

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

# 모범 사례
<a name="bestpractices"></a>

다음은 MemoryDB에 대한 권장 모범 사례입니다. 다음 모범 사례를 준수하면 클러스터의 성능과 안정성이 향상됩니다.

**Topics**
+ [

# MemoryDB의 복원력
](disaster-recovery-resiliency.md)
+ [

# 모범 사례: Pub/Sub 및 향상된 I/O 멀티플렉싱
](best-practices-pubsub.md)
+ [

# 모범 사례: 온라인 클러스터 크기 조정
](best-practices-online-resharding.md)

# MemoryDB의 복원력
<a name="disaster-recovery-resiliency"></a>

AWS 글로벌 인프라는 AWS 리전 및 가용 영역을 중심으로 구축됩니다. AWS 리전은 물리적으로 분리되고 격리된 다수의 가용 리전을 제공하며 이러한 가용 리전은 짧은 지연 시간, 높은 처리량 및 높은 중복성을 갖춘 네트워크에 연결되어 있습니다. 가용 영역을 사용하면 중단 없이 가용 영역 간에 자동으로 장애 조치가 이루어지는 애플리케이션 및 데이터베이스를 설계하고 운영할 수 있습니다. 가용 영역은 기존의 단일 또는 다중 데이터 센터 인프라보다 가용성, 내결함성, 확장성이 뛰어납니다.

AWS 리전 및 가용 영역에 대한 자세한 내용은 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.

AWS 글로벌 인프라 뿐만 아니라 MemoryDB도 데이터 복원력과 스냅샷 요구 사항을 지원하는 다양한 기능을 제공합니다.

**Topics**
+ [

# 장애 완화
](faulttolerance.md)

# 장애 완화
<a name="faulttolerance"></a>

MemoryDB 구현을 계획할 때는 장애가 애플리케이션 및 데이터에 미치는 영향을 최소화하도록 계획해야 합니다. 이 섹션의 항목은 애플리케이션 및 데이터를 장애로부터 보호하기 위해 취할 수 있는 접근 방식을 다룹니다.

## 장애 완화: MemoryDB 클러스터
<a name="faulttolerance.cluster.replication"></a>

MemoryDB 클러스터는 애플리케이션이 읽고 쓸 수 있는 단일 프라이머리 노드와 0\$15개의 읽기 전용 복제본 노드로 구성되어 있습니다. 하지만 고가용성을 위해 최소 1개의 복제본을 사용하는 것이 좋습니다. 프라이머리 노드에 데이터가 작성될 때마다 트랜잭션 로그에 유지되고 복제본 노드에서도 비동기식으로 업데이트됩니다.

**읽기 전용 복제본 장애의 경우**

1. MemoryDB는 장애가 있는 복제본을 감지합니다.

1. MemoryDB는 장애가 있는 노드를 오프라인 상태로 전환합니다.

1. MemoryDB는 동일한 AZ에서 대체 노드를 시작하고 프로비저닝합니다.

1. 새 노드는 트랜잭션 로그와 동기화됩니다.

이 기간 동안 애플리케이션에서는 다른 노드를 사용하여 계속 읽고 쓸 수 있습니다.

**MemoryDB 다중 AZ**  
MemoryDB 클러스터에서 다중 AZ가 활성화되면 장애가 발생한 프라이머리 클러스터가 감지되어 자동으로 교체됩니다.

****

1. MemoryDB가 프라이머리 노드 장애를 감지합니다.

1. MemoryDB는 장애가 발생한 기본 복제본과 일관성이 있는지 확인한 후 복제본으로 장애 조치합니다.

1. MemoryDB는 장애가 있는는 프라이머리 노드의 AZ에서 읽기 전용 복제본을 실행합니다.

1. 새 노드는 트랜잭션 로그와 동기화됩니다.

복제본 노드에 장애 조치하는 것은 일반적으로 새 기본 노드를 생성하고 프로비저닝하는 것보다 빠릅니다. 즉, 애플리케이션은 더 빠르게 프라이머리 노드에 대한 쓰기를 재개할 수 있습니다.

자세한 내용은 [다중 AZ로 MemoryDB의 가동 중지 시간 최소화](autofailover.md) 섹션을 참조하세요.

# 모범 사례: Pub/Sub 및 향상된 I/O 멀티플렉싱
<a name="best-practices-pubsub"></a>

