[Container] 컨테이너 오케스트레이션 (Container Orchestration)

서버를 관리하는 것

서버의 상태를 관리하기 위한 노력 ->문서화를 잘해보자

-> OS업데이트나 환경이 바뀌면 똑같이 따라 해도 잘 안 되는 케이스가 생긴다.

그래서 등장한 Chef , Puppet, Ansible

서버를 관리하는 도구를 사용하는 것, 해당 도구에 맞게끔 어떤 프로그램이 없으면 설치하고, 설정이 맞지 않으면 어떤 설정을 바꿔라 이러한 것들을 서포트하는 역할

 

단점 1. 설정도구 자체를 배워야 함

서버를 굉장히 복잡하게 관리하다 보면 도구의 사용법도 난이도가 굉장히 높아진다.

자바나 노드의 버전을 다르게 운영해야 하는 경우 노드 프로그램 자체의 디렉터리를 다르게 설정해야 하는데,

어떻게 하면 한 서버에서 여러 개의 버전을 잘 돌릴 수 있을 것인가?

 

 

가상머신의 등장

가상머신 하나에는 하나의 프로그램만 구성되어 있기에 충돌 날 일 없지만, 느리고 특정 벤더에 제한되기에 여러 개의 클라우드 멀티 클라우드 등에서 사용하기 어렵다.

 

 

도커의 등장

도커만 설치되어 있으면 어디서든 동작, 사용법도 쉽고 VM처럼 느린 것도 없다.

• 가상머신과 비교하여, 컨테이너 생성이 쉽고 효율적
• 컨테이너 이미지를 이용한 배포와 롤백이 간단
• 언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리
• 개발, 테스팅, 운영 환경은 물론 로컬 피시와 클라우드까지 동일한 환경을 구축
• 특정 클라우드 벤더에 종속적이지 않음

도커를 사용하기 이전에는 방법이 매번 방법이 달랐으나, 도커를 사용하면 모든 개발의 과정이 위와 같이 정형화가 된다

 

도커 등장 후, 개발 과정

1. 코드작성
2. 이미지 빌드
3. 이미지를 도커허브나 저장소에 저장
4. 도커 이미지를 컨테이너로 실행

 

But 도커가 좋기는 한데, 또 많은 것을 관리하려면 신경 쓸 것이 많다. 

컨테이너 기술이 굉장히 좋은데 그럼 컨테이너를 어떻게 배포하는 게 좋을까?
서버가 서버 1, 서버 2, 서버3 이렇게 3개가 있다고 가정하자,

도커 서버 1을 실행하려면 1번 서버에 ssh접속해서 도커 스타트하고, 서버2, 서버 3도 마찬가지 일 것이다

=> 하나하나 직접 구동해야 한다.

 

 

 

도커를 사용하다 보면 다음과 같이 빈 공간이 생긴다, 서버가 있는데 컨테이너가 실행이 안되어있는 서버,
새로운 컨테이너를 실행하려면 빈 서버와 같이 여유가 있는 서버에 실행하는 게 좋다.
하지만 어떤 서버가 여유가 있는지 보려면 모니터링 도구를 만들어야 할 수도 있고,
하나하나 접속하면서 관리를 해야 하는 문제가 있다.

 

 

일부 버전 2로 업데이트

 

 

또 다른 문제는 배포하여 일부분의 버전을 업데이트했다고 하였을 경우,
혹은 모든 컨테이너를 버전 2로 업데이트하였으나, 배포한 버전에 문제가 생겨
이렇게 다시 버전 1로 롤백을 해야 하는 경우가 생긴다.

문제가 생겨 버전 1로 롤백

 

하지만 하나하나 직접 관리하기에는 너무 손이 많이 간다.
이에 중앙에서 모든 컨테이너의 버전을 업데이트하고 싶다 이런 욕구가 생긴다.
=> Container Orchestration의 등장

 

2. 서비스 검색은 어떻게 할까?

 

위와 같이 프록시 프로그램과 웹이 있을 경우,
프록시의 경우 웹을 바라보게 192.168.0.100을 바라보게 설정

 

 

근데 웹 서버의 부하가 많아져서 서버가 웹이 2개가 된 경우,
이와 같이 로드밸런서를 구성하고 프록시는 로드밸런서를 향하도록 바라보게 한다.
Proxy -> LoadBalancer -> Web

 

 

 

3. 서비스 노출은 어떻게 할까?

퍼블릭영역에 Nginx와 같은 프록시 서버를 두고, 들어오는 호스트에 맞춰 내부의 Private에 있는 컨테이너에 연결
Nginx의 설정 바꾸는 것도 귀찮고, 더 편하게 일을 하고 싶다 -> 자동화는 안될까?

 

4. 서비스이상, 부하 모니터링은 어떻게 할까?

 

 

12개의 컨테이너를 관리하던 도중 위와 같이 5개의 컨테이너가 죽거나 , 혹은 부하가 많아진 경우 개수를 늘리거나 관리를 따로 해줘야 하는 상황 - 새벽에도 일어나서 조치 필요,

자동화는 안될까? -> Container Orchestration

 

 

Container Orchestration

위와 같은 문제점을 해결하고, 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구

• 기존 방식 : 각 노드 하나하나를 직접 관리 CPU, RAM은 이런 사양이고, 이러한 애플리케이션이 설치가 되어 있다 이런 걸 알고 관리.

 

• 클러스터 : 컨테이너 오크스트레이션에서는 위의 개수가 많아질 경우 하나로 합치고, 클러스터 단위로 추상화해서 관리
  
  

클러스터 하나하나의 노드에 SSH로 접속해서 다 관리하기는 어렵기에 마스터 서버를 하나 두고, 관리자는 마스터 서버에 명령어를 입력하면 마스터 서버가 알아서 해당 노드들에게 명령어를 수행하도록 명령

클러스터트들끼리, 서버들끼리 네트워크가 잘 이루어져서 통신하는데 문제가 없어야 함

노드의 개수가 수천 개, 수만 개가 되더라도 잘 돌아가야 한다.
처음에 설계할 때 잘 설계하지 않으면 결국에는 부하를 다 감당하지 못하게 된다.

 

• 상태관리

app1의 이미지를 띄우고 복제로 3개를 띄우라고 상태를 관리한다. 만약 3개의 상태에서 컨테이너 하나에 문제가 생기면 문제가 생긴 하나를 죽이고, 새로운 컨테이너 하나를 띄운다.

 

 

• 배포관리

APP1을 추가로 띄우고 싶을 경우 자동으로 적절한 서버를 찾아 띄워주고, 추가로 하나 더 띄우고 싶을 경우 서버하나를 생성하고, 컨테이너 하나를 생성하여 APP1을 띄워준다.

 

• 배포 버전관리

컨테이너 하나하나의 버전을 관리하기보다 중앙에서 일괄적으로 관리

• 서비스 등록 및 조회

해당 100번과 101번을 사용하는 프락시 서버가 해당 저장소를 지속적으로 관찰, 변경 사항이 있을 때마다 설정을 내부적으로 변경하고 프로세스를 재시작 -> 관리자가 하나하나 아이피를 바꿀 필요 없다.

 

• 볼륨 스토리지

각각 필요한 볼륨을 마운트, 스토리지를 연결해야 할 경우, 수동적으로 관리할 수 있지만, 추상적으로 관리가 가능하게 도와줌

Reference

https://www.youtube.com/watch?v=Ia8IfowgU7s&list=PLIUCBpK1dpsNf1m-2kiosmfn2nXfljQgb