Azure에서 AWS Lightsail로 옮긴 기록

코코블루·2022년 1월 20일
0

Server

목록 보기
2/14
post-thumbnail

이 글은 Azure에서 AWS Lightsail(이하, Lightsail)로 이전하면서 생긴 일에 관하여 간단하게 적어보고자 합니다.

시작하며


이전까지 토이 프로젝트와 DB 등을 Azure 학생 무료 프로모션을 이용하여, Web App, VM, MySQL DB 등으로 분리하여 사용했었습니다. 이제 프로모션이 끝나 과금될 위기였습니다. 계산을 해보니 Web App은 F1으로 각 지역마다 하나를 무료로 사용할 수 있지만, VM과 DB는 별도 과금이 되는 구조입니다. 요금을 계산해보니 토이 프로젝트 치고는 많이 비싼 느낌이라서 다른 클라우드도 사용할 겸하여 이전을 결심하게 됩니다.


후보는 GCP, AWS, Vultr 이렇게 3가지였는데, GCP는 이전에 사용한적이 있었기 때문에 패스. Vultr는 서울 리전이 있지만, 결제가 외화로 된다고 들었습니다. 그래서 AWS로 결정을 했는데, AWS 이거... 만만치 않습니다. 정확히 과금 체계를 알지 않으면 요금 폭탄을 맞기 십상일 것 같았습니다. 그래서, 일부 종량제인 Lightsail로 시작해보기로 결정했습니다.

요금에 따른 리소스 배분

이전을 진행하면서, 리소스를 배분하는 방법도 좀 다르게 하고자 했습니다. Azure는 무료여서 Web App, VM, DB 등 용도 별로 각각 다른 리소스를 사용하였습니다. 무료 프로모션을 최대한 활용했습니다. 하지만, 이제는 돈을 내야하는 입장이니 어떻게 하는 것이 싼지 비교가 필요했습니다. 지피지기면 백전백승이라 하였으니 현재의 구조를 그려보고, Lightsail로 이전하면 어떻게 되는지도 그려보았습니다.7

그림으로 그리면 이런 느낌?

위 구조를 그대로 Lightsail로 각각의 리소스를 따로 생성하면 아래와 같은 구조가 만들어지고, 종량제를 초과하지 않는다는 상정하에 산출된 요금은 아래와 같습니다.

각각을 VM으로 생성할 경우, 월 28.5 달러라는 요금이 발생합니다. 그래서 이걸 Dockerize 하여, 컨테이너로 구성하면 더 싸질까 싶어 좀 더 살펴봤습니다.

Discord Bot을 구성하는 컨테이너를 노드 하나로 합쳐도 어쨌든 RDBMS를 별도로 구성하는 그 자체가 비용을 많이 잡아먹는 구성이었습니다. 그리고 개인적으로 잘 사용하던 phpmyadmin도 별도로 띄울려면 요금이 들어가기 때문에 좀 더 고민해보기로 합니다.

위와 같은 요금 때문에 사실 Azure를 그대로 유지할까도 싶었습니다. (Web App은 F1이 무료니깐.) 하지만, 칼을 뽑으면 무라도 베라고 했나요. 한 번 결심한 것이니 좀 더 요금을 줄일 방법을 찾아봤습니다.

제가 찾은 최적의 결과는 하나의 VM에 올리는 것입니다.

문제가 있어요!

그렇게 되면 생각해볼 문제는 아래와 같습니다.

VM 단독 운영 시, 생기는 문제들

  • 기존에는 VM에 각각의 의존 패키지를 설치하였는데, 여러 프로그램을 하나의 VM에 구동하면, 의존 패키지에서 에러가 생길 가능성이 생깁니다.
  • 기존에는 하나의 IP가 하나의 프로그램을 가르켰다면, 이제는 한 IP에 여러 프로그램을 가르켜야하는데, 이를 구현할 방법을 찾아야합니다. 포트로 구분하기에는 이쁘지 않았습니다.
  • VM을 중단 후 시작하면 IP가 변경되는데, DDNS를 구축해야하는가.
  • Twitch API를 이용하는 토이 프로젝트는 HTTPS를 요구합니다. (Azure Web App에서는 HTTPS를 기본적으로 지원했습니다.)

