【ITニュース解説】How I Migrated a Production Platform from DigitalOcean to AWS With Zero Downtime

このニュースは、クラウド費用比較ツール「Compare Cloud Costs」の開発者が、自身のサービスを運用していたDigitalOceanからAmazon Web Services（AWS）へ、サービス停止なしで移行した経験を解説するものだ。

サービスをDigitalOceanで立ち上げた当初は、App PlatformやManaged PostgreSQLといったシンプルなサービスが、一人での迅速なプロトタイプ開発とサービス開始に役立った。しかし、サービスが成長し、27,000件以上の価格情報や複雑なクラウド構成図の解析を扱うようになると、DigitalOcean環境では限界が見え始めた。これは、固定された性能プランしかなく、急なアクセス増への自動対応やデータ量増加への柔軟な拡張が難しいという問題だった。サービスの成長にインフラが追いつかなくなったため、より柔軟に拡張できるAWSへの移行を決断したのだ。

移行先のAWSでは、サービスの構成を大幅に刷新した。ウェブサイトの見た目や動きを担当する「フロントエンド」は、Next.jsで開発されたものを、AWSのウェブアプリホスティングサービス「Amplify Hosting」で動かし、「CloudFront」で世界中のユーザーに高速にコンテンツを配信する仕組みにした。サービスの根幹となるデータ保管場所である「データベース」は、DigitalOceanの固定スペックPostgreSQLから、AWSの「Aurora Serverless v2」へと変更した。これは、アクセス量に応じて自動的に性能を上げ下げできるサービスで、普段はほとんど動いていない状態でも、必要な時に瞬時に起動し、アクセスがなくなれば自動的に停止する。AIを使った複雑な分析処理には、AWSの「Bedrock」という生成AIサービスを活用した。また、データの収集や解析といった裏側の作業は、普段は停止していて、必要な時にだけ起動して処理を実行する「ECS on Fargate」というコンテナサービスに置き換えた。これにより、必要な時だけコンピューティングリソースを利用し、使わない時はコストを抑えることが可能になった。インターネットの住所録のような役割を果たす「DNS」は、DigitalOceanからAWSの「Route 53」へ移管された。

今回の移行で最も重視されたのは、サービスを停止させない「ゼロダウンタイム」での移行だった。そのためにいくつかの戦略が取られた。まず、「デュアルライト」という方法で、価格情報を収集するシステムが、移行前のDigitalOceanのデータベースと、移行先のAWSのAuroraデータベースの両方に同時にデータを書き込むようにした。これにより、両方のデータベースが常に同じ最新のデータを持つ状態が保たれた。次に、ウェブサイトの住所を示すDNS情報の有効期限（TTL）を非常に短い60秒に設定した。これは、後で新しいAWSのサーバーに切り替える際、できるだけ早く変更がインターネット全体に反映されるようにするためだ。そして、DNSの切り替え時には、「Route 53」の「重み付けルーティング」という機能を使って、少しずつアクセスをAWS側に振り分けていった。つまり、AWS側で問題が起きてもすぐにDigitalOcean側に戻すことができ、ユーザー影響を最小限に抑えられた。最終的には、すべてのデータが正確に移行されたことを確認するため、27,834行ものデータについて、行数だけでなく内容が完全に一致するかを「チェックサム」で細かく検証した。

この移行の結果、サービスのパフォーマンスは劇的に向上した。特に、データベースへの複雑な問い合わせ時間が、平均120ミリ秒から約28ミリ秒へと3倍以上高速になった。インフラの運用にかかる基本的な費用は月額約100ドルと大きく変わらなかったが、固定料金制から、使った分だけ支払う「従量課金制」に移行したことで、必要な時に必要なだけリソースを利用し、無駄なコストを削減できるようになった。

