brunch

매거진 디지털 전환

라이킷 9 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 서진호 Nov 04. 2021

소프트웨어 설계 및 디자인 트렌드로 알아본 MSA

NIA 디지털서비스 이슈리포트 2021년 10월호

지난 50여 년 동안 소프트웨어 아키텍처 및 애플리케이션 호스팅 모델은 메인 프레임에서 마이크로서비스, 다시 서버리스로 주요 전환을 경험했습니다. 메인 프레임에서 최신 클라우드 네이티브 아키텍처(CNCF)에 이르기까지 다양한 호스팅 모델은 비즈니스 앱을 개발, 배포 및 유지 관리하는 방식에 영향을 미쳤습니다. IT 서비스 업계에서 새로운 호스팅 모델을 발견할 때마다 팀은 아키텍처의 이점을 최대한 활용하는 데 어려움을 겪었습니다. 이로 인해 아키텍처 편차 및 안티 패턴과 같은 의도하지 않은 결과가 발생하여 상당한 기술적 부채가 발생했습니다. 기술 부채 관리는 팀의 건강뿐만 아니라 전체 시스템에서 중요한 역할을 합니다. 기술 부채를 적시에 처리하지 않는 IT 리더는 소프트웨어 관련 및 조직적 피해를 일으킬 위험이 있습니다. 기술 부채는 나쁜 관행을 제도화하고 최고의 인재를 몰아내는 동시에 그 자체로 부채를 먹고 더 많은 부채를 생성합니다.

한편, 마이크로서비스, 클라우드 컴퓨팅 및 컨테이너와 같은 기술 트렌드는 최근 몇 년 동안 매우 빠르게 확대되어 이러한 기술들의 대부분은 이제 최고 SW 엔지니어, 설계를 담당하는 아키텍트 및 IT 리더의 일상 업무의 일부가 되었습니다. 그러나, 비록 클라우드가 가능한 세상에 살고 있지만, 클라우드를 지원한다고 해서 클라우드 네이티브가 되는 것은 아닙니다. 사실은 클라우드 네이티브 없이 클라우드를 지원하는 것은 가능하지만 위험합니다. 이러한 추세를 검토하고 클라우드 지원 세상을 최대한 활용하기 위해 기업들이 구현해야 하는 아키텍처 및 조직적 변경 사항에 대해 논의하기 전에 현재 우리가 어디에 있고 어디로 가고 있는지 살펴보는 것이 중요하다고 생각합니다. 그래야 역사적인 패러다임 전환의 경고와 함정을 이해함으로써 이전의 실수로부터 배우고 조직이 이 기술들의 최신 물결에서 번창할 수 있는 위치를 잡을 수 있기 때문입니다. 그러므로 최신 클라우드 소프트웨어 아키텍처 설계 및 디자인 추세가 어떠한 지 알아보겠습니다.

클라우드 애플리케이션 호스팅과 앱 서비스 간의 종속성 문제 대두

지난 10년은 애플리케이션 호스팅이 클라우드 컴퓨팅의 형태로 서비스로 제공되었을 때 애플리케이션 호스팅에서 큰 변화를 겪었습니다. 예를 들어, 분산 컴퓨팅, 네트워크, 스토리지, 컴퓨팅 등과 같은 서비스 기능이 필요한 애플리케이션 사용 사례는 기존 인프라에 비해 합리적인 비용으로 클라우드 호스팅으로 프로비저닝 하기가 이제는 훨씬 쉬워졌습니다. 또한 소비자는 자원의 탄력성을 활용하여 수요에 따라 확장 및 축소가 가능해졌고, 사용한 스토리지 및 컴퓨팅 리소스에 대한 비용만 지불하면 되는 형태로 바뀌었습니다. 클라우드 기반 호스팅의 매력은 개발 및 운영 팀이 더 이상 서버 인프라에 대해 걱정할 필요가 없습니다. 개발자는 애플리케이션을 호스팅 할 서버 사양을 선택하고, 클라우드는 하드웨어, OS 및 네트워킹을 제공합니다. 클라우드 서비스의 IaaS, PaaS, SaaS 와 같은 세 가지 유형으로 유연하게 서버를 지정해야 하는 개발 팀에 약간의 부담을 줄 수도 있습니다.

