‘애플리케이션 현대화(App Modernization) 개념과 정의’ 포스트에서 앱 현대화의 개념과 필요성을 논의해 보았습니다. 실제로 메타넷티플랫폼이 진행한 앱 현대화 세미나 결과와 고객 문의 내용만 보더라도 기업의 고민을 잘 읽을 수 있습니다. 그래서 오늘 앱 현대화 2편 포스트에서는 앱 현대화의 핵심인 클라우드 네이티브 애플리케이션 아키텍처에 대해 정리했습니다.  

[Highlights]

▶ 애플리케이션 아키텍처는 앱 구조에 관한 패턴으로 기업 비즈니스 요건과 환경에 기반한 아키텍처 설계와 도입이 필요

▶ 애플리케이션 현대화(이하. 앱 현대화)는 ‘클라우드 네이티브 앱’을 의미하며, 클라우드 환경의 ‘마이크로서비스 아키텍처를 이용해 더 효과적으로 비즈니스 요건을 지원

▶ 마이크로서비스 아키텍처(이하. MSA)는 클라우드가 제공하는 기능에 바탕을 두고 독립적으로 개발 운영 가능한 ‘마이크로서비스’로 구성하며 DevOps, 데이터 분리, API 게이트웨이, 서비스 메시 등 요소로 구성. 

다양한 방식의 앱 아키텍처

패턴이란 특정 문제에 대해 반복적으로 적용할 수 있는 솔루션을 의미합니다. 최초의 컴퓨터인 애니악을 위한 프로그램이 개발된 이래로 SW 개발에 패턴을 적용해 개발하는 것이 표준이 되었습니다. 이들 중 SW 구조와 관련된 솔루션이 SW 아키텍처입니다.

앱 아키텍처는 앱 구조를 설계 및 개발에 사용하는 패턴과 그 안에 포함된 기술을 말합니다. 구조적으로 완성도 높은 앱의 개발을 위해 참고할 로드맵이자 베스트 프렉티스입니다. 따라서 앱 목적과 규모, 기타 조건에 가장 적합한 아키텍처를 고르고 그에 맞춰 개발하는 것이 중요합니다. 앱 개발 아키텍처 형태에는 어떤 것이 있는지 살펴보겠습니다.

N-Tier 구조

지난 십수 년간 온프레미스 방식의 비즈니스 앱 개발에 활용된 전통적 아키텍처입니다. 앱을 보통 프레젠테이션, 비즈니스 로직, 데이터 3개 계층으로 나누어 구성하거나 1,2계층을 더 추가해 관리하는 구조입니다. 

수평적으로 분할된 티어(tier) 혹 레이어(layer)는 다른 층과의 종속성을 최소화하면서 부여된 기능을 수행하는 데 적합합니다. 일반적으로 각 레이어는 바로 아래 레이어만 호출할 수 있습니다. 하지만, 해당 레이어의 수정이 필요할 경우 전체 레이어 심지어 전체 앱을 새로 배포해야 하는 상황도 발생합니다.

모놀리딕 (Monolithic) 아키텍처

클라우드 네이티브 앱의 반대 개념으로 사용되는 ‘모놀리딕’ 아키텍처는 레거시 시스템과 관련된 앱 아키텍처로써 한 앱에 모든 기능을 다 담는 방식입니다. 프로그램 요소들이 밀접하게 연결되어 있고 상호 종속적입니다. 그래서 프로그램의 어떤 코드를 실행하거나 컴파일 하려면 관련된 모든 컴포넌트가 프로그램에 있어야 합니다. 기능 업데이트를 위해 앱 전체를 새로 개발해야 하는 경우도 생깁니다. 

물론 장점도 있습니다. 먼저, 구조가 단순해서 배포가 쉽습니다. 또, 모듈 간 통신 부하가 적어서 상대적으로 성능이 좋습니다. 단순한 구조 덕분에 테스트와 버그 해결도 용이합니다. 아래는 전형적인 모놀리딕 구조로 개발한 쇼핑몰 웹 앱으로, 단일 파일로 배포될 수 있습니다. 

