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

6/8（木) に行われた【オフライン】ZOZO Tech Meetup〜ZOZOTOWNフロントエンドリプレイスの事例紹介〜
イベントURL：https://zozotech-inc.connpass.com/event/283986/

Transcript

1. オンプレミスの運用からクラウドの運 用へ
 〜 SREのフロントエンドリプレイス裏側 〜
 株式会社ZOZO
 技術本部 SRE部 ZOZOSREブロック
 秋田 海人 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO
 技術本部 SRE部 ZOZOSREブロック
 秋田 海人
 2020年新卒入社。ZOZOTOWNに関わるオンプレミスとクラウ ドを使った構築・運用・保守を担当するチームに所属。
 フロントエンドリプレイスプロジェクトではSREの責任者として オンプレミスからEKSと幅広く手を動かしている。最近は沖縄 に移住して真のうみんちゅとなった男。
 
 2
3. © ZOZO, Inc. はじめに
 これまでZOZOSREブロックではZOZOTOWNのオンプレミスとモ ノリスなアプリケーションの運用・保守を担当してきました。全く EKSやマイクロサービスの運用知識がないなかでどのようにフ ロントエンドリプレイスプロジェクトに参画し技術的な取り組みを 行っていたか
 3
4. © ZOZO, Inc. アジェンダ
 • SRE部のプロジェクト体制
 • プロジェクトの進行
 • フロントエンドリプレイスのインフラ
 • まとめと今後の展望
 4
5. © ZOZO, Inc. • SRE部のプロジェクト体制
 • プロジェクトの進行
 • フロントエンドリプレイスのインフラ
 • まとめと今後の展望
 5 アジェンダ

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

13. © 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
14. © ZOZO, Inc. なぜこのような体制だったか
 14
15. © ZOZO, Inc. プロジェクトの進行
 フロントエンドリプレイスを進める上での知識面について
 
 • ZOZOSREメンバーが必要な知識
 ◦ EKS（AWS Elastic Kubernetes Service）に関する基礎知識
 ◦ 社内のマイクロサービスに関する知識
 
 • PF-SVC-SREメンバーが必要な知識
 ◦ Akamaiや既存のWebサーバーの知識
 ◦ オンプレの全体的な構成やIISに関する設定の知識
 15
16. © ZOZO, Inc. プロジェクトの進行
 
 技術トランスファーについて
 
 • 頻繁なペアプロ・モブプロの実施
 ◦ タスクを通して時間をかけて構成把握、スキル向上
 
 • 作業する時間で出入り自由なMeetを作って参加
 ◦ 気軽に相談できる機会やどんなことをやっているかわかる機会
 
 
 
 16
17. © ZOZO, Inc. プロジェクトの進行
 
 その他 工夫してたところ
 
 • GitHub Projectsによるタスク管理
 ◦ お互いがやりやすいタスク管理
 
 • 3ブロック合同で定例をやる
 ◦ コミュニケーションをとる機会を設ける
 
 
 17
18. © ZOZO, Inc. • SRE部のプロジェクト体制
 • プロジェクトの進行
 • フロントエンドリプレイスのインフラ
 • まとめと今後の展望
 18 アジェンダ

19. © 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
20. © ZOZO, Inc. インフラ構成について
 アプリケーション/サービス
 • Akamai
 • Node.js
 • BFF（Aggregation API）
 • Web Gateway
 • API Gateway
 • PCSP API
 • Session Proxy
 • 静的コンテンツ（S3）
 
 20
21. © ZOZO, Inc. インフラ構成について
 • Akamai
 ◦ CDN（Contents Delivery Network)
 ▪ S3のファイルを配信
 ◦ DNS
 ◦ ALBとしてパスルーティング機能/加重ルーティング機能
 ◦ セキュリティ機能
 ◦ オリジンサーバーとしてオンプレ/Web Gateway/Node.jsを登録
 21
22. © 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
23. © ZOZO, Inc. インフラ構成について
 • Node.js
 ◦ 現行ZOZOTOWN、Webサーバーの後継
 ◦ ビューロジックの責務を継承
 ◦ SSRをするためのWebサーバー
 ◦ CSS、JSファイルなどのアセットファイルを作成
 ▪ GitHub ActionsでS3にアップロード
 • BFF（Aggregation API）
 ◦ SSR用とCSR用の２種類のエンドポイントを提供
 ◦ データの取得先は各マイクロサービス/PCSP API /Session Proxy/S3
 23
