개발자에서 아키텍트로 -10. 설계 시각화 하기1

아이디어를 공유하는 최선의 방법은 아이디어를 손에 잡힐 듯하게 만드는 것 입니다. 아키텍처 다이어그램을 그리는 방법을 배우고 개발자들과 수월하게 대화하는 방법을 알아보겠습니다.

 

10.1 다양한 관점으로 아키텍처 표현하기

그림 한장에 아키텍처의 모든 내용을 담을 수는 없습니다. 다이어그램 하나에 모든 것을 담기보다는 다양한 관점에 기초해 다이어그램을 여러 개에 나눠 담는 게 좋습니다. 여기서 관점이란 특정 이해관계자 또는 그와 긴밀하게 연관된 고려사항의 시각에서 바라보는 것을 의미 합니다.

 

아키텍처의 경우 여러 이해관계자들의 질문에 답을 할 수 있도록 여러 관점으로 다이어그램을 그릴 필요가 있습니다. 개발진도는 어떻게 되나요? 누가 이 컴포넌트를 만들고 있나요? 품질 속성 시나리오를 충족하기에 부족한 점은 없나요?

 

소프트웨어 시스템에서 관점은 미리 정해진게 없습니다. 다만 대부분의 시스템에서 유용하게 쓰이는 것은 있습니다. 소프트웨어 아키텍처를 바라보는 여러 관점을 지칭할 때는 뷰라고 부르곤 합니다. 이제 몇 가지 유용한 뷰를 소개하겠습니다.

 

10.1.1 요소-역할 뷰로 요소의 역할 보여주기

선과 상자는 아키텍트가 가장 많이 사용하는 도구 입니다.  아래 라이언하트 프로젝트 다이어그램을 보며 이유를 알아보겠습니다.

 

 

위 다이어그램에는 중요한 정보가 빠져 있습니다. 모든 요소가 각자의 목적에 부합하지만 그림만으로는 알 수가 없습니다. 이 다이어그램의 부족한 점은 구성요소의 목록이 빠져 있다는 점 입니다. 공유해야 할 정보에 따라 주석, 표, 글로 보완해 구성 요소의 역할을 설명할 수 있습니다. 

 

요소-역할 뷰는 아주 흔히 쓰입니다. 이 뷰만 필요할 때도 있습니다. 요소와 역할을 나열할 수만 있다면 실제로 동작하는 시스템도 만들 수 있습니다.

10.1.2 구체화 뷰로 확대/축소하기

구체화 뷰는 한 모델을 일련의 뷰로 점점 상세하게 보이도록 처리해줍니다. 마치 구조를 더 배율이 높은 렌즈로 보듯 요소의 내부적인 동작을 보여주고, 다시 더 자세히 보여줄수 있습니다.

 

구체화의 첫 번째 단계에서 디스플레이 비즈니스 요소는 평범한 레이어 패턴으로 이루어졌음을 알 수 있습니다. 레이어는 디스플레이, 비즈니스, 서비스 액세스로 구분되며, 부수적으로 데이터 모델과 유틸리티 클래서를 뭉뚱그린 레이어가 있습니다. 위에 다이어그램을 보면, 전체적으로 맥락은 있지만 유지 보수성이 어떤지 알고 싶으면 좀 더 구체화를 해야 합니다.

 

위에 구체화 과정에서는 레이어 내부의 패키지와 레이어 간 상호작용을 보여줌으로써 유지 관리성에 관한 품질 속성 시나리오를 파악 할 수 있습니다. 좀 더 살펴보면 RFP 패키지가 다른 패키지와 너무 많이 연결되어 있으므로 테스트와 디버깅이 어려울 수 있는 게 분명 합니다.

 

모델 및 유틸리티 레이어는 이번 구체화에서는 보이지 않습니다. 모든 요소가 모델 및 유틸리티 레이어 클래스를 사용할 수 있습니다. 모든 관계를 포함하면 다이어그램이 너무 복잡하기 때문에 이번 뷰에서는 일부 관계를 제거 했습니다. 뷰를 이리저리 자르고 쓰는게 유용할 때도 있지만 아키텍처 모델을 이해하기 어렵게 만들기도 합니다.

 

뷰를 구체화함으로써 특정 질문에 알맞은 답을 만들 수 있습니다. 적당한 배율의 구체화로 큰 그림을 만들 수도 있습니다. 그림을 보고 이해할 수 있는 수준으로 맥락이 만들어지면 특정 이해관계자가 필요로 하는 주요 세부사항만 확대해 보다 자세하게 보여줄 수 있습니다. 

 

