レイテンシーの影響を受けやすいアプリケーションとは

すべてのアプリケーションや環境が、軽量で高度に分散されたワークロードの要求に対応できるように設計されているわけではありません。エッジコンピューティングは、ユーザーやデータソースが存在する場所またはその近くで行われるコンピューティングのことで、従来の一元化されたデータセンターやクラウドの外側に位置します。これは、さまざまなインフラストラクチャのアーキテクチャに存在します。計算リソースが限られているネットワークの最端で安価なポータブルデバイス (たとえば、スマートフォンやハンドヘルドのタブレットなどのモバイル・エッジコンピューティング・デバイス) が利用されています。 IDC はこれを「ライトエッジ」と呼んでいます。これに対する「ヘビーエッジ」は、大規模なサーバーと多数のユーザー (およびデータトランザクション) が存在するデータセンターまたはリモートオフィス構成のようなものです。

組織のインフラストラクチャがどれに該当するかに関係なく、共通のニーズと期待があります。基本的に、ユーザーとデバイスは、顧客の期待とパフォーマンスに関するサービスレベル契約 (SLA) を満たすためにリアルタイムでトランザクションを実行できる必要があります。つまり、これらの環境でアプリケーションが効果的なものであるためには、非常に具体的なパフォーマンス・ベンチマークを達成できる必要があります。このようなアプリケーションは、レイテンシーの影響を受けやすいアプリケーションと呼ばれます。

レイテンシーの影響を受けやすいアプリケーションとは何かを説明する前に、基本的な用語を定義します。

• レイテンシーとは、あるイベントが発生してから、そのイベントがシステムによって処理されるまでの時間です。A ポイントから B ポイントへの移動にかかる時間と考えるのが最も簡単です。
• 帯域幅 (またはネットワーク帯域幅) は、一定時間内に転送できるデータの量です。これは通常、1 秒あたりのメガビット数またはギガビット数です。一定時間内に転送されるデータの実際の量はスループットと呼ばれます。高帯域幅 (または高スループット) と低レイテンシーは、トレードオフと見なされることがあります。両方を同時に達成することは困難です。
• パケットは、転送されるデータ要素です。
• ジッターは、レイテンシーの変動のことをいい、通常、ネットワーク通信の一貫性が失われたり断続的に遅くなったりする場合に生じます。
• リアルタイムとは、特定の定義された時間 (通常はミリ秒またはマイクロ秒で測定) 内に操作が実行されることを意味します。リアルタイムは「非常に高速」という意味だと誤解されることがよくありますが、リアルタイムはより決定論的なものです。つまり、他の操作や負荷に関係なく、特定の時間的制約の範囲内での操作を保証するものです。リアルタイム処理では、複数のトランザクションをまとめて処理するバッチ処理とは異なり、各トランザクションは個別に処理されます。
• エッジノードは、一般に、エッジコンピューティングを実行できるデバイスやサーバーを指します。

レイテンシーは、システムの実際の応答時間を意図した応答時間と比較して測定する、時間ベースの指標です。通常、ネットワーク、ハードウェア、ファームウェア、およびオペレーティングシステムのパフォーマンスを、システム全体について個別に、またはまとめて評価します。レイテンシーの影響を受けやすいアプリケーションにとって好ましいのは低レイテンシーです。レイテンシーが低ければ、操作が開始されてから応答が返されるまでの遅延が短いからです。高レイテンシーの場合は、速度が遅くなるだけでなく、データの種類によってはパケットがドロップされたり失われたりする可能性があるため、好ましくありません。また、レイテンシーは安定している必要があります。平均レイテンシーが良好に見えても、ジッターが多すぎるとネットワークの信頼性が低下します。

エッジで使われるレイテンシーの影響を受けやすいアプリケーションの例は、AI 駆動の自動運転車です。搭載されているコンピュータが歩行者や物体などが道路上にあるかどうかを認識してコース修正を行うまでには、数ミリ秒しかありません。すべてのデータ処理と人工知能が、ゲートウェイやデータセンターに返されるライブテレメトリーとともに車両内に備わっている必要があります。これは極めて重要なアプリケーションです。クレジットカード決済やビデオ会議の処理における応答の遅延がエンドユーザーを苛立たせる一方で、自動運転での失敗は人生を変えてしまう可能性があります。IEEE (The Institute of Electrical and Electronic Engineers) は、レイテンシーの影響を受けやすいアプリケーションに対する多くの先進技術の依存状態に関する概要を述べています。

一般に、レイテンシーは速度の要因と見なされますが、システム全体のパフォーマンスの側面と捉える方が正確です。レイテンシーは、イベントが開始されてから完了するまでの時間で観測されます。また、この時間制限は、アプリケーションに応じて柔軟に設定できます。自動運転車はハードリミットの一例です。処理は瞬時に行われる必要があり、さもなければ重大なシステム障害が発生する可能性があります。

