翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ベストプラクティス
<a name="best-practices"></a>

## Amazon EC2 のベストプラクティス
<a name="best-practices-ec2"></a>

 EC2 の最新のベストプラクティスに従い、十分なデータストレージの可用性を確保します。

[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)

## Linux スケジューラ
<a name="linux-scheduler"></a>

Linux スケジューラは、対応するプロセスが特定のコアに固定されていない場合、UDP ソケット上のパケットを並べ替えることができます。UDP データを送受信するスレッドは、データ転送中は特定のコアに固定する必要があります。

## AWS Ground Station マネージドプレフィックスリスト
<a name="managed-prefix-list-best-practice"></a>

アンテナからの通信を許可するネットワークルールを指定するときは、`com.amazonaws.global.groundstation` という AWS 管理のプレフィックスリストを利用することをお勧めします。AWS マネージドプレフィックスリストの詳細については、「[AWS マネージドプレフィックスリストの使用](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)」を参照してください。

## 単一のコンタクトの制限
<a name="single-contact-limitation"></a>

 AWS Ground Station Agent は、コンタクトごとに複数のストリームをサポートしますが、一度に単一のコンタクトのみをサポートします。スケジュールの問題を防ぐため、複数のデータフローエンドポイントグループ間でインスタンスを共有しないでください。単一のエージェント設定が複数の異なる DFEG ARN に関連付けられている場合、登録に失敗します。

## AWS Ground Station エージェントと一緒にサービスとプロセスを実行する
<a name="avoiding-contested-cores"></a>

 AWS Ground Station エージェントと同じ EC2 インスタンスでサービスとプロセスを起動する場合、 AWS Ground Station エージェントと Linux カーネルで使用されていない vCPUs にバインドすることが重要です。これにより、コンタクト中にボトルネックやデータ損失が発生する可能性があります。この特定の vCPUs へのバインドの概念は、アフィニティと呼ばれます。

回避すべきコア:
+ `agentCpuCores` from [エージェント設定ファイル](configuring-agent.md#agent-config-file)
+ `interrupt_core_list` ([ハードウェア割り込みの調整とキューの受信 - CPU とネットワークに影響](ec2-instance-performance-tuning.md#tune-hardware-interrupts) から)。
  + デフォルト値は から確認できます。 [付録: 割り込み/RPS チューニングの推奨パラメータ](ec2-instance-performance-tuning.md#recommended-parameters)

### `c5.24xlarge` インスタンスの使用例
<a name="avoiding-contested-cores-example"></a>

を指定した場合

`"agentCpuCores": [24,25,26,27,72,73,74,75]"`

と の実行

`echo "@reboot sudo /opt/aws/groundstation/bin/set_irq_affinity.sh '0,1,48,49' 'ffffffff,ffffffff,ffffffff' >> /var/log/user-data.log 2>&1" >>/var/spool/cron/root`

その後、次のコアは避けてください。

`0,1,24,25,26,27,48,49,72,73,74,75`

### サービスの定義 (systemd)
<a name="avoiding-contested-cores-with-services"></a>

 新しく起動されたサービスは、`interrupt_core_list`前述の に自動的にアフィニタイズされます。起動したサービスのユースケースで追加のコアが必要な場合、または混雑の少ないコアが必要な場合は、このセクションに従ってください。

コマンドを使用して、サービスが現在設定されているアフィニティを確認します。

```
systemctl show --property CPUAffinity <service name>
```

 のような空の値が表示される場合は`CPUAffinity=`、上記のコマンドのデフォルトコアを使用する可能性が高いことを意味します。 `...bin/set_irq_affinity.sh <using the cores here> ...`

特定のアフィニティを上書きして設定するには、以下を実行してサービスファイルの場所を見つけます。

```
systemctl show -p FragmentPath <service name>
```

 ファイル (`vi`、 などを使用) を開いて変更し`nano`、 `CPUAffinity=<core list>`を次のような `[Service]`セクションに配置します。

```
[Unit]
...

[Service]
...
CPUAffinity=2,3

[Install]
...
```

ファイルを保存し、サービスを再起動してアフィニティを適用します。

```
systemctl daemon-reload
systemctl restart <service name>

# Additionally confirm by re-running
systemctl show --property CPUAffinity <service name>
```

 詳細については、[Red Hat Enterprise Linux 8 - カーネルの管理、モニタリング、更新 - 第 27 章を参照してください。systemd を使用した CPU アフィニティポリシーと NUMA ポリシーの設定](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/assembly_configuring-cpu-affinity-and-numa-policies-using-systemd_managing-monitoring-and-updating-the-kernel)。

### プロセスの実現 (スクリプト)
<a name="avoiding-contested-cores-with-processes"></a>

 デフォルトの Linux 動作ではマシン上の任意のコアを使用できるため、新しく起動したスクリプトとプロセスを手動でアフィニタイズすることを強くお勧めします。

実行中のプロセス (Python、bash スクリプトなど) のコア競合を回避するには、以下を使用してプロセスを起動します。

```
taskset -c <core list> <command>
# Example: taskset -c 8 ./bashScript.sh
```

 プロセスがすでに実行されている場合は、`pidof`、、 などのコマンドを使用して`top`、特定のプロセスのプロセス ID (PID) `ps`を見つけます。PID を使用すると、以下との現在のアフィニティを確認できます。

```
taskset -p <pid>
```

 と は、以下を使用してこれを変更できます。

```
taskset -p <core mask> <pid>
# Example: taskset -p c 32392 (which sets it to cores 0xc -> 0b1100 -> cores 2,3)
```

タスクセットの詳細については、[「Tasket - Linux man page](https://linux.die.net/man/1/taskset)」を参照してください。