StarLord

Kafka 심화) '정확히 한 번' 의미 구조

이전 챕터에서 신뢰성 보장을 제어할 수 있게 해주는 설정 매개변수들과 모범사례를 보았다. 여기서 우리는 '최소 한번' 전달에 초점을 맞췄다. 멱등적 프로듀서간혹 재시도는 메시지 중복을 발생시킨다. 가령 다음과 같은 시나리오에서..- 파티션 리더가 프로듀서로부터 레코드를 받아서 팔로워들에게 성공적으로 복제한다.- 프로듀서에게 응답을 보내기 전, 파티션 리더가 있는 브로커에 크래시가 발생한다. - 프로듀서 입장에서는 응답을 받지 못한 채 타임아웃이 발생하고, 메시지를 재전송한다.- 재전송된 메시지가 새 리더에 도착한다. 하지만 이 메시지는 이미 저장되어 있다. 이러한 케이스를 대응하기 위해서 우리는 멱등적 프로듀서를 사용한다. 멱등적 프로듀서의 작동 원리멱등적 프로듀서 기능을 켜면 모든 메시지는 고유한..

브로커 설정복제 팩터토픽 단위 설정은 replication.factor에, 자동으로 생성되는 토픽들에 적용되는 브로커 단위 설정은 default.replication.factor 설정에 잡아준다. 이책에서 지금까지는 토픽의 복제 팩터가 3이라고 가정하였다. 이는 각 브로커가 3대의 서로 다른 브로커에 3개 복제된다는 것을 의미한다. 이엇은 합리적인 가정이고 또 카프카의 기본값이기다 하지만, 이설정은 사용자가 고칠수 있는 것이다. 그렇다면 토픽에 몇개의 레플리카가 적절한지 어떻게 결정할 수 있을까? 몇가지의 핵심 고려사항이 있다. - 가용성 : 레플리카가 하나뿐인 파티션은 정기적으로 브로커를 재시작하기만 해도 작동 불능에 빠진다. 레플리카 수가 더 많을수록 가용성은 떨어진다.- 지속성 : 각 레플리카는..

간혹 Istio Proxy Level에서 트러블 슈팅이 필요한 경우가 있다. 이럴때는 Istio Proxy 로깅이 필요한데 별도의 조치가 필요하다. # istio-proxy 컨테이너 쉘 접속kubectl -n {해당 NS} exec -it {해당 POD} -c istio-proxy -- /bin/sh# 로그 레벨을 debug로 수정curl -XPOST http://localhost:15000/logging?level=debug 이게 전부다.

클러스터 멤버쉽카프카는 현재 클러스터의 멤버인 브로커들의 목록을 유지하기 위해 아파치 주키퍼를 사용한다. 각 브로커는 브로커 설정 파일에 정의되었거나 아니면 자동으로 생성된 고유한 식별자를 가진다. 컨트롤러컨트롤러는 일반적인 카프카 브로커의 기능에 더해서 파티션 리더를 선출하는 역할을 추가적으로 맡는다. 브로커가 컨트롤러가 되면, 클러스터 메타데이터 고나리와 리더 선출을 시작하기 전에 먼저 주키퍼로부터 최신 레플리카 상태 맵을 읽어온다. 브로커가 클러스터를 나갔다는 사실을 컨트롤러가 알아차리면, 컨트롤러는 해당 브로커가 리더를 맡고 있었던 모든 파티션에 대해 새로운 브로커를 할당해주게 된다. 컨트롤러는 새로운 리더가 필요한 모든 파티션을 순회해 가면서 새로운 리더가 될 브로커를 결정한다.(단순히 해당 ..

우리는 토픽으로부터 데이터를 읽어 오는 작업을 확장할수 있어야 한다. 여러개의 컨슈머가 같은 토픽으로 부터 데이터를 분할해서 읽어올 수 있게 해야 하는것이다. 카프카 컨슈머는 보통 컨슈머 그룹의 일부로써 작동한다. 동일한 컨슈머 그룹에 속한 여러개의 컨슈머들이 동일한 토픽을 구독할 경우, 각각의 컨슈머는 해당 토픽에서 서로 다른 파티션의 메시지를 받는 것이다. 파티션보다 더 많은 컨슈머를 추가한다면 컨슈머 중 몇몇은 유휴 상태가 되어 메시지를 전혀 받지 못한다. 이것은 토픽을 생성할 때 파티션 수를 크게 잡아주는게 좋은 이유이기도 한데, 부하가 증가함에 따라서 더 많은 컨슈머를 추가할 수 있게 해주기 때문이다. 여러 애플리케이션이 동일한 토픽에서 데이터를 읽어와야 하는 경우 역시 매우 흔하다. 카프..

프로듀서 측의 전반적인 메커니즘프로듀서 API 는 매우 단순하지만, 우리가 테이터를 전송할때 내부적으로는 조금 더 많은 작업들이 이루어진다. 1) 카프카에 메시지를 쓰는 작업은 ProducerRecord 객체를 생성함으로써 시작된다. 여기서 레코드가 저장될 토픽과 밸류 지정은 필수사항이지만, 키와 파티션 지정은 선택사항이다. 일단 ProducerRecord를 전송하는 API를 호출했을 때 프로듀서가 가장 먼저 하는 일은 키와 값 객체가 네트워크 상에서 전송될 수 있도록 직렬화해서 바이트 배열로 변환하는 것이다.(=Serializing) 2) 그 다음에, 만약 파티션을 명시적으로 지정하지 않았다면 해당 데이터를 파티셔너에게로 보낸다. 파티셔너는 파티션을 결정하는 역할을 하는데, 그 기준은 보통 Prod..

https://backstage.io/docs/features/techdocs/ TechDocs Documentation | Backstage Software Catalog and Developer PlatformTechDocs is Spotify’s homegrown docs-like-code solution built directly into Backstagebackstage.io TechDocs는 Spotify가 자체 개발한 문서형 코드 솔루션으로, Backstage에 내장되어 있습니다. 엔지니어는 마크다운 파일로 문서를 작성하고, 이 파일은 코드와 함께 저장되며, 간단한 설정만으로 Backstage에서 보기 좋은 문서 사이트를 만들 수 있습니다. 이 TechDocs를 사용하는데 있어서 다음과 같은..

1) packages/app/src/App.tsx에 아래 코드를 추가합니다.import { UnifiedThemeProvider, themes, } from '@backstage/theme'; // MUI themesimport LightIcon from '@material-ui/icons/WbSunny'; // Additional iconsimport { multicolorTheme } from './theme/theme'; // Custom multicolor theme components: { SignInPage: props => ( ), }, themes: [ // Keeping the original themes is completely optional { ..

전반적인 절차는 아래의 공식문서를 따르면 된다. 하지만 하다보면 군데 군데 막힌다. https://backstage.spotify.com/learn/standing-up-backstage/standing-up-backstage/1-intro/ Standing Up Backstage | Spotify for BackstageLearn how to set up and deploy your Backstage app, how to add authentication, and how to connect to your source control systembackstage.spotify.com 막혔던 부분을 기록한다. Creating the Backstage applicationnpx @backstage/creat..

아래의 과정을 통해 획득한 Key는 모두 잘 보관한다.GitHub Authentication Setup1. Create GitHub OAuth App in your organization settings 2. Configure Homepage URL and Authorization callback URL:- 로컬개발시에는 localhost 를 callback으로 한다. http://localhost:7007/api/auth/github/handler/frame - 만약 정말 서버에 provisioning을 한다면 그에 응하는 URL을 callback으로 한다. https://.spotifyportal.com/api/auth/github/handler/frame 3. Copy clientId ..