Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取...

ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist

akitok

May 15, 2022
Tweet

More Decks by akitok

Other Decks in Technology

Transcript

  1. © ZOZO, Inc. 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック ブロック長 小林 明斗

    2020年7月にZOZOテクノロジーズ(現ZOZO)に入社し、 ZOZOTOWNリプレイスPJにSREとして参画 現在はZOZOTOWN Microservices PlatformのSREチーム リードを務める Twitter: @akitok_ 
 2
  2. © ZOZO, Inc. https://zozo.jp/ 3 • ファッション通販サイト • 1,500以上のショップ、8,400以上のブランドの取り扱い •

    常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品を掲載(2021年12月末時点) • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、靴の専門モール 「ZOZOSHOES」、ラグジュアリー&デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
  3. © ZOZO, Inc. ZOZOTOWN 2004 ZOZOTOWN オープン Architecture Infrastructure Monolith

    On Premise ID UI (pc/mobile) Search Cart Products Session Payment Favorites Membership Application
  4. © ZOZO, Inc. ZOZOTOWN modernization 2004 2018 ZOZOTOWN オープン ZOZOTOWN

    リプレイス始動 Architecture Infrastructure Monolith k8s based microservices On Premise Hybrids (On Premise + Public Cloud)
  5. © ZOZO, Inc. オンプレ 6 IIS (Web) DB 商品情報API DB(RO)

    DB DB etc. AWS ストアド ストアド ストアド IIS (API) ZOZOTOWN modernization
  6. © ZOZO, Inc. ZOZOTOWN modernization 2004 2018 2020 ストラングラー パターンによる

    リプレイス with API Gateway ZOZOTOWN オープン ZOZOTOWN リプレイス始動 ZOZOTOWN Platform SRE Team誕生!
  7. © ZOZO, Inc. オンプレ 8 IIS (Web) DB 商品情報API DB(RO)

    DB DB etc. AWS ストアド ストアド ストアド IIS (API) API Gateway ZOZOTOWN modernization 2020年からストラングラーパターンでマイクロサービス化を開始
  8. © ZOZO, Inc. オンプレ 9 IIS (Web) DB 商品情報API DB(RO)

    DB DB etc. AWS ストアド ストアド ストアド IIS (API) API Gateway ・URLのパスによって、各サービスにルーティングする ・認証 ・IP制限 ・タイムアウト ・リトライ ・加重ルーティング などをGo言語で実装したGateway ZOZOTOWN modernization
  9. © ZOZO, Inc. オンプレ 10 IIS (Web) DB 商品情報API DB(RO)

    DB DB etc. AWS ストアド ストアド ストアド IIS (API) ID認証API DB(RW) API Gateway 更新系ワークロードのリプレイス第一弾として、ID認証APIのリプレイスを達成 これをZOZOTOWNの1つのマイクロサービスの型として、さらなるリプレイス・マイクロサービス化を加速 ZOZOTOWN modernization
  10. © ZOZO, Inc. オンプレ 11 IIS (Web) DB 商品情報API DB(RO)

    DB DB etc. AWS ストアド ストアド ストアド IIS (API) ID認証API DB(RW) API Gateway ZOZOTOWN modernization 検索サービスも リプレイスしよう! カート決済も リプレイスしたいね BFF(Backends for Frontends) レイヤーもマイクロサービス化したい で、本番導入って何を準 備したら良いんだっけ?
  11. © ZOZO, Inc. オンプレ 12 IIS (Web) DB 推薦API ID認証API

    パーソナライズ API モジュールAPI DB DB etc. AWS GCP ストアド ストアド ストアド IIS (API) API Gateway Aggregation API(BFF) 商品情報API 検索API DB (RO) Elastic search DB (RW) カート決済 API Kinesis DB (RW) ZOZOTOWN modernization
  12. © ZOZO, Inc. Production Readiness Checklist • Production Readyとは? ➢

    本番トラフィックを任せられるという信頼のある状態を示す • Production Readiness Checklist *1 とは? ➢ サービスが本当にProduction Readyな状態になっているか 監査するためのチェックリスト 1. 安定性、信頼性を備えている 2. スケーラブルでパフォーマンスが高い 3. 耐障害性があり大惨事対応力がある 4. 適切に監視されている 5. ドキュメントが整備され、組織的に理解されている ➢ これらを具体的にチェックするために、技術組織のニーズや目標に合わ せて調整した個々の要件をチェックリスト化する 14 *1 プロダクションレディマイクロサービス [オライリージャパン] 付録A 本番対応のチェックリスト
  13. © ZOZO, Inc. ZOZOTOWN Production Readiness Checklist ZOZOTOWNではProduction Readiness Checklist*1

    をベースとして、 SREがサービス本番リリース前に何を準備したら良いのか、より実践しやすい ように規定した 15 Production Readiness Checklist *1 プロダクションレディマイクロサービス [オライリージャパン] 付録A 本番対応のチェックリスト より引用 
 ZOZOTOWN Microservice Production Readiness Checklist 1. 安定性、信頼性を備えている 2. スケーラブルでパフォーマンスが高い 3. 耐障害性があり大惨事対応力がある 4. 適切に監視されている 5. ドキュメントが整備され、組織的に理 解されている 1. CI/CD と Release Engineering 2. Performance Testing / Capacity Planning 3. Failure Testing 4. Monitoring 5. Documentation
  14. © ZOZO, Inc. CI/CD と Release Engineering ✓ アプリケーションリポジトリに、コンテナイメージを作成するCI/CDパイ プラインがあり、以下を備えている

    ✓ lint ✓ 単体テスト ✓ コンテナ脆弱性スキャン 17 App Code Dockerfile Unit Test lint 脆弱性 スキャン Docker build Docker push Slack 通知 コンテナアプリイメージ作成・登録 Amazon ECR
  15. © ZOZO, Inc. CI/CD と Release Engineering 19 ref. ZOZOTOWN

    マイクロサービスプロジェクトにおける継続的な改善を支えるCI/CD戦略 ✓ ステージング、本番のフェーズを備えたCI/CDパイプラインがある
  16. © ZOZO, Inc. CI/CD と Release Engineering ✓ カナリアリリースが実施できる ➢

    新しいアプリケーションをリリースする際に、最初からすべてのユー ザに公開するのではなく、一部のユーザに限定公開して、各種メトリ クスやサービス状況をモニタリングし、一定の基準をパスしたら、す べてのユーザにリリースする手法 20 New App Old App Old App Old App New App New App 90% 10% New App New App New App 100%
  17. © ZOZO, Inc. CI/CD と Release Engineering ZOZOTOWN Microservice Platformのカナリアリリース手法変遷

    21 ref. ZOZOTOWNマイクロサービスの段階的移行を支えるカナリアリリースとサービス間通信における信頼性向上の取り組み 2020年度末には、各サービスをカナリ アリリースする手段を用意した サービス影響を抑えて、安全にリリース できるようになる一方で、サービスごと にリリース手法が異なり、作業負荷が大 きくなった
  18. © ZOZO, Inc. CI/CD と Release Engineering ZOZOTOWN Microservice Platformのカナリアリリース手法変遷

    22 ALBより後段をすべてサービスメッシュ化することで、 すべてのサービスに対して、Istioを利用したカナリアリリースが出来るようになった ref. ZOZOTOWNにおける段階的なIstioサービスメッシュ化戦略
  19. © ZOZO, Inc. CI/CD と Release Engineering ZOZOTOWN Microservice Platformのカナリアリリース手法変遷

    23 Istioを用いて、以下のようなリリースステップで安全にリリースできるようになった Leveling Up Your CD: Unlocking Progressive Delivery on Kubernetes – Daniel Thomson & Jesse Suen, Intuit より引用 安全にリリースできるようになった一方で、 静的なカナリアリリース手法はメトリクスの 分析(Analyze)、リリース進行(Progress)/切 り戻し(Rollback)の判断・作業コストが高い メトリクスを監視して、動的なカナリアリ リース(Auto Analyze/Progress/Rollback) を行うProgressive Delivery導入を進行中
  20. © ZOZO, Inc. CI/CD と Release Engineering ✓ 開発者にCI/CDパイプラインの仕組みが共有されている ✓

    開発者がCI/CDパイプラインの改修を行うことができる ✓ リリースフローがドキュメント化され、SREおよび開発者に共有されている 24
  21. © ZOZO, Inc. Performance Testing / Capacity Planning 26 ✓

    アプリケーションPodの適切なキャパシティサイズ見積もりができている ✓ 1Podあたりのスループット(req/s)が見積もられている ✓ resources limitsに適切なリソース使用量が設定されている ➢ エラーが出ないラインではなく、レイテンシが跳ねないラインを探る Podのresource limitやアプリケーションの チューニングを行いながら、負荷試験を実施 ここでレイテンシが跳ねているため、1Podあた りのスループットは140 req/secとする 1Podあたりのスループットを計測した負荷試験結果の例
  22. © ZOZO, Inc. Performance Testing / Capacity Planning 27 ✓

    アプリケーションPodの適切なキャパシティサイズ見積もりができている ✓ アプリケーションPodのresources limitsを考慮し、適切なインスタン スサイズのnodegroupを作成している ✓ node affinityで適切なnodegroupを利用するように設定している ➢ 1nodeにつき1アプリケーションPod + Daemonset等の必要リソース を加味したインスタンスサイズのnodegroupを選定する ➢ Pod数(≒Node数)が多くなりすぎない m5.xlarge node m5.xlarge node m5.xlarge node m5.xlarge node m5.xlarge node m5.xlarge nodegroup m5.2xlarge node m5.2xlarge nodegroup m5.2xlarge node m5.2xlarge node m5.2xlarge node m5.2xlarge node Pod Daemonset Daemonset Pod Pod 負荷試験結果などを基に、 resource.limitsを増やす 既存nodegroupでは リソースが不十分なので、 node affinityを変更し切替
  23. © ZOZO, Inc. Performance Testing / Capacity Planning 28 ✓

    アプリケーションPodの適切なキャパシティサイズ見積もりができている ✓ 依存システム(DBなど)の適切なキャパシティサイズ見積もりができている ✓ 平常時、通常土日深夜ピーク、大規模セール深夜ピーク、正月ピーク それぞれで何台必要になるかわかっている ➢ 特に大きなセールイベントでは、開始時間にスパイクアクセスが殺到 するため、オートスケールが間に合わず事故につながる ➢ サービス特性に合わせて、想定されるイベントに対して、予測・計算 して、開始時間前にスケールアウトできるように準備する ➢ 例: イベント 想定リクエスト量 スループット/1Pod 必要なPod数 平常時 1000 req/sec 100 1000 / 100 = 10 Pod 土日深夜ピーク 2000 req/sec 100 2000 / 100 = 20 Pod 大規模セールピーク 4000 req/sec 100 4000 / 100 = 40 Pod 正月ピーク 8000 req/sec 100 8000 / 100 = 80 Pod
  24. © ZOZO, Inc. Performance Testing / Capacity Planning 29 ✓

    線形にスケールする ✓ k8sのHorizontal Pod Autoscaler(HPA)によるオートスケールが 発動する 線形にスケールする良い例 Pod数を増やすと順調に性能が伸 びている 線形にスケールしていない悪い例 Pod数を増やしても、性能が伸びなくなって いくパターン このパターンだと、リクエストが増えれば 増えるほどパフォーマンスの限界に行き着く スルー プット (req/s) Pod数 スルー プット (req/s) Pod数
  25. © ZOZO, Inc. Performance Testing / Capacity Planning 30 ✓

    正月ピークを耐えられる ➢ ZOZOTOWNにおいて1月1日の正月セール開始が1年を通して 最大のピーク ✓ 目標レイテンシよりも速い
  26. © ZOZO, Inc. Performance Testing / Capacity Planning 31 ✓

    ボトルネックがどこか把握している ➢ Datadog Dashboardを用いて、アラートが鳴った場合に調査したい メトリクスを一覧化している ✓ 高負荷でアラートが鳴った場合に、何を行えば良いか分かっている ➢ アラート対応手順は後述するオンコールガイドに記載する ❏ アプリケーションメトリクス ❏ リクエスト量 ❏ エラー量 ❏ レイテンシ ❏ インフラメトリクス ❏ CPU使用量 ❏ メモリ使用量 ❏ Pod数 ❏ 依存システム(DBなど) ❏ RDS ❏ ElastiCache …etc
  27. © ZOZO, Inc. Failure Testing ✓ アプリケーションをデプロイしても瞬断しない ✓ アプリケーションにk8sのlivenessProbe, readinessProbe用の

    ヘルスチェックエンドポイントが用意されている ✓ livenessProbe用のエンドポイントは常に200 OKを返すもの ✓ readinessProbe用のエンドポイントは必須な依存システムにヘルス チェックリクエストを投げて正常な場合は200 OKを返し、異常な場 合は503を返すもの 
 33 Probeの種類 役割 失敗時の挙動 livenessProbe Pod内のコンテナが正常に動作しているかの確認 コンテナを再起動する readinessProbe Podがリクエストを受け付けることができるかの確認 トラフィックを流さない (Podを再起動しない)
  28. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ k8sのlivenessProbe/readinessProbeにおけるinitialDelaySecondsを 適切に設定している ✓ k8sのminReadySecondsを適切に設定している

    (コンテナの起動時間、postStartを考慮し、適切に小さい値を指定する) ➢ つまり、Podを安全に起動させる 34 Failure Testing Pod Schedule (optional) postStart readinessProbe OK initialDelaySeconds minReadySeconds livenessProbe readinessProbe Pod Available
  29. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ k8sのminReadySecondsを適切に設定している ✓ k8sのlivenessProbe/readinessProbeにおけるinitialDelaySecondsを 適切に設定している

    (コンテナの起動時間、postStartを考慮し、適切に小さい値を指定する) ➢ つまり、Podを安全に起動させる 35 Failure Testing Pod Schedule (optional) postStart Pod Ready initialDelaySeconds minReadySeconds livenessProbe readinessProbe k8s 1.20でstartupProbeがGA !
  30. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ➢ k8s の minReadySeconds を適切に設定している

    ➢ k8s の livenessProbe / readinessProbeにおけるinitialDelaySecondsを 適切に設定している (コンテナの起動時間にちょうど良い程度に小さい時間を指定する) ➢ つまり、Podを安全に起動させる 37 Failure Testing Istio導入により、サイドカーコンテナが登場し変化 が...!!!
  31. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ メインコンテナの起動より先にistio-proxyの起動を完了させることで、 Podを安全に起動させる ✓ ProxyConfigのholdApplicationUntilProxyStartsをtrueにする

    38 Failure Testing Pod Schedule all containers init istio- proxy (envoy) istio-proxy Running App App Running Pod Schedule istio-proxy init istio- proxy (envoy) istio-proxy Running App App init App Running istio-proxyを 先に起動させる
  32. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ k8sのterminationGracePeriodSecondsを適切に設定している (デプロイ時に瞬断しない程度に小さい値を設定する) ➢ つまり、Podを安全に終了させる

    39 Termination preStop(Optional) SIGTERM SIGKILL Serviceのターゲット から除外される terminationGracePeriodSeconds preStop + SIGTERMの時間及び、既存コネクションが安全に処理される時間を 考慮して十分に小さい値を設定する 値が大きすぎると、Podの再起動時間が長くなり、リリース時間が長くなる ここから先は新規コネクション は生成されない Failure Testing
  33. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ k8sのterminationGracePeriodSecondsを適切に設定している (デプロイ時に瞬断しない程度に小さい値を設定する) ➢ つまり、Podを安全に終了させる

    40 Termination preStop(Optional) SIGTERM SIGKILL Serviceのターゲット から除外される terminationGracePeriodSeconds preStop + SIGTERMの時間及び、既存コネクションが安全に処理される時間を 考慮して十分に小さい値を設定する 値が大きすぎると、Podの再起動時間が長くなり、リリース時間が長くなる ここから先は新規コネクション は生成されない Istio導入により、サイドカーコンテナが登場し変化 が...!!! Failure Testing
  34. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ サイドカーのライフサイクルも考慮し、Podを安全に終了させる 41 Termination preStop(Optional)

    SIGTERM SIGKILL Serviceのターゲット から除外される App istio- proxy (envoy) terminationGracePeriodSeconds terminationDrainDuration terminationされてからistio-proxy(envoy)がdrainモードで待機する期間 この期間を経過すると、istio-proxyコンテナが停止するので、preStop + SIGTERMの時間 及び、既存コネクションが安全に処理される時間を考慮して十分に小さい値を設定する デフォルトが5秒なので要注意 Failure Testing
  35. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ サイドカーのライフサイクルも考慮し、Podを安全に終了させる 42 Termination preStop(Optional)

    SIGTERM SIGKILL Serviceのターゲット から除外される App istio- proxy (envoy) terminationGracePeriodSeconds terminationDrainDuration terminationされてからistio-proxy(envoy)がdrainモードで待機する期間 この期間を経過すると、istio-proxyコンテナが停止するので、preStop + SIGTERMの時間 及び、既存コネクションが安全に処理される時間を考慮して十分に小さい値を設定する デフォルトが5秒なので要注意 Istio 1.12から新機能が...!!! EXIT_ON_ZERO_ACTIVE_CONNECTIONS drainモードに移行したあとで、アクティブなコネクション がなくなるまで待つ機能 こちらはProduction Readiness Checklistに未反映...TBU Failure Testing
  36. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ Deployment StrategyはrollingUpdateを選択し、適切な値が設定され ている ✓

    rollingUpdate中に新旧バージョンのアプリケーションが混在する過渡 的状態においてもユーザー観点でエラーが発生することなく安定的に 動作すること
 44 Old New replicas=3, maxUnavailable=1,maxSurge=0でrollingUpdateする例 この新旧バージョンが混在する期間にエラーが発生しないことを確認する Failure Testing
  37. © ZOZO, Inc. AZ 2 AZ 1 46 ✓ 回復性がある

    ✓ AZ障害があった場合に障害AZが切り離されシステムとして正常な状態 に回復する ✓ AZ障害が復旧した場合に元に戻る ➢ Pod Topology Spread Constraintsを利用して実現 ref. Kubernetes Novice Tokyo#16 「PodのAZ分散を実現する Pod Topology Spread ConstraintsとDescheduler」 Pod AZ障害 AZ 1 AZ 2 AZ 3 AZ復旧 Pod AZ 3 Pod Pod Pod Pod AZ 2 AZ 1 Pod Pod AZ 3 Pod Failure Testing
  38. © ZOZO, Inc. 47 ✓ 回復性がある ✓ 依存システム(DBやマイクロサービスなど)がサービス断した場合に引 きづられて本システムも不安定にならないような対策が入っている (Circuit

    Breaker、早めのタイムアウトなど) App A App B App C App D App A App B App C App D App Dの障害によりApp Aに障害が波及しないように、以下のような対策をする • App A → App Dのリクエストを早めにタイムアウトさせる • Circuit BreakerによるApp Dの遮断 ref. Istioサーキットブレーカーで備えるマイクロサービスの連鎖障害 Failure Testing
  39. © ZOZO, Inc. 48 ✓ 回復性がある ✓ 依存システム(DBやマイクロサービスなど)がサービス断して復旧した 場合に正常な状態に回復する(connection poolが切断されたままになら

    ない、負荷が偏ったままにならないなど) App A App B App C App D App A App B App C App D App Dの復旧後、以下のようにApp Dへのリクエストが安全に再開される • Kubernetes ServiceによるL4レベルのラウンドロビンバランシングが行わ れ、App Dへのリクエストを再開させる • Istio OutlierDetection の機能でCircuit BreakerはApp Dの復旧を検知し、 リクエストを再開させる Failure Testing
  40. © ZOZO, Inc. ✓ 依存システムへのConnection Timeout、Read Timeoutが適切に小さく 設定されている ✓ Retryが設定されている

    ➢ サービス間通信はIstioを用いて、透過的にTimeout/Retry設定 ➢ DB通信では、DB接続ライブラリやフレームワークを活用して Timeout/Retry設定 
 49 envoy proxy App B (container) envoy proxy App A (container) DB Istio が透過的にTimeout/Retry設定を伝搬 接続先DBのライブラリ等を用いてTimeout/Retryを設定 Failure Testing
  41. © ZOZO, Inc. Monitoring ✓ 動作確認できる簡易ツールが用意されている ➢ 本番リリース前に後述する各種監視設定は導入するものの、設定誤り・ 漏れによるアラート不備や、ユーザ・開発者から問い合わせがあった際 に、現在の各環境の稼働状況をSREメンバで即座に確認

    52 なにもしてないけど ステージング環境が こわれました 開発環境だけ接続で きないんですが... なにもしてないけ ど... アラートは? リリース作業し てた? ダッシュボード は? 確かに再現した! 動作確認ツールを実行
  42. © ZOZO, Inc. Monitoring ✓ 監視アラートメッセージにオンコールガイドへのリンクを記す ➢ アラート発生時にオンコール担当者が迅速にアクションを起こせるよう にしたい ➢

    オンコールガイドには、アラート時のアクションを明記する ➢ マイクロサービスが増え、アラートおよびそのアクションは多様になっ ているので、アラートメッセージ内にオンコールガイドのリンクを記す ことで、誰でも即応できるように 53
  43. © ZOZO, Inc. ✓ APM(Application Performance Monitoring)が設定され、分散トレーシ ングが実現できている ✓ アプリケーションにDatadog

    APMの仕込みができている 54 API Gatewayを含む 3つのサービスが トレースされている Monitoring ref. Datadogと歩む ZOZOTOWNの可観測性 一気通貫したトレースがで きるようになることで、ど こで何が起こっているか調 査しやすい
  44. © ZOZO, Inc. Monitoring ✓ アプリケーションエラー通知ができている ✓ アプリケーションにSentryの仕込みができている ✓ サービスごとに適切なrate

    limitを設定する 55 App A App B App C App D Sentry Quota App A App B App C App D App A App B App C App D Sentry Quota App A App B App C App D サービスごとに rate limit 平 常 時 B 大 規 模 障 害 BのQuota消費により A, C, Dもエラー通知で きない A, C, Dも引き続き エラー通知できる
  45. © ZOZO, Inc. Monitoring ✓ アクセスログを取得している ✓ アプリケーションがアクセスログを出力している ✓ アクセスログがAmazon

    Kinesis Data Firehose経由でAmazon S3に保存 される ✓ Amazon S3に保存したアクセスログに対して、Amazon Athenaでクエリ を発行できる 56 Pod アクセス ログ Amazon Kinesis Data Firehose Amazon S3 Amazon Athena クエリを発行してログ解析
  46. © ZOZO, Inc. ✓ アラート通知が設定されている ✓ 5xxエラーが発生した場合にSlackに通知される ✓ レイテンシの高騰時にSlackに通知される ✓

    バッチが失敗した場合にSlackに通知される ✓ DBなど依存システムに対する適切なアラート設定がされている ✓ Amazon CloudWatch Syntheticsによるエンドポイント死活監視を行 い、PagerDutyで通知される 57 Monitoring
  47. © ZOZO, Inc. Documentation ✓ オンボーディングガイドを作成する ➢ 新たにジョインするメンバに、サービスの開発・運用に参加してもらう ためのドキュメント ➢

    「で、何を書いたら良いの?」とならないように ドキュメントテンプレートを用意して提供 ❏ アプリケーションの概要説明 ❏ アプリケーション設計 ❏ アーキテクチャ ❏ リクエストフロー ❏ ZOZOTOWNにおける利用箇所 ❏ リポジトリ
 60 ❏ インフラ設計 ❏ 運用・障害対応 ❏ 後述するオンコールガイド
  48. © ZOZO, Inc. ✓ オンコールガイドを作成する ➢ サービスのオンコール担当者がアラート対応・障害対応をする際に参照 するドキュメント ➢ 「で、何を書いたら良いの?」とならないように

    ドキュメントテンプレートを用意して提供 ❏ 連絡体制 ❏ 担当チーム ❏ アラートチャンネル ❏ オンコールローテーション ❏ モニタリング ❏ 監視ツールリンク集 61 ❏ 関連サービス ❏ 関連サービスとの連絡体制 ❏ インシデント対応 ❏ インシデント報告フロー ❏ インシデント報告履歴 ❏ アラート一覧と対応方法 Documentation
  49. © ZOZO, Inc. ➢ 今回紹介したのはZOZOTOWN Microservices Platformにおける1つの取り 組みであり、皆さんの抱えるサービスやアーキテクチャによって本番導入 に向けて準備すべきことは多種多様 ➢

    ZOZOTOWNでは2020年にProduction Readiness Checklistを策定して以 来、各環境で遭遇した課題に対応して、アップデートを行っている →Production Readiness Checklistは一度作って終わりではなく、  継続的な営みを続けることが重要!!! 63 おわりに