URL 단축 서비스 시스템 디자인 및 스케일링 질문있습니다.

안녕하세요. 답변이 늦어 죄송합니다.좋은 질문을 해주셔서 감사합니다. 먼저 트래픽을 줄일 수 있다는 것은 userId 를 partition key 로 사용하면, 데이터 베이스의 쓰기 및 읽기 트래픽이 사용자별로 분산될 수 있습니다. 예를 들어서, 사용자가 URL 을 생성할 때, 데이터 베이스는 해당 사용자의 userId 가 속한 파티션에서만 데이터를 저장합니다. 동일한 사용자가 생성한 URL 을 관리하거나 조회할 때 해당 사용자의 파티션만 조회하면 되기 때문에 다른 파티션에 영향을 주지 않을 수 있습니다. 그래서 결론적으로는 사용자 단위로 데이터와 트래픽이 분산되고, 특정 사용자에 대한 트래픽이 다른 사용자에게 영향을 주지 않아서 전체 시스템의 부하가 줄어드는 효율성이 있습니다. 모든 방문객을 scan 해야 한다는 의미는 URL 단축 서비스의 방문자는 userId를 모른다는 점 입니다. URL 단축 서비스를 사용할 때, 대부분의 방문자는 단축 URL 만 알고 있고, 해당 URL 이 어느 사용자의 userId 에 속해 있는지 알 수 없습니다. 그래서 단축 URL 조회 요청이 생기면, 데이터베이스는 모든 파티션을 검색하여 해당 URL 의 데이터를 찾아야 합니다. 이 과정을 all partition scan 으로 정의하였습니다. 예를 들면, short.ly/inflearn 을 조회 요청했을 때 이 URL 이 어느 사용자 userId 의 파티션에 저장되어 있는지 알 수 없기 때문에 모든 파티션을 검색해야 하고 이 과정은 비효율적입니다. 결론적으로 파티션이 많아질수록 조회 작업의 성능은 점점 더 저하됩니다. 또한 이 과정이 더 큰 병목현상을 일으킬 수 있다는 점을 고려하여야 합니다. Partition key 를 userId 로 사용하는 목적입니다. 특정 사용자가 URL 을 생성하거나 자신의 URL 을 확인 , 삭제하는 작업은 해당 사용자의 파티션에서만 이루어지기 때문에 효율적 입니다. 이렇게 되면, 한 사용자와 관련된 작업은 다른 사용자와 무관하게 수행되어서 성능이 향상됩니다. 하지만 방문자를 고려하지 않은 설계는 단축 URL 서비스 빠른 리다이렉션 기능에 악영향을 미칠 수 있습니다. 결론적으로 이를 해결하기 위해 캐싱을 도입하거나 userId 와 URL 의 해시값을 조합한 키를 사용하여 데이터베이스 파티션을 설계 합니다. 결론적으로, URL 을 생성하고 관리하는 사용자의 성능을 높이기 위한 설계 방식이며, 방문자를 고려한 추가적인 보완책이 필요하다는 점을 고려해야 합니다.

예시 두개가 납득이 잘 가지않네요 ㅠㅠ

