Life Engineering

분산 키-값 저장소분산 시스템 설계 시 고려해야 할 점들CAP 정리데이터 일관성 (Consistency) : 분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐에 상관없이 언제나 같은 데이터를 봐야 함가용성 (Availability) : 분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 함파티션 감내 (Partition tolerance): 파티션은 두 노드 사이에 장애가 발생하였음을 의미, 파티션 감내는 네트워크에 파티션이 생기더라도 시스템은 계속 동작함을 의미이 3가지 요소를 동시에 만족시키는 분산 시스템을 설계하는 것은 불가능하다. 네트워크 장애는 피할 수 없는 것으로 여겨지므로, 파티션 감내는 반드시 감내할 수 있도록 설계되어야 함. 보통..

이번 장에서는 어떻게 데이터를 고르게 분산할 수 있는지에 대해 알아본다.일반적으로, 데이터를 N 개의 서버에 나누어서 저장하게 될 때 해시 함수를 이용해서 데이터를 분배해서 저장하는 방법을 생각하게 된다. (해시 테이블과 유사)그러나 이 방법은 다음과 같은 취약점이 있다.특정 서버에 장애가 발생할 경우, 장애가 발생한 서버에 저장된 데이터가 모두 재배치 되어야 한다캐시 서버일 경우, 장애가 발생한 서버에 저장된 키였을 경우 그 키에 대한 데이터가 없는 다른 서버에 접속하게 되어 대규모 cache miss 가 날 수 있다Hotspot key 문제가 발생할 수 있다 → 데이터를 균등하게 배치하지 못해 특정한 샤드에 대한 접근이 많을 경우이다.안정 해시(consistent hash) 는 해시 테이블 크기가 조..

