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