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

Transcript

1. ZOZOTOWNの Production Readiness Checklistと 信頼性向上の取り組み 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック ブロック長 小林 明斗 Copyright © ZOZO, Inc. SRE NEXT 2022 2022/05/15
2. © ZOZO, Inc. 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック ブロック長 小林 明斗 2020年7月にZOZOテクノロジーズ(現ZOZO)に入社し、 ZOZOTOWNリプレイスPJにSREとして参画 現在はZOZOTOWN Microservices PlatformのSREチーム リードを務める Twitter: @akitok_ 
 2
3. © ZOZO, Inc. https://zozo.jp/ 3 • ファッション通販サイト • 1,500以上のショップ、8,400以上のブランドの取り扱い • 常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品を掲載（2021年12月末時点） • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、靴の専門モール 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
4. © ZOZO, Inc. ZOZOTOWN 2004 ZOZOTOWN オープン Architecture Infrastructure Monolith On Premise ID UI (pc/mobile) Search Cart Products Session Payment Favorites Membership Application
5. © ZOZO, Inc. ZOZOTOWN modernization 2004 2018 ZOZOTOWN オープン ZOZOTOWN リプレイス始動 Architecture Infrastructure Monolith k8s based microservices On Premise Hybrids (On Premise + Public Cloud)
6. © ZOZO, Inc. オンプレ 6 IIS (Web) DB 商品情報API DB(RO) DB DB etc. AWS ストアド ストアド ストアド IIS (API) ZOZOTOWN modernization
7. © ZOZO, Inc. ZOZOTOWN modernization 2004 2018 2020 ストラングラー パターンによる リプレイス with API Gateway ZOZOTOWN オープン ZOZOTOWN リプレイス始動 ZOZOTOWN Platform SRE Team誕生！
8. © ZOZO, Inc. オンプレ 8 IIS (Web) DB 商品情報API DB(RO) DB DB etc. AWS ストアド ストアド ストアド IIS (API) API Gateway ZOZOTOWN modernization 2020年からストラングラーパターンでマイクロサービス化を開始
9. © ZOZO, Inc. オンプレ 9 IIS (Web) DB 商品情報API DB(RO) DB DB etc. AWS ストアド ストアド ストアド IIS (API) API Gateway ・URLのパスによって、各サービスにルーティングする ・認証 ・IP制限 ・タイムアウト ・リトライ ・加重ルーティング などをGo言語で実装したGateway ZOZOTOWN modernization
10. © 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
11. © 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) レイヤーもマイクロサービス化したい で、本番導入って何を準 備したら良いんだっけ？
12. © 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
13. © ZOZO, Inc. 13 Production Readiness Checklist と 信頼性向上への取り組み
14. © ZOZO, Inc. Production Readiness Checklist • Production Readyとは？ ➢ 本番トラフィックを任せられるという信頼のある状態を示す • Production Readiness Checklist *1 とは? ➢ サービスが本当にProduction Readyな状態になっているか 監査するためのチェックリスト 1. 安定性、信頼性を備えている 2. スケーラブルでパフォーマンスが高い 3. 耐障害性があり大惨事対応力がある 4. 適切に監視されている 5. ドキュメントが整備され、組織的に理解されている ➢ これらを具体的にチェックするために、技術組織のニーズや目標に合わ せて調整した個々の要件をチェックリスト化する 14 *1 プロダクションレディマイクロサービス [オライリージャパン] 付録A 本番対応のチェックリスト
15. © 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
16. © ZOZO, Inc. 16 CI/CD と Release Engineering
17. © ZOZO, Inc. CI/CD と Release Engineering ✓ アプリケーションリポジトリに、コンテナイメージを作成するCI/CDパイ プラインがあり、以下を備えている ✓ lint ✓ 単体テスト ✓ コンテナ脆弱性スキャン 17 App Code Dockerfile Unit Test lint 脆弱性 スキャン Docker build Docker push Slack 通知 コンテナアプリイメージ作成・登録 Amazon ECR
18. © ZOZO, Inc. CI/CD と Release Engineering ✓ インフラリポジトリに、生成されたコンテナイメージをデプロイする CI/CDパイプラインがある 18 k8s YAML kubectl diff Slack 通知 kubectl diff and apply Amazon EKS kubectl apply Amazon ECR
19. © ZOZO, Inc. CI/CD と Release Engineering 19 ref. ZOZOTOWN マイクロサービスプロジェクトにおける継続的な改善を支えるCI/CD戦略 ✓ ステージング、本番のフェーズを備えたCI/CDパイプラインがある
20. © 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%
21. © ZOZO, Inc. CI/CD と Release Engineering ZOZOTOWN Microservice Platformのカナリアリリース手法変遷 21 ref. ZOZOTOWNマイクロサービスの段階的移行を支えるカナリアリリースとサービス間通信における信頼性向上の取り組み 2020年度末には、各サービスをカナリ アリリースする手段を用意した サービス影響を抑えて、安全にリリース できるようになる一方で、サービスごと にリリース手法が異なり、作業負荷が大 きくなった
22. © ZOZO, Inc. CI/CD と Release Engineering ZOZOTOWN Microservice Platformのカナリアリリース手法変遷 22 ALBより後段をすべてサービスメッシュ化することで、 すべてのサービスに対して、Istioを利用したカナリアリリースが出来るようになった ref. ZOZOTOWNにおける段階的なIstioサービスメッシュ化戦略
23. © 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導入を進行中
24. © ZOZO, Inc. CI/CD と Release Engineering ✓ 開発者にCI/CDパイプラインの仕組みが共有されている ✓ 開発者がCI/CDパイプラインの改修を行うことができる ✓ リリースフローがドキュメント化され、SREおよび開発者に共有されている 24
25. © ZOZO, Inc. 25 Performance Testing / Capacity Planning
26. © ZOZO, Inc. Performance Testing / Capacity Planning 26 ✓ アプリケーションPodの適切なキャパシティサイズ見積もりができている ✓ 1Podあたりのスループット(req/s)が見積もられている ✓ resources limitsに適切なリソース使用量が設定されている ➢ エラーが出ないラインではなく、レイテンシが跳ねないラインを探る Podのresource limitやアプリケーションの チューニングを行いながら、負荷試験を実施 ここでレイテンシが跳ねているため、1Podあた りのスループットは140 req/secとする 1Podあたりのスループットを計測した負荷試験結果の例
27. © 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を変更し切替
28. © 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
29. © ZOZO, Inc. Performance Testing / Capacity Planning 29 ✓ 線形にスケールする ✓ k8sのHorizontal Pod Autoscaler(HPA)によるオートスケールが 発動する 線形にスケールする良い例 Pod数を増やすと順調に性能が伸 びている 線形にスケールしていない悪い例 Pod数を増やしても、性能が伸びなくなって いくパターン このパターンだと、リクエストが増えれば 増えるほどパフォーマンスの限界に行き着く スルー プット (req/s) Pod数 スルー プット (req/s) Pod数
30. © ZOZO, Inc. Performance Testing / Capacity Planning 30 ✓ 正月ピークを耐えられる ➢ ZOZOTOWNにおいて1月1日の正月セール開始が1年を通して 最大のピーク ✓ 目標レイテンシよりも速い
31. © ZOZO, Inc. Performance Testing / Capacity Planning 31 ✓ ボトルネックがどこか把握している ➢ Datadog Dashboardを用いて、アラートが鳴った場合に調査したい メトリクスを一覧化している ✓ 高負荷でアラートが鳴った場合に、何を行えば良いか分かっている ➢ アラート対応手順は後述するオンコールガイドに記載する ❏ アプリケーションメトリクス ❏ リクエスト量 ❏ エラー量 ❏ レイテンシ ❏ インフラメトリクス ❏ CPU使用量 ❏ メモリ使用量 ❏ Pod数 ❏ 依存システム(DBなど) ❏ RDS ❏ ElastiCache …etc
32. © ZOZO, Inc. 32 Failure Testing
33. © ZOZO, Inc. Failure Testing ✓ アプリケーションをデプロイしても瞬断しない ✓ アプリケーションにk8sのlivenessProbe, readinessProbe用の ヘルスチェックエンドポイントが用意されている ✓ livenessProbe用のエンドポイントは常に200 OKを返すもの ✓ readinessProbe用のエンドポイントは必須な依存システムにヘルス チェックリクエストを投げて正常な場合は200 OKを返し、異常な場 合は503を返すもの 
 33 Probeの種類 役割 失敗時の挙動 livenessProbe Pod内のコンテナが正常に動作しているかの確認 コンテナを再起動する readinessProbe Podがリクエストを受け付けることができるかの確認 トラフィックを流さない (Podを再起動しない)