애플리케이션에 적합한 데이터 모델을 선택하는 방법 ..과 그 모델에 따른 질의 언어에 대해 알아보자 ..관계형 모델과 문서 모델관계형 모델과 문서 모델은 어떻게 다를까?관계형 모델은 보통 우리가 아닌 RDB로, 관계 로 구성되고 각 관계는 튜플 의 모음임BUT RDB에는 다음과 같은 drawback 이 있음동적이고 변하는 스키마에 대응하기 어려움관계형 모델에서 지원하지 않는 특수 질의 동작대규모 데이터셋 or 높은 쓰기량 달성을 해야 할 경우또한 RDB 에서, 데이터를 테이블에 저장하려면 app 코드 ↔ DB 모델 객체 간 전환 계층이 필요 (임피던스 불일치)linkedin 예제를 보면, 같은 table 데이터를 JSON 형식으로 저장할 수 있음 SON 형식으로 데이터를 저장 (= 문서 형식으로 데이터를..

데이터베이스의 저장 및 검색 처리 방식에 대해 다룬다. 색인 자료 구조해시 색인 이 방식은 키를 데이터 파일의 바이트 오프셋에 매핑해 인메모리 해시 맵을 유지하는 방식비트캐스크(bitcask) 에서 사용 — 해시 맵을 전부 메모리에 유지하기 때문에 RAM에 모든 키가 저장,메모리에 모든 키를 보관할 수 있을 만큼 키 수가 작지만 각 키의 값이 자주 갱신되는 상황(=키당 쓰기 수가 많은 경우) 에 유리데이터가 저장되는 로그 파일을 무한정 append 하면 디스크 공간이 부족해 질 것 →컴팩션(compaction) 을 수행하여 각 로그에서 중복된 key 를 버리고 각 키의 최신 값만 유지함컴팩션 수행 시, 크기를 줄이기 위해 동시에 여러 다른 세그먼트 파일을 병합하게 됨세그먼트 파일들의 컴팩션과 병합은 백그..

카프카 운영하기토픽 작업kafka-topics.sh 사용새 토픽생성: —topic, —repolication-factor(레플리카 수), —partitions (파티션 수)토픽 목록 조회: —list토픽 상세 내역 조회: —describe—under-replicated-partitions: 1개 이상의 레플리카가 리더와 동기화되지 않고 있는 모든 파티션—at-min-isr-partitions: 레플리카 수가 인 싱크 레플리카 수의 최소값과 같은 모든 파티션—under-min-isr-partitions: ISR 수가 쓰기 작업에 성공하기 위한 최소 레플리카 수에 미달하는 모든 파티션 , 이 파티션들은 읽기 전용파티션 추가하기: —alter —topic my-topic —partitions N파티션 개수 줄..

데이터 파이프라인 구축하기카프카는 데이터 파이프라인 단계 사이사이에서 매우 크고 안정적인 버퍼 역할을 해줄 수 있음데이터 파이프라인의 읽는 쪽, 쓰는 쪽을 분리함으로써 하나의 원본에서 가져온 동일한 데이터를 다른 적시성 / 가용성 요구 조건을 갖는 여러 대상 애플리케이션이나 시스템으로 보낼 수 있음데이터 파이프라인 구축 시 고려사항적시성좋은 데이터 통합시스템은 시스템의 각기 다른 적시성의 요구 조건을 지원해야 하고 요구 조건이 변경되었을 때도 유연하게 대처해야 함카프카는 실시간으로 작동되는 데이터 파이프라인부터 배치 작업에 이르는 모든 작업에 사용될 수 있음카프카는 쓰는 쪽, 읽는 쪽 모두 시간적 민감도에 대한 요구 조건을 분리시키는 거대한 버퍼가 될 수 있음 (쓰는 쪽이 어떤 속도로 쓰든 읽는 쪽은 스..

신뢰성 있는 데이터 전달카프카가 보장하는 신뢰성카프카는 파티션 안의 메시지들 간의 순서를 보장클라이언트가 쓴 메시지는 모든 in-sync replica 의 파티션에 쓰여진 뒤에 커밋 된 것으로 간주프로듀서는 acks 설정에 따라 메시지가 커밋된 다음 응답이 올지, 리더에만 쓰여졌을 때 응답이 올지, 네트워크 전송된 다음 응답이 올지 결정할 수 있음커밋된 메시지는 최소1개의 작동 가능한 레플리카가 남아있는 한 유실되지 않음컨슈머는 커밋 된 메시지만 읽을 수 있음복제모든 이벤트들은 리더 레플리카에 쓰여지며, 대체로 리더 레플리카에서 읽혀짐다른 레플리카들은 리더 레플리카와 동기화를 맞추며 최신 이벤트를 복사해 감리더 레플리카가 죽을 경우, 인 싱크 레플리카 중 하나가 리더가 됨다음 아래 조건에 따라 in-sy..

KafkaProducer Client InternalsKafka Producer Client는 3가지 요소로 구성KafkaProducer: send() 를 호출함으로써 Record 를 전송RecordAccumulator: send() 를 호출하면 Record 가 바로 Broker에 전달되는 것이 아니라, RecordAccumulator 에 우선 저장됨. Broker 에 전달되는 것은 비동기 적으로 이루어짐Sender: 별도의 Sender Thread를 생성RecordAccumulator 에 저장된 Record를 Broker 로 전송하는 역할을 함Broker 응답 받으면 사용자가 설정한 콜백이 있으면 실행하고, Broker 로부터 받은 응답 결과를 Future 통해서 전달함KafkaProducer// cr..

클러스터 멤버십아파치 주키퍼는 현재 클러스터의 멤버인 브로커들의 목록을 유지하기 위해 사용됨각 브로커는 고유한 식별자를 가지고 브로커 프로세스는 시작될 때마다 주키퍼에 Ephemeral 노드 의 형태로 ID 를 등록함컨트롤러를 포함한 카프카 브로커들은 브로커가 등록되는 /brokers/ids 경로를 구독함으로써 브로커가 추가되거나 제거될 때마다 알림을 받음브로커와 주키퍼 간의 연결이 끊어질 경우 생성된 Ephemeral 노드는 자동으로 주키퍼에서 삭제되고, 이 브로커 목록을 지켜보고 이던 카프카 컴포넌트는 이 브로커가 내려갔음을 알게 됨특정한 ID를 가진 브로커가 완전히 유실되어 동일한 ID를 가진 새로운 브로커를 투입할 경우 곧바로 클러스터에서 유실된 브로커의 자리를 대신해서 이전 브로커의 토픽과 파티..

컨슈머와 컨슈머 그룹컨슈머는 카프카에서 토픽을 구독하고 구독한 토픽들로부터 메시지를 받는 주체주로 여러 개의 컨슈머가 같은 토픽으로부터 데이터를 분할해서 읽어옴카프카 컨슈머는 보통 컨슈머 그룹 의 일부로서 작동하고, 동일한 컨슈머 그룹에서 여러 개의 컨슈머들이 동일한 토픽을 구독할 경우 각각의 컨슈머는 해당 토픽에서 서로 다른 파티션의 메시지를 받게 됨 (출처: https://medium.com/codex/apache-kafka-series-part-2-partitions-consumer-group-and-offset-management-fbb08839edfa)컨슈머 그룹에서 컨슈머를 추가하면 토픽에서 읽어오는 데이터 양을 확장할 수 있게 됨만약 카프카 컨슈머가 지연시간이 긴 작업을 수행하고 현재 컨슈머..