Nitro System のパフォーマンスチューニングに関する考慮事項

Nitro System は、AWS が構築した、高パフォーマンス、高可用性、高度なセキュリティを実現するハードウェアとソフトウェアコンポーネントのコレクションです。Nitro System は、ベアメタルのような機能を備えることで、仮想化オーバーヘッドを排除するとともに、ホストハードウェアへのフルアクセスを要求するワークロードをサポートします。詳細については、「AWS Nitro System」を参照してください。

現行世代の EC2 インスタンスタイプはすべて、ネットワークパケット処理を EC2 Nitro カードで実行します。このトピックでは、Nitro Card でのハイレベルなパケット処理、パケット処理のパフォーマンスに影響するネットワークアーキテクチャおよび設定の一般的側面、Nitro ベースインスタンスのパフォーマンスを最大化するために実行できるアクションについて説明します。

Nitro Card は、仮想プライベートクラウド (VPC) に必要な、すべての入出力 (I/O) インターフェイスを処理します。ネットワーク上で情報を送受信するすべてのコンポーネントで、Nitro Card は I/O トラフィック用の自己完結型のコンピューティングデバイスとして機能します。このコンピューティングデバイスは、顧客のワークロードを実行するシステムメインボードとは物理的に分離されています。

Nitro Card でのネットワークパケットフロー

Nitro System 上に構築された EC2 インスタンスには、1 秒あたりのパケット数 (PPS) スループットレートで測定されるよりも高速なパケット処理を可能にする、ハードウェアアクセラレーション機能があります。Nitro Card が新しいフローの初期評価を行うと、セキュリティグループ、アクセスコントロールリスト、ルートテーブルエントリなど、フロー内のすべてのパケットについて同じ情報が保存されます。同じフローの追加のパケットを処理する場合、保存した情報を使用することで、それらのパケットのオーバーヘッドを減らすことができます。

接続速度は 1 秒あたりの接続数 (CPS) で測定されます。新しい接続が発生するたびに、追加の処理オーバーヘッドが必要になるため、ワークロード能力の予測でそれを考慮する必要があります。ワークロードを設計するときは、CPS と PPS の両方のメトリクスを考慮することが重要です。

接続の確立方法

Nitro ベースのインスタンスと別のエンドポイントとの間で接続が確立されると、Nitro Card は 2 つのエンドポイント間で送受信される最初のパケットのフルフローを評価します。同じフローの後続のパケットについては、通常、完全な再評価は不要です。ただし、例外がいくつかあります。例外に関する詳細は、「ハードウェアアクセラレーションを使用しないパケット」を参照してください。

以下のプロパティは、2 つのエンドポイントとそれらの間のパケットフローを定義します。これら 5 つのプロパティを総合して、5 タプルフローと呼びます。

パケットフローの方向は、イングレス (インバウンド) とエグレス (アウトバウンド) と呼びます。以下は、エンドツーエンドのネットワークパケットフローの概要を示したものです。

最適なパフォーマンスが得られるようにネットワークを設計する

Nitro System のパフォーマンス機能を活用するには、ネットワーク処理のニーズを理解し、そしてそれらのニーズが Nitro リソースのワークロードにどのように影響するかを理解する必要があります。そうすれば、ネットワーク環境に最適なパフォーマンスを実現するように、設計することができます。インフラストラクチャ設定とアプリケーションワークロードの設計および構成は、パケット処理と接続速度の両方に影響を与える可能性があります。例えば、DNS サービス、ファイアウォール、仮想ルーターなど、アプリケーションの接続確立率が高いと、接続が確立された後にのみ発生するハードウェアアクセラレーションを利用できる機会が減ります。

アプリケーションとインフラストラクチャの構成を設定し、ワークロードを効率化して、ネットワークパフォーマンスを改善することができます。ただし、すべてのパケットがアクセラレーションの対象となるわけではありません。Nitro System は、新しい接続や、アクセラレーションの対象ではないパケットには、ネットワークフローをすべて使用します。

本セクションの残りの部分では、パケットが可能な限り高速パス内を流れるようにするための、アプリケーションとインフラストラクチャの、設計上の考慮事項に焦点を当てます。

Nitro システムのネットワーク設計に関して考慮すべき事項

インスタンスのネットワークトラフィックを設定するときは、PPS のパフォーマンスに影響するさまざまな側面を考慮する必要があります。フローが確立されると、定期的に送受信されるパケットの大半が、アクセラレーションの対象になります。ただし、インフラストラクチャ設計とパケットフローが引き続きプロトコル標準を満たすようにするため、いくつかの例外が存在します。

Nitro Card から最高のパフォーマンスを引き出すには、使用しているインフラストラクチャとアプリケーションに関する以下の設定の詳細の、長所と短所を慎重に検討する必要があります。

インフラストラクチャの考慮事項

インフラストラクチャの設定は、パケットフローと処理効率に影響を及ぼす可能性があります。以下は、重要な考慮事項の一覧です。

アプリケーションの設計に関する考慮事項

アプリケーションの設計と構成には、処理効率に影響する要素がいくつか存在します。以下は、重要な考慮事項の一覧です。

ハードウェアアクセラレーションを使用しないパケット

