Amazon ElastiCache Well-Architected 렌즈 운영 우수성 기둥 - 아마존 ElastiCache (레디 스OSS)
OE 1: 클러스터에서 트리거되는 알림과 이벤트를 이해하고 이에 대응하려면 어떻게 해야 합니까? ElastiCache OE 2: 기존 클러스터를 언제, 어떻게 확장합니까? ElastiCache OE 3: ElastiCache 클러스터 리소스를 관리하고 클러스터를 유지 관리하려면 어떻게 해야 합니까 up-to-date?OE 4: 클러스터에 대한 클라이언트의 연결을 어떻게 관리합니까? ElastiCache OE 5: 워크로드용 ElastiCache 구성 요소를 배포하려면 어떻게 해야 합니까?OE 6: 장애를 어떻게 대비하고 완화할 계획인가요?OE 7: Redis OSS 엔진 이벤트 문제를 해결하려면 어떻게 해야 합니까?

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

Amazon ElastiCache Well-Architected 렌즈 운영 우수성 기둥

운영 우수성 요소는 비즈니스 가치를 제공하고 프로세스 및 절차를 지속적으로 개선하기 위한 시스템 운영 및 모니터링에 중점을 둡니다. 주요 주제에는 변경 자동화, 이벤트 대응, 일상 운영 관리를 위한 표준 정의 등이 포함됩니다.

OE 1: 클러스터에서 트리거되는 알림과 이벤트를 이해하고 이에 대응하려면 어떻게 해야 합니까? ElastiCache

질문 수준의 소개: ElastiCache 클러스터를 운영할 때 특정 이벤트 발생 시 알림 및 알림을 선택적으로 수신할 수 있습니다. ElastiCache기본적으로 장애 조치, 노드 교체, 조정 작업, 예약된 유지 관리 등과 같은 리소스와 관련된 이벤트를 기록합니다. 각 이벤트에는 날짜 및 시간, 소스 이름 및 소스 유형, 설명이 포함됩니다.

질문 수준의 이점: 클러스터에서 생성되는 경고를 트리거하는 이벤트의 근본 원인을 이해하고 관리할 수 있다면 더 효과적으로 운영하고 이벤트에 적절하게 대응할 수 있습니다.

  • [필수] ElastiCache ElastiCache 콘솔에서 (지역을 선택한 후) 또는 Amazon 명령줄 인터페이스 (AWS CLI) describe-events 명령을 사용하여 생성된 이벤트를 검토하십시오. ElastiCache API Amazon 단순 알림 서비스 (AmazonSNS) 를 사용하여 중요한 클러스터 이벤트에 대한 알림을 ElastiCache 전송하도록 구성합니다. SNS클러스터와 함께 Amazon을 사용하면 ElastiCache 이벤트에 대해 프로그래밍 방식으로 조치를 취할 수 있습니다.

    • 이벤트에는 크게 현재 이벤트와 예정된 이벤트라는 두 가지 범주가 있습니다. 현재 이벤트 목록에는 리소스 생성 및 삭제, 조정 작업, 장애 조치, 노드 재부팅, 스냅샷 생성, 클러스터 매개 변수 수정, CA 인증서 갱신, 장애 이벤트 (클러스터 프로비저닝 실패 VPC 또는 -, 조정 실패 ENI ENI -, 스냅샷 실패) 가 포함됩니다. 예정된 이벤트 목록에는 유지 관리 기간 동안 교체가 예정된 노드 및 교체 일정이 변경된 노드가 포함됩니다.

    • 이러한 이벤트 중 일부에 즉시 대응할 필요는 없지만 먼저 모든 장애 이벤트를 살펴보는 것이 중요합니다.

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCache: SnapshotFailed (OSSRedis만 해당)

    • [리소스]:

  • [최고] 이벤트에 대한 응답을 자동화하려면 Lambda Functions와 같은 AWS 제품 SNS 및 서비스 기능을 활용하십시오. 모범 사례에 따라 작고 빈번하며 되돌릴 수 있는 변경을 코드로 적용하여 시간이 지남에 따라 운영을 발전시킵니다. Amazon CloudWatch 메트릭을 사용하여 클러스터를 모니터링해야 합니다.

    [리소스]: Lambda를 사용하는 사용 사례의 경우 Lambda AWS , Amazon Route 53 및 SNS Amazon을 사용하여 읽기 전용 복제본 엔드포인트를 모니터링 ElastiCache (RedisOSS) (클러스터 모드 비활성화) 합니다. SNS

OE 2: 기존 클러스터를 언제, 어떻게 확장합니까? ElastiCache

