태그 보관물: AWS

IM8(아임에잇) 오토스케일링 적용기

안녕하세요. 이음소시어스 개발팀 서버개발자 육승찬(루)입니다.

오늘은 이음소시어스의 핫한 서비스 “IM8(아임에잇)“의 오토스케일링 적용경험을 공유하려고 합니다. 먼저 오토스케일링에 대한 이야기를 하기 앞서서, 아임에잇이 어떤 서비스인지 간단하게 설명하고 시작하겠습니다.

IM8 (아임에잇) ?

직장인을 위한 프리미엄 소개팅 서비스

im8_1

IM8은 2013년 10월에 런칭되어 “까다로운 신원인증으로 높은 매칭 신뢰도를 주자”를 목표로 열심히 발전해 왔습니다. IM8의 8은 8개의 회원 타입(스마트커리어비주얼유니크글로벌밀리언패밀리액티브)을 의미합니다.

im8_2

현재 아임에잇의 모든 서버는 AWS를 통해서 운용하고 있습니다. 그럼 본격적으로 AWS x IM8 오토스케일링 적용기를 공유해보겠습니다. GOGO~

기존 서버

처음에는 IM8 API 서버를 EC2(t2.medium) 한대로 운영해왔습니다. 이후 트래픽의 증가에 따라 ELB에 EC2(t2.medium) 서버 2대를 붙여 운영하는 구조로  발전했습니다. 하지만 점점 더 트래픽이 증가하면서 피크 시간대에 서버가 터지는 일이 발생하기 시작했습니다. 그래서 현재 서버구조의 문제점을 정리하고 문제점을 개선하기로 결정했습니다.

서버 증설 방법

1. ELB에 서버를 더 붙이자 OR 서버의 스팩을 올리자 !

하루 두 번 푸시가 갈 때 아임에잇에 가장 접속자가 많이 몰립니다. 왜냐하면, 실제 매칭이 되는 시점에 사용자가 들어와서 상대방의 프로필을 확인하는 구조이기 때문입니다. 그래서 일반시간대에는 많은 서버가 필요 없습니다. 이 방법의 장점은 적은 시간 안에 문제를 해결할 수 있다는 점입니다. 하지만 비용적인 측면에서 굉장히 안 좋다고 판단했습니다. 접속자가 많지 않아도 항상 여러 대의 서버가 띄워져 있고 비용을 계속 지불하기 때문입니다.

2. AutoScaling (v)

접속자가 별로 없는 시간에는 최소한의 서버를 유지하고 피크 시간대에 여러 서버를 유지하는 방법입니다. 하루 두 번 피크가 있는 아임에잇에게 아주 좋은 방법이라고 생각합니다. (대부분 서비스에 좋지 않을까하는 생각이.. 😀) 평상시에는 최소한의 서버를 유지하기 때문에 비용적인 측면에서도 굉장히 유리했습니다. 그래서 이번 기회에 아임에잇에 AutoScaling을 적용해보기로 했습니다.

AutoScaling 준비하기

  • 결제서버 분리
  • 통일된 인스턴스 만들기
  • Scaling되는 서버를 항상 최신으로 유지하기
  • Scaling Rule 정하기
  • 서버를 띄우는 시간이 있기 때문에 푸시가 나가기전에 미리 띄우기 (Pre-warm)

1. 결제서버 분리

아임에잇은 모바일과 웹에서 PG서비스를 붙여서 결제할 수 있도록 제공하고 있습니다. 특정 PG는 요청 가능한 서버의 IP를 제한하고 있는 경우가 있어서 결제서버를 분리해야 했습니다. 기존 서버에서 사용하던 IP를 결제서버에 붙이고 내부에서만 통신 가능한 결제서버를 만들었습니다.

  • 기존 서버구조
기존 서버 구조

기존 서버 구조

  • 결제서버를 분리한 구조
새로운 서버 구조

새로운 서버 구조

2. 통일된 인스턴스 만들기

AWS에서 제공하고 있는 오토스케일링 기능은 미리 정의한 규칙에 따라서 인스턴스가 띄워지고 내려가는 형태로 동작합니다. 인스턴스는 AutoScalingGroup에 등록해놓은 AMI를 이용하여 띄우게 됩니다. 원래 사용하고 있던 서버 2대는 완전히 같은 인스턴스가 아니였습니다. 하나를 나중에 띄웠기 때문에 시스템 라이브러리 같은 경우 조금씩 버전이 달랐습니다. 그래서 이번 기회에 통일된 인스턴스를 만들고자 했고, 구조는 아래와 같습니다.