그리고 개발자는 애플리케이션과 환경 설정 구성에 대해서만 걱정하면 됩니다. 왜냐하면, 클라우드 공급자는 모든 서버 인프라, 네트워크 및 모니터링 작업을 처리하기 때문입니다. 또한 클라우드 공급자는 클라우드에서 호스팅 되는 실제 애플리케이션을 제공하므로 클라이언트 조직은 애플리케이션 코드에 대한 책임 없이 애플리케이션 전체를 사용할 수 있습니다. 기본적으로 소프트웨어 서비스를 제공하지만 클라이언트가 공급자가 제공하는 것 이외의 사용자가 지정한 비즈니스 기능이 필요한 경우 유연하지 않을 수도 있습니다. 따라서, 서비스로서의 인프라(IaaS) 및 서비스로서의 플랫폼(SaaS)에 도입된 탄력적 기능을 통해 서비스의 단일 인스턴스를 필요에 따라 확장할 수 있으므로 그러한 확장성을 위해 불필요한 인스턴스 중복을 제거할 수 있습니다. 그러나 이러한 기능은 여러 버전을 보유하거나 모놀리스 기반의 애플리케이션 배포의 부산물과 같은 다른 목적으로 인스턴스를 복제하는 것은 추후 문제가 발생할 요지가 있습니다.

[그림 1] – 애플리케이션 아키텍처 진화 및 애플리케이션 호스팅 모델 (출처: InfoQ)

[그림1] 애플리케이션 아키텍처 진화 및 애플리케이션 호스팅 모델 연관에서 보듯이, 더욱 더 서비스로서의 플랫폼(SaaS)은 개발자가 기본 인프라를 프로비저닝 하거나 유지 관리하는 것에 대해 걱정할 필요 없이 자신의 맞춤형 비즈니스 애플리케이션을 호스팅 할 수 있게 해주기 때문에 클라우드 옵션 중에서 최적의 장소가 되었습니다. 그러나, 클라우드 호스팅이 모듈식 애플리케이션 설계 및 배포를 장려했지만, 많은 조직에서는 탄력적인 분산 아키텍처에서 작동하도록 설계되지 않은 레거시 애플리케이션을 클라우드로 직접 리프트 앤 시프트 하여 ‘모놀리스 지옥(Monolith Hell)’의 문제가 발생하기 시작했습니다.

또한 클라우드로의 전환은 타사 라이브러리 및 기술에 대한 애플리케이션 종속성을 관리해야 하는 업계의 과제를 안겨주었습니다. 개발자들은 옵션이 너무 많고 타사 도구를 선택하기 위한 기준이 충분하지 않아 어려움을 겪기 시작했고, 애플리케이션 서비스 간의 ‘종속성 지옥(Dependency Hell)’을 보기 시작했습니다. 그렇다면, 종속성 지옥에 대해 좀 더 상세히 알아보자면, 크게 라이브러리, 클래스, 서비스 등의 수준에서 발생하는 것을 알 수 있습니다.

첫째, 자바의 JAR 및. NET의 DLL과 같은 라이브러리 종속성을 부적절하게 관리하면 문제가 발생할 수 있습니다. 예를 들어, 일반적인 스프링 부트 앱에는 140개 이상의 라이브러리 JAR 파일이 포함되어 있습니다. 애플리케이션에 불필요한 라이브러리를 패키징 하지 않았는지 개발자들은 한 번 더 확인해 볼 필요가 있습니다.

둘째, 애플리케이션 내 개체의 모든 종속성을 명확히 해야 합니다. 예를 들어, 컨트롤러 클래스는 비즈니스 서비스 클래스에 종속되고, 서비스 클래스는 리포지토리 클래스에 종속되어 있다고 가정해 봅시다. 소스 코드를 검토하는 동안 애플리케이션 내의 종속성을 검토하고 잘못된 종속성이 없는지 확인해야 나중에 각 클래스에 대해 업데이트나 버전 업그레이드를 할 때 하나 또는 다중으로 배포할 수 있도록 해야 합니다.

