2026. 8. 16. 19:05ㆍPROJECT/Toy Project
[Cloud Ops Lab #2] 요구사항 정의
1. 시작하며
지난 글에서는 Cloud Ops Lab 프로젝트를 시작한 이유와 학습 목표를 정리했다.
이번에는 실제 구현에 들어가기 전에 Cloud Ops Lab에서 어떤 환경을 만들고 어떤 운영 문제를 직접 확인할 것인지 요구사항을 정의해보려고 한다.
이번 프로젝트의 목적은 기능이 많은 Cloud Native 환경을 만드는 것이 아니다.
핵심은 다음과 같은 문제를 직접 확인하는 것이다.
Traffic이 증가하면 현재 Replica는 어디까지 버틸 수 있을까?
Pod 하나가 죽으면 서비스에는 어떤 영향이 발생할까?
Kubernetes가 Pod를 다시 생성하면
서비스도 바로 정상화되는 것일까?
Liveness와 Readiness는
실제 Traffic 처리에서 어떤 차이를 만들까?
CPU와 Memory가 부족하면
Application은 어떻게 변할까?
Replica를 늘리면
Latency와 처리 Capacity가 실제로 좋아질까?
HPA는 언제 Scale Out하고
언제 Scale In할까?
Scale Out이 완료되기 전까지
사용자는 어떤 영향을 받을까?
Rolling Update 중에도
Request를 안정적으로 처리할 수 있을까?
장애가 발생했을 때
어떤 Metric을 보고 원인을 찾을 수 있을까?따라서 처음부터 Service Mesh, KEDA, Argo CD 같은 기능을 모두 넣지 않는다.
먼저 가장 단순한 Kubernetes 환경을 만들고 정상 상태의 Baseline을 측정한다.
그 다음 부하와 Failure Scenario를 직접 만들어 실제 문제가 어떻게 나타나는지 확인한 뒤 필요한 운영 설정을 하나씩 검토한다.
2. 서비스 범위
Cloud Ops Lab은 하나의 Backend Application을 Kubernetes 환경에 배포하고 부하와 장애 상황에서 Application과 Kubernetes의 상태 변화를 관찰하는 운영 실험용 프로젝트다.
기본 구조는 다음과 같다.
Client
↓
Kubernetes Service
↓
Deployment
↓
Pod
↓
Backend Application그리고 Application과 Kubernetes의 상태는 다음 구조로 관찰한다.
Application / Kubernetes
↓
Metric
↓
Prometheus
↓
Grafana운영 실험에서는 크게 다음 네 가지를 함께 본다.
Traffic
Application 상태
Kubernetes 상태
Resource 상태예를 들어 Traffic이 증가하면:
Traffic 증가
↓
CPU 증가
↓
Latency 증가
↓
현재 Replica 한계가 발생할 수 있다.
또 Pod를 강제로 종료하면:
Pod Failure
↓
Ready Pod 감소
↓
남은 Pod로 Traffic 집중
↓
새 Pod 생성
↓
Readiness 통과
↓
정상 Replica 복구과정이 발생할 수 있다.
Cloud Ops Lab에서는 이런 흐름을 단순히 Kubernetes 명령어로 확인하는 것이 아니라:
Error Rate
Latency
CPU
Memory
Ready Pod
Replica
Restart
Recovery Time같은 실제 값과 함께 본다.
초기 실험은 로컬 Kubernetes 환경에서 진행한다.
동일한 운영 흐름을 반복해서 확인할 수 있는 상태를 만든 뒤 AWS 환경으로 확장한다.
이번 프로젝트에서 복잡한 실제 비즈니스 기능을 구현하는 것은 핵심 범위가 아니다.
운영 실험에 필요한 최소한의 Backend Application이면 충분하다.
3. 주요 구성 요소
Cloud Ops Lab은 최종적으로 다음 구성 요소를 가진다.
3.1 Backend Application
Kubernetes에서 운영할 대상 Application이다.
복잡한 Domain을 구현하는 것이 목적은 아니다.
운영 실험에 필요한 최소한의 Request를 처리한다.
예:
GET /api/v1/workApplication에서는 최소한 다음 상태를 확인할 수 있어야 한다.
Request 처리
Latency
Error
Health
Application Metric부하 실험에서 CPU 사용량 차이가 거의 발생하지 않는다면 실험을 위한 처리량을 만들 수 있는 Endpoint를 별도로 둘 수 있다.
구체적인 Application 기능은 DESIGN 단계에서 결정한다.
3.2 Container Image
Backend Application은 Container Image로 실행한다.
Application
↓
Container Image
↓
Container
↓
Pod같은 Application Image를 로컬 Kubernetes와 이후 AWS 환경에서도 사용할 수 있도록 한다.
이번 프로젝트에서는 Container 자체를 깊게 학습하는 것이 아니라 Application이 Kubernetes에서 관리되는 최소 실행 단위로 연결되는 과정을 확인하는 것이 목적이다.
3.3 Deployment
Application Pod를 관리하는 Kubernetes Resource다.
Deployment
↓
ReplicaSet
↓
PodDeployment를 이용해 다음 동작을 확인한다.
Replica 유지
Pod 재생성
Version 변경
Rolling UpdatePod를 직접 만들어 장기간 관리하는 구조는 사용하지 않는다.
3.4 Service
Client가 개별 Pod 주소를 직접 알지 않고 Application에 접근할 수 있도록 한다.
Client
↓
Service
↓
Pod A
Pod B
Pod CPod가 종료되고 새로운 Pod가 생성되더라도 Client는 동일한 Service Endpoint를 이용한다.
이를 통해 Pod의 생명주기와 서비스 접근 경로를 분리한다.
3.5 Health Check
Application의 상태를 Kubernetes가 확인할 수 있어야 한다.
이번 프로젝트에서는 최소한 다음 두 상태의 차이를 직접 확인한다.
Application Process가 살아 있는가?
Traffic을 받을 준비가 되어 있는가?즉:
Liveness
Readiness를 구분한다.
단순히 Probe 설정을 추가하는 것이 아니라 실제 실패 상태를 만들어 Kubernetes가 어떻게 동작하는지 확인한다.
3.6 Resource 설정
Pod에는 CPU와 Memory Resource를 설정할 수 있어야 한다.
CPU Request
CPU Limit
Memory Request
Memory Limit초기부터 최적값을 정하지 않는다.
먼저 Baseline Resource 사용량을 확인한 뒤 값을 변경하면서 Application Metric이 실제로 어떻게 달라지는지 비교한다.
3.7 Prometheus
Application과 Kubernetes의 Metric을 수집한다.
예:
Request Rate
Error Rate
Request Latency
CPU Usage
Memory Usage
Pod 상태
Replica 상태Prometheus 자체를 복잡하게 운영하는 것이 목적은 아니다.
각 Experiment에서 무슨 일이 발생했는지를 설명할 수 있는 Metric을 수집하는 것이 목적이다.
3.8 Grafana
Prometheus가 수집한 Metric을 시간 흐름으로 확인한다.
예를 들어 HPA 실험에서는:
Traffic 증가
↓
CPU 증가
↓
Latency 증가
↓
Replica 증가
↓
Latency 변화가 실제로 연결되는지 확인한다.
Dashboard의 디자인 자체는 평가 대상이 아니다.
3.9 Load Generator
운영 상태를 비교하려면 같은 종류의 Traffic을 반복해서 만들 수 있어야 한다.
예:
Constant Load
Increasing Load
Spike Load구체적인 Load Test Tool은 DESIGN에서 결정한다.
중요한 것은 특정 Tool 사용 여부가 아니라 같은 부하 조건을 반복해서 재현할 수 있는가이다.
3.10 Experiment Scenario
Cloud Ops Lab에서 가장 중요한 구성 요소 중 하나다.
각 운영 실험은 가능한 한 같은 조건으로 반복할 수 있어야 한다.
예:
Scenario ID
Environment
Application Version
Replica
Resource Setting
Load Condition
Failure Condition
Observation Time
Observed Metrics
Expected
ActualAI 프로젝트에서 Evaluation Dataset을 Baseline부터 보호했던 것처럼 이번 프로젝트에서는 Experiment Scenario 자체를 Harness의 일부로 본다.
3.11 AWS 환경
로컬 Kubernetes에서 기본적인 실험이 가능한 상태가 된 이후 AWS 환경으로 확장한다.
목적은 AWS 서비스를 많이 사용하는 것이 아니다.
다음 흐름을 실제 Cloud 환경에서도 확인하는 것이다.
Client
↓
Cloud Infrastructure
↓
Kubernetes
↓
Application구체적으로 어떤 AWS Service를 사용할지는 현재 요구사항에서 미리 고정하지 않는다.
학습 목표, 비용, 운영 복잡도를 비교한 뒤 DESIGN 단계에서 결정한다.
4. 운영 Experiment 구조
이번 프로젝트에서는 운영 문제를 단순히 눈으로 확인하고 끝내지 않는다.
각 Experiment는 가능한 한 다음 구조로 진행한다.
정상 Baseline
↓
Load 또는 Failure 주입
↓
Metric 변화 확인
↓
Application 영향 확인
↓
Kubernetes 동작 확인
↓
Recovery
↓
결과 기록예를 들어 Pod Failure Scenario를 만든다고 가정해보자.
Initial
Replica = 3
Ready Pod = 3
↓
Constant Load
↓
Pod 1개 강제 종료
↓
Ready Pod = 2
↓
새 Pod 생성
↓
Readiness PASS
↓
Ready Pod = 3이때 단순히:
Pod가 다시 3개가 됐다.만 기록하지 않는다.
같은 시간에 다음 값도 확인한다.
Request Error
p95 / p99
CPU
Ready Pod
Restart
Recovery Time이를 통해:
Infrastructure 복구와:
사용자 관점의 서비스 복구가 같은지 확인한다.
5. 기본 Kubernetes Resource 구성
프로젝트의 초기 Kubernetes 구성은 가능한 한 단순하게 시작한다.
예:
k8s/
├── deployment.yaml
├── service.yaml
└── ...초기 Deployment는 하나의 Application을 실행한다.
개념적으로는 다음 정도의 정보가 필요하다.
Application Image
Replica
Container Port
Resource
Health Check처음부터 복잡한 운영 설정을 모두 넣지는 않는다.
예를 들어 HPA 실험 전에는 고정 Replica를 사용한다.
Replica = 고정Pod Failure와 Health Check를 확인하기 전에는 Failure를 숨기는 복잡한 복구 설정도 넣지 않는다.
중요한 것은:
현재 Phase에서 확인하려는 문제를 가리지 않는 가장 단순한 환경
을 유지하는 것이다.
6. 기능 요구사항
FR-01. Backend Application 실행
Backend Application은 로컬 환경에서 정상적으로 실행할 수 있어야 한다.
최소한 하나의 Request를 처리한다.
Client
↓
Backend
↓
Response이번 프로젝트의 핵심은 비즈니스 기능이 아니므로 복잡한 Domain은 필요하지 않다.
FR-02. Container Image 생성
Application을 Container Image로 Build하고 실행할 수 있어야 한다.
Application
↓
Image Build
↓
ContainerKubernetes에 올리기 전에 Container 단독 상태에서도 정상 Request가 처리되는지 확인한다.
FR-03. Kubernetes Deployment
Application Image를 Kubernetes Deployment로 실행할 수 있어야 한다.
초기에는 고정된 Replica를 사용한다.
Deployment
↓
Pod
↓
Application처음부터 HPA를 적용하지 않는다.
먼저 고정 Replica 상태의 Baseline을 만든다.
FR-04. Service 접근
Kubernetes Service를 통해 Application에 Request를 전달할 수 있어야 한다.
Client
↓
Service
↓
PodPod가 새로 생성되어 주소가 변경되더라도 Client가 개별 Pod 주소를 알아야 하는 구조로 만들지 않는다.
FR-05. Replica 변경
Deployment의 Replica 수를 변경할 수 있어야 한다.
예:
Replica 1
vs
Replica 2
vs
Replica 3Replica 변경 이후 실제 Ready Pod 수와 Application 상태를 확인할 수 있어야 한다.
FR-06. Desired State 확인
Pod 하나를 강제로 종료했을 때 Kubernetes가 설정된 Replica 수를 다시 유지하는지 확인할 수 있어야 한다.
Replica 3
↓
Pod 1개 종료
↓
Ready Pod 2
↓
새 Pod 생성
↓
Ready Pod 3단, Pod가 다시 생성됐다는 사실만으로 장애 대응에 성공했다고 판단하지 않는다.
같은 시간의 Request 상태도 확인한다.
FR-07. Health 상태 제공
Application은 Kubernetes가 상태를 판단할 수 있는 Health 정보를 제공해야 한다.
최소한 다음 두 상태를 구분한다.
Liveness
Readiness구체적인 Endpoint와 구현 방식은 DESIGN에서 결정한다.
FR-08. Readiness Failure
Application Process는 살아 있지만 Traffic을 받으면 안 되는 상태를 재현할 수 있어야 한다.
예:
Application 실행 중
하지만
Readiness = FAIL이 상태에서 다음을 확인한다.
Ready Pod 변화
Service Routing
Request Error
LatencyFR-09. Liveness Failure
Application이 정상적인 상태로 회복되기 어려운 상황을 재현하고 Kubernetes의 동작을 확인할 수 있어야 한다.
예:
Liveness = FAIL
↓
Container 상태 변화
↓
Restart최소한 다음 정보를 확인한다.
Restart 여부
Restart Count
Ready 상태
서비스 영향
복구 시간FR-10. CPU / Memory Resource 설정
Pod에 CPU와 Memory Resource를 설정할 수 있어야 한다.
CPU Request
CPU Limit
Memory Request
Memory Limit처음부터 최적값을 넣지 않는다.
현재 Application의 실제 Resource 사용량을 먼저 측정한다.
FR-11. Resource 제약 실험
Resource 설정을 변경했을 때 Application에 어떤 영향이 발생하는지 비교할 수 있어야 한다.
예:
CPU Limit 감소
↓
CPU 제약
↓
Latency 변화또는:
Memory Limit 감소
↓
Memory 부족
↓
Container 상태 변화Resource 값을 변경했다는 사실 자체를 Experiment 결과로 보지 않는다.
실제 Application Metric과 함께 확인한다.
FR-12. Application Metric 수집
Application Request에 대해 최소한 다음 값을 확인할 수 있어야 한다.
Request Rate
Error Rate
Latency가능하면 다음 형태로 집계한다.
p50
p95
p99이전 성능 프로젝트와 마찬가지로 평균값 하나만으로 상태를 설명하지 않는다.
FR-13. Kubernetes Metric 확인
Kubernetes 환경에서는 최소한 다음 상태를 확인할 수 있어야 한다.
CPU Usage
Memory Usage
Ready Pod
Replica
Pod RestartHPA 단계에서는 Scaling과 관련된 상태도 확인할 수 있어야 한다.
FR-14. Prometheus Metric 수집
Prometheus가 Experiment에 필요한 Application 및 Kubernetes Metric을 수집할 수 있어야 한다.
모든 Metric을 처음부터 수집할 필요는 없다.
현재 Experiment에서 확인하려는 문제와 관계있는 Metric부터 추가한다.
FR-15. Grafana 시각화
Grafana에서 Metric의 시간에 따른 변화를 확인할 수 있어야 한다.
최소한 다음 흐름을 비교할 수 있어야 한다.
Traffic
Latency / Error
CPU / Memory
Replica / Ready PodGrafana Dashboard를 만들었다는 사실 자체를 성공 기준으로 두지 않는다.
FR-16. 반복 가능한 Load Test
같은 형태의 부하를 반복해서 발생시킬 수 있어야 한다.
예:
Baseline Load
Increasing Load
Spike LoadBaseline 단계에서는 가장 단순한 Load부터 시작한다.
Spike는 고정 부하에서 현재 Capacity를 확인한 이후에 실험한다.
FR-17. 고정 Replica Capacity 확인
HPA를 적용하기 전에 고정 Replica 상태에서 Traffic을 증가시켜 현재 구조의 한계를 확인할 수 있어야 한다.
예:
Traffic 증가
↓
CPU 증가
↓
Latency 증가
↓
Error 발생실제로 이런 문제가 발생하는지 확인한 뒤 다음 단계로 간다.
FR-18. Replica 수 비교
동일한 Load 조건에서 Replica 수를 변경하고 결과를 비교할 수 있어야 한다.
Replica 1
vs
Replica 2
vs
Replica 3비교 항목은 최소한 다음을 포함한다.
Request Rate
Latency
Error
CPU
MemoryReplica를 늘렸다고 무조건 성능이 좋아졌다고 판단하지 않는다.
FR-19. HPA 실험
고정 Replica의 한계를 확인한 이후 HPA를 이용해 자동 Scaling을 실험할 수 있어야 한다.
Traffic 증가
↓
Metric 증가
↓
HPA
↓
Desired Replica 증가
↓
새 Pod 생성HPA는 이번 프로젝트의 학습 대상이기 때문에 직접 사용해본다.
하지만:
HPA 적용
=
운영 개선이라고 판단하지 않는다.
실제 서비스 Metric을 함께 비교한다.
FR-20. Scale Out 관측
HPA가 Scale Out하는 과정에서 다음 시점을 추적할 수 있어야 한다.
Traffic 증가
Metric 증가
Scaling 판단
새 Pod 생성
Readiness PASS
서비스 상태 변화가능하면 다음 값을 기록한다.
Scale-out Time
p95 / p99 변화
Error Rate 변화FR-21. Scale In 관측
Traffic이 감소한 이후 Replica가 줄어드는 과정도 확인할 수 있어야 한다.
Traffic 감소
↓
Resource 감소
↓
Replica 감소이때 다음도 확인한다.
너무 빠르게 Scale In하지 않는가?
Traffic이 다시 증가했을 때 문제가 생기지 않는가?
Replica 수가 반복해서 흔들리지는 않는가?FR-22. Pod Failure Experiment
Traffic이 존재하는 상태에서 Pod를 강제로 종료할 수 있어야 한다.
정상 Traffic
↓
Pod Kill
↓
Ready Pod 감소
↓
Recovery다음 결과를 확인한다.
Request Error
Latency
Ready Pod
남은 Pod Resource
새 Pod 생성
Recovery TimeFR-23. Recovery Time 확인
Failure 발생부터 서비스가 정상 상태로 돌아오기까지의 흐름을 확인할 수 있어야 한다.
가능하면 다음 시점을 구분한다.
Failure 발생
Kubernetes 감지
새 Pod 생성
Application Startup
Readiness PASS
서비스 정상화단순히 새 Pod가 만들어진 시간과 서비스가 정상화된 시간을 같은 값으로 보지 않는다.
FR-24. Rolling Update
Application Version을 변경하여 Kubernetes Rolling Update를 실행할 수 있어야 한다.
Version A
↓
A + B
↓
Version B배포 중 다음 값을 확인한다.
Ready Pod
Request Error
Latency
Version 전환 상태kubectl apply가 성공했다는 사실만으로 무중단 배포에 성공했다고 판단하지 않는다.
FR-25. 배포 실패 상태 확인
새 Version이 정상적으로 Ready 상태가 되지 않는 상황을 재현할 수 있다면 Kubernetes가 기존 Replica와 신규 Replica를 어떻게 다루는지 확인한다.
처음부터 Argo CD나 별도의 Deployment Platform을 사용하지 않는다.
먼저 Kubernetes 기본 Deployment의 동작을 이해한다.
FR-26. Experiment 결과 기록
각 Experiment의 조건과 결과를 Repository에 남길 수 있어야 한다.
예:
docs/experiments/
001-baseline.md
002-replica-capacity.md
003-resource-limit.md
004-pod-failure.mdExperiment 이름에는 해결 기술보다 확인하려는 문제를 우선한다.
예를 들어:
hpa-tuning.md보다:
scale-out-delay.md처럼 작성한다.
실험을 시작하기 전에 정답을 파일 이름에 넣지 않기 위해서다.
FR-27. AWS 환경 실행
로컬 Kubernetes에서 핵심 운영 실험이 가능한 상태가 된 이후 Application을 AWS 환경에서도 실행할 수 있어야 한다.
Client
↓
AWS
↓
Kubernetes
↓
Application어떤 AWS Service를 사용할지는 요구사항에서 미리 확정하지 않는다.
AWS 환경에서도 Kubernetes 운영 문제를 관찰할 수 있는 것이 최종 요구사항이다.
FR-28. AWS 환경 관측
AWS 환경에서도 최소한 다음 상태를 확인할 수 있어야 한다.
Application 상태
Pod 상태
CPU / Memory
Request Latency
Error로컬 Kubernetes와 완전히 같은 수치가 나오는 것이 목적은 아니다.
같은 운영 개념을 Cloud 환경에서도 연결해서 이해하는 것이 목적이다.
7. 초기 Kubernetes 처리 흐름
Baseline은 최대한 단순하게 구성한다.
Client
↓
Kubernetes Service
↓
Deployment
↓
Pod
↓
Backend Application
↓
ResponseMetric 흐름은 다음과 같다.
Application / Kubernetes
↓
Metric
↓
Prometheus
↓
Grafana초기에는 다음 구조를 사용하지 않는다.
HPA
KEDA
Service Mesh
Argo CD
Chaos Engineering Platform
분산 Tracing
복잡한 Logging Stack
Multi ClusterHPA는 이후 프로젝트에서 직접 실험할 학습 대상이지만 Baseline부터 넣지는 않는다.
먼저 고정 Replica 환경의 현재 상태를 측정한다.
8. Baseline에서 확인할 상태
초기 Baseline에서는 정상 상태의 Kubernetes Application을 먼저 확인한다.
예:
Application Version
v1
Replica
고정
Failure
없음
Load
Baseline다음 상태를 확인할 수 있어야 한다.
Application 정상 실행
Container 정상 실행
Pod Ready
Service 접근 가능
Request 성공
Application Metric 수집
CPU / Memory 확인
동일 Load 반복 실행이 단계에서는 다음 상태를 아직 해결하지 않는다.
Traffic 증가에 따른 Saturation
Pod Failure
Readiness Failure
Liveness Failure
Auto Scaling
Rolling Update 문제정상 상태의 기준점이 있어야 이후 Failure와 변경의 영향을 비교할 수 있기 때문이다.
9. 비기능 요구사항
NFR-01. 관측 가능성
최종 HTTP Response만 확인하지 않는다.
필요하면 다음 흐름을 추적할 수 있어야 한다.
Traffic
↓
Application Metric
↓
CPU / Memory
↓
Pod 상태
↓
Replica
↓
Kubernetes 동작
↓
서비스 결과이를 통해 단순히:
느려졌다.가 아니라 왜 느려졌는지를 분석할 수 있어야 한다.
NFR-02. 재현 가능한 Experiment
같은 Scenario를 가능한 한 같은 조건으로 다시 실행할 수 있어야 한다.
다음 조건을 기록한다.
Application Version
Environment
Replica
Resource Request / Limit
Load Condition
Failure Condition
Observation Time
Metric조건이 다르면 Before / After 비교에서 명확하게 표시한다.
NFR-03. 동일 조건 비교
운영 설정을 변경할 때 가능한 한 하나의 주요 변수만 변경한다.
예:
Replica 1
vs
Replica 3를 비교하면서 동시에 Application Version과 Resource Limit까지 바꾸지 않는다.
무엇 때문에 결과가 달라졌는지 설명할 수 있어야 한다.
NFR-04. Application과 Infrastructure 분리
Latency가 증가했다고 바로 Kubernetes 문제라고 판단하지 않는다.
최소한 다음 계층을 구분한다.
Application
Container Resource
Kubernetes
Load예를 들어 Replica를 늘렸는데도 Latency가 그대로라면 Application 내부나 외부 Dependency가 병목일 수 있다.
Cloud Ops 전체를 하나의 Black Box로 보지 않는다.
NFR-05. 성능 변경의 측정
다음과 같이 기술 적용 자체를 개선으로 판단하지 않는다.
Replica 증가
→ 개선또는:
HPA 적용
→ 개선이 아니라:
Baseline
↓
변경
↓
동일 Load
↓
Metric 비교결과로 판단한다.
Latency가 그대로이거나 더 나빠질 수도 있으며 그 결과도 그대로 기록한다.
NFR-06. 장애 대응의 측정
다음과 같이 판단하지 않는다.
Pod가 다시 생성됐다.
→ 장애 대응 성공최소한 다음 값을 같이 본다.
Error Rate
Latency
Ready Pod
Restart
Recovery TimeKubernetes Resource가 복구된 것과 사용자가 정상적으로 Request를 처리할 수 있게 된 것은 구분한다.
NFR-07. 시간 흐름 관측
운영 문제는 최종 값 하나만으로 판단하기 어려울 수 있다.
예를 들어 HPA에서는:
Traffic 증가
↓
CPU 증가
↓
Latency 증가
↓
Scale Out
↓
새 Pod Ready
↓
Latency 변화같은 시간 관계가 중요하다.
따라서 필요한 Experiment에서는 Metric을 시간 흐름으로 확인할 수 있어야 한다.
NFR-08. Resource 사용량 관측
성능 변화와 함께 Resource 사용량도 확인한다.
CPU
Memory
Replica예를 들어 p99가 조금 좋아졌지만 Replica가 세 배 늘었다면 그 결과 역시 함께 기록한다.
NFR-09. 비용 인식
AWS 환경에서는 Resource 사용량이 실제 Cloud 비용과 연결된다.
이번 프로젝트에서 완전한 FinOps Platform을 구현하지는 않는다.
다만:
Replica 증가
CPU / Memory 증가
Cloud Resource 증가가 비용과 연결될 수 있다는 점은 결과 분석에 포함한다.
NFR-10. Failure 결과 보존
예상과 다른 실험 결과를 삭제하거나 숨기지 않는다.
예:
Replica를 늘렸지만 Latency 개선 없음
HPA가 Spike Traffic을 따라가지 못함
Probe 적용 후 Restart 증가
Resource Limit을 낮춘 뒤 Error 증가이런 결과도 정상적인 Experiment 결과로 남긴다.
NFR-11. 반복 가능한 Failure
실제 장애가 우연히 발생하기를 기다리지 않는다.
가능하면 다음과 같은 Failure는 다시 만들 수 있어야 한다.
Pod Kill
Readiness Failure
Liveness Failure
Resource Constraint동일한 Failure를 재현할 수 있어야 변경 전후 비교가 가능하다.
NFR-12. Secret 보호
AWS Credential이나 기타 Secret은 Repository에 직접 저장하지 않는다.
예:
Access Key
Secret Key
Token
Password구체적인 Secret 관리 방식은 실제 환경에 맞게 결정한다.
NFR-13. 현재 Architecture와 문서 동기화
DESIGN.md에는 현재 실제로 존재하는 구조만 기록한다.
예를 들어 HPA를 아직 적용하지 않았다면:
HPA를 현재 Architecture처럼 작성하지 않는다.
ROADMAP과 DESIGN의 역할을 구분한다.
NFR-14. 최소 복잡도
Cloud Native 기술을 많이 사용한 것을 좋은 결과로 판단하지 않는다.
Kubernetes 사용
=
Service Mesh 필요
Prometheus 사용
=
대규모 Observability Stack 필요가 아니다.
현재 문제를 확인하고 해결하는 데 필요한 수준까지만 구조를 확장한다.
10. Experiment Scenario 요구사항
이번 프로젝트에서는 Experiment Scenario를 부가적인 테스트 자료로 취급하지 않는다.
Baseline과 운영 변경을 비교하기 위한 핵심 Harness로 본다.
최소한 다음 종류의 Scenario를 포함한다.
Baseline Load
정상 상태의 기본 부하다.
고정 Replica
Failure 없음
기본 Resource 설정이후 모든 비교의 기준이 된다.
Increasing Load
Traffic을 단계적으로 증가시킨다.
확인:
Request Rate
Latency
Error
CPU
Memory현재 Replica의 Capacity가 어디에서 한계를 보이는지 확인한다.
Replica Comparison
같은 Load에서 Replica 수를 변경한다.
Replica 1
Replica 2
Replica 3처리 Capacity와 Resource 사용량이 실제로 어떻게 달라지는지 확인한다.
Resource Constraint
CPU 또는 Memory 조건을 변경한다.
CPU Limit 변경
Memory Limit 변경Application의 Latency, Error, Container 상태가 어떻게 달라지는지 본다.
Pod Failure
Traffic이 존재하는 상태에서 Pod를 종료한다.
Pod Kill
↓
Ready Pod 감소
↓
새 Pod 생성
↓
Recovery서비스 영향과 Recovery Time을 확인한다.
Readiness Failure
Application은 살아 있지만 Traffic을 받으면 안 되는 상태를 만든다.
Readiness FAILService가 해당 Pod로 Traffic을 보내지 않는지 확인한다.
Liveness Failure
Application이 정상 상태로 회복되기 어려운 상황을 만든다.
Liveness FAIL
↓
RestartRestart와 서비스 영향을 확인한다.
HPA Scale Out
Traffic을 증가시켜 HPA가 Replica를 늘리는 상황을 만든다.
Traffic 증가
↓
Metric 증가
↓
Scale Out다음을 확인한다.
Scale-out Time
Ready Pod
Latency
ErrorHPA Scale In
Traffic을 줄이고 Replica 감소를 관찰한다.
Traffic 감소
↓
Resource 감소
↓
Scale InReplica가 안정적으로 줄어드는지 확인한다.
Spike Load
짧은 시간에 Traffic을 크게 증가시킨다.
확인:
HPA가 대응하기 전 Latency
Error
Scale-out DelayHPA가 존재한다는 사실과 순간 부하를 막을 수 있다는 것은 같은 의미가 아니기 때문이다.
Rolling Update
Load가 존재하는 상태에서 Version을 변경한다.
Version A
↓
A + B
↓
Version B배포 과정의 Error와 Latency를 확인한다.
AWS Validation
로컬에서 확인한 핵심 운영 Scenario 중 일부를 AWS 환경에서 다시 실행한다.
모든 실험을 그대로 반복할 필요는 없다.
프로젝트의 핵심 학습 목표를 확인할 수 있는 Scenario를 선택한다.
11. Baseline 완료 조건
초기 Kubernetes 단계에서는 다음 조건을 만족하면 Baseline 구현이 완료된 것으로 판단한다.
Application
Backend Application을 실행할 수 있다.
기본 Request를 처리할 수 있다.
Health 상태를 확인할 수 있다.
Application Metric을 확인할 수 있다.Container
Container Image를 Build할 수 있다.
Container 단독 실행이 가능하다.Kubernetes
Deployment로 Application을 실행할 수 있다.
Service를 통해 Request를 보낼 수 있다.
고정 Replica가 유지된다.
Pod / Ready 상태를 확인할 수 있다.Monitoring
Prometheus에서 필요한 Metric을 확인할 수 있다.
Grafana에서 시간에 따른 Metric 변화를 볼 수 있다.
CPU / Memory를 확인할 수 있다.
Request Latency / Error를 확인할 수 있다.Load Test
Baseline Load를 반복 실행할 수 있다.
같은 조건에서 Metric을 다시 측정할 수 있다.Experiment
Baseline Scenario가 존재한다.
실행 조건을 기록할 수 있다.
측정 결과를 Repository에 남길 수 있다.README
이번 프로젝트에서는 LLM Router 회고에서 남은 문제를 반영해 Baseline 완료 시점부터 최소한 다음 내용을 README에서 확인할 수 있어야 한다.
프로젝트 목적
Application 실행 방법
Container Build 방법
Kubernetes 실행 방법
Request 방법
Load Test 방법
Prometheus / Grafana 확인 방법
Experiment 실행 / 결과 위치이 단계에서는 Application이 높은 Traffic을 안정적으로 처리할 필요도 없고 장애 대응이 완성되어 있을 필요도 없다.
반복해서 실행하고 측정할 수 있는 Kubernetes Baseline이 존재하는 것이 완료 조건이다.
12. Baseline에서 의도적으로 해결하지 않을 문제
초기 구현에서 다음 문제를 발견하더라도 바로 해결하지 않는다.
Traffic 증가 시 Latency 상승
CPU Saturation
Memory 부족
Replica 부족
Pod Failure 중 Request Error
Pod 복구 지연
Readiness 설정 문제
Liveness 설정 문제
Auto Scaling 부재
Rolling Update 중 Error
Recovery 지연먼저 Experiment 결과에 실제 Failure Case로 남긴다.
그 후 실험 단계에서 문제별로 접근한다.
예를 들어:
Traffic이 늘어날 것 같음
↓
HPA 먼저 적용하지 않는다.
먼저 고정 Replica에서 실제 Capacity 한계를 확인한다.
마찬가지로:
Pod가 죽을 수 있음
↓
복잡한 장애 대응 구조 먼저 추가하지 않는다.
현재 Kubernetes 기본 복구가 서비스에 어떤 영향을 주는지 먼저 확인한다.
13. 이후 실험에서 확인할 문제
Baseline 이후에는 대략 다음 흐름으로 진행한다.
Kubernetes Baseline
↓
Baseline Load 측정
↓
고정 Replica Capacity 확인
↓
Replica 수 비교
↓
Resource Request / Limit 영향 확인
↓
Readiness / Liveness 실험
↓
Pod Failure
↓
Recovery 영향 측정
↓
HPA Scale Out
↓
HPA Scale In
↓
Spike Traffic
↓
Rolling Update
↓
Observability 기반 원인 분석
↓
AWS 환경 확장
↓
최종 비교여기서 중요한 점은:
Phase 도달
=
추가 Cloud Native 기술 반드시 도입이 아니라는 것이다.
HPA는 이번 프로젝트에서 직접 학습하기 위해 사용하는 기술이지만 HPA 이후 더 복잡한 Autoscaling 도구까지 사용할 필요는 없다.
예를 들어 CPU 기반 HPA만으로 현재 Scaling 문제를 충분히 확인할 수 있다면 KEDA를 추가하지 않아도 된다.
Prometheus와 Grafana만으로 현재 장애 원인을 충분히 설명할 수 있다면 처음부터 복잡한 Observability Stack을 추가하지 않아도 된다.
Kubernetes 기본 Rolling Update로 현재 학습 목표를 충분히 확인할 수 있다면 Argo CD를 넣지 않아도 된다.
14. 이번 프로젝트에서 제외할 기능
Cloud Ops Lab의 학습 목적과 직접 관계없는 기능은 구현하지 않는다.
다음 기능은 제외한다.
복잡한 실제 비즈니스 Domain
회원가입
로그인 UI
Frontend UI
결제 기능
Production 수준 Traffic
24시간 실제 서비스 운영
Production SLA
Multi Region
Multi Cluster
전체 Disaster Recovery 설계
실제 조직 수준 IAM
완전한 FinOps Platform또한 처음부터 다음 기술을 사용하지 않는다.
Terraform
Helm
Argo CD
Istio
Service Mesh
KEDA
OpenTelemetry 전체 Stack
ELK / EFK
Chaos Mesh
Multi Cluster Orchestration이 기술들이 필요 없다는 의미는 아니다.
실제 문제가 확인되고 프로젝트의 학습 범위 안에서 필요성이 생긴 경우에만 후보로 검토한다.
15. 운영 기능을 어떻게 성공으로 판단할 것인가
이번 프로젝트에서 가장 피하고 싶은 결과는 다음과 같다.
Kubernetes 배포
↓
HPA 적용
↓
Prometheus 연결
↓
Grafana Dashboard 생성
↓
AWS 배포
↓
Cloud Ops 성공대신 성공 기준을 여러 단계로 나눈다.
Deployment
Application을 반복 가능한 Kubernetes 환경에서 실행할 수 있는가?
Load
현재 Replica의 Capacity와 한계를 실제 Metric으로 설명할 수 있는가?
Resource
CPU / Memory 설정이 Application에 어떤 영향을 주는가?
Health
Liveness와 Readiness가 실제로 다른 동작을 만드는가?
Failure
Pod Failure가 사용자 Request에 어떤 영향을 주는가?
Recovery
Kubernetes Resource 복구와 서비스 정상화 시간을 구분할 수 있는가?
Scaling
HPA가 언제 Scale Out / Scale In하고
그 결과 Latency와 Error가 어떻게 달라지는가?
Deployment Change
Rolling Update 중 서비스 상태는 어떻게 변하는가?
Observability
장애가 발생했을 때
Metric과 Kubernetes 상태를 이용해 원인을 좁힐 수 있는가?
Efficiency
Resource를 더 사용한 만큼
실제 성능이나 안정성 이득이 발생했는가?
Cloud
로컬에서 확인한 운영 개념을
AWS 환경에서도 연결해서 설명할 수 있는가?하나의 숫자로 모든 운영 품질을 설명하려고 하지 않는다.
16. 정리
Cloud Ops Lab의 초기 구조 자체는 단순하다.
Client
↓
Service
↓
Deployment
↓
Pod
↓
Backend Application그리고 현재 상태를:
Prometheus
+
Grafana로 관찰한다.
하지만 실제 학습은 이 구조에 부하와 Failure를 넣는 시점부터 시작된다.
앞으로는 다음 질문에 답해볼 예정이다.
고정 Replica는 어느 정도의 부하에서 한계를 보일까?
Replica를 늘리면 p95 / p99와 처리 Capacity가 실제로 좋아질까?
CPU와 Memory Request / Limit은 Application에 어떤 영향을 줄까?
Pod 하나가 죽었을 때 Request Error는 발생할까?
Kubernetes가 Pod를 복구하는 것과 서비스가 정상화되는 것은 같은 시점일까?
Readiness가 실제 Traffic 보호에 어떤 역할을 할까?
Liveness Failure에서는 어떤 방식으로 Container가 복구될까?
HPA는 Traffic 증가 이후 얼마나 빠르게 Scale Out할까?
Scale Out이 완료되기 전까지 Latency와 Error는 어떻게 변할까?
Spike Traffic에서도 HPA가 충분히 대응할 수 있을까?
Scale In은 안정적으로 동작할까?
Rolling Update 중에도 Request를 정상적으로 처리할 수 있을까?
장애가 발생했을 때 어떤 Metric을 이용해 원인을 찾을 수 있을까?
Resource를 더 사용하는 만큼 실제 성능과 안정성 이득이 발생할까?
로컬 Kubernetes에서 확인한 운영 방식은 AWS 환경에서 어떻게 달라질까?
그리고 이번 프로젝트에서는 이전 LLM Router 회고에서 남은 한 가지를 처음부터 더 명확하게 가져가려고 한다.
Blog Goal
=
REQUIREMENTS
=
ROADMAP프로젝트 중 학습 범위가 달라진다면 조용히 요구사항을 바꾸지 않고 그 변경 자체를 기록한다.
이번 프로젝트에서도 가장 중요한 것은:
Kubernetes가 잘 동작하는 것처럼 보이는 것이 아니라, 실제 Load와 Failure Scenario, Metric을 통해 무엇이 문제였고 어떤 변경 이후 서비스의 Latency·Error·Resource·Recovery가 어떻게 달라졌는지를 설명할 수 있어야 한다.
다음 단계에서는 이 요구사항을 기반으로 Cloud Ops Lab의 개발 Harness와 Phase별 운영 실험 전략을 정리해보려고 한다.
'PROJECT > Toy Project' 카테고리의 다른 글
| [Cloud Ops Lab #4] 학습 목표, 요구사항, Harness 회고 (0) | 2026.08.16 |
|---|---|
| [Cloud Ops Lab #3] 바이브 코딩과 Harness 전략 (1) | 2026.08.16 |
| [Cloud Ops Lab #1] 프로젝트 소개와 학습 목표 (0) | 2026.08.16 |
| [LLM Router #4] 학습 목표, 요구사항, Harness 회고 (0) | 2026.08.16 |
| [LLM Router #3] 바이브 코딩과 Harness 전략 (0) | 2026.08.16 |