온라인 마켓플레이스 플랫폼 개발(쇼핑몰) 프로젝트의 모놀리식 프로젝트를 docker를 이용하여 AWS EC2에 호스팅을 해보았다. 하지만 MSA 방식을 사용해 보기 위해여 각 서비스(기능) 별로 구별하여 5개의 레포지토리(front, user, product, order, review)로 나누어 보았다.
이 각각의 서비스들을 AWS EC2에 연결하기 위하여 docker-compose를 사용해보려고한다.
Docker Compose는 단일 서버에서 여러개의 컨테이너를 하나의 서비르로 정의해 컨테이너의 묶음으로 관리할 수 있는 작업 환경을 제공해주는 관리 도구입니다.
여러 개의 컨테이너가 하나의 어플리케이션으로 동작할 때 도커 컴포즈 를 사용하지 않는다면, 이를 테스트하 려면 각 컨테이너를 하나씩 생성해야 합니다. 예를 들면, 웹 어플리케이션을 테스트하려면 웹 서버 컨테이너, 데이터베이스 컨테이너 두 개의 컨테이너를 각각 생성해야 합니다.
그래서 컨테이너의 수가 많아지고 정의해야할 옵션이 많아진다면 Docker-Compose를 사용하는 것이 좋습니다.
먼저 모놀리식 프로젝트에서 도커 허브에 이미지를 푸쉬햇던것과 유사하게 생각하면된다.
AWS EC2에 Docker를 사용하여 Spring Boot 프로젝트 호스팅하기
위 링크를 따라 1~3번(Dockerfile생성, 빌드, 도커허브)까지를 각 프로젝트마다 해주면 된다.
Docker-compose를 사용할 ec2에서 docker-compose를 설치해야한다.
// 설치 전 우분투 시스템 패키지 업데이트
sudo apt-get update
// Docker Compsoe를 설치합니다. (설치 버전 : 2.5.0)
sudo curl -L https://github.com/docker/compose/releases/download/v2.5.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
// 다운로드 한 파일에 권한 설정
sudo chmod +x /usr/local/bin/docker-compose
// 설치가 완료되었는지 확인하기 위해 도커 컴포즈의 버전을 확인
docker-compose --version
EC2에 docker-compose.yml파일을 생성 -> docker-compose.yml작성
services:
front-service:
image: ssuminn/front:latest
ports:
- "8081:8081"
networks:
- app_network
user-service:
image: ssuminn/user:latest
ports:
- "8082:8082"
networks:
- app_network
product-service:
image: ssuminn/product:latest
ports:
- "8083:8083"
networks:
- app_network
order-service:
image: ssuminn/order:latest
ports:
- "8084:8084"
networks:
- app_network
review-service:
image: ssuminn/review:latest
ports:
- "8085:8085"
networks:
- app_network
networks:
app_network:
driver: bridge
docker-compose.yml을 사용하여 여러 개의 서비스를 정의하고 해당 서비스들을 하나의 네트워크에 연결하는 방법을 나타냅니다.
여기서 각 서비스는 개별적인 이미지를 사용하여 컨테이너를 실행하며, 서비스마다 고유한 포트를 호스트와 연결하여 외부에서 접근할 수 있도록 합니다.
각 서비스는 app_network라는 도커 브릿지 네트워크에 속하며, 이 네트워크는 도커 컨테이너들 간의 통신을 위한 가상 네트워크를 제공하여 각 서비스가 서로 통신할 수 있게 해줍니다.
docker-compose를 실행하기 전 도커 허브에서 ec2로 각 서비스의 이미지를 Pull을 받습니다.
// 도커 허브에 존재하는 이미지를 pull 받습니다.
sudo docker pull 도커허브 ID/Repository 이름
docker-compose실행
// 현재 디렉토리에 있는 docker-compose.yml 파일에 정의된 서비스들을 실행합니다.
// 여러 개의 도커 컨테이너를 동시에 run
docker-compose up
// 백그라운드로 실행합니다.
docker-compose up -d
처음에 프리티어로 ec2를 생성하여 작업을 하는 중 docker-compose up을 하니 죽간에 cpu문제로 서버가 다운되버렸다... 메모리 1기가라 그런가...? 인스턴스를 재시작하여 확인해보았지만 이번에는 저장소 문제로 파일수정등에 문제가 생겼다.
ec2인스턴스 -> storage -> volumes -> modify
-> size 30으로 변경(프리티어에서 가능한 최대 용량으로 알고있습니다.)
❗️한번 변경하고나면 6시간 이후에 변경 가능하니 수정하실때 주의❗️
그리고 부족한 메모리는 ec2인스턴스의 사양을 높이거나 swap 메모리를 사용하는 방법인데 사양을 높이는 건 다른 방법들을 시도해보고 하기로 결정하였습니다.
위에 링크 처럼 진행을 하고 나면 아래 사진 처럼 스왑 메모리가 할당된거를 확인할 수 있다.
보통 swap 메모리는 기본 RAM 용량의 2배정도를 잡는 것을 권장한다.
스왑 메모리의 장점과 단점을 확인해보자.
장점:
메모리 확장: 물리적인 RAM이 부족할 때 시스템의 메모리를 확장하여 추가적인 공간을 제공할 수 있습니다.
프로세스 관리: Swap 메모리를 사용하여 현재 실행 중인 프로세스를 디스크로 스왑하여 메모리를 확보할 수 있습니다. 이를 통해 시스템이 더 효율적으로 프로세스를 관리하고 메모리를 최적화할 수 있습니다.
안정성: 물리적인 RAM이 부족할 때도 시스템이 계속 동작할 수 있도록 보장합니다. 이는 시스템이 갑작스런 메모리 부족으로 인한 충돌을 방지할 수 있습니다.
단점:
성능 저하: Swap 메모리는 디스크에 저장되기 때문에 RAM에 비해 접근 속도가 느립니다. 메모리에 비해 시스템 성능이 저하될 수 있습니다. 특히, 반복적으로 Swap이 발생하는 경우 성능 저하가 발생할 수 있습니다.
디스크 사용량 증가: Swap 메모리를 사용하면 디스크 공간을 추가적으로 사용해야 합니다. 따라서 시스템 디스크 사용량이 늘어날 수 있습니다. 또한, 빈번한 Swap 작업은 디스크를 자주 읽고 쓰기 때문에 디스크의 수명을 단축시킬 수 있습니다.
응답 지연: 메모리 스왑이 발생할 때 시스템이 디스크에 액세스해야 하므로, 프로세스의 응답 시간이 지연될 수 있습니다. 특히, 사용자가 많은 작업을 수행할 때 이러한 지연이 더 심해질 수 있습니다.
결론
Swap 메모리는 메모리 부족 시에는 시스템의 안정성을 유지할 수 있는 방법이지만, 너무 빈번하게 사용되거나 너무 많은 양의 Swap 메모리가 사용되는 것은 시스템 성능에 부정적인 영향을 줄 수 있습니다. 따라서 적절한 메모리 관리와 모니터링이 필요합니다.