Scalability and Maintainability
ref. 1 의 Chapter 1, Reliable, Scalable, and Maintainable Applications
확장성 Scalability
성능에 대한 표현
Scalability > Describing Performance
p.14
- 응답시간의 평균은 유저들이 일반적으로 어떤 평균 응답시간을 경험했는지를 말해주지 못한다.
- 이때는 percentiles(백분위수)를 사용하는 것이 낫다.
- 중앙값(median)은 50번째 백분위수라서 p50 으로 불린다.
- 중앙값이 1.5ms 라고 하면, 절반은 1.5ms 보다 느렸고, 절반은 1.5ms 보다 빨랐다고 알 수 있다.
p. 15
- 예를 들어 Amazon은 내부 서비스에 대한 응답 시간 요구 사항을 99.9% 라고 설명한다. 이말은 1,000건의 요청 중 1건에만 영향을 미친다는 뜻이다. 이는 요청이 가장 느린 고객이 종종 계정에 가장 많은 데이터를 보유하고, 구매횟수가 많은 고객이기 때문이다. 즉 가장 가치있는 고객들이다.[19].
- 반면에 99.99번째 백분위수(요청 10,000건 중 가장 느린 1건)를 최적화하는 것은 비용이 너무 많이 들고 아마존의 목적에 비해 충분한 이점을 얻지 못하는 것으로 간주되었다.
- 응답 시간이 100밀리초 증가하면 매출이 1% 감소하고[20], 1초 느려지면 고객 만족 지표가 16% 감소한다는 보고도 있다.[21, 22]
p. 16
- 응답 시간 데이터를 집계하는 올바른 방법은 히스토그램을 추가하는 것
- 시간 해상도를 낮추거나 여러 머신의 데이터를 결합하기 위해 백분위수를 평균하는 것은 수학적으로 의미가 없다.
부하 다루기
Scalability > Approaches for Coping with Load
- scale up(수직확장, 더 강력한 머신으로 이동)
- scale out(수평확장, 여러 대의 작은 머신에 부하를 분산)
- 탄력적 시스템(elastic system)은 부하를 예측할 수 없는 경우에 유용할 수 있다. 하지만 수동으로 확장하는 시스템이 더 간단하고 운영상의 돌발 상황이 적을 수 있다.
- ’단일 노드로 된 상태 저장 데이터 시스템(stateful data system)’을 분산 설정으로 전환하면 많은 복잡성이 추가될 수 있다.
- 일반적인 방법은 ‘확장 비용(scaling cost)’이나 ’고가용성 요건(high availability requirements)’ 들이 데이터베이스를 분산하는 것이 나은 시점이 올때까지 단일 노드에 데이터베이스를 유지(스케일업)하는 것.
- 그러나 요즘 분산시스템을 구성하기가 더 편리해져서 향후, 대량의 데이터나 트래픽을 처리하지 않는 사용사례에서도 분산형 데이터 시스템이 기본이 될 수 있다.
- 대규모로 운영되는 시스템의 아키텍처는 일반적으로 애플리케이션에 따라 매우 특수하다.
- 그래서 모든 경우에 사용가능한 확장 가능한 아키텍처(비공식적으로 마법의 확장 소스라고 알려진)와 같은 것은 존재하지 않는다.
- 특정 응용을 위해 잘 확장되는 구조는 어떤 작업이 일반적이고 어떤 작업이 드문지에 대한 가정, 즉 부하 매개변수(load parameters)를 기반으로 구축된다. 이러한 가정이 잘못된 것으로 판명되면, scaling 을 위한 노력은 가장 최악의 낭비가 되어 버린다.
- 그래서 초기스타트업이나, 그렇게 흥행이 되지 않은 제품에서는 미래 부하량에 맞춰서 확장하는 것보단 제품 기능들을 빠르게 재시작(iterate)할 수 있는 것이 더 중요하다.
Maintainability
- 소프트웨어 비용의 대부분은 지속적인 유지 보수에 발생
- 버그 수정
- 시스템 운영 유지
- 장애 조사
- 새로운 플랫폼에 맞게 조정
- 새로운 사용 사례에 맞게 수정
- 기술 부채 상환
- 새로운 기능 추가
- 유지보수시 고통을 최소화하도록 sw를 설계, 그래야 legacy sw 가 되지 않는다.
- 이를 위한 3가지 설계원칙, 이 원칙을 염두에 두고 시스템을 고민해야 한다.
- 운영성(Operability) : 운영팀이 쉽게 운영할 수 있도록
- 단순성(Simplicity) : 새로운 엔지니어가 시스템을 쉽게 이해할 수 있도록
- 진화가능성(Evolvability) : 확장성(extensibility), 수정가능성(modifiability), 가소성(plasticity) 라고도 부른다.
운영성
- 좋은 운영성은 ‘일상적인 작업(routine task)을 쉽게 만드는 것’ 그래서 운영팀이 고부가가치 활동에 집중할 수 있도록 하는 것을 의미
- 좋은 운영팀이 중요
- ’좋은 운영팀’이란
- 시스템 상태 모니터링 및 불량 상태 발생 시 신속한 서비스 복구
- 시스템 장애 또는 성능 저하와 같은 문제의 원인을 추적합니다.
- 보안 패치를 포함한 소프트웨어와 플랫폼을 최신 상태로 유지
- 서로 다른 시스템이 서로에게 어떤 영향을 미치는지 파악하여 문제가 되는 변경이 손상을 일으키기 전에 피할 수 있도록 유지보수성 확보
- 향후 문제를 예측하고 문제가 발생하기 전에 해결(예: 용량 계획)
- 배포, 구성 관리 등을 위한 모범 사례 및 도구 설정
- 애플리케이션을 한 플랫폼에서 다른 플랫폼으로 이동하는 것과 같은 복잡한 유지 관리 작업 수행
- 구성이 변경될 때 시스템의 보안 유지
- 운영을 예측 가능하게 하고 프로덕션 환경을 안정적으로 유지하는 데 도움이 되는 프로세스 정의
- 개별 직원이 이동하는 경우에도 시스템에 대한 조직의 지식 유지
routine task 를 쉽게 만드는 방법 :
- 우수한 모니터링을 통해 런타임 동작 및 시스템 내부에 대한 가시성 제공
- 자동화 및 표준 도구와의 통합을 위한 우수한 지원 제공
- 개별 머신에 대한 종속성 방지(시스템 전체가 중단 없이 계속 실행되는 동안 유지보수를 위해 머신을 중단할 수 있음)
- 좋은 문서와 이해하기 쉬운 운영 모델 제공(“X를 하면 Y가 발생합니다”)
- 좋은 기본 동작을 제공하되, 관리자가 필요할 때 기본값을 재정의할 수 있는 자유를 제공해야 합니다.
- 적절한 경우 자가 복구 기능을 제공하되, 필요한 경우 관리자가 시스템 상태를 수동으로 제어할 수 있어야 합니다.
- 예측 가능한 동작을 보여줌으로써 돌발 상황 최소화
단순성 Simplicity
- 시스템을 단순하게 만드는 것은 accidential complexity 를 줄이는 것을 뜻하기도 한다.
- accidentail complexity 는 소프트웨어가 해결하려고 하는 문제에서 나온 복잡성이 아니라, 단순히 구현에서 나온 복잡성이라고 정의
- 이것을 줄이는 좋은 방법중 하나가 추상화(abstraction) 이다.
- 복잡하고 이해하기 어려운 시스템은 시스템작업과 연관된 모든 사람의 작업속도를 떨어뜨린다.
- 복잡하고 이해하기 어려운 시스템은 유지비용을 증가시킨다.
- 복잡성 –> 유지보수 어려움 –> 예산, 일정의 초과
- 복잡성의 다양한 증상
- state space 의 폭발
- 모듈의 긴밀한 결합(tight coupling)
- 얽힌 종속성
- 일관되지 않은 명명 및 용어
- 성능문제를 해결하기 위한 hacks
- 다른 곳의 이슈를 해결하기 위한 특수케이스
- 변경시 버그가 발생할 위험이 더 크다.
- 개발자가 시스템을 이해하기 어렵고, 이유를 찾기 어렵다.
- 복잡한 시스템에선 숨겨진 가정, 의도하지 않은 결과, 예기치 않은 상호작용을 더 간과하기 쉽다.
진화가능성, 변경을 쉽게 Evolvability
- 데이터 시스템을 수정하는 것과 변화하는 요구 사항에 맞게 조정하는 것을 쉽게 하려면 단순성 및 추상화가 중요하다.
- 단순하고 이해하기 쉬운 시스템이 수정하기 더 쉽다.
See Also
Reference
- Designing Data Intensive Applications
댓글 없음:
댓글 쓰기