シンクロ・フード エンジニアブログ

飲食店ドットコムを運営する、株式会社シンクロ・フードの技術ブログです

Railsで稼働しているWebサービスをサブディレクトリから新規ドメインに移行しました

技術

開発部の光永です。
店舗デザイン.COM・求人＠インテリアデザイン・内装建築.com・グルメバイトちゃんなどのサービスの開発に携わっています。

弊社が運営しているサービスの1つであるグルメバイトちゃんで新規ドメインに移行するという開発が行われました。1つのRailsアプリケーションで2つのドメインを利用する形となっていて、あまり見ない例だと思うので、開発の内容や、リリースの手順を紹介します。

グルメバイトちゃんについて

まず初めにグルメバイトちゃんがどんなサービスなのか紹介します。

グルメバイトちゃんは2023年から弊社で開発をしている新規サービスです。ショート動画を使ってアルバイト募集をするサービスになっています。

開発環境的な話をすると、新規サービスということもあり、リリース速度を重視していたので、既存サービスのRailsアプリケーションのサブディレクトリに実装する形で開発を進めています。グルメバイトちゃん以外にも自社サービスをサブディレクトリで開発するという方法をとっているためそれらと同じような流れで開発がスタートしました。

既存サービスのサブディレクトリを利用していた理由にWAFの費用を抑えるためというものがあります。弊社で利用しているWAFがドメイン単位で課金されるシステムなので、既存サービスのドメインを利用することで追加で費用がかからないようにしました。

なぜ新規ドメインに移行することになったのか

既存サービスのサブディレクトリでの運用から新規ドメインでの運用へと切り替えたわけですが、この理由としては大きく2つあります。

1つ目はブラウザ上で表示されるサイト名をグルメバイトちゃんにしたかったためです。
サブディレクトリで運用していると、下の画像のようにグルメバイトちゃんのページであってもグルメバイトちゃんと表示されずに別のサービス名が表示されてしまいます。

これを下の画像のような形でグルメバイトちゃんの名前で表示したいという理由です。

2つ目の理由は基本的に1サービス1ドメインにしたいという理由です。
これに関してはグルメバイトちゃんの開発開始当初から検討されていました。利用者の増加等にともなってサービスが大きくなってきたので、タイミングを早めて実施されました。

グルメバイトちゃんのサイト構成

グルメバイトちゃんは主に3種類のページから構成されます。

gourmet_baito_chan/
├── shops
├── videos
├── entries
├── companies/
│     └── shops/
│            └── entries
└── admin/
       ├── shops
       ├── videos
       └── entries

gourmet_baito_chan直下にあるページは求職者が使います。アルバイト募集のされている店舗や、その募集動画を見たり、アルバイトに応募したりすることができます。

companies下はアルバイトを募集する飲食店の方が使う管理画面です。応募のあった人の情報を確認したりすることができます。

admin下は弊社の社員が使う管理画面です。掲載される店舗や動画の情報を登録、編集したり、応募者の情報を見たりすることができます。

この3種類のページが飲食店ドットコムという弊社サービスのサブディレクトリにありました。
また、管理画面の認証部分は飲食店ドットコムのサブドメインに実装されているサービスを利用しています。

全体的な進め方

続いて、実際にどんな進め方で新規ドメインへの移行が進められたのかを紹介します。

概要

実際の対応は以下のような方針で行われました。

  • 管理画面、エラーページは既存ドメイン側をそのまま使用する
  • 1つのRailsアプリケーションで2つのドメインを利用する

管理画面、エラーページは既存ドメイン側をそのまま使用する

サイト構成の箇所で説明した弊社社員が使う管理画面と飲食店の方が使う管理画面に関しては新規ドメインへの移行の際に新ドメイン側に移行しませんでした。
理由はサイトの構成上、認証部分の移行が難しかったためです。サイト構成でも触れましたが、認証が既存ドメインのサブドメインに実装されています。その実装が既存ドメイン以下でしか動かせない実装になってるためです。そのため、ログインが必要なページは既存ドメイン側に残す判断となりました。

また、404等のエラーページに関しても既存ドメインと同じページを利用することにしています。
この影響で、ページ内のリンクを変更する必要があったのでその対応は別途しています。具体的には、サイト内のリンクのhrefが相対パス等で指定されているリンクを絶対URLに直すという対応です。これをしないと新ドメイン側のエラーページから旧ドメイン側のページへのページ遷移ができなくなってしまうため、対応が必要になりました。

1つのRailsアプリケーションで2つのドメインを利用する

上記の1部ページを既存ドメインに残すことになった影響で1つのRailsアプリケーション内で2つのドメインを用意する必要が出てきました。 その影響で以下の2つの対応が必要となります。

1つはディレクトリによってどちらのドメインで処理するかが異なるため、それらを適切にリダイレクトすることです。

新ドメイン側ではサブディレクトリが不要なためサブディレクトリを取り除いたり、別のドメインに来たアクセスを適切なドメインに流したりする必要があります。
具体的には、下の表のような形になります。グルメバイトちゃんのディレクトリは/gourmet_baito/、管理画面は/gourmet_baito/admin/下にあるものとします。

アクセス リダイレクト先
https://旧ドメイン/gourmet_baito/hoge https://新ドメイン/hoge
https://新ドメイン/gourmet_baito/hoge https://新ドメイン/hoge
https://新ドメイン/admin/foo https://旧ドメイン/gourmet_baito/admin/foo

もう1つはページ内に置くリンクをドメインとディレクトリを意識して指定することです。
新旧両方のドメインで使われる箇所は絶対URLで指定します。新ドメイン側へのリンクはサブディレクトリを除いた新ドメインへ向く形で指定します。旧ドメインのパスはサブディレクトリのついた旧ドメインへ向く形で指定する必要があります。

