diff --git "a/submissions/Week1/13\352\270\260_\354\213\240\355\230\204\354\243\274.md" "b/submissions/Week1/13\352\270\260_\354\213\240\355\230\204\354\243\274.md" new file mode 100644 index 0000000..84ebc36 --- /dev/null +++ "b/submissions/Week1/13\352\270\260_\354\213\240\355\230\204\354\243\274.md" @@ -0,0 +1,287 @@ +# 1주차 과제 답변 + + +## 과제 1. 동기 처리와 비동기 처리 구조 다이어그램 + +쿠폰 발급 요청이 들어왔을 때 동기 처리 방식과 비동기 처리 방식이 각각 어떤 순서로 동작하는지 다이어그램으로 작성한다. + +그림 아래에는 두 구조의 차이를 간단히 설명한다. + +Image + +**동기 처리**: API Server가 요청을 받은 즉시 모든 처리를 순서대로 끝내고, 최종 성공/실패 결과를 Client에게 반환한다. Client는 처리가 완전히 끝날 때까지 기다린다. + +**비동기 처리**: API Server는 요청을 받아 검증 후 Queue에 메시지를 넣고, 즉시 요청 접수 완료 응답을 Client에게 반환한다. 실제 쿠폰 발급 처리는 Worker가 별도로 수행하며, Client는 나중에 결과를 확인한다. + +### 두 구조의 차이 + +| 항목 | 동기 처리 | 비동기 처리 | +|------|----------|------------| +| 응답 시점 | 모든 처리가 끝난 후 | 요청 접수 후 즉시 | +| 사용자 결과 확인 | 응답에서 바로 확인 | 나중에 별도 조회 | +| 트래픽 집중 시 부하 | API Server + DB에 집중 | Queue가 완충 역할 | +| 적합한 상황 | 낮은 트래픽, 즉시 결과 필요 | 대규모 트래픽, 처리 분리 필요 | + +--- + +## 과제 2. 구조 A와 구조 B 중 더 적합한 구조 선택하기 + +아래 두 구조를 비교한다. + +image + +다음 질문에 답한다. + + +``` +1. 두 구조 중 선착순 쿠폰 이벤트에 더 적합한 구조는 무엇인가? +구조 B가 더 적합하다. +구조 B는 API Server가 Queue에 메시지를 넣은 뒤 즉시 요청 접수 완료 응답을 반환하고, 실제 발급 처리는 Worker가 비동기로 수행한다. 이 방식은 API Server의 처리 시간을 최소화하여 대규모 동시 요청을 빠르게 수용할 수 있다. + + +2. 구조 A는 Queue를 사용했는데도 왜 비동기 처리의 장점이 줄어드는가? +구조 A에서는 API Server가 Queue에 메시지를 넣은 뒤, Worker가 처리를 끝낼 때까지 응답을 보내지 않고 대기한다. +Queue를 사용하더라도 API Server가 Worker 결과를 기다리는 순간, 해당 요청을 처리 중인 스레드는 계속 점유된다. 결국 동시 요청이 많아지면 API Server의 스레드가 Worker 응답 대기로 모두 묶여 버리고, 구조적으로는 동기 처리와 비슷한 병목이 발생한다. Queue가 있어도 그 장점을 살리지 못하는 것이다. + +3. API Server가 Worker 결과를 기다리면 어떤 문제가 생기는가? +- 스레드 점유: 결과를 기다리는 동안 해당 스레드가 묶여 다른 요청을 처리하지 못한다. +- 응답 지연: Worker 처리 시간만큼 Client의 대기 시간이 늘어난다. +- Timeout 위험: Worker 처리가 지연될 경우 API Server-Client 간 연결이 타임아웃될 수 있다. +- 확장성 저하: 결국 API Server의 동시 처리 용량이 Worker 처리 속도에 종속된다. + + +4. 구조 B를 선택한다면 사용자는 최종 발급 결과를 어떻게 확인해야 하는가? +- 폴링: 클라이언트가 주기적으로 내 쿠폰 발급 상태 조회 API를 호출해 Worker 처리 결과(SUCCESS / FAILED / PENDING)를 확인한다. +- 마이페이지/알림: Worker 처리 완료 후 쿠폰 지갑이나 알림 센터에 결과를 표시해, 사용자가 나중에 확인하도록 한다. + +``` +--- + +## 과제 3. 나쁜 설계의 문제점을 찾고 개선하기 + +다음 설계를 보고 문제가 될 수 있는 부분을 찾는다. + +image +다음 질문에 답한다. + + +``` +1. 이 설계에서 문제가 될 수 있는 부분을 5개 이상 찾아라. +(1) API Server의 역할 과부하 +- 요청 검증, 수량 차감, DB 저장, 알림 발송, 마이페이지 갱신을 하나의 요청 흐름에서 처리한다. +- 단일 책임 원칙에 위배되고 장애 범위가 넓어진다. +(2) 응답 지연 +- 알림 발송이나 마이페이지 갱신은 쿠폰 발급의 핵심 로직이 아닌데도, 이 작업들이 끝날 때까지 Client는 응답을 기다려야 한다. +- 외부 서비스가 느리면 전체 응답 시간이 늘어난다. +(3) DB 병목 및 Lock 경합 +- 동시에 수만 건의 요청이 쿠폰 수량 차감을 시도하면 Lock 경합이 심해지고, Deadlock이나 Timeout이 발생할 수 있다. +(4) 원자성 보장 어려움 +- DB 저장 → 알림 발송 → 마이페이지 갱신을 하나의 트랜잭션으로 묶기 어렵다. +- 예를 들어 DB 저장 후 알림 발송이 실패하면 일관성이 깨질 수 있다. +(5) 재시도 및 멱등성 처리 부재 +- 단일 흐름에서 중간에 실패했을 때 어느 단계부터 재시도해야 하는지 명확하지 않다. +- 요청을 재시도하면 수량이 중복 차감될 위험도 있다. + + +2. API Server가 너무 많은 일을 하면 어떤 문제가 생기는가? +- 처리 시간 증가: 작업이 많을수록 하나의 요청 처리 시간이 길어지고, 그 시간 동안 스레드와 DB 커넥션이 점유된다. +- 장애 전파: 알림 서버처럼 부가 기능이 장애를 일으켜도 쿠폰 발급 전체가 실패하는 등, 영향 범위가 커진다. +- 확장 어려움: 모든 로직이 한 서버에 묶여 있으면, 특정 기능만 부분적으로 스케일 아웃하기 어렵다. +- 유지보수 어려움: 기능이 뒤섞여 있으면 코드 변경 시 의도치 않은 부작용이 생길 가능성이 높다. + + +3. 알림 발송이나 마이페이지 데이터 갱신이 실패하면 쿠폰 발급 응답에 어떤 영향을 줄 수 있는가? +- 쿠폰은 발급됐지만 응답이 실패로 반환 +- 사용자에게 오류 응답 반환 +- 데이터 불일치 + + +4. 요청 접수와 실제 발급 처리를 분리하는 구조로 개선 +- API Server는 검증 + 요청 상태 저장 + Queue 발행까지만 담당하고 즉시 응답한다. +- 수량 차감, 발급 기록 저장, 상태 갱신은 Worker가 담당한다. +- 알림 발송, 마이페이지 갱신은 Worker가 발행하는 별도 이벤트를 통해 각각의 서비스가 처리한다. 이 과정이 실패해도 쿠폰 발급 결과에는 영향을 주지 않는다. + +``` + +--- + +## 과제 4. API Server가 직접 처리할 일과 비동기 처리 영역으로 넘길 일 나누기 + +쿠폰 발급 요청이 들어왔을 때 API Server가 직접 처리해야 하는 일과, 비동기 처리 영역으로 넘겨야 하는 일을 구분한다. + +| 작업 | API Server에서 처리 | 비동기 처리 영역에서 처리 | 이유 | +|------|:-----------------:|:--------------------:|------| +| 로그인 여부 확인 | O | | 비인가 요청을 가장 앞단에서 차단해야 한다. Queue에 유효하지 않은 요청이 들어가면 Worker 자원이 낭비된다. | +| 이벤트 시간 확인 | O | | 이벤트 시간 외 요청을 빠르게 거절해야 한다. 검증 비용이 낮고, Queue에 무의미한 메시지가 쌓이는 것을 막을 수 있다. | +| 쿠폰 수량 최종 차감 | | O | 수량 차감은 동시성 제어가 필요한 핵심 로직이다. Worker가 순차적으로 처리하면 DB Lock 경합을 줄일 수 있다. | +| DB 발급 기록 저장 | | O | 발급 기록 저장은 수량 차감 이후에 이루어져야 하며, Worker가 차감 결과에 따라 처리하는 것이 자연스럽다. | +| 사용자에게 요청 접수 응답 | O | | 사용자에게 요청이 접수됐다는 피드백을 빠르게 줘야 한다.| +| 발급 성공/실패 최종 결정 | | O | 실제 수량 차감 결과를 알아야만 성공/실패를 판단할 수 있다.| + +--- + +## 과제 5. 요청 접수 성공 응답을 언제 반환할 수 있는지 설계하기 + +비동기 처리 구조에서는 API Server가 사용자에게 다음과 같은 응답을 반환할 수 있다. + +``` +쿠폰 발급 요청이 접수되었습니다. +``` + +하지만 이 응답을 아무 때나 반환하면 안 된다. + +예를 들어 요청이 메모리에만 있는 상태에서 응답했는데 API Server가 장애로 종료되면 요청이 유실될 수 있다. + +따라서 API Server가 언제 사용자에게 요청 접수 성공 응답을 반환할 수 있는지 설계해야 한다. + +다음 질문에 답한다. + +``` +1. API 서버는 언제 사용자에게 요청 접수 성공 응답을 반환해야 하는가? +- Queue에 안전하게 전달된 순간 +- 요청 상태가 DB에 PENDING으로 저장된 순간 +- 서버가 재시작되거나 장애가 발생해도 해당 요청이 유실되지 않는 상태가 되어야 한다. + +2. 요청이 메모리에만 있는 상태에서 응답하면 어떤 문제가 생기는가? +- 사용자 입장: 접수 완료 응답을 받았는데 쿠폰이 발급되지 않음 +- 시스템 입장: 유실된 요청에 대한 복구 수단이 없음 +- 신뢰성 저하: 요청 접수 완료 응답의 의미가 무효화됨 + +3. 요청 상태를 PENDING으로 저장한 뒤 응답하는 방식은 어떤 장단점이 있는가? +[장점] +- DB에 기록이 남으므로 서버 재시작 후에도 요청이 유실되지 않는다. +- Worker가 DB를 폴링하거나 스케줄러로 PENDING 요청을 처리할 수 있어, Queue 없이도 구현 가능하다. +- 발급 상태를 DB에서 일관되게 관리할 수 있다. +[단점] +- DB 저장 자체가 병목이 될 수 있다. 대규모 요청이 몰리면 PENDING 저장 쿼리가 DB에 부하를 준다. +- Queue 없이 DB를 직접 폴링하면 폴링 간격 동안 처리 지연이 생길 수 있다. + +4. 비동기 처리 영역에 전달된 것을 확인한 뒤 응답하는 방식은 어떤 장단점이 있는가? +[장점] +- Queue는 내구성을 보장하도록 설계되어, 메시지가 발행되면 소비 전까지 보존된다. +- DB 저장보다 빠르게 응답할 수 있다. +- Worker 처리 속도와 API Server 응답을 완전히 분리할 수 있다. +[단점] +- Queue 자체가 장애를 일으키면 요청 접수 자체가 불가능해진다. +- DB와 Queue 간 상태 동기화가 필요하다. Queue 발행은 성공했지만 DB PENDING 저장에 실패하는 케이스 등 예외 처리가 복잡하다. +- Queue 인프라 관리 비용이 추가된다. + +5. 내가 선택한 방식과 그 이유를 설명하라 +- DB에 PENDING 저장 + Queue 발행 확인 후 응답 구조 +(1) 요청 검증(로그인, 이벤트 시간) +(2) DB에 요청 상태 PENDING 저장 +(3) Queue에 메시지 발행 +(4) 발행 성공 확인 후 Client에게 접수 완료 응답 + +[이유] +- DB PENDING 저장만으로도 유실 방지가 가능하지만, Queue 발행까지 확인하면 Worker가 빠르게 처리를 시작할 수 있어 처리 지연이 줄어든다. +- Queue 발행 실패 시에는 DB에 PENDING 기록이 남아 있으므로, 별도 재처리 스케줄러가 해당 요청을 다시 Queue에 넣을 수 있다 +- 단순히 메모리에만 올린 뒤 응답하거나, 요청 검증만 하고 응답하는 방식은 서버 장애 시 요청 유실 위험이 있으므로 선택하지 않는다. +``` +--- + +## 과제 6. 항상 비동기가 성능이 좋은지 생각해보기 + +비동기 처리는 대규모 트래픽 상황에서 유리할 수 있다. + +하지만 항상 비동기가 더 좋은 것은 아니다. + +다음 질문에 답한다. + +``` +1. 비동기 처리가 동기 처리보다 유리한 상황은 언제인가? +- 대규모 동시 요청이 몰리는 상황 (선착순 이벤트, 티켓 예매) +- 처리 시간이 오래 걸리는 작업 (이미지 변환, 대용량 파일 처리) +- 결과를 즉시 알지 않아도 되는 작업 (이메일 발송, 알림) + +2. 동기 처리가 더 단순하고 적합한 상황은 언제인가? +- 사용자가 즉시 결과를 알아야 하는 경우 (로그인 성공 여부, 결제 승인) +- 처리 시간이 짧고 트래픽이 예측 가능한 경우 (일반적인 CRUD API) +- 트랜잭션 원자성이 중요한 경우 (금융 이체) +- 팀 규모가 작거나 인프라 관리 비용을 최소화해야 하는 서비스 + +3. 비동기 처리 구조를 사용하면 어떤 추가 복잡도가 생기는가? +- 상태 관리: 요청의 현재 상태를 저장하고 조회하는 구조가 필요하다. +- 결과 조회: 사용자가 결과를 확인하기 위한 메커니즘이 추가된다. +- 멱등성 보장: Worker가 같은 메시지를 두 번 처리해도 결과가 같아야 한다. +- 실패 처리: Worker 실패 시 재시도 처리가 필요하다. +- 인프라 비용: Queue 시스템 도입 및 운영 비용이 발생한다. + +4. 사용자가 최종 결과를 바로 알아야 하는 기능이라면 비동기 처리가 항상 적합한가? +그렇지 않다. 사용자가 결과를 즉시 알아야 하는 경우에는 비동기 처리가 오히려 불편할 수 있다. +예를 들어 결제 완료 여부, 회원가입 성공 여부는 사용자가 그 결과를 보고 다음 행동을 결정한다. +비동기가 적합한 경우는 결과 지연이 수용 가능하거나, 처리 자체가 오래 걸려서 동기로 기다리는 것이 더 나쁜 경험이 되는 경우다. + +5. 이번 선착순 쿠폰 이벤트에서는 왜 비동기 처리가 더 적합한가? +- 트래픽 집중: 이벤트 시작 직후 수만 건의 요청이 몰린다. 동기 처리로 모든 요청이 DB에 동시에 접근하면 Lock 경합, Connection Pool 고갈, 응답 지연이 발생한다. +- 결과 지연 수용 가능: 쿠폰 발급 결과는 수 초~수십 초 후에 마이페이지나 폴링으로 확인해도 된다. 즉각적인 최종 결과가 반드시 필요한 상황이 아니다. +- 요청 유실 방지: Queue를 통해 요청을 순서대로 처리하면 선착순 보장과 수량 초과 방지를 더 안정적으로 구현할 수 있다. +- API Server 보호: Queue가 완충재 역할을 해, API Server는 요청을 받아 넘기는 역할만 하면 되므로 서버 과부하를 방지할 수 있다. + +``` +--- + +## 과제 7. 동기/비동기와 블로킹/논블로킹 조합 분석하기 + +동기/비동기와 블로킹/논블로킹은 비슷해 보이지만 기준이 다르다. + +동기/비동기는 요청한 작업의 결과를 **같은 요청 흐름에서 직접 받아 처리하는가**, 아니면 요청 흐름과 실제 처리 흐름을 분리하는가에 대한 개념이다. + +블로킹/논블로킹은 **작업이 끝날 때까지** 현재 실행 흐름이 멈추는가, 아니면 바로 제어권을 돌려받는가?에 대한 개념이다. + +다음 4가지 조합을 분석한다. + +**1. 아래 4가지 조합 각각이 무엇인지, 일반적인 작업 흐름(예: 함수 호출, DB 호출, 소켓 IO 등) 기준으로 다이어그램과 함께 설명하라. (쿠폰 발급 시나리오에 한정하지 않아도 된다.)** + +Image + +**① 동기 / 블로킹** +- 결과를 같은 흐름에서 직접 받고 + 기다리는 동안 실행 흐름이 멈춘다 +- 가장 일반적인 형태로 DB에 쿼리를 날리면 + 응답이 올 때까지 다음 코드가 실행되지 않는다 + + +**② 동기 / 논블로킹** +- 결과를 같은 흐름에서 직접 받지만 + 기다리는 동안 멈추지 않고 계속 확인한다 +- 작업을 요청하면 즉시 제어권을 돌려받고 + 결과가 나올 때까지 반복적으로 확인한다 +- 결과를 직접 받는다는 점에서 동기이지만 + 멈추지 않고 계속 확인한다는 점에서 논블로킹이다 + + +Image + +**③ 비동기 / 블로킹** +- 처리 흐름은 분리되어 있지만(비동기) + 결과를 받기 위해 실제로 기다린다(블로킹) +- 비동기로 작업을 넘겼지만 결과를 기다리기 때문에 + 비동기의 장점이 사라진 구조다 + + +**④ 비동기 / 논블로킹** +- 처리 흐름이 분리되어 있고 + 요청 후 현재 흐름이 멈추지 않는다 +- 결과는 콜백이나 이벤트로 나중에 받는다 +- 가장 이상적인 비동기 구조로 + 요청을 넘기고 바로 다른 작업을 처리할 수 있다 + +**2. 이 4가지 중 이번 선착순 쿠폰 발급 구조에 실제로 등장하는 조합은 무엇인지 고르고, 어디에서 등장하는지 근거를 들어 설명하라.** + +#### ① 동기 / 블로킹 + +**위치**: API Server에서 요청 검증 시 (로그인 여부, 이벤트 시간 확인) +API Server는 요청을 받아 Redis나 DB에서 이벤트 정보를 조회할 때, 응답이 올 때까지 대기하고 결과를 같은 흐름에서 처리한다. 또한, DB에 PENDING 상태를 저장할 때도 저장 완료 응답을 받아야 다음 단계인 Queue 발행으로 넘어가므로 동기/블로킹이다. + +#### ② 비동기 / 논블로킹 + +**위치**: API Server가 Queue에 메시지를 발행한 뒤 즉시 Client에게 접수 완료 응답을 반환하는 구조 +API Server의 요청 처리 흐름과 Worker의 쿠폰 발급 처리 흐름이 분리되어 있고, API Server는 Worker 결과를 기다리지 않고 바로 응답을 반환한다. + + +#### ③ 비동기 / 블로킹 (나쁜 구조) + +**위치**: 과제 2에서 다룬 구조 A — API Server가 Queue에 메시지를 넣고 Worker 처리 결과를 기다리는 구조 +처리 흐름은 분리되어 있지만, API Server 스레드가 Worker 결과를 기다리며 블로킹된다. Queue를 써도 비동기 장점이 줄어드는 나쁜 구조이다. +