アプリを高速化

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

アプリケーションと、それを支えるネットワークの分割によってデータセンターの分散化が進むなかでも、「スピードが最優先」というビジネスの格言は変わりません。パフォーマンスは依然として、売上から生産性まであらゆる領域に影響を及ぼし、程度の差こそあれ収益を圧迫する、経営上の重要課題です。

DZoneに掲載された最近の記事「2016年のWebアプリケーションの速度」では、パフォーマンスについて具体的に掘り下げ、「一般的なWebアプリケーションでは、トランザクションの4.2%が途中で放棄されている」と指摘しています。これは、「500種類のWebベースアプリケーションにおける50億件のユーザー操作」に基づくデータです。

もちろん、それが金額に換算してどの程度になり、利益や生産性にどう影響するかは、ビジネスモデルによって異なります。数百万ドル、あるいは数十億ドル規模の損失につながる可能性もあれば、通話時間の増加によって時間が失われ、顧客の不満が高まる可能性もあります。

いずれにせよ、パフォーマンスは開発者と運用担当者の双方にとって、引き続き重要な検討事項です。ここでいう運用とは、あらゆる運用、つまりインフラストラクチャ、ネットワーク、ストレージ、セキュリティを指します。最新の「State of Application Delivery」調査でも、パフォーマンスが極めて重要であるという認識が、ITのあらゆる職務で引き続き示されています。セキュリティ向上のためにパフォーマンスを犠牲にすると回答した割合は最も低く（そのような選択をするのはわずか9%）、回答者の14%は、マルチクラウド導入で直面する重大な課題としてパフォーマンスを挙げています。

それにもかかわらず、現在アプリケーション高速化サービスを利用していると回答したのはわずか38%で、今後1年以内に導入を予定している回答者も22%にとどまりました。やや意外なことに、40%はアプリケーション高速化を導入または利用する予定はないと回答しました。

これは、「アプリケーション高速化」に何が含まれるのかが、やや曖昧に捉えられているためかもしれません。ここでいう曖昧さは「クラウド」によるものではなく、アプリケーション高速化が長年にわたり、QoSからブラウザベースの差分更新やキャッシュ、さらには、実際にはパフォーマンスを重視した機能を備える専用プロキシである、いわゆるアプリケーションフロントエンド（AFE）へと進化し、変化してきたことに起因します。

「アプリケーション高速化」と聞いて、多くの場合に思い浮かべるのは、圧縮やキャッシュ、ミニファイ、画像の最適化です。今日のビジネスやユーザーの期待に広く浸透している「スコッティ、ワープ9だ」という発想の一環として、プロトコルの最適化を捉えることはあまりありません。しかし、捉えるべきです。

最近では、プロトコルのオフロードが広く利用されています。2015年には、クライアント側（ユーザーとのセキュアなHTTP通信を管理する側）でのSSLオフロードの利用率が、80%弱からほぼ100%に増加しました。「Let’s Encrypt!」や「SSL Everywhere」といった取り組みにより、セキュアな通信への関心が高まっていることを考えれば、これは驚くことではありません。SSL/TLSは、特に負荷が増大するとパフォーマンスに悪影響を及ぼします。高性能なプロキシにオフロードすることは合理的であり、あらゆる通信をセキュアにすることによるパフォーマンスへの影響を軽減するために、実際に多くの組織がこの方法を採用しています。

しかし、バックエンド、つまりサーバー側では、同様の増加は見られません。パフォーマンスを向上させる（と同時にリソース容量を増やす）TCP多重化の利用率は、この1年間ほとんど変化していません。組織の半数弱（継続して約46%）が、このあまり注目されていない最適化手法を利用しています。

同じ組織の多くが現在、コンテナ熱に浮かされていることを考えると、これは懸念すべき状況です。

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

TCP多重化のようなTCPベースの最適化はプロトコル層で機能するため、ラーテルのように周囲を気にしません。アプリがコンテナ内にあっても、仮想マシン内にあっても、Webプラットフォーム上で直接稼働していても関係ありません。アプリの導入方法や場所を問わず、接続を徹底的にチューニングしてパフォーマンスを向上させます。このようなサービスが重視するのはプロトコルだけです。さらに、クライアント側とサーバー側が分離されていることを活用し、クライアント側はクライアント向けに、サーバー側はアプリ向けに最適化します。つまり、両側でパフォーマンスを向上できます。

従来のアプリケーション高速化サービスや手法が優れていることに異論はありません。上の多色グラフからも分かるように、組織はアプリケーションのパフォーマンスを向上させるために、それらをすべて活用しています。しかし、できることはほかにもあります。そして、前述のパフォーマンスデータが示すとおり、取り組むべきことはさらに多くあります。

プロキシ（おそらく現在は負荷分散にしか使用していないもの）を見直し、アプリのパフォーマンス向上にさらに活用できないか確認することをお勧めします。

F5がアプリをより高速に、よりスマートに、より安全に動作させる仕組みをご覧ください。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事