AWS Outposts 모니터링 모범 사례

AWS Outposts는 온프레미스 환경에서 AWS 인프라 및 서비스를 실행할 수 있게 하여 일관된 완전관리형 하이브리드 경험을 제공합니다. Outposts는 온프레미스 시스템에 대한 빠른 접근, 로컬 데이터 처리, 데이터 레지던시, 로컬 시스템과 상호 종속된 애플리케이션 마이그레이션이 필요한 워크로드 및 디바이스를 지원합니다.

Outposts는 고객에게 Amazon CloudWatch 지표와 AWS Health 이벤트를 제공하여 Outposts를 효과적으로 관찰하고 관리할 수 있게 합니다. 이 블로그 게시물은 Outposts와 관련된 관측성 및 이벤트 관리 모범 사례를 중점적으로 다룹니다. 여기에는 여러 계정에 걸친 중앙 집중식 알림, 대시보드, AWS Health Aware를 사용한 사용자 정의 가능한 작업과 같은 운영 전략이 포함되어 있습니다. 올바른 모니터링, 경고, 자동화 설정은 시스템의 고가용성과 운영 우수성을 보장하는 매우 중요한 요소입니다.

지표를 활용하여 Outposts 용량과 네트워크 모니터링하기

Outposts는 Outposts에 대한 데이터 포인트를 Amazon CloudWatch에 게시합니다. CloudWatch를 사용하면 이러한 데이터 포인트에 대한 통계를 지표라고 하는 정렬된 시계열 데이터 집합으로 받게 됩니다. 이러한 지표를 사용하여 Outposts에서 사용하는 모든 AWS 서비스(예: EC2)에 대해 적절한 임계값, 대시보드 및 경고가 포함된 경보를 설정해야 합니다.

태생적으로 Outposts가 가진 온프레미스의 특성으로 인해 용량 관리를 위한 EC2 및 EBS 리소스 사용량 모니터링이 중요합니다. 특히 여러 팀이 Outposts를 함께 사용하는 경우엔 더욱 중요하죠. 개별 리소스 수준의 용량에 관한 CloudWatch 지표뿐만 아니라 CapacityExceptions와 같은 지표도 제공합니다. 이에 대한 더 자세한 내용은 AWS Outposts를 위한 CloudWatch 지표에서 확인할 수 있습니다.

CloudWatch 대시보드는 CloudWatch 콘솔의 사용자 정의 가능한 초기 페이지로서 리소스를 한 눈에 모니터링하는 데 사용됩니다. 이러한 대시보드는 정기적으로(예: 매주) 지표를 검토하여 추세를 검토하는 데 유용하며, 이는 Well Architected Framework의 운영 우수성 원칙에서 강조하는 모범 사례입니다. Outposts 용량 대시보드의 예는 그림 1과 같으며 자세한 단계별 설정 방법은 AWS Outposts 용량 모니터링 블로그에 나와 있습니다. AWS CDK를 사용하여 AWS Outposts를 위한 자동화된 Amazon CloudWatch 대시보드 배포하기 블로그에 공유된 방법을 사용하여 Outposts 전용 CloudWatch 대시보드를 만들 수도 있습니다.

그림 1: 용량 지표를 보여주는 CloudWatch 대시보드

Outposts는 AWS 리전에 연결되어 있으므로 모든 Outposts 기능이 사용 가능한 상태인지 확인하려면 네트워크를 모니터링하는 것이 중요합니다. 서비스 링크는 Outposts에서 선택한 AWS 리전 또는 Outposts의 홈 리전으로 연결되는 링크입니다. ConnectedStatus 지표는 Outposts의 서비스 링크의 연결 상태를 표시하므로 중요한 모니터링 대상입니다.