좋은 질문을 주셔서 감사합니다, 목동개발자님. 말씀하신 포인트가 맞습니다. 응답을 바로 반환해야 하는 경우, 메시지 큐를 사용하면 불필요한 홉이 생겨 응답 속도가 느려질 수 있습니다.다만, 메시지 큐는 비동기 처리가 필요하거나 리소스 분리가 필요한 상황에서 특히 유용합니다. 즉각적인 응답이 요구되지 않거나, 시스템 간 작업을 독립적으로 처리할 필요가 있을 때 큐를 사용하는 것이 적합할 수 있습니다. 또한, 큐는 재시도 메커니즘을 지원하고, 대규모 시스템에서의 안정성을 높이는 장점이 있습니다. 이런 이유로 저 같은 경우에는 예시 1에서는 메시지 큐를 적용하여 자료에 반영했습니다.User -> Message Queue -> OrderService 이러한 구조에서 사용자가 OrderService에 요청을 보낼 때, 메시지 큐를 거쳐야 하는 구조는 불필요한 네트워크 홉을 추가하고 실시간 응답 속도를 저하시킬 수 있습니다. 이러한 사용자-facing 서비스에는 메시지 큐가 적합하지 않을 수 있습니다. 즉, 실시간으로 응답이 필요한 상호작용에서는 큐가 불필요한 지연을 초래할 수 있습니다.OrderService -> 내부 시스템: 반면, OrderService가 Analytics, Fulfillment System, Email Notification Service와 같은 비동기 작업을 수행할 때는 메시지 큐가 유용합니다. 이 과정에서는 즉각적인 응답이 요구되지 않으며, 메시지 큐를 통해 비동기로 처리할 수 있어 시스템 간 결합도를 낮추고 확장성 및 안정성을 높일 수 있습니다.사용자-facing 부분과 비동기 백그라운드 작업을 구분해 메시지 큐를 적절히 사용하는 것이 중요하다는 점을 자료에서 설명하려고 했는데 설명이 부족했던 것 같습니다. 죄송합니다. 예시 2에서도 좋은 관점에서 질문을 주셨습니다. 수강생 분들이 배울 수 있는 부분이 될 것 같습니다. 예시 2의 시나리오는 사용자가 "piano cat"을 검색할 때, Google 서버는 데이터베이스에서 가장 관련성 높은 10개의 결과를 조회해야 합니다. 그리고, 트래픽이 갑자기 증가하여 초당 약 100만 건의 요청이 발생하고, 이로 인해 서버가 모든 요청에 즉각적으로 응답하기 어려운 상황이 됩니다. 이때 메시지 큐를 사용하여 각 검색 요청을 큐에 넣고 순차적으로 처리하는 방식으로 부하를 관리하려고 하는 것을 나타내었습니다.이 구조에서 여러 요청을 동시에 받아 순차적으로 처리하면 서버의 과부하를 방지할 수 있으며, Google Server가 다른 작업을 처리할 여유도 확보할 수 있습니다. 또한, 서버가 다운되거나 장애가 발생하더라도 큐에 요청이 남아 있어 복구 후에도 처리가 가능합니다.그러나, 목동개발자님께서 말씀하신 것처럼 사용자는 큐에 요청이 쌓일수록 대기 시간이 길어져, 실시간 검색 요청에서는 불편함을 느낄 수 있습니다. 100만 건의 요청이 쌓이면 상당한 지연이 발생할 수 있습니다.따라서, 실시간 응답 요구에 부적합 하다고 할 수 있습니다. 이 방식은 트래픽 급증 시 서버를 보호할 수 있지만, 사용자 경험이 중요한 실시간 검색 서비스에서는 적합하지 않을 수 있습니다.따라서, 메시지 큐가 트래픽 급증 시 서버 부하를 관리하는 데 유용하다는 점을 보여드리고 있지만, 실시간성을 요구하는 서비스에서는 캐시나 분산 시스템과의 조합이 필요하다는 점을 이해하실 수 있도록 구성하고자 했습니다. 좋은 관점에서의, 수강생분들께 도움이 되는 포인트의 질문 해주셔서 감사합니다. 그리고, 다시 한번 저의 설명이 부족했던 점 사과의 말씀드리며, 추후 강의 자료에서 보충하도록 하겠습니다.

강의자료는 제공 불가능할까요?

안녕하세요 목동개발자님, 열정적인 학습 감사드립니다. 제가 사실 현재 미국 빅테크 기업과의 최종 면접을 위해일정이 바쁜 상황에 있어서, 늦어도 11월 말까지 강의 자료를 제공 해드릴 예정입니다. 양해를 구하며 항상 좋은 하루 되시길 바랍니다! 다시 한번 감사드립니다.

General Service 서비스 컴포넌트 관련 질문있습니다!

