<데이터 중심 애플리케이션 설계> 개발서적 후기

책을 어떻게 접하게 되었냐면,

회사에서 스터디를 하게 되었습니다. 회사에서 맡고 있는 직무가 데이터 기반 백엔드 엔지니어링과 약간의 데이터 사이언스를 하고 있기 때문에, 데이터 중심 프로그램 아키텍처에 관련된 책을 찾아보았던 적이 있습니다. 하지만 "데이터"라고 검색하면 나오는건 데이터사이언스에 대한 파이썬 머신러닝 책뿐이죠.

그래도 그 중에서 몇 가지 책이 눈에 띄었는데, 그 중 하나가 바로 이 데이터 중심 애플리케이션 설계입니다. 이 책을 마침 또 회사 선배님이 회사 책장에 구매해두셔서 빌리러 갔더니 스터디를 제안해주셔서, 사내 스터디를 하게 되었습니다. 총 540쪽을 40쪽씩, 14주간 일정이었습니다.

선배님은 개발 유튜버 노마드코더 영상을 보고 책을 구매요청하셨다는데요, 영상에서 노마드코더가 강조하듯 이 책은 다루기 힘든 거대한 데이터, 소위 말해 빅데이터를 처리하는 요즘 시대의 웹 플랫폼에 대한 이야기를 담고 있습니다. 개발 관련 책이 쏟아져나오지만 그 중 흔치 않은 이론만 있는 서적이고, 따라서 회사의 JS, 파이썬, C++ 등 다양한 언어를 사용하는 개발자들이 부담 없이 스터디에 조인해주셨습니다. 글을 쓰는 지금은 3주차쯤 되었는데 저는 한 2주에 걸쳐 좀 급하게 먼저 읽어보았습니다.

간단히 책에 대해 평가해보자면,

부담 없이 스터디에 조인해주신 개발자분들께 죄송할 정도로 부담이 큰, 엄청 어려운 책이었습니다. 처음에는 단순히 글에 문제가 있다고 생각했습니다. 문장과 문장, 문단과 문단 사이에 연결이 부족해서 읽다보면 혼미해졌고, 그게 3명의 번역가가 서로 다른 문단을 맡아서인가? 라는 생각이 들기도 했습니다. 물론 원서를 보지는 않았으니 알 수가 없었지만요.

읽다보니 사실 글의 문제보다는 책 난이도 자체가 어려웠습니다. 책 자체가 백엔드, 데이터, DB, 운영체제 모두 어느 정도 알고 있는 상급자를 대상으로 하는 책이라 여러가지 개념을 독자가 알고 있다고 가정하고 들어가서 어려웠고, 하나의 장 안에서 최대한 많은 정보를 알려주다보니 세부 사항들에 대해 이해를 못하고 넘어가면 그 다음 문단에서부터 헤매곤 했습니다.

하지만 꾹 참고 보다보면, 요즘 시대에 흔치 않은 이론서적 값을 합니다. 우리는 거대한 데이터에 대해 너무도 걱정없이 프로그래밍하고있습니다. 하지만 큰 데이터를 하드웨어가 따라갈 수 없는데서 생기는 오류들이 생각보다 너무 많습니다. 그 오류들을 놓치지 않도록, 역사적으로 수많은 방법론들과 툴킷들이 데이터를 처리하기 위해 개발되어왔음을, 이 책을 읽으며 알 수 있습니다.

정말 오랜만에 대학생 시절 CS 이론공부로 돌아간 느낌을 받으면서, 백 퍼센트 이해는 안 갔지만, 다음과 같이 맘에 드는 부분만 요약해봤습니다.

---

머리말

• 이런 것들을 찾고 있다면 이 책이 유용하다고 느낄 것: 1) 확장성 있는 데이터 시스템, 즉 수백만 명의 사용자를 감당할 수 있는 웹/앱, 2) 대형 웹사이트와 온라인 서비스의 내부 설계에 사용된 생각들

제1장 - 제4장: 데이터모델과 데이터베이스

• 데이터 중심: CPU보다는 데이터의 양/복잡도/변화속도가 애플리케이션을 제한할 때
• 데이터 시스템: 새로운 도구들은 데이터베이스/큐/캐시와 같은 전통적인 분류에 해당하지 않고, 여러 도구들을 사용해 복잡하게 데이터를 관리
• 트위터의 작동 원리: 트윗을 쓰면 거대 트윗 데이터베이스에 넣고, 트위터 홈 타임라인을 켜면 내가 팔로우하는 모든 사람의 트윗을 찾아 합치기 vs 트윗을 쓸 때마다 나를 팔로우하는 사람의 타임라인 캐시에만 미리 보내놓고 그걸 읽기 → 결론적으로 일반적으론 2번, 팔로워가 많으면 1번
• 관계형 모델: 임피던스 불일치(impedance mismatch): 앱과 DB 객체 간에 필요한 거추장스러운 전환 계층
• 문서 모델: 조인이 없고 정규화가 어려우므로 다대다, 다대일 관계의 중복 제거가 어려움
• 다중 저장소 지속성(polyglot persistence): SQL+NoSQL
• 데이터 웨어하우스: 비즈니스용 트랜잭션 처리 시스템(OLTP)에서 대규모 데이터 분석 시스템(OLAP)로 확장되면서, OLTP에 영향을 주지 않고 OLAP만 할 수 있게 마련된 개별 데이터베이스
• 데이터베이스를 통한 데이터플로: 관점의 전환: 데이터베이스 쓰기는 사실 미래의 나에게 메시지를 보내는 것이 아닐까?
• 서비스를 통한 데이터플로: REST와 RPC: 서버가 API를 네트워크로 공개(서비스)하면 클라이언트가 GET/POST 등 요청을 표준화된 프로토콜(HTTP, URL, SSL, ...)로 보내서 연결
• 메시지를 통한 데이터플로: (메시지 브로커(큐)) 버퍼처럼 동작시켜 안정성 향성, 유실 방지, 여러 수신자로 전송 가능

