개발블로그임다

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..

목적 IP & 도메인 로깅을 위해 InetAddress.getLocalHost() 사용으로 발생할 수 있는 성능 이슈, 나아가 AWS EC2 환경에서의 동작 방식 분석 배경 사내 타 프로덕트에서 라이브 중인 서버의 Latency가 급격하게 튀는 현상이 발생. 모든 Request마다 InetAddress.getLocalHost()를 사용하여 IP 주소를 로깅하고 있었음. InetAddress.getLocalHost()를 사용하면 DNS 서버를 통해 IP 정보를 가져올텐데 부하가 크지 않을까? 결론을 먼저 말한다면, API Call이 올때마다 InetAddress.getLocalHost()를 호출하게 되면 치명적인 성능 이슈를 초래한다. 꼭 사용해야 한다면, 처음 서버 부팅시 static하게 정보를 받아 재..