읽다가 정리할 만한 점들을 기록함.
1장
신뢰성
시스템이 오류, 결함 없이 잘 동작해야 한다는 의미
- 하드웨어 결함
- 소프트웨어 오류
- 휴먼 에러
하드웨어 결함의 경우, 데이터 연산량에 따라 하드웨어 개수도 늘어나는 경향이 있고 이에 비례해 결함 수도 증가하는 경향이 있다.
소프트웨어 오류 방지 방안으로 프로세스 격리, 측정, 모니터링, 분석을 통해 경고를 발생시켜야 한다.
휴먼에러 방지 방안으로는 샌드박스(실제 데이터 이용하여 실험해볼 수 있는 공간)을 마련해보거나, 모니터링 대책, 복구 방안을 마련해야 한다.
도커에서 말하는 프로세스 격리가 소프트웨어 오류 방지 방안이라는 말이 유의미하게 다가왔다.
실제 업무에서 나온 시스템 결함들을 회고해보았을 때 샌드박스를 잘 구축해놓았으면 방지했을 수도 있겠다 생각했다. (근데 FEP, EAI 외부 통신은 어떻게 해야 하나)
확장성
대용량 트래픽에도 잘 견뎌야 한다는 의미
유지보수성
이후 시스템 변화 시 발생 비용이 적어야 한다는 의미
운용성 - 원할하게 운영할 수 있도록 쉽게 만들어라
자동화 할 수 있는건 자동화하자
좋은 문서와 이해하기 쉬운 운영 모델 제공
좋은 모니터링으로 런타임 동작과 시스템 내부에 대한 가시성 제공
단순성 - 복잡도 관리
코드의 가독성
발전성 - 변화를 쉽게 만들기
2장
관계형 모델 / 문서형 모델 / 그래프 모델
3장
해시 / LSM 트리 / B 트리
OLTP / OLAP
4장
직렬화 포맷 - JSON, XML, CSV, 이진 부호
"123"과 123은 XML이나 CSV에서는 구분할 수 없다.
엄청 큰 수(2^53 이상)는 부동소수점을 사용하면 정확하게 표현할 수 없다. 그런데 JS의 경우 부동소수점을 사용하므로 파싱할 때 부정확해질 수 있다.
JSON이나 XML은 사람의 텍스트는 잘 지원하나 이진 문자열(문자열에서 숫자로 변환된 바이트열)은 지원하지 않는다.
CSV는 스키마가 없으므로 모호한 면이 있다. 특히 개행이나 " , 자체를 표기하고 싶을 때 모호한 측면이 있다.
프로세스 간에 데이터를 교환하고 싶을 때 어떤 방법이 있을 수 있는가?
- DB에 저장하고 읽어가기
- 서비스 호출(REST API, RPC)
- 비동기 메시지 전달
DB에 저장하고 읽어갈 때 발생할 수 있는 문제
데이터 유실 가능성
상위 호환성(과거 코드가 -> 미래 데이터 참조)와 하위 호환성(미래 코드가 -> 과거 데이터 참조)를 고려해야 한다.
예를 들면 새 필드 추가 시 예전 버전 코드가 읽어가면 복호화(JSON -> Java Object)할 때 데이터가 유실될 수 있다.
RDB는 스키마가 특정 시점에 반드시 하나
이를 유지하기 위해서는 마이그레이션 하거나, 새 필드를 추가할 때 디폴트 값으로 null이 허용된다.
이러한 메커니즘 덕분에 최종적으로 스키마가 변함에 따라 전체 DB가 단일 스키마로 부호화된 것처럼 보이게 해준다.
반면에 문서형 DB(NoSQL)은 SchemeLess이기에 유의가 필요하다.
메시지 브로커(ex. Kafka)가 RPC 보다 나은 점
- 수신자가 사용 불능 상태일 때 버퍼처럼 동작하게 할 수 있다.
- 메시지 유실을 방지할 수 있다.
- 송신자가 수신자 정보를 알 필요가 없다. (특히 클라우드 환경에서 이점으로 작용함)
- 논리적으로 디커플링을 가져갈 수 있다. (송신자는 누가 소비하는지 관리할 필요x)
- 하나의 메시지를 여러 수신자로 전송할 수 있다.
+그리고 메시지 브로커는 특정한 데이터 모델을 강요하지 않는다.
RESTful API
HTTP 기능을 어느 정도 사용한다.
간단한 데이터 타입을 강조하고, URL을 사용해 리소스를 식별한다.
API 버전을 관리하기 위해 URL이나 Accept 헤더를 사용하는 것이 일반적이다.