server

  • 시스템 라이브러리 설치 (ex. git)
  • API Rails App 설정
  • Puma 설정
  • Nginx 설정
  • Papertrail 설정 (로그 수집)

3. 서버를 항상 최신으로 유지하기

오토스케일링 되고있는 서버들은 항상 최신의 코드를 유지해야 하고 같은 응답을 줄 수 있어야 합니다. 아임에잇은 Git으로 소스코드를 관리하고 배포에는 Capistrano를 사용합니다. 지금까지는 서버 2대만을 최신으로 유지하면 됐기 때문에 아래의 순서로 배포를 해왔습니다.

  • Git fetching
  • whenever에 등록된 스케줄링 crontab에 등록
  • Puma Reload

오토스케일링을 적용하기 시작하면 서버가 딱 몇 대라고 가정할 수 없습니다. 그래서 모든 서버를 항상 최신으로 유지하기 위한 아래 두 가지 정리해봤습니다.

  • EC2 Instance가 시작되는 시점에 최신으로 만들기

EC2 설정 중에 “User Data“라는 부분이 있습니다. 인스턴스가 띄워지는 시점에 명령어를 실행시킬 수 있도록 할 수 있습니다. 여기서 소스코드를 최신상태로 유지하고 puma를 띄우는 등의 명령을 할 수 있습니다. 이렇게 하면 스케일링 돼서 실행되는 서버도 최신코드를 유지할 수 있게 됩니다. 쉽고 빠르게 모든 서버의 최신상태로 유지할 수 있지만 매 서버가 띄워질 때마다 Ruby 라이브러리 설치(bundle install)하기 때문에 서버가 띄워지고도 최신상태로 유지하는데 시간이 더 걸린다는 단점이 있습니다.

  • 최신의 AMI를 사용하기

이 방법은 미리 최신의 AMI를 항상 유지하고 서버가 띄워지는 부분에 대해서는 신경을 쓰지 않아도 됩니다. 코드를 한 번만 최신으로 유지하면 되고 라이브러리 설치 시간도 매우 줄일 수 있다는 장점이 있습니다. Ruby 라이브러리 중에 ELBAS라는 라이브러리가 있습니다. Capistrano와 연동되어 배포시 실행되고 있는 인스턴스를 최신으로 만들어주고, AMI까지 만들어주는 아주 좋은 녀석입니다… 이 라이브러리를 사용하면 빠르고 쉽게 항상 최신의 AMI를 유지할 수 있습니다.

4. Scaling Rule 정하기

처음에 AutoScalingGroup만 만들면 아무리 기다려도 서버는 스케일링 되지 않습니다… 그래서 어떤 규칙에 의해서 스케일링 할 건지 정해줘야 합니다. 먼저 AutoScalingGroup 설정을 보시면 “Instances“, “Desired“, “Min“, “Max“가 있습니다. Instances는 현재 서버의 개수, Min은 최소 서버 수, Max는 최대 서버 수를 의미합니다. Desired는 스케일링이 돼서 현재 몇 대를 희망하고 있는지를 의미합니다. Desired와 Instances의 수가 같으면 더는 서버를 띄우거나 내릴 필요가 없다는 의미입니다.

아임에잇에서는 서버를 띄우는 규칙 2지와 서버를 내리는 규칙 2가지를 사용하고 있습니다.

  • Add 1 instance (CPUCreditBalance < 9)

10분안에 CPUCreditBalance의 수치가 9 미만이라는 알람 두번이 울리면 인스턴스를 띄워라!

이 규칙은 CPUCreditBalance 수치에 따라서 동작하게 됩니다. 아임에잇 서버는 현재 t2계열의 인스턴스를 사용하고 있습니다. T2계열의 인스턴스에는  CPUCredit라는 개념이 존재합니다. 크레딧이 부족하면 CPU 연산 능력이 매우 떨어지기 때문에 새로운 서버 한 대를 띄우도록 하고 있습니다.

  • Add 2 instances (CPUUtilization >= 60)

2분안에 CPUUtilization의 수치가 60% 이상이라는 알람 두번이 울리면 인스턴스를 띄워라!

