유성

Kafka Streams의 개념 및 특징Kafka Streams은 Kafka 기능 위에 구축된 라이브러리로, 실시간 데이터 스트림을 처리하고 분석하기 위한 간단한 방법을 제공합니다. 그 중 주요 특징은 다음과 같다고 합니다. 분산 처리: Kafka Streams 어플리케이션은 분산시스템으로 쉽게 확장될 수 있습니다.상태 저장: 내부적으로 RocksDB와 같은 내장 상태 저장소를 활용하여 처리 중인 데이터를 유지합니다.탄력성과 내결함성: 어플리케이션 장애나 Kafka 클러스터의 변화에 강하게 설계되어 있습니다. 사실 위에 내용을 읽어봐도 크게 와닿지가 않아서 Kafka와의 차이점을 적어보겠습니다.처리 유형Kafka: 기본적인 메시지 전송과 저장에 초점을 맞춥니다. 메시지를 생성하고, 저장하며, 다른 시스템..

Kafka 아키텍처Apache Kafka는 분산 스트리밍 플랫폼으로, 대용량의 데이터를 처리하고 실시간 데이터 스트리밍을 지원하는데 특화되어 있습니다. Kafka의 아키텍처는 다음과 같은 주요 요소로 구성됩니다. 1. 브로커 (Broker) : 데이터를 저장하고 관리하는 주체데이터를 저장하고 관리하는 주체로서 Kafka 클러스터의 핵심 구성 요소입니다. 브로커는 Topic에 쌓인 데이터를 Partition 단위로 관리하며, 여러 개의 브로커가 클러스터를 형성하여 데이터를 분산하여 처리합니다. 각 브로커는 자신이 관리하는 Topic의 데이터를 저장하고, Consumer에게 데이터를 전달합니다.2. 토픽 (Topic) : 여러 파티션의 집합 (데이터가 보관되는 장소)여러 파티션의 집합으로 데이터가 보관되는 ..

Apache Kafka는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 오픈 소스 분산 이벤트 스트리밍 플랫폼(distributed event streaming platform)입니다.Kafka를 사용 목적대용량 데이터 처리 : Kafka는 대용량 데이터를 효율적으로 처리할 수 있으며 높은 처리량과 확장성을 제공합니다.실시간 스트리밍 : 실시간 데이터 스트리밍을 지원하여 실시간 애플리케이션 개발에 용이합니다.데이터 파이프라인 : 다양한 시스템 간에 데이터를 안정적으로 전송하고 연결하는 데 Kafka를 사용할 수 있습니다.내구성과 보존 : 데이터를 안전하게 보존하고 장애가 발생해도 데이터의 유실을 방지합니다.다양한 애플리케이션과 통합 : Kafka는 다양한 형..

