Be-Developer

데이터 중심 아키텍처 : 1.신뢰할수있고 확장가능하며 유지보수하기 쉬운 애플리케이션

01. 신뢰할 수 있고 확장가능하며 유지보수 하기 쉬운 애플리케이션

  • 신뢰성 : 하드웨어, 소프트웨어 결함, 인적요류 등의 이슈에 직면하더라도 시스템은 지속적으로 올바르게(원하는 성능 수준에서 정확한 기능을 수행) 동작해야한다.
  • 확장성 : 시스템의 데이터, 트래픽, 복잡도가 증가해도 처리할 방법이 있어야한다.
  • 유지보수성 : 모든 사용자가 시스템상에서 생상적으로 작업할 수 있어야한다.

데이터 시스템에 대한 생각

  • db, queue, cache 모두 포함하는 명칭, 카프카처럼 db지속성을 보장하는 메시지큐도 있기때문에 분류간 경계가 흐려짐.
  • 요구사항이 많아져서 단일도구 사용보다 여러도구를 조합해서 보통 사용.

신뢰성

  • 결함(fault) : 잘못될 수 있는 일
  • 내결함성(fault-tolerant), 탄력성을 지닌 시스템 : 결함을 예측하고 대처할 수 있는 시스템
  • 장애(failuer) : 시스템이 멈춘 경우.
  • 고의적으로 결함을 일으켜 내결함성을 테스트하는 예로 넷플릭스의 카오스 몽키가 있다.

    하드웨어 결함

  • 하드웨어를 중복 구성하여 장애대응.
  • 클라우드 플랫폼은 하드에어 결함을 자주 맞지만, 소프트웨어 내결함성 기술을 사용하기도 한다.

    소프트웨어 오류

  • 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다.
  • 시스템이 뭔가를 보장하길 기대한다면 지속적으로 기대결과를 모니터링해야한다.

    인적 오류

  • 가장 많이 실수하는 부분을 분리.
  • 철저하게 테스트

확장성

웹의 대기큐는 어떤구조일까?.?

  • 서버에서 연결은 일단 웹소켓으로 들고있고, redis나 kafka를 이용하여 대기열 구축하는게 일반적인듯.
  • 확장성은 시스템에 부여하는 일차원적인 표식이 아니다.
    • (X) A시스템은 확장 가능하다. 확장성이 있다.
    • (O) 시스템의 부하가 커지면 이에 대처하기위해 어떤 선택을 할수있다.

      부하 기술하기

  • 트위터 예시
    • 트윗 작성 (RPS 4.6k , peak 12k)
    • 홈 타임라인 (RPS 300k)
  • 트위터는 작성량 < 조회량 이 많기때문에, 쓰기시점에 더 많은 일을 하는 트레이드오프를 했다.
    • 트윗을 작성하면, 모든 팔로워의 타임라인 캐시에 트윗을 삽입한다.
  • 팔로워가 매우 많은 소수의 사용자는 쓰기작업이 크기때문에, 팬아웃에서 재외된다. 유명인의 트윗은 타임라인 조회시점에 쿼리한다.

    성능 기술하기

  • 처리량(throughput), 응답시간,,
    • 지연시간 : 요청이 처리되길 기다리는 시간, 서비스를 기다리며 휴지상태인 시간으로, 클라이언트 관점에서 보는 응답시간과 다르다.
  • 응답시간의 백분위, SLO, SLA에 자주 사용된다.
    • 사용자가 보통 얼마나 오랫동안 기다려야하는지 알고싶다면 중앙값 p50
    • 특이값이 얼마나 좋지 않은지 알아보려면 상위 백분위 p95, p99, p99.9
      • p95가 1.5s : 100개요청중 95개가 1.5s 이내, 5개가 1.5s 이상 걸린다
      • p99.9는 1000명중 1명이 평균이상인데, 보통 1이 헤비유저이므로 응답시간 개선이 중요하다.
      • p99.99 는 최적화 비용이 크므로 트레이드오프한다.
    • SLO (Service Level Objective) 서비스 수준 목표
    • SLA (Service Level Agreement) 서비스 수준 협약서
      • ex) 응답시간 중앙값이 0.2s, p99.9가 1s 미만일때 정상상태로 간주한다.
  • 꼬리지연 증폭(tail latency amplification) : 병렬로 요청해도 가장 느린 응답에의해 최종 응답시간이 결정된다.
  • 상위 백분위값을 효율적으로 계산하는 알고리즘 : forward decay, T-digest, HdrHistogram ,,

    부하대응 접근방식

  • 용량확장(scaling up=수직 확장), 규모확장 (scaling out=수평확장)을 상황에 따라 적절히 조합해야한다.

유지보수성

  • 레거시 최소화를 위한 시스템 설계원칙
    • 운용성 : 운영팀이 시스템을 원활하게 운영할수있게 쉽게만들어야한다
    • 단순성 : 복잡도를 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어야한다.
    • 발전성/유연성 : 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 해야한다.

      운용성: 운용의 편리함

  • 자동화로 효율을 높인다

    단순성: 복잡도 관리

  • 추상화를 통해 우발적 복잡도(사용자에게는 보이지 않지만 구현레벨의 복잡도)를 줄일 수 있다. 직관적인 인터페이스 내부로 구현 숨기기

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

  • 애자일 작업패턴, TDD, 리팩토링,,