AP 시스템이 전자상거래에 적용될 수 있는 이유

안녕하세요 한재현님, 수강 감사드리며, 좋은 포인트를 짚어주셨습니다.전 세계 사용자에게 끊김 없는 경험을 제공하기 위해 전자상거래 사이트는 전 세계에 흩어진 수많은 고객에게 빠른 페이지 응답을 보장해야 합니다. 네트워크 지연이나 일부 서버 장애가 발생해도 “읽기, 쓰기 요청을 계속 받아들이는” AP 계열 데이터베이스, 예를 들어 DynamoDB 같은 시스템은 글로벌 쇼핑몰의 요구사항과 잘 맞습니다. 왜냐하면, 즉시 완벽한 일관성이 아니어도 되는 영역이 많아서 물론 결제나 주문 확정 같은 부분은 강한 일관성이 필요하지만, 상품 상세 조회나 장바구니처럼 “약간의 지연”이 사용자에게 큰 불편을 주지 않는 경우가 많습니다. 예컨대 재고 수량이 실제보다 몇 초 늦게 업데이트돼도, 고객 경험에는 크게 영향을 주지 않죠. 그렇기 때문에, 이런 영역은 AP 모델의 ‘최종 일관성’을 받아들이고, 백그라운드 동기화로 데이터를 맞춰 갈 수 있습니다.중요한 트랜잭션은 보강해서 처리할 수 있다는 점은 DynamoDB에도 트랜잭션 기능이 있어서, 결제나 주문 확정과 같이 “절대 놓칠 수 없는” 작업은 CP처럼 처리하도록 설계할 수 있습니다. 즉, 전체 서비스는 AP로 운영하면서도, 민감한 도메인에서는 트랜잭션을 걸어 강한 일관성을 확보하는 하이브리드 구조를 만드는 것이 가능합니다.감사합니다. 좋은 하루 되세요!

채팅을 영속할 DB로 RDB를 선택한 이유도 궁금합니다

