데이터 중심 애플리케이션 설계01

---

소프트웨어 시스템의 3가지 관심사

1. 신뢰성 : 하드웨어나, 소프트웨어 결함, 인적 오류 같은 역경에서도 올바르게 동작해야 한다.
2. 확장성 : 스템의 데이터 양, 트래픽 양, 복잡도가 증가해도 처리해야 한다.
3. 유지보수성 : 시간이 지나도, 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있어야 한다.

신뢰성

• 잘못될 수 있는 일을 결함이라고 한다.
• 결함에 대응할 수 있는 시스템을 내결함성 또는 탄력성을 지녔다고 함
• 결함과 장애는 다르다. 결함은 사양에서 벗어난 것이고, 장애는 사용자에게 필요한 서비스를 제공하지 못한 것이다.
• 결함 -> 장애가 되지 않도록 내결함성 구조를 지녀야 한다.

결함의 종류

• 하드웨어 결함 : 개별 하드웨어 구성 요소에 이중화를 해야 한다.
• 소프트웨어 결함 : 예측이 어렵고, 빈틈 없는 테스트나 프로세스 격리, 모니터링과 같은 방법으로 문제 해결해야 함.
• 인적 오류 : 결함의 주요 원인으로, 오류의 가능성을 최소화하는 방향으로 설계하고 잘 테스트하며, 빠르게 롤백할 수 있도록 인프라를 갖춰야 함.

확장성

• 시스템이 부하의 증가에 대처하는 능력
• 확장 가능하다와 같은 말은 의미기 없고, 시스템이 추가 부하를 다루기 위해서 어떻게 자원을 투입하거나, 대처하기 위한 선택을 어떻게 할 수 있을지를 논해야 한다.

부하 기술하기

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

• 초당 요청 수, DB 읽기 쓰기 비율, 동시 활성 사용자 수, 캐시 적중률 등등

Twitter 사례. 트윗의 볼륨보다 팬 아웃으로 트윗을 사용자간에 전달하는 문제가 관심사임.

성능 기술하기

• 부하 매개변수가 증가되고, 시스템 자원이 동일하면, 시스템 성능은 어떻게 영향을 받는지?
• 부하 매개변수를 증가시킬 때, 성능이 유지되려면 자원을 얼마나 늘려야 할지
• 하둡같은 처리 시스템은 처릴량이 중요하고, 온라인 시스템은 응답 시간이 중요하다.
• 지연 시간과 응답 시간은 다르다. 지연 시간은 요청이 처리되기를 기다리는 시간이고, 응답 시간은 클라이언트 관점에서 응답이 돌아오는데 걸리는 시간이다.
• 응답 시간은 측정 가능한 값의 분포로, 평균은 그다지 의미 있는 지표가 아니다.
• 백분위를 사용하는 편이 좋다. p50, p95, p99 등을 살펴보자.
• 99.9분위와 같은 꼬리 지연 시간은 사용자 경험이 직접 영향을 주기 때문에 중요하다. 느리다 = 많은 데이터를 갖고 있다 = 핵심 고객.

부하 대응 접근 방식

• 스케일 업 또는 스케일 아웃
• 탄력적인 시스템은 부하를 예측할 수 없다면 유용하지만, 수동으로 확장하는 시스템이 더 간단하고 운영상 예상치 못한 일이 적다.
• stateful 시스템을 분산 설치하는 일은 아주 복잡하고, 고가용성 요구가 있을 때까지 단일 노드에 데이터베이스를 유지하는 것이 최근의 통념이다.

유지보수성

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

운용성

좋은 운영은 나쁜 소프트웨어의 제약을 피하는 대안이 딜 수 있다. 하지만 좋은 소프트웨어라도 나쁘게 운영하면 작동을 신뢰할 수 없다.

단순성

• 우발적 복잡도를 줄여야 한다. 소프트웨어가 풀어야 할 문제에 내재하고 있지 않고, 구현에서 발생하는 것이다.
• 추상화로 우발적 복잡도를 제거해라. 좋으느 추상화는 깔끔하고 직관적인 외간 아래로 많은 세부 구현을 숨길 수 있다.

발전성

시스템의 요구사항은 끊임없이 변하한다. 이는 단순성과 관련이 깊다. 단순한 시스템일수록 수정하기 쉽다.

정리

• 애플리케이션의 요구사항은 기능적 요건과, 비기능적 요건이 있다.
• 개발자는 비기능적 요건인 신뢰성, 확장성, 유지보수성에 신경을 써야 한다.
• 이 모두를 한번에 들어주는 간단한 해결책은 없지만, 특정 패턴과 기술로 이 목표를 향해 나아갈 수 있을 것이다.