📝 상세 정리 # 이번 장에선 JSON, XML, 프로토콜 버퍼, Thrift, Avro를 비롯해서 데이터 부호화를 위한 다양한 형식을 살펴볼 것이다. 특히 어떻게 스키마를 변경하고 예전/새로운 버전의 데이터와 코드가 공존하는 시스템을 지원할지! 그리고 REST 원칙과 remote procedure call, actor과 같은 메세지 전달 시스템에서도 어떻게 사용되는지 알아보자. 데이터 부호화 형식 # 언어별 형식 # JSON과 XML, 이진 변형 # 이진 부호화 # 스리프트와 프로토콜 버퍼 # 필드 태그와 스키마 발전 # 데이터 타입과 스키마 발전 # 아브로 # 쓰기 스키마와 읽기 스키마 # 스키마 발전 규칙 # 그러면 쓰기 스키마는 무엇인가? # 동적 생성 스키마 # 코드 생성과 동적 타입 언어 # 스키마의 장점 # 데이터플로 모드 # 데이터베이스를 통한 데이터플로 # 다양한 시점에 기록된 다양한 값 # 보관 저장소 # 서비스를 통한 데이터플로: REST와 RPC # 웹 서비스 # 원격 프로시저 호출(RPC) 문제 # RPC의 현재 방향 # 데이터 부호화와 RPC의 발전 # 메세지 전달 데이터플로 # 메시지 브로커 # 분산 액터 프레임워크 # 정리 # ❔질문 사항 # 🔗 참고 자료 #

📝 상세 정리 # 인트로 # 가장 기본적인 수준에서 데이터베이스는 두가지 작업을 수행한다 데이터 저장하기 데이터 제공하기 이번 장에서는 데이터베이스가 데이터를 저장하는 방법과 데이터를 찾는 방법을 설명하겠다. 이걸 왜 알아야 할까? 저장소 엔진을 직접 구현하는게 아니라 선택하니까, 대략적으로는 알고 고르자. RDB, NoSQL에 대해서 우선 할건데 로그 구조 계열 저장소 엔진 페이지 지향 계열 저장소 엔진 을 검토할것 데이터베이스를 강력하게 만드는 자료구조 # 걍 배시로 db_set(){ echo "$1, $2" >> database } db_get () { grep "^$1, " database | sed -e "s/^$1, //" | tail -n 1 } 이라는 db를 만들면, 쓰기는 매우매우 빠르다. 겹쳐도 걍 뒤에 써버리고, -tail로 하나만 가져오니까. 로깅도 비슷한 느낌인걸 잘 알지 않나? 이런 append-only 데이터 파일을 로그(log) 라고 한다. 로그는 사람이 읽을 수 있는 형식일 필요도 없다. 암튼 db_set은 빠른데, db_get은 O(N)으로 개느리다. 그래서 다른 데이터 구조가 필요한데.. 색인 에 대해서 알아보겠다. 다양한 색인 구조를 살펴보고 여러 색인 구조를 비교해보자. 색인의 일반적인 개념은 어떤 부가적인 메타데이터를 유지하는 것이다. 이는 이정표 역할을 해서, 원하는 데이터의 위치를 찾는데 도움을 준다. 색인은 기본 데이터 (primary data)에서 파생된 추가적인 구조이다. 많은 DB는 색인의 추가/삭제를 허용하고 이는 내용에 영향을 미치지 않는다. 추가적인 구조의 유지보수는 오버헤드를 발생시킨다. 보통 쓰기속도를 느리게 만든다. 이것이 저장소시스템에서 중요한 트레이드오프이다. 해시 색인 # key-value 데이터를 색인해보자.

📝 상세 정리 # 인트로 # 데이터 모델은 소프트웨어 개발에서 제일 중요하다 특히 데이터 모델을 표현하는 방법이 중요한데 어떤 데이터를 저장할것인가 (사람 / 조직 등) 어떤 형태로 저장할것인가 (json / xml 등) 어떤 장소에 저장할것인가 (램 / 하드디스크 등) 어떤 방식으로 저장할것인가 (전류 / 빛의파동 등) 결국 이들을 추상화시키는게 중요하다. 관계형 모델과 문서 모델 # 1970년 에드가 코드가 제안한 관계형 모델을 기반으로한 SQL이 젤 잘 알려져있는데

