SQS FIFO seoul 리전 추가

https://aws.amazon.com/ko/about-aws/whats-new/2019/02/amazon-sqs-fifo-qeues-now-available-in-15-aws-regions/?fbclid=IwAR0bpsLT7gUS6Ek64ybLTvu8IuxEGn66zHPz4i7N11S0eXEFlou9ly9K8G4

페이스북 AWSKRUG 그룹에서 주워온 소식이다.

바로 SQS에서 FIFO 대기열을 서울에서도 이제 쓸 수 있다는 점이다.

글은 2월 7일에 올라오긴 했지만 늘 그렇듯 이전에 미리 업데이트하고 나중에 게시했겠지

AWS의 좋은 점

원래라면 내가 구현해야되는 기능을 거의? 완벽하게 완전관리형으로 제공해준다는 점이다.

물론 클라우드 회사 중 비용이 비싼 편이지만 

내가 1~2년 서비스를 하면서 몸소 장애/에러를 경험하면서 추가하는 요소들을 AWS는 기본으로 제공해준다.

기본으로 제공? 무슨 뜻?

예를 들면 AWS의 Elastic beanstalk을 쓰면 내부적으로 로드벨런서에 다수의 EC2 생성 및 연결해서 하나의 어플리케이션처럼 사용할 수 있게 제공해준다.

문제는 생성되는 로그파일이 많아져서 디스크를 가득 채우면 원래라면 장애가 나고 

스스로 반성하며 별도의 배치나 디스크 확장을 통해서 해결해야하지만!

Elastic beanstalk은 알아서 새로운 볼륨으로 교체 + 재부팅을 해준다는 사실이다.

(aws summit 행사가면 자주 볼 수 있는 문구 : 완전관리형/고가용성)

그래서 SQS는?

일단 SQS는 AWS에서 제공하는 완전관리형 메세지 큐이다. 일정 사이즈의 TEXT를 큐에 쌓아두고 나중에 처리하기 위해서 사용하는 제품이다.

예를 들어, 댓글 작성 API를 만든다면 댓글 작성, Log, Push 알림의 작업이 있을 것이다.

(3개의 작업은 필수적으로 처리되야하는 요소이다)

그런데 댓글 작성은 실시간으로 해야되지만 

Log, Push 알림은 사실 운영적인 요소이기 때문에 유저입장에서는 실시간 작업을 할 필요가 없다.

그래서 이런 작업들은 SQS에 쌓아두고 나중에 worker를 통해서 SQS에서 큐를 빼와서 천천히 처리하는 것이다.

(물론 이벤트, error, retry 처리 등 다양한 용도로 사용된다.)

유저 입장에서는 일부 작업을 실시간으로 하지 않기 때문에 API가 더 빨라짐을 몸소 느낄 수 있다는 장점이 있다.

개발자 입장에서는 일단 큐에 쌓이기 때문에 해당 내용을 당장 처리하지 않아도 되고 처리 중 실수로 에러가 발생해도 실수가 난 트랜젝션을 롤백하고 해당 내용을 다시 SQS에 담으면 되니깐 장애 대응이나 운영적인 측면에서 좋다.

물론, 비용적인 측면에서는 SQS를 쓰면 메세지큐당 돈이 나가니깐 누군가는 불필요하다고 느낄 수 있다. 실제로 전회사에서 EC2, RDB와 비슷한 규모로 SQS에서 비용이 발생했다.

(매달 AWS 계산서를 본 후 대표의 눙물...)

하지만, 대용량 로그나 DB의 과도한 write 트랜젝션을 조절하기 위해서는 SQS와 같은 메세지 큐는 필수적인 요소이다.

(MYSQL과 같이 write 트랜젝션이 한개의 클러스터에 집중되는 구조라면 더더욱 필수)

그럼 SQS FIFO는?

FIFO대기열은 기존의 SQS와 다른 점이 메세지의 중복제거를 지원한다는 점이다. 이를 활용한다면 로그인 대기열, 수강신청 사이트처럼 중복되지 않는 대기열을 만들 수 있고 실시간 채점과 같이 정확히 한번만 처리되야하는 서비스에서 편하게 개발할 수 있다는 점이다.

이걸 난 리전 문제 때문에 쓸 수 없어서 기본 SQS에 일단 메세지를 쌓고 

worker에서 처리할때 redis에 메세지를 캐싱하고 

대신에 처리하기 전에 같은 메세지가 redis에 캐싱되어 있으면 

worker에서 처리하지 않고 큐를 제거하도록 구현했다.

(물론 처리한 큐는 캐싱된 메세지를 지워야하겠지)

