[Cloud] 클라우드 네이티브 애플리케이션(Cloud Native Application)

플랫폼

• 애플리케이션을 만들고 운영하는 것을 돕는 기능의 집합체를 의미한다.
• 애플리케이션의 비즈니스 요구사항을 충족시키는 데 필수적이지 않은 작업들을 자동화하여 비즈니스 가치를 차별화할 수 있는 기능 개발에 집중할 수 있다.
• 플랫폼을 구축할 때는 반복 가능한 관행(Practice)을 자동화하는 도구를 만들게 되며, 관행은 가치있는 아이디어를 계획으로 바꾸어줄 수 있는 제약 조건으로부터 도출된다.
• 제약 조건으로부터 도출되는 관행은 약속(Promise)의 모음이다.

아마존닷컴 플랫폼의 사례

아이디어 :

• 소프트웨어 컴포넌트들을 격리시키면 시스템의 일부를 더 빠르고 독립적으로 전달할 수 있게 된다.

제약조건 :

• 소프트웨어 컴포넌트는 독립적으로 배포 가능한 서비스로 만들어져야 한다.
• 서비스 안에 있는 모든 비즈니스 로직과 데이터는 캡슐화되어야 한다.
• 서비스 외부에서 데이터베이스로의 직접 접근이 허용되어서는 안된다.
• 다른 서비스에서 비즈니스 로직에 접근할 수 있도록 웹 인터페이스를 제공해야 한다.

관행 :

• 애플리케이션을 운영하는 데 필요한 인프라스트럭처를 프로비저닝해주는 셀프 서비스 인터페이스를 제공한다.
• 애플리케이션을 하나의 꾸러미로서 패키징하고 셀프 서비스 인터페이스를 통해 운영 환경에 배포한다.
• 데이터베이스를 서비스의 형태로 애플리케이션에 제공하고 셀프 서비스 인터페이스를 통해 프로비저닝한다.
• 애플리케이션은 데이터베이스 접근에 필요한 정보는 데이터베이스가 명시적으로 서비스로서 바인딩된 이후에만 외부 환경 변수로서 제공받는다.
• 애플리케이션은 자신이 의존하는 외부 서비스의 위치를 파악할 수 있게 해주는 서비스 레지스트리를 제공받는다.

확장성

• 확장(Scale)은 가치를 만들어내는 비용에 대한 함수

위험성

• 위험(Risk)은 가치를 떨어뜨리는 예측 불가능성의 수준

신뢰도

• 비용을 통해서 얼마만큼의 가치를 만들어낼 수 있는지를 신뢰할 수 있는 수준으로 예측하는 것

넷플릭스 사례

• 수직적 확장만 가능한 인프라스트럭처와 단일 장애 지점의 한계 극복
• 수직적 확장만 가능한 관계형 데이터베이스에서 수평적 확장이 가능한 오픈소스 분산 NoSQL 데이터베이스인 아파치 카산드라로의 이관
• AWS로의 애플리케이션 이관
• 50개 이상의 사내 프로젝트를 오픈소스로 공개했고 이후 넷플릭스 OSS라는 브랜드까지 만들어냈다.

마이크로서비스(Microservice)

• 개발팀이 개발 조직을 스스로 구성할 수 있는 권한과 함께 특정 비즈니스 범위를 담당하는 애플리케이션을 만드는 능력을 갖게 하는 것
• 모듈성과 단순성, 느슨한 결합은 제대로 설계된 일체형 애플리케이션에서도 그대로 존재하지만 개발 이력에서 차이가 있다.
• 새로운 운영 모델인 데브옵스(DevOps) 도입함으로서 개별 팀은 전통적인 프로젝트 그룹 구조에서 벗어나서 제품 그룹에 소속된다.

클라우드 네이티브 자바

• 스프링(Spring)과 넷플릭스 OSS를 사용한 회복성 있는 분산 시스템 구축
• 지속적 전달을 사용하는 클라우드 파운드리 기반 클라우드 네이티브 애플리케이션 운영

12요소 방법론

• 허로쿠(Heroku) 클라우드 플랫폼의 창시자들이 정립한 애플리케이션 개발 원칙 중 유익한 것을 모음
• 선언적 형식으로 설정을 자동화해서 프로젝트에 새로 참여하는 동료가 적응하는 데 필요한 시간과 비용을 최소화함
• 운영체제에 구애받지 않는 투명한 계약을 통해 다양한 실행 환경에서 작동할 수 있도록 이식성의 극대화함
• 현대적인 클라우드 플랫폼 기반 개발을 통해 서버와 시스템 관리에 대한 부담을 줄임
• 개발과 운영의 간극을 최소화해서 지속적 배포를 가능하게 하고 애자일성을 최대화함
• 도구, 아키텍처, 개발 관행을 크게 바꾸지 않아도 서비스 규모의 수직적 확장이 가능함

