이우석 | Portfolio

갤러리 보기

Project 1: COME2US

Role: Infra & DevOps — 아키텍처 설계 주도 | 1•2차 인프라 단독 구축, 3차 설계 주도•구축 | CI/CD 구축•운영 주도 | Istio 도입 주도 Period: 2025.10 – 2025.12 Key Tech: AWS EKS, Istio, Terraform, Jenkins, ArgoCD Links: [GitHub], [아키텍처 설계], [RCA Report]

프로젝트 소개: 트래픽 증가 상황을 가정한 MSA 기반 전자상거래 플랫폼으로, 운영 복잡도와 변경 비용을 낮추기 위해 아키텍처를 3단계에 걸쳐 고도화했습니다. 각 단계는 이전 구조의 한계를 경험한 뒤 다음 전환의 근거로 삼는 방식으로 진행되었습니다.

1. 아키텍처 고도화: 각 단계의 한계를 다음 전환의 근거로

“단순히 기술을 교체한 것이 아니라, 각 구조가 만들어낸 운영 문제를 경험하고 그 근거로 다음 단계를 결정했습니다.”

[이미지 1] COME2US 아키텍처 — Event-Driven MSA 아키텍처 (AWS EKS, Kafka, Istio)

Phase 1 — Monolith

•

단일 EC2에 애플리케이션을 도커 컨테이너로 배포하는 구조로 MVP를 빠르게 배포

•

한계: 트래픽 증가 시 수직 확장(Scale-up)에 의존하며, 서비스 일부 장애가 전체 다운으로 확산되는 구조적 취약점 확인

→ 서비스 독립성과 수평 확장을 위해 MSA + ECS Fargate로 전환 결정

Phase 2 — ECS MSA

•

서비스를 독립 컨테이너로 분리하여 개별 확장과 장애 격리에 성공

•

한계: 

◦

ECS Fargate는 task 내부 IP와 외부 노출 IP가 달라 Eureka 서비스 디스커버리가 정상 동작하지 않는 구조적 문제 발생 (환경변수로 hostname을 직접 주입하는 방식으로 임시 해결)

◦

서비스가 늘어날수록 서비스마다 hostname을 별도 관리해야 하는 운영 확장성/관리성 한계 인식

→ Spring Cloud 컴포넌트 의존 구조의 한계를 벗어나기 위해 Kubernetes 네이티브 환경으로 전환 결정

Phase 3 — EKS Cloud-Native

•

Kubernetes 선언형 리소스로 배포•정책을 표준화하고, Istio Service Mesh로 공통 정책을 플랫폼 계층으로 이관

•

인증/인가•라우팅 정책 변경이 서비스 재배포 없이 Manifest PR → ArgoCD Sync 단위로 처리

→ Spring Cloud 컴포넌트 완전 제거, 정책 변경 리드타임 단축

2. Service Mesh 도입: Spring Cloud 종속 제거와 운영 리스크 해소

“Istio를 단순한 통신 프록시가 아닌 정책 제어 평면(Control Plane)으로 사용해, 인증•인가•라우팅 정책을 Git 기반 선언형 리소스(CRD)로 전환했습니다.”

배경

ECS 환경에서 발생한 Eureka IP 불일치 문제를 계기로 Spring Cloud 컴포넌트 제거를 결정했습니다. 라우팅 대체제로 Kubernetes Ingress가 자연스러운 선택지로 떠올랐고, 동시에 ArgoCD 도입과 함께 Canary 배포를 목표로 설정했습니다. Canary 배포와 Spring Cloud Gateway가 수행하던 인증•인가•필터링을 플랫폼 레이어에서 통합 처리할 수 있는 방법으로 Istio를 확인하였습니다. 금전 거래가 포함된 E-Commerce 서비스 특성 상 서비스 간 통신 암호화가 보안적으로 유의미하다고 판단하여 mTLS 적용을 통한 서비스 간 통신 보안 강화를 추가 목표로 설정했습니다.

구현

•

AuthN/AuthZ Offloading: Ingress에서 RequestAuthentication(JWKS) + AuthorizationPolicy로 JWT 검증/권한을 처리해 서비스 코드의 인증 의존을 제거

•

Traffic Management: Gateway/VirtualService로 라우팅/보안 정책을 선언적으로 관리해, 정책 변경을 서비스 배포가 아닌 “Manifest PR → ArgoCD Sync” 단위로 전환

•

Observability 연동: Istio 도입으로 인한 운영 복잡도 증가를 인지하고, OTel 트레이싱 연동 설정을 통해 Mesh 내 호출 경로 가시성 확보

