문제 상황
개발 환경과 실제 운영 환경을 분리하여 운영하기 위해 ec2 인스턴스를 추가로 생성하여
기존의 환경을 옮겨야 한다.
기존 컨테이너를 그대로 옮기는건 큰 문제가 되지 않는다.
-
어떤 ec2 인스턴스가 우리 서비스에 가장 적합한가?
-
현재 운영중인 데이터베이스의 데이터들은 어떻게 옮길 것인가?
ec2 인스턴스 고르기
요금 문제로 ec2 프리티어를 자주 사용해서, 무료 인스턴스 생성은 이제 익숙하다.
하지만 실제 운영되는 서버에 사용될 인스턴스이기 때문에 신중하게 고를 필요가 있다.
체크해야 할 부분
1. ec2 서비스 지역 확인
-> 아시아 태평양(서울) 이랑 미국에 오하이오 처럼 ec2 지역마다 대여 가격이 다르다.
2. 비용 결제 방식 확인
-> 가장 중요한 '비용'에 대한 결제 방식을 고려한다. 3가지 방식을 소개하면
- 온디맨드: 대여한 스펙에 맞게, 사용한 시간 만큼 결제
- 컴퓨팅 절감형: 약정형 대여 (할인 많이 해줌), 도중에 인스턴스 스펙 변경시 제약이 없음(당연히 추가비용은 발생 가능함)
- EC2 인스턴스 절감형: 약정형 대여 (할인 많이 해줌), 도중 인스턴스 스펙 변경에 제약이 있을 수 있음(인스턴스 유형이 비슷한 것 끼리만 변경 가능)
3. 인스턴스 유형
-> 대여할 인스턴스의 스펙을 고려한다.
현재 ec2 인스턴스를 사용중이고, 서비스하고 있는 중이면
htop 명령어를 통해 실시간 서버 리소스 사용량을 확인할 수 있다.
인스턴스 스펙 3요소를 보면
- CPU 성능
-> 현재 서비스의 cpu 사용량에 대해서 확인을 해본다. cpu 코어 개수가 많아질수록 가격 상승폭이 높음.
cpu 종류에 따라서 가격도 꽤 많이 차이난다.
cpu 인스턴스들은 특정 문자들로 시작한다.
cpu 시리즈 중에서 t 시리즈를 많이 고려했기 때문에 다른 시리즈는 좀 더 찾아보길 바란다.-
t 시리즈
t 시리즈는 기본 성능은 낮다. 하지만 t 시리즈에는 '버스트' 라는 기능이 있다. t 시리즈는 '크레딧' 이라는걸 cpu 사용량이 적을 때 계속 조금씩 쌓아둔다. 그러다가 cpu 사용량이 폭발적으로 늘어나는 순간이 오면 크레딧을 사용해서 성능 향상을 시킬수 있다. t 시리즈 마다 cpu 사용량 기준이 되는 지점이 있는데 해당 지점을 넘게되면 '버스트'가 활성화 된다. t1 : 초창기 버전이다. 현재 지원 x t2 : cpu 사용량이 많아져서 크레딧을 전부 소비하게 되면 속도가 제한된다. -> cpu 사용량 10~20% 이상시 버스트, 크레딧 소진시 속도 제한 걸림 t3 : unlimited 옵션을 켜면 추가 요금을 발생시키지만 속도를 유지할 수 있다. -> cpu 사용량 20~30% 이상시 버스트, 크레딧 전부 소진해도 unlimited 옵션을 켜면 속도 유지 but 추가요금 발생 t4g : unlimited 옵션을 켜면 추가 요금을 발생시키지만 속도를 유지할 수 있다. 'g' 가 붙었는데 g 는 아마존 자체 개발 인스턴스이고 그렇기에 '더 저렴하고 더 빠르다'라는 특징이 있음 g가 붙은것들은 !!⭐ARM 기반의 인스턴스이다.⭐!!(ARM 기반의 프로세서와 내 운영 서비스가 호환하는지 잘 찾아보기) -> cpu 사용량 20~30% 이상시 버스트, 크레딧 전부 소진해도 unlimited 옵션을 켜면 속도 유지 but 추가요금 발생 -
c 시리즈
c 시리즈는 cpu에 최적화된 인스턴스 유형이다. cpu 처리량이 많은 서버의 경우 c 시리즈로 시작하는 인스턴스를 사용하는게 좋다. -
r 시리즈
r 시리즈는 메모리에 최적화된 인스턴스 유형이다. 메모리 속도가 빠르고 많은 용량이 필요할 경우 선택하게 된다. -
i 시리즈
i 시리즈는 스토리지에 최적화된 인스턴스 유형이다. 읽고 쓰기가 많은 경우 저장장치의 읽고 쓰는 속도가 중요한데 읽고 쓰기 작업의 속도가 중요할 때 사용하는걸 추천한다.
-
- RAM 용량
-> 메모리 여유 공간을 확인한다. 평상시 메모리 사용량보다, 배포할 때 메모리 최대 사용량을 확인해보는게 좋다.
서버가 켜져있을 때 보다 컨테이너들을 만들면서 메모리 부족으로 터지는 경우가 많았다.
-> 인스턴스 뒤에 small, medium, large, xlarge 이렇게 붙은건 메모리 용량마다 차이가 난다.
- 저장 용량
-> 인스턴스에 저장되는 데이터가 많다면 크게 잡아줘야겠지만 엄청 클 필요는 없는것 같다.
적당하게 30 ~ 50GB 으로 잡아서 사용중
->저장 용량이 많아질수록 당연히 가격이 상승하고, 또한 저장장치도 빠른걸 쓰면 그만큼 비용이 증가함
또한 '스냅샷' 이라는 기능이 있는데 특정 주기마다 백업을 하는 기능이다. 이 기능을 사용하게 되면 추가 비용이 많이 발생하는것 같은데 그냥 자체로 백업을 하는게 맞다고 본다.
데이터베이스 마이그레이션
인스턴스를 골라서 생성하고 나서
compose.yml을 옮기거나 각종 설정들을 다 해준 후
실제 운영데이터들을 옮겨야 할 것이다.
MySQL
MySQL은 Data Exports를 해주면 된다.
보통 MySQL 쓸 때 cli 보다는 workbench를 많이 사용하는데
여기서 스키마 선택하고 Data Exports 해주면 dump 파일들이 생긴다.
이를 새로운 인스턴스에 접속해서 Data Import 해주면 끝
MongoDB
MySQL에서 스키마(DB) 라고 하는거를 MongoDB 에서는 그냥 DB 라고 하고
MySQL에서의 테이블을 MongoDB에는 Collection 라고한다.
또한 mysql의 튜플은 mongoDB에서 document 라고 한다.
그런데 중요한 점은
MySQL workbench에서는 DB exports 가 되어서 스키마 내부에 테이블들을 한번에 백업할 수 있다.
그런데 MongoDB 전용 툴인 MongoCompass 에서는 그게 안된다. 그래서 collection이 많다면 하나씩 옮기느라 시간이 오래걸릴 수 있다.
또한 각 DB 마다 '계정' 이 존재해서 이러한 정보들은 또 수동으로 옮겨줘야 한다.
나는 운영 mongo 안에 컬렉션이 너무 많아서 다른 방법을 찾았는데
컨테이너에 직접 접속해서 dump를 만들고 이를 밖으로 꺼내서 사용했다.
MongoDB 전체 DB dump 생성 후 복원
- 이전 서버에서 dump 파일 생성하기 (mongo컨테이너 내부에 저장됨)
docker exec -it mongo mongodump -u <계정ID> -p <계정PW> --authenticationDatabase admin --out /data/dump- 컨테이너 내부 dump 파일을 컨테이너 밖에 복사 (docker cp 사용)
docker cp mongo:/data/dump ./dump- FTP로 해당 dump 파일을 새로운 서버로 옮긴 후 dump파일을 mongoDB 컨테이너 안으로 복사
docker cp /home/ubuntu/dump mongo:/data/dump- mongo 컨테이너 접속해서 mongorestore 하기
docker exec -it mongo mongorestore -u <계정ID> -p <계정PW> --authenticationDatabase admin /data/dump이러한 과정을 거치게 되면 내부 데이터를 복제해서 옮기는 것이기 때문에
온전한 데이터 이전이 가능하다.
물론 옮기는 과정 중 발생하는 데이터는 유실되므로 서비스를 중지하고 옮겨야 한다.
이렇게 ec2 이전 작업을 해보았다.
끝
