こんにちは、技術部プラットフォームグループのそめやポチです。最近は生成AIとレスバトルする仕事をしています。
この記事では、GMOペパボのグループ企業であるGMOクリエイターズネットワークにおける、サービスの監視体制の構築について紹介します。
なぜGMOペパボに所属している私がGMOクリエイターズネットワークの記事を書くかというと、10月からペパボの技術部としてGMOクリエイターズネットワークのエンジニアリングをお手伝いしているからです。ペパボの技術部は特定サービスには属さず全社横断的に技術施策を実施する組織です。このたび、会社の枠を飛び越え、GMOクリエイターズネットワークが提供しているWebサービスの、主にインフラ・セキュリティ・運用周りをお手伝いすることになりました。
2023年4月にジョインしたGMOクリエイターズネットワークの技術責任者であるぼいらーさんの記事にある通り、エンジニアの正社員は現在一人だけです。そのような組織でサービスを運用していくにあたって、監視体制を構築した過程を紹介します。
遭遇していた課題
私が最初にサービスの運用体制に対して感じたことは、サービスの信頼性が損なわれている場合に、それを検知する手段が乏しいということです。 私がジョインした直後に、印象的な事例がありました。エンドユーザーからのお問い合わせによって、インフラ要因によるエラーの頻発を検知したのです。過去にも、「レスポンスが遅い」というお問い合わせを受けて初めてインフラの不調を検知したことがあったようです。
システムの不調にいち早く気づいて対応をするために、サービスの監視体制が必要だと私は判断しました。
監視を設計するにあたって考えたこと
ユーザー視点でのペインを減らしたい
私たちのサービスはユーザーのためにあるものです。そのため、ユーザーが不愉快な思いをしているかどうかを監視するべきだと考えました。 裏を返せば、最終的にユーザーのためにならない監視は作るべきでないと考えています。
偽陽性アラートは最小にしたい
偽陽性（本当は問題がないのに、問題があるかのようにふるまう）のアラートはデメリットが大きいことを私は経験的に知っています。 端的にデメリットを説明すると、疲れるのです。アラートを見ると身体が硬直し、精神が昂ぶります。何か悪いことが起きているのではないかと焦り、必死で調査をします。その結果、問題がないことが分かると、安堵こそすれど、「アラートが本当は問題なかった」ことを学習してしまいます。その結果、アラート全般がオオカミ少年であると捉えられてしまうと、本当に悪影響のあるアラートを見逃しかねません。 そのため、対応する価値のあるアラートのみを出したいと考えました。
可能な限り手間をかけたくない
エンジニアの正社員は、現在一人しかいません。少ない人的資源を何に割り振るかが重要です。多少のお金で解決するのであればそれに頼るべきであると判断しました。
監視を実装するにあたってやったこと
Datadogの導入
監視と可観測性はDatadogに頼ることにしました。Datadogとは、Webサービスの可観測性や監視を中心に多数の機能を提供しているSaaSです。 Datadog導入についての細かい経緯や理由については、先に出たぼいらーさんの記事内のオブザーバビリティについての項目を参照してください。
外形監視の実装
外形監視は最低限導入するべき監視だと思います。
外形監視は、定期的にサービスのエンドポイントにアクセスし、想定した応答（レスポンスコードが200など）が返るかどうかを監視します。つまり、サービスが生きているかどうかの監視です。
DatadogではSyntheticsという機能によって、自動的な外形監視を実現できます。
ただし、DatadogのSyntheticsの課金体系は、テストを実行した回数での従量課金です。そのため、サービスの重要度に応じてテストをする頻度を変えました。例えばメインのサービスは１分ごと、サービスのメディアページは30分ごと、といった具合です。
また、外形監視のアラートが発報されたときによく出るのが「瞬断だった」という結論です。もちろん可用性が低い状態は検知し、調査するべきです。しかし、外形監視としてアラートが飛ぶときは、対応が必要なときであってほしいです。先述の「偽陽性アラートは疲れる」というのが理由です。DatadogのSyntheticsでは、「失敗時にN秒後に再試行するのをM回繰り返す」という設定ができます。落ちたときの影響が重大でないサービスにはそのような設定をしています。
LBでの監視の実装
私たちが提供しているサービスのほとんどは、最前段にLB（ロードバランサー）があります。 つまり、私たちが監視できるコンポーネントのうち、LBが最もユーザーに近いということです。したがって、LBのレイヤーで収集したメトリクスやログを監視することで、ユーザーのペインを効果的に検知できると考えました。
具体的には、次のメトリクスの監視を実装しました。
- エラーレート
- レイテンシー
ユーザーにとっての影響が大きい部分を監視したいという意図でこれらを監視することにしました。
ここで、Datadogを使う利点がいくつか現れました。
私たちは複数のサービスを提供しています。それらの複数サービスを一つのDatadogアカウントで取り扱っています。そのような場合でも、Datadogのクエリを書けば、複数のコンポーネントに対して同種のメトリクスを監視できます。
例えば次のクエリによって、Google Cloudで使用しているCloud Load Balancingにおける500系レスポンスの数をbackend_nameごとに取得できます。
sum:gcp.loadbalancing.https.backend_request_count{response_code:5*} by {backend_name}.as_count()
事前にDatadogとGoogle Cloudの統合処理が必要ですが、複数のGoogle Cloudプロジェクトに対しても一括でメトリクスを取得できることが利点です。
また、アラートを鳴らす閾値を決めるのは難しいです。低すぎると偽陽性アラートが増え、高すぎると障害を検知できません。そこで、DatadogのAnomaly Detectionという機能を使いました。Anomaly Detectionは、過去のメトリクスからパターンを学習し、そのパターンから外れたときにアラートを鳴らすという監視機能です。時間、日、週といったさまざまな時間単位でパターンを予測させることができます。
まだAnomaly Detectionの機能を十分に把握できている自信がないため、現在は、過去の実績値から決めた値を閾値とした監視と、Anomaly Detectionによる監視を動かしています。
サービスがダウンする前に対応が可能な、コンポーネント不調の監視の実装
システムの可用性が下がる前に対処できるのであれば、対処するべきです。その兆候が分かっているのであれば、その兆候を監視することで、サービスダウンの時間を最小化できます。 今回は、次の二つの監視を実装しました。
- ストレージ容量
- 冗長化されているコンポーネントの死活
これらもDatadogによって、複数の環境にあるリソースを一括のルールで監視できます。
ストレージ容量
ストレージは、溢れると即サービスダウンにつながりかねません。過去に、実際に社内向けサービスを動かしているサーバーのストレージが溢れた事故があったことを受けて監視を実装しました。
冗長化されているコンポーネントの死活
ほとんどのサーバーは前述のLBの配下で冗長化されています。それらのうちすべてがダウンしない限りサービスダウンにはなりません。しかし、サービスが落ちる前に、コンポーネントの不調に気づいて対応したいです。そのため、それぞれのサーバーにおいて、LBによるHealthCheckが通っているかどうかを監視することにしました。
アラート通知の整備
監視は、それが対応につながって初めて価値を生みます。対応できる人間に、しかるべき形で通知されるべきです。
今回は重要度に応じて２種類の通知方法を導入しました。
- チャットルームへの投稿
- 個人の携帯端末への発信
チャットルームへの投稿
GMOクリエイターズネットワークではチャットツールとしてSlackを利用しています。Slackでアラート専用のチャンネルを用意し、アラートが発報された際はそのチャンネルに投稿がされるようにしました。
個人の携帯端末への発信
Slackのアラートチャンネルを絶え間なく見続けることはできません。しかし、一刻も早く対応しなければいけないアラートがあります。 そこで、重要なアラートは個人の携帯端末へ通知することにしました。そのために、PagerDutyというSaaSを導入しました。PagerDutyはペパボでも利用しているため、ペパボの知見を使って導入をスムーズに進めることができました。
現在は、主要なサービスの外形監視が落ちたときのみPagerDutyと連携するようにしています。 夜間でもアラートが鳴る設定で運用しているため、過剰な通知は人間の健康を損ねます。健やかな生活を送るために、PagerDutyと連携する監視は最小にとどめました。
まとめ
以上、エンジニア正社員が一人のみの開発組織で、サービス監視体制を構築した過程を紹介しました。これからサービスの成長とともに必要な監視は変わっていくのでしょうが、現在のサービス規模に適した最低限の監視設計ができたと考えています。 また、監視の実装とともに、オブザーバビリティの観点で優れた機能を持つDatadogを導入したことによって、アラート発報→事象の把握→原因調査→対応までがスムーズにできるようになったと感じています。
しかし、サービスのために、ひいては使ってくれるユーザーのために、やるべきことがまだまだたくさんあります。人手が足りず、それらすべてをやりきれないことを歯痒く思っています。助けてください！！！！！！
ペパボのテックブログの仕様のため、記事の最下部にはペパボの採用情報が表示されますが、GMOクリエイターズネットワークでも積極採用をしています。
まだできたてほやほやの開発組織なので、いま入れば価値を生み放題です。ご興味を持たれた方々、ご応募をお待ちしております。