개발블로그임다

나의 말: CDN을 두는 이유가 뭘까, 실제 캐싱할 수 있는 데이터는 많이 없고 거의 서버로 넘어오는 구조에서?   ChatGPT의 말:아주 좋은 질문이야.“실질적으로 캐싱할 데이터가 별로 없는데, 왜 CDN을 두는가?”이건 실제로 많은 실무자들이 겪는 고민이기도 해.✅ CDN을 두는 이유: 꼭 캐시만이 전부는 아니다!CDN(Contents Delivery Network)은 단순히 "정적 파일 캐싱"만을 위한 게 아니라,네트워크 경로 최적화, 지연 시간 단축, 글로벌 유저 대응 등 여러 목적이 있어.📌 1. 캐싱 외에도 중요한 기능들기능설명지리적 근접성유럽 유저가 한국 서버에 직접 요청하는 대신, 유럽 CDN 노드가 중계해 RTT를 단축TCP 핸드쉐이크 최적화CDN이 사용자와의 커넥션을 유지하므로, 서..

✅ 느슨한 결합(Loosely Coupled)이란?💡 정의:컴포넌트(시스템 간)가 서로에 대해 최소한의 정보만 알고,직접 의존하지 않고, 독립적으로 동작할 수 있는 구조📌 느슨한 결합이 중요한 이유장점설명 확장성A → B, C, D로 쉽게 연결 가능유지보수성한 쪽 바뀌어도 다른 쪽 영향 적음장애 격리B가 죽어도 A는 메시지만 보내고 끝냄재사용성특정 서비스가 다양한 곳에 재활용 가능테스트 용이성모의(mock) 구성으로 단위 테스트 쉬움✅ Kafka는 왜 느슨한 결합 구조에 적합할까?Kafka는 발행-구독(Pub/Sub) 메시지 큐 시스템.즉, **생산자(Producer)**와 **소비자(Consumer)**가 직접 연결되지 않음.🔁 Kafka 기반 메시지 흐름[Service A] → Kafka Top..

Spring Boot Actuator란? 정의 어플리케이션의 상태와 여러지표들을 API로 제공 어플리케이션을 조작할 수도 있음( shutdown, restart, pause, ... ) 기타 정보를 더 알고싶으면 https://supawer0728.github.io/2018/05/12/spring-actuator/ 를 참고 하기 바란다. 사용법과 기능에 대한 자세한 소개가 있다. Actuator + Eureka를 이용한 무중단 서비스 구축 ( /actuator/shutdown 호출 시 ) 거래 가 진행중일 때 Shutdown(요구사항) 1. Eureka같은 Service Discovery와 연동 상황에서도 제거 한다고 알리고, 즉시 다른서비스에서 호출하지 않도록 하는가? OK => Eureka Clien..

[ Zuul 개요 ] RequestContext holds Request, response, state information and data for ZuulFilters to access and share. The requestContext lives for the duration of the request and is ThreadLocal. - ZuulFilter는 Pre -> Route -> Post 필터 순서로 Thread가 진행되는데 이때 쓰레드 안에 Local Storage 이용하여 필요한 데이터를 쉽게 전파하기 위하여 RequestContext 구현체를 사용한다. extensions of RequestContext can be substituted by setting the contextCla..

컨슈머 주요 옵션 bootstrap.servers 카프카 클러스터의 주소 fetch.min.bytes (df: 1 bytes) 한번에 가져올 수 있는 최소 사이즈로, 만약 가져오는 데이터가 지정한 사이즈보다 작으면 요청에 응답하지 않고, 데이터가 누적될 때 까지 기다린다. fetch.max.wait.ms(df: 500sec = 0.5sec) : fetch.min.bytes에 설정된 데이터보다 데이터 양이 적은 경우 요청에 응답을 기다리는 최대시간을 설정 group.id: 컨슈머가 속한 컨슈머 그룹의 id enable.auto.commit (df: true) 백그라운드로 주기적으로 오프셋을 커밋할지 안할지 설정하는 옵션 auto.commit.interval.ms (df: 5000ms = 5sec) : 주기..

