PaaS-TA 교육 1일차

1일차
12/10 - Raviloi 발표
- Dynamic Router
- 애플리케이션만 올리면 기능을 통해서 인터넷으로 바로 서비스가 가능
PaaS-TA는 Iaas+Container 기술 / 특정 VM에 사용자의 application이 배포가 되고 이 형상은 container로 / VM이 전부 사용되면 IaaS가 VM을 또 만듦(diego cell)
container는 하나의 어플리케이션을 구동(garden)

VM-Garden-컨테이너 생성-사용자 어플리케이션 삽입-실행-(코드+실행+옵션)Droplet 전달-Blobstore (이미지)저장-재배포
왜 컨테이너를 저장했다가 다시 배포할까?
- 클라우드는 가용성을 보장하기 떄문에 문제가 생겼을 때 대처하기 위해서
- 특정 시점에 있는 형상을 기록하기 위해서
State의 개념이 있는 Data는 Container에 종속되면 안된다 - 이 것을 Stateless라고 함
서버가 죽었을 경우를 대비해야하며 이 것은 자동으로 배포해주고, 자동으로 복구해주는 기능을 가지고 있어야 한다.
재기동이되어도 문제가 없어야 한다.

논리적인 개념
Org & Space
- Space라는 공간에만 Application이 배포가 됨
- Space가 없는 User는 Application을 배포할 수 없음 --- Rule

Application & Service

- Application은 Container의 환경변수를 독점
- 다른 Application은 나의 환경변수를 볼 수 없고, 나만의 저장소로 사용할 수 있음
- Legacy 환경에서 만든 Application을 PaaS-TA로 바꾸려면 system 변수만 가져오면 됨
- Application의 범위 -> micro service architecture로 배포하는 것을 권장

BOSH(배포+관리) - VM Life Cycle Management Tool
- VM을 만들기 위해 필요한 것 : Stemcell(OS+BOSH Agent), Release(실제 사용되는), Deployment(정의 명세서)
- VM을 List화하여 DB로 가지고 있으며 State도 알고있음(Health Check)

Cloud Foundry
- Linux Foundry 하위재단
- Cloud Foundry Application Runtime (CFAR)
- Cloud Foundry Container Runtime (CFCR)
Kubernetes의 단점은 Serverside의 배포가 복잡함 - 이를 BOSH로 해결
- CFCR+CFAR = EIRINI
- QUARKS = PaaS-TA를 VM으로 배포하는 것이 아닌 Container로 배포(K8S)
- 총 4가지 전략으로 제품 다변화

Cloud Native Application
- Device에 종속된 Program
- Cloud에서 실행되는 Application의 핵심은 "서비스"
가용성이 보장되며 실행 중단이 되면 안되며 금전적인 가치를 가지고 있어야 함
- 최소의 상태 컴포넌트들이 격리된 상태의 micro service로 구성되며, 각각의 서비스는 분산되고,
탄력적이며 수평적 확장성 있는 시스템으로 구성됨.
- Legacy 환경에서 옮긴 Application은 구동시에는 문제가 없지만 문제점이 생겼을 때 문제임.

Monolith
- PPT상 표기가 조금 다름(Microservices로 적혀있음)
- 이 architecture의 문제점 때문에 Microservice가 나오게 됨
- microservice : patch가 쉽고 scale up/down이 쉽다
blue/green deployment
하나의 서비스는 여러 언어로 구성이 가능해짐(polyglot)

DDD(Domain Driven Design)
- Pivotal에서는 중요하게 생각하는 개념
- Event Storming -> Domain Events, Command, Aggregate 관계 도출
- 시간에 따른 Event 나열 및 backlogitem 도출
- 도메인별 수행 업무 정리
- Boris diagram 작성 : 액션에 대한 정의
- snap-E 작성 : Item별 API, Data, Story, Risk, UI 등을 정의
- 도메인별로 수행해야하는 업무 명료화 후 구현 시작
- https://miro.com 같은 자산화
>> 기술사 준비한다면 알아야 하는 내용

API 이외의 Cloud Native Tools
- Cloud Native tools
- Config Server
- 코드와 설정 분리
- 환경변수의 암호/복호화 지원
- 애플리케이션 재시작없이 설정 반영
- Dynamic server discovery(registration server) - eureka
- Server client 주소
- 서버 자동 검색/추가/삭제
- API 호출하는 쪽에서 이름으로만 호출 가능
- circuirt breaker
- 각 서비스들가의 실패율을 통한 서비스 가용성 향상
- 자동으로 장애 감지
- ??
- Loadbalancer, service mash, sid car etc.
- 마이크로 서비스 아키텍쳐 네트워크 설정
- 코드단계의 네트워킹정의가 아닌 설정
- 에러시 원인을 찾기 쉬워짐
- 개발 원칙(12 Factors)
- Cloud Application 개발을 위해서 지켜야하는 원칙들