[출처: https://microservices.io/i/DecomposingApplications.011.jpg]

​

마이크로서비스 (Microservice)

마이크로서비스는 아키텍처이자 SW를 개발하는 방법입니다. 마이크로서비스 형태로 개발하면 앱을 가장 작은 단위로 나누고 나눠진 컴포넌트들은 서로 독립적으로 작동합니다. 이렇게 분리된 컴포넌트를 ‘마이크로서비스’로 부릅니다. 

유명한 SW 개발자인 마틴 파울러는 마이크로서비스를 “개별 실행되는 프로세스를 가지고 상호 간에 HTTP API 같은 가벼운 방법으로 통신하는 일련의 ‘서비스’로 구성된 앱 개발 방식”으로 설명합니다. 파울러에 따르면 MSA는 앱 개발, 배포, 운영 시 다음의 특성을 가집니다:

   -    One Thing: 한 가지 기능 (비즈니스 기능 및 역할)을 수행

   -    Small: 독립적이고 배포 가능한 가장 작은 단위 서비스(=atom)로 분리

   -    API(Application Programming Interface): API를 통해 다른 서비스와 연동

   -    Autonomous: 각각 자율적으로 개발 및 운영 가능

​

[출처: https://docs.microsoft.com/ko-kr/azure/architecture/includes/images/microservices-logical.png]

마이크로서비스는 분산형으로 느슨하게 결합되어 서로 영향을 주지 않고 독립적입니다. 따라서 한 서비스 문제가 다른 부분으로 확산되지 않습니다. 또, 부하가 걸리는 MSA만 보완하면 전체 서비스를 쉽게 확장 가능한 장점도 갖습니다. 앱 확장을 위해 전체 시스템을 늘려야 하는 모놀리딕 및 N-티어 구조에 비해 매우 탄력적이고 장애 발생도 적습니다.

MSA의 중요 목적은 비즈니스에 필요한 고품질 SW를 빠르게 개발, 배포하는 데 있습니다. 아울러 여러 마이크로서비스를 여러 팀이 동시 개발하고 독립적으로 배포할 수 있습니다. 배포 및 변경 작업 시에도 다른 서비스에 영향을 줄 수 있는 전체 앱 리빌드나 재배포가 필요 없습니다. 그래서 특정 마이크로서비스에 기능 추가나 개선이 필요하면 다른 팀 서비스에 신경 쓰지 않고 작업을 시작할 수 있습니다.

몇 가지 단점도 있습니다. 우선, 기존 아키텍처와 다른 복잡성을 제공합니다. 서비스 간 통신, 디버깅과 테스트가 상대적으로 어렵습니다. 서비스 간 통신을 위한 인터페이스 제어도 복잡합니다. 각 서비스 API 정의, 변경에 따른 버전업 등도 부담이죠. 처음 시도하는 기업은 초기 비용이 기존 아키텍처 개발보다 높다는 것도 이슈입니다. 인프라 구성, 개발팀 고도화 및 보안 등의 초기 투자 비용이 생각보다 높을 수 있습니다. 하지만 이런 조건을 갖고 있다면 오히려 비용이 줄어듭니다.

아래는 마이크로서비스 아키텍처 애플리케이션을 제대로 구현하기 위해 필요한 요소들입니다. 

1) 서비스

각 SW 컴포넌트는 ‘서비스’라는 형태로 구현되고 API(보통 RESTful API)를 이용해 다른 서비스와 통신합니다. 서비스 간 경계는 보통 사용자 관리, 상품관리, 주문관리 등 업무 영역을 경계로 합니다. 서비스는 http://Mysshop/v1/users], myshop/v1/products 같이 URI(Uniform Resource Identifier; 통합 리소스 식별자) 형태로 제공됩니다.

2) 데이터 분리

서비스별로 필요에 따라 별도 데이터베이스를 사용하는 경우가 많습니다. 이유는 다른 서비스에 대한 의존성을 없애기 위한 ‘수직분할원칙’을 권장하기 때문입니다. 데이터베이스를 다르게 하거나 같은 데이터베이스를 사용하더라도 스키마를 다르게 가져가는 방법 등을 이용합니다. 

3) API 게이트웨이

모든 API에 대한 end point를 통합하고 추가 기능을 제공하는 미들웨어 적용을 권장합니다. 게이트웨이가 제공하는 기능에는 오케스트레이션, 인증, 로깅, 메시지 변환 등이 포함됩니다. 

4) DevOps

DevOps는 개발(Development)과 운영(Operations)을 합친 말로, 개발과 운영을 통합적으로 수행한다는 의미입니다. 아마존은 DevOps를 “앱과 서비스를 빠른 속도로 제공할 수 있도록 조직 역량을 향상시키는 문화 철학, 방식 및 도구의 조합”으로 정의합니다.

