AWS에서의 Multi tier 아키텍처

Contents

좀 더 체계적으로 클라우드를 공부하기 위해서 아키텍처 관련 내용들을 정리하기로 했다. 아키텍처 관련 내용들은 architecture 태그로 관리한다. 체계적으로 공부를 시작하는 이유는 AWS Solutions Architects의 준비하기 위함이다. 필드에서 경험쌓으면서 3년 정도 장기적으로 준비하려 한다. 멀티티어(multitier) 아키텍처는 n-tier 아키텍처 혹은 멀티레이어드(multilayered)아키텍처라고 부르기도 한다. 애플리케이션을 여러 개의 계층으로 나눠서 개발을 하고 이들을 연결해서 하나의 통합된 서비스를 만드는 아키텍처다. 일반적으로 프리젠테이션, 애플리케이션, 데이터베이스 3개의 계층(tier)을 가진다. 이러한 아키텍처를 3 티어 아키텍처라고 부르며, 가장 널리 사용되는 아키텍처다. 각 계층은 서버/클라이언트아키텍처를 따른다. 결과적으로 서버/클라이언트 모델이 몇 개의 계층을 구성하는 아키텍처다.

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

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

으로 구성되는 프로젝트를 어렵지 않게 찾아볼 수 있는데, 멀티티어 아키텍처를 따르는 애플리케이션을 구성하기 위한 조직구성이라고 보면 되겠다.

객체지향 디자인을 지향하는 정보 시스템에서 멀티레이어 아키텍처는 일반적으로 아래의 4가지 요소로 구성된다.

• 프리젠테이션 레이어(Presentation layer) : a.k.a UI layer, view layer
• 애플리케이션 레이어(Application layer) : a.k.a Service layer, GRASP(General Responsibility Assignment Software Pattern) Controller layer
• 비지니스 레이어(Business login layer) : a.k.a business logic layer(BLL), domain layer
• 데이터 액세스 레이어(Data access layer) : a.k.a persistent layer. 비지니스 레이어의 요구사항을 지원하기 위한 로깅, 네트워킹 등을 포함한다.

Domain-Driven Design의 경우 위의 레이어들에 대한 일반적인 내용을 다루지만, 도메인 계층에 촛점을 맞춘다.

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

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

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

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

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

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

비지니스 로직, 로직티어, 미들티어라고 부르기도 한다. 프리젠테이션 계층에서 전달된 요청을 읽어서 세부적인 처리를 수행한다. 쇼핑카트라면

1. 구매 아이템의 정보(가격, 품목, 상품이미지, 상품식별번호)를 얻는다.
2. 전자장바구니(데이터베이스 혹은 REDIS 등으로 구현한)에 아이템을 넣고 뺀다.
3. 아이템을 넣고 뺄때, 장바구니에 있는 아이템 갯수, 전체 비용등의 계산을 수행한다.

구현을 가지고 있을 것이다.

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

• 서비스는 크게 데이터 입출력, 데이터 처리, 데이터 저장소의 영역구성된다.
• 위 3개의 영역은 사용자 관점에서 계층(tier)화 할 수 있다.
• 멀티티어 아키텍처는 이들 계층을 독립적으로 개발하고 API를 통해서 연결하는 구조다.
• 멀티티어 아키텍처는 서버/클라이언트 아키텍처 패턴을 근간으로 한다.

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

• client/server 아키텍처 : client/server 아키텍처는 아키텍처라기 보다는 패러다임이라고 봐야 할 것이다. 중앙에 자원을 처리하는 강력한 서버가 있고, (분산된)클라이언트의 요청을 처리한다는 정보처리 패러다임이다. 멀티티어 아키텍처, MSA 아키텍처 모두 client/server 아키텍처를 사용하고 있다.
• 멀티티어 아키텍처
• MSA(Microservice 아키텍처) : (2019년 8월 현재)요즘 핫한 아키텍처다. 하나의 큰 (서버)애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처다. 분리된 애플리케이션은 자체 데이터베이스, 캐시, 배포 환경을 가지고 있기 때문에 이론적으로 완전히 독립적으로 작동하며, 다른 애플리케이션과 자유롭게 연동 할 수 있다. 컨테이너 기술이 일반적으로 사용하면서 프로세스단위로의 (네트워크,CPU,메모리,파일시스템)격리가 가능해지면서 조목받는 아키텍처다.
• Messaging-oriented middleware(MOM) : 메시지 큐 시스템 혹은 브로드캐스트 형식의 메시지처리 시스템을 기반으로 한다. 퍼블리셔가 발행한 메시지는 메시지 큐에 들어간다. 메시지 큐를 관리하는 브로커는 해당 메시지를 처리할 서브스크라이버에 라우팅(routing)한다. 메시지큐를 중심으로 퍼블리셔와 서브스크라이버가 분리되기 때문에, 근본적으로 비동기 처리성격을 가진다.

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

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