[이미지 2] Istio 서비스 흐름

[이미지 3] Istio JWT 인증 흐름

Trade-off

Istio 도입은 운영 복잡도/학습비용의 증가를 수반합니다. 오버엔지니어링이 될 수 있지만, 서비스 확장 단계에서 정책 변경 비용과 관측 공백이 운영 리스크로 커진 시점에 도입이 합리적이라고 판단했습니다.

결과

Spring Cloud 컴포넌트를 제거함으로써 서비스 디스커버리 문제를 Kubernetes 네이티브로 해소하며, 정책 변경을 재배포 없이 선언적으로 처리 가능한 구조를 확립했습니다. 또한 서비스 간 mTLS를 적용하여 신뢰성을 높였습니다.

3. CI/CD 고도화: 파편화 → 표준화 → 역할 분리

“’더 좋은 도구’를 쫓은 것이 아닌, 각 시점의 운영 문제를 근거로 파이프라인 전략을 전환했습니다.”

Phase 1 — GitHub Actions

•

단일 서비스 구조에서 GitHub Actions로 간단한 CI 구성

Phase 2 — Jenkins 도입

•

문제: MSA로 전환하며 서비스가 늘어나자 각 서비스마다 별도 파이프라인이 생겨 중복 코드와 관리 비용 급증

•

구현: 

◦

Jenkins Shared Library로 공통 CI(빌드/테스트, 이미지 빌드•푸시, 알림) 표준화

◦

Gradle 빌드 캐시•Docker BuildKit 레이어 캐시 적용으로 반복 빌드 효율 개선

◦

Terraform 연계 Blue/Green 배포 파이프라인 구현 (CI → Warm-up 서비스 생성 → Health Check → ALB Target Group 전환 → 이전 환경 정리)

[이미지 4] Docker Layer Cache 적용 전/후: 1분 3초 → 3.2초 (95% 단축)

•

결과: 서비스별 파이프라인 중복 제거 및 공통 CI 표준화

Phase 3 — GitHub Actions + ArgoCD

•

문제: Jenkins 자체가 별도 인프라로 존재하며 유지•관리 부담이 새로운 운영 비용으로 부각됨

•

구현:

◦

CI — GitHub Actions로 단순화하여 별도 서버 운영 부담 해소

◦

CD — ArgoCD + Helm Chart 기반 GitOps로 분리하여 선언적 배포 재현성 확보

•

결과: CI는 빌드 및 검증, CD는 배포 및 수렴의 역할로 분리, Jenkins 운영 부담 해소

4. 장애 대응: Jenkins 노드 Hang 원인 규명과 재발 방지

"단순 서버 증설이 아닌, CloudWatch 지표로 병목을 증명하고 구조적으로 재발을 막았습니다." (Phase2: Jenkins 기반 CI 장애 — Phase3: GitOps 전환으로 대체)

•

문제: 특정 서비스의 Docker 이미지 빌드 구간에서 Jenkins UI가 504 Gateway Timeout을 반환하고, 이후 SSH 접속 불가(노드 Hang/시스템 정지) 상태로 전환되어 CI 파이프라인이 중단됨. CPU/Memory 사용량은 정상 범위였기 때문에 단순 리소스 부족을 볼 수 없었음

•

원인 분석 (RCA): 

◦

CloudWatch 분석 결과, EBS BurstBalance가 0%로 떨어지고 VolumeTotalReadTime 최대 119초, VolumeQueueLength가 급증하는 패턴 발견

◦

단일 Root EBS(gp2)에서 OS와 Docker I/O가 경합

→ gp2 볼륨의 IOPS Throttling을 근본 원인으로 규명

•

측정 기준: CloudWatch BurstBalance/VolumeQueueLength/VolumeTotalReadTime (1m period) 기준, 동일 빌드 시나리오에서 변경 전/후 3회 재현하여 비교

[이미지 5] EBS gp2 볼륨의 BurstBalance 고갈

[이미지 6] EBS gp2 볼륨의 QueueLength 급증과 유지

[이미지 7] EBS gp2 볼륨의 TotalReadTime 급증과 유지

•

해결 전략:

Root/Data 볼륨 분리로 빌드 워크로드의 I/O 영향을 OS 레이어와 격리

gp3(Provisioned IOPS 6000)로 마이그레이션함으로써 크레딧 기반 가변 IOPS에서 고정 IOPS 구조로 전환

•

결과: Jenkins 504/노드 Hang 장애 제거, EBS 병목 지표 안정화

[이미지 8] EBS gp3 볼륨 변경 후 QueueLength 개선 (피크 후 안정화)

