메뉴

문서정보

목차

좀 더 체계적으로 클라우드를 공부하기 위해서 아키텍처 관련 내용들을 정리하기로 했다. 아키텍처 관련 내용들은 architecture 태그로 관리한다. 체계적으로 공부를 시작하는 이유는 AWS Solutions Architects의 준비하기 위함이다. 필드에서 경험쌓으면서 3년 정도 장기적으로 준비하려 한다.

Multi-tier 아키텍처

멀티티어(multitier) 아키텍처n-tier 아키텍처 혹은 멀티레이어드(multilayered)아키텍처라고 부르기도 한다. 애플리케이션을 여러 개의 계층으로 나눠서 개발을 하고 이들을 연결해서 하나의 통합된 서비스를 만드는 아키텍처다. 일반적으로 프리젠테이션, 애플리케이션, 데이터베이스 3개의 계층(tier)을 가진다. 이러한 아키텍처를 3 티어 아키텍처라고 부르며, 가장 널리 사용되는 아키텍처다. 각 계층은 서버/클라이언트아키텍처를 따른다. 결과적으로 서버/클라이언트 모델이 몇 개의 계층을 구성하는 아키텍처다.

멀티티어 아키텍처를 사용하는 이유는 유연하고 재활용 가능한 응용 프로그램 개발환경을 제공하기 때문이다. 응용 프로그램을 몇 개의 계층으로 분리함으로써, 개발자는 전체 응용 프로그램을 개발하는 대신 자신이 담당하는 특정 계층만을 개발 할 수 있게 된다.

  1. 프론트앤드 팀 : 데스크탑 PC, 안드로이드, iOS, 웹브라우저(HTML+Javascript)에서 실행되는 애플리케이션을 개발한다. 유저와 상호작용하기 위한 UI를 가지고 있다. 백앤드 팀과는 주로 기능 구현을 위한 API 명세의 요청과 토론방식의 커뮤니케이션이 이루어진다.
  2. 백앤드 팀 : 비지니스 로직을 실행한다. 여기에는 유저인증, 연결관리, 빌링, 구매, 정보출력(상품목록 같은)등의 기능이 포함된다. 중요 정보들은 데이터베이스에 저장을 해야하므로 데이터 팀과 커뮤니케이션해야 한다. 또한 효과적인 API 작성을 위해서 프론트앤드팀과도 커뮤니케이션 해야 한다. 중간에 위치하는 팀이다.
  3. 데이터 팀 : 데이터를 안전하고 효과적으로 쓰고, 읽을 수 있는 시스템을 구축한다. RDBMS, NO-SQL을 주요 툴로 사용한다.
으로 구성되는 프로젝트를 어렵지 않게 찾아볼 수 있는데, 멀티티어 아키텍처를 따르는 애플리케이션을 구성하기 위한 조직구성이라고 보면 되겠다.

Layer

객체지향 디자인을 지향하는 정보 시스템에서 멀티레이어 아키텍처는 일반적으로 아래의 4가지 요소로 구성된다. Domain-Driven Design의 경우 위의 레이어들에 대한 일반적인 내용을 다루지만, 도메인 계층에 촛점을 맞춘다.

만약 애플리케이션 아키텍처가 비지니스 레이어와 프리젠테이션 레이어(프리젠테이션 레이어가 비지니스 레이어의 일부가 되는 경우)가 명확히 구분되지 않는다면 two-multi-tier 구현이 된다.

애플리케이션 레이어는 비지니스 레이어의 하위 레이어로 간주되며, 일반적으로 비지니스 기능을 제공하는 API 형태로 추상화 한다. 실제로 애플리케이션/비지니스 레이어는 각 계층을 명확히 개발하기 위해서 세분화될 수 있다. 예를 들어 MVP(model-view-presenter) 패턴을 사용하는 경우 프리젠테이션 레이어는 사용자 인터페이스와 애플리케이션 레이어를 연결하기 위한 추가적인 레이어로 사용 할 수 있다.

3-티어(3-tier) 아키텍처

 멀티티어 아키텍처

