Hong

안녕하세요 에어님 피드백주셔서 감사합니다.제가 깜빡한 부분이 있나보네요. 강의 소개 수정하도록 하겠습니다.&nbsp;좋은 하루 보내시고 설 명절 푹 쉬시길 바라겠습니다!! 감사합니다!!

강의 언어

오 좋은 피드백 감사합니다. KRaft 모드도 굉장히 각광받고 있죠 시간이 될 떄 한번 다루어 보도록 하겠습니다.&nbsp;감사합니다.

Zookeeper vs KRaft 모드

안녕하세요 slow님 질문 주셔서 감사합니다.&nbsp;그건 당연한겁니다!! 생각하신 방향이 맞습니다. 저는 어느정도 코드의 깔끔한 구조를 추구했기 보다는 편의를 추구해서 저런 방식으로 구현한 바가 있습니다.&nbsp;누구나 코드를 보면 해당 핸들러를 중복 호출 할 떄, 문제가 발생할 수 있다는것은 안다고 생각했기 떄문에 그 부분에 대해서는 크게 고려를 하는편은 아닌거 같아요.&nbsp;하지만 slow님이 그런 부분까지 고민을 하는 개발자라면, 그런 부분도 보완해서 코드를 구현하시면 좋지 않을까싶습니다.<ul><li>저는 Spring이나 Java를 그렇게 좋아하지는 않아서... 뭔가 좀 틀에 맞춰 작성하는걸 많이 좋아하는 편은 아닙니다... ㅎㅎ 그래서 해당 코드도 저런 방식으로 구현이 되어 있네요.</li></ul>&nbsp;감사합니다!&nbsp;

RedisMessageBroker.kt setLocalMessageHandler 관련 문의

안녕하세요 swm.3idiots님 질문 남겨주셔서 감사합니다.&nbsp;질문 1)수업 자료가 많다보니 관리가 일부 미흡한 부분이 있는거 같네요. 기본적인 기준은 질문자님이 주신 부분이 맞습니다. SPOF라는 관점이 틀린건 아니에요.&nbsp;근데 저희가 정의대로 구현하는 케이스가 생각보다 많이 없습니다. 상황에 따라서 이 방식이 더 효과적이면 정의에서 좀 벗어난 방식을 적용하는 경우들이 많아요. 그만큼 실무는 많이 다르기 떄문입니다.&nbsp;그래서 어느정도 실무에서 쓰는 가장 일반적인 패턴을 좀 보여드린거 같습니다. 생각보다 오케스트레이션이라는 패턴이 하나의 서비스에서 모두 관리하는 케이스는 많이 보지 못한거같아요.<ul><li>물론 그런 케이스가 나쁘다는건 아닙니다.</li></ul>&nbsp;그래서 정의대로라면 SPOF의 관점이 맞지만, 현실적으로는 저런식으로 구현을 많이 한다고 너그롭게 봐주시면 감사하겠습니다.&nbsp;질문 2)맞아요. 기본적으로 목표하는바는 똑같습니다. 시나리오나 보상처리 시스템이 달라지면 안되기 떄문이에요.&nbsp;단지 이 두 패턴의 차이는 어떻게 호출이되고 굴러가냐의 차이인거지 당연하게도 기본적으로 보장해줘야하는것들은 보장해줘야합니다. 특정 패턴이라고 이 방식은 도입하지 않아도 된다가 아닙니다.&nbsp;결국 우리가 A라는 기능을 구현할 떄, 어떤 방식으로 A라는 기능을 구현하는것이 중요한지라는 방식으로 이해하시면 좋을꺼같아요.&nbsp;단순하게 DB에서 데이터를 가져와서 뿌려주는 방식도 있을거고, 아니면 트래픽 특성을 고려해서 데이터를 미리 캐싱 처리 할 수 있는 방식도 있겠죠.&nbsp;이와 같은겁니다. 기능을 구현하는데에 있어서 어떤 방식으로 내가 구현을 하는게 좋을지가 중요한거고, 이 SAGA라는 패턴에서도 이 두가지 패턴들을 대중적으로 사용해서 구현을 하는거라고 봐주시면 되는겁니다.&nbsp;감사합니다.

23강 예제 질문입니다! (서비스 1 > 2 > 3 호출 시나리오 관련)