위와 같은 내용을 아래와 같이 해결하기로 합니다.

위 문제의 해결책

  • 각 프로젝트를 Dockerize 하여, 컨테이너 환경에서 구동하여 의존성 충돌 문제를 해결합니다.
  • AWS Lightsail은 고정 IP와 VM을 연결하면 VM이 구동되는 중에는 IP에 대한 과금은 하지 않습니다. 이를 통해 고정 IP를 연결하고, 개인 도메인을 이용하여 각 프로젝트 별로 서브 도메인을 생성하여 앞단에 Nginx를 두고, 리버스 프록시를 걸어주기로 했습니다.
  • Let's Encrypt를 사용하여 SSL 인증서를 발급 받고, Nginx와 연동합니다. 이후, HTTP 연결을 강제로 HTTPS로 리다이렉트 시켜 전부 HTTPS를 통해 통신하게 됩니다.

위의 해결 내용과 연계하여 아래 내용을 추가 조치하기로 했습니다.

  • 내부 통신으로 해결할 수 있는 것들은 내부에서만 통신하게 하여, 트래픽을 최소화합니다.
  • Nginx를 앞에 두기 때문에 컨테이너를 Public에 직접 오픈할 필요가 없어졌습니다. 컨테이너 네트워크 내부에만 포트를 엽니다.
  • 각 프로젝트는 정식 서비스 예정이 없기 때문에 robots.txt를 통해 검색을 제한합니다.

해결했어요!


그렇게 최초로 그린 컨테이너 구조 (참고용)

  • 모든 요청은 일단 Nginx가 받습니다.
    요청을 읽고, 어떤 도메인으로 접속했는지 등을 판단하여 해당하는 컨테이너로 프록시를 걸어줍니다.
  • certbot은 90일 마다 자동으로 SSL 인증서를 갱신합니다.
  • 각 컨테이너는 필요에 따라 DB를 참조합니다.
    즉, Nginx, certbot, ms2-bot 컨테이너는 DB에 직접 접속할 순 없습니다.

위 구조는 각 서비스별로 Docker Compose Yaml 파일을 구성하고, 각 컨테이너별로 통신이 필요한 경우에만 각각 도커 네트워크로 연동합니다. 이렇게 하면, 필요한 컨테이너만 노출되기 때문에 관계 없는 컨테이너에 방해를 주지 않을 것으로 보입니다.

일단은 위 구성대로 VM 단독으로 사용하고, 업로드된 Object가 많아지면 AWS S3 또는 Lightsail Bucket을 생성하고, VPC로 연동하는 식으로 확장할 것 같습니다.

Lightsail 간단 후기

Lightsail의 요금 산정, 서비스 생성 과정에 대해서는 많은 분들이 소개해주시기 때문에 저는 매우 주관적인 후기를 남겨보겠습니다. 아마도, Azure와의 비교가 주되지 않을까 싶습니다.

  • Lightsail의 Web Console 반응이 빠릿빠릿합니다. Azure에서 경험하지 못했어요.
  • Azure는 리소스 생성이 상당히 느리다는 느낌을 받았는데, Lightsail은 빨라서 좋았습니다.
  • Azure는 VM을 생성할 때 Username을 지정할 수 있으나, Lightsail은 기본 Username이 지정되어 있기 때문에 해킹에 취약할 수도 있겠다는 생각이 듭니다. 특히, 테스트나 실습 용으로 VM을 올리고, 방치한다면 대참사가 생길 것 같아요.
profile
Have A Happy Coding Time!

0개의 댓글