「ユメミルクスリ」をプレイした

2005/12/22発売のユメミルクスリを最後までプレイした。

この作品を今プレイした理由は2022/10/05に公開された以下の動画で作品のOPを聴いたから。

www.youtube.com

個人的にここ一年近く配信を見ていた人の久しぶりの歌ってみた動画で、自分はこの作品の世代でもないし知名度を正確には知らないので、なぜこの曲を選んだのか全く理由がわからず逆に興味が出てきたと言う感じ。

ユメミルクスリ自体も十年以上前から存在は知っていた作品だし、5月にも同じブランドの「つくとり」をプレイしていたのでこの機会にやってみるかと思って始めた。

感想はあまり言うとネタバレになるので細かいところは言えないけれど、作品内のとあるキャラクターと歌った人の活動におけるスタイルが強く重なる部分が感じられる部分があり、そこを意識して欲しくて選んだのではないかと思えるような印象的な作品だった。(もちろん合っているかは本人にしかわからないけれど)

少なくとも自分には二人の初見のインパクトと長く見てきた中での印象のどちらもがかなり近くてルーツとすら思えるほどだった。

また別のあるルートではそう言ったことと関係なく自分の過去の体験を思い出すようなシーンもあり先が気になって一気にプレイしてしまった。

こういった複数の理由もあって個人的にかなり刺さった作品になった。

パッケージに似合わずすごく現実的な作品で描写など人を選ぶ部分はあるけれど、あえて言うなら学生時代に死にたいと思ったことがあるような人には特に刺さるそんな作品だと思う。

余談

仕事でAsanaを使っているのでスクショを同僚に見せたところウケが良かった。

Fluent Bit のメトリックを Mackerel に送る

Fluent Bit では以下のようにHTTP_Serverを有効にすることで内部のメトリックをHTTP経由で /api/v1/metrics というパスからJSON形式で取得できるようになります。*1

[SERVICE]
  HTTP_Server       On
  HTTP_Listen       127.0.0.1
  HTTP_PORT         2020

これで各プラグインで今までに処理したレコード数やバイト数が取得できるわけですが、実はこのJSONはmackerel-plugin-jsonでそのまま扱える形式になっています。

下はoutputのcloudwatch_logsプラグインに対してのメトリックを送信する例です。

$ mackerel-plugin-json -prefix='fluent-bit' -url='http://127.0.0.1:2020/api/v1/metrics' -diff='.?' -include='output.cloudwatch_logs'
fluent-bit.output.cloudwatch_logs.1.retries 0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.retries_failed  0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.dropped_records 0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.retried_records 0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.proc_records    0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.proc_bytes  0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.errors  0.000000    1653008277

このようにdiffオプションを使ってFluent Bitで1分間に処理したログに関するメトリックをMackerelで確認することができるようになります。

ユースケースとしては、Fluent Bit経由でCloudWatch Logsにエラーログを送っているけどエラーの増加はMackerelで通知したいという時にわざわざCloudWatchから集計しなくても良くなるというのがあります。

ちなみにmackerel-container-agentのpluginsイメージにはmackerel-plugin-jsonが最初から同梱されているので、HTTP_Serverを有効にすればあとはすぐに取得できるようになります。

参考

htnosm.hatenablog.com

cohalz.co

*1:https://docs.fluentbit.io/manual/administration/monitoring#metrics-examples

distrolessのnonrootイメージを使おう

この記事は はてなエンジニア Advent Calendar 2021 11日目の記事です。

コンテナのベースイメージとしてdistrolessを選択肢にするということがここ最近増えてきました。

そんなdistrolessを非rootユーザで使おうとしたらとても簡単だったのでその紹介です。

どのくらい簡単かというと、Goのアプリケーションであれば以下のように変えるだけで対応できます。(コメントアウト部分は元々のrootユーザで動かしていた場合のもの)

FROM golang:1.17 as builder

WORKDIR /go/src
COPY go.mod go.sum .
RUN go mod download
COPY . .
RUN go build -o /out/myapp .

# FROM gcr.io/distroless/static:latest
FROM gcr.io/distroless/static:nonroot

# COPY --from=builder /out/myapp /usr/local/bin/
COPY --from=builder --chown=nonroot:nonroot /out/myapp /usr/local/bin/

distrolessでは2019年にマージされた以下のプルリクエストで非rootユーザである nonroot ユーザ及びそれを利用するための :nonroot というイメージタグが導入されました。

github.com

:nonroot のタグはstaticに限らずdistrolessの全イメージで使うことができ、簡単には :latest はrootユーザで :nonroot はnonrootユーザという区別がされています。

なので非rootユーザ対応は基本的には :nonroot にするだけで良いですが、マルチステージビルドの場合はbuilderステージで作成されたものはユーザを指定していない限りrootで作成されて実行できなくなってしまうのでCOPY時にchownオプション*1で nonroot:nonroot を指定してあげる必要があります。

ちなみにnonrootというユーザは :nonroot イメージに限らずどのイメージでも作成されているのでDockerfileに USER nonroot と書くという方法でも冗長だけど一応実現は可能です。

cohalz@co ~ % docker run -it --rm gcr.io/distroless/static:debug
/ # cat /etc/passwd
root:x:0:0:root:/root:/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/sbin/nologin
nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin

ちなみにdistrolessはnonroot以外にもbusybox入りのdebugイメージやアーキテクチャも指定することができますが、全部使いたい場合は順番としてはdebug-nonroot-arm64 といった順番で指定するという感じになっています。

この :nonroot イメージは少しずつ利用が広がっており、google/koも2020年10月に出たv0.6.0からデフォルトではこのnonrootイメージを使うようになっています。

cloud.google.com

