AWS

들어가기 앞서

AWS란 어느정도 개발을 해보신분이라면 한번쯤은 들어보셨을겁니다. 웹 클라우드 컴퓨팅 서비스를 제공하는 사이트죠. 하지만 이글은 이런 기본적인것에 대해서 다루진 않을겁니다.

그런 기본적인 개념을 다루기에는 이미 우리는 많은것들을 이해하고 있고, 똑같은 지식들을 말해봐야 지루할테니까요.

그리고 대부분의 컴퓨터 개발 개념들은 기초 지식들이 있으면 대부분은 어느정도 사용이 가능하고 추론이 가능합니다.

그렇기 때문에 어느정도 기초 지식이 있는 사람을 대상으로 해당글을 작성하고자 합니다.

SAW의 전체적 흐름

저희 SAW 전체 프로젝트에서 흐름은 크게 프론트, 백엔드, DB, Minio로 분산처리가 되어있습니다.

그림으로 보자면 해당 흐름으로 되어있죠.

프론트에서 백엔드 API를 요청하면 백엔드에서는 DB와 Minio를 조회하여 데이터를 가공후에 프론트에게 전송을하고, 프론트는 가공된 데이터를 기반으로 랜더링을하죠.

그렇기에 큰틀로 보자면 4개의 분산처리가 진행되고 있습니다.

하지만 해당 글에서는 Minio는 제외하기로 했습니다. 여러 정책 문제 때문에 통합하기가 어렵거든요.

사용하는 인스턴스

자 이제 해당 글에서 다루고자 하는것이 3개의 분산처리라는것을 알았으니 각각 분산되는 컴퓨팅 서비스에 어떤 인스턴스가 필요한지 알아야겠죠.

해당 글에서는 다음과 같은 인스턴스들을 사용하며, 간단하게 해당 인스턴스가 무엇인지 짚고 넘어갈것입니다.

그정도만 아셔도 다들 추론은 가능하실테니까요.

필수 사항

EC2 * 2

사이징 커스텀 컴퓨팅 서비스

자원 조절 가능한 컴퓨팅 서비스

Elastic IP

IP 주소 고정 서비스

도메인 고정 서비스

RDS

관계형 데이터베이스 서비스

Mysql, PostgreSQL, MariaDB, Oracle, Etc...

선택 사항

SNS

알림용

Event Bridge

AWS 이벤트 관리

한도량 제한걸기

한도량에 제한을거는것 그것은 상당히 중요하죠.

무료범위에서만 사용하기 위해서만이 아니라 어떤 상황이 되었던 한도량에 제한을거는것은 중요합니다.

기존에 걸어두었던 한도량을 초과한다는것은 여러가지로 생각할 수 있으니까요.

내 서비스가 목표치보다 더 많은 사람들이 사용하고 있다는 척도가 될 수 도 있고,

내 서비스의 로직에 최적화가 필요하다는것을 눈치챌수도 있으며,

내 서비스가 누군가에게 공격 받고 있다는것을 눈치챌수도 있죠.

기본 설정

이동해봅시다. 귀찮은 사람을 위한 링크

계정 설정 -> 결제 및 비용 관리 -> 기본 설정 및 설정 -> 빌링 기본 설정

(기존에는 결제 기본 설정이였습니다만 2023년 기준으로 바뀌었습니다.)

둘다 활성화 해줍시다. 귀찮으면 CloudWatch 부분은 안하셔도 됩니다.

설정을 안해도 상관은 없습니다만...

AWS에서 가장 큰 문제점은 특정 비용이 초과되어도 인스턴스를 멈춰주는 기능이 없다는것입니다. 그렇기 때문에 저는 해당 설정을 굉장히 중요하게 여깁니다.

또 이동을 해줍시다. 귀찮은 사람을 위한 링크

서비스 검색 -> CloudWatch

(마찬가지로 23년 기준으로 IAM에서 설정하던 부분이 새로운 서비스로 빠졌습니다. 기존에는 버지니아 북부 인스턴스로 고정해야지만 설정 부분이 나타나서 사용가능했던 문제점은 고쳐졌습니다.)

경보 생성 -> 지표 선택

지표를 선택하는 화면이 나올겁니다.

하지만 일부 분들은 지표를 선택하는곳에서 다음과 같은 화면이 없고 일부분 로그, 사용량만 나올것입니다.

결제에 대한 지표를 설정하는 부분이 없다면 지표의 기준점을 버지니아로 잡지 않아서 그렇습니다.

