https://www.youtube.com/watch?v=NQcOwOI7nl0&feature=emb_logo
00. Cloud Native의 이해
Devops + CD + MSA + Containers
== Resiliency + Agility + Scalable + Automation + State-less
클라우드 네이티브의 핵심은 어떻게 만들고, 어떻게 배포할지에 있다.
어디에 위치해있고, 어떤 IDC에 있고 IP주소가뭐고.. 이런건 중요하지 않다!!
- Devops, CD, MSA, Containers 가 주 축을 이룸
00-0. 클라우드 서비스를 활용한다는 것
: 컨테이너와 같이 민첩하고 확장가능한 구성요소를 사용해서 재사용 가능한 개별적인 기능을 제공하는 것
- 신축성(Resiliency)
: 서비스가 중단이 되거나 (인스턴스나 앱이 다운) 했을때, 전체적인 장애로 퍼지지 않고 빠르게 복구되는 성질 - 민첩성(Agility)
: 빠르게 배포, 독립적인 운영 - 확장가능성(Scalable)
: 서비스가 수평적으로 scale-out가능하게 하는 것 - 자동화(Automation)
: 배포, 운영, scale-out이 자동화되어 운영에 큰 수고를 들이지 않게 하는 것 - 무상태(State-less)
: 각 서비스의 상태는 state-less
근데 이 특징들이 어떻게 장점이 되는거임?...
01. Devops
"You run it, you build it" / 만들면 운영까지
_ 베르너 보겔스, 아마존 CTO
전통적 모델
- 개발과 운영 조직의 분리 ( DB팀, 배포팀이 따로 있었음 )
- 다른 쪽으로 일을 던진 후에 알아서 처리하라며 잊어버리는 방식
01-0. Devops 문화로의 발전
- 개별팀은 프로젝트 그룹이 아닌 제품(Product)그룹에 소속
- 운영과 제품관리 모두가 포함되는 조직적 구조, 제품팀은 소프트웨어를 만들고 운영하는 데 필요한 모든것을 보유 (DB, 배포, 개발 ... )
( 개발자가 배포를 한다는 의미가 아님, 한 팀 안에 개발자와 운영자가 함께 있어야 한다는 의미임. - 빠른 의사소통 )
02. Twelve-Factors
: Heroku 클라우드 플랫폼 창시자들이 정립한 애플리케이션 개발 원칙 중 유익한 것을 모아 정리한 것.
-> 탄력적(elastic)이고 이식성(portablility)있는 배포를 위한 베스트 프랙티스(Best Prcatices)
02-0. 핵심 사상
- 선언적 형식으로 설정을 자동화해서 프로젝트에 새로 참여하는 동료가 적응하는데 필요한 시간과 비용을 최소화
[ 선언적(무엇을 해야함) <-> 명령적(어떻게 해야함) ] - 운영체제에 구애받지 않는 투명한 계약을 통해, 다양한 실행환경에서 작동할 수 있도록 이식성을 극대화한다
- 현대적인 클라우드 플랫폼 기반 개발을 통해 서버와 시스템 관리에 대한 부담을 줄인다
- 개발과 운영의 간극을 최소화 해서 지속적 배포를 가능케 하고 민첩성 최대화
- 도구, 아키텍쳐, 개발 관행을 크게 바꾸지 않아도 서비스 규모 수직적 확장(scale-up)이 가능
02-1. 12Factor 리스트
*: 이해안가는 부분
1. 코드 베이스: CODEBASE
: 버전 관리되는 하나의 코드베이스가 여러 번 배포된다.
코드베이스와 앱 사이에는 항상 1대1 관계가 성립된다
2. 의존성: DEPENDENCIES
: 앱의 의존관계는 명시적으로 선언되어야 한다.
- 모든 의존 라이브러리는 아파치 메이븐, 그레이들 등의 의존관계 관리 도구를 써서 라이브러리 저장소에서 내려받을 수 있어야 한다.
ex. 녹서스, npm등을 통한 관리
3. 설정: CONFIGURATION
: 설정 정보는 실행 환경에 저장한다
- 설정 정보 (configuration)는 애플리케이션 코드와 엄격하게 분리
- 설정은 배포(스테이징, 프로덕션, 개발환경 등)마다 달라질 수 있는 모든 것 (DB정보, 외부 서비스 인증, 호스트 이름 등)
- 설정을 환경변수(env)에 저장한다
ex. application-local.yml / application-dev.yml (스프링에서 잘 해주고 있음)
4. 백엔드(지원) 서비스: BACKING SERVICES
: 지원 서비스(backing service)는 필요에 따라 추가되는 자원으로 취급.
- 지원 서비스는 데이터베이스, API기반 RESTFul 웹 서비스, SMTP 서버, FTP 서버 등
- 지원 서비스는 애플리케이션의 자원으로 간주한다.
(테스트 환경에서 사용하던 임베디드 SQL을 스테이징 환경에서 MySQL로 교체할 수 있어야 한다.)
5. 빌드,릴리즈, 실행: BUILD, RELEASE, RUN
: 철저하게 분리된 빌드와 실행 단계
코드베이스는 3단계를 거쳐 (개발용이 아닌) 배포 변환된다
- 빌드단계
: 소스코드를 가져와 컴파일 후 하나의 패키지를 만든다 - 릴리즈 단계
: 빌드에 환경설정 정보를 조합한다. 릴리즈 버전은 실행환경에서 운영될 수 있는 준비가 완료되어 있다. 시맨틱 버저닝 등 식벽자가 부여됨. 이 버전은 롤백하는데 사용 (??? 이해 안감) - 실행 단계
: 보통 런타임 이라 불림, 릴리즈 버전 중 하나를 선택해 길행환경위에서 애플리케이션 실행
6. 프로세스: PROCESSES*
: 애플리케이션을 하나 혹은 여러개의 무상태(State-less)프로세스로 실행
7. 포트 바인딩: PORT BINDING*
: 서비스는 포트에 연결해서 외부에 공개한다
실행 환경에 웹 서버를 따로 추가해 줄 필요 없이, 스스로 웹 서버를 포함하고 있어서 완전히 자기 완비적 (self-contained)이다.
( 임베디드 Tomcat을 사용한 애플 띄우기...? war? jar? ) .... 이부분 뭔말인지 모르겠음
8. 동시성: CONCURRENCY*
: 프로세스 모델을 통해 수평적으로 확장(Scale Out)
- 앱은 필요할 때 마다 프로세스나 스레드를 수평적으로 확장해서 병렬로 실행할 수 있어야 함
- 장시간 소요되는 데이터 프로세싱 작업은 스레드풀에 할당해서 스레드 실행기(executor)를 통해 수행되어야 한다
ex. HTTP요청은 서블릿 쓰레드가 처리하고, 시간이 오래걸리는 작업은 워커 쓰레드가 처리해야 한다...?
9. 처분성/폐기가능성: DISPOSABILITY
: 빠른 시작/ 그레이스풀 셧 다운(graceful shutdown)을 통한 안정성 극대화
앱은 프로세스 실행 중에 언제든지 중지될 수 있고, 중지될 때 처리되어야 하는 작업을 모두 수행한 다음 깔끔하게 종료될 수 있다.
가능한 한 짧은 시간 내에 시작되어야 한다
10. 개발/프로덕션 환경 일치: DEV/PROD PARITY
: development, staging, production 환경을 최대한 비슷하게 유지
유의할 세 가지 차이
---시간 차이: 개발자는 변경 사항을 운영환경에 빨리 배포해야 함
---개인 차이: 코드 변경을 맡은 개발자는 운영환경으로의 배포 작업까지 할 수 있어야 하고, 모니터링도 할 수 있어야 한다
---도구 차이: 각 실행 환경에 사용된 기술이나 프레임워크는 동일하게 구성되어야 한다.
11. 로그: LOGS
: 로그를 이벤트 스트림으로 취급. 로컬서버에 저장하지 말고 중앙저장소로 수집
12. Admin 프로세스: ADMIN PROCESSES*
: admin/maintenance작업을 일회 프로세스로 실행
03. HTTP, REST API
HTTP
- 클라이언트의 상태를 갖지 않음 (stateless)
- 각 요청은 자기 완비적(self-contained)
REST vs 그 외 (EJB, SOAP, etc...)
REST API
- 원격자원과 엔터티를 다루는 데 초점
- 동사 대신 명사를, 행위대신 엔터티에 집중
- 기술 표준이 아닌, 아키텍쳐 제약사항
- 상태가 없고 요청이 자기 완비적이기 때문에 서비스도 수평적으로 쉽게 확장가능
04. 기본 지식
