GCP를 이용하여 도커와 쿠버네티스를 학습한 결과를 정리하고자 한다.

큼지막한 개념 정리와 실습 위주의 정리를 통해

docker, kubernets에 대한 감을 익히는 것이 이 글의 목적이다.

 

첫 번째 글에서는 docker, kubernetes, GCP(Google Cloud Platform) 세 가지를 쓰는 이유에 대해서 정리한다.

 

1. 왜 도커, 쿠버네티스를 써야 할까?

 

내가 중국집을 오픈한다고 가정을 해보자.

판매할 메뉴는 세 가지다.

자장면, 짬뽕, 탕수육

이제 주방에서 요리할 주방장을 고용해야 한다.

이때, 두 가지 방법이 있다.

방법 1: 세 가지 메뉴를 모두 만들 수 있는 비싼 주방장 1명 고용하기

방법 2: 두 가지 메뉴를 만들 수 있는 비교적 저렴한 주방장 3명 고용하기

         (직원 1: 자장면, 짬뽕 | 직원 2: 짬뽕, 탕수육 | 직원 3: 탕수육, 짬뽕)

 

각 방법의 장단점을 알아보자.

 

방법 1

   장점

      -인력 관리가 간편하다.

      -비싼 만큼 Performance가 좋으므로, 많은 주문도 비교적 빨리 처리 가능하다.

   단점

      -주방장이 과로로 병이 나서 출근을 못하게 되면 주문을 전혀 받을 수 없다.(운영 불가)

      -가게를 조금 확장해야 할 때(테이블 추가) 인력 추가가 어렵다(단가가 비싸므로)

 

방법 2 : 방법 1과 반대

 

손님의 수가 항상 일정한 가게라면 방법 1이 좋겠지만

 

손님의 수가 들쑥날쑥하고,

직원들의 주 52시간 근무 준수, 휴가 보장, 갑작스런 병가 등에 대한 변수가 많은 곳이라면 방법 2가 훨씬 유리할 것이다.

 

비싼 주방장은 기존의 서버를 의미하고 저렴한 주방장은 Docker를 의미한다.

주방장들의 수를 손님의 수에 맞게 control 하는 내가 Kubernetes가 되겠다.

 

우리가 방법2를 택해야 하는 이유는, 변수가 많고 변화가 빠른 최근의 IT 서비스 환경 속에서

  계속적인 서비스 제공 능력(High Availability) 그리고 상황에 따른 빠른 확장 및 축소 능력을 위함이다.

 

kubernetes를 통해서

상황에 따라 부하가 많을 때는 docker 개수를 늘러 performance를 늘리고

부하가 없을 때는 docker 개수를 줄일 수 있다.

또한, 특정 docker가 죽었을 때 self healing 기능을 통해 해당 docker를 삭제하고 새 docker를 생성하여 서비스의 수준을 유지시킬 수도 있다.

 

 

2. GCP를 사용하는 이유

 

현재의 많은 Cloud Platform 중에서, GCP가 대두되고 있는 이유에 대해 알아보자.

 

서버는 크게 메인 프레임 -> 가상화 서버(OS) -> 컨테이너 가상화 의 방향으로 변형되어 왔다.

이 변화는 크게 두 가지 목적을 가지고 진행해왔는데

   -첫 번째는 서비스 다중화를 통한 HA(High Avilability) 구현

  - 두 번째는 CPU, Memory와 같은 hardware 장비의 낭비 최소화 즉, 비용 절감이다.

 

현재 컨테이너 기술의 대세는 docker이며, docker를 Manage할 수 있는 Orchestration 기술의 대표주자가 kubernetes이다.

kubernetes는 구글에 의해 설계 및 구현되었고, 소스를 리눅스 재단에 공개함으로써 오픈 소스화 했다.

 

구글이 kubernetes와 같은 기술을 오픈 소스로 공개하면 어떻게 될까?

