Technology部の菊池です。
日本のみならずグローバル展開するようなサービスやアプリケーション開発では、ユーザーがアクセスを開始した地点からサーバーまたはサービスまでの物理的距離によって、リクエストとレスポンスの遅延が発生することがあります。当記事ではこれを地理的レイテンシーと呼びます。
では、どのように対策すれば地理的レイテンシーを減少させて、ユーザーのUXを損なわないようにできるのか。今回はその方法について解説します。
※クラウドネイティブについてはAWSを使う前提としています。
目次
地理的レイテンシーとは？
そもそもレイテンシーとは、サーバ上でデータの転送をリクエストしてから実行されるまでに発生する遅延時間を指します。レイテンシーが発生する主な要因は以下の通りです。
- 物理的距離
- ネットワークルーティング
- 待ち合わせ
クライアントとサーバーの間の距離が長いほど、データが移動する時間が増加する。
データパケットが目的地に到達するまでに複数のネットワークデバイス（ルーター、スイッチなど）を経由する場合、それぞれのデバイスでの処理時間が加算される。
ネットワークの混雑状況によっては、データパケットが一時的に待機する必要があり、これがレイテンシーを増加させる場合がある。
このうち、物理的距離を原因とする遅延について、当記事では地理的レイテンシーと呼びます。
たとえば、日本に位置するサーバーと、日本から遠く離れたブラジルのサンパウロにあるサーバーが同様のシステムを提供している場合、日本からアクセスした際には後者のレスポンス時間が遅くなる可能性が高いといえるでしょう。
レイテンシーを確認できるサイト
AWS Ping Test (Latency)にアクセスすれば、各リージョンのPingの結果を計測・確認できます。自身のクライアントの端末から確認してもらうようにしましょう。
地理的レイテンシーの対応策に付随する課題
地理的レイテンシーを軽減する方法としてもっとも効果が見込める極端な方法は、各リージョンに全く同様の構成のインフラを構築することが考えられます。ただし、これには以下のような問題があるため、現実的ではありません。
- コストの増大
- 各リージョン間でのデータの同期問題
- 管理コストの増大
リージョンごとに同様のリソースを構築するとなると、構築対象のリージョン分だけコストが増大する
複数リージョンでデータを同期する場合、データ同期の地理的レイテンシーが発生する恐れがある
管理するリージョンが増えれば増えるほど、それに対する監視、セキュリティ対策など余計な管理コストが発生する
これらの問題を見越して、インフラ観点、アプリケーション観点での対策が必要です。以下、それぞれ詳しくご紹介します。
インフラ観点の対応策
1.CDN（Content Delivery Network）の利用
AWSでは、CloudFrontというコンテンツ配信ネットワーク (CDN) が提供されており、これを活用して各種アセットデータを地理的に最も近いエッジロケーションに配信する方法があります。対象となるアセットはイメージや動画、jsやhtmlなどのコンテンツデータです。
レスポンス結果を動的に変換させたい場合は、lambda@Edgeを使うことで、エッジローションでLambda関数の実行してレスポンスさせることも可能です。
なお、PostやPutでAPIを使ってデータベースなどにデータを書き込みたい場合、リージョンが異なると時間がかかってしまいます。たとえばエッジロケーションでリクエストのみを受信し、実際の書き込みのロジックは非同期で実施するなどの方法も選択肢として可能です。
この対策で想定する構成図とシーケンス図は以下の通りとなります。
またWebsocketを使ってリアルタイム性のある通信を実現させたい場合も、Cloudfrontが役立つでしょう。具体例としては、メッセージチャットや金融取引などリアルタイム性の早いUXを求められる機能を実装するときなどが考えられます。
構成としては上図の通りです。基本的にはクライアントからCloudfront経由へアクセスし、S3へ毎回データ取得を実施してください。AWSの内部ネットワークを使う関係から、直接クライアントからオリジンへアクセスするよりも早いレスポンスを期待できます。
2.DNS名前解決の高速化
▲AWS Global Accelerator Speed Comparisonの計測例
どうしてもDBなどのストレージにアクセスしてデータのReadが必要な場合は、AWS Global Acceleratorを使用する方法があります。
IPアドレスを固定化し、DNSの名前解決の高速化を実現すればレイテンシーを小さくすることが期待できます。実際の結果はAWS Global Accelerator Speed Comparisonで測定することが可能です。
このときの構成図としては以下のようなものが想定されます。
3.インメモリ型のストレージを活用して高速読み出しを実現する
よく使うデータについては余計なDBアクセスをせず、Redisなどのキャッシュに保存しておくことも有効です。たとえばトークンの有効状態はAPIアクセスの際に毎回DBを読み出すとレイテンシーが発生する可能性があるため、この方法で効果が期待できます。
また、システムの要件次第にはなりますが、DBのデータとの連携させる方法も案として考えられます。データの更新が発生したら、redisのキャッシュも差し替えることで常に最新データを取得可能なようにし、データが見つからない場合はDBにアクセスする、といった具合です。
ただし、この方法は事実上ストレージを新たに追加するソリューションとなるため、コストに見合う効果を出せるか検討する必要があります。
4.レプリケーションの設定
データの書き込みと読み出しのエンドポイントを分けることで、読み出し処理の高速化を図れます。
レプリケーションを作れるサービスにはさまざまなものがありますが、代表例としてはAuroraやRedisが挙げられます。レプリケーションにより、データの書き込み待ち時間の解消が期待できるのもメリットです。
またレプリケーションについても各リージョンに展開することも可能であり、DB読み出しをリージョンで高速化させたい場合に有用といえます。ただし、DBアクセスするためのサーバーは何かしらの方法で用意は必要になり、コスト面は注意が必要です。
アプリケーション観点
１．キャッシュの活用
API読み出しをしたデータを次回でも即時反映されるようにするために、クライアント端末内においてキャッシュとして保存しておけば高速化が図れます。
Webブラウザであればセッションストレージやローカルストレージに保存し、ネイティブアプリであればモバイル内のストレージにキャッシュとして保存するとよいでしょう。
また、イメージデータや大きなアセットデータもキャッシュ化しておくことで、次回は即時データの読み出しが可能となります。
想像しやすいのがインスタグラムのネイティブアプリです。一度読み出したイメージファイルを２回目に開いたとき、初回開いたときに比べて大幅に高速でイメージや動画が表示される経験をお持ちではないでしょうか。実際にこちらはインスタグラムのネイティブアプリを使って、お試しになってもらえればと思います。
この方法を検討する際の注意点として、キャッシュの有効期限を設定しておかないと古いキャッシュデータをいつまでも読み続ける可能性があります。例えば特定の閾値時間に達したらキャッシュを削除して新しいデータを読み出しするようにするなど、キャッシュを削除したり最新のデータを読み出したりするための実装をおこなってください。
２．バックグラウンド処理の実施
ネイティブアプリの場合は、アプリを開きっぱなしにするとバックグラウンドタスクによって定期的にサーバーからデータを取得することができます（各OSによって様々な制約などがあるため、仕様については適宜確認が必要です）。
これを実現することで、ネイティブアプリがフォアグラウンドにないときでも定期的にデータがサーバーから読み出されます。そのデータをキャッシュ保存することで、アプリケーション内の各種コンテンツの読み出しを高速化が期待できます。
なお、短い間隔で読み出しをやりすぎると、消費電力量が増えるため注意が必要です。
まとめ
クライアント端末とサーバー間の地理的レイテンシー問題は、サービスをグローバル展開するにあたって避けては通れない課題です。
今回ご紹介したようにさまざまな対応策がありますが、まず第一はUX観点で、表示を遅いと思われないような仕様策定を踏まえた上で、インフラ観点とアプリケーション観点で対策を進めていくことが望ましいといえます。
当社LIGでは、戦略設計に長けたプロジェクトマネージャーや技術に長けたエンジニア、UI/UXに精通したデザイナーがチームを組み、お客様のビジネス成功に向けて支援しています。
気になる方はぜひ下記ページよりサービス詳細をご覧ください。