手順

次にリリースの手順を紹介します。基本的な流れとして、最初に新ドメイン側を使える状態にして新ドメイン側のテストをします。そのテストが完了した後で旧ドメイン側の対応をします。
これにより、新ドメイン側でのテスト中もユーザーはサービスを問題なく利用できるため、テストをした上でのドメイン移行が安全にできます。

リリースの流れとしては

  1. 新ドメイン側のリバースプロキシの設定
  2. 新ドメイン側のテスト
  3. 旧ドメイン側のリバースプロキシの設定
  4. Railsアプリケーションのデプロイ

という流れで進めました。

新ドメイン側のリバースプロキシの設定

まずは新ドメイン側を使えるようにする対応として、新ドメイン内でのページ遷移をできるようにします。対応内容としては以下のようなものがあります。

  • 不要なパス（/gourmet_baito_chan/）がついていたら、不要な部分を外したパスにリダイレクトする
  • このドメインへのアクセスに/gourmet_baito_chanをつけてRailsアプリケーションに処理させる
    • 既存のRailsアプリケーションで処理させるためにはサブディレクトリ付きのパスが必要になるため
  • 管理画面のパスにアクセスが来た時に旧ドメインにリダイレクトする

これらの対応により新ドメイン側でページ遷移できるようになります。

この開発段階では旧ドメインから新ドメインへのリダイレクトはしていないため、旧ドメイン側での利用には影響がありません。
また、新ドメイン側ではリダイレクトが設定されたことにより、以下のことができるようになります。

  • 新ドメインからのサブディレクトリなしのリクエストを既存アプリケーションで処理する
  • 新ドメイン内でのページ遷移

新ドメイン内でのページ遷移に関しては、リンクのパスが変更されていないため、1度サブディレクトリを外すためのリダイレクトが挟まる状態ではありますが、特に意識しなくても遷移ができるようになるという感じです。

新ドメインテスト

この段階で旧ドメインは影響がなく、新ドメイン側はページ遷移含め使用できるようになっています。なのでここで新ドメイン側のテストをします。

テスト内容としては、新ドメイン側のリダイレクトの設定や、Railsアプリケーションで新ドメイン側からのアクセスを正しく処理できているかの確認になります。

旧ドメイン側のリバースプロキシの設定

新ドメインが問題なく使えるようになっていることが確認できたので、旧ドメイン側のアクセスを新ドメイン側に向ける対応をします。

ここでの対応は新ドメイン側で処理したいアクセスが旧ドメイン側に来た時に新ドメイン側にリダイレクトすることになります。
この対応が完了すると、ページ内のリンクに不要なパスがついているので、リダイレクトが挟まれるものの画面に表示されるのは意図したドメインで表示されるような状態になります。

この時点で旧ドメインは管理画面以外のページが表示されることなく、リダイレクトされるようになります。新ドメインは特に変更を加えていないため、テストをした時と同じ状態でリダイレクトを挟むもののページ遷移しながら使えるような状態になっています。

railsアプリケーションのデプロイ

最後の手順として、ページ内のリンクを正しいものにする変更をしたRailsアプリケーションをデプロイします。この作業はリダイレクトの設定前に行なってしまうと、適切なページへのアクセスとならないことがあるので、最後に行う必要があります。

具体的な変更としては以下のようなものがあります。

  • サブディレクトリの/gourmet_baito_chan/が不要な箇所には含めないようにする
  • 旧ドメインと新ドメインを分けられるようにする

サブディレクトリを除く対応は新ドメイン側のリンクで対応が必要になります。この対応でリダイレクトせずに新ドメイン内のページ遷移ができるようになります。

ドメインを分けられるようにする対応はメールなどに必要です。Railsアプリケーションは共通なので、メールの送り先等によって適切なドメインが表示されるように変更します。

この対応が終わると、新ドメインも旧ドメインも不要なリダイレクトなしにページ遷移ができる状態となります。

新規ドメインへの移行をしてみて

新規ドメインへの移行を終えての振り返りを目的達成できたのかという点とSEO的な観点から振り返ります。

目的達成できたのか

どんな目的があったのかをもう1度書いておくと

  • ブラウザでの検索時のサイト名をグルメバイトちゃんにする
  • 1サービス1ドメインにする

の2点になります。

1つ目のサイト名の変更についてはサイトの一部ページではグルメバイトちゃんとなっていますが、他のページでは下の画像のようにドメインがそのまま出るような形となっています。

既存サービスの名前から変更するという点では達成していますが、指定した名前にならない点については引き続き調査や改善をしていきます。

2つ目の1サービス1ドメインにするということについては、Googleにインデックスされる箇所に関しては全て新ドメインで統一されているので達成したと言えるのではないでしょうか。

新規ドメインへの移行によるSEO的な影響

次に新規ドメインへの移行によるSEO的な影響についてですが、移行直後はサイトの評価が低い状態となりました。これに関しては新規ドメインを使うので避けられないと予想していたので、想定通りの結果でした。

現在では、元通り以上のアクセス数となっているため、サイト評価は回復したと判断しています。
サイト評価の回復の要因として考えられることに適切に301リダイレクトを設定したことが考えられます。

終わりに

グルメバイトちゃんの新規ドメインへの移行の中で1つのrailsアプリケーションで2つのドメインを利用するという対応をしたのでその手順や対応内容の紹介でした。

1つのアプリケーションで複数のドメインを利用する実装を見る機会があまりないと思うので、面白い開発だなと思っています。

今後もサービスの拡大や認知の拡大を進めるような開発が進んでいくので、そのような開発に努めていきたいと思います。