[Mybrary] AWS 계정 이전 일기: 서버비가 끊겨서 새로운 계정으로 인프라마이그레이션하기🥲 - #0. VPC 구축

너무 늦게 정리하는 느낌이지만,,

그래도 마이브러리 AWS 계정 이전했던 경험들을 기록해두고자

인프라 마이그레이션을 했던 과정을 남겨보기로 했다. 🙂

한 계정에서 다른 계정으로 서비스를 옮기고 싶은 사람들에게 도움이 됐으면 하는 바람이다.

 

Background

SW마에스트로 최종 발표 직후 곧바로 AWS 계정을 정리해야된다는 공지가 올라왔다.

그 전까지 리소스를 지우지 않으면 개인 계좌에서 서버 비용이 부담된다고 했다.

AWS 관리형 서비스를 이것저것 사용했던 지라 비용이 월에 50만원 이상은 청구될 것이기에

리소스를 줄이고 줄여 팀쟝님 개인 계정으로 서버를 이사가기로 했다 ㅠㅠ,,

(근데 연말에 바빠서 바로 서버 이전을 하지 못하고,

소마 계정에서 잠시 서비스 중단 했다가 개인 계정에서 뚝딱뚝딱 복구했다😅)

 

그동안 서버 비용 지원해주셔서 너무 감사했습니다 소마

 

계정 간에 옮겨야 할 것들

최종 발표 즈음의 마이브러리 인프라 아키텍처

 

음,, 옮겨야 할 것들이 상당히 많았다.

모든 리소스를 개인 계정에서 새로 만들고,

이미지, 스냅샷, 데이터, 설정 파일 등을 옮기는 과정으로 진행했다.

 

왼쪽 노트는 대강 어떻게 마이그레이션할 지 계획을 세워본 내역이다.

근데 실상은 다음과 같은 순서대로 구축했다.

 

1. VPC 구축

2. RDS 스냅샷 복구

3. S3 마이그레이션

4. API Docs 서버 복구

5. Lambda 함수 복구

6. Redis Cluster 복구

7. Config 서버 복구

8. Config 레포지토리 설정 파일 수정

9. SNS/SQS 복구

10. NAT Instance 복구

11. ECR/ECS 복구

12. API Gateway 서버 복구

13. 로드밸런서 생성 및 도메인 등록

14. CI/CD 워크플로우 수정

15. 무중단 배포 설정

 

 

물론 계획대로 되진 않았다 크고 작은 이슈가 대여섯개 정도 있었다.

 

벌써 서버 이전 작업을 한지 3달이 넘어서,,

그 당시에 기록한 내용들과 나의 작고 소중한 기억들을 모아서 그 과정을 정리해보겠다.

 

#0. VPC 구축

왼쪽이 기존 구성, 오른쪽이 새로운 구성

 

처음 VPC를 구축했을 때는 서브넷을 촘촘히 나누는게 멋있어 보였다.

마이크로서비스/DB/캐시레이어 등 모두 다 다른 서브넷으로 구성했다.

그렇게 서브넷을 16개를 만들었는데, 딱히 효율적인 느낌도 없었고 오히려 구분이 어렵기만 했다.

 

🤷‍♂️ book service redis 그거 서브넷 몇 번이었더라?? 14번인가 15번인가

🤷‍♀️ 흠,, 머였더라?_? 컨플루언스에 있으니까 찾아보고 쓰셔유~~

 

이런 상황이 종종 연출됐다 (아이 부끄러)

 

그래서 이번에 옮기면서 정리해버렸다.

같은 도메인으로 묶이는 영역은 한 개의 서브넷만 쓰기로! (user service/cache/redis는 한곳에 두자구~)

 

가용영역도 1개만 쓰려고 했는데,

1. RDS에서 서브넷을 지정하려면 서브넷 그룹을 만들어야 하는데, 이 서브넷 그룹이 2개 이상의 AZ를 커버해야 한다.

    -> AZ 2b에 private 서브넷 2개 추가(user, book)