📝 상세 정리 # 인트로 # 오늘날 많은 애플리케이션들은 계산 중심이 아닌 데이터 중심적 애플리케이션을 제한하는 요소는 CPU 성능이 아닌, 데이터의 양 / 복잡도 등이라는 것 데이터를 저장 (DB) 데이터를 빠르게 읽기 (캐시) 검색과 색인 비동기 처리 (스트림) 주기적으로 분석 (배치 처리) 위와 같은것들을 진행해야하기 때문! 데이터시스템에 대한 생각 # 우리는 DB / 큐 / 캐시 등을 다르게 생각한다. 하지만 이걸 데이터 시스템이라고 묶어서 생각하자. 어차피 분류도 흐려지고 있으니까! 메세지큐로 사용하는 데이터스토어인 Redis 지속성을 보장하는 메세지큐인 Kafka 애플리케이션이 단일 도구로는 만족하기 어려울정도로 과도하고 광범위한 요구사항을 가지니까! 아무튼 소프트웨어 시스템에서는 그러면 신뢰성 / 확장성 / 유지보수성이 중요한데 신뢰성 # 소프트웨어에 대한 신뢰란? 애플리케이션은 사용자가 기대한 기능을 수행한다. 실수나 예상치 못한 사용법도 허용한다. 필수적인 사용사례를 충분히 만족한다. 허가되지 않은 접근, 오남용을 방지한다. 결함과 장애 결함 잘못될 수 있는 일 장애 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우 결함 확률을 0으로 만드는건 불가능하지만, 결함으로 인해 장애가 발생하지 않게끔 해야 한다. 하드웨어 결함 # 하드디스크 고장 / 램 결함 / 정전 / 네트워크 케이블 이슈 등 시스템 장애율을 줄이기 위해 하드웨어 구성요소에 중복을 추가하기 디스크 RAID구성 이중전원 CPU 예비전원용 디젤 발전기 이전에는 저정도로 충분했지만… 이제는 데이터양과 계산 요구가 늘어나면서 하드웨어 결함률도 증가했다. 소프트웨어 내결함성 기술도 사용해야한다 소프트웨어 오류 # 하드웨어 결함을 무작위적이고 서로 독립적이라고 생각한다. 온도같은 약한 상관관계도 있겠지만 시스템 내 체계적 오류(systematic error)가 있을 수도 있다. 잘못된 특정 입력이 있을때 서버 인스턴스가 죽는 버그 CPU / 메모리 / 디스크 / 네트워크를 과도하게 사용하는 프로세스 반응이 없거나 잘못된 응답을 반환하는 서비스 연쇄 장애 등의 큰 이슈도 있다. 여기에는 신속한 해결책은 없다. 빈틈없는 테스트, 프로세스 격리, 모니터링, 분석 등으로 열심히 해야지.. 인적 오류 # 사람이 하는일이다보니 오류가 난다 사실 운영자 설정 오류가 하드웨어 결함보다 훨씬 많다 확장성 # 증가한 부하에 대처하는 시스템 능력 부하 기술하기 # 부하 매개변수라 부르는 몇개의 숫자로 나타내자. 웹 서버의 초당 요청수 데이터베이스의 읽기 대 쓰기 비율 액티브 유저 캐시 적중률 등.. 평균적인경우가 중요할수도 있고, 극단적인 케이스가 병목일수도 있고 트위터의 경우 개별 사용자는 많은 사람을, 많은 사람은 개별 사용자를 팔로하는데서 문제가 생김 읽기가 쓰기에 비해 훨씬 많이 일어나므로, 쓰기 시점에 더 많은 일을 하는것이 바람직하다. 미리 캐시로 계산해버렷 하지만 이러면 팔로워가 많은사람은 쓰기 비용이 너무 커지니까.. 이럴때는 읽기에 더 많은 일을 시킨다. 성능 기술하기 # 부하 매개변수를 증가시키고, 시스템 자원은 그대로 두면 성능이 어떻게 될까? 성능이 변하지 않기 위해선 자원을 얼마나 많이 늘려야 할까? 하둡과 같은 처리 시스템에서는 처리량(throughput)에 관심을 가지고, 온라인 시스템에서는 응답시간에 관심을 가진다. 응답시간은 평균, 백분위, 꼬리 지연 시간 등으로 목표를 설정한다. 이 목표를 서비스 수준 목표(SLO) 혹은 서비스 수준 협약서 (SLA)라고 한다. 높은 백분위에서 응답시간의 상당부분은 큐 대기 지연이 차지한다. 앞의 느린 요청들 처리를 기다리는 시간 이를 선두차단이라 한다. 부하 대응 접근 방식 # 용량 확장 (수직 확장) 좀더 좋은 장비로 바꾸기 규모 확장 (수평 확장) 다수의 낮은 사양 장비에 부하를 분산하기 비공유 아키텍쳐 유지보수성 # 레거시 시스템 유지보수…. 이를 위해선 다음이 중요하다 운용성 단순성 발전성 운용성 # 운영의 편리함 만들기 시스템 상태 모니터링 / 서비스 복원 시스템 장애, 성능 저하 원인 추적 ..등등 단순성 # 시스템에서 복잡도를 최대한 제거해서 새로운 엔지니어가 시스템을 이애하기 쉽게 만들기 추상화를 적절히 사용해서 우발적 복잡도를 제거하자. 발전성 # 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하기 애자일 / TDD 등 정리 # 애플리케이션이 유용하기 위해선 다양한 요구사항을 충족해야한다. 이에는 기능적 요구사항과 비기능적 요구사항이 있다. 여기서 비기능적 요구사항인 신뢰성 / 확장성 / 유지보수성을 살펴봤다.