EC2 기반의 ECS도커 배포 시스템을 구축하다보니, 궁금한게 생겼다.
태스크와, 컨테이너의 각각의 cpu, memory 설정을 해야하는데 왜 태스크도 있고 ,컨테이너도 있는건지?
그냥 도커 1개 = 1개 시스템 이 돌아가게 간단하게 만들면 참 좋을텐데...
그 와중에 태스크 정의 생성할 때 , 태스크에 컨테이너1,컨테이너2, 컨테이너3.. 여러개의 컨테이너를 설정할 수가 있던데, 이런 설정은 왜 있는걸까??
알아보자!
하나의 태스크에 컨테이너를 분리해야하는 경우는 언제일까? 그리고 각 컨테이너를 A,B 라고 했을 때, A, B가 동일한 서비스일 경우는 일반적으로 있을까?
답은?
거의 없다. (있긴 있지만.. 내 이해를 위해서)
하나의 태스크(Task) 안에 컨테이너(Container)를 여러 개 분리하는 이유와 그 예시
✅ 하나의 태스크에 컨테이너를 분리해야 하는 경우는?
하나의 태스크 안에 여러 컨테이너를 배치하면, 서로 다른 서비스를 함께 실행하거나 의존성을 유지하면서 동일한 호스트에서 실행할 수 있게 된다.
💡 예시 1:
웹 애플리케이션 + 로깅 서비스
컨테이너 A: 웹 서버 (예: Nginx, Apache, 또는 Node.js 앱)
컨테이너 B: 로깅 서비스 (예: Fluentd, Logstash, 또는 Elastic Agent)
상황:
웹 서버는 로그를 실시간으로 로깅 서비스로 전송해야한다.
이때, 둘을 하나의 태스크 내에서 실행하면, 리소스 공유를 통해 네트워크 통신 비용을 줄일 수 있다.
즉, 웹 앱과 로깅 서비스가 같은 네트워크(태스크 내부)에서 통신하므로, 네트워크 성능이 최적화된다.
💡 예시 2:
API 서버 + 데이터베이스
컨테이너 A: API 서버 (예: Express.js 또는 Flask)
컨테이너 B: 데이터베이스 (예: MySQL, PostgreSQL)
상황:
API 서버가 데이터베이스와 밀접하게 연관된 작업을 할 때, 같은 태스크 내에서 데이터베이스와 API 서버를 실행하는 게 좋다.
이렇게 하면 API 서버와 DB 간의 네트워크 지연을 최소화할 수 있다. (태스크 내 컨테이너들은 로컬 네트워크를 사용하므로 빠르게 연결될 수 있음)
💡 예시 3:
리버스 프록시 + 애플리케이션 서버
컨테이너 A: 리버스 프록시 (예: Nginx)
컨테이너 B: 애플리케이션 서버 (예: Django, Spring Boot)
상황:
리버스 프록시(Nginx)가 애플리케이션 서버를 프록시하는 경우.
이때 리버스 프록시와 애플리케이션 서버를 같은 태스크 내에서 실행하면, 유지 관리와 설정이 용이하고, 네트워크 성능도 향상된다.
A와 B가 동일한 서비스일 경우, 이렇게 분리하는 경우는 있을까?
✅ 일반적으로는 없다!!! 같은 서비스라면 태스크 갯수를 늘리지, 굳이 컨테이너를 여러개 만들지 않지
하지만 특정 조건에서는 이렇게 분리할 수도 있을 수도??
💡 예시 1:
롤백을 위한 버전 관리
컨테이너 A: 기존 버전의 서비스 (예: 버전 1)
컨테이너 B: 새 버전의 서비스 (예: 버전 2)
상황:
새로운 버전으로 롤아웃하면서, 서버 A와 B를 동시에 운영하여 트래픽을 점진적으로 전환할 수 있다.
이 방법은 Blue/Green Deployment와 비슷하며, 트래픽을 100% 새 버전으로 전환하기 전에 기존 버전과 새 버전이 동일한 서비스를 제공하는 경우.
💡 예시 2:
캐싱과 비즈니스 로직 분리
컨테이너 A: 캐싱 서버 (예: Redis)
컨테이너 B: 비즈니스 로직 서버 (예: Express.js 앱)
상황:
비즈니스 로직이 캐시와 통합되어야 하는 경우.
이때, A와 B가 같은 서비스이지만 서로 다른 역할을 맡아서 리소스 분리를 하거나 디커플링할 수 있다.
✅ 결론: 하나의 태스크에 여러 컨테이너를 분리하는 이유
상호 의존성이 있는 서비스들이 리소스를 효율적으로 공유하거나, 성능 최적화가 필요할 때
서비스의 리소스를 분리해서 더 잘 관리하려는 경우
배포나 버전 관리를 점진적으로 롤아웃하고자 할 때
상호작용이 필요한 서비스를 하나의 태스크 내에서 관리할 때
이 후에 API 서버에 redis도 컨테이너화 해서 붙여봐야지!!
to be continued...