최근까지 비즈니스 앱 개발 시 개발, 운영 및 인프라 조직을 분리해 가져가는 경우가 많았습니다. 이제는 고객과 시장 요구를 빠르게 지원하기 위해 한 팀에서 개발, 테스트, 배포, 운영의 전체 과정을 통합하는 쪽으로 변하고 있습니다. 클라우드가 메인 인프라가 되면서 개발 사이클이 짧아지고 개발자와 인프라 관리자의 역할이 중첩되기 시작한 것도 큰 이유입니다. DevOps 팀은 서비스별로 소수 인원으로 조직됩니다. 작은 팀으로 개발-운영에 이르는 전 과정을 관리하기 위해서는 자동화를 통한 생산성 향상이 병행되어야 합니다.

5) 기타 

이 밖에도 컨테이너 관리, CI/CD(continuous integration & continuous delivery), 데이터베이스 메시징큐 등 공통 서비스, 서비스 메시(Service Mesh; 마이크로서비스 간 통신 담당)도 중요합니다. 

레거시 디자인 – 모놀리딕

‘앱 현대화(App Modernization) 개념과 정의’ 설명처럼 모놀리딕 방식의 3-티어 아키텍처(아래 그림)로 개발된 앱은 비즈니스에 필요한 민첩성, 확장성을 제공하지 못하는 경우가 많았습니다. 이런 앱으로 현대의 비즈니스를 수행한다는 것은 큰 위험이죠. 앱 현대화가 중요한 이유입니다.

[출처: 기존 모놀리딕 디자인]

클라우드 네이티브

앱 현대화와 ‘클라우드 네이티브’ 앱은 거의 동의어처럼 사용합니다. 원주민(Native)은 ‘특정 지역에서 태어나서 성장하고 살아가는 사람’을 이르죠. 클라우드 네이티브 역시 ‘클라우드 환경에 맞추어 설계되고 최적화되어서 서비스’되는 앱을 의미합니다.

클라우드 네이티브 앱의 핵심은 ‘서비스’입니다. 앱을 독립적인 여러 서비스로 분리한 다음 서비스를 체계적으로 구성, 연결 및 관리하는 것이 관건이죠. 이들 ‘서비스’를 기업이 비즈니스 기능으로 제공하기 위해서 다양한 클라우드 기술, 기능 및 인프라가 필요합니다. 클라우드 ‘마이크로서비스’ 아키텍처가 레거시 모놀리딕에 비해 이런 요소를 휠씬 더 효율적으로 지원합니다. 위 모놀리딕 구조를 클라우드 네이티브로 바꾸면 아래와 같습니다. 

[출처: 클라우드 네이티브 디자인]

위 그림처럼 기능(인증 서비스, 카탈로그 서비스 등)이 마이크로서비스 단위로 나눠지고 독립적으로 클라우드 서비스에 존재하면서 필요시 다른 앱(모바일 앱, SPA 웹 앱)에 기능을 제공하도록 설계되어 있습니다. 업데이트도 개별 마이크로서비스 단위로 진행되고 클라우드 서비스 기능을 이용해 자동 배포됩니다. 

현대의 기업은 디지털 트랜스포메이션의 파도 앞에 놓여 있습니다. 업종을 막론하고 디지털화를 통해 비즈니스 모델을 개선하고 경쟁 우위를 확보해야 하는 상황입니다. 디지털 전환의 성공 요건 중 하나는 비즈니스 변화를 빠르게 대응하고 내/외부 고객에게 최적의 앱을 신속히 제공하는 데 있습니다. 

이런 이유로 클라우드 네이티브 방식의 앱 현대화가 확산 중입니다. 이를 위해서는 비즈니스 프로세스, 인프라, 아키텍처에도 지속적 투자가 따라야 합니다. 또 앱 현대화, 클라우드 구축 경험과 역량을 가진 파트너와의 협업도 필수입니다. 여러분 회사가 앱 현대화를 처음으로 시도한다면 더욱 그렇습니다. 

다음 포스트에서는 메타넷티플랫폼이 구현한 앱 현대화 고객 사례를 알아보겠습니다.

​

메타넷티플랫폼은 고객의 클라우드 여정을 같이합니다.

http://www.metanettplatform.com/

​

#앱현대화 #MSA #마이크로서비스 #클라우드네이티브앱 #티플랫폼 #클라우드구축업체 #클라우드컨설팅 #클라우드마이그레이션 #디지털트랜스포메이션 #애플리케이션현대화 #앱현대화 #3티어아키텍처 #마이크로서비스아키텍처 #클라우드네이티브

​