Amazon Q Developer를 사용한 AWS Elastic Disaster Recovery 실시간 모니터링

이 글은 AWS Storage Blog에 게시된 Real-time monitoring of AWS Elastic Disaster Recovery using Amazon Q Developer을 한국어 번역 및 편집 하였습니다.

실시간으로 워크로드를 모니터링하고 관리하는 능력은 복원력 목표를 달성할 수 있도록 보장하는 기본 요구사항입니다. 주요 사용자 활동과 중요한 비즈니스 기능의 성능에 대한 가시성을 확보하면 비즈니스 운영에 영향을 줄 수 있는 이벤트에 대한 자동화된 응답을 가능하게 합니다. 효과적인 모니터링은 운영 무결성을 달성할 뿐만 아니라 비용 관리에도 중요합니다. 예를 들어, 불필요한 서버를 실행하거나 감독 없이 리소스 집약적인 시스템을 시작하면 비용이 크게 증가할 수 있습니다. 이러한 위험을 완화하려면 리소스 사용량을 추적하고, 핵심 성과 지표를 모니터링하며, 정보에 입각한 비즈니스 의사결정을 지원하는 실시간 알림을 제공하는 포괄적인 모니터링 전략을 구현하는 것이 중요합니다.

Amazon Q Developer를 사용하면 Amazon Web Services(AWS)에서 운영 이벤트를 모니터링하고 대응할 수 있습니다. Amazon Q Developer를 Slack 채널과 통합하여 워크로드에서 작동하는 이벤트와 작업, 인프라 변경 사항에 대한 실시간 알림을 받을 수 있습니다. AWS Elastic Disaster Recovery는 저렴한 스토리지, 최소한의 컴퓨팅, 특정 시점 복구를 사용하여 온프레미스 및 클라우드 기반 애플리케이션의 빠르고 안정적인 복구로 다운타임과 데이터 손실을 최소화합니다. Amazon Q Developer를 사용하여 Elastic Disaster Recovery 환경을 모니터링함으로써 운영 팀이 잠재적인 문제가 주요 문제가 되기 전에 신속하게 대응할 수 있는 능력을 제공할 수 있습니다.

이 포스트에서는 Amazon Q Developer를 Slack과 통합하여 Elastic Disaster Recovery로 보호되는 리소스와 관련된 중요한 이벤트에 대한 실시간 알림을 받는 과정을 안내합니다. 이 솔루션을 통해 재해 복구 환경을 사전에 모니터링하고, 잠재적인 문제를 조기에 식별하며, 이러한 이벤트에 신속하게 대응할 수 있습니다. 실시간 모니터링을 통해 전반적인 복원력을 개선하고 비즈니스 연속성 목표를 달성할 수 있도록 보장할 수 있습니다.

솔루션

이 포스트에서는 eu-west-1 리전에서 실행되는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 eu-west-2 리전의 Elastic Disaster Recovery로 보호합니다. 먼저 Elastic Disaster Recovery 환경을 모니터링하기 위한 Amazon Simple Notification Service(Amazon SNS) 주제를 생성합니다. 그런 다음 Amazon Q Developer로부터 실시간 알림을 받을 Slack 채널을 생성합니다. Slack 채널을 Amazon Q Developer와 통합하려면 AWS로부터 알림을 받도록 Slack을 구성하고 이후 Amazon Q Developer가 Slack으로 메시지를 보내도록 구성해야 합니다. 완료되면 워크로드에서 작동하는 작업과 이벤트에 대한 실시간 알림을 받도록 Amazon CloudWatch 규칙을 구성합니다. 이 시나리오에서는 StartRecovery와 같은 Elastic Disaster Recovery 변경 API와 “DRS Source Server Data Replication Stalled Change”와 같은 CloudWatch 이벤트를 추적하는 CloudWatch Events 규칙을 생성합니다. 전체 솔루션은 다음 그림 1에 나와 있습니다.

그림1 : 솔루션 개요

전제 조건

이 솔루션을 완료하려면 다음 전제 조건이 필요합니다:

