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

by akitok

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

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

Slide 25

Slide 25 text

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 aﬃnityで適切な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 aﬃnityを変更し切替

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

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

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を安全に起動させる ✓ ProxyConﬁgの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

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

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

Slide 51

Slide 51 text

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

Slide 59

Slide 59 text

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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