섹션 1. 아파치 카프카의 역사와 미래

정리용 간단용어설명

[K] : Kafka, 카프카

(D) : DATA, 데이터

[P] : Producer, 프로듀서

[C] : Consumer, 컨슈머

Kafka는 링크드인의 장애를 막으려고 만들었다

Source APP : Target APP
1 : 1 로 대응되는 시스템관계에서 시스템이 확장되면 → N : M 까지 사이즈가 커짐

 

이때 장애가 발생한다면? 하나의 시스템에 연동된 모든 APP에 장애가 발생하는 상황이 되는거임

초기 Linkedin에서는 N개의 Source APP ⇒ M개의 Target APP 의 관계를 가지고 있었는데
중앙 시스템이 없다보니, 프로그램 관리가 너무 힘들엇음

 

Kafka는 내부 데이터 흐름 개선을 위해서 만들었다

메세지 큐 구조

카프카는 다음과 같은 구조를 가지고있다
[Producer] → (DATA) → [KAFKA QUEUE] → (DATA) → [Consumer]

 

프로듀서 : 큐에 데이터를 보내는 것
컨슈머 : 큐에서 데이터를 가져가는 것

 

프로듀서가 Kafka에 Data를 보낼때, 데이터가 FIFO 형식으로 적재된다

프로듀서가 데이터를보내면, 여러개의 파티션 중 1개에만 저장됨
컨슈머가 파티션에서 데이터를 가져가도, 파티션 내의 DATA는 없어지지 않는다

 

카프카의 특징 4가지

1. 높은 처리량많은양의 데이터를 묶고, 이를 배치(묶음단위) 로 처리할수 있고
   여러 파티션에 분배하고 데이터를 병렬처리할수도 있다여담으로, 하나의 프로듀서는 하나의 파티션에만 데이터를 보낼수 있고,
   하나의 컨슈머는 여러개의 파티션에서 데이터를 받을수 있다
2. 파티션 갯수만큼 컨슈머 갯수를 늘려서, 동일시간당 데이터처리량 늘리는것도 가능하다
3. [Producer] → (DATA) → [QUEUE] → (DATA) → [Consumer] 에서
   Producer, Consumer가 데이터를 보내고받을때, DATA를 모두 묶어서 전송한다.
   많은양의 데이터를 송수신할때 생기는 네트워크비용은 무시할수 없다.
4. 확장성데이터의 양이 많아지면 브로커의 갯수를 늘려서 (스케일아웃, Scale OUT) 확장시킬수 있게 해놨고,
   데이터의 양이 적어지면 브로커의 갯수를 줄여서 (스케일인, Scale IN) 규모를 축소시킬수 있게 해놨다
5. 파이프라인을 구성할때 생각해야할것중 하나는 ‘데이터가 얼마나 들어오고, 이를 손실없이 처리하려면 어떻게 해야할까’ 이다. 카프카는 가변적인 환경에서도 안정적으로 확장가능하도록 설계되어있고
6. 영속성일반적으로 DATA를 메모리에 저장하는 일반 메세징 플랫폼과 다르게, Kafka는 파일시스템에 저장한다.
   운영체제 레벨에서 파일시스템을 활용하고, 특히 페이지캐시 영역을 메모리에 따로 생성해서 사용하는 방식을 사용한다.
7. 영속성 : 프로그램이 종료되더라도, 데이터는 사라지지 않는다.
8. 고가용성이때, 카프카는 데이터의 복제(replication)을 하여, ‘한 브로커에 장애가 발생해도, 동일한 데이터(복제된 데이터)가 나머지 브로커에 저장되어있으므로, 저장된 데이터를 기준으로 지속적인 처리를 할수 있다. 라는게 가장 큰 카프카의 장점이다
   • [P]는 DATA를 [B] 1개에 보낸다
   • [B]는 (D)를 자체적으로 복제해서, 나머지 [B]도 모두 동일한 (D)를 가진다.
9. 일반적으로 카프카의 서버는 3대 이상을 1개의 클러스터로 묶어서 사용한다.
   이는 운영중인 서버1대가 맛탱이가가서 작동을 못해도, 나머지 2대의 서버로 작동시켜서 → 서버를 안전하게 작동시키게 하기 위함이다

빅데이터 아키텍쳐의 변천사

1. 초기 빅데이터 플랫폼
   • 구조 : 원천데이터 → 파생데이터 → 서빙데이터
   • 특징 : 배치처리 못함, 실시간 못함
2. 람다 아키텍쳐
   • 구조 : 데이터 → 배치레이어 → 서빙레이어 / 데이터 → 스피드레이어 → 서빙레이어
   • 특징 : 배치레이어에서 배치일괄처리, 스피드레이어에서 실시간처리, 서빙레이어에서 APP이 사용할수 있는 상태로 유지
   • 한계 : 데이터가 배치레이어, 스피드레이어로 각각 들어가기 때문에 결국 동일한 데이터에 대해서 다른 처리를 한번씩해야함. 즉, 동일한 데이터를 2번 처리해야함
3. 카파 아키텍쳐
   • 구조 : 데이터 → 스피드레이어 → 서빙레이어
   • 특징 : 배치레이어가없고 모두 스피드레이어로 보냄
   • 활용 : STREAM DATA → BATCH로 사용
   • 일정 수준모인 스트림데이터를 스냅샷으로 남기자 → 그럼 모든 데이터를 batch처리 할수 있겠다 → 배치데이터를 스트림으로 표현할때 Log로 바꾸자
   • 배치 데이터에 대한 스냅샷을 찍어서 → 이를 로그로 만들고, 시간 순서대로 기록하게 해두자 (Timestamp사용)

    배치데이터 : 한정된 데이터처리, 대규모 배치 데이터를 위한 분산처리 수행, 지연시간(김), 키 조인(복잡함)
    스트림데이터 : 무한데이터처리, 지속적으로 들어오는 데이터를위한 분산처리 수행, 지연시간(분단위 이하), 키조인(단순)