ワークロードの中には低レイテンシーを必要としないものもあります。言い換えると、操作の開始から応答までの時間は、許容できる程度に長くなり得ます。これらのワークロードは非同期です。つまり、開始から完了までの時間は観測できず、ユーザーにも関係ありません。たとえば E メールのようなサービスでは、E メールが送信されてから受信するまでに必要な時間をエンドユーザーが容易に認識することはないため、高レイテンシーが許容されます。

複雑な環境では、それが単一のシステムであろうと相互に作用する複数のシステムであろうと、レイテンシーの影響は累積します。操作を順番に完了する必要があるのか、並行して完了する必要があるのかに関係なく、主要な操作の合計レイテンシーがシステム全体の有効性に影響を与える場合があります。この場合、速度は主要な要素ではなく、一貫性が重要な指標になる可能性があります。これは確定的レイテンシーと呼ばれ、特定の操作に期待されるレイテンシー (またはすべての操作の合計レイテンシー) が予測可能で一貫していることを意味します。これは、フェーズドアレイレーダー、通信機器、製造機器など、複数のデバイスを同期する必要がある場合に極めて重要です。

端的に言えば、レイテンシーの影響を受けやすいアプリケーションは、機能上はリアルタイム・アプリケーションです。このようなアプリケーションでは、高レイテンシーや変動するレイテンシーがパフォーマンスに悪影響を及ぼすため、多くの場合マイクロ秒単位で測定される一定の時間内に操作が行われる必要があります。これらは、低レイテンシー・アプリケーションとも呼ばれます。

レイテンシーがパフォーマンスには影響するが動作が止まるわけではないアプリケーションを「レイテンシーの影響を受けやすいアプリケーション」とし、レイテンシーがあるポイントを超えた場合に障害が起こるアプリケーションを「レイテンシーが極めて重要なアプリケーション」とするとわかりやすいかもしれません。

レイテンシーはネットワーク・パフォーマンスの観点から説明されることが多いですが、レイテンシーの影響を受けやすいアプリケーションでは、ネットワークの品質だけがレイテンシーの原因ではないことがよくあります。処理時間に影響を与える要因は、レイテンシーにも影響します。

仮想化と仮想マシンでは、さまざまな仮想プロセスが、CPU リソースと、メモリーやストレージなどの共有リソースをめぐって互いに競合します。電源管理やトランザクション処理などのシステム設定でさえ、さまざまなプロセスがリソースにアクセスする方法に影響を与える場合があります。

同様の問題は、クラウド・コンピューティング環境でも起こり得ます。ハードウェア環境に存在する抽象化の層が増えるほど、コアアプリケーションの処理時間を最適化し、レイテンシーを最小限に抑える方法で、処理と共有リソースを割り当てることが難しくなる可能性があります。Amazon Web Services (AWS) のようなクラウドプロバイダーは、レイテンシーの影響を受けやすいアプリケーションとレイテンシーが極めて重要なアプリケーションのデプロイと最適化を提供する場合があります。

レイテンシーの影響を受けやすいアプリケーションを扱う場合、全体的な運用環境と基盤となるハードウェアは、ネットワーク・インフラストラクチャや信頼性を生み出すための設定と同じくらい重要です。

エッジ・アーキテクチャは、中央のデータセンターから同心円状に離れていくハードウェアの層を持つ、タマネギのようなものとして説明されることがよくあります。各層にはそれぞれ独自のアーキテクチャと考慮事項があり、これらのさまざまなユースケースには異なるソリューションが必要です。

エッジ・アーキテクチャの外輪は、顧客またはユーザーや管理対象デバイスなど、データを生成する相互作用に最も近いものです。これらのエッジは、変化する状況や新しいデータに対して高い応答性を備えている必要があり、したがって、レイテンシーの影響を受けやすいアプリケーションやリアルタイム・アプリケーションがデプロイされる可能性が最も高くなります。また、これらは共有データストアから最も離れた層であり、タブレットや IoT (モノのインターネット) デバイスなどの軽量で小規模なハードウェアが使用されることが多くなります。

これに関連して、IT リーダーはレイテンシーの影響を受けやすいアプリケーションと全体的なエッジコンピューティング環境のパフォーマンスを確実に維持するために、効果的なプロセスとポリシーを開発することができます。次のことを行う必要があります。

• 明確で一元化された開発とデプロイのパイプラインを保持する
• ソフトウェアとハードウェアの両方に一貫した更新ポリシーと管理ポリシーを適用する
• パフォーマンステストをすべてのパイプラインに統合する
• 可能な限り自動化する
• エッジ全体で一貫性を保つための標準運用環境を定義する
• 一貫性のあるオープン標準と手法を使用して相互運用性を確保する

