사례 기반 소프트웨어 아키텍처 2편

지난 테크 블로그에서는 분당서울대병원과 서울대병원의 차세대 프로젝트에 활용되었던 HSF(Healthcare Software Framework) 구축 사례를 기반으로, ‘소프트웨어 아키텍처’ 가 무엇인지, 어떤 의미와 가치를 갖고 있는지를 살펴보았습니다. 혹시, 지난 블로그를 못 보신 독자분은 지난번의 블로그를 참고하시기 바랍니다.

👉‘사례 기반 소프트웨어 아키텍처 1편’이 궁금하시다면?

본 사례 기반 소프트웨어 아키텍처 2편에서도 슈퍼컴퓨터를 활용한 국가과학기술 데이터 관리 체계를 빅데이터 플랫폼 기반으로 전환하려는 기획 프로젝트를 기반으로, 소프트웨어 아키텍처를 만드는 과정을 좀 더 구체적으로 살펴보겠습니다.

지난번 블로그와는 달리, 이번 블로그에는 약간의 이론적 토대가 담겨 있습니다. 이론을 정말 싫어하거나 흥미 위주로만 보고싶은 분들은 이론 부분을 건너뛰면서 보는 것도 괜찮습니다.

프로젝트 소개

먼저 프로젝트를 간단히 소개하면 “미래의 서비스 환경을 위한 빅데이터 플랫폼 구축 기획”이라고 할 수 있습니다. 프로젝트 배경은 슈퍼컴퓨터가 처리해오던 기존의 방대한 과학기술 데이터를, 일반 서버 기반 스케일 아웃(Scale Out)이 가능한 클라우드 환경에서 처리하여, 연구 비용 절감 및 많은 연구자들에게 보다 나은 연구 편이성을 제공하기 위한 것입니다.

프로젝트 맥락 이해 – 개념도

다음의 개념도(Context Diagram) 그림을 보면, 다양한 과학기술 영역에 대해 여러 이해관계자들이 서로 다른 관심사를 갖고 있으며, 다양한 레퍼런스들이 존재한다는 것을 알 수 있습니다. 아키텍트는 전체 맥락을 효과적으로 파악하여 전달할 책임이 있는데, 이와 같은 개념도는 프로젝트 초기에 많은 사람들이 프로젝트 및 시스템에 대해 올바른 이해를 하는데 도움을 줍니다.

아키텍처 개념의 기준 – IEEE 1471, ISO/IEC/IEEE 42010

아키텍처 개념 및 효용을 설명하는 다음 그림은 아키텍처 관련 표준인 IEEE 1471에 근거한 것입니다. 많은 사람들이 참여하는 프로젝트 초기부터 리더십을 가져가고 싶은 아키텍트는 IEEE 1471 또는 IEEE 42010를 이해하고 활용하는 것은 매우 효율적인 수단이라고 할 수 있습니다.

아키텍처 관련 개념 및 개념 설명

본 블로그에서는 IEEE1471의 핵심만 간단히 살펴보겠습니다. 그림2의 왼쪽에는 전반적인 아키텍처 관련 개념 및 관계가 오른쪽에는 개념에 대한 설명이 있습니다. 그림 속 개념 중 하나인 시스템에는 서로 다른 관심사를 가진 다양한 이해관계자가 있으며, 이들에 대한 합리적 근거를 제시하는 것이 아키텍처라는 의미를 찾아볼 수 있습니다. 합리적 근거를 만들어가는 구체적인 방법으로 다양한 뷰(View)가 있습니다. 이해관계자들의 관심사가 반영된 아키텍처 요구사항을 수집 및 분석하는 과정과, 그를 토대로 다양한 뷰를 정의하면서 아키텍처를 설계하는 과정을 지금부터 살펴보겠습니다.

이해관계자 관심사의 중요성

이해관계자 관심사 파악은 매우 중요합니다. 일반적으로 프로젝트를 시작하려면, 프로젝트에 대한 필요성이 제기되고, 필요성을 충족시키기 위한 예산안이 승인되어야 합니다. 많은 예산과 경영진의 관심사를 받는 프로젝트를 성공시키는 것은 조직이 수행해야 할 매우 중요한 일이며, 성공 여부를 판단하는 기준이 이해관계자 관심사를 기반으로 정의된 프로젝트 요구사항입니다. 따라서, 이해관계자 관심사와 함께 관련 있는 구체적인 기능(Functional) 및 비기능(Non-Functional) 요구사항을 수집하고 분석하는 과정은 모두 중요한 일입니다.

