[Cloud Ops Lab #1] 프로젝트 소개와 학습 목표

[Cloud Ops Lab #1] 프로젝트 소개와 학습 목표

1. 시작하며

Playback Gate에서는 하나의 API에 많은 요청이 들어왔을 때 발생하는 Latency, Connection Pool, Cache, 동시성 문제를 다뤘다.

Live Event Stream에서는 Kafka를 이용해 많은 Event를 비동기로 처리하면서 Consumer Lag, Partition, Idempotency, Retry, Replay 같은 문제를 직접 확인했다.

ContentOps Agent에서는 RAG와 Tool Calling을 이용하면서 Retrieval, Generation, Grounding, Tool Selection을 Evaluation했다.

LLM Router에서는 여러 Model을 비교하면서 Quality, Cost, Latency, Routing Decision을 확인했다.

지금까지 프로젝트에서는 주로 Application 내부에서 발생하는 문제를 다뤘다.

이번에는 조금 다른 영역을 다뤄보려고 한다.

Backend Application을 실제 운영 환경에 올리면 코드가 정상적으로 동작하는 것만으로는 충분하지 않다.

예를 들어 다음과 같은 상황이 발생할 수 있다.

Traffic이 갑자기 증가하면 어떻게 될까?

Pod 하나가 죽으면 서비스는 계속 동작할까?

Application Process는 살아 있지만
Request를 정상 처리하지 못하면 어떻게 될까?

CPU나 Memory가 부족하면 어떤 문제가 발생할까?

Replica를 늘리면 실제 처리량과 Latency가 좋아질까?

HPA는 언제 Pod를 늘리고 언제 줄일까?

배포 중 일부 Pod가 준비되지 않으면
Traffic은 어디로 갈까?

장애가 발생했을 때
어떤 Metric을 보고 원인을 찾아야 할까?

로컬에서 Application을 실행할 때는 잘 보이지 않았던 문제들이다.

하지만 실제 운영 환경에서는:

Application

Container

Kubernetes

Network

Resource

Monitoring

Cloud

가 모두 연결되어 있다.

이번 프로젝트에서는 Backend Application을 Kubernetes 환경에서 실제로 운영하면서 이런 문제를 직접 만들어보고 확인해보려고 한다.

프로젝트 이름은 Cloud Ops Lab으로 정했다.

---

2. Cloud Ops Lab이란?

Cloud Ops Lab은 Backend Application을 Kubernetes 환경에 배포하고 부하와 장애 상황에서 서비스가 어떻게 동작하고 복구되는지를 직접 실험하는 프로젝트다.

기본적인 구조는 다음과 같다.

Client
   ↓
Service
   ↓
Kubernetes
   ↓
Pod
   ↓
Backend Application

그리고 Application과 Kubernetes의 상태를 관찰하기 위해:

Prometheus
+
Grafana

를 사용한다.

최종적으로는 로컬 Kubernetes 환경에서 확인한 실험을 AWS 환경까지 확장해보려고 한다.

이번 프로젝트에서 보고 싶은 것은 단순히:

Pod가 실행됐다.

Deployment가 생성됐다.

Grafana Dashboard가 보인다.

HPA가 설정됐다.

가 아니다.

예를 들어 Pod가 하나 죽었다면:

Pod Failure
     ↓
Replica 감소
     ↓
Kubernetes가 새 Pod 생성
     ↓
새 Pod Ready
     ↓
Replica 복구

과정에서 실제 서비스에는 어떤 영향이 있었는지 확인한다.

Error Rate는 증가했는가?

p95 / p99 Latency는 변했는가?

남아 있는 Pod의 CPU는 증가했는가?

새 Pod가 Ready가 되기까지 얼마나 걸렸는가?

사용자가 장애를 느낄 정도였는가?

같은 질문까지 확인해보려고 한다.

즉 이번 프로젝트에서는 Kubernetes를 단순히 배포 도구로 사용하는 것에서 끝내지 않고,

Application이 실제 운영 환경에서 어떤 상태인지 관찰하고, 부하와 장애에 어떻게 대응하는지를 직접 확인하는 과정

까지 다뤄보려고 한다.

---

3. 이번 프로젝트에서 중요한 것

이번 프로젝트의 목표는:

Docker Image 생성

↓

Kubernetes 배포

↓

HPA 설정

↓

Prometheus 연결

↓

Grafana 연결

↓

AWS 배포

↓

"Cloud 프로젝트 만들었다."

로 끝내는 것이 아니다.

이전 프로젝트에서 사용했던 방식과 동일하게 진행한다.

기본 구조 구현
      ↓
Baseline 측정
      ↓
문제 재현
      ↓
Metric 확인
      ↓
원인 분석
      ↓
개선 후보 비교
      ↓
구조 / 운영 설정 변경
      ↓
동일 조건 재측정

다만 이번에는 이전 프로젝트와 측정 대상이 조금 다르다.

Playback Gate에서는:

RPS

p95

p99

DB Connection

Cache Hit

등을 봤고,

Live Event Stream에서는:

Events/sec

Consumer Lag

Processing Latency

를 봤다면,

Cloud Ops Lab에서는 Application Metric뿐 아니라 운영 환경의 상태도 함께 보게 된다.

예를 들면:

Request Rate

Error Rate

p95 / p99 Latency

CPU Usage

Memory Usage

Ready Pod 수

Replica 수

Pod Restart

HPA 상태

Scale-out 시간

Recovery 시간

등이다.

즉 이번 프로젝트의 핵심은:

운영 문제도 재현하고 측정할 수 있는 대상으로 보는 것

이다.

---

4. 가장 단순한 구조부터 시작한다

처음부터 복잡한 Cloud Architecture를 만들지 않는다.

초기 구조는 최대한 단순하게 시작한다.

Client
   ↓
Kubernetes Service
   ↓
Deployment
   ↓
Pod
   ↓
Spring Backend

우선 하나의 Application을 Container로 만들고 Kubernetes에 배포한다.

처음에는 고정된 Replica로 시작한다.

예를 들어:

Deployment

Replica = 1

상태에서 정상 Request가 처리되는지 확인한다.

이 상태를 첫 번째 Baseline으로 사용한다.

처음부터 다음 기능을 모두 넣지는 않는다.

HPA

복잡한 Auto Scaling 정책

Service Mesh

Argo CD

Multi Cluster

Chaos Engineering Platform

복잡한 Alert Rule

분산 Tracing

대규모 Logging Stack

먼저 단순한 Kubernetes 환경에서 어떤 문제가 발생하는지 확인한다.

---

5. 먼저 Kubernetes의 기본 동작을 직접 확인한다

Kubernetes를 공부하면 다음 개념을 쉽게 접할 수 있다.

Pod

Deployment

ReplicaSet

Service

ConfigMap

Secret

문서로 개념을 이해하는 것과 실제 서비스가 동작하는 모습을 보는 것은 조금 다르다.

예를 들어 Deployment에:

replicas: 3

을 설정하면 Pod 세 개가 생성된다.

하지만 이번 프로젝트에서 확인하고 싶은 것은:

Pod 3개 생성

에서 끝나지 않는다.

Pod 하나를 직접 종료했을 때:

Pod 3개
   ↓
Pod 1개 종료
   ↓
Pod 2개
   ↓
새 Pod 생성
   ↓
다시 Pod 3개

로 돌아오는 과정을 직접 확인한다.

이를 통해 Kubernetes의 Desired State가 실제로 어떻게 유지되는지 이해한다.

---

6. 학습 목표

6.1 Container와 Kubernetes의 관계 이해

먼저 Backend Application을 Container Image로 만든다.

Spring Application
       ↓
Container Image
       ↓
Container
       ↓
Pod

이를 통해 다음 관계를 실제로 확인한다.

Application

Container

Pod

Deployment

Container가 실행되는 것과 Kubernetes에서 Pod가 관리되는 것은 같은 개념이 아니다.

Application을 Container로 만드는 과정부터 Kubernetes가 해당 Container를 어떻게 실행하고 관리하는지까지 직접 확인한다.

---

6.2 Pod, Deployment, Service 이해

Kubernetes의 기본적인 Application 배포 구조를 직접 만든다.

Client
   ↓
Service
   ↓
Pod A
Pod B
Pod C

Deployment는 원하는 Replica를 유지하고,

Service는 여러 Pod에 접근할 수 있는 Endpoint 역할을 한다.

이번 프로젝트에서는 단순히 YAML을 작성하는 것보다:

Deployment를 수정하면 Pod는 어떻게 바뀌는가?

Replica를 변경하면 어떤 순서로 Pod가 생성되는가?

Pod가 새로 생성되어도 Service는 계속 같은 주소로 접근할 수 있는가?

같은 동작을 직접 확인한다.

---

6.3 Resource Request와 Limit 이해

Container에는 CPU와 Memory Resource를 설정할 수 있다.

CPU Request

CPU Limit

Memory Request

Memory Limit

처음부터 적당해 보이는 값을 넣고 끝내지는 않는다.

먼저 Application의 Resource 사용량을 관찰한다.

Load 증가
   ↓
CPU 증가

Load 증가
   ↓
Memory 변화

그리고 Resource 설정을 변경했을 때 실제 Application의 상태가 어떻게 달라지는지 확인한다.

예를 들어 CPU Resource가 부족한 상태에서:

Traffic 증가
   ↓
CPU 사용
   ↓
처리 지연
   ↓
Latency 증가

가 실제로 발생하는지 확인할 수 있다.

Memory Limit 역시 너무 작게 설정하면 어떤 Failure가 발생하는지 직접 확인한다.

목표는 Resource YAML 값을 외우는 것이 아니라:

Resource 설정이 Application의 동작과 서비스 품질에 어떤 영향을 주는지를 이해하는 것

이다.

---

6.4 Liveness와 Readiness 이해

Application Process가 살아 있다는 것과 사용자의 Request를 받을 준비가 되어 있다는 것은 다를 수 있다.

예를 들어:

Application Process
→ 실행 중

하지만

Dependency 문제
→ Request 처리 불가

상태가 존재할 수 있다.

Kubernetes에서는 이를 구분하기 위해 Health Check를 사용할 수 있다.

Liveness Probe

Readiness Probe

이번 프로젝트에서는 정상 상태만 확인하지 않는다.

가능하면 다음 상태를 직접 만들어본다.

정상

Startup 중

Readiness 실패

Liveness 실패

그리고 각 상태에서:

Pod가 Restart되는가?

Service에서 제외되는가?

Request Error가 발생하는가?

를 확인한다.

이를 통해:

살아 있는가?

와:

Traffic을 받을 준비가 됐는가?

의 차이를 실제 운영 관점에서 이해한다.

---

6.5 Pod Failure와 Self-Healing 이해

Kubernetes의 장점 중 하나로 Self-Healing을 자주 이야기한다.

하지만:

Pod가 다시 생성됐다.

만 확인하고 끝내지는 않는다.

Pod를 강제로 종료하고 다음 흐름을 관찰한다.

정상 상태
   ↓
Pod 강제 종료
   ↓
Replica 감소
   ↓
Kubernetes 감지
   ↓
새 Pod 생성
   ↓
Readiness 통과
   ↓
정상 Replica 복구

그리고 Application Metric도 같이 확인한다.

Error Rate

Latency

CPU

Ready Pod

Recovery Time

이를 통해:

Infrastructure가 복구된 것과 서비스가 정상 상태를 유지한 것은 같은가?

를 확인한다.

---

6.6 Traffic 증가와 Scale Out 이해

Application Traffic이 항상 일정한 것은 아니다.

평상시에는 하나의 Pod로 충분할 수 있다.

Traffic
↓
Pod 1
↓
정상 처리

하지만 Traffic이 증가하면:

Traffic 증가
      ↓
Pod 1
      ↓
CPU 증가
      ↓
Latency 증가

같은 문제가 발생할 수 있다.

먼저 고정 Replica 상태에서 부하를 발생시킨다.

그리고 다음을 확인한다.

어느 수준의 Traffic부터 Latency가 증가하는가?

CPU는 얼마나 사용하는가?

Error는 언제 발생하는가?

Replica를 늘리면 실제로 개선되는가?

단순히:

Pod 수 증가
=
성능 향상

이라고 가정하지 않는다.

동일한 부하 조건에서 실제 결과를 비교한다.

---

6.7 HPA 이해

고정 Replica의 한계를 확인한 뒤 HPA를 실험한다.

기본적인 흐름은 다음과 같다.

Traffic 증가
      ↓
Resource Metric 증가
      ↓
HPA
      ↓
Desired Replica 증가
      ↓
새 Pod 생성
      ↓
Service Capacity 증가

하지만 이번 프로젝트에서 확인하려는 것은:

HPA가 Replica를 늘렸다.

가 아니다.

다음 값을 같이 본다.

Scale-out 전 p95 / p99

Scale-out 후 p95 / p99

CPU Usage

Replica Count

Scale-out 시작 시점

새 Pod Ready 시점

Error Rate

그리고:

HPA가 실제 사용자 관점의 Latency와 Error를 줄였는가?

를 확인한다.

---

6.8 Scale In과 과도한 Scaling 문제 이해

Auto Scaling은 Pod를 늘리는 것만 있는 것이 아니다.

Traffic이 감소하면 다시 줄어들 수 있다.

Traffic 감소
      ↓
Resource 사용 감소
      ↓
HPA
      ↓
Replica 감소

이 과정에서도 생각해볼 문제가 있다.

너무 빨리 줄어들지는 않는가?

Traffic이 다시 증가하면 바로 부족해지지 않는가?

Scale Out / Scale In이 반복되지는 않는가?

즉 Auto Scaling을:

Traffic 많음
→ Pod 증가

정도의 기능으로만 보지 않고 실제 운영 정책의 관점에서 확인한다.

---

7. Prometheus를 이용해 Metric을 수집한다

운영 문제를 분석하려면 먼저 상태를 관찰할 수 있어야 한다.

Application에 문제가 발생했을 때:

느려졌다.

정도로만 알고 있다면 원인을 찾기 어렵다.

Prometheus를 이용해 Application과 Kubernetes의 Metric을 수집한다.

예를 들면:

Request Rate

Error Rate

Request Latency

CPU Usage

Memory Usage

Pod 상태

Replica 상태

등이다.

중요한 것은 Metric을 많이 수집하는 것이 아니다.

각 Experiment에서:

무슨 일이 발생했는가?

를 확인할 수 있는 Metric을 선택한다.

---

8. Grafana를 이용해 상태 변화를 본다

Prometheus에서 수집한 Metric을 Grafana에서 확인한다.

하지만 이번 프로젝트의 목표는:

예쁜 Dashboard 만들기

가 아니다.

예를 들어 Traffic을 증가시켰을 때:

Traffic
   ↑

CPU
   ↑

Latency
   ↑

Replica
   ↑

Latency
   ↓

같은 흐름이 실제로 보이는지 확인한다.

Pod Failure Experiment라면:

Ready Pod 감소

↓

Error / Latency 변화

↓

새 Pod 생성

↓

Ready Pod 복구

가 Metric에서 어떻게 나타나는지 확인한다.

즉 Dashboard는 결과물이 아니라:

운영 상황을 이해하기 위한 관찰 도구

로 사용한다.

---

9. Monitoring과 Observability의 차이를 직접 경험한다

Monitoring만으로도 다음 값은 볼 수 있다.

CPU 80%

Memory 70%

Pod 3개

하지만 실제 장애에서는 조금 다른 질문이 생긴다.

"왜 갑자기 p99가 증가했지?"

이 질문에 답하려면 여러 신호를 같이 봐야 할 수 있다.

예를 들어:

p99 증가
   ↓
CPU 증가 확인
   ↓
Replica 수 확인
   ↓
HPA 상태 확인
   ↓
새 Pod Ready 시간 확인

처럼 원인을 좁혀갈 수 있다.

이번 프로젝트에서는:

Application Metric

Kubernetes 상태

Pod 상태

Event

Log

등을 이용해 장애의 원인을 설명해보려고 한다.

즉 Observability를:

Monitoring Tool을 설치했다.

로 이해하는 것이 아니라,

현재 시스템 내부에서 무슨 일이 발생하고 있는지 관측 데이터를 이용해 설명할 수 있는 상태

로 이해하는 것이 목표다.

---

10. 장애를 직접 만들어본다

운영 프로젝트라면 정상 상태만 확인해서는 부족하다.

실제 장애가 우연히 발생하기를 기다리지 않고 직접 Failure Scenario를 만든다.

예를 들면:

Pod 강제 종료

Application Crash

Readiness 실패

Resource 부족

Memory Limit 초과

Traffic Spike

같은 상황이다.

각 실험에서는 가능한 한 다음 순서를 유지한다.

정상 Baseline
      ↓
Failure Injection
      ↓
Metric 변화
      ↓
서비스 영향 확인
      ↓
Kubernetes 동작 확인
      ↓
Recovery

그리고 다음 질문에 답한다.

장애를 감지할 수 있었는가?

어떤 Metric이 먼저 변했는가?

Request Error가 발생했는가?

Latency는 얼마나 변했는가?

Kubernetes가 자동으로 복구했는가?

정상 상태로 돌아오기까지 얼마나 걸렸는가?

---

11. Recovery Time을 직접 확인한다

장애 대응에서 단순히:

결국 복구됐다.

만 보는 것은 부족하다.

예를 들어 Pod Failure가 발생했다면:

Failure 발생
      ↓
Kubernetes 감지
      ↓
새 Pod 생성
      ↓
Application Startup
      ↓
Readiness PASS
      ↓
정상 Traffic 처리

까지 시간이 필요하다.

따라서 이번 프로젝트에서는 가능한 경우:

Failure 시점

새 Pod 생성 시점

Ready 시점

서비스 정상화 시점

을 구분해서 확인한다.

이를 통해 Recovery가 실제 서비스에 어떤 영향을 주는지 본다.

---

12. Rolling Update와 배포 과정 이해

운영 환경에서는 새로운 Version을 배포하는 순간도 중요한 상태 변화다.

Deployment를 이용해 Rolling Update를 직접 확인한다.

예를 들면:

Version A
Pod 3개

↓

Version B 배포

↓

A / B 혼재

↓

B Pod Ready

↓

A Pod 종료

↓

Version B
Pod 3개

과정이다.

이때 다음 질문을 확인한다.

배포 중 Request Error가 발생하는가?

새 Pod가 Ready되기 전에 Traffic을 받는가?

배포 중 Latency는 달라지는가?

잘못된 Version을 배포하면 어떻게 되는가?

단순히:

kubectl apply 성공

을 배포 성공으로 판단하지 않는다.

실제 서비스 관점에서 배포 과정의 영향을 확인한다.

---

13. Application Metric과 Infrastructure Metric을 같이 본다

Application만 보면:

p99 증가

라는 결과만 보일 수 있다.

Kubernetes만 보면:

CPU 90%

라는 결과만 보일 수 있다.

하지만 둘을 연결하면:

Traffic 증가

↓

CPU 증가

↓

Pod Saturation

↓

p99 증가

↓

HPA Scale Out

↓

Replica 증가

↓

p99 감소

같은 흐름을 확인할 수 있다.

Cloud Ops Lab에서는 Application과 Infrastructure를 별개의 시스템처럼 보지 않고:

Application 상태와 운영 환경의 상태를 같이 관찰하는 것

을 중요하게 다룬다.

---

14. AWS 환경으로 확장한다

로컬 Kubernetes 환경에서도 기본적인 실험은 가능하다.

하지만 최종적으로는 AWS 환경까지 확장해보려고 한다.

목적은 AWS 서비스를 최대한 많이 사용하는 것이 아니다.

확인하고 싶은 것은:

Application
      ↓
Container
      ↓
Kubernetes
      ↓
Cloud Infrastructure

가 실제 환경에서 어떻게 연결되는가이다.

AWS 환경에서는 로컬과 비교해 다음 요소들도 실제 운영 조건에 가까워진다.

Compute Resource

Network

Load Balancing

Cloud Resource 사용량

운영 비용

다만 처음부터 AWS에 복잡한 Architecture를 만들지 않는다.

먼저 로컬 환경에서:

배포

부하

Scaling

Failure

Monitoring

Recovery

실험을 반복할 수 있는 상태를 만든 뒤 Cloud 환경으로 확장한다.

---

15. 성능과 Resource의 Trade-off도 확인한다

Replica를 늘리면 처리 Capacity가 증가할 수 있다.

예를 들어:

Replica 1
↓
p99 증가

Replica 3
↓
p99 감소

라는 결과가 나올 수 있다.

하지만 Replica가 늘어나면 Resource 사용량도 증가한다.

Replica 증가

↓

CPU Resource 증가

Memory Resource 증가

Cloud Resource 증가

따라서:

Pod가 많다
=
좋은 운영

이라고 판단하지 않는다.

이번 프로젝트에서는 가능한 범위에서:

성능

Resource

운영 비용

사이의 Trade-off도 같이 확인한다.

---

16. 장애 대응도 기능이 아니라 결과로 판단한다

Kubernetes에서:

Replica 설정

Health Probe 설정

HPA 설정

을 했다고 해서 장애 대응이 완료된 것은 아니다.

예를 들어:

Pod Failure
↓
자동 복구

가 발생했더라도 그 사이 Request가 계속 실패했다면 사용자 입장에서는 장애가 발생한 것이다.

따라서 장애 대응은 다음처럼 본다.

Failure
   ↓
서비스 영향
   ↓
Detection
   ↓
Recovery
   ↓
정상화

그리고 가능한 경우:

Error Rate

Latency

Recovery Time

Restart Count

같은 값을 기준으로 판단한다.

---

17. 실험이 이번 프로젝트의 핵심이다

Cloud Ops Lab에서도:

Kubernetes 배포

↓

HPA 추가

↓

Grafana 확인

↓

"잘 동작한다."

로 끝내지 않는다.

대신:

Baseline 생성
      ↓
부하 / Failure Scenario 실행
      ↓
Metric 기록
      ↓
현재 문제 확인
      ↓
원인 분석
      ↓
운영 설정 변경
      ↓
동일 Scenario 재실행
      ↓
Before / After 비교

방식으로 진행한다.

예를 들어:

Replica = 1
p99 = 측정값

↓

Replica 변경

↓

Replica = 3
p99 = 측정값

또는:

HPA 없음
Scale-out 없음

↓

HPA 적용

↓

Scale-out Time = 측정값
p99 = 측정값
Error Rate = 측정값

처럼 실제 결과를 비교한다.

물론 HPA를 적용했다고 반드시 결과가 좋아질 것이라고 가정하지 않는다.

Scale-out이 너무 늦어 Spike Traffic을 막지 못할 수도 있다.

Replica가 늘었지만 Database가 병목이라 Latency가 거의 달라지지 않을 수도 있다.

그 역시 정상적인 Experiment 결과로 남긴다.

---

18. 이전 프로젝트와 다른 점

지금까지 프로젝트의 중심 문제를 비교하면 다음과 같다.

프로젝트	핵심 문제
Playback Gate	많은 동기 요청을 빠르고 정확하게 처리
Live Event Stream	많은 Event를 안정적으로 비동기 처리
ContentOps Agent	내부 데이터에서 올바른 정보를 찾아 근거 있는 AI 답변 생성
LLM Router	요청에 적절한 Model을 선택하고 Quality / Cost / Latency 비교
Cloud Ops Lab	Kubernetes 환경에서 서비스를 운영하고 부하 / 장애 / 복구를 관찰

측정하는 값도 달라진다.

Playback Gate	Live Event Stream	ContentOps Agent	LLM Router	Cloud Ops Lab
RPS	Events/sec	Hit Rate@K	Quality	Request Rate
p95 / p99	Consumer Lag	MRR	Cost	Error Rate
DB Query	Processing Latency	Retrieval Latency	Latency	p95 / p99
Connection Pool	Retry / DLT	Tool Selection	Routing Decision	CPU / Memory
Race Condition	Duplicate Event	Grounding	Provider Failure	Replica / HPA
Lock	Idempotency	Hallucination	Token	Pod Restart
Cache	Partition	Reranking	Model 비교	Recovery Time

지금까지는 주로:

Application 내부

에서 문제를 찾았다면,

이번에는:

Application
+
Container
+
Kubernetes
+
Cloud

까지 관찰 범위를 넓힌다.

---

19. 이번 프로젝트에서도 기술을 미리 정답으로 두지 않는다

이번 프로젝트에서는 Kubernetes 자체가 학습 대상이기 때문에 다음과 같은 기본 기술은 처음부터 사용한다.

Container

Kubernetes

Deployment

Service

Prometheus

Grafana

그리고 처음 계획한 핵심 학습 대상인:

HPA

장애 대응

Observability

AWS

도 프로젝트 과정에서 직접 확인한다.

하지만 다음 기술까지 처음부터 모두 넣지는 않는다.

Terraform

Helm

Argo CD

Istio

Service Mesh

KEDA

OpenTelemetry

ELK / EFK

Chaos Mesh

Multi Cluster

실제 문제와 현재 학습 목표에 필요성이 생겼을 때만 후보로 검토한다.

예를 들어 HPA만으로 현재 Scaling 문제를 충분히 실험할 수 있다면 KEDA를 추가할 이유는 없다.

Prometheus와 Grafana만으로 현재 장애 원인을 확인할 수 있다면 처음부터 복잡한 Observability Stack을 만들 필요도 없다.

이번에도:

기술 사용 여부가 아니라 문제를 실제로 확인하고 설명할 수 있는지를 기준으로 판단한다.

---

20. 이번 프로젝트에서 확인하고 싶은 질문

Cloud Ops Lab을 진행하면서 다음 질문에 직접 답해보고 싶다.

Pod가 하나 죽었을 때 Kubernetes는 실제로 어떻게 복구하는가?

Pod Failure가 발생하는 동안 Request Error와 Latency는 어떻게 변하는가?

Liveness와 Readiness는 실제 서비스에서 어떤 차이를 만드는가?

CPU와 Memory Request / Limit은 Application에 어떤 영향을 주는가?

Replica를 늘리면 처리 Capacity가 실제로 증가하는가?

Traffic이 증가하면 HPA는 언제 Scale Out하는가?

Scale Out이 완료되기 전까지 서비스에는 어떤 영향이 있는가?

HPA를 적용하면 p95 / p99와 Error Rate가 실제로 좋아지는가?

Traffic이 줄었을 때 Scale In은 어떻게 동작하는가?

Rolling Update 중에도 Request를 안정적으로 처리할 수 있는가?

장애가 발생했을 때 Prometheus와 Grafana를 이용해 원인을 좁혀갈 수 있는가?

Application Metric과 Kubernetes Metric은 어떤 식으로 연결되는가?

Resource를 더 사용하는 만큼 실제 성능 이득이 있는가?

로컬 Kubernetes에서 확인한 동작이 AWS 환경에서도 어떻게 이어지는가?

이 질문들에 실제 Experiment 결과를 이용해 답하는 것이 이번 프로젝트의 중요한 학습 목표다.

---

21. 최종 목표

Cloud Ops Lab을 통해 단순히 AWS와 Kubernetes를 사용해보는 것이 아니라,

Backend Application을 Kubernetes 환경에 배포하고, Traffic 증가와 Resource 부족, Pod Failure, Health Check 실패 같은 운영 문제를 직접 재현한 뒤 Prometheus와 Grafana를 이용해 상태를 관찰하고, HPA와 Kubernetes의 복구 동작이 실제 서비스의 Latency·Error·Recovery에 어떤 영향을 주는지를 Metric과 Experiment로 설명할 수 있는 경험

을 만드는 것이 최종 목표다.

프로젝트가 끝났을 때:

Kubernetes를 사용했다.

HPA를 적용했다.

Prometheus를 붙였다.

Grafana Dashboard를 만들었다.

AWS에 배포했다.

라고 말하는 것보다 다음을 설명할 수 있었으면 한다.

어떤 부하에서 현재 Replica의 한계가 나타났는가?

어떤 Metric에서 문제를 확인했는가?

HPA가 언제 동작했고
실제 서비스 Metric은 어떻게 변했는가?

Pod Failure가 사용자 Request에 어떤 영향을 주었는가?

Recovery에는 얼마나 걸렸는가?

Readiness가 Traffic 보호에 어떤 역할을 했는가?

Resource 설정을 바꾼 뒤
성능과 안정성은 어떻게 달라졌는가?

장애가 발생했을 때
어떤 관측 데이터를 이용해 원인을 찾았는가?

결국 이번 프로젝트에서도 같은 방식으로 진행하려고 한다.

Baseline
   ↓
부하 / Failure 재현
   ↓
Metric 측정
   ↓
원인 분석
   ↓
대안 비교
   ↓
변경
   ↓
동일 조건 재측정

Cloud Ops Lab의 목표는 Kubernetes 기능을 많이 사용하는 것이 아니다.

실제 운영 환경에서 서비스가 어떤 상태인지 관찰하고, 부하와 장애에 어떻게 대응하며, 그 결과를 측정값으로 설명할 수 있게 되는 것

이 이번 프로젝트의 핵심이다.