Outposts 랙의 로컬 게이트웨이를 사용하면 Outposts 서브넷에서 상위 리전에서 사용 가능한 모든 AWS 서비스에 연결할 수 있습니다. Outposts 서버용 로컬 네트워크 인터페이스(LNI)는 EC2 인스턴스를 온프레미스 네트워크에 연결합니다. Outposts 랙 또는 서버와 피어링된 네트워크 장치에서 로컬 게이트웨이 또는 LNI의 BGP 상태를 모니터링하는 것이 좋습니다. 또한 로컬 게이트웨이를 통해 Outposts와 주고받는 데이터의 비트 전송률을 제공하기 위해 IfTrafficIn 및 IfTrafficOut 지표도 제공합니다. Amazon CloudWatch는 여러 CloudWatch 지표를 쿼리하고 수학 표현식을 사용하여 이러한 지표를 기반으로 새로운 시계열 데이터를 생성할 수 있는 지표 수학을 제공합니다. 지표 수학은 집계된 트래픽 비트 전송률을 구할 때 사용할 수 있습니다.

운영에 영향을 주는 지표에 대해서는 경보를 설정해두는 것이 좋습니다. Amazon CloudWatch에서는 지표 경보(단일 CloudWatch 지표나 CloudWatch 지표를 기반으로 한 수학 표현식의 결과를 감시)을 설정할 수 있습니다. 또한, Amazon CloudWatch 경보 사용 설명서에 안내된 대로 복합 경보(사용자가 생성한 다른 경보의 경보 상태를 고려하는 규칙 표현식 포함)을 설정할 수도 있습니다. 다음은 Outposts 서비스 링크의 ConnectedStatus 지표에 대한 경보를 설정하는 예제입니다.

그림 2: Outposts ConnectedStatus CloudWatch 지표 경보 생성

EC2, RDS, ALB 등 Outposts에서 사용하는 모든 서비스에 대한 지표는 모니터링 대상입니다. AWS Managed Services(AMS)는 모니터링과 경보에 대해 다년간의 경험을 가지고 있으며, AMS의 기본 모니터링에서 경보에 대한 설명서에 기본 임계값을 제공하고 있습니다. Outposts 모니터링에서 특히 중요한 서비스 지표 중 하나는 인스턴스가 실행되는 AWS 시스템을 모니터링하는 EC2 시스템 연결성 상태 지표입니다. 이 지표는 리소스의 기본 시스템이 비정상(unhealthy) 상태일 때 장애 조치 및 교체가 필요한지 여부를 판단하는 데 유용합니다.

이벤트 관리, 경보 및 자동화 설정하기

Outposts의 효율적인 운영과 관련하여 모니터링이 필요한 주요 이벤트가 있습니다. 이 중 많은 이벤트가 AWS Health에 표시됩니다. AWS Health는 리소스 성능과 AWS 서비스 및 계정의 가용성에 대한 지속적인 가시성을 제공합니다. AWS Health 이벤트를 사용하여 서비스 및 리소스 변경이 AWS에서 실행 중인 애플리케이션에 어떤 영향을 미치는지 알아볼 수 있습니다. AWS Health는 진행 중인 이벤트를 관리하는 데 도움이 되도록 적절한 시점에 연관성 높은 정보를 제공합니다. 또한 AWS Health는 계획된 활동을 인지하고 이에 대비할 수 있도록 도와줍니다. 이 서비스는 AWS 리소스의 상태 변화에 따라 트리거되는 경보 및 알림을 제공하므로 거의 즉각적인 이벤트 가시성과 지침을 통해 더욱 빨리 문제를 해결할 수 있습니다. 반드시 모니터링이 필요한 두 가지 주요 이벤트는 다음과 같습니다:

