Tweet
Tweet

Slide 1

Slide 1 text

ZOZOTOWNの Production Readiness Checklistと 信頼性向上の取り組み 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック ブロック長 小林 明斗 Copyright © ZOZO, Inc. SRE NEXT 2022 2022/05/15

Slide 2

Slide 2 text

© ZOZO, Inc. 株式会社ZOZO 技術本部 SRE部 ECプラットフォーム基盤SREブロック ブロック長 小林 明斗 2020年7月にZOZOテクノロジーズ(現ZOZO)に入社し、 ZOZOTOWNリプレイスPJにSREとして参画 現在はZOZOTOWN Microservices PlatformのSREチーム リードを務める Twitter: @akitok_ 
 2

Slide 3

Slide 3 text

© ZOZO, Inc. https://zozo.jp/ 3 ● ファッション通販サイト ● 1,500以上のショップ、8,400以上のブランドの取り扱い ● 常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品を掲載（2021年12月末時点） ● ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、靴の専門モール 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 ● 即日配送サービス ● ギフトラッピングサービス ● ツケ払い など

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

© ZOZO, Inc. ZOZOTOWN modernization 2004 2018 ZOZOTOWN オープン ZOZOTOWN リプレイス始動 Architecture Infrastructure Monolith k8s based microservices On Premise Hybrids (On Premise + Public Cloud)

Slide 6

Slide 6 text

© ZOZO, Inc. オンプレ 6 IIS (Web) DB 商品情報API DB(RO) DB DB etc. AWS ストアド ストアド ストアド IIS (API) ZOZOTOWN modernization

Slide 7

Slide 7 text

© ZOZO, Inc. ZOZOTOWN modernization 2004 2018 2020 ストラングラー パターンによる リプレイス with API Gateway ZOZOTOWN オープン ZOZOTOWN リプレイス始動 ZOZOTOWN Platform SRE Team誕生！

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

© 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

Slide 11

Slide 11 text

© 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) レイヤーもマイクロサービス化したい で、本番導入って何を準 備したら良いんだっけ？

Slide 12

Slide 12 text

© 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

Slide 13

Slide 13 text

© ZOZO, Inc. 13 Production Readiness Checklist と 信頼性向上への取り組み

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

© 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

Slide 16

Slide 16 text

© ZOZO, Inc. 16 CI/CD と Release Engineering

Slide 17

Slide 17 text

© ZOZO, Inc. CI/CD と Release Engineering ✓ アプリケーションリポジトリに、コンテナイメージを作成するCI/CDパイ プラインがあり、以下を備えている ✓ lint ✓ 単体テスト ✓ コンテナ脆弱性スキャン 17 App Code Dockerfile Unit Test lint 脆弱性 スキャン Docker build Docker push Slack 通知 コンテナアプリイメージ作成・登録 Amazon ECR

Slide 18

Slide 18 text

© ZOZO, Inc. CI/CD と Release Engineering ✓ インフラリポジトリに、生成されたコンテナイメージをデプロイする CI/CDパイプラインがある 18 k8s YAML kubectl diff Slack 通知 kubectl diff and apply Amazon EKS kubectl apply Amazon ECR

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

© 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%

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

© 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導入を進行中

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

© ZOZO, Inc. 25 Performance Testing / Capacity Planning

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

© 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を変更し切替

Slide 28

Slide 28 text

© 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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

© ZOZO, Inc. 32 Failure Testing

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

© 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

Slide 35

Slide 35 text

© 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 !

Slide 36

Slide 36 text

© ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ コンテナの起動時に安全に暖気処理などを実施したい場合は、 initialDelaySecondsやminReadySecondsでの秒数調整ではなく、 startupProbeを活用し、制御する 36 Failure Testing Pod Schedule Pod Ready startupProbe livenessProbe readinessProbe

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

© 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を 先に起動させる

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

© 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

Slide 42

Slide 42 text

© 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

Slide 43

Slide 43 text

© ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ アプリケーションにgraceful shutdownが実装されている ➢ TERMシグナルを送ると、サーバが新しいリクエストを受け付けなく なり、サーバが受けているリクエスト全てにレスポンスを返してから shutdownするような実装を行う 43 Failure Testing

Slide 44

Slide 44 text

© ZOZO, Inc. ✓ アプリケーションをデプロイしても瞬断しない ✓ Deployment StrategyはrollingUpdateを選択し、適切な値が設定され ている ✓ rollingUpdate中に新旧バージョンのアプリケーションが混在する過渡 的状態においてもユーザー観点でエラーが発生することなく安定的に 動作すること
 44 Old New replicas=3, maxUnavailable=1,maxSurge=0でrollingUpdateする例 この新旧バージョンが混在する期間にエラーが発生しないことを確認する Failure Testing

Slide 45

Slide 45 text

© ZOZO, Inc. ✓ 回復性がある ✓ 依存システムをフェイルオーバーしても瞬断しない またはサービス断の時間が最小化されており、関係者間で許容の合意 が取れている 45 App A DB DB フェイルオーバー App A DB DB サービス断時間を最小化 Failure Testing