의존관계(Dependency)가 무엇인지부터 알아보겠습니다. 셰프와 재료 공급업체를 예로 들겠습니다. 셰프 (클래스 A): 셰프는 요리를 만들기 위해 식재료가 필요합니다. 셰프가 재료 없이는 요리를 만들 수 없으므로, 재료에 의존하고 있습니다.쿠팡 재료 공급업체 (클래스 B): 재료 공급업체는 셰프가 필요로 하는 재료를 제공합니다.이처럼 셰프 -> 재료 공급업체 의 의존 관계가 형성되었습니다. 이를 코드로 나타내면 다음과 같습니다. public class Chef { private CoupangIngredientSupplier coupangIngredientSupplier; public Chef() { this.coupangIngredientSupplier = new Coupang..

Redis 트랜잭션 에 대하여 알아보겠습니다. 우선 트랜잭션이 이루어지는 순서는 다음과 같습니다.MULTI : 트랜잭션을 시작합니다. 이후에 실행되는 명령어는 모두 이 트랜잭션에 속합니다.명령어 저장 : MULTI 이후에 실행되는 멸영어들은 순차적으로 기록되어 트랜잭션 로그(명령어 큐)에 저장됩니다. 여기에 저장된 명령어들은 실행되지 않습니다.EXEC : 트랜잭션을 실행합니다. EXEC 명령어를 호출하면 트랜잭션 로그(명령어 큐)에 저장된 순서대로 명령어들을 실제로 실행합니다.트랜잭션 결과 : 만약 중간에 오류가 발생하거나, WATCH로 감시한 키가 변경되었다면, EXEC가 호출되기 전까지의 트랜잭션의 모든 명령어들은 취소되어 실행되지 않은 것처럼 처리됩니다. 트랜잭션의 주의사항Redis는 단일 스레드로..

Redis는 메모리 기반 데이터베이스입니다. 하지만 데이터 소멸의 문제를 피하기 위해 영속성 기능을 제공합니다. Redis는 두가지 전략을 같이 사용하며 데이터를 Disk에 영속화 합니다. 1. 스냅샷(Snapshot) 방식 Redis는 주기적으로 또는 변경 사항이 있을 때마다 데이터를 스냅샷 파일(.rdb)로 저장합니다.  .rdb 파일은 Redis Database의 약자로 바이너리 형식이며 Redis 서버가 재시작될 때 또는 데이터를 복구할 때 사용합니다. 또한, Redis 스냅샷은 Redis 저장소 전체를 스냅샷하는 방법입니다. 스냅샷은 Redis 서버의 현재 상태를 모두 포함하는 것으로, 메모리에 있는 모든 데이터를 디스크에 저장합니다. 스냅샷은 Redis 데이터베이스의 모든 키-값 쌍을 포함하여..

Redis(Remote Dictionary Server)는 인메모리 DB로서 고성능 key-value 데이터베이스입니다.Redis는 데이터를 디스크 기반이 아닌 메모리 기반 저장 방식을 채택하여 매우 빠른 응답 속도를 제공합니다. 이러한 특징은 데이터베이스에 자주 액세스해야하는 세션 캐싱, 메시징 기능 등에 이상적입니다.Redis 사용 목적 Reids를 사용하는 이유는 다음과 같습니다.속도 : 데이터를 디스크에 저장하는 대신 메모리에 저장하여 빠른 응답 속도를 제공합니다.간단한 구조 : Redis는 문자열, Hash, List, Set, SortedSet 등 과 같은 간단한 데이터 구조를 지원합니다.영속성 지원 : 인메모리 DB임에도 불구하고, 시스템의 전원이 차단되었을 때도 데이터가 증발하지 않습니다...

시스템이 성장함에 따라 단일 DB에서는 성능에 저하 또는 장애가 발생할 수 있습니다.이때 DB 구성 방식으로써 해결할 수 있는 방법을 순서대로 설명하겠습니다. * Scale Up첫 번째로 고려할 방법은 "스케일 업"입니다. 이는 기존의 컴퓨터 하드웨어(CPU, RAM, Disk 등)를 더 강력한 것으로 교체하는 방식으로, 기존의 애플리케이션 코드나 데이터베이스 구조를 크게 변경하지 않아도 됩니다.스케일 업은 초기 단계에 고려되는 이유는 기존 DB를 그대로 사용할 수 있으므로 하드웨어 리소스를 제외한 추가 비용이 들지 않기 때문입니다.그러나 Scale Up에는 한계가 있고, 시스템이 더 커진다면 다음 방법을 고려해야 합니다.* Scale Out다음으로 고려할 방법은 "스케일 아웃"입니다. 이는 데이터베이스..

메시지 기반 아키텍처는 대규모 및 복잡한 시스템에 아주 잘 맞는 설계 방식입니다. 이유는 다음과 같습니다. 1. 디커플링메시지 기반 아키텍처는 서비스간 결합도를 낮춥니다. 온라인 쇼핑몰로 예를 들겠습니다. 주문 시스템, 재고 관리 시스템, 배송 시스템 등 여러 서비스로 구성될 수 있습니다. 이 서비스들이 서로 밀접하게 연결되어 있다면, 각 시스템은 다른 시스템의 상태와 행동에 대해 알아야하며, 이는 시스템 간의 강한 결합을 의미합니다.예를 들어, 배송 시스템이 주문 시스템에 직접적으로 연결되어 있고, 주문이 이루어질 때마다 즉시 배송 프로세스를 시작한다면, 주문 시스템의 변경이 배송 시스템에 영향을 줄 수 있습니다. 주문 시스템에 문제가 발생하면 배송 시스템도 문제가 발생하거나, 주문 시스템의 로직이 변..

이 글에서는 HTTP 요청에서부터 ArgumentResolver가 어디서 작동하는지 전반적인 흐름과 원리를 살펴보려 합니다.저는 흐름을 알고 난 후 개발, 디버깅, 최적화 하는데 훨신 도움이 많이되어서 해당 파트를 넣었습니다. 만일 ArgumentResolver의 작동 방식에만 관심이 있으시다면, 3번으로 이동하셔도 좋습니다.그리고 ArgumentResolver를 이용한 개발은 아래 url을 참고해주세요.개발 : https://youseong.tistory.com/23구체적인 내용은 다음과 같은 순서로 구성되어 있습니다:1. ArgumentResolver를 이용한, 자주 사용되는 주요 어노테이션2. 요청부터 응답까지: HTTP 요청의 전체 흐름3. ArgumentResolver의 동작 원리아래로 스크롤하..