EC2 만료: AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED Health 이벤트는 AWS가 인스턴스를 호스팅하는 기본 하드웨어의 복구 불가능한 장애를 감지했을 때 인스턴스가 만료되도록 예약되어 있음을 의미합니다. Outposts에서 이 이벤트는 안전하지 않은 하드웨어를 교체하기 위해 고객과 협력해야 함을 의미합니다. 장애가 발생한 하드웨어에서 장애 조치를 처리할 수 있는 충분한 용량이 Outposts에 있는지 확인하는 것이 중요하며, 고가용성을 위해 자동화된 장애 조치를 사용하는 것이 좋습니다. N+M 가용성 모델을 지원할 수 있는 충분한 컴퓨팅 용량을 주문해야 합니다. 여기서 N은 필요한 서버 수이고 M은 서버 장애를 수용하기 위해 프로비저닝된 예비 서버의 수입니다. AWS Outposts에서 실행 중인 EC2 인스턴스를 호스팅하는 하드웨어에서 복구 불가능한 문제가 감지되면 AWS는 Outposts 유지 관리 페이지에 자세히 설명된 것처럼 영향을 받는 인스턴스에 대한 인스턴스 만료 알림을 보내드립니다.

서비스 링크 다운: AWS_OUTPOSTS_SERVICE_LINK_DOWN Health 이벤트는 Outposts 서비스 링크가 다운되어 Outposts에서 리전으로 연결할 수 없음을 의미합니다. 기존 리소스는 계속 실행되지만 API 호출이 필요한 새로운 AWS 리소스(예: ec2 run-instances)는 서비스 링크 연결이 복구될 때까지 실행할 수 없습니다. AWS Health 이벤트는 ConnectedStatus CloudWatch 지표에 추가로 생성되며, 최소 하나 이상의 옵션을 사용하여 경보를 설정하는 것이 좋습니다. 이 이벤트는 문제를 조사하기 위해 네트워크 팀에서 몇 가지 조치를 취하도록 트리거해야 합니다. 서비스 링크 문제 해결에 대한 가이드는 AWS Outposts 랙 네트워크 문제 해결 체크리스트에서 확인할 수 있습니다.

이러한 AWS Health 이벤트는 AWS EventBridge, AWS Health API 및 이메일로 표시됩니다. 계정 관리 설명서에 명시해 놓은 것처럼 올바른 대상이 이벤트를 수신할 수 있도록, 특히 운영 담당자의 연락처를 정확한 정보로 업데이트할 것을 권고합니다. AWS Health Aware를 사용하면 조직 및 개인 AWS 계정에 대한 AWS Health 알림을 사용자 정의할 수 있습니다. 사용자 정의 알림, 경고 및 자동화가 필요할 때 강력한 도구입니다. AWS Health 이벤트를 자동화하고 알림을 사용자 정의하는 더 많은 예는 AWS Health Tools에서 확인할 수 있습니다(예: Amazon Simple Notification Service (SNS) 알림 및 Slack 통합).

그림 3: 계정과 서비스 전반에 걸친 AWS Health API 이벤트 개요

AWS 모니터링 및 분석 도구 활용하기

CloudWatch와 AWS Health외 모니터링 및 진단에 사용할 수 있는 다른 도구가 어떤 것이 있는지 아는 것도 중요합니다. 많은 서드 파티 파트너 모니터링 제품이 Amazon CloudWatch 및 AWS Health와 통합되어 Outposts에서 애플리케이션 상태를 end-to-end로 파악하는 데 도움을 줍니다. 다음은 모니터링 도구 모음에 추가할 수 있는 AWS의 몇 가지 추가 기능입니다:

CloudTrail 로그

AWS CloudTrail을 사용하여 AWS API 호출에 대한 자세한 정보를 캡처하세요. 이러한 호출은 Amazon S3에 로그 파일로 저장할 수 있습니다. 이 CloudTrail 로그를 사용하여 어떤 호출이 수행되었는지, 호출이 발생한 소스 IP 주소, 호출을 수행한 사람, 호출이 수행된 시간 등의 정보를 확인할 수 있습니다. CloudTrail 로그에는 AWS Outposts에 대한 API 작업 호출 정보가 포함되어 있습니다. 또한 Amazon EC2 및 Amazon EBS와 같은 Outposts의 서비스에서 호출하는 API 작업에 대한 정보도 포함되어 있습니다. 자세한 내용은 CloudTrail의 AWS Outposts 정보를 참조하세요. API 이슈의 경우, AWS CloudTrail Lake에서 쿼리를 실행하여 실패한 API 호출을 신속하게 격리할 수 있습니다. 예를 들어, 다음 코드는 문제의 원인이 될 수 있는 보안 그룹 변경 사항을 표시하는 방법을 보여줍니다:

