[TroubleShooting] Jenkins 장애 분석

Date

2025/11/18

장애 발생 일시: 2025.11.17 23:50 ~ 00:10

영향 서비스: Jenkins CI 빌드 파이프라인

장애 유형: Jenkins 빌드 중단 / ALB 504 Timeout / SSH 연결 불가 / EBS I/O Bottleneck

1. 개요

2025-11-17 23:50 ~ 00:10 사이, Jenkins를 통해 특정 서비스의 Docker 이미지 빌드 & ECR Push 작업 중 Jenkins UI가 504 Gateway Timeout을 반환하였고, 이후 SSH 접속 또한 불가해지는 장애가 발생했다.

해당 장애는 단순한 네트워크 문제나 Jenkins 자체 오류가 아니라, EC2 내부의 EBS(gp2) 디스크 I/O 병목으로 인한 시스템 정지(hang)로 확인되었다.

본 문서는 장애의 전체 원인, 증상, CloudWatch 지표 분석, 해결 방안, 근본적인 개선 전략을 기술한다.

2. 장애 영향 범위

항목	영향
Jenkins Web UI	접속 불가 (504 Gateway Timeout)
SSH 접속	불가
이미지 빌드	중단됨
Jenkins 컨테이너	Docker 내부에서 정지 상태
NAT Gateway / 네트워크	문제 없음
EC2 상태 체크	정상

→ Jenkins EC2 내부의 디스크 I/O 스톨로 인해 OS 전체가 멈춘 사례

3. 장애 타임라인

시간	이벤트
23:50	Docker build 시작 → I/O 증가
23:55	Jenkins 응답 지연 시작
00:00	DiskOps/ReadBytes 폭상승
00:00~00:03	EBS BurstBalance 급락 / TotalReadTime 폭증
00:03	Jenkins 504 발생
00:05	SSH 접속 불가
00:10	EC2 완전 hang 상태

4. 원인 분석 (Root Cause)

Root Cause: EBS gp2 BurstBalance 고갈 → I/O 스톨(IO Stall)

Jenkins EC2 인스턴스에서 사용 중인 EBS 볼륨 타입이 gp2였으며, Docker build와 ECR push 과정에서 순간적으로 높은 IOPS를 요구하면서 gp2의 버스트 크레딧(Burst Credit)이 소진됨.

그 결과:

•

VolumeTotalReadTime이 최대 119초까지 증가

•

QueueLength 증가

•

디스크 요청이 처리되지 못해 OS 레벨에서 block

•

Jenkins 컨테이너 + SSH 모두 요청 처리 불가

•

인스턴스가 사실상 “멈춘” 상태(hang)

5. CloudWatch 지표 분석

5.1 EC2 측 지표 분석

1) CPUUtilization

•

CPU는 40~60% 수준 → 정상

•

CPU 병목 현상은 아닌 것으로 판단

2) NetworkIn / NetworkOut

•

Docker build와 push 과정에서 일시적으로 증가 → 정상

•

이후 갑자기 0으로 떨어짐 → EC2가 멈춘 상태로 판단됨

3) StatusCheckFailed (System/Instance)

•

모두 0 → OS, 하드웨어, 네트워크 문제 아님

결론

EC2 자체 문제는 아니라고 확인됨 → Storage(EBS) 분석으로 방향 결정

5.2 EBS 측 지표 분석

1) VolumeReadBytes / WriteBytes (데이터 양 폭증)

•

Docker 레이어 생성으로 인해 급격히 증가

•

이는 정상적이지만 → 이후 지표들과 결합하면 비정상 흐름이 나타남

2) VolumeReadOps / WriteOps (Ops 폭발 → I/O 병목 시작)

•

ReadOps는 16만 ops까지 상승

•

WriteOps도 수만 ops 발생

•

gp2는 기본 IOPS가 매우 낮기 때문에(100~300 IOPS 수준), 순간 부하를 절대 감당할 수 없음

3) VolumeTotalReadTime / WriteTime (I/O 스톨 발생) — 핵심 지표

OS가 스토리지 응답을 받을 때까지 걸린 시간

•

정상 값: 1ms ~ 10ms

•

경고 수준: 50ms+

•

장애 수준: 100ms+

•

 이번 장애 값: 119초

4) VolumeQueueLength (대기열 증가)

•

I/O가 처리되지 못해 QueueLength 증가

→ 디스크 요청이 줄서고 있었음

5) BurstBalance (gp2 크레딧 고갈) — 2번째 핵심 지표

