입금 성공 후 계좌 잔고 증가 로직 구현 방법 문의

안녕하세요 호로록님 제가 이벤트를 일부 뺴먹었나 보네요 ㅠㅠ 죄송합니다. 생각하시는 방향이 맞습니다. 우선 오케스트레이션 방식은 내가 동기적으로 볼 수 있기 떄문에 단순히 값을 추가해주시면 될 것이고 코레오그래피 패턴에서는 최종적으로 처리하는 이벤트 즉 예를들면 결제 성공 이벤트도 최초 계좌의 잔액을 담당하는 서비스가 소비를 하면서 계좌의 잔액을 처리하시면 됩니다. 생각하시는 방향이 틀리지는 않은거 같아요. 감사합니다!

코레오그래피 방식으로 SAGA 패턴을 구성할때 메시지 설계는 어떤식으로 해야하는지 궁금합니다

안녕하세요 minsik2434님 질문 주셔서 감사합니다. 기본적으로 코레오그래피 패턴을 구현하신다면, 특정 서비스의 API를 호출하면서 동작하지 않습니다. EDA 기반의 아키텍처가 기본이기 떄문에 보통은 모두 다 메시지를 통해서 처리를 하게 됩니다.물론 어쩔 수 없는 상황은 항상 존재합니다. 필요하다면 API도 가능하겠죠 이러한 상황에서 처리해야하는 정보를 이벤트에 담아서 전송을 하는 형태로 진행이 될 겁니다.예를들어서 (주문 → 재고 → 결제) 흐름으로 흘러간다면, 주문 서비스(Order Service)사용자가 주문 요청을 하면 OrderCreated 이벤트를 발행할 겁니다.메시지에는 주문 식별자, 주문한 상품 목록, 수량, 사용자 정보 정도가 포함될겁니다.이정도 포멧이면 될 꺼 같아요.{ "eventType": "OrderCreated", "orderId": "123123123", "userId": "USER", "items": [ { "productId": "001", "quantity": 2 }, { "productId": "2002", "quantity": 1 } ] } 재고 서비스(Inventory Service)OrderCreated 이벤트를 구독하고, 주문에 포함된 상품의 재고를 감소시킵니다.재고가 충분하면 InventoryReserved 이벤트를 발행하고, 부족하면 InventoryFailed 이벤트를 발행합니다.이때 상품의 가격 정보나 결제에 필요한 정보가 있다면, 재고 서비스가 이를 이벤트에 포함시켜 다음 단계로 전달할 수 있습니다. 여기서 핵심은 뭔가 추가적인 정보가 필요하다면, 이 이벤트를 담아서 전송을 하는 겁니다. 그래야 다른 서비스가 해당 값을 참조하여 처리하는것이죠 질문에 대한 답변이 되었을까요?? 뭐든 다른서비스가 처리해야 할 정보가 있다면 단순하게 포함만 시켜서 전달한다 라고 이해하시면 더 편하실꺼 같아요. 감사합니다.

빌드 파일

안녕하세요 옥윤님 질문 감사합니다. 혹시 좀 더 세부적으로 어떤 내용이 궁금하신지 알 수 있을까요??

설명과 화면이 맞지 않습니다.

안녕하세요 Olla Vi님 혹시 어떤 내용에서 화면상과 매칭이 안되는지 공유 가능하실까요?? 예전 초기에 만들었던 강의라서 미흡한 부분이 많은거 같습니다. 관련해서 공유주시면 감사하겠습니다.

웹소켓을 이용한 채팅시스템에서 부하테스트를 어떻게 진행해야할까요?

