728x90 Kotlin Spring37 9) Kafka 기반 도메인 분리 (4) Transactional Outbox 패턴이란? 1. CAP 이론 이란? 1) 정의 - 분산 시스템에서 동시에 만족할 수 없는 세 가지 특성을 설명하는 이론 - 2000년 Eric Brewer가 제안 → "Brewer’s theorem" 2) 세 가지 요소 - C (Consistency, 일관성) : 모든 노드가 동시에 같은 데이터를 보며, 어떤 노드에서 읽든 항상 최신 데이터가 보장됨 - A (Availability, 가용성) : 모든 요청에 대해 항상 응답을 돌려줌, 다만 최신 데이터일 필요는 없음 - P (Partition Tolerance, 파티션 허용성) : 네트워크 장애나 노드 분리 상황(P.. 2025. 9. 5. 9) Kafka 기반 도메인 분리 (3) Saga 패턴이란? 1. Saga 패턴이란? : Saga 패턴은 분산 트랜잭션을 여러 개의 로컬 트랜잭션(Local Transaction) 시퀀스로 나누어 처리하고, 만약 실패 시 보상(Compensation) 작업을 통해 전체 일관성을 맞추는 패턴.2. 동작 방식 1) 하나의 비즈니스 프로세스 = N개의 로컬 트랜잭션 2) 각 로컬 트랜잭션은 자신의 DB에서 커밋됨 → 분산 락 불필요 3) 중간에 실패하면, 이미 완료된 트랜잭션을 보상 트랜잭션으로 되돌림 3. 구현 방식 1) Choreography (코레오그래피) - 이벤트 기반 - 각 서비스가 이벤트를 발행하고, 다른 서비스가 그 이벤트를 구독하여 다음 트랜잭션 실행 - 장점: 단순,.. 2025. 9. 5. 9) Kafka 기반 도메인 분리 (2) 결제 시 쿠폰도메인을 완전하게 분리하기 1. 도메인 분리를 왜 해야할까?(feat. 트랜젝션 분리) 2. Kafka 를 도메인 분리에 이용방법은? 3. 분리했을때 발생되는 문제점? kafka 를 통한 정합성보장 롤백처리 2025. 9. 5. 9) Kafka 기반 도메인 분리 (1) Kafka 란? 1. Kafka 란? : Apache 재단에 등록된 오픈소스로써, 분산형 스트리밍, 대규모 트래픽처리, 대용량 데이터 처리를 원활하게 처리하기 Message Queue https://kafka.apache.org/ Apache KafkaApache Kafka: A Distributed Streaming Platform.kafka.apache.org 2. Kafka 최근 근황 및 구조 - kafka 의 구성은 main 의 역할인 kafka와 헬스체크 등 보조적인 역할인 zookeeper 가 있음.- Apache Kafka 3.3 버전부터는 KRaft 를 합의 프로토콜로 공식 지정 함.(자체 메타 관리 가능)- 4.0 버전부터는 Zookeeper 를 완전히 제거 함.- 하지만, 대규모 기업 고객 대부.. 2025. 9. 5. 8) Spring 캐시 (4) Redis 로 캐싱 관리 1. 기존 코드에서 수정이 필요한 내용 1) 추상화된 공통 API 제공 - @Cacheable, @CachePut, @CacheEvict, @Caching 같은 어노테이션을 제공 - 개발자는 캐시 라이브러리(Caffeine, Redis, Ehcache 등)를 몰라도 동일한 방식으로 사용 가능 2) 기존 소스 위치 2. 구현체만 Caffeine 에서 Redis 로 변경 Spring 캐시로 인해 추상체는 그대로 둔채 구현체만 변경가능! 2025. 9. 5. 8) Spring 캐시 (3)redis란? 1. Redis 란? : C언어로 구현된 Key value 기반의 data 저장소(nosql) 이자, pub sub 이 지원 되는 Message Queue 2. Redis 는 어떻게 동작할까? : Redis 핵심 서버 엔진은 단일 쓰레드, 논블로킹 이벤트 루프로 동작 ( 클라이언트 요청 → 이벤트 루프 → 명령 실행 → 응답 하는 구조임) - 이벤트 루프란? 1) 클라이언트가 요청을 보냄 → 소켓 이벤트 감지 2) 이벤트 루프가 해당 명령을 싱글 스레드에서 바로 실행 (대부분의 명령은 메모리 연산이므로 바로 처리 가능) 3) 처리 결과를 바로 클라이언트 소켓에 기록 (별도 스레드 없이도 논블로킹 소켓 사용 가능) .. 2025. 9. 5. 8) Spring 캐시 (2)분산 캐시란? 1. 로컬 캐시의 한계 1) 데이터 불일치(Inconsistency) - 서버 A, B, C가 각각 로컬 캐시를 들고 있을 경우, A에서 데이터가 갱신되더라도 B, C 캐시는 여전히 옛 데이터를 유지 - 분산 환경에서는 캐시 갱신 전파 불가능 2) 메모리 한계 - 캐시 데이터가 많아질수록 JVM Heap / 애플리케이션 메모리 부족(OutOfMemoryError 위험) - GC 부하 증가(애플리케이션 성능 저하로 까지 이어질 수 있음) 3) 확장성(Scalability) 부족 - 서버가 늘어날수록 각 서버가 동일한 데이터를 중복 캐싱(메모리 낭비) - 서버 수평 확장(Scale-out) 환경에서.. 2025. 9. 2. 8) Spring 캐시 (1) HomeBody 상품 리스트 구현 내 "로컬 캐싱" 추가 1. 로컬 캐시란? - 서버 내부 메모리(Heap) 에 데이터를 캐싱하는 방식. - 대표적으로 Caffeine, Guava, EhCache 같은 라이브러리를 사용. - 장점 1) 낮은 지연 시간: DB나 Redis까지 가지 않고 바로 응답 2) 구현 단순: 라이브러리 import 후 간단하게 적용 가능 3) 추가 비용 없음: 별도 캐시 서버 필요 없음 2. 스프링 캐시는? 1) 추상화된 공통 API 제공 - @Cacheable, @CachePut, @CacheEvict, @Caching 같은 어노테이션을 제공 - 개발자는 캐시 라이브러리(Caffeine, Redis, Ehcache 등)를 몰라도 동일한 방식으로 .. 2025. 9. 2. 7) 주요 기능 개발(Back-end) 주요 기능 개발(Back-end)1. 로그인 로그아웃 2. Home body - 최초 진입 시 표시 되는 화면을 위한 기능 3. 상품(product) - 사용자가 상품조회(상품정보, 가격정보, 재고수량) 4. 장바구니(cart) - 상품을 선택하여 장바구니로 저장 - 장바구니 조회 5. 주문서(order) - 장바구니의 상품을 주문 하기위한 주문서 - Spring Feign을 이용하여 도메인 분리하기(cart 정보 가져오기) 6. 주문서 상세(orderDetail) - 주문서에 어떤 상품이 담겼는지 상품 detail 정보 (주문서가 총 정보가 기입되어있는 Header의 역할이고 주문서 상세는 Body의 역할) 7. 쿠폰(coupon) - .. 2025. 9. 2. 6) 개발 architecture (5) 강의용 Architecture 1. 강의에서 사용하는 아키텍처는? : 도메인 별로 분리를 고려하여, 레이어드 아키텍처와 EDA, 클린아키텍처(일부)를 종합하여 설계2. 새로운 Architecture 를 적용한 배경 1) 도메인 구분없이 개발할 경우 거대한 강결합이 발생할 수 있는 구조로 개발된다.3. 패키지 아키텍처 구조 및 Layer 설명presentation ├── api │ ├── controller // REST/gRPC 등 외부 요청 진입점 │ └── dto // Controller용 DTO (Request/Response) └── event │ └── consumer // Kafka, RabbitMQ 등 이벤트 수신 처리.. 2025. 9. 1. Spring Boot warm up 순서 1. JVM & SpringApplication 시작 - main() → SpringApplication.run() 호출 - Spring Boot 내부에서 ApplicationContext, Environment 준비 2. Environment 준비 - application.yml / application.properties / OS env / JVM args 로드 - 이때 Redis, Kafka, DB의 연결 정보(URL, username, password, cluster info 등) 도 Environment에 로드됨 - 어떤 profile(local, dev, prod)을 쓸지도 결정됨 3. ApplicationContext 생성 & BeanDefinition 등록 .. 2025. 8. 31. 6) 개발 architecture (4) EDA(Event-Driven Architecture) 패턴 1. EDA 정의 (Event-Driven Architecture) : 이벤트 기반 아키텍처는 시스템 내 컴포넌트들이 이벤트를 중심으로 상호작용하도록 설계된 아키텍처 패턴 1) 한 서비스가 상태 변화나 특정 행동을 이벤트로 발행(publish) 2) 다른 서비스는 그 이벤트를 구독(subscribe) 하여 필요한 작업 수행 3) 전체 패키지 구조를 정하는 다른 아키텍처와는 달리, EDA는 타 아키텍처 기반에서 강결합과 비동기 등의부족한 부분을 보완할 수 있는 개발 패턴 중 하나 임 목표: "서비스 간 결합도를 낮추고, 확장성과 비동기 처리를 쉽게 만드는 것" 2. 핵심 구성 요소구성 요소역할Event시스템에서 발생한 사건 또는 메시지 (ex: O.. 2025. 8. 31. 6) 개발 architecture (3) 클린 아키텍처(Clean Architecture) 1. 클린 아키텍처 정의 : 클린 아키텍처는 도메인 중심 아키텍처로, 1) 비즈니스 규칙(Entity, Use Case)을 가장 안쪽에 두고, 2) 외부 의존성(웹, DB, 메시지 브로커, 프레임워크)을 바깥쪽에 둠 3) 의존성은 항상 안쪽으로만 향한다 (DIP: Dependency Inversion Principle)즉, 외부 기술은 교체 가능하고, 핵심 도메인은 독립적이라는 것이 핵심! 2. 구조 설명 1) Entities (Domain Model) - 순수한 비즈니스 규칙 (ex. Concert, User, Order 등) - 프레임워크에 전혀 의존하지 않는 POJO/POKO 2) Use Cases (Application S.. 2025. 8. 31. 6) 개발 architecture (2) 헥사고날 아키텍처(Hexagonal Architecture) 1. 레이어드 아키텍처 개념 : 애플리케이션의 비즈니스 로직(도메인)과 외부 시스템을 철저히 분리2. 계층(Layer) 구조 1) 포트(Port) : 외부와 통신하기 위한 인터페이스 2) 어댑터(Adapter) : 포트를 구현하는 외부 기술 구체화(포트의 구현체이자, Controller 역할 수) 3) 핵심 도메인(Core Domain) : 순수 비즈니스 로직, 외부 의존 없음 (레이어드 아키텍처의 도메인과 동일) com.example ├─ user │ ├─ domain │ │ ├─ User.kt │ │ └─ UserDomainService.kt │ ├─ .. 2025. 8. 31. 6) 개발 architecture (1) 레이어드 아키텍처(Layered Architecture) 1. 레이어드 아키텍처 개념 : 레이어드 아키텍처는 전통적인 애플리케이션 구조로, 관심사의 분리 (Separation of Concerns)에 기반해 계층을 나누는 패턴. 2. 계층(Layer) 구조 1) Presentation Layer (Controller, UI) - 사용자의 요청을 받아서 응용 계층(비지니스 계층)에 전달 - DTO 변환, HTTP 응답 처리 2) Application Layer (Application Service) - (선택) - 비즈니스 흐름(Use Case) 조합 - 도메인 로직을 직접 가지지 않고 도메인 객체를 조립 및 조율 3) Domain Layer.. 2025. 8. 31. 5) 요구사항 분석 및 ERD 설계 1. 요구사항 분석현업에서 개발을 진행할 때 요구사항 분석 과정 없이 바로 개발부터 진행하는 주니어 개발자들이 눈에 많이 보입니다. 개발 이후 막히거나, 기획쪽 수정될 내용을 뒤늦게 찾게되면, 기존 개발했던 로직들을 전반적으로 수정해야해서 개발 시간을 더 달라는 개발자들이 있습니다. 그럴때 저는 반대로 질문합니다.요구사항 분석을 제대로 하셨나요?개발 전 요구사항에 명시되어 있는데요? 개발자 중 어떤 개발자는 질적으로도 속도적으로도 잘하는 개발자가 있는 방면, 어떤개발자는 코드 리뷰에도 수정될 부분이 많이 발생하고 개발시간도 느리게 개발하는 사람들이 있어요.그런데 그 중 원인을 분석해보면, 요구사항분석을 개발전에 진행했냐? 안했냐로 구분되기도 합니다.val 개발자에게_좋지_않은_습관 = "요구사항을 제대로.. 2025. 8. 31. 4) Spring @controller, @service, @repository 스프링은 기본적으로 레이어드 아키텍처(Layered Architecture)를 따르는데, 보통 다음 3단계로 나뉨 1. Controller(라우팅 역할) : “문 앞에서 손님을 맞이하는 안내원” 1) 클라이언트(웹/앱) 요청을 받고, 어떤 서비스가 필요할지 결정 2) 비즈니스 로직은 직접 하지 않고, Service로 위임import org.springframework.web.bind.annotation.*@RestController@RequestMapping("/users")class UserController( private val userService: UserService) { @PostMapping fun createUser(@RequestBody .. 2025. 8. 29. 3) Spring 컨테이너, Bean 1. "Spring 컨테이너"란?“Spring 컨테이너는 커피숍의 바리스타와 같다” 1) 커피숍에선 손님이 주문하면, 바리스타가 재료를 조합해서 커피를 만들어 줌 2) 바리스타는 커피를 만들기 위해서 커피 원두, 우유, 시럽 등 필요한 재료들을 잘 보관, 관리함 3) 바리스타가 모든 걸 직접 만들고, 관리하니 손님은 그냥 주문만 하면 됨 4) 즉, Spring 컨테이너는 객체(Bean)를 생성하고, 관리하며, 필요할 때 꺼내주는 "바리스타" 같은 존재2. Bean 이란?Bean은 커피숍에서 만드는 ‘커피’ 한 잔' 1) Bean은 "Spring 컨테이너"가 관리하는 "객체" 2) 직접 new 해서 만드는 게 아니라, Spring이 대신 만들.. 2025. 8. 26. 2) Spring Boot란? (맛보기) 1. Spring 이란? : Spring Framework는 자바 기반의 엔터프라이즈 애플리케이션 개발을 위한 핵심 프레임워크로, IoC(제어의 역전)와 DI(의존성 주입), AOP 등을 통해 유연하고 확장성 있는 애플리케이션 개발을 지원하는 기술 2. Spring Boot 란? - Spring Boot는 Spring Framework를 더 쉽게 사용할 수 있도록 만든 도구. - 설정을 최소화하고, 빠르게 실행 가능한 애플리케이션을 만들 수 있음. - 핵심 특징 1) 자동 설정(Auto Configuration): 의존성 기반 자동 Bean 등록 2) 내장 서버(Embedded Server): Tomcat/Jetty 등을 내장 → 별도.. 2025. 8. 25. 1. (2) Kotlin 주요 문법 1. 변수 선언 var name: String = "Bill" // 값 변경 가능val age: Int = 25 // 값 변경 불가능 (final)var nickname: String? = null - var: 가변 변수 - val: 불변 변수 (초기화 후 값 변경 불가 - ? = null: nullable 변수 선언 2. 형변환 val number: Int = 10val text: String = number.toString() - Kotlin은 명시적 형변환만 지원 (toInt(), toString() 등) 3. 함수 선언//일반함수fun sum(a: Int, b: Int): Int { return a + b}//단일 표현식 함수fun sum(a: I.. 2025. 8. 25. 이전 1 2 다음 728x90
