온프레미스 환경에서 고객은 모범 사례를 따르고 있는지 확인하기 위해 전사의 기술적 아키텍처 모범 관리를 위한 중앙팀을 보유하는 경우가 많습니다. 전사 기술팀에는 일반적으로 인프라 설계자, SW 솔루션 설계자, 데이터 설계자, 네트워킹 설계자, 보안 설계자 등이 포함됩니다. 이러한 팀은 엔터프라이즈 아키텍처 기능의 일부로 TOGAF 또는 Zachman 프레임워크를 사용하는 경우가 많습니다. AWS에서는 클라우드 환경에 적합한 AWS Well-Architected 프레임워크를 통해6가지 원칙을 제시하고 있습니다. 이를 통해, AWS에서 제시하는 Cloud Native향 MSA 아키텍처 구현, 고려할 점 그리고 사례를 알아봅니다.
I. 컴퓨팅 환경 변화에 따른 패러다임의 변화
[그림 1] 컴퓨팅 환경 변화에 따른 패러다임의 변화
많은 엔터프라이즈 기업들이 빠르게 변하는 외부 환경에 애자일 하게 대응하기 위하여 디지털 대전환을 선포하고, 더 빨리 고객을 이해하고 이를 위한 데이터 및 분석 시스템을 기반으로 새로운 서비스나 상품을 더 빨리 출시하고, 시장을 선도하기 위한 기반 환경 구축을 위해 클라우드를 도입하거나 클라우드로 이관을 하고 있습니다. 하지만, 클라우드로의 이관 상태(가상 머신)에서 머물며, 이를 통해 달성하고자 했던 기술 혁신과 Time to the Market 단축 목표 달성에 어려움을 겪는 경우가 많습니다. 클라우드 도입 후, 인적 자원, 프로세스, 기술 관점에서 접근해야 하지만 이번 리포트에서는 컨테이너 및 서버리스 관련 기술적 관점에 대해 살펴보겠습니다.
II. AWS Well-Architected 프레임워크의 6가지 원칙
AWS에서는 해당 기능을 갖춘 중앙 집중식 팀만을 구성하는 것보다 여러 팀에 필요한 기능 및 권한을 배분하는 것을 제시합니다. 하지만, 의사 결정 권한을 분산하기로 선택하면 위험이 있을 수 있는데, 두 가지 방법으로 이러한 위험을 완화할 수 있습니다. 첫째, 각 팀이 해당 역량을 갖도록 하는 데 초점을 맞춘 거버넌스(일 수행 방식, 프로세스, 표준 및 허용된 규범)를 갖추도록 해야 하고, 표준에 대한 기준을 확인하는 전문가를 배치해야 합니다. 둘째, 표준이 충족되는지 확인하기 위한 점검 수행은 자동화된 메커니즘을 구현하여야 합니다. 이를 위해, AWS Well-Architected(AWS WA) 프레임워크는 클라우드에서 워크로드를 설계하고 실행하기 위한 주요 개념, 설계 원칙 및 아키텍처 모범 사례를 아래와 같이 6가지 관점(Pillar)으로 제시합니다.
[그림 2] AWS Well-Architected 프레임워크의 6가지 관점
현재 운영 중인 클라우드 아키텍처 또는 서비스가 AWS WA 프레임워크를 잘 따르는 지, 큰 위험 요소는 없는지는 AWS WA Tool을 활용하여, 지속적으로 클라우드 아키텍처를 평가하고 조정함으로써 신뢰할 수 있는 클라우드 환경을 유지해 나갈 수 있습니다. AWS WA Tool을 사용하여 모범 사례를 기준으로 운영중인 아키텍처를 검토하였다면, 마이크로서비스로 아키텍처를 전환하는 것을 고려해볼 수 있습니다.
III. 마이크로서비스로 애플리케이션 현대화
마이크로서비스는 기본적으로 애플리케이션을 구성하는 작고 독립적인 단위입니다. 전통적 모놀리식 구조에서 마이크로서비스로 전환 및 분해하기 위해서는 아래와 같은 다양한 전략을 따를 수 있습니다.
[표 1] 모놀리스 분해 패턴
| 모놀리스 분해 패턴 | 장점 | 단점 |
|---|---|---|
| 비즈니스 역량별 분류 | 비즈니스 기능이 비교적 안정적일 경우 안정적인 마이크로서비스 아키텍처 제공. 개발 팀은 여러 부서에 기능보다 비즈니스 가치를 중심 제공위해 조직화. Loosely coupled. | 애플리케이션 디자인이 비즈니스 모델과 긴밀히 연결됨. 비즈니스 역량과 서비스를 식별하기 어려울 수 있어 전체 비즈니스의 심층적인 이해 필요. |
| 하위 도메인별 분해 | Loosely coupled. 확장성, 복원성, 유지보수성, 확장성, 위치 투명성, 프로토콜 독립성 및 시간 독립성을 제공. 시스템의 확장성과 예측성이 향상. | 비즈니스 역량 분해한 후 하위 도메인으로 분해하므로 마이크로서비스가 너무 많이 생성되어, 서비스 검색, 통합이 어려울 수 있음. 전체 비지니스 이해없이 하위도메인 식별이 어려울 수 있음. |
| 트랜잭션을 사용 분해 | 더 빠른 응답 시간. 데이터 일관성에 대해 걱정 없이, 가용성을 높일 수 있음. | 여러 모듈을 함께 패키징하여 모노리스를 만들 수 있으나, 여러 기능이 단일 마이크로서비스에 구현되어 비용과 복잡성 증가. 비즈니스 도메인의 수와 종속성이 많으면 트랜잭션 지향 마이크로서비스가 증가함. 일치하지 않는 버전이 동일한 비즈니스 도메인에 동시에 배포될 수 있음. |
| 팀별 서비스 패턴 | 각 팀은 독립적 활동. 제품 기능을 빠르게 혁신 및 반복 개선하며, 코드베이스와 마이크로서비스는 공유하지 않음. 팀별 다른 언어 등의 Polyglot허용. 중요: 단, 잘 정의되고 안정적 공개 API 뒤에 숨겨져 있어야함. | 최종 사용자 기능이나 비즈니스 기능에 맞게 팀을 조정하는 것은 어려울 수 있음. 팀 간에 순환 종속성이 있는 경우, 더 크고 팀간 조정이 필요한 애플리케이션 증분 만들려면 추가 공수 필요. |
| 스트랭글러 피그 패턴 | 변환-공존-제거 단계로 구성 서비스에서 하나 이상의 대체 서비스로 정상적으로 이관 가능. 업데이트 및 리팩토링하는 동안 이전 서비스를 계속 사용 가능. 이전 서비스 리팩토링하며 새 서비스 및 기능 또한 추가 가능. **모놀리스 주변에서 호출 차단할 수 있을 때 잘 작동 | 복잡성이 낮고 크기가 작은 소규모 시스템엔 부적합. 백엔드 요청을 가로채서 라우팅할 수 없는 시스템에서는 사용할 수 없음. 제대로 설계되지 않을 경우 SPOF나 성능 병목 발생 가능. 문제시 빨리 대응 위해 각 리팩토링 된 서비스별 롤백 계획 필요. |
| 추상화 패턴 별 분기 | 문제 발생시 되돌릴 수 있는 점진적 변경 허용(이전 버전과 호환). 모놀리스 가장자리에서 모놀리스에 대한 호출을 차단할 수 없을 때, 업스트림 종속성 있는 요소 현대화시 활용 가능 새 기능과 이전 기능을 모두 호출하여 폴백 메커니즘을 쉽게. 지속적인 배포 가능. | 데이터 일관성이 관련된 경우에는 부적합 기존 시스템을 변경 필요. 코드베이스가 제대로 구성되지 않으면, 개발에 더 많은 오버헤드가 추가될 가능성 있음. |
이러한 마이크로서비스로의 전환 도입시 고려할 점은 시스템 변경뿐 아니라 조직의 운영 방식에도 영향을 미치게 된다는 점입니다. 빠른 주기의 민첩한 개발을 장려하기 위해선, Two Pizza 팀으로 대표되는 정도의 작은 팀 단위로 조직화 되고, 이 팀이 생성, 배포, 유지관리까지 책임지게 됩니다. 아키텍처 리뷰와 팀구성이 준비되었다면 좀 더 유연한 확장에 대응을 위해 컨테이너로의 전환부터 고려해 볼 수 있습니다.
IV. AWS 상에서의 컨테이너화를 통한 마이크로서비스 아키텍처
모놀리식 애플리케이션은 대개의 경우 프리젠테이션, 애플리케이션, 데이터 계층으로 구성되는 반면, 마이크로서비스 아키텍처는 기술 계층이 아닌 도메인에 따른 기능을 수직으로 분리합니다. 아래는 AWS의 기본적인 마이크로서비스 참조 아키텍처를 보여줍니다.
[그림3] AWS의 일반적 마이크로서비스 애플리케이션
현대 웹 애플리케이션은 종종 자바스크립트를 활용하여 백엔드 API와 통신하는 API구현을 통해 개발됩니다. 아래는 위 참조 아키텍처에 대한 간략한 설명입니다.
[표 2] 마이크로서비스 참조 아키텍처 설명
| 레이어 | 주요 기술 요소 | 관련 AWS 서비스 |
|---|---|---|
| 사용자 인터페이스 | REST, RESTful API 또는 GraphQL API 사용 구축 | Amazon S3 저장 서비스 및 Amazon CloudFront(CDN)서비스를 활용 정적 웹 콘텐츠 제공 |
| 마이크로서비스 컴퓨팅 구현 | API 호출의 관리 및 처리, 트래픽 관리, 요청 필터링, 로드 밸런싱, 라우팅, 인증과 권한 부여 기능 | 기본 인프라 관리에 대한 고객의 요구사항에 따라 컨테이너 오케스트레이션을 위한 Amazon ECS (또는 Amazon EKS)와 호스팅 위해 AWS Fargate 또는 Amazon EC2 (서버인스턴스) 선택 인프라 관리가 필요 없는 경우, AWS Lambda를 사용 코드를 업로드하고 고가용성으로 실행 자동화 및 확장 |
| 데이터 저장 | 애플리케이션 서버와 DB 사이에 캐시 통해 읽기 부하를 줄이고 더 많은 쓰기 지원 및 latency 향상 | 관계형 DB는 구조화된 데이터 저장에 많이 활용. Amazon RDS를 통해 Microsoft SQL Server, Oracle, MySQL, MariaDB, PostgreSQL, 과 Amazon Aurora 엔진 지원 관계형 DB의 일관성보다 확장성, 성능 및 가용성이 우선시 된다면 데이터를 수평으로 확장할 수 있는 NoSQL DB를 활용 (Amazon DynamoDB) |
마이크로서비스로 전환 후 이를 실행, 유지 관리, 모니터링하는 데 필요한 운영 노력을 더욱 단순화하고 싶다면, 완전한 서버리스 아키텍처 사용을 고려할 수 있습니다.
IV. AWS 상에서의 서버리스
대표적인 서버리스 관련 서비스인, AWS Lambda(이벤트 기반 코드 호출)를 통해 코드를 zip 파일, 또는 컨테이너 이미지를 업로드하여 배포할 수 있으나, 여러 계층이 관여하고 종속성이나 권한 문제로 복잡해지면 코드 변경이 어려워질 수 있습니다. 이런 경우, IaC 서비스인 AWS CloudFormation및 아래 그림의 AWS SAM(Serverless Application Model)을 사용하여, AWS CDK나 Terraform을 활용하여 간소화 할 수 있습니다.
[그림 4] AWS 서버리스 애플리케이션 모델 (SAM)
위 [그림4]는 AWS CloudFormation및 CI/CD 도구를 통하여 필요한 리소스를 배포하는 방법을 보여줍니다. Lambda에 업로드 하기전에 로컬에서 개발, 테스트 및 분석을 하고, 관련 도구와 통합 환경을 구현함으로써 애플리케이션 작성, 테스트, 디버깅 및 배포를 간소화 할 수 있습니다. 아래는 컨테이너가 아닌 EDA(Event Driven Architecture) “서버리스 마이크로서비스” 구현 방식의 기본적 아키텍처를 보여줍니다.
[그림 5] AWS Lambda를 사용하는 서버리스 마이크로서비스
[그림 5]는 AWS Lambda 및 관리형 서비스를 사용하는 서버리스 마이크로서비스 아키텍처를 보여줍니다. 이 서버리스 아키텍처는 확장성과 고가용성을 위한 설계 필요성을 완화하고 기본 인프라를 실행하고 모니터링하는 데 필요한 노력을 줄여줍니다. 이러한 마이크로서비스로의 애플리케이션 현대화는 궁극적으로 빠르게 변화하는 비지니스 환경에 비용 효율성을 갖추고 탄력적으로 대응하기 위함입니다.
V. 마이크로서비스 시스템을 위한 고려 사항
| 고려할 관점 | 특징 | 고려할 사항 |
|---|---|---|
| DR (Disaster Recovery) | 마이크로서비스는 12-Factor 애플리케이션 패턴을 따름 프로세스의 상태 비저장 장애시 새 인스턴스 시작하여 DR 단순화 가능 DB와 같은 상태 저장 지원 서비스에 영구 데이터 저장 필요 | 마이크로서비스 자체보다, 파일 시스템, 데이터베이스 또는 대기열과 같이 애플리케이션의 상태를 유지 관리하는 다운스트림 서비스 중점 전략 필요 조직의 비지니스 전략을 지원하기위한 적절한 RTO, RPO 목표 수립과 측정 방법 및 메커니즘 수립 |
| HA (High Availability) | 쿠버네티스의 컨트롤과 데이터 플레인을 여러 AZ(Availability Zone)에 구현 가용성과 접근성 높이기 위한 스토리지 사용 필요 자원과 가용성 요구사항에 맞춘 여러 스케줄링 전략 제공 | 자동화된 업그레이드 및 패치에 따른 비지니스 영향도 사전 숙지 AZ 간의 물리적 거리로 인해 발생할 수도 있는 무거운 배치 작업등의 latency 고려 AZ간 적절한 분배 |
마이크로서비스 아키텍처는 민첩한 소프트웨어 개발, 서비스 지향 아키텍처, API 우선 설계, CI/CD를 아우르며 탄력적이 비용 최적화된 아키텍처입니다. 하지만, 조직내에서 실제 구현 전략과 방향을 정하고, 모놀리스에 익숙한 조직 문화의 변화를 이끌어내는 데에는 조직원 전체의 많은 노력이 필요합니다. 또한, 조직이 *콘웨이의 법칙에서 얘기하는 바와 같이 마이크로서비스 아키텍처를 지원하기 위해 최적화된 조직 구성인가도 고려해 볼 필요가 있습니다.
* 콘웨이의 법칙 (Conway’s Law) : 1964년 4월 멜빈 콘웨이(Melvin E. Coway)의 Datamation이라는 컴퓨터 잡지에 “How do committees invent?”라는 기사에서 “시스템을 설계하는 조직은 조직의 의사소통 구조를 닮은 구조의 시스템을 만들게 된다”는 문장이 있었는데, 이 글이 이후, 개발자들 사이에서 회자되면서 “콘웨이의 법칙”으로 불리우게 되었습니다. 예를 들어, DevOps, MLOps, CI/CD를 기술적으로 구현하는 것은 어느 정도의 노력을 기울이면 가능합니다. 하지만, 구현 과정에서 조직 간 시스템에 대한 권한 구조와 문화, 개발자의 인프라 프로비저닝 권한, 배포 과정 마다의 결재에 대한 자동화 프로세스 논의, 보안 체계, 또는 컴플라이언스 관련 (ISMS-P 등) 등 기술 외적인 요인으로 구현이 늦춰지거나, 구현 이후 운영 단계에서 어려움을 겪는 경우가 종종 있습니다. 따라서, MSA 를 논할 경우에는 항상 기술 외적인 부분에 대한 고려도 반드시 필요합니다.
[참고문헌]
[1] AWS에서 워크로드의 재해 복구 (클라우드에서의 재해복구)
[2] The Twelve Factor App: https://12factor.net/
[3] 모놀리스를 마이크로서비스로 분해 : AWS 규범적 지침.
[4] 스트랭글러피그 애플리케이션 https://martinfowler.com/bliki/StranglerFigApplication.html.