Search

[스터디] Docker & Kubernetes Study #1

요약

모노리스 애플리케이션은 구축하기 쉽지만, 시간이 지남에 따라 유지 관리하기가 어렵고 확장이 어려움
마이크로서비스 기반 어플리케이션 아키텍처는 각 구성요소의 개발을 용이하게 하지만, 하나의 시스템으로 작성되록 배포하고 구성하기 어렵다.
리눅스 컨테이너는 가상 머신과 동일한 이점을 제공하지만 훨씬 더 가볍고, 하드웨어 활용도를 높일 수 있도록 한다
도커는 OS 환경과 함께 컨테이너화 된 어플리케이션을 좀 더 쉽고 빠르게 프로바이저닝 할 수 있도록 지원해 기존 리눅스 컨테이너 기술을 개선했다
쿠버네티스는 전체 데이터 센터를 애플리케이션 실행을 위한 컴퓨팅 리소스로 제공한다
개발자는 시스템 관리자의 도움 없이도 쿠버네티스로 애플리케이션을 배포할 수 있다
시스템 관리자는 쿠버네티스가 고장 난 노드를 자동으로 처리하도록 함으로서 편하게 잠을 잘 수 있다
모노레포
전체가 하나의 운영체제 프로세스에서 실행, 하나의 개체로 개발, 배포 관리 되어야 함
상호의존성의 제약이 커지면서 전체 시스템의 복잡성이 증가 → 품질 저하
릴리즈할 때 마다 전체 시스템을 패키징해서 운영팀에 넘겨주는 방식 → 릴리즈 사이클 느려짐
운영팀은 배포하고 모니터링.
마이크로 서비스
독립적으로 실행되는 더 작은 구성 요소
서로 분리되어 있어서, 각 어플리케이션 별로 개발, 배포, 업데이트 확장할 수 있음
급변하는 요구사항을 만족할 수 있도록, 신속하게 자주 구성 요소를 변경할 수 있다.
단, 구성요소가 많아지만 배포 조합의 수가 증가하고, 구성요소간의 상호 종속성 수가 늘어나면서 배포 관련 결정이 어려워진다.
쿠퍼네티스가 등장한 이유
여러 마이크로서비스가 개발되면서, 전체 시스템을 월활하게 구성, 관리, 유지하는 일이 점점 어려워짐
리소스 활용율을 높이고, 하드웨어 비용을 낮추고, 적재적소에 애플리케이션을 배치하는 것이 어려움
구성 요소의 서버 배포를 자동으로 스케줄링 하고 구성, 관리, 장애처리를 포함한 자동화 수행
쿠버네티스란?
개발자가 운영팀의 도움 없이도 자주 배포 가능
운영팀은 개별 어플리케이션을 감독하는 것에서 쿠버네티스를 감독, 관리하는 것에 집중
하드웨어 인프라를 추상화하고, 데이터 센터 전체를 하나의 거대한 컴퓨팅 리소스로 제공
각 구성 요소들을 여러 서버에 분산하고, 서로 쉽게 통신할 수 있도록 함
클라우드 공급자의 시스템 관리자가 자신의 하드웨어에서 도는 수만개의 앱을 알 필요 없음

쿠버네티스가 필요한 이유

1.
모노리스 애플리케이션에서 마이크로서비스로의 전환
마이크로서비스로 애플리케이션 분할
마이크로서비스 확장
마이크로서비스 배포
환경 요구 사항의 다양성
2.
애플리케이션에 일관된 환경 제공
3.
지속적인 배포로 전환: 데브옵스와 노옵스
수직 확장(scale up):
시스템의 증가하는 부하를 처리하려고 CPU, 메모리, 그 밖의 구성 요소를 추가하는 방법
장점: 어플리케이션을 변경할 필요가 없음
단점: 비용이 많이 들고, 확장에 한계가 있음
수평 확장(scale out)
서버를 추가하고, 어플리케이션의 복사본을 실행해 전체 시스템을 확장하는 방법
장점 : 저렴하다
단점: 어플리케이션을 수정할 수도
Q. 구글 같은 경우에는 mono-repo 를 사용한다고 들었는데 책에 언급된 내용 이외에 mono-repo의 장점은 뭐가 있을까?
Q. 가상머신과 컨테이너간의 성능 차이는 어느정도 일까?
Q. 컨테이너 기반 서비스를 운영 할 때의 단점은