들어가기전에
요즘 IT 생태계에 도커와 쿠버네티스라는 것을 사용하는 회사가 많아졌다. 도커, 쿠버네티스를 접하지 않은 나에게는 둘 다 생소한 단어들이였다. 최근에 우리 회사에서 도커에 대해 관심을 보이기 시작하여 도커를 사용하려는 움직임을 보이기 시작했고, 도커와 쿠버네티스에 대해 용어적으로 공부한 것들을 기록해본다.
용어 정리
| 용어 | 뜻 |
| 컨테이너 | 앱이 구동되는 환경까지 감싸서 실행할 수 있도록 하는 격리 기술 |
| 컨테이너 런타임 | 컨테이너를 다루는 도구 |
| 도커 | 컨테이너를 다루는 도구 중 유명한 것 |
| 쿠버네티스 | 컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구 |
| 오케스트레이션 | 여러 서버에 걸친 컨테이너 및 사용하는 환경 설정을 관리하는 행위 |
컨테이너부터 살펴보면 내가 구동하려는 애플리케이션을 실행할 수 있는 환경까지 감싸서 어디서든 쉽게 실행 할 수 있도록 해주는 기술이라 정의되어 있다.
컨테이너라는 개념을 쉽게 설명하자면 PC에 프로그램을 설치할 때 특정 경로에 맞춰 설치를 하거나, 내 컴퓨터에 필요한 옵션들을 맞춰 설치해주어야 했는데 컨테이너는 그런 환경까지 모두 포함하여 독립적으로 프로그램을 실행 할 수 있도록 도와주는 기술이란 것이다.
이 컨테이너 라는 개념을 공부하며 사용하는 개발자들은 편하겠지만 이걸 구축하는 데브옵스 사람들은 꽤나 쉽지 않겠다고 생각하게 되었다.
그리고 컨테이너를 사용할 때 필요한 도구가 컨테이너 런타임인데 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구이다. 이 도구는 종류가 굉장히 많은데 그 중에서 유명한 게 도커이다.
하지만 컨테이너 규격은 표준화되어 있기 때문에 굳이 도커가 아닌 다른 컨테이너 런타임들도 도커로 만든 컨테이너를 사용할 수 있다.
쿠버네티스는 컨테이너 런타임을 통해 컨테이너를 다루는 도구를 말한다. 그러니까 컨테이너를 분산 배치, 상태 관리 및 컨테이너의 구동환경까지 관리하는 도구를 의미한다.
그래서 쿠버네티스가 해 주는 일을 예를 들어보자면 여러 서버(노드)에 컨테이너를 분산해서 배치하는 것, 문제가 생긴 컨테이너를 교체 해주는 일, 컨테이너가 사용할 비밀번호나 환경 설정을 관리하고 주입해 주는 일등이 그 예이다.
이것을 컨테이너 오케스트레이션 이라고 부른다.
가상머신과 컨테이너 비교
맨 왼쪽 Traditional Deployment(전통적 배포)는 가상화 이전이라 부르는 오래전부터 쓰이던 방식이다.
물리적인 컴퓨터 한 대에 하나의 OS를 깔고 여러 가지 프로그램을 설치하는 방식이다.
PC 한 대에 윈도우를 하나 설치하고, 여러 가지 게임이나 기타 필요한 프로그램 등을 깔아서 사용하는 것과 비슷한 방식이라고 생각하
면 된다. 가장 오래되고 단순한 방식이며 단일 목적 시스템이라면 이것으로도 별 무리가 없다.
그렇다면, 이 방식이 가진 문제점은 무엇이 있을까? 인터넷 뱅킹을 위해 보안 프로그램을 많이 설치했더니 게임이나 웹 브라우저 성능이 떨어지는 건 한 번쯤 경험해봤던 일일 것이다.
한 대의 컴퓨터에서 모든 것을 처리하려고 하면 어떤 프로그램 동작이 다른 프로그램의 동작을 간섭하거나, 특정 프로그램이 성능을 독
점할 경우 또 다른 프로그램의 성능이 떨어지는 단점이 있다. 성능이 떨어지는 정도에 그치지 않고 프로그램의 중단까지도 유발할 수도
있다.
그렇다면 이 문제를 해결하기 위해서는 어떻게 해야 할까?
인터넷 뱅킹 전용 컴퓨터와 게임용 컴퓨터 두 대로 운영하면 되지 않을까?
이렇게 생각해 볼 수도 있겠지만, 그러기엔 비용이 너무 많이 드는 문제가 생기게 된다.
(뭐든 모난 단점이 없으면 비용이 문제가 되는 것 같다.)
하지만 이 문제를 해결하기 위한 방법이 있다.
Virtualized Deployment(가상화 배포)라는 것인데 가상머신(Virtual Machine)을 기반으로 배포를 하는 방법이다.
중간에 위치한 하이퍼바이저는 하나의 시스템 상에서 가상 컴퓨터를 여러 개 구동할 수 있도록 해 주는 중간 계층을 의미한다는 정도로
만 알고 있으면 된다. 그리고 App은 실행하고자 하는 프로그램, Bin/Library는 프로그램이 실행하는데 필요한 환경과 관련된 파일이라고 생각하면 된다.
여기서 가상머신은 말 그대로 가상 컴퓨터다. 컴퓨터이기 때문에 우리가 컴퓨터를 조립할 때 CPU, 메모리 및 SSD를 장착하듯, 가상머신에도 CPU, 메모리, 저장 장치 등을 개별적으로 할당할 수 있다. 앞에서 말한 게임 프로그램과 인터넷 뱅킹 보안 프로그램이 간섭을 일으켜 문제가 된다면 두 프로그램을 각각의 가상머신에서 실행시키면 된다.
하나의 컴퓨터 안에서 두 개의 가상화된 컴퓨터가 동작하기 때문에 서로 간섭을 일으키지 않게 되고, 가상머신 성능을 조절해 게임 컴퓨터에는 좀 더 많은 CPU와 메모리를, 인터넷 뱅킹용 컴퓨터에는 적은 CPU와 메모리를 할당하여 사용할 수 있다.
또한 서버와 같이 다중화와 분산 처리가 중요한 시스템이라면 시스템 자원 상황에 따라 가상머신 개수를 늘리고 줄이는 것도 좀 더 유연하게 처리할 수 있다.
하지만 이 방식이 전통적 배포 방식보다는 분명 효율적이지만, 가상머신은 완전한 컴퓨터이고 가상머신에 일일이 운영체제를 설치해야 하기 때문에 컨테이너 중심의 배포(Container Deployment)보다는 무거운 편이라는 것을 기억해두자.
마지막으로 Container Deployment(컨테이너 중심의 배포)에 대해 살펴보자. 하이퍼바이저라는 부분이 Container Runtime으로 대체되었고, Virtual Machine이라고 된 부분은 Container로 대체가 되었다. 컨테이너는 가상머신과 달리 프로그램 구동을 위해서 OS를 매번 설치할 필요가 없기 때문에 그림에서 보는 것과 같이 OS는 하나만 사용한다.
컨테이너 기반 배포는 전통적 배포 위에 Container Runtime이 올라가 있는 것 같은데 물리적인 컴퓨터 상에서만 유효한 것인지 궁금할 수 있는데 꼭 그렇지는 않는다. 컨테이너 런타임 위에 OS와 하드웨어가 층으로 쌓여 있는 그림을 보고 전통적인 배포 위에서 컨테이너 런타임을 올렸다고 오해를 하곤 하는데, 컨테이너는 OS 하단이 어떻게 동작하는지 직접 관심을 두지 않는다. 그래서 가상머신 위에 올라간 OS에서 컨테이너 기반 배포를 하는 것이 가능하다.
앞에서 게임과 인터넷 뱅킹 프로그램이 한 컴퓨터에 설치된다면, 서로 간섭을 일으켜 성능 저하나 오류를 발생시킬 수 있다고 말했다.
지금부터 이 문제를 컨테이너 중심의 배포 방식에서는 어떻게 해결하는지 알아보기 위해 게임과 인터넷 뱅킹 소프트웨어가 각각 컨테이너로 배포된다고 가정해 보겠다.(물론 이럴 일은 없겠지만, 동작 방식의 예시라고 생각해 주면 좋겠다.)
이 때 게임과 인터넷 뱅킹은 하나의 OS 상에서 구동된다. 이것만 보면 전통적 배포에서 하나의 OS 위에 프로그램을 여러 개 구동시킨 것과 별 차이가 없어 보이지만 컨테이너 중심의 배포는 여기서 하나의 중요한 기술적인 차이점이 존재한다.
게임과 인터넷 뱅킹이 각각 실행되면서 ‘이 컴퓨터에서 나만 구동되고 있다’라고 판단할 수 있도록, 실제로 두 프로그램 간에 간섭을 일으킬 수 없는 장벽을 친다. 이러한 장벽을 치는 것과 동시에 OS는 게임과 인터넷 뱅킹이 사용할 수 있는 CPU, 메모리 등의 자원 또한 독립적으로 사용할 수 있도록 할당하고 관리해준다. 이러한 과정을 통해 게임과 인터넷 프로그램은 스스로를 ‘서로 다른 컴퓨터에서 깔려 있다’고 생각하게 된다. (물론 OS의 관점에서 보자면 둘 다 OS 상에서 구동되는 프로그램이지만...)
이와 같은 컨테이너 동작 방식을 OS 커널을 공유하는 가상화라고 표현하기도 한다.
이 때 주의할 점이 하나 있는데 컨테이너는 OS를 공유하는 방식이기 때문에, 어떤 프로그램의 문제가 다른 프로그램을 간섭할 수는 없다. 그러나 내 프로그램의 문제가 OS에 문제를 일으킬 경우에는 OS에서 구동 중인 전체 컨테이너의 문제가 될 가능성이 있게 된다.
이 점에 신경을 써야 한다.
리눅스를 기준으로 내가 실행한 프로그램이 독립된 환경에서 실행되는 것처럼 격리시켜주고, CPU, 메모리 및 저장 장치와 같은 자원도 실행한 프로그램이 독립적으로 쓸 수 있도록 해주는 namespace 및 cgroup이라는 기술이 있다는 것만 알아 두시면 된다.
| 전통적인 배포 | 가상머신 기반 배포 | 컨테이너 기반 배포 | |
| 컴퓨터 | 물리적인 컴퓨터 1대 | 물리적인 컴퓨터 1대에 다수 가상머신 존재 | 컴퓨터 형태에 영향 받지 않음 |
| OS | 물리적인 컴퓨터 1대에 OS 1개가 설치 | 물리적인 컴퓨터 OS 1대 + 다수의 가상머신에 각각 OS 설치 |
컴퓨터 형태와 관련 없이 설치된 OS 1개 |
| 리소스 | 컴ㅂ퓨터 1대의 자원을 여러 프로그램이 나눠 사용 | 하이퍼바이저를 통해 가상머신 별 개별적 자원 할당 |
프로그램 실행 환경은 격리되지만 OS 환경은 공유 |
| 격리 수준 | 격리되지 않아 프로그램 간 간섭 발생 | 각 가상머신이 완전하게 격리 | 특정 프로그램의 문제가 다른 프로그램에 간섭을 일으키지않지만, 특정 프로그램의 문제가 OS문제를 유발할 경우 시스템 중단 가능성 있음 |
| 문제 전이 가능성 | 특정 프로그램의 문제가 시스템 전체의 중단을 가져올 수 있음. | 특정 가상머신의 문제가 다른 가상머신의 문제로 전이될 가능성이 낮음 |
마치며
오늘을 시작으로 도커와 쿠버네티스에 대해 한 발짝 알아가는 시간을 가졌다.
나에게는 익숙하지 않는 분야이지만 추후에 내가 회사에서 도커와 쿠버네티스를 사용할 때 도움이 되길 바란다.
우리회사가 도커를 통해 기대할 수 있는 점은 '가용되는 서버의 최소화'이다. 현재 의미없이 분산된 서버들이 많아 관리하는 데 있어
불편함이 있는데 도커를 통해 이 부분들이 해결 될 것을 기대하고 있다.
나는 데브옵스 쪽 일을 맡지 않고 있어 도커나 쿠버네티스를 회사에서 구축할 기회는 없지만 개발자가 편하게 사용하는 만큼 그 것을 구축하는 것이 상당히 어렵다는 것을 젠킨스를 구축하며 알고 있었기에 회사에서 인프라를 담당하고 계시는 분들에게 감사할 따름이다.
참조
- 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 (조훈, 심근우, 문성주 저)
- https://www.samsungsds.com/kr/insights/220222_kubernetes1.html
'프로그래밍(Web) > 공부일기' 카테고리의 다른 글
| sequelize 사용기 (0) | 2023.11.17 |
|---|---|
| Node - koa 프레임워크를 사용하며 느낀점 (0) | 2023.10.17 |
| [바미] 백엔드 개발자로 이직하며 접했던 면접 질문들 (0) | 2023.09.25 |
| [바미] 실전 아파치 카프카 - 카프카의 구성요소 (0) | 2023.09.25 |
| [바미] 만 3년 개발자의 회고 (2) | 2023.05.09 |