플랫폼 구축에 관한 요구사항 수집

이 프로젝트에 대한 이해관계자는 매우 많지만, 그 중 핵심은 전국에 걸친 국가 연구 기관이었습니다. 이해관계자들의 관심사 이해 및 요구사항을 수집하기 위해 각 기관들의 홈페이지/포탈에 대한 사전조사 및 각 기관에 대한 사전 설문 조사를 수행했고, 전국을 돌아다니면서 대면 인터뷰를 통해 구체적인 요구사항을 수집 및 확인했습니다. 요구사항 수집 대상 기관은 한국생명공학연구원, 국가생명연구자원정보센터, 나노종합기술원, 한국에너지기술연구원, 한국항공우주연구원, 한국천문연구원, 한국지질자원연구원, 국립환경과학원, 한국건설기술연구원, 농촌진흥청, 기상청, 한국수자원공사, 한국원자력연구소, 국가핵융합연구소, 한국해양과학기술원, 한국과학기술원 등 총 16개 기관이었습니다.

아키텍처 분석 및 설계 프로세스

그림3을 보면 아키텍처 관련 모든 활동에 대한 기준이 앞에서 수집한 요구사항이라는 것을 알 수 있습니다. 특히, 아키텍처가 기능과 독립적인 영역이기 보다는 서로 매우 밀접하게 관련을 맺고 있으며, 분석 및 설계 과정 속에 분할과 통합을 거치면서 개발 및 환경 준비에 필요한 구체적인 사항들이 만들어지는 개괄적인 프로세스를 살펴볼 수 있습니다.

품질 속성(Quality Attribute) – 아키텍처 요구사항 유형

아키텍처 요구사항 유형을 품질 속성이라고 하는데, 이들 품질 속성 관리가, 큰 시스템의 경우에는 품질 속성들을 단순하게 모아서 관리하는 것이 아닌, 아키텍처의 복잡성을 효율적으로 관리하기 위한 분류 체계를 기반으로 관리를 해야 합니다. 그 이유가 품질 속성들은 서로에게 긍정적 또는 부정적으로 영향을 끼칠 수 있고, 그 관계가 복잡하기 때문에 체계적인 관리를 하지 않는 경우, 미션 크리티컬 프로젝트나 대규모 프로젝트의 경우 프로젝트 실패로 연결될 수 있는 큰 위험에 빠질 수도 있기 때문입니다. 예를 들어, 성능과 보안 두가지 품질 속성만 보아도, 서로가 상충하는 부정적 관계라는 것을 쉽게 파악할 수 있습니다. 따라서, 이들 품질 속성 각각의 요구사항 뿐만 아니라, 상호 관련성을 모두 고려하여 다양한 이해관계자들이 이해할 수 있는 합리적인 절충안을 만들어야 합니다.

효율적 품질 속성 관리의 근간 – 품질 모델

품질 속성에 대한 분류 체계를 제시하는 품질 모델이 다음 그림에 나타나 있는 ISO/IEC 9126 및 ISO/IEC 25010입니다. 그림에서 보는 것처럼 품질 모델은 시스템이 가질 수 있는 전반적인 품질 속성을 구조화시켜 정의하고 있습니다. 이 프로젝트는 ISO/IEC 9126에 기준을 두고 품질 속성을 선택하였고, 관련 요구사항을 정의하였습니다.

플랫폼 구축에 관한 품질 속성

앞의 그림에 나열된 사항은 이 프로젝트에서 초기에 선정된 품질 속성인데, 상위 수준의 핵심 시나리오와 함께 정의하였습니다. 품질 속성은 가급적 수치 형태로 측정 및 검증이 가능한 구체적인 요건으로 정의하는 것이 바람직하며, 이를 위해 이해관계자들과 많은 논의 및 절충 과정을 거쳐야 합니다. 구체적인 품질 속성 요건을 정의할 때는 품질 속성 시나리오의 형태를 준수하거나 프로젝트 상황에 맞게 변형시키는데, 이에 대한 구체적인 내용은 본 블로그에서는 언급하지 않겠습니다. 이에 관심있는 분들은 “소프트웨어 아키텍처 이론과 실제 4/e, 에이콘 출판” 서적을 참조할 것을 추천드립니다.

품질 속성 기반 합리적 아키텍처 의사결정

