先日、コスト削減と運用効率化のために、バックエンドサーバーをRenderからRailwayへ移行しました。（移行自体はとても簡単でした！その話はまた別の記事で。）
「これで安くなるし、スリープ問題も解決して爆速になるぞ！」
と意気揚々とデプロイを完了させたのですが……。
「あれ？ なんか……遅い？」
管理画面を開いてもローディングがグルグル。チャットを送っても返事が来るまで数秒かかる。 Renderの無料プランを使っていた時よりも、体感で明らかにモッサリしているのです。
コードは一行も変えていません。サーバーのスペックもRailwayの方が良いはず。 なのに、なぜ？
結論から言うと、原因は**「サーバーとデータベースの物理的な距離（リージョン）」**にありました。 今回は、PaaS移行時にうっかりハマりやすい「リージョンの落とし穴」について共有します。
なぜ「コードは同じ」なのに遅くなるのか？
まず、当時の私のアプリの構成を見てみましょう。
- フロントエンド: Vercel
- バックエンド: Railway (FastAPI)
- データベース: Neon (PostgreSQL)
「APIが遅い」と感じた時、私たちはつい「クエリが重いのかな？」「ループ処理が無駄なのかな？」とコードの中身を疑ってしまいがちです。
しかし、今回ボトルネックになっていたのは物理的な距離でした。
太平洋を往復するデータたち
調べてみると、各サービスの「住処（データセンターの場所）」は以下のようになっていました。
- データベース (Neon): シンガポール (Asia Pacific)
- バックエンド (Railway): アメリカ西部 (US West) ← ここが原因！
つまり、ユーザーがアプリで何か操作をするたびに、以下のような通信が発生していたのです。
- API（アメリカ）が DB（シンガポール）にデータを要求 【太平洋横断 ✈️】
- DB（シンガポール）が API（アメリカ）にデータを返す 【太平洋横断 ✈️】
Webアプリの処理では、1回のAPIリクエストの中で、データベースとのやり取りが数回〜数十回行われることも珍しくありません。 もし1回の往復に0.2秒かかるとしたら、5回やり取りするだけで1秒の遅延になります。
これが「モッサリ」の正体でした。コードがどんなに高速でも、物理的な距離による移動時間には勝てません。
確認方法と解決手順
原因がわかれば、解決は簡単です。**「バックエンドサーバーをデータベースの近くに引っ越す」**だけです。
1. データベースのリージョンを確認する
まずは、自分が使っているデータベースがどこにあるかを確認しましょう。 私はNeonを使用しているので、ダッシュボードの「Project settings」を見に行きます。
（キャプション：Neonの設定画面。「Region」の項目を確認します）
しっかりと**「AWS Asia Pacific 1 (Singapore)」**と書かれていますね。私の大事なデータたちはシンガポールにいます。
2. Railwayのリージョンを確認・変更する
次に、遅延の原因となっているRailway側の設定を確認します。 Railwayのプロジェクト画面から、対象のサービス（今回はbackend）を選択し、**「Settings」**タブを開きます。
そこにある**「Scale」**という項目を見てみましょう。
（キャプション：Railwayの設定画面。「Region」がUS Westになっています）
犯人はこれです！ **「Region」が「US West (California, USA)」**になっています。 Railwayなどの海外発PaaSは、デフォルトの設定が「US（アメリカ）」になっていることが非常に多いです。何も気にせず「Next」を連打してデプロイすると、自動的にサーバーがアメリカに爆誕してしまいます。
3. リージョンを合わせる
この「Region」のプルダウンメニューをクリックし、データベースと同じエリアに変更します。 今回はNeonがシンガポールだったので、Railway側も**「Asia Pacific (Singapore)」**を選択しました。
※設定を変更すると、Railwayが自動的に再デプロイを開始します。
結果：驚くほど爆速に！
再デプロイ完了後、恐る恐るアプリを開いてみました。
「……速っ！！！」
今まで数秒かかっていたチャットの履歴表示が、クリックした瞬間にパッと表示されます。 「サクサク動く」というのはこのことか、と感動するレベルです。
これまでは、近所のコンビニに行くのにわざわざ飛行機に乗っていたような状態でした。それが徒歩で行けるようになったのですから、速くて当たり前です。
まとめ：サーバー移行時の「必須チェックリスト」
今回の教訓をまとめます。
- バックエンドとデータベースは「同じリージョン」に置くのが鉄則
- 可能な限り、物理的に近い場所（同じ都市、最低でも同じ国や地域）を選びましょう。
- PaaSのデフォルト設定を疑う
- Railway、Render、Herokuなどは、初期設定がUS（アメリカ）になっていることが多いです。日本向けのサービスや、すでにDBがアジアにある場合は必ず変更しましょう。
- 「何もしてないのに遅い」時はインフラを疑う
- コードを変更していないのに動作が重くなった場合、ネットワークやリージョンの設定が原因である可能性が高いです。
個人開発だと、機能の実装に集中しすぎてインフラの設定は「動けばOK」と流してしまいがちです。 しかし、この「ボタン一つ」の設定を変えるだけで、ユーザー体験（UX）は劇的に改善します。
もし、あなたのアプリが「なんか遅いな…」と感じたら、一度サーバーとデータベースが離れ離れになっていないか、地図の上で確認してみてくださいね！