AWS 같은 클라우드 환경에서 (MSA 등의 핫한 모델이 있음에도)여전히 멀티티어 아키텍처가 우선 고려되는 이유는 아래와 같다.

• 역할이 명확하다. : 프로젝트 계획 수립과 관리가 쉽다. 왜 ? 조직구성이 눈에 보이기 때문이다. 물어볼 경험있는 사람도 많다.
  • 프리젠테이션 영역 : 안드로이드, iOS 개발자로 구성된 프론트앤드 팀을 꾸려야 겠군
  • 비지니스 로직 : Java, Python, Ruby, Go 언어를 사용하는 서버 개발자로 구성된 백앤드 팀을 만들면 되겠군. 아 언어 많아지니 관리 힘들어지네. 그냥 Java로 통일하자.
  • 데이터 영역 : DBA가 필요하겠어. DBA를 독립적인 팀으로 하기 모호하면, 백앤드 팀에 소속해도 되겠지.
• 직관적이다. : 누가 봐도 왜 이런 구성이 필요한지 한 눈에 들어온다.
• 오랜시간 검증 됐다.

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

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

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

• 프리젠테이션 티어 : 각 유저 스마트폰에서 실행되는 모바일 애플리케이션
• 로직 티어 : ELB 와 EC2 기반의 애플리케이션 서버로 구성된다. Application ELB는 Lambda를 호출 Amazon Cognito를 이용해서 유저를 인증 할 수 있다. 일반적인 작업요청은 Application ELB를 통해서 EC2 인스턴스 위에 있는 서버 애플리케이션으로 전달된다. ELB와 Amazon API Gateway를 함께 사용 할 수 있다.
• 데이터 티어 : 서비스 요구 사항에 따라서 다양한 RDBMS, No-SQL 들이 사용 될 수 있다.

• 프리젠테이션 티어 : Amazon S3는 Static website content hosted기능을 제공한다. 이 기능을 이용해서 S3에 있는 파일을 CloudFront를 이용해서 인터넷에 배포 할 수 있다. 정적 컨텐츠를 S3로 배포하는 것은 비용, 관리, 효율성 측면에서 좋은 방법이다.
• 로직 티어 : ELB, API Gateway와 Lambda, EC2 인스턴스의 조합으로 구성된다.
• 데이터 티어 : 서비스 요구사항에 따라서 다양한 RDMBS, No-SQL 들이 사용 될 수 있다.

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

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

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

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

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

• 멀티티어 아키텍처에서 각 티어간 연동은 네트워크 시스템을 통해서 이루어진다. AWS는 VPC, ELB, API Gateway를 이용해서 티어를 연결한다. 이들 네트워크 시스템은 99.95% 이상의 SLA(Service Level agreement)를 제공한다. 자유롭게 전개/확장 할 수 있으며, terraform, cloudformation 을 이용해서 전체 구성을 자동화 할 수 있다.
• CloudWatch, Log Insight, S3, ELK, Athena 를 통한 로깅/모니터링 시스템 통합. Opgsenie를 이용한 AWS 인프라 이벤트 관리 시스템 구성 참고
• Security, Security Hub, WAF, Security Group, DutyGuard, CloudTrail, IAM 등 보안 시스템과의 통합.
• 여러번 빠르게 부담없이, 실패 할 수 있다. 기업 IT 시스템 혁신에 가장 크게 기여하는 특징이라고 본다.
• 복잡도의 위임. 클라우드 인프라 설계의 큰 방향이라 생각한다.

• AWS 기반의 Message Queue 기반 아키텍처를 정리해야 겠다. 아마 MSK 기반이 되지 않을까.
• AWS 기반으로 MSA 아키텍처를 정리하고 구현을 해봐야겠다.
• aWS 기반으로 Event-Drive 아키텍처를 정리해야 겠다.

공부할 거 많네...

• Multi tier architecture - wikipedia
• Building three tier architectures with security groups
• Designing a three tier architecture in aws
• How to architect and deploy a multi tier share point server farm on AWS
• Amazon & AWS의 MSA와 DevOps, 그리고 지속적 혁신
• AWS Serverless Multi Tier Architectures