계획된 또는 계획되지 않은 이벤트 중에 장애 조치하기로 결정한 AWS 리전에서 Elastic Disaster Recovery 서비스가 초기화되어야 합니다.
Elastic Disaster Recovery로 보호되는 소스 서버가 있어야 합니다. 교차 리전 사용 사례에 대한 Elastic Disaster Recovery 설정에 대한 구체적인 지침은 이 블로그를 참조하세요.
Slack에 엑세스할 수 있고 채널을 생성하고 Amazon Q Developer와 통합할 수 있는 권한이 있어야 합니다.

세부 실습 단계

다음은 이 솔루션에 필요한 전체 단계를 요약한 것입니다.

Amazon SNS 주제 생성
전용 Slack 채널 설정
Slack을 Amazon Q Developer와 통합
Amazon Q Developer를 Slack과 구성
Amazon CloudWatch 규칙 생성
알림 테스트

1. Amazon SNS 주제 생성

Elastic Disaster Recovery 서비스 환경을 모니터링하려는 리전에서 Amazon SNS 주제를 생성합니다. 이 예제에서는 eu-west-1 리전에서 “DRS” 라는 이름의 주제를 생성합니다.

SNS 주제를 생성하려면:

1.1. Amazon SNS 콘솔에 로그인합니다.

1.2. 탐색 패널에서 주제를 선택합니다.

1.3. 주제 페이지에서 주제 생성을 선택합니다.

1.4. 주제 생성 페이지의 세부 정보 섹션에서 다음을 수행합니다:

1.4.1 유형에서 표준 주제 유형을 선택합니다.

1.4.2. 주제의 이름을 입력합니다.

1.4.3. (선택 사항) 주제의 표시 이름을 입력합니다.

1.5 다른 모든 옵션을 건너뛰고 주제 생성을 선택합니다. 필요한 경우 조직의 정책에 따라 주제를 추가로 사용자 지정할 수 있습니다. Amazon SNS 주제 생성에 대한 자세한 내용은 설명서 페이지를 참조하세요.

주제가 생성되고 주제(Topics) 페이지가 표시됩니다. 다음 그림 2에 표시된 것처럼 세부 정보 섹션에 주제의 이름, ARN, (선택 사항) 표시 이름 및 주제 소유자의 AWS 계정 ID가 표시됩니다.

그림 2 : SNS 주제 세부 정보 페이지

2. Slack 채널 생성

2.1. 알림을 받을 새 Slack 채널을 생성하거나 기존 채널을 사용합니다. Slack 채널을 생성하려면 이 가이드를 따르세요. 이 예제에서는 다음 그림 3에 표시된 것처럼 drs-slack-notifications Slack 채널을 생성하고 가시성을 비공개로 설정합니다.

그림 3: Slack 채널 생성

3. Slack 채널을 Amazon Q Developer와 통합

Amazon Q Developer가 알림을 보낼 수 있도록 하려면 Amazon Q Developer를 Slack과 구성해야 합니다.

3.1 Amazon Q Developer로부터 알림을 받도록 Slack 채널 구성

3.1.1. Slack 채널에서 “/invite @Amazon Q”를 입력하고 다음 그림 4에 표시된 것처럼 키보드의 Enter 키를 누릅니다.

그림 4: Slack에서 Amazon Q Developer 초대

완료되면 그림 5에 표시된 것처럼 Amazon Q Developer가 초대를 통해 Slack 채널에 참여합니다.

그림 5: Amazon Q Developer가 Slack 채널에 초대됨

3.2. Amazon Q Developer가 Slack 채널로 알림을 보내도록 구성

3.2.1. Amazon Q Developer 콘솔을 열고 새 클라이언트 구성을 선택합니다. 채팅 클라이언트 구성에서 Slack을 선택한 다음 그림 6에 표시된 것처럼 클라이언트 구성을 선택합니다.

그림 6: 채팅 클라이언트로 Slack 선택

3.2.2. 이 단계에서는 Slack 워크스페이스를 선택해야 합니다. 다음 그림 7에 표시된 것처럼 워크스페이스를 선택하고 허용을 선택하여 Amazon Q Developer가 AWS Slack 워크스페이스에 액세스할 수 있도록 합니다.

