普段インターネットを使っていると、サイトによってはレスポンスのすごくいいサイトとそうでないサイトがありますね。
ページの構成や、システムの処理能力、根本的なアーキテクチャの問題などいろいろと原因が考えられますが、ここでは、システムのスペック的には問題がないという前提で、バックエンドのエジニアがどのようにWebサイトのレスポンスを上げるのに貢献できるか、例をいくつか挙げていきたいと思います。
地域密着型サイト
サイトを立ち上げる時に、どこのだれを対象にサイトを作るかというのはインフラをどこに作るかというのに密接にかかわってきます。例えば、東京で会社を立ち上げ主に東京にある企業向けの事業を始めるとします。立ち上げ当初はシンプルなサイトをとりあえず作りこむということにるすると、クラウドで東京リジョンにいくつかVMをたてこのような感じになります。
日本の国内であれば、東京以外のところからアクセスしても特にストレスを感じることはないかと思われます。
海外進出にむけて
事業を拡大して、カリフォルニアにに進出するとします。サイトを英語にするのはもちろんですが、アメリカのユーザーが東京のサーバーにそのままアクセスするとどうしてもストレスを感じます。どれだけページの構成をよくしても距離は短くはなりません。必要最小限で解決するには例えばAWSだとUS Westのカリフォルニアにあるリジョンに同じくVMを立てて、コンテンツのアップデートは東京から両方に行うとこのようになります。
この場合、一般的には東京からはwww.example.co.jp、ロサンゼルスからはwww.example.comというようにURLを別に設定する必要があります。良いかどうかは別として多くの企業でも採用されています。それぞれの国のドメインを使ったほうがユーザーにとっては慣れていて、受け入れやすいかもしれません。
GTMとDNS
会社のマーケティングの方針で、ドメインを国ごと設定せずにwww.example.comに統一することになったとします。現在の設定では、東京のユーザーがアメリカのサイトにアクセスすることになります。これでは以前の東京にだけシステムがあった時と同じ状態になります。東京とカリフォルニアにシステムを作り上げたので、それをそのまま利用してさらに東京とカリフォルニアのユーザーをそれぞれのリジョンのシステムにアクセスしてもらうためにDNSベースのGlobal Traffic Management（GTM:名前はプロバイダー、製品によって異なります）を使います。
ユーザーがwww.example.comのDNS Lookupをすると、GTMはユーザーが使用しているDNSサーバーとの距離などをもとに、ユーザーがどちらのリジョンにアクセスしたほうが良いかを決め、それぞれのシステムのIPアドレスをユーザーに返します。東京のユーザーは東京のシステムのIP、ロサンゼルのユーザーはカリフォルニアのシステムのIPを返されてそれぞれサイトにアクセスします。
これによってアドレスはwww.example.comに統一されたものの、それぞれユーザーが近くにあるシステムにアクセスできます。
DR対策
先ほどのセットアップによってDR（ディザスタリカバリ）対策にもなります。
例えば、災害の多い日本で何か起こって東京のシステムがアクセス不能になった場合、GTMがHealth Checkを行うことによって自動的に東京のシステムの障害を感知して、すべてのリクエストをカリフォルニアのシステムに送ることができます。東京のユーザーにとってはレスポンスは悪くなりますが、ダウンタイムよりはましです。
東京のシステム障害が復旧すると、GTMは自動的に感知して東京のユーザーは東京のシステムにアクセスするようになります。
CDN
事業をさらに拡大して、ヨーロッパや南米にも進出したとします。アメリア進出の時と同じようにそれぞれのリジョンにシステムを立ち上げ、同じようにGTMでそれぞれの地域のユーザーが近くのシステムにアクセスするようにすることもできますが、それでは管理するシステムの数も増えますし、コストも上がるかもしれません。また、これまでのようにVMを使っていたりするとメンテナンスもかなり複雑になりかねませんし、何よりも増える負荷に簡単には対応できなくかもしれません。
ですので今回はCDN（コンテンツデリバリネットワーク）とKubernetesをつかって両方の問題を解決します。
CDNもクラウドごとに提供されていますが、ここではAkamaiのCDNをモデルに進めていきます。GTMもCDNプロバイダーから提供されているサービスに変更します。
Kubernetes
今までのVMからKubernetesのクラスターに変更をしています。これによって、トラフィックが増えて負荷がかかるようなときは、自動的にリソースを増やしたりして対応できます。
また、これだけ事業が大きくなると、コンテンツも増えてCMS（コンテンツ管理システム）のアプリケーションやそのほかのアプリケーションも必要になってくるはずです。その場合、やはり従来のVMを使うよりKubernetesのほうがメンテナンスやアップグレード、普段のデプロイなど運用しやすくなり得ます。
キャッシュ
CDNには独自のネットワークを持って通信のスピードを上げている部分もありますが、最もわかりやすくサイトのレスポンスを良くするにはキャッシュを最大限に利用することだと思います。
上の例ですと、ロサンゼルスのユーザーはCDNを通してカリフォルニアのシステムにアクセスします。これによってCDN内のカリフォルニアの近辺にあるサーバーにコンテンツがキャッシュされます。（紺色の１と２）
次に、フランスのユーザーがアクセスした場合、CDNは近くのサーバーにキャッシュがないかを探します。あった場合は、そこからコンテンツを持ってきてユーザーに返します。またそのコンテンツもヨーロッパのCDN内のサーバーにキャッシュされます。近くにキャッシュがない場合は、カリフォルニアのシステムにアクセスします。（水色の１と２）
それ以降、同じ地域のユーザー、例えばドイツのユーザーが同じページをアクセスした場合、ヨーロッパのCDNのサーバーにすでにコンテンツはキャッシュされているので、そこから直接返ってきます。ですので、カリフォルニアにあるKubernetesのシステムにまでアクセスすることなくコンテンツを見ることがでるのでレスポンスもかなり上がるはずです。（赤色の１）
キャッシュは設定次第では全体の80-90％をキャッシュで返して、実際のシステムにかかる負荷はほんの10-20％だけと言ったこともできます。
これにより、大規模なシステムを作り上げるよりCDNを利用して負荷を分散し同時にサイトのレスポンスを高めることができたりします。
一番最初のリクエストだけは比較すると遅く感じるかもしれませんが、それ以降のリクエストは基本的にキャッシュで対応するのでレスポンスはかなりいいはずです。
最後に
いかがでしたでしょうか。上の例では細かいことには触れずにかなりシンプルに一例として、全世界のユーザーが対象のサイトを作る場合にどのようなことを考える必要があるか書いてみました。
これは、一例でほかにもレスポンスを良くするアイデアがいろいろとあると思います。
CDNを導入するとコスト的に上がってしまうかもしれませんが、レスポンスが良いことによってのユーザーからの高評価を考えると、費用対効果の面では十分に検討の価値のあるものです。
遠距離のユーザーを対象としているシステムを作られる場合は、ご検討されてはいかがでしょうか