AWS 용어를 알아보자

시작하기...

AWS와 도커를 사용해서 어떻게 프론트엔드를 올리는지에 대해서는 이해했지만, 여전히 AWS에는 너무 많은 서비스들이 존재하고, 이러한 것들이 어떻게 서로 동작하는지, 왜 필요한지에 대해서는 제대로 이해가 가지 않았다. 하지만 DevOps와 원활히 소통하고 점점 규모가 커지고 복잡해지는 프로젝트를 다루기 위해서는 해당 서비스들이 어떻게 굴러가는지, 왜 필요한지에 대해서는 이해해볼 필요가 있는 것 같다.

 

이번 시간에는 알쏭달쏭한 AWS 용어와 용도, 그리고 여기에 달려있는 Grafana, 프로메테우스에 대해 이야기를 해보려 한다.

 

일반적인 AWS 흐름

지난 시간 도커를 공부하면서 프론트엔드 배포 흐름에 대해 알아보았다면, 이번에는 AWS에서 클라이언트가 접속할 경우 어떻게 흘러가는지 확인해보자.

StormIT AWS 구성 예시

1. 유저의 도메인 접속

Amazon Route 53은 무엇인가요? - Amazon Route 53

유저가 웹사이트에 접속할 때는 곧바로 192.xx.xxx.xx로 접속하는 것이 아닌, 도메인 네임을 통해 접속하는 것이 일반적이다. 이 두 가지를 연결해주는 역할을 하는 것이 route 53이다. 

 

route 53가 하는 역할은 크게 세가지이다.

• 도메인 등록
• DNS 라우팅
• 리소스 상태 확인

그냥 IP 주소 그대로 쓰면 안되나?

IP 주소 그대로 접근하게 할 순 있지만, 보안적으로 IP 주소가 공개되어있는 것은 그리 추천할 만한 사항은 아니다. 무엇보다도 가독성이 좋지 않아 유저가 접근하는 것에 큰 불편함이 있고, 트래픽을 고려하여 여러개의 IP 주소로 로드밸런싱을 하기 위해서라도 DNS를 사용하는 것이 바람직하다.

 

이제 내 서버의 주소 대신 도메인 네임을 통해 접근할 수 있도록 연결해주는 작업이 되었다. 하지만 문제가 생겼다. 만약 내 웹사이트가 전세계 사람들이 사용하는 초특급짱인기 웹사이트라면, 그리고 최대한 빠른 서비스를 제공하는 것이 중요한 사안이라면 유저와 가장 가까운 곳의 서버에서 서비스를 하는 것이 좋다. 하지만 어떻게 할 수 있을까?

2. Amazon CloudFront CDN

https://aws.amazon.com/ko/cloudfront/

CDN 서비스 | CloudFront | Amazon Web Services

Amazon에서는 콘텐츠 전송 네트워크 서비스 (CDN)로 사용자와 물리적으로 더 가까운 위치의 서버에서 컨텐츠를 빠르게 전송할 수 있도록 하는 서비스를 지원한다. 우리가 한국에서 서비스를 하더라도, AWS가 알아서 CDN을 통해 영국이나 미국에 있는 유저에게 해당 지역과 가까운 곳에 위치한 서버로부터 컨텐츠를 받을 수 있게 하는 것이다. 이를 통해 지연 시간을 최소화하고 성능을 최적화 할 수 있다.

 

하지만 이렇게 요청이 이루어지는 도중, 어떤 악의적인 공격자가 DDos 공격을 가해 엄청난 양의 트래픽을 발생시키게 된다면 어떻게 될까? 서버가 터지는 문제도 있지만, 그보다 더 무서운 것은 AWS의 요금 부과 방식이다. AWS의 서비스들은 통신 횟수에 따른 종량제 요금제로 많은 통신이 이루어질 수록 더 많은 비용을 내야 한다. 갑작스러운 공격으로 인해 CloudFront에 엄청난 양의 통신이 이루어지게 된다면 그대로 금전적 손실로 이어질 수 있다. 그렇다면 CDN에서 컨텐츠를 전송하기 전에 해당 유저가 정말 우리의 고객인지, 안전한지를 걸러보는 것도 좋은 방법이다. 이를 위해 우리는 CloudFront에 방화벽을 세워둘 수 있다.

 

