【レポート】ZOZOTOWNにおけるAmazon EKSを中心に据えたマイクロサービスアーキテクチャへの変遷 #CUS-01 #AWSSummit

コンサル部のとばち（@toda_kk）です。

本記事は、AWS Summit Online Japan 2021 にて行われた動画セッション「ZOZOTOWNにおけるAmazon EKSを中心に据えたマイクロサービスアーキテクチャ」のレポートです。

このセッションは、日本最大級のファッション通販サイトであるZOZOTOWNにおいて、モノリシックなシステムをいかにしてマイクロサービスに移行していったのか、またそこでどのようなAWSサービスを組み合わせて利用しているのか、といった内容となっています。

特にAmazon EKSを利用する上で発生する課題について具体的な解決策が述べられているため、利用中もしくは利用を検討中の方にとって非常に有用な情報が得られるのではないかと思います。

セッション概要

"ZOZOTOWNのリプレイス！AWSを利用したマイクロサービスアーキテクチャ設計！"

ZOZOTOWNはサービス提供開始から16年の月日が流れており、現在マイクロサービスアーキテクチャへのシステムリプレイスを進めています。本発表では、リプレイス戦略に加え、具体的にどのAWSサービスをどのように利用しているのか、特にEKSを中心に据えたマイクロサービスアーキテクチャをどのように設計しているのかについて、設計思想も含めて詳細をお伝えします。

スピーカー

株式会社ZOZOテクノロジーズ SREスペシャリスト 瀬尾直利 氏

セッション動画

ZOZOTOWNにおけるAmazon EKSを中心に据えたマイクロサービスアーキテクチャへの変遷 (CUS-01) - Summits JP Production

セッションレポート

アジェンダ

• ZOZOTOWNリプレイス戦略
• Amazon EKSを中心に据えたマイクロサービスアーキテクチャの設計と実践

ZOZOTOWNリプレイス戦略

リプレイス前: 2017年まで

• オンプレミス上でWindows Serverを用いて構築
• SQL Serverにストアドプロシージャを用いてロジックを記述してデータ取得
• 2004年当時はこういった仕組みが全盛であり、最適なアーキテクチャとして選択していた
  • ネットワーク速度が今よりも遅いため、データソースに近い箇所で演算させることでシステム全体を高速化させていた
• クラウドの台頭によって生まれた課題
  • CPUを水平スケーリングして演算処理を増強したいときに、DBを増やさなければならない
  • ストアドプロシージャのテストが書きづらい

「ZOZOTOWN作り直し」

「ZOZOTOWN作り直しにつき職人求む」のワケ：40人の大規模募集 - ITmedia ビジネスオンライン

• モノリスからマイクロサービスアーキテクチャへのリプレイス
  • API Gatewayを利用したStranglerパターンによる切り替え
    • 既存のAPIリクエストを、オンプレミスのWebサーバーからAPI Gatewayに切り替える
    • API Gatewayを経由することで、インターフェースは同じままバックエンドのシステムを変更できる
  • まずはID認証サービス、次に商品サービス、さらに次にお気に入りサービス、メンバーサービス……といったように、徐々に新しいアーキテクチャに切り替えていく戦略

補足: Stranglerパターンとは？

• Martin Fowlerが言及した、レガシーシステムをマイクロサービスに移行するための戦略パターン
• リクエストを受ける前段にインターセプションを置くことで、モノリスなシステムを丸ごと置き換えるのではなく、段階的に移行させていく
• 参考
  • Migrating Monoliths to Microservices with Decomposition and Incremental Changes
  • すごいよ、Strangler Applicationパターン！ 〜 マイクロサービスアーキテクチャの設計パターン 〜 | ふじやまエッグのブリコルール日誌

Amazon EKSを中心に据えたマイクロサービスアーキテクチャの設計と実践

マイクロサービスアーキテクチャをどのように設計してきたのか？

• マイクロサービスプラットフォーム基盤の要件をチーム内で議論して整理する
  • システムが満たしたい性質: 安全性、信頼性、高速性……
  • システムが満たしたい機能: オンプレ・クラウド間の専用線接続、EKSクラスタのバージョンアップ手法の確率、分散トレーシング……
• 要件をAWSのサービスで実現する

ネットワーク設計

• オンプレ・クラウド間の専用線接続
  • Direct Connectを利用したオンプレとAWS間の専用線接続を構築
  • MLデータ基盤はGCPをメインで利用するため、Cloud InterconnectでオンプレとGCP間の専用線接続を構築
  • AWSにシステム移行後、AWSからGCPのMLデータ基盤にアクセスするために、オンプレをハブにしたネットワーク構成となっている
• EKSクラスタのネットワーク
  • External/Internalなエンドポイント（ALB）を両方用意している
    • External ALBには、iOS/Androidアプリからリクエストする
    • Internal ALBには、オンプレミスのWebサーバからリクエストする
  • ALB障害を前提とした3AZ構成
• 環境分離、サービス分離の原則の徹底化
  • dev/stg/prd環境をAWSアカウントで分離、DBを共用しない
  • マイクロサービス間でもDBを共用しない

Amazon EKSの運用設計