34. © 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
35. © 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 !
36. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ コンテナの起動時に安全に暖気処理などを実施したい場合は、 initialDelaySecondsやminReadySecondsでの秒数調整ではなく、 startupProbeを活用し、制御する 36 Failure Testing Pod Schedule Pod Ready startupProbe livenessProbe readinessProbe
37. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ➢ k8s の minReadySeconds を適切に設定している ➢ k8s の livenessProbe / readinessProbeにおけるinitialDelaySecondsを 適切に設定している (コンテナの起動時間にちょうど良い程度に小さい時間を指定する) ➢ つまり、Podを安全に起動させる 37 Failure Testing Istio導入により、サイドカーコンテナが登場し変化 が...!!!
38. © 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を 先に起動させる
39. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ k8sのterminationGracePeriodSecondsを適切に設定している (デプロイ時に瞬断しない程度に小さい値を設定する) ➢ つまり、Podを安全に終了させる 39 Termination preStop(Optional) SIGTERM SIGKILL Serviceのターゲット から除外される terminationGracePeriodSeconds preStop + SIGTERMの時間及び、既存コネクションが安全に処理される時間を 考慮して十分に小さい値を設定する 値が大きすぎると、Podの再起動時間が長くなり、リリース時間が長くなる ここから先は新規コネクション は生成されない Failure Testing
40. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ k8sのterminationGracePeriodSecondsを適切に設定している (デプロイ時に瞬断しない程度に小さい値を設定する) ➢ つまり、Podを安全に終了させる 40 Termination preStop(Optional) SIGTERM SIGKILL Serviceのターゲット から除外される terminationGracePeriodSeconds preStop + SIGTERMの時間及び、既存コネクションが安全に処理される時間を 考慮して十分に小さい値を設定する 値が大きすぎると、Podの再起動時間が長くなり、リリース時間が長くなる ここから先は新規コネクション は生成されない Istio導入により、サイドカーコンテナが登場し変化 が...!!! Failure Testing
41. © 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
42. © 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
43. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ アプリケーションにgraceful shutdownが実装されている ➢ TERMシグナルを送ると、サーバが新しいリクエストを受け付けなく なり、サーバが受けているリクエスト全てにレスポンスを返してから shutdownするような実装を行う 43 Failure Testing
44. © ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ Deployment StrategyはrollingUpdateを選択し、適切な値が設定され ている ✓ rollingUpdate中に新旧バージョンのアプリケーションが混在する過渡 的状態においてもユーザー観点でエラーが発生することなく安定的に 動作すること
 44 Old New replicas=3, maxUnavailable=1,maxSurge=0でrollingUpdateする例 この新旧バージョンが混在する期間にエラーが発生しないことを確認する Failure Testing
