「Ship It Saturdays」参加記:Firebase HostingとCloud Runによる効率的なルーティング実装
「Ship It Saturdays」に参加し、普段後回しにしていた課題を解決しました。今回はGoogle Cloud Runのプロジェクトデプロイにおいて、Firebase Hostingを活用して特定のパスをCloud Runサービスへ振り分ける構成を実装しました。GCPロードバランサとの比較を通じて、コストと運用の観点からFirebase Hostingが最適であると判断。SvelteKitのベースパス設定とfirebase.jsonの書き換えルールによる具体的な実装手順を紹介します。
「Ship It Saturdays」に参加して:集中力と技術判断の実践的振り返り
今日は Lloyd さんにお誘いいただき、「Ship It Saturdays」というイベントに参加してきました。これは4時間の集中「スプリント」イベントで、普段先延ばしにしていたタスクを完了させるための集中できる環境を提供するものです。
1.イベントの体験と成果
「Ship It Saturdays」は、単なるコワーキングスペースではなく、職場での思考の枠組みを打ち破るコミュニティでもあります。ここでは、自分の「副業」や突飛なアイデアを探求することができます。当日は、午前10時の開始から15時の終了まで、濃密なプロセスで行われました。「ビルド/スプリント」に集中する時間だけでなく、最後には「Show-and-tell(成果発表)」の時間も設けられています。
実際に参加してみて、非常に深い感銘を受けました。集中できる環境のおかげで、自宅ではつい先延ばしにしがちなタスクを無事に完了できました。同時に、他の参加者との議論を通じて新しい視点に触れることができ、知識の幅も大きく広がりました。私個人としては、すべて英語で行われる環境での交流は、非常に貴重な鍛錬の機会となりました。
2.技術的課題:Google Cloud Run のパス設定
今回のイベントでは、主に Google Cloud Run のプロジェクトデプロイに関する問題に取り組みました。私の核心的なニーズは、同一ドメイン doc.mydomaintest.jp を利用して、パスごとに振り分けることでした。具体的には、ルートパス doc.mydomaintest.jp はあるWebサイトへ、doc.mydomaintest.jp/domaintest] は別の Cloud Run サービスへ向けるというものです。
将来的な長期開発戦略を評価した上で、「Firebase Hosting(Cloud Run内蔵)」と「GCP ロードバランサ(ロードバランサ+複数の Cloud Run)」の2つの選択肢を詳細に比較しました。
評価指標:
アーキテクチャの複雑さ:
- Firebase Hosting:極めて低い。JSON設定が少し必要なだけで、サーバー運用の負荷はかかりません。
- GCP ロードバランサ:高い。静的IP、SSL証明書、VPCプロキシサブネット、ルーティングルールの管理が必要です。
コスト:
- Firebase Hosting:極めて低い、あるいは無料。無料枠が充実しており、書き換えルール自体に追加料金は発生しません。
- GCP ロードバランサ:高い。トラフィックの量にかかわらず、ロードバランサ自体に固定のインスタンス時間料金(通常月額20〜30ドル程度から)が発生します。
静的リソースのパフォーマンス:
- Firebase Hosting:極めて速い。世界トップクラスのCDNを内蔵しており、静的リソースはエッジノードに直接キャッシュされます。
- GCP ロードバランサ:設定次第。Cloud CDN を設定していない場合、トラフィックは Cloud Run まで透過する必要があり、パフォーマンスが制限されます。
柔軟性と拡張性:
- Firebase Hosting:中程度。メインサイトが静的サイトやフロントエンドフレームワークで、サブサイトが軽量なマイクロサービスである場合に最適です。
- GCP ロードバランサ:非常に高い。Blue/Green デプロイ、クロスリージョン災害対策、Cloud Armor ファイアウォールなどのエンタープライズ向け機能をサポートしています。
結論:
SvelteKit、Next.js、Vue、React を核とするモダンなフルスタックプロジェクトにとって、「Firebase Hosting をメインとし、部分的に Cloud Run をマイクロサービスとして埋め込む」構成が、開発体験とコスト制御のバランスが最も良いという結論に至りました。
3.実装手順
構成を決定後、スムーズにデプロイを完了しました。主な手順は以下の通りです。
ステップ1:SvelteKit のベースパスを変更
プロジェクトの svelte.config.js ファイルで paths を設定し、サブパスで実行されることを確認します:
import adapter from '@sveltejs/adapter-node';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter(),
paths: {
// Edit this↓↓↓
base: '/domaintest'
}
}
};
export default config;ステップ2:firebase.json の設定
rewrites 配列にルールを追加し、スラッシュの有無にかかわらずパスを Cloud Run サービスに誘導します:
"rewrites": [
{
"source": "/domaintest",
"run": {
"serviceId": "Your Cloud Run Service Name",
"region": "asia-northeast1"
}
},
{
"source": "/domaintest/**",
"run": {
"serviceId": "Your Cloud Run Service Name",
"region": "asia-northeast1"
}
}
]設定完了後、firebase deploy --only hosting を実行すればデプロイ成功です。
4.今後の展望
今回の技術的な課題が円満に解決したことに安堵しています。次はより壮大な技術的目標があります。AIモデル(Gemini 3.5 Live や GPT Realtime 2 など)を活用し、『名探偵コナン』の「変声機」のような機能を備えた同時通訳デバイスを、「3Dプリント + IoT + アプリ」の組み合わせで開発する予定です。 英語力の向上は一朝一夕にはいきませんが、今後も継続的に努力し、将来皆さんとよりスムーズに交流し、この活気あるコミュニティにさらに溶け込めるようにしたいと思います。