프로젝트마다 관련 시스템의 목적 및 특성에 따라 서로 다른 아키텍처 결정사항들이 존재합니다. 프로젝트가 만드는 시스템이 크고 중요할수록 많은 아키텍처 결정사항이 수반될 수 있는데, 다음 그림은 품질 속성과 아키텍처 결정사항과의 관계를 표현한 일부 테이블 내용입니다.

예를 들어, 테넌트(tenant)란 사용자 집단을 의미하는데, 멀티테넌시(multi-tenancy)란 다양한 사용자 집단군의 데이터를 보호하면서, 효율적인 운영을 하기 위한 소프트웨어 구조를 말합니다. 즉, 테넌트는 개별 계약의 대상이며, 테넌트 데이터는 개별적으로 구분하여 관리하지만 비즈니스 프로세스 및 로직은 최대한 공유하면서 효율적인 시스템을 만들어 운영합니다. 다만, 전문 인력이 필요하고, 보안 등 컴플라이언스 요건 등에 따른 저장 공간의 분리 등 다양한 설계 전략이 필요합니다. 하지만, 이 프로젝트의 품질 속성들과 연관해서 고려해볼 때 긍정적인 아키텍처 의사결정이라고 볼 수 있습니다.

이처럼 아키텍처 요구사항과 연결된 품질 속성은 적절한 아키텍처 의사결정을 위한 좋은 기준이 됩니다.

품질 속성 중심의 위험 관리

시스템 규모가 커지거나 미션 크리티컬(Mission Critical) 시스템인 경우 위험관리의 중요성이 증대되는데, 이 경우에는 품질 속성 중심의 통합적인 위험관리를 기반으로 체계적이면서도 효율적으로 위험관리를 수행할 수 있습니다. 즉, 품질 속성별로 다른 품질 속성과의 관계나 관련 의사결정 사안, 품질 속성 실현에 대한 가능성 및 전문성 등을 분석하면서 그에 따른 위험을 정의하고, 각 품질 속성별로 정의된 모든 위험들을 조직, 비용, 의사결정, 기술 관점에서 검토하여 통합적 위험관리를 하면서 프로젝트에 잠재된 위험을 관리하는 것입니다.

이제 품질 속성에서 뷰(View) 관련 내용으로 넘어가보겠습니다.

사용자에게 가치를 전달하기 위한 기반 – 기능 중심의 모듈 뷰(Module View)

설문, 인터뷰 등 다양한 수단을 통해 수집한 요구사항들을 구조화 시키고 분류하는 과정에서 기능을 통합하면서 모듈화 시킵니다. 이렇게 모듈화 시킨 모든 모듈을 모아 관련 모듈끼리 묶고 연관을 지어 만든 그림을 모듈 뷰라고 하며, 이 모듈 뷰는 기능 중심으로 사용자에게 가치를 전달하는 가장 기본적인 관점을 형성합니다.

모듈 뷰 설계 전략 및 목적

모듈 뷰의 가장 기본적이면서도 중요한 목적은 기능 요구사항의 추적이며, 이 과정에서 요구사항의 누락은 없는지, 요구사항이 적절하게 구현되는지에 대한 효율적인 관리 기반을 만듭니다. 뿐만 아니라, 각 모듈 간 의존성 정보를 바탕으로 시스템 변경에 대한 영향 등을 파악할 수 있으며, 프로젝트 전반에 걸친 팀간 부서간 업무간 시스템간 복잡한 의사소통을 효율화 시키는 기반을 제공할 수 있습니다.

이처럼 모듈 뷰는 소프트웨어 아키텍트 뿐만 아니라 프로젝트 관리자나 개발자에게도 빼놓을 수 없는 중요한 사항이며, 모듈 뷰는 소스코드를 만들기 위한 청사진이라는 의미도 갖습니다.

모듈 뷰 예시 – 요구사항 관리 및 개발의 근간

그림을 보면 채널, PC, 기기 등 다양한 사용자 환경과 연계되는 애플리케이션 레이어 및 모듈, 그리고 연관된 많은 레이어나 모듈들이 보인다. 많은 테넌트들은 대부분 애플리케이션 레이어와 연결되며, 애플리케이션 레이어는 플랫폼 및 외부 시스템과 관련성을 갖는다.

이 그림에서 볼 수 있는 것처럼 모듈은 그 내부에 모듈을 포함시킬 수 있으며, 이 프로젝트에서는 그 수준을 L1에서부터 L5까지의 모듈로 세분화하여 관리하였습니다. 이는 요구사항 기능 구조도(Functional Structure Diagram), 유저 스토리 맵(User Story Map)과도 일맥상통합니다.