제5장 - 제9장: 분산 처리에서 만나는 문제점들 - 복제, 파티셔닝, 트랜잭션

• 단일 리더 복제: 리더 서버를 지정해 일단 쓰고, 팔로워 서버들이 복제 로그만 받아서 복사
• "케이크 부인: 보통 10초 정도요, 푼스 씨." "푼스 씨: 미래에 대해 얼마나 멀리 볼 수 있나요, 케이크 부인?"
• 복제 지연: 그래도 팔로워가 리더를 따라잡는데는 시간이 걸림
• 다중 리더 복제:다중 데이터센터마다 리더를 두면서 데이터센터 간 네트워크 지연/중단을 숨길 수 있음
• 리더리스 복제: 읽는 사람이나 미처 못쓴 노드는 여러 곳에 요청한 다음 최신만 사용하면 됨
• 범위 기준 파티셔닝: 키로 범위를 주지만, 타임스탬프를 키로 잡으면 쓰기가 한 파티션을 과부하
• 해시값 기준 파티셔닝: 파티션 나누기엔 좋은데, 범위 색인이 안됨; 앞부분만 해싱해서 파티셔닝하고, 뒷부분은 정렬해서 범위 색인을 하는 복합 기본키 지정도 괜찮음
• 단일 객체에 대한 쓰기만 트랜잭션 보장하는 것보다, 다중 객체에 트랜잭션 보장하는게 훨씬 어려움
• ACID는 유감스럽게도 거의 마케팅 용어가 돼버렸다.
• 오류가 발생하면 이를 취소하는 것은 DB의 책임이 아니라 애플리케이션의 책임 → N번 재시도하든지, 아무튼 오류 처리 메커니즘을 만들어야함
• 좋은 소프트웨어가 설치된 각각의 컴퓨터는 보통 완전하게 동작하거나 전체 장애가 발생하지 그 중간 상태가 되지는 않는다.
• 비잔틴 결함(비잔틴 장군 문제): 여러 노드에서 메시지를 주고받는데 그중 가짜도 있다면?
• 선형성: 시스템에 데이터 복사본은 하나 뿐이며, 모든 연산은 원자적인 것처럼 보이게 함
• CAP 정리: 선형성을 요구한다면 서버 간 연결이 끊기면 아예 사용 불가능해진다는 것 → 선형성을 요구하지 않으면 네트워크 문제에 강해짐 → 선형성과 가용성 중 선택하란 뜻
• 인과성: 전체 순서를 정할 수 있는 선형성과 다르게 두 연산의 상대적, 부분 순서를 정하는 것
• 2단계 커밋(2PC): 코디네이터가 두 노드의 ok 사인을 모두 받아야 커밋 → 원자성 보장

제10장 - 제12장: 맵리듀스와 스트림 - 트렌디한 데이터 처리

• 맵리듀스 순서: 1) 파일을 줄 간격으로 쪼개서 레코드를 만듦 like \n, 2) 맵: 매퍼 함수를 레코드마다 호출해 키와 값을 추출 like awk, 3) 키-값 쌍을 키를 기준으로 정렬 like sort, 4) 리듀스: 키-값 쌍을 대상으로 리듀스 함수를 호출 like uniq -c
• 맵리듀스 vs 일반DB: 맵리듀스는 전체 테이블 스캔을 하므로, 한 샘플을 찾는건 DB의 색인 스캔이 낫지만 대량의 레코드를 집계 연산하는건 병렬 처리가 되므로 더 효율적임
• 메시지 브로커: 유실에 대처하기 위해서는 직접 통신이 아닌 메시지 브로커 DB를 쓸 수 있음
• 로그 기반 메시징: 메시지를 보낼 때마다 지우지 않기 위해 로그를 하되, 여러 메시지를 순서대로 보낼 수 있게 파티셔닝해두고 오프셋만큼만 각 소비자가 옮겨가며 처리하는 방식
• 쓰기와 읽기 간의 밸런싱이 중요: 색인 ↔ 캐시 ↔ 스캔, 결국 현재 상태의 질의보다도 변경 사항의 구독 방식을 염두에 둬야 함
• 결국 정확성이란 무엇인가?: 일관성이라는 말은 결국 적시성(선형성)과 무결성(원자성)의 합, 환불 등 느슨한 유일성을 비즈니스적으로 허락해줄 순 있지만, 이는 적시성의 위반에 해당하지 무결성의 위반은 돌이킬 수 없음
• 알고리즘 감옥: 자동화 시스템은 무죄 추정의 원칙을 보장하지 않는 문제가 있음
• 에코 채임버(echo chamber): 서비스가 보고자 하는 콘텐츠만 보여줘서 생기는 고정관념과 양극화, 인지편향
• 데이터란 단어를 감시로 바꾼다면? 감시 중심 애플리케이션 설계라면?
• 데이터는 정보화 시대의 오염 문제고, 사생활 보호는 환경적 난제다. - 브루스 슈나이어(Bruce Schneier)