「気付けない」「気付いても対処できない」障害をヤプリのSREグループはどう回避したのか：「Cloud Operator Days Tokyo 2022」セミナーレポート＃3

Cloud Operator Days Tokyo 2022のセッション「顧客影響に気付けるアラート設計と原因特定が素早くできるSREへ ヤプリが乗り越えてきた監視運用の失敗と改善」にてヤプリの望月真仁氏は、監視に関する失敗談とそれをどのように解決したのかについて紹介した。

[齋藤公二，＠IT]

　障害は起きないに越したことはないが、残念ながらいつかは発生してしまうものだ。そのため監視で予兆を発見し、迅速に対処できる体制を構築することが重要になる。ただ、そこで懸念されるのは「構築した監視体制が適切かどうか」だ。

　どのような監視でもサーバがシャットダウンする、サービスが落ちるといった非常事態を見逃すことはないだろう。しかし、「半年間でCPU使用率のアベレージが上昇している」といった微妙な変化は検知しにくい。気にしなくてもいいかもしれないが、もしかしたら重大な障害につながる予兆かもしれない。

　Cloud Operator Days Tokyo 2022のセッション「顧客影響に気付けるアラート設計と原因特定が素早くできるSREへ ヤプリが乗り越えてきた監視運用の失敗と改善」では、そういった“監視の課題”に直面したヤプリと取り組みについて紹介した。

ヤプリのSREグループが直面した監視の課題

　ヤプリの望月真仁氏（SREグループ　マネジャー）はSRE（Site Reliability Engineering）グループとして監視業務に携わっている。

ヤプリの望月真仁氏

　同社が提供する「Yappli」はノーコードでアプリの開発、運用、分析ができるアプリプラットフォームだ。導入社数は600社以上、アプリケーションの累計ダウンロード数は1億以上に達し、アップデート回数は年間200回を超えるという。同社は事業拡大とともに2019年にSREグループを新設し、2020年にかけてベースとなる監視の考え方、仕組みを構築した。それ以来、大きな障害がなかったため「われわれのサービスは安定している」と安心していた。

　だが実は、見えないところで問題が進行していた。ある日、Aサービスのサーバのうち2台のプロセスで障害が発生し、残ったサーバもアクセスのスパイクに耐え切れず利用不可になった。さらに翌週にはBサービスのサーバがアクセスのスパイクに耐え切れず利用不可となった。

　望月氏は当時を振り返り「インフラを起因とする障害が立て続けに発生し、アプリケーションの重要機能が使えなくなった。SREグループとしてはなかなか"しびれる"状況だった」と語る。障害の再発防止のため、望月氏らSREグループは早速、振り返りを実施。ポストモーテムも使ってさまざまな監視の課題を洗い出したところ、5つの課題があることが分かった。

現実と監視体制にギャップがある

　1つ目の課題は「障害の緊急性にふさわしいレベルで通知されていなかった」こと。

　ある障害が起きたとき、利用頻度の高い「クーポン」「ポイントカード」といった機能が使えなくなっており、利用者の視点ではすぐにでも対処が必要な状況だった。だが、監視では「CPU負荷がいつもより高いかも」「エラーログが増えているような？」「サーバはシャットダウンしていないから大丈夫」など“緊急ではない”と判断していた。

　このギャップを解消するため、望月氏は利用者視点での外形監視を実施することにした。ブラウザリプレイ形式やPing形式での外形監視をしようとしたが「適切な方法が見つからなかった」という。そこで望月氏が注目したのが「New Relic」の「Scripted API」機能だ。

Scripted API機能で「利用者への影響の有無」でアラートを出せるようにした

　「この機能は監視の条件をJavaScriptで自由に設定できる。『利用者に影響が出ているかどうか』で障害を判断できるようになり、適切なレベルでエンジニアへの通知とアラートが可能になった」（望月氏）

