To Be Continued

기능 개요카카오 모빌리티 Directions API를 활용하여 허브 간 거리와 소요시간 계산계산된 결과를 기반으로 물류 배송 경로 자동 생성처리 흐름-> Kakao API 호출-> 거리 / 시간 계산-> 허브 간 경로 저장핵심 구현외부 API 호출(RestTemplate)https://apis-navi.kakaomobility.com/v1/directions응답 데이터 변환distance → km 변환 duration → 분 변환경로 저장sourceHub ↔ destinationHub (양방향 저장)

Redis 캐싱을 적용한 이유허브 프로젝트에서 다음과 같은 특징이 있었다.허브 정보 -> 거의 변경되지 않음허브 간 이동경로 -> 거의 변경되지 않음조회는 자주 발생이런 데이터는 매번 DB를 조회할 필요가 없기 때문에 Redis를 이용한 캐싱을 적용했다.즉, 조회 성능 개선 + DB 부하 감소가 목적이다.전체 구조구조는 다음과 같다DB -> 실제 데이터 저장Redis -> 조회 성능을 위한 캐시client -> service -> Redis ->있으면 반환 없으면 DB조회 후 Redis 저장 적용 방식조회@Cacheable(value = "hubs", key = "#hubId")동작 : 1. Redis에서 먼저 조회2. 있으면 바로 반환3. 없으면 DB조회4. 결과를 Redis에 저장수정@CacheE..

Docker Compose 란?Docker Compose는 여러 개의 컨테이너로 이루어진 애플리케이션을 하나의 YAML 파일로 정의하고, 한번에 생성, 실행, 종료할 수 있게 해주는 도구다. 보통 compose.yml파일에 서비스, 네트워크, 볼륨 등을 정의하고 docker compose up같은 명령으로 전체 스택을 실행한다.왜 사용하는가?백엔드 프로젝트를 실행할 때 애플리케이션 서버만 필요한 경우는 드물고, DB, Redis, 메시지브로커같은 여러 컨테이너가 함께 필요한 경우가 많다. Compose를 사용하면 이 구성을 파일로 남길 수 있어서 팀원이 같은 환경을 쉽게 재현할 수 있고, 프로젝트 루트에 두면 버전 관리도 가능하다.핵심 개념Compose 파일에서는 애플리케이션을 이루는 요소를 주로 ser..

build.gradle을 모듈별로 나누기로 한 이유 오늘은 build.gradle을 전역으로 둘지, 각 모듈마다 따로 둘지 고민했다.처음에는 한 곳에서 공통으로 관리하면 편할 것 같았지만, 전역으로 두면 어떤 파트는 사용하는 설정이나 의존성을 다른 파트는 사용하지 않는 상황이 생길 수 있다는 점이 걸렸다.그래서 최종적으로는 각 모듈에 필요한 설정만 따로 두는 방식으로 정리했다.왜 모듈별로 나누기로 했는가전역 build.gradle로 모든 설정을 한 번에 관리하면 편해 보이지만,실제로는 모든 모듈이 동일한 의존성이나 설정을 필요로 하지 않는다. 예를 들어 어떤 서비스는 웹 관련 기능이 필요하고,어떤 서비스는 데이터베이스만 필요할 수 있다.그런데 이를 전역으로 한꺼번에 묶어버리면 사용하지 않는 설정까지 함께..

Zipkin이란?Zipkin은 분산 시스템 환경에서의 하나의 요청이 여러 서비스들을 거치며 어떻게 처리되는지 추적할 수 있게 해주는지 추적할 수 있게 해주는 분산 트레이싱 도구이다.MSA 구조에서 서비스 간 호출 흐름을 시각적으로 확인할 수 있도록 도와준다.왜 사용하는가?MSA 환경에서는 하나의 요청이 여러 서비스들을 거치며 어떻게 처리된다.예시Client -> Gateway -> Order -> Payment -> Delivery이때 문제가 발생하면 어디서 지연이 발생했는지, 어떤 서비스에서 에러가 났는지 파악하기 어렵다.Zipkin을 사용하면 요청의 전체 흐름과 각 단계의 처리 시간을 확인할 수 있다. 핵심 개념Trace - 하나의 요청 전체 흐름을 의미한다.Span - 각 서비스에서 수행되는 작업 ..