질문 수준의 소개: ElastiCache 클러스터의 크기를 적절하게 조정하는 것은 기본 워크로드 유형이 변경될 때마다 평가해야 하는 밸런싱 작업입니다. 목표는 워크로드에 적합한 규모의 환경에서 운영하는 것입니다.

질문 수준의 이점: 리소스를 과도하게 사용하면 지연 시간이 늘어나고 전반적인 성능이 저하될 수 있습니다. 반면, 활용도가 낮으면 최적화되지 않은 비용으로 리소스를 과도하게 프로비저닝하게 될 수 있습니다. 환경을 적절한 규모로 조정하면 성능 효율성과 비용 최적화 간의 균형을 맞출 수 있습니다. 리소스 사용률 초과 또는 저하 문제를 해결하려면 2차원으로 확장할 ElastiCache 수 있습니다. 노드 용량을 늘리거나 줄여서 수직으로 규모를 조정할 수 있습니다. 노드를 추가 및 제거하여 수평적으로 규모를 조정할 수도 있습니다.

OE 3: ElastiCache 클러스터 리소스를 관리하고 클러스터를 유지 관리하려면 어떻게 해야 합니까 up-to-date?

질문 수준의 소개: 대규모로 운영하려면 모든 리소스를 정확히 찾아내고 식별할 수 있어야 합니다. ElastiCache 새 애플리케이션 기능을 출시할 때는 개발, 테스트, 프로덕션 등 모든 ElastiCache 환경 유형에서 클러스터 버전 대칭을 만들어야 합니다. 리소스 속성을 사용하면 새 기능을 배포하거나 새 보안 메커니즘을 활성화하는 등 다양한 운영 목표에 맞게 환경을 분리할 수 있습니다.

질문 수준의 이점: 개발, 테스트 및 프로덕션 환경을 분리하는 것이 운영 모범 사례입니다. 또한 잘 이해되고 문서화된 프로세스를 사용하여 환경 전반의 클러스터와 노드에 최신 소프트웨어 패치를 적용하는 것이 가장 좋습니다. 기본 ElastiCache 기능을 활용하면 엔지니어링 팀이 유지 관리가 아닌 비즈니스 목표를 달성하는 데 집중할 수 있습니다 ElastiCache .

  • [최고] 사용 가능한 최신 엔진 버전에서 실행하고 셀프 서비스 업데이트가 제공되는 즉시 적용하십시오. ElastiCache 클러스터의 지정된 유지 관리 기간 동안 기본 인프라를 자동으로 업데이트합니다. 하지만 클러스터에서 실행 중인 노드는 셀프 서비스 업데이트를 통해 업데이트됩니다. 이러한 업데이트에는 보안 패치 또는 소프트웨어 소규모 업데이트의 두 가지 유형이 있습니다. 패치 유형과 적용 시기의 차이를 이해해야 합니다.

    [리소스]:

  • [최고] 태그를 사용하여 ElastiCache 리소스를 정리하십시오. 개별 노드가 아닌 복제 그룹에 태그를 사용합니다. 리소스를 쿼리할 때 표시되도록 태그를 구성하고 태그를 사용하여 검색을 수행하고 필터를 적용할 수 있습니다. 일반적인 태그 세트를 공유하는 리소스 모음을 쉽게 만들고 유지 관리하려면 리소스 그룹을 만들어야 합니다.

    [리소스]:

OE 4: 클러스터에 대한 클라이언트의 연결을 어떻게 관리합니까? ElastiCache

질문 수준의 소개: 대규모로 운영하려면 클라이언트가 ElastiCache 클러스터에 연결하여 애플리케이션 운영 측면 (예: 응답 시간) 을 관리하는 방법을 이해해야 합니다.

