はじめに
こんにちは、SREチームの田中（@j_untanaka）です。
ROBOT PAYMENTでは2年ほど前からシステムでインシデントが発生した際にポストモーテムを書いています。
ポストモーテムとは何かを『O'Reilly Japan - SRE サイトリライアビリティエンジニアリング』（以下SRE本）から引用すると「インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因(群)、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるもの」と説明されています。
いわゆる障害報告書のように顧客や上司に報告や謝罪するための文書ではなく、インシデントをドキュメント化し開発者間で共有することで学びやサービス改善につなげるためのツールとなります。
最初はSREチームで取り組みを開始し、徐々にプロダクト開発チームにも浸透していきました。基本的には先述のSRE本に記載のあるポストモーテムの例に沿った形式で書いています。
とても良い傾向で素晴らしいと自画自賛したいところですが、書いたら書きっぱなし、場合によってはアクションアイテムも残りっぱなしというケースもちらほらという課題がありました。
せっかく書いているのにもったいないということで、まずはSREチームでポストモーテム読書会を開催し過去のポストモーテムを振り返ってみることにしました。
何回か開催してみて思いのほかいい感じだったので、今回は事例とともに紹介したいと思います。
ポストモーテム読書会とは
ポストモーテム読書会とは、またまた登場SRE本の「15.3 ポストモーテムの文化の導入」に紹介されているプラクティスの一つです。
ポストモーテム読書会
定期的なポストモーテムの読書会を開催するチームで、興味深いポストモーテムや、影響の大きいポストモーテムを(美味しい軽食と共に)取り上げます。これは参加者、非参加者、新人の Googler たちのオープンな対話の場であり、起きたこと、インシデントが残した教訓、インシデントの余波などについて語り合います。レビューの対象となるポストモーテムは、数ヶ月、あるいは数年前のものであることもよくあります!
O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
〜15.3 ポストモーテムの文化の導入〜
開催方法
とりあえず始めてみようということで、現状あまり体系立てて実施はしていません。
- 月に一度業務時間内で30分間開催
- 今のところ美味しい軽食は用意できていない（これは課題だ）
- 現状全メンバーがフルリモートなのでslack callで実施
- 時間になったら集まって読むポストモーテムを冒頭で決める
- ここは時間を有効に使うため事前に決めておいたほうがいいですね（課題）
- 決めたポストモーテムを一度最初から読んだら、各々思ったことを発言して話を発散させていく
おおむねこのような流れです。このやり方だと参加者が多くなると統制がとれなくなったりお客さん状態の人が増えてしまうかもしれませんが、現状SREチームは3名の少数精鋭チームのためいい感じで成立しています。
ポストモーテム事例: 非同期処理の滞留
以下、一部抜粋および数値や各種表現をぼやかし気味にしたポストモーテムの事例と、それをネタにした読書会で話した内容をご紹介します。
対象サービス
請求管理ロボ
サマリ
請求管理ロボでは非同期処理の実行にAWS Batchを利用しています。
ある日いくつかの処理がなかなか完了ステータスにならないという問い合わせがあり状況を確認したところ、非同期処理用のキューにジョブが滞留している状態となっていました。インパクト
- 都合2時間程度多くの非同期ジョブが実行できない状態となった
直接原因
- 処理量の多いジョブが特定の組み合わせでキューイングされた場合に長時間コンピューティング環境を占有してしまうケースがあった
- オートスケール設定も上限に達しており、後続のジョブがキューに入ったまま実行できない状態となっていた
根本原因
- システムの利用状況や新規非同期ジョブ実装の追加に応じてキャパシティプランニングができていなかったこと
暫定対応
- 事象を確認後AWS Batchコンピューティング環境のオートスケール設定を見直し、より多くのジョブを捌ける状態として解消
恒久対応
- 現時点の想定として十分耐えうるコンピューティングリソースをあらためて算出
- コストインパクトも概ね問題ないことを確認の上、オートスケール設定を見直し
- 現在AWS Batchのコンピューティング環境にはECS on EC2を使用しているが、Fargate基盤へ移行すれば少なくとも急なジョブ増加にともなうキュー詰まりは発生しにくくなると考えられる（こちらは諸事情でまだできておらず対応検討中）
- キューの監視設定見直し
検出
- 顧客からの問い合わせ
教訓
うまくいったこと
- 対応に着手しはじめてから、原因の特定、解消までスムーズに対応できた
うまくいかなかったこと
- 内部で検知できず、顧客問い合わせで気づく結果となった
- キューの監視設定をしていたが、今回のケースでは重要なアラートとならない状態だった
幸運だったこと
- たまたま事情に精通したメンバーが対応可能な状態だった
本件をネタにした読書会のまとめ
もともとAWS Batch使用開始時に、その当時存在したジョブをふまえたキャパシティプランニングは実施していました。
その後徐々に開発チーム主導で非同期ジョブを追加できる状態になってきており、SREチームから開発チームに権限委譲が進んでいたということでこれはいい傾向と考えています。
しかし結果として性能要件に対する意識がちょっと薄くなったか、ジョブが増えても確保リソースはそのままとなっていたため本事象が発生したと考えられます。
上記をふまえるとあらためてコンピューティング環境のFargate移行は有効な手段となります。Fargateにすることで基盤のリソースを意識することが減るためです。AWS Well-Architectedフレームワークにおいても「キャパシティーニーズの推測が不要」であることを設計の原則として挙げています。
AWS Well-Architected フレームワーク > はじめに > 一般的な設計の原則
Fargate移行できたとして、コンピューティング環境の制約がなくなる分ボトルネックがDBに移ることが考えられます。DBのモニタリングが十分にできているか見直す機運が高まります。また利用コストのモニタリングも注意が必要になりそうです。
いかがでしょう、わりと掘り下がった感じがしませんか！
おわりに
SRE的な文脈で語られるプラクティスの中でもポストモーテムは個人的に特に好きなものの1つです。
起きてしまった問題を前向きに振り返り次に繋げること、人ではなくシステムやプロセスの改善にフォーカスすること。始めるのも難しくないので、このようなSREの実践に必要となる考え方を組織に浸透させる入り口としても最適だと思います。
せっかく書いたポストモーテムはそれで終わりにせず、定期的に読み返して有効活用していきたいものです。
We are hiring!! 絶賛仲間募集中です。