Valkey 또는 Redis OSS 버전 7 이상을 사용하는 경우 [샤딩된 Pub/Sub](https://valkey.io/topics/pubsub/)를 사용하는 것이 좋습니다. 또한 [향상된 I/O 멀티플렉싱](https://aws.amazon.com/memorydb/features/#Ultra-fast_performance)을 사용하여 처리량과 지연 시간을 개선할 수 있습니다. 향상된 I/O 멀티플렉싱은 Valkey 또는 Redis OSS 버전 7 이상을 사용할 때 자동으로 제공되며 클라이언트를 변경할 필요가 없습니다. 여러 클라이언트 연결로 처리량이 제한되는 Pub/Sub 워크로드에 적합합니다.

# 모범 사례: 온라인 클러스터 크기 조정
<a name="best-practices-online-resharding"></a>

*리샤딩*에는 클러스터에(서) 샤드 또는 노드를 추가 및 제거하고 샤드 간에 키 공간을 재분산하는 작업이 수반됩니다. 따라서 클러스터에 대한 로드, 메모리 사용률 및 데이터의 전체 크기 등과 같은 여러 가지 요인이 리샤딩 작업에 영향을 미칩니다. 최상의 성능을 구현하기 위해서는 균일한 워크로드 패턴 분산을 위한 전반적인 클러스터 모범 사례를 따르는 것이 좋습니다. 또한 다음 단계를 수행하는 것이 좋습니다.

리샤딩을 시작하기 전에 다음 작업을 수행하는 것이 좋습니다.
+ **애플리케이션 테스트** - 가능한 경우, 준비 환경에서 리샤딩 중 애플리케이션 동작을 테스트합니다.
+ **확장 문제는 초기에 알리기** - 리샤딩은 컴퓨팅 집약적인 작업입니다. 이 때문에 리샤딩 중에는 CPU 사용률을 멀티 코어 인스턴스의 경우, 80% 미만으로, 싱글 코어 인스턴스의 경우에는 50% 미만으로 유지하는 것이 좋습니다. 애플리케이션에서 규모 조정 문제 관찰을 시작하기 전에 MemoryDB 측정치를 모니터링한 다음 리샤딩을 시작합니다. `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` 및 `BytesUsedForMemoryDB` 지표를 추적하면 유용합니다.
+ **스케일 인 전 충분한 여유 메모리를 사용할 수 있는지 확인** - 확장하는 경우, 샤드에서 제거하려는 사용 중인 메모리의 1.5배가 넘는 여유 메모리가 샤드에 있는지 확인합니다.
+ **사용량이 적은 시간에 리샤딩 시작** - 이 사례를 적용하면 리샤딩 작업 중 클라이언트에서 지연 시간과 처리량에 미치는 영향을 줄일 수 있습니다. 또한 슬롯 재분산에 더 많은 리소스를 사용할 수 있기 때문에 리샤딩을 더욱 빠르게 완료할 수 있습니다.
+ **클라이언트 제한 시간 동작 검토** - 일부 클라이언트에서는 온라인 클러스터 크기 조정 중 지연 시간이 더 길어지는 경우를 관찰할 수 있습니다. 제한 시간을 좀 더 길게 설정해 클라이언트 라이브러리를 구성하면 서버에 대한 로드가 더욱 큰 상황에서도 시스템에서 연결할 시간을 가질 수 있습니다. 일부 경우에 서버에 대해 많은 수의 연결을 열 수 있습니다. 이 경우 지수 백오프를 추가해 로직을 다시 연결합니다. 이렇게 하면 동시에 서버에 연결하는 새로운 연결이 급격하게 증가하는 것을 방지할 수 있습니다.

리샤딩 중에 다음 작업을 수행하는 것이 좋습니다.
+ **비용이 많이 드는 명령 피하기** - 컴퓨팅 및 I/O 집약적인 작업(예: `KEYS` 및 `SMEMBERS` 명령)을 실행하지 않습니다. 이러한 작업은 클러스터에 대한 부하를 늘리고 클러스터의 성능에 영향을 미치기 때문에 이러한 접근 방식을 채택하는 것이 좋습니다. 대신 `SCAN` 및 `SSCAN` 명령을 사용합니다.
+ **Lua 모범 사례 따르기** - 오래 실행되는 Lua 스크립트의 사용을 피하고 항상 사전에 Lua 스크립트에 사용되는 키를 선언합니다. 이렇게 하면 Lua 스크립트가 슬롯 간 명령을 사용하지 않습니다. Lua 스크립트에 사용되는 키가 동일한 슬롯에 속해 있는지 확인하세요.

리샤딩 후에는 다음 내용에 유념하세요.
+ 대상 샤드에 사용 가능한 메모리가 부족한 경우에는 부분적인 확장만 가능했을 수 있습니다. 이러한 결과가 발생하면 필요한 경우, 사용 가능한 메모리를 검토한 후 작업을 다시 시도하세요.
+ 항목이 많은 슬롯은 마이그레이션되지 않습니다. 특히, 직렬화 후 크기가 256MB 이상인 항목이 있는 슬롯은 마이그레이션되지 않습니다.
+  리샤딩 작업 중에는 Lua 스크립트 내에서 `FLUSHALL`과 `FLUSHDB` 명령이 지원되지 않습니다.