WhiteKow / Designing-Data-Intensive-Applications

데이터 중심 애플리케이션 설계
1 stars 0 forks source link

Ch1. Reliable, Scalable, and Maintainable Applications #1

Open hhhyunwoo opened 1 year ago

hhhyunwoo commented 1 year ago

오늘날 많은 애플리케이션은 Compute-Intensive 와는 다르게 Data-Intensive 적이다.

즉, CPU 성능보다는 데이터의 양, 데이터의 복잡도, 데이터의 변화 속도가 더 큰 문제이다.

일반적인 데이터 중심 애플리케이션은 아래와 같은 컴포넌트들이 필요하다.

image

이러한 시스템을 위한 여러 도구들은 다양한 Use Case 에 최적화됐기 때문에 더 이상 전통적인 분류에 딱 맞지 않다. 예를 들어 KafkaRedis 는 데이터를 다루는 도구이지만, 사용되는 목적이 전혀 다르다.

따라서 이러한 도구들을 엔지니어링 관점에서 신중하게 신뢰성, 확장성, 유지보수성을 고려하여 사용해야한다!

이번 장에서는 신뢰성, 확장성, 유지보수성에 대해서 자세히 알아보자


Reliability

소프트웨어에 대한 사용자의 일반적인 기대치는 아래와 같다.

즉, 이 모든 것들은 올바르게 동작함을 의미한다.

무언가 잘못되더라도 지속적으로 올바르게 동작함

Fault

잘못될 수 있는 일을 fault 라고 부른다.

Fault Tolerant (or Resilient)

Failure 와 Fault 의 차이

Chaos Monkey (chaos engineering)

Hardware Faults

일반적인 디스크 고장, 메모리 고장 등과 같은 이슈들을 말함

(하드디스크의 평균 장애시간은 10~50년인데, 이는 10,000개의 디스크로 구성된 클러스터에서 평균적으로 하루 1개의 디스크가 죽는다는 의미)

아래의 방법으로 장애율을 줄일 수 있음

Software Errors

하드웨어의 결함은 무작위적이고 독립적이라고 생각하지만, 소프트웨어는 그렇지 않음.

소프트웨어의 오류 문제는 신속한 해결책이 없다. 따라서 빈틈없는 테스트, 프로세스 격리, 재시작 허용, 모니터링, 분석하기 등의 방법이 도움이 될 수 있음

Human Errors


Scalability

확장성을 논한다는 것은 “X는 확장 가능하다” 가 아니라 “시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택은 무엇인가?”“추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?” 같은 질문이다.

Describing Load

Load Parameter

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

Twitter 의 예시

image

Describing Performance

시스템 부하를 기술하면 부하가 증가할 때 어떤 일이 일어나는지 조사할 수 있음.

이를 위해서는 성능 수치가 필요함!

Throughput

Response Time

값이 아닌 분포로 생각하기

클라이언트가 몇 번이고 반복해서 동일한 요청을 하더라도 매번 응답 시간은 다름!! 따라서 응답 시간은 단일 숫자가 아니라 분포 값으로 생각해야함!

image

위의 그래프에서 볼 수 있듯이 동일 요청에서도 Outlier가 존재함. 아래의 다양한 변수 때문

전형적인 응답 시간을 알고 싶다면 산술 평균 을 사용하는 것은 좋은 지표는 아니고, 일반적으로 평균보단 백분위를 사용하는 편이 좋음

Tail Latency

아마존의 예시!!

SLO와 SLA

Approches for coping with Load

One-Size-Fits-ALL 확장 아키텍쳐는 없다!

아키텍쳐를 결정하는 요소는 읽기의 양, 쓰기의 양, 저장할 데이터의 양, 데이터의 복잡도, 응답 시간 요구사항, 접근 패턴 등이 있다.


Maintainability

image

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

유지보수는 필수불가결하지만, 유지보수의 고통을 최소화 하고 레거시를 만들지 않게끔 소프트웨어 설계는 가능하다.

이를 위한 원칙 세 가지는 아래와 같다.

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

시스템이 지속해서 원활하게 작동하려면 운영팀이 필수! 좋은 운영팀은 일반적으로 다음과 같은 작업 등을 책임짐

단순성: 복잡도 관리

복잡도는 다양한 증상으로 나타남. 상태 공간의 급증, 모듈 간 강한 커플링, 복잡한 의존성, 일관성 없는 명명과 용어, 성능 문제 해결을 목표로 한 해킹, 임시방편으로 문제를 해결한 특수 사례

→ 이를 해결하기 위한 최상의 도구는 추상화!

좋은 추상화는 깔끔하고 직관적인 괴관 아래로 많은 세부 구현을 숨길 수 있고, 재사용이 가능!!

예시.

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

Agile 작업과 TDD, Refactoring 은 자주 변화하는 환경에서 도움이 됨.

데이터 시스템 수준에서 민첩성을 언급할 때는 민첩성 대신 다른 단어로 발전성을 사용할 예정!


Reference