디지털 시대의 애플리케이션 개발을 위한 네 가지 아키텍처 선택지

3계층 애플리케이션 아키텍처는 프레젠테이션 계층, 애플리케이션 계층, 데이터베이스 계층으로 구성된 전형적인 클라이언트 서버 아키텍처입니다.

이 아키텍처에는 사용자 인터페이스, 비즈니스 및 데이터 액세스 로직, 데이터 액세스 기능이 포함됩니다. 많은 엔터프라이즈 애플리케이션이 이 단순한 3계층 아키텍처로 만들어졌습니다.

간단히 말해, 3계층 애플리케이션 모델은 현재 시대에 맞지 않습니다. 이 모델은 퍼블릭 클라우드와 모바일 애플리케이션이 확산되기 이전의 애플리케이션 개발 환경을 기준으로 설계되었기 때문에 클라우드 환경에 적응하는 데 어려움을 겪습니다.

시간이 지나면 애플리케이션이 너무 크고 복잡해져 자주 변경하기가 어려워집니다.또한 최소 세 개의 하드웨어 및 소프트웨어 계층을 관리해야 하므로 비즈니스적으로 비효율적입니다.

3계층 애플리케이션 모델은 흔히 모놀리식 아키텍처라고도 합니다. 오늘날에는 다양한 새로운 아키텍처 모델이 있으며, 아래에서는 클라우드 시대에 사용할 수 있는 몇 가지 모델을 살펴보겠습니다.

클라우드 모델에서는 서비스와 데이터의 집합으로 설계된 복잡한 애플리케이션이 애플리케이션 본체와 완전히 분리됩니다.마이크로서비스는 애플리케이션을 여러 서비스의 집합으로 구성하는 아키텍처 스타일입니다. 각 서비스는 서로 다른 프로그래밍 언어로 작성될 수 있으며 개별적으로 테스트할 수 있습니다. 이 서비스들은 독립적으로 배포 가능하며 비즈니스 역량을 중심으로 구성됩니다.

마이크로서비스 아키텍처로 개발된 전자상거래 애플리케이션을 예로 들어보겠습니다. 각 마이크로서비스는 장바구니, 검색, 고객 리뷰와 같은 단일 비즈니스 기능에 집중할 수 있습니다. 이들은 서로 다른 프로그래밍 언어로 작성되고, 다른 인프라에 배포되며, 서로 다른 팀에서 관리할 수 있습니다.

각 서비스는 경량 프로토콜을 사용해 다른 서비스와 통신합니다. 3계층의 경우 MVC(모델 뷰 컨트롤러) 프레임워크가 익숙합니다. Sidecar, Ambassador, Adapter는 마이크로서비스 아키텍처를 지원하는 프레임워크의 예입니다.

마이크로서비스 아키텍처 vs 단일체 아키텍처

모놀리식 아키텍처에서는 모든 구성 요소가 단일 모듈로 함께 존재하며, 대부분 하나의 팀에서 관리합니다. 업데이트를 하려면 전체 애플리케이션을 다시 배포해야 하므로 대규모 복잡한 애플리케이션의 변경 속도가 느려집니다.작은 규모의 애플리케이션에서는 단일체 아키텍처가 종종 최선의 해결책이 됩니다.

마이크로서비스, 컨테이너, Kubernetes

마이크로서비스 기반 애플리케이션 아키텍처를 만들고 실행하는 가장 좋은 선택지 중 하나는 컨테이너를 사용하는 것입니다. 컨테이너는 애플리케이션을 위한 경량 가상화 실행 환경을 캡슐화하며, 개발자 데스크톱에서 프로덕션 배포까지 일관되게 이동할 수 있도록 합니다. 컨테이너는 대부분의 운영 체제에서 가상 머신 또는 물리 머신 위에서 실행할 수 있습니다. 컨테이너는 일관된 소프트웨어 환경을 제공하며, 애플리케이션의 모든 의존성을 배포 가능한 단위로 캡슐화할 수 있습니다.컨테이너는 노트북, Bare Metal Server, 퍼블릭 클라우드 어디에서든 실행할 수 있습니다.

많은 조직이 컨테이너 관리를 위해 Kubernetes를 사용하고 무중단 운영을 보장합니다. Kubernetes는 여러 호스트에서 컨테이너 오케스트레이션을 제공하며 컨테이너 라이프사이클 관리를 위해 사용됩니다. Kubernetes를 사용하면 배포 자동화, 애플리케이션 자동 확장, 빠른 빌드와 빠른 배포가 가능합니다.

Kubernetes에 대해 더 자세히 알아보려면 “Kubernetes 설명” 영상을 참고하세요.

