StarLord

Backstage의 Entity 종류는 9 가지가 있고, 각자 고유한 정의를 따른다. Backstage 내의 Entity와 Relation은 Core library에서 어느정도 정의해서 제공하고 있다. 그러다 보니 단순이 app-config.yaml에서 allow되는 Entity 목록에 완전히 새로운걸 추가한다던지 그런 수준의 yaml만 수정해서는 새로운 Entity를 만들수 없다. Kind: ComponentKind: TemplateKind: APIKind: GroupKind: UserKind: ResourceKind: SystemKind: DomainKind: Location Descriptor Format of Catalog Entities | Backstage Software Catalog an..

클러스터 문제 진단하기활성 컨트롤러 수나 컨트롤러 큐 크기와 같은 지표를 모니터링 함으로써 뭔가 문제가 발생했을 때 간단히 알아차릴수 있다. 불완전 복제 파티션 다루기해당 브로커가 리더 레플리카를 잡고 있는 파티션 중 팔로워 레플리카가 따라오지 못하고 있는 파티션의 수를 나타낸다. 다수의 브로커가 일정한 수의 불완전 복제 파티션을 가지고 있다는 것은 보통 클러스터의 브로커중 하나가 내려가 있다는 것을 의미하는 경우가 많다. 가장 먼저 해야 할 일은 문제가 단일 브로커에 국한된 것인지 아니면 클러스터 전체에 연관된 것인지를 확인하는 것이다 때로는 이것이 쉽지 않은 문제일 수 있다. 만약 다음 예와 같이 불완전 복제 파티션들이 한 브로커에 몰려 있다면 해당 브로커가 문제일 가능성이 높다. 에러 메시지를 보..

보안 프로토콜PLAINTEXT : PLAINTEXT 전송 계층에는 인증이 존재하지 않는다. 사설 네트워크 안에서 인증이나 암호화가 필요없을 정도로 민감하지 않은 데이터를 처리할 때문 적합하다. SSL : SSL전송 계층은 선택적으로 클라이언트 SSL인증을 수행할 수 있다. 암호화 뿐만 아니라 클라이언트/서버 인증도 지원되기 때문에 안전하지 않은 네트워크에서 적절하다. SASL_PLAINTEXT : SASL 인증과 PLAINTEXT 전송계층이 합쳐진 것이다. 어떤 SASL메커니즘은 서버 인증 역시 지원한다. 암호화는 지우하지 않기 때문에 사실 네트워크 안에서만 적합하다. SASL_SSL : SASL 인증과 SSL 전송계층이 합쳐진 것이다. 암호화 뿐만아니라 클라이언트/서버 인증도 지워되기 때문에 안전..

카프카 클러스터 간의 데이터 복제는 미러링 이라고 부를것이다. 아파치 카프카에는 클러스터간 데이터 복제를 수행하기 위한 툴로 미러메이커를 포함하고 있다. 클러스터간 미러링 활용 사례지역 및 중앙 클러스터고전적인 사례로는 수요와 공급에 따라서 가격을 조정해야 하는 회사가 있을 것이다. 이 회사는 사무실을 운영중인 각각의 도시에 데이터 센터를 가지고 각 지역의 수요와 공급에 대한 정보를 수집해서 그에 따라 가격을 조정한다. 이 모든 데이터는 그 후 중앙 클러스터로 미러링되어 비즈니스 분석가들이 회사 단위의 수익 보고를 할 때 사용할 수 있다. 고가용성과 재해복구 규제여러 나라에서 사업을 운영하는 회사의 경우 국가별로 다른 법적, 규제적 요구 조건을 따르기 위해 나라마다 있는 카프카 클러스터별로 서로 다른..

데이터 파이프라인 구축 시 고려사항적시성하루에 한 번 대량의 데이터를 받는 시스템이 있는 반면 데이턱 생성된 뒤 몇 밀리초 안에 받아야하는 시스템도 있다. 대부분의 데이터 파이프라인은 이 두가지 형태의 중간쯤 어딘가에 위치한다. 이러한 맥락에서 카프카를 이해하는 좋은 방법은 쓰는 쪽과 읽는 쪽 사이의 시간적 민감도에 대한 요구조건을 분리시키는 거대한 버퍼로 생각하는 것이다. 쓰는 쪽에서는 실시간으로 쓸 수 있지만, 읽는 쪽에서는 배치 단위로 읽을 수 있으며, 그 반대로 가능하다. 이것은 백프레셔(Producer가 cONSUMING 가능 이상의 데이터를 발생시킬때) 적용 역시 단순하게 해준다. 신뢰성데이터 파이프라인은 많은 경우 중요한 비즈니스 시스템에 데이터가 전달되는 통로이기도 하기 때문에, 몇 초간..

이것이 기존의 Catalog Graph 인데, 모든 Kind가 같은 색상으로 아이콘으로 구분되다 보니 가시성이 떨어진다. Custom UI 를 사용하여 가시성을 향상시킬수 있다. 설명은 공식적으로 여기에 소개되어 있다.https://github.com/backstage/backstage/blob/master/plugins/catalog-graph/README.md#customizing-the-ui backstage/plugins/catalog-graph/README.md at master · backstage/backstageBackstage is an open framework for building developer portals - backstage/backstagegithub.com 수정사항은 ..

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

브로커 설정복제 팩터토픽 단위 설정은 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 이게 전부다.

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