[AWS] VPC Migration

만드려는것

디폴트 vpc를 사용하고 있던 환경에서 마이그레이션을 하려고 한다.

 

db서버가 퍼블릭 vpc에 있는게 마음에 걸리기도 하고,

서비스 런칭으로 production server에 트래픽이 증가함에 따라 정보 유출에 대한 걱정이 커지고있다.

(오투오 서비스라 민감한 정보가 DB에 들어간다)

 

MFA + private subnet 콤보로 보안을 챙겨보겠다.

(db접근은 mfa를 거쳐서만 갈 수 있도록)

 

그래서 오늘은 production server는 아니고, development server에서 테스트를 진행하기로 했다.

 

EC2와 Load Balancer는 public subnet에 두어서

1. 로드밸런서는 유저 트래픽 받기

2. EC2는 ssh연결하여 db 접속 용도 (말고도 뭐 서버 관리도..)

 

정도로 사용하겠다.

 

 

https://repost.aws/knowledge-center/move-ec2-instance

Move an Amazon EC2 instance to another subnet, Availability Zone, or VPC

re:Post에 좋은 자료가 있어서 이걸 참고했다.

 

참고자료 일부

그래서 AWS System Manager를 쓰거나, 직접 하거나인데..

 

후자의 방법은 내 환경에 적용하려면 이런식으로 해야겠다.

running server는 그대로 두고 load balancer, ec2, rds를 구성된 서브넷에 연결하여 생성

확인 후 route 53에서 레코드를 변경 (A레코드 alias -> load balancer의 dns를 새로 만든걸로 변경)

이렇게 하면 다운타임이 거의 없을 것 같다.

db의 마이그레이션이 아마 가장 걱정되는 부분이 아닐까 싶다.

 

전자의 방법에 대해 소개하자면 ..

automation runbook으로 딸깍 딸깍만 하면 알아서 이전을 해준다고 한다.

managed instance가 아니면 문제가 생길수도 있다고 한다.

그래서 Quick Setup을 통해 설정을 할 수 있다고 한다.

 

항상 사용 전 pricing을 체크하자. ^_^

 

설정하고 바로 되는건 아니고, 조금 기다리면 뜬다.

그렇지만 이건 EC2를 마이그레이션 하는 방법이니, 나는 어차피 하는김에 수동으로 해주겠다.

 

 

RDS에 복제본이 없고 클러스터가 아닌 단일이기 때문에 마이그레이션이 간단하다.

심지어 같은 계정 내 vpc라서 더 쉽다.

 

RDS subnet group

 

vpc 세팅을 할 때, vpc의 CIDR는 10.0.0.0/16 으로 잡는걸 추천한다.

그래야 서브넷을 10.0.0.0/24, 10.0.1.0/24 , ... 이런식으로 깔끔하게 할당 가능하다.

 

그리고 private subnet 두개를 만들되, 두개의 AZ에 걸쳐있어야 한다.

(ap-northeast-2a, ap-northeast-2b 이런식으로)

그래야 db subnet group을 만들 수 있다.

 

multi-AZ 하려면 AZ가 세개 이상 걸쳐 있어야 한다는 점을 유의하시기 바란다.

 

그리고 여러분의 db가 위치한 AZ를 포함하고 있어야 한다. (안그러면 물리적인 migration이 필요하므로 설정이 불가능하다)

나는 db가 ap-northeast-2d에 있으므로 2d를 포함시킨 subnet을 만들고, 이에 따른 db subnet group을 만들어 연결시켰다.

 

 

이제 db를 private 환경으로 옮겼으니 dev서버의 ec2에서 api를 쏴본다.

 

당연히 안된다. (피키 귀엽죠?)

ec2 내에 접근하여 docker-compose up을 다시 수행하고 확인해보자.

컨테이너 다시 띄우기

당연히 안된다. (private subnet인데 다른 vpc에서 접속할 수 있을리가..)

그럼 이제 ec2를 db와 같은 vpc내부 public subnet으로 옮기자.

ec2같은 경우엔 로드밸런서까지 vpc만 다른 상태로 카피를 마친 후 route53으로 도메인이 가리키는 방향만 수정해주면 되겠다.

 

2023/11/23 기준 ap-northeast-2b에는 t2.micro가 안된단다.

 

이후 타겟그룹을 만들고 로드밸런서를 만들어준다.

 

EC2 새로 만들었으니 잡다구리를 설치해준다.

swap memory, apt upgrade, docker

 

생각해보니 EC2 애플리케이션에 ElastiCache Redis가 묶여있어서 이것도 subnet group을 다시 설정해줬다.

(사실 잘 모르고 새로 만들었는데 subnet group만 바꾸면 되더라. 프로비저닝 오래걸리니까 나같은 실수 하지 마시길)

 

 

짜잔

 

이제 개발환경의 private subnet은 구현이 완료되었다.

프로덕션 환경도 똑같이 적용하겠다.

이상