토스 SLASH 23 - Kafka 이중화로 다양한 장애 상황 완벽 대처하기

https://www.youtube.com/watch?v=Pzkioe7Dvo4 

 

토스증권의 Data Engineer인 강병수 님의 발표를 요약해보고자 합니다.

 

 

대주제 : IDC 장애가 발생한 상황에 서비스를 지속할 수 있는 방법

 

토스증권 Kafka 활용 현황

거래서 정보, 체결가, 서비스 간 통신 및 비동기처리, 로그, cdc 등 매우 다양하게 kafka를 활용하고 있습니다.

실시간으로 발생하는 로그를 필요에 맞게 변환하기 위해 스트리밍 프로세싱 플랫폼이 필요한데 ksqlDB를 적극적으로 활용하고 있습니다.

위와 같이 핵심이 되는 부분이 kafka를 통해 이루어지기 때문에 kafka는 시스템에서 막중한 임무를 가지고 있습니다.

 

Kafka 이중화 목적

Kafka Cluster 내의 일부 노드 장애 -> 가용성이 유지되어 있어서 괜찮다!  -> 극복 가능한 장애

IDC 전면 장애 -  이중화가 안되어 있으면 더 이상 서비스할 수 없음 -> 이중화를 구성해야 한다.

(IDC 전면 장애가 발생한 예시로는 카카오 화재사건 등등)

 

증권사들은 이를 해결하기 위해 DR을 Active-StandBy로 구성합니다.

장애상황이 잦지 않기 때문에 평시에 잘 관리되지 않으면 StandBy가 제대로 동작하기 어렵습니다.

 

토스증권에서는 2개의 IDC를 모두 Active로 사용하려고 지향합니다.

 

토스증권에서 Kafka 이중화 방법

저장 중인 메시지가 STATE, 클러스터의 구성원 리더가 누구인지 STATE, offset 등이 모두 STATE입니다.

IDC별로 STATE 일관성을 잘 구성해야 합니다.

 

IDC1, IDC2에 유저 트래픽을 50%씩 소화합니다.

Kafka Connect를 활용하여 실시간 메시지를 미러링 합니다.

Offset Sync라는 데몬이 양쪽 IDC 간 Consumer Group offset의 Sync를 맞춰줍니다.

 

이때 IDC1에만 Consumer가 구성되어 있는데 이유로는 양쪽 IDC에 Consumer를 붙여놓으면 중복으로 메시지가 처리됩니다.

(sync를 계속 수행하기 때문)

 

이런 미러링을 수행하기 위해서는  토픽개수만큼 필요하여 수백 개의 운영부담으로 찾아옵니다.

제한된 인원으로 늘어나는 운영비용을 최소화하기 위해 자동화를 통해 공수를 줄이고 있습니다.

 

프로메테우스로 메트릭을 수집하고, 알림을 통해 모니터링 공수도 줄였다.

더 나아가 머신러닝모델도 개발하고 있습니다.

 

IDC 장애 시 대응법

만약 IDC1에서 장애가 나면 첫 번째로 IDC2로 유저 트래픽을 보내야 합니다.

IDC1의 메시지는 미러링을 통해 IDC2로 들어오게 됩니다.

모든 메시지를 IDC2가 가지고 있어 메시지 일관성이 유지됩니다.

 

이제 IDC1에서 사용하던 Consumer가 IDC2를 바라보도록 설정해 주면 됩니다.

Offset도 잘 관리되고 있기 때문에 메시지 중복수신 및 손실 없이 정상적으로 서비스는 유지됩니다.