Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

    View full-size slide

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

    2

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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%

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. © ZOZO, Inc.
    25
    Performance Testing /
    Capacity Planning

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  32. © ZOZO, Inc.
    32
    Failure Testing

    View full-size slide

  33. © ZOZO, Inc.
    Failure Testing
    ✓ アプリケーションをデプロイしても瞬断しない
    ✓ アプリケーションにk8sのlivenessProbe, readinessProbe用の
    ヘルスチェックエンドポイントが用意されている
    ✓ livenessProbe用のエンドポイントは常に200 OKを返すもの
    ✓ readinessProbe用のエンドポイントは必須な依存システムにヘルス
    チェックリクエストを投げて正常な場合は200 OKを返し、異常な場
    合は503を返すもの

    33
    Probeの種類 役割 失敗時の挙動
    livenessProbe Pod内のコンテナが正常に動作しているかの確認 コンテナを再起動する
    readinessProbe Podがリクエストを受け付けることができるかの確認 トラフィックを流さない
    (Podを再起動しない)

    View full-size slide

  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

    View full-size slide

  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 !

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    44
    Old
    New
    replicas=3, maxUnavailable=1,maxSurge=0でrollingUpdateする例
    この新旧バージョンが混在する期間にエラーが発生しないことを確認する
    Failure Testing

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  51. © ZOZO, Inc.
    51
    Monitoring

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  59. © ZOZO, Inc.
    59
    Documentation

    View full-size slide

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

    60
    ❏ インフラ設計
    ❏ 運用・障害対応
    ❏ 後述するオンコールガイド

    View full-size slide

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

    View full-size slide

  62. © ZOZO, Inc.
    62
    おわりに

    View full-size slide

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

    View full-size slide