ドメイン移行の背景

弊社はもともと Vorkers という名前でサービスを運用していましたが、2019 年にサービス名を OpenWork へと変更しました。

以後、サービス名 (OpenWork) とサイトドメイン (www.vorkers.com) 間の不一致が続いていました。遅くなってしまいましたが、今回いよいよ移行の準備が整いました。

チーム体制

影響範囲が広いため、Web アプリケーション、ネイティブアプリ、アナリスト、そしてインフラなど幅広い職能のメンバーから構成されました。

何をしなければいけないのか、どのような作業があるのかの洗い出しと見積もりを行いました。

新ドメイン自体は前もって用意されていたため、Route53 で DNS レコードを作成するためのホストゾーンを構築しました。

ロードバランサーにアタッチするための ACM を作成しました。旧ドメインも一部で利用されているため、SANs に旧ドメインを追加しました。

旧ドメインからのリダイレクトを ALB のリスナールールで定義しました。 www. の付与など、前々からあったリダイレクトは .htaccess (Apache) 側で行っていましたが、これらも ALB へ移行することで管理しやすくなりました。

「ドメイン移行」をどのようにデプロイ・リリースするべきか。

ここでは後者を選択しました。すなわち、移行前/移行後の 2 環境が並行して稼働する状態となります。この方式のメリデメを以下にまとめました。

メリット:

デメリット:

移行後環境の構築に手間がかかる
- サービスの Terraform ファイルをまるごとコピーして必要な箇所を手直しする形だが、OpenWork というメインプロダクトの IaC であるため、みるべきコード量が純粋に多い

ドメインや AWS リソース名が変わることによって生じる諸々の設定変更を行いました。このあたりは組織やサービスによって変わってくるところだと思います。

リリースに関してはインフラ作業が多くなるため、インフラチームが主体となって手順をまとめました。

やったことはざっくり以下の 3 つです。

上記によって、vorkers.com → 移行後環境 ALB が openwork.jp へリダイレクト → 移行後環境というルーティングとなります。

※ なお今回はお世話にならなかったのですが、切り戻すためには 2 と 3 をもとに戻せば OK です。
極めて少ない手数で対応できるため UX への影響を最小限に抑えることができます。

育休明け直後というポンコツ状態の自分でしたが、周りの方々によるサポートのおかげもあり、1 ヶ月強という期間でスピーディにやりきれました。

最後に、今回作業をしていてはまった点と、課題に感じた点を挙げて結びとしたいと思います。

Fastly (CDN) の TLS 証明書を取得するには別料金
- 無料で作れる AWS ACM のような感覚でいると思わぬ落とし穴 (2023/09 現在、$275/月)
Terraform ファイルの PR が巨大になった
- 上述のようにファイルをコピーして移行後環境を構築したため、新規追加行の差分が膨大になり、PR として機能するか迷った
- レビュー負荷を少しでも下げるため、自前で diff コマンド (旧環境 vs. 新環境) を叩いた結果を載せるなど工夫

開発環境の構築に時間がかかった
- 他チームの影響調査もその分後ろ倒しとなった。
- どうすれば品質を保ちながら構築作業を効率化できるか、検討中。
他チームとの情報共有の粒度はより小さく
- 特にインフラの専門的な情報共有は、どこまでが他チームにとってノイズになるのかの判断が難しかった。
- 共有を端折ったことで結果的に齟齬が生まれることもあった。
インフラチーム内での役割分担はより工夫できそう
- 私が開発の主担当であったが、他チームからのコミュニケーション窓口も受け持っていたことで、開発作業があまり進まない日もあった。