Phase 1 · 연쇄 장애의 밤¶
예상 소요 1시간 30분 · 난이도 ⭐⭐
스토리¶
김팀장이 노트북을 열고 지난 목요일 장애 로그를 띄웠습니다.
"이걸 보세요. 결제 API 응답이 2초에서 8초로 늘어난 시점이, 주문 조회 API 에러율이 치솟기 시작한 시점이랑 거의 동시예요. 왜 이런 일이 생기는지 박대리가 설명해볼래요?"
박대리는 모니터를 응시했지만, 솔직히 잘 모릅니다. "원래 그런 거 아닌가?" 정도가 솔직한 심정입니다. 이 Phase의 목표는 그 느낌을 구조적으로 이해하는 것입니다.
핵심 질문¶
- 주문 조회 API는 어떻게 결제 API를 호출하고 있나?
- 결제 API가 느려지면 주문 조회 API에서는 무슨 일이 일어나는가?
- 왜 단순히 "결제 호출을 빼면" 되는 문제가 아닌가?
학습 목표¶
- REST 기반 동기 호출의 호출 흐름을 다이어그램으로 그릴 수 있다
- 스레드 풀 포화가 장애 전파의 본질임을 설명할 수 있다
- 타임아웃이 있음/없음에 따라 결과가 어떻게 달라지는지 체험한다
- "CA 환경에서의 서비스 간 통신 설계 시 고려사항"을 3가지 이상 나열한다
세부 단원¶
Phase 1-1 · REST 기반 서비스 통신 구조 이해 (1시간)¶
| 소단원 | 활동 |
|---|---|
| REST 동기 호출의 본질 | 강의 + 코드 리딩. order-api가 payment-api를 호출하는 코드 분석 |
| 타임아웃과 연결 풀 | 현재 코드에 타임아웃이 설정되어 있는지 확인 (스포일러: 없음) |
| 호출 흐름 다이어그램 그리기 | 팀별로 주문 조회 → 결제 호출 흐름 화이트보드에 그려보기 |
왜 다이어그램을 직접 그리나
다음 Phase들에서 어디에 Retry/Circuit Breaker를 넣을지, 어디를 ArgoCD가 배포할지 계속 이 그림을 참조합니다. 꼭 본인 손으로 한 번 그려보세요.
Phase 1-2 · 장애 전파 체험 (30분)¶
| 소단원 | 활동 |
|---|---|
| 결제 API에 지연 주입 | payment-api에 FAULT_DELAY_MS=8000 환경변수 주입 |
| 주문 API 부하 걸기 | ab 또는 hey로 동시 접속 30개 발생 |
| 장애 전파 관찰 | 주문 API 스레드 포화 → 응답 불가 → 완전한 장애 체감 |
예상 결과물¶
이 Phase가 끝나면 여러분은 다음을 손에 쥐고 있어야 합니다.
- 주문 API → 결제 API 호출 흐름 다이어그램 (손그림 OK)
- "왜 결제 지연이 주문 장애로 번지는가" 3줄 요약 메모
- 실제로 재현해본 장애 상황의 터미널 캡처