3-티어 아키텍처는 유저 인터페이스(presentation), 비지니스 로직 그리고 스토리지(데이터베이스)가 독립적인 모듈로 개뱔,유지/보수 되는 서버/클라이언트 소프트웨어 아키텍처 패턴이다.

Three-tier 아키텍처는 잘 정의된 인터페이스를 이용해서 서로 통신을 한다. 각 티어는 서로에 대해서 독립적이기 때문에, 요구사항 변화에 따라서 필요한 티어만 업그레이드 혹은 교체 할 수 있다. 예를들어 사용자 UI에 대한 변경이 필요하다면, 프리젠테이션 영역만을 수정하면 된다. 요구사항에 따라서 비지니스로직의 변경이 필요한 경우도 있는데, 그렇다 하더라도 최소한의 변경으로 작업을 수행 할 수 있다.

일반적으로 유저 인터페이스는 데스크탑 PC나 워크스테이션에서 GUI(Graphical user interface)로 실행된다. 비지니스로직은 하나 이상으로 구성된 애플리케이션 서버에서 실행된다. 비지니스로직은 하나 이상의 분리된 기능 모듈들을 가질 수 있다. 비지니스로직의 핵심 역할을 데이터의 처리에 있다. 스토리지 티어에 있는 RDBMS로 부터 데이터를 읽어서 처리하고, 그 결과를 RDBMS 혹은 다른 파일형태로 스토리지에 저장한다. 때때로 비지니스로직이 다시 여러 개의 티어로 구성될 수 있는데, 이를 N-tier 아키텍처라 한다.

프리젠테이션 티어

애플리케이션의 최상위 레벨이다. 온라인 쇼핑 애플리케이션이라면, 프리젠테이션 티어는 상품검색, 상품정보, 구매, 장바구니와 같은 정보들을 화면에 표시한다. 상품검색, 물품구입등의 유저 액션이 발생하면 네트워크를 통해서 액션을 다른 티어에 전달하고 다시 그 결과를 화면에 표시한다. 간단히 말해서 웹 브라우저, 안드로이드/iOS 애플리케이션등, 유저가 직접 상호작용하는 소프트웨어들이다.

애플리케이션 티어

비지니스 로직, 로직티어, 미들티어라고 부르기도 한다. 프리젠테이션 계층에서 전달된 요청을 읽어서 세부적인 처리를 수행한다. 쇼핑카트라면
  1. 구매 아이템의 정보(가격, 품목, 상품이미지, 상품식별번호)를 얻는다.
  2. 전자장바구니(데이터베이스 혹은 REDIS 등으로 구현한)에 아이템을 넣고 뺀다.
  3. 아이템을 넣고 뺄때, 장바구니에 있는 아이템 갯수, 전체 비용등의 계산을 수행한다.
구현을 가지고 있을 것이다.

데이터 티어

데이터 티어는 데이터를 안정적/지속적으로(persistence)유지하기 위한 매커니즘을 제공한다. 이러한 매커니즘에는 데이터베이스 서버, 파일서버등이 포함된다. 또한 이들 매커니즘들은 데이터를 읽고, 쓰고, 관리하기 위한 기능들을 제공한다. 데이터 티어는 이들 기능을 애플리케이션 티어에 제공하는 일을 한다. 일반적으로 데이터베이스, 파일시스템등의 종속성을 피하기 위해서 API 형태로 기능을 개발해서 제공한다.

멀티티어 아키텍처 요약

AWS와 멀티티어 아키텍처

아키텍처 접근 방식의 변화

AWS에서 멀티티어 아키텍처를 확인해보기 전에 아키텍처 접근 방식이 어떻게 변화했는지 간단히 살펴보겠다.

 아키텍처 변화

이들 아키텍처는 어느 하나가 다른 하나를 대체하지는 않는다. 필요에 따라서 하나 이상의 아키텍처를 함께 사용한다. 그리고 하나의 아키텍처가 다른 아키텍처를 기반으로 할 수 있다. 예를 들어 MSA의 경우 멀티티어 아키텍처위에 구성 할 수 있다.

AWS에서의 멀티티어 아키텍처

