IVRyのサブサービス、引っ越しするってよ
はじめに
先日、45歳の誕生日を祝ってもらったIVRyの最年長エンジニアの島筒です。
旧環境に設置されていたIVRyのサブサービスのインフラを引っ越したので、ご紹介します。
移管されるまでの経緯
前提として、IVRyのインフラは、AWSにホスティングされています。
IVRy本体及びIVRyのサブサービスは、リリース当初いくつかのサービスと相乗りのVPCに構築されていましたが、IVRy本体は、サービスが大きくなってきたこともあり、昨年末に独立したVPCに移管されました。
しかし、成長している本体サービスがあると、サブサービスのメンテナンスは後回しになりがちになるのは世の常で、IVRyのサブサービスも1年近く旧環境に放置されていました。
サブサービスにも注力したい構想もあり、旧環境に取り残しておくわけにはいかないと、重い腰をあげ、インフラ移管するに至りました。
本質的な移管理由は、IVRy本体を移管した理由と同様です。
IVRyのインフラの変遷
IVRyリリース当時の構成
今回の移管前の状態と、移管作業の内容(矢印部分)
インフラ移管に際して
IVRyのサブサービスを移管するにあたり配慮した点として、サブサービスはIVRy本体と少なからず連携しており、IVRy本体の利用が、平日の日中帯に集中しているため、土日の深夜の移管実施となりました。
本体と連携しているサブサービスの宿命です。
事前作業と移管当日の流れ
事前作業
- DNSのTTLを変更
- 本番環境のインフラを構築
- 移管当日の手順作成
移管当日の流れ
- ALBで、メンテナンスページを表示
- データ移行
- DNSを変更
事前作業
メンテナンスページに切り替える前に行う作業、事前にできることは極力事前に行います。検証環境の移管や、それに伴う修正などは事前作業には含まれておりません。
DNSのTTLを変更
移管作業前に必ずやるべきこととして、TTLの設定変更です。レコードの種類によっては、1週間が設定されており、直前に気づいても、遅いことが多々あります。重要なのは、Aレコード、CNAME、NSレコードです。AレコードやCNAMEのTTLが1日に設定されていると、ドメインの向け先のサーバを変更することができず、移管時に詰みます。
気をつけるべきこと
2週間以上前に確認を終え、1週間前にTTLを1日未満、可能であれば1時間(3600秒)に変更を完了すること作業当日には、5分(300秒)に切り替えます。
本番環境のインフラを構築
インフラ移管は、DNSで指定されているIPアドレスやドメインを切り替えることで向け先を変更できるため、インフラ構築は事前に行うことが可能です。可能であれば、仮のドメインを割り当て、動作確認まで行います。今回は、サービスが大きくないことと、検証環境で十分な検証が行えたため、除外しました。
移管当日
しっかり寝て食事を早めに終わらせ、心身ともに安定した状態で、実施される時刻を待ちましょう。実施時刻の30分くらい前に集まって、最終確認すると良いですね。
ALBで、メンテナンスページを表示
ALBには、綺麗にデザインを当てることはできません(スタイルシートをS3などに設置し、読み込めば可能)が、一部または全てのリクエストに対し、同じレスポンスを返却する機能があります。それを使って、メンテナンス中のページを表示します。
データ移行
RDSのデータをダンプ、インポート
これは、踏み台サーバがある環境に限ることですが、旧環境の踏み台サーバにポートフォワーディングで接続し、dumpコマンドを実施します。その後、新環境の踏み台サーバに同様に接続し、dumpデータを流し込みます。
画像データの移行
旧環境からデータを取り出し、新しいS3へ保存します。
DNSを変更
最後に、DNSを変更して終了です。メンテナンスページを表示しているALBは旧環境にあり、DNSが新環境のALBへ向けば、切り替わりが完了します。TTLと各DNSサーバにキャッシュされたタイミングの関係で、切り替わりは順次切り替わりますが、旧環境へリクエストが入った人は、メンテナンスページが表示され、新環境へリクエストが行った人は、新しい環境へアクセスされます。
たまには障害のない移管もあるんだよ
公開後、確認が完了して、就寝しました。翌日も障害連絡なく、一切の障害はありませんでした。
やばいくらいに盛り上がりの欠ける記事が出来上がってしまったのだけど、たまには、こんなに無事に移管作業が終わる記事があっても良いじゃないかと思う。
苦労して準備して、結局1度失敗した移管作業の記事は、こちらから読んでください。
スタートアップに入ったベテランエンジニアと話してみませんか
IVRyでは、エンジニアに限らず広い職種で人材を募集中です
Discussion