これらのベストプラクティスは、産業用 IoT (IIoT)、HPC (高性能計算)、およびその他の分散アーキテクチャの場合と非常によく似ています。エッジや IoT は最終状態ではなく、特定の目標を達成するための手段です。同様に、レイテンシーの影響を受けやすいアプリケーションは、速いほど良いという理由だけで有益なのではありません。これらのアプリケーションは高速データ処理によって目的を果たすものであり、強力なカスタマーエクスペリエンスを作成したり、大型機器を安全かつ効率的に管理したり、変化する動作条件に対応したり、新しいインプットに適応したりするために役立ちます。

オペレーティングシステムは、物理的なデータセンターやサーバールームと同様に、エッジ環境やクラウド環境でも重要です。オペレーティングシステムは、レイテンシーの影響を受けやすいアプリケーションに不可欠なリソースのプロビジョニングや管理などのコア機能だけでなく、セキュリティやネットワーク構成などのその他の IT 要件も提供します。

レイテンシーの影響を受けやすいアプリケーションでの問題は、データセンターやクラウドで確認する必要があるデータの量に重点を置くか、アクティビティをローカルで実行するためにオフロードするべきかです。これは、データ量と速度のバランスです。

レイテンシーのリスクがローカル処理にある場合は、システムパフォーマンスの向上に役立つ特定のツールがあります。あるいは、さまざまなツールやテクノロジーを使用して、レイテンシーの影響を軽減するアーキテクチャを設計することもできます。

アーキテクチャでのレイテンシーへの対処

アプローチによっては、ネットワーク内のレイテンシーの要件がより重要になります。つまり、サービスを効果的に実行するにはエッジ・アーキテクチャが重要です。ネットワークレイテンシーがあるため、エッジ・アーキテクチャは、生データをデータセンターに送信して処理し、応答を送信するのではなく、エッジ自体でローカルにデータを処理できる必要があります。アプリケーションの処理をエッジにプッシュできることで、高レイテンシーのネットワークへの依存が軽減されます。

Red Hat® Enterprise Linux® for Distributed Computing は、エッジ向けに最適化された機能を提供し、データセンター、クラウド、エッジなど、オープンで一貫性のある運用環境を備えた分散型のハイブリッドクラウド・アーキテクチャ全体にアプリケーション・ワークロードをデプロイします。Red Hat Enterprise Linux for Distributed Computing をエッジのエンドポイントとゲートウェイにインストールすると、アプリケーションがローカルでデータを分析し処理できるようになると同時に、関連する更新とデータの知見をクラウドやデータセンターのサーバーに配信できます。これにより、高レイテンシーで帯域幅に一貫性がなく、接続が断続的であるネットワークへの依存度が低下します。

システムレイテンシーへの対処

レイテンシーの影響を受けやすい環境では、タイミングが重要です。適切に設計されたアーキテクチャであっても、エッジでローカル処理用の高性能システムを使用するのが賢明な判断です。

レイテンシーの影響を受けやすいアプリケーションには、高度に調整可能な運用環境が必要です。Red Hat Enterprise Linux for Real Time は、通常のパフォーマンス・チューニングの範囲を超えた予測可能性とスピードが必要とされる、レイテンシーの影響を受けやすい環境向けに設計されたアルゴリズムとサブシステムの変更を実装するために作成された特別なパッケージです。

Red Hat Enterprise Linux for Real Time には、リアルタイム・パフォーマンスを向上させるための主要な設定をサポートする低レベルのユーティリティが含まれています。

• ハードウェアおよびメモリーの構成と、並行プログラミング技術で作成されたアプリケーションを最適化する
• マルチスレッド・アプリケーション、マルチプロセス・アプリケーションの実行を制御する
• ハードウェアシステムの適合性を確認する
• キャッシュ動作を定義する

より大規模なエコシステムを利用する

これは、Red Hat エコシステムが特に力を発揮するエリアです。Red Hat Enterprise Linux for Real Time と Red Hat Enterprise Linux for Distributed Computing には認定済みのハードウェア構成とベンダーがあり、エッジアプリケーションが仕様どおりに動作するという確信を得ることができます。

さらに、Red Hat Enterprise Linux は、Kubernetes コンテナのオーケストレーションとデプロイに対応する Red Hat® OpenShift®、自動化に対応する Red Hat® Ansible® Automation Platform、プロセスと意思決定の管理、データストリーム、統合、およびその他のツール向けの Red Hat Middleware と統合されています。

エッジは、求められている知見とエクスペリエンスを瞬時に提供するための戦略なのです。Red Hat Enterprise Linux for Real Time と Red Hat Enterprise Linux for Distributed Computing を含め、Red Hat ポートフォリオは、その戦略を実現するための強力な基盤となります。