안녕하세요 준영님 좋은 질문 주셔서 감사합니다. 사실상 쉽지 않은 질문이라서 여러가지 관점에서 대답을 드리면 좋을꺼같아요. 우선 테스트를 진행하는데에 있어서는 저는 개인적으로 노드 기반의 테스트 도구를 사용하였습니다.대표적으로 k6 를 사용하여 간단한 스크립트 작성을 하면서 부하 테스트를 진행 할 수 있고, 이를 통해서 가상의 연결을 동시다발적으로 시뮬레이션을 하실수가 있습니다. 이 부분을 알아보시면 부하테스트를 하는데에 있어서 도움이 될 꺼 같습니다. 우선 웹소켓이 음... 보통은 큰 문제가 없습니다. 실시간 통신을 하는데에 있어서는 당연히 사용이되는것이 일반적이지만, 애초에 t2.micro 를 사용하는거부터가 잘못된 상황인거 같습니다. 기본 천장이 너무나도 낮아요. t2.micro 는 CPU 1, RAM 1GB 정도로 구성이되어 있을텐데, 이미 400개의 웹소켓이 연결이 되었다면, 한계에 가까울꺼같네요. 대략적으로 300~500개 정도 가능할꺼같거든요물론 이 부분은 저의 일종의 감입니다. 상황에 따라서 당연하게도 달라질 수 있어요. 그래서 이렇게 연결이 되어 있는 상태에서는 애초에 인스턴스의 성능 문제로 대응이 불가능하셨을겁니다. GC나 스레드 스케줄링이 밀려버려요.웹소켓 서버가 기본적으로 메모리를 많이 잡아먹습니다. 커넥션을 물고있는 상황이기 떄문이에요. 이 커넥션을 유지하기 위해서 고성능의 서버가 필요하죠. 그래서 취준생 입장에서 비용적인 부분이 부담이 되신다면,,, 그냥 HTTP 풀링으로 구현하시는것도 하나의 방법일꺼 같아요. 그리고 해당 인스턴스의 CPU 사용률과 메모리 사용률을 우선적으로 확인하시고 이 부분에 대해서 분석을 하시는게 좋을꺼같습니다. 현재 서버가 과도하게 사용이되고 있는지 등을 확인해야 좀 더 좋은 답변을 드릴 수 있지 않을까 싶어요. 그래서 우선적으로 테스트를 k6 를 통해서 환경을 맞춰주시고, 그 이후에 동일한 환경에서 보시면 되지 않을까 싶네요. 그럼 이제 추가적인 질문에 대해서 답변을 드리도록 할게요.앱 개발에서 채팅시스템을 구축하는 상황이고, 대략 500~1000명을 수용해야한다면 어떤 기술을 적용해 채팅시스템을 구축하셨을 것 같나요? 우선적으로 웹소켓은 기본적으로 사용할겁니다. 양방향 통신이 필수적으로 필요한 기능이기 떄문이에요.그래서 저라면, 그냥 현재 강의에서 다루었던 아키텍처를 그대로 구현할꺼 같습니다. 큰 문제가 없이 저정도의 요청은 사실 무리가 없이 처리가 가능하다고 생각을 하거든요 t2.micro 서버는 얼만큼의 소켓연결까지 버틸 수 있는지 알고 싶습니다. 일단 이 질문에 대해서는 단편적으로 이게 맞다 아니다를 말할수는 없습니다. 내부적으로 어떻게 구현하셨는지도 모르고 제가 알 수 있는 정보가 인스턴스 성능밖에 없어요. 그래서 딱 말하기가 어렵지만, 그냥 딱 인스턴스 성능만 봐도 사실상 천장이 낮습니다. 너무 성능이 안좋아요.우선 80명 정도라면 문제는 없겠죠. 서버가 OOM같은 현상이 발생하지는 않을꺼같아요. 근데 기본적으로 불안한 상태는 맞습니다. 속히 말해서 돌아는 가는데, 여유가 진짜 없다 수준의 성능인거 같습니다.또한 채팅 메시지가 얼마나 들어오는지도 모르기떄문에 음.. 저라면 성능을 올릴꺼같습니다. 그렇게 트래픽이 없다면, 가볍게 t3.small 정도도 괜찮을꺼 같네요. 제 질문들이 대부분 인프라 확장의 타당성을 갖추기 위한 질문이라고 생각합니다. 혹시 인프라 확장을 위한 근거로써 어떤 지표가 타당성을 확보할 수 있다고 생각하시는지 궁금합니다. 지표라는게 추상적인 수치이기도 하고 상황에 따라 다르게 해석이 가능한 수치라고 생각을 합니다. 그래서 이 부분도 참.. 어려운거 같아요. 보통은 CPU 사용률, 메모리 사용률을 저는 주로 봅니다. 그리고 부수적으로 스레드 수 정도까지는 확인을 하는거 같아요. 예를들어서 CPU 사용률이 70~80%인데, 이 현상이 5~10분 이상 계속해서 지속한다. 이런 상황이라면 문제가 있을 수 있겠죠.배치성 모듈이라면 그럴 수 있습니다. 특정 시간대에 작업이 몰려서 증가하는것이죠. 또한 GC의 활동주기도 종종 확인합니다. GC가 돌았는데, 메모리가 정리가 안된다던지, 아니면 GC가 너무 자주 돈다던지 이런 부분을 확인하는거 같아요. 그래서 이 질문에 대해서는 여러가지 요소들을 확인하셔야 해서... 사실상 경험을 직접 해보시고 다양한 상황을 마주하시는게 더 도움이 되지 않을까 싶습니다 ㅠㅠ 제가 보는 대략적인 관점은 저정도를 확인하고 조합해서 관리를 하는 편입니다. 예를들어서 CPU가 80% 이상이고, 메모리가 계속 높은 상태로 지속하네?? 이 과정에서 GC가 계속 활동하는데 수치가 점진적으로 증가하네?? 이런 현상이라면 메모리 누수가 있고, 서버의 성능도 올려야 하는 상황인거죠.하지만 앞서 말씀 드린것처럼 일시적으로 작업이 몰리는 상황에서는 확장에 대한 근거로 사용하지는 않습니다. 전반적으로 생각하는 부분을 설명드렸는데 도움이 되셨을지 모르겠습니다. 추가적인 질문 있다면 남겨주세요 감사합니다.

