【TECH BLOG】Datadogの活用ノウハウを一挙に公開・それを支える全社管理者の工夫とは #datadog_japan_meetup

こんにちは。ECプラットフォーム基盤SREブロックの高塚と巣立（@tmrekk_）です。

ZOZOTOWNはクラウド化・マイクロサービス化を進める中で、監視SaaSのDatadogを採用しました。この数年で多くの知見が蓄積され、今では様々なシーンでDatadogを活用しています。この記事ではそのノウハウを惜しみなく公開します。

※本記事は、先日開催されたDatadog Japan Meetup 2022 Summerにて発表した内容を書き起こして再構成したものです。

当日の発表資料

はじめに

（高塚）こんばんは。これからZOZOTOWNにおけるDatadogの活用と、それを支える全社管理者の取り組みについて発表させていただきます。

わたくし、株式会社ZOZOでSREをしている高塚大暉と申します。よろしくお願いいたします。

（巣立）同じくSREの巣立健太郎です。Datadogの全社管理者も務めています。よろしくお願いします。

（高塚）ZOZOTOWNは日本最大級のファッションECサイトです。洋服はもちろん、シューズやコスメも取り扱っておりますので、ぜひ使ってみてください。

そのZOZOTOWNは2004年にサービスを開始しました。

ここで皆様にクイズです。2004年のできごとは4つのうちどれでしょうか？

（巣立）答えは...全部です！　皆様ご正解です。おめでとうございます！

話を本題に戻すと、2004年にオープンしたZOZOTOWNは、長らくオンプレでモノリスなアプリケーションとして動いてきました。ただ、サービスが成長にするにつれて、スケーリングや開発効率など、様々な点で厳しくなってきました。

そこで2020年から本格的にクラウド化・マイクロサービス化によるリプレイスを推し進めており、今もその道半ばです。

マイクロサービス基盤に必要な監視の要件

現在のアーキテクチャがこちらです。AWS, GCP, オンプレのハイブリッド構成で、API Gatewayが各マイクロサービスにルーティングを行います。

まだマイクロサービス化できていないAPIは、API Gatewayを経由してオンプレを叩きます。マイクロサービス化ができたPathは、API Gatewayで新しいAPIにルーティングを切り替えます。

また、BFF（Backend for Frontend）で複数のAPIのレスポンスをまとめて返すこともあります。APIが他のAPIを叩くこともあります。

そして、各APIで使用技術は大きく異なります。

ここまでをまとめると、マイクロサービスアーキテクチャにおいてサイト全体の信頼性を上げるには、各マイクロサービスを個別に監視するのではなく、統合的に監視することが必須です。

そのためには、我々は色々な言語やフレームワークを使っていますので、幅広い技術に対応していて、ひと通りの機能が揃った監視SaaSが必要というわけです。

そこでDatadogです。Datadogは、その条件にマッチしていました。

本発表は2部に分かれています。

第1部はZOZOTOWNにおけるDatadogの活用についてです。我々がぶつかった監視の課題と、それをDatadogでどう解決したか、そしてDatadogの便利なポイントについて話します。

第2部はそれを支える全社管理者の取り組みです。弊社ではSREだけでなく色々な職種のエンジニアがDatadogを使っていますので、それを支える工夫をいくつか紹介します。

第1部 ZOZOTOWNにおけるDatadogの活用

（高塚）第1部では、監視の課題を6つ紹介します。

1. どこで障害が起こっているのか分からない → APM

1つ目の課題は、どこで障害が起こっているか分からないということです。

例えばZOZOTOWNアプリのホーム画面を開いたとき、図の赤い矢印のような通信が発生します。ホーム画面の表示がいつもより遅いというとき、いろいろなマイクロサービスが原因として考えられるわけです。

仮に、どうやら商品APIのレイテンシが上昇しているぞと分かっても、実は商品API自体は問題なくて、商品APIが呼び出す推薦APIが遅くなっていたということがあり得るわけですね。

API間の通信が複雑になればなるほど、障害箇所の特定が難しくなります。

そこで活用したいのがAPMです。APMは色々なことができますが、今日は特に分散トレーシングについて話します。

導入方法は簡単で、スライドにGo言語での例を入れていますが、パッケージを入れた上でアプリケーションコードに数行追加するだけです。もちろん色々な言語に対応しています。

我々は全マイクロサービスにAPMを入れました。さらに、全てのリクエストの入口であるAPI Gatewayで、クライアントとリクエストPathをトレースのタグに追加しました。独自のタグを追加するのも1行のコードで可能です。

そうした結果、ご覧のようなトレース一覧が見られるようになります。この画面ではスライド左側に書いたような条件で絞り込み表示できます。

例えばステータスコードを500番台に絞って、「あれ、このリクエストPathだけエラーが出ているな」とか「iOSだけエラーが起きているな」とか「AWSのAZ-1cだけ障害が起きているな」というような使い方をしています。

これがとても便利なので、我々のチームは全てのマイクロサービスで、かつ本番環境だけでなく事前環境や開発環境も100%トレースを送信しています。

一覧画面の次は、1つ1つのトレースを見ていきましょう。これがアプリのホーム画面を開いたときの実際のトレースです。

上に見える青色のラインがBFFのスパンです。BFFは色々なAPIを叩いて結果を集約し、ホーム画面の描画に必要なJSONを返すという処理をします。

真ん中の緑色のラインが、叩かれている各APIのスパンです。各緑色のスパンの下に紫色のスパンもあるのですが、これがデータベースへの接続のスパンです。

今こうやってぱっと見ても、ちょうど真ん中らへんのスパンだけ長い、つまり時間がかかっていることが分かりますよね。「ホーム画面の表示が遅い」という問題に対して、かなりスピーディーに原因を特定することができました。

今度は別のトレースで、細かいスパンの中まで見てみます。

アプリケーションが実行したMySQLのクエリ1つ1つが、トレースの1番下の行、赤色のスパンで表示されています。画面の下半分には、ロック待ちでタイムアウトしたというエラーが表示されています。非常に細かいレベルまで見られるので便利です。

2. アラートやダッシュボードや外形監視が欲しい → Monitors, Dashboards, Synthetics

（巣立）課題2では、Datadogの基本機能であるMonitorやDashboard、Syntheticsについて、便利なポイントをお話します。

続きはこちら