Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

서비스 디스커버리

Container 기반 가상화 시스템의 특징

컨테이너(Container)를 기반 가상화 시스템이라고 해서 가상머신(Virtual machine) 기반 가상화 시스템과 다를 점은 없다. 컨테이너 가상화를 위한 네트워크, 스토리지 가상화 기술은 가상머신 가상화에서 이미 완성됐다. 단지 머신을 가상화 하느냐 하지 않느냐의 차이만 있을 뿐이다.

그러므로 컨테이너 기반 가상화 시스템을 만든다고 하면, 기존에 사용하던 네트워크/스토리지 가상화 기술을 기반으로 컨테이너 오케스트레이션 툴을 올리면된다.

간단해 보이지만 두 가지 부분에서 쉬운일이 아니다.
  1. 기존 가상화 기술들도 그렇게 만만한 기술들이 아니다.
  2. 기존 가상화 기술들을 근간으로 삼고 있다는 이야기지 그대로 사용 할 수 있다는 것은 아니다. 가상화 레벨이 틀리기 때문에, 기존 가상화 기술들을 컨테이너 가상화에 맞게 수정해서 사용해야 한다.
가상화를 하려면 1번은 어차피 해결해야 하는 문제이니 여기에서 다루지는 않겠다. 2번 문제를 다루려고 한다. 컨테이너 가상화는 기존 가상화와 어떤 차이점이 있고 그래서 어떤 방식으로 해결 해야 하는지를 살펴본다.

서비스 디스커버리가 필요한가 ?

소프트웨어 개발자라면 인터넷에 연결되는 것은 결국 프로세스라는 것을 알고 있다. 하지만 보통은 "인터넷에 연결되는 것은 컴퓨터다"라고 이야기하고 있다. 프로세스(Django 기반의 웹 애플리케이션 서버 같은)를 실행하려면 운영체제가 있어야 하고, 그 운영체제는 컴퓨터 위에 실행되기 때문이다. 프로세스와 운영체제 그리고 컴퓨터를 분리해서 생각 할 수 없기 때문에 만들어진 직관이다. Django를 설치한다고 하면 가장 먼저하는게 컴퓨터를 준비하고 운영체제를 설치하는 거다. 클라우드 환경이라고 해봐야 물리적인 컴퓨터가 아닌 가상의 컴퓨터(Virtual Machine)가 됐다는 것 외에는 크게 달라지지 않았다.

하지만 컨테이너기반 가상화는 VM 가상화보다 네트워크 영역에서 복잡한 양상을 보인다. 아래 그림을 보자.

 Container 네트워크와 VM 네트워크

VM 가상화 환경에서는 각 VM이 데이터센터의 내부 네트워크와 직접연결되는 IP를 할당 받는다. 따라서 로드밸런서를 경유하건, 퍼블릭 IP를 프라이빗 IP로 직접 맵핑하건(DNAT) 쉽게 서비스를 찾을 수 있다. VM끼리의 통신은 더 쉽다. 통신하려는 VM의 IP만 알고 있으면 된다. 서비스는 보통 도메인으로 찾기 마련이니 IP에 도메인만 붙여주면 된다. 서비스 디스커버리에 고민할 필요 없이 그냥 기존에 쓰던 도메인 시스템 잘 응용하면 된다.

반면 컨테이너의 경우에는 컨테이너 네트워크가 하나 더 만들어지기 때문에 VM에서 사용하던 방법을 쓸 수가 없다. 다른 컨테이너 인스턴스에 있는 컨테이너와 통신을 하는 것도 쉽지 않다. 더 큰 문제는 컨테이너들이 컨테이너 인스턴스를 자유롭게 떠다닌 다는 것이다. VM도 노드 사이를 자유롭게 떠다니기는 하지만, IP가 변하지 않기 때문에 찾는데 전혀 문제가 없다. 하지만 컨테이너의 경우 IP를 고정 할 수 없기 때문에 IP만으로는 서비스를 찾을 수 없다.

IP 기반 디스커버리