45. © ZOZO, Inc. ✓ 回復性がある ✓ 依存システムをフェイルオーバーしても瞬断しない またはサービス断の時間が最小化されており、関係者間で許容の合意 が取れている 45 App A DB DB フェイルオーバー App A DB DB サービス断時間を最小化 Failure Testing
46. © 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
47. © 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
48. © 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
49. © 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
50. © ZOZO, Inc. ✓ 障害発生時の手順がドキュメント化されている (または障害の検出と修正が自動化されている) ➢ 後述するオンコールガイドに記載する 50 Failure Testing
51. © ZOZO, Inc. 51 Monitoring
52. © ZOZO, Inc. Monitoring ✓ 動作確認できる簡易ツールが用意されている ➢ 本番リリース前に後述する各種監視設定は導入するものの、設定誤り・ 漏れによるアラート不備や、ユーザ・開発者から問い合わせがあった際 に、現在の各環境の稼働状況をSREメンバで即座に確認 52 なにもしてないけど ステージング環境が こわれました 開発環境だけ接続で きないんですが... なにもしてないけ ど... アラートは？ リリース作業し てた？ ダッシュボード は？ 確かに再現した! 動作確認ツールを実行
53. © ZOZO, Inc. Monitoring ✓ 監視アラートメッセージにオンコールガイドへのリンクを記す ➢ アラート発生時にオンコール担当者が迅速にアクションを起こせるよう にしたい ➢ オンコールガイドには、アラート時のアクションを明記する ➢ マイクロサービスが増え、アラートおよびそのアクションは多様になっ ているので、アラートメッセージ内にオンコールガイドのリンクを記す ことで、誰でも即応できるように 53
54. © ZOZO, Inc. ✓ APM(Application Performance Monitoring)が設定され、分散トレーシ ングが実現できている ✓ アプリケーションにDatadog APMの仕込みができている 54 API Gatewayを含む 3つのサービスが トレースされている Monitoring ref. Datadogと歩む ZOZOTOWNの可観測性 一気通貫したトレースがで きるようになることで、ど こで何が起こっているか調 査しやすい
55. © 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も引き続き エラー通知できる
56. © ZOZO, Inc. Monitoring ✓ アクセスログを取得している ✓ アプリケーションがアクセスログを出力している ✓ アクセスログがAmazon Kinesis Data Firehose経由でAmazon S3に保存 される ✓ Amazon S3に保存したアクセスログに対して、Amazon Athenaでクエリ を発行できる 56 Pod アクセス ログ Amazon Kinesis Data Firehose Amazon S3 Amazon Athena クエリを発行してログ解析
57. © ZOZO, Inc. ✓ アラート通知が設定されている ✓ 5xxエラーが発生した場合にSlackに通知される ✓ レイテンシの高騰時にSlackに通知される ✓ バッチが失敗した場合にSlackに通知される ✓ DBなど依存システムに対する適切なアラート設定がされている ✓ Amazon CloudWatch Syntheticsによるエンドポイント死活監視を行 い、PagerDutyで通知される 57 Monitoring
58. © ZOZO, Inc. ✓ オンコールガイド・ローテーションが用意され、共有されている ✓ オンコールガイドが作成されており、SRE及び開発者に共有されている ✓ SRE、開発者それぞれのオンコールローテーションが組まれている 58 Monitoring
59. © ZOZO, Inc. 59 Documentation
60. © ZOZO, Inc. Documentation ✓ オンボーディングガイドを作成する ➢ 新たにジョインするメンバに、サービスの開発・運用に参加してもらう ためのドキュメント ➢ 「で、何を書いたら良いの？」とならないように ドキュメントテンプレートを用意して提供 ❏ アプリケーションの概要説明 ❏ アプリケーション設計 ❏ アーキテクチャ ❏ リクエストフロー ❏ ZOZOTOWNにおける利用箇所 ❏ リポジトリ
 60 ❏ インフラ設計 ❏ 運用・障害対応 ❏ 後述するオンコールガイド
61. © ZOZO, Inc. ✓ オンコールガイドを作成する ➢ サービスのオンコール担当者がアラート対応・障害対応をする際に参照 するドキュメント ➢ 「で、何を書いたら良いの？」とならないように ドキュメントテンプレートを用意して提供 ❏ 連絡体制 ❏ 担当チーム ❏ アラートチャンネル ❏ オンコールローテーション ❏ モニタリング ❏ 監視ツールリンク集 61 ❏ 関連サービス ❏ 関連サービスとの連絡体制 ❏ インシデント対応 ❏ インシデント報告フロー ❏ インシデント報告履歴 ❏ アラート一覧と対応方法 Documentation
62. © ZOZO, Inc. 62 おわりに
63. © ZOZO, Inc. ➢ 今回紹介したのはZOZOTOWN Microservices Platformにおける1つの取り 組みであり、皆さんの抱えるサービスやアーキテクチャによって本番導入 に向けて準備すべきことは多種多様 ➢ ZOZOTOWNでは2020年にProduction Readiness Checklistを策定して以 来、各環境で遭遇した課題に対応して、アップデートを行っている →Production Readiness Checklistは一度作って終わりではなく、 　継続的な営みを続けることが重要!!! 63 おわりに