Datadogは6月9日～11日の期間で米ニューヨークのJavits Centerにおいて年次カンファレンス「DASH」を開催した。昨今、プラットフォームの規模が拡大するにつれて、モニタリングとインシデント管理の課題も増えており、成長に合わせてモニタリング戦略を確実に進化させるにはどうすればいいのだろうか？Toyota Connected North America(TCNA)の導入事例を紹介する。

Datadogで6年間のモニタリングプロセスを合理化

トヨタ自動車の海外子会社であるTCNAでは、6年前にテレマティクスプラットフォームを立ち上げて以来、新しいサービスを世界各地に展開・拡大しており、トヨタのカイゼン思想(継続的改善)を活用し、モニタリングプロセスを合理化することで規模に応じたシンプルさを維持している。

TCNAは北米のトヨタグループであるToyota Motor North Americaとは別会社となり、社員数は約400人。トヨタグループのソフトウェア部門のような存在で、車両内のセンサが通信するCAN(Controller Area Network)バスを活用した技術や、新しいヘッドユニットのUI/UXデザインなどを手がけている。最近、発表された新しい車載インターフェースも同社のチームが設計した。

説明に立った、Toyota Connected North America Senior DevOps EngineerのAshley Parks氏は、TCNAのテレマティクスプラットフォーム「Drivelink」を担当。Drivelinkは、トヨタ自動車のコネクティッドサービス「T-Connect」の一部として2019年から提供。緊急通報や車両位置情報サービス「Safety Connect」のローンチを同年にダウンタイムゼロを実現している。

Drivelinkはグローバルで1250万台で有効化されており、これまで受電が550万件、うち安全に関するものが55万件、車両追跡は3万5000件となっている。

  • Toyota Connected North America Senior DevOps EngineerのAshley Parks氏

    Toyota Connected North America Senior DevOps EngineerのAshley Parks氏

提供している安全サービスには、衝突時に自動で通知する「ACN(Automatic Collision Notification)」、車内のSOSボタンによる緊急通報、そして盗難車両の追跡機能などがある。これらはDCM(Data Communication Module：専用通信機)という、車載のデバイスを通じて、SIMカードでコールセンターに音声通話と車両データを送信することで、事故の有無、衝突箇所、乗員数などを把握し、迅速な救助対応を可能としている。

また、盗難車両の追跡は、必ずしも盗難に限らず、警察の報告があればAmber Alert(児童誘拐)やSilver Alert(高齢者行方不明)などにも対応可能なことに加え、「Destination Assist」というサービスでは、車載ヘッドユニットに目的地情報を送信する機能も提供しており、オペレーターまたはAIが対応している。

Parks氏は「トヨタ生産方式(Toyota Production System)は、創業者の豊田佐吉氏が母親の織機事業を改善する過程で生み出した哲学です。トヨタは元々織機メーカーとしてスタートしました。効率性、効果性、無駄の排除を追求するこの哲学の中でも、特に『Kaizen(カイゼン)』=継続的改善を重視しています。当社でもシステムのアップグレードや証明書やセキュリティの最新化、新しいツールのアーキテクチャ評価など、さまざまな形でカイゼンを実践しています」と述べ、まずはビジネスの成長に合わせてモニタリングをスケールさせる方法を紹介した。

ビジネスの成長に合わせてモニタリングをスケール

TCNAではHashiCorpの「Terraform」でグローバルモニタリングスイートを構築し、サービスが増加しても一貫性のある監視を可能としている。地域別のモニターを用意しているが、大半のモニターはグローバルモニタリングシステムに統合されおり、プラットフォーム上のすべてのサービスが送信する共通のメトリクスにもとづいている。

例えば、RabbitMQとKubernetesでマイクロサービス間の通信を行っているため、すべてのサービスがRabbitMQに関するメトリクスを送信し、新しいサービスがデプロイされたり、既存のサービスがオーストラリアに複製されてデプロイされたりした場合でも、自動的にメトリクスが送信され、Datadogのモニターに含まれるようになっている。