1. 코드베이스(Codebase)

• 버전 관리되는 하나의 코드베이스가 여러 번(개발, 품질보증, 스테이징, 운영) 배포된다.
• 소스 코드 저장소에는 의존관계를 나타내는 매니페스트(Manifest)를 가지고 있는 하나의 애플리케이션이 포함되어 있어야 하며, 실행 환경이 달라질 때마다 애플리케이션을 다시 컴파일하거나 패키지 구조를 변경할 필요가 없어야 한다.

2. 의존관계(Dependencies)

• 의존관계는 명시적으로 표시하고 격리한다.
• 애플리케이션에 필요한 모든 의존 라이브러리는 아파치 메이븐 같은 의존관계 관리 도구를 써서 라이브러리 저장소에서 내려받을 수 있어야 한다.

3. 설정(Config)

• 설정 정보는 실행 환경에 저장한다.

4. 지원 서비스(Backing service)

• 자원 서비스는 필요에 따라 추가되는 자원으로 취급한다.
• 자원 서비스는 12요소 애플리케이션이 일반적인 작업을 수행할 때 사용하는 데이터베이스, API 기반 RESTful 웹 서비스, SMTP 서버, FTP 서버 등의 서비스이다.
• 소스 코드를 변경하지 않고도, 테스팅 환경에서 사용하던 임베디드 SQL을 스테이징 환경에서는 MySQL로 교체할 수 있어야 한다.

5. 빌드, 릴리스, 실행(Build, release, run)

• 빌드와 릴리스, 실행 단계는 엄격히 분리한다.
• 애플리케이션 소스 코드를 가져와서 필요하다면 컴파일 한 후에 하나의 패키지(Build)로 만든다.
• 릴리스 단계는 빌드에 환경설정 정보를 조합한다.
• 배포를 위해 생성된 릴리스 버전은 실행 환경에서 운영될 수 있는 준비가 완료되어 있으며, 시맨틱 버저닝(Semantic versioning) 또는 타임 스탬프를 통해 유일한 식별자가 부여된다.
• 릴리스 버전은 특정 디렉토리에 저장되어 나중에 릴리스 관리 도구를 통해 이전 버전으로 롤백하는 데 사용된다.
• 실행 단계는 보통 런타임이라고 부르며, 릴리스 버전 중에 하나를 선택해서 실행 환경 위에서 애플리케이션을 실행한다.

6. 프로세스(Processes)

• 애플리케이션은 무공유(share-nothing) 아키텍처 위에서 하나 이상의 무상태(Stateless) 프로세스로 실행한다.
• 애플리케이션은 지원 서비스(데이터베이스와 객체 스토어(Object store)를 통해서만 영속성(Persistence)을 가질 수 있다.

7. 포트 바인딩(Port binding)

• 서비스는 포트에 연결해서 외부에 공개한다.
• 12요소 애플리케이션은 웹 서비스를 만들 때 실행 환경에 웹 서버를 따로 추가해줄 필요 없이 스스로 웹 서버를 포함하고 있어서 완전히 자기 완비적(Self-contained)이다.
• 각 애플리케이션은 특정 HTTP 포트에 연결되어 외부에 공개되고, 라우팅 계층은 외부에 공개된 호스트 이름으로 유입되는 요청을 HTTP 포트 기준으로 분류해서 해당 애플리케이션 실행 환경으로 전송한다.

8. 동시성(Concurrency)

• 프로세스 모델을 통해 수평적으로 확장한다.

9. 처분성(Disposability)

• 빠른 시작과 깔끔한 종료로 견고함을 극대화한다.

10. 개발/운영 짝맞춤(Dev/prod parity)

• 개발, 스테이징, 운영은 가능한 한 동일하게 유지한다.

11. 로그(Logs)

• 로그는 이벤트 스트림으로 취급한다.
• 애플리케이션은 로그 파일 저장에 관여하지 말아야 한다.
• 로그 집계와 저장은 애플리케이션이 아니라 실행 환경에 의해 처리되어야 한다.

12. 관리 프로세스(Admin Process)

• 관리 작업을 일회성 프로세스로 실행한다.
• 데이터베이스 마이그레이션이나 일회성 스크립트 등이 애플리케이션 소스 코드에 포함될 수 있는데, 이를 관리 프로세스라고 한다.
• 관리 프로세스는 애플리케이션의 실행 환경에서 실행되어야 하고, 스크립트는 실행 환경 간 일관성 유지를 위해 소스 코드 저장소에 포함되어야 한다.