「え、なにこれ。うち、 memcached なんて使ってたっけ……」
エムスリー SRE がお届けするブログリレーの 10 日目。エンジニアリンググループ / 電子カルテチームの山口 (@no_clock) です。
入社直後はサーバサイドメインのソフトウェアエンジニアでした。 SREの民主化とクラウド移行にある民主化の流れに「やってみたいです〜」と宣言し、 1 年半前から電子カルテチーム内の SRE も兼任しています。
今回は、「兼任」が功を奏して謎のインフラコンポーネントをコード化できた話です。
- 知っている人が誰もいない状態
- 「memcached サーバ……？」
- Terraform で管理されていない、システム構成図にもない
- 利用されているか、 Web アプリケーションのコードを確認する
- 適切に IaC にするために、やはりコードを確認する
- 振り返り: 同じ過ちを繰り返さないために
- まとめ: 「チーム内 SRE」は面白い
- We're hiring! チーム内 SRE 、どうでっか？
知っている人が誰もいない状態
「このアプリ/インフラ、知っている人が誰もいないぞ……」という状態は、時として発生してしまうことがあります。要因としては以下のものが思い浮かびます。
- 知る必要性が低い
- 長期間変更がなく、安定稼働している
- 知るチャンスがない
- 普段意識する機会がなく、そもそも存在に気づかない
- なかなか手が出ない
- 複雑度が高すぎる
- 自分の技術スタックと合わないか、興味が湧かない
- チームメンバの入れ替わり
- 知っている人がいなくなる
電子カルテチームのインフラコンポーネントでも、「知っている人が誰もいない」状態が発生しました。
「memcached サーバ……？」
電子カルテチームでは、 2 年前から Infrastructure as Code を実施しています。
Terraform を使っていましたが、最近サービスの成長に合わせて CDK + TypeScript ベースに一新しました（詳細： Infrastructure as "型付き" Code - 急成長する事業のインフラ再構築）。
その移植の最中に、気づいてしまいます。
「環境変数に MEMCACHED ってあるけど、 memcached なんか使ってたっけ……」
Terraform で管理されていない、システム構成図にもない
AWS コンソールを確認すると、確かに memcached サーバがありました。作成日は 5 年以上前。電子カルテサービスが始まる前です。
一体何をキャッシュしているのかわからない
しかし、 Terraform での定義はおろかシステム構成図にも memcached は見当たりません。チームメンバも知らないようでした。
なんなんだ、この memcached サーバは。
利用されているか、 Web アプリケーションのコードを確認する
この誰も知らない memcached サーバは本当に利用されているのでしょうか。これを確認すべく、環境変数から Web アプリケーションでの使用箇所を特定していきます。
幸い、 Ruby on Rails で書かれたコードには親しみがありました。そのコードを辿っていき、無事にたった 1 箇所で使われていることを特定しました。
適切に IaC にするために、やはりコードを確認する
システム構成図に memcached を追加しつつ、このタイミングでコード化 (IaC) することとしました。
ただし、スペックや設定値は以下の情報から再検討します。おそらく 5 年以上前に作成したまま「運良く動いている」だけで、適切な設定値である確証がないためです（正直、とても怖い状態です）。
- CloudWatch Metrics: 過去のメトリクス
- Ruby on Rails で書かれたコード: memcached の使い方
- 今後のサービス成長予想
これらを踏まえた結果…… 「負荷は非常に小さく、 t3.micro の小さなインスタンスタイプで運用し続けてよい」との判断に至りました。
こうして memcached サーバはコード化され、無事に謎が解けましたとさ。めでたしめでたし。
振り返り: 同じ過ちを繰り返さないために
今回は一件落着しましたが、今後繰り返したくありません。振り返りましょう。
原因: なぜ起きたか
なぜ、誰も知らない memcached サーバになってしまったか。前述の「知っている人が誰もいない状態」で挙げた要因に当てはめると、今回は以下が要因と言えそうです。
- 知る必要性がなかった
- 安定稼働し続けており、手を入れる必要がなかった
- 知っていたメンバも普段から気にかけるコンポーネントではなかった
- 知る機会がなかった
- 構成図になかった
- Web アプリケーションのコード上に利用箇所がほとんどなかった
- Terraform で管理されていなかった
- 変更が入らないため、 Terraform 管理の必要性が低いと判断され放置され続けた
- チームメンバが入れ替わった
- サービス開始から 5 年を経て初期メンバはほぼ居なくなり、知っている人がいなくなった
知る機会を得ぬままチームメンバが入れ替わってしまった結果、誰も知らない状態になってしまった…… ということです。
改善策: 繰り返さないために何ができるか
では、今後誰も知らない状態を避けるために何が出来るでしょうか。いくつか策が思い浮かびます。
- システム構成図への反映漏れを防ぐ (レビュー観点への追加、定期的な更新等)
- システム構成を共有する定期的な場を設定する
- Infrastructure as Code でコードを読めば分かる状態にしておく
個人的には 3. が良いと考えています。インフラとコードの同期 (Infrastructure as Code) を維持することで、再利用性の向上やバージョン管理だけでなく「コードを読めば分かる」利点も維持出来るわけです。
今回のコード化も、これを実現する一環と言えます。システム構成図は、その理解を補助するドキュメントという位置付けです。
まとめ: 「チーム内 SRE」は面白い
特定プロダクトの SRE である「チーム内 SRE」の一事例でした。
今回の調査やコード化は、「チーム内 SRE」だからこそ効率良く出来た面があると感じています。
- Web アプリケーションのコードに慣れており、 memcached の使用箇所の特定が容易だった
- サーバのスペックや設定値が適切であるか、インフラストラクチャとアプリケーションと事業計画(サービス成長)の 3 面から検討できた
綺麗に表現すると「境界がなくなり、自由に動ける範囲が広がった」、率直に表現すると「チーム外のメンバに依頼したり説明したりすることが減って楽」という印象です。良いです。
We're hiring! チーム内 SRE 、どうでっか？
「境界なく自由に動ける」チーム内の SRE になってみませんか。
例えば電子カルテチームでは、今後の成長に合ったシステム構成を一緒に考えるメンバを心待ちにしています。興味がありましたら、カジュアル面談でワイワイ議論しましょう。関西弁でなくても大丈夫です。
