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

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

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

lingi04 2023. 12. 26. 20:45

오늘날 많은 애플리케이션은 데이터 중심적
- 애플리케이션의 성능은 CPU 성능보다는 데이터의 양, 복잡도, 변화 속도에 영향을 받는다.
데이터 시스템
- 데이터베이스 : 데이터를 저장
- 캐시 : 읽기 속도 향상을 위하여 값비싼 수행 결과를 기억
- 검색 색인 : 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있게 제공
- 스트림 처리 : 비동기 처리를 위해 다른 프로세스로 메세지 보내기
- batch 처리 : 주기적으로 대량의 누적된 데이터를 분석

데이터 시스템에 대한 생각

데이터베이스, 큐, 캐시 등 다른 범주에 속한 도구로 생각이 되지만 데이터 시스템이라는 포괄적인 용어로묶어야함.
- 분류간 경계가 흐려지고 있고
  - redis, apache kafka
- 많은 애플리케이션이 단일 도구로는 더 이상 데이터처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 갖고 있다.
좋은 데이터 시스템 설계를 위해 고려해야할것
- 신뢰성, 확장성, 유지보수성

신뢰성

소프트웨어의 경우 일반적인 기대치는 아래와 같다.

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

⇒ 신뢰성을 ‘무언가 잘못되더라도 지속적으로올바르게 동작함.’ 으로 이해할 수 있다.

보안과 관련된 문제는 해결책이 없어 예방책이 더 좋은 경우이지만 이 책에선 해결책이 있는 결함에 대해 다룬다.

결함과 장애

결함 :
- 잘못될 수 있는 일을 뜻함.
- 결함을 예측하고대처할 수 있는 시스템을 내결함성 또는 탄력성을 지녔다고 말함.
- 사양에서 벗어난 시스템의 한 구성 요소
장애:
- 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우

결함 확률을 0으로 줄이는 것은 불가. 대개 결함으로 인해 장애가 발생하지 않게끔 내결함성 구조를 설계하는 것이 가장 좋다.

하드웨어 결함

규모가 큰 데이터센터에서 하드웨어 결함은 늘상 일어나는 일.
하드웨어 구성 요소에 중복을추가하는 방법이 일반적
- 디스크를 raid 구성으로 설치
- 서버는 이중 전원 디바이스와 핫 스왑 가능한 cpu
- 데이터센터는 건전지와 예비 전원용 발전기
고가용성이 절대적으로 필수적인 소수의 애플리케이션에서만 필요했지만
- 애플리케이션의 규모가 커지면서(계산량, 데이터량 증가) 많은 수의 장비를 사용하게 되었고
- 클라우드플랫폼을 많이 사용하게 되면서
- 소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 점점 옮겨가고 있다.

소프트웨어 오류

시스템 내 체계적 오류
- 노드간 상관관계 때문에(상관관계가 없는 하드웨어 결함 보다) 시스템 오류를 더욱 많이 유발함.
  - 리눅스 커널 윤초 버그
  - 공유 자원을 과도하게 사용하는 일부 프로세스
  - 시스템의 속도가느려져 반응이 없거나잘못된 응답을 반환하는 서비스
  - 한 구성 요소의 결함이다른 구성 요소의 결함 야기. 연쇄장애
특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다.[11]
신속한 해결책은 없다.
- 시스템의 가정과 상호작용에 대해서 주의깊게 생각
- 빈틈 없는 테스트
- 프로세스 격리
- 죽은 프로세스의 재시작 허용(?)
- 프로덕션 환경에서 시스템 동작의 측정
- 모니터링
- 이상동작에 대해 알람 걸어놓기

인적 오류

운영자의 설정 오류가 중단의주요원인. 하드웨어결함은 10~25%
사람은 미덥지 않다.. 그럼에도 신뢰성 있는 소프트웨어를 만들기위해선
- 오류의 가능성을 최소화하는 방향으로 시스템을 설계하라.
  - 잘 설계된 추상화, API, 관리 인터페이스
- sandbox 환경을 제공.
  - 실제 데이터를 볼 수 있지만 사용자에게는 영향이 없도록
- 모든 수준에서 철저히 테스트
  - 단위 테스트, 전체 시스템 통합 테스트, 수동 테스트까지
- 인적 오류를 빠르게 복구할 수 있도록
  - 설정 변경은 빠르게 롤백 가능하게, 새로운 코드는 서서히 롤 아웃
