MicroService 와 Cloud Native Architecture

Cloud Native Architecture

기존에서 로컬환경이나 사내에서 구축하고 운영하였던 시스템을 클라우드 환경으로 전환하기 위해서 어떠한 아키텍처를 가져야 하는가?

확장 가능한 아키텍처

• 시스템이 필요에 따라 확장 가능한 형태의 아키텍처로 확장 → 시스템의 수평적 확장에 유연해짐
• 그와 동시에 확장된 서버로 시스템의 부하분산을 함과 동시에 가용성 보장 가능
• 스케일업/스케일아웃
  • 스케일업 - 가지고 있는 CPU나 메모리 등을 늘리는 것
  • 스케일아웃 - 같은 사양의 서버 즉 인스턴스를 여러 대 배치함으로써 동시에 많은 사용자들의 요청을 처리할 수 있다.
• 클라우드 서비스를 제공하는 업체를 이용함으로써 가상의 서버, 가상의 스토리지, 가상의 네트워크 등을 빌려 사용하여 비용을 최소화 → 서버 사용 안 할 땐 리소스 반납
• 컨테이너 방식의 가상화방식 사용
• 클라우드 네이티브에서의 가상의 리소스들은 다양한 모니터링 도구를 이용하여 현재 사용되고 있는 시스템 사용 현황과 리소스를 확인할 수 있다.

탄력적 아키텍처

• 애플리케이션을 구성하는 각 기능을 분리된 서비스로 개발 → 분리된 서비스를 다시 통합하여 배포하기까지 걸리는 시간을 CICD 자동화 파이프라인을 통해 처리함으로써 배포 시간 단축
• 마이크로서비스는 작게 분리된 독립적인 서비스 → 전체 어플리케이션을 구성하는 도메인 특성에 따라 서비스 경계를 구분하고 개발 → 서로 분리된 서비스 간에 원활한 통신을 위해 각각의 서비스 종속성을 최소화해야 한다.
• 마이크로서비스들은 자신들이 배포될 때 위치를 등록해야 한다 → 외부에 연결된 타 서비스들이 해당 서비스를 검색하고 사용할 수 있어야 한다
• 마이크로서비스의 존재는 디스커버리 서비스에 등록/삭제된다

장애 격리

• 클라우드 네이티브 아키텍처는 장애복구에 뛰어나다
• 여러개로 분리되어 개발되는 서비스들은 독립된 작은 애플리케이션과 같다. 각각의 장애나 오류사항이 다른 서비스로 전파되는 문제를 최소화할 수 있다. → 특정 서비스에 문제 발생 시 그 서비스만 다시 배포하면 된다.

Cloud Native Application

클라우드 네이티브 아키텍처의 의해 설계되고 구현되는 애플리케이션이다.
아키텍처의 특징이나 장애격리 특징을 가지고 다음과 같이 구현된다.

1. Microservices - 마이크로서비스로 개발된다.
2. CI/CD - CICD에 의해 자동으로 통합되고 빌드 배포된다.
3. DevOps - 마이크로 서비스에 문제가 발생하였을 경우에 바로 수정해서 다시 배포하는 과정을 반복하는 특징 → 시스템이 기획, 구현, 테스트, 배포되는 과정을 시스템이 종료될 때까지 반복함으로써 최선의 결과물을 만드는데 목적을 둔다
4. Containers - 하나의 애플리케이션을 구성하는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해선 컨테이너 가상화 기술을 사용한다.

CI/CD

• 지속적인 통합 - CI
  • 하나의 어플리케이션을 여러 팀이나 개발자에 의해 개발하는 경우에 결과물을 통합하기 위한 형상관리
  • 통합된 코드를 빌드하고 테스트하는 과정 자체
  • 젠킨스, 팀씨아이, 트래비스씨아이 등 → 깃과 같은 형상관리 시스템과 연동하여 사용
• 지속적인 배포 - CD
  • 지속적인 전달 / 지속적인 배포 두 가지의 의미
  • 소스저장소에 있는 코드를 가져와서 패키지화된 결과물을 실행환경에 어떻게 배포하는지에 따라 달라진다.
  • 패키지화된 결과물을 수동 반영 → Continuous Delivery
  • 관리자의 개입 없이 실행환경까지 자동화된 배포를 한다면 → Continuous Deployment
  • 카나리배포, 블루그린 배포 등의 전략 사용

DevOps

• Development(개발) + Operation(운영)
• 개발조직과 운영조직의 통합을 의미
• 고객의 요구사항에 빠르게 대응하고 결과물을 제시하는 것에 목적
• 자주 테스트, 피드백, 업데이트하는 과정을 거쳐서 전체 개발 일정이 완료될 때까지 지속적으로 진행해 가는 것
• 클라우드 네이티브 애플리케이션은 데브옵스 환경에 맞춰서 서비스를 작은 단위로 분할할 수 있게 함으로써 더 자주 통합, 테스트, 배포할 수 있는 구조가 될 수 있다.

Container 가상화

