최근 핀다 시스템 전체를 MSA로 전환 중에 있으며, 리액티브 요소를 강화하기 위해 카프카를 도입했습니다. 카프카 없이도 MSA를 구성할 수 있지만, 진정한 MSA라면 카프카와 같은 기술은 도입이 필수입니다. 리액티브 시스템과 카프카 관련 IBM의 좋은 글이 있어 공유하고, 추가적으로 제 조언을 추가하니, 카프카를 통해 MSA를 구축하려는 분들께 많은 도움이 되길 바랍니다^^ 카프카 기반 리액티브 시스템인란? - 리액티브(반응형) 시스템은 논블록킹, 비동기 메시지 기반이며, 느스한 결합(Loosely Coupling), 독립성, 투명성을 강화한다. - 논블록킹 메시지 처리는 액티브 상태에서만 리소스를 활용하게 하여 전체적인 시스템 오버헤드를 줄이고, 비동기 기반의 명시적 메시지 처리는 메시지 큐(카프카에서는 토픽) 기반으로 전체적인 시스템 처리 흐름을 조율함으로써, 부하 관리, 탄력성, 플로우 컨트롤을 가능하게 한다. - 카프카는 리액티브 시스템을 구축할때 가장 훌륭한 도구이며, 애플리케이션에 복원력(Resiliency)과 탄력성(Elasticity)을 지원한다. 카프카는 구성성이 뛰어나(Highly Configurable), 애플리케이션에 따라 맞춤 제작(Tailoring)이 가능하다. 리액티브 시스템을 위해 카프카를 구축할때 고려해야 할 사항은 다음과 같다. 1. 복원력 지원 (Enabling resiliency) 카프카는 복원력을 내장하고 있음 => 분산 노드를 기반으로 클러스터 환경으로 카프카를 구축하기 때문이며, 시스템이 처리하는 전체 트래픽 및 메시지 수를 기반으로 노드 수 및 레플리카 팩터(Replica Factor)를 잘 정의해야 하는 것이 기본이며, 뒤에 나올 승인, 재시도 정책 및 오프셋 커밋 전략, 컨슈머 그룹 전략 등도 복원력을 강화시키는 중요한 요소이다. 2. 승인 및 재시도 정책(Acknowledgements and retries) 카프카는 “적어도 한 번(at least once)“과 "최대한 한 번(at most once)”의 두 가지 기록 전달 방식 중 하나로 설정되며, 리액티브 시스템에서 가장 일반적인 것은 “적어도 한번” 임 => “적어도 한번”은 acks 설정 값을 모두로 설정하거나 빠른 응답을 위해 최소 1로 설정할 수 있으며, “최대한 한번”은 acks 설정 값을 0이거나 1(최대한 한명)로만 설정할 수 있어 미션 크리티컬한 메시지를 처리하는 데는 적합하지 않다. (at least once로 설정하고 acks를 상황에 맞게 조정하는 것을 추천함) 3. 오픈셋 커밋 전략 (Committing offsets) 오프셋은 컨슈머가 토픽(Topic)을 읽거나 처리한 마지막 레코드를 가리키며, 애플리케이션이 다운되었을 경우 중단되었던 부분을 찾아갈 수 있게 카프카에 오프셋을 커밋함 자동커밋은 특정 시간 뒤에 자동으로 오프셋이 커밋됨으로, 애플리케이션이 레코드를 읽어 간 뒤에 자동커밋되고, 애플리케이션이 다운되면 애플리케이션이 복구된 후에 오프셋이 그 다음 레코드를 가리키고 있어서 원래 처리했던 레코드는 손실될 수 있어, 수동커밋이 리액티브 시스템에서 중요하며, 수동커밋은 오프셋은 레코드가 완전히 처리된 후에 명시적으로 오프셋을 커밋할 수 있음 => 카프카는 자동커밋이 디폴트이며, 5초가 기본 커밋 시간이다. 간단한 시스템을 구축할 때는 이렇게 써도 충분하지만, 자동커밋을 비활성화하고 수동커밋을 통해 리액티브 요소를 강화해야 한다. 4. 탄력성 지원 (Enabling elasticity) 카프카는 탄력성을 내장하고 있으며, 탄력있는 프로듀서와 컨슈머를 잘 구축하는 것이 중요함 => 프로듀서는 특별히 구축할 때 신경쓸 부분이 없고, 대부분 컨슈머와 관련된 구축, 설정이 중요한데, 컨슈머 그룹과 토픽의 파티션을 통해 이를 설계할 수 있다. 하나의 토픽을 소비하는 컨슈머를 여러개 두게되면, 하나가 다운되더라도 다른 컨슈머가 정상적으로 메시지를 소비할 수 있게 하며, 토픽의 파티션을 여러개 두게되면, 한 컨슈머 그룹 안에 있는 여러 컨슈머가 동시에 파티션의 메시지를 소비할 수 있어 처리 속도를 향상시킬 수 있다. (참고, 하나의 파티션에는 하나의 컨슈머만 접근 가능)