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

📝 상세 정리

#

인트로

#

• 오늘날 많은 애플리케이션들은 계산 중심이 아닌 데이터 중심적
  • 애플리케이션을 제한하는 요소는 CPU 성능이 아닌, 데이터의 양 / 복잡도 등이라는 것
    • 데이터를 저장 (DB)
    • 데이터를 빠르게 읽기 (캐시)
    • 검색과 색인
    • 비동기 처리 (스트림)
    • 주기적으로 분석 (배치 처리)
  • 위와 같은것들을 진행해야하기 때문!

데이터시스템에 대한 생각

#

• 우리는 DB / 큐 / 캐시 등을 다르게 생각한다.
  • 하지만 이걸 데이터 시스템이라고 묶어서 생각하자.
  • 어차피 분류도 흐려지고 있으니까!
    • 메세지큐로 사용하는 데이터스토어인 Redis
    • 지속성을 보장하는 메세지큐인 Kafka
  • 애플리케이션이 단일 도구로는 만족하기 어려울정도로 과도하고 광범위한 요구사항을 가지니까!
• 아무튼 소프트웨어 시스템에서는 그러면 신뢰성 / 확장성 / 유지보수성이 중요한데

신뢰성

#

• 소프트웨어에 대한 신뢰란?
  • 애플리케이션은 사용자가 기대한 기능을 수행한다.
  • 실수나 예상치 못한 사용법도 허용한다.
  • 필수적인 사용사례를 충분히 만족한다.
  • 허가되지 않은 접근, 오남용을 방지한다.
• 결함과 장애
  • 결함
    • 잘못될 수 있는 일
  • 장애
    • 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우
  • 결함 확률을 0으로 만드는건 불가능하지만, 결함으로 인해 장애가 발생하지 않게끔 해야 한다.

하드웨어 결함

#

• 하드디스크 고장 / 램 결함 / 정전 / 네트워크 케이블 이슈 등
• 시스템 장애율을 줄이기 위해
  • 하드웨어 구성요소에 중복을 추가하기
    • 디스크 RAID구성
    • 이중전원 CPU
    • 예비전원용 디젤 발전기
• 이전에는 저정도로 충분했지만…
• 이제는 데이터양과 계산 요구가 늘어나면서 하드웨어 결함률도 증가했다.
  • 소프트웨어 내결함성 기술도 사용해야한다

소프트웨어 오류

#

• 하드웨어 결함을 무작위적이고 서로 독립적이라고 생각한다.
  • 온도같은 약한 상관관계도 있겠지만
  • 시스템 내 체계적 오류(systematic error)가 있을 수도 있다.
    • 잘못된 특정 입력이 있을때 서버 인스턴스가 죽는 버그
    • CPU / 메모리 / 디스크 / 네트워크를 과도하게 사용하는 프로세스
    • 반응이 없거나 잘못된 응답을 반환하는 서비스
    • 연쇄 장애
  • 등의 큰 이슈도 있다.
• 여기에는 신속한 해결책은 없다.
  • 빈틈없는 테스트, 프로세스 격리, 모니터링, 분석 등으로 열심히 해야지..

인적 오류

#

• 사람이 하는일이다보니 오류가 난다
  • 사실 운영자 설정 오류가 하드웨어 결함보다 훨씬 많다

확장성

#

• 증가한 부하에 대처하는 시스템 능력

부하 기술하기

#

• 부하 매개변수라 부르는 몇개의 숫자로 나타내자.
  • 웹 서버의 초당 요청수
  • 데이터베이스의 읽기 대 쓰기 비율
  • 액티브 유저
  • 캐시 적중률 등..
• 평균적인경우가 중요할수도 있고, 극단적인 케이스가 병목일수도 있고
• 트위터의 경우
  • 개별 사용자는 많은 사람을, 많은 사람은 개별 사용자를 팔로하는데서 문제가 생김
  • 읽기가 쓰기에 비해 훨씬 많이 일어나므로, 쓰기 시점에 더 많은 일을 하는것이 바람직하다.
    • 미리 캐시로 계산해버렷
  • 하지만 이러면 팔로워가 많은사람은 쓰기 비용이 너무 커지니까..
    • 이럴때는 읽기에 더 많은 일을 시킨다.

성능 기술하기

#

• 부하 매개변수를 증가시키고, 시스템 자원은 그대로 두면 성능이 어떻게 될까?
• 성능이 변하지 않기 위해선 자원을 얼마나 많이 늘려야 할까?
• 하둡과 같은 처리 시스템에서는 처리량(throughput)에 관심을 가지고, 온라인 시스템에서는 응답시간에 관심을 가진다.
• 응답시간은 평균, 백분위, 꼬리 지연 시간 등으로 목표를 설정한다.
  • 이 목표를 서비스 수준 목표(SLO) 혹은 서비스 수준 협약서 (SLA)라고 한다.
• 높은 백분위에서 응답시간의 상당부분은 큐 대기 지연이 차지한다.
  • 앞의 느린 요청들 처리를 기다리는 시간
  • 이를 선두차단이라 한다.

부하 대응 접근 방식

#

• 용량 확장 (수직 확장)
  • 좀더 좋은 장비로 바꾸기
• 규모 확장 (수평 확장)
  • 다수의 낮은 사양 장비에 부하를 분산하기
  • 비공유 아키텍쳐

유지보수성

#

• 레거시 시스템 유지보수….
• 이를 위해선 다음이 중요하다
  • 운용성
  • 단순성
  • 발전성

운용성

#

• 운영의 편리함 만들기
  • 시스템 상태 모니터링 / 서비스 복원
  • 시스템 장애, 성능 저하 원인 추적
  • ..등등

단순성

#

• 시스템에서 복잡도를 최대한 제거해서 새로운 엔지니어가 시스템을 이애하기 쉽게 만들기
• 추상화를 적절히 사용해서 우발적 복잡도를 제거하자.

발전성

#

• 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하기
• 애자일 / TDD 등

정리

#

애플리케이션이 유용하기 위해선 다양한 요구사항을 충족해야한다. 이에는 기능적 요구사항과 비기능적 요구사항이 있다. 여기서 비기능적 요구사항인 신뢰성 / 확장성 / 유지보수성을 살펴봤다.

❔질문 사항

#

🔗 참고 자료

#