일반적인 AWS 아키텍처 문제 해결: 솔루션 및 팁

대부분의 AWS 아키텍처 문제는 처음에는 모호하게 보입니다. 애플리케이션이 느리거나, 프라이빗 인스턴스가 AWS API에 도달할 수 없거나, 로드 밸런서에 정상 대상이 없거나, 데이터베이스 장애 조치가 다이어그램에서 약속한 대로 작동하지 않는 경우가 있습니다. 가장 빠른 문제 해결은 일반적으로 전체 계정에서 설정을 변경하는 대신 하나의 요청 경로를 따라 각 홉이 정상인지 확인하는 것입니다.

세 가지 질문으로 시작하세요. 무엇이 변경되었는지, 사용자가 볼 수 있는 증상은 무엇인지, 요청이 어디서 멈추는지입니다. 실패가 성능, 연결, 가용성 또는 권한 부여 중 무엇인지 알게 되면 AWS 콘솔이 훨씬 덜 혼란스러워집니다.

성능 병목 현상

성능 문제는 느린 애플리케이션 응답 시간, 높은 지연 시간 또는 리소스 고갈로 나타날 수 있습니다. 병목 현상을 식별하는 것은 효과적인 최적화에 중요합니다.

성능 병목 현상 식별

• 핵심 지표 모니터링: Amazon CloudWatch와 같은 AWS 서비스를 사용하여 컴퓨팅, 스토리지 및 데이터베이스 리소스에 대한 지표를 추적하세요. 다음을 확인하세요.
  • CPU 사용률: EC2 인스턴스의 지속적으로 높은 CPU 사용률은 처리 능력 부족 또는 비효율적인 코드를 나타낼 수 있습니다.
  • 메모리 사용률: 높은 메모리 사용률은 스와핑으로 이어져 성능을 저하시킬 수 있습니다. EC2 메모리는 기본 인스턴스 지표에 포함되지 않으므로 워크로드에 메모리가 중요한 경우 CloudWatch 에이전트 또는 애플리케이션 모니터링 도구를 사용하세요.
  • 네트워크 In/Out: 네트워크 트래픽의 급증 또는 지속적인 증가는 비효율적인 데이터 전송 또는 부하 증가를 나타낼 수 있습니다.
  • 디스크 I/O 작업(IOPS) 및 처리량: Amazon EBS 및 Amazon S3와 같은 서비스의 경우 프로비저닝된 제한을 초과하면 스토리지 관련 속도 저하가 발생할 수 있습니다.
  • 데이터베이스 연결 및 쿼리 지연 시간: Amazon RDS 또는 DynamoDB 인스턴스의 성능을 모니터링하세요.
• AWS X-Ray: 분산 애플리케이션의 경우 AWS X-Ray는 요청 흐름을 시각화하고 특정 서비스 호출의 성능 문제를 식별하는 데 도움이 됩니다.
• VPC 흐름 로그: 네트워크 트래픽 패턴을 분석하여 예상치 못한 또는 과도한 데이터 전송을 식별하세요.

성능 병목 현상에 대한 솔루션

• 리소스 확장:
  • 수직 확장(Scale Up): EC2 인스턴스의 인스턴스 크기(CPU, RAM)를 늘리거나 RDS 인스턴스 클래스를 업그레이드하세요. AWS Auto Scaling을 사용하여 수요에 따라 용량을 자동으로 조정하세요.
  • 수평 확장(Scale Out): 애플리케이션 계층에 더 많은 인스턴스를 추가하거나(예: EC2 Auto Scaling 그룹 사용) 여러 데이터베이스 읽기 복제본에 부하를 분산하세요.