Red Hat OpenShift는 가장 널리 사용되는 대표적인 하이브리드 클라우드 엔터프라이즈 컨테이너 플랫폼 중 하나입니다.많은 퍼블릭 클라우드 공급자가 CaaS(서비스형 컨테이너)를 제공합니다. 사용할 수 있는 다른 Kubernetes 엔진으로는 IBM® Cloud Kubernetes Service, 오픈 소스 Kubernetes, AWS(EKS, ECS, Fargate), Google GKS, Azure AKS 등이 있습니다.

일반적으로 각 마이크로서비스는 서로 다른 소규모 팀에 의해 구축되며, 이들은 프로그래밍 언어와 배포 일정을 선택합니다. Istio 와 같은 서비스 메시는 기업에서 마이크로서비스와 관리 간의 통신을 관리하는 데 사용됩니다. 서비스 메시에서는 요청이 마이크로서비스 간의 프록시(예: Sidecar)를 통해 라우팅됩니다.

클라우드 네이티브 아키텍처는 클라우드에 배포하려는 애플리케이션을 위해 특별히 설계되었으며, 마이크로서비스는 중요한 부분입니다.

클라우드 네이티브는 클라우드 컴퓨팅 제공 모델의 장점을 활용하는 애플리케이션 구축 및 실행 방식입니다. 클라우드 네이티브는 컨테이너 기반 환경을 설명하는 데 사용되는 용어로, 애플리케이션이 어디에 만들어지고 배포되는지가 아니라 어떻게 만들어지고 배포되는지에 관한 것입니다.

클라우드 네이티브 기술을 사용하면 퍼블릭, 프라이빗, 하이브리드 클라우드에서 애플리케이션을 실행할 수 있습니다. 클라우드 네이티브 개발은 애플리케이션을 신속하게 시장에 출시하는 데 필수적입니다. 클라우드 네이티브 개발은 사람, 프로세스, 기술이 클라우드에 적합한 애플리케이션을 빌드, 배포, 관리하는 데 도움이 됩니다.

클라우드 네이티브 아키텍처 모델은 DevOps, CI(지속적 통합), CD(지속적 업데이트), 마이크로서비스 및 컨테이너를 사용합니다. 대부분의 기업은 확장 가능하고 강력한 클라우드 네이티브 애플리케이션을 설계하기 위해 12가지 요소 방법론을 사용합니다.

클라우드에서 애플리케이션은 여러 노드에서 동시에 실행되고, 구성/세션 상태를 공유하고, 중앙 집중식 로깅 메커니즘을 갖추고, DevOps 및 CI/CD 프로세스를 사용하여 배포할 수 있어야 합니다. 많은 클라우드 공급업체가 클라우드 네이티브 개발에 대한 가이드라인을 제공합니다. Amazon Web Services(AWS)는 잘 설계된 프레임워크를 보유하고 있으며, Google은 클라우드 네이티브 애플리케이션을 구축하는 방법에 대한 다양한 가이드를 제공하고, Microsoft Azure는 클라우드 패턴 가이드를 보유하고 있습니다.

일반적으로 클라우드 네이티브 애플리케이션은 본질적으로 상태 비저장입니다. 서비스는 REST 기반 프로토콜이나 메시징을 사용하여 서로 통신합니다. API Gateway, Container Registry, 메시지 지향 미들웨어(MOM: 게시/구독하기 또는 요청/응답), 서비스 메시, 오케스트레이션은 클라우드 네이티브 아키텍처의 일부가 될 수 있습니다.

이벤트 기반 아키텍처(EDA)는 이벤트에 대한 응답으로 실행되는 분리된 시스템을 기반으로 합니다. 이벤트 기반 아키텍처는 이벤트를 사용하여 분리된 서비스 간에 트리거하고 통신합니다. EDA는 오랫동안 존재해 왔지만, 이제는 클라우드에서 더 중요한 역할을 하고 있습니다.

새로운 기능은 무엇인가요? 올바르게 사용하면 민첩성이 크게 향상되고, 비용이 절감되며, 운영상의 이점도 얻을 수 있습니다. 분산 서버리스 EDA는 REST API 또는 이벤트 트리거에 응답하여 자동으로 확장되는 함수로 알려진 코드를 실행할 수 있습니다.

서버리스 모델에서는 서버 관리가 필요하지 않습니다. 서버리스 모델은 빠르게 확장 가능한 것으로서 빠른 업데이트와 배포가 가능하며 상태 저장소가 없습니다.

현재 다양한 클라우드 공급업체에서 제공하는 클라우드 서버리스 서비스는 다음과 같습니다.

서버리스 유형

• 서비스형 기능(FaaS): 기능 조각을 클라우드에 업로드하고 이러한 조각이 독립적으로 실행되도록 합니다.
• 서비스형 백엔드(BaaS): 애플리케이션 관리, 데이터베이스 관리, 클라우드 스토리지와 같은 타사의 서비스를 활용합니다.
• 모바일 백엔드 서비스(MBaaS): 모바일 애플리케이션을 위한 기능입니다.