セキュリティ対策をちゃんとしようという流れがある中、コンテナイメージの非root化をまだ全然やれてない人は数行変えるだけで試せるdistrolessからやってみてはどうでしょうかという記事でした。

明日のアドベントカレンダーの担当は id:papix さんです。

*1:Docker 17.09から利用できる https://docs.docker.com/engine/release-notes/17.09/#17090-ce

Google Cloud Innovators Gym Japan に参加して Professional Cloud Developer に合格した #giggcp

Google Cloud

Google Cloud Innovators Gym JapanというGoogle Cloud主催のトレーニングプログラムに第二期生として参加しました。

その結果Professional Cloud Developerに合格することができた*1のでそのレポートです。

cloud.google.com

トレーニングを受ける前の経験

  • Google Cloudの実務経験はなし
    • AWSの経験はあるけど資格は一つも取ってない
  • Kubernetesに関してもPod、ReplicaSet、Deployment、Serviceが何を指しているかはわかるくらいの知識くらいしかない状態

試験に向けて勉強したこと

基本的にはトレーニングプログラムで用意されたものを使って対策しました。

具体的にはpixivさんの記事にあるとおりで Google Cloudのエンジニアが行うセッション+ハンズオンと、Courseraのコースが無償で提供されるのでそれを進めていくという感じです。

inside.pixiv.blog

例えばこんなコースを受けていました。 www.coursera.org

Courseraに関しては動画を見る・Qwiklabsと連携したハンズオンを行う・テストを受けるのサイクルで結構効率よく学べました。

下の記事にもある通り、Qwiklabsのハンズオンが非常に良くできていて、実際にGoogle Cloudの環境を用意してハンズオンをすることができました。 コマンドを打つときも基本的にCloud ShellとCloud Shell Editorを使う手順になっているので手元の環境に依存することはないです。

dekotech.dekokun.info

その他では本を読むとかはしていなくて、Courseraのテストや模試で間違えたところはちゃんとドキュメントを見るというのをやったくらいです。

掛けた時間としてはセッション+ハンズオンとCourseraのコースを8つほど受けて、大体50時間弱くらいかなと思います。

スケジュールとしては6月に入ってからCourseraのコースをやり始めて6/24にAssociate Cloud Engineerに合格、7/6にProfessional Cloud Developerという感じです。

感想

普段業務で触れていないGoogle Cloudについて知る機会になってとても楽しかったです。

試験の内容自体もクラウドネイティブなアプリケーションの構築ができるかどうかを問われている問題も多く、腕試しという感じで楽しく受けられました。

せっかくなのでトレーニングプログラムの期間中にProfessional Cloud Architectも取得目指してみたいなと思いました。

*1:https://www.credential.net/b75defee-e669-4501-ab71-cc0f1ac2f5b8?key=d280a26a24860162a90555caedb0e2837fc782d1feacc63e633e41f8cd091944

Webサービスのモニタリングについてのチェックリスト

この記事は はてなエンジニア Advent Calendar 2020 11日目の記事です。

はじめに

運用しているWebサービスについて、より良いモニタリングにしていくために普段考えていることをチェックリスト形式でまとめてみました。

全部にチェック付いていないとダメというわけでもなく、Webサービスの性質によっては当てはまらないものもあると思うので参考程度に現状を把握するツールとして使ってください。

チェックリスト

疎通確認

  • それぞれのコンポーネントに対して疎通確認を行っている
  • localhostでなくネットワーク経由でのコンポーネントへの疎通確認を行っている
  • 疎通が取れなかったときに正しくアラートになることを確認している

メトリック

  • 可能な限りチェック監視ではなくメトリック経由での監視にしている
  • ビジネスロジックに関わる値をメトリックにしている

ログ

  • 利用しているログ配送システムの可用性や完全性について理解している
  • ログをメトリックにする際に詰まってしまった場合のことを考慮できている

アラート通知

  • 閾値の根拠をアラート通知から確認できるようにしている
  • アラート発生時にどうすれば良いのかをアラート通知から確認できるようにしている
  • SLOに関係するような重大なものとそうでないものでアラートのレベルを使い分けている
  • 通知の再送を設定している

HTTPリクエストの場合

  • 5xx系だけでなく4xx系もモニタリングしている
  • nginxを使っている場合、499とその他の4xx系を区別してモニタリングしている
  • レイテンシの平均及びパーセンタイル値をモニタリングしている
  • 以上の項目をエンドポイント単位でモニタリングしている

バッチの場合

  • バッチの実行に成功したかどうかをモニタリングしている
  • バッチの実行時間をモニタリングしている
  • 決まった時間に実行されているということを監視している

ジョブキューの場合

  • 正しい結果が返ってくる割合をモニタリングしている
  • 処理の遅延状況をモニタリングしている
  • ジョブキューに入ってきたジョブの数と処理したジョブの数をモニタリングしている

ダッシュボード

  • The Four Golden Signalsに従ってダッシュボードを構築している
  • 単なる数字ではなく割合を確認している
  • 1日前や7日前と比較した数値を確認している
  • リリースタイミングをダッシュボードから確認できるようにしている
  • 開発イテレーションの期間内だけでなく数ヶ月以上での傾向も確認している

開発メンバーとの振り返り

  • リリース・障害に伴って数字に変化は現れたか確認している
  • 監視項目について議論し見直しを行っている
  • 半期や四半期の単位で起きた障害について原因を分類できている

その他

  • サービスの構成図やリクエストのフロー図を用意している
  • 依存している他サービスがあれば、そのサービスが動かなかったときの影響を考慮できている

おわり

他にも色々あったような気がしますが、とりあえず思いついたものはこのあたりです。他にもあれば教えて下さい。