유성

[클라우드 네이티브] 1편: 온프레미스에서 클라우드 네이티브로: 로깅 아키텍처(ELK) 설계과거 온프레미스 환경에서 고가용성을 갖춘 ELK 스택을 구축하고 유지하는 것은 꽤나 어려운 작업이였다.단순히 서버를 띄우는 것을 넘어, 인프라와 애플리케이션 사이의 수많은 '수동 연결 고youseong.tistory.com 이전 글에서는 온프레미스 환경을 클라우드 네이티브로 전환하는 이론적 배경을 살펴보았다면,이번 실전 편에서는 Helm을 통해 실제 ELK 스택을 구축하고, 직접 부하를 가해 파이프라인이 얼마나 버티는지 검증해 본다. Helm Chart 저장소 GitHub - youseonghyeon/k8s-blogContribute to youseonghyeon/k8s-blog development by crea..

개발자라면 항상 고민하는 문제가 있다."빠르게 변하는 비즈니스 요구사항 속에서도, 어떻게 시스템의 안정성을 지킬 것인가?" 이다. 테스트 코드는 그 질문에 대한 가장 확실한 대답이였다.그러나 현실적으로 '커버리지 100%'를 채우는 것이 능사는 아니다. 개발자에게 시간은 한정적이다. 오늘은 실무에서 느낀 테스트 코드의 진짜 목적과, 복잡한 분산 환경에서 테스트를 작성하며 마주한 난관들에 대해 이야기해보려 한다. 1. 왜 테스트 코드를 작성해야 하는가?테스트 코드의 장점으로 '버그 예방'을 생각할 수 있으나, 내가 경험한 가장 큰 가치는 '과감한 리팩터링을 가능하게 하는 안전장치' 이다.지금 막 시작한 프로젝트라고 한다면 테스트 코드를 쓴다는 것이 어려울 수 있다. 기능이 몇번 사용되고 버려진다거나 구조가..

이 글에서는 Kafka 기반의 대규모 채팅 서비스를 직접 설계하고 구현하며 마주친 문제와, 이를 어떻게 해결했는지를 기록합니다.인프라 아키텍처부터 코드 레벨의 구조 개선, 서비스의 생명주기 까지 순차적으로 회고합니다. 1. 서비스 구성을 위해 정해야 할 것각 노드간 통신을 어떻게 해야할지?단일 노드 사용 시 성능 한계와 노드 다운에 대한 안정성 문제가 있어, 멀티 노드로 구성하겠습니다. 그럼 멀티 노드간에 사용자에 대한 통신 문제를 아래 '짱구' 와 '철수' 예제로 보겠습니다.(Node는 서버 또는 Pod를 의미하며, client는 현재 연결된 connection을 의미합니다.) 위와 같이 Node를 구성 할 경우 '짱구'와 '철수'는 각기 다른 Node를 통신하기에 메시지 송수신이 불가능합니다. 짱구와..

Kafka의 안전성과 복구 전략Apache Kafka는 대용량의 실시간 데이터 스트림 처리를 위한 분산 메시징 시스템입니다. Kafka의 안정성과 높은 가용성을 위해 여러 가지 전략과 구성 요소가 사용됩니다. 본 글에서는 Kafka의 주요 안전성 및 복구 전략에 대해 알아보겠습니다. 1. 데이터 복제Kafka는 데이터의 내구성을 보장하기 위해 각 Topic의 파티션을 여러 개의 복제본으로 구성합니다. 각 파티션은 주 브로커(리더)와 여러 팔로워 브로커(복제본)으로 구성됩니다.Producer가 데이터를 전송하면, 해당 데이터는 주 브로커에 저장되고, 주 브로커는 복제본 브로커들에게 데이터를 복제하여 저장합니다. 이렇게 복제된 데이터는 클러스터 내에 여러 브로커에 분산 저장되므로, 하나의 브로커가 장애가 발..

1. EOS의 개념과 중요성EOS (Exactly Once Semantics)는 메시지 전송에서 메시지가 한 번만 전송되고 처리되는 것을 보장하는 전송 보증입니다. 다시 말해, 송신자와 수신자 사이에 데이터의 중복 또는 손실 없이 데이터가 한 번만 전송되는 것을 의미합니다. EOS의 중요성:데이터 중복성 제거: 중복된 메시지는 데이터의 무결성을 해칠 수 있습니다. EOS는 이를 방지하여 데이터의 정확성을 보장합니다.데이터 손실 방지: 손실된 메시지는 시스템의 안정성을 위협합니다. EOS는 모든 메시지가 제대로 전달되도록 보장합니다.자원 효율성: 중복 메시지를 처리하는 데 필요한 자원을 절약하여 시스템의 효율성을 높입니다.  2. Kafka에서 EOS를 어떻게 구현하는지Apache Kafka는 0.11.0..

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

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

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