네 이찬민님 질문 감사합니다.&nbsp;<ol><li>String Set 방식의 의미</li></ol>네 우선 틀린말은 아닙니다. 유저의 고유 키마다 쿠폰 Set이 존재 할 수 있고, 이를 통해서 어떤 쿠폰을 발급받았는지 저장하는 구조가 되거나, 아니면 하나의 서비스가 런칭되었을 떄 쿠폰을 포괄적으로 저장하고 그 값들을 Set으로 관리 할 수 있겠죠&nbsp;둘다 가능합니다. 일단 기본적으로 유저의 고유 키마다 쿠폰 Set이 있다고 가정해 볼게요. 이 방식은 유저 수가 많아지면 당연하게도 각 유저마다 키가 생성되고 쿠폰 ID를 문자열로 저장하기 떄문에 메모리 사용량이 많아지는 구조가 될 겁니다. 근데 이걸 비트맵으로 기준을 잡을 수 있다면 쿠폰 기준으로 키를 만들고 유저 발급 여부를 1비트로 표현 할 수 있어서 메모리 관리 측면에서는 훨씬 효율이 좋은거죠&nbsp;<ol start="2"><li>Redis 사용 이유와 저장 방식</li></ol>일단 관점은 일시적인 서비스라는 관점입니다. 당연하게도 영속성이 유지가 되어야한다면 DB에 넣는것이 안전할거에요. 하지만 일부 Latency를 위해서 Redis를 InMemory DB로 사용하는 케이스도 존재합니다.현실적으로 실무에서는 Redis와 DB 둘 다 저장을 하게 될 겁니다. 일종의 Redis는 특정 이벤트 기간동안 중복 체크용으로 둘 수가 있고, DB는 영구적인 기록과 쿠폰 사용 이력을 관리 할 수 있겠죠&nbsp;<ol start="3"><li>쿠폰 번호 관리</li></ol>뭐 상황에 따라 다르겠지만 구현하는 방식에 따라 달라요. 유저마다 다른 고유 쿠폰 코드를 발급한다고 가정해볼게요. 같은 "5000원 할인 쿠폰"이지만, 유저마다 특정 고유 코드를 부여하는거죠.이 과정에서 Redis 비트맵이 사용이된다면 쿠폰 타입 단위로 "이 타입의 쿠폰을 이미 받았는지"를 체크하는 용도로 사용이 될 수 있는거죠.&nbsp;혹시 어느정도 이해가 되셨을까요?? 사실 구현 방식이 현실적으로 상황에 다르다보니깐.... 막 정의내리기 힘들기는 하지만 각각 상황에 따라서 어울리는 관점으로 구현하시면 되는거고 그 상황에서 선택 할 수 있는 선택지가 비트맵 or Set이라고 봐주시면 됩니다.&nbsp;&nbsp;

비트맵 자료구조 관련 질문

안녕하세요 영준님!! 영준님의 여정에 먼저 힘내시기를 바라겠습니다!! ㅎㅎ &nbsp;우선적으로 해당 강의는 분산환경을 고려하는데에 있어서 참고하시면 좋을만한 주제들을 선정해서 하나하나 다루고 있습니다. 무언가 하나의 프로젝트를 구성한다는 개념이 아니라 여러분들이 이런 부분을 고려해서 개발을 하면 좋다는 내용을 담고 있어요.&nbsp;그래서 사실상 그렇게 순서는 상관이 없는걸로 보입니다. <ul><li>해당 강의 기준에서요!!</li></ul>&nbsp;또한 제 다른 강의들에 대한 순서 질문을 주신거라면, 저는 일단 해당 강의를 수강하고, 해당 강의에서 추가적으로 궁금한 부분을 직접 구현하고 테스트하는 주제들을 따로 들으시는것을 추천드려요.&nbsp;아무래도 분산 환경이라는 관점이 너무나도 다양한 문제와 주제들이 있기 떄문에 무언가 순서를 지켜가면서 들으시라고 할 수는 없을꺼 같습니다. 얼마나 잘 알고, 어디까지 알고 있냐가 이 분산환경에서의 가장 중요한 요소인거 같아요.<ul><li>아무래도 아무것도 모르면 대응도 안되고 개발도 어렵기 떄문이죠. 잘 몰라도 어느정도라도 안다면 추후에 학습 할 수 있다는 기회는 있잖아요?? 그런 관점입니다.</li></ul>&nbsp;그래서 정리를 하자면, 순서는 상관없습니다. 영준님의 실력이 어느정도인지는 제가 잘 모르겠지만, 어느정도 모놀리틱, 모놀리식 형태에 익숙하셨다면, 그 다음에는 멀티 모듈 구조 -> 간단한 프로젝트 -> MSA 과정으로 넘어가면 좋지 않을까 싶습니다.<ul><li>바로 처음부터 "나는 MSA를 할꺼야!! 이게 좋다며!!" 이건 절대 틀린 방식입니다. 상황에 따라 사용하는 방식의 차이를 알아야 해요</li></ul>&nbsp;혹시 제가 질문주신 부분에 대해서 올바르게 답변했는지 검토 부탁드리고. 좋은 하루 보내시길 바라겠습니다!!

