diff --git a/submissions/Week1/.gitkeep b/submissions/Week1/.gitkeep deleted file mode 100644 index 8b13789..0000000 --- a/submissions/Week1/.gitkeep +++ /dev/null @@ -1 +0,0 @@ - diff --git "a/submissions/Week1/12\352\270\260_\354\235\264\355\225\264\354\233\220.md" "b/submissions/Week1/12\352\270\260_\354\235\264\355\225\264\354\233\220.md" new file mode 100644 index 0000000..e05075a --- /dev/null +++ "b/submissions/Week1/12\352\270\260_\354\235\264\355\225\264\354\233\220.md" @@ -0,0 +1,223 @@ +# 1주차 과제: 요청 처리 구조 설계 + +# 과제 1. 동기 처리와 비동기 처리 구조 다이어그램 + +## 동기 처리 구조 + +Image + +동기 처리에서는 API Server가 DB 발급 처리까지 모두 끝낸 뒤, 그 흐름 안에서 최종 결과를 사용자에게 응답한다. 사용자는 응답을 받는 순간 발급 성공 여부를 바로 알 수 있다. + +## 비동기 처리 구조 + +Image + +비동기 처리에서는 API Server가 요청을 접수한 뒤 바로 접수되었다는 응답을 반환한다. 실제 쿠폰 발급은 Worker가 뒤에서 처리하고, 사용자는 발급 결과를 나중에 조회해서 확인한다. + +## 두 구조의 차이 + +| 구분 | 동기 처리 | 비동기 처리 | +| --- | --- | --- | +| 응답 시점 | 발급 완료 후 | 요청 접수 후 | +| 응답 내용 | 최종 성공/실패 | 접수됨(PENDING) | +| API Server 점유 시간 | 길다 (DB 처리까지 대기) | 짧다 (접수 후 즉시 반환) | +| 부하 집중 | 요청 순간 DB에 집중 | Worker가 분산 처리 | +| 결과 확인 | 즉시 | 나중에 조회 | + + +--- + +# 과제 2. 구조 A와 구조 B 중 더 적합한 구조 선택 + +## 1. 두 구조 중 선착순 쿠폰 이벤트에 더 적합한 구조는 무엇인가? + +구조 B가 적합하다. +선착순 쿠폰 이벤트는 짧은 시간에 트래픽이 폭발적으로 몰린다. API Server가 요청을 빠르게 접수하고 즉시 응답한 뒤 실제 발급을 뒤에서 처리하는 구조 B가, 순간적인 부하를 흡수하고 API Server 스레드를 빠르게 회수할 수 있어 더 적합하다. + +## 2. 구조 A는 Queue를 사용했는데도 왜 비동기 처리의 장점이 줄어드는가? + +구조 A는 Queue에 요청을 적재하지만, API Server가 Worker의 처리 결과를 기다린다. 큐를 거쳐도 최종 결과가 나올 때까지 대기하므로, 동기 처리와 흐름이 다르지 않다. 비동기의 본질은 큐를 쓰느냐가 아니라 결과를 기다리지 않고 분리하느냐에 있다. 큐를 추가한 만큼 복잡도만 늘어나고 비동기의 부하 분산 효과는 거의 없다. + +## **3. API Server가 Worker 결과를 기다리면 어떤 문제가 생기는가?** + +- API Server 스레드가 Worker 처리 시간만큼 점유되어, 요청이 몰리면 스레드 풀이 고갈된다. +- 사용자는 여전히 최종 결과가 나올 때까지 기다려야 해서 응답 지연과 Timeout이 발생한다. +- 큐를 추가했지만 부하 분산 효과는 거의 없고, 시스템 복잡도가 증가한다. + +## 4. 구조 B를 선택한다면 사용자는 최종 발급 결과를 어떻게 확인해야 하는가? + +사용자는 먼저 처리 중 응답을 받고 실제 결과는 나중에 조회한다. Worker가 발급 처리를 끝내고 결과를 저장해 두면, 사용자는 조회 API를 폴링하거나 마이페이지에서 확인하는 방식으로 최종 발급 결과를 받는다. 발급 완료 시 푸시 알림으로 확인할 수도 있다. + +--- + +# 과제 3. 나쁜 설계의 문제점 찾고 개선하기 + +## **1. 문제가 될 수 있는 부분 5개 이상** + +1. API Server가 발급, 알림, 마이페이지 갱신까지 모두 한 흐름에서 처리해 요청당 처리 시간이 길다. +2. 한 요청이 오래 스레드를 점유해, 트래픽이 몰리면 스레드 풀과 Connection Pool이 고갈된다. +3. 알림 발송 실패가 쿠폰 발급 트랜잭션에 영향을 줄 수 있다. +4. 다수의 요청이 동시에 쿠폰 수량 조회를 수행하면, 초과 발급 문제가 발생할 수 있다. +5. 책임이 한 곳에 몰려 있어 장애 격리가 안 되고, 한 작업의 장애가 전체로 전파된다. + +## **2. API Server가 너무 많은 일을 하면 어떤 문제가 생기는가?** + +요청 하나당 처리 시간이 길어져 스레드 점유 시간이 늘고, 동시 처리 가능한 요청 수가 줄어든다. 선착순처럼 트래픽이 몰리는 상황에서는 스레드 및 커넥션 고갈, 응답 지연, Timeout으로 이어진다. +또한 핵심 로직(발급)과 부가 로직(알림)이 섞여 장애 격리와 유지보수가 어려워진다. + +## **3. 알림 발송이나 마이페이지 데이터 갱신이 실패하면 쿠폰 발급 응답에 어떤 영향을 줄 수 있는가?** + +같은 트랜잭션에 묶여 있으면, 부가 작업 실패가 발급 트랜잭션 롤백을 유발하거나 발급 응답을 실패로 만들 수 있다. 실제로는 쿠폰 발급이 성공했어야 하는데, 알림 전송 실패 때문에 사용자에게 실패로 응답되는 문제가 생길 수 있다. 발급의 성공 여부는 알림이나 마이페이지 갱신과 무관해야 한다. + +## **4. 요청 접수와 실제 발급 처리를 분리한 개선 구조** + +- **요청 접수 및 빠른 응답** + - Client → API Server: API 서버는 요청이 유효한지(로그인 여부, 이벤트 기간 등)만 빠르게 검증한다. + - API Server → Message Queue: 유효한 요청을 메시지 큐(Kafka, Redis Queue 등)에 발행(Publish)한다. + - API Server → Client: 큐에 안전하게 적재된 것을 확인한 즉시 발급 요청이 접수되었다고 클라이언트에게 빠르게 최종 응답을 반환하여 스레드를 반환한다. + +- **실제 쿠폰 발급 처리 (Worker A)** + - Queue → Worker A: 백그라운드 워커가 큐에서 요청을 순차적으로 꺼내어 DB에 수량을 차감하고 발급 기록을 저장한다. + +- **후속 작업 분리 (Worker B, C)** + - Worker A가 쿠폰 발급을 성공적으로 마치면 쿠폰 발급 완료 이벤트를 다시 발행한다. + - 알림 서버(Worker B)와 마이페이지 서버(Worker C)는 이 완료 이벤트를 구독하여 각각 비동기적으로 알림을 발송하고 데이터를 갱신한다. 이 과정이 실패해도 쿠폰 발급 자체에는 영향을 주지 않는다. +--- + +# 과제 4. API Server 직접 처리 vs 비동기 처리 영역 분리 + +| 작업 | API Server에서 처리 | 비동기 처리 영역에서 처리 | 이유 | +| --- | --- | --- | --- | +| 로그인 여부 확인 | O | | 인증 안 된 요청을 빠르게 걸러내야 하고, 접수 전에 즉시 판단 가능한 검증이다. | +| 이벤트 시간 확인 | O | | 이벤트 기간이 아니면 곧바로 거절해야 하므로 접수 단계에서 처리한다. | +| 쿠폰 수량 최종 차감 | | O | DB Lock과 경합이 큰 작업이라 API Server에서 처리하면 부하가 집중된다. Worker에서 순차/제어된 방식으로 차감해야 정확성과 성능을 확보한다. | +| DB 발급 기록 저장 | | O | 실제 발급 확정은 수량 차감과 함께 이뤄지는 핵심 처리이므로 비동기 영역에서 일관되게 수행한다. (단, 접수 상태 PENDING 저장은 API Server에서 한다.) | +| 사용자에게 요청 접수 응답 | O | | 검증과 접수가 끝나면 즉시 반환해야 API Server 스레드를 빠르게 회수할 수 있다. | +| 발급 성공/실패 최종 결정 | | O | 선착순 결과는 수량 차감 결과에 따라 결정되므로, 실제 발급을 처리하는 Worker에서 최종 확정한다. | + +--- + +# 과제 5. 요청 접수 성공 응답을 언제 반환할 수 있는가 + +## **1. API 서버는 언제 요청 접수 성공 응답을 반환해야 하는가?** + +요청이 유실되지 않도록 영속적인 저장소(DB의 PENDING 상태) 또는 안정적인 메시지 시스템(Queue/Kafka)에 안전하게 전달이 확정된 시점 이후에 접수 성공 응답을 반환해야 한다. 단순히 받기만 한 상태에서 응답하면 안 된다. + +## **2. 요청이 메모리에만 있는 상태에서 응답하면 생기는 문제** + +API Server가 응답 직후 장애로 종료되거나 재시작되면, 메모리에만 있던 요청이 사라진다. 사용자는 접수되었다는 알림을 받았지만 실제로는 발급 처리가 일어나지 않아, 요청이 유실되고 신뢰성이 깨진다. + +## **3. 요청 상태를 PENDING으로 저장한 뒤 응답하는 방식의 장단점** + +- 장점: 요청이 DB에 기록되어 서버 장애 시에도 유실되지 않는다. 사용자는 이 ID로 상태를 조회할 수 있고, 미처리 요청을 복구할 근거가 남는다. +- 단점: 요청마다 DB 쓰기가 발생해 트래픽이 몰리면 DB 부하가 커질 수 있다. PENDING 저장과 큐 전달 사이의 정합성 관리가 필요하다. + +## **4. 비동기 처리 영역에 전달된 것을 확인한 뒤 응답하는 방식의 장단점** + +- 장점: Kafka 또는 Queue가 메시지를 영속화 및 복제하므로 전달이 확정되면 유실 위험이 낮다. DB 직접 쓰기 부담을 줄일 수 있다. +- 단점: 큐 시스템 자체에 대한 의존과 운영 복잡도가 생긴다. 전달은 됐지만 아직 처리 전인 요청의 상태를 사용자에게 어떻게 보여줄지 별도 설계가 필요하다. + +## **5. 내가 선택한 방식과 이유** + +요청 상태를 DB에 PENDING으로 저장한 뒤 응답하는 방식을 선택한다. 사용자에게 접수 응답을 준 이상 그 요청은 반드시 처리되거나 추적 가능해야 하는데, DB에 PENDING으로 남겨 두면 서버 장애가 나도 유실되지 않고 이후 결과 조회와 복구가 모두 가능하기 때문이다. 접수의 기준은 유실되지 않는 응답이어야 한다. + +--- + +# 과제 6. 항상 비동기가 성능이 좋은가 + +## **1. 비동기가 동기보다 유리한 상황** + +순간적으로 트래픽이 폭증하거나, 처리에 시간이 오래 걸리는 작업, 외부 시스템 연동처럼 지연이 큰 작업일 때 유리하다. 요청 접수와 실제 처리를 분리해 순간 부하를 흡수하고, API Server 스레드를 빠르게 회수할 수 있다. + +## **2. 동기가 더 단순하고 적합한 상황** + +트래픽이 적고, 처리 시간이 짧으며, 사용자가 결과를 즉시 알아야 하는 단순한 작업이다. 일반 조회나 즉시 응답이 필요한 결제 확인 등은 동기가 구조도 단순하고 디버깅도 쉽다. + +## **3. 비동기 처리 구조를 사용하면 생기는 추가 복잡도** + +- 요청 상태 관리(PENDING/SUCCESS/FAIL)와 결과 조회 기능이 필요하다. +- 실패 시 재처리, 중복 처리 방지, 메시지 유실 대응이 필요하다. +- Queue, Kafka, Worker 등 운영 및 모니터링 대상이 늘어난다. +- 최종 결과 일관성을 사용자에게 설명하는 설계가 필요하다. + +## **4. 사용자가 최종 결과를 바로 알아야 하는 기능이라면 비동기가 항상 적합한가?** + +그렇지 않다. 결과를 즉시 알려줘야 하는 기능에 비동기를 쓰면 결과를 다시 조회하게 만들기 때문에 사용자 경험이 나빠진다. 이런 경우 동기 처리가 더 적합하거나 비동기를 쓰더라도 폴링이나 푸시로 결과를 빠르게 전달하는 보완 설계가 필요하다. + +## **5. 이번 선착순 쿠폰 이벤트에서는 왜 비동기 처리가 더 적합하다고 볼 수 있는가?** + +이벤트 시작 직후 초당 수천 건의 요청이 몰리는데, 모든 요청을 동기로 DB까지 처리하면 스레드나 커넥션 고갈과 Lock 경합으로 장애가 발생할 수 있다. 또한 선착순은 개수가 한정되어 있어서 대부분의 요청은 실패하므로 굳이 모든 요청을 즉시 최종 처리할 필요가 없다. 요청을 빠르게 접수해 부하를 흡수하고, 실제 발급은 제어된 속도로 처리한 뒤 결과를 조회하게 하는 비동기 구조가 안정성과 성능 모두에서 유리하다. + +--- + +# 과제 7. 동기/비동기와 블로킹/논블로킹 조합 분석 + +- 동기/비동기: 요청한 작업의 결과를 같은 흐름에서 직접 받는가, 아니면 흐름을 분리하는가. +- 블로킹/논블로킹: 작업이 끝날 때까지 현재 실행 흐름이 멈추는가, 바로 제어권을 돌려받는가. + +## 1. 동기 / 블로킹 + +결과를 같은 흐름에서 받고, 그 결과가 올 때까지 흐름이 멈춰 있다. + +``` +호출 흐름 ──read 호출──>리소스 + │ │ + │<───결과 반환─────────┘ (그 사이 호출 흐름은 멈춤/대기) + v +다음 로직 +``` + +## 2. 동기 / 논블로킹 + +결과는 같은 흐름에서 직접 받지만, 작업이 끝나지 않았으면 즉시 결과를 돌려받고 흐름은 멈추지 않는다. 대신 완료될 때까지 반복 확인(폴링)한다. + +``` +호출 흐름 ──시도────> 리소스 + │<──아직 안 됨(즉시 반환)──┘ + │ + │ + └──반복 폴링···> 리소스 ── 결과 수신 ──> 다음 로직 +``` + +## 3. 비동기 / 블로킹 + +작업 처리는 다른 흐름에 맡겼지만, 호출자가 그 결과를 기다리며 멈춰 있는 형태다. 비동기의 장점이 사라지는 조합으로 자주 지적된다. + +``` +호출 흐름 ──작업 위임──> 처리 흐름 + │ │ (실제 처리) + │<────결과 통보─────────┘ (그동안 호출 흐름은 결과 대기로 멈춤) + v +다음 로직 +``` + +## 4. 비동기 / 논블로킹 + +작업을 다른 흐름에 위임하고, 호출 흐름은 멈추지 않고 즉시 다음 일을 한다. 결과는 콜백/이벤트/별도 조회로 나중에 받는다. + +``` +호출 흐름 ──작업 위임──> 처리 흐름 + │ │ (실제 처리) + V │ +다른 작업 │ + ^ │ + └────콜백/이벤트 통보────┘ (완료되면 나중에 결과 전달) +``` + +## 2. 이번 선착순 쿠폰 발급 구조에 등장하는 조합 + +**(1) 비동기 / 논블로킹** + +API Server가 요청을 접수(PENDING 저장 + Queue 전달)한 뒤 Worker 결과를 기다리지 않고 즉시 접수 응답을 반환하는 부분이 이 조합에 해당한다. 처리 흐름(Worker)과 요청 흐름(API Server)이 분리되고, API Server는 멈추지 않고 다음 요청을 처리한다. 사용자는 결과를 나중에 조회한다. + +**(2) 비동기 / 블로킹** + +구조 A처럼 Queue에 요청을 넣고도 API Server가 Worker의 처리 결과를 기다리는 부분이 여기에 해당한다. 처리는 분리됐지만 호출자(API Server)가 결과를 기다리며 멈춰 있어, 비동기의 장점이 사라진다. + +**(3) 동기 / 블로킹: 부분적으로 등장** + +API Server나 Worker가 DB에 접근할 때 일반적인 블로킹 DB 드라이버를 쓴다면, 그 개별 DB 호출 단위는 동기/블로킹이다. 또한 가장 단순한 동기 구조(Client → API Server → DB → 응답) 전체가 동기/블로킹에 해당한다. + +**등장하지 않을 수 있는 조합: 동기 / 논블로킹** + +이번 시나리오에서 결과를 같은 흐름에서 폴링으로 직접 받는 동기/논블로킹 패턴은 일반적으로 등장하지 않는다. 결과를 분리(비동기)하거나, 분리하지 않고 그냥 기다리는(동기/블로킹) 쪽으로 설계되기 때문이다.