git 에 강의내용에 필요한 파일들 존재하지 않음

안녕하세요, 이도원입니다.말씀하신 Pipeline 관련 스크립트는 다른 Repo에 있습니다 .https://github.com/joneconsulting/jenkins_pipeline_script위 URL에서 확인해 보시기 바랍니다. 감사합니다.

젠킨스에 등록된..

안녕하세요, 이도원입니다. 답변이 늦어 죄송합니다. 아래 AI 답변처럼, Jenkins에서 제공되는 API(https://www.jenkins.io/doc/book/using/remote-access-api/)를 사용하실 수 있을 것 같습니다. 프로젝트(잡)의 목록의 경우, https://[Jenkins_주소]/api/json?tree=jobs[name,url,color] 라고 웹 브라우저에서 호출해 보시면, 아래와 같은 목록을 확인해 보실 수 있습니다. (사진) 감사합니다.

필요한 파일만 가지고 배포할 수 있나요?

안녕하세요, 이도원입니다. AI 답변이 달려있어, 미확인으로 보이지 않았습니다. 답변이 늦어 죄송합니다. 만약, 말씀하신대로 일부의 코드만 선별적으로 취합하여 배포하려면, Shell Script난 Jenkinsfile을 통해 간단한 필터링으로 작업해 볼 수도 있습니다. 강의에서는 Jenkinsfile을 직접 프로그래밍 해서 처리하는 작업을 많이 넣지는 못했는데, 아래와 같이 선택해서 해 볼 수 있습니다. (아래 AI 답변처럼 필요한 파일을 별도의 폴더에 저장한 다음에 사용하는 것도 가능합니다)아래 예시에서 사용한 rsync (remote sync)명령어는 특정 패턴의 파일만 포함하거나 제외하는 기능이 사용될 수 있는 명령어로써, Linux 시스템에서 파일을 효율적으로 전송하고 동기화하기 위한 유틸리티 입니다. pipeline { agent any stages { script { // 1. JSP 파일만 배포하는 경우 echo "Deploying only JSP files..." sh """ rsync -avzR --include='*.jsp' --include='*/' --exclude='*' \ ./ ${REMOTE_USER}@${REMOTE_HOST}:${TARGET_DIR} """ // 2. 'admin-'으로 시작하는 파일만 배포하는 경우 echo "Deploying files starting with 'admin-'..." sh """ rsync -avzR --include='admin-*' --include='*/' --exclude='*' \ ./ ${REMOTE_USER}@${REMOTE_HOST}:${TARGET_DIR} """ } } }감사합니다.

읽기 모델을 조회 최적화하여 성능 향상 하는 방법

안녕하세요, 이도원입니다. 답변이 늦어 죄송합니다. 먼저, 질문1은, 아래 AI 답변에서도 언급 된 것처럼, 명령과 조회가 섞여 있는 경우, 데이터베이스 트랜잭션이 더 복잡해 질 수 있습니다. 하나의 스토리지에서 2가지 분리된 작업을 해야 하기 때문에, 확장성에도 적합하지 않을 수 있습니다. 조회는 트래픽이 많은데, 업데이트는 그렇지 않다고 할때, 조회만을 위해 확장해야 하는 경우도 생길 수 있습니다. 간단하게는 이러한 부분만 고려해 보더라도 최적화에 문제가 있을 수 있습니다. 질문2는, AI 답변에 아래 2가지 정도를 더 추가해 볼 수 있을 것 같습니다. 비동기 이벤트 스트리밍을 통한 "쓰기-조회" 간극 최적화전문 검색 엔진(Full-text Search) 및 다중 투영(Multiple Projections): 예를 들어, 예를 들어, 상품 정보가 변경되었을 때 이를 일반 RDB 기반 조회 모델뿐만 아니라 Elasticsearch와 같은 검색 엔진에도 동시에 반영(Projection)합니다. 이는 검색 유연성이나 맞춤형 데이터 구조를 가져갈 수 있습니다. 추가 문의 사항 있으시면 글남겨 주세요. 감사합니다.

Orders에 테이블의 용도

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

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

안녕하세요, 이도원입니다.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.*)이나 외부 라이브러리 설정 등의 일부 정보는 가능합니다. 말씀하신것처럼, 동적으로 설정으로 변경하기 위해서는,Tomcat Manager에서 Undeploy 후에 Redeploy를 다시 해 보시기 바랍니다. Jenkins 작업에서도 단순하게 교체하는 작업 외에 이전에 등록 된 웹 애플리케이션을 삭제하고 다시 재로드하는 방법이 필요합니다.Tomcat의 conf/Catalina/localhost/[your_context_name].xml 파일이나 META-INF/context.xml 파일에 속성을 추가하면, Tomcat은 웹 애플리케이션의 클래스나 설정 파일 변경을 감지하고 자동으로 애플리케이션 컨텍스트를 재로드가 가능합니다. 위와 같은 방법으로 테스트해 보시고, 추가 문의사항 있으시면 다시 글 남겨 주시기 바랍니다.감사합니다.

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

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

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

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

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

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

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

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