310万人以上の会員数を持つサービスのVPCを移行した話

現在「N organic」を愛用してくださっているお客様は約310万人^[1]、2024年で誕生から7年目のブランドとなりました。

https://sirok.jp/norganic

今回は、「N organic」を取り扱っているシロクオンラインショップのRDS,ECS,EC2を含む本番環境のVPCを移行したお話になります。

何をしたか

7年間使っていたVPCから構成を変えて新しいVPCに移行しました。
RDS, EC2, ElasticCacheなどVPC内にあるリソースは全て新しく作り直し、移行しています。

計画

どうやって移行してくかを考えた時に、段階的に移行をしたいと考えました。
何かエラーになったときに、どのリソースに原因がありどのように対処すればいいかがわかりやすくなるためです。

移行するリソースは主にVPC内部にある

• ECS on EC2（Webサーバー、Batchサーバー）
• Aurora
• ElasticCache

の3つでした。

段階的に移行をするため、移行途中では新VPCにあるリソースと旧VPCにあるリソースが共存することになります。
（Webサーバーだけを移行したとき、Webサーバーは新VPCにあり、そのほかのAurora、Batchサーバーは旧VPCにある状態になる）

これを可能にするために、今回はVPCピアリングを用いました。

また、移行してくリソースの順番は

1. ECS on EC2（Batchサーバー）
2. ECS on EC2（Webサーバー）、ElasticCache
3. Aurora MySQL

の順で行いました。（Auroraが一番しんどそうだなと思ったためです。）

最終的な全体的な計画は以下のように行いました。

1. 新VPCを作成し、必要なリソースも新たに全て作成する（ECS on EC2, Aurora, ElasticCache, SQS）
2. VPCピアリングの構築
3. Route53にレコードを作成して新ALBに向ける（移行してお客様に公開する前に新EC2のWebサーバーで動作確認をするため）
4. Batchサーバーの移行
5. Webサーバーの移行
6. Auroraの移行

準備

新VPCを作成

既存のVPCを模倣して、作成。
EC2, Auroraなど必要なリソースも全て新規で作成しています。
今回は全ての既存リソースのIaC化も兼ねていたので、全てterraformで作成しました。

VPCピアリングで新VPCと旧VPCを繋ぐ

VPCピアリングとは

VPC ピアリング接続は、プライベート IPv4 アドレスまたは IPv6 アドレスを使用して 2 つの VPC 間でトラフィックをルーティングすることを可能にするネットワーク接続です。どちらの VPC のインスタンスも、同じネットワーク内に存在しているかのように、相互に通信できます。

https://docs.aws.amazon.com/ja_jp/vpc/latest/peering/what-is-vpc-peering.html

今回は、新VPC内のEC2から旧VPCのAuroraに接続するためにVPCピアリングを使用しました。

Route53にレコードを作成して新ALBに向ける

こちらの目的は、Webサーバーを移行してお客様に公開する前に、社内だけで動作確認を行うためです。
サブドメイン(hoge.sirok.jpのような)を作成し、ALB側で社内VPNのみアクセスできるようにしました。
新EC2は既存のAuroraにread/writeするため本番同様の動作確認ができるようになります。

移行開始

Batchサーバー移行

メンテナンス無しで行いました。

詳細は省きますが、
Batch処理の大まかな流れは

1. CloudWatchのEventBridgeからSQSにタイムメッセージをキューイング
2. タイムメッセージを元にBatchサーバーからJobがキューイング
3. それを再度Batchサーバーが処理をする
   という流れになっています。

また、アプリケーションでの動作に応じてWebサーバーからもJobをキューイングされることもあります。

Batchサーバー移行で行った作業は主に以下の通りになります。

1. 旧バッチで処理しているSQSへのEventBridgeを無効化
2. 新バッチで処理しているSQSへのEventBridgeを有効化
3. Webサーバーからのキューイング先を新SQSに変更

Webサーバー移行

こちらもメンテナンスは無しで行いました。

行った作業は主に以下の通りになります。

1. 新WebサーバーへのALBは社内のみIP許可していたので、その制限を解除
2. TTLを0にしてsirok.jpのホストゾーンのsirok.jp Aレコードのルーティングを新ALBに変更（これで本番環境が実際に新Webサーバーに移り変わる）
3. 旧WEBのタスクを減らす

IAM周りがうまく渡せるかが不安でしたが、無事に動作できて良かったです。
この時点では、Webサーバーからのジョブのキューイングは旧SQSにキューイングして、旧バッチサーバーで処理しています。

Aurora移行

こちらは深夜メンテナンスありで行いました。

Amazon Aurora MySQLでは、クラスターをそのままVPCを移行させる機能がなく、EC2とは異なりデータごと引越ししないといけないため、AuroraのVPC移行が最難関でした。

そのため、今回はDBクローンを使って移行を行いました。

大まかな流れは以下のように行いました。

1. メンテナンス入り
2. DBへのread/writeを全て止める（Web, Batchサーバーのタスク数を0にする）
3. read/writeを完全に無くすためDBのセキュリティグループをメンテ用のセキュリティグループ（ingressが存在しないセキュリティグループ）にする
4. 新VPC内にクローンを作成
5. Webサーバー、BatchサーバーのDBのホストを新しくクローンで作成したDBに変更する
6. タスク数を戻す

大体2時間ほどで完了しました。
スナップショットからの復元よりはクローンの方が圧倒的に時間短縮になるため、クローンを用いました。
これが今年一番のBigなタスクだったため、無事に完了して本当に安心しています。。

まとめ

各サービスのインフラ構成によって、作業内容や計画は異なるとは思いますが、弊社でのVPC移行は以上のような方法で行いました。
Auroraの移行方法はもっと楽な方法がないかと探りましたが思いつかず、もっと安全な方法や楽な方法があれば教えていただけると幸いです。

今回は、実稼働しているサービスのVPCの移行という今後のエンジニア人生でもあまり行うことのなさそうなミッションを経験できました。
失敗したら色々と不都合なことが起きるというハラハラものでしたが、とても良い機会でした。

インフラを触り始めたのは今年の9月頃でしたが、実際にこのようなミッションをやってみると知識も一段階アップするなと感じました。
このミッションでインフラの興味が強まってきたので、もっと学んでいこうと思います！

脚注

1. 2024年4月現在「N organic」会員数