Container 오케스트레이션은 효율적인 서버 관리를 위해 등장했다.
● 서버 관리 방법론 히스토리
1. 서버 세팅 방법을 문서화했다.
2. 서버 관리 도구를 활용했다.
3. 가상 머신을 활용했다.
4. 도커가 등장했다.
사용법도 쉽고, 빨랐다.
도커는...
- 가상머신과 비교하여 컨테이너 생성이 쉽고, 자원 사용이 효율적이다.
- 이미지를 이용한 컨테이너 배포와 롤백이 간단하다.
- 언어/프레임워크에 상관없이 APPLICATION을 동일한 방식으로 관리할 수 있다.
- DEV/TST/PRD 환경 뿐만 아니라, LOCAL에도 동일한 환경을 쉽게 구축할 수 있다.
- 특정 벤더에 종속적이지 않다.
모든 것이 도커화되었다.
도커를 중심으로 개발 프로세스 정형화되었다.
이슈 : 모든 걸 컨테이너로 만들 수 있었지만, 컨테이너가 너무 많아지는 경우에 관리가 힘들어졌다.
4.1 배포 시 문제점
- 컨테이너의 IP관리와 더불어 하나씩 접속해서 관리해야했다.
- 버전 업그레이드 / 롤백 할 때도 하나씩 접속해서 처리해야했다.
- 수많은 컨테이너 중 어떤 컨테이너가 동작 중인지/멈춰있는지 확인하려면 모니터링 툴을 별도로 활용해야했다.
4.2 서비스 검색 시 문제점
- 서비스 검색은 클라이언트가 어떤 서버(서비스)에 접근해야할지 검색하는 것을 의미한다.
- 프록시 서버가 로드밸런서를 바라보게 하고, 그 뒤에 여러 서버를 두어 부하를 분산처리할 수 있다.
- 마이크로 서비스가 유행하면서 서버간 통신이 늘고, 너무 많은 로드밸런서와 서버들을 세팅/관리해주어야했다.
4.3 서비스 노출
- 요청 도메인에 따라 어떤 컨테이너로 연결할지 수동으로 세팅해야했다.
4.4 서비스 이상, 부하 모니터링
- 많은 컨테이너 중, 갑자기 몇개 컨테이너가 죽거나 부하를 많이 받게되면 수동으로 조치해야했다.
★ 복잡한 컨테이너 환경을 효율적으로 일괄 관리하기 위해 Container Orchestration이 등장했다.