ネットワークによりアプリケーションのパフォーマンスを大幅に向上させるための5つのヒント

Please find the English language post, by Lori MacVittie, from which this was adapted here.

本番環境へのアプリケーションの展開は最初のステップにすぎません。優れたユーザ エクスペリエンスの提供こそが次のステップでは重要になります。つまりネットワーク側で行う作業があるということです。そこで登場するのがNetOpsです。

テーマとしているのが利益であっても生産性であっても、どちらもパフォーマンスの低いアプリから同じように影響を受けます。参考として企業のアプリの応答時間に基づく放棄率（アバンダンレート）、可用性とパフォーマンスに基づく採用率（アドプションレート）を示すチャートを示すことができますが、よく目にする情報であり、それが事実であることは明らかです。ネットワークのセキュリティを高めるために犠牲にしているものを組織に尋ねると、「パフォーマンス」であると回答した組織は最も少なく、全体の10%未満でした。

スピード（の不足）が "致命的" ということです。

アプリケーションの開発者に改善を要求したいところですが、ほとんどの場合、開発者はスピード（アプリケーション配信が完了されるまでの迅速性）について対処しようがないのが現実です。遅延がネットワークで生じているのは、アプリケーションによって通信に使用されるプロトコルなど、さまざまな要因によるためです。

実際、こんな現実もあります。TCPに関連する100以上のRFCがあるように、われわれの多くは、アプリケーションのパフォーマンスの向上ではなく、信頼性に重点を置いて設計されたプロトコルの性能向上に尽力し続けています。

もちろん、アプリケーション展開先のプラットフォームにかかわらずTCPスタックを調整できますが（ここはDevOpsチームが関与する領域）、ネットワークではさらに上位層にも対処すべきサービスが数多くあります（ここがNetOpsチームの活躍する領域です）。ここでは、アプリケーションのパフォーマンスの向上に役立つ可能性のある "ネットワーク"サービスについて5つのヒントを挙げます。

パフォーマンスに関するヒント#1：可用性サービスで使用されているロードバランシングアルゴリズムを確認する。

使用されているロードバランシングアルゴリズムを確認します。たとえば、ラウンドロビンは最も基本的なアルゴリズムであり、アプリケーションの個々のインスタンスに関するパフォーマンスや負荷は考慮されません。"負荷が増えるにつれてパフォーマンスは下がる" という運用上の原理からすると、負荷や応答時間に基づいたアルゴリズムの採用によりパフォーマンスが向上する可能性があります。

パフォーマンスに関するヒント#2：キャッシング可能なコンテンツヘッダがあるかどうかを確認し、ない場合にはインテリジェントなパフォーマンスサービスを使用して、それらのヘッダを追加する。

開発者がコンテンツをキャッシング可能として適切にマーキングしていない場合がよくあります。アウトバウンド応答にキャッシング可能なヘッダを自動的に挿入できるアプリケーションサービスを使用すれば、わずらわしいラウンドトリップが不要になり、重複したコンテンツが取得されないため、全体的なパフォーマンスが向上します。  

パフォーマンスに関するヒント#3：TCP多重化を使用して、アプリの応答時間から高コストなセッション管理にかかる時間を省けるかどうかを確認する。

TCPのオーバーヘッドによっても通信ストリームに遅延が生じることがあり、エンド ユーザ側の全体的なパフォーマンスに悪影響を与えます。TCP多重化を利用することで、TCPセッション管理が可用性サービスにオフロードされ、ページごとの大量のHTTPリクエストの受信と応答にかかる時間が短縮されます。

パフォーマンスに関するヒント#4：パフォーマンスサービスでデバイスタイプに基づいて画像の最適化を有効にする。 

画像は頻繁に使用されますが、必ずしも配信先のデバイスに合わせて最適化されているとは限りません。これはアプリ開発者の責任ではありません。配信先がモバイル デバイスの場合、画像の最適化は一般的に、画像がより小さく表示されるように、HTML要素の属性を変更するだけでは済みません。実際のコンテンツの操作、この場合はEXIFデータの削除も必要です。それにより実際、画像はサイズが小さくなり、転送時間が短くなります。その結果、画像の転送が完了するまで、Webアプリに "X" が代わりに表示されることはなくなります。パフォーマンスサービスには一般的に、チェックボックスだけで有効にすることのできる画像最適化機能が用意されています。

パフォーマンスに関するヒント#5：すべてのアプリケーションサーバのフォークリフトアップグレードを行うことなく、HTTP/2またはSPDYゲートウェイを使用してユーザエクスペリエンスを向上させることを検討する。

HTTP/1が役目を終える時が来たようです。かといって、HTTP/2またはSPDYをサポートするために既存のすべてのアプリケーションサーバを丸ごと置き換えるのは現実的ではありません。代わりに、それらのサーバの外部からHTTP/2、SPDY、またはその両方をサポートできます。ネットワークに接続されたHTTP/2およびSPDYゲートウェイは、パフォーマンスに基づくこれらの新しいプロトコルをサポートできると同時に、データセンタ内のすべてのアプリケーションに対する安全なHTTP/1通信も継続できます。どちらのプロトコルでも、ヘッダが圧縮されてHTTPストリームがより効率的に使用されるため、アプリケーションのパフォーマンスが大幅に向上する可能性があります。 

これらのすべてのサービスは一般的に "ネットワーク" で稼働しています。それらのサービスはDevOpsが担当するアプリケーションインフラストラクチャに含まれないため、重要なのは、ネットワークチーム（この記事ではNetOpsと定義）が運用担当者と開発担当者とのコラボレーションに参加して、運用環境への移行後のアプリケーションのパフォーマンスを向上させるために何が役立つかを検討することです。役立つであろうと考えた選択肢が、実はまったく役立たない場合があります。つまり、パフォーマンスの実際の向上を目指すには、監視と評価、とりわけ他のチームとの情報交換が必要になります。

また重要なのは、これらのネットワークサービスをできる限り迅速に対象のアプリケーションにプロビジョニングして、DevOpsの多くの考え方を活かせるようにすることです。これらのサービスのプロビジョニングを可能にすることは市場投入に不可欠ですが、市場投入後にそれらのサービスを監視、評価、調整することは、ビジネスに求められる利益と生産性の向上を実現するために重要です。

魅力あるアプリケーションを競合に先駆けて市場に投入するのは、市場でトップを維持することよりも簡単です。投入後に、最高のパフォーマンスを発揮するアプリケーションを目指せばよいのです。

 

最終更新日：2014年12月14日