평소에는 CPU 사용률이 평온하다가 피크시간이 되면 갑자기 막 올라갑니다. 그래서 CPU사용률이 60% 이상이 되면 인스턴스 2대를 띄우도록 하고 있습니다. (피크시간이 아니면 올라갈 일이 거의 없기 때문)

  • Delete 1 instance (CPUUtilization < 25), Delete 2 instances (CPUUtilization < 15)

1분에 한번씩 CPU 사용률이 낮다는 알람 10번이 울리면 인스턴스를 내려라 !

피크시간이 지나고 나면 급격히 사용률이 떨어지기 때문에 인스턴스를 내리기 시작합니다. 하지만 인스턴스를 내리는 옵션을 상당히 까다롭습니다. 알람이 울리는 10분은 같지만 연속적으로 10번이 울려야 하기 때문입니다. 이유는 인스턴스를 내려도 되는 상황인지 확실시 하고 싶었기 때문입니다. 대게 인스턴스를 띄워서 생기는 문제보다 내리면서 생기게 되는 문제가 많기 때문입니다..

5. Pre-warm

아마 대부분의 프로그래머분들은 장애를 원하지 않을 것 입니다. 이음소시어스 개발팀도 장애가 나지않게 하기 위해서 노력을 하고 있습니다. 아임에잇 서비스의 경우 12:30, 19:00에 푸시를 보내고 있습니다. 실제로 푸시를 보내고 나서 오토스케일링 룰에 따라 서버를 띄우기 시작하면 대처가 좀 늦습니다. 갑자기 들어오는 트래픽을 버티지 못하고 아예 서버 한대가 죽어버리는 일도 있었습니다. 그래서 12:20, 18:50에 서버를 미리 띄워놓고 있습니다.  서버를 미리 띄우는 코드는 Python으로 작성했고 Crontab에서 실행되도록 하고 있습니다.

 

정리

이번 포스팅에서 아임에잇의 오토스케일링 적용 경험을 적어보았습니다. 사실 이번 포스팅을 작성하면서 너무 뻔한 글이 되지 않을까 걱정이 많았습니다. 이미 오토스케일링에 대한 글도 많고 참고할 부분도 많아서 잘 쓸 수 있을지 고민이 되었기 때문입니다. 그래서 더 자세히, 숨김없이 써보려고 노력했습니다.

오토스케일링을 적용하면서 가장 크게 얻은 두 가지는 비용절감과 불안감이 사라졌다는 것입니다. 기존 서버 비용 보다 45%의 비용을 절감할 수 있었습니다. 그리고 평소보다 가입자가 많은 날은 트래픽에 서버가 죽을까 하는 불안감이 있었습니다. 오토스케일링이 만병통치약은 아니지만 룰에 의해서 확장하고 수축하는 구조 덕분에 더 많은 트래픽을 커버할 수 있게 되어 불안감이 해소되었습니다.

마치며..

이번 오토스케일링을 사용하면서 ELBAS라는 라이브러리가 참 좋다고 느꼈습니다. 너무 쉽게 AMI를 최신으로 유지할 수 있는 방법을 제공해줬기 때문인데요. 그래서 이 라이브러리의 핵심적인 부분을 파이썬 코드로 작성해봤습니다 (파이썬을 오래 쓰다보니 재밌는건 파이썬으로 구현해보고 싶은 맘이 생기네요..)

 

 

이음(I-UM) on AWS

안녕하세요. 이음소시어스 개발팀 서버개발자 육승찬(루)입니다.

바야흐로… 2010년 4월 소셜데이팅 서비스 “이음”을 베타 런칭했습니다. 이음은 5년 동안 베이론 서버 제작을 포함해서 많은 변화를 추구해 왔습니다. 앞서서 이음 서비스를 간단하게 설명하고 시작하겠습니다.

이음은 대한민국 대표 소셜데이팅 서비스이며, 현재 회원 110만 명, 일 평균 1,000쌍 이상의 상호 OK가 진행되고 있습니다. 그리고 150만 이상의 누적 앱 다운로드를 기록하고 있습니다.

스크린샷 2015-07-03 오후 2.22.01

이 포스팅에서는 이음이 AWS를 어떻게 사용하고 있는지 설명하려고 합니다. 이음은 2012년 6월부터 AWS를 사용해 왔습니다. 현재 사용하고 있는 서비스를 간략히 나열해보면 아래와 같습니다.

  • EC2
  • ELB
  • RDS
  • S3
  • CloudFront
  • Route53
  • CloudWatch
  • SES
  • SNS