멀티티어 애플리케이션은 수십년 이상 기본이 되는 아키텍쳐의 위상을 가지고 있다. 지금도 인터넷 서비스 개발에 가장 기본이 되는 아키텍처 패턴이다. EC2를 중심으로 하는 IaaS 애플리케이션 뿐만 아니라 Lambda, API Gateway, ECS로 구성되는 서버리스(Serverless) 애플리케이션에도 멀티티어 아키텍처가 적용된다.

AWS 같은 클라우드 환경에서 (MSA 등의 핫한 모델이 있음에도)여전히 멀티티어 아키텍처가 우선 고려되는 이유는 아래와 같다. SI 프로젝트가 멀티티어 아키텍처를 우선 선택하는 이유가 뭘까 ? "역할이 명확해서 조직의 세팅과 관리를 가시화 하기 쉽기" 때문이다. 세팅이 쉬운 것과 그걸을 잘 운용해서 프로젝트를 성공시키는 것은 다른 영역이긴 하지만, 변화가 큰 조직으로 프로젝트를 안정적으로 이끌어야 하는 SI 프로젝트에는 엄청난 장점이다. SI 프로젝트가 아니더라도, 아키텍처 자체가 일반 회사들이 채택하고 있는 조직구성과 닮아있기 때문에 적용하기가 수월하다.

모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다.

멀티티어 아키텍처 오버뷰

 멀티티어 아키텍처 오버뷰

전형적인 3 티어 아키텍처를 AWS에 통합해 보자. 고전적인(온-프레미스)아키텍처를 클라우드에 구현한다고 해서 아키텍처 레벨에서 변하는 것은 없다(Web Architecture ABC With AWS 참고). 아키텍처의 특점 과 장/단점을 잘 이해하고 있다면, 중요한 것은 아키텍처 본연의 목표를 달성 할 수 있도록 클라우드 환경을 구축하는 것이다.

멀티티어 아키텍처 서비스 스택

멀티티어 아키텍처 구현을 위해 사용 할 수 있는 AWS 주요 서비스들이다.

 AWS 서비스 스택

멀티티어 아키텍처 예제

모바일 백앤드
 AWS Multi-tier Architecture

S3 호스트 웹사이트
 S3 호스트 웹 사이트
마이크로서비스
 마이크로 서비스

마이크로서비스 아키텍처는 멀티티어 아키텍처 영역에 포함된다고 할 수는 없다. 하지만 마이크로 서비스 아키텍처는 디커플링된 소프트웨 컴포넌트들의 연결이기 때문에 멀티티어 아키텍처의 장점들이 증폭되는 경향을 가지고 있다. 따라서 큰 범주에서 멀티티어 아키텍처를 따른다고 볼 수 있다.

마이크로서비스 아키텍처를 구현하기 위해서 특별한 기술이 필요한 것은 아니다. ELB(혹은 API Gateway)는 AWS Lambda, AWS ECS, AWS EC2에 있는 기능을 호출할 수 있으면 충분하다. 이제 이들 소프트에어 컴포넌트들을 분리해서 특정팀에 책임과 권한을 부여하면 된다.

마이크로 서비스 아키텍처를 잘 활용하기 위해서는 아래의 문제들을 해결해야 한다.

각각의 새로운 마이크로 서비스를 만들기 위해서 반복적으로 수행해야 하는 오버헤드가 있다. 예를 들어 커다란 하나의 소프트웨어 컴포넌트들로 구성이 된다면, (대체로)통일된 소스코드 저장소/개발&테스트 정책/배포 시스템과 정책/버전관리/보안정책/기술스택 들을 구성할 수 있다. 하지만 마이크로 서비스하에서는 통일된 툴과 정책을 가져가기가 힘들다. 따라서 프로젝트 관리자는 느슨하게 연결된 컴포넌트들을 상위레벨에서 묶어주기 위한 시스템을 개발해야 한다.

AWS에서의 멀티티어 아키텍처의 장점

AWS라고 해서 온-프레미스 환경과 아키텍처상에 차이가 있는 건 아니다. 아키텍처를 올리는 인프라에 차이가 있을 뿐이다.

정리

공부할 거 많네...

참고