셋째, 시스템에서 마이크로서비스를 사용하는 경우 서로 다른 서비스 간에 직접적인 종속성이 없는지 확인한다. 라이브러리 기반 종속성 지옥은 패키징 문제이고 후자의 두 가지는 디자인 문제입니다. 다양한 종속성 지옥 시나리오를 더 자세히 조사하고 의도하지 않은 결과를 방지하여 기술의 확산을 방지하기 위한 설계 패턴으로 설계해야 합니다.

세분화된 재사용성의 마이크로서비스로 발전

이러한 모놀리스 지옥과 종속성 지옥을 탈피하기 위해 좀 더 앱 서비스를 세분화하여 재사용 하기 시작했습니다. 도메인 주도 개발(DDD) 및 엔터프라이즈 통합 개발(EIP)와 같은 소프트웨어 설계 방식은 2003년 정도부터 사용할 수 있었고, 일부 팀은 애플리케이션을 모듈식 서비스로 개발했지만 자바 애플리케이션용 헤비급 J2EE 애플리케이션 서버 및 .NET 애플리케이션용 IIS와 같은 기존 인프라는 모듈식 배포에 도움이 되지 않았습니다.

클라우드 호스팅, 특히, 히로쿠(Hiroku) 및 클라우드 파운더리(Cloud Foundary)와 같은 서비스로서의 플랫폼(PaaS)의 등장으로 개발자 커뮤니티는 진정한 모듈식 배포 및 확장 가능한 비즈니스 앱에 필요한 모든 것을 갖추게 되었습니다. 이는 마이크로서비스의 발전을 가져왔는데, 마이크로서비스는 세분화되고 재사용 가능한 프로그램블 가능한 기능 서비스와 환경 설정과 같은 오퍼레이션 가능한 비기능 서비스의 가능성을 제공했습니다.

마이크로서비스는 2013~2014년에 더욱 인기를 얻었습니다. 마이크로서비스는 강력하며 소규모 팀이 특정 비즈니스 및 기술 기능의 전체 주기 개발을 소유할 수 있도록 했습니다. 개발자는 클라이언트 응용 프로그램 또는 다른 서비스와 같은 시스템의 다른 부분에 부정적인 영향을 주지 않고 언제든지 코드를 배포하거나 업그레이드할 수 있습니다. 또한 마이크로서비스는 개별 서비스 수준에서 수요에 따라 확장 또는 축소할 수도 있습니다. 특정 비즈니스 기능을 사용해야 하는 클라이언트 애플리케이션은 개발자가 솔루션을 처음부터 코딩하거나 애플리케이션에서 솔루션을 라이브러리로 패키징 할 필요 없이 적절한 마이크로서비스를 호출할 수 있습니다.

마이크로서비스 접근 방식은 서비스 제공자와 서비스 소비자 간의 계약 중심 개발을 장려했습니다. 이는 전체 개발 시간을 단축하고 팀 간의 종속성을 줄였습니다. 즉, 마이크로서비스는 팀을 보다 느슨하게 결합하고 조직, 특히 비즈니스 스타트업에 중요한 솔루션 개발을 가속화했습니다. 예를 들어, 고객 대 주문 대 재고와 같은 마이크로서비스는 비즈니스 프로세스와 도메인 간의 명확한 경계를 설정하는 데 도움이 됩니다. 조직에서 ‘제한된 컨텍스트’로 알려진 수직 모듈성 내에서 독립적으로 개발할 수 있습니다.

고유한 마이크로서비스 아키텍처의 문제 발생

