Runbooks는 조사하지 않는다. AWS DevOps Agent는 조사한다.

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a Korean translation while keeping the source link, formatting, markdown, and any code blocks unchanged.

개요

DR Toolkit을 마무리하면서 재해 복구의 중요한 부분—런북, RTO/RPO 목표, 사후 분석—을 모두 다뤘다고 생각했습니다. 그 후 실제 사고 라이프사이클을 도식화해 보니 제가 만든 모든 것이 가장자리에만 위치한다는 것을 깨달았습니다. 중간 단계(사고 감지, 지역 간 신호 상관관계 파악, 기본 지역이 활발히 장애를 겪는 동안 근본 원인 찾기)는 포함되지 않았습니다. 이 격차가 바로 이번 시리즈의 주제입니다.

BuildWithAI: DR Toolkit on AWS 시리즈에서는 ap‑southeast‑1에서 서버리스 AWS로 구동되는 여섯 가지 AI 기반 도구를 구축해 DR 계획의 번거로운 부분을 자동화하는 방법을 다뤘습니다. 이 도구들은 사고 전과 사고 후에 수행하는 작업을 처리합니다. 하지만 그 사이—실제 사고 대응—는 전혀 다루지 않았습니다.

이번 시리즈에서는 AWS DevOps Agent를 사용해 그 중간 단계를 다룹니다. 데모 애플리케이션은 PayLedger이며, 이 블로그를 위해 특별히 만든 다중 지역 서버리스 결제 원장입니다. 실제 제품이 아니며 실제 사용자 데이터도 포함하고 있지 않습니다.

• Part 1에서는 격차를 정의하고 DevOps Agent를 소개한 뒤 아키텍처를 살펴봅니다.
• Part 2에서는 전체 설정 과정과 실제 데모를 진행하며, 세 가지 실제 장애를 발생시켰을 때 에이전트가 수행한 조사 과정을 보여줍니다.

---

DR 라이프사이클, 단계별 정리

DR Toolkit은 Prepare 단계에서 충분히 준비되어 있습니다. CloudWatch와 Route 53이 Detect 단계를 담당해 알람이 발생하고 Route 53이 자동으로 트래픽을 정상 지역으로 전환합니다. 하지만 Investigate 단계는 별도의 도구가 없으며, 직접 구축하지 않는 한 지원이 부족합니다. 기본 지역에서 서비스가 중단된 원인을 파악하고, 서비스 간 신호를 연관시켜 해당 지역을 복구하기 위해 팀에 필요한 정보를 제공하는 것이 AWS DevOps Agent의 목표입니다.

Source: …

AWS DevOps Agent

AWS DevOps Agent는 클라우드 운영을 위한 프런티어 에이전트입니다. “프런티어 에이전트”는 AWS가 자율 시스템을 지칭하는 용어로, 다음을 의미합니다:

• 독립적으로 작업하고,
• 동시 작업을 확장하며,
• 지속적으로 실행되어 지속적인 인간 감독이 필요하지 않음.

에이전트는 알람이 발생하는 순간 바로 작업을 시작합니다—수동 트리거가 필요 없습니다.

세 가지 핵심 기능

1. 자율적인 사고 대응

   • 알림이 도착하면 에이전트가 즉시 조사에 착수합니다.
   • 서비스와 리전 전반에 걸친 신호를 연관시킵니다.
   • 동일한 근본 원인에서 파생된 여러 알람이 있으면 이를 하나로 그룹화합니다.
   • 조사하는 근본 원인 카테고리:
     • 시스템 변경
     • 입력 이상
     • 리소스 한계
     • 구성 요소 장애
     • 종속성 문제

2. 사전적인 사고 예방

   • 조사가 끝난 후 에이전트는 네 가지 영역에서 개선 방안을 제시합니다:
     • 가시성(Observability)
     • 인프라 최적화(Infrastructure optimization)
     • 배포 파이프라인(Deployment pipeline)
     • 애플리케이션 복원력(Application resilience)

3. 온‑디맨드 SRE 작업

   • 실제 인프라에 대해 대화형 채팅을 수행합니다.
   • 콘솔을 전환하지 않고도 리소스 상태, 알람 현황, 배포 이력 등을 물어볼 수 있습니다.

아키텍처

서비스는 이중 콘솔 아키텍처를 사용합니다:

