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를 사용하는 것이 좋습니다. 이를 통해 각 개별 아이템 재고를 추적하고 관리할 수 있습니다.따라서 두 설계 모두 맞지만, 추후 어떤 기능과 범위로 시스템을 설계할지에 따라 선택이 달라질 수 있습니다. 질문자님의 생각도 맞습니다 🙂