클라우드용 어플리케이션은 뭐가 다를까?

이전글(클라우드 컴퓨팅 이해하기)에서 클라우드 컴퓨팅의 개념을 이해해보았다.

그렇다면 몇가지 의문이 생길 것이다.
SaaS 모델로 클라우드 컴퓨팅이 발전하긴 할텐데 그게 말처럼 쉬운 것일까?
가상화(Virtualization) 기술이 발전하면서 IaaS 에서 PaaS 로는 발전할 수 있었다지만 PaaS에서 SaaS 로 발전하려면 또 어떤 기술이 필요할까?

이런 궁금증을 해결하려면 먼저 클라우드 네이티브 어플리케이션(Cloud Native Application)을 이해해야 한다.
아래 그림은 어플리케이션의 유형과 발전단계를 표현한 그림이다.

• Native Application

PC(Personal Computer) 의 도입으로 모든 프로그램은 PC 에서 실행되어야 했었다.
그래서 처음에 만들어진 어플리케이션(Application)은 돌아갈 PC 환경에 맞도록 패키징(Packaging) 되어 배포되었다.
그러다보니 동일은 어플리케이션도 Window용 Linux용으로 다르게 패키징 되었고, 같은 Window용 어플리케이션도 Window7, Window10 등으로 모두 다르게 패키징되어 배포되었다.
이렇게 패키징되어 배포되었던 어플리케이션을 Native Application(네이티브 어플리케이션)이라고 한다.

• Web Application

PC 환경에 인터넷이 결합하면서 나타난 것이 웹 어플리케이션(Web Application)이다.
웹 어플리케이션은 원격에 있는 서버(Server)에서 어플리케이션이 돌아가고, PC는 인터넷을 통해 서버로부터 정해진 서비스를 제공받는 형태이다.
그래서 PC 의 환경에 따라 어플리케이션을 따로 배포할 필요가 없고, 어플리케이션의 업그레이드도 손쉬운 장점이 있다.
하지만 인터넷이 안 될경우 사용할 수 없고, 인터넷 속도가 느려질 경우 실행 속도가 느려진다는 단점도 있다.
그리고 어플리케이션 사용자는 서버의 서비스를 일방적으로 받는 경우가 많아서 네이티브 어플리케이션(Native Application)에 비해 수동적인 면이 많다.

• Cloud Native Application

클라우드 컴퓨팅 환경이 빠르게 발전하면서 등장한 형태가 클라우드 네이티브 어플리케이션(CNA)이다.
CNA는 SaaS 모델의 환경에서 동작하는 어플리케이션이다.
그래서 인터넷을 통해 서비스 되어진다는 점에서는 웹 어플리케이션과 유사하다.
하지만 CNA는 사용자 스스로 어플리케이션의 설치하고 서비스를 컨트롤(Control)할 수 있다는 점에서 큰 차이를 보인다.


위의 3가지 어플리케이션 유형이 거의 20년 주기로 컴퓨팅 환경의 변화에 맞춰서 새롭게 등장한 것을 볼 수 있다.
현재가 웹 어플리케이션에서 CNA로 변해가는 과정이라고 이해하면 될 것 같다.


이번에는 CNA의 등장배경을 사업(Business) 환경의 관점에서 알아보자.
현재의 사업 환경은 불확실성이 높은 환경이다.
이렇게 불확실성이 높아진 환경에서 사업을 성공으로 이끌기 위해 어플리케이션도 다음과 같은 요구사항을 충족시켜야 한다.

• Speed

신속한 서비스의 배포 및 회수는 비즈니스의 불확실성을 극복할 수 있는 유일한 해법이라고 할수 있다.
또한 잘못된 배포로 인한 손해도 새로운 버젼의 즉각적인 배포로 최소화 할 수 있다.

• Safety

하나의 서비스에서 발생된 장애가 다른 서비스에 전달되지 않아야 한다.
설령 장애가 발생했더라도 빠르게 복구되어 사용자들이 장애발생을 인지하지 못하도록 해야 한다.

• Scalability

서비스 사용량에 대한 과도한 예측으로 발생할 수 있는 자원낭비나 반대로 부족한 사용량 예측으로 인한 서비스 품질 저하등의 문제가 발생하지 않아야 한다.
이를 위해 서비스의 수평적인 확장은 물론 이를 동적으로 적용할 수 있어야 한다.

• Diversity

사용자들이 다양한 채널로 접근할 수 있도록 서비스가 제공 되어야 한다.
최대한 많은 사용자에게 서비스의 기회가 주어져야 한다.

위와 같은 비즈니스 요구사항을 충족하기 위해서 CNA 는 다음과 같은 특징들을 가지고 있어야 한다.

• Services

각각의 서비스는 서로 느슨하게 결합되어 있고, API 를 통해 실행되고 관리되어야 한다.

• Handling Failures

장애가 발생했을 경우 이를 제어할 수 있어야 한다.

• Horizontal Scalability

수평으로 확장이 가능하도록 설계되어야 한다.

• Asynchronous Processing

서비스 요청은 비동기적으로 처리되어야 하고, 큐(Queue)를 사용하여 기능들을 분리해야 한다.

• Stateless Model

모든 데이터는 어플리케이션 코드와 분리 되어야하고, 여러 사용자가 동시에 실행할 수 있어야한다.

• Minimize Human Intervention

사용자의 개입을 최소화 할 수 있도록 신속하고 반복적인 배포(Deploy)가 가능해야 한다.
장애가 발생할 경우 장애를 탐지하고, 손실된 인스턴스(Instance)는 제거한다.
그리고 새로운 노드를 빠르게 생성 할 수 있어야 한다.