개요
애플리케이션 아키텍처는 애플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술을 설명합니다. 아키텍처는 애플리케이션을 구축할 때 따라야 할 로드맵과 모범 사례를 제공하여 체계적으로 구성된 애플리케이션을 완성할 수 있게 해줍니다.
소프트웨어 설계 패턴은 애플리케이션을 구축할 때 도움이 됩니다. 패턴은 문제에 대한 반복 가능한 솔루션을 설명합니다.
패턴을 서로 연결해 보다 일반적인 애플리케이션 아키텍처를 만들 수 있습니다. 아키텍처를 직접 완전히 구축하는 대신, 기존 설계 패턴을 사용할 수 있으며 이를 통해 모든 것을 의도한 대로 작동하게 할 수 있습니다.
애플리케이션 아키텍처에는 프런트엔드와 백엔드 서비스가 모두 있습니다. 프런트 엔드 개발이 애플리케이션에서 제공하는 사용자 경험에 초점을 맞춘다면, 백엔드 개발은 데이터 및 서비스, 애플리케이션을 작동하게 하는 기타 기존 시스템에 대한 액세스를 제공하는 데 초점을 맞추고 있습니다.
아키텍처가 애플리케이션 구축의 시작점 또는 로드맵 역할을 하지만, 아키텍처에서 캡처하지 않은 부분에 대해서도 구현 여부를 결정해야 합니다. 예를 들면, 첫 단계에서는 애플리케이션을 작성할 프로그래밍 언어를 선택합니다.
소프트웨어 개발에 사용할 수 있는 프로그래밍 언어는 그 종류가 다양합니다. Swift는 모바일 애플리케이션에, JavaScript는 프런트 엔드 개발에 사용되는 것처럼 특정 유형의 애플리케이션을 구축할 때는 특정 언어를 사용해야 할 수 있습니다.
HTML 및 CSS와 함께 사용하는 JavaScript는 현재 웹 애플리케이션 개발에서 가장 널리 사용되는 프로그래밍 언어 중 하나입니다.
Ruby, Python, Swift, TypeScript, Java, PHP, SQL 역시 자주 사용됩니다. 애플리케이션을 구축할 때 사용하는 언어는 애플리케이션의 유형, 사용 가능한 개발 리소스, 요건에 따라 달라집니다.
전통적으로 애플리케이션은 모든 요소가 동일한 리소스와 메모리 공간을 공유하는 단일 코드 유닛으로 작성되었습니다. 이러한 아키텍처 스타일을 모놀리식이라고 부릅니다.
현대적인 애플리케이션 아키텍처는 마이크로서비스와 애플리케이션 프로그래밍 인터페이스(API)를 사용해 보다 탄력적으로 결합되어 서비스를 연결하고 클라우드 네이티브 애플리케이션의 기반을 제공합니다.
클라우드 네이티브 개발은 새로운 애플리케이션 구축 속도를 높이고 기존 애플리케이션을 최적화하며 프라이빗, 퍼블릭, 하이브리드 클라우드 전반에서 일관된 개발과 자동화된 관리 경험을 제공합니다.
애플리케이션 아키텍처 선택
새로운 애플리케이션에 사용할 애플리케이션 아키텍처를 정하거나 기존 아키텍처를 평가하려면 먼저 전략적 목표부터 결정해야 합니다.
그래야 아키텍처를 먼저 선택하고 애플리케이션을 그 구조에 끼워 맞추는 대신, 목표를 지원할 아키텍처를 설계할 수 있기 때문입니다.
고객 또는 운영 요건을 충족하기 위해 얼마나 자주 업데이트를 릴리스할 것인지, 비즈니스 목표 또는 개발 요구 사항에 필요한 기능은 무엇인지 생각해보세요.
고객에게 새로운 서비스와 기능을 신속하게 제공하는 역량은 기업의 핵심적인 경쟁력 차별화 요소 중 하나입니다. 개발 속도가 빨라야 새로운 기능을 보다 자주 출시하고, 취약점이 발견되자마자 업데이트를 롤아웃할 수 있습니다.
애플리케이션 아키텍처에는 다양한 유형이 있지만 서비스 간 관계를 기준으로 오늘날 가장 널리 사용되는 유형은 모놀리식 및 N-티어 아키텍처(긴밀한 결합), 마이크로서비스(분리됨), 이벤트 기반 아키텍처 및 서비스 지향 아키텍처(탄력적 결합)입니다.
Red Hat 리소스
계층화 또는 N-티어 아키텍처
계층화 또는 N-티어 아키텍처는 온프레미스 및 엔터프라이즈 애플리케이션을 구축할 때 흔히 사용하는 전통적인 아키텍처로, 레거시 애플리케이션과 연관된 경우가 많습니다.
계층화된 아키텍처는 주로 3개 티어 또는 레이어로 구성되지만 이보다 많을 수 있으며, 각각 책임이 지정된 티어가 애플리케이션을 구성합니다.
레이어는 종속성을 관리하고 논리적 기능을 수행하도록 지원합니다. 계층화된 아키텍처에서 레이어는 수평으로 배열되기 때문에 바로 아래 있는 레이어만 호출할 수 있습니다.
하나의 레이어는 바로 아래에 있는 레이어만 호출하거나, 아래에 있는 임의의 레이어를 호출할 수 있습니다.
모놀리식 아키텍처
레거시 시스템과 연관된 또 다른 아키텍처 유형인 모놀리스는 하나의 애플리케이션 내 모든 기능을 포함한 단일 애플리케이션 스택입니다. 그래서 서비스 사이 상호작용과 개발 및 제공 방식 모두가 긴밀하게 연결되어 있습니다.
모놀리식 애플리케이션의 단일 측면을 업데이트하거나 확장하는 경우 전체 애플리케이션은 물론, 기반이 되는 인프라에도 영향을 미칩니다.
애플리케이션 코드에서 한 부분만 변경하더라도 전체 애플리케이션을 다시 릴리스해야 한다는 의미입니다. 이로 인해 업데이트와 새로운 릴리스는 일반적으로 1년에 1~2번 정도밖에 이루어지지 않으며, 이때에도 새로운 기능이 도입되기보다는 일반적인 유지관리만 진행되는 경우가 많습니다.
이와는 대조적으로 현대적인 아키텍처는 기능 또는 비즈니스 기능별로 서비스를 분리하여 민첩성을 강화합니다.
마이크로서비스 아키텍처
마이크로서비스란 소프트웨어를 구축하기 위한 아키텍처이자 하나의 접근 방식으로, 애플리케이션을 상호 독립적인 최소 구성 요소로 분할합니다. 이러한 각각의 구성 요소 또는 프로세스가 마이크로서비스입니다.
마이크로서비스는 탄력적으로 결합되어 배포되므로 서로 영향을 미치지 않습니다. 이러한 방식은 동적인 확장성과 결함 허용 측면 모두에서 장점이 있습니다. 무거운 인프라 없이도 개별 서비스를 필요에 따라 확장할 수 있으며, 다른 서비스에 영향을 미치지 않고 페일오버가 가능하기 때문입니다.
마이크로서비스 아키텍처를 사용하는 궁극적인 목표는 우수한 품질의 소프트웨어를 더욱 빠르게 제공하는 것입니다. 또한, 동시에 여러 마이크로서비스를 개발하는 것도 가능합니다. 서비스가 개별적으로 배포되기 때문에 변경 사항이 있더라도 전체 애플리케이션을 다시 빌드하거나 배포할 필요도 없습니다.
따라서 전체 애플리케이션을 업데이트하는 대신 더 많은 개발자가 동시에 개별 서비스 작업을 수행할 수 있게 되므로 궁극적으로 개발에 드는 시간을 절감하고 새로운 기능을 더욱 자주 출시할 수 있습니다.
컨테이너화된 마이크로서비스는 API 및 DevOps팀과 함께 클라우드 네이티브 애플리케이션의 기반입니다.
이벤트 기반 아키텍처
이벤트 기반 시스템에서 이벤트 캡처, 커뮤니케이션, 처리 및 지속성은 솔루션의 핵심 구조입니다. 이는 전통적인 요청 기반 모델과는 다릅니다.
이벤트란 시스템 하드웨어 또는 소프트웨어 상태의 변화 또는 중대 사건의 발생을 의미합니다. 이벤트 소스는 내부 또는 외부 입력일 수 있습니다.
이벤트 기반 아키텍처는 최소한의 결합을 지원하므로 현대적인 분산형 애플리케이션 아키텍처에 적합한 방법입니다.
이벤트 기반 아키텍처는 이벤트 생성자와 이벤트 소비자로 구성되어 있습니다. 이벤트 생성자는 이벤트를 감지하며 메시지로 해당 이벤트를 나타냅니다. 생성자는 이벤트 소비자 또는 이벤트 결과를 알지 못합니다.
이벤트가 감지된 후에는 이벤트 처리 플랫폼이 이벤트를 비동기식으로 처리하는 이벤트 채널을 통해 해당 이벤트 생성자에서 이벤트 소비자로 전송됩니다.
이벤트 기반 아키텍처는 게시/구독(pub/sub) 모델 또는 이벤트 스트림 모델을 기반으로 할 수 있습니다.
게시/구독 모델은 이벤트 스트림에 대한 서브스크립션을 기준으로 합니다. 이 모델을 사용하면 이벤트 발생 후 또는 게시 후에 알림을 받아야 하는 구독자에게 이벤트가 전송됩니다.
이는 이벤트 소비자가 이벤트 스트림을 구독하지 않는 이벤트 스트리밍 모델과는 다릅니다. 그 대신 스트림의 모든 부분에서 읽기가 가능하며 언제든지 스트림에 참여할 수 있습니다.
이벤트가 사물 인터넷(IoT) 기기, 애플리케이션 및 네트워크와 같은 이벤트 소스에서 발생하는 경우 캡처되므로 이벤트 생성자 및 이벤트 소비자가 실시간으로 상태 및 응답 정보를 공유할 수 있습니다.
서비스 지향 아키텍처
서비스 지향 아키텍처(Service-Oriented Architecture, SOA)는 체계적으로 구축된 소프트웨어 설계 스타일로, 마이크로서비스 아키텍처와 유사합니다.
SOA는 애플리케이션을 별개의 재사용 가능한 서비스 단위로 분할하며 이 서비스는 엔터프라이즈 서비스 버스(Enterprise Service Bus, ESB)를 통해 통신합니다.
이러한 아키텍처에서는 특정 비즈니스 프로세스를 기반으로 구성된 개별 서비스가 통신 프로토콜(SOAP, ActiveMQ, Apache Thrift 등)을 준수하며 ESB의 플랫폼을 통해 공유됩니다. 이처럼 ESB를 통해 통합된 이러한 일련의 서비스는 프론트 엔드 애플리케이션에서 사용되어 비즈니스 또는 고객에게 가치를 제공합니다.
Red Hat의 애플리케이션 개발 지원 방식
Red Hat의 솔루션은 모놀리식 애플리케이션을 마이크로서비스로 분리하고, 관리하고, 오케스트레이션하는 것은 물론 생성된 데이터까지 처리하여 비즈니스 민첩성을 개선하므로 팀이 신속하게 고객에게 우수한 솔루션을 제공할 수 있습니다.
신규 비즈니스 애플리케이션 구축 시 향후 상황을 염두에 두어, 민첩하면서도 손쉽게 확장 가능한 클라우드 네이티브 애플리케이션을 구축하고 이를 비즈니스의 모든 부분과 통합할 수 있습니다.
이 웨비나 시리즈를 통해 Red Hat® OpenShift®에서 엔터프라이즈급 데이터 플랫폼을 통해 애플리케이션을 구축하고, 실행하고, 배포하고, 현대화하는 방법에 대한 전문가의 관점을 확인할 수 있습니다.
마이크로서비스의 이점을 얻기 위해 기존 시스템을 전체적으로 정비할 필요는 없습니다. 오픈소스, 오픈 표준, 수년간의 경험을 바탕으로 Red Hat은 고객에게 적합한 최적의 마이크로서비스 기반 솔루션을 찾아드립니다.
Red Hat® Enterprise Linux® 및 Red Hat OpenShift, Red Hat Application Services를 포함하는 오픈소스 포트폴리오를 통해 Red Hat은 급변하는 소프트웨어 중심 시장에서 경쟁하기 위해 혁신해야 하는 기업들과 협력할 수 있는 독보적인 입지를 확보하고 있습니다.
레드햇 공식 블로그
레드햇 공식 블로그에서 고객, 파트너, 커뮤니티 에코시스템 등 현재 화제가 되는 최신 정보를 살펴 보세요.