Slide 46

Slide 46 text

© 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

Slide 47

Slide 47 text

© 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

Slide 48

Slide 48 text

© 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

Slide 49

Slide 49 text

© 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

Slide 50

Slide 50 text

© ZOZO, Inc. ✓ 障害発生時の手順がドキュメント化されている (または障害の検出と修正が自動化されている) ➢ 後述するオンコールガイドに記載する 50 Failure Testing

Slide 51

Slide 51 text

© ZOZO, Inc. 51 Monitoring

Slide 52

Slide 52 text

© ZOZO, Inc. Monitoring ✓ 動作確認できる簡易ツールが用意されている ➢ 本番リリース前に後述する各種監視設定は導入するものの、設定誤り・ 漏れによるアラート不備や、ユーザ・開発者から問い合わせがあった際 に、現在の各環境の稼働状況をSREメンバで即座に確認 52 なにもしてないけど ステージング環境が こわれました 開発環境だけ接続で きないんですが... なにもしてないけ ど... アラートは？ リリース作業し てた？ ダッシュボード は？ 確かに再現した! 動作確認ツールを実行

Slide 53

Slide 53 text

© ZOZO, Inc. Monitoring ✓ 監視アラートメッセージにオンコールガイドへのリンクを記す ➢ アラート発生時にオンコール担当者が迅速にアクションを起こせるよう にしたい ➢ オンコールガイドには、アラート時のアクションを明記する ➢ マイクロサービスが増え、アラートおよびそのアクションは多様になっ ているので、アラートメッセージ内にオンコールガイドのリンクを記す ことで、誰でも即応できるように 53

Slide 54

Slide 54 text

© ZOZO, Inc. ✓ APM(Application Performance Monitoring)が設定され、分散トレーシ ングが実現できている ✓ アプリケーションにDatadog APMの仕込みができている 54 API Gatewayを含む 3つのサービスが トレースされている Monitoring ref. Datadogと歩む ZOZOTOWNの可観測性 一気通貫したトレースがで きるようになることで、ど こで何が起こっているか調 査しやすい

Slide 55

Slide 55 text

© 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も引き続き エラー通知できる

Slide 56

Slide 56 text

© ZOZO, Inc. Monitoring ✓ アクセスログを取得している ✓ アプリケーションがアクセスログを出力している ✓ アクセスログがAmazon Kinesis Data Firehose経由でAmazon S3に保存 される ✓ Amazon S3に保存したアクセスログに対して、Amazon Athenaでクエリ を発行できる 56 Pod アクセス ログ Amazon Kinesis Data Firehose Amazon S3 Amazon Athena クエリを発行してログ解析

Slide 57

Slide 57 text

© ZOZO, Inc. ✓ アラート通知が設定されている ✓ 5xxエラーが発生した場合にSlackに通知される ✓ レイテンシの高騰時にSlackに通知される ✓ バッチが失敗した場合にSlackに通知される ✓ DBなど依存システムに対する適切なアラート設定がされている ✓ Amazon CloudWatch Syntheticsによるエンドポイント死活監視を行 い、PagerDutyで通知される 57 Monitoring

Slide 58

Slide 58 text

© ZOZO, Inc. ✓ オンコールガイド・ローテーションが用意され、共有されている ✓ オンコールガイドが作成されており、SRE及び開発者に共有されている ✓ SRE、開発者それぞれのオンコールローテーションが組まれている 58 Monitoring

Slide 59

Slide 59 text

© ZOZO, Inc. 59 Documentation

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

© ZOZO, Inc. ✓ オンコールガイドを作成する ➢ サービスのオンコール担当者がアラート対応・障害対応をする際に参照 するドキュメント ➢ 「で、何を書いたら良いの？」とならないように ドキュメントテンプレートを用意して提供 ❏ 連絡体制 ❏ 担当チーム ❏ アラートチャンネル ❏ オンコールローテーション ❏ モニタリング ❏ 監視ツールリンク集 61 ❏ 関連サービス ❏ 関連サービスとの連絡体制 ❏ インシデント対応 ❏ インシデント報告フロー ❏ インシデント報告履歴 ❏ アラート一覧と対応方法 Documentation

Slide 62

Slide 62 text

© ZOZO, Inc. 62 おわりに

Slide 63

Slide 63 text

© ZOZO, Inc. ➢ 今回紹介したのはZOZOTOWN Microservices Platformにおける1つの取り 組みであり、皆さんの抱えるサービスやアーキテクチャによって本番導入 に向けて準備すべきことは多種多様 ➢ ZOZOTOWNでは2020年にProduction Readiness Checklistを策定して以 来、各環境で遭遇した課題に対応して、アップデートを行っている →Production Readiness Checklistは一度作って終わりではなく、 　継続的な営みを続けることが重要!!! 63 おわりに

Slide 64

Slide 64 text

No content