Dowon Lee

안녕하세요, 이도원입니다. CQRS와 Event Sourcing을 함께 사용할 때, RDS에 직접 데이터를 저장하고 읽어오는 방식은 Command 영역과 Query 영역의 역할에 따라 다릅니다. 일반적인 관계형 데이터베이스(RDS) 테이블은 여전히 사용되지만, 그 역할과 구조가 이벤트 소싱 모델에 맞게 변형됩니다. 결론적으로, 데이터는 말씀하신 ORDER_EVENT 와 같은 이벤트 테이블이 맡게 됩니다. Command 이벤트의 모든 데이터 변경은 말씀하신 것처럼 이벤트 형태로 저장됩니다. 쓰기 영역에 새로운 이벤트가 저장되면, 이 이벤트를 구독하는 프로젝션(Projection) 또는 리스너가 동작하여 Query 영역에서는 사용 됩니다. CQRS+Event Sourcing 기반에서는 데이터의 최종 상태(Current State)를 저장하는 기존 방식의 정규화된 RDS 테이블은 Command 영역에서 사용되지 않습니다.추가 문의사항 있으시면 다시 글 남겨주시기 바랍니다. 감사합니다.

Orders에 테이블의 용도

안녕하세요, 이도원입니다.Spring Boot 애플리케이션이 Tomcat 위에서 war 파일로 배포되면, Tomcat은 해당 war 파일의 압축을 풀고 내부의 Spring Application Context를 로드하여 실행합니다. Spring Boot는 부팅 시 최초 한 번만 application.yml 파일을 읽어 모든 Bean과 환경 설정(Environment)을 초기화하게 되는데, Tomcat이 war 파일을 다시 덮어쓸 때와 같이, 단순히 파일을 덮어쓰는 것만으로는 이미 메모리에 로드되어 실행 중인 기존의 Spring Application Context를 자동으로 종료하고 새 컨텍스트로 교체하지 않습니다. RDS 접속 정보나, 서버 포트, JPA/Hibernate (영속성 관련 핵심 Bean 초기화 정보) 등은 application.yml 파일을 수정해도, 이미 메모리에 있는 Bean을 재구성해야 하므로 Tomcat의 재시작(또는 웹 애플리케이션 컨텍스트의 재로드)이 필요합니다. 이렇게 Tomcat의 재시작을 하지 않더라도 일부 설정은 Spring Boot의 핵심 Bean 초기화와는 관계없이, 해당 정보를 주기적으로 다시 읽도록 설계된 라이브러리나 Spring Actuator 기능을 통해 실시간으로 변경될 수 있습니다. 예를 들어, 로깅 레벨(logging.level.*)이나 외부 라이브러리 설정 등의 일부 정보는 가능합니다. 말씀하신것처럼, 동적으로 설정으로 변경하기 위해서는,<ol><li>Tomcat Manager에서 Undeploy 후에 Redeploy를 다시 해 보시기 바랍니다. Jenkins 작업에서도 단순하게 교체하는 작업 외에 이전에 등록 된 웹 애플리케이션을 삭제하고 다시 재로드하는 방법이 필요합니다.</li></ol><ol start="2"><li>Tomcat의 <code>conf/Catalina/localhost/[your_context_name].xml</code> 파일이나 <code>META-INF/context.xml</code> 파일에 <code><Context reloadable="true"></code> 속성을 추가하면, Tomcat은 웹 애플리케이션의 클래스나 설정 파일 변경을 감지하고 자동으로 애플리케이션 컨텍스트를 재로드가 가능합니다. </li></ol>위와 같은 방법으로 테스트해 보시고, 추가 문의사항 있으시면 다시 글 남겨 주시기 바랍니다.감사합니다.

yml 파일 db 접속정보 수정 후 배포 시 미반영

