Life Engineering

목표트랜잭션의 ACID 속성에 대해 설명할 수 있다.트랜잭션의 Commit/Abort 기능이 애플리케이션에 주는 이점을 설명할 수 있다.동시성 문제의 종류를 이해하고 이를 방지할 수 있는 격리 수준의 종류에 대해 설명할 수 있다. Transaction트랜잭션: 애플리케이션에서 여러 개의 읽기와 쓰기를 하나의 논리적 단위로 묶는 방법, 한 연산으로 실행 됨 전체가 성공(커밋) 하거나 실패(어보트) 함트랜잭션을 사용함으로써 잠재적인 오류 시나리오와 동시성 문제를 무시할 수 있음(all or nothing, 부분적 결과를 허용하지 않음)트랜잭션의 핵심 기능은 오류가 생기면 어보트되고 안전하게 재시도 할 수 있다는 점.ACID?너무 흔하게 들어보는 개념이지만. .DB 마다 ACID 구현이 제각각이다 ..원자성(..

분산 키-값 저장소분산 시스템 설계 시 고려해야 할 점들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를 가진 새로운 브로커를 투입할 경우 곧바로 클러스터에서 유실된 브로커의 자리를 대신해서 이전 브로커의 토픽과 파티..