2. LB에서 가용영역을 2개 이상 달아줘야 한다.

    -> AZ 2b에 public 서브넷 1개 추가

 

고가용성에 목숨건 AWS 1

고가용성에 목숨건 AWS 2

 

마지막으로 VPC가 무엇인지 간략하게 정리하고,

다음 글에 이어서 RDS 스냅샷 복구에 대해 작성해보겠다.

 

VPC(Virtual Private Cloud)에 대한 이해

참고) Amazon 공식 문서

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html

Amazon VPC란 무엇인가? - Amazon Virtual Private Cloud

Amazon VPC를 사용하면 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 시작할 수 있다.

이 가상 네트워크는 고객 자체 데이터센터에서 운영하는 기존 네트워크와 매우 유사하다.

VPC 구성 다이어그램 예시

위의 예시에서는 Region의 각 Availability Zone에 하나의 서브넷이 있고, 각 서브넷에 EC2 인스턴스가 위치한다.

또한 VPC의 리소스와 인터넷 간의 통신을 허용하는 인터넷 게이트웨이를 포함한다.

 

VPC 사용을 위해 다음과 같은 개념과 기능들에 대해 알아두면 좋다.

 

서브넷

VPC의 IP 주소 범위이다. 더 많은 네트워크 망을 만들기 위해 사용한다. 단일 가용 영역에만 구성할 수 있으며, 서브넷을 추가한 뒤에 VPC에 AWS 리소스를 배포할 수 있다.

 

라우팅

라우팅 테이블을 사용하여 서브넷 또는 게이트웨이의 네트워크 트래픽이 전달되는 위치를 결정한다.

 

게이트웨이 및 엔드포인트

게이트웨이는 VPC를 다른 네트워크에 연결한다. (인터넷 게이트웨이는 VPC를 인터넷에 연결한다) VPC 엔트포인트를 사용하여 인터넷 게이트웨이 또는 NAT 장치를 사용하지 않고, 고객이 구성한 VPC와 AWS 서비스를 연결할 수도 있다. 이를 통해 AWS 서비스를 프라이빗하게 접근할 수 있다.

public service endpoint를 통한 접근

VPC endpoint를 통한 접근

[참고] S3, CloudWatch 등의 서비스는 VPC 내부에 위치하는 서비스가 아니라서 따로 공인 IP를 가지고 외부에서 접근한다. VPC 밖에서 들어오는 트래픽은 과금이 되기 때문에, AWS 네트워크 안에서만 통신이 될 수 있도록 동일 리전 내에서는 VPC 엔드포인트를 통해 접근하도록 개선하여 비용을 절감할 수 있다.

 

피어링 연결

VPC 피어링 연결을 사용하여 두 VPC의 리소스 간 트래픽을 라우팅할 수 있다.

VPC 피어링을 통한 연결

 

트래픽 미러링

네트워크 인터페이스에서 네트워크 트래픽을 복사하고 심층 패킷 검사를 위해 보안 및 모니터링 어플라이언스로 전송할 수 있다.

 

Transit Gateway

중앙 허브 역할을 하는 전송 게이트웨이를 사용하여 VPC, VPN 연결 및 AWS Direct Connect 연결 간에 트래픽을 라우팅할 수 있다.

 

VPC 흐름 로그

VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡처할 수 있다. CloudWatch Logs, S3, DataFirehose 등에 흐름 로그 데이터를 게시할 수 있다.

프라이빗 서브넷에 위치한 EC2 인스턴스의 네트워크 인터페이스에 대한 흐름 로그 레코드를 S3 버킷에 게시

 

VPN 연결

AWS VPN 서비스를 사용하여 온프레미스 네트워크에 VPC를 연결할 수 있다.

 

VPC 사용에 따르는 추가 요금은 없다.

다만 NAT 게이트웨이, IP 주소 관리자, 트래픽 미러링, Network Access Analyzer와 같은 일부 VPC 구성 요소에 대한 과금이 있을 수 있다.