低レイテンシSaaSインフラの技術設計図

本記事では、低レイテンシな分散型SaaSアプリケーションの実現に立ちはだかる技術的な壁と、それをどこまで解消できるのかを整理します。

目指すのは、地理的に近いユーザー同士のあいだで可能な限りレイテンシを抑えたステートフルなアプリケーションです。ホスティングはSaaSプロバイダー側で行う必要があります。理由は2つ。プロバイダー側で計算結果を検証できること、そしてすべての参加者に高い可用性を提供できることです。

ご想像のとおり、この課題は現在いくつかの方法で対処されています。人口密集地ではクラウドプロバイダーで計算処理を行い、より遠隔地への接続にはCDN(コンテンツデリバリーネットワーク)を活用し、クラウドプロバイダーがカバーしていないエリアではオンプレミス拠点を使う、といった具合です。

とはいえ、これらを連携させて一体運用するのは非常に骨の折れる作業で、Valveのような超大手でなければ自前で抱え込めないのが実情です。しかし、その状況は近く変わるかもしれません。その理由をこれから順に見ていきましょう。

低レイテンシアプリケーションのユーザーにとって、物理ネットワークは越えられない制約です。CDNは複数のプロバイダー間を結ぶ仕組みとしては優れていますが、ユーザー側の事情は依然としてバラバラで、トラフィックのホップが増えるたびにレイテンシが積み上がり、高品質な体験から遠ざかっていきます。これは「ハード」な制約であり、地域によっては地上・海底の新規インフラ整備でしか解決できません。Starlinkのような画期的な技術は遠隔地への接続性をもたらしますが、そのレイテンシは低レイテンシアプリケーションにはまだ大きすぎます。

一方、「ソフト」な制約は、異なるクラウドプロバイダー、CDN、ハードウェアのあいだでトラフィックを相互接続することです。こちらはすでに克服されており、すぐに利用可能な実装も公開されています。

ネットワーク速度と接続性というハードな制約を乗り越えるには、SaaSアプリケーションのホスティングをユーザーのできるだけ近くに配置する必要があります。当然ながらコストがかかり、そうしたインフラをどう制御するかという課題も生まれます。

有力な答えのひとつが、複数拠点にノードを分散させたKubernetesクラスタです。あるベンチマークによれば、コンテナはネイティブプロセスと比べてわずか0.12%しか遅くなかったとされています。

ノードをオンデマンドでプロビジョニングするには、Terraformのようなインフラ構成ツールを運用し、クラウドプロバイダー(AWS、GCP、Azure)のAPIや、VMwareをはじめとするハイパーバイザーで動くデータセンターを呼び出す必要があります。この仕組みのメンテナンスだけでも、相応の工数を覚悟しなければなりません。

クラウドプロバイダーがもたらし、いまや当たり前になった進化が従量課金(Pay-As-You-Go)モデルです。AWSならクレジットカードを登録した瞬間から仮想マシンを使い始められます。面倒な縛りは一切ありません。

一方、従来型のデータセンターの多くは、プライベートクラウドツールによるオンラインでの環境プロビジョニングにようやく追いつき始めた段階です。大きなハードルとなるのが、マシンの性能とコストパフォーマンスをどう見極めるかという点です。とはいえ、自社のworkloadに即したベンチマークを得るには、実際にパイロットを走らせるのが一番の近道です。