[Mybrary] ECS/ECR/EC2/VPC/RDS/Route53/ALB: AWS에서 MSA 배포 환경 구성하기

들어가면서

23년 8월 말 경, 드디어 마이브러리가 플레이스토어에 출시되었다.

(공개 테스트 버전이지만 ^^..)

https://play.google.com/store/apps/details?id=kr.mybrary.mybrary&hl=ko-KR 

마이브러리 - Google Play 앱

 

현재까지 EC2 인스턴스로 임시 서버를 띄웠지만

이제 정말로 프로덕션 환경에 맞게 배포를 해야 겠다는 생각이 들었다.

 

3일 정도 바우 팀장님과 머리를 맞대고 배포 환경 구성을 무사히 끝마칠 수 있었다.

어떤 작업들을 하였는지 간략히 포스팅해보고자 한다.

 

왜 ECS를 사용하였는가

MSA 기반이기 때문에 API Gateway, Config, Eureka, Book-Service, User-Service 등 많은 서버가 필요했고,

DB와 캐시도 서비스별로 따로 관리해주어야 했다.

 

따라서 컨테이너 오케스트레이션이 필요할 것으로 예상되었지만,

쿠버네티스를 적용하기에는 러닝 커브가 상당할 것 같아서

AWS에서 제공하는 ECS(Elastic Container Service)를 사용해 컨테이너를 관리하기로 했다.

 

 

ECS Fargate는 EC2 인스턴스의 서버나 클러스터를 관리할 필요 없이 컨테이너를 실행하기 위해 ECS에 사용할 수 있는 기술이다.

직접 EC2의 서버 유형, 용량 등을 프로비저닝하고 최적화할 필요 없이 AWS가 어디선가 원하는 스펙의 컨테이너를 띄워준다.

Fargate를 사용하면 EC2 인스턴스 관리 부담이 줄어들 수 있으리라 생각했다.

 

컨테이너 이미지는 프라이빗하게 저장하기 위해 ECS(Elastic Container Registry)를 사용했다.

(도커는 프라이빗 레포가 유료였던 것 같다.)

 

 

그렇다면 EC2는 어디에 사용되는가

Book-Service와 User-Service는 유연하게 오토스케일링을 해주고자 ECS로 테스크 정의를 하였지만

API Gateway, Eureka, Config 서버는 단일 컨테이너로 충분히 커버할 수 있으리라 생각해

EC2 인스턴스에 띄우고 컨테이너를 직접 관리하기로 했다.

 

Redis도 원래 ElastiCache를 사용하려 했으나,

굉장히 비싼 요금때문에 EC2에서 직접 클러스터를 구성해 사용 중이다.

 

추가로 프라이빗 인스턴스에 접근하기 위한 Bastion 서버도 사용 중이다.

 

 

네트워크 구성

VPC를 서울 리전의 가용영역 a, b에 나누어 구성했다.

퍼블릭 서브넷은 인터넷 게이트웨이와 연결해주었고

일부 프라이빗 서브넷은 NAT 게이트웨이와 연결해주었다

(NAT 게이트웨이가 이렇게 비쌀줄은 꿈에도 몰랐다 🙃 조만간 비용 절감을 위해 EC2로 전환해야지 싶다)

각 프라이빗 서브넷은 Book-Service, User-Service의 Fargate, RDS, EC2(Redis 컨테이너 호스팅) 및 Config 서버, Eureka 서버에 할당되었다.

 

데이터베이스

RDS에서 MySQL 데이터베이스를 사용 중이다.

프라이빗 서브넷을 할당하였기 때문에 내부에서만 접근 가능하다.

 

음? 보통 운영 환경에서는 Hibernate DDL auto가 None 또는 Validate로 설정된다.

따라서 서버가 시작될 때 테이블을 자동으로 생성해주지 않는다.

그럼 DB에 직접 접근해서 DDL문으로 테이블을 만들어주어야 하는데,

프라이빗 RDS에 어떻게 접근해서 어떻게 테이블을 만들어주어야 하지???

 

RDS DB 접근 문제

친절한 AWS는 이러한 상황에 쏙 맞는 해결 방법을 제시해준다.

 

https://repost.aws/ko/knowledge-center/rds-connect-ec2-bastion-host

Amazon EC2를 사용하여 프라이빗 RDS DB 인스턴스에 로컬로 연결

 

Bastion 서버로 접속함과 동시에 로컬 포트를 RDS 인스턴스로 연결한다.

 

 

Book-Service DB와 User-Service DB 모두 위와 같이 RDS에 접근해 테이블을 생성해주었다.

(인텔리제이에서 DDL을 뽑아왔는데, 나중에 보니까 일부 칼럼이 누락되었다. 🙁 다음에는 한 번 검토해보고 써야겠다.)

 

로드 밸런서 적용

 

가용영역 a, b에 독립적으로 구동중인 API Gateway 서버에 요청을 로드밸런싱 하고자

어플리케이션 로드 밸런서(Application Load Balancer;ALB)를 생성하고 API Gateway 타겟 그룹에 전달되도록 설정했다.

 

Certificate Manager에서 발급 받은 SSL 인증서를 적용해주었고,

따라서 HTTPS:443 요청만 수신하도록 리스너를 설정했다.

 

도메인 적용

 

로드밸런서의 DNS를 mybrary.kr 도메인으로 등록해주었다.

 

이제 https://mybrary.kr 로 API Gateway에 요청을 보낼 수 있다.

기존: http://mybrary.kr:8000/user-service/api/v1/.. 

변경: https://mybrary.kr/user-service/api/v1/.. 

 

마치면서

위의 인프라 작업 사항들은 아래의 아키텍처를 따른다.

 

구체적으로 ECS 테스크 정의를 어떻게 하였는지, 서비스를 어떻게 생성하였는지

API Gateway가 어떻게 각 요청을 서비스로 전달하는지,

Config 서버가 어떻게 설정 파일을 읽어와 각 서비스에 업데이트 시켜주는지,

ECS Fargate에서 호스팅되는 서비스 컨테이너가 어떻게 Eureka 서버에 등록되는지 등

여전히 포스팅 할 것들이 많다. 😂

 

그리고 블루/그린 무중단 배포, 모니터링, 성능 테스트 등 업그레이드 시켜야 할 부분도 많다.

 

프로젝트 수행 기간 동안 부지런히 일해야겠다는 생각이다. 🔥