IVRyでは昨年、サービスが稼働しているインフラをAWSの共有VPCから独立したVPCへ移管しました。この記事では、移管を実施するに至った経緯と、移管当日の話を紹介します。
インフラ移管の経緯
2年前の2020年8月に開発を開始したIVRyは、当時運営していた他サービス（snapu! など）とVPCを同居していました。IVRyが凄い勢いで成長したことから、会社としてもIVRyに注力することを決めました。そうしてリリースから1年後である、2021年8月に重い腰をあげ、独立したVPCへ移管すべく、インフラ移管の計画を進めはじめました。
本インフラ移管の目的は、今後のサービスの爆発的成長やアジリティの高い開発力を作り続けることを目的としたものでした。しかし、事業成長の真っ只中に、インフラ移管を行うことは、以下のメリット・デメリットがありました。※ インフラ移管に伴って、合わせてインフラ構成も一部変更しています。
移管のメリット（狙い）
- 利用者が突然増えた場合のスケーラビリティの向上
- インフラ構成の追加、変更する際のメンテナビリティの向上
- セキュリティの向上
移管のデメリット
- 移管にかかる開発コスト
- 機能開発の停滞
上記の整理を行い、メリット・デメリットを比較検討するとかなり難しい意思決定でしたが、以下の移管しないことのリスクを含め、統合的に検討した結果、プロダクト開発ベースの意思決定を行うことができました。
移管しないことのリスク
- 短期リスク
- スタートアップ事業は、突然トラフィックが増加するリスク
- 中長期リスク
- SaaSの特性上、機能・顧客数・トラフィック数は増え続ける性質であるため、スケーラビリティが低い構成を後で移管することの後回しリスク
- 電話の特性上、土日や深夜時間帯の停止がしづらく、実施タイミングが遅れれば遅れるほど移管しづらくなるリスク
また、この移管計画に対し、新規機能開発の遅延・停滞をカスタマサクセスチーム（IVRyでは、セールス部署も含めた部署をカスタマサクセスと呼んでいます）が理解してくれ、その間も事業を伸ばし続けてくれたことは、背中をあずけるチームとして大変心強く、開発チームとしても1日でも早く実装を完了したいという、大きな推進力になりました。
移管方針
一般的にプロジェクトにおいては、QCDマネジメントが大変ですが、そのバランスが悪くならないように、今回の移管に関する方針は、以下の3つを決め、それに伴った準備や計画を進めました。
※ 制約条件と目的を整理して、全体の行動方針がぶれないようにすることで、説明コストや無駄な仕事が最小化できると思ってます
- 手順を細かくタスク化し、切り戻し基準、切り戻し判定と対策前進のタイミングを明確に定義し、クライアント影響の極消化すること
- 移行準備から検証を進めるタイミングに発生する機能開発を凍結する期間を可能な限り短くすること
移管作業（準備編）
アーキテクチャ変更
当時のインフラは、初期の開発者がの得意なAWSサービスを利用して、速度優先で開発していたこともあり、EC2を利用しておりましたが、今回の移管のタイミングでスケーラビリティ・セキュリティの観点でECSを採用しました。
その他にも、GA（Global Acceslerator）やCloudTrail等、比較的容易に導入でき、効果が大きいと思われるものを新たに導入しましたが、本論ではないため、ここではこの程度にしておきます。
IaC （Infrastructure as Code）
移管前までは、インフラの構築や設定をAWSコンソールから、手動で行っていました。
SaaSの性質上、より安全により高速にデプロイしていくことが、年々求められていくことがわかっていたので、今回のインフラ移管で、IaCを合わせてやってしまうのが良いだろうと判断し、Terraformでインフラを管理することとしました。
上記のアーキテクチャ変更の方針に従い、より良くより早く行うため、Terraformを利用して、実際に触れる検証環境におき、検証と修正を繰り返しました。
移管作業（当日編）
1回目の移管作業
前述の通り検証環境で入念に確認し、万全を気して当日を迎えました（つもりでした）
我々は、移管作業が終わったら、みんなでビールを飲む気持ちまで準備してありました。
しかし、移管は失敗に終わりました。
なぜ失敗したのか？
事前検証の結果、切り戻しとバッファを含めて、5時間あれば問題ないことを確認し、移管作業は、電話の着電数とWebへのアクセス数の少ない曜日の夜間帯に実施し、当日は、サービス停止も行い、インフラ移管作業を開始しました。
当日は、サービス停止し、インフラ移管作業を開始しました。
作業開始後、Redisのインスタンスが起動と停止を繰り返すなどのトラブルはありつつ、その場で調査・対応しながら進めていました。
しかし、DNS変更したivry.jpへのアクセスがいつまでも新環境へ到達しないというトラブルが発生してしまい、結果としてはこのトラブルにより切り戻しを決断しました。
DNS更新失敗
移管前日に、以下のようにTTLの設定を確認し、当日を迎えていました。
Route53に定義されているNSのTTLを60秒に変更しておけば、ドメインを取得したサービス（今回はお名前ドットコム）に登録されているNSの変更も60秒ほどで切り替わる想定でした。
$ nslookup -debug ivry.jp
Server: 2409:10:a5e0:53f0:6ab:18ff:fe59:212f
Address: 2409:10:a5e0:53f0:6ab:18ff:fe59:212f#53
------------
QUESTIONS:
ivry.jp, type = A, class = IN
ANSWERS:
-> ivry.jp
internet address = 13.35.49.9
ttl = 60
-> ivry.jp
internet address = 13.35.49.79
ttl = 60
-> ivry.jp
internet address = 13.35.49.102
ttl = 60
-> ivry.jp
internet address = 13.35.49.123
ttl = 60
世の中、そんなに甘くない（笑）
当日、満を辞して、お名前ドットコムのNSの値を変更し、数分待ちましたが、あえなく旧環境へリクエストが行き続けました。
まさにカイジのぐにゃあ状態。
失敗した設定
移管先となる新環境の構築（Terraformのapply作業）や、RDS、DynamoDBなどのデータ移行で、5時間のメンテナンス時間中、半分以上時間を消費している状況。
対応方法がわかったときは、切り戻し判定のタイミングになってしまったので、1回目のインフラ移管はタイムアップ。
翌日、昼間に検証し、問題ないことを確認すると、その翌日には再度移管を実施することに。移管作業失敗の2日後に再度移管作業を実施するスピード感は、凄かった。
そして、2回目は、無事に予定時間内に移行を完了することができました。
成功した設定
1回目の移管失敗時の事や、その後の事
1回目の移管失敗の帰宅時、一緒に立ち会ってくれたカスタマサクセスの方が、スラムダンクの山王の堂本監督が言った
「負けたことがある」というのが、いつか大きな財産になる
というシーンの画像とともに
「負けてないけど、良い一日でしたね。開発の皆様お疲れ様でした。」
というメッセージをくれたときは泣きそうになりつつ、もっともっと頑張らないと、という気持ちになりました。
2回目の移管作用実施後、深夜作業に付き合ってくれた仲間と飲んだビールの味は忘れられない味になりました。
移管後についてですが、移管の影響による障害がなかったことは驚きでした。
一度は切り戻しを行い、移管作業は2回実施しましたが、ここまで綺麗に移管できたのはエンジニアだけでなく、一緒に徹夜してくれた仲間、機能開発の停滞などを許容してくれた仲間たちに感謝です。
最後に
今回、インフラ移管という大きなプロジェクトを数名の体制で実行し、IVRyや私にとって新しいチャレンジや気付きを得て、チームとして個人として大きく成長することができました。
今のIVRyは、サービスが成長している真っ只中で、一緒に成長できる仲間や背中を預けられる仲間がいることの楽しさを感じられて、本当に良い環境だと思います。
最近、新たにすごいスキルを持ったエンジニアも入ってきており、より面白く・よりチャレンジングな経験ができそうで楽しみです。
エンジニア募集しています！
このようなのインフラを管理するインフラエンジニアを筆頭に、サーバサイド、フロントエンドのエンジニアを募集してます。成長力（1年ちょいのIVRy成長の軌跡）は凄いですし、将来性（3億円の資金調達）もあるので、興味がある方、是非。
オープンポジションでの募集もしています！
エンジニアに限らず、オープンポジションでの募集も行っております。少しでも興味を持ってくださった方はぜひ、以下のリンクよりご応募ください！
MeetyでRails談義しませんか？
Railsで開発し始めて10年ほどですが、まだまだわからないことや、みんなどうやってるんだろうってことがたくさんあります。カジュアルに、Rails談義しませんか？島筒の最近の困りごとは、ECSでのジョブ管理です。
Discussion