• 애플리케이션 코드 최적화: 비효율적인 알고리즘, 과도한 데이터베이스 쿼리 또는 메모리 누수가 있는지 애플리케이션 코드를 검토하세요.
• 캐싱: Amazon ElastiCache(Redis 또는 Memcached) 또는 정적 콘텐츠용 Amazon CloudFront를 사용하여 캐싱 전략을 구현하여 백엔드 서비스의 부하를 줄이세요.
• 데이터베이스 최적화: SQL 쿼리를 튜닝하고, 적절한 인덱스를 추가하거나, Amazon Aurora와 같은 더 나은 성능의 데이터베이스 솔루션으로 마이그레이션하는 것을 고려하세요.
• 스토리지 최적화: 적절한 EBS 볼륨 유형(예: 범용 gp3, 높은 IOPS용 io2)을 선택하거나 비용 및 성능 최적화를 위해 Amazon S3 Intelligent-Tiering을 활용하세요.

예시: 높은 EC2 CPU 사용률 진단

1. CloudWatch 지표 확인: CloudWatch로 이동하여 EC2를 선택하고 인스턴스의 CPUUtilization 지표를 확인하세요. 80-90% 이상으로 지속적으로 높다면 추가로 조사하세요.
2. 인스턴스에 SSH 접속: top, htop 또는 ps와 같은 도구를 사용하여 CPU를 가장 많이 소비하는 프로세스를 식별하세요.
3. 애플리케이션 로그 분석: 높은 CPU 사용량과 관련될 수 있는 애플리케이션 로그의 오류 또는 패턴을 찾으세요.
4. 확장 고려: 워크로드가 정당하고 더 이상 최적화할 수 없는 경우 인스턴스 크기를 늘리거나 EC2 Auto Scaling을 활성화하는 것을 고려하세요.

연결 문제

연결 문제는 사용자가 애플리케이션에 액세스하지 못하게 하거나 AWS 리소스 간의 통신을 방해할 수 있습니다.

일반적인 연결 시나리오

• EC2 인스턴스에 연결할 수 없음: VPC 내의 인스턴스가 인터넷이나 다른 인스턴스에서 액세스할 수 없을 수 있습니다.
• VPC 간 연결 실패: 다른 VPC 간의 리소스 연결 문제.
• 서비스 엔드포인트를 사용할 수 없음: VPC 내에서 AWS 서비스(예: S3, RDS)에 연결할 수 없음.

문제 해결 단계

1. VPC 네트워크 구성 검토:

   • 보안 그룹: 인스턴스에 연결된 보안 그룹이 올바른 소스 IP 주소 또는 보안 그룹의 필수 포트에서 인바운드 트래픽을 허용하는지 확인하세요. 보안 그룹은 상태 저장(stateful)입니다.
   • 네트워크 액세스 제어 목록(NACL): 서브넷과 연결된 NACL이 인바운드 및 아웃바운드 트래픽을 허용하는지 확인하세요. NACL은 상태 비저장(stateless)이므로 양방향에 대한 규칙이 필요합니다.
   • 라우팅 테이블: 서브넷의 라우팅 테이블을 확인하여 인터넷(인터넷 게이트웨이 또는 NAT 게이트웨이를 통해), 다른 서브넷 또는 피어링된 VPC로의 올바른 라우팅이 있는지 확인하세요.
   • 서브넷 설정: 인스턴스가 올바른 서브넷에 있고 서브넷에 적절한 라우팅 테이블 연결이 있는지 확인하세요.

2. 인터넷 게이트웨이(IGW) / NAT 게이트웨이 확인:

   • IGW: 퍼블릭 서브넷에 인터넷 액세스를 위한 IGW 경로가 있는지 확인하세요.
   • NAT 게이트웨이: 프라이빗 서브넷의 인스턴스가 인터넷에 액세스해야 하는 경우 NAT 게이트웨이가 올바르게 구성되었는지, 탄력적 IP와 연결되었는지, 프라이빗 서브넷의 라우팅 테이블에서 해당 게이트웨이를 가리키는 경로가 있는지 확인하세요.

