실용적인 (도커)컨테이너 구축 및 배포를 위한 지식_1

애플리케이션 내 단일 컨테이너의 적정 비중

---

실제 운영에서는 애플리케이션을 컨테이너 안에 어떻게 배치하는지가 매우 중요하다.

• 컨테이너 하나가 맡을 수 있는 적정 수준의 책임은 어느 정도일까?
• 세세하게 역할을 나누다가 시스템 전체의 복잡도가 올라가지는 않을까?

단일 컨테이너의시스템 내 비중은 어떻게 결정해야하는지 알아보자.

컨테이너 1개 = 프로세스 1개?

---

애플리케이션 + 인프라 = 도커 컨테이너

결과부터 말하자면, 컨테이너 1개 = 프로세스 1개 원칙은 괜찮게 생각될 수 있으나 지나치게 복잡해질수도 있다.

예를 살펴보자

정기적으로 작업을 실행하는 애플리케이션

정기적으로 어떤 작업을 실행하는 컨테이너가 있다고 가정해보자.

스케줄러 + 작업이 합쳐진 애플리케이션을 만든다면 컨테이너 1개 = 프로세스 1개 원칙을 지킬 수 있을 듯 하다. 그러나 대부분은 스케줄러를 외부기능에 의존한다. 예제의 애플리케이션도 스케줄러 기능을 갖고 있지 않다고 가정한다.

cron은 1개의 상주 프로세스 형태로 동작하는데, 이 스케줄러가 실행하는 작업 역시 하나의 프로세스로 동작한다.

컨테이너 1개 = 프로세스 1개 방식을 택한다면, cron, Job 이 각각 1개의 컨테이너의 형태로 구성해야 한다.

이렇게 구성해야한다면 아래와 같은 방법이 존재한다.

1. 작업 컨테이너 쪽에서 작업을 실행하는 트리거 역할을 하는 API 구축, cron 컨테이너가 컨테이너 간 통신을 통해 API를 호출하는 구조
2. cron 컨테이너에 도커를 구축하고 다시 그 위에 작업 컨테이너를 실행하는 구조

수행하기 불가능하지 않지만, 이런 방법은 지나치게 복잡하다.

⇒ 컨테이너 하나에서 cron과 작업까지 2개의 프로세스를 모두 실행하는 형태가 깔끔하다.

컨테이너 1개 = 프로세스 1개를 억지로 고수하는 것보다 1개 이상의 프로세스를 실행하는 컨테이너를 허용하는 쪽이 간결한 형태를 유지할 수 있는 경우가 많다.

 

컨테이너 1개에 하나의 관심사

---

도커의 공식 문서 "Best Practices for writing Docerfiles" 에는 다음과 같은 공식 입장이 담겨있다.

Each container should have only on concern.(컨테이너는 하나의 관심사에만 집중해야 한다.)

컨테이너 하나는 한 가지 역할이나 문제 영역(도메인)에만 집중해야 한다는 의미다.

컨테이너를 사용하지 않는 스택에서는 리버스 프록시, 애플리케이션, 데이터 스토어가 서로 독립적으로 자기 역할을 수행하며 전체 시스템을 구성한다. 이런 분리 구조라면 이를 그대로 컨테이너로 바꿔도 어색하지 않다.

각 컨테이너가 맡을 역할을 적절히 나누고, 그 역할에 따라 배치한 컨테이너를 복제해도 전체 구조에서 부작용이 일어나지 않는가? 를 따져가며 시스템을 설계해야 한다.