참고
아키텍쳐 설계
NOTE
알고리즘은 명확한 해답을 명시할 수 있지만 아키텍쳐는 정해진 정답이 없다!
아키텍쳐 설계 사이클
설계 → 구현 → 테스트 → 배포
•
그래서 배우는 단계에서는 업계에서 증명된 아키텍쳐 패턴을 이용한다.
◦
확장 및 변경 가능한 구조
◦
효율적인 구조
◦
보안을 고려한 구조
•
Best Practices를 기반으로 수정하는 방향이 좋다.
시스템 요구 사항
NOTE
대규모 시스템 설계 요구사항은 소규모와 비교해 몇 가지 다른 특성이 있다!
•
추상화의 단계와 범위가 다르다.
•
모호성의 정도가 다르다.
◦
클라이언트가 원하는 요구사항은 극히 일부분일 수 있다. (질문을 통해 구체화 해야한다.)
◦
실시간성이 필요한지, PC와 Mobile을 모두 제공해야하는지 등등..
요구사항을 3개의 종류(아키텍쳐 드라이버)로 구분한다! → Feature / Quality / Constraint
•
시스템 기능 요구사항
◦
ex) 웹 브라우저에 pdf, img 파일 업로드 시스템을 만들고 짧은 URL을 반환해야 한다.
•
퀄리티 특성 요구사항
◦
S 스케일 - L 레이턴시 - A 가용성 (아키텍쳐의 SLA, 보안 + 신뢰)
◦
ex) 99.9% 5MB/s로 파일을 다운로드 할 수 있어야 한다.
•
시스템 제약 사항
◦
마감 기한, 개발 인원 수 등
◦
ex) 에지, 크롬 등 최신 브라우저를 지원해야 한다.
시스템 기능 요구사항
NOTE
요구사항이 모호해서, 수집을 해야 할 때 유스 케이스/유저 플로우를 고려!
시퀀스 다이어그램 작성 (객체들 간의 상호작용은 시간 순으로 표시)
Action → API 요청
ex) 히치하이킹 서비스 - 매칭
•
유스 케이스
◦
특정 시나리오에 대한 요구 사항
•
유저 플로우
◦
더 세밀한 step by step으로 정리
◦
각 이벤트는 Action, Data가 포함된다!
시스템 품질 속성 요구사항
NOTE
시스템이 충족해하는 품질 기준(성능, 신뢰성, 효율성, 유지보수성..)이다!
•
많은 요소가 있지만 그중 가장 중요하게 고려해야하는 요소
◦
테스트 가능하고 측정가능해야 한다.
▪
ex) 300ms안에 응답 요청이 와야한다.
◦
트레이드 오프를 고려해야 한다.
▪
모든 품질 속성을 제공할 수 없다.
▪
다른 속성과 적당히 교환되어야 한다.
◦
실현 가능성 고려
▪
100% 가용성은 불가능하다.
▪
대역폭이 제한된 지역에서, 고해상도 영상은 재생이 불가능하다.
시스템 제약 사항
NOTE
시스템 설계와 구현에 영향을 미치는 한계나 제한을 나타낸다!
•
기술적 제약사항
◦
채용의 이유로 Golang을 사용해야 한다.
◦
엔지니어가 다루어 본 Redis와 카산드라 DB로 구성해야 한다.
•
비즈니스 제약사항
◦
특정 SASS를 이용해야 한다. (특정 은행 및 중개인과 연계)
◦
개발 일정으로 자체 게임 엔진 대신, 언리얼 엔진을 사용
•
법적 제약사항
◦
의료 서비스를 제공하므로 HIPAA 인증을 받아야한다.