개발블로그임다

Sleuth Span 생성시점- HttpRequest 요청 들어온 후 Intercept 처리 할 때 ES 403 Index read-only, cluster_block_exception 발생문제 Trouble Shooting 원인파악 : ES사용량이 95% 이상로 내려갔을 시, ES 내부적으로 INDEX_READ_ONLY OPTION을 TRUE로 활성화 시켜서 더이상 index를 write 하지 못하게 한다고 한다. [ES LOG] flood stage disk watermark [95%] exceeded on [n6~][es-name][데이터경로], free: 남은 데이터노드 용량 등.. 문제해결 : 인덱스 삭제 및 용량 정리 => 아래 api call 호출 PUT your_index_name/_set..

해당 포스트는 yun blog님의 포스트를 바탕으로 하여 작성, 추가로 알게된 내용들을 덧붙인 글 입니다. [원문] https://cheese10yun.github.io/spring-batch-basic/ Spring Batch 간단 정리 - Yun Blog | 기술 블로그 Spring Batch 간단 정리 - Yun Blog | 기술 블로그 cheese10yun.github.io 스프링 부트 배치 주의사항 스프링 부트 배치는 스프링 배치를 간편하게 사용 할 수 있게 래핑한 프로젝트입니다. 따라서 스프링 부트 배치와 스프링 배치에 모두에서 다음과 같은 주의사항을 염두해야 합니다. 가능하면 단순화해서 복잡한 구조와 로직을 피해야합니다. 데이터를 직접 사용하는 편이 빈번하게 일어나므로 데이터 무결성을 유지하..

스크립트 언어 인터프리터 방식을 사용하는 인터프리터 언어의 한 종류로, 응용 소프트웨어에서 해당하는 스크립트 언어로된 API를 제공하며 스크립트 언어는 이러한 소프트웨어를 제어, 상호작용하기 위해 만들어진 언어이다. 다만, 이러한 방식에서 스크립트 특성상 수정이 빈번하게 일어날 수 있어서 인터프리터 방식을 많이 사용하는 것 뿐이다. 이러한 수정이 빈번한 방식에는 한줄 한줄 코드를 읽어나가는 인터프리터 방식이 전체 수정과 컴파일이 필요없이, 해당 부분만 수정하여 배포하면 되므로 인터프리터 방식을 사용한다.

컨슈머 주요 옵션 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 마다 제각기 다른 방식으로 구현될 수 있어 복잡도가 증가, 추후에 통합데이터 분석을위해 파이프라인들이 연결되어야 할 때 문제 발생. 이러한 배경에서 카프카는 다음과 같은 목표를 달성하기 위해 탄생하였다. 프로듀서와 컨슈머의 분리 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용 높은 처리량을 위한 메시지 최적화 데이터가 증가함에 따라 스케일 아웃이 가능하도록 한다. 카프카의 동작 방식과..

도커 이미지와 컨테이너 도커 이미지 컨테이너를 생성할 때 필요한 파일로 가상 머신의 iso와 유사 컨테이너를 생성, 실행할 때 읽기 전용으로 사용된다. 이미지의 이름은 [저장소(생략가능)]/[이미지이름]:[태그(생략시 latest)] 형태로 구성된다. 도커 컨테이너 도커 이미지로 생성했을 때 기존 파일시스템과 격리된 시스템 자원 및 네트워크를 사용하도록 생성된 공간. 컨테이너는 이미지를 읽기 전용으로 사용하되 이미지에서 변경된 사항은 컨테이너 계층에 저장한다. 하나의 같은 이미지로도 독립적인 여러 컨테이너를 생성할 수 있음. 도커 컨테이너 다루기 컨테이너 생성 dokver -v : 도커 버전확인 docker run -i -t( i: 상호입출력, t: tty bash 셸 사용 옵션, i,t는 동시에 사용해..

가상 머신과 도커 컨테이너 기존의 가상화 기술은 하이퍼바이저를 이용해 여러 개의 운영체제(가상머신)를 하나의 호스트에서 생성하는 방식. 기존 가상화 기술의 단점 하이퍼바이저를 통해 자원을 가상화, 독립된 공간을 생성하므로 성능의 손실 게스트 운영체제들을 사용하기 위해 각각의 게스트 운영체제마다 라이브러리, 커널등을 전부 포함하기 때문에 이미지의 크기도 커진다.( ~ N Giga Bytes ) 도커 컨테이너의 장점 가상화된 공간을 리눅스 자체 기능인 chroot, namespace, cgroup을 사용함으로써 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없다. 컨테이너들의 커널은 호스트와 공유하기 하고, 컨테이너 안에는 애플리케이션에 필요한 파일들만 존재하기때문에 이미지 용량도 적고, 따라..