アプリを高速化する

アプリケーションとそれが依存するネットワークを分割することでデータ センターを分割し続ける中で、ビジネス格言の 1 つは真実であり続けます。それは「スピードこそが王様」です。 パフォーマンスは、売上から生産性まであらゆるものに影響を及ぼし、少しずつ、時には最終的な利益を食いつぶす、ビジネスレベルの懸念事項です。

DZone の最近の記事「 2016 年の Web アプリケーションの速度はどの程度か」では、パフォーマンスに関する詳細が詳しく説明されており、「一般的な Web アプリケーションでは、トランザクションの 4.2% が放棄される」と指摘されています。 これは、「500 種類の異なる Web ベース アプリケーションを使用した 50 億回のユーザー インタラクション」に基づいています。

もちろん、それがどのように金銭に換算され、利益や生産性に影響を与えるかは、ビジネス モデルによって異なります。 これは、通話時間の増加による数百万ドルまたは数十億ドルの損失、または時間の損失、そして顧客の怒りを意味する可能性があります。

いずれにせよ、パフォーマンスは開発者と運用者の両方にとって重要な考慮事項です。 ここで言う運用とは、インフラストラクチャ、ネットワーク、ストレージ、セキュリティなど、すべての運用を指します。 当社の最新のアプリケーション配信の現状調査では、パフォーマンスが重要であるというすべての IT 役割の姿勢が引き続き支持されました。 セキュリティ向上のためにクラウドを放棄する可能性は最も低く（そのような取引に応じると答えたのはわずか 9%）、マルチクラウドの実装で直面する大きな課題として回答者の 14% が挙げました。

それにもかかわらず、現在アプリ高速化サービスを導入していると回答したのはわずか 38% で、来年中に導入する予定があると回答したのはわずか 22% でした。 やや意外なことに、40% の回答者がアプリ アクセラレーションを導入または使用する予定はないと回答しました。

これは、「アプリの高速化」が何を意味するのかという認識がやや曖昧だからかもしれません。 また、これは「クラウド」のせいでもありません。クラウドは長年にわたり、QoS からブラウザベースのデルタ更新やキャッシュ、そして実際にはパフォーマンスに重点を置いた機能を備えた特殊なプロキシであるアプリケーション フロント エンド (AFE) と呼ばれるものへと進化、変容してきたからです。

「アプリの高速化」を考えるとき、私たちはほとんどの場合、圧縮とキャッシュ、縮小、画像の最適化を思い浮かべます。 私たちは、プロトコルの最適化を、今日のビジネスやユーザーの期待に浸透している「ワープ 9 が必要だ、スコッティ」という考え方の一部とは考えていません。 しかし、そうすべきです。

ああ、最近はプロトコルオフロードがよく使われているようですね。 2015 年中に、クライアント側 SSL オフロード (ユーザーとの安全な HTTP を管理する側) の使用が 80% 弱からほぼ 100% に増加しました。 「Let's Encrypt!」や「SSL Everywhere」などの取り組みにより、安全な通信への注目が高まっていることを考えると、これは驚くことではありません。 SSL/TLS は、特に負荷が増加すると、パフォーマンスに影響を与えます (良い影響ではありません)。 有能なプロキシにオフロードすることは理にかなっており、組織がすべてを安全にすることによるパフォーマンスへの影響を相殺するためにまさにそれを実行しているのを目にしています。

しかし、バックエンド、サーバー側では同様の増加は見られません。 パフォーマンスを向上させる（そして同時にリソースの容量を増やす）ための TCP 多重化の使用は、過去 1 年間であまり変わっていません。 組織の約半数（一貫して約 46%）が、この知られざる最適化手法を使用しています。

同じ組織の多くが現在コンテナ熱に陥っていることを考えると、これは恐ろしいことです。

なぜ怖いのでしょうか？ 理由を説明しましょう... 仮想化によって組織が各インスタンスの TCP スタックを微調整し、アプリケーションごとに可能な限り最高のパフォーマンスを確保できるようになった可能性は十分にありますが、コンテナの登場によりそのモデルが脅かされています。 これは、コンテナが単一のネットワーク スタックを共有するためです。 1 つのコンテナーにデプロイされた 1 つのアプリをチューニングしても、同じホスト上の別のコンテナー内の別のアプリに対して最適な構成が保証されるわけではありません。

TCP 多重化などの TCP ベースの最適化はプロトコル層で動作するため、ハチドリのようなものです。 アプリがコンテナ内にあるか、仮想マシン内にあるか、あるいは Web プラットフォーム上にそのまま存在するかは問題ではありません。 アプリがどのように、どこに展開されているかに関係なく、接続を徹底的に調整し、パフォーマンスを向上させます。 このようなサービスはプロトコルのみを考慮し、クライアント側とサーバー側の分離を活用して、クライアント側がクライアント用に最適化され、サーバー側がアプリ用に最適化されることをさらに保証します。つまり、パフォーマンスが 2 倍向上します。

誤解しないでください。従来のアプリ高速化サービスとテクニックは素晴らしいものです。上記の色分けされたグラフからわかるように、組織はアプリケーションのパフォーマンスを向上させるためにこれらすべてを活用しています。 しかし、できることはまだたくさんあり、前述のパフォーマンス データが示すように、やるべきこと以上のことが行われています。

プロキシ（おそらく負荷分散のためだけに使用しているもの）を確認し、現在使用しているものよりもアプリのパフォーマンスを向上できるかどうかを確認することをお勧めします。

F5 がどのようにしてアプリをより高速、スマート、安全にするのかをご覧ください。