안녕하세요, 이도원입니다. 두 속성 모두 데이터의 유일성(Uniqueness)을 보장하는 역할을 하지만, 목적과 적용되는 레이어가 완전히 다릅니다. @Id는 엔티티(객체) 식별을 위한 JPA/객체 지향 레벨의 설정인 반면, unique = true는 데이터베이스(테이블) 제약 조건을 위한 설정입니다. @Id는 해당 엔티티 객체를 영속성 컨텍스트(Persistence Context) 내에서 고유하게 구별하는 유일한 기준입니다. JPA의 모든 기능(저장, 조회, 수정, 삭제)은 이 기본 키를 기반으로 수행됩니다. 반면, Unique 속성은 해당 컬럼의 값이 테이블 내에서 중복되는 것을 물리적으로 방지하여 데이터의 무결성을 보장합니다만, 엔티티의 식별자가 아니며, 필요에 따라 여러 컬럼에 적용할 수 있습니다. (예: 사용자 ID, 이메일, 주민등록번호 등)감사합니다.

혹시 pk 외 별도의 id 를 부여한 이유가 있을까요 ??

안녕하세요, 이도원입니다. 데이터베이스의 선택과 용도가 MSA 구조를 선택하거나 단위를 나누는 중요한 요소임에는 분명합니다. 실제로 저도 데이터를 기준으로 Monolithic -> Microservice 전환작업을 고려하기도 하고, 더나아가서 데이터의 사용량과 프로세스에 따라 서비스를 분리하는 작업을 고려하기도 합니다. 강의에서도 중간중간 말씀드리기는 했는데, 무조건이라는 것없다고 생각됩니다. 다만, DB가 여러 종류가 어떤 이유에 있어 프로젝트에 모두 도입되어야 할 경우라면, 그 용도에 맞춰 서비스가 분할되어야 할 것이고, 그렇다면, MSA 구조로 갈 수 있는 충분한 이유가 된다고 생각됩니다. 물론 하나의 프로젝트에서도 다수의 DB를 사용할 수 있도록 구성할 수도 있기 때문에, 말씀드렸던것처럼 절대적인 기준으로 결정하기는 조금 어렵지 않나 싶습니다. 충분한 답변이 되지 못했다면, 다시 글 남겨주시기 바랍니다. 감사합니다 .

마이크로서비스와 모듈러 아키텍처 선택 질문

안녕하세요, 이도원입니다. 말씀하신 내용처럼 강의에서는 전체 프로젝트를 구성하는 ROOT Project 밑으로 여러 서비스들 (user, product, order 등)을 SUB Project 개념으로 등록하여 관리하도록 했습니다. 실제로 Maven이나 Gradle로 자바 프로젝트를 관리할 때도, 다수의 프로젝트라 하더라도 하나의 Category나 Group으로 묶어 관리하는 경우가 편할 수 있습니다. 다만, 강의에서 말씀드린 내용처럼 배포 단위, 그리고 실제 개발하는 단위까지 고려하신다면, 이 부분은 팀의 규모나 개발자, 역할 등에 따라 나뉘어야 할 것 같습니다. 하나의 조직, 팀, 개발자가 전체를 프로젝트를 공유하고, 이과정에서 세부적인 모듈이나 코드를 또 분리해서 개발할 수도 있고, 각각 1개씩 프로젝트를 전담해서 개발할 수도 있고, 배포를 담당할 수도 있습니다. 어디까지나 조직의 규모와 팀의 역할, 개발의 단위에 따라 달라지고, 거기에 맞춰 팀빌딩과 R&R을 결정하는 작업이 프로젝트 초기 작업에 이뤄지게 될 겁니다. 추가 문의사항 있으시면 언제든지 글 남겨 주시기 바랍니다. 감사합니다.

MSA 아키텍쳐 프로젝트 구성 방식

안녕하세요, 이도원입니다. 말씀하셨던 부분에 대해서 정확한 위치를 찾지 못해, 우선 제 강의 의도로 말씀드립니다. -.-;Modular Monolithic Architecture와 Layered Architecture 모두 Monolithic 구조입니다. 전통적인 설계 방식으로 기술적 레이어 중심의 방식(Layered Architecture)과 도메인 중심으로 내부를 서비스 단위로 나눈 현대적인 Monolithic 방식의 차이라고 생각됩니다. 기술단위(Controller, Service, Repository 등)로 코드를 분리했던 Layered 방식과 비교해서, 기능별로 모듈화하여 각자 독립된 Layer로 코드를 분리해서 사용하는 방식의 Modular 방식이 말씀드리고자 하는 내용이었습니다. 강의했던 내용 중 어느 부분이었는지 조금 더 말씀해 주실 수 있을까요? 해당 부분을 확인하고 수정해야 할 부분있으면 수정하도록 하겠습니다. 감사합니다.