질문 수준의 이점: 가장 적절한 연결 메커니즘을 선택하면 시간 초과와 같은 연결 오류로 인해 애플리케이션 연결이 끊기지 않습니다.

  • [필수] 읽기와 쓰기 작업을 분리하고 복제본 노드에 연결하여 읽기 작업을 실행합니다. 하지만 읽기와 쓰기를 분리하면 Redis 복제의 비동기식 특성으로 인해 쓰기 직후 키를 읽을 수 없게 된다는 점에 유의하세요. OSS 이 WAIT 명령을 활용하면 실제 데이터 안전성을 높이고 복제본이 클라이언트에 응답하기 전에 쓰기를 승인하도록 할 수 있지만 전반적인 성능 저하가 발생할 수 있습니다. 클러스터 모드의 ElastiCache 리더 엔드포인트를 비활성화하여 ElastiCache (RedisOSS) 클라이언트 라이브러리에서 읽기 작업에 복제본 노드를 사용하도록 구성할 수 있습니다. 클러스터 모드를 활성화하려면 ElastiCache (RedisOSS) 명령을 사용합니다. READONLY 대부분의 ElastiCache (RedisOSS) 클라이언트 라이브러리의 경우 ElastiCache (READONLYRedisOSS) 는 기본적으로 또는 구성 설정을 통해 구현됩니다.

    [리소스]:

  • [필수] 연결 풀링을 사용합니다. 클라이언트와 서버 측 모두 TCP 연결을 설정하는 CPU 데 시간이 많이 걸리며 풀링을 사용하면 연결을 재사용할 수 있습니다. TCP

    연결 오버헤드를 줄이려면 연결 풀링을 사용해야 합니다. 연결 풀을 사용하면 애플리케이션에서 연결 설정 비용 없이 '마음대로' 연결을 재사용하고 연결을 해제할 수 있습니다. 애플리케이션 환경에 사용할 수 있는 프레임워크를 사용하여 ElastiCache (RedisOSS) 클라이언트 라이브러리 (지원되는 경우) 를 통해 연결 풀링을 구현하거나 처음부터 구축할 수 있습니다.

  • [가장 좋음] 클라이언트의 소켓 제한 시간이 최소 1초로 설정되어 있는지 확인합니다. 몇몇 클라이언트의 일반적인 기본값인 '없음'으로 설정되어 있으면 안 됩니다.

    • 제한 시간 값을 너무 낮게 설정하면 서버 로드가 높을 때 시간 초과가 발생할 수 있습니다. 너무 높게 설정하면 애플리케이션에서 연결 문제를 감지하는 데 시간이 오래 걸릴 수 있습니다.

    • 클라이언트 애플리케이션에서 연결 풀링을 구현하여 새 연결의 볼륨을 제어합니다. 이렇게 하면 연결을 열고 닫고 클러스터에서 핸드셰이크를 활성화한 경우 TLS 핸드셰이크를 수행하는 데 필요한 지연 시간과 CPU 사용률이 TLS 줄어듭니다.

    [리소스]: 가용성을 높이도록 구성 ElastiCache (RedisOSS)

  • [좋음] (사용 사례에서 가능한 경우) 파이프라이닝을 사용하면 성능이 크게 향상될 수 있습니다.

    • 파이프라이닝을 사용하면 애플리케이션 클라이언트와 클러스터 사이의 왕복 시간 (RTT) 을 줄일 수 있으며, 클라이언트가 이전 응답을 아직 읽지 않았더라도 새 요청을 처리할 수 있습니다.

    • 파이프라이닝을 사용하면 응답/확인을 기다리지 않고 서버에 여러 명령을 보낼 수 있습니다. 파이프라이닝의 단점은 결국 모든 응답을 대량으로 가져올 때 끝에 가서야 잡을 수 있는 오류가 있을 수 있다는 점입니다.

    • 잘못된 요청을 생략하는 오류가 반환될 때 요청을 재시도하는 메서드를 구현합니다.

    [리소스]: 파이프라이닝

OE 5: 워크로드용 ElastiCache 구성 요소를 배포하려면 어떻게 해야 합니까?

질문 수준의 소개: ElastiCache 환경은 AWS 콘솔을 통해 수동으로 배포하거나 APIsCLI, 툴킷 등을 통해 프로그래밍 방식으로 배포할 수 있습니다. 운영 우수성 모범 사례에서는 가능하면 코드를 통해 배포를 자동화하는 것을 권장합니다. 또한 ElastiCache 클러스터를 워크로드별로 분리하거나 비용 최적화를 위해 결합할 수 있습니다.

질문 수준의 이점: ElastiCache 환경에 가장 적합한 배포 메커니즘을 선택하면 시간이 지남에 따라 Operation Excellence를 개선할 수 있습니다. 인적 오류를 최소화하고 반복성, 유연성 및 이벤트에 대한 응답 시간을 향상하기 위해서는 가능하면 코드로 작업을 수행하는 것이 좋습니다.

