Docker와 Docker Compose의 장단점과 도입하기 좋은 상황

Docker의 장단점

Docker의 장점

• ‘컨테이너’라는 독립된 실행 환경을 제공하여, 개발-배포 환경 간의 차이로 인한 문제를 줄일 수 있음
• 컨테이너는 독립적으로 실행되므로 여러 애플리케이션을 같은 서버에서 격리하여 운영할 수 있어 서로 다른 종속성이나 라이브러리의 충돌을 방지함
• 컨테이너는 가상머신처럼 OS를 별도로 설치하지 않기 때문에 가상머신에 비해 자원을 덜 소모함 → 더 많은 애플리케이션을 같은 서버 내에서 실행할 수 있음
• 애플리케이션의 모든 설정, 종속성, 파일 등을 이미지에 포함시키므로 배포 과정에서 환경 설정의 차이로 인한 문제가 거의 발생하지 않음
• 동일한 Docker 이미지를 이용하면 어느 서버에서도 일관된 환경에서 실행 가능 (이식성)
• Docker 이미지는 버전별로 관리할 수 있어 특정 버전의 이미지를 쉽게 배포하거나 롤백할 수 있고 CI/CD에서 배포할 이미지의 버전을 명시적으로 지정해 관리할 수 있음

 

Docker의 단점

• Docker는 가상 머신보다 효율적이지만 네트워크와 I/O, 시스템 자원에 약간의 오버헤드 발생 가능 → 매우 높은 성능이 요구되는 서비스에서는 성능 저하가 있을 수 있음
• 컨테이너는 기본적으로 비휘발성 데이터 저장소를 포함하지 않으므로 컨테이너를 지우거나 다시 시작하면 저장된 데이터가 사라질 수 있음 → 안전하게 보존하려면 볼륨을 사용하거나 외부 데이터베이스에 저장해야 함
• 여러 컨테이너로 구성된 복잡한 애플리케이션에서는 설정 관리가 어려워질 수 있음
• 컨테이너는 커널을 공유하기 때문에 보안에 민감한 서비스에서는 특정 보안 설정을 신경 써야 함

 

Docker를 도입하기 좋은 상황

• 일관된 환경이 필요한 경우 → 많은 팀원이 함께 하는 프로젝트 등에서 다양한 환경 간의 차이로 인한 문제를 줄일 수 있음
• 각 기능이 서로 다른 종속성을 가지며 독립적으로 배포되고 확장되어야 하는 경우 → 격리된 실행 환경을 제공하여 각 기능을 효과적으로 관리할 수 있게 해줌
• 빠른 테스트 환경 설정이 필요한 경우 → 새 버전의 애플리케이션이나 특정 설정을 테스트할 때 컨테이너를 이용해 기존 환경에 영향을 주지 않고 별도의 테스트 환경을 쉽게 구축할 수 있음
• 서버 자원 최적화가 필요한 경우 → 여러 애플리케이션을 같은 서버에서 효율적으로 운영하고자 할 때 Docker의 경량화된 컨테이너 구조가 서버 자원 절약에 도움됨

 

Redis를 Docker로 띄우는 게 나을까 직접 설치하는 게 나을까?

Docker로 띄우기

• 장점
  • Docker 컨테이너 내에서 Redis가 실행되기 때문에 다른 서비스와 독립적으로 관리할 수 있어 충돌 가능성을 줄임
  • 동일한 Redis 환경을 다른 서버나 개발 환경에서 쉽게 복제할 수 있어 일관성 있는 개발/테스트 환경을 유지하기에 좋음
  • 버전을 업데이트하거나 다른 서버로 이전할 때 Docker 이미지를 활용해 쉽게 배포/관리할 수 있음
  • 이미지와 컨테이너 설정을 통해 빠르게 재배포 가능
• 단점
  • Redis는 고속의 데이터 처리가 중요한 경우가 많기 때문에 컨테이너 오버헤드로 인해 성능 저하가 발생할 수 있음
  • Redis의 영구적 데이터 저장, 고급 네트워킹 설정 등이 필요할 경우 Docker 설정이 복잡해질 수 있음

 

