[데이터 중심 애플리케이션 설계] 1장 : 신뢰할 수 있고 확장가능하며 유지보수하기 쉬운 애플리케이션

• 오늘날의 많은 어플리케이션은 계산 중심이 아닌 데이터 중심적임
• 일반적으로 데이터 중심 애플리케이션은 공통으로 필요한 기능을 제공하는 표준 구성 요소(standard building block)로 만듬
  • 애플리케이션에서 다시 데이터를 찾을 수 있게 저장 (DB)
  • 읽기 속도 향상을 위해 수행 결과 기억 (캐시)
  • 다양한 방법으로 필터링 할 수 있게 제공 (search index)
  • 다른 프로세스로 메세지 보내기 (steam processing)
  • 주기적으로 대량의 데이터를 분석 (batch processing)
• 위의 과정이 당연한 이야기 처럼 들린다는것 = 데이터 시스템이 성공적으로 추상화 되었다는 것

데이터 시스템에 대한 생각

• 데이터 시스템이라는 포괄적인 용어로 묶는 이유에는
  1. 데이터 시스템 분류간 경계가 흐려지고 있음 (ex.메세지 큐의 레디스, db처럼 지속성 보장 메세지 큐인 카프카 등..)
  2. 더 많은 애플리케이션이 단일 도구로는 데이터 처리와 저장 모두 만족시킬 수 없음
• 이 책에서는 대부분의 SW 시스템에서 중요하게 여기는 3가지 관심사에 중점을 둠
  1. 신뢰성
  2. 확장성
  3. 유지보수성

신뢰성

• 무언가 잘못되더라도 지속적으로 올바르게 동작함이라 이해할 수 있음
• 잘못될 수 있는 일 = 결함
• 결함을 예측하고 대처할 수 있는 시스템을 내결함성 or 탄력성을 지녔다 함
• 결함 ≠ 장애(시스템 전체가 멈춘 경우를 의미)
• 고의적으로 결함을 유도함으로써 내 결함성 시스템을 훈련할 수 있음
  • 이것의 대표적인게 넷플릭스의 카오스 몽키
• 해결책이 있는 결함 유형 3가지
  1. 하드웨어 결함
  • 각 하드웨어 구성 요소에 중복을 추가하는 방법이 일반적
  • 소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 옮겨가는 추세
  1. 소프트웨어 오류
  • 이 결함은 예상하기 어렵고, 더욱더 많이 발생하며, 신속한 해결책이 존재하지 않음
  • 시스템이 뭔가를 보장하길 기대한다면 이를 지속적으로 확인해 차이가 생기는 경우 경고를 발생시킬 수 있음
  1. 인적 오류
  • 대규모 인터넷 서비스에 대한 연구에 따르면 인적 오류로 인한 중단이 주요 원인이다
• 신뢰성은 손실이 발생하며 명성에 타격을 준다는 면에서 큰 비용이 발생한다

확장성

• 시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작한다는 보장은 없음
• 성능 저하를 유발시키는 가장 흔한 이유중 하나는 부하 증가
• 확장성은 증가한 부하에 대처하는 시스템 능력을 설명하는데 사용하는 용어

부하기술하기

• 현재 부하에 대해 간결하게 기술할 수 있어야지 부하 성장 질문을 논의할 수 있다
• 부하는 부하 매개변수라 부르는 몇개의 숫자로 나타낼 수 있음

트위터 예시

• 트위터의 주요 동작 두가지
  • 트윗 작성 (초당 12k 요청 이상)
  • 홈 타임라인 (초당 300k 요청)
• 이 때 12k 건의 쓰기 처리를 상당히 쉬우며, 트위터의 확장성 문제는 주로 팬 아웃 문제로 발생함
• 이를 구현하는 방법은 총 두가지가 있음
  1. 트윗 작성은 간단히 새로운 트윗을 트윗 전역 컬렉션에 삽입한다. 사용자가 홈 타임라인을 요청하면 팔로우 하는 모든 사람을 찾고, 이를 시간순으로 정렬하여 합친다
  2. 개별 사용자의 홈 타인라인 캐시를 유지하여, 트윗을 작성하면 해당 사용자를 팔로우하는 모든 사람을 찾고, 팔로워 각자의 홈 타임라인 캐시에 새로운 트윗을 삽입한다.
• 트위터는 1번 의 방식에서 2번의 방식으로 전환함
• 평균적으로 트윗 게시 요청량이 홈 타임라인 읽기 요청량에 비해 수백배 적기 떄문에 접근 방식 2가 훨씬 잘 동작함
• 하지만 트윗 작성에 많은 부가작업을 필요로 하여, 팔로워의 분포가 팬 아웃 부하를 결정하는 문제가 발생함
• 따라서 트위터는 두 접근 방식의 혼합형으로 바꾸어, 대부분 사용자의 트윗은 2의 방식을 채택하지만, 팔로워수가 매우 많은 소수 사용자는 팬아웃에서 제외되고 1처럼 읽는 시점에 사용자의 홈 타임라인에 합쳐짐

