CNA를 가능하게 하는 기술

이전글(클라우드용 어플리케이션은 뭐가 다를까?)에서 CNA(Cloud Native Application)의 필요성과 특성에 대해서 알아보았다.

이번에는 이런 CNA를 가능하게 하기 위한 기술에 대해서 알아보자.
CNA 를 구현하기 위해서는 아래 그림과 같은 6가지의 기술이 필요하다.

• Microservices

이름에서 알 수 있듯이 기능별로 잘게 쪼개서 서비스를 개발하는 것이다.
이런 구조를 MSA(Micro Service Architecture)라고 부른다.
MSA의 반대는 모노리틱 아키텍쳐(Monolithic Architecture)이다.

모노리틱 아키텍쳐는 모든 기능을 하나의 덩어리고 만드는 것이다.
그래서 모노리틱 아키텍쳐로 개발하면 최적의 효율성을 보장할 수는 있지만 하나의 기능에서 발생한 문제가 전체 시스템에 영향을 주게된다.
이때문에 단순한 구조의 어플리케이션에는 적당한 아키텍쳐이지만 복잡한 기능을 가지고 있는 어플리케이션에는 안정성을 떨어뜨리는 구조이다.
반면 MSA는 기능별로 서비스를 분리하여 한 서비스의 오류가 다른 서비스에 영향을 주는 것을 막는다.
대신에 각 서비스간 데이터 통신량이 늘어나서 리소스가 더 많이 소모되고, 공유되는 데이터의 정합성을 맞추기 위한 추가적인 코드 개발이 필요하다는 단점이 있다.

• 12-Factors App

12-Factors App 의 정의에 대해서는 12factor.net 사이트의 머릿말에 다음과 같이 정의되어 있다.

Twelve-Factor app은 아래 특징을 가진 SaaS 앱을 만들기 위한 방법론이다. 

• 설정 자동화를 위한 절차(declarative) 를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.
• OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화 한다.
• 최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.
• 개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
• 툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있다.

12개의 Factor 에 대한 자세한 내용은 12factor.net 사이트의 내용을 참조하기 바란다.

• Multi-tenancy

멀티 테넌시(Multi-tenancy)란 여러 사용자(거주자)를 갖는 아키텍쳐이다.
집에 비유하자면 아파트에 비유할 수 있다.

말이 어려워서 그렇지 우리는 이미 이런 서비스 환경에 익숙해져 있다.
예를 들면 웹메일 서비스의 경우를 보자.
웹메일 서비스는 하나의 웹 어플리케이션이지만 여러 사용자가 각자의 환경속에서 사용하고 있다.
각자의 메일 보관함은 철저하게 분리되어 타인의 메일을 볼 수도 없으며 자신만의 화면이나 메일함들을 생성하여 개인화(Personalized)된 UI를 사용할 수도 있다.
이처럼 하나의 서비스내에서 사용자별로 저장공간과 설정내용 등을 독립적으로 관리한다.
이런 아키텍쳐의 장점은 하나의 시스템을 여러 사용자가 공유하는 구조이기 때문에 비용을 절감할 수 있다.
또한 겉으로는 사용자별로 다르게 보이지만 내부적으로는 하나의 스키마(Schema)를 가지고 있기 때문에 데이터 통합이 쉽다는 것도 장점이다.
하지만 사용자별로 다르게 보여주기 위해서는 서비스를 정교하게 개발해야하고, 만약 버그 발생시 시스템 전체에 영향을 미칠 수 있다는 단점도 존재한다.
게다가 데이터가 통합 관리되기 때문에 보안에도 취약한 구조이다.

• Container

컨테이너 기술과 비교되는 것이 가상화(Virtualization) 기술이다.
이 둘은 겉으로 보기에는 비슷한 면이 있어서 항상 비교가 되곤 한다.
하지만 엄밀히 말하면 컨테이너 기술과 가상화 기술은 전혀 다르다.

가상화 기술은 OS를 통째로 가상화한 것이고, 컨테이너 기술은 OS 위에서 환경을 격리(Isolation) 시킨 것이다.
그래서 OS 가상화처럼 인스턴스 생성시 부팅이라는 과정이 존재하지 않고, OS 자원을 공유하기 때문에 속도도 빠르다.
컨테이너 기술은 각각의 운영환경을 컨테이너라는 곳이 보관하여 서로 격리 시키는 기술이다.
리눅스에는 기본 내장되어 있는 기능이고, 향후 윈도우(Windows)  계열의 OS 도 지원할 예정인 기술이다.

• API

API(Application Programming Interface) 는 프로그램간의 인터페이스 기술이다.
하나의 프로그램이 사용자(User)와 상호작용(Communication)하기 위해서는 UI(User Interface)가 필요하다.
마찬가지로 서로 다른 어플리케이션이 상호작용을 하기 위해서는 API가 필요하다.
API는 사전에 서로 약속된 규칙에 따라 서비스를 요청(Request)하고 응답(Response)하는 구조를 갖는다.
최근에는 REST 형식의 API가 주로 개발되고 있으며 데이터 타입도 JSON 포맷을 주로 사용하여 개발되고 있다.

초기의 API는 패킷(Packet) 형태로 정의되었고, 데이터는 바이너리(Binary) 형태로 개발되었다.
패킷형태의 API는 개발자에 의해서 패킷의 구조가 정의되었다.
그러다 보니 패킷의 구조가 모두 제각각이여서 API 이용에 많은 학습이 필요했었다.
또한 데이터 형태도 바이너리여서 패킷정의 문서가 없으면 내용을 알 수가 없었다.
그래서 나타난 것이 SOAP(Simple Object Access Protocol)이다.
SOAP 은 패킷의 형태를 표준화하기 위해서 등장하였고, 객체(Object)를 직렬화(Serialize)해서 전송할 수 있었다.
이는 패킷형태의 프로토콜에서는 생성하기 어려웠던 계층적인 데이터의 표현도 가능하게 되었다는 것을 의미한다.
또한 XML 포맷으로 SOAP을 정의하는 WSDL을 배포하여 프로토콜 공유도 한층 쉬워졌다.
하지만 다른 언어간 연동시에 데이터가 깨지는 문제들이 발생하여 개발에 많은 노력이 들어가야하는 단점들이 발생하게 되었다.
REST API 는 웹 프로토콜을 사용하여 플랫폼, 개발언어, 디바이스 종류에 상관없이 연동이 쉽게 이루어 질 수 있었고, JSON 포맷 사용으로 데이터의 가독성이 높아졌다.
JSON 포맷은 XML에 비해 경량화(Compact)된 사이즈를 제공하고 있어서 최근에 가장 많이 개발되고 있는 API 형태이다.

• PaaS

CNA는 SaaS 모델용 어플리케이션 이다. 따라서 PaaS 기술의 기반위에서 동작한다.
PaaS 관련된 내용은 "클라우드 컴퓨팅 이해하기"를 참조하기 바란다.