추가 기능:

• [AWS DevOps Agent features]
• [About AWS DevOps Agent]

가용성

작성 시점에 AWS DevOps Agent는 ap‑southeast‑1(싱가포르) GA에서는 사용할 수 없습니다. 지원되는 리전은 다음과 같습니다:

us-east-1
us-west-2
eu-central-1
eu-west-1
ap-southeast-2
ap-northeast-1

AWS는 향후 더 많은 리전을 추가할 수 있으니, 시작하기 전에 Supported Regions 페이지를 확인하세요.

• SEA 지역 빌더에게 가장 가까운 두 리전은 ap‑southeast‑2(시드니)와 ap‑northeast‑1(도쿄)입니다.
• 이번 데모에서는 ap‑southeast‑2를 사용했지만, 지원되는 리전이면 어디든 사용할 수 있습니다.
• Agent Space와 조사 데이터는 선택한 리전에 저장되며, 워크로드는 기존 위치에 그대로 유지됩니다.
• 크로스‑리전 모니터링을 통해 에이전트는 연결된 AWS 계정의 리전과 관계없이 리소스를 탐지하고 모니터링합니다.

Note: PayLedger는 이 블로그 시리즈를 위해 만든 데모 프로젝트이며, 실제 비즈니스와 연관되지 않았습니다. 실제 거래를 처리하지 않으며, 개인 식별 정보가 포함되지 않습니다. 모든 데이터는 시드 스크립트에 의해 생성된 합성 데이터입니다.

PayLedger 데모 애플리케이션

결제 원장은 DR(재해 복구) 데모에 실용적인 선택입니다. 요구사항이 명확하기 때문인데, 장애가 발생하면 거래가 실패하고 잔액이 오래된 상태가 됩니다. 다중 지역 설정은 과도한 설계가 아니라 올바른 대응입니다.

엔드포인트

아키텍처 다이어그램

payledger.yourdomain.com  (CloudFront + S3)
        |
   Next.js UI
   (balance, transactions, region indicator)
        | calls
        v
api-payledger.yourdomain.com
        |
   Route 53 (failover routing)
        |-- PRIMARY   --> ap-southeast-1 (Singapore)
        +-- SECONDARY --> ap-northeast-1 (Tokyo)

ap-southeast-1                         ap-northeast-1
+-- API Gateway                        +-- API Gateway
+-- Lambda: createTransaction           +-- Lambda: createTransaction
+-- DynamoDB Global Table (replicated)  +-- DynamoDB Global Table (replicated)

• Route 53은 두 지역 간에 액티브‑패시브 장애 조치를 수행합니다.
• DynamoDB Global Tables는 레저 데이터를 지역 간에 복제하여 일관성을 보장합니다.

---

다음 단계

• Part 1 – 격차를 파악하고 DevOps 에이전트를 소개하며 아키텍처를 살펴봅니다 (이 페이지).
• Part 2 – 전체 설정 및 실시간 데모, 실제 장애 주입 3회와 에이전트 조사 결과를 포함합니다.

계속 지켜봐 주세요!

Architecture Overview

+-- Lambda: listTransactions           +-- Lambda: listTransactions
+-- Lambda: getBalance                 +-- Lambda: getBalance
+-- Lambda: health                     +-- Lambda: health
+-- Lambda: devopsAgentTrigger         +-- Lambda: devopsAgentTrigger
+-- DynamoDB       +-- DynamoDB (replica)
+-- SNS Topic (alarm notifications)    +-- SNS Topic (alarm notifications)
+-- CloudWatch alarms                  +-- CloudWatch alarms

                    ap-southeast-2 (Sydney)
                    +-- AWS DevOps Agent
                        +-- Agent Space
                        +-- Slack (optional)
                        +-- GitHub (optional)

---

Service Layer Summary

---

Fail‑over Behaviour

• 건강 체크 – Route 53이 10 s마다 /health를 호출합니다.
• 장애 복구 트리거 – 체크가 두 번 실패하면 (≈ 20 s), DNS가 트래픽을 보조 리전으로 전환합니다.
• 프론트엔드 표시기 – UI가 5 s마다 /health를 폴링하고 색상 배지를 표시합니다:
  • 녹색 – 싱가포르 (PRIMARY)
  • 주황색 – 도쿄 (FAILOVER)
