cloud native는
- cloud
- devops
- container
로 구성된다. 이것을 운영하는 시스템 플랫폼 중 하나가 kubernetes (쿠버네티스) 다.
클라우드는 컴퓨터를 구매하지 않고 컴퓨터 리소스를 구매하는 것.
데브옵스 운동은 개발자와 운영자가 서로 협업하고 다양하고 복잡해진 시스템의 신뢰도와 정확성에 대한 책임을 공유하는 것을 뜻함. 여기서 운영은 서버운영을 뜻함 → 줄여서 개발자와 운영자가 협업하는 것
데브옵스란
- Culture (문화)
- Automation (자동화)
- Measurement (측정)
- Sharing (공유)
이다 (줄여서 CAMS) - 브라이언 도슨
데브옵스 운동은 소프트웨어 개발 기술을 운영에 도입하는 것
Infrastructure as code(코드형 인프라) 개념에선
- 운영자가 물리적으로 서버를 건드리지 않고 클라우드를 자동 배포하도록 코딩
- 개발자는 시스템이 망가지지 않게 코딩하는 법을 배워야 함
컨테이너와 VM(Virtual Machine)의 차이점 - VM은 최적화하지 않고 시스템 그대로 덤프 뜨는거라 이미지가 크다. 실행하려면 CPU 위에 에뮬레이터가 떠 있어야하고 이로인해 속도가 느리다.
컨테이너는 바로 CPU위에서 실행
컨테이너는
- 배포 및 패키지 단위
- 재사용 단위 - 하나의 컨테이너 이미지가 여러 서비스에서 사용가능
- 스케일링 단위
- 리소스 할당 단위 - 요구조건에 맞는 리소스가 있다면 실행가능
컨테이너는 오직 OS Kernel (운영체제 커널)에만 의존된다 (== dependancy가 커널에만 있다)
운영자는 직접 시스템, 운영체제를 건드리지 않고 Container Orchestrator를 사용한다.
컨테이너 오케스트레이터는
- Scheduling (스케줄링)
- Orchestration (오케스트레이션)
- Management Cluster (클러스터 관리)
가 일반적인 구성이다
스케줄링은 리소스를 관리하고 가장 효율적인 워크로드 할당을 의미 (예약된 작업을 실행하는 스케줄링이 아님)
오케스트레이션은 컨테이너의 역할을 조정하고 나열
클러스터 관리는 여러 서버를 신뢰할 수 있고 장애가 허용되는 그룹으로 통합하는 것
대표적인 컨테이너 오케스트레이터는 쿠버네티스
쿠버네티스를 잘 쓰지 않는 App - 데이터베이스, AWS 람다 같은 Faas
Fass랑 Container를 Funtainers (펀테이너) 라고 한다. 미래에는 이렇게 변할듯? 실제로 Knative가 이걸 위해 개발되는 중
클라우드 네이티브의 특징
- 자동화 : 사람이 배포 안한다는 것
- 유비쿼터스와 유연성 : 유비쿼터스라고 부르는게 맞나? 이 클러스터 실행(또는 메모리를 잡던가 여튼 마이크로서비스가 뭔가 하는것)하다 저 클러스터 실행하는 것
- 탄력성과 확장성 : 하나 뻗어도 시스템은 안죽음
- 역동성 : 위와 비슷. 배포를 카나리아로 할 수 있다는 것
- 관측가능성 : 모니터링 쉬움
- 분산
- 클라우드 네이티브 ≠ 마이크로서비스
운영팀 → (Developer Productivity Engineering Team)개발자 생산성 엔지니어링팀 줄여서 DPE. 중앙 인프라를 맡는 팀
각 팀에는 Site Reliability Engineer (사이트 신뢰성 엔지니어) 줄여서 SRE 가 하나씩 들어감
내가 보기에는 팀과 업부의 배치가 달라질 뿐 지금 인프라 또는 운영 팀에서 하는 일들의 일정부분을 개발자에게 넘기고 클라우드 네이티브를 다루는 것을 집중하는 팀으로 변한다 이런 뜻 같다. 결국 운영팀은 이름과 업무가 약간 바뀔 뿐.
아마 저자는 마지막에 한 말은 개발자가 없어지고 모두가 엔지니어가 되야 한다는 소리를 하고 싶었던듯하다