「十分」は、十分でなくなるまでのこと

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

率直に話しましょう。七面鳥、クリームエッグ、キャンディの詰め合わせ。これらの共通点は何でしょうか。もちろん、どれも祝日に欠かせないものです。そして実は、こうした祝日は、利益を最も多く生み出す一方で、Webサイトのパフォーマンス低下を最も引き起こす時期でもあります。

英国で行われた最近の調査を見てみましょう。この調査は「100人を超えるeコマースの意思決定者を対象」としたもので、「半数以上（58%）が、前年のピーク期間中にWebサイトの速度に関する問題に直面したことを認めた」と報告しています。

パフォーマンスが重要であり、わずか数マイクロ秒の遅延でも数百万ドルの損失につながることは、周知の事実です。これ以上の説明は不要でしょう。

では、どのような対策ができるのでしょうか？

その答えは、運用上の公理#2「負荷が増加すると、パフォーマンスは低下する」を思い出せば見えてきます。

アプリケーションサーバーがクラウドとデータセンターのどちらで稼働しているか、仮想マシンとコンテナのどちらで稼働しているかは関係ありません。この原則が公理とされるのは、どのような場合にも必ず成り立つからです。システムにかかる負荷が増えるほど、動作は遅くなります。例外はありません。

パフォーマンス向上の鍵は、負荷を最大化してコストを抑えることと、パフォーマンスを最適化することのバランスを取ることです。多くの場合、特にシステムがどこにあっても大きな負担がかかるピーク時には、利用可能なあらゆるツールを活用して、そのバランスを取り戻す必要があります。

1. 負荷を分散する

だからこそ、「十分な」（初歩的な）アプリサービスでは不十分なのです。多くの場合、容易にスケールできても、利用可能なリソース間で負荷を実際に分散できるとは限りません。また、パフォーマンスや現在の負荷に基づいてリソースを選択するために必要なインテリジェンスが備わっているとも限りません。その「ベストエフォート」は、当てずっぽうと大差ありません。

負荷を分散するには、現在の負荷状況を把握し、新しいリクエストを最も迅速に応答できる可能性が高いリソースへ振り分ける必要があります。基本的なロードバランシングでは、利用可能なリソースの静的な重み付け以外の要素が考慮されることはほとんどなく、アルゴリズムに基づく判断のみに重点が置かれるため、これを実現できません。リアルタイムの判断には、まさに今存在する負荷についてのリアルタイム情報が必要です。そうでなければ、負荷を分散しているのではなく、単に負荷を振り分けているにすぎません。

2. 負荷を軽減する

負荷を分散しながらパフォーマンスを向上させるには、リソースの選択だけでは不十分です。可用性を損なうことなく、さまざまなプロトコル拡張機能を活用して負荷を軽減することも重要です。TCP接続の多重化と再利用、暗号化およびセキュリティ処理のオフロード、圧縮処理のアップストリームサービスへの移行により、アプリケーションサービスやWebサービスの負担が軽減され、リソースに余裕が生まれ、パフォーマンスが実質的に向上します。

サーバーは、クラウドとデータセンターのどちらに配置され、コンテナとVMのどちらで稼働していても、本来の処理に専念すべきです。暗号化と圧縮は依然として多くのコンピューティングリソースを必要とする機能ですが、これらの処理向けに設計された上流サービスで実行できます。

3. 負荷を解消する

リクエスト／レスポンスの経路から余分なホップをなくすことも、パフォーマンスの向上につながります。確かに、負荷分散サービスを複数配置して水平スケーリングすることは可能です。しかし、その場合は意思決定（ルーティング）のレイヤーが1つ増え、処理（このリクエストをどれに処理させるか）にも転送（ネットワーク経由でその1台に送る）にも時間がかかります。その分、Webサーバーやアプリサーバーが本来の処理に使える時間が減ってしまいます。そもそも、求めていたのはその処理です。通常の負荷では、1つのシステムで100万件の接続を管理する場合と、10のシステムで同じ接続を分担して管理する場合の差は、無視できる程度かもしれません。しかし、需要の増加によって負荷が高まれば、ここでも運用上の原則が当てはまります。パフォーマンス低下の原因となるのは、Webサーバーやアプリサーバーの負荷だけではありません。アプリケーションデリバリーチェーン全体が影響します。

ロードバランシングサービスが同時に処理できる容量（接続数）が大きいほど、必要なインスタンス数は少なくなります。これにより、他のサービスと同様に運用上の原則#2に細心の注意を払う必要があるリソース層を、さらに管理するオーバーヘッドを削減できます。

パフォーマンスは小売業者にとって引き続き大きな課題です。デジタル経済が急速に拡大するなか、デジタルプレゼンスを持つすべての組織にとって、まだそうなっていないとしても、いずれ課題となるでしょう。休暇前に必ず訪れる繁忙期には、パフォーマンスの低下に対する利用者の許容度がさらに下がります。前日まで十分だったパフォーマンスでも、通用しなくなります。多くの場合、パフォーマンスの問題はアプリケーション自体ではなく、その提供とセキュリティ確保に使用するアーキテクチャやサービスに起因します。適切な機能を備えた適切なサービスを利用することで、組織は高負荷時のパフォーマンス問題を回避しやすくなります。

「これで十分」は、十分でなくなるまでは通用します。しかし、その時にはもう手遅れです。不満を抱いたお客さまに戻ってきてもらおうとしても、すでに同じ商品やサービスを提供する別の事業者を見つけています。

著者について

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

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

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