Datadogと歩むZOZOTOWNの可観測性 / Observability of ZOZOTOWN with Datadog
by
akitok
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
Datadogと歩む ZOZOTOWNの可観測性 Datadog Private Webinar for Z Holdings 2021/2/10 株式会社ZOZOテクノロジーズ SRE部 小林 明斗 Copyright © ZOZO Technologies, Inc.
Slide 2
Slide 2 text
© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ SRE部 小林 明斗 2020年7月にZOZOテクノロジーズへ中途入社 前職は通信系SIerでバックエンドやインフラを中心に テックリードとして活動していました 現在はZOZOTOWNリプレイスプロジェクトにSREとし て参画しています 2
Slide 3
Slide 3 text
© ZOZO Technologies, Inc. https://zozo.jp/ ● 日本最大級のファッション通販サイト ● 1,300以上のショップ、7,900以上のブランドの取り扱い(ともに 2020年6月末時点) ● 常時83万点以上の商品アイテム数と毎日平均3,000点以上の新着 商品を掲載 ● 即日配送サービス ● ギフトラッピングサービス ● ツケ払い など 3
Slide 4
Slide 4 text
© ZOZO Technologies, Inc. アジェンダ ● ZOZOTOWNリプレイスとAPI Gateway ● API Gatewayにおける可観測性の課題と解決手法 ● まとめ 4
Slide 5
Slide 5 text
© ZOZO Technologies, Inc. ZOZOTOWNリプレイス 5
Slide 6
Slide 6 text
© ZOZO Technologies, Inc. 6 2004年 ZOZOTOWN オープン
Slide 7
Slide 7 text
© ZOZO Technologies, Inc. 7 ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた
Slide 8
Slide 8 text
© ZOZO Technologies, Inc. IIS (Web) RO iOS Android ブラウザ PC/SP リプレイス開始前: 〜2017年 ストアド ストアド ストアド 8 IIS (API) ロジックがDBに載っ ている(ストアド) 成功 ● データの近くで処理を行うため高速 (特に2005年当時はネットワークが細い) ● ロジックをDBに載せることでDRYにできる 課題 ● ストアドプロシージャ (ストアド) をスケール させづらい ● ストアドのテストが書きづらい ● Classic ASP ● Windows Server の構築自動化が難しい ● 現実問題、ASPレイヤーで2重管理になってい るロジックは存在する ● レガシーなフレームワークからの脱却も難しい
Slide 9
Slide 9 text
© ZOZO Technologies, Inc. 9 2017年4月
Slide 10
Slide 10 text
© ZOZO Technologies, Inc. Java API Read Only SQL ストアドを剥 がしてAPIに 移設 第1フェーズ: 2017年〜2020年 参照系ロジックのストアド剥がし IIS (Web) RO iOS Android ブラウザ PC/SP ストアド ストアド ストアド Read Only IIS (API) DBレプリ 課題 ● ASPレイヤーのロジックがそのまま ● 更新系のリプレイスが未計画 ● オンプレIISが入り口のままであるためオ ンプレを卒業できない設計 ● デプロイの順番待ち (モノリス) ● ビッグバンアップグレード (モノリス) ReadOnly 成功 ● ストアドロジックが減った ● クラウドに移行したことでスケーラビ リティを手にいれた (ECサイトは参照 リクエストが圧倒的に多い) ZOZO DC クラウド 10
Slide 11
Slide 11 text
© ZOZO Technologies, Inc. 改めて目的を再確認 なぜリプレイスするのか ZOZOTOWNの成長のため スピード をあげる コスト をさげる 人材 をふやす これらを達成できる組織にする 11
Slide 12
Slide 12 text
© ZOZO Technologies, Inc. 2020年度リプレイス方針 まず、変更しやすくしたい 1. ストアド剥がし (継続) 2. マイクロサービスの立ち上げ 12
Slide 13
Slide 13 text
© ZOZO Technologies, Inc. 商品 サービス RO お気に入り サービス RW メンバー サービス RW API Gateway ID認証 サービス RW IIS (Web) RO ブラウザ PC/SP ストアド ストアド ストアド IIS (API) ZOZO DC 第2フェーズ (2020年〜進行中) 切り替え方法 (ストラングラーパターン) iOS Android 切り替え 切り替え DBレプリ クラウド 13
Slide 14
Slide 14 text
© ZOZO Technologies, Inc. 移行方法としてストラングラーパターンを採用 段階的にレガシーからモダンなシステムへ移行する方法 14 ○ 既存アプリケーションと新規アプリケーションにリクエストを振り分けるファサードを作成 ○ 機能の特定部分を新しいアプリケーションに段階的に置き換えながら移行する https://docs.microsoft.com/ja-jp/azure/architecture/patterns/strangler
Slide 15
Slide 15 text
© ZOZO Technologies, Inc. API Gateway ● マイクロサービスのAPIの出入り口として機能するアプリケーション 商品 サービス RO お気に入り サービス RW メンバー サービス RW API Gateway ID認証 サービス RW IIS (Web) RO ブラウザ PC/SP ストアド ストアド ストアド IIS (API) ZOZO DC iOS Android 切り替え 切り替え DBレプリ クラウド これ 15
Slide 16
Slide 16 text
© ZOZO Technologies, Inc. API Gatewayのメリット ● 各マイクロサービスに求められる共通機能を集約できる ○ ルーティング ○ 認証、認可 ○ リトライ、タイムアウト設定 ○ ロギング、トレース ○ etc. 16
Slide 17
Slide 17 text
© ZOZO Technologies, Inc. API Gateway ID認証 サービス RW IIS (Web) RO ブラウザ PC/SP ストアド ストアド ストアド IIS (API) ZOZO DC iOS Android 切り替え 切り替え クラウド API Gatewayを用いた切替 (ストラングラーパターン) 17
Slide 18
Slide 18 text
© ZOZO Technologies, Inc. 商品 サービス RO API Gateway ID認証 サービス RW IIS (Web) RO ブラウザ PC/SP ストアド ストアド IIS (API) ZOZO DC iOS Android 切り替え 切り替え クラウド API Gatewayを用いた切替 (ストラングラーパターン) 18
Slide 19
Slide 19 text
© ZOZO Technologies, Inc. 商品 サービス RO お気に入り サービス RW API Gateway ID認証 サービス RW IIS (Web) ブラウザ PC/SP ストアド IIS (API) ZOZO DC iOS Android 切り替え 切り替え クラウド API Gatewayを用いた切替 (ストラングラーパターン) 19
Slide 20
Slide 20 text
© ZOZO Technologies, Inc. 商品 サービス RO お気に入り サービス RW メンバー サービス RW API Gateway ID認証 サービス RW IIS (Web) ブラウザ PC/SP IIS (API) ZOZO DC iOS Android クラウド API Gatewayを用いた切替 (ストラングラーパターン) 20
Slide 21
Slide 21 text
© ZOZO Technologies, Inc. 新フレームワーク Viewのみ 商品 サービス RO お気に入り サービス RW メンバー サービス RW ネイティブアプリ はAPI直呼び出し ブラウザ PC/SP iOS Android フロントエンドに 新技術が使えるよ うになる それぞれのAPIが 独立したサービスに =マイクロサービス化 API Gateway ID認証 サービス RW 21 第2フェーズ: 目指す姿
Slide 22
Slide 22 text
© ZOZO Technologies, Inc. 22 API Gatewayにおける 可観測性の課題と解決手法
Slide 23
Slide 23 text
© ZOZO Technologies, Inc. 可観測性確保のため必要なデータ 23 ● ログ ● メトリクス ● トレース
Slide 24
Slide 24 text
© ZOZO Technologies, Inc. ログ・インフラメトリクス収集 24 ● Datadogを使用 ○ 各マイクロサービスともにアプリケーションメトリクスはDatadogのAPM トレーシング ● CloudWatch Log/CloudWatch Container Insights ○ EKSを利用しているため基本的にノードやk8sのメトリクスについてはAWS ○ アラート通知はCloudWatchモニターからSlack ● Datadogを使用 ○ Elastic CloudなどAWSではないマネージドサービスについてはDatadog ○ アラート通知はDatadogモニターからSlack
Slide 25
Slide 25 text
© ZOZO Technologies, Inc. API Gatewayにおける可観測性の課題 25 ● どこで何が起こっている? ● API Gatewayのサイドカーコンテナも監視したい ● 収集する監視データが多く、俯瞰しにくい
Slide 26
Slide 26 text
© ZOZO Technologies, Inc. API Gatewayにおける可観測性の課題 26 ● どこで何が起こっている? ● API Gatewayのサイドカーコンテナも監視したい ● 収集する監視データが多く、俯瞰しにくい
Slide 27
Slide 27 text
© ZOZO Technologies, Inc. どこで何が起こっている? ● マイクロサービス化により複雑なサービス間連携が発生している が、各マイクロサービス単位でのAPMしか確認できない ● API Gatewayで発生したエラーが、どのマイクロサービスに起因す るのか追いにくい、パフォーマンスボトルネックを見つけづらい、 など、監視コストが高まっていた ● また、特定クライアントで発生するエラー も有り得るため、どのクライアントで発生 しているのか、にも関心が高まっていた 27 API Gateway Service A Service B Service C iOS Android
Slide 28
Slide 28 text
© ZOZO Technologies, Inc. ● トレーシングの課題に対してはDatadogの分散トレーシング機能を 利用して解決 ● Datadogでの分散トレーシングは非常に簡単に実現可能であり、ト レースの起点となるマイクロサービスに1コード埋め込むのみ 28 ➢ Golangでのトレース情報埋込例 どのマイクロサービスで起こっている? 分散トレーシング
Slide 29
Slide 29 text
© ZOZO Technologies, Inc. ➢ マイクロサービス間でのトレース例 29 API Gatewayを 含む3つのサー ビスがトレース されている。 どのマイクロサービスで起こっている? 分散トレーシング
Slide 30
Slide 30 text
© ZOZO Technologies, Inc. ● API GatewayではAPI認証を行っておりクライアント識別を行っ ている ● 識別したクライアント毎のリクエスト情報をトレースしたい 30 API Gateway ブラウザ PC/SP iOS Android IIS (Web) どのクライアントで起こっている? タグ付きトレース
Slide 31
Slide 31 text
© ZOZO Technologies, Inc. 31 ● Datadogのタグ付け機能を利用して解決 ● タグ付け機能もトレースの起点となるマイクロサービスに1コード 埋め込むのみ ➢ Golangでのクライアント情報を clientタグとして埋め込む例 ➢ APMのUIにclientタグが出現し クライアント情報でフィルター可能になる どのクライアントで起こっている? タグ付きトレース
Slide 32
Slide 32 text
© ZOZO Technologies, Inc. API Gatewayにおける可観測性の課題 32 ● どこで何が起こっている? ● API Gatewayのサイドカーコンテナも監視したい ● 収集する監視データが多く、俯瞰しにくい
Slide 33
Slide 33 text
© ZOZO Technologies, Inc. API Gatewayのサイドカーコンテナも監視したい ● API Gatewayは通信量削減によるユーザー体験向上のため、サイド カーコンテナとしてNginxを導入し、HTTP通信のgzip圧縮を行って いる ● このNginxの各種メトリクスやログも重要度が増してきた API Gateway Nginx Pod gzip化 33 iOS Android
Slide 34
Slide 34 text
© ZOZO Technologies, Inc. サイドカーコンテナNginxのメトリクスを収集したい ● やることは2つ ○ Nginxのstab_statusモジュールを有効にする ○ NginxのDeploymentマニフェストにannotationsを4行追加する 34 ➢ Deploymentにannotationsを 追加した例 ➢ Nginxのメトリクスが取得できる 以下はdev環境の例
Slide 35
Slide 35 text
© ZOZO Technologies, Inc. サイドカーコンテナNginxのログを収集したい ● k8s上で動作しているコンテナログは、Datadog Agentのマニフェ ストにenvを数行追加するだけで自動収集できる ➢ マニフェストにenvを追加した例 ➢ Datadog Log Managementで参照可能になる →コンテナログの収集を有効にした上で、 対象コンテナの判定条件を記載している 35
Slide 36
Slide 36 text
© ZOZO Technologies, Inc. API Gatewayにおける可観測性の課題 36 ● どこで何が起こっている? ● API Gatewayのサイドカーコンテナも監視したい ● 監視対象のデータが多く、俯瞰しにくい
Slide 37
Slide 37 text
© ZOZO Technologies, Inc. 監視対象のデータが多く、俯瞰しにくい ● Datadog個々の機能は導入も容易で非常に強力だが、複数のUIを渡 り歩くのは効率も悪く、辛い ○ Datadog APM ○ Datadog Log Management ○ Datadog Nginx Integration ● Datadog Dashboardでまとめよう! 37
Slide 38
Slide 38 text
© ZOZO Technologies, Inc. 38 Datadog Dashboard ➢ dev環境の例
Slide 39
Slide 39 text
© ZOZO Technologies, Inc. まとめ 39 ● ZOZOTOWNはクラウド化・マイクロサービス化を進める中で、柔軟な スケーラビリティやアジリティなどを獲得してきた ● 一方で、その複雑性により可観測性には課題が発生していた ● そこで、非常に強力なDatadog APMを導入し、さらに分散トレースやタ グ付きトレースの仕組みを利用することで、可観測性が向上した ● Datadogはトレース以外のログ・メトリクス収集も簡易に導入でき、 Dashboardでサービスにとって重要なデータをまとめることで、監視・ 運用者のコスト削減も見込める
Slide 40
Slide 40 text
No content