또한 '모호함을 유지하라' 라는 의미처럼 모델을 어느 수준까지만 구체화 합니다. 구체화는 특정 품질 속성을 충족하고 우선순위가 높은 위험요소를 줄일 수 있다고 입증하는데 필요한 수준까지만 해야 합니다.

 

10.1.3 품질 속성 뷰로 품질 속성 충족 여부 보여주기

품질 속성 뷰는 아키텍처가 특정 품질 속성을 충족하는지 확인 할 때 사용합니다. 라이언하트 프로젝트의 가용성 시나리오오는 아래와 같습니다.

사용자가 시스템에서 보내는 시간의 99%는 열람 가능한 RFP 목록을 받고  RFP를 찾아보는 일 입니다.

 

이 품질 속성을 만족하려면 중복 패턴을 이용할 수 있습니다. 

 

'가용성을 촉진한다'는 것은 라이언하트 서비스가 장애에 탄력적으로 대응할 수 있게 한다는 뜻 입니다. 이를 위해 디스플레이 비즈니스, 검색 서비스, 검색 색인에 쓰이는 인스턴스가 여러개 필요합니다. 디스플레이 비즈니스 및 검색 서비스 컴포넌트는 상태를 보존하지 않는 마이크로서비스이므로 쿠버네티스 또는 마라톤과 같은 컨테이너 관리 시스템에서 여러 인스턴스를 쉽게 배포할 수 있습니다.

 

검색 색인은 상태를 보존하는 컴포넌트이며 시스템 성능에 잠재적인 병목 현상을 주므로 데이터 저장에 매우 주의해야 합니다. 또한 일시적인 중단과 데이터 파티셔닝이 일어날 때 장애가 발생하지 않도록 라우팅을 고려할 필요가 있습니다. 이번에는 간단히 로드밸런서와 DNS를 사용해 요청을 라우팅 합니다.

 

이제 다이어그램을 사용해 품질 속성 시나리오를 만족하는지 확인하겠습니다. 검색 색인 컴포넌트 중 하나가 실패한 것으로 가정합시다. 로드 밸런서는 상태를 확인해 실패를 감지하고 들어오는 요청을 보조 검색 색인 컴포넌트로 라우팅 합니다.

 

이 뷰는 꽤 괜찮지만 아직 발전의 여지가 있습니다. 상태 확인은 얼마나 자주 합니까? 핑을 한 번 보낼때 무엇을 필요합니까? 로드 밸러서가 다운되면 어떻게 합니까? 실패한 검색 색인이 다시 온라인 상태가 되면 어떻게 됩니까? 이러한 질문에 대한 대답은 다이어그램과 함께 글로 설명하도록 합니다. 다이어그램 하나만으로는 아키텍처가 가용성 시나리오는 어떻게 충족하는지 설명하지 못합니다.

10.1.4 매핑 뷰로 여러 뷰의 요소 연결하기

여러 뷰를 동원하면 서로 다른 뷰에서 하나의 요소가 다른 요소와 어떤 관계를 맺고 있는지를 쉽게 파악할 수 있습니다. 더 나아가 뷰를 맞붙여서 하나의 뷰로 만들면 요소끼리 어떤 관계가 있는지 보여줄 수 있습니다. 두개 이상의 뷰를 맞붙인 뷰를 매핑뷰라고 합니다.

 

서로 맞붙이기에 유용한 두 가지 뷰로 업무 할당 뷰와 배포 뷰가 있습니다. 업무 할당 뷰에서는 시스템의 여러 구성 요소마다 작업할 팀을 볼 수 있고, 배포 뷰에서는 컴포넌트와 커넥터 구조에 입각해 구성 요소가 실제로 어디에 설치되고 실행되는지 볼 수 있습니다.

 

라이언 하트 프로젝트의 업무할당뷰 예시 입니다.

 

 

뷰는 다이어그램이 아니라는 점에 유의합시다. 목표는 단지 의미 있는 설계 의사결정이 이루어지도록 하는 데에 초점이 있어야 합니다. 때로는 표만 만들어도 목표를 달성할 수 있습니다.

 

맵핑 뷰는 이해관계자 간의 서로 다른 관점을 반영할 수 있습니다. 업무 할당 뷰는 스케쥴과 인원계획을 세우는 프로젝트 매니저에게는 완벽하게 부합 합니다.