• なぜEKSを使うのか？
  • コンテナのメリット: 高い再現性、依存OSも含めたパッケージ化
    • e.g. アプリケーションで必要になったパッケージを、アプリケーションエンジニアだけで管理できる
  • Kubernetesのメリット
    • Amazon ECSに比べて管理する項目は増えるが、OSSの利用など含めて自由度が高い
    • AWSだけでなくGCPも利用しており、Kubernetesのナレッジを全社的に活かせる
  • EKSのメリット
    • コントロールプレーンの運用管理は難易度が高く、マネージドのメリットが大きい

EKSバージョンアップの3つの戦略

1. クラスタマイグレーション
   • 新バージョンのクラスタを新しく作成して移行する
   • 利点: コントロールプレーンのアップグレードや、マニフェストの互換性の考慮など、安心安全
   • 欠点: 毎回やるのは大変
2. In-placeクラスタアップグレード / ノードグループマイグレーション（この戦略を一番採用している）
   • 新バージョンのノードグループを作成して、Podをローリングアップデートすることで移行する
   • 利点: Podのノードグループ移行は日常的に実施している（インスタンスタイプの変更など）ため熟れている方法
   • 制約: ノードグループをDeploymentのaffinityで指定する運用にしていること
3. In-placeクラスタアップグレード / In-placeノードグループアップグレード
   • クラスタもノードグループも、丸ごとIn-placeでアップグレードする
   • 利点: 一番楽
   • 欠点: ユーザー影響が怖い（事前に別環境でのテストなどを実施しておく）

補足: Deploymentのaffinityについて

• PodをスケジュールするNodeを指定する方法として、nodeSelectorとnodeAffinityを使う方法がそれぞれある
• nodeSelectorでは、Nodeに付与されているkey-value形式のLabelからスケジュールするNodeを指定する。このとき、Labelは完全一致として指定する
• 一方、nodeAffinityでも同じくLabelを利用するが、部分一致など柔軟な条件付けが可能となる
• 参考
  • Node上へのPodのスケジューリング | Kubernetes
  • Kubernetes道場 17日目 - Label / NodeSelector / Annotationについて - Toku's Blog
  • Kubernetes道場 18日目 - Affinity / Anti-Affinity / Taint / Tolerationについて - Toku's Blog

モニタリング・監視

• Datadog APMを利用してマイクロサービス分散トレーシングを実現
  • API Gatewayでクライアント識別子を付与している
• アプリケーション監視には、Datadog Monitorを利用
• AWSリソースの監視には、Amazon CloudWatchを利用
  • AWS Chatbotを利用してSlackに通知しているが、メッセージをカスタムできないのが難点（アップデート希望）
• 外形監視
  • Amazon CloudWatch Syntheticsをメインで利用
  • External/Internalでそれぞれエンドポイントがあり、外部からだけでなくAWS内部のネットワークからも外形監視をしたいため
• アプリケーションログの監視と収集
  • Amazon CloudWatch Logs
    • アラートを飛ばしたいログを送る
  • Amazon Kinesis Data Firehose → Amazon S3 + Amazon Athena
    • アラートが必要ないログを送る
• 監査ログ
  • AWS CloudTrail、DBクエリ実行ログ、EKSコントロールプレーンのログ を利用
  • Linux操作コマンド実行のログ取得で工夫
    • EKS Pod内のログ取得にFalcoを利用
    • EC2インスタンス内のログ取得にAWS Systems Manager Agentを利用

カナリアリリース

• マイクロサービスのカナリアリリース
  • API Gatewayの機能として実装した
  • StranglerパターンでモノリスAPIを移行する際にも利用
  • フォールバック機能も自前で実装しており、他社のAPI Gatewayでは見たことがない
    • カナリアでエラーが起きた場合には即座に旧系にフォールバックする機能も実装し、エラーが発生したリクエストを単純にリトライするのではなく確実に旧系に行くようにした
• API Gatewayのカナリアリリース
  • API Gateway自体のカナリアリリースは、ALBの加重ルーティングで実施
• EKS丸ごとのカナリアリリース
  • Route 53の加重ルーティングで実施

Infrastructure as Code および CI/CD

• 全面的に実施している
• CloudFormationとGitHub Actionsを利用

Public APIの保護

• iOS/AndroidからアクセスされるAPIを保護している
• EKSでIngressとしてALBを作成しACMをアタッチ
• API認証、ユーザ認証は自前で実装
• AWS WAFの利用
  • できないこと: 高度なBot振る舞い検知ができない、Rate Limitは最小でも5min、複雑な条件の組み合わせ

サービスメッシュ・サーキットブレーカー

• EKSとGKEで技術共有も考慮して、AWS App Meshではなく、Istioを採用
• Istioが提供する機能
  • タイムアウト、リトライ制御
  • カナリアリリース
  • サーキットブレーカー
• 一部のサービスで導入済み、今後はプラットフォーム基盤全体に広げていく

巨大なサービス運用の知見が詰まったセッション

Stranglerパターンやカナリアリリースの実施も含めたAPI Gatewayを自前で実装していたり、AWSとGCPのマルチクラウドを前提とした設計をしていたりと、興味深い話題が満載でした。

また、EKSを運用し続ける上でバージョンアップはどうしても課題として上がってきます。アップグレードの戦略を整理した上で、AWSサービスや自前実装したリソースを組み合わせて適切な戦略を採用するプロセスが説明されており、EKSを利用中もしくは利用を検討中のチームにとって非常に参考になるのではないかと感じました。

本レポートでは、詳細な内容については記載し切れていないため、具体的に気になる箇所がある方はぜひセッション動画をご覧ください！

以上、コンサル部のとばち（@toda_kk）でした。