Micro Service Archtecture 이해하기 1.소프트웨어 아키텍처의 이해

소프트웨어 아키텍처란?

소프트웨어 아키텍처는 소프트웨어를 구성하는 요소와 요소 간의 관계를 정의한 청사진입니다.

소프트웨어 아키텍처는 소프트웨어의 전체적인 구성 관계인 구성 요소와 구성 요소 간의 포함관계, 호출 관계 등을 표현하여 소프트웨어 구성 전체를 조망하고 이해하는 데 유용합니다.

또, 소프트웨어와 관련된 이해관계자들이 기술 구조를 이해하고 논의할 수 있는 소통의 도구 역할도 합니다.

아키텍처의 표현

아키텍처를 표현할 때에는 UML(Unified Modeling Language)과 같은 표준화 모델링 언어를 이용하여 작성하는 것이 바람직합니다.

왜냐하면, 아키텍처를 표현하는 아키텍트(architect)들의 수준과 표현에 따라 제각각의 도식과 표기법으로 작성되어 이해관계자마다 다르게 해석할 수 있기 때문입니다.

이미지 출처 : 위키피디아 - 통합 모델링 언어 (https://ko.wikipedia.org/wiki/%ED%86%B5%ED%95%A9_%EB%AA%A8%EB%8D%B8%EB%A7%81_%EC%96%B8%EC%96%B4)

최근 시스템의 복잡도가 증가하면서 아키텍처를 표현하는 것은 설계만큼 중요한 일입니다. 따라서 아키텍처의 표현은 다양한 관점으로 접근하고 표현되어야 합니다.

소프트웨어 아키텍처의 이러한 관점을 뷰(view)라 하고, 여러 과점에서 이 뷰를 표현할 방법들이 있습니다. 그중 대표적으로 4+1 뷰가 있습니다.

이미지 출처 : 위키피디아 - 4+1 아키텍처 뷰 모델(https://en.wikipedia.org/wiki/4%2B1_architectural_view_model)

아키텍처의 역할

소프트웨어 아키텍처는 건축공학에 비유하면 건축물의 뼈대이고, 도시공학에 비유하면 도시의 전체적은 구조라 할 수 있습니다.

소프트웨어는 건축물과는 다르게 형체가 있는 것이 아니고, 소스 코드들이 복잡하게 얽혀 있는 무형의 지식 집합체입니다.

소프트웨어 아키텍처는 폭넓은 시각과 사례를 기반으로 설계되어야 하고, 전문적인 역량을 가진 집단이나 해당 분야 전문가들의 고민과 노력이 뒤따라야 합니다.

수백 명의 개발자가 참여한 프로젝트에서는 아키텍처의 결정이 시스템의 성능을 좌우할 뿐만 아니라 이를 개발하는 개발자들의 수고를 더하거나 덜 수 있습니다.

아키텍처는 시스템 풀질 속성을 충족할 수 있게 설계되어야 하고, 비가시성을 최소화하기 위해 적절히 표현하여 소통의 도구로 활용해야 합니다.

이를 위해 여러 측면에서의 충분한 고민과 검토가 이뤄져야 합니다.

소프트웨어 아키텍처 스타일

소프트웨어 아키텍처 스타일은 시스템 요건을 충족시키기 위한 제약 조건을 가진 아키텍처 측면의 접근 방법입니다.

아키텍처 스타일과 아키텍처 패턴을 흔히 혼용해서 사용하지만, 둘 사이에는 차이점이 있습니다.

• 소프트웨어 아키텍처 스타일

스타일은 상황을 해결할 수 있는 접근 방법을 제시해 주지만, 정답을 제시해 주지는 않습니다. 다만, 스타일에서 제시하는 접근 방법을 선택하면 그만큼 실패할 확률을 줄일 수 있습니다.

• 소프트웨어 아키텍처 패턴

시스템이 가지는 문제점이나 해결해야 할 문제의 구체적인 해결 방안을 경험적 사례를 기반으로 제시합니다.

즉, 스타일은 접근 방법을 제시하고, 패턴은 구체적인 해결 전술을 제시한다고 이해하면 됩니다.

모놀리스에서 마이크로서비스로 변화

모놀리스한 아키텍처란, 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 괴어 서비스되고, 애플리케이션에서 사용하는 데이터 또한 한 곳에 모인 데이터를 참조하여 서비스하는 것이 일반적인 형태입니다.

하지만 비즈니스의 변화가 빠르고 수시로 애플리케이션을 변경해서 적용해야 하는 환경에서는 하나의 애플리케이션으로는 유연하게 대처할 수 없습니다.

모놀리스한 아키텍처의 애플리케이션 중 일부 프로그램만 수정하려도 해도 관련 없는 기능들까지 단일 애플리케이션이 빌드되어 다시 배포되어야 합니다.

변경 배포에 따른 영향도를 파악하기 위해 직접 관련이 없는 많은 사람의 노력과 시간을 할애해야 합니다. 물론, 하나의 패키지로 관리하면 관리의 편리함은 있겠지만, 변화에 대한 민첩한 대응이 부적합한 구조임은 사실입니다.

최근에는 서비스를 유연하고 안정적으로 운영할 수 있는 인프라 지원 기술들(최근의 Cloud 서비스 AWS, GCP, Azure 등 플랫폼 사업자들이 제공하는 서비스)의 등장으로 서비스 설계의 접근 방법과 구축 운영 형태의 패러다임 전환이 일어나고 있습니다. 그중 하나가 마이크로서비스와 이를 위한 아키텍처입니다.

 

마이크로서비스를 간단하게 말하자면, 기존 모놀리스와는 달리 하나의 큰 애플리케이션을 아주 작은 애플리케이션으로 나누어 서비스하자는 사상입니다.

 

마이크로서비스는 단일 애플리케이션이 가지는 단점을 해결하고, 민첩성과 유연한 시스템이라는 측면에서 분명 많은 이점이 있습니다.

비즈니스 환경의 급속한 변화와 시스템의 규모와 복잡도의 증가로 모놀리스 형태로 더는 해결할 수 없는 새로운 기술적인 이슈들이 생겨나고, 이에 대한 고민이 이어졌습니다.

마이크로서비스 아키텍처 스타일은 그 이슈들에 대응할 수 있는 아키텍처적인 접근 방법의 하나입니다.

 

플랫폼 사업자들이 과거에 아키텍트들이 했던 대부분의 작업을 Saas(Service as a Service), PaaS(Platform as a Service), IaaS(Infrastructure as a Service) 등 자동화된 기능으로 지원합니다.

 

이미지 출처 : Red Hat Topic - PaaS란 ? (https://www.redhat.com/ko/topics/cloud-computing/what-is-paas)

따라서, 아키텍터들은 기존 온프레미스(on-premise) 형태의 구축형 사업에서 요구하는 역할보다는 하루가 다르게 새롭게 만들어지는 기술 집약적 솔루션의 특징을 이해하고 조합할 줄 아는 능력을 더 요구받고 있습니다. 기술 중재자라는 측면에서의 역할은 같지만, 역할을 수행하는 방법 측면에서 바뀌고 있는 것입니다. 새로운 솔루션을 만드는 노력도 필요하지만, 하루가 다르게 쏟아져 나오는 솔루션을 이해하는 노력도 중요합니다.

참고 자료

• 자바기반의 마이크로서비스 이해와 아키텍처 구축하기 - 박성훈 지음
• 위키피디아 : UML, 4+1 아키텍처 뷰 모델
• Red Hat 토픽 : 클라우드 컴퓨팅의 이해

자바 기반의 마이크로서비스 이해와 아키텍처 구축하기