SELECT eventname, useridentity.username, sourceIPAddress, eventtime, element_at(requestParameters, 'groupId') as SecurityGroup, element_at(requestParameters, 'ipPermissions') as ipPermissions
FROM $EDS_ID
WHERE (element_at(requestParameters, 'groupId') like '%sg-%')
and eventtime > '2023-05-01T00:00:00Z'
order by eventtime asc;

VPC 흐름 로그

VPC 흐름 로그를 사용하여 Outposts로 들어오고 나가는 트래픽과 Outposts 내부의 트래픽에 대한 자세한 정보를 캡처할 수 있습니다. 흐름 로그 레코드는 VPC의 네트워크 흐름을 나타냅니다. 각 레코드는 집계 간격 내에서 발생하는 네트워크 인터넷 프로토콜(IP) 트래픽 흐름(네트워크 인터페이스별로 5-tuple로 표시됨)을 캡처합니다. 마찬가지로 ELB 액세스 로그를 사용하여 Outposts의 Application Load Balancer에 전송된 요청에 대한 자세한 정보를 검사할 수 있습니다. Amazon Athena는 VPC 흐름 로그 예제 문서에 설명된 대로 Amazon VPC 흐름 로그용 Athena 테이블을 생성한 후 쿼리를 사용하여 흐름 로그를 쉽게 분석할 수 있게 해줍니다. 예를 들어, 다음 쿼리는 거부된 모든 TCP 연결을 나열하고 새로 생성된 날짜 파티션 열인 date를 사용하여 이러한 이벤트가 발생한 요일을 추출합니다:

SELECT day_of_week(date) AS
date,
interface_id,
srcaddr,
action,
protocol
FROM vpc_flow_logs
WHERE action = 'REJECT' AND protocol = 6
LIMIT 100;

거부된 TCP 연결을 보여주는 쿼리 출력의 예는 다음과 같습니다:

Traffic Mirroring

Traffic Mirroring을 사용하여 네트워크 트래픽을 Outposts에서 Outposts의 대역 외 보안 및 모니터링 어플라이언스로 복제하고 전달할 수 있습니다. 이렇게 미러링된 트래픽은 콘텐츠 검사, 위협 모니터링 또는 문제 해결에 사용할 수 있습니다.

AWS X-Ray

AWS X-Ray를 사용하면 애플리케이션을 통해 이동하는 요청을 전체적으로 파악하고 페이로드, 함수, 추적, 서비스 전반에 걸쳐 시각적 데이터를 필터링할 수 있습니다. Outposts에서 AWS X-Ray 데몬은 EC2 인스턴스에서 트래픽을 수신하고, 원본 세그먼트 데이터를 수집한 후 이를 AWS X-Ray API로 전달할 수 있습니다.

CloudWatch Synthetics

카나리아를 사용하여 리소스에 대한 사전 모니터링을 수행할 수 있습니다. Amazon CloudWatch Synthetics는 일정에 따라 실행되는 구성 가능한 스크립트인 카나리아를 생성하여 엔드포인트와 API를 모니터링할 수 있습니다. 예를 들어, 서비스 링크 또는 로컬 게이트웨이를 통해 AWS 리전의 애플리케이션에서 Outposts로의 HTTPS 트래픽을 테스트하는 카나리아를 설정할 수 있습니다.

AWS Incident Detection and Response

AWS Incident Detection and Response는 AWS Enterprise Support 고객에게 Outposts에서 선택한 워크로드에 대한 사전 예방적 모니터링 및 인시던트 관리 기능을 제공합니다. AWS Incident Detection and Response는 잠재적인 워크로드의 장애 가능성을 줄이고 중요한 인시던트로부터 빠르게 복구할 수 있도록 설계되었습니다.

다중 계정 기능 이용하기