그림 7: Amazon Q Developer가 Slack 워크스페이스에 액세스하도록 허용

웹 브라우저에서 Slack에 로그인하지 않은 경우 먼저 Slack에 로그인하고 웹 브라우저 오른쪽 상단 모서리의 드롭다운에서 올바른 워크스페이스가 선택되었는지 확인하세요.

Amazon Q Developer가 Slack 워크스페이스에 액세스하도록 승인한 후 다음 그림 8에 표시된 것처럼 AWS 콘솔 상단에 “Slack에서 Amazon Q Developer이(가) 승인되었습니다. “라는 메시지가 포함된 녹색 막대가 나타납니다.

그림 8: Amazon Q Developer가 Slack 워크스페이스에 액세스하도록 승인

3.2.3. Amazon Q Developer 콘솔의 워크스페이스 세부 정보 페이지에서 새 채널 구성을 선택합니다. 구성 세부 정보 섹션에서 AWS 콘솔에서 쉽게 식별할 수 있도록 구성 이름을 제공합니다.

이 예제에서는 다음 그림 9에 표시된 것처럼 구성 이름을 aws-drs-slack-notifications로 제공합니다.

그림 9: 구성 이름 제공

3.2.4. 이 구성에 대한 로깅을 활성화하려면 Amazon CloudWatch Logs에 로그 게시를 선택합니다. 그림 10에 표시된 것처럼 요구 사항에 따라 오류만과 모든 이벤트 중에서 선택할 수 있습니다.

Amazon Q Developer용 CloudWatch Logs를 사용하면 Amazon Q Developer가 처리하는 모든 이벤트를 볼 수 있습니다. 또한 Slack 채팅방에 알림이 나타나지 않게 한 오류의 세부 정보도 볼 수 있습니다.

그림 10: CloudWatch Logs에 로그 게시

CloudWatch Logs 사용에는 추가 요금이 부과됩니다. 자세한 내용은 Amazon CloudWatch 요금을 참조하세요.

3.2.5. Slack 채널에서 이번 실습에서 Slack 내에서 이전에 생성한 채널을 선택합니다. Amazon Q Developer는 공개 및 비공개 채널을 모두 지원합니다.

Slack 채널 ID를 찾으려면 Slack 왼쪽 창에서 채널 이름을 마우스 오른쪽 버튼으로 클릭하고 채널 세부 정보 보기를 선택합니다. 다음 그림 11에 표시된 것처럼 채널 ID가 창 하단에 표시됩니다.

그림 11: Slack 채널 ID 보기

Slack 채널 ID를 복사하여 그림 12에 표시된 것처럼 Amazon Q Developer의 Slack 채널 섹션 아래 채널 ID 텍스트 상자에 붙여넣습니다.

그림 12: Amazon Q Developer의 Slack 채널 ID

3.2.6. 권한 섹션에서 채널 구성원에 대한 권한을 선택합니다. AWS Command Line Interface(AWS CLI) 명령도 Slack 채널에서 실행할 수 있으므로, 모든 채널 구성원이 동일한 권한 집합이 필요한 경우 채널 역할을 선택하거나, 채널 구성원이 서로 다른 권한이 필요한 경우 사용자 수준 역할을 선택할 수 있습니다. 다음 그림 13에 표시된 것과 같습니다.

3.2.6.1. 이번 실습에서는 채널 역할을 선택하고 채널 역할 드롭다운 목록에서 템플릿을 사용하여 IAM 역할 생성을 선택합니다.

3.2.6.2. 역할 이름 상자에서 생성하려는 AWS Identity and Access Management(IAM) 역할의 이름을 제공합니다. 이번 실습에서는 역할 이름으로 aws-drs-slack-role을 제공했습니다.

3.2.6.3. 정책 템플릿의 경우 알림 권한 및 Resource Explorer 권한 템플릿이 기본적으로 선택됩니다. 읽기 전용 명령 권한 템플릿과 같이 사용하려는 다른 템플릿을 선택할 수 있습니다. 정책 템플릿을 선택하면 계정에 IAM 권한이 생성됩니다. 이러한 정책은 이전 단계에서 지정한 채널 역할에 연결됩니다.

