[Hongflix] AWS 인프라 구조

* Hongflix의 배포 환경, 인프라에 대한 정리글입니다.

 

24시간 돌릴 서버로 사용할 PM도 없었고, 다양한 AWS 리소스와 연동하고 테스트해보고 싶어서 모든 서버 및 리소스를 AWS EC2로 생성했다.

아키텍처를 아래 사진과 같이 구성한 이유에 대해 하나씩 정리해보고자 한다.

---

- 개발환경

• Java : 11
• SpringBoot : 2.7.XX
• Build : Gradle
• DB : MySQL

---

- 최종 AWS 아키텍처

 

---

- Web Server / WAS

 

VPC를 분리한 이유

• AWS에서 제공하는 고정 IP주소인 탄력적 IP를 프론트, 백엔드 서버에 각각 연결할 계획이었다.
• 하지만 하나의 계정에서 오직 하나의 탄력적 IP만 무료였다. 과금을 방지하기 위해서는 여러 개의 계정에서 리소스를 나눠서 관리하는 방식이 필요하다.
• 추가로 AWS 프리티어에서는 한달에 총 750시간의 인스턴스 가동시간을 제공하는데, 이는 하나의 인스턴스를 24시간 내내 가동했을 때 한달동안 무료로 사용가능한 정도였다.
• 위 상황을 모두 고려했을 때, 하나의 계정에서 AWS 리소스를 모두 관리하는것 보단, 적절하게 리소스를 나눠 여러 계정에서 관리하고 연결하는 방식이 비용적인 측면에서 유리할 것이라고 판단했다.
• 이렇게 계정이 분리되어 VPC또한 분리된 상황에서 통신하는 방법에 대해서 공부할 수 있는 좋은 기회일 것이라 판단했다.

서로 다른 VPC 간 통신 방법

• VPC가 분리된 상황에서 통신하는 방식은 여러가지가 있지만 크게 두 가지 방식에 대해서 고민했다.
  1. VPC 피어링을 통해 VPC간 통신 가능한 채널을 형성
  2. API Gateway를 프록시 서버로 두어 통신
• 통상적으로 VPC 피어링을 통해 서로 다른 VPC 간 통신을 가능하게 할 수 있지만, API Gateway를 프록시 서버로 둠으로써 아래와 같은 이점을 얻을 수 있다고 판단했다. 
  1. HTTPS 통신을 할 수 있다는 점
  2. CORS 설정을 간단하고 확실하게 할 수 있다는 점
  3. 계층을 더욱 독립적으로 구분할 수 있다는 점
• 위와 같은 장점들로 API Gateway를 도입하기로 결정했다.

 

---

- Database

• DB는 아래 세 가지 방식 중 고민했다.
  1. DB 서버 정도는 로컬 환경으로 구동
  2. AWS RDS 사용
  3. AWS EC2에 직접 MySQL 설치해서 사용
• 1번 방식은 제일 편하고 간단하게 연결할 수 있지만, 24시간 전원공급이 필요하고 기술적으로 배울 점이 적다고 판단해 제외했다.
• 2번 방식에서 RDS는 AWS에서 제공하는 관리형 데이터베이스 서비스이다. 필요한 데이터베이스 엔진을 고르고 손쉽게 연결할 수 있다는 장점이 있지만, 편의성에서 오는 비용을 무시할 수 없고 직접 환경설정을 하지 못한다는 단점이 있다.
• 나에게는 직접 데이터베이스를 설치하고, 보안 등에 관련된 환경설정을 직접해보는 경험이 더 좋을 것이라 판단했다.
• 결론은 데이터베이스또한 독립적인 EC2에 설치하고 운영하는 방식을 선택했다.
• DB용 인스턴스에는 퍼블릭 IP를 설정하지 않았다. 오직 같은 VPC 내 백엔드 인스턴스에서만 접근이 가능하도록 보안그룹을 설정했다.

 

---

- API Gateway

 

프록시 역할, API 경로 설정

• 현 프로젝트에서 API Gateway를 사용하는 이유는 HTTPS 연결을 해주는 프록시 서버의 역할 + CORS 설정이 주 목적이다.
• 자세한 설정보단, 단순히 API 요청을 대신 처리해주는 역할이므로 API Gateway를 생성할 때 Restful API 말고 HTTP API로 생성하면 된다.

생성 완료

요청 경로 설정

• 바로 위 사진처럼 클라이언트 측으로 요청받을 URL 엔드포인트를 설정할 수 있다.
• 해당 엔드포인트로 요청이 들어왔을 때 호출할 백엔드 리소스(=통합)를 설정해주면 된다.

호출할 백엔드 리소스 설정

 

CORS 설정

CORS 설정

• 사이드탭에서 CORS 필드로 접근해서 손쉽게 설정 가능하다.
• 추가로 이렇게 요청 경로 및 백엔드 리소스 연결을 마치면, API Gateway에서 JSON 파일로 API 명세서를 만들어주는 기능을 제공한다. 협업 시 매우 편리했다!

 

---

- S3, Lambda, MediaConvert

• 관리자 페이지에서 비디오를 S3 Input 버킷에 업로드하고, Lambda 함수를 통해 MediaConvert에서 적절한 스트리밍 파일과 썸네일 이미지를 생성해 다시 S3 Output 버킷에 저장하는 파이프라인이다.
• 관련된 자세한 내용은 하단의 포스팅 참고

https://dong-woo.tistory.com/119

[Hongflix] 원본 비디오 업로드 --> 스트리밍 파일, 썸네일 생성

 

---

- CloudFront

• 모든 파일이 저장되어있는 오리진 서버(= S3 Output 버킷)에 대한 직접적인 접근을 없애고, 클라이언트 측에서 보다 빠른 속도로 미디어를 받아볼 수 있는 기술에 대해 고민했다.
• 결과적으로 AWS에서 제공하는 CDN 서비스인 CloudFront를 사용하기로 결정했다.
• 관련된 자세한 내용은 하단의 포스팅 참고

https://dong-woo.tistory.com/120

[Hongflix] CDN을 활용한 성능 최적화

 

---

- 배운 점 & 생각해볼 점

• 우선 여러가지 클라우드 리소스들을 서로 유기적으로 연결하는 과정이 가장 오류가 많고 복잡했다.
• 스프링에서 S3 버킷에 업로드하기 위해 적절한 권한을 지닌 IAM 사용자를 생성하고
• S3 버킷에는 Object를 내어줄 수 있는 정책을 설정하고... 등등
• 권한, 정책에 관련된 설정이 굉장히 많았는데, 큰 그림을 미리 그려 유기적인 관계를 파악하고 적절한 권한을 연결해주는 것이 중요하다고 생각했다.
• 또한 '내가 지금 이러한 리소스들을 사용하고 있는 목적이 적절한가?'에 대한 고민을 많이 했다.
• 가령 API Gateway에는 정말 많은 기능이 있는데, 단순히 프록시 서버를 두고 CORS 설정을 위해 API Gateway를 도입하는 것은 적절한 선택일까? 라는 고민을 했었다.
• 단순히 임의의 서비스가 제공해주는 장점만 생각하지 말고, Trade-off되는 점이나 단점들에 대해서도 고려해 서비스의 규모, 목적에 따른 적절한 솔루션을 고민하고 선택하는 시야를 키워가야겠다고 다짐했다.