3. VPC 피어링 / 트랜짓 게이트웨이 확인: VPC 간 통신의 경우 VPC 피어링 연결 또는 트랜짓 게이트웨이 연결이 활성 상태이고 관련된 모든 VPC의 라우팅 테이블이 피어링된 VPC CIDR 블록 또는 트랜짓 게이트웨이에 대한 경로를 포함하도록 업데이트되었는지 확인하세요.

4. DNS 확인 검사: VPC가 DNS(예: VPC_CIDR_PLUS_2의 AmazonProvidedDNS)를 사용하도록 구성되어 있고 DNS 확인이 올바르게 작동하는지 확인하세요. 인스턴스에서 dig 또는 nslookup을 사용하여 테스트하세요.

5. AWS 네트워크 연결성: AWS Reachability Analyzer를 사용하여 VPC 내 또는 VPC 간 AWS 리소스 간의 연결 문제를 진단하세요.

예시: 인터넷에서 EC2 인스턴스에 액세스할 수 없음

1. 퍼블릭 IP 주소: EC2 인스턴스에 퍼블릭 IP 주소가 할당되어 있습니까? 퍼블릭 서브넷에 있습니까?
2. 보안 그룹: 인스턴스에 연결된 보안 그룹을 확인하세요. 0.0.0.0/0(또는 특정 IP 범위)에서 오는 트래픽을 허용하는 애플리케이션 포트(예: HTTP의 경우 포트 80, HTTPS의 경우 443)에 대한 인바운드 규칙이 있는지 확인하세요.
3. 네트워크 ACL: 인스턴스의 서브넷과 연결된 NACL을 확인하세요. 응답을 위해 애플리케이션 포트의 인바운드 트래픽과 임시 포트(1024-65535)의 아웃바운드 트래픽을 허용하는지 확인하세요.
4. 라우팅 테이블: 서브넷의 라우팅 테이블에 인터넷 게이트웨이에 대한 경로(0.0.0.0/0 -> igw-xxxxxx)가 있는지 확인하세요.
5. 인스턴스 상태: 인스턴스가 실행 중입니까?

서비스 가용성 문제

미션 크리티컬 애플리케이션의 경우 고가용성을 보장하는 것이 중요합니다. 다운타임은 심각한 비즈니스 영향으로 이어질 수 있습니다.

고가용성을 위한 전략

• 다중 AZ 배포: 데이터베이스(RDS Multi-AZ) 및 애플리케이션 서버와 같은 중요 리소스를 리전 내 여러 가용 영역(AZ)에 배포하세요. 하나의 AZ가 실패하면 트래픽이 자동으로 다른 AZ로 장애 조치될 수 있습니다.
• 로드 밸런싱: Elastic Load Balancing(ELB) - Application Load Balancer(ALB), Network Load Balancer(NLB) 또는 Classic Load Balancer(CLB) -를 사용하여 여러 AZ의 여러 인스턴스에 트래픽을 분산하세요. ELB 상태 확인은 비정상 인스턴스를 자동으로 순환에서 제거합니다.
• Auto Scaling: EC2 Auto Scaling을 구현하여 비정상 인스턴스를 자동으로 교체하고 수요 및 상태 확인에 따라 용량을 확장 또는 축소하세요.
• 무상태 애플리케이션: 애플리케이션을 무상태(stateless)로 설계하여 데이터 손실이나 중단 없이 개별 인스턴스를 더 쉽게 교체하거나 확장할 수 있도록 하세요.
• 정상적 성능 저하: 일부 종속성을 사용할 수 없더라도 기능이 축소될 수 있지만 애플리케이션이 작동하도록 설계하세요.

가용성 문제 해결

1. 상태 확인:

   • ELB 상태 확인: ELB 상태 확인 구성이 정확하고 올바른 엔드포인트와 포트를 테스트하는지 확인하세요.
   • EC2 Auto Scaling 상태 확인: Auto Scaling 상태 확인이 올바르게 구성되었는지 확인하세요.
   • 애플리케이션 상태 엔드포인트: 모니터링할 수 있는 전용 상태 확인 엔드포인트를 애플리케이션에 구현하세요.

