강의 순서

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

강의 11 질문

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

강의 첨부파일 문의

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

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

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

강의에서사용하신 root.py 파일이 안보여서 실습하면서 만든 텍스트 공유 드려요

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

강의에서사용하신 root.py 파일이 안보여서 실습하면서 만든 텍스트 공유 드려요

잠시 확인하고 말씀드리겠습니다. 감사합니다!

Orchestration 방식의 모듈 구성에 관한 질문

안녕하세요 질문 주셔서 감사합니다. 우선적으로 이 SAGA패턴이라는게 딱 정해진게 없습니다. 상황에 따라서 하이브리드 형태로 조합해서도 사용해요. 그래서 다양하게 조합하시면 좋습니다. 말씀해주신 부분도 사실 가장 일반적으로 볼 수있는 패턴이에요. 최종 조율자를 하나 더 둠으로써 조율을 좀 더 포괄적으로 수항하는거죠. 그래서 개인적으로는 나쁜 방향은 아닌거 같습니다 좀 더 책임이 명확해지는 방식인거 같아요. 대신 반드시 명심하셔야합니다 SPOF로써의 위험을 인지하시고 사용하시면 좋을꺼같습니다. 감사합니다!!

질문] 에러처리 관련 문의

안녕하세요 치즈초코우유님 이렇게 질문주셔서 감사합니다. 너무나도 유익한 질문같아요. 물론 말씀해주신 부분처럼 영역이 좀 더 포괄적이고 넓어진자면 에러처리하는 부분에서 문제가 많을겁니다. 저 같은 경우에는 기본적으로 root class를 만들어서 해당 클래스를 모두 상속받아 구현하고 해당 root class를 exception의 기준으로 잡는것을 선호하는거 같아요. 나누어진만큼 나눠진 기준으로 class들을 만들어서 처리한다고 봐주시면됩니다. 물론 root class를 상속받아 사용하는 각각의 class들에 대해서는 공통필드나 사용할 수 있는 공통값이 있어야겠죠. 어느정도 이해가되셨을까요?? 혹시라도 추가적인 질문있다면 남겨주세요. 감사합니다!!

Orchestration 패턴시 트랜잭션 분리

안녕하세요 파이리이2님 질문 주셔서 감사합니다. 말씀해주신 부분이 현실적으로 틀린부분은 아니에요 정말 좋은 고민을 해주신거 같습니다. 어디까지나 저는 간단하게 어떤 형태라는것을 알려드리기위해 작성한바가 있습니다. 그러니깐 너무 이 코드가 맞다고 생각하지마시고 고민해주신 부분으로도 나쁘지않겠다는 생각이 들어요. 또한 오케스트레이션이라고 이벤트를 사용을 안하지는 않아요 현실적으로 비동기로 돌릴 수 있는 부분이 있다면 이벤트로 처리하시는것을 추천드려요. 어디까지나 표준이지 그 표준을 조합해서 하이브리드 형태를 가져가는것이 가장 좋은 패턴이라고 생각합니다. 추가적인 질문있다면 편하게 주세요 감사합니다!!

common 모듈의 필요성과 다른 방법에 대한 문의

안녕하세요 BeakGwa님 질문 감사합니다. 절대 죄송할만한 질문이 아니라서 죄송하지 않으셔도 됩니다 ㅎㅎ 우선 강의에서도 제가 언급했을텐데, 당연하게도 실무 또는 프로덕션 레벨에서는 따로 레파지토리를 관리하게 됩니다. 말씀해주신 Nexus도 많이 사용하죠 이 형태는 어느정도 강의이기 떄문에 추가적이거나 너무 혼동되는 내용은 삭제하려고 이렇게 구셩이 되었습니다. 참고해주시면 감사하겠습니다. 날이 많이 춥네요 ㅠㅠ 감기 조심하시고 좋은 하루 보내세요!