인프라 분산 구현

하나의 서버 EC2에 집중되어 있던 서비스와 컨테이너를 분리 진행했다.

기존의 서버 구성은 다음과 같다

service

postgis

memcached

nginx

certbot

 

위 5개의 컨테이너를 아래와 같이 분산 구현하려고 한다
1번 EC2: service, nginx, certbot

2번 EC2: postgis

3번 EC2: memcahced 

 

인프라를 분산하여 구현하려는 이유는 다음과 같다.

1. 성능 향상 및 확장성

• service, Nginx, Certbot 인스턴스
  • 웹 애플리케이션과 관련된 모든 것이 한 곳에 있기 때문에, 웹 트래픽을 쉽게 관리하고, 애플리케이션의 로드 밸런싱을 구현 가능
  • 필요에 따라 인스턴스를 수평적으로 확장하여 더 많은 트래픽을 처리 가능
• memcached 인스턴스
  • 캐시 서버를 별도로 둬서 캐시의 부하를 따로 관리할 수 있으며, 메모리 사용량을 최적화
  • 캐시를 여러 애플리케이션 서버에서 공유
• PostGIS 인스턴스
  • 데이터베이스 서버를 분리하여 데이터베이스의 부하를 다른 애플리케이션 서버와 분리하여 관리
  • 데이터베이스 성능 최적화와 보안을 독립적으로 관리

2. 안정성 및 가용성

• 각 서비스 분리할 경우 한 컴포넌트의 장애가 다른 컴포넌트에 영향을 미치지 않는다. 예를 들어, 애플리케이션 서버에 문제나 장애 발생시 데이터베이스 서버나 캐시 서버는 정상적으로 동작할 수 있다.
• 개별 인스턴스를 독립적으로 재시작하거나 유지보수할 수 있어, 서비스 다운타임을 최소화

3. 보안 강화

• 각 서비스가 분리되어 있으면, 보안 정책을 더욱 세밀하게 적용할 수 있다.
• 데이터베이스 서버에 대한 접근을 제한, 애플리케이션 서버와 캐시 서버는 필요한 포트만 열어 보안 위협을 줄일 수 있다.

4. 관리 용이성

• 서비스가 분리되어 있으면, 각 서비스의 로그, 모니터링, 백업 등을 독립적으로 관리가 가능하기 때문에 문제를 쉽게 진단하고 해결할 수 있다.
• CI/CD 파이프라인을 개별 서비스에 맞춰 구축이 가능하기 때문에 배포 속도를 높일 수 있다.

1. 보안그룹 설정

인프라 분산을 구현하기 위해 AWS EC2 인스턴스를 추가로 생성한다. 인프라마다 설정이 다 다르기 때문에 생성하는 방법은 따로 설명하지 않음, 본 인프라 구현에서는 t3.medium ubuntu로 생성하여 사용.

생성시에 보안그룹을 설정해줘도 되고 생성시에 설정해줘도 된다.

 

보안그룹 생성 설정은 다음과 같다.
서비스 EC2-보안그룹 1

인바운드:22(SST), 80(HTTP), 443(HTTPS) 모든 IP (0.0.0.0/0)에서 접근 허용

아웃바운드: 모든 IP (0.0.0.0/0)로 나가는 트래픽을 허용

 

DB EC2-보안그룹 2
인바운드: 22(SST), 5432(postgis) 보안그룹 1에서 접근 허용

아웃바운드: 5432 모든 IP (0.0.0.0/0)로 나가는 트래픽을 허용

 

캐시 EC2-보안그룹 3
인바운드: 22(SST), 11211(memcached): 보안그룹 1에서 접근 허용

아웃바운드: 11211 모든 IP (0.0.0.0/0)로 나가는 트래픽을 허용

 

이렇게 설정시 외부에서는 서비스 서버로만 접근이 가능하며 DB, 캐시 서버로는 접근이 불가능하고, 위에서 언급한 장점을 살릴 수 있다.

 

실제로 포트가 연결됐는지 확인하는 방법은 다음과 같다.

telnet {privateIP} {port}

실제로 연결해보면 아래와 같이 Connected to {private ip} 문구가 나온다면 제대로 설정한것이다.

 

그러면 기존의 배포는 하나의 EC2 인스턴스에 몰아서 했지만 3개의 EC2 인스턴스로 분리하면서 docker-compose.yml도 3개로 분리후 적용 시켰다. 서비스 EC2 인스턴스는 주기적으로 버전관리와 업데이트가 발생하지만 DB와 캐쉬의 서버는 업데이트가 주기적으로 발생하지 않기 때문에 실제로 CI/CD가 주기적으로 배포되는것은 서비스 docker-compose 밖에 없다.