멀티모듈 초기설정

안녕하세요 김우철님 질문 남겨주셔서 감사합니다. 어... 현재 질문주신 내용으로는 제가 어떤 문제인지 잘 파악이 힘들꺼 같아요... 그떄 당시의 소스코드라던지 추가적인 정보가 필요할꺼같습니다... ㅠㅠ IDE 문제일수도 있고, 필수 라이브러리가 아직 설치가 안되어 있을수도 있고 유추가 거의 불가능한 상태인거 같네요.,.

중복 컨슘 방지에 대해서 여쭤보고 싶습니다!

안녕하세요 YOGURT님 질문 주셔서 감사합니다.우선 처리 실패에 대해서는 DLQ를 사용하는 패턴을 구현하셨다는걸로 이해를 하였습니다.그리고 정확히 한번 즉 exactly-once 정책을 보장하고 싶은 고민으로 보입니다. 우선 해결해야 하는 부분은 컴슈머 입장에서의 멱등성 보장입니다.어떤 전략을 사용하냐에 따라 다르지만, 기본적으로 중복된 메시지가 들어와도 이미 처리가 되었다면, 더이상 처리가 되지 않도록 하는 방식 구현이 되면 좋습니다. 대표적으로 처리한 ID를 기록해두면 좋겠죠 이를 통해서 멱등성도 보장이 가능하고요 말씀해 주셨던 인박스 패턴이라는게 결국 이런 멱등성을 보장하기 위한 패턴ㅇ입니다. 상태 저장소에 기록함으로써 처리하였던것을 기록하고 검증하는 것이죠. 근데 조금 제가 이해가 안가는 부분이 있는거 같아요.하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...? 해당 부분에서 첫번쨰에서 리밸런싱 발생 -> 하지만 인박스 패턴 및 리밸런싱이 발생해도 상태값을 통해 다시 같은 메시지를 스킵 -> 이후의 첫 컨슘?? 이 첫 컨슘이 어떤 컨슘을 의미하시는지 상황이 명확하게 그려지지는 않는거 같아서요. 혹시 마지막에 질문주신 부분을 좀 더 상세하게 설명해 주실 수 있을까요??

강의 19] 질문입니다.

안녕하세요 치즈초코우유님 질문 주셔서 감사합니다.보내주신 당연하게도 개발자간에 스타일의 차이는 있겠고 저도 새당 코드를 구현할 떄 크게 뭔가 고려한 스타일은 아니였다보니 중요하게 생각하지 않았는데, 보내주신 코드 스타일이 좀 더 유지관리하기에는 좋은 포인트인거 같습니다. 직접적으로 전달을 해준다는것이 좀 더 유용한 형태는 맞는거 같아요. 저보다 더 뛰어나시네요 ㅎㅎ 질문주셔서 감사합니다!

Kotlin data class 엔티티에서 copy로 수정 후 save하는 이유가 있을까요?

안녕하세요 심재경님 질문 주셔서 감사합니다. 혹시 어떤 영상을 보시고 질문을 해주셨는지 알 수 있을까요?? 구체적인 코드를 확인하고 내용을 확인하면 답변드리는데 더 큰 도움이 될 꺼 같습니다.

엔티티는 Data Class로 작성하면 안되나요?

안녕하세요 최현민님 질문 주셔서 감사합니다. 비슷한 형태로 좋은 질문 해주신 분이 있고 그에따라서 답변을 한 케이스가 있어서 해당 질문을 참고해 보시면 좋을 꺼 같습니다. https://inf.run/GHA8N 그리고 compainon object, object는 기본적으로 Spring Boot를 통해서 무언가 상태를 관리하지 않을 떄 사용하는게 좋습니다. 예를들면 일반 상수값이나, 정말 무난하게 사용가능한 함수 같은거에 적용하면 좋을꺼같습니다. 감사합니다.