この仕組みについて同氏は「非常にシンプルですが、モニターのタイトルには必ず『チーム名』や『環境名』などのグルーピング情報を含めるようにしています。これにより、Slackチャンネルなどで通知を受け取った際に、どのチームが対応すべきかがすぐに分かるようになります。さらに、すべてのモニターはTerraformで管理しており、Slackチャンネルへの通知先を判定する巨大なif文を作成しています。開発者はTerraformの変数を指定するだけで、モニターが正しいSlackチャンネルに通知されるようになります。North Americaのサービスは『North America』という名前で識別され、プロダクションと非プロダクションのアラートも分けて管理しています。これにより、不要なノイズを減らし、地域ごとのモニターを明確に追跡できます」と説明する。

また、モニターにはP1～P4までの「優先度(Priority)」を必ず設定する。P1は最も重大なアラートとなり、P1モニターはインフラチームに直接ページを送信し、サポートプロセスをスキップして即時対応を促す。例えば、ノードがダウンした場合には即座に通知が飛び、迅速な復旧を可能としている。

人間がモニターを見るときだけでなく、DatadogのAIエージェント「Bits AI」がオンコール対応を行う際にも必要なため、Runbook(対応手順書)の添付は必須となっており、問題が発生したときに何をすればよいのかが明記されていないと、誰も対応できずに放置されてしまう可能性があるという。

モニタリングの精度を保つ2つの運用施策

モニターの有効性を維持するための取り組みとしては、モニターが適切に機能しているかを確認するために、同社では「隔週のモニター確認ミーティング」と「四半期ごとのGame Day(システム検証イベント)の2つの方法を採用している。

モニター確認ミーティングでは、Datadogが提供する「Monitor Notifications Overview」というダッシュボードを活用し、モニターの発火回数、通知先のSlackチャンネル、アラート状態などをグラフやテーブルで可視化するものとなる。

特に注目するのは「最も多く発火したモニター」のグラフで、例えばあるモニターが過去2週間で5000回も発火していた場合、その閾(しきい)値が適切か否かを再評価し、重要でない場合は削除することもある。また、常にアラート状態のままになっているモニターもチェックし、メトリクスが送信されていないか、設定ミスの可能性があることから、不要であれば削除する。

さらに、通知先が設定されていないモニター(Slackやメールに送られていないもの)を「品質タブ」で確認し、テスト用に作成されたまま放置されている可能性が高いものもあるため削除対象とする。

最後に、時間があれば過去数週間で新たに監視すべき事象がなかったかを話し合う。通常はRCA(Root Cause Analysis)で議論される内容だが、定期的なブレインストーミングとして有効だという。これらの取り組みは、Slackチャンネルがノイズで溢れかえるのを防ぎ、チームがモニターを無視せず、確実に対応できる環境を整えるための“カイゼン”の一環として取り組んでいる。

  • Toyota Connected North America Senior DevOps EngineerのAshley Parks氏

    モニター確認ミーティングの概要

同社では隔週でモニターの確認を行い、新しいアラートを本番環境に投入する前には、検証のプロセスを設けている。Terraformのif文では、非本番用と本番用のSlackチャンネルを分けており、非本番環境で頻繁にアラートが発生している場合はミーティングで取り上げる。

ただし、多くの場合は「まだテスト中です」「異常値の閾値を調整中です」といった理由で、すぐに対応する必要はないと判断。Datadogのダッシュボードでは、Slackチャンネルごとにフィルタリングできるため、こうした運用を可能としている。

Game Dayで実現する技術検証とチーム強化

また、四半期ごとのGame Dayではカオスエンジニアリング(Chaos Engineering：本番環境で意図的に障害を発生させ、システムの耐障害性を検証・改善する手法)の一環で、意図的に非本番環境で障害を発生させ、システムの耐障害性や復旧能力を検証する。

  • 四半期ごとのGame Dayにおける検証事項

    四半期ごとのGame Dayにおける検証事項

