はじめに

こんにちは。計測プラットフォーム開発本部SREブロックの西郷です。普段はZOZOSUITやZOZOMAT、ZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。先日私達のチームでは、シングルクラスタ・マルチテナントを前提として構築したEKSクラスタにZOZOMATシステムを移行しました。本記事では移行ステップや作業時に工夫した点について紹介したいと思います。

移行の概要とそのアプローチ

マルチテナントのEKSクラスタに移行した理由は、EKSクラスタが多く存在することで管理コストの高さが目立ってきたためです。

というのも、EKS導入当初はまだ手探りな部分が多かったため、各サービスごとにEKSクラスタを作成していました。しかしながら当初の想定以上にサービスが増えてしまったため、今回単一のクラスタで複数のサービスを運用するマルチテナントのEKSクラスタへ移行するに至りました。

この辺については先だって公開したこちらの記事で詳しく書かれているので、是非併せてご覧ください。

まずは今回の前提と要件を整理します。

前提

• AWSリソースはCloudFormation（以降CFnと記載します）で管理している

要件

• 無停止で切り替えること
• ロールバックが容易であること
• コンピューティングタイプをEC2からFargateに変える

コンピューティングタイプを変える点について少し補足すると、マルチテナント化に伴うマシンリソースの競合および権限の分離や、運用負荷の軽減を目的としたEC2からの脱却が背景にあります。

移行方針

以上を踏まえ、EKSクラスタ間の切り替えについてはマルチテナントのEKSクラスタにZOZOMATリソースを追加した上で、Route 53に設定済みのALBの値を変更しました。図で示すと以下のようになります。

また、ZOZOMATで利用しているAWSリソースについても一部を除いて新しいCFnスタックに新規作成し、管理するCFnスタックを切り替えることにしました。理由は日々の運用作業と干渉せず移行作業をしやすかったことや、リソースの命名則を変更したかったためです。各AWSリソースのスタック間での移行方針はリソースごとに異なるため、わかりやすくまとめると以下のようになります。

EKSクラスタ 既存のマルチテナントのEKSクラスタを利用
FargateProfile IAMRole等 新規作成
CodePipeline CodeDeploy CodeBuild 新規作成
ECR 新規作成 作業時点でCFnのResource Importが未対応だったため。1世代分のイメージのみ移行
Redis 新規作成
DynamoDB Resource Import
RDS Snapshotを元に新規作成＆データ同期
S3 新規作成＆データ同期

そもそものZOZOMATの構成については以前の記事に詳しく書かれているので、興味がある方は是非そちらをご覧ください。

まとめると、今回の移行のポイントは以下のようになります。

• ZOZOMATが利用するEKSクラスタをマルチテナントのEKSクラスタに切り替える
• 付随して、ZOZOMATが利用するAWSリソースも新しいCFnスタック管理に切り替える

各移行ステップとその詳細

今回の移行作業は大きく4段階に分けて行いました。

STEP1:移行先CFnスタックへのAWSリソース作成、インポート
STEP2:移行先へのデータマイグレーション
STEP3:移行先のEKSクラスタにkubernetesリソースを追加
STEP4:EKSクラスタの切り替え

ここから先は各ステップについて、工夫した点や注意点を交えて説明いたします。

STEP1:移行先CFnスタックへのAWSリソース作成、インポート

まずは前述のとおり、新しいCFnスタックに必要なAWSリソースを作成していきます。

ECRは、この作業を行なった2021年5月時点ではCFnのResource Importに未対応でした。そのため、既存のECRを一度削除して再作成し、あらかじめ取得しておいた最新1世代分のイメージをpushすることにしました。現在はResource Importに対応しているようです。

DynamoDBは命名則の修正が必要なく、Resource Importも対応していたため、既存のテーブルをそのまま新しいスタックにインポートしました。

移行の流れをわかりやすくするため、現時点の状態を図で示します。

STEP2:移行先へのデータマイグレーション

このステップでデータのマイグレーションが発生するデータソースはRDSとS3です。まずはZOZOMAT環境に存在するデータソースとその中に含まれるデータについて簡単に説明します。

続きはこちら