🏷️

サービス名を変えたのでドメインの変更をしてみた

に公開
Go
Next.js
PWA
Google App Engine
Domain
tech

自己紹介

zacker（ざっかー）といいます。
アプリ開発が大好きな大学院生です。

profile

「komichi」という2時間くらいの暇つぶしプランを作ってくれるサービスを作っています。
ぜひ、一度触ってみてください！
https://komichi.app/

Instagram、TikTokもはじめたので、よろしければフォローをお願いします！
https://www.instagram.com/komichiapp/
https://www.tiktok.com/@komichiapp

コトの経緯

「komichi」というサービスはもともと「poroto」という名前で運用していました。
なぜ、名前が変わったのかという経緯は ↓ の記事で紹介しています。
もし、よければチェックしてみてください！
https://note.com/zacker2010/n/n79e2e6c450fc

この記事を読むと何がわかるか？

  • すでに運用しているサービスの名前を変更するときに何が発生するか
  • 既存の資源をどれだけ変更しなければならないのか
  • サービス名を変更するときに注意するべき箇所

補足すると、拙作のアプリはユーザー数が片手で数えられる弱小サービスなので
大規模サービスと違い気軽に変更を行うことができます。

既にビジネス展開している場合は、ソフトウェアの範囲外のことも気に掛ける必要がありますが、
この記事では単純にサービス名を変更したときのソフトウェアの影響だけを紹介します。

利用している技術・サービス

影響範囲の説明も兼ねて、サービス内で利用している技術を紹介します。

要素 採用技術・サービス
フロントエンド Next.js
バックエンド Gin（Golang）
ホスティング Google App Engine
認証 Firebase Authentication
広告 Google Adsence
ドメイン管理 Google Domain -> Squarespace

やらなければいけないこと

  • ドメインの取得
  • DNSの登録
  • Google Search Consoleからサイトマップの更新
  • 旧サービス名を含む画像、コードを新しいものに置き換える
  • 旧ドメインアクセス時に、新ドメインにリダイレクトする
  • Google Adsenceのドメイン変更
  • Firebaseの設定修正

全てを書くととても長くなるので
「ここは人によって違うだろうなぁ」というところだけをピックアップします。

どんな課題があるか？

旧ドメインで動作しているサービスを止めたくない

今まで知り合いにporoto.appとして宣伝していましたが、
アクセスしたときに404 Not Foundとなってしまっては、
「開発をやめてしまったのかな 🤔」と思われてしまいます。
弱小サービスではありますが、既に存在を知ってくれている人への心がけは忘れたくありません。

どの順番で行うか

戦略としては、「とりあえず動く」を小さく積み重ねていくことです。
そうすると、うまくいかないときの原因を特定しやすく
何より小さな達成感を味わいながら作業できます。

  1. 影響範囲の調査
    一番つらいのは手戻りの発生です。
    そこで、まずは影響範囲の調査から始めました。
    旧ドメインを参照している場所をgrepしたり
    実際にアプリケーションを使って通信している場所を調べる地道な作業です。

  2. Google App Engineと新しいドメインを結びつける
    Google App Engineとドメインは1対1対応ではなく、複数のドメインを登録することができます。
    旧サービスを止めないために、移行中は旧ドメインを残しながら、新しいドメインを追加します。
    変更が完了すると、新しいドメインからアプリケーションを利用できるようになります 🎉

  3. Firebase Authenticationの設定更新
    Firebase Authentiacationではログインをするのに
    認証元のドメインを指定する必要があります（今回はkomichi.app）。
    修正が完了すると旧ドメインのログイン機能を維持しながら、新ドメインからもログインを行うことができます。

  4. ソースコードの変更
    サービス名やリンク、ロゴ等の画像を書き換えていきます。

  5. 🚀 デプロイ
    これでアプリケーションの準備は整ったのでデプロイを行います。

  6. 旧ドメインにアクセスしたときに、新しいドメインにリダイレクトする
    poroto.appというドメインをしっているユーザーに新しいサービス名を知らせるためです。
    半年くらいはこの運用を続けるつもりです。

  7. Google Adsence, Analyticsの設定更新
    アプリケーションの動作に関わらない分析や広告に関わる部分はデプロイ後に修正を行いました。
    Google Adsenceは今まで利用していたものに、新しいドメインを追加登録するだけで完了です。
    広告ID等も変更が無いので、コードの修正は発生しませんでした。
    ただ、新しいドメインの承認が完了するまでに2週間程度かかりました。

アプリケーション内の旧サービス名を新サービス名に置き換える

このときはまだ、新しい名前が決まったばかりで
新しいアプリロゴができていなかったため
grepで置換できる場所だけ置換を行い、
画像などの資源は別のPRで修正を行うという方針で進めました。

システム名を変更するか？

システム内の名称やリポジトリの名前まで変更するかという判断がありました。
結論からいうと、ユーザーに見えない部分は修正を行いませんでした。

私はサービス名はUIのように、「変化しやすい」ものと考えています。
そのような変更をシステムが全てうけてしまうと、その度に改修が必要となるため大変です。
したがって、ユーザーに見える部分だけを変更することにしました。