프로듀서 주요 옵션 bootstrap.servers 카프카 클러스터는 기본적으로 마스터가 없는 구조이므로 클러스터 내 모든 서버가 클라이언트의 요청을 처리 할 수 있다. 그러므로, 하나의 서버가 장애가 나도 클라이언트는 자동으로 다른 서버로 재접속 한다. acks(default: 1) 프로듀서가 토픽 혹은 파티션의 리더에게 메시지를 보낸 후 요청을 완료하기 전 ack의 수. 0인 경우 : 서버로부터 완료됬다는 ack를 기다리지 않음 1인 경우 : 리더에 데이터가 기록되었는지만 확인 all 또는 -1 인 경우 :: 리더 뿐만 아니라 모든 팔로워로부터 데이터 기록 응답을 기다림. buffer.memory(default: 33554432 byte) : 프로듀서가 카프카 서버로 데이터를 보내기 전, 잠시 대기하..

카프카 디자인의 특징 확장이 쉬운 분산 시스템 페이지 캐시 페이지 캐시는 메모리에 있고, 공유할 수 있기 때문에, 카프카 클러스터를 같은 시스템, 서버에 구축하는것이 좋다. 배치 전송 처리 카프카에서는 작은 I/O가 빈번하게 일어나기 때문에 이러한 I/O들을 묶어 배치로 처리하는 방식을 취한다.(ex: 메시지 4개를 모은 후 한번만 I/O 작업을 한다.) 카프카 데이터 모델 토픽의 이해 파티션의 이해 토픽을 분할한 것 EX) 4개의 토픽을 보내는 상황에서 파티션이 1개라면, A->B->C->D 순서로 보내기 때문에 총 4초가 걸리는 반면, 프로듀서와 파티션을 늘려서 4개의 프로듀서가 각각 1개의 파티션에 메시지를 보내면, 4개의 메시지가 보내진다고 해도 1초밖에 안걸리게 된다. 파티션 확장의 단점 파일 ..

카프카 관리를 위한 주키퍼 분산 시스템을 설계 하다보면, 가장 문제점 중의 하나가 분산된 시스템간의 정보를 어떻게 공유할것이고, 클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 또한, 분산된 서버들간에 동기화를 위한 락(lock)을 처리하는 것들이 문제로 부딪힌다. 이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service)라고 하는데, Apache Zookeeper가 대표적이다. 이 코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보등을 유지하기 때문에, 코디네이션 서비스의 장애는 전체 시스템의 장애를 유발하기 때문에, 이중화등을 통하여 고가용성을 제공해야 한다. ZooKeeper는 이러한 특성을 잘 제공하고 있는데, 그런 이유로 이미 유명한..

카프카의 탄생배경 기존 end-to-end 연결 방식의 아키텍처의 문제점 통합, 중앙화된 전송 영역이 없어 end-to-end 연결이 갈수록 복잡해지므로 하나의 프로세스에 여러 데이터 시스템을 확인 해야 한다. 데이터 파이프라인 관리의 어려움, end-to-end를 연결하는 연결선 마저도 end-to-end 마다 제각기 다른 방식으로 구현될 수 있어 복잡도가 증가, 추후에 통합데이터 분석을위해 파이프라인들이 연결되어야 할 때 문제 발생. 이러한 배경에서 카프카는 다음과 같은 목표를 달성하기 위해 탄생하였다. 프로듀서와 컨슈머의 분리 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용 높은 처리량을 위한 메시지 최적화 데이터가 증가함에 따라 스케일 아웃이 가능하도록 한다. 카프카의 동작 방식과..

유레카 클라이언트가 유레카 서버에서 registry를 가져오는 방식. 유레카 서버에서는 default로 자신이 레지스트리 정보를 캐싱하여 주기 때문에 실제 정보를 얻어오는데 약간의 시간차가 있을 수 있다. 유레카 클라이언트는 등록 시, 곧바로 자신이 살아있다는 Status 정보를 서버로 주기 떄문에 즉각적으로 등록할 수도 있다. 유레카 클라이언트 등록 딜레이는 서버,클라이언트,리본에 관한 옵션 설정등을 통하여 줄일 수 있다. 1. 유레카 서버의 캐쉬 업데이트 주기 조정옵션 eureka.server.response-cache-update-interval-ms: 3000 # 기본30초 2. 유레카 클라이언트의 레지스트리를 받아오는 주기를 조정. eureka.client.registryFetchInterval..