初めに
こんにちは。クラウドワークスのエンジニアをしているu2_cwです。
普段はクラウドワークス テック・クラウドワークス エージェントの開発を行なっています。
今回は、そのサービスのアプリケーションで利用しているインフラである HerokuとAWS のリージョンを東京リージョンへ移行した際に起こった問題について共有しようと思います。
なぜやったのか
目的はパフォーマンスの向上です。
移行前は海外リージョンだったため、物理的に遠く応答速度に時間がかかってしまいレスポンスが遅くなっていました。
そのためレスポンスが少しでも早くなるように今回のリージョン移行を行いました。
やったこと
Heroku
アプリケーションを動かしているHerokuですが、通常のCommon Runtimeの場合、USリージョンもしくはEUリージョンのみが利用可能なので、東京リージョンにするにはPrivate Spaces Runtimeを利用する必要があります。
そのため今回の移行ではCommon RuntimeからPrivate Spaces Runtimeでアプリケーションの環境を構築しました。
AWS
アプリケーションが接続しているAWSの各種サービス（S3/RDS）ですが、こちらもリージョンを東京リージョンに変更しました。
事前準備
事前準備として大きく分けると以下の2点になります。
HerokuのPrivate spaceでアプリケーションの環境を構築
AWSのS3やRDSなど東京リージョンで用意
HerokuのPrivate spaceでアプリケーションの環境を構築
前環境で使用していたAdd-ons（Heroku scheduler、Fastly、Redis、Memcached、PaperTrailなど）を新しい環境に追加し、設定のコピーをしました。
ここは何も考えずに左から右に写す感じです。
アプリケーションのコードはGitHubで管理していて、CIはCircleCIを利用しているので特定のブランチにマージされたら自動でデプロイされるように設定しました。 これも既存の環境が既に存在しているので、そちらを参考にするだけでした。
AWSのS3やRDSなど東京リージョンで用意
以前はマネジメントコンソールで画面上で操作してインスタンスの作成などを行なっていました。
チームで会話している中でエンジニアなのでコードで管理したいよねとなり、今回の移行ではTerraformを利用して環境構築していくことになりました。
リリース
リリースは一度にリリースするのではなく、段階的にリリースしていくことにしました。
その方が万が一が起きた際に切り戻すのも簡単に出来るだろうという判断でした。
第1段階
DNSの管理をPointDNSからAWSのRoute 53に変更
第2段階
Herokuで使っているFastlyを新しいHerokuアプリケーションに移す
Heroku Common RuntimeのHerokuアプリケーションに紐つくFastlyアカウントからHeroku Private Spaces RuntimeのHerokuアプリケーションに紐つくFastlyアカウントへ移行しました。
この段階ではアプリケーションの移行はまだ行っていないので、Fastlyからリクエストが流れてくるバックエンドのアプリケーションはHeroku Common Runtimeで稼働中のアプリケーションになります。
第3段階
アプリケーションをHeroku Common RuntimeからHeroku Private Spaces Runtimeに変更
アプリケーションが参照するAWSのS3/RDSのリージョンを東京リージョンに変更
以上３段階を経て移行を完遂する予定でした。
起こったこと
「There's nothing here, yet.」のエラー
第2段階のリリース中、Fastlyを新規Heroku Private Spaceに設定したFastlyに移行した際に発生しました。 Heroku Private Space の東京リージョンにおいたアプリケーションに関連づけられたFastlyアカウントから既存のHeroku Common Runtimeで動いているアプリケーションへリクエストが流せていない感じでした。
原因究明のため、移行完了後にHerokuのサポートに問い合わせをしたら「FastlyのHostの設定に問題がある可能性が高いと思われます。」と言われました。
ただ、移行前に旧Fastlyアカウントの設定と新Fastlyアカウントで設定に差分はないようにしていたので、何が間違っているのかが分からずでした。
リリース時には原因がわからずロールバックをする事にしました。
Fastlyのアカウントを旧環境に戻せない
上記、「There's nothing here, yet.」の問題が起きた際にロールバックするためFastlyのアカウントを旧環境に戻そうとしました。
しかし、Fastlyは複数アカウントで同一ドメインでの設定は出来ない仕様であり、アカウントから違うアカウントへドメイン設定を移行するにはドメインの移譲の手続きが必要でした。
旧Fastlyアカウントから新Fastlyアカウントへ移行する際にドメインの移譲の手続きは行なっていたのに戻す際に必要だということはすっぽり抜け落ちていました。
事前に旧Fastlyアカウントから新Fastlyアカウントへのドメイン移譲の手続きをしていたので、
旧Fastlyアカウントの設定が生きている状態で、新しいFastlyアカウントにドメインの設定ができる状態となっていたためドメインの移譲をしなくても戻せるという認識になっていました。
この思い込みが今回の大きな問題でした。
暫定対応
このままではサービスが利用できない状況になってしまうので、暫定対応を行なうことにしました。
対応としては上の画像のイメージの通りで、RDSやS3のみ旧環境を参照するように変更しました。
急遽段階リリースを諦め、全てをリリースをすることに
Fastlyのアカウントが戻せないとなった時点で旧環境に直ぐに戻すことは難しく前に進むしかなくなりました。
そんな状況でチームで話し合った結果、後日対応予定だった第3段階のHerokuアプリケーションのリージョン移行とAWSのリージョン移行を急ピッチで進めることになりました。
幸いチームメンバー含め色々な方が協力的に動いてくれたので、リリースの前倒しもスムーズに進めることが出来ました。
大変だったこと
Herokuのエラー
一番大変だったのはFastlyの移行時に起きたHerokuのエラーです。
そこまで順調に移行できていたのに画面に「There's nothing here, yet.」とだけ表示され正常にサイトが確認できない状況になりました。
解決手段もわからずだったので、生きた心地がしませんでした。
Heroku/AWSの知見が少ない
HerokuについてやHerokuのAdd-onsについて、また、AWSのサービスについて自分含めてチームメンバーの知見が少なく、何をどうすればいいのかがわかっていませんでした。
Terraformの知見が少ない
チームでの知見が無いに等しく、ゼロからのスタートだったので問題によく直面して躓くことが多かったです。
幸い社内には詳しい方がいたので、色々教えてもらうことも出来て進めることが出来ました。
ドキュメントがない
同じような環境で運用しているドキュメントも少なく、同じようなリリース手順をしている人もいないので手探りでした。
最後に
今回の移行を通じて、「どこで問題が発生しても対処できるように想定しておくこと」と「インフラ知識を身につけ、チーム全体でのスキルを向上すること」が必要だと改めて感じました。
知識・経験不足があったことでうまく問題に対処ができなかったり、解決に時間がかかることが多かったです。
今後はチームとして知見を蓄積して、大きな問題が起きないようなインフラを整備していきたいなと思います。
クラウドワークスに興味のある方へ
株式会社クラウドワークスでは、共によりよい社会を築いてくれる仲間を募集しています！ ぜひご応募ください！
テックが気になる方はこちらから！