24. © 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/*
25. © 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
26. © 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/*
27. © ZOZO, Inc. インフラ構成について
 • PCSP API
 ◦ 現行のDB操作、処理を行うためのAPI（ClassicASP）
 ◦ まだ作られていないマイクロサービスの代わり
 ◦ 現行のロジックをそのまま利用している部分もある
 ◦ Web GatewayとBFFから呼び出される
 • Session Proxy
 ◦ 現行のSession情報を取得、更新するためのAPI（ClassicASP）
 ◦ まだ作られていないSession基盤の代わり
 ◦ Web GatewayとBFFから呼び出される
 27
28. © 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
29. © 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 ✕ ◎
30. © ZOZO, Inc. インフラ構成について
 • 静的コンテンツ（S3）
 ◦ 採用情報、セール情報、LPなどのJSONファイルを管理
 ◦ VPC エンドポイントを利用して内部通信で取得
 ◦ Node.jsでビルドしたCSS、JSファイルなどのアセットファイルも管理
 ▪ Akamai CDNで配信
 ◦ 既存のWebサーバーとBFFから呼び出される
 30
31. © 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
32. © ZOZO, Inc. 負荷試験ついて
 前提
 • 負荷試験は弊社で開発したGatling OperatorといったOSSツールを利用しています
 • GatlingはWebアプリケーション向けのOSS負荷試験フレームワーク
 • Gatling OperatorはGatlingをベースとした分散負荷試験のライフサイクルを自動化するKubernetes Operatorになり ます。
 ※Gatlingによる分散負荷試験を自動化するKubernetesオペレーターGatling Operatorの紹介 32
33. © ZOZO, Inc. 負荷試験について
 試験観点
 • 目標リクエスト数を流した際に各システム(Node.js/Web Gateway/API Gateway/PCSP API/Session Proxy/BFF) が正常に動作しているかどうか
 ◦ 正常に動作
 ◦ 各レイテンシーが目標値以下
 ◦ エラーが０である事
 • 目標リクエスト数(新春セール*1.4)の各システム必要負荷を見積もれる事
 • リリース時に各システムのリソースが見積もれる
 • ボトルネックが把握できる
 • Direct Connectの帯域の不足がないか
 33
34. © ZOZO, Inc. 負荷試験について
 リクエスト数算出・目標値の決定
 • リクエスト数はSplunkを利用して見積もる
 ◦ 既存のWebサーバーのアクセスログからリクエスト数を抽出
 ◦ 秒間リクエスト数を見積もる
 • リクエスト数を抽出するターゲット
 ◦ セールイベントが無い土日平日
 ◦ ZOZOWEEK
 ◦ 新春セール
 • レイテンシはSLOの値をもとに目標値を決定
 
 34
35. © ZOZO, Inc. 負荷試験について
 シナリオ作成
 • 対象エンドポイントの洗い出し
 ◦ バックエンドチームとフロントエンドチームに確認
 ◦ まとめる
 • シナリオの内容に関して詳細すり合わせる
 ◦ リアルなユーザートラフィックに近づけることができるか
 ▪ パラメーターのパターン
 ▪ ログイン済みでシナリオを実施する
 ◦ リアルなユーザートラフィックを再現しづらい部分は最大req/secで見積もるようにする
 • 実際にアプリケーションを触りながら、挙動を確認しながらシナリオ作成をする
 
 35
36. © ZOZO, Inc. リリースについて
 リリースフロー
 • 案件の進捗を5段階に分類しその工程ごとに必要な確認事項を定めるもの
 ◦ 企画
 ◦ 設計
 ◦ 開発
 ◦ テスト/負荷試験/脆弱性診断
 ◦ リリース前 ~ リリース後
 • 関係各所との調整漏れやセキュリティリスクの露呈による手戻りを回避するため
 36
37. © ZOZO, Inc. リリースについて
 • セキュリティ
 ▪ 適切なアクセス制御がされている
 • CI/CD
 ▪ ステージング、カナリア、本番のフェーズを備え た CI/CD パイプラインがあるなど
 • 障害試験
 ▪ デプロイ時に瞬断しない/安定稼働を担保する ためのヘルスチェックなど
 • 負荷試験
 ▪ Podの見積もり/線形スケール可能/1Podあた りのスループット見積など
 37 • 監視
 ◦ PagerDuty/メトリクス可視化/アラート通知など
 • 障害予防
 ◦ Botのアクセス対策など
 • ドキュメント
 ◦ サービス/オンコールガイド/オンボーディングガイ ドなど
 • レビュー
 ◦ チームレビューの実施/テックリードレビューの実施
 プロダクションレディチェックリスト
 

38. © ZOZO, Inc. • SRE部のプロジェクト体制
 • プロジェクトの進行
 • フロントエンドリプレイスのインフラについて
 • まとめと今後の展望
 38 アジェンダ

39. © ZOZO, Inc. まとめ
 • オンプレミスとモノリスなアプリケーションの運用からEKSを利用したNode.jsのアプリケーションの運 用に取り組むようになった
 • 全く知識がない状態からペアプロ・モブプロの実施を通して技術トランスファーを行いクラウドの運 用やリリースまでに必要なタスクを実施することができる
 • Ph1しかまだ終わっていないのでこれからの運用に向けて更にスキルアップしていく必要
 39
40. © ZOZO, Inc. まとめ
 
 40 As Is To Be オンプレ or リプレイスで 分かれていた組織及び役割 目指すマイクロサービス化及び プロダクトに沿った組織へ 管理するインフラも リプレイス先を見据えた形に変更 ZOZOSREとPF-SREで異なる ポリシーやルール SRE部の統一的なルールや ポリシーを策定しギャップを解消 人員の移動や加入などより容易にし オンボーディングのストレスを解消する 今までのチームで閉じたインフラ情報 可視化と透明性を担保し インフラやサービスの理解度を向上 SRE部のエンジニアが 管轄するインフラを理解し リプレイスを促進する 強い内製組織を目指すために
41. © ZOZO, Inc. 今後の展望
 • Node.jsのマルチプロセス化
 ◦ c6a.4xlargeにインスタンスタイプを変更予定
 • オンプレのリソースの最適化
 ◦ オンプレへのトラフィックが減少していくのでWebサーバーのリソースを調達する必要がなくなる
 ◦ AWSへ移っていくことでオンプレの運用コストも減少する
 ◦ オンプレのリソースを調整できる仕組みを検討
 • ZOZOSREのブロックでの運用
 • 継続的な負荷試験を行う仕組み
 ◦ 早期ボトルネックの発見
 
 41