AWS WAF

AWS에서는 Web Application Firewall을 통해 방화벽을 세울 수 있도록 돕는다. 주로 layer 7에서 발생하는 여러 보안 위협 (DDos, SQL 인잭션, 크로스 사이트 스크립팅 등)을 대응한다.

해당 서비스를 CloudFront와 연계하면, 웹 요청이 들어올 때 마다 해당 요청이 정상적인지, 우리가 원하는 요청인지, 아니면 원하지 않는 요청인지를 판별하고 필터링할 수 있다. 성능과 보안을 함께 챙길 수 있게 된 것이다.

 

3. ELB

Elastic Load Balancing이란 무엇인가요? - Elastic Load Balancing

Elastic Load Balancer는 이름대로 로드 밸런싱 서비스를 제공해준다. 둘 이상의 가용 영역이 존재할 경우, ELB는 주기적으로 등록된 EC2 인스턴스를 모니터링하고 상태가 양호한 쪽에만 트래픽을 라우팅한다. 인스턴스에 문제가 생길 경우 경보를 줄 수 있도록 설정도 가능하다 한다.

 

4. Nginx

Nginx 프록시 서버는 자주 들어봤을 것이다. 때문에 이 부분은 간단하게 용도만 짚고 넘어간다.

• 로드 밸런싱을 통한 트래픽 분산
• 캐싱을 통한 서버 부하 단축 및 응답 시간 최소화
• 클라이언트 서버 간 통신 암호화
• 정적 콘텐츠 최적화

5. API gateway

Amazon API Gateway란 무엇입니까? - Amazon API Gateway

백엔드에서 제공되는 API를 API Gateway에서 관리하게 되면, 해당 API에 대한 권한 부여를 쉽게 할 수 있는 것을 더불어 API의 트래픽을 관리하고 보안을 강화할 수 있으며 Cloudwatch에서 모니터링과 로깅이 가능해진다. 최소 비용이 없으며 요청 횟수에 따른 비용만 지불하여 비용을 최소화 할 수 있는 장점도 있다.

6. 리전 및 영역

리전 및 영역 - Amazon Elastic Compute Cloud

 

모든 난관을 통과하여 드디어 Frontend가 서빙되는 서버까지 접근이 완료되었다. 해당 서버는 Docker가 올려진 상태일 수도 있고 아닐 수도 있으며 어떻게 jenkins, github와 배포 과정을 거쳐 올라가는지는 또 별개로 다뤄야 하겠지만, 어찌되었건 여기까지 도달하였다면 Client는 정상적으로 우리가 제공하는 웹 서비스를 볼 수 있게 된다. 하지만 그림에서 보면 Availability Zone이 항상 두 개 이상으로 그려져 있는 것을 볼 수 있다. 이는 AWS에서 제공하는 가용성이다.

 

서버는 언제 어떤 불운이 겹쳐 갑작스럽게 동작되지 않을 위험을 가진다. 100% 안전한 서버는 없는 것이다. 그렇다면 하나보다는 두 개를 두는 것이, 두 개 보다는 세 개를 두는 것이 더 안전하지 않을까? 이런 가능성으로 인해 서로 다른 리전에 서버를 두어 하나에 문제가 생기더라도 다른 쪽에서 동일한 서비스를 할 수 있도록 물리적으로 서버의 위치를 분리하는 것이다. 

 

다음 시간에는...

간단하게 AWS에서 사용되는 기능들과 용도에 대해 알아보았으니, 이러한 서버의 상태와 이슈 로깅 등을 모니터링하는 방법과 그 용어에 대해 한번 알아보자. 주로 Grafana와 Prometheus에 대해 이야기해볼 것 같다.