• 클라우드 네이티브 아키텍처의 핵심
• 기존에 하드웨어 가상화, 서버 가상화에 비해 비교적 적은 리소스를 사용하여 가상화 서비스를 구축할 수 있다.
• 기존 - 하드웨어 시스템 위에 운영체제를 설치하고 App 들을 운영하게 된다.
• 가상화 - 운영체제 위에 Hypervisor 기술을 통한 가상머신을 기동 하게 된다. 가상 머신은 하드웨어(Host System)가 가지고 있는 물리적인 하드웨어를 쪼개서 사용함으로써 하나의 가상머신은 독립적인 운영체제를 가지고 실행될 수 있다 → Host 운영체제에 많은 부하를 주게 된고 시스템 확장에 한계가 있다.
• 컨테이너 가상화 - 운영체제 위에 컨테이너 가상화를 기동 하기 위한 소프트웨어를 작동하기 된다. 컨테이너에서는 공통적인 라이브러리나 리소스를 공유해서 사용하게 된다. 각자 필요한 부분에 대해서만 독립적으로 실행할 수 있는 구조이다. 기존의 하드웨어 가상화 기술보다는 더 적은 리소스를 사용할 수 있게 되었고, 컨테이너 가상화 위에서 작동되는 서비스들은 가볍고 빠르게 운영할 수 있다.

12 Factors

https://12factor.net/
해로쿠라는 회사에서 클라우드 네이티브 아키텍처를 적용하면서 마주쳤던 문제들과 경험을 바탕으로 클라우드 네이티브 아키텍처를 위한 조건 12가지를 제시한 것

Codebase

레파지토리에 저장된 마이크로서비스의 베이스
버전 지원하기 위한 목적
형상관리를 위해 한 곳에서 배포하는 게 목적
이후에 배포하기 위해 코드의 통일적인 관리가 필요하기 때문에 가장 중요한 항목

dependencies

각 마이크로서비스는 자체 종속성을 가지고 패키지 되어있어서 전체 시스템에 영향을 주지 않은 상태에서 변경, 수정할 수 있어야 한다

Config

시스템 코드 외부에서 구성 관리 도구를 통해서 마이크로서비스에 필요한 작업들을 제어하는 것.

Backing services

데이터베이스, 캐시, 메시지 서비스 등을 이용해서 마이크로서비스가 가져야 할 기능들을 추가로 지원하는 것
시스템에 필요한 보조 서비스 리소스를 분리함으로써 상호 간의 필요한 작업들을 의존성 없이 작업할 수 있는 것을 말한다

Build, release, run

빌드와 릴리즈와 실행환경을 각각 분리하는 것
개발서버에서 만들어진 코드를 배포하기 위해 실행단계까지 옮기는 과정을 엄격하게 분리해야 한다.
각 작업은 고유한 아이디로 태그를 가지고 있어야 하고 롤백기능을 지원해야 하며 CICD를 완벽하게 이용해서 자동화된 시스템을 구축해야 한다.

Processes

각각의 마이크로서비스는 실행 중인 다른 서비스와 분리된 채 자체 프로세스에서 운영될 수 있어야 한다.
즉 하나의 마이크로서비스는 다른 마이크로서비스와 분리되어서 독립적으로 실행되어야 하고, 캐시라던가 데이터 저장소를 통해 데이터 동기화를 할 수 있어야 한다.

Port binding

각각의 마이크로 서비스는 자체 포트에서 노출되는 인터페이스 및 기능과 함체 자체적으로 포함되어 있는 기능이 있어야 한다. → 다른 서비스와의 격리가 가능함

Concurrency

하나의 서비스가 여러 개의 인스턴스에 복사가 되어 이루어짐으로써 부하분산을 이룰 수도 있는데 동일한 서비스가 여러 인스턴스에 나눠서 서비스되고 있기 때문에 동시성을 가져야 한다.

Disposability

서비스 인스턴스 자체가 삭제가 가능해야 하고 확장성 기회를 높여야 하고 정상적으로 종료를 할 수 있는 상태여야 한다.
도커와 같은 것을 사용한다면 서비스에 인스턴스를 등록/실행/삭제 작업을 쉽게 할 수 있다.

Dev/prod parity

개발단계와 프로덕션 단계를 구분할 수 있어야 한다.
환경 자체를 최대한 다른 작업과 종속적이지 않은 상태로서 서비스를 유지할 수 있어야 한다.

Logs

마이크로서비스에서 생성되는 로그를 이벤트 스트림으로 처리해야 한다.
즉 하나의 시스템 안에서 구성되고 있는 로그를 출력하는 로직은 기존에 썼던 애플리케이션과 분리가 되어서 애플리케이션이 실행되지 않는 상태라 할지라도 로그만은 정삭적으로 작동되어야 한다.
로그와 이벤트 집계를 사용하기 위해서 별도의 모니터링 도구를 사용할 수 있다.
EX) Azure, DataMining, ELK 등

Admin processes

현재 운영되는 모든 마이크로 서비스들을 어떤 상태로 사용되고 있으며 리소스가 어떻게 사용되고 있는지에 대해 파악하기 위한 관리도구가 있어야 한다.
리포팅할 수 있는 기술, 데이터 정리, 데이터 분석 기능이 포함되어있어야 한다.


최근에 3가지 추가해서 피보탈이라는 회사에서 발표함

API first

모든 마이크로서비스에 대해선 API 형태로 서비스가 제공이 되고, 서비스를 구축함에 있어서 사용자 측에서 어떤 형태로 쓸지 고민해야 한다.

Telementry

모든 지표는 수치화되어서 시각화되어 관리할 수 있는 항목 이어야 한다.

Authentication and authorization

마이크로 서비스의 형태로 분리되어 개발된다 하더라도 API 사용함에 있어서 적절한 인증을 가지고 있어야 한다.