エンドユーザー向けのapplicationエクスペリエンスの最適化: 変化する風景
インターネットは、その誕生以来、テクノロジーと市場の力の進歩に牽引されて、application配信プロセスの改善や双方向性の向上など、かつてないほど速いサイクルで進化してきました。 企業と政府は、ユーザーの期待と競争圧力に応えるために努力する必要があります。 ユーザー エクスペリエンスを妨げていた古いテクノロジ (Adobe Flash、HTTP/1.x など) は廃止され、ユーザー エクスペリエンスにさらに適合した新しいテクノロジ (HTML5 など) が取って代わりました。
このホワイト ペーパーでは、ユーザー エクスペリエンスに影響を与える最近の変更点のいくつかを定量化し、2017 年以降の運用と計画のために IT グループが理解しておくべき点を説明します。
- コンテンツ配信ネットワーク（CDN）の普及
- データセンターとサービスプロバイダーのネットワークのアップグレード
- より高速な「ラストマイル」とモバイルアクセス
- パフォーマンスを重視して設計されたHTTPプロトコルの更新
- クライアントとサーバーの関係の進化
CDN ベンダーは、ユーザーへのコンテンツ配信の遅延 (多くの場合、約 30 ミリ秒) を削減するために、主に人口密集地付近で運用するポイント オブ プレゼンス (PoP) の数を急速に拡大しています。 以下は、コンテンツの高速配信を保証するために世界中にインフラストラクチャを構築した最も人気のある CDN のリストです。1
CDN が運用する PoP の数とユーザーとの距離が拡大し、applicationsのユーザー ベースがグローバル化するにつれて、Web サイトは CDN への依存度を高めています。 2015 年 3 月時点で、インターネットで利用可能な HTML コンテンツの 11% が CDN でホストされていました。2 2016 年には、その数は 17% に増加し、2017 年 3 月時点では、CDN でホストされる HTML コンテンツは最大 20% に達しました。 2 年足らずで、CDN でホストされる HTML コンテンツの量はほぼ 2 倍になり、この傾向により、ユーザーへのコンテンツ配信の待ち時間が大幅に短縮されました。
10G/40G/100G イーサネット ポート (および対応する大容量スイッチとルーター) の実装により、企業ネットワーク、WAN 接続、およびリモートにあるエンドポイントのインターネット パフォーマンスが大幅に向上しました。 今後 4 年間で、企業およびサービス プロバイダーのネットワークは 25G および 100G 接続へのアップグレードを継続し、帯域幅容量は 2015 年と比べてほぼ 5 倍にアップグレードされます。3
データ センターとエッジ インフラストラクチャのアップグレードへの投資により、サービス プロバイダー ネットワークとエンタープライズ データ センターがクライアントに向かうapplicationトラフィックのボトルネックになるという問題が軽減されました。
競争の激化により、世界中のインターネット サービス プロバイダー (ISP) とモバイル キャリアは、「ラスト マイル」(顧客に接続を提供する通信ネットワークの最終区間) とモバイル ユーザーのダウンロード速度を向上させました。 以下は、2015 年の米国、アジア、ヨーロッパの ISP のダウンロード パフォーマンスを示すグラフです。4
世界中で、インターネット接続の「ラストマイル」は以前よりもはるかに高速になり、現在利用可能な帯域幅は、Webapplicationsのユーザー エクスペリエンスの向上に役立ちます。
HTTP/2 仕様の開発は、主に HTTP1.x のパフォーマンスの問題によって推進されました。 2012 年、Google は Web コンテンツの配信を最適化し、以前の HTTP 1.1 プロトコル設計の非効率性を解消するためにSPDYを開発し、普及させました。 HTTP/2 は SPDY をベースに構築されており、HTTP/1.1 との互換性を維持しながら、遅延と TCP 接続の数を減らすことに主眼を置いています。
パフォーマンス向上を目的として、HTTP/2 プロトコルには次の変更が含まれています。
- 多重化: 単一の TCP 接続で複数のやり取りを可能にします (SPDY が提供したものと同様)。
- ヘッダー圧縮: 同じヘッダー (リクエスト URL、ユーザーエージェント、Cookie など) を繰り返し送信することによる冗長性を削減します。
- サーバープッシュ: 要求されたコンテンツとソースの依存関係 (JS ファイルや CSS ファイルなど) に基づいて、サーバーからエンドポイントにコンテンツをプロアクティブにプッシュできるようにします。
- リソースの優先順位付け: 重みと依存関係を使用してタイプ/コンテンツに基づいて配信を優先順位付けし、配信とレンダリングを最適化します。
主要な Web ブラウザー ベンダーは、2015 年半ばに IETF によってプロトコル仕様が承認された後、HTTP/2 サポートを組み込むスケジュール (下の表を参照) を発表しました。
エンドポイント Web ブラウザーから Web サーバーへの HTTP/2 リクエストは 2016 年初頭に開始され、新しい仕様に対応した Web ブラウザーのリリースと採用に伴って増加しました。 更新された Web ブラウザから Web サーバーへのリクエストは、最初に HTTP/2 で行われ、その後 HTTP/1.x へのネゴシエーションが行われます。 下の図では、世界中の Web サイトからの HTTP/2 相互作用 (サーバーとエンドポイント間) の増加の詳細を示しています。5
HTTP/2 仕様の強化により、HTTP/1.x ベースのインフラストラクチャよりも 80% ～ 1000% 高速なパフォーマンスが実現します。 仕様の変更が実際のパフォーマンスにどのような影響を与えるかを知るには、これを実行してください。 シンプルな HTTP と Anthum からの HTTPS テスト 2 つのプロトコル バージョン間の違いを示します。
これらのインフラストラクチャとプロトコルの改善に加えて、applicationsの実際の構成も変化しています。 古いapplicationsではすべてがクライアントに「プッシュ」されていたため、「フロントエンド」の高速化が必要でしたが、最新のアプリは 2 つの主要コンポーネント (クライアントとサーバー) に分散されており、applicationとのやり取り (API 経由またはブラウザー経由) の 90% は小さなデータ チャンクで処理されます。
最初の読み込み以降に配信される「コンテンツ」はごくわずかです。プレゼンテーション層 (UI) のほとんどは、クライアントの JavaScript ライブラリ (JQuery、Angular など) を介して操作できます。 つまり、応答内のデータの量と種類（フロントエンド アクセラレーション テクノロジーの主なターゲット）は大幅に減少し、現在は HTML ではなく JSON または XML が主流になっています。
このアーキテクチャの変化により、現在、アプリにおける HTML の割合は減少し、他の構成タイプは増加しています (下の図を参照)。6
大量の JavaScript (および HTML) が CDN 経由で配信されているため (開発者はスクリプトをローカルではなくインターネットから組み込むため)、このコンテンツをターゲットとするフロントエンドの高速化手法は、最新のapplicationsにとってそれほど重要ではなくなります。
モバイル デバイスの普及と、以前のテクノロジ (Adobe Flash など) から HTML5 への移行に伴い、ITapplicationsグループはブラウザーに配信されるシングル ページ Webapplicationsの開発を開始しました。 これらのシングルページ Webapplicationsでは、通常、ユーザーがapplicationのさまざまな部分を移動するときにページを再読み込みする必要はありません。 その結果、ナビゲーションが高速化し、ネットワーク転送がより効率的になり、エンドユーザー エクスペリエンスが向上します。7 今日、Web アプリの大部分は「ワンページ」デザインを念頭に置いて開発されています。
IT 運用の管理下にある Web ベースのapplicationsに対して理想的なエンド ユーザー エクスペリエンスを作成し、維持するには、次のテクノロジとプラクティスを採用する必要があります。
Web サーバーを HTTP/2 プロトコルで標準化します。
Web インフラストラクチャを HTTP/2 標準にアップグレードすると、HTTP/1 および HTTP/1.1 で発生していたサーバー側のパフォーマンスの問題が解決されます。 HTTP/2 では、接続管理が改善されるだけでなく、Webapplication設計者は優先順位を付けて、エンドポイント Web ブラウザー内でのコンテンツ配信と構築を最適化できるようになります。
HTTP/2 ベースのリクエストのみが実行されるように、Web ブラウザの最小標準を設定します。
内部（従業員や請負業者など）または外部（顧客やパートナーなど）に、ブラウザを HTTP/2 リクエストをサポートするバージョンにアップグレードするよう促すことで、HTTP/1.1 または 1.0 への自動ネゴシエーションがなくなり、データ転送の効率が低下します。
SaaS ベンダーがすべての Webapplicationsにわたって HTTP/2 を実装していることを確認します。
繰り返しになりますが、HTTP/1.1 および 1.0 への自動ネゴシエーションを回避することで、パフォーマンスが向上し、ユーザー エクスペリエンスが向上します。
CDN ベンダーが、ユーザーと顧客の所在地に合わせて地理的に PoP を配置していることを確認します。
従業員、請負業者、顧客に合わせて地理的に調整された PoP ネットワークを持つ CDN ベンダーを利用すると、Web ブラウザーと CDN PoP 間のやり取りの遅延が短縮されます。
ネットワークベースのアプライアンスでのキャッシュ テクノロジを検討してください。
applicationsの前にあるオンボード キャッシュ テクノロジ ネットワーク アプライアンスを活用すると、Web ページ内で必要な静的コンテンツのパフォーマンスが向上します。
低コストのオープンソース Web キャッシュを評価します。
キャッシュが必要な場合は、 Varnishなどの低コストで高性能な SSD 搭載のオープンソース Web キャッシュの使用を検討してください。
ビジネス要件とモバイルおよびクラウド コンピューティングへの移行により、重要なapplicationsを提供しながらユーザー エクスペリエンスを最適化するというプレッシャーが IT グループにますます高まっています。 現在、ユーザーが Web コンテンツを体験する方法を変える要因は 3 つあります。 CDN の容量は大幅に拡大し、POP がコア ユーザー ベースに近いため、レイテンシが短縮されます。 第二に、インターネット プロトコルが更新され、Web サーバーからクライアントへの全体的なパフォーマンスが向上しました。 3 番目に、インターネット サーバーとクライアントの関係が変化し、両者間のトランザクションが以前ほど一方的ではなく、配信されるデータがより動的でユーザー固有のものになりました。 こうした変化を踏まえると、フロントエンドのapplication配信を最適化してユーザーエクスペリエンスを向上させるために 5 ～ 7 年前に作成された戦略は、市場の力と Web テクノロジーの自然な進化によって急速に価値が下がっています。
エンタープライズ Webアプリケーション インフラストラクチャは、市場の変化に合わせて進化する必要があります。そうしないと、パフォーマンスと IT 投資収益率が低下してしまいます。 IT 部門にとって重要なのは、ユーザー エクスペリエンスを提供するインフラストラクチャ (Web サーバー、ロード バランサー、CDN、SaaS など) を、Web パフォーマンスの向上を目的として設計された HTTP/2 にアップグレードすることです。
1 http://www.cdnplanet.com/cdns/
2 http://httparchive.org/
3 https://technology.ihs.com/589721/data-center-network-equipment-market-tracker-regional-q2-2017
4 https://www.stateoftheinternet.com/resources-connectivity-2015-q1-state-of-the-internet-report.html
5 https://w3techs.com/technologies/details/ce-HTTP/2/all/all
6 http://httparchive.org/
7 https://techcrunch.com/2012/11/30/why-enterprise-apps-are-moving-to-single-page-design/
F5とつながる
