데이터 중심 에플리케이션 설계 - DAY1

오늘 읽은 범위

• ~ p10

책에서 기억하고 싶은 내용을 써보세요.

• Designing Data-Intensive Applications : DDIA
• 데이터 중심 어플리케이션 : 데이터 양, 데이터 복잡성, 데이터가 변화는 속도 등 데이터가 주요 도전 과제인 어플리케이션을 데이터 중심적이라 함 <-> 계산 중심적(CPU 사이클이 병목인 경우)
• 데이터 시스템의 동작 방식과 왜 그렇게 동작하는지
• 3부로 구성 1. DDIA를 뒷밭침하는 근본 개념, 2. 한 장비에서 분산 저장으로 이동, 3. 특정 데이터셋에서 다른 데이터셋을 파생하는 시스템 설명

Part1 데이터 시스템의 기초

• 모든 상황에서 적용되는 기본 개념

1. 신뢰성(reliability), 확장성(scalability), 유지보수성(maintainability)의 의미와 목표 달성하기 위해 어떻게 해야하는지
2. 다양한 데이터 모델과 질의 언어 비교
3. 저장소 엔진의 내부와 DB가 디스크에 어떻게 데이터를 배치하는지
4. 다양한 데이터 부호화(encoding,직렬화) 포맷을 비교

01장 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 app

데이터 중심적의 문제는 데이터의 양, 복잡도, 변화속도이다
app이 필요로 하는 5가지 요소

• DB(저장), 캐시(읽기 속도 향상), 검색 색인(search index), 스트림처리(stream processing, 비동기 처리를 위한 다른 프로세스로 메시지 보내기), 일괄처리(batch processing, 주기적으로 대량의 누적된 데이터를 분석)
• 데이터 시스템의 원칙, 실용성을 활용한 DIA 개발 방법
• 쉬운 데이터 시스템을 구축하기 위한 기초적인 노력 : 신뢰성, 확장성, 유지보수성

데이터 시스템에 대한 생각

• 왜? why? 데이터 시스템이란 포괄적 용어로 묶는가?
• 이유. because. 1. 더 이상 여러 도구들은 여러 케이스에 최적화 돼어서. 2. 단일 도구로는 처리와 저장을 만족시킬 수 없음.
• 대신 단일 도구로 효율적으로 수행할 수 있는 태스크를 나누고 다양한 도구들은 app 코드를 이용해 연결(NiFi가 이런건가?)
• 신뢰성 : 하드웨어나 소프트웨어 결함, 심지어 인적 오류같은 역경에 직면하더라도 올바르게 동작 애햐한다.
• 확장성 : 시스템의 데이터 양, 트래픽 양, 복잡도가 증가함녀서 이를 처리할 수 있는 방법이 있어야 한다.
• 유지보수성 : 시간이 지남에 따라 여러 다양한 사람들이 데이터 상에서 작업할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야한다.

신뢰성

• app는 사용자가 기대한 기능을 수행

• 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있다.

• 시스템 성능은 예쌍된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족

• 시스템은 허가되지 않은 접근과 오남용을 방지한다.

  올바르게 동작함 -> 잘못되더라도 지속적으로 올바르게 동작함

• 결함 != 장애 : 결함은 시스템의 부분, 장애는 시스템 전체

• 결함으로 인해 장애가 생기지 않도록 설계

• 신뢰할 수 없는 여러 부품으로 신뢰할 수 있는 시스템을 구축하는 다양한 기법 설명

• 넷플릭스의 카오스 몽키의 접근 방식 : 고의적으로 결함을 유도하여 내결함성을 테스트함

하드웨어 결함

• 해결방법은 중복(redundancy)을 추가 한다. 디스크를 RAID 구성으로 설치하고 서버는 이중 전우너 디바이스와 핫 스왑 가능한 CPU를, 데이터 센터는 건전지와 예비 전원용 디젤 발전기를 찾루 수 있도록 구성. 하드웨어가 고장나도 중복된 요소가 대신할 수 있도록 구성
• 단일 장비의 신뢰성보다 유연성과 탄력성을 우선시 함. 시스템을 재부팅 하는 경우에도 중단없이 가능

소프트웨어 오류

• 하드웨어 결함은 무작위적이고 독립적
• 소프트웨어 결함은 발생해야 알 수 있음
• 신속한 해결책이 없고 주의 깊게 생각하기, 빈틈없는 테스트, 프로세스 격리, 죽은 프로세스 재시작 허용, 프로덕션 환경에서 시스템 동작의 축정, 모니터링, 분석하기 등으로 해결에 도움을 줄 수 있음. 시스템적으로는 차이에 대한 경고를 발생시는 방법이 있다.

인적 오류

• 사람은 실수한다.
• 오류의 기능성을 최소화하는 방향으로 시스템을 설계.
• 테스트 열심히하고, 장애 발생하면 빨리 복구할 수 있게, 모니터링(원격측정(텔레메트리))
• 조기교육과 실습을 시행

느낀점 / 소감

• 정리를 잘 못하네. 너무 많은 내용이 있어 복습할때 오래걸리겠다. 만들기도 오래 걸리고
• 모르는 단어나 내용이 많아 보는데 오래 걸리는 것 같다.
• 데이터 시스템이 중요해진 시기가 온 것 같다. 아마 오래된 것 같지만 이제 알게 된 것 같다.
• 설계에 많은 부분이 포함돼 있었는데 나는 어디까지 생각하고 있었는가? 생각해봤다
• 신뢰성에 대해 어렴풋이 알고 있지만 어떠한 부분이 어디까지 인지 정의를 배운 것 같다.
• 개발에 대한 관점이 넓어지는 기분이다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용

• 맵리듀스 : 구글에서 개발한 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작된 프레임워크
• 트레이트 오프
• 레디스 : 메시지 큐로 사용하는 데이터 스토어
• 카프카 : 지속성을 보장하는 메시지 큐
• 맴캐디시
• 결함(fault) : 잘못될 수 있는 일
• 내결함성(fault-tolerant) or 탄력성(resilient) : 결함을 예측하고 대처하는 능력(모든 x, 특정 유형)
• 샌드박스 : 영향력이 없는 비프로덕션