• 데이터 복제 – DynamoDB 글로벌 테이블이 잔액 및 거래 내역을 리전 간에 동기화합니다. 장애 복구 후 데이터는 동일하며, 제공되는 리전만 변경됩니다.
• 장애 주입 시나리오 – ap‑southeast‑1 (싱가포르)에 장애가 주입되면 건강 체크가 실패하기 시작하고, Route 53이 약 20 s 내에 트래픽을 ap‑northeast‑1 (도쿄)로 재라우팅합니다. 사용자는 DevOps 에이전트가 조사하는 동안 도쿄에서 계속 서비스를 받습니다. 근본 원인이 해결되면 주 리전이 복구되고 Route 53이 원래 리전으로 복귀합니다.

결함 주입 매트릭스

세 가지 결함이 python scripts/fault.py inject 로 동시에 트리거됩니다. 기본 모드에서는 서비스당 하나의 고유한 결함을 할당합니다.

• ap‑southeast‑1에서 하나의 알람이 발생합니다.
• 조사 과정에서 세 가지 다른 근본 원인이 나타납니다.
• DevOps 에이전트는 단일 실행에서 세 가지를 모두 풀어야 합니다 – 각각의 결함을 개별적으로 처리하는 것보다 더 어려운 테스트입니다.

재해 복구 (DR) 툴킷 컨텍스트

• Prepare 단계는 DR 툴킷이 다룹니다.
• 이 시리즈는 Investigate와 Recover에 초점을 맞춥니다 – 알람이 발생한 이후에 일어나는 단계들입니다.

AWS DevOps Agent는 조사에 DR 툴킷이 필요하지 않습니다. 에이전트는:

1. 토폴로지를 읽습니다.
2. 서비스 간 신호를 연관시킵니다.
3. 근본 원인을 식별합니다.
4. 결과를 자동으로 Slack에 게시합니다.

선택적으로, DR 툴킷이 생성한 런북을 Custom Skill로 미리 로드하여 에이전트에 추가적인 아키텍처 지식을 제공할 수 있습니다.

---

Source:

Part 2 – Hands‑On Demo

다음 파트에서는:

1. PayLedger를 두 지역에 모두 배포합니다.
2. Route 53 장애 조치를 구성합니다.
3. Agent Space(Slack, GitHub 등)를 설정합니다.
4. 세 가지 동시 장애를 실행합니다.

에이전트의 타임라인, 발견 내용, 근본 원인 식별 및 완화 권고 사항을 단계별로 살펴봅니다.

시작하기 / 포크하기

• 저장소:
• 프로젝트 이름: payledger-aws-devops-agent

PayLedger – 다중 지역 서버리스 결제 원장 (데모용).
Lambda, DynamoDB Global Tables, 및 Route 53 장애 조치 라우팅을 사용하여 ap‑southeast‑1(싱가포르, 기본) 및 ap‑northeast‑1(도쿄, 보조) 지역에 배포되었습니다.
참고: 이것은 시연용 프로젝트이며 실제 거래를 처리하지 않으며 PII(개인 식별 정보)를 포함하지 않습니다.

---

Architecture Diagram (high‑level)

payledger.yourdomain.com (CloudFront + S3)
          │
   Next.js static UI (balance, transactions, region indicator)
          │
          ▼
api-payledger.yourdomain.com
          │
Route 53 fail‑over routing
├── PRIMARY   ──▶ apse1-api-payledger.yourdomain.com  ← health check
└── SECONDARY ──▶ apne1-api-payledger.yourdomain.com  ← health check
TTL: 60 s | health check: 10 s interval, 2 failures to trip
          │
 ┌────────┴─────────┐
 │                  │
ap‑southeast‑1      ap‑northeast‑1
(Singapore)         (Tokyo)
│                   │
│  API Gateway      │  API Gateway
│  (regional)      │  (regional)
│  Lambda: createTransaction
│  Lambda: listTransactions
│  … (other functions)
│
└─ DynamoDB Global Table (replicated)

---

References

• AWS DevOps Agent – 기능, 지원되는 리전 및 개요.
• Amazon DynamoDB Global Tables – 다중 리전 복제.
• Amazon Route 53 – 장애 조치 라우팅 구성.
• Disaster Recovery of Workloads on AWS – 모범 사례 가이드.