こんにちは、エムスリーエンジニアリングGの榎田です。趣味は数学とゲームです。数学はここ半年ほど 微積分の勉強 をしていて、ぼちぼち微分形式の話ができそうです。ゲームは黎の軌跡（日本ファルコム軌跡シリーズ最新作）を遊んでいます。初週ナイトメアでも遊べるバランスなのがよいです。あとフェリちゃんがかわいい。
お仕事では Docpedia という医師向け Q&A サービス を開発するチームでの仕事が半分、チーム SRE としての仕事が半分、という立ち位置です。最近、その Docpedia チームで GameDay というものをやりました。その過程で色々なことが学べたので、今日はその話を書きます。
GameDay とは
GameDay という言葉そのものは、AWS が開催している DevOps イベントに由来します。
オリジナルでは DevOps に関する幅広い出題が考えられるようですし、チーム戦でスコアをつけたりできる問題を出すようですが、今回私たちのチームで実施するにあたっては、単純に「検証環境で障害を起こすから、復旧してね」という問題を出すことにしました。普段インフラ寄りの仕事をしている私が出題役で、同じチームの他の3人が攻略役です。攻略側は普段あまりインフラは触っていません。攻略時間は1時間取りました。
出した問題
ぱっと見
Docpedia の検証環境がブラウザで開けなくなっているので、それを直してください、という問題を出しました。
裏で何を壊したか
以下の2箇所を壊しました。
- Docpedia のインフラは、アプリが動いているコンテナの前面に ALB が立っている、という構成になっています。その ALB のリスナーを落としました。
- 上記を含むインフラは terraform でコード管理されています。その tfstate をわざと別のファイルで書き換えました。
逆に、普段チーム全員がよく触るアプリコンテナ部分は一切手を入れませんでした。
結果
1時間経過したタイミングで、攻略側が手動で ALB のリスナーの復旧に成功しました。tfstate については復旧までは至らなかったので、どのような障害を起こしたか私の方から解説する形にしました。
問題設計の意図
私が攻撃側にまわって問題を作るにあたり、以下の点を意識しました。本家の GameDay でこれらの点が意識されてはいないでしょうが、せっかくやるからにはと思ってあれこれカスタムした感じです。とはいえ考えすぎると出題側の負担になるので、あまり考えすぎないほうがいいだろうとも思います。問題を作る際のヒントのひとつとして見ていただければと思います。
ひどく難しくしない
この問題は実際には更に難しくすることもできはします。ALB に加え、DB の接続情報も壊して、コンテナ台数も手動で0台に変えておいて、CI でのデプロイジョブも機能しないようにして…といった具合に、障害を何重にもすればよいです。が、そうしても攻略側がつらくなるだけで、いい問題になるとは思いません。今回の出題形式を取るなら、ポイントをきっちり絞るくらいでよいと思います。
できることを制限しない
本番で障害が起きたら、とりあえず前バージョンのコンテナに戻したり、コードの diff を取ったり、インフラがコード管理されているなら ansible の dry run や terraform plan をしたりすると思います。これらに代表されるような、本番障害時にできる調査手段は一切制限しないと決めて問題を作りました。
調査手段を限定するというレギュレーションで問題を作るほうがよい場合もあると思うのですが、まずはもっとも本番に近い状況にしよう、と思った次第です。tfstate に手を入れたのは、この前提のもと「terraform plan で現状確認をしよう」という動きを想定しての先回りです*1。
引き継ぎ
この下期から、私は徐々に Docpedia の担当を離れてチーム SRE としての仕事に重心を移す予定です。それを踏まえて、半ば引き継ぎのつもりで、「私しか知らないことを減らす」ことを意識して問題を作りました。なので、全員がよく触れるアプリコンテナ部分から少し軸足を外して、
- インフラの基本的かつ機能に直接関わる部分（ALB のリスナーを含め、コンテナ以外になにがあるのか、どのような仕組みでアプリが動くのか）
- 普段表に出ないがインフラ保守上で致命的に重要な部分（tfstate の仕組みや中身、その置き場所、管理の重要性、そもそもどうして terraform plan が可能なのか）
といったところに焦点を当てました。いずれも一度インフラを構築すると透明化しがちな部分です。
感想や学び
このイベントを通して、当初の問題に込めていた目論見を越えて、いろいろなことがわかりました。
一人でも文殊、三人でもっと文殊
GameDay の実施会場の zoom には私も聞き専で参加していました。攻略中のやりとりを聞いていた範囲でも、今回の問題のポイントであった
- ECS コンテナじたいは正常に動作している
- が、ALB のリスナーが落ちている
- terraform plan が正常に動作しない
の全てについて、攻略側の3人の誰かには気づかれていたようでした。終了後の振り返りで「これらは気づいてましたよね？」と確認したところ、やはり気づかれていました。やはり各々アプリの開発やデバッグには慣れているので、普段見ていないところでも調査する手腕が発揮されていてさすがだなと思いました。
ただ、ここで「誰かには気づかれていたようでした」と書いたのはわけがあります。これは、攻略中に何気なく口走っていたことがらなどから「おそらくこの人はこれに気づいているだろうな」と推測した、ということです。もっと言うと、3人の共有知にまではなっていなかったポイントでした。攻略に必要なピースの全ては各々の気づきの中にあって、あとはそれを組み合わせるだけだった、とも言えます。その「組み合わせ」をよりよく進めるために、
- 障害発生時には「正常に動いている」も一つの情報なので、きちんと共有する。
- 事象の正確な共有をする。その際、やった操作を正確に口で言うのは難しいので、画面を共有してみせるなどがよい。
といったところが次に活かせるポイントだったのではないか、という振り返りをしました。
権限があることと実際に行動に移せることは違う
先に述べたとおり、今回の問題は「できることを制限しない」という意図で設計しました。初回をこの設計にしておいてよかったと思います。というのも、権限を持っているかどうかに関わらず、
- ログを見に行ったり、他の環境と比べて diff を取ったり、という調査のための手段を知っている。
- aws console から直接ポチポチ色々いじったり戻したりする手順を知っている。ボタンを押す度胸がある。
- terraform plan してインフラの現状把握をできる。terraform plan をするディレクトリも知っている。plan が正常に終わったときのターミナルの表示も見たことがある。
といった、何度か対応しているうちに「慣れて見えなくなってしまう」ポイントがいくつかあることがわかったからです。攻略側のみなさんからも、「自信がない部分もあったので、これが本番でなくてよかった」というコメントをいただきました。
2回目以降は、たとえば「あまり知られてないけどこのツールみんな使えて便利だし知られてほしいな、このツールの布教を目的にするか」という考えのもと、制限レギュレーションで実施する、というのも案かもしれません。
古いドキュメントが見つかる
システム構成図などを置いておくドキュメント置き場があり、攻略側のみなさんは攻略時にそこを見に行っていました。それ自体はよいことなのですが、そこにある文章が更新されずに古いままになっており、ひとり申し訳ない気持ちになっていました。これをうけて、ドキュメント置き場のホコリ落としをはじめました。
解かれないと悔しい
これはかなり個人的な話ですが、いいところまで行ったのに完全には解かれないと悔しかったです。
We are hiring！
今回手探りで GameDay を実施しましたが、いろいろな学びがあってよかったです。状況に応じて色々カスタムして出題を考えられるのは出題側としての面白さでした。このような問題の先にある本番運用を担うエンジニアは絶賛募集中です。ぜひご検討ください。
そして、もし良い問題の作り方をご存じの方は入社して出題側に回っていただけるとうれしいです。喜んで解きにいきます。
*1:かなり個人的な話をすれば、私自身 tfstate が破壊されたときに terraform がどのようなエラーを吐くか見たことがなかったので、一度見てみたかった、というのもあります。