안녕하세요. 목동 개발자님좋은 질문을 해주셨습니다.채팅 데이터를 영속화하는 데 RDB를 선택한 이유는, 채팅 시스템에서 메시지와 사용자, 타임스탬프 같은 데이터가 명확한 구조를 가지기 때문입니다. RDB는 이런 구조화된 데이터를 테이블로 관리하기 쉽고, 메시지 전송 순서나 사용자간의 관계를 정확하게 보장하는 데 유리합니다. 예를 들면, 메시지 ID, 발신자, 수신자, 전송 시간을 하나의 레코드로 저장하면서 데이터 무결성을 유지할 수 있습니다.또한, RDB는 ACID(원자성, 일관성, 격리성, 지속성) 속성을 지원해 메시지 전송 중 오류가 발생해도 데이터가 손상되지 않도록 보장합니다. 예를 들어, 메시지를 보내는 동시에 읽음 상태를 업데이트하는 작업을 트랜잭션으로 묶을 수 있습니다.쿼리 효율성도 중요한데, RDB는 조인(JOIN)을 통해 사용자, 채팅방, 메시지 간 관계를 효율적으로 조회할 수 있습니다. 예를 들어, 특정 그룹의 모든 메시지를 시간순으로 가져오거나 특정 사용자가 받은 메시지만 필터링하는 작업이 용이합니다.실제 사례를 보면, WhatsApp은 초기 아키텍처에서 MySQL 같은 RDB를 사용했으며, Slack도 MySQL을 사용해 데이터 저장을 관리했습니다참고 링크: (https://slack.engineering/scaling-datastores-at-slack-with-vitess/)질문에서 채팅은 강결합 트랜잭션이 불필요해 보인다고 언급해주셨는데, 이는 부분적으로 공감할 수 있습니다. NoSQL은 확장성과 유연성이 뛰어나 대규모 분산 시스템에 강점이 있습니다. 하지만 채팅 시스템에서는 단순히 메시지를 저장하는 것뿐 아니라, 읽음 상태 업데이트, 그룹 채팅 멤버 관리 등 데이터 일관성이 중요한 작업이 있습니다.RDB는 이런 경우 트랜잭션을 통해 안정적으로 처리할 수 있지만, NoSQL은 기본적으로 eventual consistency(최종 일관성)를 제공하는 경우가 많아 실시간성이 중요한 채팅에서 일시적인 데이터 불일치가 발생할 수 있습니다. 예를 들어, 메시지가 한 사용자에게는 표시되었지만 다른 사용자에게는 아직 반영되지 않은 상황이 생길 수 있습니다.또한, RDB는 관계형 데이터 모델을 통해 복잡한 쿼리와 데이터 관계를 효율적으로 처리할 수 있어, 채팅 앱의 초기 설계와 유지보수에서 유리합니다. NoSQL은 대규모 데이터와 비구조화된 데이터에 강하지만, 채팅 데이터의 특성과 초기 설계의 단순함을 고려할 때 RDB가 더 적합할 수 있습니다.실제 사례에서, WhatsApp은 초기에는 RDB를 사용했으며, 이후 규모가 커지면서 Mnesia 같은 분산 데이터베이스를 도입했지만, 이는 RDB의 한계를 보완하기 위한 보조적인 선택이었습니다아래 이미지와 링크를 통해 해당 내용을 참고하실 수 있습니다!(사진)https://www.cometchat.com/blog/whatsapps-architecture-and-system-design좋은 하루 되세요!

URL 단축 서비스에서 redis counter를 사용하는 이유가 무엇인지 궁금합니다.

안녕하세요 방구석효행뜽님, 먼저 수강 해주신 것에 감사드립니다. 아주 좋은 질문을 해주셨습니다. 먼저 Redis Counter를 사용하는 이유는 URL 단축 서비스에서 사용되는 고유한 id 를 생성하기 위함입니다. URL 단축 서비스의 핵심은 긴 URL 을 짧고 고유한 Short URL 로 변환하는 것에 있습니다. 또한 쓰기(URL 생성) 작업에 대한 확장성과 빠른 퍼포먼스를 보여줄 수 있습니다.이 과정에서 중복되지 않는 키를 빠르고 효율적으로 만들어야 하기 때문에 메모리 기반의 고성능 데이터 저장소인 Redis Counter를 기반으로 INCR 명령어를 통해 카운터를 증가 시켜 고유한 id 값을 생성하게 됩니다. 따라서 Redis Counter 가 제공하는 증가되는 숫자 (예시, 1, 2,3 ...) 를 기반으로 Short URL 을 생성하게 되는데 데이터 흐름을 보면 아래와 같습니다. Short URL 생성Redis Counter 증가DB에 저장캐시 업데이트이 과정에서 사용자가 긴 URL(예: https://example.com/very/long/url 을 단축하려고 요청하면, 시스템은 고유한 short URL(예: https://short.url/g8)을 생성해야 합니다.Redis counter는 여기서 고유한 숫자 값을 제공합니다. 예를 들어, INCR counter 명령을 실행하면 현재 값이 1000에서 1001로 증가합니다.이 값(1001)을 기반으로 short URL의 키를 만듭니다. 흔히 Base62 인코딩(0-9, a-z, A-Z를 사용한 62진법)을 사용해 숫자를 짧은 문자열로 변환합니다. 예를 들어, 1001은 g8로 변환될 수 있습니다.Counter 값 1000 → Base62로 변환 → g8 → https://short.url/g8Counter 값 1001 → Base62로 변환 → g9 → https://short.url/g9결과적으로 https://short.url/g8 같은 short URL이 생성됩니다.그리고 질문에서 "Redis counter를 증가시키고 short URL을 생성한다"는 순서가 반대일 수도 있다고 하셨는데, 보통은 counter를 증가시키는 게 먼저고 그 값을 사용해 short URL을 만듭니다. 하지만 시나리오상 순서가 바뀌어도 결과는 동일합니다. 그리고 말씀하신대로 "100억 개 URL limit을 체크하기 위함이 합리적일 것 같다"고 하신 추측도 타당합니다. 예를 들어, counter가 10,000,000,000(100억)에 도달하면 시스템이 더 이상 새로운 URL을 생성하지 않도록 제한할 수 있습니다.하지만 이건 주로 모니터링 목적입니다. 실제 URL 생성 로직 자체는 counter 값이 100억을 넘어도 계속 동작할 수 있고, 100억 제한은 시스템 설계상 의도된 한계일 뿐입니다. 따라서, 100억 URL 제한: Redis counter로 생성된 URL 수를 모니터링해 한도를 체크할 수 있지만, 생성 로직과 DB 저장에는 직접 영향을 주지 않습니다. 감사합니다. 좋은 질문을 해주셔서 감사드리며 좋은 하루 되세요

Celery worker 튜닝을 통한 성능 개선 부분 질문

안녕하세요. HanKyul Kim 님 수강 감사드립니다.아주 좋은 질문을 해주셨습니다.확인해보니, worker 수를 10개 -> 15개 -> 9개로 조정했을 때 8~9초에서 개선이 미미한 이유는 태스크가 너무 가볍고, 태스크 자체의 실행 시간이 짧아서 worker 간 병렬 처리의 이점이 두드러지지 않을 수 있습니다.브로커(RabbitMQ)나 결과 백엔드(RPC)의 오버헤드가 더 큰 영향을 미쳤을 가능성이 높아요. 지금 태스크는 단순 문자열 반환이라 worker 수를 늘려도 병렬 처리 이득이 크지 않고, worker_prefetch_multiplier=9로 설정된 상태에서 태스크 예약과 통신 비용이 병목일 수 있습니다.이 값은 각 worker가 한 번에 미리 가져오는 태스크 수를 의미해요. worker가 10개라면 최대 90개의 태스크를 동시에 예약할 수 있고, 15개라면 135개까지 가능합니다. 하지만 태스크가 10,000개로 충분히 많더라도, prefetch로 인해 worker가 태스크를 과도하게 예약하면 브로커(RabbitMQ)와 worker 간 통신 오버헤드가 늘어나 성능 개선이 제한될 수 있습니다.또한, worker 수를 10개 -> 15개로 늘렸을 때, 시스템의 CPU 코어 수를 초과하거나 메모리 사용량이 포화 상태에 가까워졌다면, 추가 worker가 오히려 컨텍스트 스위칭 비용을 늘릴 수 있어요. 반대로 9개로 줄였을 때도 태스크가 워낙 가볍고 빠르게 끝나서 리소스 활용도가 이미 최적화된 상태일 가능성이 있습니다.테스트로 현실적이 부하를 일으킬 수 있는time.sleep(0.02)를 넣거나, prefetch 값을 1~4로 낮춰보시고, CPU 코어 수에 맞춰 worker 수를 조정해보세요. 그리고 나서 celery -A app worker -l info 로 실행 후 로그를 확인하면 리소스 활용도를 파악하실 수 있습니다. 추가 질문 있으면 언제든 말씀해주세요!수강 감사드립니다.항상 좋은 강의가 되도록 하겠습니다.

섹션1 Array 강의 default value 질문

좋은 질문 감사드립니다. 제가 혼동을 드려 죄송한 말씀드립니다.default value 는 변수 초기화 값을 의미한 것입니다.감사합니다.

노션 사용권한 이슈 문의 드립니다.

다시 링크 수정했습니다 ☺감사합니다

선생님 강의 노트 수정 막으셔야 할 것 같습니다

안녕하세요 강의 노트 코멘트 감사합니다😊편집이 되지만 링크로 다시 접속 하셨을때는 Replace my content 버튼으로 다시 원래대로 되시는 것을 보실 수 있을겁니다수정하실 수 있는게 정상입니다! 감사합니다 ☺

long url을 파티션키로 지정했을때 장점이 생각 안나네요 ㅎㅎ;;

안녕하세요. 좋은 질문 감사드립니다.강의에서 언급했던 Traffic distribution 의 경우에는 단순히 short URL 조회 트래픽뿐만 아니라,short URL을 생성할 때 발생하는 트래픽을 포함하는 개념이라고 할 수 있습니다.보통 URL 단축 시스템은 크게 두 가지 주요 트래픽 유형을 가집니다.Read-heavy 트래픽이 발생하는 유형 (Short URL -> Long URL 조회)대부분의 사용자는 shortURL 을 입력했을 때 Long URL 로 리다이렉션 됩니다. 이 경우에는 Short URL 을 기준으로 파티션을 나누는 것이 효율적 입니다. Write-heavy 트래픽이 발생하는 유형 (Long URL -> Short URL 변환)사용자가 새로운 short URL을 생성할 때, 보통은 해당 Long URL이 이미 존재하는지 체크하는 경우가 많습니다. 이때, Long URL을 파티션 키로 하면 동일한 URL이 하나의 파티션에 저장되므로 검색 속도를 최적화할 수 있음.즉, 트래픽 분배라는 것은 데이터 읽기 Read 트래픽만이 아니라, 데이터 쓰기에 대한 부하도 고려해야 한다는 것이기 때문에 특정 유저가 대량의 URL을 만들거나, 특정 URL 도메인 (예: https://youtube.com/...) 에 집중된 트래픽이 발생하는 경우, Long URL을 기반으로 분산하면 특정 파티션으로 몰리는 현상을 줄일 수 있습니다. 그래서 Traffic distribution 이 Pros 중의 하나가 될 수 있습니다.

실제 인터뷰에서도 Object Oriented Design 을 이런 과정으로 하는걸까요?

네 제가 스페이스X 인터뷰 했던 경험에 의해서 말씀드리면 실제로 존재하는 하드웨어 시스템에 들어갈 소프트웨어를 설계하는 부분에 대한 문제로 객체 모델 설계와 데이터베이스 테이블 그리고 구현되어야 하는 기능들에 대해서 알고리즘으로 구현하도록 했었습니다. 참고로 국내 같은 경우 제가 미국에 있는동안 국내 토스, 당근, 배민 등의 기업 서류를 통과하고 인터뷰를 해 본 결과 토스 같은 경우는 시스템 디자인에 대해 질문을 했었습니다.

able to get all students who got a "d+" grade or lower 요구사항

안녕하세요, 좋은 질문 주셔서 감사합니다! 네 enrollments 테이블과 참조 관계를 설정하시거나, 성적 데이터를 독립적으로 관리할 별도 Grades 테이블 생성하는 방법을 고려하실 수 있을 것 같습니다 😊