🤔 메세징 플랫폼의 등장
시대적 배경
2000년대 ~ 2010년대부터 IT(인터넷, 모바일)혁명이라고 부를 수 있을 만큼의 변화가 생겨났다. 반도체 기술은 날이 갈수록 진화했고, 더 가볍고 더 빠른 속도의 칩들이 계속해서 개발되었다.
그에 따라서 '핸드폰'이라고 불리던 것은 '스마트폰'이라고 불리게 되었고, 집 또는 PC방과 같은 특정 공간에서만 사용하던 컴퓨터가 사람들의 손에 하나씩 주어지게 되었다. 컴퓨터를 사용하는 데 있어서 시간적 공간적 제약이 허물어진 것이다.
이러한 시대적 변화로 인해서 기본적으로 모든 서비스들은 기존보다 더 많은 트래픽을 받게 됐고, 자국에서만 운영되던 서비스가 아닌 전세계 사람들이 이용하는 글로벌 서비스들이 심심치 않게 생겨나기 시작했다. 대표적인 예시가 넷플릭스인데, 어지간한 모든 국가에서 서비스되고 있는 넷플릭스는 하루에도 수십, 수백억 건의 트래픽과 데이터를 처리해야만 했다.
이러한 상황은 비단 넷플릭스만의 이야기는 아니고, 대부분의 글로벌 기업들이 맞이한 문제들이였고, 그래서 많은 기업들에서는 많은 양의 트래픽과 데이터를 처리하기 위한 혁신적인 변화들을 만들어 낸다.
MSA (Micro Service Architecture)
넷플릭스를 필두로 수 많은 글로벌 기업에서 많은 양의 트래픽과 데이터를 안정적이면서 빠르게 처리하기 위해서 MSA를 발전시키게 된다. 그리고 넷플릭스를 포함한 다양한 글로벌 기업에서 내부적으로 사용하던 MSA관련 프레임워크들을 오픈소스로 풀면서, MSA를 사용하는 기업들이 폭발적으로 늘어났고, 현재 MSA는 어지간한 대기업은 모두 다 사용하는 시스템 구조가 되었다.
MSA는 고객의 입장에서는 1, 2개의 서비스인데 내부적으로는 수십 수백개의 서버 애플리케이션으로 되어 있는 시스템 구조를 이야기한다.
각 서버 애플리케이션의 역할에 맞게 팀을 구성할 수 있고 당연하게도 언어나 DB도 원하는대로 구성할 수 있는 것이다. 또, 다른 서비스들과 시스템적으로 분리되어 있기 때문에 한 곳에서 발생한 장애가 다른 곳에 거의 영향을 주지 않는다는 장점도 있다.
메세징 플랫폼과 Kafka
지금에 와서는 MSA를 구축하는 데에 있어서, 메세징 플랫폼은 필수 스펙이지만, MSA가 먼저 생겨난 것인지 메세징 플랫폼이라는 개념이 먼저 생겨난 것인지는 잘 모르겠다.
하지만, 확실한 것은 MSA가 발전해야만 했던 동일한 이유로 인해서 메세징 플랫폼 또한 발전하게 된 것이고, Kafka는 LinkedIn에서 처음에 개발되어서 지금은 오픈소스로 운영되고 있는 이벤트 기반의 메세징 플랫폼 중에 하나이다.
실시간 스트리밍 데이터를 처리하기 위해서 만들어졌고, Producer역할의 애플리케이션과 Consumer역할의 애플리케이션의 결합성을 크게 낮추면서 시스템의 복잡도도 크게 낮출 수 있도록 도와준다.
Kafka의 역할
위에서도 이야기했지만, Kafka와 같은 메세징 플랫폼이 필요한 이유는 결국에는 복잡한 시스템 구조를 복잡하지 않으면서 효율적이고 안정적인 구조로 만들기 위함이다.
예를 들자면, 하나의 서비스에 대해서 수 많은 서버 애플리케이션이 있다고 가정했을 때, Kafka와 같은 메세징 플랫폼이 없다면 상호간의 API콜만을 이용해서 데이터를 주고 받아야할 것이다. 이렇게 되면, 서버 애플리케이션 간에 의존성이 강하게 형성되게 된다는 치명적인 문제점이 발생하게 된다.
하지만, Kafka가 애플리케이션 간에 브로커역할을 한다면, 이렇게 비교적 직관적인 시스템 구조를 구성할 수 있게 되는 것이다.
📒 Kafka의 구성
1) Producer와 Consumer
Kafka에 데이터를 제공하는 역할을 하는 애플리케이션을 Producer라고 부르고, Kafka를 구독하면서 Kafka의 큐에 올라온 데이터를 가져가서 처리하는 애플리케이션을 Consumer라고 부른다.
2) Topic
Kafka의 Topic은 DB의 테이블 또는 OS의 폴더와 유사한 역할을 하는 개념이다.
Producer에서는 특정 Topic에 데이터를 게시할 수 있고, Consumer는 특정 Topic을 구독하며 게시되는 데이터를 받아서 처리할 수 있다.
3) Partition
하나의 Topic은 N개의 파티션으로 구성이 되어 있다. 파티션의 갯수가 많을 수록 Consumer의 갯수를 늘려서 분산처리할 수 있다는 장점이 있지만, 파티션을 늘리게 되면 다시 줄일 수는 없어서, 신중하게 추가해야한다. 또, 파티션에 적재된 데이터는 유지할 시간 또는 최대 데이터 용량을 설정하여 기준이 넘어간 데이터들은 삭제되도록 처리가 된다.
파티션이 여러개인 경우, Producer가 데이터를 게시할 때 어떤 파티션에 데이터를 올릴지 결정하는 역할을 하는 것을 "파티셔너"라고 부른다. 특정 파티셔너를 지정하지 않는다면, 기본적으로 UniformStickyPartitioner가 파티셔너로 선정이 된다. UniformStickyPartitioner는 Producer로부터 '키(Key)'값을 같이 전달받으면 해당 키 값을 해싱 & 모듈러 연산해서 파티션을 결정하고, 키 값을 같이 보내지 않았다면 배치방식으로 여러 데이터를 한번에 모아서 라운드-로빈 알고리즘으로 랜덤하게 파티션에 배정한다.
파티셔너는 API에 맞게 자신만의 파티셔너를 만들어서 사용할 수도 있다.
3) Kafka broker와 Replication
Kafka가 설치되어 있는 서버를 Kafka broker라고 부르는데, 기본적으로 3대 이상의 Broker를 사용하는 것을 권장한다고 한다.
위 그림은 Partition의 갯수는 1, Replication의 갯수는 2로 설정했을 때의 모습니다.
위에서도 이야기했다시피 Broker들은 물리적으로 서로 다른 서버에서 실행되고 있고, 그렇기 때문에 각 Broker들은 Sync를 맞춰줄 필요가 있다.
그래서 하나의 Broker의 Partition이 Leader partition으로 선정되고, 나머지 Partition들은 Follower partition이라고 부르며, 이 Partition들의 그룹을 In Sync Replica (ISR)라고 부른다.
이렇게 Replication을 사용하는 이유는 고가용성을 보장하기 위함이다. 쉽게 이야기하면, 안정성을 보장하기 위함이라고 할 수 있다.
우리가 서버를 여러 대 띄우거나 여러 호스트 영역에 분산 시켜 구동하는 것 처럼 특정 Broker에 문제가 생겨도 나머지 Broker들이 백업을 하고 있음으로 인해서 문제가 생기지 않도록 하는 것이다.
⚡ Kafka 운영
1) Consumer lag (컨슈머 랙)
Consumer lag은 각 파티션 안에서 컨슈머가 마지막으로 읽은 Offset과 프로듀서가 마지막으로 넣은 Offset의 차이를 의미한다. 위 그림에서는 Consumer lag은 3개이다.
Consumer lag이 클수록 Consumer가 Producer의 데이터 게시량을 따라가지 못한다는 것을 의미한다. 즉, 장애가 발생한 경우일 수도 있고, Partition의 갯수를 늘려줘야하는 상황이라는 의미가 될 수도 있어서, Consumer lag은 운영적인 측면에서 중요한 지표가 된다.
2) Burrow
컨슈머 랙은 메세징 처리의 성능을 단번에 파악할 수 있는 중요한 지표이다. 그래서 Consumer lag은 안정적으로 수집이 되어야만 하고, LinkedIn에서는 Kafka와 함께 Consumer lag을 안정적으로 수집할 수 있는 오픈소스 툴인 Burrow를 개발하였다.
여러 개의 Kafka 클러스터(Kafka broker의 집합)가 존재하더라도 하나의 Burrow 애플리케이션으로 Consumer lag을 수집할 수 있기 때문에 효율적으로 Consumer lag을 수집할 수 있다. 또, 수집한 Consumer lag을 기반으로 직관적인 대시보드를 제공해서 각 Kafka broker 또는 파티션의 상태를 손쉽게 파악할 수 있다.