移行は大きく7つの段階で進められた。まず、AWS上に仮想ネットワーク（VPC）、データベース（Aurora Serverless v2）、セキュリティ設定などを構築する「ターゲット環境の準備」を行った。次に、DigitalOceanのPostgreSQLからデータベースの設計情報（スキーマ）と初期データをAWSのAuroraへコピーする「スキーマとデータの移行」を実施した。続いて、価格情報スクレイパーが両方のデータベースにデータを同時に書き込み、データが常に同期されるようにする「データ書き込みの二重化」を行った。この間もウェブサイトはDigitalOceanのデータベースを読み取り続けた。その後、AWS Amplifyに新しいウェブサイトをデプロイし、ステージング環境のAuroraと接続して問題がないか検証する「フロントエンドの構築とテスト」を行った。次に、事前にDNSのTTLを短く設定した後、DigitalOceanのDNS設定をAWSのRoute 53にコピーし、ネームサーバーを切り替える「DNSのAWSへの移行」を実施。そして、DNSを使って、ウェブサイトへのアクセスをDigitalOceanからAWSのAmplifyへと全面的に切り替える「本番環境への切り替え（カットオーバー）」を行った。切り替え後も、数日間はDigitalOcean側を「読み取り専用」の状態にしておき、万が一の事態に備えた。最後に、問題がないことを確認した後、DigitalOceanの環境を削除する「DigitalOcean環境の削除」を行った。

この移行作業中に、いくつかの予期せぬ困難にも遭遇した。一つは、PostgreSQLの拡張機能に関する互換性の問題だった。DigitalOceanの管理型PostgreSQLに最初から入っていた一部の拡張機能は、Auroraに移行する際に管理者権限がないと動作しなかった。これに対し、データベース設計情報から「所有者情報」を削除し、RDSのマスターロールを通して利用権限を与えることで解決した。また、Aurora Serverless v2は、最低でも2つ（できれば3つ）の「アベイラビリティゾーン（AZ）」にまたがるネットワーク設定が必要だった。これは、AWSのデータセンターが物理的に分かれている場所のことで、複数のAZに分散することで、特定の場所での障害時もサービス停止を防ぎ、冗長性を高めることができる。最初はこの要件を満たしておらずエラーが発生したが、VPCを3つのAZに再設計することで対応した。Next.jsをAmplifyで動かす際にも設定の調整が必要だった。特に、サーバー側で動的なコンテンツを生成する機能（SSR）が動作しない問題が発生したが、next.config.tsファイルやamplify.ymlファイルの設定調整、Node.jsのバージョン指定で解決した。AIサービスであるBedrockを呼び出すための権限が不足している問題も発生した。AmplifyのウェブサイトがBedrockにアクセスするためのIAMロールに適切な権限を追加することで解決した。一部のインターネットサービスプロバイダ（ISP）のキャッシュサーバーがTTL設定を無視し、DigitalOceanにアクセスを送り続ける問題もあった。これには、DigitalOcean側でAWSへのHTTP 301リダイレクトを設定し、古いDNS情報を持つユーザーも最終的にAWS側に誘導されるようにした。Aurora Serverless v2を最小容量0（ACU）で運用すると、データベースが完全に停止した状態から起動する際に数秒間の遅延（コールドスタート）が発生することが判明した。これは、1日の最初のデータ取り込み時に顕著だったため、最小容量を0.5 ACUに設定することで、常にデータベースを温かい状態に保ち、遅延をなくした。この設定による追加コストはごくわずかだった。最後に、ウェブサイトへのアクセスが急増した際、データベースへの接続が多すぎて限界に達する「コネクションプール枯渇」の問題が発生した。これに対しては、Auroraの前に「RDS Proxy」を導入することで、ウェブサイトからの多数の接続要求をRDS Proxyが一元管理し、データベースへの接続数を効率的に制御できるようにした。

今回の移行では、データの損失がないことを徹底的に確認した。行数の比較だけでなく、すべてのデータの整合性をチェックサムで検証し、移行前後で完全に一致していることを証明した。

もし次回同じような移行を行うとしたら、Aurora Serverless v2の最小容量を最初から0.5 ACUに設定すること、そしてDNSの切り替え前にHTTP 301リダイレクトの安全策をあらかじめ準備しておくことを挙げている。それ以外の計画は概ね成功だったと結論づけている。この経験は、将来的に同様のクラウド移行を計画するエンジニアにとって貴重な教訓となるだろう。