2. CloudWatch 알람 분석: 중요한 지표(예: 높은 오류율, 낮은 디스크 공간, 높은 지연 시간)에 대한 CloudWatch 알람을 설정하고 트리거된 알람을 신속하게 조사하세요.

3. AWS Health 검토: 계정 또는 리전에 영향을 미치는 서비스 이벤트에 대해 AWS Health Dashboard를 확인하세요. 광범위한 공개 이벤트의 경우 공개 AWS Health 상태 페이지도 확인하세요.

4. 장애 조치 테스트: 고가용성 전략이 예상대로 작동하는지 확인하기 위해 정기적으로 장애 조치 테스트(예: 한 AZ의 인스턴스 종료)를 수행하세요.

예시: 인스턴스 장애로 인한 애플리케이션 응답 없음

1. ELB 상태 확인: ALB를 사용하는 경우 대상 그룹의 상태를 확인하세요. ALB는 실패한 인스턴스를 자동으로 비정상으로 표시하고 트래픽 전송을 중단해야 합니다.
2. Auto Scaling: 인스턴스가 Auto Scaling 그룹의 일부인 경우 그룹은 비정상 인스턴스를 감지하고(ELB 또는 EC2 상태 확인을 통해) 대체 인스턴스를 시작해야 합니다.
3. CloudWatch 지표: ALB에 대한 HealthyHostCount 및 UnHealthyHostCount와 같은 지표를 CloudWatch에서 모니터링하세요. 또한 나머지 정상 인스턴스의 CPUUtilization 및 NetworkIn/Out을 확인하여 증가된 부하를 처리하고 있는지 확인하세요.
4. 로그: 실패한 인스턴스(가능한 경우)와 새 인스턴스의 로그를 검토하여 장애가 발생한 이유를 이해하세요.

문제를 방지하기 위한 보안 모범 사례

직접적인 문제 해결은 아니지만 보안 모범 사례를 준수하면 사전에 많은 일반적인 아키텍처 문제를 방지할 수 있습니다.

• 최소 권한 원칙: IAM 사용자, 역할 및 서비스에 필요한 권한만 부여하세요.
• 네트워크 분할: VPC, 서브넷, 보안 그룹 및 NACL을 사용하여 리소스를 격리하고 보안 침해의 영향을 제한하세요.
• 정기적인 패치: EC2 인스턴스의 운영 체제와 애플리케이션을 패치된 최신 상태로 유지하세요.
• 암호화: 저장 데이터(예: EBS 볼륨, S3 객체, RDS 데이터베이스)와 전송 중 데이터(TLS/SSL 사용)를 암호화하세요.
• 로깅 및 모니터링: 상세 로깅(CloudTrail, VPC 흐름 로그)을 활성화하고 의심스러운 활동에 대한 모니터링 및 알림을 설정하세요.

소형 런북 만들기

각 프로덕션 워크로드에 대해 실제 요청 경로(DNS, CDN, 로드 밸런서, 컴퓨팅 계층, 데이터베이스, 캐시, 큐, 객체 스토리지 및 외부 종속성)를 명시하는 짧은 런북을 유지하세요. 팀이 가장 먼저 확인해야 할 특정 CloudWatch 지표, 대상 그룹, 보안 그룹, 라우팅 테이블 및 대시보드를 추가하세요. "AWS 확인"은 런북이 아닙니다. "ALB 대상 상태, ECS 서비스 이벤트, RDS Performance Insights 및 인시던트 기간 동안의 최근 CloudTrail 변경 사항 확인"은 오전 2시에 유용합니다.

네트워크 장애와 IAM 장애를 분리하고, 양호한 시간대와 불량 시간대를 비교하며, 여러 계층을 동시에 변경하는 것을 거부할 때 AWS 문제 해결은 훨씬 더 차분해집니다. 요청을 따르고, 첫 번째 중단된 홉을 찾은 다음, 해당 계층을 수정한 후에 다음으로 넘어가세요.