이러한 진화는 데브옵스(DevOps)와 같은 다른 모범 사례의 진화를 가속화했으며 조직 수준에서 민첩성과 더 빠른 출시 시간을 제공했습니다. 각 개발 팀은 해당 도메인에서 하나 이상의 마이크로서비스를 소유하고 설계, 코딩, 프로덕션 배포, 포스트 프로덕션 지원 및 유지 관리의 전체 프로세스를 책임집니다. 그러나 이전 아키텍처 모델과 유사하게 마이크로서비스 접근 방식은 고유한 문제에 봉착했습니다.

상향식 마이크로서비스로 설계되지 않은 레거시 애플리케이션이 마이크로서비스 아키텍처로 강제 전환되면서 잠식되기 시작하여 모놀리스 지옥으로 알려진 안티 패턴이 발생했습니다. 다른 시도는 모놀리식 애플리케이션을 여러 마이크로서비스로 인위적으로 나누려고 시도했지만 이러한 결과로 생성된 마이크로서비스는 기능면에서 분리되지 않고 여전히 동일한 모놀리식 애플리케이션에서 분리된 다른 마이크로서비스에 크게 의존하는 데, ‘마이크로리스(microliths)’ 라고 하는 안티 패턴으로 불러집니다. 모놀리스와 마이크로서비스는 두 가지 다른 패턴이며 마이크로리스가 항상 모놀리스 지옥을 대체하는 것은 아닙니다. 주의하지 않으면 밀접하게 결합되고 뒤섞인 마이크로서비스를 만들 수 있습니다. 애플리케이션 기능의 비즈니스 및 확장성 요구 사항에 따라 올바른 선택은 다 다릅니다.

마이크로서비스 폭발의 또 다른 원치 않는 부작용은 소위 ‘데스 스타(Death Star)’ 안티 패턴입니다. 서비스 상호 작용 및 인증 및 권한 부여와 같은 서비스 간 보안 측면에서 거버넌스 모델 없이 마이크로서비스가 확산되면 모든 서비스가 기꺼이 다른 서비스를 호출할 수 있는 상황이 종종 발생합니다. 또한 이러한 서비스 호출을 적절히 조정하지 않고 서로 다른 클라이언트 애플리케이션에서 얼마나 많은 서비스를 사용하고 있는지 모니터링 하는 것도 문제가 됩니다. 한편, 넷플릭스 및 트위터와 같은 조직이 이 악몽 같은 시나리오에 직면하고 ‘데스 바이 데스 스타’ 문제에 대처하기 위해 새로운 패턴을 제시해야 하는 방법을 보여 줍니다.

이러한 예는 빅테크 서비스 업체에게만 발생하는 극단적인 경우처럼 보일 수 있지만, 클라우드 안티 패턴의 기하급수적인 파괴력을 가집니다. 그러므로, IT 서비스 업계는 이전에 세계에서 본 것보다 훨씬 더 큰 무기를 작동하는 방법을 배워야 합니다. 서비스 메시, 사이드카, 서비스 오케스트레이션 및 컨테이너와 같은 새로운 아키텍처 패턴은 클라우드 지원 세계에서 잘못된 관행에 대한 효과적인 방어 메커니즘이 될 수 있습니다. 조직은 이러한 패턴들을 이해하고 더 빨리 채택을 추진해야 합니다.

마이크로서비스 아키텍처의 문제를 보완하는 설계 패턴과 트렌드

요약해서 말하자면, 마이크로서비스 아키텍처의 문제를 보완해 줄 수 있는 설계 패턴들은 서비스 메시, 서버리스, 컨테이너 기술들을 활용하는 것입니다.