이렇게 나열해보고 나니 생각보다 많이 쓰고 있었네요! 그럼, 각 서비스를 어떻게 사용하고 있는지 설명해 드릴게요.

나와랏.. 스피드웨건 !

나와랏.. 스피드웨건 !

EC2 & EBS & ELB

이음에서는 다수의 EC2 인스턴스를 사용하고 있습니다. API서버, 웹서버, 어드민서버, 통계서버, 개발서버, Redis, SMS 등을 EC2에 올려놓고 사용하기 때문입니다. EC2는 순식간에 가상 서버를 만들 수 있는 장점이 있습니다. 예로 이전의 포스팅했던 깃랩 업데이트 당시에도 테스트하기 위해 가상서버를 만들어서 진행했습니다. AMI로 인스턴스를 만드니 빠르게 테스트 할 수 있었습니다.

대부분의 EC2의 Volume으로 EBS General Purposed SSD(gp2)를 사용하고 있습니다.

API 서버와 웹서버 같은 경우는 ELB를 앞단에 두고 있습니다. API 서버는 Auto-Scaling 기능을 사용하여 자동으로 scale-out 됩니다. 어드민, 통계, Redis 같은 경우는 아직 scale-out 할 필요성이 없어서 순수 EC2만을 사용하여 구동하고 있습니다.

여담으로 내부적으로 T2 타입 인스턴스를 좋아하고 많이 사용합니다. T2 타입 인스터스는 인스턴스 크기를 기반으로 정해진 고정 비율에 따라 지속해서 CPU 크레딧을 받고, 크레딧을 사용하여 기본 CPU 성능을 넘은 “성능 순간 확장”이 가능합니다. 간단한 테스트 서버가 필요할 경우 T2 타입의 인스턴스를 사용하면 좋습니다 ^^

RDS

이음에서는 MYSQL을 사용하고 있습니다. RDS에서 Mysql Engine을 선택하여 Master 1대, Read Replica 1대를 사용하고 있습니다. 그리고 Provisioned IOPS 옵션은 2000으로 사용하고 있습니다.

RDS 인스턴스는 종료하지 않고 인스턴스 타입을 변경할 수 있습니다. (물론 다운타임은 있습니다) 또한, Replica를 생성할 수 있는 기능도 있어서 관리 측면에서는 매우 좋습니다. RDS는 다른 서비스에 비해 상당히 비싼 편입니다. 하지만 관리적인 측면에서 매우 편하기 때문에 사용하고 있습니다.

최근에 RDS 오로라 엔진이 나왔습니다. 오레곤 리전에 인스턴스를 만들어서 사용해보고 있습니다. 이음 개발팀에서는 긍정적으로 보고 있고 빨리 도쿄리전에서 사용할 수 있었으면 하는 바람입니다.

S3

S3는 장점이 매우 많아 활용도가 무궁무진한 서비스입니다. 비용이 매우 저렴하고 오브젝트에 설정할 수 있는 옵션도 많습니다. Bucket에 로깅 기능도 있기 때문에 쉽고 편하게 사용할 수 있습니다. 그래서 이음에서 사용하는 모든 이미지는 S3에 저장하고 static 이미지들 또한 S3에 업로드하여 사용합니다. 또 이벤트 페이지가 필요할 때, 마크업을 작성하여 S3에 올려서 배포하여 사용하고 있습니다.

관리 측면에서 보면 S3는 정말 좋은 서비스입니다. 보통 static 서버를 따로 구성하게 되면 용량이 찼을 때, 증설 작업을 해줘야 합니다. 하지만 S3는 scale-out, 용량 증설에 고민할 필요가 없습니다. 다양한 서비스에 붙여서 사용할 수 있는 아주 매력적인 서비스입니다. (제가 정말 좋아해요..)

CloudFront

CloudFront는 S3에 업로드된 오브젝트를 배포할 때 사용합니다. 한국을 비롯한 세계 각 리전에 엣지가 있고 S3와 연동 쉬워서 매우 편리합니다. 이음에서는 프로필 이미지, 뱃지 이미지를 포함한 대부분 이미지를 signed URL을 사용하여 배포되고 있습니다.

이음은 AWS와 향후 1년간 CDN 서비스로 CloudFront만 사용하겠다는 Exclusivity 계약을 맺고 사용하고 있습니다. 위 계약을 맺게 되면 비용절감을 할 수 있습니다.