강의 순서

1) stateless 요청에서 상태값의 전달 관련 해당 질문에 대해서는 우선적으로 고민하고 말씀해주신 부분이 일단 맞습니다. 가장 일반적으로 사용 할 수 있는 패턴이에요.&nbsp;이떄 중요한거는 ID를 기반으로 값을 다시 요청하거나 주기적으로 요청을 함으로써 상태를 계속해서 확인하는거죠. 이 기반을 구현할떄는 세가지 방식이 있을 겁니다.&nbsp;첫번쨰는 Polling 입니다. 가장 단순한 형태죠. 예를들어서 1~2초마다 계속 서버에 값을 요청하는 형태가 될 겁니다. 그걸로 Clinet의 State 변경을 인지하는거고요.&nbsp;두번쨰는 Socket이 있을꺼에요. 가장 효율적인 형태지만, 인프라 복잡도나 상태 관리가 어려울수는 있죠.&nbsp;세번쨰로는 Long Polling이 존재할겁니다. 사실상 Polling과 동일하죠.&nbsp;이떄 중간 상태값은 음... 어떤 관점을 보시냐에 따라 다르기는 한데, 말씀해주신 부분처럼 Redis나 DB에 저장을 하는것이 가장 안전합니다. 근데 일부 유실되어도 무방한 트래픽이라면 그냥 메모리에서 관리해도 괜찮다고 생각을 하는편이고요.&nbsp;<h3 style="text-align: left">2) 메시지 브로커(카프카) 를 쓸 때 고려사항</h3>CDC라는 개념도 알고 계시다니 대단하시네요 ㅎㅎ 우선 메시지 발행의 정확성을 위해서 CDC를 설정한다는 것이 무슨 뜻인지 모르겠는데, DB에 대한 상태 변경을 인지하고 이벤트화를 하는 기능을 CDC라고 합니다. 레플리카 개념을 따라가는거죠.&nbsp;근데 CDC를 사용하지 못한다면.... Transactional Outbox 패턴을 따라가시면 어떨까싶어요.간단하게 표현하자면 이런 패턴이라고 봐주시면 됩니다.&nbsp;<pre><code>[Application]
 |
 | BEGIN TX
 | - 비즈니스 데이터 변경
 | - outbox 테이블 insert
 | COMMIT
 v
[DB]</code></pre>&nbsp;이 상황에서 Outbox Publisher라는 역할을 따로 두고, 주기적으로 outbox 테이블을 polling하고 Kafka에 이벤트를 발행하고 그 이후에 처리하였다고 outbox 테이블의 상태를 변경하는거죠

강의 11 질문

화면상의 OS가 Window로 보이는데, 제 강의는 기본적으로 MAC으로 구성이 되어 있어서요. 제가 방금 다운로드 한 결과 정상적으로 다운로드가 되었는데, 혹시 해당 부분을 확인하여 다시 해보실 수 있을까요??&nbsp;<a target="_blank" rel="noopener noreferrer nofollow" href="https://inf.run/2wamH">https://inf.run/2wamH</a>

강의 첨부파일 문의

안녕하세요 chess.min님 이렇게 추가적으로 도움이 될 수 있는 내용 작성해주셔서 감사합니다. 아무래도 제가 강의하는 입장에서 조금 부족한 부분이 있었던거 같네요. &nbsp;좋은 하루 보내세요!! 감사합니다!

비동기 전송을 위한 Thread 관리 에서 Executor 설명 오류

혹시 dellahong님 어떤 root.py가 보이지 않는다고 하시는지 공유 가능하실까요??

Hong

投稿