워크로드 격리 요구 사항을 이해하면 워크로드별 전용 ElastiCache 환경을 선택하거나 여러 워크로드를 단일 클러스터 또는 이들의 조합으로 결합할 수 있습니다. 장단점을 이해하면 운영 우수성과 비용 최적화 간의 균형을 맞추는 데 도움이 될 수 있습니다.

  • [필수] 사용 가능한 배포 옵션을 이해하고 가능한 ElastiCache 경우 이러한 절차를 자동화하세요. 가능한 자동화 방법으로는 CloudFormation, AWS CLI/SDK, 등이 APIs 있습니다.

    [리소스]:

  • [필수] 모든 워크로드에 대해 필요한 클러스터 격리 수준을 결정합니다.

    • [가장 좋음]: 높은 수준의 격리 - 워크로드와 클러스터를 1:1로 매핑합니다. 워크로드별로 ElastiCache 리소스의 액세스, 크기 조정, 규모 조정 및 관리를 세밀하게 제어할 수 있습니다.

    • [더 좋음]: 중간 수준의 격리 - 목적별로 M:1로 격리하지만 여러 워크로드 간에 공유될 수 있습니다(예: 워크로드 캐싱 전용 클러스터와 메시징 전용 클러스터).

    • [좋음]: 낮은 수준의 격리 - M:1 격리로 다용도로 사용하며 완전히 공유합니다. 공유 액세스가 허용되는 워크로드에 권장됩니다.

OE 6: 장애를 어떻게 대비하고 완화할 계획인가요?

질문 수준의 소개: Operational Excellence에는 정기적인 “사전 검토” 연습을 수행하여 잠재적 장애 원인을 식별하여 제거하거나 완화할 수 있도록 장애를 예측하는 것이 포함됩니다. ElastiCache 테스트 목적으로 노드 장애 이벤트를 시뮬레이션할 수 API 있는 장애 조치를 제공합니다.

질문 수준의 이점: 장애 시나리오를 미리 테스트하면 장애 시나리오가 워크로드에 미치는 영향을 파악할 수 있습니다. 이를 통해 대응 절차와 그 효과를 안전하게 테스트할 수 있을 뿐만 아니라 팀이 대응 절차 실행에 익숙해질 수 있습니다.

[필수] 개발/테스트 계정에서 정기적으로 장애 조치 테스트를 수행하십시오. TestFailover

OE 7: Redis OSS 엔진 이벤트 문제를 해결하려면 어떻게 해야 합니까?

질문 수준의 소개: Operational Excellence를 사용하려면 서비스 수준 및 엔진 수준 정보를 모두 조사하여 클러스터의 상태와 상태를 분석할 수 있어야 합니다. ElastiCache (RedisOSS) 는 CloudWatch Amazon과 Amazon Kinesis Data Firehose에 모두 Redis OSS 엔진 로그를 내보낼 수 있습니다.

질문 수준의 이점: ElastiCache (RedisOSS) 클러스터에서 Redis OSS 엔진 로그온을 활성화하면 클러스터의 상태와 성능에 영향을 미치는 이벤트를 파악할 수 있습니다. Redis OSS 엔진 로그는 이벤트 메커니즘을 통해 사용할 수 없는 Redis OSS 엔진에서 직접 데이터를 제공합니다. ElastiCache 두 ElastiCache 이벤트 (이전 OE-1 참조) 와 Redis OSS 엔진 로그를 주의 깊게 관찰하면 ElastiCache 서비스 관점과 Redis 엔진 관점에서 문제를 해결할 때 이벤트 순서를 결정할 수 있습니다. OSS

  • [필수] ElastiCache (Redis) 6.2 이상부터 사용할 수 있는 Redis OSS 엔진 로깅 기능이 활성화되어 있는지 확인하십시오. OSS 클러스터 생성 중에 또는 생성 후 클러스터를 수정하여 이 작업을 수행할 수 있습니다.

    • Amazon CloudWatch Logs 또는 Amazon Kinesis Data Firehose가 Redis 엔진 로그의 적절한 OSS 대상인지 판단하십시오.

    • 로그를 유지하려면 둘 중 하나 CloudWatch 또는 Kinesis Data Firehose에서 적절한 대상 로그를 선택합니다. 클러스터가 여러 개 있는 경우, 문제 해결 시 데이터를 분리하는 데 도움이 되므로 클러스터마다 다른 대상 로그를 사용하는 것이 좋습니다.

    [리소스]:

  • [최고] Amazon Logs를 사용하는 경우 Amazon CloudWatch Logs Insights를 활용하여 Redis OSS 엔진 CloudWatch 로그에서 중요한 정보를 쿼리하는 것을 고려해 보십시오.

    예를 들어, 다음과 같이 a가 WARNING ''인 이벤트를 반환하는 Redis OSS 엔진 로그를 포함하는 CloudWatch 로그 그룹에 대한 쿼리를 생성해 보십시오. LogLevel 

    fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"

    [리소스]: Logs Insights를 통한 CloudWatch 로그 데이터 분석