1. MSA
MSA(MicroService Architecture)는 소프트웨어 개발 기법의 하나. MSA는 단일 애플리케이션을 작은 서비스 모음으로 개발하는 접근 방식. 각각은 자체 프로세스에서 실행이 되고 느슨한 연결(Loosely-coupled) 구조로 만들어 HTTP 리소스인 REST와 같은 경량 메커니즘과 통신을 함. 한마디로 "하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처".
MSA와 같은 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합해 높은 인기를 구가하고 있음. 특히 도커(Docker), 쿠버네티스(Kubernetes) 등과 같은 컨테이너 기반의 플랫폼과 조합이 잘 어우러지면서 클라우드 플랫폼과 MSA는 서로 끌어주고 밀어주면서 발전하고 있음. 하지만 아래와 같은 난관들이 있음
1) 개발 복잡도와 숙련도
독립적인 서비스이기 때문에 각 모듈의 인터페이스를 신중하게 처리해야 함. 요청에 응답하지 않게 될 경우에 대한 방어 코드도 작성해야 하며 호출 대기 시간이 일정 수준을 넘기면 복잡한 상황이 발생할 수 있음. 또한 동기적인 처리방식인 REST 통신으로 인한 제약이 발생할 수 있음.
2) 트랜잭션 관리
MSA는 Database Per Service라는 새로운 요구사항으로 분산된 서비스마다 분리된 DB들 간의 트랜잭션 관리가 어려울 수 있음. 또한 반정규화 된 데이터의 동기 처리도 신경을 써야 함.
3) 통합 테스트 어려움
MSA 기반의 애플리케이션을 테스트하는 것은 번거로울 수 있음. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 함.
4) 배포 복잡도
MSA를 도입하다 보면 기존에 없던 새로운 문제점들이 발생함. 이런 부분들은 자동화 도구를 사용하거나 비즈니스 상황에 맞게 수정된 아키텍처를 적용하여 해결할 수 있음. Event Driven MircoService(EDM)가 이를 보완할 수 있음.
2. Event Driven MicroService(EDM)
Event Driven 아키텍처는 특정 서비스에서 다른 서비스가 관심을 가질 수 있는 일부 작업을 수행할 때 해당 서비스는 이벤트(작업의 기록)를 생성함. 다른 서비스는 이벤트들을 전달받고 필요시 자체 작업을 수행할 수 있음. REST와는 달리 이벤트를 통해 느슨한 구조로 요청을 생성하는 서비스는 요청을 소비하는 서비스의 세부 정보를 알 필요가 없음.
이벤트는 다양한 방법으로 게시할 수 있음. 예를 들어 이벤트를 적절한 소비자에게 전달하도록 보장하는 대기열(Queue)에 게시하거나 이벤트를 게시하고 모든 이해 당사자에게 액세스를 허용하는 "발행-구독"(Pub-Sub) 메시지 모델에 게시할 수 있음. 두 경우 모두 생산자는 이벤트를 발행하고 소비자는 해당 이벤트를 수신하여 그에 따라 반응함. 이 두 행위자를 발행자(생산자)와 구독자(소비자)라고 불림.
Queue 처리 방식에는 대표적으로 ActiveMQ, RabbitMQ가 있으며 메시지 모델로는 대표적으로 Apache Kafka를 많이 활용함.
MSA에서 내부 통신은 요청-응답 모델(Request-Response: 동기 통신에 단일 통신 방법)보다 발행-구독 모델(Pub-Sub: 비동기 통신에 Broadcasting 가능)을 선택함.
발행-구독은 이벤트 게시자는 구독자의 주소를 몰라도 되고 이벤트를 수신했는지 여부를 파악하지 않아도 되는 Non-Blocking 모델. 수신자의 서비스가 항상 떠 있지 않아도 게시자는 메시지를 발송할 수 있음. 이로 인하여 장애가 격리(Fault Isolation)됨.
EDM은 MSA가 적용된 시스템에서 이벤트 발생 시 해당 이벤트 로그를 보관하고 이를 기반으로 동작하며 비동기 통신을 통해 시스템 내 통합을 수행하는 아키텍처. 기존의 모놀로틱 아키텍처의 단점 및 한계를 해결하고자 하거나 클라우드 환경에서 시스템을 구축할 때 얻을 수 있는 장점 때문에 MSA 도입을 결정했다면 그다음 닥칠 문제에 대비해 EDM을 고려해 볼 필요가 있음.
3. 클라우드 서비스 모델과 Trail Map
IaaS → PaaS → SaaS
CNCF(Cloud Native Computing Foundation)는 다양한 클라우드 네이티브 애플리케이션 개발에 도움을 주기 위해 아키텍처를 제안하고 관련된 영역을 정의하며 개별 영역에서 유효한 제품과 기술을 소개함
cf. 파이썬의 대표적인 웹 프레임 워크 세 가지
1) Django: 풍부한 내장 기능들(보안, Rest Framework, ORM 단 SQLAlchemy 지원 X, 서드파티 연계). 관리자 페이지. 캐시 시스템 제공. MVT 패턴. 커다란 커뮤니티. 사이즈가 크고 느림(동기 방식). 중~대형 프로젝트에 적합
2) Flask: Micro Framework. 웹 애플리케이션을 빠르게 프로토 타입으로 제작 가능. 동기 방식이라 느리고 한 번에 많은 트래픽 처리하기 어려움. 규모 커질수록 세팅 다 신경 써야 함. API 개발에 적합
3) FastAPI: 확장 가능한 Micro Framework 유지하고 편리하고 사용하기 쉬운 routing system을 쓰면서, 필요한 tools와 parts를 mix and match를 통해 만듦. 높은 성능(빠른 속도와 간편한 유효성 검사). Async I/O 덕분에 event loop와 async/await 관리를 하지 않아도 됨. 의존성 주입 솔루션이 내장되어 Class 간 의존성이 줄어들고 모듈화, 확장이 용이함. 코드 분석해 자동으로 Open API 문서 생성. 잘 정리된 공식 문서. 커뮤니티 작음. ORM 사용 위해 다양한 라이브러리를 설치해야 하므로 의존성을 직접 관리해야 함. 비동기식 혹은 빠른 처리를 요하는 API 개발에 적합
cf. 웹 프레임 워크 선택 시 고려할 사항들
1) 프로젝트의 사이즈와 복잡도: Full Stack vs. Micro
2) 확장성
3) 공식 문서와 커뮤니티
4) 라이선스 정책(오픈소스 여부)
cf. Colocation vs. Cloud
- Colocation: 서버, 하드웨어 및 기타 장비를 위한 물리적 공간(IDC = 데이터 센터)을 임대하고 유지 보수 서비스를 제공함
- Cloud: 오프사이트, 클라우드 기반 소프트웨어, 스토리지 및 인프라를 관리함
'Cloud Engineer' 카테고리의 다른 글
| 6/3 토_3 Tier, 클라우드 생태계(CSP/MSP/ISV) (0) | 2023.06.03 |
|---|
