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

[epicblues]

신뢰성

• 결함과 장애는 엄연히 다른 개념
  • 결함(fault)
    • 특정 시스템 컴포넌트에서 스펙과 불일치하는 현상 발생
    • 내결함성(fault-tolerance) 중요
      • 결함이 발생했을 때에도 시스템이 정상적으로 돌아갈 수 있게 처리
  • 장애(failure)
    • 사용자가 시스템을 사용하지 못하는 상태
    • 결함이 장애로 이어지는 것을 막는 것이 중요.
• 모든 결함을 막을 수 없음
  • 특정 유형의 결함에 강한 시스템을 만드는 것이 중요

종류

하드웨어 결함

• 특정 하드웨어 구성 요소에서 발생
  • 독립적, 무작위적
• 중복을 통해 해결
  • 각 구성 요소 별 중복

소프트웨어 오류

• 체계적 오류
• 예시
  • 잘못된 입력
  • 공유 자원 과도 사용 프로세스
  • 느린/잘못된 응답을 제공하는 서비스
  • 연쇄 장애
• 빠른 원인 파악 불가능
• 해결책
  • 시스템의 가정과 상호작용 생각
  • 모니터링
    • 시스템이 보장하는 영역과 관련된 사항 체크

인적 오류

• 사람들의 실수로 발생
• 해결책
  • 꼼꼼한 인터페이스 설계
  • 모니터링 매우 중요
    • 지표(metric) 수집
  • 자동화된 테스트
    • 엣지 케이스 중심
  • 빠른 복구 방식
    • roll back → roll out

확장성

• 부하가 늘어날 때에도 정상적으로 시스템이 구동할 수 있는 능력
• 부하 파라미터
  • 시스템 마다 다름
    • 요청 스레드 수, DB 쿼리 요청 수, 팬 아웃(한 트랜잭션을 처리하는데 필요한 다른 시스템 호출 수) 등
  • 부하 파라미터가 높아졌을 때 시스템이 정상적으로 구동하는가? 정상적으로 구동하려면 하드웨어를 늘려야 하는가(Scale up, Scale out)
• 산술 평균보다는 백분위를 본다
  • 중간값(p50), p99, p99.9, p99.99
  • 트위터 → 99.9 백분위 보다 느린 응답을 받는 고객에 주목
    • 해당 고객이 가진 데이터가 많아서 느린 것이라고 가정
      • 데이터가 많다? 핵심 고객
    • 최대한 낮추려고 노력중
• 응답 지연 원인 예시
  • 컨텍스트 스위치
  • 가비지 컬렉션
  • TCP 패킷 손실
  • 페이지 폴트
  • 서버랙 진동

유지보수성

운용성

• 운영을 용이하도록 하는 것
  • 여기서 운영은 비즈니스 팀의 운영이 아님.
    • 트러블 슈팅, 의존 패키지 버전 업, 인스턴스 마이그레이션, 플랫폼 추가 등
• 예시
  • 모니터링
  • CI/CD
  • 문서화와 쉬운 운영 모델
  • 자기 회복 및 커스텀
  • 개별 장비 의존성 회피

단순성

• 복잡도 관리
  • 우발적 복잡도
    • 기능이 많다 ≠ 복잡하다
    • 대부분의 원인은 ‘구현’
• 추상화를 통한 해결
  • 세부 구현 감추기
  • 재사용
• 예시
  • 프로그래밍 언어
    • 기계 언어, 시스템 콜, CPU 레지스터
  • SQL
    • 데이터 구조
    • 동시성

발전성

• 시스템은 끊임없이 변화 → 변화를 쉽게!
• 애자일