[SW아키텍처&설계] 2. 대규모 시스템에서 가장 중요한 품질 속성

목차

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://aws.amazon.com/ko/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all 

AWS 서비스 수준 계약(SLA)

https://cloud.google.com/terms/sla

Google Cloud Platform Service Level Agreements

https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services?lang=1 

https://github.com/customer-terms/github-online-services-sla