How Circle K accelerated DevOps incident triage to under 15 minutes with Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Circle K는 Amazon Bedrock 기반 장애 초기 분석 자동화로 평균 분석 시간을 15분 미만으로 줄였으며, 데이터와 분석 맥락의 증가에 대응해 Amazon Bedrock Flows에서 Amazon Bedrock AgentCore로 실행 구조를 전환했다.

📌 핵심 요약

• 27개국에서 17,200개 이상의 매장을 운영하는 Circle K는 장애 발생 후 수동 조사에 통상 45~60분이 걸리는 문제에 대응했으며, 팀 내부 사고 대응 지표 기준으로 평균 초기 분석 시간을 15분 미만으로 줄여 67~75% 단축했다고 밝혔다.
• Circle K는 모델 호스팅과 도구 조율 등의 운영 부담, 기존 AWS 환경과의 통합, 내부 문서 검색 및 민감한 운영 데이터 처리 요건을 고려해 Amazon Bedrock을 선택했다.
• 초기 Amazon Bedrock Flows 구조는 Grafana 알림을 받아 AWS 자원과 OpenSearch 데이터를 병렬 조사한 뒤 GitHub를 검색하고, 원인 후보·근거·담당자·권장 조치를 담은 요약을 Slack으로 전달했다. 알림부터 메시지까지는 장애 복잡도에 따라 5~15분이 걸렸다.
• 예시 장애에서는 HTTP 5xx 오류율이 3분 연속 5%를 넘자 데이터베이스 연결 고갈, 애플리케이션 로그, 요청마다 연결을 생성하는 코드를 종합했다. 분석 결과는 마케팅 캠페인에 따른 트래픽 증가와 연결 풀 최대치 50의 부족을 원인으로 제시하고 연결 재사용 또는 Amazon RDS Proxy 도입 등을 권고했다.
• 서비스 집합은 그대로였지만 로그와 지식 베이스가 커지면서 일부 분석이 단일 Flow 노드의 처리 범위를 넘었다. 전환 후에는 단일 에이전트가 Amazon Bedrock AgentCore Runtime 세션에서 조사하고 AgentCore Gateway로 데이터 소스에 접근하며, Lambda에 15분 이내 결과를 반환한다. Runtime 자체는 최대 8시간 세션을 지원한다.

🧩 주요 포인트

1. 반복적인 로그 조회·상태 확인·문서 검색의 자동화 → 담당자의 서비스 숙련도에 따라 달라질 수 있는 초기 조사에 일관된 맥락과 근거를 제공하고 운영 판단을 지원한다.
2. AWS·OpenSearch 조사 후 GitHub 검색과 최종 요약을 수행하는 순서 → 검색 대상을 구체화하고 인프라 증상에서 코드 수준의 수정 제안으로 분석을 연결한다.
3. 데이터 증가에 따른 Amazon Bedrock Flows의 제약과 AgentCore Runtime 전환 → 긴 분석을 수용할 여지를 확보했지만, 현재 Lambda 연동 경로의 결과 반환 시간은 15분 이내로 유지된다.

🧠 상세 정리

1. 사업 규모 확대와 장애 초기 분석의 부담

Circle K는 27개국에서 17,200개 이상의 편의점과 주유 소매 매장을 운영하며, AWS에서 실행되는 클라우드 네이티브 인프라로 판매시점 관리 시스템, 멤버십 애플리케이션, 전기차 충전 애플리케이션을 지원한다. 원문이 설명하는 일반적인 DevOps 장애 대응에서는 알림이 발생한 뒤 엔지니어가 로그와 서비스 상태를 확인하고 여러 도구의 증상을 연결하는 데 45~60분을 쓰며, 실제 복구는 그 이후에 시작된다. Circle K에서도 디지털 운영이 확대되면서 서비스와 알림이 늘어 이러한 조사 부담이 커졌다. 이에 회사는 Amazon Bedrock을 이용해 장애를 자율적으로 조사하고 구조화된 결과를 Slack으로 전달하는 시스템을 구축했다. 도입 후 평균 초기 분석 시간은 15분 미만으로 줄었으며, 67~75%라는 단축률은 팀 내부 사고 대응 지표에 근거한 수치다.

2. 반복 조사와 담당자별 편차를 줄이려는 목표

Circle K의 DevOps 팀은 Grafana로 여러 AWS 계정의 인프라를 모니터링하며, 컨테이너 재시작, 오류율 상승, 지연 급증, 배포 실패 등의 알림을 처리한다. 기존 조사에서는 Amazon CloudWatch의 최근 로그, Amazon OpenSearch Service의 애플리케이션 추적 정보, Amazon ECS 태스크 상태를 확인하고 GitHub의 내부 런북과 증상을 대조했다. 이 과정은 필요한 정보를 제공했지만, 서비스가 추가될수록 같은 로그 쿼리와 상태 점검, 문서 검색을 반복해야 한다는 부담도 드러냈다. 또한 담당자가 해당 서비스를 얼마나 잘 아는지에 따라 조사 깊이와 속도가 달라질 수 있었고, 여러 도구를 오가는 작업은 대응 속도와 모범 사례의 일관된 적용을 저해할 수 있었다. 팀이 시작한 연구개발의 목표는 반복적인 맥락 수집을 자동화하고 실행 가능한 조사 결과를 제공하면서 엔지니어의 운영 판단을 지원하는 것이었다.

