Docker 네트워크 구성과 구성별 기능에 대한 고민

Contents

도커 컨테이너의 사용 목적에 따라서, 다양한 네트워크 모델을 설계할 수 있을 것이다. 예컨데,

1. 탄력적인 운용보다 성능이 더 중요 한 경우
2. 성능보다 탄력적인 운용이 더 중요 한 경우
3. 네트워크 격리, 네트워크 서브넷 구성과 같은 네트워크 기능이 필요한 경우

등 운용성 & 성능 & 기능간의 적절한 트레이드오프를 통해서 최적의 모델을 설계해야 한다.

도커로 Paas를 서비스한다고 가정해 보자. 이 서비스의 네트워크의 특징은 아래와 같이 정의 할 수 있다.

• 유저에게는 애플리케이션이 제공된다.
• 네트워크, 스토리지, 운영체제는 유저에게 전혀 보이지 않는다.

유저는 애플리케이션만 바라볼 뿐, 애플리케이션 뒷단의 네트워크 흐름을 알 수 없기 때문에(신경쓸 필요도 없다.) 네트워크의 격리에 신경 쓸 필요가 없다. 단지 애플리케이션의 격리만 신경 쓰면 되는데, 이는 일반적인 유저관리 시스템의 영역이다.

웹과 WAS처럼 애플리케이션과 애플리케이션이 연결되는 경우에도, 각 애플리케이션의 유저 권한을 확인해서 연결만 시켜주면 된다.

따라서 Paas에서 네트워크는 아주 단순화 해서, 성능을 우선하는 방향으로 설계할 수 있다.

플랫(Flat)하게 구성한다. 각 호스트에 24비트 네트워크를 할당한다. 하나의 호스트에 254개의 인스턴스를 만들 수 있는데, 이 정도면 충분한 크기일 것이다. 이제 16비트 네트워크를 하나의 zone으로 만들면, 최대 254개의 호스트로 구성되는 zone을 구성 할 수 있다. 48U 랙에 16개의 호스트를 집어 넣는다면, 하나의 zone은 16개의 랙으로 구성할 수 있을 거다. 네트워크 레벨에서 애플리케이션들은 격리하지 않는다. 호스트 내부의 컨테이너들은 브로드캐스팅 도메인으로 묶이며, 다른 호스트의 컨테이너들과는 L3 영역에서 통신할 수 있다.

애플리케이션간의 격리는 리눅스에서의 프로세스와 동일한 모델을 따른다.

1. 격리는 하지 않는다.
2. 애플리케이션 레벨에서의 통신 채널에 대한 접근을 제어한다.

리눅스에스 프로세스간 통신을 위한 수단으로 IPC를 이용한다. IPC는 전역자원이며, IPC에 대한 권하을 설정하는 것으로 프로세스간 통신을 관리 한다.

Paas에서 일반 유저는 운영체제와 네트워크에 접근할 수 없으므로, 인프라 차원에서 컨테이너간 통신 채널에 대한 권한만 제어하면 된다. 규칙은 단순하다 동일한 유저가 소유한 컨테이너들 간의 통신만 가능하게 하면 된다.

이 경우 서로 다른 유저의 컨테이너들간의 통신을 원할 경우 어떻게 할래 ? 라는 문제가 생길 수 있다. 이 문제는 그룹 개념을 도입함으로써 해결할 수 있다. AWS의 IAM과 같은 시스템이라고 보면 되겠다.

Iaas라면 DHCP가 중요하겠지만, Paas에서 DHCP는 중요하지 않다. 유저는 연결할 컨테이너의 이름만 알고 있으면 된다. 따라서, DHCP를 이용하지 않고 컨테이너를 올릴 때 IP를 직접 할당한다. 이 IP는 persistent 하게 한다. 컨테이너는 삭제하지 않는 한, 항상 동일한 호스트에서 동일한 IP로 올라온다.

컨테이너의 가용성 확보는 인프라가 아닌, 애플리케이션 영역에서 로드밸런서를 이용해서 처리한다. 서비스의 대부분은 가용성과 확장성을 위해서 로드밸런스를 이용한다.

• 전용 네트워크 장비 : 클라우드 환경에 대응하는 네트워크 장비들이 있다. 로드밸런서를 인스턴스로 만들고, 이들 인스턴스를 scale-in/out, scale-up/down하는 것으로 가용성과 확장성을 확보한다.
• 오픈소스 기반 구성 : haproxy로 구성한다.
• GSLB와 함께 사용해야 할 것 같다. NginX의 GSLB 기능을 조사해 봐야 겠다.