[이미지 9] EBS gp3 볼륨 변경 후 TotalReadTime 개선 (피크 후 안정화)

5. Packer와 Terraform을 통한 CI 플랫폼 재현 자동화 (비용 제약 환경 운영 리스크 제거)

•

배경: 비용 제약으로 AWS 리소스 Destroy/Recreate가 빈번하여, Jenkins 서버 및 설정의 재구성이 요구되어 설정 누락, 환경 불일치 등의 운영 리스크와 시간 비용 발생

•

구현: 

◦

Docker 사전 구성 Golden AMI를 Packer로 빌드하여 일관된 이미지 확보

◦

Terraform으로 EC2 + EBS(영속 데이터) + ALB 노출 + Jenkins 컨테이너 기동까지 자동화

•

효과: terraform apply만으로 Jenkins를 반복 재구성 가능한 운영 모델로 전환하여, 재구축 리드타임과 작업 중단 비용을 제거

Project 2: CINEBOX

Role: BE, Infra & DevOps Lead — 아키텍처 설계 및 인프라 단독 구축 | CI/CD•모니터링 전담 Period: 2025.02 – 2025.03 Key Tech: AWS EKS, ArgoCD, Prometheus, Loki, Grafana, Terraform Links: [GitHub Repository] | [Report PDF]

프로젝트 소개: 실시간 좌석 점유와 예매가 발생하는 고가용성 요구사항을 가정한 영화 예매 서비스입니다. 모니터링 데이터를 의사결정의 근거로 삼아 확장 시 운영 리스크를 줄이는 방향으로 개선했으며, 운영 환경의 신뢰성과 재현성을 위해 GitOps를 도입했습니다.

[이미지 10] CINEBOX 아키텍처

1. 모니터링 기반 의사결정

관측 체계 구축

•

Grafana/Prometheus로 인프라 리소스와 애플리케이션 상태 통합 모니터링

•

Loki를 통한 흩어진 파드 로그를 중앙 수집하여 Grafana에서 통합 확인 가능한 구조 확보

의사결정

•

모니터링 결과 movie 도메인 GET 요청에 트래픽이 집중됨을 확인

•

DB를 Master/Replica 구조로 분리하여 조회 트래픽을 Replica에서 처리

→ 읽기 트래픽을 Replica로 분산하여 Master 부하 감소

2. GitOps 도입: Dev/Prod 환경 분리와 선언적 배포 재현성 확보

단순히 "배포했다"가 아니라, Dev와 Prod 환경의 설정 충돌을 구조적으로 차단하고 모든 변경을 추적 가능하도록 만들었습니다.

배경

Dev와 Prod 환경을 동시에 운영하면서 환경별 설정을 kubectl로 직접 적용하면 실제 클러스터 상태와 코드 베이스가 달라지는 문제가 생길 수 있는 구조였습니다. 특히 Dev에서 검증한 설정이 Prod에 그대로 반영된다는 보장이 없었고, 배포 이력도 남지 않았습니다. GitOps를 통해 Git을 단일 지점으로 삼아 이 문제를 차단하고자 했습니다.

구현

•

ArgoCD: 클러스터의 현재 상태와 Git에 정의된 상태(Desired State)를 실시간 동기화. 수동 변경을 PR 기반으로 제한해 Drift 발생 가능 지점 최소화

•

Kustomize: Base와 Overlay(Dev/Prod) 구조로 나누어 환경별 리소스 격리 관리, 개발 검증 후 안정 시 프로덕션으로 배포하는 흐름 표준화

•

GitHub Actions → ArgoCD 흐름으로 CI와 CD 역할 분리

결과

환경별 설정 충돌 방지, 선언적 배포 재현성 확보

3. Troubleshooting — CoreDNS Taint 충돌

문제

애플리케이션 Pod가 RDS와 연결에 실패하며 지속적으로 CrashLoopBackOff 상태로 반복 재시작

원인 추적

RDS 설정, Security Group, 환경 변수 확인 → 정상

연결 실패가 IP가 아닌 endpoint 기반인 점에 주목 → DNS 해석 문제 의심

CoreDNS Pod 상태 확인 → Pending → 모든 노드에 Taint가 적용되어 있어 CoreDNS가 어떤 노드에도 스케줄링되지 못한 것이 원인

결론

클러스터 내부 DNS 해석 불가 → RDS endpoint를 IP로 변환하지 못한 연결 실패

해결

CoreDNS Deployment에 tolerations를 추가하여 모든 노드에서 스케줄링 가능하도록 변경 → CoreDNS 정상 스케줄링, 애플리케이션-RDS 연결 정상화