AWS FargateからCloud Runへ。Cloudflareを中心とした「堅牢かつ低コスト」な移行戦略

ツール導入前の課題

私達のサービスは、AWS Fargate環境で稼働していました。 しかし、Fargateの手前にBFFに相当するLambdaがAPIエンドポイントごとに存在するなど、複雑なアーキテクチャによって開発者体験が悪く、トラブルシューティング時のログも分散していて運用負荷も高い状態でした。Fargate自体へのデプロイに10分以上要すことからCI/CDのパイプラインのコストにも響いていました。 また、セキュリティへの対策が後手に回っていたこともあり、何かが起こる前に手を打つべき状況でもありました。

大きなタスクとしてはFargateからCloudRunへの移行でしたが、それに伴って複雑化したLambdaの整理、セキュリティの対策をCloudflareに任せるという部分がこの話の趣旨になります。

どのような状態を目指していたか

インフラエンジニアが常時張り付かなくても、冗長性やスケール性能、セキュリティなどがある程度担保され、アプリケーションの変更がスムーズにデプロイされるなど、プロダクトの運用ができる状態。

• CloudFront
• Cloudflare

• コスト効率: 利用に関する料金がほぼかからないこと
• セキュリティ機能: デフォルトの設定でDDoS対策及び十分なルールのWAFがあり、複雑な設定なく導入できること
• エッジでの柔軟な処理: 移行期間中のパス書き換えや、将来的な認証連携など、エッジでロジックを実装できる柔軟性があること。
• 開発体験とデプロイ速度: デプロイが高速であり、アプリケーションエンジニアが扱いやすい簡潔な設定であること。

• 最終的にCloudflareを選定した決め手は、「優れたコストパフォーマンス、Workersによる柔軟なカスタマイズ、高いセキュリティ機能の両立」でした。

• Workersによる高い柔軟性: Workersのシームレスなデプロイ体験と、Honoを用いたモダンな開発体験が、複雑化したLambdaの整理に役立ち、今後の開発体制に不可欠だと判断しました。

• セキュリティ: WAF、DDoS対策、オリジン保護をまとめてCloudflareに任せられるという安心感がありました。DNSも合わせて使用することで、Cloudflare内のセキュアなネットワークを利用することが出来ます。

• デプロイ時間が約15分から約1分に短縮しました。Cloudflareに限れば数秒です。
• セキュリティ面ではCloudflareによってDDoSなど一般的な攻撃への耐性が大幅に向上しました。

• Cloud Runのオリジン保護設計: 今回Google CloudのLoad Blancerを使用しなかったため、Cloud Runのデフォルトドメイン（*.run.app）への直アクセスを防ぐためのセキュリティ設計を自前で構築する必要がありました。

• DNS設定と移行の順序: AWSからGoogle Cloudへの移行と同時にCloudflareへDNSを移管する必要があり、ダウンタイムを最小限に抑えるように慎重に計画しました。

Cloudflareは非常に使いやすいサービスです。DNSやCDNだけでなくWorkersへのアプリケーションのデプロイは大変強力です。AI機能の拡充やZeroTrustの活用など、低コストで多くの恩恵を受けられます。

アプリケーションをTypeScriptで書き直すなどすれば、エッジコンピューティングのスケールメリットを活用でき、プロダクトの安定運用に繋がるばかりでなく、Cloudflareのシームレスなデプロイによって開発体験をさらに向上させたいです。