AWS Resource Access Manager (RAM)는 AWS 계정 간에 리소스를 안전하게 공유할 수 있도록 도와줍니다. AWS Outposts 소유자는 Outposts 사이트 및 서브넷을 포함한 Outposts 및 Outposts 리소스를 AWS Organization 내의 다른 AWS 계정과 공유할 수 있습니다. Outposts 소유자는 Outposts 리소스를 중앙에서 생성 및 관리하고 AWS Organization 내의 여러 AWS 계정에서 리소스를 공유할 수 있습니다.

Outposts 소유자는 아래의 대상과 Outposts 리소스를 공유할 수 있습니다:

• AWS Organizations 조직 내 특정 AWS 계정
• AWS Organizations 조직 내 조직 단위(OU)
• AWS Organizations 조직 전체

Outposts 소유자로부터 공유받은 리소스를 사용하는 AWS 계정은 다른 AWS 계정이 소유한 리소스를 보거나 수정할 수 없으며 공유받은 Outposts를 수정할 수 없습니다. 공유받은 Outposts 리소스를 다른 계정과 다시 공유할 수는 없으며, Outposts 리소스를 공유할 때에는 AWS 조직 내 계정에게만 공유 가능합니다.

조직의 계정과 Outposts 리소스를 공유하는 경우, 소비자 계정에서는 Outposts 리소스와 연결된 CloudWatch 지표를 사용할 수 없습니다. Amazon CloudWatch 교차 계정 관측성을 사용하면 리전 내의 여러 계정에 걸쳐 있는 애플리케이션을 모니터링하고 문제를 해결할 수 있습니다. 계정 경계 없이 연결된 모든 계정에서 지표, 로그 및 추적을 원활하게 검색, 시각화 및 분석할 수 있습니다.

그림 4: 계정 및 Outposts 전반에 걸친 Outposts 지표를 보여주는 CloudWatch 대시보드

또한, 소비자 계정은 Outposts에서 사용 가능한 현재 인스턴스 유형을 얻기 위해 Outposts CLI 명령을 실행할 수 있습니다. Outposts에서 여러 계정과 공유 리소스를 사용할 때 이벤트를 모니터링하려면 AWS Health Aware 기능을 사용하여 적절한 소유자에게 알림을 보내 조치를 취하거나 올바른 자동화를 설정하도록 권고합니다.

결론

올바른 모니터링, 경고, 자동화에 대한 설정은 시스템의 고가용성과 운영 우수성을 보장하는 매우 중요한 요소입니다. Outposts가 가진 온프레미스의 특성으로 인해 Outposts 전반에 걸친 용량 활용률과 네트워크 상태를 모니터링하는 것이 중요합니다.

AWS Resource Access Manager를 이용하면 현재의 AWS 조직 전략을 활용하여 여러 팀이 안전하게 Outposts 리소스를 공유할 수 있습니다. CloudWatch 지표와 경보를 단일 모니터링 계정으로 중앙에서 관리하면 Outposts에 대한 CloudWatch 지표를 한 눈에 볼 수 있으며, AWS 조직 내의 여러 계정에서 공유된 Outposts 리소스와 관련된 지표를 볼 수 있습니다. AWS Health Aware를 사용하면 AWS Health 이벤트에 대한 응답을 이용해서 계정 전반에 걸친 사용자 정의 알림 및 경보를 생성할 수 있습니다.

이제 여러분도 AWS 모니터링 및 분석 도구를 활용하여 Outposts의 용량 및 네트워크를 모니터링하고, 이벤트를 관리하고, 알림 및 자동화를 설정하기 위한 Outposts 지표를 설정하실 수 있기를 바랍니다.

– Tipu Qureshi, Senior Principal Engineer, AWS Support Engineering
– Jared Thompson, Hybrid Edge Specialist Solutions Architect, AWS

이 글은 AWS Cloud Operations & Migrations Blog의 Monitoring best practices for AWS Outposts를 김지현 솔루션즈 아키텍트가 한국어로 번역 및 편집한 글입니다.