즉, 어쩔 수 없이 중복방지를 위한 redis나 DB 등을 사용해야했다.

(불필요한 비용)

하지만 SQS FIFO를 사용하면 기존의 redis를 사용할 필요가 없고 

대신 비용은 큐당 $0.4에서 $0.5로 $0.1만 더 지불하면 된다.

(물론 FIFO의 경우, 최대 트랜젝션 Limit가 있기 때문에 이 또한 고민해야될 포인트이다)

서울리전에 출시된게 그렇게 좋은 일인가?

왜 중요하냐면 클라우드는 단순 제품의 시간당 비용 외에도 트래픽 비용을 별도로 받는다.

나도 전 회사에서 이걸 쓰고 싶었는데 당시엔 일본만 지원이되서 사용을 못했었다.

그 이유는 바로 타리전간에 발생하는 트래픽 비용 문제가 크기 때문이다.

좀 더 자세히 설명하자면

AWS 내의 트래픽. 예를 들어서 EC2에서 동작하는 웹서버에서 SQS에 메세지를 전송하는 트래픽 비용은 무료이다.

(이를 내부 트래픽이라고 한다)

(물론 메세지를 쌓는데 발생하는 비용은 있다)

하지만 유저가 EC2에서 동작하는 웹서버에서 값을 주고 받거나 S3에서 이미지를 다운 받는 등의 비용은 과금대상이다.

(이를 외부 트래픽이라고 한다)

그렇기 때문에 

클라우드 서비스에서는 request, response 사이즈 조절을 잘해야 트래픽 비용을 절감할 수 있고

API 구조를 잘 설계해야 트래픽이 과도하게 발생하지 않는다.

(예를 들어 게시판에서 모든 글을 다 가져오지 않고 일정 page로 나눠서 일부만 노출시키는 이유가 그러하다)

(하지만 page당 글 수가 너무 적으면 사용자는 자주 요청을 해야하니 사용에 불편을 느낄 것이다)

문제는 AWS 내에서 트래픽이 발생했지만 다른 리전의 제품 간의 통신에서 발생하는 트래픽이다.

예를 들어서 웹서버(EC2)는 한국(서울)에 있지만 SQS가 일본에 있는 경우이다.

고민할 필요없이 AWS의 SQS 요금 정책 사이트를 가보자.

(필요한 내용만 스샷!)

같은 리전은 무료지만 다른 리전은 요금을 받는다. 즉, 안내도 될 비용을 내야한다는 것이다.

만약에 내가 SQS FIFO를 일본 지역껄 사용하고 한국 EC2에서 메세지큐 요청을 처리 해보자.

"123"을 SQS에 집어 넣는다.

-> 그럼 "123"에 대한 서울-일본 송신 트래픽 요금과 FIFO 대기열 비용이 부과된다.

SQS에 "123"이 있는 상태에서 또 "123"을 넣는다면?

-> 이전과 동일한 트래픽 요금과 FIFO 대기열 요금이 발생한다.

즉, 2회의 [트래픽 + FIFO 대기열] 비용이 발생한다.

만약에 서울 SQS FIFO를 사용한다면 단지 [FIFO 대기열] 2개의 비용만이 발생할 것이다.

즉, 리전을 섞어서 사용하는 것보다 단일 리전에서 사용시 저렴하다는 뜻이다.

(특히 수익이 적은 스타트업이라면 트래픽 비용은 매우매우 민감할 사항이다)

그래서 결론

매우 늦게 서울 리전에 출시되긴 했지만 리전별 출시 순서를 보면 2~3순위 정도인 듯하다. 

예전에 사용하던 Athena도 17년 11월에 서울 출시되고 

이를 확장해서 사용할 수 있는 Glue나 코카콜라에서 꿀빨았다는 step functions도 18년 5월에 서울에 출시된 걸보면

예전보다는 서울 출시일에 대한 중요도가 올라간듯 하다.

(athena를 쓸때 glue가 편하다고 해서 써보고 싶었는데 서울에 없어서... ㅂㄷㅂㄷ)

대부분 1년 이내로 서울에 출시해주는걸보면 한국에서도 AWS를 많이 사용하는 듯하고

나름 힘있는? 업체에서 푸쉬를 많이 해주면 더 많은 기능을 서울에서도 쓸 수 있을 듯하다.

(AWS가 돈많이 쓰는 업체의 요구조건을 빨리 들어준다는 소문이 있...)

어서 서울의 영향이 더 커져서 도쿄리전보다 빨리 출시되고 기술지원도 한글을 지원했으면 매우매우 좋겠다...(눙물)