バックエンドの修正

「ユーザーに見える部分だけ変更する」という方針をとったため、
バックエンドの修正はCORSの許可設定の修正のみとなりました。

フロントエンドの修正

フロントエンドを修正していて感じたのは、アプリロゴ等のファイル名は
具体的なサービス名ではなく、logo.pngのようにすると、
それを参照するコードを変更する必要がなく楽だなと思いました。

また、grepしまくるのがつらかったので
URLが含まれるところだけ環境変数として切り出しました。

ロゴを新しいものに置き換える

アプリケーション内で用いているものに加えて、以下のものを変更しました。

  • OGP画像
  • PWA用のアプリロゴ
  • favicon

それぞれ便利なツールがあるのでご紹介します。

PWA用のアプリロゴの作成

PWAを利用する端末やブラウザによってアプリアイコンの形が異なることがあります。
Maskable icons
（画像はProgressierから引用しました。）

このようにアイコンの外枠の形が変わっても、アイコンが見切れたりしないように
いい感じにしてくれるサービスがあるようなので、
こちらを用いてもととなるアイコン画像を作成します。
https://progressier.com/maskable-icons-editor

このアイコン画像から、以下のサービスを用いて複数サイズのアイコンを作成しました。
https://www.pwabuilder.com/imageGenerator

faviconの作成

svg画像からも作ることができるので、画質の劣化を防ぐことができます。
https://realfavicongenerator.net/

旧ドメインアクセス時に、新ドメインにリダイレクトする

最初はDNSの設定を修正するのかなと思いましたが
調べてみるとNginx等のWebサーバやアプリケーションを修正する必要があるようです。

GAEでのルーティング設定

komichiではGoogle App Engine（GAE）を利用しています。
GAEではアプリケーションはサービスという単位で管理されます。

GAEではdispatch.yamlという設定ファイルを用いて
サービスごとのルーティングの設定を行うことができます。

具体的に、フロントエンドのサービスがdefaultサービスとして起動していて
以下のようにルーティングしたいとします。

リクエストURL ルーティング先
example.com default サービス

これに対応するdispatch.yamlは、このようになります。

dispatch.yaml
dispatch:
  - url: "example.com/*"
    service: default

バックエンドをサービス（backend)を増設したいとなっても簡単です。

リクエストURL ルーティング先
example.com default サービス
backend.example.com backend サービス
dispatch.yaml
dispatch:
  - url: "example.com/*"
    service: default
  - url: "backend.example.com/*"
    service: backend

このルーティング機能を使って、poroto.appに来たリクエストを
「すべてのリクエストをkomichi.appにリダイレクトするくん」に割り当てます。

これによって、poroto.appのリクエストをkomichi.appにリダイレクトするようにします。

リダイレクト専用のサーバを建てる

やることが決まれば、あとは簡単です。

以下のように、Express.jsを使ってリダイレクト専用サーバを起動します。

index.js
const express = require('express');
const app = express();

const PORT = process.env.PORT || 3000;

app.use((req, res) => {
    res.redirect(301, 'https://komichi.app');
});

app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

GAEにデプロイするための設定ファイルを用意して

app.yaml
runtime: nodejs20
service: redirect-komichi

デプロイします🚀

gcloud app deploy

poroto.appに来たリクエストをこのサービスに紐づけるようにして

dispatch.yaml
dispatch:
  ...
  - url: "poroto.app/*"
    service: redirect-komichi

ルーティングの設定を反映させます。

gcloud app deploy dispatch.yaml

これで、リダイレクトができるようになりました。！

沼ったところ

Firebase Authenticationの承認済みドメインの追加

認証済みドメインの追加はFirebaseの設定画面から行うことができます。
これだけで新しいドメインからログインできて、めでたしめでたし
……となると思いきや、そうは問屋が卸しません。

ブラウザからFirebaseを利用するときには、Firebaseが発行したAPIキーを用います。
私はこのAPIキーに対して、リクエストもとの制限をかけていたため利用することができませんでした。

設定を変更するには Google Cloud コンソール > APIとサービス > 認証情報 のページに移動し、
対象となる鍵の「ウェブサイトの制限」に以下のように新しいドメイン名を追加する必要があります。

APIキー - ウェブサイトの制限

Next.js によるリダイレクト

Next.jsのmiddlewareという機能を使うと、Next.jsに来る全てのアクセスに対して介入することができます。

この機能を使って以下の用にリダイレクトを行おうとしました。

middleware.ts
export function middleware(req: NextRequest) {
    const { hostname } = req.nextUrl;
    if (hostname === "poroto.app") {
        const url = new URL("https://komichi.app/");
        return NextResponse.redirect(url, 301);
    }
    return NextResponse.next();
}

しかし、実際にデプロイしてみると、poroto.appに来たリクエストも
hostnameがlocalhostとなってしまい、うまく動作しませんでした。
有識者の方がいれば教えていただけると嬉しいです！

おわりに

このような記事を書くのが初めてなので、読みづらい部分がたくさんあったと思います🙇
これからも少しずつ発信を続けていきたいと思うので、ウォッチしてもらえると嬉しいです！

おしまい。

Discussion