# Nitro System のパフォーマンスチューニングに関する考慮事項
Nitro System は、AWS が構築した、高パフォーマンス、高可用性、高度なセキュリティを実現するハードウェアとソフトウェアコンポーネントのコレクションです。Nitro System は、ベアメタルのような機能を備えることで、仮想化オーバーヘッドを排除するとともに、ホストハードウェアへのフルアクセスを要求するワークロードをサポートします。詳細については、「[AWS Nitro System](https://aws.amazon.com/ec2/nitro/)」を参照してください。
現行世代の 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 つのエンドポイント間で送受信される最初のパケットのフルフローを評価します。同じフローの後続のパケットについては、通常、完全な再評価は不要です。ただし、例外がいくつかあります。例外に関する詳細は、「[ハードウェアアクセラレーションを使用しないパケット](#ena-nitro-perf-exceptions)」を参照してください。
以下のプロパティは、2 つのエンドポイントとそれらの間のパケットフローを定義します。これら 5 つのプロパティを総合して、5 タプルフローと呼びます。
+ [Source IP] (送信元 IP)
+ ソースポート
+ 送信先 IP
+ 発信先ポート
+ 通信プロトコル
パケットフローの方向は、イングレス (インバウンド) とエグレス (アウトバウンド) と呼びます。以下は、エンドツーエンドのネットワークパケットフローの概要を示したものです。
+ **イングレス** — Nitro Card は、受信ネットワークパケットを処理するとき、パケットをステートフルファイアウォールルールとアクセス制御リストに照らして評価します。接続を追跡し、測定し、必要に応じてその他アクションを実行します。次に、パケットをホスト CPU 上の宛先に転送します。
+ **エグレス** — Nitro Card は、アウトバウンドネットワークパケットを処理するとき、リモートインターフェイスの宛先を検索し、さまざまな VPC 機能を評価し、レート制限を適用して、適用されるその他アクションを実行します。次に、パケットをネットワーク上の次のホップの宛先に転送します。
## 最適なパフォーマンスが得られるようにネットワークを設計する
Nitro System のパフォーマンス機能を活用するには、ネットワーク処理のニーズを理解し、そしてそれらのニーズが Nitro リソースのワークロードにどのように影響するかを理解する必要があります。そうすれば、ネットワーク環境に最適なパフォーマンスを実現するように、設計することができます。インフラストラクチャ設定とアプリケーションワークロードの設計および構成は、パケット処理と接続速度の両方に影響を与える可能性があります。例えば、DNS サービス、ファイアウォール、仮想ルーターなど、アプリケーションの接続確立率が高いと、接続が確立された後にのみ発生するハードウェアアクセラレーションを利用できる機会が減ります。
アプリケーションとインフラストラクチャの構成を設定し、ワークロードを効率化して、ネットワークパフォーマンスを改善することができます。ただし、すべてのパケットがアクセラレーションの対象となるわけではありません。Nitro System は、新しい接続や、アクセラレーションの対象ではないパケットには、ネットワークフローをすべて使用します。
本セクションの残りの部分では、パケットが可能な限り高速パス内を流れるようにするための、アプリケーションとインフラストラクチャの、設計上の考慮事項に焦点を当てます。
### Nitro システムのネットワーク設計に関して考慮すべき事項
インスタンスのネットワークトラフィックを設定するときは、PPS のパフォーマンスに影響するさまざまな側面を考慮する必要があります。フローが確立されると、定期的に送受信されるパケットの大半が、アクセラレーションの対象になります。ただし、インフラストラクチャ設計とパケットフローが引き続きプロトコル標準を満たすようにするため、いくつかの例外が存在します。
Nitro Card から最高のパフォーマンスを引き出すには、使用しているインフラストラクチャとアプリケーションに関する以下の設定の詳細の、長所と短所を慎重に検討する必要があります。
#### インフラストラクチャの考慮事項
インフラストラクチャの設定は、パケットフローと処理効率に影響を及ぼす可能性があります。以下は、重要な考慮事項の一覧です。
**非対称ネットワークインターフェイス構成**
セキュリティグループは、接続追跡を使用して、インスタンスに出入りするトラフィックの情報を追跡します。トラフィックが特定のネットワークインターフェースからインスタンスに入り、別のネットワークインターフェースから外に出る、非対称ルーティングでは、フローを追跡した場合に、インスタンスが達成できるピークパフォーマンスが低下する可能性があります。セキュリティグループの接続トラッキング、追跡されない接続、自動的に追跡される接続の詳細については、「[Amazon EC2 セキュリティグループの接続の追跡](security-group-connection-tracking.md)」を参照してください。
**ネットワークドライバー**
ネットワークドライバーは、定期的に更新されリリースされています。ドライバーが古くなっていると、パフォーマンスが大幅に低下する可能性があります。最新のパッチを適用して、最新世代のドライバーのみで利用できるアクセラレーションパス機能などのパフォーマンス強化を活用できるよう、ドライバーを常に最新状態に保つようにします。旧世代のドライバーでは、アクセラレーションパス機能はサポートされていません。
アクセラレーションパス機能を利用するため、最新の ENA ドライバーをインスタンスにインストールすることが推奨されます。
**Linux インスタンス** – ENA Linux ドライバー 2.2.9 以降。Amazon Drivers GitHub リポジトリから ENA Linux ドライバーをインストールまたは更新するには、readme ファイルの「[ドライバーのコンパイル](https://github.com/amzn/amzn-drivers/tree/master/kernel/linux/ena#driver-compilation)」のセクションを参照してください。
**Windows インスタンス** – ENA Windows ドライバー 2.0.0 以降。ENA Windows ドライバーをインストールまたは更新するには、「[EC2 Windows インスタンスに ENA ドライバーをインストールする](ena-adapter-driver-install-upgrade-win.md)」を参照してください。
**エンドポイント間の距離**
同じアベイラビリティーゾーン内の 2 つのインスタンス間の接続は、リージョン間の接続よりも 1 秒あたりで多くのパケットを処理できます。これは、アプリケーション層での TCP ウィンドウ処理により、いつでも送信できるデータの量が決定されるためです。インスタンス間の距離が長いとレイテンシーが長くなり、エンドポイントで処理できるパケットの数が減少します。
**バイトキュー制限 (BQL)**
BQL は、Nitro Card に渡されるバイト数を制限してキューイングを減らす機能です。BQL は、ENA ドライバー、Amazon Linux オペレーティングシステム、およびほとんどの Linux ディストリビューションでデフォルトで無効になっています。BQL とフラグメントプロキシの上書きの両方が有効になっている場合、すべてのフラグメントが処理される前に Nitro に渡されるバイト数が制限されることにより、パフォーマンスが低下する可能性があります。
#### アプリケーションの設計に関する考慮事項
アプリケーションの設計と構成には、処理効率に影響する要素がいくつか存在します。以下は、重要な考慮事項の一覧です。
**バケットサイズ**
パケットサイズを大きくすると、インスタンスがネットワーク上で送受信できるデータのスループットが増加します。Amazon EC2 では 9001 バイトのジャンボフレームがサポートされますが、他のサービスでは異なる制限が適用される場合があります。パケットサイズを小さくすると、パケットの処理速度は上がりますが、パケット数が PPS の許容値を超えたときに達成される最大帯域幅が、減少する可能性があります。
パケットのサイズがネットワークホップの最大転送単位 (MTU) を超えると、パス上のルーターがパケットをフラグメント化する可能性があります。生成されたパケットフラグメントは例外とみなされ、通常は標準速度 (高速ではない) で処理されます。これにより、パフォーマンスにばらつきが生じる可能性があります。ただし、フラグメントプロキシモード設定を使用して、アウトバウンドフラグメントパケットの標準の動作を上書きできます。詳細については、「[Nitro System でのネットワークパフォーマンスを最大化する](#ena-nitro-perf-maximize)」を参照してください。MTU を設定するときは、トポロジを評価することが推奨されます。
**プロトコルのトレードオフ**
TCP のような信頼性の高いプロトコルは、UDP のような信頼性の低いプロトコルよりもオーバーヘッドが大きくなります。UDP トランスポートプロトコルの低いオーバーヘッドとシンプルなネットワーク処理により、PPS レートを高くすることができますが、信頼性の高いパケット配信が犠牲になります。アプリケーションにとって信頼性の高いパケット配信が重要でない場合は、UDP が適しているかもしれません。
**マイクロバースティング**
マイクロバーストは、トラフィックが均等に分散されているときではなく、短時間で許容値を超えたときに発生します。通常これは、マイクロ秒単位で発生します。
例えば、最大 10 Gbps を送信できるインスタンスがあり、アプリケーションが 10 Gb を 0.5 秒で送信するとします。このマイクロバーストは最初の 0.5 秒で許容値を超え、残りの時間には何も残りません。10 Gb を 1 秒以内に 送信したとしても、最初の 0.5 秒間に余裕があると、パケットがキューに入れられたりドロップされたりする可能性があります。
Linux Traffic Control などのネットワークスケジューラを使用すると、スループットを調整でき、マイクロバーストによってパケットがキューに入れられたりドロップされたりすることを、防ぐことができます。
**フロー数**
1 つのフローは、最大 10 Gbps をサポートするクラスタープレイスメントグループ内にある場合や、最大 25 Gbps をサポートする ENA Express を使用している場合を除いて、5 Gbps に制限されます。
同様に、Nitro Card は、1 つのフローを使用する場合と比べて、複数のフローで、より多くのパケットを処理できます。インスタンスあたりの、ピークのパケット処理速度を達成するには、総帯域幅が 100 Gbps 以上のインスタンスで、100 フロー以上にすることが推奨されます。総帯域幅の容量が増えると、ピーク処理速度の達成に必要なフローの数も増えます。ベンチマークは、ネットワークのピーク速度を達成するために、どのような構成が必要かを判断するのに役立ちます。
**Elastic Network Adapter (ENA) キュー**
ENA (Elastic Network Adapter) は、複数の受信 (Rx) キューと転送 (Tx) キュー (ENA キュー) を使用して、EC2 インスタンスのネットワークパフォーマンスとスケーラビリティを向上させます。これらのキューは、利用可能なキュー全体で送受信されるデータの負荷を分散させることで、ネットワークトラフィックを効率的に管理します。
詳細については、「[ENA キュー](ena-queues.md)」を参照してください。
**特徴量処理のオーバーヘッド**
トラフィックミラーリングや ENA Express などの機能では、処理オーバーヘッドが増加して、パケット処理の絶対的パフォーマンスが低下する可能性があります。パケットの処理速度は、機能の使用を制限したり、無効にしたりすることで上げることができます。
**状態を維持するための接続トラッキング**
セキュリティグループは、接続トラッキングを使用して、インスタンスに出入りするトラフィックに関する情報を追跡します。接続トラッキングは、ネットワークトラフィックの各フローにルールを適用して、そのトラフィックが許可されているか拒否されているかを判定します。Nitro Card は、フロートラッキングを使用してフローの状態を維持します。適用されるセキュリティグループのルールが増えれば、フローを評価するための作業も増えます。
トラフィックフローはすべて追跡されるわけではありません。セキュリティグループルールが [追跡されていない接続](security-group-connection-tracking.md#untracked-connections) で設定されている場合は、有効な応答パスが複数あるときに対称ルーティングを確保するため接続を自動的に追跡する場合を除いて、追加の作業は必要ありません。
#### ハードウェアアクセラレーションを使用しないパケット
ハードウェアアクセラレーションは、すべてのパケットで利用できるわけではありません。これらの例外の処理には、ネットワークフローの状態を確認するために必要な、処理オーバーヘッドが伴います。ネットワークフローは、プロトコル標準を確実に満たし、VPC 設計の変更に従い、許可された宛先にのみパケットを送信する必要があります。ただし、オーバーヘッドはパフォーマンスを低下させます。
**パケットフラグメント**
「**アプリケーションの考慮事項**」で述べたように、ネットワーク MTU を超えるパケットから発生するパケットフラグメントは、通常は例外として処理され、ハードウェアアクセラレーションを利用することはできません。ただし、ドライバーのバージョンによっては、フラグメントプロキシモードでエグレスフラグメントの制限を回避できます。詳細については、「[Nitro System でのネットワークパフォーマンスを最大化する](#ena-nitro-perf-maximize)」セクションで実行可能なアクションを確認してください。
**アイドル接続**
接続がタイムアウト制限に達していなくても、接続に一定時間アクティビティがないと、システムはその優先順位を下げることができます。優先順位が下がった後にデータが入ってきた場合、システムは、再度接続するために、そのデータを例外として処理する必要があります。
接続を管理するには、接続トラッキングタイムアウトを使用してアイドル接続を終了します。TCP キープアライブを使用して、アイドル接続を開放しておくこともできます。詳細については、「[アイドル接続追跡タイムアウト](security-group-connection-tracking.md#connection-tracking-timeouts)」を参照してください。
**VPC ミューテーション**
セキュリティグループ、ルートテーブル、アクセスコントロールリストの更新は、すべて処理パスで再評価して、ルートエントリとセキュリティグループのルールが、想定どおりに適用されることを確認する必要があります。
**ICMP フロー**
インターネット制御メッセージプロトコル (ICMP) は、ネットワーク通信の問題を診断する場合にネットワークデバイスで使用するネットワーク層プロトコルです。これらのパケットでは、常にフルフローが使用されます。
**非対称 L2 フロー**
NitroV3 以前のプラットフォームでは、同一サブネット内の 2 つの ENI 間のトラフィックにおいて、片方の ENI がデフォルトゲートウェイルーターを使用し、もう片方が使用しない構成の場合、ハードウェアアクセラレーションは有効になりません。NitroV4 以降のプラットフォームでは、このシナリオにおいてハードウェアアクセラレーションが有効になります。NitroV3 以前のプラットフォームでのパフォーマンスを向上させるには、両方の ENI 間で使用されているデフォルトのゲートウェイルーター、またはそれらの ENI が異なるサブネットにあることを確認してください。
## Nitro System でのネットワークパフォーマンスを最大化する
Nitro システムのネットワークパフォーマンスは、ネットワーク設定を調整することで最大化できます。
**Topics**
+ [考慮事項](#considerations)
+ [PPS パフォーマンスの調整](#tuning)
+ [ENA キュー割り当てを設定する](#max-perf-ena-queues)
+ [Linux インスタンスのパフォーマンスを監視する](#monitoring)
### 考慮事項
設計上の決定や、インスタンスのネットワーク設定の調整を行う際には、ベストな結果が得られるよう、事前に以下の手順を実行しておくことが推奨されます。
1. [Nitro システムのネットワーク設計に関して考慮すべき事項](#ena-nitro-perf-considerations) をレビューして、パフォーマンスの向上に役立つアクションの、長所と短所を理解しておきます。
Linux でのインスタンス設定に関するその他の考慮事項とベストプラクティスについては、GitHub の「[ENA Linux Driver Best Practices and Performance Optimization Guide](https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/ena/ENA_Linux_Best_Practices.rst)」を参照してください。
1. ピーク時のアクティブフロー数でワークロードをベンチマークし、アプリケーションパフォーマンスのベースラインを決定します。パフォーマンスベースラインを使用すると、設定やアプリケーション設計のバリエーションをテストして、特にスケールアップやスケールアウトを計画している場合に、どの考慮事項が最も大きな影響を与えるかを判断することができます。
### PPS パフォーマンスの調整
以下は、システムのニーズに応じて PPS のパフォーマンスを調整する際に活用できるアクションの一覧です。
+ 2 つのインスタンス間の物理的な距離を短くします。送信側と受信側のインスタンスが同じアベイラビリティーゾーンにある場合や、クラスタープレイスメントグループを使用している場合は、パケットが 1 つのエンドポイントから別のエンドポイントに移動する際に必要になるホップの数を、減らすことができます。
+ [追跡されていない接続](security-group-connection-tracking.md#untracked-connections) を使用します。
+ ネットワークトラフィックには UDP プロトコルを使用します。
+ 総帯域幅が 100 Gbps 以上の EC2 インスタンスでは、Nitro Card 全体に処理を均等に分散するために、100 以上の個別のフローにワークロードを分散します。
+ EC2 インスタンスのエグレスフラグメント PPS 制限を克服するには、フラグメントプロキシモードを有効にします (これはドライバーのバージョンによってできる場合とできない場合があります)。この設定により、フラグメント化されたパケットが処理パスで評価されるようになるため、エグレス PPS 制限の 1024 を克服できます。ドライバーをロードするときは、次のいずれかのコマンドを実行して、フラグメントプロキシモードを有効または無効にします。
**フラグメントプロキシモードを有効にする**
```
sudo insmod ena.ko enable_frag_bypass=1
```
**フラグメントプロキシモードを無効にする**
```
sudo insmod ena.ko enable_frag_bypass=0
```
### ENA キュー割り当てを設定する
サポートされているインスタンスタイプでは、これらのキューを Elastic Network Interface (ENI) 全体に動的に割り当てることができます。柔軟な ENA キューの割り当てはリソース配分を最適化するため、vCPU を最大限に活用できます。通常、ネットワークパフォーマンスの高いワークロードには複数の ENA キューが必要です。詳細については、「[ENA キュー](ena-queues.md)」を参照してください。
### Linux インスタンスのパフォーマンスを監視する
Linux インスタンスの Ethtool メトリクスを使用することで、帯域幅、パケットレート、接続トラッキングなどの、インスタンスのネットワークパフォーマンス指標を監視することができます。詳細については、「[EC2 インスタンスでの ENA 設定のネットワークパフォーマンスのモニタリング](monitoring-network-performance-ena.md)」を参照してください。