　2つ目は「障害が発生したサーバからアラートが通知されない」という課題だ。サービスのアラートは「Slack」に飛ばし、大まかに「#error」「#warn」「#info」という3つのチャンネルに分けて対処するしないを判断するといった設計にしていた。だが、サービスが増えたことでノイズ（緊急度が高くないアラートのこと、望月氏は「オオカミ少年」と例えた）も増え、それを嫌って「アラートを過剰に整理しすぎて、届くべきアラートが届かなくなっていた」と望月氏は語る。

　「従来の通知は全体を俯瞰（ふかん）するためには有効だ。そのため、新たに『サービスごとの通知チャネル』を追加し、これまで出していなかった『すぐ対処しなくてもいい通知』も積極的に流すようにした。これによってどのサービスでどんな障害や変化が起きているかを個別に把握できるようになった」（望月氏）

通知全般を見直し

　さらに、サーバのディスク容量が一定割合を超えた、SSL証明書の期限が近づいているなど特定のアクションが必要なものについても通知を追加した。

　3つ目の課題は「特定のエンジニアしか対処できない障害があること」だ。障害に気付いても、対象のサービスに詳しくないため適切な対応方法が分からない。もしくは対応方法は想定できても手順書やドキュメントがどこにあるか分からず、二の足を踏んでしまうといった状態になっていた。

「気付くけど対処できない」という事態が発生していた

　そこで望月氏は、課題2の対応で追加した“サービスごとの通知チャネル”にドキュメントをリンクし、誰でもすぐにメンテナンス手順や調査方法、連絡体制などが把握できるようにした。さらに“避難訓練”を通じて障害の通知が適切か、ドキュメントは有効なのかを継続的にチェックする仕組みを構築した。望月氏は「今後の課題として、ドキュメントの拡充やメンテナンス、“最新であることを保証するための運用”などがあるので引き続き改善を続ける」としている。

「把握・調査に時間がかかる」「事前に予兆に気付けない」という課題

　4つ目の課題は「障害の状況把握・原因調査に時間がかかること」だ。

　望月氏は「ヤプリにはアプリケーション用、配信用、外部API連携用などさまざまな基盤があり、それぞれが複雑に関連し合っている。そのため、障害が発生しても根本原因がどこにあるのかの特定が難しい」と説明する。ある障害が発生したときはデータベース（DB）で「ロック待ち」が多いことを確認できていたが、一方で特定のサービスのアクセス数が異常なことに目を奪われ、そこに調査の意識を集中させ過ぎていたという。

　「その障害については、APM（Application Performance Management）ツールでアクセス数の問題をまずクリアにし、その後、残ったDBの調査を進めることで根本原因の特定できた。そこから得たのは、影響範囲が分からず障害対応が困難なプログラムがあったとしても諦めず、APMを使って多角的な観点で障害を俯瞰するが重要ということだ」（望月氏）

　5つ目は「事前に予兆があっても気付けない」という課題だ。サーバ障害について情報を整理していると、実は障害発生前に予兆があったことが分かった。

　「Aサービスは、ある日を境にCPU使用率は上昇し続けている一方で、特定のサーバだけ減少していた。また、Bサービスは半年前と比べてCPU使用率のアベレージが上昇していた。改めて見ると何かが起こっているのだが、いずれもアラートのしきい値内の変化だったので、事前に気付けなかった」（望月氏）

　そこで望月氏は「標準のメトリクスでは可視化できない指標」を可視化する必要があると判断。New Relicでログをパースし、メトリクス化してダッシュボードで確認できるようにした。これによって「プロセスが駄目になるほどではないけど、減少傾向がある」といった“しきい値に触れない変化”を把握できるようになった。

課題への対処のまとめ

　望月氏は次のように語る。

　「監視は一度構築したら終わりではなく、事業拡大など周囲の状況に合わせて継続的にアップデートしていくものだ。同様の課題に取り組んでいる先人の知恵を活用し、一長一短ある監視サービスを自社の状況やフェーズに合わせて柔軟に選択することが重要だ。こうした点を踏まえ、『すてきな監視ライフ』を送ってほしい」