CloudWatch 서비스가 23년을 기준으로 서비스가 따로 빠져서 어느정도 개편이 되었다고 하더라도 여전히 결제에 대한 부분, 금액에 대한 그래프들은 여전히 로컬라이징이 되어있지 않기 때문에 버지니아만 사용이 가능합니다.

(그럴거면 왜 '개편' 이라고 하고 따로 서비스를 빼버렸는지 모르겠습니다. 지표랍시고 여러가지를 나열해뒀으면서 정작 제대로 기능하는 지표는 몇개 없습니다. 대표적인 옆그레이드의 예시라고 볼 수 있죠.)

그렇기 때문에 일단 무엇있는지 보기위해서 지표 설정을 버지니아 기준으로 해줍시다.

결제 -> 예상 요금 합계 -> 통화 USD 체크

하지만 서버 사용을 버지니아가 아닌 다른 서버로 사용하고 있다면 (서울) 아래 이미지와 같이 더 이상 설정이 불가능하고 진행이 불가능할것입니다.

왜 진행이 불가능할까?

그건 바로 AWS의 비용 정책과 연관이 있습니다.

AWS의 비용 정책은 각 리전 위치에 따라서 비용이 산정됩니다.

버지니아와 서울 서버를 비교해봅시다.

간단하게 보면은 월당 비용이 다릅니다. 각 리전 위치 사정에 따라서 비용이 달라지게 됩니다.

그렇기 때문에 모든 리전에서 동일한 지표를 제공할 수 없기 때문에 해당 상황을 고려해서 서비스를 제공해줘야하죠.

그렇기 때문에 리전이 다르면은 더 이상 진행이 불가능하게 됩니다.

그렇다면 의문이 드실겁니다. 버지니아 서버가 더 싸다면은 굳이 한국 서버에서 사용할 필요가 있나요?

예상 비용은 트래픽을 계산하지 않는다.

가장 큰 문제점이라고 할 수 있죠. 예상 비용은 트래픽을 계산하지 않습니다.

기본적인 트래픽에 대한 설명은 건너뛰도록 하겠습니다. 기초 지식은 있을것을 상정하고 이야기를 진행하고 있으니까요.

트래픽은 기본적으로 물리적 거리량, 데이터 크기, 전송속도에 따라서 달라집니다.

하지만 지금은 단순히 물리적 거리량으로만 봅시다.

물리적 거리량만 하더라도 상당히 많은 차이가 발생합니다.

이 물리적 거리 때문에 반응속도는 물론, 거쳐야하는 지점들이 자연스럽게 많아질수밖에 없죠.

AWS의 트래픽 비용 계산

그렇다면 AWS는 트래픽에 대한 비용을 어떻게 계산할까요?

자세한 사항은 여기

AWS는 아웃바운드에 대해서만 요금을 부여합니다.

즉 들어오는 데이터에 대해서는 요금을 부여하지 않습니다만 인스턴스가 데이터를 보내는데는 요금을 부여하는 방식인거죠.

그리고 거리에 따라서 최적화를 위해서 각 데이터 센터를 거쳐 지나가게 됩니다. 여기서 추가 비용이 발생하죠.

물론 AWS 리전끼리 통신을 진행하면 비용이 더 적기 때문에 서로 연결되어있는 상황에서는 크게 고려하지 않아도 되는 문제입니다.

하지만 일반적인 상황에서 클라이언트는 일반 회선을 사용하고 있을 가능성이 높습니다.

(애초에 한국은 3통신사 밖에 사용이 불가능하잖아요? 그밖에도 있지만 규제 때문에 끔찍하게 느리죠.)

그렇기 때문에 특수한 상황이 아닌 경우에는 한국서버를 사용하는게 좋습니다.

그래도 버지니아 서버를 사용할래요.

...물론 상단에 있는 UI에서 서버를 버지니아로 설정하면 모든것이 정상적으로 진행이 될겁니다.

하지만... 내 서비스가 성공할지도 모르잖아요? 최대한 비용을 아끼고 싶잖아요? 그리고 반응속도를 챙기고 싶잖아요? 내 서비스가 글로벌하게 타겟팅을 잡으면 몰라도 일단은 한국인들을 대상으로 서비스를 진행하고 싶잖아요? 우리는 바로 글로벌 하게 서비스를 하기 위해서는 준비가 되어있지 않아요.

그래도 상관 없다구요...? 네... 그렇다면 서버를 버지니아로 바꿔서 설정해봅시다.

