「オンコール対応するエンジニアの睡眠時間を確保せよ」 GMOペパボSREチームの6つの取り組み：「Cloud Operator Days Tokyo 2022」セミナーレポート＃1
Cloud Operator Days Tokyo 2022のセッション「信頼性を落とさず効果的にオンコールを減らす取り組みを目指して エンジニアの睡眠時間を守ろう」にてGMOペパボの渡部龍一氏は、信頼性を落とさずに効果的にオンコールを減らした取り組みについて紹介した。
サービスの信頼性を守るため、オンコール対応は重要な仕事だ。だが、夜中に何度も呼び出されるような状況ではエンジニアの肉体的、精神的な疲労は計り知れない。Cloud Operator Days Tokyo 2022のセッション「信頼性を落とさず効果的にオンコールを減らす取り組みを目指して エンジニアの睡眠時間を守ろう」では、こうしたオンコール対応におけるエンジニアへの負担を軽減させる取り組みを紹介した。
「常に何らかのアラート情報が流れている」
GMOペパボの渡部龍一氏（技術部プラットフォームグループ）の役割は、GMOペパボの各種サービスの可用性を確保しビジネスの成長に合わせて適切な環境を提供することだ。そのためのさまざまな業務をこなす中で、オンコール対応は悩みの種になっていた。
「私のチームで対応するサービスだけでも100を超えており、平均すると2、3日に1回のペースで何らかのアラートが発生していた。日に数回の呼び出しが発生することも珍しくなく、担当者の睡眠時間が削られていた。平日の10時から19時は通常の業務と並行してオンコール対応をしているため、そちらへの影響も懸念される状況だった」
もちろんオンコールは複数人で担当しており、交代制も採用している。だが、それでも担当者の負担が積み重なっていたという。この背景にはGMOペパボならではの理由もある。GMOペパボは多くのサービスを運用しており、規模も大きいため、その全てをSRE（Site Reliability Engineering）チームが把握することは難しい。アラートを管理する仕組みはあったが、サービスごとの設定にしていたため「常に何らかのアラート情報が流れている状態で重要なものを見逃す危険性もあった」と渡部氏は説明する。
また、オンコールで対応ができないことがある点も課題だった。1つのサービスであっても開発には複数チームが携わっており、どのチームがどのようなリリースや変更作業をしているのかを把握することは容易ではない。しかもそういったサービスが無数にある。SREチームで対応できない場合は、担当チームを調べてエスカレーションするが、そのやりとりに時間が取られてしまい、結果としてMTTR（平均修復時間）が伸びてしまう恐れもあった。
オンコールを見直す「6つのステップ」
「オンコール対応が頻発して運用担当の負担が大きい」「オンコールでは対応できないアラートをどうするか」。これら2つの課題を解決するために、渡部氏は「オンコール対応の見直し」を行った。同氏が実施した取り組みは以下の6つだ。
- オンコールの現状を分析する
- オンコールやアラートの設定理由を調査する
- オンコールの原因調査の優先度付けを整備する
- オンコール設定を見直す
- オンコールに対するアクションを自動化する
- エスカレーションパスを整備する
1．オンコールの現状を分析する
オンコールといっても、対象とするサービスや緊急度によって連絡プロセスや対応期限は異なる。ストレージ逼迫（ひっぱく）のアラートであれば対応期限は翌営業日まで、連絡は電話とテキストチャットを併用する。Webページに大量のアクセスが発生してレスポンスが悪化しているのであれば、期限は「なるはや」になるし、連絡は基本的に電話を使うといった具合だ。そこで渡部氏は「何事もまずは計測」ということで現状を整理することに着手した。
GMOペパボはオンコールのために「Pagerduty」というサービスを利用している。渡部氏はその中の「オンコールの概要表を作成する機能」を使い、オンコール対応が必要なアラートの分類とオンコールの発生日時の調査を実施した。
2．オンコールやアラートの設定理由を調査する
オンコールの状況を確認した後はオンコールやアラートを設定した背景に注目した。オンコールやアラートは、過去に発生した何らかの問題に対処するために設定されている。だが設定当時は問題なくても、時間の経過とともに「最適な設定」は変化する。最適な設定を維持するためにはその背景を理解することが重要だ。
「私自身、SREチームに入ってから日が浅いこともあり、アラートが設定された歴史的背景を学ぶ必要もあった。オンコールの設定をGitHubで管理しているものはプルリクエストなどから情報を収集した。オンコールやアラートは障害と結びついていることも多いので、ポストモーテムも活用した。その他、設定時の環境と現在の環境の差分を調べる、当時の担当者を探し、現在の担当者（担当チーム）がどこかを明確にするといった作業も実施した」
3．オンコールの「原因調査の優先度付け」を整備する
それぞれの背景を確認した後は、オンコール対応の優先度付けの調整だ。
アラートが発生したからといって手当たり次第に対応していては担当者が疲弊するばかりだ。「ユーザーに影響があるアラート」を優先的に対応するのは言うまでもないが、「頻繁に発生しているアラート」にも早急な対処が必要だ。頻繁にアラートが出ているということは何か大きな不具合が発生している可能性がある。もちろん、対処をしないと同じアラートが出続けるというデメリットもある。そこで渡部氏はオンコール対応の優先度を「ユーザー影響の有無」と「発生の頻度」で判断するようにした。
4．オンコール設定を見直す
次はいよいよオンコール設定の見直しだ。アラートが発生したときにエンジニアでなければ対応できないからこそ、オンコール対応が必要になる。だが、エンジニアがいなくても対処できるようにすればオンコール対応は不要だ。そう考えた渡部氏は、アラート発生時の対処法の整理とアラートのしきい値の調整を行った。
「リソース不足が原因なら、スケールアウトやスケールアップなどを増強すれば解決できる。そういった対応については手順を整備した。瞬断でアラートが発生することがあるが、正常動作の範囲なら静観していても問題ない。そこでアラートのしきい値を上げて、正常動作の範囲ならオンコールをしないようにする。プロセス再起動などメンテナンス作業でもアラートが発生しているケースもあったので、作業中だけアラートをオフにするようにした」
見直しを進め、ユーザーへの影響が少なく緊急度の低いものはオンコール対応をしないことにした。アラートそのものが不要になったケースも幾つかあった。ただ、それらの設定変更作業は慎重に実施した。オンコール対応はそもそも「サービスの信頼性」を確保するために必要なものだ。不用意に変更すれば「SLO」（Service Level Objective）が守れなくなる恐れがある。
「変更作業の前に『設定を変更してもSLOが守られるかどうか』を注意深く確認した。またSLOがないサービスであっても、ユーザーから問い合わせが増えていないかなどを常に確認しながら作業した」
5．オンコールに対するアクションを自動化する
次に実施したのが、オンコールに対するアクションの自動化だ。「メモリ使用率が高い」「キューが詰まっている」など復旧用のスクリプトがあれば自動的に対処できるアラートは多い。スクリプトの作成やアクションの設定にはGMOペパボに導入していた「Mackerel」を利用した。
ただ注意しなければならないのは「自動対応してよいのかどうかの判断」だ。「中には、アクションを実行するかどうかの判断を人がすべきアラートもある。まずその切り分けを行うことが重要だ」と渡部氏は指摘する。
6．エスカレーションパスを整備する
GMOペパボではSREチームが一括してアラートの一次受けを行っているが、その理由は「SREチームの活動にとって障害などを通知するアラートが重要なトリガーになるから」だ。とはいえ、SREチームだけで全てのアラートに対処できない状態になっていたため、一次受けするアラートとそうでないものを定義し、一次受けするものについては、アラートそれぞれについてどのチームにエスカレーションすればいいかという「エスカレーションパス」を整備した。
オンコールの回数は3分の1に、障害も増えていない
今回の取り組みでオンコールの回数は月平均で10回前後から月3回と3分の1に削減できた。オンコールの対応時間は月平均で10時間だったものが、取り組み後は月平均で2時間になった。「『同じような原因で夜中に何度も呼び出されてたまるか』という思いでこの取り組みを進めた。取り組みの結果、何度も呼び出されるといった事象はほぼなくなった。結果的にSREメンバーの睡眠時間の確保につながったはず」と渡部氏は言う。オンコール回数が減少しても障害が増えることはなく、信頼性の確保にも成功している。
今後の課題として渡部氏は次のように語る。
「オンコール回数は減らすことができたが、それでもまだ多いと考えている。四半期に2、3回くらいになるよう改善を続ける。また今回の取り組みは半年ぐらいの期間がかかってしまった。数年後に同じような取り組みが必要になる可能性があるので、さらなる効率化に取り組んでいく」
Copyright © ITmedia, Inc. All Rights Reserved.