성능기술하기

• 시스템 부하를 기술하면 다부하가 증가할 때 어떤 일이 일어나는지 조사할 수 있는데, 다음 두가지 방법으로 살펴볼 수 있음
  • 부하 매개변수를 증가시키고 시스템 자원은 유지하면 시스템 성능은 어떻게 영향 받을지?
  • 부하 매개변수를 증가시켰을때 성능이 변하지 않고 유지되길 원한다면 자원을 얼마나 많이 늘려야할지?
• 하둡같은 일괄 처리 시스템은 보통 처리량에 관심을 가짐.
• 온라인 시스템에서 더 중요한 사항은 서비스 응답시간
• 클라이언트가 동일한 요청을 반복해서 하더라도 응답시간은 매번 다름 → 응답시간은 단일 숫자가 아닌 측정 가능한 값의 분포로 이야기함
• 보고된 서비스의 평균응답시간 을 살피는 일은 일반적이지만, 백분위 를 사용하는 편이 더 좋음
• 사용자가 보통 얼마나 오랫동안 기다려야 하는지 알고싶다면 중앙값이 좋은 지표
• 특이 값이 얼마나 좋지 않은지 알아보려면 상위 백분위를 살펴보는 것도 좋음
  • 꼬리 지연 시간으로 알려진 상위 백분위 응답 시간은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요함

부하 대응 접근 방식

• 확장성과 관련해서 용량 확장(scaling up)-수직 확장(vertical sacling) / 규모 확장(sacling out) - 수평 확장(horizontal sacling)으로 구분해서 이야기함
• 다수의 장비에 부하를 분산하는 아키텍처를 비공유 아키텍처라 이야기함
• 상당히 집약된 작업 부하는 대게 규모확장을 피하지 못함.
• 일부 시스템은 **탄력적(elastic)**이어서, 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있음
• 다수의 장비에 상태 비저장(stateless)서비스를 배포하는 일은 간단함
  • 하지만 단일 노드에 상태 유지(stateful) 데이터 시스템을 분산 설치하는 일은 많은 복잡도가 추가적으로 발생함
  • 이런 이유로 확장 비용이나 데이터베이스를 분산으로 만들어야 하는 고가용성 요구가 있을때까지 단일 노드에 데이터베이스를 유지하는 것(용량 확장)이 최근가지의 통념임
• 대개 대규모로 동작하는 시스템의 아키텍처는 해당 시스템을 사용하는 애플리케이션에 특화되어있음
• 범용적이고 모든 상황에 맞는(one-size-fits-all) 확장 아키텍처는 없음

유지 보수성

• 소프트웨어 비용이 대부분은 초기 개발이 아니라 유지보수에 들어감
• 레거시 소프트웨어를 만들지 않게 끔 잘 설계해야하는데 이런 설계원칙은 3가지 존재함
  • 운용성 : 시스템을 원활하게 운용할 수 있도록 쉽게 만들자
  • 단순성 : 복잡도를 최대한 제거하자
  • 발전성 : 시스템을 쉽게 변경할 수 있도록 하자

운용성 : 운영의 편리함 만들기

• 운영 중 일부 측면을 자동화 할 수 있고 또 자동화 해야함
• 하지만 자동화를 처음 설정하고 제대로 동작하는지 확인하는 일은 여전히 사람의 몫
• 좋은 운영성이란 동일하게 반복되는 태스크를 쉽게 수행하게 끔 만들어 운영팀이 고부가치 활동에 노력을 집중한다는 의미

단순성 : 복잡도 관리

• 복잡도 수렁에 빠진 소프트웨어 프로젝트를 때론 커다란 진흙 덩어리(big ball of mud)라고 묘사함
• 시스템을 단순하게 만든다는것은 = 우발적 복잡도(accidental complexity)를 줄인다는 것
• 우발적 복잡도를 제거하기 위한 최상의 도구는 추상화이다
• 책 전반에 걸쳐 좋은 추상화에 대해 이야기 할 것

발전성 : 변화를 쉽게 만들기

• 시스템의 요구사항은 끊임없이 변할 가능성이 크다.
• 조직의 프로세스 측면에서 애자일(agile) 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공한다
• 또한 TDD와 리팩토링 같이 자주 변화하는 환경에서 소프트웨어를 개발할때 도움이 되는 기술 도구와 패턴을 개발하고 있다.