Route53

서비스 도메인 i-um.net, i-um.com의 DNS 서비스를 Route53로 옮겨서 사용하고 있습니다.  Route53는 비용도 저렴하고, 도메인 구입 비용도 비싸지 않습니다. 그리고 AWS의 다른 서비스들과 같이 사용하면 매우 편합니다. ELB, S3 웹호스팅, EIP, CloudFront와 연동이 매우 쉬우므로 좋습니다. 도메인 연결을 AWS Console에서 할 수 있기 때문이기도 하고요.

CloudWatch

ELB, EC2, EBS, RDS, SNS, Auto-Scaling Group의 상태를 모니터링합니다.. 이음에서는 CPU, DISK 등 다양한 기준을 두고 해당 조건에 맞으면 이메일, SMS로 알려줍니다. 그리고 특정 조건에 Auto-Scaling 되도록 연동하여 사용하고 있습니다.

CPU 올라간다~

CPU 올라간다~

SES

SES를 사용하면서 크게 문제 있었던 적은 없었으나, 이메일 반환율 때문에 메일이 온 적이 있습니다. 메일 전송시 반환비율이 높아지면 경고 메일이 옵니다. 반환율이 일정 비율을 넘기면 SES 서비스가 블럭 되므로 평소에 잘 관리해야 합니다.

SNS

이음에서 전송하는 모든 푸쉬는 SNS를 통해서 나갑니다. 여러 디바이스에 한 번에 보낼 수 있어서 매우 편리합니다. PUSH뿐만 아니라 CloudWatch에서 설정한 Alarm을 메일 또는 메세지로 보내주기도 합니다. SNS 내에 SMS를 보내주는 기능이 없어서 SMS 서버를 만들었습니다. 그리고 SNS에서 HTTP로 Call 하도록 구성했습니다.

맺음말

마지막으로 이음에서 사용하는 모든 서비스를 그림으로 그려봤습니다.

스크린샷 2015-07-03 오전 11.05.44

현재 개발팀은 RDS 오로라와 람다 서비스에 많은 관심을 기울이고 있습니다. 오로라는 서베이 후 괜찮다 싶으면 시범적으로 사용해볼 예정입니다. 람다의 경우 아직 Javascript, Java밖에 지원하지 않는 점이 아쉽습니다. AWS는 운영하면서 중간중간 변화를 주는 묘미가 있고 틈나는 대로 구성을 변경하고 있습니다. 앞으로도 더 좋은 서비스가 나오기를 바라면서 마칩니다.

 

PS. 항상 도움을 주는 AWS 팀에게 감사드립니다.

이상형 오디션 on AWS

2013년 11월 말… 새로운 프로젝트 개발을 시작하게 되었습니다. 이름하여 ‘본격대결, 이상형 오디션’ 입니다. 5개월여의 시간이 흘러 4월말 오픈 베타를 시작으로 5월 7일에 정식 런칭을 하게 되었습니다.

idealmate

 

현재 <안드로이드앱>을 스토어에서 만나볼 수 있습니다. 또한 이상형 오디션의 기획 이야기에 관심이 있으시다면 <게임과 네트워킹의 만남, 본격 대결 ‘이상형오디션’ 기획 이야기>를 읽어보시기를 추천합니다.

 

이 포스팅에서는 이상형 오디션이 인프라로 선택하고 사용한 AWS 서비스에 대해서 소개를 해보려고 합니다. 사용한 서비스를 간략히 나열해보면 아래와 같습니다.

  • EC2
  • RDS
  • S3
  • CloudFront
  • Route53
  • SNS
  • SQS

 

EC2

EC2는 AWS의 기본이 되는 서비스이며 가상 서버입니다. 사용자의 요청을 처리하는 API 서버와 서비스 운영, 통계 등을 담당하는 어드민 서버, 아직 AWS의 서비스로는 지원하지 않는 mongoDB 서버를 EC2 상에서 운영하고 있습니다. API 서버의 경우 ElasticLoadBalancer, AutoScaling 연동을 해서 자동으로 scale-out 이 되도록 해두었으나 아직 서비스 규모가 크지 않아서 효과를 보지는 못했네요.(얼른 트래픽이 많아져서 AutoScaling 이 빛을 발하는 모습을 보고 싶습니다.) MongoDB 의 경우 2014년 4월에 추가된 memory optimized instance인 r3 instance 를 사용하여 가격대비 높은 메모리를 쓰고 있으며 I/O 성능을 높이기 위해 Provisioned IOPS EBS volume을 붙여서 mongoDB 의 storage로 사용하고 있습니다. 참고로 r3 instance의 경우 HVM(Hardware Virtualization) AMI 만을 지원하므로 instance 생성시에 주의해야 합니다.