포함된 다양한 수준의 모듈들은 모두 요구사항과 연계된 구조화의 결과들입니다. 특히, 기능 요구사항들은 모두 모듈에 연관되어 있고, 추후 이들 모듈의 대부분은 소프트웨어로 개발되지만, 아키텍처 전략에 따라 일부는 기존 서비스, 컴포넌트, 솔루션, 라이브러리, 프레임워크로 대치되기도 합니다.

컴포넌트 & 커넥터 뷰를 위한 의사결정 – 하둡(Hadoop) 프레임워크 선정

이 프로젝트의 경우 컴포넌트 & 커넥터 뷰를 설계하기 위해 실제 개발 및 테스트 환경을 고려했습니다. 빅데이터 플랫폼을 구현하기 위한 다양한 개발 및 테스트 환경을 고려하였고, 기반 프레임워크로 하둡을 최종 선택했습니다. 하둡 선택은 중요한 아키텍처 의사결정 중 하나였습니다. 특히, 컴포넌트 & 커넥터 뷰를 정의하기 전에 하둡 프레임워크 및 관련 적용 방안을 결정하였고, 이후 구체적인 컴포넌트 & 커넥터 뷰 및 세부 메커니즘을 정의하였습니다.

상황에 따라 다른 선택 및 의사결정 필요

지금이라면 Flink, Spark, Kafka 등 다양한 빅데이터 프레임워크 및 솔루션 많이 존재하고, 단일 프레임워크가 아닌 복수의 프레임워크를 상황에 맞게 하나 또는 복수 프레임워크를 혼용해서 활용할 것을 권고할 수도 있지만, 2013년 당시 빅데이터 플랫폼에 대한 소프트웨어 아키텍처 설계 당시만 해도 빅데이터 플랫폼 전반에 걸친 기능 및 성능, 관리 역량을 보유한 프레임워크가 없는 상황에서 하둡은 거의 유일한 해결 방안으로 판단했었습니다.

컴포넌트 & 커넥터 뷰 설계 전략 및 목적

소프트웨어가 실행되는 단위를 컴포넌트라고 생각하기 바랍니다. 여기에는 .o, .exe, .dll, .jar, .bin 등 다양한 실행 파일 형태가 있을 수 있습니다. 요즘 핫한(?) 오픈소스 LLM(Large-Language Model)도 결국은 실행 파일이며 컴포넌트라고 할 수 있습니다. 이들 컴포넌트는 로컬(Local) 또는 리모트(Remote) 환경에서 다양한 형태로 서로 상호작용을 하는데, 이때 컴포넌트간 상호 참조(양방향 참조)나 순환 참조가 나타나면 메모리를 빠르게 잠식하여 장애로 이어질 수 있기 때문에 이를 방지하는 설계가 필요합니다.

이처럼 컴포넌트 & 커넥터 뷰를 잘 활용하면 신뢰성 있는 시스템을 설계하고 만들기에 용이합니다. 이때, 컴포넌트는 어떤 개발자들이 만들고 통합하는지, 얼마나 많은 사용자가 동시 접속하는지, 보안 요건은 무엇인지, 트랜잭션 처리 성능은 어느 정도인지 등을 판단할 수 있는 좋은 기준이 됩니다. 커넥터는 소켓, RPC, RESTful 등 다양한 연계 방식뿐만 아니라, 암호화 및 워크플로우나 접근 제어 등 다양한 관리를 고려하여 설계할 수 있습니다.

컴포넌트 & 커넥터 뷰 예시 – 체계적 개발 및 효율적 운영 기반 정의

이 프로젝트는 많은 사용자가 활용하는 빅데이터 플랫폼을 고려하기 때문에 상당히 구체적인 컴포넌트 & 커넥터 뷰를 관리할 필요가 있었습니다. 그래서, 관리 및 서비스에 관한 별도의 컴포넌트 & 커넥터 뷰를 구성하여 총 3영역으로 구분한 컴포넌트 & 커넥터 뷰를 구성하였습니다..

맵리듀스 메커니즘 예시 – 빅데이터 처리 방안 정의

