기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 모범 사례
<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 에이전트는 접촉당 여러 스트림을 지원하지만 한 번에 하나의 접촉만 지원합니다. 일정 문제를 방지하려면 여러 데이터 흐름 엔드포인트 그룹에서 인스턴스를 공유하지 마세요. 단일 에이전트 구성이 여러 개의 서로 다른 DFEG ARN과 연결된 경우 등록에 실패합니다.

## AWS Ground Station 에이전트와 함께 서비스 및 프로세스 실행
<a name="avoiding-contested-cores"></a>

 AWS Ground Station 에이전트와 동일한 EC2 인스턴스에서 서비스 및 프로세스를 시작할 때 AWS Ground Station 에이전트 및 Linux 커널에서 사용하지 않는 vCPUs에 바인딩하는 것이 중요합니다. 이렇게 하면 고객 응대 중에 병목 현상과 데이터 손실이 발생할 수 있기 때문입니다. 이러한 특정 vCPUs을 선호도라고 합니다.

피해야 할 코어:
+ `agentCpuCores`시작[에이전트 구성 파일](configuring-agent.md#agent-config-file)
+ [하드웨어 인터럽트 및 수신 대기열 튜닝 - CPU 및 네트워크에 영향을 미칩니다.](ec2-instance-performance-tuning.md#tune-hardware-interrupts)의 `interrupt_core_list`
  + 기본값은에서 찾을 수 있습니다. [부록: 인터럽트/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`

### 서비스 선호(시스템)
<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)
```

작업 세트에 대한 자세한 내용은 [작업 세트 - Linux 맨 페이지를](https://linux.die.net/man/1/taskset) 참조하세요.