직접 설치

• 장점
  • Docker 오버헤드가 없어 최대 성능을 발휘할 수 있음 → 특히 높은 TPS를 요구하는 상황에서 유리
  • 운영 체제에 직접 설치하기 때문에 추가적인 Docker 설정 없이 바로 실행하고 관리할 수 있음
• 단점
  • 서버 환경에 직접 설치되므로 다른 서비스와의 의존성 관리나 충돌 가능성이 있을 수 있음
  • Redis 설정이나 버전이 서버마다 달라질 수 있으며 이를 다른 서버로 쉽게 이전하는 것이 어려움
  • Docker의 이미지 기반 배포 방식에 비해 Redis의 업데이트나 복구가 더 번거로울 수 있음

 

결론

• 개발 및 테스트 환경에서는 Docker를 활용해 이식성과 관리 용이성을 높이기
• 프로덕션 환경에서 Redis의 성능이 중요한 경우에는 Docker 없이 직접 설치해 최상의 성능을 확보하기

 

 

Docker Compose의 장단점

Docker Compose의 장점

• 여러 컨테이너의 설정을 하나의 docker-compose.yml 파일에 정의할 수 있음
  • docker-compose up과 같은 명령어로 손쉽게 여러 컨테이너를 한꺼번에 시작, 중지할 수 있음
  • 다른 서버에서도 동일한 환경을 쉽게 복제할 수 있음
• Compose는 기본적으로 각 서비스 간의 연결을 위한 네트워크를 자동으로 구성하여, 서로 통신이 필요한 서비스는 이를 통해 손쉽게 같은 네트워크에 두고 관리할 수 있음
• 업데이트 시 특정 서비스만 재시작 가능
• .env 파일 같은 민감한 정보를 쉽게 관리할 수 있고 특정 환경별로 다른 설정을 적용할 수도 있음

 

Docker Compose의 단점

• 설정 파일이 길어질 수 있어 여러 서비스가 복잡하게 얽히면 docker-compose.yml 파일의 관리가 어려워질 수 있음
• Compose로 시작한 여러 컨테이너 중 특정 컨테이너만 재시작하거나 변경하기가 불편할 수 있음 → 독립적인 컨테이너 제어가 필요하면 각 컨테이너를 별도로 관리하는 게 나음
• 모든 서비스를 하나의 Compose 파일로 시작하면 개발 환경에서 필요하지 않은 서비스까지 함께 실행될 수 있어 불필요한 리소스를 사용할 수 있음

 

Docker Compose를 도입하기 좋은 상황

• 여러 서비스 간 연결이 필요한 경우 → Redis(캐시 서버)-Nest.js(API 서버)와 같이 상호 통신이 필요한 여러 컨테이너를 함께 배포해야 할 때 적합함
• 일관된 환경이 필요한 경우 → 팀원이 많은 프로젝트나 여러 환경에서 일관된 설정을 유지하고자 할 때
• 테스트/로컬 환경 구축 시: 개발 환경에서 여러 의존성을 쉽게 관리하고 설정 변경도 docker-compose.yml만 수정해 손쉽게 적용할 수 있어 개발 편의성이 높아짐

 

Redis와 Nest.js를 하나의 Docker Compose로 관리하는 것이 나을까?

• Docker Compose는 서비스 간 네트워크를 기본적으로 제공하기 때문에 Redis와 Nest.js 간 통신을 쉽게 설정할 수 있음
  • e.g. Nest.js에서 Redis에 연결할 때 localhost 대신 redis처럼 서비스 이름으로 연결 가능
• 두 서비스를 하나로 관리하면, Redis가 없으면 Nest.js도 시작하지 않는 등 종속성을 관리할 수 있음
• Redis와 Nest.js를 함께 정의함으로써 테스트 환경을 로컬에서 쉽게 실행할 수 있고 배포 시에도 동일한 환경을 구축할 수 있음