🔊 본 내용은 인프런 강의를 보고 요약한 내용입니다. 이해한 것을 정리하였을 뿐, 자세한 내용은 강의를 참고하시길 바랍니다.
1. 역사
- LinkedIn에서 파편화된 데이터를 수집하고 분배하는데 큰 어려움을 겪었다.
- 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타겟 애플리케이션을 연결해야 했다.
- 아키텍처가 거대해지면서 단방향 통신을 통해 연동하던 소스 애플리케이션과 타켓 애플리케이션의 전송 역시 복잡해졌다.
- 링크드인은 아파치 카프카를 개발하여 각각의 애플리케이션끼리 연결하는 방식이 아닌, 데이터를 한 곳에 모아 처리할 수 있도록 중앙집중화 방식을 제시하였다.
- 소스 애플리케이션에서 생성되는 데이터를 어디에 넣을 것인지 고민하지 않고, 카프카에 넣기만 하면 된다.
- 소스 애플리케이션과 타겟 애플리케이션은 1:1 매칭으로 소스 애플리케이션에서 문제가 발생할 경우, 타겟 애플리케이션에 영향을 미쳤다.
- 카프카는 중앙 집중화 방식으로 데이터를 관리하면서, 소스 애플리케이션이 미치는 영향력을 최소화하였다.
2. 빅데이터 파이프라인: 카프카
1) 높은 처리량
- 최소한의 네트워크 비용, 최대한의 효율: 카프카는 네트워크 비용을 줄이기 위해 배치로 데이터를 묶어서 전송
- 네트워크 비용을 줄이기 위해서는 다양한 옵션이 있다. 네트워크 회선을 업그레이드 시킬 수도 있고, 전송 시, 네트워크의 성능을 최대한 이용하는 방법도 있다. 이 외에도 여러 방법이 존재하지만, 카프카는 네트워크 비용 최소화를 위해 데이터를 전송할 때, 배치(한 데 묶어 최대한 많은 양을 전송할 수 있도록) 옵션을 기본적으로 제공한다.
- Scale-out
- 본래는 토픽의 1개의 파티션이 1개의 컨슈머와 연결하는 것이 원칙
- 여러 개의 파티션을 여러 개의 컨슈머와 연결하여 동일 시간당 처리할 수 있는 데이터의 양을 늘릴 수 있도록 함
2) 확장성
- 여기서의 확장성은 들어오는 데이터의 양에 따라 카프카가 가변적으로 대응할 수 있다는 것
- Scale-in과 Scale-out 모두 포함
- 데이터는 많이 들어올 수도 적게 들어올 수도 있다.
- 카프카는 가변적 환경에 안정적으로 확장이 가능하다.
- 평소에는 카프카 클러스터의 브로커를 최소한의 개수로 운영하다가 데이터가 많아지면 클러스터의 브로커 개수를 자연스럽게 늘릴 수 있다.
3) 영속성
- 카프카는 데이터를 파일 시스템에 저장한다.
❓ 카프카는 어떻게 높은 처리량을 보장할 수 있을까?
- 파일 시스템에 저장할 경우 데이터를 읽어오는 시간이 오래 걸릴 수 있다.
- 카프카는 이러한 단점을 보완하기 위해, 페이지 캐시 메모리 영역을 사용하여 한 번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식을 취한다.
- 파일 시스템을 사용하기 때문에 브로커 애플리케이션 장애 발생 시, 카프카는 급작스럽게 종료되더라도 프로세스를 재시작하여 데이터를 다시 읽어올 수 있다는 장점이 존재한다.
4) 고가용성
- 3개 이상의 서버들을 이용한 카프카 클러스터 (브로커의 모음)
- 일부서버에 장애가 발생해도 무중단으로 데이터 처리 가능
- 클러스터로 이루어진 카프카는 데이터 복제가 가능하도록 설계 → 고가용성을 이끔
- 서버를 직접 운영하는 on-premise 환경의 서버 랙, 클라우드의 지역 단위 장애에도 데이터를 안전하게 복제할 수 있는 옵션을 제공
3. 빅데이터 아키텍처
1) 초기 빅데이터 플랫폼
- 앤드 투 앤드
- 데이터를 배치로 모으는 방식을 채택
→ 실시간으로 생성되는 데이터들을 애플리케이션에 빠르게 전달하지 못한다는 단점
- 다음 구조와 같이, 원천데이터 - 파생데이터 - 서빙데이터로 나뉘어져 있어 가공된 데이터의 형태로는 데이터 표준 정책을 지키기 힘들었다.
2) 람다 아키텍처
- 배치 레이어: 데이터를 모아서 특정 시간마다 일괄 처리
- 서빙 레이어: 가공된 데이터를 클라이언트가 사용할 수 있도록 데이터가 저장된 공간
- 스피드 레이어: 서비스에서 생성되는 원천 데이터를 실시간으로 분석
스피드 레이어에 카프카가 위치한다.
- 한계:
- 데이터 처리 방식을 명확히 나눌 수 있지만, 데이터를 분석-처리하는데 배치 레이어와 스피드 레이어 두 개가 존재 (중복)
- 배치 레이어와 실시간 데이터를 융합하여야 할 때 다소 유연하지 못한 파이프라인이 형성됨
- 트위터에서는 이를 해결하기 위해 서밍버드를 만들어 배치 레이어와 스피드 레이어에 적용하는 형태가 있었으나 한계를 극복하지 못했다.
3) 카파 아키텍처 by 제이 크렙스
- 배치 데이터와 스피드 데이터를 한 곳(카프카)에 모으는 방식을 제안
- 배치 데이터와 스피드 데이터를 분산시키면서 데이터의 파편화, 디버깅, 배포 등의 이슈를 제거하기 위해 스피드 레이어에서 모두 처리할 수 있도록 고안
- 서빙 레이어를 없애고 스피드 레이어만 남기는 스트리밍 데이터 레이크 가 고안되었으나 현재 상용화되지는 X
❓어떻게 배치 데이터를 스트림 데이터로 바꿀 수 있을까❓
- 하둡은 배치 데이터를 처리하는 용도로 사용된다.
- 지속적으로 들어오는 데이터(로그)에 카프카는 Timestamp를 추가한다.
- 타임스탬프를 이용하여 변환기록로그를 만들어 모든 시점의 스냅샷 데이터를 저장하지 않고도 배치 데이터를 표현할 수 있게끔 하였다.
담대하게 도전하고 기꺼이 실패를 받아들이는 개발자