안녕하세요, 김현지입니다. 이번에는 ‘도커 찍먹하기’라는 주제로 기술 세미나 발표를 하게 되었습니다. 도커를 선택한 이유는 저의 파이널 프로젝트를 배포할 때 도커를 사용할 것이기 때문입니다. 이에 따라 도커에 대한 이해와 익숙함을 기를 필요가 있다고 판단하였습니다. 이 포스팅은 ‘도커’에 대한 깊은 원리를 다루는 것이 아니라 소개 수준으로 이루어질 것이니, 편안하게 따라와 주시면 감사하겠습니다.
처음에는 도커가 무엇인지부터 시작해서, 개발과 배포 과정에 어떻게 변화를 가져오는지 살펴보겠습니다.
도커란 무엇일까요?
도커는 컨테이너를 생성하고 실행할 수 있는 생태계입니다. 생태계라는 표현을 강조한 이유는 도커와 컨테이너가 동치관계가 아니기 때문입니다. 도커는 컨테이너를 생성하고 관리하는 플랫폼으로, 이미지 생성, 컨테이너 오케스트레이션, 네트워킹 관리 등을 포함하는 포괄적인 개념입니다.
도커를 사용하는 이유는?
소프트웨어 개발을 위해 도커를 사용하는 이유는 여러 가지가 있습니다. 일반적으로 소프트웨어 개발은 개발, 테스트, 배포, 운영 단계를 거칩니다. 때때로 애플리케이션은 로컬 환경에서는 잘 작동하지만 테스트 환경에서는 문제가 발생할 수 있습니다. 이는 환경 설정이나 의존성의 문제 때문일 수 있습니다. 따라서 도커를 사용하여 일관된 환경을 구성하고 애플리케이션을 격리하여 테스트하는 것이 중요합니다.
일관된 환경을 구성하기 위해 도커는 가상 머신을 사용합니다. 가상 머신은 컴퓨터 하드웨어 리소스의 추상화된 개념으로, 다양한 운영 체제와 애플리케이션을 동시에 실행할 수 있도록 도와줍니다. 가상 머신을 사용하면 개발 환경과 테스트 환경을 동일하게 설정할 수 있습니다.
가상 머신을 구성하는 과정에서 가상화 기술이 중요한데, 이는 물리적인 컴퓨터 자원을 가상적으로 분할하여 여러 개의 가상 컴퓨터 환경을 만들어내는 기술입니다. 가벼운 보따리인 컨테이너는 이러한 가상화 기술을 더욱 발전시킨 것입니다. 컨테이너는 전체 운영 체제를 포함하지 않고도 애플리케이션을 격리하여 실행할 수 있습니다.
도커는 컨테이너 기반의 가상화 도구로, 애플리케이션을 컨테이너 단위로 격리하여 실행하고 배포할 수 있습니다. 이를 통해 애플리케이션을 손쉽게 빌드, 배포, 관리할 수 있습니다. 따라서 도커는 단순히 컨테이너를 실행하는 도구 이상의 플랫폼으로 발전하게 됩니다.
도커의 아키텍처
도커의 아키텍처는 각각 특별한 역할을 하는 구성요소들로 이루어져 있습니다. 그 중 핵심 구성 요소는 도커 엔진입니다. 이번에는 도커 엔진에 대해 자세히 살펴보겠습니다.
도커 엔진은 크게 세 가지 섹션으로 나뉩니다.
첫 번째로, 도커 CLI는 사용자가 웹에서 요청을 보낼 때와 마찬가지로 run, pull, rm 등의 도커 명령이 도커 클라이언트로 전달됩니다.
두 번째로, 도커 데몬은 도커 프로세스가 실행되어 서버로서 입력을 받을 준비가 된 상태를 나타냅니다. 이는 도커 엔진의 핵심이며, 클라이언트의 요청을 받아들이고 처리하는 역할을 합니다.
세 번째로, 도커는 도커 CLI 요청이 도커 데몬과 통신하기 위해 자체적인 API를 제공합니다.
이러한 클라이언트와 서버 아키텍처를 다시 한 번 살펴보면, 사용자가 docker run, docker build, docker pull과 같은 요청을 보내면 이것들은 도커 호스트의 데몬에서 처리됩니다.
이 과정에서 데이터 볼륨, 네트워크 관리, 도커 이미지 생성, 그리고 이미지를 통해 컨테이너를 생성하는 작업이 수행됩니다.
각 작업마다 엔드포인트가 있으며, 따라서 도커는 많은 엔드포인트를 가지고 있습니다.
도커 이미지와 컨테이너
도커 이미지와 컨테이너에 대한 개념을 정리해보겠습니다. 도커 이미지는 소프트웨어를 실행하는 데 필요한 모든 것을 포함하는 패키지입니다. 이는 자바의 클래스 파일과 유사한 개념으로, 소프트웨어의 실행에 필요한 모든 설정, 종속성, 코드 등을 담고 있습니다. 반면에, 컨테이너는 도커 이미지의 인스턴스로, 이미지를 실행한 상태입니다. 클래스 파일을 실행하여 여러 개의 객체(인스턴스)를 생성하는 것과 비슷하게, 도커 이미지로부터 여러 개의 컨테이너를 생성할 수 있습니다.
이러한 개념을 이해하기 위해 도커 파일이 등장합니다. 도커 파일은 도커 이미지를 빌드하기 위한 지침서로, 이미지를 어떻게 구성할지를 정의합니다. 즉, 도커 파일은 이미지의 빌드 과정을 자동화하고 이미지가 어떻게 구성되는지를 명시합니다.
이제 비즈니스 관점에서 살펴보겠습니다. 예전에 진행한 해외 모임지갑 서비스가 성공적으로 운영되었고, 이제 해외 숙박 예약 서비스를 추가하여 비즈니스를 확장하려고 합니다. 이로 인해 사용자 트래픽이 증가할 것으로 예상되는데, 이에 대비하여 서비스의 안정성과 응답성을 유지하기 위해 도커 컨테이너를 스케일 아웃하여 서비스를 확장해보고자 합니다.
즉, 도커를 사용하여 현재 운영 중인 서비스를 여러 개의 컨테이너로 병렬로 실행하고, 트래픽이 증가할 경우 추가적인 컨테이너를 동적으로 생성하여 부하를 분산하고 응답성을 유지하려는 것입니다. 도커를 사용하면 이러한 확장이 비교적 쉽게 이루어질 수 있으며, 서비스의 안정성을 보장할 수 있습니다.
도커 컴포즈
도커 컴포즈는 여러 개의 컨테이너로 구성된 도커 애플리케이션을 쉽게 정의하고 실행하기 위한 도구입니다.
이를 통해 yaml 파일을 사용하여 서비스, 네트워크, 볼륨 등을 구성할 수 있습니다.
주요 장점은 단일 명령어로 모든 구성 요소를 시작하거나 중단할 수 있다는 것입니다.
docket compose up은 실행시키는 명령어이며, docker compose down은 중단하는 명령어입니다.
그러나 서비스가 대박나면서 트래픽이 급증하여 컨테이너 증설만으로는 해결할 수 없는 상황이 발생했습니다. 이에 대응하기 위해 서버를 확장해야 할 필요가 생겼습니다. 이 때 선택할 수 있는 방법은 Scale Up과 Scale Out입니다. Scale Up은 기존 서버의 성능을 높이는 것이며, Scale Out은 여러 대의 서버를 병렬적으로 활용하는 것입니다.
그러나 현재 상황에서는 스타트업이므로 재빠르게 대응할 필요가 있으며, 비용을 고려하여 Scale Out 방식이 적합해 보입니다. 이를 통해 서버를 병렬적으로 확장하여 트래픽을 효과적으로 처리할 수 있을 것으로 기대됩니다.
컨테이너 오케스트레이션
컨테이너 오케스트레이션은 여러 대의 서버를 클러스터로 만들어 자원을 병렬로 확장하는 것을 의미합니다. 이를 위해 도커에 내장된 도커 스웜을 소개하겠습니다.
도커 스웜은 컨테이너 수를 동적으로 조절하여 로드 밸런싱 기능을 수행합니다. 그러나 사용자가 인스턴스의 개수를 수동으로 조절하는 스케일 아웃 방식을 사용하기 때문에 수작업이 필요합니다. 도커 스웜은 매니저 노드와 워커 노드로 구성되어 있으며, 매니저 노드는 워커 노드의 기능을 수행하면서 관리도 함께 합니다.
또 다른 컨테이너 오케스트레이션 방법으로 쿠버네티스를 소개합니다. 쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 운영을 자동화합니다. 도커 스웜보다 더 정교한 자동화를 가능하게 해주며, 서비스의 복제 수를 자동으로 조절할 수 있습니다.
컨테이너 오케스트레이션 도구를 선택할 때는 프로젝트의 규모와 요구 사항을 고려해야 합니다. 도커 스웜은 작고 가벼운 프로젝트에서 손쉽게 사용할 수 있으며, 쿠버네티스는 복잡한 환경에서 세밀한 관리가 필요할 때 사용하는 것이 좋습니다.