인프라는 문서가 아니라 실행 가능한 구성이다.
Compose로 팀의 개발 환경을 동일하게 만든다.
개발자가 로컬에서 겪는 환경 차이를 없애기 위해,
운영 인프라를 Docker Compose로 고정하는 방식을 사용합니다.
이를 통해 팀원들의 개발 환경을 동일하게 맞출 수 있고,
운영 인프라에서 발생할 수 있는 문제를
localhost 환경에서 미리 재현하고 대응할 수 있습니다.
저의 경우, 다음과 같은 구성을 로컬에서 세팅했습니다.
- Oracle 1대
- Redis 3대(Cluster, Master - Slave)
- Backend 3대
docker-compose.oracle.yml
oracle yml 파일
oracle init 파일
Oracle은 로컬에 직접 설치하기 번거롭고,
버전 및 초기 설정 차이가 발생하기 쉬워 Docker Compose로 고정했습니다.
컨테이너 기동 시 초기 SQL을 실행하도록 구성하여,
계정 생성까지 자동화합니다.
docker-compose.redis.yml
redis cluster yml 파일
Redis는 각 Container에 단일 Redis 인스턴스를 두고,
Master 3개로 Cluster를 구성하여 Docker Compose로 고정했습니다.
각 Master에는 서로 다른 Container의 Slave를 연결하여,
A PC의 Master – B PC의 Slave,
B PC의 Master – C PC의 Slave,
C PC의 Master – A PC의 Slave 형태로
교차(replica) 구조를 구성했습니다.
이를 통해 특정 Redis 노드가 Down되더라도
동일 머신에 Master와 Slave가 동시에 장애를 일으키는 상황을 피하도록 설계했습니다.
docker-compose.dev.yml
backend yml 파일
nginx yml 파일
이제 backend를 세팅하겠습니다.
Backend는 NestJS 기반 Node App 3개를 띄우고,
Nginx를 통해 Load Balancing을 구성했습니다.
각 인스턴스는 동일 이미지로 실행하며,
Nginx는 upstream으로 3대를 묶어 라운드로빈으로 분산합니다.
외부에서는 Nginx만 바라보도록 구성해
로컬에서도 수평 확장 형태를 재현했습니다.
맺은말
이 구성은 로컬에서 운영 인프라를 최대한 유사하게 재현하기 위한 예시입니다.
환경 차이로 인한 문제를 줄이고,
인프라 변경이나 장애 상황을 사전에 확인하는 용도로 사용하고 있습니다.
각 구성은 필요에 따라 단순화하거나 확장해도 무방합니다.