あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】
ユーザーや顧客へ信頼性を担保した価値提供をしていく中で、監視・オブザーバビリティの取り組みは非常に重要です。
今回の特集記事では、合同会社DMM.com、株式会社MIXI、株式会社マネーフォワード、パイオニア株式会社、Sansan株式会社、株式会社ZOZOの6社の各サービスを支える監視・オブザーバビリティの仕組みとして各社がどのようなアーキテクチャを組んでいるのか、またそのアーキテクチャにしている背景や意図についてお伺いしました。
自社に近いアーキテクチャやどのようにツールを活用しているかについて、実際の事例を元に参考になれば幸いです。
なお、後編も近いうちに公開させていただきますのでお楽しみに。
合同会社DMM.com（DMMブックス）
アーキテクチャ設計の背景・意図
DMMブックスにおけるオブザーバビリティの主な焦点は、利便性とコストのバランスを適切に保つことです。
私たちはメトリクス、イベントログ、アクセスログ、アプリケーションログ、そしてトレースデータをすべてNewRelicに集約し、これらのデータを横断的に分析するようにしています。
ただし、データを過度に集めると取り込みコストが急増します。NewRelicの課金体系は保存データ量に基づいているため、メトリクスと比較的少ないデータ量のトレースデータはそのままNewRelicに取り込みます。
しかし、ログ系データについては、その種類に応じて取り込み方を変えています。調査の起点となるアクセスログは全て取り込みますが、イベントログとアプリケーションログにはフィルターを適用し、必要なログだけを取り込むようにしています。
NewRelic固有の仕様としてトレースデータやログの保持期間はメトリクスに比べて短い（数日から1ヶ月）ため、長期トレンドを分析することが難しいことがあります。
その問題を解決するため、これらのデータをメトリクスに変換して記録します。例えば、CoreWebVitalsのデータはユーザーの1ページビューごとに記録されていますが、保持期間は8日間しかありません。そこでDMMブックスでは、これらのデータをデバイスやURLごとのメトリクスに変換し、長期的なトレンドを分析できるようにしています。
◆執筆：合同会社DMM.com ITインフラ本部 SRE部 部長 小野博志
株式会社MIXI（家族アルバム みてね）
アーキテクチャ設計の背景・意図
New Relic APMを活用しつつ、インフラやKubernetesのメトリクスについてはPrometheusを活用することで、New Relicのデータ転送量を抑えつつ、Grafanaによってインフラの各種メトリクスを統合的に可視化することができている。アプリケーションのログはGrafana Loki、その他ログはAthenaやBigQueryを活用しコストパフォーマンスの面で最適化をしている。
▼事例はこちらもご参照ください
https://gihyo.jp/article/2023/03/mitene-06observability
◆執筆：株式会社MIXI Vantageスタジオ みてねプロダクト開発部 プラットフォームグループマネージャー 清水 勲
株式会社マネーフォワード
アーキテクチャ設計の背景・意図
クラウド 給与、クラウド 勤怠、クラウド 人事管理ではモニタリングツールとしてDatadogをメインに利用しています。アプリケーションに寄り添った独自メトリクスを実装したり、DatadogAPMを利用することで、サービス間通信が増えた今もサービス間連携部分の可観測性を高める取り組みをしています。
週に一度DatadogダッシュボードやAPMを振り返ることで、開発者と共にサービス理解が深められる点も重宝しています。
◆執筆：株式会社マネーフォワード MFBC-CTO SRE Group VTRyo （with SRE team）
パイオニア株式会社
アーキテクチャ設計の背景・意図
パイオニアでは、ビークルアシストサービス用アプリケーションのパフォーマンス監視に、New Relic を使用しています。
バックエンドは Rust で作られており New Relic APM が使用できなかったため、代替手段として OpenTelemetry を導入しました。OpenTelemetry をバックエンドに組み込むことで、トレース情報の収集と New Relic への送信を行っています。
また、アプリケーションエラー検出も OpenTelemetry のトレースを使用しています。トレース情報の中に HTTP ステータスを含めることで、5xx エラーが発生したかどうかをトレースから検出しています。
New Relic のクエリを使うことでこれらの情報から簡単にエラー率を算出できるため、SLI/SLO 運用にも活用できています。
なお、ログに関しては OpenTelemetry を使わず、FluentBit → Amazon Kinesis Firehose 経由で New Relic に送信しています。
また、メトリクスに関しても OpenTelemetry は使用せず、New Relic 側でトレースデータを基にメトリクスへの変換を行っています。
Sansan株式会社（Bill One）
アーキテクチャ設計の背景・意図
Bill Oneでは、ベンダーに依存しない計装が可能なOpenTelemetryを採用しています。テレメトリデータはOpenTelemetryとの親和性が高いSplunk Observability Cloudに送信し、ウォーターフォール形式のトレースやマイクロサービス間の関係性を示す有向グラフなど、複数の形式で可視化しています。
また、OpenTelemetryの自動計装を活用しながら、個別の計装としてコンテナIDのAttributeの追加やDBコネクション取得時のSpanの追加、キューサービスを通じた伝播を可視化するためのヘッダの付与などを実施することで、可観測性をより向上させています。
さらに、特定エンドポイントのパフォーマンスを監視して異常を検知したり、異なる可観測性ツールで取り扱っているトレースとログのデータを同一のTrace IDで関連付けて横断的な検索を可能とすることで、円滑な調査を実現しています。
株式会社ZOZO（ZOZOTOWN）
アーキテクチャ設計の背景・意図
ZOZOTOWNはAWS、Google Cloud、オンプレのハイブリッド構成です。ここではAWSについてご紹介します。
全体はマイクロサービスアーキテクチャで、EKS上に多数のマイクロサービスがあり、DBやキューなど様々なAWSのサービスを利用しています。それらを統合的に監視するために、幅広い技術に対応し、ひと通りの機能が揃っているDatadogを採用しました。
全マイクロサービスのトレースやアラートを始めとするあらゆる監視をDatadogに集約することで、障害発生時の原因特定を容易にしています。
ただしログは基本的にAWS内に集約しています。AWSの各サービスがCloudWatch LogsやS3にログを送信しますが、それら全てをDatadogに送信するとコストがかかりすぎるためです。
また、エラートラッキングにはSentryを、オンコールにはPagerDutyを使用しています。
◆執筆：株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック 高塚大暉
▼記事の後編はこちら▼
あのサービスの監視・オブザーバビリティ アーキテクチャ選定【後編】