RDS

개발 시작 즈음부터 RDS에서 PostgreSQL을 사용할 수 있게 되었습니다. 이음에서 MySQL을 사용하면서 겪었던 문제들 중 하나가 table에 새로운 column을 추가할때 table에 lock이 걸려서 해당 table에 대한 요청을 처리할 수 없는 것이었습니다. PostgreSQL의 경우 column 추가가 매우 빨라서 기획이 바뀌거나 기능을 추가하는 경우에 좀 더 유연하게 대처할 수 있을 것으로 판단을 해서 선택하게 되었습니다. 또한 PostgreSQL의 안정성을 믿기로 했습니다. PostgreSQL 또한 Provisioned IOPS를 설정해서 안정적인 성능이 나오도록 했습니다. 역시나 아직까지 트래픽이 많지 않아 매우 안정적이며 여유롭습니다.

S3

S3는 다양하게 활용할 수 있는 매우 좋은 서비스입니다. 서비스를 위한 이미지와 사용자가 직접 업로드하는 프로필 사진 모두 S3에 업로드하여 서비스를 하고 있으며 각종 로그도 저장하고 있습니다. 또한 API 서버 배포시에 S3를 저장소로 사용하고 있습니다.

CloudFront

서비스용 이미지와 사용자 프로필의 경우 S3를 origin으로 하여 CloudFront를 통해 서비스를 하고 있습니다. CDN를 따로 계약할 필요없이 트래픽만큼만 비용을 지불하면 되니 정말 최고의 서비스가 아닌가 싶습니다. 참고로 사용자 프로필의 경우는 무분별한 크롤링을 방지하기 위해 signed URL을 사용하고 있습니다.

Route53

서비스용 도메인인 idealmate.kr의 DNS 서비스로 Route53을 사용하고 있습니다. 4월 10일부터 유료화된 DNSever 대신 사용하게 된 것이 그나마 이야깃거리네요. DNSever의 경우 standard DNS가 도메인당 월 천원(부가세 별도)이고 Route53의 경우 0.5달러여서 조금 더 저렴하기도 합니다.

SNS

모바일앱 Push nofitication을 사용하고 있습니다. 이상형 오디션의 경우 현재는 안드로이드앱만 출시된 상태지만 iOS앱도 출시를 위해 심사중입니다.(애플과의 밀당은 그만하고 싶네요ㅠㅠ)  SNS Push notification의 경우 APNS, GCM을 모두 지원하고 월 최초 백만건이 무료이며 추가 백만건당 0.5달러로 매우 저렴합니다. Push nofitication외에도 CloudWatch에서 설정한 alarm을 받는 용도로도 사용하고 있으며 alarm을 email과 http 연동을 통한 SMS로도 받고 있습니다.

SQS

이상형 오디션의 기능 중 랭킹 기능이 있습니다. 랭킹의 경우 사용자의 연승 갱신, 승리 추가, 채팅 요청, 채팅 수락 등의 액션에 따라서 랭킹 포인트가 증가해야 하는데 API 서버가 바로 랭킹 포인트를 갱신하기에는 부담스러운 작업입니다. 그래서 SQS를 사용해서 랭킹 포인트를 비동기로 증가시키도록 했습니다. 물론 SQS에 쌓인 job을 읽어서 처리하는 worker는 별도로 구현을 했습니다.

 

맺음말

이번 프로젝트를 하면서 AWS 서비스를 다양하게 사용해보았습니다. 이음에서는 아직 사용하지 않는 CloudFront, SNS Push notification을 사용하면서 비용도 절약하고 개발도 편하게 할 수 있었습니다. 프로젝트를 진행하는 동안 AWS도 RDS PostgreSQL 지원, EC2 r3 instance 추가, 가격 인하 등의 변화가 있었고 프로젝트에도 많은 도움이 되었습니다. 앞으로도 AWS가 더 발전하기를 바라면서 이만 마치겠습니다.