1장:데이터 중심 애플리케이션 설계

데이터 중심 애플리케이션 설계 책을 읽고 정리하였습니다.

chapter 단위로 내용을 정리해서 올릴 예정입니다.

---

서문

급격한 기술 변화에도 변하지 않는 원리가 있다. 이 원리는 사용하는 도구의 버전과도 상관이 있다.

이 책은 성공적인 데이터 시스템을 예로 들어 여러 유명 애플리케이션의 기반 기술을 설명하고 서비스 환경에서 확장성과 성능, 그리고 신뢰성 요구사항을 항상 충족하기 위해 사용하는 기술을 설명한다.

데이터 시스템의 동작 방식뿐만 아니라 왜 그런 식으로 동작하며 어떤 질문을 해야 하는지를 알아본다.

이 책을 다 읽고 나면 특정 목적에 어떤 기술이 적합한지 결정하는 능력과 좋은 애플리케이션 아키텍처의 기반을 만들기 위해 도구를 조합하는 방법을 이해하는 능력이 생긴다.

이 책에서 다루는 내용

데이터 시스템의 기초가 되는 다양한 원리와 트레이드오프에 대해 논의하고 다양한 제품이 채택한 서로 다른 여러 설계 결정을 살펴본다.

참고 문헌 링크: http://github.com/ept/ddia-references

이 책에서는 데이터 시스템 아키텍처와 데이터 중심 애플리케이션으로 데이터 시스템을 통합하는 방법을 주로 다룬다.

---

1장 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

기본 개념

• 1장에서는 책 전반에 걸쳐 사용하는 전문 용어와 접근 방식을 소개한다.
• 신뢰성, 확장성, 유지보수성 같은 단어의 실제 의미와 이 같은 목표를 달성하기 위해 어떻게 해야 하는지 알아본다.
•  

---

표준 구성 요소(standard building block)

• 데이터베이스
• 캐시
• 검색 색인
• 스트림 처리
• 일괄 처리

데이터 시스템에 대한 생각

데이터베이스, 큐, 캐시 등을 왜 데이터 시스템이라는 포괄적 용어로 묶어야 할까?

대부분의 소프트웨어 시스템에서 중요하게 여기는 세가지 관심사

• 신뢰성(Reliability)
• 하드웨어나 소프트웨어 결함, 심지어 인적 오류 같은 역경에 직면하더라도 시스템은 지속적으로 올바르게 동작(원하는 성능 수준에서 정확한 기능을 수행)해야 한다.
• 확장성(Scalabitliy)
• 시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법이 있어야 한다.
• 유지보수성(Maintinability)
• 시간이 지남에 따라 여러 다양한 사람들이 시스템 상에서 작업(현재 작업을 유지보수하고 새로운 사용 사례를 시스템에 적용 하는 엔지니어링과 운영)할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다.

신뢰성

• 애플리케이션은 사용자가 기대한 기능을 수행한다.
• 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있다.
• 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다.
• 시스템은 허가되지 않은 접근과 오남용을 방지한다.

2012년 6월 30일 윤초 사건

하드디스크의 평균 장애시간은 약 10~50년으로 보고됐다.

따라서 10000개의 디스크로 구성된 저장 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다고 예상해야 한다.

소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다.

인적오류를 최소화 하는 다양한 접근 방식

• 샌드박스를 제공하라.(개발서버도 샌드박스라고 할 수 있는가?)
• 모든 수준에서 철저하게 테스트 하라. → 특히 코너 케이스를 다룰땐 자동 테스트가 좋다.
• 오류를 빠르고 쉽게 복구할 수 있게 하라.
• 모니터링 대책을 마련하라.

확장성

성능저하를 유발하는 흔한 이유 중 하나는 부하 증가다.

부하는 부하 매개변수라고 하는 몇 개의 숫자로 나타낼 수 있다.

부하 매개변수: 웹 서버의 초당 요청수(다른 의미지만 TPS), 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자(active user), 캐시 적중률 등

보통 응답 시간이 가장 느린 요청을 경험한 고객들은 많은 구매를 해서 고객 중에서 계정에 가장 많은 데이터를 갖고 있어서다.(즉, 이 고객들은 가장 소중한 고객이다.)

아마존의 내부 서비스 응답 시간 요구사항은 99.9분위로 기술 한다. 1000개 중 1개만 영향이 있음

아마존은 응답 시간이 100밀리초 증가하면 판매량이 1% 줄어들고 1초가 느려지면 고객의 만족도 지표는 16% 줄어드는 현상을 관찰했다.

부하 대응 접근 방식

현실적으로 좋은 아키텍처는 실용적인 접근 방식의 조합이 필요하다. 예를 들어 적절한 사양의 장비 몇대가 낮은 사양 가상 장비보다 여전히 훨씬 간단하고 저렴하다.

모든 상황에 맞는 확장 아키텍처는 없다.(은탄환은 없다.)

유지보수성

소프트웨어의 비용의 대부분은 초기 개발이 아니라 지속해서 이어지는 유지보수에 들어간다는 사실은 잘 알려져 있다.

유지보수 중 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 소프트웨어를 설계를 꼭 해야한다.

그러기 위해 소프트웨어 시스템 설계 원칙은 다음과 같다.

• 운용성
• 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들어라.
• 단순성
• 시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어라.
• 발전성
• 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하라.

---

생각해볼것

지금 우리 회사는 어떤 신뢰성, 확장성, 유지보수성을 가지고 있는가

신뢰성을 위해 장애대응에 필요한 쿠버네티스 클러스터링을 별도로 가지고 있다.

확장성을 위해 노드 메모리를 12기가로 가용성을 가지고 있다.

유지보수성을 위해 코드리뷰를 하고 아키텍쳐 구성을 고민한다.