[SW아키텍처&설계] 1. 시스템 요구 사항 및 아키텍처 드라이버

목차

1. 시스템 요구 사항 및 아키텍처 드라이버

2. 대규모 시스템에서 가장 중요한 품질 속성

3. API 설계

4. 대규모 시스템에 필요한 아키텍처 빌딩 블록

5. 글로벌 규모의 데이터 스토리지

6. 소프트웨어 아키텍처 패턴 

7. 빅 데이터 아키텍처 패턴

8. 소프트웨어 아키텍처 & 시스템 디자인 연습

 

 

개요

아키텍처 설계가 필요한 이유 

 

- 확장 및 변경 가능한 구조 / 효율적인 구조 / 보안을 고려한 구조  

 

추상화 레벨

1. 클래스 : 패키지 내 동작 행위 명세, 클래스 다이어그램 이용 

2. 모듈/패키지/라이브러리 : 모듈 단위의 행위 명세, 하나 이상의 모듈이 모여 서비스가 된다. 

3. 시스템 디자인 : 서비스 단위 ( 프로세스 혹은 프로세스 단위 ) , 아키텍처 설계 레벨이다.

SW Architecture의 성공 

알고리즘은 주어진 입력에 대해 명확한 해답을 명시할 수 있다. 

하지만 아키텍쳐는 정해진 정답이 없다.

- 그래서 배우는 단계에서는 업계에서 증명된 아키텍쳐 패턴을 이용하고,

- Best practices 를 기반으로 수정하는 방향이 좋다. 

- eg) FrontEnd Patterns : https://www.patterns.dev/posts/progressive-hydration

- eg) SSR Micro FrontEnd Architecture :  https://aws.amazon.com/ko/blogs/compute/server-side-rendering-micro-frontends-the-architecture/

 

SW 개발 라이프 싸이클

SW Dev Cycle : 설계 > 구현 > 테스트 > 베포로 크게 4단계로 볼 수 있다. 

- 시스템 디자인은 그중 설계 단계이다. 

 

아키텍처 설계가 필요한 큰 규모의 시스템

 

 

1.  시스템 요구 사항 및 아키텍처 드라이버

 

1.  요구사항의 유형 및 아키텍처 드라이버 

 

대규모 시스템 설계 요구사항은 소규모와 비교해 몇 가지 다른 특성이 있다. 

1. 추상화의 단계와 범위가 다르다. 아키텍처 래벵의 요구사항이다. 

2. 모호성의 정도가 크다. 

- 클라이언트가 원하는 요구사항은 극히 일부분일 수 있다. 질문을 통해 구체화를 해야 한다. 

- 실시간성이 필요한지, PC와 Mobile 모두 제공해야 하는지 등등

 

요구사항을 정의하는 것은 중요하다. 고객조차 요구사항을 정확하게 모르는 경우도 있다. 

이런 요구사항을 3개의 종류(아키텍처 드라이버)로 구분할 수 있다. 

- Feature / Quality / Constraint ( FQC )

 

1. 시스템 피쳐 요구사항 ( 시스템 자체의 요구 사항 ) 

- eg) 웹 브라우저에서 pdf, img 파일 업로드 시스템을 만들고, 짧은 url를 반환해야 한다. 

 

2. 퀄리티 특성 요구사항 ( 아키텍처의 SLA 등, 이키텍처에 연관된 특성 )

- S 스케일 - L 레이턴시 - A 가용성 + ( 보안 + 신뢰 )

- eg) 99.9% 5MB/s로 파일을 다운로드할 수 있어야 한다.  

 

3. 시스템 제약사항 ( 마감 기한, 개발인원수, supported ) 

- eg) 에지, 크롬 등 최신 브라우저 (크롬 버전 88) 이상을 지원해야 한다. 

 

2. 시스템 피쳐 요구사항 (기능 요구 사항)

요구사항이 모호해서, 수집을 해야 할 때 유즈 케이스와/유저 플로우를 고려하자.

1. 유즈 케이스 : 특정 시나리오에 대한 요구사항

2. 유저 플로우 : 더 세밀하게 스탭 바이 스태프로 정리

시퀀스 다이어 그램 작성

- 객체들을 먼저 나열한다. / 객체들 간의 상호작용은 시간순으로 표시한다. 

예) 히치하이킹 서비스 - 매칭

 

 

3. 시스템 품질 속성 요구 사항

테스트 가능하고, 측정가능해야 한다. 

- 300ms 안에 응답 요청이 와야 한다.

 

트레이드오프 고려 

- 모든 품질속성을 제공할 수 없다. 다른 속성과 적당히 트레이드 오프 해야 한다. 

 

실현가능성 고려

- 100% 가용성 즉, 장애가 아예 없는 상황을 만들 수 없다. 

- 시스템을 해커로부터 100% 보호할 수 없다. 

- 대역폭이 제한된 지역에서, 고해상도 영상을 재생할 수 없다. 

 

 

4. 시스템 제약 사항

제약사항의 종류

1. 기술적 제약사항 : AWS 를 사용해야 한다,

- 채용의 이유로 Golang을 사용해야 한다,

- 엔지니어가 다루어 본 Redis 와 카산드라 DB로 구성해야 한다,

- 구버전의 크롬까지 지원해야 한다. 등등

 

2. 비즈니스 제약사항

- 특정 SASS를 이용해야 한다. / 특정 은행 및 중개인과 연동해야 한다. 

- 개발 일정으로 자체 게임 엔진 대신, 언리얼 엔진을 사용하여 일정을 단축시킨다. 

 

3. 리걸 제약사항 

- 의료 서비스를 제공하므로 HIPAA 인증을 받아야 한다. 

 

한 번 정한 제약사항은, 추후 변경하기 어렵다. 만약 제약사항에 변동이 생길것이 예상된다면 아키텍쳐에 루즈한 커플링으로 설계해야 한다. 

 

요약

요구사항 정의 먼저 하자 = 아키텍쳐 드라이브( Feature / Quality / Constraint =  FQC 고려 ) 

1. Feature = Use Case + User Flow ( 시퀀스 다이어 그램 이용 )

2. Quality = SLA+ ( 지표화 및 테스트 가능 / 트래이드 오프 고려 / 실현가능성 고려 ) 

3. Constraint = 기술적 역량 + 비즈니스 제약 (시간 등) + 리걸 이슈