첫째, 클라우드 플랫폼, 특히 쿠버네티스와 같은 컨테이너 오케스트레이션 기술의 등장으로 ‘서비스 메시(Service Mesh)’가 주목받고 있습니다. 서비스 메시는 트래픽 제어, 서비스 검색, 로드 밸런싱, 탄력성, 관찰 가능성, 보안 등과 같은 추가 기능을 추가하는 애플리케이션 서비스 간의 브릿지입니다. 이를 통해 애플리케이션이 애플리케이션 수준 라이브러리에서 이러한 기능을 오프로드하고 개발자가 비즈니스 논리에 집중할 수 있게 합니다. 또한 istio와 같은 일부 서비스 메시 기술은 기존의 시나리오 테스트 방식으로는 모든 장애를 예측할 수 없어 다양한 오류를 시뮬레이션 해 주는 카오스 엔지니어링의 ‘혼돈 주입(chaos injection)’과 같은 기능도 지원하므로 개발자는 애플리케이션과 잠재적으로 상호 의존적인 수십 개의 마이크로서비스의 탄력성과 견고성을 테스트할 수 있습니다. 따라서, 서비스 메시는 서비스로서의 플랫폼과 서비스로의 컨테이너 위에 잘 맞으며 클라우드 플랫폼 서비스를 통해 클라우드 채택 경험을 향상시킵니다.

둘째, 지난 2014년 AWS에서 처음으로 선 보인 MSA의 문제를 보완해 줄 수 있는 설계 패턴은 ‘서버리스 컴퓨팅(serverless computing)’ 이라고도 하는 서버리스 아키텍처입니다. 서버리스는 애플리케이션 개발자로부터 서버 인프라를 완전히 추상화한다는 점에서 서비스로서의 플랫폼 모델보다 한 걸음 더 나아갔습니다. 서버리스에서는 비즈니스 서비스를 기능으로 작성하고 해당 기능을 클라우드 인프라에 배포하는 방식입니다. 서버리스 기술의 몇 가지 예로는 아마존 람다, 스프링 클라우드 함수, 구글 클라우드 함수 및 애저 함수 등이 있습니다.

셋째, 컨테이너 기술과 같은 보완 설계 패턴은 비즈니스 서비스의 진정한 격리와 개별 서비스의 확장성을 제공하는 마이크로서버 환경에서 서비스와 앱을 배포하는 데 도움이 되는 마이크로 서비스와 거의 같은 시기에 나타났습니다. 도커, 컨테이너드 및 쿠버네티스와 같은 컨테이너 기술은 마이크로서비스 개발을 매우 잘 보완할 수 있습니다. 오늘날 마이크로서비스나 컨테이너들 중 하나를 언급하지 않고는 다른 하나를 언급할 수 없습니다.

새로운 앱 설계 중심의 Dapr와 오픈 애플리케이션 모델

최근 앱 설계 추세로 볼 때, 마이크로서비스의 발전으로 클라우드 기반의 분산 시스템을 구축하는 것이 더 쉬워졌습니다. 그러나 약방의 감초처럼 마이크로서비스를 모든 문제를 해결하기 위한 시도로 마이크로서비스의 남용에 대한 일부 반발을 계속 보고되고 있습니다. 따라서, 분산 시스템 또는 모듈식 모놀리식 구축과 관련된 일부 추세는 모두 높은 응집력 및 낮은 결합과 같은 기본 아키텍처 원칙으로 돌아갑니다.

도메인 주도 설계는 이미 많이 알려져 지금은 후기 다수 추세로 간주되지만, 컨텍스트 매핑 및 시스템 내 경계 식별에 대한 좋은 지침을 찾는 설계자들에 의해 계속 강조되고 있습니다. 마찬가지로 컨텍스트, 컨테이너, 컴포넌트 및 코드와 같은 C4 모델은 시스템을 이해하는 데 도움이 되는 계층적 아키텍처 다이어그램 집합을 만드는 데 매우 유용할 수 있습니다. 또한 개발자들에게 이벤트 기반의 탄력적인 분산 애플리케이션을 구축할 수 있도록 지원하는 Dapr는 온프레미스, 클라우드 또는 엣지 장치에 관계없이 마이크로서비스 구축과 관련된 문제를 해결하고 코드 플랫폼에 구애받지 않는 상태를 유지하도록 도와 줍니다. Dapr과 함께 오픈 애플리케이션 모델(OAM)은 모두 2019년 말에 마이크로소프트에서 도입했습니다. 따라서, 오픈 애플리케이션 모델(OAM)은 클라우드 네이티브 애플리케이션을 정의하기 위한 사양으로 컨테이너나 오케스트레이터가 아닌 애플리케이션에 중점을 두는 것이 차이점입니다.