3. Amazon Bedrock을 선택한 운영·검색·보안상의 이유

팀은 자체 관리 인프라에서 오픈 소스 에이전트 프레임워크를 운영하는 방안도 검토했지만, 이 경우 모델 호스팅, 프롬프트 버전 관리, 도구 조율, 보안 통제를 직접 맡아야 했다. Amazon Bedrock은 단일 API로 기반 모델에 접근하고 코드를 다시 작성하지 않고도 모델을 교체할 수 있게 했으며, 기존 IAM 정책과 Amazon VPC 구성, 로깅 파이프라인에도 맞았다. 에이전트의 도구 사용과 조율 기능은 AWS API 호출, 데이터베이스 조회, 문서 검색을 지원해 별도의 조율 코드 부담을 줄였다. Amazon Bedrock Knowledge Bases는 서비스 설명을 담은 제품 카드의 수집과 검색을 관리해 별도 벡터 데이터베이스 운영을 피할 수 있게 했고, 팀은 프롬프트와 도구 정의에 집중했다. 원문은 Amazon Bedrock이 고객 데이터를 모델 제공업체와 공유하거나 기반 모델 학습에 사용하지 않는다고 설명하며, 이러한 처리 방식이 민감한 로그와 내부 서비스 정보를 다루는 Circle K의 보안 요건을 충족했다고 밝힌다.

4. 초기 Flows 구조의 알림 수신과 병렬 조사

초기 시스템에서는 Grafana 알림이 Amazon SNS로 전달되고, 이어 Amazon SQS 대기열에 들어가면 AWS Lambda가 메시지를 가져와 알림 내용을 추출하고 Amazon Bedrock Flows를 호출했다. Flow 내부에서는 AWSResourceExplorerAgent와 OpenSearchExplorerAgent가 병렬로 실행되어 인프라와 애플리케이션 측면의 정보를 각각 수집했다. AWSResourceExplorerAgent는 AWS Organizations로 관리되는 여러 워크로드 계정에서 Amazon ECS 태스크 상태, Application Load Balancer 대상 상태, CloudWatch 지표와 로그를 확인했다. OpenSearchExplorerAgent는 Amazon OpenSearch Service의 애플리케이션 로그와 분산 추적 정보를 조회했으며, 반환되는 로그가 많아 별도 에이전트로 분리함으로써 각 에이전트의 컨텍스트 창을 관리 가능한 수준으로 유지했다. 또한 이 에이전트만 지식 베이스에 접근하도록 구성했고, 지식 베이스의 제품 카드에는 각 서비스와 의존 관계가 기록되어 있었다.

5. GitHub 조사와 근거를 결합한 Slack 요약

병렬 조사가 끝나면 GitHubExplorerAgent가 두 에이전트의 결과를 받아 영향을 받은 서비스의 GitHub 저장소를 찾고, 애플리케이션 코드와 인프라 정의, 최근 커밋을 검색했다. 이 순서는 앞선 조사로 검색 대상을 구체화한 뒤 문제의 발생 지점과 수정 방안을 찾게 하려는 설계였다. 세 에이전트의 출력은 도구가 연결되지 않은 단일 모델 호출인 AnalysisPrompt 노드로 모였으며, 여기서 AWS 자원 정보와 OpenSearch 로그, GitHub 맥락을 종합했다. 최종 결과에는 유력한 근본 원인, 이를 뒷받침하는 근거, 영향을 받은 서비스와 담당자, 권장 복구 단계가 일정한 형식으로 담겼고, 원문은 당직자가 2분 이내에 훑어볼 수 있는 형식이라고 설명한다. Flow는 결과를 호출한 Lambda에 반환하고 Lambda가 Slack 채널에 게시했으며, 전체 소요 시간은 장애 복잡도에 따라 알림 발생 후 5~15분이었다.

6. 데이터베이스 연결 고갈을 추적한 예시

