b

Kafka 는 기본적으로 1번 이상의 메시지 전송을 보장 하는 At Least Once Delivery 정책이었다. 메시지가 전송되었다는 ack를 확실히 받지 못할 경우 retry send를 하는 방법으로 최소 1회의 전송을 보장 하였던 것이다. 하지만 0.11 버전부터 exactly once delivery 를 위해서 idempotent producer가 지원되기 시작하였다 (함께 transactional producer도 포함된다) 메시지가 at least once delivery (즉 duplicate send)는 링크의 글과 이미지를 참고하면 쉽게 이해할 수 있다. https://dzone.com/articles/exactly-once-semantics-with-apache-kafka-1 Exac..

https://deview.kr/2019/schedule/305 에서 소개한 11번가의 주문/결제 시스템에 관련된 이야기이다. 실제로 '결제'단계에서 장애가 났을때 11번가의 주문/결제는 어떻게 진행이 되었을까? 아래의 예는 지난 11월 11일 오후 1시경의 11번가 스토리이다. 단순화해서 "주문 -> 결제 처리 -> 11번가 데이터베이스에 저장" 흐름대로 주문/결제가 처리된다고 생각하자. 13:00 정각 기프티콘을 절반 가격에 한정 판매 하면서 주문은 미친듯이 들어온다. 12시 59분에 비해 약 4배의 속도로 주문/결제가 들어왔다. 당연히 주문 처리량 보다 높아졌다. 13:01분 부터 주문유입량 >> 주문처리량이 되었다. 원래대로라면 다른 주문들은 다 Rejection 하거나, 고객에게 1분 이상의 대..

#topic 생성 kafka-topics --create --topic freblogg --partitions 3 --replication-factor 1 --zookeeper localhost:2181 - 파일명은 base offset에 영향을 받는다 (해당 세그먼트의 첫 번째 offset) 그러므로 새로 생성된 토픽-파티션의 첫번째 세그먼트는 항상 0000000000000.log 파일명이다. 간단하게 2개의 메시지를 넣고 다시 한번 0번 파티션을 확인해보면 0000000000000.log 의 파일 크기가 변경되고 그 안을 보면 해당 데이터가 들어간것을 확인 할 수 있다 이를 좀 더 자세히 보려면 아래의 명령어처럼 세그먼트 내부를 확인 할 수 있다. ( DumpLogSegments ) ~/conflue..

결론부터 얘기하면, 아직은 못쓰겠다. 정확히 말하면 쉽게 사용 가능하지만, 이걸 메인 모니터링으로 사용하기에는 메트릭 종류가 너무 적다 RabbitMQ는 다양한 플러그인을 가지고 있고, 위의 화면처럼 기본적인 모니터링 화면도 제공하고 있다. 하지만 매번, 해당 UI 에 접근한다는 점이 불편했고, 메트릭 수치가 현재것만 볼 수 있다는 점, 그리고 alert/watch 기능을 제공하지 않는 점이 불편해서 다른 모니터링이 필요하였다. (지금에서야 고민하는 이유는... 이 시스템이 담당자가 없고, 모니터링이 없었다. 그래서 오늘 해야겟다고 마음 먹었다) 팀내에서 사용하고 있는 모니터링은 메인 스트림은 Promethus + Grafna / ELK 이다. 이중에서 간편하고 전체 플랫폼을 내가 직접 관리하고 있는 E..

카프카 스트림은으로 StateStore를 구성하여 서비스에 투입하는 것은 튜토리얼과 상용은 하늘과 땅차이다. 특히 데이터가 어느 정도 적재되는 상황에서는 그 문제는 더 커진다. 일반적으로 Application 이 standby가 되면 트래픽을 받을 수 있는 것과는 달리, Kafka Streams로 Query를 받아 내기 위해서는 StateStore가 초기화 되어야 한다. 그래서 아래와 같은 코드를 준비하여야 한다. (시대가 어느시대인데 무한 루프냐 ㅠ) public class StoreHelper { public static T waitUntilStoreIsQueryable(final String storeName, final QueryableStoreType queryableStoreType, fina..

nginx module : https://github.com/google/ngx_brotli google/ngx_brotli NGINX module for Brotli compression. Contribute to google/ngx_brotli development by creating an account on GitHub. github.com 보통 20% ~ 이상의 압축 효율이 더 좋다고 하지만, 진리의 케바케 그래도 gzip 보다는 좀 더 효율적인듯 하다. FF, Safari, Chrome 같은 모던 브라우저는 다 되지만 IE11 은 지원 안한다.

데이터의 준비 분간하기 쉬운 데이터 10개를 큐에 준비한다 ex) data1 ~ data10 @Bean public ApplicationRunner runner(AmqpTemplate template) { return args -> IntStream.rangeClosed(1, 10).forEach(c -> template.convertAndSend("myqueue", "data => " + c)); } delivery-tag 의 출력 어떤식으로 delivery-tag 값이 할당되는지 확인한다. @RabbitListener(queues = "myqueue") public void listen(Message in, Channel channel) throws InterruptedException, IOExce..

엘라스틱서치는 한번에 볼 수 있는 데이터의 건수가 제한적이다. 예를 들어 GET INDEX_NAME/_search { "size" :15000 } //결과 "root_cause": [ { "type": "illegal_argument_exception", "reason": "Result window is too large, from + size must be less than or equal to: [10000] but was [15000]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] i ndex level..