섹션 2 - 12강 강의 제목 관련 질문있습니다.

안녕하세요, 이도원입니다. 올려주신 코드의 일부분 (Default Filter 부분, Global Filter)을 제가 가지고 있는 apigateway-service 프로젝트에 옮겨서 작업 했을 때, 아래와 같이 정상작동 되었습니다. application.yml 파일의 다른 부분, 예를 들어, server-port, eureka, routes 등의 설정은 정상적으로 작동되는대도 필터 부분만 작동되지 않는다면, 사용하신 apigateway-service 프로젝트의 spring boot + spring cloud의 버전을 확인해 보시고, 자바코드를 이용하여 작성된 필터 코드를 등록하는 방법(AbstractGatewayFilterFactory 상속)과 application.yml에 직접 필터를 적용하는 부분을 분리해서 따로따로 확인해 보시고 모든 필터가 작동되지 않는 것인지도 확인해 보시면 좋을 것 같습니다. 지속적인 문제가 발생하신다면, 아래 이메일로 작업하신 apigateway-service 프로젝트 코드를 압축하여 보내주시면, 제쪽에서도 확인해 보도록 하겠습니다. <a target="_blank" rel="noopener noreferrer nofollow" href="mailto:edowon0623@gmail.com">edowon0623@gmail.com</a>감사합니다.

GlobalFilter, LoggingFilter가 동작하지 않습니다.

안녕하세요, 이도원입니다. 코드를 직접 작성한다는 의미는 해당 코드를 만들 때나, 실무에서 필요한 개발할 하는 경우에, 어딘가 참고할 만한 코드나 Reference가 있어도, 그걸 그대로 Copy & Paste 한다기 보다는 직접 코드를 작성해 본다는 의미입니다. 강의에서는 한줄한줄 입력하는 시간을 가지면, 듣는 수강생분들에 따라, 지룰 할 수도 있어서, 최대한 사용할 수 있는 코드는 제가 작성한 코드를 이용하여 실행했습니다. MSA 관련된 예제나 Spring Boot 애플리케이션 코드에 익숙치 않으시다면, Github에 있는 코드를 참조해서 직접 작성해 보시면 좋을 것 같고, 기본적인 구조와 역할에 대해서 어느정도 파악되셨다면, 처리되는 프로세스와 결과를 확인하고 이해하는데 집중하기 위해 작성 된 코드를 실행해 보시는 쪽도 도움이 되지 않을까 싶습니다. 추가 질문사항 있으시면 다시 글 남겨 주세요.감사합니다.

학습 방향

안녕하세요, 이도원입니다. 강의에서 언급한 카프카 커넥트를 사용한 order-service와 DB와의 연결은 사용량은 많은 서비스들이 부하가 걸릴 수 있는 상황에서 DB와의 직접적인 연결 대신, Queue 방식을 이용해서 처리하는 방법에 대해서 설명드렸습니다. 말씀하신대로 여러 order-service가 직접 하나의 DB에 연결되어 작업한다면, 동기화 문제는 해결될 수 있을 수 있으나, order-service에서의 다량 요청에 의해 DB의 병목 현상이 생기거나, DB로부터의 처리 완료 전까지 order-service가 대기해야 하는 시간을 가져야 하는 점을 MQ를 이용해서 처리하는 과정을 설명드렸습니다. 서비스의 사용량, 네트워크의 트래픽, 스케일과의 비용 등을 고려해서 카프카와 카프카 커넥트 사용의 도입을 고려하시면 좋을 것 같습니다. 감사합니다.

카프카 커넥터 사용 목적 문의

안녕하세요 이도원입니다. 최신 Kafka에서는 Kraft 모드를 기본으로 실행되는 것으로 알고 있습니다. 말씀하신 오류는 Confluent 5.5.2 버전 말고, 그 위 버전인 6.1.0 버전으로 테스트해 본 결과 Windows에서도 정상적으로 작동됨을 확인했습니다. 다만 Confluent 최신 버전에 속하는 8.x 버전으로 테스트 시 SLF4j 라이브러리의 호환성 문제로 오류가 발생되었습니다. 우선 Confluent 6.1.0 버전으로 변경하시고 실행해 보시면 좋을 것 같습니다. 감사합니다.

Dowon Lee

Posts