- 상세하고명확한 모니터링 대책 마련
  - 성능 지표와 오류율 등
- 조작 교육과 실습 실행

확장성

증가한부하에 대처하는 시스템 능력을 설명하는 데 사용
확장성을 논한다는 것은
- 확장성이 있나?없나? 같은 것이 아니고
- 시스템이 특정 방식으로 커지면 대처하기 위해 어떤 선택을 할것인가?, 추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까? 를 고민하는 문제.

부하 기술하기

부하 매개변수 선택은 시스템 설계에 따라달라짐.
- 웹 서버의 초당 요청 수
- DB의 읽기/쓰기 비율
- 대화방의 동시 활성 사용자
- 캐시 적중률
트위터를 예로들면
- 초당 12000건 쓰기?
- fan-out?

성능 기술하기

성능 측정 방법
- 부하 매개변수를 증가시키고 시스템자원은 변경하지 않으면 성능은어떤 영향으 ㄹ받을까?
- 부하 매개변수를 증가시켰을 때 성능이 변하지 않고 유지되길 원한다면 자원은 얼마나 많이늘려야 할까?
기술 방법
- 평균 응답 시간
- 백분위 - 중앙값
- 백분위 - 95, 99, 99.9분위(p95, p99, p999)
  - 꼬리 지연 시간 이라고부름
  - 아마존은 내부 서비스의 응답시간 요구사항을 p999 로 기술함. 1000명 중 1명의 고객이지만 구매를 많이 해서 계정에 가장 많은 데이터를 갖고있는 소중한 고객
  - SLA에서도 사용
  - 큐 대기 지연(queueing delay) 에도 중요함. 선두 차단(head-of-line blocking) 때문

부하 대응 접근방식

Scale up (용량 확장, 수직 확장) 과 Scale out (규모 확장, 수평 확장) 을 적절히
- 다수의 장비에 상태 비저장 서비스를 배포하는 일은상당히 간단함.
- 단일 노드에 상태 유지 데이터 시스템을 분산 설치 하는 것은 복잡도가 크기때문에 고가용성 요구가 있을 때까지 단일 노드에 DB를 유지하여 scale up 하는게 통념.
범용적이고모든 상황에 맞는 확장 아키텍처는 없다.
- 읽기의 양
- 쓰기의 양
- 저장할 데이터의 양
- 데이터의 복잡도
- 응답 시간 요구사항
- 접근 패턴
- 등 여러 요소를 따져보고 적절한 아키텍처를 선택해야함
스타트업들은 빠르게 반복해서제품 기능 갯너 작업 하는게 좀 더 중요

유지보수성

소프트웨어 비용의 대부분은 유지보수에 들어감.

레거시 소프트웨어를 직접 만들지 않게끔 소프트웨어를 설계해야 한다.

아래와 같은 세 원칙이 있다.

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

동일하게 반복 되는 태스크를 쉽게 수행하게끔 만들어 운영팀이 고부가가치 활동에 노력을 집중할 수 있는 환경
모니터링, 런타임 도앚꽈 시스템의 내부에 대한 가시성
자동화!!
개별장비 의존성 회피 등
좋은 문서와 이해하기 쉬운운영 모델
만족할 만한 기본동작 제공, 필요할때 값을 변경할 수 있도록
적절한 자기 회복 & 관리자가 시스템 상태 수동 제어 할 수 있도록
예측 가능하게 동작 & 예기치 않은 상황 최소화

단순성: 복잡도 관리

개발자가 시스템을 이해하고 추론하기 어려워지면 시스템에 숨겨진 가정과 의도치 않은 결과 및 예기치 않은 상호작용을 간과하기 쉽다.
- 같은 repository 안에 naming 규칙이 다름
- 같은 개념인데 다른 naming
- 임시방편으로 문제를 해결한 특수 사례
추상화를 통해 우발적인 복잡도를 줄이자.

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

시스템의 요구사항은 끊임없이 발전한다.
- 예기치 않은 사용 사례
- 법적 규제 변경
- 시스템의 성장으로 인한 아키텍처 ㅂ녀경
조직 프로세스 측면에서 애자일 작업 패턴
- 자주 변화하는 환경에서 소프트웨어를 개발할 때 도움이 되는 기술 도구와 패턴
  - TDD
  - refactoring
간단하고 이해하기 쉬운 시스템을 만들기