[Spring Cloud 를 활용한 MSA 기초] 3. Cloud Native 이해

3. Cloud Native 이해

---

youtu.be/NQcOwOI7nl0

---

Cloud Native 란

• '클라우드 네이티브'의 핵심은 애플리케이션을 어떻게 만들고 배포하는지에 있으며 위치는 중요하지 않다
• 클라우드 서비스를 활용한다는 것은 컨테이너와 같이 민첩하고 확장 가능한 구성 요소를 사용해서 재사용 가능한 개별적인 기능을 제공하는 것을 의미한다
  이러한 기능은 멀티 클라우드와 같은 여러 기술 경계 간에 매끄럽게 통합되므로 제공 팀이 반복 가능한 자동화와 오케스트레이션을 사용해서 빠르게 작업 과정을 반복할 수 있다
  • 앤디 맨, Chief Technology Advocate at Splunk

• 신축성(Resiliency)
• 민첩성(Agility)
• 확장 가능성(Scalable)
• 자동화(Automation)
• 무상태(State-less)

출처: https://www.itworld.co.kr/news/109679

---

DevOps

• 전통적 모델
  • 개발과 운영 조직의 분리
  • 다른 쪽으로 일을 던진 후에 알아서 처리하라며 잊어버리는 방식
• DevOps
  • You run it, you build it. 만들면 운영까지 - 베르너 보겔스, 아마존 CTO
  • 개별 팀은 프로젝트 그룹이 아닌 제품(Product) 그룹에 소속
  • 운영과 제품 관리 모두가 포함되는 조직적 구조, 제품 팀은 소프트웨어를 만들고 운영하는 데 필요한 모든 것을 보유

---

Twelve-Factors

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

---

The Twelve Factors - 12가지 제약 조건

#팩터(영어)팩터(한국어)설명

1	Codebase	코드베이스	단일 코드베이스. 버전 관리되는 하나의 코드베이스와 다양한 배포 개발/테스트/ 운영서버(인스턴스)는 동일한 코드 기반이어야 함
2	Dependencies	의존성	명시적으로 선언되고 분리된 의존성. 필요한 의존성을 애플리케이션과 함께 담음
3	Config	설정	환경설정은 분리하여 외부에 보관 소스코드(코드베이스)는 하나, 환경(개발/테스 트/운영)에 따라 설정만 바꿔야 함
4	Backing Services	백엔드 서비스	백엔드 서비스를 연결된 리소스로 취급. URL을 통해 접근(바인딩)되어야 함
5	Build, release, run	빌드, 릴리즈, 실행	분리된 빌드와 실행 단계를 가져야 함
6	Stateless process	무상태 프로세스	애플리케이션을 하나 혹은 여러개의 무상태 프로세스로 실행 상태는 외부저장소 에 보관
7	Port binding	포트 바인딩	포트 바인딩을 사용해서 서비스 노출 별도의 웹서버를 두지 않고 자기완결적으로 서비스 제공
8	Concurrency	동시성	프로세스 모델을 사용한 확장(scale out) 프로세스가 복제를 통해 확장될 수 있 게 설계해야 함
9	Disposability	폐기 가능	빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화
10	Dev/prod parity	dev/prod 일치	development, staging, production 환경을 최대한 동일하게 유지
11	Logs	로그	로그를 이벤트 스트림으로 취급 로컬서버에 저장하지 말고 중앙저장소로 수집
12	Admin processes	Admin 프로세스	admin/maintenance 작업을 일회성 프로세스로 실행

출처: https://zetawiki.com/wiki/12_%ED%8C%A9%ED%84%B0_%EC%95%B1

---

Twelve-Factors - 코드 베이스

• 버전 관리되는 하나의 코드베이스가 여러 번 배포된다
• 코드베이스와 앱 사이에는 항상 1대1 관계가 성립된다

---

Twelve-Factors - 의존성

• 애플리케이션의 의존관계(dependencies) 는 명시적으로 선언되어야 한다
• 모든 의존 라이브러리는 아파치 메이븐, 그레이들 등의 의존관계 관리 도구를 써서 라이브러리 저장소에서 내려받을 수 있어야 한다

dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web')
    implementation('org.springframework.boot:spring-boot-starter-actuator')
    implementation('org.springframework.cloud:spring-cloud-starter-netflix-eureka-client')
    implementation('io.micrometer:micrometer-registry-prometheus')
    compileOnly('org.projectlombok:lombok')
    testImplementation('org.springframework.boot:spring-boot-starter-test')
}

---

Twelve-Factors - 설정

• 설정 정보는 실행 환경에 저장한다
• 설정 정보(configuration)는 애플리케이션 코드와 엄격하게 분리
• 설정은 배포(스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것(DB정보, 외부 서비스 인증, 호 스트 이름 등)
• 설정을 환경 변수(env) 에 저장한다

application-local.yaml

datasource.main:
  url: jdbc:h2:mem:main;DB_CLOSE_ON_EXIT=FALSE
  driver-class-name: org.h2.Driver
  username: sa
  password:

application-dev.yaml

datasource.main:
  url: jdbc:log4jdbc:oracle:thin:@XXXXX:TMALL
  driver-class-name: net.sf.log4jdbc.sql.jdbcapi.DriverSpy
  username: user
  password: password

---

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년 로이 필딩(Roy Fielding) 박사가 소개(HTTP 명세 writer)
  • 원격 자원(resource) 와 엔티티(Entity) 를 다루는 데 초점
  • 동사 대신 명사를, 행위 대신 엔티티에 집중
  • REST 는 기술 표준이 아닌 아키텍처 제약사항
  • 상태가 없고 요청이 자기 완비적이기 때문에 서비스도 수평적으로 쉽게 확장될 수 있다