3.2.6.4. 채널 가드레일 정책의 경우 채널 구성을 보호하기 위해 최대 5개의 가드레일 정책을 선택할 수 있습니다. 기본적으로 ReadOnlyAccess 가드레일 정책이 선택됩니다. 이 정책은 전체 AWS 서비스 제품군에 대한 Get, List 및 Describe 권한을 정의하여 Amazon Q Developer가 이 역할을 사용하여 사용자를 대신하여 해당 서비스에 액세스할 수 있도록 합니다.

가드레일 정책은 채널 구성원이 사용할 수 있는 작업과 Amazon Q Developer가 사용자를 대신하여 수행할 수 있는 작업에 대한 세부적인 제어를 제공합니다. 이들은 사용자 역할과 채널 역할 모두를 제한하고 우선합니다. 예를 들어, 사용자가 관리자 액세스를 허용하는 사용자 역할을 가지고 있고, 채널 역할이나 가드레일 정책이 하나 이상의 서비스에 대한 권한을 제한하는 채널에 속해 있는 경우, 사용자는 더 제한적인 권한을 갖게 되어 관리자 액세스보다 적은 권한을 갖게 됩니다.”

그림 13: 채널 역할 생성 및 역할에 대한 권한 선택

3.2.7. 알림 – 선택 사항에서 이번 실습 시작 부분에서 생성한 SNS 주제를 선택하고 다음 그림 14에 표시된 것처럼 AWS 리전을 선택합니다. 여러 AWS 리전을 모니터링하기 위해 각 AWS 리전에 SNS 주제가 생성되어 있다면 여러 AWS 리전을 추가할 수 있습니다.

그림 14: SNS 알림

3.2.8. 태그에서 Slack 클라이언트에 사용자 지정 태그를 추가합니다. 이번 실습에서는 다음 그림 15에 표시된 것처럼 두 개의 태그를 추가합니다.

그림 15: 채널에 태그 추가

3.2.9. 마지막으로 구성을 선택하여 클라이언트 구성을 생성합니다.

클라이언트 구성이 완료되었습니다. 다음 그림 16에 표시된 것처럼 AWS 콘솔의 녹색 막대에 Slack 채널을 구성했습니다. 라는 성공 메시지가 나타납니다.

그림 16: Slack 채널로 Slack 클라이언트 구성

표 1에 표시된 것처럼 다음 리전에서 다음 API가 실행되는 것을 볼 수 있습니다. 이는 실습 중에 발생하는 잠재적인 문제를 해결하는 데 도움이 될 수 있습니다.

리전	us-east-2	us-east-1	eu-west-1
API	CreateSlackChannelConfiguration GetAccountPreferences	CreateRole CreatePolicy AttachRolePolicy	Subscribe

표 1: API와 리전 매핑

SNS 주제로부터 알림을 받기 위해 이 리전을 선택했기 때문에 subscribe API가 eu-west-1에 표시됩니다.

4. Amazon CloudWatch 규칙 생성

Elastic Disaster Recovery의 변경 API 작업에 대한 Slack 알림을 받으려면 Elastic Disaster Recovery가 구성된 AWS 리전에서 CloudWatch 규칙을 생성해야 합니다.

4.1. CloudWatch 규칙 구성

4.1.1. Amazon EventBridge 콘솔을 엽니다. 탐색 창에서 규칙을 선택합니다. 규칙 생성을 선택합니다.

4.1.2 규칙의 이름과 선택적으로 설명을 입력합니다.

4.1.3. 이벤트 버스에서 default 이벤트 버스를 선택합니다.

4.1.4. 선택한 이벤트 버스에 대해 규칙 활성화 토글 버튼을 켜두고 이벤트 패턴이 있는 규칙 규칙 유형을 선택한 상태에서 그림 17에 표시된 것처럼 다음을 선택합니다.

그림 17: CloudWatch 규칙 세부 정보 정의

4.2. 이벤트 패턴 작성

4.2.1. 이벤트 패턴 작성 페이지에서 이벤트 소스로 기타를 선택합니다. 샘플 이벤트 – 선택 사항 섹션을 무시하고 다음 섹션으로 진행합니다.