•

100% → 정상

•

20% 이하 → 성능 저하

•

0% → EBS 성능 3MB/s로 제한(= 작동 정지와 거의 동일)

그래프에서 BurstBalance가 빠르게 0으로 떨어졌음.

결론

•

gp2의 구조적 한계로 인한 성능 붕괴

•

모든 I/O 요청이 대기열에서 멈춤

•

결국 EC2 전체가 hang

6. 결론 (Root Cause 정리)

EC2 장애가 아니라 EBS(gp2)의 I/O 버스트 고갈이 원인

•

Docker build 시 I/O 사용량 폭증

•

gp2의 IOPS 한계 + BurstCredit 고갈

•

EBS가 119초 동안 응답 못 해 OS가 block 상태로 멈춤

•

Jenkins + SSH + Docker 모두 응답 불가

•

EC2는 살아있지만 실제로 동작하지 않는 hang 상태

→ 스토리지 병목(IO Stall)로 인한 시스템 전체 정지

7. 개선 방안 & 재발 방지 대책

이번 장애는 Jenkins CI 빌드 과정에서 EBS(gp2)가 순간적인 I/O 부하를 감당하지 못하면서 시스템 전체가 멈춘 것이 원인이었다. 동일 상황이 다시 발생하지 않도록 아래와 같이 조치한다.

7.1 EBS 타입을 반드시 gp3로 변경 (필수 조치)

장애의 직접 원인이 gp2의 BurstCredit 고갈이었기 때문에, Jenkins EC2가 사용하는 모든 EBS 볼륨은 gp3로 전환한다.

gp3는 IOPS와 처리량을 크레딧과 관계없이 지속적으로 보장하기 때문에 Docker build처럼 단시간에 I/O가 몰리는 작업에서도 안정적으로 동작한다.

gp3 장점

•

IOPS/Throughput을 크레딧 없이 지속적으로 제공

•

성능 저하 없이 도커 빌드 workload 처리 가능

•

gp2 대비 비용이 동일하거나 조금 더 저렴

7.2 Jenkins가 사용하는 EBS 사양을 현실적으로 조정

현재 CI 파이프라인에서 Docker 빌드 과정에서 레이어가 반복 생성되고 삭제되기 때문에 디스크 I/O뿐만 아니라 디스크 사용량 자체도 변동 폭이 크다.

따라서 Jenkins가 운영되는 EC2에서는 이번 장애에서 실제로 발생한 I/O 패턴을 기준으로 EBS를 구성하기로 했다:

•

gp3

•

IOPS 3,000

•

Throughput 125MB/s

•

디스크 용량은 40~50GB 수준으로 확보 (Docker 캐시 포함)

7.3 Jenkins의 역할을 Master/Worker로 분리하는 구조로 전환

지금은 Jenkins Master가 빌드 실행부터 Docker build, ECR push까지 모두 처리하고 있다.

Docker build 같은 무거운 작업이 들어오면 Jenkins 전체가 영향을 받기 때문에, 향후 운영 안정성을 위해 역할을 분리할 계획이다.

•

Jenkins는 Master 역할만 담당

•

Jenkins Build Worker를 EC2 또는 ECS Fargate로 분리

•

Docker build는 분리된 빌드 노드(Worker)에서 수행

7.4 CloudWatch 모니터링 항목 재정비 (EBS 중심)

이번 장애에서 가장 큰 지표는 CPU나 네트워크가 아니라 EBS TotalReadTime / QueueLength였다.

따라서 Jenkins 인스턴스의 모니터링 포커스를 아래와 같이 조정한다:

•

VolumeTotalReadTime ≥ 50ms → 알람

•

VolumeQueueLength ≥ 1 → 알람

•

BurstBalance ≤ 30% (gp2만 해당)

•

DiskOps 급증

•

ReadBytes/WriteBytes 비정상 증가

기존에는 CPU/네트워크 위주로 모니터링했지만, 이제는 스토리지 병목을 핵심 항목으로 삼아 감시한다.

7.5 Docker build 자체를 가볍게 만들기 위한 조치

Docker 빌드 과정에서 레이어가 계속 쌓이고 삭제되면서 I/O 부하가 집중됨을 확인했다.

이를 완화하기 위해 Jenkins 빌드 과정에 다음을 적용한다:

•

빌드 캐시 및 임시 파일 정리

•

Dockerfile 레이어 수 최소화

•

multi-stage build 적용

•

base image 변경이 없으면 캐시 활용