Life Engineering

현대 웹 서비스: 다양한 소스의 콘텐츠를 조합, 여러 웹 서비스에 접근해야 함→ 즉 외부 서비스나 데이터베이스 결과를 기다리는 스레드를 블록함으로 연산 자원을 낭비하는 일은 피해야함동시성을 구현하는 자바 지원의 진화Runnable, thread → ExecutorService (스레드 실행과 태스크 submit을 분리) → Callable, Future (Runnable, Thread의 변형을 반환) → RecursiveTask (분할/정복 알고리즘의 포크/조인 구현을 지원) → 스트림/람다 지원에 기반한 병렬 프로세싱 → CompletableFuture 지원(분산 비동기 프로그래밍 지원) → Flow 인터페이스 (발행-구독 프로토콜)가능한한 동시에 실행할 수 있는 독립적인 태스크를 가능하게 만들면서 멀..

Netty - async and event-driven기존 blocking model 은 아래와 같음 매 Thread 마다 socket connection 을 가지게 하고, blocking I/O 모델일 경우 다음과 같은 drawback 이 발생할 수 있다 많은 thread 가 I/O 이벤트 결과가 나타날 때까지 기다려야 함각 연결마다 thread 가 배정되는 형태이기 때문에, connection 이 늘어난다면 thread 도 늘어나게 될 것이고 그에 따른 context-switching 비용도 늘어날 것이다그래서 Java NIO 가 도입되었음setsockopt() : socket의 read/write call 이 즉시 리턴됨non-blocking socket 을 등록할 수 있음: event notifi..

목표트랜잭션의 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..