Cloud Native Architecture
클라우드 시스템
최근에는 AWS나 Heroku, Azure, Naver Cloud Plaform 등 여러 기업에서 다양한 클라우드 컴퓨팅 기술을 제공한다. 이러한 클라우드 시스템을 이용하는 이유는 서버의 증축을 유연하게 사용하여 효율적으로 비용 관리를 할 수 있기 때문이다.
예를 들자면, 평소에는 평균 10만의 트래픽이 발생하지만 연말과 연초에는 1000만의 트래픽이 발생하는 애플리케이션이 있다. 이러한 경우 연말-연초의 짧은 기간을 위해 1000만의 트래픽을 수용할 수 있는 서버를 구축해두어야 한다. 하지만 클라우드 시스템을 사용하면 ondemand 방식이라하여 사용한만큼만 비용을 지불하면 되기 때문에, 서버의 필요에 의해 scaling을 통해 유연하게 대처할 수 있다. 심지어 이를 서버가 자원 사용률을 보고 자동으로 확장하는 Auto scaling 기능도 제공한다.
클라우드 네이티브 아키텍처
클라우드 네이티브 아키텍처란 말은 CNCF(Cloud Native Computing Foundation)에서 다음과 같이 처음 사용되고 정의되었다.
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
클라우드 네이티브 기술을 통해서 조직은 현대적인 동적 환경에서 확장 가능한 애플리케이션을 구축하고 실행할 수 있게 된다. 컨테이너, 서비스 매쉬, 마이크로 서비스, 불변 인프라, 선언적 API를 통해 이를 해결한다는 것이다. 이러한 기술을 통해 관리 가능하며 관찰 가능한 느슨하게 결합된 시스템을 구축하는 것이 클라우드 네이티브 아키텍처이다.
쉽게 말해 클라우드 네이티브 아키텍처란, 위의 클라우드 시스템의 유연성을 잘 활용할 수 있도록 애플리케이션을 구축하는 방법을 말한다. 클라우드 네이티브 아키텍처를 통해 클라우드 시스템의 장점을 활용하여 자동화된 빌드와 테스트, 배포가 가능하게 하고, 단단한 서비스의 구성 요소와 변화에 민첩하게 대응할 수 있는 유연한 시스템을 구축할 수 있게 된다.
비즈니스 시스템은 더 많은 사용자 요구로 인해 점점 더 복잡해지는데, 빠른 응답성과 현식적인 기능, 제로 가동 중지 시간을 기대한다. 하루에도 수없이 많이 수정되고 재배포되는 상황에서 이런 기대들을 만족하기 위해, Netflix나 Uber, WeChat 등 많은 대규모 기업에서 클라우드 네이티브 기술을 구현하였다.
클라우드 네이티브의 특징
이러한 클라우드 네이티브 아키텍처는 다음과 같은 특징을 가진다.
•
확장 가능한 아키텍처
◦
시스템의 수평적 확장에 유연
◦
확장된 서버로 시스템의 부하를 분산하여 가용성 보장
◦
시스템 또는 서비스 애플리케이션 단위의 패키지
◦
모니터링
•
탄력적 아키텍처
◦
서비스 생성-통합-배포 단계 및 비즈니스 환경 변화 대응 시간 단축
◦
분할된 서비스 구조
◦
무상태 통신 프로토콜
◦
서비스의 추가와 삭제를 자동으로 감지
◦
변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)
•
장애 격리
◦
특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음
클라우드 네이티브의 핵심요소
최신 디자인
클라우드 네이티브 애플리케이션에 널리 사용되는 디자인 방법은 12-Factor 방식이다. 최근 소프트웨어를 서비스 형태로 제공하는게 일반화 되면서, 웹앱 혹은 SaaS(Software As A Service)라고 부른다. 12-Factor app은 다음과 같은 특징을 가지는 SaaS 앱을 만들기 위한 방법론이다.
•
자동화를 위한 절차를 체계화하여 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.
•
OS에 따라 달라지는 부분을 명확히하고, 실행환경 사이의 이식성을 극대화한다.
•
클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리를 최소화한다.
•
개발 환경과 운영 환경의 차이를 최소하하고 민첩성을 극대화하기 위해 지속적인 배포를 가능하게 한다.
•
툴이나 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up)을 할 수 있다.
12-Factor의 각 요소는 다음과 같다.
요인 | 설명 |
1 - 코드베이스 | 각 마이크로 서비스는 레포지토리에 버전 관리를 위한 코드베이스을 가진다. 다양한 환경에서 배포할 수 있고 버전 제어로 추적하여 형상관리를 위해 코드를 한 곳에서 배포하는 것이 목적이다. |
2 - 종속성 | 각 마이크로서비스는 분리된 종속성을 가지며, 전체 시스템에 영향을 주지 않으면서 변경 내용을 수용할 수 있다. |
3 - 환경설정 | 마이크로서비스 외부에 환경설정 관리 도구를 통해 config를 관리한다. 이를 통해 동일한 배포가 동일한 config가 적용된 환경 간에 전파될 수 있다. |
4 - 지원 서비스 | 데이터 저장소나 캐시, 메세지 브로커 등의 보조 리소스를 주소 지정 가능한 URL을 통해 노출한다. 이를 통해 리소스를 애플리케이션에서 분리하고, 의존성을 줄인 채 여러 마이크로서비스에서 사용할 수 있다. |
5 - 빌드, 릴리즈, 실행 | 각 릴리스는 빌드-릴리스-실행 스테이지마다 고유한 ID 태그를 지정하고 롤백 기능을 지원하여 엄격하게 구분되어야 한다. |
6 - 프로세스 | 각 마이크로서비스는 실행 중인 다른 서비스와 격리된 자체 프로세스에서 실행 되어야한다. 필요한 상태(state)를 저장소나 분산 캐시를 통해 외부화하여, 각 프로세스를 무상태(stateless)로 두어야한다. |
7 - 포트 바인딩 | 각 마이크로서비스는 포트 바인딩을 사용해서 포트에 노출되는 인터페이스 및 기능을 갖추어야 한다. |
8 - 동시성 | 용량을 늘려야하는 경우 스케일 업이 아닌, 동일한 프로세스를 복사하여 수평적으로 스케일 아웃을 한다. 애플리케이션을 동시성을 가지도록 개발하여 스케일 아웃을 클라우드 환경에서 원활하게 수행할 수 있도록 한다. |
9 - 삭제 가능성 | 서비스 인스턴스를 삭제할 수 있어야한다. 빠른 시작과 정상적인 종료를 늘려 시스템을 올바른 상태로 유지한다.(Docker 컨테이너는 기본적으로 이 사항을 충족한다) |
10 - 개발/프로덕션 패리티 | 애플리케이션 수명 주기 동안 환경을 최대한 비슷하게 유지하여, 비용이 많이드는 작업을 예방한다.(Docker의 컨테이너는 동일한 실행 환경을 제공하므로 이 사항을 충족한다) |
11 - 로깅 | 마이크로서비스에서 생성된 로그를 이벤트 스트림으로 처리한다. 이벤트 집계를 사용하여 처리하고, 로그 데이터를 데이터 마이닝/로그 관리 도구로 전파하여 장기 보관 상태로 유지한다. |
12 - 관리 프로세스 | 데이터 정리 또는 컴퓨팅 분석과 같은 운영/관리 작업을 일회성 프로세스로 실행한다. 독립 도구를 사용하여 프로덕션 환경에서 이러한 작업을 호출하지만 애플리케이션과는 별도로 호출되도록 한다. |
여기에 최신 클라우드 애플리케이션 디자인을 반영하는 세 가지 추가 요소도 있다.
요인 | 설명 |
13 - API 우선 | 작성한 코드가 클라이언트나 게이트웨이, 다른 서비스에서 사용된다고 가정하고 모든 항목을 API 서비스로 만든다. |
14 - 원격 분석 | 클라우드에서는 애플리케이션 및 동작을 심층적으로 파악하기 어려우니, 디자인에 모니터링과 도메인별 상태, 시스템 데이터 컬렉션이 포함되어 있는지 확인한다. |
15 - 인증/권한 부여 | ID를 구현하여 인증과 권한 부여를 한다. 퍼블릭 클라우드에서 사용할 수 있는 RBAC(역할 기반 액세스 제어) 기능을 고려한다. |
마이크로 서비스
클라우드 네이티브 시스템은 최신 애플케이션에서 많이 사용되는 마이크로 서비스 아키텍처를 사용한다.
마이크로 서비스 아키텍처는 이벤트나 메세지 큐를 통해 서로 상호작용하는 소규모의 독립 서비스 분산 집합으로 이루어지고, 각 마이크로 서비스는 다음과 같은 공통된 특성을 가진다.
•
각 마이크로 서비스는 더 큰 도메인 컨텍스트 내에서 특정 비즈니스 기능을 구현한다.
•
각 마이크로 서비스는 자율적으로 개발되며 독립적으로 배포할 수 있다.
•
각 마이크로 서비스는 각자의 데이터 저장소, 종속성, 프로그래밍 플랫폼을 캡슐화하여 포함한다.
•
각 마이크로 서비스는 자체 프로세스에서 실행되며, HTTP/HTTPS, gRPC, WebSockets, AMQP와 같은 표준 통신 프로토콜로 통신한다.
마이크로 서비스는 자율 생명 주기가 있어 독립적으로 개발하고 자주 배포할 수 있다. 또한 독립적으로 스케일링하여, 원하는 성능과 서비스 수준에 맞춰 시스템을 구성하여 전반적인 비용을 절약할 수 있다. 마이크로 서비스 아키텍처는 이러한 서비스 민첩성을 가지기 때문에, 클라우드 네이티브 기술에서 사용된다.
컨테이너
컨테이너가 클라우드 네이티브 소프트웨어를 구축할 수 있게 되는 근본 기술이라고 볼 수 있다. 가상의 컨테이너를 띄워서 그 안에 독립된 환경을 제공하여, 그 위에 서비스를 올려 사용할 수 있는 구조이다.
마이크로 서비스의 코드나 종속성, 런타임이 컨테이너 이미지로 패키징되고, 이미지를 통해 컨테이너 인스턴스로 변환하여 사용자에게 독립적인 프로세스 환경을 제공한다.
컨테이너는 다양한 환경에 대한 이식성을 제공하면서도 일관성을 보장한다. 마이크로 서비스의 모든 항목을 단일 패키지로 캡슐화하여 독립된 환경을 제공한다. 여러 컨테이너를 제공하는 업체가 있지만, Docker가 클라우드 네이티브 애플리케이션을 위한 사실상 표준이 되어 사용되고 있다.
Docker와 같은 컨테이너를 실행하는 동안 이미지를 관리하는 도구도 필요하는데, 이런 컨테이너 관리는 컨테이너 오케스트레이터에서 수행된다. 많은 수의 독립된 컨테이너를 사용한다면 오케스트레이션이 필수적으로 동반되어야한다. 오케스트레이터 역시 많은 업체에서 제공하지만, Kubernetes가 사실상 클라우드 네이티브 기술의 표준이 되었다.
지원 서비스
클라우드 네이티브 시스템은 데이터 저장소나 메세지 브로커, 모니터링 등 다양한 보조 리소스에 의존한다. 이러한 서비스를 지원 서비스라고 한다.
AWS와 같은 클라우드 업체에서는 다양한 관리형 백업 서비스 모음을 제공하여, 서비스를 직접 만들 필요없이 가져다가 사용하면 된다. 이를 통해 작업량과 작업 시간을 줄일 수 있지만, 직접 운영하는 것에 비해 성능과 보안, 유지관리의 문제를 해결하는데는 오히려 비용이 많이 들 수 있다.
자동화
IaC(Infrastructure as Code)를 사용하여 애플리케이션의 배포를 자동화 할 수 있다.
•
인프라 자동화
Azure Resouce Manager, Azure CLI와 같은 도구를 사용하여 필요한 클라우드 인프라를 스크립트 작성을 통해 자동화 할 수 있다. 스크립트를 저장하고, 스크립트를 호출하여 다양한 시스템 환경에서 일관적이고 반복 가능한 인프라를 프로비저닝 할 수 있다.
IaC를 사용한 인프라 배포는 반복 가능하며, 누락된 종속성이나 config를 통해 런타임 문제를 미리 방지할 수 있다. DevOps 팀은 이를 통해 애플리케이션과 지원 인프라를 빠르고 안정적이게 제공할 수 있다.
•
배포 자동화
최신의 CI/CD 시스템을 통해 배포 파이프라인을 구축하여, 별도의 빌드 및 전송 단계를 자동화할 수 있다.
일반적으로 CI/CD 파이프라인 배포 단계는 다음과 같다.
1.
개발자에 의해 코드 수정 혹은 새로운 기능 구현
2.
GitHub, Azure DevOps 등 코드 리포지토리에 push
3.
push에 의해 빌드 스테이지 트리거
CI 파이프 라인으로 구현되어 자동으로 애플리케이션 빌드 및 테스트, 패키징
4.
빌드된 이진 파일을 전달받아 외부 애플리케이션 및 환경 config 정보를 적용하여 릴리스 생성
CD 파이프라인으로 구현되어 생성된 릴리스를 배포
5.
배포된 릴리스 실행
배포 과정에서 서버가 중단되는 지점을 없애기 위해 카나리 배포와 블루그린 배포 전략을 선택할 수도 있다.
카나리 배포는 대부분의 사용자가 이전 버전 서비스를 이용하게 두고, 일부 사용자만 새로 릴리즈한 버전의 서비스를 사용하도록 하여 정상 동작을 확인하는 전략이다.
블루그린 배포는 이전 버전의 서비스와 새 버전의 서비스를 동시에 띄운 뒤, 로드 밸런서를 통해 잠시동안 동시에 떠있는 두 버전이 모두 트래픽을 처리하도록 연결하고 이후 블루 그룹의 서비스 인스턴스를 종료하는 전략이다.