좋은 관점의 질문입니다. 제가 강의에서 명확하게 설명드리지 못한 부분인 것 같습니다. 먼저 MSA(마이크로서비스 아키텍처)에서는 API 게이트웨이와 로드 밸런서가 모두 중요한 역할을 합니다. 강의에서 게이트웨이를 모놀리식 아키텍처에만 적용 가능하다고 설명한 부분이 있었다면, 이것은 의도하지 않은 오해일 수 있습니다. 사실, API 게이트웨이는 MSA에서도 매우 흔하게 사용됩니다.게이트웨이는 MSA에서도 클라이언트의 진입점으로서, 다양한 마이크로서비스로 요청을 라우팅하고 보안, 인증, 트래픽 관리 등의 여러 기능을 제공합니다. 또한, 로드 밸런서는 동일한 서비스 인스턴스들 간에 트래픽을 분산시키는 역할을 하죠. 즉, MSA에서는 API 게이트웨이가 상위에 위치하고, 각 서비스 인스턴스에 대한 트래픽을 분배할 때 로드 밸런서가 사용될 수 있습니다.그리고, 게이트웨이와 로드 밸런서는 그 기능과 목적이 다릅니다. API 게이트웨이는 트래픽을 여러 마이크로서비스로 라우팅하는 중간 브로커 역할을 하며, 로드 밸런서는 특정 마이크로서비스의 여러 인스턴스 사이에서 트래픽을 분배하는 역할을 합니다.하지만, 요즘에는 게이트웨이에서 로드 밸런싱 기능이 통합되어 제공되는 경우도 많습니다. 예를 들어, Nginx나 AWS API Gateway 같은 서비스들은 게이트웨이 기능과 함께 기본적인 로드 밸런싱도 수행할 수 있습니다. 그래서 때로는 두 개념이 겹치기도 하지만, 여전히 그 목적과 역할은 다르다고 볼 수 있습니다. 제가 강의에서 이 부분이 조금 더 명확하게 전달될 필요가 있었을 것 같네요. 앞으로 수정하거나 보완하는 데 참고하겠습니다.

영화 DVD 대여 시스템 데이터베이스 스키마 설계에 대한 질문입니다.

혼란을 드려 죄송합니다. 좋은 질문입니다.먼저 Rentals 테이블에 items_id가 컬럼으로 추가된 이유는, 개별 재고 관리는 강의 설계 범위에서 제외되었기 때문이며, 검색 성능을 향상시키기 위해 이 컬럼에 인덱스를 적용하기 위함입니다.items_id를 컬럼으로 추가하면 어떤 고객이 어떤 종류의 아이템을 대여했는지 알 수 있지만, 개별 재고 관리까지는 추적하지 않습니다.하지만 개별 아이템의 상태 및 재고 관리가 필요하다면 inventory 테이블의 id인 inventory_id를 사용하는 것이 좋습니다. 이를 통해 각 개별 아이템 재고를 추적하고 관리할 수 있습니다.따라서 두 설계 모두 맞지만, 추후 어떤 기능과 범위로 시스템을 설계할지에 따라 선택이 달라질 수 있습니다. 질문자님의 생각도 맞습니다 🙂

메세지 큐 예제 2번 질문있습니다!!

먼저, 메시지 큐는 요청을 저장하고 순서대로 전달하는 역할을 하지만, 일반적으로 큐가 직접 소비자에게 메시지를 전달하는 것이 아니라, 소비자가 큐에서 메시지를 가져와서 처리하는 방식입니다."Piano cat" 검색 요청을 Google 서버에서 받아서, 이 요청을 메시지 큐에 넣어 대기열에 추가합니다. 그 후, 메시지 큐로부터 Results Store가 해당 요청을 가져옵니다. Results Store에서는 데이터베이스 조회, 인덱싱 등의 알고리즘을 사용하여 실제 검색 작업을 수행합니다. 이렇게 처리된 결과를 Results Store에서 Google 서버로 반환하는데, 별도의 응답 메시지 큐를 추가해서 구성을 해서 Google 서버가 그 큐에서 결과를 가져오도록 할 수 있습니다. 하지만 응답 메시지큐를 별도로 추가하게 되면 비동기 처리에 효율적이지만, 시스템 복잡성이 증가할 수 있습니다. 그리고 메시지 큐 없이 직접 Google 서버로 결과를 반환한다면, Results Store에서 Google 서버의 RESTful API 엔드포인트로 전달 하거나 RPC 등을 통해 결과를 Google 서버에 전달할 수 있습니다. RESTful API 엔드포인트로 전달 예시를 코드로 직접 보여드리기 위해 첨부합니다.api_endpoint = 'http://localhost:5000/api/search_results' response = requests.post(api_endpoint, json={'query': search_query, 'results': search_results}) if response.status_code == 200: print(f"결과를 성공적으로 전달했습니다: {search_results}") else: print("결과 전달에 실패했습니다.")이러한 과정을 통해 Google 서버는 사용자에게 응답을 반환하게 됩니다. 이러한 시스템 구성을 통해 모듈화, 확장성이 향상되며, 각 시스템 컴포넌트가 독립적으로 작업을 수행할 수 있습니다. 또한 로드 밸런싱 및 장애 처리에도 유리한 구조가 될 수 있습니다. 강의 열심히 들어주셔서 감사합니다. 언제든지 질문 올려주세요! 다만, 미국 캘리포니아 서부에 살고 있어서 답이 느릴 수 있습니다.