4.2.2. 생성 방법 섹션에서 다음 그림 18에 표시된 것처럼 사용자 지정 패턴(JSON 편집기) 옵션을 선택합니다.

그림 18: CloudWatch 이벤트 패턴 및 생성 방법 선택

4.2.3. 이벤트 패턴 섹션에서 알림을 받고자 하는 Elastic Disaster Recovery 서비스 API를 추가하고 그림 19에 표시된 것처럼 다음을 선택합니다. 이 예제에서 JSON의 사용자 지정 이벤트 패턴은 다음과 같습니다:

{
  "source": ["aws.drs"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["drs.amazonaws.com"],
    "eventName": ["InitializeService", "CreateSourceServerForDrs", "DisconnectSourceServer", "StartRecovery", "StartReplication", "StopFailback", "DeleteSourceServer", "ReverseReplication", "StartFailbackLaunch", "DisconnectRecoveryInstance", "DeleteRecoveryInstance"]
  }
}

그림 19: CloudWatch 이벤트 패턴 추가

모든 Elastic Disaster Recovery 서비스 API에 대한 자세한 내용은 이 Elastic Disaster Recovery 설명서를 참조하세요.

4.2.4. 대상 선택 섹션에서 대상 유형에 대해 대상 1로 AWS 서비스를 선택합니다. 대상 선택 드롭다운에서 대상으로 SNS 주제를 선택합니다. 주제 드롭다운에서 이번 실습의 1단계에서 생성한 주제 이름을 선택합니다. 추가 설정 섹션을 무시하고 그림 20에 표시된 것처럼 다음을 선택합니다.

그림 20: SNS 대상 선택

4.2.5. 규칙에 대한 원하는 태그를 입력하고 다음을 선택합니다.

4.2.6. 규칙을 검토하고 규칙 생성을 선택하여 규칙을 생성합니다.

4.2.7. 이 단계들을 다시 따라 Elastic Disaster Recovery에서 지원하는 다양한 CloudWatch 이벤트에 대한 알림을 받기 위한 또 다른 CloudWatch 규칙을 생성합니다. Elastic Disaster Recovery 서비스에서 지원하는 CloudWatch 이벤트에 대한 자세한 내용은 이 Elastic Disaster Recovery 사용자 가이드를 참조하세요.

이 예제에서는 다른 이벤트와 함께 소스 서버의 정체된 데이터 복제와 관련된 CloudWatch 이벤트를 선택합니다. 데이터 복제는 다음을 포함한 다양한 요인으로 인해 정체될 수 있습니다:

네트워크 연결 문제: 소스 서버와 스테이징 서브넷 간의 통신을 방해하는 잘못 구성된 보안 그룹, 네트워크 ACL 또는 라우팅 테이블이 포함될 수 있습니다.
AWS 복제 에이전트 문제: Elastic Disaster Recovery용 AWS 복제 에이전트가 소스 서버 자체의 문제로 인해 소스 서버에서 올바르게 실행되지 않을 수 있습니다.
IAM 권한 문제: 복제 서버에 누락된 IAM 역할, 권한 정책 또는 신뢰 관계 정책과 같은 필요한 IAM 권한이 부족할 수 있습니다.

지속적인 데이터 복제를 유지하는 것은 비즈니스 연속성에 중요합니다. 정체된 복제에 대한 CloudWatch 이벤트를 모니터링하면 이러한 문제를 사전에 식별하고 해결하여 서버에 대한 지속적인 데이터 복제를 신속하게 복원할 수 있습니다.

이 예제에서는 CloudWatch 이벤트를 모니터링하기 위해 이벤트 패턴 작성 섹션에 다음 JSON을 추가합니다:

{
  "source": ["aws.drs"],
  "detail-type": ["DRS Source Server Data Replication Stalled Change", "DRS Recovery Instance Failback State Change", "DRS Source Server Launch Result"]
}

규칙 생성을 완료하려면 섹션 4.2에 설명된 나머지 단계를 따르세요. 이번 실습 시작 부분에서 생성한 동일한 SNS 주제를 대상으로 사용합니다.

