SW 아키텍처(SW Architecture)의 처음 시작 지점에 대하여...

코로나로 인하여 귀차니즘이 폭발하면서 한동안 글을 쓰지 않았다...다시 정신 차려야지...

SW아키텍처라고 하면 흔히 다이어그램으로 그려져 있는 SW아키텍처 다이어그램 그림을 떠올리지만 사실 그건 SW아키텍처의 결과물에 일부분이고 한눈에 보기 쉽게 정리한 요약본 같은것이지 아키텍처의 본질이라고 보기 어렵다.

SW아키텍처의 본질은 SW아키텍처 명세서 라고 하는 문서로서 결과물이 만들어 진다. 이 문서는 크게 두가지 파트로 나누어진다.

1. 기능적인 부분(Functional View)

2. 비기능적인 부분(Non-Functional View) 

기능적인 부분은 다들 알고 있는 SW가 어떻게 작동할 것인가에 대한 부분이다. 사용자가 메일기능을 원하면 어떻게 메일기능을 구현할 것인가...뭐 이런 내용들로 구성된다. 

기능적인 내용들은 사실 아키텍처명세서 뿐만 아니고 프로젝트의 각종 산출물들, 요구사항명세서, 기능설계서 등 각종 산출물에서 명확화 되면서 계속 다루어 지게 때문에 아키텍처 명세서 단계에서는 통상적으로 정밀성 보다는 정확성 위주로, 방향성에 대한 언급을 하면서 크게 다루지는 않는 경향이 있다.

사실, 아키텍처명세서의 핵심은 비기능적인 부분이다. 비기능적인 부분은 통상 품질에 대한 내용을 다룬다.

품질은 구체적으로 성능,보안,확장성,무결성,강건성,유지보수성,유연성,추적성,신뢰성 등 각종 품질속성들로 구성된다.

예를 들어 메일기능을 만드는데 동시에 초당 10개 메일을 보내는 시스템과 초당 10만개 메일을 보내는 시스템은 그 고민의 시작지점 부터 다르다.

종종 작은 시스템으로 시작했다가 갑자기 사용자가 몰리면서 전체시스템을 재설계하고 재개발하는 경우를 많이 보게 된다. 이러한 것들은 다 처음에 아키텍처에 대한 고민을 가볍게 진행했다가 갑자기 몰리는 사용자들과 트래픽을 감당하지 못해서 큰 손해를 보는 경우들이다.

아키텍처링 단계에서 확장성을 예를 들면, 사용자가 적을 때 세션클러스터링은 아무문제가 없지만 초당 10만명이 접속되는 환경에서는 스케일업을 진행하던지 스케일아웃을 진행해야 되는데 스케일업은 상당한 비용문제와 다운타임이 소요되므로 스케일아웃을 진행해야된다.

세션클러스터링은 스케일아웃이 어렵기 때문에 아키텍처 측면에서 스케일아웃이 필요하다면 처음부터 세션클러스터링을 안쓰던지 클라우드 인메모리 데이터베이스를 사용하는 방향으로 확장성 구성방안이 결정된다. 

또다른 예로 간단하게 신뢰성에 대해서 고민해 보자.

서버장비를 도입해야 되는데 신뢰성 98%(0.98)의 상용벤더 유닉스머신과 신뢰성 90%(0.90) 리눅스머신이 있다.

유닉스머신은 100만원이고 리눅스머신은 50만원이다. 미션크리티컬한 업무라면 일반적으로 유닉스머신을 선택하게 된다.

중요한 업무이기 때문에 이중화를 고민해야 되는데 유닉스머신 이중화는 돈이 많이 들어서 리눅스머신으로 이중화 했으면 좋겠는데 신뢰성이 고민된다....검증해보자

리눅스머신으로 이중화하면 1개의 머신이 장애발생률은 0.1 이고 두개머신이 동시에 장애발생률은 0.1X0.1=0.01 이므로 이중화된 전체시스템의 신뢰성은 1-0.01 = 0.99, 즉 99%의 신뢰성을 가지게 된다.

따라서 유닉스머신 1개보다 리눅스머신 2개가 더 높은 신뢰성을 가지게 된다.(물론 현실은 네트웍과 스토리지등 훨씬 복잡하다...)

이처럼 어느정도 개발레벨이 올라오고 중급이상 개발자에서 고급개발자 단계로 넘어가려면 필연적으로 아키텍처에 대한 고민을 해야 되고(통상 이러한 고민을 아키텍처에 대한 고민이라고 인식하지 못하는 경우가 많다) 처음에 방향을 잘 잡아야 과도한 삽질을 피하게 된다.

P.S 초반에 언급한것 처럼 다이어그램이 아키텍처라고 생각하면 엄청난 삼질을 경험할수 있다.....나처럼...ㅡㅡ;