안녕하세요.
저번 포스팅에 이어 AWS 인프라를 셋팅해 봅니다.
이번에는 AWS 아키텍처를 설계하고 그에 따른 리소스를 생성해 보려고 합니다.
가비아에서 산 도메인을 AWS Route 53 과 연동하는 작업도 같이 하려고 합니다.
1. 요구 사항
아키텍처 요구 사항을 정의해 봅니다.
첫 번째로 과금이 되지 않아야 합니다. 프리 티어로 수용이 가능한 설계를 해야 합니다.
AWS 프리 티어 세부 정보는 아래 사이트에 검색하여 열람할 수 있습니다.
무료 클라우드 컴퓨팅 서비스 - AWS 프리 티어
Q: AWS 프리 티어란 무엇입니까? AWS 프리 티어는 고객에게 서비스별로 지정된 한도 내에서 무료로 AWS 서비스를 살펴보고 사용해 볼 수 있는 기능을 제공합니다. 프리 티어는 12개월 프리 티어, 상
aws.amazon.com
이용해야하는 서비스에서 프리 티어를 사용하려면 그 조건이 어떻게 되는지 확인해야 하고, 초과하지 않도록 조절해야 합니다.
또한, 나중에 프리 티어 기간이 끝나면, 다음 새로운 프리 티어 계정으로 이전할 시 어떻게 해야 하는 지 메뉴얼도 작성할 예정입니다.
두 번째로 스프링 부트 서버를 가동할 리소스가 필요합니다. 필요한 리소스는 모두 AWS 리소스 프리 티어 안에서 사용할 예정입니다.
코드를 실행하는 데 필요한 컴퓨팅 서버 인스턴스와 데이터를 저장할 데이터베이스 인스턴스 필요합니다.
이는 위 사진에서도 볼 수 있듯이 한 달에 750 시간씩 12개월 동안 사용이 가능합니다.
최대 한 달에 31일이므로 24 * 31 = 744 이므로, 한 인스턴스를 운영하고 테스트 용도로 추가로 하나의 인스턴스를 6시간씩 사용해도 될 정도로 충분합니다
파일을 저장할 스토리지도 필요합니다. AWS S3 의 경우 5GB, GET 요청 2만건, PUT 요청 2천건을 지원합니다.
서비스에선 이미지 파일을 주로 저장합니다.
프로필 사진의 경우 노출 크기가 작아 저화질로 변환하여 용량을 절약하는 방법도 있습니다.
노출 크기가 큰 이미지는 용량 제한을 걸어 너무 고화질의 이미지는 업로드하지 못하도록 제한하는 게 좋을 것 같네요.
세 번째로 도메인 관리가 필요합니다. 도메인은 구매처인 가비아에서 관리가 가능합니다. 그러나 인프라 관리를 한 곳에서 하기 위해 AWS Route 53 과 연동할 에정입니다. 하위 호스팅 영역과 AWS 리소스를 쉽게 연결하려는 목적도 있습니다.
2. 아키텍처 설계
아키텍처는 다음과 같습니다.
EC2 인스턴스 한 대로 백엔드 서버를 가동합니다.
RDS 인스턴스 한 대로 데이터베이스를 할당받아 백엔드 서버와 연동합니다.
포스터, 프로필 사진 등의 이미지 파일을 담을 S3 버킷을 하나 생성합니다.
백엔드 서버에서 S3 버킷을 업로드합니다.
CloudFront 서비스로 S3 이미지 파일을 캐싱하여 제공합니다.
Route53 서비스로 도메인을 연동해 CloudFront 배포와 EC2 인스턴스의 서브 도메인 주소를 연결합니다.
AWS 리소스 리전은 서울 (ap-northeast-2) 리전으로 설정했습니다.
글로벌 또는 특정 리전에서만 생성되어야 하는 서비스가 아닌 한, 모두 서울 리전으로 설정했습니다.
아키텍처 아이콘은 아래 사이트에서 다운로드 받았어요!
AWS 아키텍처 아이콘
아키텍처 다이어그램은 설계, 배포, 토폴로지에 관해 커뮤니케이션할 수 있는 유용한 방법입니다. 이 페이지에서 다이어그램을 구축하는 데 도움이 되는 AWS 제품 아이콘, 리소스 및 기타 도구가
aws.amazon.com
정말 자세하게 모든 서비스의 아이콘을 정리해놓았고 화살표 같은 것도 제공해주더라고요..!
다른 분들도 AWS 아키텍처를 설명하는 장표를 만들 때 이용해 보세요!
3. EC2 인스턴스 생성
제일 처음으로 EC2 인스턴스를 생성했습니다.
EC2 인스턴스는 서버 구동을 위해 필수인 리소스입니다.
운영체제는 Ubuntu 을 선택했습니다.
기본 선택지인 Amazon Linux 를 선택하지 않은 이유는, 예상치 못한 이슈가 발생했을 때
경험상 Ubuntu 가 조금 더 범용적인 운영체제라 대응하기가 쉽더라고요.
이슈를 해결할 때 Ubuntu 는 이러한데, Amazon Linux 는 또 다르게 해결해줘야 하는 경우를 경험했었어요.
잔버그에 빠르게 대응하기 위해 Ubuntu 가 더 낫다라는 판단을 했어요.
키페어 PEM 키를 다운로드 받고 노션에 전문으로 아래처럼 공유했습니다.
스토리지는 프리 티어 최대 용량인 30GB 으로 설정합니다.
보안그룹은 인바운드 그룹을 아래처럼 설정했습니다.
SSH 프로토콜은 EC2 인스턴스 접속에 필요한 포트입니다.
자주 접속하는 네트워크 IP를 등록합니다.
노트북으로 작업하는 환경상 자주 네트워크 IP를 추가하고 삭제해야 하는 번거로움이 있을 순 있는데요.
사소한 것에서 보안을 우선시하도록 하는 습관을 가지려고 합니다.
탄력적 IP 를 바로 적용합니다.
탄력적 IP 를 적용하지 않으면, 작업 도중에 IP 주소가 변경되기도 합니다.
EC2 서버에 프리징이 걸려 재시작을 하는 경우, 새로운 가용 서버에서 로딩을 해 퍼블릭 IP 주소가 변경됩니다.
AWS Route 53 도메인 설정으로 퍼블릭 IP 주소만 변경하면 되지만, 번거로움이 여전히 있습니다.
탄력적 IP 주소를 바로 적용해 이런 불편함을 사전에 방지했습니다.
탄력적 IP 적용은 아래와 같습니다.
EC2 탄력적 IP 메뉴에서 새 탄력적 IP 를 생성합니다.
그 후 생성한 탄력적 IP 주소를 선택해, 작업 > 탄력적 IP 주소 연결로 인스턴스에 연결합니다.
참고로, 탄력적 IP 주소를 생성한 후 연결하지 않고 있으면 비용이 과금됩니다.
연결이 정상적으로 되었는지 확인해주세요.
연결하지 않은 탄력적 IP 주소는 즉각 삭제합니다.
4. EC2 필요 패키지 설치
Ubuntu 인스턴스를 만든 후 NginX 패키지를 설치하고 스프링 부트 서버 구동을 위한 패키지를 설치했어요.
현재 패키지 목록을 최신화합니다.
$ sudo apt update
$ sudo apt upgrade
$ sudo apt autoremoveNginX 패키지를 설치합니다.
$ sudo apt install nginx
$ sudo apt remove nginx ( 삭제할 시 )NginX 서버를 구동합니다.
$ sudo service nginx start
$ sudo service nginx stop ( 정지 )
$ sudo service nginx restart ( 재시작 )
$ sudo service nginx status ( 상태 )
$ sudo service nginx reload ( 설정 리로딩 )허슬 프로젝트는 JDK 11 버전을 사용하므로, OpenJDK 11 버전을 설치합니다.
$ sudo apt-get install openjdk-11-jdk
$ java -version
openjdk version "11.0.20" 2023-07-18
OpenJDK Runtime Environment (build 11.0.20+8-post-Ubuntu-1ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.20+8-post-Ubuntu-1ubuntu122.04, mixed mode, sharing)
이후 남은 작업은 Jar 파일을 전달하고 스프링 부트 서버를 구동하는 방법과, NginX HTTPS 설정과 리버스 프록싱 작업만 남았습니다.
5. RDS 인스턴스 생성
RDS 인스턴스로 MySQL 데이터베이스를 할당합니다.
예전에는 db.t2.micro 로 프리 티어로 생성했지만, 22년 3월 이후로 db.t3.micro 으로도 프리 티어로 생성할 수 있다네요.
Amazon RDS 프리 티어, 이제 모든 상용 리전에서 db.t3.micro, AWS Graviton2 기반 db.t4g.micro 인스턴스 포함
오늘부터 Amazon Relational Database Service(Amazon RDS) 프리 티어에는 모든 상용 리전에서 db.t3.micro, AWS Graviton2 기반 db.t4g.micro 인스턴스가 포함됩니다. 이를 통해 현재 AWS 프리 티어에서 신규 AWS 고객을 위
aws.amazon.com
보안 그룹으로 인바운드 규칙에 EC2 인스턴스와 개발자가 접속할 수 있도록 설정합니다.
EC2 인스턴스가 가진 탄력적 IP 를 입력했습니다.
그리고 각 개발자의 네트워크를 등록했습니다.
데이터베이스 클라이언트에서 연결이 성공하는지 확인합니다.
만약 인바운드 규칙에 없는 IP 가 접속한다면, 아래와 같이 Connection timed out 오류가 발생합니다.
다음으로 파라미터 그룹을 변경합니다.
데이터베이스의 내부 설정을 AWS RDS 에선 파라미터 그룹으로 관리합니다.
우선, 개발하기 편하도록 타임존 설정을 변경했습니다.
한국 중심의 서비스이므로 time_zone 파라미터를 Asia/Seoul 로 변경했습니다.
문자열 인코딩은 모두 utf8mb4 으로 변경했습니다.
utf8 인코딩과의 차이점은 이모지 지원 여부입니다.
utf8mb4 인코딩으로 생성된 테이블은 이모지도 이상 없이 처리됩니다.
파라미터 그룹 변경사항을 저장합니다.
다시 RDS 인스턴스를 수정합니다.
추가 구성의 데이터베이스 옵션에서 DB 파라미터 그룹을 수정할 수 있습니다.
즉시 적용으로 변경합니다.
RDS 인스턴스를 생성하고 내부 데이터베이스 설정까지 마무리헀습니다.
6. S3 버킷 생성
S3 버킷은 파일을 업로드하고 다운로드받는 스토리지 공간입니다.
허슬 프로젝트는 주로 이미지 파일을 저장소에 저장합니다.
포스터 이미지 파일, 동아리 사진 등의 이미지 파일을 취급합니다.
AWS S3 서비스로 이미지 파일을 저장하는 버킷에 저장하려고 합니다.
S3 버킷은 추후 CloudFront 서비스와 연동될 예정입니다.
S3 버킷에 저장된 파일을 다운로드 받거나 업로드할 때의 횟수 제한이 있습니다.
한 번 요청할 때 마다 횟수 카운팅이 올라갑니다.
만약 자주 요청되는 파일이 있다면, 빠르게 횟수가 올라가 프리 티어의 제한을 넘어서 과금될 겁니다.
이를 방지하기 위해 캐싱을 해주는 CloudFront 서비스를 이용합니다.
CloudFront 에 요청하면, S3 에서 파일을 가져오기 전에 캐싱이 되었는지 확인합니다.
캐싱이 되었다면, 캐싱이 된 파일을 대신 반환해줍니다.
따라서 CloudFront 를 사용하면 S3 의 Get 요청 수를 줄일 수 있습니다.
CloudFront 서비스는 인증서가 있어야 하므로, 다음 시간에 도메인 설정과 Https 인증서 설정할 때 같이 하도록 하겠습니다.
7. Route53 호스팅 영역 생성
AWS Route53 서비스로 도메인 내의 호스팅을 지정할 수 있습니다.
서브 도메인을 추가할 수 있고, 이를 AWS 내의 서비스와 연동이 가능하며 다른 도메인으로 연결해줄 수도 있습니다.
호스팅 영역에서 생성한 도메인의 네임서버를, 구입한 도메인 서비스에 등록을 해야 하는데요.
이 과정은 가비아에서 구입한 팀원에게 네임서버를 등록해달라고 요청을 드렸어요.
아래처럼 api 서브 도메인을 만들었습니다.
A 타입으로 EC2 인스턴스의 탄력적 IP 으로 이동하도록 설정했습니다.
남은 작업은 Https 인증서 발급하여 NginX를 설정하고, ACM 에서 인증서도 발급한 다음, CloudFront 를 배포할 예정입니다.
CloudFront 배포도 Route53 도메인으로 추가하기만 하면 됩니다.
마무리
이번 포스팅에선 AWS 아키텍처를 짜고 리소스를 직접 생성해보았습니다.
아직 인프라 설정을 다 하기 까지 많이 남은 것 같네요!
늘 새로운 프로젝트를 시작하고 인프라 설정할 때 마다 새로운 것 같아요.
능숙해지는 것 같으면서도 다시 처음으로 돌아간 듯한 이상한 느낌이네요. ☺️
다음 포스팅에서 뵙겠습니다!
'프로젝트 > 장기 프로젝트' 카테고리의 다른 글
| Hustle #8. Jasypt 암호화 라이브러리 적용 (2) | 2023.09.03 |
|---|---|
| Hustle #7. (3부) AWS 인프라 초기 셋팅 - HTTPS 적용, 리버스 프록싱 설정, CloudFront 배포 (0) | 2023.09.01 |
| Hustle #5. (1부) AWS 인프라 초기 셋팅 - AWS 계정, IAM 계정, 예상 결제 요금 알림 (0) | 2023.07.10 |
| Hustle #4. 이슈 템플릿, 브랜치 규칙 설정, 프로젝트 보드 만들기 (0) | 2023.07.06 |
| Hustle #3. 스프링 부트 프로젝트 생성하기 (0) | 2023.07.06 |
댓글