마찬가지로 Dapr은 클라우드 네이티브 개발을 더 쉽게 만들기 위한 플러그인 가능한 구성 요소가 있는 프레임워크입니다. 물론 마이크로소프트가 생성에 참여했지만 둘 다 오픈 소스 프로젝트이고, 모든 클라우드 제공업체에서 작동하며 Dapr은 CNCF 프로젝트가 될 수 있습니다. Dapr과 오픈 애플리케이션 모델(OAM)은 모두 아직 주요 클라우드 네이티브 애플리케이션 채택을 보지 못했기 때문에 계속 주시해야 할 혁신 추세입니다.

끝으로 소프트웨어 아키텍처와 데이터 아키텍처 간의 교차점에서 혁신적인 트렌드는 ‘데이터 메시(Data Mesh)’입니다. 데이터 메시는 API 게이트웨이와 다소 비슷하지만 데이터 측면에 중점을 둔 데이터 게이트웨이로 연결됩니다. 마이크로서비스가 다중 언어 지속성 계층으로 이어짐에 따라 API 게이트웨이는 추상화, 보안, 확장, 연합 및 계약 기반 개발 기능을 제공합니다.

마치며

시간이 지남에 따라 소프트웨어 아키텍처 및 코드에서 개발될 수 있는 안티 패턴을 주시하는 것이 무엇보다도 중요합니다. 안티 패턴은 기술적 부채를 유발할 뿐만 아니라 더 중요하게는 해당 도메인 전문가를 사내 조직에서 몰아내기 때문이라고 서론에서 언급했었습니다. 따라서, 사내 조직은 아키텍처 편차나 안티 패턴에 신경 쓰지 않는 사람들만 남을 수 있음을 강조했습니다.

앞써 클라우드 소프트웨어 설계 및 디자인 트렌드를 보듯이, 성급한 마이크로서비스 채택의 일부로 나타날 수 있는 안정화 격차와 안티 패턴에 초점을 맞추어야 합니다. 또한 조직의 팀 구조, 비즈니스 도메인 및 팀의 기술과 같은 특정 요소에 따라 마이크로서비스로 구현해야 하는 애플리케이션과 모놀리식 솔루션으로 유지해야 하는 애플리케이션이 결정된다. 몇몇 서비스 회사들은 마이크로서비스에서 모놀리식 아키텍처로 돌아간 경우도 있습니다. 이러한 모든 아키텍처 모델, 안티 패턴 형태의 안정화 격차, 진화된 디자인 패턴 및 모범 사례로부터 우리가 배운 것은 기술 부채를 가속화하는 새로운 패러다임의 모범 사례를 알지 못하는 초기 단계를 포함하여 아키텍처 진화의 단계로 먼저 실험해 보는 것입니다. 클라우드 소프트웨어 업계가 안정화 격차를 해결하기 위해 새로운 디자인 패턴을 개발함에 따라 팀은 아키텍처에 새로운 표준과 패턴을 채택합니다.

그러므로, IT 리더는 끊임없이 발전하고 최적화하는 기술 기반에서 실행되는 안정적인 비즈니스 애플리케이션을 제공하는 동시에 끊임없이 성장하는 기술의 급속한 변화로부터 투자를 보호해야 합니다. 전 세계의 IT 경영진은 이러한 문제를 점점 더 자주 해결해 왔습니다. 또한 기술의 발전을 수용해야 하지만 비즈니스를 지원하는 앱의 지속적인 불안정성을 희생해서는 안 됩니다. 규율된 체계적인 아키텍처가 바로 이를 제공할 수 있어야 합니다. 새로운 디자인 패턴이 발전하여 새로운 호스팅 모델에 의해 열린 안정화 격차를 해결했기 때문에 위에서 논의된 패턴을 비즈니스 앱을 변동성으로부터 보호하면서 급속한 기술 발전을 선호하는 전략으로 고려하기 바랍니다.