こちらを読み終わったので感想です。
買ったモチベーション
ジャケ買い
SRE界隈について思うこと
本書と関係ないけど最近SRE関係のテック情報がよく入ってくる、気がする。
わたしがエンジニアになったのは2020年でそれよりも前のことはわからないけどなんとなくAWSが主流で業界全体的にオンプレからクラウドに移っており、インフラエンジニアと呼ばれるロールが重宝されてそうな感じがした。
さらに、自動テストやデプロイサイクルを多く回すためにCI/CDの構築などが重要視されていてそこら辺をインフラ含めて良い感じにするのにDevOpsみたいなワードをよく耳にした気がしなくもない。Dockerやk8sのようなコンテナ技術がまだ技術トレンド感があった気がするのでそこら辺も良い感じに扱えるという意味合いもあったのかもしれない。（というかDevOpsが何を指しているのかいまいちピンときていない）
今となってはクラウドもDevOpsの領域も技術への関心がちゃんとある組織であれば当たり前のように使われてると思う。
エンジニアのロールをざっくりわけるとフロントとバックエンドとインフラだけどバックエンドとインフラの領域はかなり重なっている。コードが書ける優秀な若い人は死ぬほどいるのでぼーっとしていると自分の居場所がなくなるんじゃないかという不安をおじさんは感じなくもない。
そうすると、なんとなくそこまで競争率が高くなくできるとみんなが嬉しいインフラやDevOpsと呼ばれる領域にシフトしたほうがいいんじゃないかという気がしなくもない。
インフラやDevOpsが主戦場の方に怒られそうではあるがそこまで経験がないバックエンドエンジニアがキャリアの生存戦略的なことを考え、インフラやDevOpsを気にしていた人は多いのではないか？わたしは気にしてた
で、最近はインフラやDevOpsというワードよりもSREというワードをよく目にする。SREを新規で立ち上げたいと思ってる組織が多いとは思っていたけど最近そんなにSREいるのってくらい目にする気がする。
しかも、最近のSREはDataDogやNewRelicのダッシュボードを構築・モニタリングして、SREがなんたるかをちゃんと知ってチームがまわっていてい、コードも普通に書けて、k8sに精通していてその周辺エコシステムというか技術トレンドもちゃんと追いかけているスーパーエンジニアのように見える。
なんとなくインフラエンジニア -> DevOps -> SREのようにサーバーサイドエンジニアの逃げ道が変化していったように感じる。(逃げ道とかいうと本業の人に怒られそう。）
特にk8sに精通したいと思っているエンジニアは多そうで、SREがk8sのスペシャリストっぽい雰囲気を最近感じるのでキャリアをSREに軌道修正しようとする人とかいるんじゃないだろうか。わたしはしようとした
何にせよSREという職域に勢いを感じる
SRE関係の技術
なんとなく言葉は知ってるけど何かよくわかってなかったものたち
Prometheus
Grafana
NewRelic
OpenTelemetry
eBPF
オブザーバビリティー
あってるか？このような言葉はよく聞いていて、何となくSREの領域の技術なんだろうなーとざっくり思っていた。
本書を読んで
Prometheus本を買ったのは完全にジャケ買いで何となくk8sも絡んでるし面白そうだから買ったけど結果1年くらい寝かせてしまっていた。
Prometheusを今後使うことがあるかはわからないけど思ったよりも学びは多かった。
Prometheusが何か知れた
関連して上述したSRE関連の技術も調べる機会になった
全体的にシステム監視についての解像度が上がった
基本的に本書の内容はdockerとk8s(kind)を使って手元に構築するので手を動かしながら学べる。が、結局一気に読み切ってしまった。言い訳として半分くらいはyamlファイルにどのような項目があって何を書くかみたいな話になるので飛ばしてしまった。k8sといいほんとにyamlファイル書くこと多いよね、下手したらyamlしか書かないんじゃないかってくらい書く気がする。
ただ、本書の内容は大変わかりやすく退屈になることはまったくなかった。
念願のぴよログダッシュボード
育児をした方はわかると思うが令和の子育てに「ぴよログ」は必須だ。このぴよログのエクスポートデータを使い、Grafanaで育児ダッシュボードを作った人たちがいるのをTwitterで知って、自分もやりたいと思っていた。てか、最初見た時まじで感動した。
結果的に途中で断念してしまったが一応途中までは作った。というのも上記のリンクの内容もそうなのだがぴよログのエクスポートデータをGoogle Driveに保存して、そのファイルを何かしらのCron処理で解析しPlanetScaleのようなサーバーレスDBに育児データとして保存する。その保存したデータをデータソースとしてマネージドのGrafana Cloudを使って可視化するみたいな流れだ。そう、Prometheusを使わない。
それじゃあやる意味薄れるなと思いローカルでカスタムエクスポーターを自作してGoogle Driveの育児ファイルからメトリクス取るかと考えた。
ただどう考えても非効率なのでやっぱりGoogle DriveにファイルをあげたタイミングでGASでDBに育児データを保存して、そのDBに対してエクスポーターを作成するかと考えた。
いや、じゃあ直接データソースにDBを指定して可視化すればいいじゃんとなって結局目新しさのない二番煎じだと思うとやる気がなくなってしまった。（言い訳）
しかも、その育児データからメトリクスとして何を取得するのかは難しい問題で、そういうメトリクス設計というかダッシュボード設計みたいな難しさを感じれたのは良かった。
おわりに
結局当初の目的だったぴよログダッシュボードは作成しなかったけどPrometheusをはじめシステム監視まわりの解像度が上がったのは良かったと思う。実際自分がPrometheusのような監視システムを構築することがあるかはわからないがDataDogやNew RelicのようなSaaSで監視基盤を構築することは大いにあるかもしれない。その時にPrometheus本で学んだことは大いに役立つかもしれない。
さらに、SREの仕事の奥深さも感じれた。上述したがメトリクスとして何をどう取得するかやダッシュボードをどう構築するか、もしPrometheusならばPrometheusをどこで動かしてそれを運用しなければならない。k8sのようなコンテナ環境でアプリが動いているのであればそういったコンテナ技術にも精通していなければならないし、その複雑なコンテナ環境を適切に監視しなければならない。
そして、SREチームがどこまで仕事を持っているかはわからないがそれ以上にもう少しインフラよりなことやQA的な話やアプリケーションコードを触ったりなどかなり仕事が多岐にわたりそうだなと感じた。
どこかでSREは目指すものではなく気づいたらなってるものという登壇スライドをみたことがあるがほんとそんな感じのイメージを持った。
何が言いたいかというと自分にSREはまだ早すぎるのでおとなしくサーバーサイドエンジニアとしてもうしばらくは精進します。