Cloud Native 란
- 클라우드 네이티브의 핵심은 애플리케이션을 어떻게 만들고 배포하는지에 있으며 위치는 중요하지 않다.
- 클라우드 서비스를 활용한다는 것은 컨테이너와 같이 민첩하고 확장 가능한 구성요소를 사용하여
재사용 가능한 개별적인 기능을 제공하는 것을 의미한다.
- 이러한 기능은 멀티 클라우드와 같은 여러 기술 경계 간에 매끄럽게 통합되므로 제공 팀이 반복 가능한 자동화와
오케스트레이션을 사용해서 빠르게 작업 과정을 반복할 수 있다.
- 앤디 맨, Chief Technology Advocate at Splunk
- 신축성 Resiliency
- 민첩성 Agility
- 확장 가능성 Scalable
- 자동화 Automation
- 무상태 State-less
DevOps
- 전통적 모델
- 개발과 운영 조직의 분리
- 다른 쪽으로 일을 던진 후 알아서 처리하라며 잊어버리는 방식
- DevOps
- you run it, you build it. 만들면 운영까지 - 베르너 보겔스, 아마존 CTO
- 개별 팀은 프로젝트 그룹이 아닌 제품 그룹에 소속
- 운영과 제품 관리 모두가 포함되는 조직적 구조,
제품 팀은 소프트웨어를 만들고 운영하는데 필요한 모든 것을 보유
Twelve-Factors
- 12 Factors
- Heroku 클라우드 플랫폼 창시자들이 정립한 애플리케이션 개발 원칙 중 유익한 것을 모아 정리
- 탄력적(elastic)이고 이식성 있는(portability) 배포를 위한 베스트 프랙티스 (Best Practices)
- 핵심 사상
- 선언적 형식을 설정으로 자동화하여 프로젝트에 새로 참여하는 동료가 적응하는 데의 시간과 비용 최소화
- 운영체제에 구애받지 않는 투명한 계약을 통해 다양한 실행환경에서 작동할 수 있도록 이식성 극대화
- 현대적인 클라우드 플랫폼 기반 개발을 통해 서버와 시스템 관리에 대한 부담을 줄인다.
- 개발과 운영의 간극을 최소화하여 지속적 배포 (continuous deployment)를 가능하게 하고 애자일성을 최대화한다.
- 도구, 아키텍쳐, 개발 관행을 크게 바꾸지 않아도 서비스 규모 수직적 확장이 가능하다.
Twelve-Factors - 12가지 제약 조건
Twelve-Factors - 코드 베이스
- 버전 관리되는 하나의 코드베이스가 여러 번 배포된다.
- 코드베이스와 앱 사이에는 항상 1대 1 관계가 성립된다.
Twelve-Factors - 의존성
- 애플리케이션의 의존관계(dependencies) 는 명시적으로 선언되어야 한다.
- 모든 의존 라이브러리는 아파치 메이븐, 그레이들 등의 의존관계 관리 도구를 써서 라이브러리 저장소에서 내려받을 수 있어야 한다.
Twelve-Factors - 설정
- 설정 정보는 실행 환경에 저장한다.
- 설정 정보 (configuration)은 애플리케이션 코드와 엄격하게 분리한다.
- 설정은 배포(스테이징, 프로덕션, 개발 환경) 마다 달라질 수 있는 모든 것
(DB정보, 외부 서비스 인증, 호스트 이름 등)
- 설정을 환경 변수(env)에 저장한다.
Twelve-Factors - 백엔드(지원) 서비스
- 지원 서비스(backing service)는 필요에 따라 추가되는 자원으로 취급한다.
- 지원 서비스는 데이터베이스, API기반 RESTFul 웹 서비스, SMTP 서버, FTP 서버 등
- 지원 서비스는 애플리케이션의 자원으로 간주한다.
- 테스트 환경에서 사용하던 임베디드 SQL을 스테이징 환경에서 MySQL로 교체할 수 있어야 한다.
Twelve-Factors - 빌드, 릴리즈, 실행
- 철저하게 분리된 빌드와 실행 단계
- 코드베이스는 3단계를 거쳐(개발용이 아닌) 배포로 변환된다.
- 빌드 단계 : 소스코드를 가져와 컴파일 후 하나의 패키지를 만든다.
- 릴리즈 단계 : 빌드에 환경설정 정보를 조합한다.
릴리즈 버전은 실행 환경에서 운영될 수 있는 준비가 완료되어 있다.
시맨틱 버저닝 등 식별자가 부여됨. 이 버전은 롤백하는데 사용
- 실행 단계 : 보통 런타임이라 불림. 릴리즈 버전 중 하나를 선택해 실행환경 위에 애플리케이션 실행
Twelve-Factors - 포트 바인딩
- 서비스는 포트에 연결해서 외부에 공개한다.
- 실행 환경에 웹 서버를 따로 추가해줄 필요 없이 스스로 웹 서버를 포함하고 있어 완전히 자기 완비적(self-contained) 이다.
Twelve-Factors - 동시성 ( concurrency )
- 프로세스 모델을 통해 수평적으로 확장한다.
- 애플리케이션은 필요할 때 마다 프로세스나 스레드를 수평적으로 확장하여 병렬로 실행할 수 있어야 한다.
- 장시간 소요되는 데이터 프로세싱 작업은 스레드풀에 할당에서 스레드 실행기(executor)를 통해 수행되어야 한다.
- 예를 들어, HTTP 요청은 서블릿 스레드가 처리하고, 시간이 오래 걸리는 작업은 워커 스레드가 처리해야 한다.
Twelve-Factors - 처분성 ( Disposability )
- 빠른 시작과 그레이풀 셧다운(graceful shutdown)을 통한 안정성 극대화
- 애플리케이션은 프로세스 실행 중에 언제든지 중지될 수 있고, 중지될 때 처리되어야 하는 작업을 모두 수행한 다음 깔끔하게 종료될 수 있다.
- 가능한 짧은 시간 내에 시작되어야 한다.
Twelve-Factors - dev/prod 일치
- development, staging, production 환경을 최대한 비슷하게 유지
- 개발 환경과 운영 환경을 가능한 동일하게 유지하는 짝맞춤(parity)를 통해 분기(divergence)를 예방할 수 있어야 한다.
- 유념해야 할 세 가지 차이
- 시간 차이 : 개발자는 변경 사항을 운영환경에 빨리 배포해야 한다.
- 개인 차이 : 코드 변경을 맡은 개발자는 운영 환경으로의 배포 작업까지 할 수 있어야 하고, 모니터링도 해야 한다.
- 도구 차이 : 각 실행 환경에 사용된 기술이나 프레임워크는 동일하게 구성되어야 한다.
Twelve-Factors - 로그
- 로그는 이벤트 스트림으로 취급한다.
- 로그를 stdout에 남긴다.
- 애플리케이션은 로그 파일 저장에 관여하지 말아야 한다.
- 로그 집계와 저장은 애플리케이션이 아니라 실행 환경에 의해 처리되어야 한다.
- 엘라스틱 서치 -> 로그를 중앙으로 모아서 -> 키바나로 조회..
Twelve-Factors - Admin 프로세스
- admin / maintenance 작업을 일회성 프로세스로 실행
- 실행되는 프로세스와 동일한 환경에서 실행
- admin 코드는 애플리케이션 코드와 함께 배포되어야 한다.
애플리케이션 호출 - HTTP, REST API
- HTTP
- 클라이언트의 상태를 갖지 않음 stateless
- 각 요청은 자기 완비적 self-contained
- REST vs 그 외 (EJB, SOAP, etc ...)
- REST API
- 2000년 로이 필딩 박사가 소개 (HTTP 명세 writer)
- 원격 자원(resource)와 엔티티(Entity)를 다루는데 초점
- 동사 대신 명사를, 행위 대신 엔티티에 집중
- REST는 기술 표준이 아닌 아키텍쳐 제약사항
- 상태가 없고 요청이 자기 완비적이기 때문에 서비스도 수평적으로 쉽게 확장 가능