원문의 예시는 한 서비스의 HTTP 5xx 오류율이 3분 연속 5%를 초과해 Grafana 알림이 발생하는 상황으로 시작한다. AWSResourceExplorerAgent는 데이터베이스 연결 풀이 고갈되고 ECS 서비스가 재시작을 시도하는 상태를 확인하며, OpenSearchExplorerAgent는 PostgreSQL 데이터베이스 연결에서 발생한 'connection refused' 로그와 해당 의존성을 설명하는 제품 카드를 가져온다. GitHubExplorerAgent는 저장소와 인프라 파일에서 Amazon RDS 정의를 찾고, 서비스가 기존 연결을 재사용하지 않고 요청마다 새 연결을 연다는 점을 발견한다. AnalysisPrompt는 이를 알림 10분 전에 시작된 예정된 마케팅 캠페인과 연결하며, 예시 Slack 메시지는 연결 풀 최대치 50의 부족, 14:32 UTC의 연결 오류, 14:30 이후 ECS 태스크 재시작 3회를 근거로 제시한다. 권장 조치는 Amazon RDS Proxy를 통한 연결 풀링 또는 코드의 연결 재사용 변경이며, 향후 캠페인을 위한 Auto Scaling 규칙 검토도 포함된다.

7. 데이터 증가로 드러난 Flows의 한계와 Runtime 전환

Amazon Bedrock Flows 기반 구조는 수개월 동안 잘 작동했고 단순한 장애는 10분 미만에 초기 분석을 마쳤지만, 시간이 지나면서 각 조사에 필요한 데이터와 맥락이 커졌다. 서비스 집합 자체는 달라지지 않았음에도 일부 장애는 단일 Flow 노드가 완료할 수 있는 범위를 넘어 더 긴 분석을 요구했다. 팀은 먼저 로그 필터링을 강화하고 컨텍스트 창을 줄였으며 일부 서비스를 별도 Flow로 분리했지만, 이러한 조치가 도움이 된 뒤에도 로그와 지식 베이스는 계속 증가했다. 이후 팀은 에이전트 로직을 컨테이너화해 Amazon Bedrock AgentCore Runtime에 배포했고, 전체 조사를 하나의 세션에서 실행하도록 바꿨다. Runtime은 최대 8시간의 세션을 지원해 현재 조사에 필요한 시간보다 큰 여유를 제공하지만, 이는 플랫폼의 지원 한도이며 Circle K의 실제 조사가 8시간 걸린다는 의미는 아니다.

8. 단일 에이전트와 Gateway를 사용하는 운영 구조

전환 후에도 분석 논리는 유지됐지만, Flows에서 나뉘어 있던 세 전문 에이전트는 AgentCore Runtime 세션에서 실행되는 하나의 에이전트로 통합됐다. Lambda가 세션을 시작하면 에이전트는 여러 계정의 AWS 자원 조회, OpenSearch 로그 수집, GitHub 검색, 지식 베이스의 제품 카드 검색을 수행하고 15분 이내에 결과를 반환하며, 이는 Lambda의 최대 제한 시간 안에 들어간다. Lambda는 반환된 구조화된 요약을 Slack에 게시하므로 알림을 받은 엔지니어가 조사 맥락을 전달받는 흐름은 이어진다. AgentCore Gateway는 Amazon OpenSearch Service, Amazon Bedrock Knowledge Bases, GitHub 등의 데이터 소스를 에이전트가 호출하는 도구로 노출하고, 접근 제어를 중앙화해 데이터 소스 추가나 변경을 단순하게 한다. 제공된 원문은 이어서 Runtime이 확장을 지원한 세 가지 기능을 소개하려는 대목에서 끊기므로, 해당 기능의 구체적인 내용과 이후 설명은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Circle K의 개선은 복구 전에 반복되던 정보 수집과 초기 분석을 줄인 성과다. 제시된 67~75% 단축률을 전체 장애 복구 시간의 감소로 확대 해석해서는 안 된다.
• 초기 구조는 대량 로그를 별도 에이전트로 분리하고 GitHub 검색을 후속 단계로 배치해, 컨텍스트 관리와 검색 범위 구체화를 함께 다뤘다.
• AgentCore Runtime의 최대 8시간 세션 지원과 현재 Lambda 경로의 15분 이내 결과 반환은 서로 다른 제약이다. 실행 플랫폼의 시간 여유가 현재 응답 경로의 제한을 자동으로 바꾸지는 않는다.

✅ 액션 아이템

• Circle K의 평균 초기 분석 시간 15분 미만과 67~75% 단축 수치를 팀 내부 사고 대응 지표에 근거한 성과로 해석.
• AWS·OpenSearch 조사에서 GitHub 검색으로 이어지는 순서와 로그 조회·상태 확인·문서 검색의 자동화 효과 검토.
• Amazon Bedrock AgentCore Runtime의 최대 8시간 세션 지원과 Lambda의 15분 이내 결과 반환 제약을 함께 고려.

❓ 열린 질문

• Circle K의 내부 사고 대응 지표에서 장애 복잡도에 따라 평균 초기 분석 시간과 67~75% 단축 효과는 어떻게 달라졌는가?
• 로그와 지식 베이스가 계속 커질 때 Amazon Bedrock AgentCore Runtime 구조는 Lambda의 15분 이내 결과 반환을 어떻게 유지하는가?
• AWS·OpenSearch 조사 후 GitHub를 검색하는 순서는 코드 수준의 수정 제안 정확도에 어떤 영향을 주었는가?