5. 알림 테스트

Slack 채널에서 Elastic Disaster Recovery 알림을 테스트하려면 소스 서버 중 하나에 Elastic Disaster Recovery용 AWS 복제 에이전트를 설치하세요. 서버에 AWS 복제 에이전트를 설치하는 방법을 알아보려면 이 Elastic Disaster Recovery 사용자 가이드를 참조하세요.

AWS 복제 에이전트 설치가 성공하면 추가 세부 정보와 함께 CreateSourceServerForDrs API에 대한 Slack 채널에서 알림을 받습니다.

다음 그림 21은 Slack 내에서 받은 알림의 샘플 스크린샷을 보여줍니다.

그림 21: Elastic Disaster Recovery 서비스 에이전트의 성공적인 설치에 대한 Slack 알림

Elastic Disaster Recovery에서 데이터 복제 정체(Stalled)가 발생하면 비즈니스 연속성이 중단될 수 있습니다. 소스 서버에서 복제 서버로의 복제가 중단되어 최신 데이터가 복제되지 않습니다. 이는 다음 그림 22에 표시된 것처럼 Elastic Disaster Recovery 콘솔의 데이터 복제 상태 열에서 정체됨(Stalled) 상태로 표시되며 즉각적인 사용자 주의가 필요합니다.

그림 22: Elastic Disaster Recovery 정체된 복제

“DRS Source Server Data Replication Stalled Change”를 모니터링하는 CloudWatch 이벤트를 통합하면 다음 그림 23에 표시된 것처럼 Slack 채널에서 Amazon Q Developer로부터 알림을 받게 됩니다.

그림 23: 테스트 결과

실습 환경 정리

불필요한 AWS 비용을 최소화하려면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Elastic Disaster Recovery 소스 서버, CloudWatch 이벤트 규칙, Amazon Q Developer의 Slack 클라이언트, SNS 주제를 포함하여 생성한 모든 리소스를 삭제하세요. 이러한 리소스를 실행 상태로 두면 사용하지 않더라도 AWS 청구서에 예상치 못한 요금이 발생할 수 있습니다. 프로비저닝된 모든 리소스를 검토하고 더 이상 필요하지 않은 리소스는 종료하세요.

결론

이 포스트에서는 Amazon Q Developer를 Slack과 통합하여 AWS Elastic Disaster Recovery로 보호되는 리소스와 관련된 중요한 이벤트에 대한 실시간 알림을 활성화하는 단계를 안내했습니다. Elastic Disaster Recovery는 애플리케이션과 데이터를 최신 상태로 신속하게 복구하여 조직이 비즈니스 연속성을 유지할 수 있도록 도와줍니다. 중요한 워크로드 활동에 대한 실시간 알림은 애플리케이션이 필요한 복구 지점 목표(RPO)와 복구 시간 목표(RTO)를 충족할 수 있도록 보장하는 데 중요합니다. 재해 복구 시나리오에서는 매 초가 중요하며, 중단을 감지하고 대응하는 능력이 이러한 목표를 달성하는 것과 사용자를 실망시키는 것 사이의 차이를 만들 수 있습니다.

Amazon Q Developer를 CloudWatch Events 규칙과 통합하면 Elastic Disaster Recovery에 대한 모니터링 기능이 크게 향상됩니다. Amazon Q Developer를 사용하면 Slack과 같은 선호하는 커뮤니케이션 채널에서 직접 실시간 알림을 받을 수 있습니다. 이 블로그에서는 소스 서버에 대한 데이터 복제 변경과 같은 Elastic Disaster Recovery의 특정 작업과 이벤트 추적을 자동화하기 위해 CloudWatch 이벤트 규칙을 구성했습니다.

이 블로그가 유용하기를 바라며 여러분의 피드백을 기다립니다. 서비스에 대한 자세한 내용은 Elastic Disaster Recovery 페이지를 방문하세요. 또한 AWS에서 워크로드를 보호하기 위해 Elastic Disaster Recovery를 사용하고 있는 사용자들의 사례 연구도 살펴볼 수 있습니다.

AWS 기술 블로그