ハードウェアアクセラレーションは、すべてのパケットで利用できるわけではありません。これらの例外の処理には、ネットワークフローの状態を確認するために必要な、処理オーバーヘッドが伴います。ネットワークフローは、プロトコル標準を確実に満たし、VPC 設計の変更に従い、許可された宛先にのみパケットを送信する必要があります。ただし、オーバーヘッドはパフォーマンスを低下させます。

Nitro System でのネットワークパフォーマンスを最大化する

Nitro システムのネットワークパフォーマンスは、ネットワーク設定を調整することで最大化できます。

考慮事項

設計上の決定や、インスタンスのネットワーク設定の調整を行う際には、ベストな結果が得られるよう、事前に以下の手順を実行しておくことが推奨されます。

PPS パフォーマンスの調整

以下は、システムのニーズに応じて PPS のパフォーマンスを調整する際に活用できるアクションの一覧です。

Linux インスタンスのパフォーマンスを監視する

Linux インスタンスの Ethtool メトリクスを使用することで、帯域幅、パケットレート、接続トラッキングなどの、インスタンスのネットワークパフォーマンス指標を監視することができます。詳細については、「EC2 インスタンスでの ENA 設定のネットワークパフォーマンスのモニタリング」を参照してください。

ENA キュー

ENA キューは、インスタンスのタイプとサイズに基づくデフォルトの静的制限を用いてネットワークインターフェイスに割り当てられます。サポートされているインスタンスタイプでは、これらのキューを Elastic Network Interface (ENI) 全体に動的に割り当てることができます。インスタンスあたりのキューの合計数はインスタンスのタイプとサイズによって異なりますが、ENI キューは、ENI とインスタンスの最大キュー数に到達するまで複数の ENI に設定できます。

柔軟な ENA キューの割り当てはリソース配分を最適化するため、vCPU を最大限に活用できます。通常、ネットワークパフォーマンスの高いワークロードには複数の ENA キューが必要です。特定のワークロードニーズに応じてキュー数を調整することで、ネットワークパフォーマンスと 1 秒あたりのパケット数 (PPS) を細かく調整できます。例えば、ネットワーク集約型アプリケーションには CPU 集約型アプリケーションよりも多くのキューが必要になる場合があります。

サポートされているインスタンス

以下のインスタンスは、複数の ENA キューの動的な割り当てをサポートしています。

以下のコマンドを使用して、インスタンスが ENA キューの動的な割り当てをサポートしているかどうかを確認できます。

aws ec2 describe-instance-types --filters Name=network-info.flexible-ena-queues-support,Values=supported

Amazon EC2 ベアメタルインスタンスは、柔軟な ENA キューをサポートしていません。

ENA キューの可用性

利用可能な ENA キューの数は、インスタンスのタイプとサイズに基づいています。利用可能なキューの数を確認するには、以下のコマンドを使用します。

aws ec2 describe-instance-types --filters "Name=network-info.flexible-ena-queues-support,Values=supported" --query "InstanceTypes[*].[InstanceType,NetworkInfo.NetworkCards[*].DefaultEnaQueueCountPerInterface,NetworkInfo.NetworkCards[*].MaximumEnaQueueCount,NetworkInfo.NetworkCards[*].MaximumEnaQueueCountPerInterface]" --output json

インスタンス上のすべての ENI 全体で、DefaultEnaQueueCountPerInterface、MaximumEnaQueueCountPerInterface、および MaximumEnaQueueCount を利用できることがわかります。

キュー数の変更

ENA キューの数は、AWS Management Consoleまたは AWS CLI を使用して変更できます。AWS Management Consoleでは、各 [ネットワークインターフェイス] 設定に ENA キューの設定があります。

AWS CLI を使用して ENA キューの数を変更するには、次のコマンドのいずれかを使用します。キュー数を変更する前に、以下のコマンドを使用して現在のキュー数を確認してください。

aws ec2 describe-instances --instance-id i-1234567890abcdef0

attach-network-interface

以下の例では、ENI に 32 個の ENA キューが設定されます。

aws ec2 attach-network-interface \
  --network-interface-id eni-001aa1bb223cdd4e4 \
  --instance-id i-1234567890abcdef0 \
  --device-index 1 \
  --ena-queue-count 32

run-instances

以下の例では、3 個の ENI にそれぞれ 2 個の ENA キューが設定されます。

aws ec2 run-instances \
  --image-id ami-12ab3c30 \
  --instance-type c6i.large \
  --min-count 1 \
  --max-count 1 \
  --network-interfaces \
    "[{\"DeviceIndex\":0,\"SubnetId\":\"subnet-123456789012a345a\",\"EnaQueueCount\":2},
      {\"DeviceIndex\":1,\"SubnetId\":\"subnet-123456789012a345a\",\"EnaQueueCount\":2},
      {\"DeviceIndex\":2,\"SubnetId\":\"subnet-123456789012a345a\",\"EnaQueueCount\":2}]"

modify-network-interface-attribute

以下の例では、ENI に 32 個の ENA キューが設定されます。

aws ec2 modify-network-interface-attribute \
--network-interface-id eni-1234567890abcdef0 \
--attachment AttachmentId=eni-attach-12345678,EnaQueueCount=32

以下の例では、ENA 数がデフォルト値にリセットされます。

aws ec2 modify-network-interface-attribute \
--network-interface-id eni-1234567890abcdef0 \
--attachment AttachmentId=eni-attach-12345678,DefaultEnaQueueCount=true