Experiment
TravelPlanner EKS
기존 여행 서비스를 EKS MSA로 구성하고, 로컬 자원·HPA 실험과 EC2 ASG 비교를 통해 배포 설정과 확장 한계를 확인한 후속 프로젝트입니다.
이미지 보기예약량과 교체 중첩을 함께 계산해 노드 축소를 보류
로컬 MSA 실험 요약이미지 보기300초 전체 판정창 통과 부하 · 플랫폼 단독 개선 배수로 해석하지 않음
AWS 비교 판정과 측정창구성도 보기비교 당시 설정을 재작성한 구성도 · 현재 상시 운영 상태가 아님
노드·Pod·업무 처리 타임라인Pass and fail
같은 부하에서도 결과는 달랐습니다
2026년 9월 12~13일 시험입니다. 정상 정책과 통제된 최대 구성, 전체 구간과 안정 tail을 나눠 읽습니다. 시험 완료가 모든 조건의 통과를 뜻하지는 않습니다.| 시나리오 | 판정 기준 | 측정 결과 | 판정 |
|---|---|---|---|
| EC2 stress | 정상 정책 · 300초 전체 창 | 18 journeys/s 통과. 19는 안정 tail만 충족. | 통과 |
| EKS stress | 정상 정책 · 300초 전체 창 | 68 journeys/s 통과. | 통과 |
| 상단 부하 | 전체 구간 SLO | EC2 20 / EKS 72 journeys/s 기준 미달. | 기준 미달 |
| 최대 4대 통과 부하 | 별도 통제 실험의 전체 구간 SLO | EC2 10 / EKS 64 journeys/s 통과. | 통과 |
| 최대 4대 상단 부하 | 별도 통제 실험의 전체 구간 SLO | EC2 11 / EKS 68 journeys/s 기준 미달. | 기준 미달 |
| 절대 soak | 16 journeys/s · 1시간 전체 | 양쪽 모두 60개 창 중 59개 통과, 전체는 기준 미달. | 기준 미달 |
| 앱 장애 | 원본 도구 오류와 회복 구분 | 인증 도구 오류로 원래 판정 유지. 계정 수리 후 회복 통과. | 도구 수리 필요 |
| 실패 이미지 배포 | 장애·회복 구간 | 양쪽 통과. EKS는 기존 정상 Pod가 서비스를 유지. | 통과 |
Attribution boundary
팀 결과와 개인 기여
기존 팀의 여행 서비스를 대상으로 진행한 후속 인프라·검증 작업입니다. 아래 구성·실험·분석은 직접 수행한 범위이며, 팀원이 만든 서비스 기능과 최초 GitOps 자동화는 개인 구현 성과에 포함하지 않습니다.EKS Terraform과 MSA 전환
비공개 EKS 접근·데이터 계층·관측 환경을 구성하고, 네 서비스의 배포·자원·HPA 설정과 기존 모놀리스 경로를 분리했습니다.
protove 작성 커밋·PR과 직접 남긴 실험 원본을 구분해 검증자원 가설을 실험으로 검증
로컬 고정 Pod/HPA 구성과 AWS 부하·장애 조건을 직접 비교했습니다. 실패와 측정 불완전도 원본 판정에 남겼습니다.
protove 작성 커밋·PR과 직접 남긴 실험 원본을 구분해 검증GitOps 적용과 연결 고갈 대응
Argo CD의 환경값·자동 동기화를 연결하고 HPA replicas와의 충돌을 피했습니다. 후속 배포에서 드러난 DB 연결 부족은 서비스별 Hikari 설정으로 조정했습니다.
protove 작성 커밋·PR과 직접 남긴 실험 원본을 구분해 검증Situation
상황
EC2에서 동작하던 여행 서비스를 네 서비스로 나누면서, Pod 수와 노드 규격을 근거 없이 정할 수는 없었습니다. 자동 확장이 실제 요청 처리로 이어지는지도 확인해야 했습니다.
Task
과제
로컬에서 자원 후보를 좁힌 뒤 동일한 사용자 흐름으로 EC2 ASG 모놀리스와 EKS MSA의 부하 경계·확장·회복을 비교했습니다.
Action
실행
- 고정 Pod A/C/B와 HPA를 비교하고 JVM 메모리, 기동 시간, 느린 Maps 응답에 따른 DB 연결 대기를 함께 관측했습니다.
- 앱/노드를 t3.large, 시작 정책을 2/2/4로 맞추고 별도 runner에서 baseline·stress·spike·soak와 장애 시험을 수행했습니다.
- Pending부터 Cluster Autoscaler, 노드 등록, Pod Ready와 업무 요청 성공까지 증거를 연결하고, 도구 실패와 SLO 미달을 분리했습니다.
- Argo CD 적용과 HPA 설정 소유권을 정리하고, 9월 14일에는 신규 Pod의 DB 연결 고갈에 맞춰 Hikari 설정을 별도로 보완했습니다.
Result
결과
1/2/2/2를 우선 후보로
로컬 실험을 통해 서비스별 자원 후보를 남겼습니다. 작은 구성도 배포 중 메모리 예산이 부족해 t3.medium 축소는 보류했습니다.
이미지 보기예약량과 교체 중첩을 함께 계산해 노드 축소를 보류
로컬 MSA 실험 요약통과 부하와 실패 경계를 함께 확인
정상 정책 5분 stress에서 EC2 18, EKS 68 journeys/s가 전체 창을 통과했습니다. 장시간 soak와 과부하 실패는 별도 결과로 남겼습니다.
이미지 보기300초 전체 판정창 통과 부하 · 플랫폼 단독 개선 배수로 해석하지 않음
AWS 비교 판정과 측정창노드 확장과 서비스 준비의 차이
EKS 노드는 2→3→4로 늘었지만 새 Pod의 준비는 별개였습니다. 세 번째 노드의 첫 업무 요청까지 3분 32초, 네 번째 노드의 첫 Pod Ready까지 21분 23초가 관측됐습니다.
구성도 보기비교 당시 설정을 재작성한 구성도 · 현재 상시 운영 상태가 아님
노드·Pod·업무 처리 타임라인Evidence story