こんにちは。プロダクト本部プラットフォーム部SREチームのid:ut61zです。
サービスを運用していくうえで監視は避けて通れません。
Classiでは長らく朝当番という制度を設け、平日朝のピークタイムにエンジニアを監視担当としてアサインし、何らかの問題が発生した際、即座に対応できる体制を整えてきました。
2020年9月からスタートした朝当番制度ですが、2024年4月をもってこの制度を終了しました。
今回はその経緯や理由、現在のClassiの運用体制などをご紹介します。
朝当番とは
あらためて朝当番制度とは、平日朝のピークタイムにエンジニアが常に1名待機し監視する制度になります。担当エンジニアは各種メトリクスに異常がないかチェックし、問題や気になったことがあれば関係各所に情報連携を行う役割を担います。
朝当番制度の目的、背景、期待される効果など、以下のブログに詳細が記載されていますので興味があればぜひご覧ください。
上記ブログ執筆時点(2022年)でもすでに19人のエンジニアが朝当番を経験し、今日に至るまでには述べ51人のエンジニアが朝当番を担当してきました。
Classiのシステム、そしてエンジニア組織の変化と共に朝当番もアップデートされてきました。
遍歴を追ってみましょう。
朝当番の遍歴
朝当番発足当初の運用は以下のようなかたちでした。仮にV1としましょう。
朝当番運用 V1
- 朝当番担当を5人募集し、平日の各曜日に1人アサイン(3ヶ月で交代)
- 朝当番担当は、08:00~09:30の時間帯、Datadogを見ながら異常がないか確認。Datadogのmonitorやダッシュボードの改善、その日のピークアクセス数や気になった点などをドキュメントにまとめる等を実施
- Infra Performance Working Group(以下 Infra PWG) という会を隔週で実施し、朝当番のふりかえりを行い、朝当番をブラッシュアップしていく
しばらく運用を続け、アラートに反応できるメンバーが増えてきたなかで「サービスダウンが発生することはなく、朝当番中にインシデント対応する機会もほぼなくなった」という声があがるようになってきました。
そこで、朝当番担当の時間を短縮、さらに毎日ドキュメントにまとめていた内容を簡素化し、ピークアクセス数、気になったこと、次の曜日の担当者への申し送りをSlackに記述するという運用に変更しました。V2です。
朝当番運用 V2
- 朝当番担当を5人募集し、平日の各曜日に1人アサイン(3ヶ月で交代)
- 朝当番担当は、08:15~08:45の時間帯、Datadogを見ながら異常がないか確認。可能であれば、Datadogのmonitorやダッシュボードの改善、その日のピークアクセス数や気になった点などをSlackで報告
- Infra PWG で朝当番のふりかえりを行い、朝当番をブラッシュアップしていく
同時に朝当番の目的のひとつであった担当エンジニアの育成は徐々に Infra PWGで吸収し、参加者の学習機会となるようにアップデートしてきました。
後ほど詳細について触れようと思います。
さて、朝当番経験者が増え、2周目、3周目を担当するエンジニアも現れ始めました。
朝当番担当でなくてもピークタイムにアラートが発砲されたときは、担当チームのエンジニアが自然と反応し、対応するケースも多く見受けられるようになってきました。
朝当番を経験し、どう振る舞えばよいかが各チームのエンジニアに知見として根付いてきたと言ってよいでしょう。
さらに朝当番の運用を縮小しました。
朝当番運用 V3
- 朝当番担当を3人募集し、月・水・金に1人アサイン(3ヶ月で交代)
- 朝当番担当は、08:15~08:45の時間帯アラートがあれば反応して確認、担当チームにSlackで確認
- Infra PWG で朝当番のふりかえりを行い、朝当番をブラッシュアップしていく
火・木は朝当番なしでしばらく運用をしてみました。
朝当番をやめる
徐々に縮小していった朝当番制度ですが、朝当番がいない曜日があっても特別不安を感じなくなってきました。
朝当番制度のそもそものモチベーションはなんだったのか振り返ると、以下2点が大きな割合を占めていました。
- 朝のピークタイムに不安定な状態になることが多発しており、エンジニアが張り付いて対応をスムーズに行えるようにしたかった
- アラートに反応できるエンジニアがシニアエンジニアに偏っていたため、対応できるエンジニアを育成する機会を設けたかった
この2点は大きく改善されました。
ピークタイムの安定状態の獲得
朝のピークタイムはかなり安定している状態を維持できるようになってきました。
Classiのサービスは、複数のアプリケーションコンポーネントで構成され、多くのコンポーネントがAmazon ECS Fargate上で稼働しています。
ピークタイムにサービスダウンするような事態は解消されつつも、アクセスが急増することでコンポーネントのうちのいずれかが不安定な状況に陥ることはしばしば発生していました。
特に Fargate タスクのスケールアウトが間に合わず、レイテンシの悪化や接続エラーを招くような事態が頻繁に発生していました。
対して、各チームが自チームのECSサービスに対して以下のような取り組みを実施しつつ微調整を重ね、最適化を進めてきました。*1
- オートスケーリングのターゲット追跡ポリシーの調整
- 時間指定でのオートスケーリングの導入
- タスク数を一気に増やすステップスケーリングの導入
最近では、直接的なコンピューティングリソースやリクエスト数とは別の、独自のCloudWatch Alarmを作成・利用してスケーリングを実現するなど、さらなる改善に取り組む事例も出てきています。それについてはまた別の機会に触れたいと思います。
また、Infra PWGで、年間のおおよそのアクセス数のトレンドを把握し「来週はアクセス数が例年スパイクする時期なので事前にECSタスク数を増やしておこう」といった会話がなされ、緩やかに人為的な調整も行っています。
これは、Classiが学校向けのサービスということもあって、比較的年間イベントサイクルが安定しているからできることではありますが、学校の年間イベントの理解を深めることが安定性に寄与するという体験は、事業会社ならではという感触があります。
そのようなシステム面、運用面での改善を重ねた結果、現在の安定した状態を維持できています。
アラートに反応できるエンジニアの増加
各プロダクトチームのエンジニアの監視への理解や姿勢が成熟し、アラートに反応できるエンジニアが増えました。
朝当番としてもっとも称賛されるべき振る舞いは「なにかおかしい、誰か見て！」と誰よりもはやくSlackのオープンチャンネル等、社内のメンバーにすぐ伝わる場で発言することです。
そうすることで、アラート対応に巻き込まれることこそ朝当番の肝だと私は思っています。
当事者になることで、仮に自身ではどこからどう調査すべきかわからなかったとしても、その後他の誰かと一緒にメトリクスを見て原因を突き止めていくという体験をすることが、サービス全体の理解や、メトリクスの見方の学習に繋がります。
そのような学習の積み重ねにより、現在ではSREやシニアエンジニアが反応せずとも、各チームでアラートに対応することが当たり前になってきています。
場合によっては、CSチーム等、関係部署への情報連携を要求されることもあります。
Classiでは「障害報」と呼んでいますが、問題発生時、起こっている事象をまとめ、すばやく関係部署に情報連携する運用を立て付けています。
朝当番として障害報を発する機会を得たエンジニアは、有事の際どうアクションすべきかという、ある種の筋肉が鍛えられてきたと言えるでしょう。
他にもアラートのメンテナンス(不要なものの削除、しきい値の調整、メンション先を都度適切なチームに変更するなど)が各チームのエンジニアにて、日常的に行われるようになってきました。
それらの状況を踏まえ、朝当番を終了することを決定しました。
やめてみて
朝当番を終了してみて半年以上経ちましたが、朝当番がいなくて対応が遅れたということは今のところ起きていません。
特に警戒している学校の長期休暇明けの日であっても、問題も起きず安定したサービス提供ができています。
もちろんアラートがゼロになったわけではないし、まだまだ信頼性やパフォーマンスの改善の余地はあります。
しかしアラートに誰も反応できないということは少なくとも起きておらず、常に担当チームによって適切な対応がなされていると言えます。
また、チーム単位でInfra PWGが開催されるなど、チームによる自律的な運用体制の強化も進んでいます。
プラットフォーム部SREチームとして
現在SREチームは、監視運用体制という観点では、Infra PWGにて各チームが監視運用をスムーズに行えるようにアラートの原因を深堀りして知見を共有したり、Datadogの便利なTipsの紹介や年間イベントの確認などを行っています。
広くエンジニアが監視運用に携わるというステージからステップアップし、各チームの運用力を洗練させていくということがSREチームに求められていると思っています。
プラットフォーム部として、各チームの運用力を継続的に底上げすることに今後さらにリソースを割いていきたいです。
また、ここまで触れてきていませんでしたが、昨年からSLI/SLOを段階的に各コンポーネントに対して定義していくことを主導しています。
今後の展望としては、SLI/SLOとエラーバジェットをベースにしたアラートの構築・運用を強化していくことを推進したいと思っています。
さいごに
朝当番は、人的リソースを充ててサービスレベルを底上げする取り組みでもありました。
人的リソースを割く以上そこには少なくないコストが発生しています。
単純なエンジニアの稼働時間というのに加え、フレックスに働けるという働きやすさを一部手放すという面も人によってはあったと思います(3クール担当した私はありました)。
しかし、それと同時にサービスと監視・運用に対する理解や姿勢の醸成のための時間でもありました。それが各チームに浸透した結果、エンジニアの時間の使い方を再配分しながらサービスレベルを向上させることができたとも言えるので、とても実りある時間の使い方だったと思います。
「また朝当番を配置しなきゃね」という事態にならないようにこれからも気を引き締めたいと思います。
最後までお読みいただきありがとうございました。
*1:もちろんECSタスク数は多ければ多いほど安定性は増しますが、コストとのトレードオフになるので、適切な時間帯に適切なタスク数が稼働していることを目指すという前提のもと調整を重ねてきました。