그렇다면 매끄럽게 지표 및 조건 지정 페이지로 넘어갈것입니다.

그 다음부터는 이미지를 그대로 따라하시면 됩니다.

동일한 페이지인데 이미지에서 설정하는 부분이 없으면 넘어가세요.

그리고 이 설정들은 어디서나 찾아볼 수 있으니 해당 내용을 더 자세히 알고 싶은분이라면은 다른 블로그를 참조해보시는것도 좋습니다!

모든 절차들을 잘 따라오셨다면 다음과 같은 이메일이 올것입니다.

불합리하네?

실제로 제가 이 글을 쓰기 시작한 이유입니다.

아무리 생각해도 버지니아 기준으로만 잡았을때 비용에 대한 그래프를 제공하고, 특정 임계값에 대한 커스텀 알람을 제공한다는것이 마음에 들지 않았습니다.

물론 지금은 내가 비용을 지불하지 않고 무료로 사용하고 있지만 내가 비용을 내고 서비스를 운영 할 수 있는 가능성도 있는거 아닌가요?

그러기 위해서 1년간 프리티어를 제공해주는거 아닌가요?

그래서 제가 직접 커스터마이징해봤습니다. 이미 CloudWatch에서 재료들은 다 주어져있었으니까요.

개발자란 프로그래밍 언어를 가지고 무언가를 만드는 사람들이잖아요.

하지만 저는 패배했습니다.

우선은 CloudWatch(CW) 에서 EC2를 대상으로 잡았을때 CPUUtilization이 있었습니다.

CPUUtilization에 대해서 더 자세히 알고 싶으신분들은 아래 링크를 참조하세요

CPUUtilization이란?

저는 해당 데이터를 찾아냈을때 이런 생각을 했습니다.

CPU가 시작된 시점의 데이터가 존재한다면 해당 인스턴스가 시작된 시점으로 봐도 무방하며, 오차가 있다 할지라도 1분 내외로 잡힐거라고 생각되었죠.

그렇기 때문에 CW에서 쿼리를 잘 다루면은 해당 데이터에서 시작 시점과 종료시점을 추려내어 총 가동 시간과, 비용을 산정할 수 있겠다라고 생각을 했습니다.

하지만 CW의 쿼리는 일반적으로 생각하는 쿼리와 달랐습니다.

쿼리를 제공한다기 보다는 Function을 제공하는것과 동일했죠.

그리고 직접 쿼리를 편집도 가능했습니다만 이것도 어디까지나 Function의 영역내에서만 가능했습니다....

결국엔 인터페이스 형태로 제공하는 쿼리 작성기에서는 벗어나지 못했던거죠.

그렇기 때문에 SW는 제가 원하는 방식의 데이터를 얻지 못한다는것을 알고 저는 포기했습니다.

물론.... 가능은합니다. CPUUtilization을 대시보드에서 추가하고 이를 크롤링을 진행해서 데이터를 얻어내면 됐거든요.

하지만 이는 배꼽이 배보다컸습니다. 그리고 크롤링을 진행하다보면은 AWS에서 저의 계정을 차단할것이라는것을 알았습니다.

물론... 익명성으로 바꿔서 저를 숨긴다음 이것저것 하면됐습니다만...

그건 해킹의 영역이였습니다. 저 자신을 해킹하는것과 마찬가지였죠. 재밌겠지만 저는 시간이 없었습니다.

그렇기에 저는 다른 방법을 찾아야만 했습니다. 배보다 배꼽이 큰 상황이였으니까요.

그리고 저는 단초를 찾았습니다!!

Amazon Event Bridge(AEB)는 AWS내에 서비스는 물론 외부 앱, Saas 앱에 대한 이벤트들을 수집하고, 제어가 가능한 서비스입니다!

그리고 프리티어 내에서는 AWS의 서비스까지라면 무료로 사용이 가능했죠.

해당 서비스를 사용하면은 프리티어 요금을 초과하려고 했을때 인스턴스를 중지시키는것은 물론 다양한 이벤트들을 제어가 가능해지니 가능성은 무궁무진해지죠! 딱 제가 원하는 제어 방식이였어요!

하지만 해당 서비스를 다루는것은 이 글의 마지막쯤이 될것입니다.

우선은 SAW 프로젝트를 AWS의 인스턴스에서 어떻게 배포할것인가에 대해서 먼저 다뤄야 하니까요.

이만 글을 끝내겠습니다.