카프카의 역할과 탄생 이유

들어가기전, 나의 생각

한동안 주변 부동산 가격을 보면서 일에 대한 의지가 많이 내려갔으나, 이대로 가다간 이도저도 안될 것 같아서 책을 주문 후 공부를 시작하는 첫날이다. 첫날로써 많은 공부는 하지는 못하겠지만 시작하겠다.

 

 

카프카가 왜 생겨났을까?

결론만 말하면 '링크드인'이라는 회사가 필요로 인하여 만들었다. 기존 프로그램은 소스 애플리케이션과 타킷 애플리케이션을 연결하는 파이프 라인 개수가 많아지면서 소스코드 및 버전 관리에서 이슈가 생겼다. 그리고 타킷 애플리케이션에 장애가 생길 경우 그 영향이 소스 애플리케이션에 그대로 전달이 되었기 때문에 이러한 장애를 애결하고자 '아파치 카프카'를 만들었다. 

아래의 그림을 보게 된다면 카프카 도입과 이후의 아키텍쳐를 확인 할 수 있다. 카프카의 도입 후 아키텍쳐를 보게 된다면 각각의 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라 한 곳에 모아 처리할 수 있게 중앙집중화를 진행하였다. 중앙에 배치된 카프카는 소스 애플리케이션과 타깃 애플리케이션 사이의 의존도를 최소화하여 커플링을 완화하였다. 그래서 소스 애플리케이션에서 생성되는 데이터를 어느 타깃 애플리케이션으로 보낼 것인지 고민하지 않고 카프카로 넣으면 된다.

카프카 도입 이전 아키텍쳐

카프카가 적용된 이후의 파이프라인 아키텍쳐

 

 

 

빅데이터 파이프라인에서 카프카의 역할

높은 처리량

• 카프카는 프로듀서가 브로커로 데이터를 보낼 때와 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송한다.
  • 많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수 없는 규모이기 때문에 네트워크 통신 횟수를 최소한으로 줄인다면 동일 시간내에 많은 데이터를 전송이 가능하다.
• 많은 양의 데이터를 묶음 단위로 처리하는 배치로 빠르게 처리할 수 있다.
  • 대용량의 실시간 로그데이터를 처리하는데 적합하다
  • 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬로 처리 가능

확장성

• 가변적인 환경(하루 100건 또는 1000만건이 들어오는 경우)에서 안정적으로 확장 가능하도록 설계
• 데이터가 적을 때는 카프카 클러스터의 브로커를 최소한의 개수로 운영하다가 데이터가 많아지면 클러스터의 브로커 개수를 자연스럽게 늘려 스케일 아웃할 수 있다. 반대로 브로커의 갯수를 줄이는 스케일 인도 가능하다.

영속성

• 영속성이란 데이터를 생성한 프로그램이 종료 되더라도 사라지지 않는 데이터들을 뜻한다.
• 다른 메시지 플랫폼과 다르게 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장한다.
  • 운영체제 레벨에서 파일 시스템을 최대한 활용하는 방법을 사용하였다.
    • 운영체제 레벨에서 파일 시스템을 최대한 활용하는 방법을 적용
    • 페이지 캐시(page cache)영역을 메모리에 따로 생성하여 사용
    • 페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식
  • 위와같이 페이지 캐시 영역을 사용하기 때문에 데이터를 저장 전송하더라도 처리량이 매우 높다.
• 파일시스템을 사용하기 때문에 중간에 에러 및 재시작을 하더라도 중단된 부분부터 시작할 수 있다.

고가용성

• 카프카 클러스터를 구척할 때 브로커의 개수의 제한은 없다.
• 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 아전하고 지속적으로 데이터를 처리할 수 있다.

카프카 클러스터를 3대 이상의 브로커들로 구성되어야 하는 이유
   - 1대로 운영할 경우 브로커의 장애는 서비스의 장애로 이어진다.
   - 2대로 운영할 경우 한대의 브로커에 장애가 발생하더라도 처리가 가능하나 브로커 간에 데이터가 복제되는 시간 차이로 일부 데이터에 대한 유실이 발생할 수 있다.
   - 3대 이상의 브로커들로 구성을 한다면 1개가 자앵가 나더라도 지속적으로 데이터를 처리할 수 있다.

• 클러스터로 이루어진 카프카는 데이터의 복제(replication)을 통해 고가용성의 특징을 가지게 되었다.

 

데이터 레이크 아키텍쳐

레거시 데이터 플랫폼 아키텍처

레거시 데이터 플랫폼

• 데이터를 배치로 모으는 구조
• 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못하는 단점이 존재
• 데이터의 가공으로 인해 데이터가 파편화되면서 데이터 거버넌스(데이터 표준 및 정책)를 지키기 어려움

위와같이 레거시 데이터 플랫폼 아키텍처의 단점이 분명하기 때문에 새로운 아키텍쳐를 설계했는데 그 아키텍쳐는 람다 아키텍처와 카파아키텍쳐이다.

 

람다 아키텍처

위와같이 람다 아키텍쳐는 크게 3가지로 나뉜다.

배치 레이어

• 배치 데이터를 모아서 특정 시간, 타이밍 마다 일괄 처리

서빙 레이어

• 가공된 데이터를 데이터 사용자, 서비스 애플리케이션이 사용할 수 있도록 데이터가 저장된 공간

스피드 레이어

• 서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용
• 배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우 사용
• 가공, 분석된 실시간 데이터는 사용자 또는 서비스에서 직접 사용할 수 있지만 필요한 경우에는 서빙 레이어로 데이터를 보내서 저장하고 사용 가능
• 카프카가 존재하는 레이어
  • 카프카가 존재하기 때문에 실시간 데이터를 짧은 지연시간으로 처리, 분석할 수 있다.

단점

• 데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어를 분리한 람다 아키테거는 데이터 처리 방식을 명확히 나눌 수 있었지만 레이어가 2개로 나뉘는 단점이 존재
  • 데이터를 분석, 처리하는 필요한 로직이 2벌로 각각의 레이어에 따로 존재 -> 로직의 파편화
• 배치 데이터와 실시간 데이터를 융합하여 처리할 때는 다소 유연하지 못한 파이프라인을 생성
  • 해당 이슈를 해결하기 위해 서밍버드가 존재했지만 배치 레이어와 스피드 레이어에 각각 디버깅과 배포를 진행

 

카파 아키텍처

특징

• 람다 아키텍처와 비슷하지만 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리
• 람바 아키텍쳐의 단점인 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈의 원인인 배치 레이어를 제거
• 스피드 레이어에서 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리

배치 데이터
   - 초, 분, 시간, 일 등으로 한정된 기간(bounded) 단위 데이터를 뜻한다.
   - 해당 데이터는 일괄 처리를 진행한다.
스트림 데이터
   - 한정되지 않는(unbounded) 데이터로 시작 데이터와 끝 데이터가 명확히 정해지지 않은 데이터를 뜻한다.
   - 각 지점의 데이터는 보통 작은 단위(KB)로 쪼개져 있으며 웹 사용자의 클릭 로그, 주식 정보, 사물 인터넷의 센서 데이터 스트림를 뜻한다.

 

 

 

 

 

참고

 - 아파치 카프카 애플리케이션 프로그래밍 with 자바 

     - https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=268985828 

아파치 카프카 애플리케이션 프로그래밍 with 자바