例えば、ノードを落としたり、AWS(Amazon Web Services)のリージョンを停止させたりして、サービスが再接続できるか、インフラに冗長性があるかを確認する。これらの取り組みは、オンコール対応の不安を軽減する効果もあり、新しいチームメンバーや新規サービスが加わった際に、実際にページ通知が届くか否かを確認できるため、運用体制の整備にも役立つとしている。

また、コロナ禍以降、対面での交流が減ったこともあり、チーム間のコミュニケーションを促進する場としても機能している。Game Dayでは障害を発生させることで、システム内の他の部分にもエラーが波及する可能性があり、潜在的な障害ポイントの特定にもつながるとのことだ。

例えば、Javaサービスが再接続できずにエラーが出る場合、新しいバージョンや依存関係の見直しが必要かもしれないほか、Datadogのモニターが正しく発火するかどうかも確認できる。もし、何も発火しなければモニターの設定が不十分か、Game Dayのシナリオが適切でなかった可能性があるという。

Parks氏は「単なる技術検証だけでなく、チームビルディングの機会としてもとらえ、他チームのメンバーと交流し、インシデント時の対応方法を共有することで、組織全体の対応力が向上させています」と述べている。

Datadogを活用した効率的なインシデント管理プロセス

続いて、Parks氏はインシデント管理に話を移した。同氏は新しいインシデント管理プロセスを設計する際、あるいは既存のプロセスを見直す際に以下の6つの問いをチームで共有することが重要だとの認識を示した。

  • 誰がSlackで発火したモニターに対応するのか？ 多くの人がSlack通知をミュートしている可能性があるため、責任者を明確にする必要がある。

  • モニターが発火したとき、どのようなステップを踏むのか？
    どのタイミングでページ通知を送るのか、対応の流れを定義しておくことが重要。

  • インシデントが始まった後、次に何をするのか？
    初動対応の手順が曖昧だと、対応が遅れる原因になる。

  • いつエンジニアを呼び出すか？
    Runbookの最後に到達したとき、または複数のモニターが同時に発火しているときは、即座にエンジニアに通知を送る。

  • インシデントが長期化した場合の対応は？
    8時間、3日など長引いた場合の対応方針を事前に決めておく必要がある。

  • インシデントが収束した後、何をするのか？
    ポストモーテム(事後分析)や振り返り、再発防止策の共有など、終了後のプロセスも重要。

インシデントが発生すると自動的にワークフローが起動

インシデントが発生すると、Datadog上で作成した「専用Slackチャンネルへの通知」や「直近のリリースの確認」「自動シンセティック監視テストの実行と共有結果の共有」「テストチームへの共有」などのカスタムワークフローが自動的に起動する。

さらに、問題が発生しているサービスの担当エンジニアをSlackチャンネルに追加し、通知が必要かどうかを確認。重大なインシデントの場合は、マネージャーやディレクターもSlackチャンネルに追加し、状況を共有する。

  • インシデント発生後、自動的に作成されるワークフローと対応策

    インシデント発生後、自動的に作成されるワークフローと対応策

また、バックグラウンドで動作する小規模なワークフローもあり、最大24時間稼働するため毎時、テスターにテスト実施をリマインドするとともに、4時間ごとにオンコール担当者を交代するよう通知することで、長時間のインシデントでも対応が途切れないようにしている。

最後に「Datadog Incident Management」から自動生成されるポストモーテムのテンプレートには「5 Whys(なぜを5回繰り返す分析手法)」が含まれており、タイムラインを記録しながら、責任追及ではなく改善に焦点を当てた振り返りミーティングを行う。

その際に「何が起きたのか？」「どのモニターが発火したのか？」「改善できる点はあるか？」「新たに作成すべきモニターはあるか？」などを確認し、インシデントが解決した後に必ず実施する重要なプロセスとなっているという。

このようにして、TCNAはDatadogを活用した監視とインシデント管理の取り組みを実践している。サービスの成長に伴い、どのようにスケーラブルなモニタリングを構築してきたか、6年間にわたってモニターの有効性をどう維持し、インシデント管理を整備してきたかを知れたのではないだろうか。Datadogの導入を検討している企業の一助になれば幸いだ。