AWS + 온프레미스로 무비용과 가용성을 달성할 수 있을까?
들어가며
백엔드 서버 구축을 위해 AWS를 한번쯤은 사용해봤을 것이다.
t2.micro는 프리티어에 포함되어 무료로 사용할 수 있지만 처참한(?) 성능에 실서버에서 사용하기는 어렵다.
그렇다고 비싼 돈을 주고 고성능 인스턴스를 사용할 수는 없다.
그래서 홈서버를 구축하여 서버비를 아끼고, AWS의 프리티어 정책을 잘 활용해서 가용성까지 챙긴 무비용 아키텍처를 구성하려 했으나 결과적으로 불가능하다는 것을 깨닫게 되었다.
내가 생각한 아키텍처, 실패 이유 등을 기록한다.
AWS 프리티어
먼저 프리티어 정책을 살펴봐야한다.
나는 프리티어로 사용할 수 있는 서비스들 중 ALB, EC2를 사용하려 했다
두 서비스 모두 1달에 750시간까지 무료로 사용할 수 있는데 24시간 x 30(일) = 720시간이므로 중단 없이 계속해서 사용할 수 있다
여기서 주의할 점이 있는데 1개씩만 사용할 수 있다
즉, EC2 인스턴스를 2개 이상 사용하면 1440시간을 사용하는 것으로 계산되어 비용을 지불해야 한다
물론 EC2도 프리티어인 t2.micro만 사용 가능하다.
Application Load Balancer
먼저 ALB에 대한 기본적인 이해가 필요하다
AWS Elastic Load Balancer의 한 종류로서, 애플리케이션 계층(7계층)의 트래픽을 분산하는 역할을 한다.
ALB를 사용하면 내부적으로 IP는 바뀔 수 있지만 고정된 도메인 이름을 제공하므로 클라이언트가 단일 엔드포인트를 사용할 수 있다.
리스너 및 규칙 설정
리스너는 포트와 프로토콜(HTTP/HTTPS)을 기반으로 트래픽을 수신한다.
규칙을 추가하여 경로 및 호스트 기반 라우팅이 가능하다
1
2
3
예시
example.com/api → 타겟그룹 A
cart.example.com → 타겟그룹 B
Target Group
트래픽을 분산할 대상들을 그룹으로 관리한다
대상은 EC2, Lambda, 컨테이너(ECS), 온프레미스 서버 등이 될 수 있다.
Health Check
대상의 정상 동작 여부를 주기적으로 검사하여 비정상 인스턴스로 가는 트래픽을 자동으로 차단한다.
Auto Scaling Group(ASG)과 연동하여 비정상이 되면 새로운 인스턴스를 생성하고 자동으로 연결시킬 수 있다.
SSL/TLS 지원
SSL/TLS 인증서를 적용할 수 있다
AWS Certificate Manager(무료)와 연동하여 손쉽게 인증서를 관리할 수 있다
내가 생각한 아키텍처
- ALB를 기본적으로는 홈서버와 연결하여 모든 트래픽을 홈서버에서 처리한다.
- 정전 등의 재해로 홈서버가 다운되면, 헬스 체크에 실패하고 ASG에서 감지하여 t2.micro 인스턴스를 시작한다.
- ALB가 새로 시작된 EC2 인스턴스에 트래픽을 보내 처리하는 동안, 홈서버의 문제를 파악하고 오류를 해결한다.
- 클라이언트는 고정된 ALB DNS 엔드포인트만 보기 때문에 내부적으로 어떤 일이 일어나는지 알 필요가 없다.
조건(무비용) 달성 불가
이 아키텍처의 가장 큰 목표는 무비용으로 가용성 있게 설계되어야 한다는점이다.
프리티어 정책을 잘 활용하면 가능할 것이라 생각했지만 역시 AWS는 이를 허용하지 않았다.
비용 문제 외 다른 문제도 있었다.
1. ALB는 온프레미스로 직접 트래픽 전달 불가
기본적으로 ALB는 VPC내에 위치하여 해당 VPC 내의 타겟으로만 트래픽을 전달한다
때문에 VPC 외부에 있는 홈서버로는 직접 트래픽을 전달할 수 없다
2. DB의 고가용성
데이터베이스도 필요했는데 NoSQL 데이터들을 마이그레이션 해야했다.
하지만 NoSQL을 지원하는 AWS의 DocumentDB는 프리티어 정책이 없다.
데이터 구조를 바꿔서 RDS를 쓴다 하더라도 고가용성을 위한 Multi-AZ는 프리티어로는 사용할 수 없다.
그래서 그냥 로컬에 DB를 두고 일정 주기로 스냅샷을 S3에 백업해서 EC2가 실행될 때 스냅샷을 불러오는 방식을 생각했다.
데이터가 많이 저장되지 않기 때문에 프리티어 할당량 안에서 저장이 가능하다.
하지만 시도하기 전에 ALB 연결에 문제가 생겨버렸다
ALB와 VPN 외부 인스턴스 연결하는 방법
물론 외부에 있는 온프레미스에도 연결할 수 있지만 비용이 발생한다.
Site-to-Site VPN
현실적으로 가장 합리적인 해결책이다.
인터넷을 통해 통신하지만, IPSec + VPN 터널링을 통해 암호화된 통신을 제공한다.
비용이 상대적으로 저렴(월 4만원..?)하다.
만약 이 기술을 채택한다면 아키텍처는 아래와 같다.
Direct Connect(DX)
전용 물리 회선을 설치한다.
데이터센터와 AWS 간 대규모 데이터 전송을 위한 기술로 설치에만 약 일주일 소요된다.
비용이 비싸지만 성능이 좋다
EC2 리버스 프록시
EC2 인스턴스 내부에 Nginx, Apache 등의 웹서버를 사용하여 트래픽을 전달한다.
무료로 구현할 수 있지만, 홈서버가 다운될 경우 t2.micro 하나에 웹서버와 애플리케이션 서버와 DB가 돌아가야 된다.
꾸진 t2.micro 스펙으로는 어림도 없다.
가용성 포기
결과적으로 위와 같은 이유들 때문에 가용성은 포기하기로 했다.
비록 무비용과 가용성 두마리 토끼를 잡지는 못했지만, 홈서버 만으로도 해볼 것들이 매우 많고, 고가용성을 위한 아키텍처를 구성해봤다는 점에서 만족한다.
3년 살면서 정전 한번 안났는데..