멀티 모듈과 멀티 레포의 차이멀티 모듈은 하나의 레포지토리 안에서 여러 모듈로 코드를 나누는 구조이고, 멀티레포는 프로젝트를 여러개의 레포지토리로 나누는 방식이다.멀티 모듈은 하나의 build.gradle로 관리되기 때문에 모듈 간의 의존성 관리가 쉽고, 멀티 레포는 각 레포가 독립적이기 때문에 완전히 분리된 개발이 가능하다. 모놀리식과의 관계모놀리식은 구조가 아니라 배포 방식이다.애플리케이션이 하나로 빌드되고 하나로 배포된다면 모놀리식이다.이때 내부가 멀티모듈인지 싱글모듈인지 여부는 중요하지 않다.반대로, 모듈별로 따로 실행하고 배포한다면 MSA 형태가 된다. 마무리그동안 멀티 모듈과 멀티 레포를 같은 기준으로 생각해 공부할 때 많이 헷갈렸던것 같다.이제는 각자 다른 기준으로 나눠서 이해해야 한다는걸 ..

CodeRabbit이란?CodeRabbit은 Pull Request(PR)에 대해 자동으로 코드 리뷰를 수행해주는 AI 기반 코드 리뷰 도구이다.PR이 생성되거나 업데이트되면 변경된 코드(diff)를 분석하여 개선 사항, 버그 가능성, 코드 스타일 등을 자동으로 피드백해준다. 적용방법CodeRabbit을 GitHub 저장소에 연동하면 별도의 복잡한 설정 없이 PR 기반으로 동작한다.설정 예시language: "ko-KR"reviews: auto_review: enabled: true base_branches: - ".*" profile: "assertive"설정 설명language : "ko-kr"리뷰 코멘트를 한국어로 생성auto_review.enabled:truePR 생성/수정..

Kafka란?Apache kafka는 서비스 간 데이터를 메시지로 전달하고 저장하는 분산 스트리밍 플랫폼이다.Kafka를 사용하지 않는 구조 특징서비스 간 직접 호출 (REST API) 방식요청 → 응답 구조 (동기 처리)한 서비스 장애 시 연쇄 장애 발생 가능문제점서비스 간 강한 결합트래픽 증가 시 병목 발생장애 전파 위험요청 지연 시 전체 시스템 영향Kafka를 사용하는 구조특징서비스 간 메시지 기반 비동기 처리Producer / Consumer 구조메시지를 kafka에 저장 후 각 서비스가 소비장점서비스 간 느슨한 결합한 서비스 장애가 다른 서비스에 직접 영향 없음트래픽이 몰려도 kafka가 버퍼 역할 수행확장성 뛰어남언제 Kafka가 필요한가서비스 간 의존도를 줄이고 싶을 때트래픽이 많고 확장이 ..

Kafka란?Apache kafka는 대용량 데이터를 실시간으로 처리하기 위한 분산 스트리밍 플랫폼이다.데이터를 메시지 형태로 저장하고, 여러 시스템 간에 빠르게 전달할 수 있도록 도와준다. Kafka를 사용하는 이유서비스 간 비동기 통신 가능대용량 데이터를 높은 처리량으로 안정적으로 처리데이터 유실 방지를 위한 내구성 보장서비스 간 결합도를 낮추는 느슨한 결합 구조Kafka의 핵심 구성 요소3-1 Producer데이터를 Kafka로 보내는 역할메시지를 특정 Topic으로 전송3-2 ConsumerTopic에 저장된 데이터를 가져가는 역할여러 Consumer가 동시에 데이터를 처리 가능3-3 BrokerKafka 서버메시지를 저장하고 전달하는 역할3-4 Topic메시지를 분류하는 단위3-5 Partiti..

FeignClient란?FeignClient는 Spring Cloud에서 제공하는 선언형 HTTP 클라이언트이다.다른 서버의 API를 호출할 때 RestTemplate이나 WebClient처럼 직접 요청 코드를 길게 작성하지 않고, 인터페이스 형태로 간단하게 외부 API 호출을 정의할 수 있게 해준다. FeignClient를 사용하는 이유서비스가 여러개로 나뉘어 있는 환경에서는 한 서비스가 다른 서비스의 API를 호출해야 하는 경우가 자주 발생한다.이때 FeignCLient를 사용하면 HTTP호출 코드를 줄일 수 있고 인터페이스만으로 API 호출을 정의할 수 있으며 가독성이 좋아지고 유지보수가 편해진다. 즉, 서비스 간 통신을 더 간결하고 직관적으로 작성하기 위해 사용한다. FeignClient의 특징인..