新米SREとしての半年を振り返る

以前の記事にあるように、かれこれ8年くらいやっていたiOS開発を一旦離れてフルタイムのSREに転向するという決断をした。それから約半年が経ったので、ここまでどのようなことをやったか振り返ってみる。まだまだ経験の浅い分野なので語彙に厳密性が欠けているかもしれない。

やったこと

Kubernetes

やはりこれを触ることが一番多い。弊社ではマルチテナントのクラスタが5つあり、うち2つがDCで、3つがAWS上で動いている。アプリケーション開発者やCI/CDパイプラインはGoで書かれた内製のコマンドラインツールを通じてクラスタとインタラクトする。つまり、開発者向けに新機能のサポートする度に、このツールのインターフェースを拡張することになる。

StatefulSets/Ceph

そうした中でもステートフルなアプリケーションのサポートが一番目立った変更だった。マネージドのサービスをほとんど利用しておらず、MySQL・Cassandra・Elasticsearch・Kafka等のステートフルなアプリケーションが必要な場合は、開発者がセルフサービスでサーバーを立ち上げてChefでプロビジョニングするというワークフローだったが、これらを全てKubernetes上に移行しようとしている。

DCではStorageClassにCeph RBDを使うことになったため、Rookを利用してCephクラスターをセットアップするという大きめのタスクがあり、それに長い時間を割いた。

Prometheus

ステートフルなアプリケーションのパイロット版として、まずPrometheusをKubernetes上に移行することになった。100近いノードがあって、その平均CPU使用率がわずか7%なので、コスト面でもかなりの改善が見込まれる。

具体的な作業は、Prometheus Operatorが定義するリソースを簡単にデプロイできる仕組みを作ることに終始する。ついでにThanosやPromlensのセットアップも行い、モニタリング周りの体験はかなり良くなった。ちなみにThanos Rulerを実用段階1にしたところで今年は仕事納めとなった。

とはいえ、実際のマイグレーションは始まったばかりで、ダッシュボードのデータソースも順次Thanos Querierに切り替えていく必要があり、来年始もしばらくこれにかかずらうことになりそうだ。

Cassandra

弊社ではオンラインパス上にあるWritableなストレージは基本的にMySQL Percona XtraDB ClusterかCassandraのどちらかである。社全体としてCassandra運用の知見が不足していて、古いバージョンのクラスタやまずい設定が散見されていたので、これらをまとめて改善するタスクがちらほらあった。

多くのアプリケーションが依存しているにも関わらず可用性に問題のあるクラスタがあり、そのMulti-DC移行の準備も進めている。

Docker

基本的にパブリックのコンテナは使わず自前でビルドするという戦略をとってきたが、辛いケース2が出てきたので、Trivyを使ってスキャンしてから社内のレポジトリにミラーリングする簡単なアプリケーションを実装した。

モバイル開発とのシナジーがあるか

使用する言語も開発のコンテキストも全然違うので、正直オーバラップはほとんどない印象。ただ、モバイル開発ではよくあるように、20人くらいで触るモノリシックなアプリケーションの開発を体験しているので、言語が変わってもコードの読み書きやGitHub上でのコミュニケーションには結構自信があり、コーディング系のタスクでは早い段階で戦力になっていたと思う。

モバイルエンジニアの視点が入ることで、システム全体の最適化がしやすくなったとも思う。Postmortemではバックエンドの議論が中心になって、インシデント中のクライアントの挙動はあいまいな理解に終始することがあるが、そういう時にある程度正確な情報を提供できる。クライアントのリトライ処理がまずく、長い間Cascading Failureの温床になっていた箇所を発見して修正することもできた。

学習コスト

先に述べたように技術的なオーバーラップが少なく、新たに覚えることが多くて大変ではあったが、どういうアクターがいるかさえ把握できれば概念レベルでの理解はそこまで難しくないと思うので、分散システム、Linux、TCP/IP、DNS、仮想化、ストレージ等、メジャーなトピックを全て20%くらいさらって、80%の仕事を遂行できるようにするという戦略をとった。

CS出身でもないし、この分野に携わるようになったのも遅いので、残りの20%がすぐできるようになるかということに対しては悲観的だ。あまり遠回りする余裕がないライフステージにいるので、ここからは慎重な取捨選択が必要になりそうだ。

お気持ち

「一般的には3」モバイル開発者のコンピュータの理解はどうしてもインフラの人たちよりは浅く、そこの差を埋めるのは大変だと感じる。どっちが高度かという話ではない。不確定要素の高いUIレイヤで、プロダクトのデッドラインを常に意識し、大人数でモノリシックなコンパイルに時間のかかるアプリケーションの開発するのは難しいし、正直めちゃくちゃ辛いことも多い。

技術のキャッチアップは大変だが精神的にはSREに移ってからのほうが余裕がある。社内に自分の仕事のユーザがいて、組織内でのビジビリティが上がったことも、仕事の満足度に繋がっている。

裏を返すと、定量化しにくいモバイル開発のチャレンジがエンジニアリング組織内で適切に評価されることの難しさを痛感している。また、バックエンド・インフラに比べると汎用的な話題も少ないので、適切に評価できる人も限られているのではないだろうか4。

  1. SREになるまで「なんでこいつらはこの言葉をこんなに連呼するんだ」と内心思っていたが、やっと気持ちが分かった ↩︎

  2. 特にCeph関連のコンテナ ↩︎

  3. 当然フロントエンドでサイエンス的に高度なことをすることもある。ただ、扱うテクノロジや計算量のオーダーの傾向で言えば、そのようなケースは相対的に少ないと思う ↩︎

  4. おそらく組織の成熟度にもよるだろう。「とにかくフロントを作らないと何も始まらん」というフェーズの組織では全然様子が違うかもしれない ↩︎