클라우드 환경에서 모놀리식 애플리케이션이 잘 작동하도록 하려면 어떻게 해야 할까요? 클라우드 기반 아키텍처는 최신 웹 애플리케이션(정적/동적 웹사이트) 구축, 웹 애플리케이션 배포, 데이터베이스 연결, 사용자 행동 분석에 가장 적합합니다.

기존의 클라우드 기반 애플리케이션 아키텍처에는 로드 밸런서, 웹 서버, 애플리케이션 서버 및 데이터베이스가 포함됩니다. 리소스 탄력성, 소프트웨어 정의 네트워킹, 자동 프로비저닝, 고가용성, 확장성과 같은 클라우드 기능의 이점을 누릴 수 있습니다.

이러한 유형의 아키텍처는 조직이 서버 유지 관리에 대해 걱정할 필요가 없는 경우에 이상적입니다. 서버리스 함수는 PHP, Java, .NET, Node.js, Python, Ruby, Docker, Go 등 다양한 프로그래밍 언어를 지원합니다.

API Gateway는 개발자가 안전한 API를 쉽게 만들고 게시할 수 있도록 해주는 중요한 서비스입니다. API는 애플리케이션이 데이터와 비즈니스 로직에 접근하는 프런트 도어 역할을 합니다. 또한 권한 부여 및 액세스 제어도 처리합니다. 개발자는 API Gateway를 사용하여 다양한 API 호출에 대해 다양한 서버리스 함수를 호출합니다.

아키텍처 모델을 선택할 때 내리는 결정은 프로젝트의 성공과 실패에 영향을 미칠 수 있습니다. 애플리케이션과 비기능적 요구 사항에 따라 선택해야 합니다. 예를 들어, 몇 마일만 이동하려는 경우 비행기를 선택하지 않습니다.

앱 프로젝트에 맞는 아키텍처를 선택하기 전에 다음 사항을 고려하세요.

• 모놀리식 우선주의인가요, 아니면 마이크로서비스 우선주의인가요? (간단한 애플리케이션 요구 사항이 있는 소규모 프로젝트의 경우 모놀리식이 올바른 선택일 수 있습니다.)
• 팀은 마이크로서비스를 활용할 준비가 되어 있나요?
• 팀에 기존 클라우드 기반 DevOps 및 CI/CD 프로세스가 있나요?
• 호스팅 모델은 무엇인가요? 비공개, 공개, 하이브리드?
• 애플리케이션 아키텍처는 프로젝트에 어떤 영향을 미치나요?
• 여러 아키텍처 모델의 조합이 적합한가요?
• 애플리케이션에 대한 지속성과 세션이 필요하신가요?

웹 애플리케이션 아키텍처는 디지털 비즈니스 요구 사항과 변화하는 IT 인프라 환경을 충족하기 위해 끊임없이 발전하고 있습니다. 인공 지능, 분석, 자동화, 고급 로봇공학, 엣지 컴퓨팅, 블록체인, 사물인터넷(IoT), API와 같은 기술은 많은 산업 분야에서 가능성의 한계를 재정의하고 있습니다. 인프라, 애플리케이션, 데이터 크기가 점점 더 복잡해지면서 새로운 아키텍처 접근 방식이 필요합니다. 대부분의 기업은 하나 이상의 클라우드 제공업체를 사용하여 멀티클라우드 접근 방식을 채택하고 있습니다. 기업들은 프라이빗, 퍼블릭 또는 SaaS, PaaS 또는 IaaS 모델의 하이브리드를 사용하여 클라우드 서비스를 소비하고 있습니다.

초기에는 애플리케이션 배포가 어려운 과정이었고 정상적인 업무 시간 동안에는 수행할 수 없었습니다. 그러나 DevOps와 CI/CD(지속적인 통합 및 지속적인 배포)를 포함하여 다양한 배포 방법(예: 블루-그린 및 카나리아 배포)을 사용하면 이제 애플리케이션 중단 없이 언제든지 배포할 수 있습니다.

모놀리식 아키텍처는 여전히 많은 애플리케이션에 유효하지만 민첩성과 출시 기간을 단축하려면 디지털 사용 사례에 적합한 아키텍처를 사용해야 합니다. 간단한 애플리케이션의 경우 전통적인 모놀리식 접근 방식을 선택하는 것이 좋습니다. 클라우드 네이티브 또는 마이크로서비스 패턴은 복잡성이 있는 애플리케이션에 적합합니다. 여러 언어와 배포 일정을 사용하는 숙련된 팀이 여러 개 있는 경우 마이크로 서비스 아키텍처를 사용하는 것이 좋습니다. 참조를 위해 기존 3/N 계층 애플리케이션과 클라우드 기반 아키텍처 모델 간의 비교는 아래에 나와 있습니다.

시작하려면 IBMid에 가입하고 IBM Cloud 계정을 만드세요.