[LG CNS AM - TIL 38일차] AM기반 MSA: 서비스 디스커버리, 보안, API 게이트웨이 활용

About this offer

1. 오늘의 한 줄 요약 Spring Boot 기반 MSA에서 사용자·카탈로그·주문 서비스를 각각 구성하고, REST API와 JPA로 데이터를 처리하는 방법, Spring Security로 인증을 적용하는 방법, API 게이트웨이를 통한 호출 흐름을 학습했다. 2. 배운 내용 핵심 개념: - 서비스별 역할과 독립적인 데이터 관리 서비스 경계 : 사용자 서비스는 회원 가입, 사용자 조회, 로그인 기능을 맡는다. 카탈로그 서비스는 상품 목록과 재고 정보를 관리한다. 주문 서비스는 주문 생성과 사용자별 주문 내역 조회를 맡는다. 각 서비스는 독립적인 데이터베이스를 사용한다. 실습에서는 가볍게 실행할 수 있는 H2를 사용하며, 인메모리 방식에서는 애플리케이션 종료 후 데이터가 사라진다. 지원 구성 요소 : 유레카는 실행 중인 서비스의 위치를 등록·조회하게 하고, API 게이트웨이는 클라이언트 요청을 서비스로 전달한다. Kafka를 통한 주문 이벤트 전달, Config Server를 통한 설정 관리, 모니터링과 배포 자동화는 서비스가 늘어날 때 필요한 운영 요소로 소개되었다. - 사용자 서비스의 REST API와 데이터 흐름 일관된 API 설계 : GET /users 는 전체 사용자 조회, GET /users/{userId} 는 특정 사용자 조회, POST /users 는 회원 가입에 사용한다. 게이트웨이를 통하면 /user-service/users 처럼 서비스 식별 경로가 앞에 붙는다. 게이트웨이는 이 경로를 이용해 요청을 전달하고, 필요하면 실제 서비스의 경로에 맞게 변경한다. 리소스 이름은 /users 처럼 명사형 복수형을 사용하고, 조회와 생성은 HTTP 메서드로 구분한다. 회원 가입 데이터 처리 : @RequestBody 가 JSON 요청을 RequestUser 로 받고, @NotNull , @Size , @Email 등으로 입력값을 검증한다. 요청 객체의 값을 DTO로 옮겨 사용자 ID를 생성하고 비밀번호를 해시한 뒤, 엔티티로 변환해 JPA 레포지토리에 저장한다. 저장 결과는 응답 객체로 변환한다. 응답에는 사용자 ID 등 필요한 정보만 담고 비밀번호는 제외한다. ResponseEntity 로 상태 코드·헤더·본문을 지정할 수 있으며, 새 사용자를 생성한 결과에는 201 Created 가 적절하다. JPA 활용 : 엔티티는 데이터베이스 테이블과 매핑하고, CrudRepository 또는 JpaRepository 를 상속한 레포지토리에서 save() , findAll() , findById() 등을 사용한다. findByEmail() , findByUserId() 처럼 메서드 이름을 이용한 조회 메서드도 선언할 수 있다. - Spring Security의 인증·인가와 비밀번호 처리 인증과 인가 : 인증은 사용자가 누구인지 확인하는 과정이고, 인가는 확인된 사용자가 특정 기능에 접근할 수 있는지 판단하는 과정이다. SecurityFilterChain 에서 회원 가입이나 H2 콘솔처럼 공개해야 하는 경로는 permitAll() 로 허용하고, 보호할 경로는 authenticated() 로 설정한다. 401 Unauthorized 는 인증이 필요한 경우, 403 Forbidden 은 인증은 되었지만 권한이 부족한 경우를 구분하는 데 쓰인다. 비밀번호 해시 : 비밀번호를 평문으로 저장하지 않고 BCryptPasswordEncoder.encode() 로 해시한다. 로그인할 때는 저장된 값을 원래 비밀번호로 되돌리는 것이 아니라 matches() 로 입력값과 해시의 일치 여부를 검사한다. - 카탈로그·주문 서비스와 서비스 간 연동 상태 카탈로그 서비스 : GET /catalog-service/catalogs 로 상품 목록을 조회한다. 실습 설정에서는 data.sql 에 초기 상품 세 개를 넣고, 테이블 생성이 끝난 다음 데이터가 삽입되도록 초기화 순서를 맞춘다. 조회된 엔티티는 응답 객체로 바꾸어 200 OK 와 함께 반환한다. 주문 서비스 : POST /order-service/{userId}/orders 는 주문을 생성하고 201 Created 를 반환한다. GET /order-service/{userId}/orders 는 해당 사용자의 주문 내역을 조회하고 200 OK 를 반환한다. 주문 ID는 UUID로 만들고, 주문 총액은 수량과 단가를 곱해 계산한다. 현재 연동 범위 : 사용자 서비스의 상세 응답에는 orders 필드가 있지만, 사용자 서비스가 주문 서비스를 호출하는 기능은 아직 구현되지 않았다. 따라서 사용자 상세 조회의 orders 는 빈 리스트로 표시된다. 주문 내역 자체는 주문 서비스의 조회 API로 확인할 수 있다. 두 서비스의 데이터를 합치는 작업은 이후 단계다. 새롭게 알게 된 점 : 응답 객체에 orders 필드를 추가하는 것과 실제 주문 서비스에서 데이터를 가져오는 것은 별개의 작업이다. 서비스 간 호출이 연결되기 전까지는 필드만으로 주문 내역이 채워지지 않는다. 3. 실습 / 적용 직접 해본 것: 학습 내용의 실습 순서를 사용자·카탈로그·주문 서비스 설정 -> 유레카 등록 -> 게이트웨이 라우팅 -> API 호출 -> 각 H2 데이터 확인으로 정리했다. 개인 환경에서 직접 실행했다는 기록은 없어, 아래 결과는 제시된 테스트 흐름을 기준으로 적었다. 회원 가입 요청에는 이름·이메일·비밀번호를 JSON으로 보내고, 응답에 비밀번호가 포함되지 않는지 확인한다. 카탈로그 조회로 초기 상품 데이터를 확인한 뒤, 주문 생성과 사용자별 주문 조회를 순서대로 호출한다. 결과: 회원 가입과 주문 생성은 새 리소스를 만들므로 201 Created , 목록 및 상세 조회는 200 OK 로 응답하도록 구성된다. 주문 서비스의 사용자별 조회에서는 주문 내역을 확인할 수 있지만, 사용자 서비스의 상세 응답에 있는 orders 는 아직 빈 리스트다. 4. 문제와 해결 막힌 부분: Spring Security를 추가하면 회원 가입처럼 로그인 전에 사용해야 하는 경로까지 인증이 필요해질 수 있다. 사용자 상세 조회에서 orders 필드를 만들었는데도 주문 내역이 보이지 않는다. 해결 방법: SecurityFilterChain 에서 회원 가입과 필요한 공개 경로를 permitAll() 로 지정하고, 인증이 필요한 경로만 보호한다. 비밀번호는 BCrypt로 해시해 저장한다. 현재는 사용자 서비스가 주문 서비스를 호출하지 않으므로 orders 가 빈 리스트인 것이 예상된 결과다. 다음 단계에서 사용자 서비스의 주문 조회 호출을 구현하고, 주문 서비스 응답을 ResponseUser.orders 에 넣어야 한다. 5. 다음에 할 일 강의 자료 복습 실습코드 복습 github commit/push 하기