cloud-13회차-2026-03-11-pl-meeting

[WAFriend3416]

기본 정보

• 팀명: 나춘식과 집사들 (14팀)
• 미팅 일시: 2026.03.11 목요일 13:15 ~
• 미팅 회차: 13주차 1회차
• 참여 인원: @WAFriend3416, @juyoungIt

---

1. 이전 PL 미팅 이후 구현 내용 (완료)

사실 기반으로 작성, 완료 기준 명확히

• 구현한 기능:
  • V3 인프라 IaC 작성 및 테스트 완료
  • V3 k8s 클러스터 IaC 작성 및 테스트 완료
  • 무중단 마이그레이션 스토리 완결 (ProxySQL을 통한 실패율 낮추기 실패)
  • MySQL, MongoDB, Redis, RabbitMQ HA 방안 기술선정 및 다이어그램 작성
• 관련 PR / 커밋 링크:
  • feat: V3 K8S 매니페스트 + ECR Credential Provider + 설계 확정 feat: V3 K8S 매니페스트 + ECR Credential Provider + 설계 확정 #278
• 구현 범위 요약:
  • V3 K8S 클러스터 구성 완료
  • Dev 서버 매니페스트 수동 배포 완료
  • V3 Stateful 성격의 서비스들 다중화 설계 완료다이어그램 첨부

---

2. 이전 PL 미팅 이후 추가로 진행한 작업

예상에 없었으나 실제로 진행한 작업

• 추가 작업 내용:
• 추가 작업을 하게 된 이유:

---

3. 구현하지 못한 내용

계획 대비 미완료 항목

• 미구현 기능:
• 구현하지 못한 이유:

---

4. 현재 어려운 점

기술적·구조적 어려움만 작성

• 기술적 문제:
  • 무중단 마이그레이션 과정에서 MySQL 쓰기실패율 0% 달성 실패 (+ ProxySQL의 한계점)
• 구조/설계 관련 고민:
  • Public 저장소에서의 GitOps Secret 관리 리스크
    • ArgoCD(GitOps) 파이프라인을 구축 중이나, 설정 저장소(Config Repo)가 외부에 공개된 Public 상태.
    • SOPS 등으로 암호화하여 K8S Secret을 커밋하더라도, Public 환경 특성상 암호문 노출에 따른 공격 리스크 존재.
• 스스로 시도해본 해결 방법:
  • Secret 문제: AWS Secrets Manager에 실제 환경변수를 저장하고, K8S 클러스터 내에 External Secrets Operator(ESO)를 도입하여 동기화하는 방안을 설계 중.
  • 무중단 마이그레이션 간 MySQL 쓰기실패 0.019%
    • 다양한 방향으로 마이그레이션 스크립트를 개선하며 20회 이상의 무중단 마이그레이션 테스트 수행 (분리된 환경에서 수행)
    • ProxySQL이 Query를 Resume하는 방식(In-flight Query), Spring Boot의 HikariCP 등의 문제로 단순 ProxySQL의 도입만으로는 쓰기 실패 문제 해결을 기대하기 어려우며, 애플리케이션 수준의 재시도 로직을 넣거나 Debezium & CDC 솔루션을 택해야 함
    • 하지만 Kafka가 기본 스택에 포함되어 있지 않던 관점에서 CDC & Debezium은 다소 오버엔지니어링 성격이 강하다는 입장

---

5. PL의 답변

PL 미팅에서 받은 피드백을 수강생이 정리

• PL 피드백 요약:

• 즉시 반영해야 할 사항:

• 추후 개선 또는 보류 사항:

---

체크리스트

• 실제 구현 기준으로 작성함
• PR / 커밋 링크 포함함
• 미구현 사유를 솔직하게 작성함
• 구두 설명 없이 문서만으로 상황 파악 가능함

[WAFriend3416]

[FIS 테스트 기획] 4.0 vs 5.0 아키텍처 복원력(Resilience) 비교 검증

1. 테스트 목적

• 4.0에서 5.0 K8S 아키텍처로 전환함에 따라 확보한 서비스 회복력(Resilience) 향상 및 복구 시간(MTTR) 단축을 AWS FIS(Fault Injection Simulator)를 통해 정량적으로 증명.

2. 베이스라인 및 아키텍처 비교군

• 베이스라인: 4.0 환경 (4.5와 페일오버/스케일링 로직이 유사하므로 4.0으로 통일하여 비교)
• 구조적 차이점 (AS-IS vs TO-BE):
  • Compute: 4.0 (VM 기반 Auto Scaling, 느린 프로비저닝) ↔ 5.0 (K8S 파드 Auto Scaling, 빠른 프로비저닝)
  • Stateful: 4.0 (Standby 구조, 수동 Failover 필요) ↔ 5.0 (HA 구조, 자동 Failover)
  • AZ (가용영역): 4.0 (2AZ 기반) ↔ 5.0 (3AZ 기반 )

3. 핵심 FIS 장애 주입 시나리오

• 시나리오 A (컴퓨팅 노드 장애): EC2 인스턴스 강제 종료. VM 부팅/초기화 시간과 K8S 파드 프로비저닝 속도 비교.
• 시나리오 B (Stateful 리더 노드 장애): DB/Cache 프라이머리 노드 장애 주입. 수동 Failover 개입 시간과 HA 자동 리더 선출/복구 시간 비교.
• 시나리오 C (AZ 전체 장애): 특정 AZ 네트워크 단절. 2AZ 아키텍처의 한계와 3AZ 기반 K8S의 즉각적인 트래픽 분산 능력 확인.

4. 지표 측정 및 테스트 환경 구성 방안 (SLI & MTTR)

• 제약 사항: 현재 실제 운영 트래픽이 미미하여, 단순 장애 주입만으로는 응답 지연(Latency)이나 5xx 에러율 같은 가용성 지표(SLI) 변화를 관측하기 어려움.
• 해결 방안 (Synthetic Traffic 주입):
  • 부하 테스트 도구(k6, Locust 등)를 활용해 일정한 가상 트래픽(예: 50 RPS)을 지속적으로 발생시키는 통제된 실험 환경 구성.
  • 트래픽이 흐르는 도중 FIS로 장애 주입 수행.
• 핵심 관측 지표:
  • 장애 주입 시점부터 시스템이 정상 응답(HTTP 200 OK)을 100% 회복할 때까지 걸린 절대 시간 (MTTR 측정).
  • 복구 과정에서 발생하는 API 실패 구간(Downtime) 길이 비교 (4.0의 수 분 단절 vs 5.0의 초 단위 단절 또는 무중단).