컨테이너는 프로세스다. 인터넷상에서 프로세스를 찾기 위해서는 두 번의 과정을 거친다.
  1. 네트워크카드(NIC)를 찾는다. : IP로 찾을 수 있다.
  2. 포트번호에 연결된 프로세스를 찾는다. : 운영체제가 처리한다.
이런 이유들로 테이너도 그냥 포트포워딩 방식으로 서비스하는게 깔끔할 수도 있다. 특히 컨테이너는 하나의 호스트에 VM 보다 훨씬 많은 수를 실행 할 수 있기 때문에, VM에 하던데로 IP를 그냥 썼다가는 IP가 남아나질 않을 것이다.

프라이빗 서비스라면 포트포워딩 방식으로 가도 상관 없다. 하지만 퍼블릭에서라면 표준 포트번호를 사용 할 수 없기 때문에 큰 문제가 될 수 있다. Mysql의 표준포트는 3306 인데 이 번호를 사용 할 수가 없다. 사용성이 떨어질 수 밖에 없다. 어떤 SaaS 애플리케이션에서는 IP 기반으로 사용 할 수동 있다. 예를 들어 소프트웨어 기반의 로드밸런서 클러스터링의 경우, 대역폭의 문제 때문에 하나의 노드에서 만들 수 있는 컨테이너 갯수가 제한된다. 다양한 경우에 IP 기반으로의 응용이 가능하다.

IPv4 기반

네트워크 기반의 거의 대부분이 IPv4 기반으로 작동한다. 소프트웨어들 역시 IPv4를 기반으로 하고 있으며, 다루기도 쉽다. IPv4 기반으로는 아래와 같이 구성 할 수 있을 것이다.

 IPv4 기반 컨테이너 네트워크

호스트 노드에 24 비트 네트워크를 만들고 이 위에 다시 16 비트 네트워크를 만들어서, 통합하는 방식이다. 24 비트 네트워크의 경우 255 개의 IP만 할당 할 수 있다. 자원의 낭비가 있을 수 있는데, 아래와 같은 방식으로 자원을 관리 할 수 있다.
  1. 몇 개의 고성능 노드가 아닌, 낮은 성능을 가지는 여러 개의 노드로 클러스터를 구성한다.
  2. 하나의 호스트 노드에 2개의 24 비트 네트워크를 구성한다. 쉽게 늘릴 수 있기는 하지만 IP의 낭비가 있을 수 있다.
  3. 24비트 보다 더 작은 크기의 서브넷을 구성한다. IP 자원의 낭비를 최소화 할 수 있을 것이다. 관리가 귀찮아지는게 좀 문제인 것 같다. 개인적으로 8 비트씩 딱 나눠떨어지는 서브넷을 좋아하는데, 인식하기가 쉽기 때문이다. 프로그램이 알아서 관리해 준다고 해도, 직관적인 것과 그렇지 않은 것의 차이는 상당히 크다.
172.16.0.0/16 네트워크를 만들고 두 개의 호스트에 172.16.1.0/24와 172.16.2.0/24 네트워크를 만들어서 테스트를 하기로 했다. 테스트를 위한 호스트 구성은 아래와 같다.

 IPv4 테스트 환경 구성

  1. 개인 Linux PC에 OVS 네트워크 172.16.0.1/16을 설정한다.
  2. VirtualBox를 이용 두 개의 테스트 노드를 만든다. Open vSwitch를 이용 각 노드에 172.16.1.0/24, 172.16.2.0/24 네트워크를 구성한다.
호스트 운영체제에 Open vSwitch 네트워크 환경 설정
Open vSwitch 설치는 Open vSwitch Tutorial문서를 참고하자.

IPv6 기반

만약 프라이빗 클라우드 환경을 가지고 있다면 IPv6도 괜찮은 방법이다. 사용 할수 있는 IP의 갯수가 128bit인데, 뭐 그냥 전 지구에 있는 모래알에 IP를 붙이고도 크게 남는 숫자다.
  • 2^128 = 340282366920938463463374607431768211456
  • 지구상의 모래알 수 = 대략 10^22
각 호스트에 64bit 네트워크를 할당 한다. 아래 같은 구성이 될 것이다.