発注したシステムが妙に遅い — 原因は「サーバーの非力さ」ではなく距離かもしれない | GH Media
URLがコピーされました

発注したシステムが妙に遅い — 原因は「サーバーの非力さ」ではなく距離かもしれない

URLがコピーされました
発注したシステムが妙に遅い — 原因は「サーバーの非力さ」ではなく距離かもしれない

「社内で使っている管理システムが、一覧を開くたびに数秒待たされます。開発してもらった会社に相談したら『アクセスが増えたのでサーバーを増強しましょう』と提案されたのですが、そこそこの費用がかかる割に、本当にそれで速くなるのか確信が持てません」——製造業の会社で業務システムを管理している方から、こんな相談を受けました。「遅い=サーバーが非力」と考えてスペックを上げても、体感がほとんど変わらない。この行き詰まりは珍しくありません。

先日、エンジニアの間で「サーバーもデータベースも東京にあるのに、実は全部のクエリが太平洋を横断していた」という調査記事が話題になりました。国内で完結しているように見えて、データが知らないうちに海外を経由していた、という話です。同じことは、発注した側からは絶対に見えません。本記事では、システムの「遅さ」を安易にサーバー増強で片付ける前に、発注者が疑うべき原因を整理します。

「遅い」には二種類ある — 処理が重いのか、距離が遠いのか

システムの遅さは、大きく二つに分けて考えると原因が絞れます。ひとつは 処理の重さ。大量のデータを計算したり、非効率な検索をしていて、サーバーの中での作業に時間がかかっているケース。もうひとつは 距離(レイテンシ)。処理そのものは一瞬でも、データがユーザーとサーバー、サーバーとデータベースの間を何度も往復し、その一回一回の移動距離が長いために、待ち時間が積み上がるケースです。

「サーバーを増強すれば速くなる」が効くのは、前者の処理が重いケースだけです。距離が原因の遅さは、どれだけサーバーを強くしても縮まりません。移動する経路そのものが長いのだから、走る車を速くしても道のりは変わらない、という理屈です。ここを混同したまま増強に費用を払うと、「高いお金を出したのに変わらない」という結果になります。

なぜ「国内なのに海を渡る」ことが起きるのか

サーバーもデータベースも日本国内に置いたはずなのに、通信が海外を経由してしまう——直感に反しますが、次のような理由で実際に起こります。

  • サービスの初期設定が海外になっている:クラウドやデータベースのサービスは、何も指定しないと米国のリージョンが既定になっていることがある。日本のつもりで作ったのに、一部が海外に置かれたまま気づかない
  • 経由している外部サービスが海外にある:認証、決済、通知、地図などを外部サービスに任せていると、その処理のたびに海外のサーバーへ問い合わせが飛ぶ
  • 経路を振り分ける仕組みがずれている:アクセスを最寄りの拠点へ振り分ける設定が誤って働き、国内の利用者をわざわざ遠い拠点へ回してしまう

距離の影響は無視できません。一般に、同じ地域内での通信に比べ、別のリージョンをまたぐと往復の待ち時間はおおよそ倍前後に増えるとされ、日本から米国を経由するような経路では一回あたり数百ミリ秒に達することもあります。一回の画面表示でこうした往復が何十回も積み重なれば、「数秒待たされる」体感につながります。

発注者が投げるべき三つの質問

原因の切り分けは専門的な作業ですが、発注者でも「どこを疑うべきか」を制作・保守会社に問いかけることはできます。増強の見積もりに即答する前に、次を確認してください。

質問何を確かめているか
サーバー・DB・使っている外部サービスは、どの地域に置かれていますか想定外の海外リージョンが紛れ込んでいないか
遅いのは「処理」ですか「通信の往復」ですか、切り分けましたか増強で効く問題かどうかの見極めがされているか
一画面の表示で、裏で何回やり取りが発生していますか往復回数が多すぎて距離が効いていないか

とくに核心は、「増強を提案する前に、処理の重さと距離のどちらが原因か切り分けたか」です。切り分けをせずに「とりあえずサーバーを上げましょう」と言う相手には、その根拠を求めてよい。まっとうな開発者なら、どこで時間を食っているかを計測した上で提案します。計測なしの増強は、当てずっぽうに費用を払うのと変わりません。CI/ビルドの高速化で計測から入る考え方はDockerビルド高速化の記事でも扱っています。

増強の前に「計測」を挟むだけで、無駄払いは防げる

弊社が相談を受けた前述の会社では、サーバー増強の発注を一度止めて、まず「どの処理に何ミリ秒かかっているか」を計測しました。すると、遅さの大半はサーバーの処理ではなく、画面を開くたびに海外にある通知サービスへ何度も問い合わせていた往復時間だと判明。増強では一切解決しない問題でした。対応は、その問い合わせをまとめて回数を減らし、国内で完結できる部分は国内に寄せるという設計変更で、増強費用をかけずに体感が改善しています。

システムが遅いとき、増強はいちばん分かりやすい解決策に見えますが、原因が距離にある場合は費用がまるごと無駄になります。海外リージョンへの依存や、外部サービスとの往復のような設計上の問題は、事業継続の観点でも見直す価値があり、クラウド障害に備えた設計とも通じるテーマです。「発注したシステムが遅いが原因が分からない」「増強の見積もりが妥当か第三者の目で見てほしい」「まず計測してボトルネックを切り分けてほしい」——そうしたお悩みがあれば、グリームハブの開発・システムのご相談からお気軽にお問い合わせください。増強ありきではなく、計測に基づいて本当に効く手を一緒に見極めます。

Sources

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事

「TECH」の記事一覧を見る