해당 기술을 쓰고는 싶었지만 비용 문제로 사용할 수 없었던 기업들이 오픈 소스를 쓰게 되며, 오픈 소스를 기반으로 한 추가적인 기술들이 개발됨으로써 사실상 세계 표준 기술이 된다.

실제로, kubernetes는 거의 모든 Cloud Platform에서 사용하는 컨테이너 Orchestration 기술이 됐다.

 

Google이 Kubernetes 기술을 직접 설계, 구현하고 배포했기 때문에

Kubernetes를 비교적 가장 손쉽고 효율적으로 사용할 수 있는 곳이 Google Cloud Platform(GCP)이 되었다.

 

 

3. Docker, Kubernetes를 활용하는 세계적인 기업들

 

일반적인 기업에서 Application 배포를 얼마나 자주 할까?

보통 1주일에 한 번 정기 배포, 잦으면 하루 한 번.

변경이 많지 않은 기업은 몇 달에 한 번일 것이다.

 

그렇다면 다음 기업들의 배포 횟수는 어떨까.

 

500 / day

넷플릭스: 하루 500회

 

5,500 / day

구글: 하루 5,500회

23,000 / day

아마존: 하루 23,000 회

 

고객의 돈 벌기가 이렇게 어렵다.

 

저렇게 많은 횟수를 어떻게 큰 문제없이 배포할 수 있을까?

이는 Canary Deployment 방식을 사용하기 때문에 가능하다.

 

4. Canary deployment 란?

 

"Canary in a coal mine" 이라는 관용구가 있다.

의역하면 '조기경보' 정도가 되는데, 다름과 같은 유래가 있다.

예전에 광부들이 환기장치가 없었던 탄광안으로 들어갈때 카나리아라는 새를 새장에 넣어갔다.


이유는 탄광안에 차오르는 메탄가스와 일산화탄소의 양에 가장 민감하게 반응하는것이 바로 이 카나리아였기 때문이다.


건강하던 카나리아가 유독가스의 농도가 짙어지면 순식간에 죽어버린다.


이를보고 광부들이 위험을 감지했다고 한다.

카나리아 새를 탄광에 한 마리 넣어보고, 괜찮으면 한 마리 더.

그렇게 다수의 카나리아를 넣어보고 문제가 없으면 비로소 모든 광부가 탄광으로 들어가 일을 시작했다.

 

위의 기업들은 이 새의 이름을 딴, Canary Deployment 방식을 사용한다.

 

docker를 통해 운영하는 수천, 수 만 개의 서버가 있을 때

한꺼번에 모든 docker에 신규 개발 건을 배포하는 것이 아니라,

1개, 2개, 소수의 docker로 시작하여 영향도를 서서히 파악하면서 이상이 없을 경우 전체의 docker에 배포한다.

이러한 방식으로 모든 개발자들이 배포하기 때문에, 위와 같은 수의 deployment가 가능하다.

 

Canary Deployment를 통해, 개발자들은 부담없이 개발 건을 배포할 수 있으며

고객들의 needs를 빠르게 반영하여 서비스의 만족도 또한 높일 수 있다.

 

Canary Deployment, ingress 등 kubernetes는 여러 기능을 제공한다.

이러한 기능들을 이용하여 IT 서비스를 상당히 고도화시킬 수 있다.

 

 

5. 정리

정리하자면,

고가용성과 비용절감을 위해 가상화, 컨테이너 기술을 사용하며

이를 가장 잘 구현할 수 있는 기술이 container, kubernetes이다.

또한, kubernetes는 Canary Deployment와 같은 여러 가지 기법을 통해 고객의 Needs를 만족시킬 수 있다.

마지막으로, GCP가 위의 두 기술을 다루기에 가장 최적화된 Platform이다.

 

이 글에서는 docker, kubernetes를 사용해야 하는 이유와 GCP에 대해 알아보았다.

앞으로는 간단한 실습을 통해 도커, Kubernetes에 대한 감을 익혀보자.

+ Recent posts