목차
1. 시스템 요구 사항 및 아키텍처 드라이버
2. 대규모 시스템에서 가장 중요한 품질 속성
3. API 설계
4. 대규모 시스템에 필요한 아키텍처 빌딩 블록
5. 글로벌 규모의 데이터 스토리지
6. 소프트웨어 아키텍처 패턴
7. 빅 데이터 아키텍처 패턴
8. 소프트웨어 아키텍처 & 시스템 디자인 연습
2. 대규모 시스템에서 가장 중요한 품질 속성
P - S - A - T
1. 성능 Performance (P)
성능
1. response time ( 응답시간 )
2. throughput ( 처리량 )
응답 시간은 = 프로세싱 타임 ( 서버에서 비즈니스 처리 속도 ) + 웨이팅 타임 ( 네트워크 지연 )으로 구성
*레이턴시는 응답시간 혹은 웨이팅 타임을 혼용해서 지칭한다.
처리량은 일정시간 동안 데이터를 얼마나 받아서 처리할 수 있는지를 나타내는 지표이다.
- 응답시간이 빠르다고 좋은 퍼포먼스를 가지는 것이 아니다. QPS 등의 지표도 중요하다.
고려할 점
1. 응답시간을 올바르게 측정하기
- 대기 큐에 걸린 경우, 마지막 사용자는 응답시간이 늘어날 수 있다.
- 그래서 응답시간은 평균을 구해야 한다.
2. 응답시간 분포
- Percentile : P90 혹은 P95 혹은 P99는 x(ms) 안에 들어와야 한다는 기준
- *P95까지 ( 대부분의 사용자는 문제없음 ) 50ms를 보장한다면 나머지 극단값 5% 에 대해서도 최대 지연을 정의할 수 있다.
- Tail Latency : 이를 Tail Latency라고하며, 늦어도 1 sec 안에 응답을 하자는 기준이 세워질 수 있다.
3. performance degradation
- 응답시간 그래프를 보면, 어느 순간 응답시간이 치솟는 변곡점이 발견될 수 있다.
- 처리량 그래프를 보면, 어느 순간 처리량이 감당이 안되어 장애로 번지는 시점이 있다.
예)
- High CPU utilization , High memory consumption
- Too many connection IO ( network , db.. )
- Message Q is at capacity
2. 확장성 Scale (S)
2.1 확장성 - 동기 및 정의
- 유저 트래픽은 일정한 패턴이 따르고, 성능저하지점이 발생하지 않도록 조치가 필요
- 확장성 정의 : 시스템의 작업 처리 능력
- 확장성이 좋다는 것은 ? : 리소스 투자 대비 작업 처리 능력 향상이 좋다.
- *따라서, 같은 돈과 시간을 써도, 확장성이 좋은 디자인은 성능저하시점이 늦게 찾아온다.
이상적인 방향은 자원을 소모한 만큼 처리량이 늘어나는 것이다.
시스템은 3가지 방향으로 확장성을 확보할 수 있다. ( 3차원 축 )
2.2 Vertical Scalability
- 수직 확장은 컴퓨터 자체의 리소스를 업그레이드
- 장점 : 코드 변경 없이, 어떤 앱도 가능하며, 스케일 업/다운이 쉽다(클라우드라면)
- 단점 : 확장에 한계가 있다, 고가용성과 내결함성 갖추지 않음
2.3 Horizontal Scalability
- 새 인스턴스를 추가해, 리소스를 확장하는 방식
- 장점 : 확장에 무제한 / 쉽게 스케일 업/다운 / 고가용성과 내결함성 갖춘다.
- 단점 : 초기 코드 변경이 필요하다 / 리소스 구성 복잡도 및 오버헤드 증가
2.4 팀/조직 확장
하나의 코드베이스를 여러 엔지니어가 작업하게 되면, 어느 순간 리소스 투입 대비 생산성이 급감한다.
원인들 )
- 많은 미팅과 참여인원 증가
- 코드 병합 충돌
- 비즈니스 복잡도 증가 > 서로 안겹치게 일하도록 램프업 타임 필요
- 테스트 어렵고 느려진다
- 많은 변경사항이 반영된 릴리즈의 위험도 증가
코드베이스가 다른 MSA 및 네트워크 구성으로 해결
- 엔지니어가 더 많이 투여 되더라도, 생산성이 감소하지 않는 것이 목표
3. 가용성
- 가용성의 중요성 및 위험
- 가용성의 정의 및 공식
- 고가용성이란 ?
---
3.1 가용성의 중요성 및 위험
가용성이 낮다면 ?
- 1시간 동안 유저가 이메일 서비스에 방문을 못한다.
- 결제창에서 오류가 발생해서, 다시 결제를 시도했다.
- AWS S3 중단 사태로, 수백 개의 기업과 웹사이트가 일시적으로 다운
- 특히나 미션 크리티컬 서비스에 중요,
- eg) 환자의 건강관리 시스템이 다운되어 바이털 시그널 캐치 실패
비즈니스 임팩트
- 1. 다운 타임 동안 수익이 제로
- 2. 잦은 다운 타임으로 고객 이탈
3.2 가용성의 정의 및 공식
가용성 정의 = 업타임 / ( 업타임 + 다운타임 )
*업타임은 시스템이 운용되어 사용자가 접근 가능함을 말한다.
MTBF : Mean TIme Between Failures : 유효수명이라고 보면 된다.
- eg) SSD 2년 보장
MTTR : Mean Time To Recovery : 문제 발견 후 회복까지의 시간 ( = 다운타임 )
- eg) 장애 회복까지 1시간 걸림
가용성( 통계적/확률적으로 더 밀접하게 ) 정의 = MTBF / ( MTBF + MTTR )
3.3 고가용성이란?
가용성이 95% 면 높아 보이지만, 하루에 1시간 12분은 다운타임을 가진다는 말이다.
- 99.9% 는 3 ninse라고도 말한다.
- 99.99% 는 4 ninse라고도 말한다.
- 보통 업계에서는 최소 3 ninse를 보장한다고 말한다.
4. 내결함성 및 고가용성
- 4.1 HA(고가용성)을 저해하는 요인
- 4.2 고가용성 및 내결함성
---
4.1. HA(고가용성)을 저해하는 원인
휴먼 애러 : 결함이 있는 구성을 포함 / 코드 및 명령어 오류 / 테스트 안된 새 버전 배포
SW 애러 : OOM / Null Exception / Segement fault / Long - GCC
HW 애러 : 수명 다한 하드웨어 / 자연재해로 정전 / 네트워크 오류
4.2. 고가용성 및 내결함성
내결함성 : 일부 구성에 오류가 발생하더라도, 전체 시스템은 정상적으로 가동되게끔 유지하는 기능
4.2.1 Failure Prevention
4.2.2 Failure Detection and Isolaction
4.2.1 Failure Prevention
- 시스템의 오류를 일으키는 요인들을 제거한다.
- 단일 장애점 제거 : DB 레플리카로, 장애 발생 시 트래픽을 정상서버로 리다이렉션
중복성의 종류
1. 공간적 중복성 : DB 레플리카, 복제된 서버
2. 시간적 중복성 : 동일한 수행이나 요청을 성공 혹은 포기할 때까지 반복
복제와 중복성의 전략
1. Actiive-Active 아키텍처 : DB 레플리카를 두고, DB의 동기를 유지한다.
- 장점 : 수평적 확장과 일치 / 단점 : 동기화 오버헤드
2. Active-Passive 아키텍처 : 모든 요청을 받는 프라이머리 인스턴스가 있고, 이를 복제하는 스냅숏 존재
- 장점 : 최신의 상태를 유지, 구현의 간단 / 단점 : 확장능력 잃음
4.2.2 Failure Detection and Isolaction
- 1. health check로 서비스가 정상적으로 응답하는지 점검하는 모니터링 서비스를 실행
- 2. 만약 응답이 없다면, 해당 서비스를 고립시킨다. ( 서킷 브레이크 )
- 고립에 대하서는 여러 기준을 적용시킨다.
- *레이턴시가 너무 높다 / 애러 응답을 1분에 20개 이상...
4.2.3 Recovery
- 트래픽 중단 후 인스턴스 재부팅
- 롤백
5. SLA, SLO, SLI
SLA : 서비스 수준 협약
- 가용성, 성능, 내구성, 장애 응답 등 품질에 대한 합의 계약서
- 보상에 대한 내용도 명시 ( 구독, 크레디트, 전체 및 부분 환불 )
SLO : 서비스 수준 목표
- 서비스는 3 nines의 가용성을 가지며,
- 응답속도는 P90 - 100ms을 만족한다.
- 장애 대응은 48 시간 이내로 이루어진다.
- *SLA 하위에 각 서비스별 SLO가 다수 존재 가능
SLIs : 서비스 수준 척도
- 모니터링 시스템을 사용해서, 측정된 실제 숫자값이 나온다.
- SLO의 합/불 여부를 판단하는 지표가 된다.
고려점
- 모든 지표를 가져다가, SLO로 만들면 안 된다. 사용자가 중요하게 생각하는 것을 만들어야 한다.
- 너무 많은 SLO을 약속하면 안된다.
- SLIs의 worst case로 페널티 지급해도 괜찮을 정도로 산출
- 장애대응에 대한 DevOps 조치 시스템을 구축 ( 모니터링 - 얼럿 - 온콜 ) , SRE
실제 기업의 SLA
https://cloud.google.com/terms/sla
https://github.com/customer-terms/github-online-services-sla
'SystemDesign' 카테고리의 다른 글
[SW아키텍처&설계] 4. 대규모 시스템에 필요한 아키텍처 빌딩 블록 (0) | 2023.04.16 |
---|---|
[SW아키텍처&설계] 3.API 설계 (0) | 2023.04.16 |
[SW아키텍처&설계] 1. 시스템 요구 사항 및 아키텍처 드라이버 (0) | 2023.04.16 |
[시스템디자인&인터뷰] 6. 일반적인 기술 인터뷰 팁 (0) | 2023.04.16 |
프런트엔드 아키텍처 (0) | 2023.04.13 |