목차
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 = 기술적 역량 + 비즈니스 제약 (시간 등) + 리걸 이슈
'SystemDesign' 카테고리의 다른 글
[SW아키텍처&설계] 3.API 설계 (0) | 2023.04.16 |
---|---|
[SW아키텍처&설계] 2. 대규모 시스템에서 가장 중요한 품질 속성 (0) | 2023.04.16 |
[시스템디자인&인터뷰] 6. 일반적인 기술 인터뷰 팁 (0) | 2023.04.16 |
프런트엔드 아키텍처 (0) | 2023.04.13 |
[시스템디자인&인터뷰] 5. 모의 설계 인터뷰 (0) | 2023.03.23 |