「AWSアカウントを渡せば終わり」の案件が、丸ごと引っ越しになった話

以前、音楽ライブ中継サイトの移行案件を担当したことがある。

すでに運用されているサービスを、別の会社に引き渡すという案件だった。

プログラムの変更は一切なし。

機能追加もなし。

やることは、システムをA社の環境からB社の環境へ移すだけ。

期間は3ヶ月、体制は私1名である。

こう聞くと、簡単な仕事に思えるかもしれない。

技術的には、実際そうだった。

本来なら。

技術者の正解は「譲渡」だった

AWSには、アカウントごと管理を移す方法がある。

システムが載っているAWSアカウントを、そのまま先方の管理に付け替えればいい。

サーバも、データベースも、ドメインの設定も、何一つ動かさなくて済む。

サービスは止まらない。

移行リスクは、ほぼゼロ。

作業は事務手続きが中心で、エンジニアの出番はわずかである。

私は最初、当然そうなると思っていた。

見積もりの頭の中では、この案件はすでに終わっていた。

ビジネスの正解は「コピー」だった

ところが、打ち合わせを重ねるうちに、雲行きが怪しくなってくる。

「アカウントの譲渡は、ちょっと難しいんです」

詳しい事情は、ここには書けない。

書けないというより、正直に言えば、私にも全部は分からなかった。

契約の都合。

経理の都合。

アカウントに紐づく、いろいろな都合。

会社と会社の間には、エンジニアからは見えない配管が、たくさん通っているのである。

とにかく結論はこうだった。

アカウントは渡せない。中身だけ、新しいアカウントに作り直してほしい。

つまり、引っ越しである。

家ごと渡せば済むところを、家はそのままに、間取りも家具も配線もそっくり同じ家を隣に建てて、住人だけ移す。

技術的には何も生まない、完全な回り道だ。

正直、最初は「なんてめんどくさい話だ」と思った。

回り道の3ヶ月

こうして私は、動いているシステムの完全コピーを作ることになった。

まず、既存環境の調査から始まる。

EC2、CloudFront、ALB、Route 53、Redis、RDS、S3。

構成図はあったが、例によって、現物と微妙に違う。

長年の運用で手作業の変更が積み重なり、設定は「生きた環境の中」にしか存在しなかった。

私はそれを一つずつ掘り起こして、Terraformのコードに書き起こしていった。

セキュリティグループの謎のルール。

誰が設定したのか分からないリダイレクト。

なぜか本番だけ違うインスタンスサイズ。

一つひとつ、「これは意図か、事故か」を判断しながらコードにしていく。

環境のコード化とは、システムの身辺整理である。

そして新アカウントにTerraformを流し、同じ環境を立ち上げる。

データを移し、動作を確認し、最後にDNSを切り替える。

ライブ中継サービスなので、切り替えの失敗はそのまま放送事故につながる。

1名体制の静かな部屋で、切り替えの瞬間だけは、さすがに手が汗ばんだ。

サービスは、止まらなかった。

めんどくささが残したもの

案件が終わってから、気づいたことがある。

この回り道は、無駄ではなかった。

移行前のシステムは、手作業の積み重ねでできた、再現不能な一点物だった。

移行後のシステムは、Terraformのコードから何度でも再現できる。

環境が壊れても作り直せる。

検証環境も同じコードから作れる。

次にまた「引っ越してくれ」と言われても、今度は数日で済む。

ビジネスの都合による回り道が、結果として、システムを一点物から工業製品に変えたのである。

あのとき「アカウント譲渡で終わり」だったら、この資産は生まれなかった。

再現不能な一点物のまま、次の会社に渡っていただけだ。

「めんどくさい」は、たいてい仕様である

エンジニアを長くやっていると、この種の話には何度も出会う。

技術的な最短ルートがあるのに、ビジネスの事情で通れない。

正論を言いたくなる。

「アカウントを渡せば終わりですよ」と。

昔の私は、実際に言っていた。

今は、少し違う考え方をしている。

契約や経理の都合は、エンジニアから見えないだけで、向こうの世界では立派な制約条件である。

つまり、あれは「めんどくさい話」ではなく「仕様」なのだ。

物理サーバの性能に文句を言っても仕方がないのと同じで、ビジネスの配管に文句を言っても仕方がない。

仕様なら、その中で最善の設計をするだけである。

そして不思議なもので、仕様だと思って取り組んだ回り道は、あとから振り返ると、意外と何かを残してくれている。

もっとも。

切り替え作業の夜、汗ばんだ手でDNSを書き換えていた自分が、そんな悟った顔をしていたかどうかは、また別の話である。