빅데이터 관련 아키텍처의 내부는 대부분 마스터와 슬레이브(Master & Slave) 구조를 기반으로 동작합니다. 또한 빅데이터 처리는 기존의 정규화된 데이터 처리와는 달리 키-값 쌍으로 된 데이터를 분산 공간에 저장하고 처리하는 형태를 기본으로 갖고 있으며, 맵리듀스는 이와 같은 형태에 아주 효율적인 처리 메커니즘을 제시합니다. 예를 들어, 그림에서는 메타 정보를 기반으로 관리하는 JabTracker와 실제 데이터를 처리하는 여러 TaskTracker사이의 상호 작용을 볼 수 있습니다.

이해를 쉽게 하기 위해 맵리듀스 메커니즘 설명에 조금 사족을 조금 붙여보겠습니다. 구글은 전세계로부터 끊임없이 들어오는 수많은 검색어들을 분류하고 분석하고 있습니다. 그 많은 데이터들을 처리한다고 생각할 때, 떠오르는 좋은 처리 방법이 있을까요? 구글은 자신들이 하는 일을 패턴화시켜 논문으로 작성했고, 이를 자바 언어로 프레임워크화 시킨 것이 하둡입니다. 맵리듀스는 빅데이터 처리의 핵심으로, 이를 활용해 비용 대비 빠른 데이터 처리 성능 및 안정성을 동시에 갖출 수 있게 되었습니다.

시스템 뷰 설계 전략 및 목적

시스템 뷰는 소프트웨어를 개발하고 검증하고 실행하는 서버, 네트워크, 저장 환경과 소프트웨어 요소 간에 어떤 관계가 있는지를 보여줍니다. 어떤 프로세스에서 어떤 소프트웨어 요소가 실행되는지, 실행시 상호작용을 하는 프로토콜은 무엇이며, 실행 결과는 어떤 영역에 저장되는지 등을 알 수 있도록 설계합니다.

특히, 목적한 시스템이 제대로 기능(Functionality)하고, 서비스가 항상 가용해야 하며(Availability), 효율적인(Efficiency) 운영이 될 수 있도록 소프트웨어 요소들을 배치하고 파이프라인을 구성할 수 있는 환경을 제공해야 합니다.

시스템 뷰 예시 – 개발, 테스트, 특히 운영 관련 역할에 도움

시스템 뷰에서는 모듈 뷰와 컴포넌트 및 커넥터 뷰를 바탕으로 소프트웨어를 개발 및 실행시키는 시스템과 시스템을 구성하는 소프트웨어 요소들의 관계를 볼 수 있습니다. 이 프로젝트의 시스템 뷰는 통합/허브센터를 구성하는 물리적/논리적 시스템의 구성을 정의합니다. 제시한 서버 환경은 x86 계열의 Commodity 서버 클러스터로 구성되는 분산 처리 환경과 고성능 서버 기반의 분석/저장 환경을 갖는 하이브리드형 센터의 구조를 갖습니다. 분산 환경 제어 및 기타 관리 서버들은 사용자 및 관리 대상에 따라 적절한 규모의 서버를 선정하여 도입하여 구성할 수 있습니다.

시스템 뷰의 하부 뷰 예시 – 플랫폼 서비스 뷰

플랫폼 기반으로 구축되는 통합 및 허브 센터는 서비스 미들웨어의 역할을 담당합니다. 센터는 사용자(연구자 및 관리자)들에 대한 인증 및 관리 기능을 기반으로 협업/개인화/커뮤니티/과학기술포탈 등을 웹 또는 클라우드 서비스로 제공하며, 백엔드 서비스로 각종 시스템 및 과학기술 단체의 데이터 수집 및 연동 서비스를 제공합니다.

분산 컴퓨팅 클라우드 시스템 뷰, 센터 데이터 수집 및 연동 데이터 변환 시스템 뷰, 플랫폼 운용관리 시스템 뷰, 플랫폼 보안 시스템 뷰, 플랫폼 네트워크 구성 뷰 등의 하부 시스템 뷰를 정의하였습니다.

이상으로 아키텍처 관련 두번째 블로그를 마칩니다.

이미 10년도 더 지난 빅데이터 플랫폼 구축 기획이었지만, 그 이야기 속에서 소프트웨어 아키텍처가 커다란 플랫폼을 만들 때 어떻게 활용될 수 있는지, 그리고 그 요건 정의 및 품질 속성 기반의 아키텍처 설계 과정을 간단하나마 살펴보았습니다.

이후 블로그에서는 대규모 프로젝트에 참여한 경험 기반의 아키텍처 이야기뿐만 아니라 Agile Architecture 및 AI Architecture에 관한 이야기도 써보도록 하겠습니다.