ZOZO Tech Meetup 「オンプレミスの運用からクラウドの運用へ〜SREのフロントエンドリプレイス裏側〜」

by Kaito Akita

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© ZOZO, Inc. 担当サービス       ● ZOZOSRE + PF-SVC-SRE  ○ Node.js(Next.js)のインフラ構築  ○ Akamaiの設定  ○ 既存のWebサーバー周りの設定など  ○ 既存のWebサーバーがNode.jsに移行されていくのでZOZOSREが今後運用することを想定    ● PF-INFRA-SRE  ○ Web Gatewayのインフラ構築  ○ API基盤ブロックで開発されるのでAPI Gatewayとセットで今後の運用を想定  7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© ZOZO, Inc. なぜこのような体制だったか  11 As Is To Be オンプレ or リプレイスで分かれていた組織及び役割目指すマイクロサービス化及びプロダクトに沿った組織へ管理するインフラもリプレイス先を見据えた形に変更 ZOZOSREとPF-SREで異なるポリシーやルール SRE部の統一的なルールやポリシーを策定しギャップを解消人員の移動や加入などより容易にしオンボーディングのストレスを解消する今までのチームで閉じたインフラ情報可視化と透明性を担保しインフラやサービスの理解度を向上 SRE部のエンジニアが管轄するインフラを理解しリプレイスを促進する強い内製組織を目指すために

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© ZOZO, Inc. 担当サービス       ● ZOZOSRE + PF-SVC-SRE  ○ Node.js(Next.js)のインフラ構築  ○ Akamaiの設定  ○ 既存のWebサーバー周りの設定など  ○ 既存のWebサーバーがNode.jsに移行されていくのでZOZOSREが今後運用することを想定    ● PF-INFRA-SRE  ○ Webのgatewayのインフラ構築  ○ API基盤チームで開発されるのでAPI Gatewayとセットで今後の運用を想定  13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© ZOZO, Inc. プロジェクトの進行  フロントエンドリプレイスを進める上での知識面について    ● ZOZOSREメンバーが必要な知識  ○ EKS（AWS Elastic Kubernetes Service）に関する基礎知識  ○ 社内のマイクロサービスに関する知識    ● PF-SVC-SREメンバーが必要な知識  ○ Akamaiや既存のWebサーバーの知識  ○ オンプレの全体的な構成やIISに関する設定の知識  15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© ZOZO, Inc. 19 Akamai Node.js Web Gateway Data Center Load Balancer Web Server SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 システム構成図  zozo.jp

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© ZOZO, Inc. 22 Akamai Node.js Web Gateway Data Center Load Balancer Web Server SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 システム構成図  zozo.jp / /shoes/ /cosme/ /sp/ /sp/shoes/ /sp/cosme/ /_next/data/* /apis/* それ以外 assets.imgz.jp

Slide 23

Slide 23 text

© ZOZO, Inc. インフラ構成について  ● Node.js  ○ 現行ZOZOTOWN、Webサーバーの後継  ○ ビューロジックの責務を継承  ○ SSRをするためのWebサーバー  ○ CSS、JSファイルなどのアセットファイルを作成  ■ GitHub ActionsでS3にアップロード  ● BFF（Aggregation API）  ○ SSR用とCSR用の２種類のエンドポイントを提供  ○ データの取得先は各マイクロサービス/PCSP API /Session Proxy/S3  23

Slide 24

Slide 24 text

© ZOZO, Inc. 24 Akamai Node.js Web Gateway Data Center Load Balancer Web Server SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 システム構成図  zozo.jp / /shoes/ /cosme/ /sp/ /sp/shoes/ /sp/cosme/ /_next/data/*

Slide 25

Slide 25 text

© ZOZO, Inc. インフラ構成について  ● Web Gateway  ○ API Gatewayの前段にありWebブラウザ(JavaScript)からのみリクエストを受ける  ○ フロントエンドアプリケーションのセッション・UIDの初期化とAPIリクエストのメンバー認証・転送の役割  ■ セッション・UIDの初期化処理は、フロントエンドアプリケーションの読み込み時に呼び出され、Session ProxyおよびPCSP APIと通信して行う  ■ メンバー認証は、リクエストの転送時、Cookieに格納されたSession ID/IDトークン/リフレッシュトークンを元に、Session ProxyおよびID基盤と連携して認証を行い、認証情報をヘッダーに付与する  ● API Gateway  ○ ストラングラーパターンを実現  ○ 複雑な APIリクエスト制御を実現し、その他要望にも素早く対応するため内製化している  ○ ルーティング機能/クライアント認証/メンバー認証などの機能がある  25

Slide 26

Slide 26 text

© ZOZO, Inc. 26 Akamai Node.js Web Gateway Data Center Load Balancer Web Server SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 システム構成図  zozo.jp /apis/*

Slide 27

Slide 27 text

© ZOZO, Inc. インフラ構成について  ● PCSP API  ○ 現行のDB操作、処理を行うためのAPI（ClassicASP）  ○ まだ作られていないマイクロサービスの代わり  ○ 現行のロジックをそのまま利用している部分もある  ○ Web GatewayとBFFから呼び出される  ● Session Proxy  ○ 現行のSession情報を取得、更新するためのAPI（ClassicASP）  ○ まだ作られていないSession基盤の代わり  ○ Web GatewayとBFFから呼び出される  27

Slide 28

Slide 28 text

© ZOZO, Inc. 28 Akamai Node.js Web Gateway Data Center Load Balancer Web Server SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 システム構成図  zozo.jp

Slide 29

Slide 29 text

© ZOZO, Inc. SecurityGroup for Podによる通信制御  ● 個人情報を扱うPCSP API/Session Proxyにアクセスできるマイクロサービスを限定するために導入  ● Web Gateway/BFFに導入  29 Session Proxy ALB Web Server Front API BFF AWS Account-X AWS Account-Y ✕ ◎

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© ZOZO, Inc. 31 Akamai Node.js Web Gateway Data Center Load Balancer Web Server SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 システム構成図  zozo.jp assets.imgz.jp

Slide 32

Slide 32 text

© ZOZO, Inc. 負荷試験ついて  前提  ● 負荷試験は弊社で開発したGatling OperatorといったOSSツールを利用しています  ● GatlingはWebアプリケーション向けのOSS負荷試験フレームワーク  ● Gatling OperatorはGatlingをベースとした分散負荷試験のライフサイクルを自動化するKubernetes Operatorになります。  ※Gatlingによる分散負荷試験を自動化するKubernetesオペレーターGatling Operatorの紹介 32

Slide 33

Slide 33 text

© ZOZO, Inc. 負荷試験について  試験観点  ● 目標リクエスト数を流した際に各システム(Node.js/Web Gateway/API Gateway/PCSP API/Session Proxy/BFF) が正常に動作しているかどうか  ○ 正常に動作  ○ 各レイテンシーが目標値以下  ○ エラーが０である事  ● 目標リクエスト数(新春セール*1.4)の各システム必要負荷を見積もれる事  ● リリース時に各システムのリソースが見積もれる  ● ボトルネックが把握できる  ● Direct Connectの帯域の不足がないか  33

Slide 34

Slide 34 text

© ZOZO, Inc. 負荷試験について  リクエスト数算出・目標値の決定  ● リクエスト数はSplunkを利用して見積もる  ○ 既存のWebサーバーのアクセスログからリクエスト数を抽出  ○ 秒間リクエスト数を見積もる  ● リクエスト数を抽出するターゲット  ○ セールイベントが無い土日平日  ○ ZOZOWEEK  ○ 新春セール  ● レイテンシはSLOの値をもとに目標値を決定    34

Slide 35

Slide 35 text

© ZOZO, Inc. 負荷試験について  シナリオ作成  ● 対象エンドポイントの洗い出し  ○ バックエンドチームとフロントエンドチームに確認  ○ まとめる  ● シナリオの内容に関して詳細すり合わせる  ○ リアルなユーザートラフィックに近づけることができるか  ■ パラメーターのパターン  ■ ログイン済みでシナリオを実施する  ○ リアルなユーザートラフィックを再現しづらい部分は最大req/secで見積もるようにする  ● 実際にアプリケーションを触りながら、挙動を確認しながらシナリオ作成をする    35

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© ZOZO, Inc. リリースについて  ● セキュリティ  ■ 適切なアクセス制御がされている  ● CI/CD  ■ ステージング、カナリア、本番のフェーズを備えた CI/CD パイプラインがあるなど  ● 障害試験  ■ デプロイ時に瞬断しない/安定稼働を担保するためのヘルスチェックなど  ● 負荷試験  ■ Podの見積もり/線形スケール可能/1Podあたりのスループット見積など  37 ● 監視  ○ PagerDuty/メトリクス可視化/アラート通知など  ● 障害予防  ○ Botのアクセス対策など  ● ドキュメント  ○ サービス/オンコールガイド/オンボーディングガイドなど  ● レビュー  ○ チームレビューの実施/テックリードレビューの実施  プロダクションレディチェックリスト   

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© ZOZO, Inc. まとめ  ● オンプレミスとモノリスなアプリケーションの運用からEKSを利用したNode.jsのアプリケーションの運用に取り組むようになった  ● 全く知識がない状態からペアプロ・モブプロの実施を通して技術トランスファーを行いクラウドの運用やリリースまでに必要なタスクを実施することができる  ● Ph1しかまだ終わっていないのでこれからの運用に向けて更にスキルアップしていく必要  39

Slide 40

Slide 40 text

© ZOZO, Inc. まとめ    40 As Is To Be オンプレ or リプレイスで分かれていた組織及び役割目指すマイクロサービス化及びプロダクトに沿った組織へ管理するインフラもリプレイス先を見据えた形に変更 ZOZOSREとPF-SREで異なるポリシーやルール SRE部の統一的なルールやポリシーを策定しギャップを解消人員の移動や加入などより容易にしオンボーディングのストレスを解消する今までのチームで閉じたインフラ情報可視化と透明性を担保しインフラやサービスの理解度を向上 SRE部のエンジニアが管轄するインフラを理解しリプレイスを促進する強い内製組織を目指すために

Slide 41

Slide 41 text

© ZOZO, Inc. 今後の展望  ● Node.jsのマルチプロセス化  ○ c6a.4xlargeにインスタンスタイプを変更予定  ● オンプレのリソースの最適化  ○ オンプレへのトラフィックが減少していくのでWebサーバーのリソースを調達する必要がなくなる  ○ AWSへ移っていくことでオンプレの運用コストも減少する  ○ オンプレのリソースを調整できる仕組みを検討  ● ZOZOSREのブロックでの運用  ● 継続的な負荷試験を行う仕組み  ○ 早期ボトルネックの発見    41

Slide 42

Slide 42 text

No content