도커와 쿠버네티스 시작하기
클라우드 네이티브의 정의
- 클라우드 네이티브는 애플리케이션을 클라우드 환경에서 구축, 배포 및 관리하는 방식
- 쿠버네티스는 클라우드는 네이티브 구성요소를 완전히 수행할 수 있는 최고의 플랫폼
- 퍼블릭, 프라이빗, 하이브리드 클라우드
기존 애플리케이션과 클라우드 네이티브 애플리케이션의 차이점
| 구분 |
기존 애플리케이션 |
클라우드 네이티브 애플리케이션 |
| 애플리케이션 구조 |
모놀리식 구조 |
마이크로서비스 |
| 결합 |
크고, 조밀한 결합 |
느슨한, 서비스 기반 |
| 실행 환경 |
물리 서버 중심 |
가상 컨테이너 중심 |
| 확장 |
수직 확장(Scale-Up) |
수평 확장(Scale-Out) |
| 인프라 의존성 |
인프라 의존 |
인프라 독립, 이식성 → 컨테이너 |
| 개발 방법 |
폭포수(Waterfall) |
애자일(Agile) |
| 빌드/배포 |
수작업, 긴 시간 |
CI/CD 자동화, 짧은 시간 & 지속 |
| 조직 구조 |
단절된 개발, 운영, 보안 |
데브옵스 협업 |
클라우드 네이티브 구성요소
- 마이크로서비스 : 독립적인 실행 및 배포가 가능한 마이크로서비스
- 컨테이너 : 경량화된 컨테이너 단위 수평적 확장
- 프로세스가 동작하는데 필요한 요소들로 구성된 독립적 실행 환경
- DevOps : 개발팀과 운영팀간 단일한 협업 프로세스
- CI/CD : 소규모 개발팀별 자율적, 독립적 서비스 운영
모놀리식 아키텍처와 마이크로서비스 아키텍처
-
모놀리식 아키텍처
- 전통적인 아키텍처, 기존에 사용하던 서비스 방법
- 서비스가 하나의 애플리케이션으로 돌아가는 구조
- 기존의 개발 방식을 사용해 개발하여 간단히 배포
- 하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍처
- 다양한 기능을 동작하는 서비스를 서버에서 실행하여 서비스
-
모놀리식 아키텍처의 단점
- 스케일아웃
- 스케일아웃 시 기존의 애플리케이션을 그대로 복제하여 로드밸런싱하므로 불필요한 서비스까지 모두 복제됨
- 종속적 라이브러리 충돌
- 각각의 기능들은 서로 다른 기능을 제공하여 버전의 종속성을 필요한 경우가 존재
- 각 기능의 라이브러리를 매 업데이트마다 관리하기 어려움
- 일부 수정 시 전체 빌드 및 배포 필요
- 전체 빌드 및 배포되므로 소요시간이 어마어마함
-
마이크로서비스 아키텍처
- 모놀리식 아키텍처의 대안으로 반대되는 개념
- 애플리케이션의 각각의 기능을 분리하여 개발 및 관리
-
마이크로서비스 아카텍처의 장점
- 빠른 개발
- 개발자가 특정 비즈니스 로직에 대해서만 집중 개발 가능하여 빠르게 개발
- 개별 서비스 단위별 개발, 패키징, 빌드, 테스트, 배포로 각 서비스마다 유연하게 스케줄할 수 있음
- 스케일아웃
- 사용량에 따른 서비스 단위로 스케일아웃이 가능
- 라이브러리 종속 X
-
마이크로서비스 아카텍처의 단점
- 관리의 복잡성
- 수 많은 프로세스로 인해 Transaction 보장, 테스트, 배포, 관리가 복잡해짐
- 그로 인해 컨테이너 오케스트레이션 쿠버네티스가 등장
DevOps 모델의 개념
- 데브옵스는 개발팀과 운영팀의 협업으로 전체 라이프사이클을 합께 관리하자 라는 일종의 철학 또는 운동
- 더 빠르고 안정적으로 SW를 빌드, 릴리즈할 수 있도록 두 팀 간의 프로세스를 자동화하는 일련의 과정
- 데브옵스의 장점
- 속도
- 서로의 업무에 대해 이해하여 신속한 문제파악 가능
- 컨테이너와 마이크로서비스를 사용하면 더 빠르게 릴리즈, 제공 가능
- 안정성
- 개발과 릴리즈가 편해져 안정성 확보, 협업 강화
마이크로서비스 성공 사례
- Netfilx (2013년)
- 최초의 마이크로서비스 사례
- 수백 개가 넘는 작은 단위의 서비스 운영
- API 기반의 마이크로서비스를 활용, 컨테이너가 아닌 VM(EC2)
- Netfilx 마이크로서비스 도입 배경
- 개발속도 저하 : 연관된 코드가 많음
- 데이터센터 비대화 : 트래픽 증가로 인한 HW 추가 필요
- 서버 점검의 문제 : 24시 서비스
- 서비스 중단 : 장애 시 서비스 중단
하이퍼바이저와 가상 머신의 이해