HerokuからAWSへの無停止移行：月間1,400万ドルの決済を処理しながら

このクライアントは、米国とカナダの約900の中小規模の加盟店向けに、月間約1,400万ドル、180,000件以上の取引を処理しています。プラットフォーム全体が、Heroku上の単一のRuby on Railsアプリケーション（モノリス）として動いていました。このアーキテクチャが、事業の最大の制約になっていました。

問題は数字で表せました。デプロイのたびに38分かけて全体を再起動する必要があり、実施できるのはメンテナンス時間帯の週2回だけでした。過去にはデプロイの失敗でピーク時間帯に47分間の障害が発生し、約$62,000分の取引が失敗しています。Herokuでは構成要素を個別にスケールできないため、月末にレポート処理が集中すると、アプリケーション全体をスケールさせるしかありませんでした。費用は月額$14,200に達し、毎月8〜12%のペースで増えていました。さらに、どこか1か所の不具合が全体を止めるおそれがありました。実際に、レポート機能の書式エラーが決済キューを23分間停止させ、大口の見込み顧客2社を失ったことがあります。

CTOが示した条件は絶対のものでした。移行のための停止時間は設けない。加盟店から見える影響は出さない。移行は、稼働中の決済トラフィックの裏側で進める必要がありました。

最初に$6,000のインフラ診断を行いました。約85,000行のRailsコードベースを確認し、47テーブルのスキーマ（うち12テーブルは100万行超）を整理し、リクエストをトレースしました。その結果、月末にはレポートのクエリがデータベースCPUの60%を消費している一方で、決済処理そのものはp99で340msで動いていることがわかりました。当社はストラングラーフィグ・パターンを提案しました。サービスを1つずつ切り出し、新旧を並行稼働させ、トラフィックを段階的に移す方法です。切り出す順序はリスクの低い順に、通知、レポート、オンボーディング、Webhook、そして最後に決済の中核としました。

3〜4週目は、切り出しを始める前に基盤を整えました。AWSのリソースはすべてTerraformで定義し、GitHub ActionsによるCI/CDにセキュリティスキャンとEKSへのブルーグリーンデプロイを組み込みました。Datadogによる監視基盤も先に導入し、新旧システムの差異を数秒以内に検知できるようにしました。

5〜8週目に、リスクの低い部分を切り出しました。通知サービスは5日間の並行稼働で差異率0.00%を確認してから切り替えました。レポートをリードレプリカに移したところ、プライマリデータベースのCPU使用率は78%から31%に下がり、副次的な効果として決済のp99レイテンシも340msから180msに改善しました。決済の中核は最後に、最大限慎重に移行しました。まず48時間のシャドートラフィックで12,000件の取引を検証し、差異率0.00%を確認しました。その後、10日間かけてトラフィックを1%から100%へ段階的に移し、各段階でテスト済みのロールバック計画を用意しました。14週目は、運用手順書の整備、知識の引き継ぎ、3時間の障害注入演習（ゲームデー）で締めくくりました。

移行後の90日間を、移行前の90日間と比較した結果です。デプロイ時間はサービスあたり38分から2.5分に短縮（-93%）、デプロイ頻度は週2回から週18回に増加（+800%）、月額のインフラ費用は$14,200から$9,230に減少（-35%）、決済のp99レイテンシは340msから145msに改善（-57%）、月末のレポートクエリは12〜45秒から2〜8秒に短縮（-82%）しました。計画外のダウンタイムは、移行前の70分からゼロになりました。移行作業中のダウンタイムもゼロです。

同社の取引量は四半期ごとに15%増えており、Herokuのままでは年末に月額$22,000に達する見込みでした。AWSの構成では、同じ取引量で月額$11,500の見込みです。その差は年間$120,000以上で、取引量が増えるほど広がります。インフラ費用の削減だけで計算しても、$74,000の移行費用は14.8か月で回収できます。1回あたり$62,000の損失につながる障害のリスクがなくなった効果は、この計算に含めていません。

クライアントは、GigabitのDevOpsエンジニア1名と月額$5,500のSRE継続契約を結んでいます。現在のロードマップには、マルチリージョン展開、リアルタイムの不正検知パイプライン、SOC 2 Type IIに対応するインフラが入っています。