wjrmffldrhrl
commented
2 years ago Real-time Data Infrastructure at Uber
SYSTEM OVERVIEW
이전에 읽은 내용 정리하고 남은 시간 더 읽기
Apache Kafka for streaming storage
아래의 서브섹션에서는 그림에서 나오는 오픈소스 시스탬에 대해서 설명한다.
Kafka는 산업에서 많이 사용되는 인기있는 오픈소스 분산 이벤트 스트리밍 시스템이다.
Uber에서 채택했을때는 이미 Kafka는 좋은 성능으로 잘 알려진 인기있는 솔루션이었다. 최근 성능 연구에서는 Kafka, Pulsar, RabbitMQ등 이벤트 스트리밍 시스템들의 시스템 처리량과 지연과 같은 성능 지표를 뽑아냈는데 여기에는 채택을 함에 있어서 고려되는 몇 가지 중요한 요소들이 있었다.
- 운영의 단순함
- 오픈소스 에코시스템의 성숙함
- 오픈소스 커뮤니티의 크기
- 산업에서의 채택률
이러한 지표들을 고려했을 때, Kafka가 Queuing & Event streaming system에서 명백한 승리자였다.
오늘날 우버는 기업들 중에서 가장 큰 Apache Kafka를 배포하고 있으며, 매일 수 조개의 메세지와 페타바이트의 데이터를 처리하고있다.
스트리밍 데이터를 배치 또는 실시간으로 전송하기 위한 구조로서, 우버의 카프카는 아래와 같은 아주 많은 워크플로우들을 지원한다.
- 승객과 운전자 앱에서 발생하는 이벤트 데이터의 전파.
- Apache Samza, Flink와 같은 스트리밍 분석 플렛폼 지원
- subscribers에게 스트리밍 데이터베이스 로그 전달
- Apache Hadoop Data Lake로 정렬된 데이터 삽입
Uber의 거대한 규모와 몇 가지 독특한 요구사항으로 인해 Uber는 Kafka를 커스터마이징 하고 추가적인 개선사항을 적용했다.
4.1.1 Cluster federation.
가용성의 향상과 단일 클러스터의 실패를 견뎌내기위해, Uber는 클러스터의 세부 사항을 Producer와 Consumer들에게 숨길 수 있는 새로운 Kafka federation 구성을 개발했다.
사용자들은 어떤 클러스터에 topic이 있는지, 논리적 클러스터 구성이 어떤지 볼 필요가 없다.
메타데이터 서버는 클러스터들과 topic들의 모든 메타데이터 정보를 중앙에서 통합하고 있다. 그래서 클라이언트의 요청은 실제 물리적 클러스터로 전달된다.
안정성 이외에도 클러스터 federation은 비즈니스의 성장을 위한 확장성도 개선되었다.
Uber의 경험적인 데이터에 기반하여 이상적인 클러스터 크기는 150개 미만이다.
Federation을 사용하면 Kafka 서비스는 클러스터가 가득 찼을 때 클러스터를 더 추가하여 수평적으로 스케일링이 가능하다. 새로운 topic들은 깔끔하게 새로운 클러스터에 생성된다.
마지막으로, 클러스터 federation은 쉬운 topic 관리를 제공한다. Uber 내부에서는 아주 많은 어플리케이션과 클라이언트들이 있고 클러스터간에 consumer들의 topic을 이전하는 것은 매우 어렵다. 일반적으로 트레픽을 새로운 클러스터로 이전하는데 사용자의 수동 조정이 필요하고 결과적으로는 job이 재시작 되어야 한다. 클러스터 federation은 어플리케이션의 재시작 없이 다른 물리적인 클러스터로 consumer의 트래픽을 리다이렉션 하는 것을 가능하게 한다.
4.1.2 Dead letter queue
몇몇의 메세지들이 downstream application에서 처리되지 못하고 실패하는 경우가 있는데, 예를 들어 메세지가 변형되거나 올바르지 않은 동작이 있는 경우가 있다.
Apache Kafka에서는 실패한 메세지를 처리하는 두 가지 방법이 있다.
- 메세지 드랍하기
- 메세지가 처리될 때 까지 무한정 재시도 하기
그러나 Uber에는 여행 영수증 처리처럼 데이터가 손실되거나 막히지 않도록 요구되는 많은 시나리오들이 있다.
이러한 사례들을 해결하기 위해 Dead Letter Queues(DLQ)라는 전략이 Kafka interface 위에 구축되어있다.
만약 topic의 consumer가 몇 번의 재시도에도 메세지를 처리하지 못하면 해당 메세지는 DLQ로 전달된다.
dead letter topic의 메세지들은 제거되거나 사용자들에게 통합(i.e 재시도)될 수 있다. 이 방법은 처리되지 않은 메세지가 실시간 트레픽을 지연시키지 않도록 할 수 있다.
4.1.3 Consumer Proxy.
오픈소스 Kafka는 batching과 compression의 세련된 로직이 담긴 consumer liberary package를 가지고있다.
각 cline side의 최적화는 consumer의 처리량을 향상시키지만, Uber와 같은 큰 조직에게는 client 관리를 어렵게 만든다. 수천 수만의 Kafka application이 동작하고 있는데 이것은 platform team이 유저들을 지원하는데 많은 어려움을 가져온다.
추가적으로 client library 개발을 더디게 하고 모든 application을 업데이트 하는데 몇 달이 걸린다. 또한 큰 조직은 많은 프로그래밍 언어를 사용하는데 이것은 clinet 들이 복잡할 때 다양한 언어의 지원이 어려워진다.
마지막으로 Kafka 구조의 한계 때문에 open source Kafka는 topic partition의 수 보다 conumer group 내부의 instance가 더 많지 않도록 제한하고 있으며, 이로인해 conumer level에서의 병렬성에 방해가 된다.
이러한 문제들을 해결하기 위해 Uber는 모든 pub/sub 구조에 proxy layer를 구성했다.
이 proxy layer는 Kafka로부터 message를 받아 사용자가 지정한 gRPC 서비스의 endpoint로 보낸다.
consumer layer의 복잡도는 proxy layer에 encapsulated 되었고 application은 간다하고 기계적으로 생성된 gRPC만 가져오면 된다.
부가적으로 proxy는 멋진 error handling을 제공한다.
아랫단의 서비스가 메세지를 수신하거나 처리하는데 실패하면 consumer proxy는 재시도하거나 몇 번의 재시도가 실패하면 DLQ를 메세지를 보낸다.
jongfeel
https://meet.google.com/jyx-mxnq-kpk
참여 방법:
Assignees에 자신의 github 계정을 self로 추가 2시간 분량의 할 내용에 대해 댓글 작성 (최소 모임 시작 전까지) 빛의 속도 혹은 (주말, 휴일 포함) 최소 3일 내에 구글 캘린더 등록 메일 확인 모임 시간에 각자 개발 관련된 공부 진행
모임 끝난 후 공부한 내용 정리 & 링크 추가 => 최소 다음 모각코 전까지 확인 가능해야 함.
주의: 회사일 혹은 마감 기한 임박한 일 처리의 경우는 최대한 자제해 주세요. 주말 아침에 일하면 우울하니까요. ㅜㅜ