Category: Startup*


Sprinklr의 AWS 리전간 대용량 재해 복구 구축 사례

Sprinklr에서 통합된 고객 경험 관리 플랫폼을 통해 세계에서 가장 큰 브랜드 기업들의 마케팅, 광고, 조사, 관리, 상거래를 지원합니다. Facebook, Twitter, LinkedIn 및 전 세계 22개 기타 소셜 채널과 통합된 당사 플랫폼은 수천 개의 서버를 사용하고, 페타바이트 단위의 데이터를 조사하고, 매일 수십억 건의 트랜잭션을 처리합니다. Twitter 하나만 해도 하루에 몇 억 개의 트윗을 처리해야 합니다.

매일 처리하는 엄청난 데이터 양을 고려할 때 재해 복구(Disaster Recovery, DR)는 더없이 중요한 문제입니다. 자연재해나 인재가 발생하더라도 비즈니스 연속성이 보장되어야 합니다.

대부분의 기업은 DR 대신에 고가용성(HA)을 구현하여 서비스 가동 중지 상황에 대비합니다. HA 보장을 위한 서비스 폴백 메커니즘을 갖추고 있습니다. HA 모드로 실행되는 서비스는 여러 가용 영역에서 실행되지만 동일한 지리적 리전에 속하는 호스트가 처리합니다. 그러나 이러한 접근 방식은 리전 전체가 다운된 경우에 비즈니스의 정상적인 운영을 보장하지 않습니다. DR은 250마일 이상 떨어진 다른 리전에서 복구할 수 있다는 점에서 완전히 새로운 차원을 보여 줍니다. DR 구현은 액티브/패시브 모델로, 이는 여러 리전에서 중요성이 가장 덜한 서비스를 항상 실행하지만 필요할 때 인프라의 주요 부분이 시작 및 복원됨을 뜻합니다.

당면 과제

재해 발생 시 비즈니스 운영이 중단되는 위험을 감수하고 싶지 않습니다. 고객에 대한 약속의 일환으로 튼튼한 재해 복구 프로세스를 갖춰야 합니다. 이는 어느 비즈니스에나 매우 중요합니다. 예를 들어 허리케인 샌디가 기승을 부릴 때 미국 북동부 지역에 데이터 센터가 있는 일부 회사만이 홍수로 인해 오프라인 상태가 되었습니다. 당사 DR의 경우 복구 목표 시점(RPO)이 24시간입니다. 이는 복구할 데이터가 생성된 지 24시간이 지나지 않았음을 뜻합니다. 복구 목표 시간(RTO)은 DR이 선언된 시점으로부터 복원이 완료되기까지 걸리는 시간을 뜻하며, 당사의 경우 고객 SLA에 따라 6시간~24시간입니다. 테스트를 하면서 RTO를 4시간으로 정했습니다.

재해 복구(DR)를 위한 단계

규모 파악

Sprinklr의 리전 간 재해 복구 동기화

목표를 이해하려면 서비스 유형과 그 개수를 포함하여 현재의 작업 규모를 고려해야 합니다. MongoDB, Elasticsearch, SOLR, Mesos, RDS 등 광범위한 데이터/비데이터 서비스 목록이 있습니다. 따라서 서버가 수천 개에 이르는데, ELB는 거의 100개, route53 항목 약 4,000개, 1페타바이트 이상의 기본 데이터, 그리고 RDS 인스턴스 50개 이상이 있습니다. 이러한 서비스는 모두 복원 시점에 DR 리전에서 시작되어야 합니다.

목적 달성을 위해 사용자 지정 스크립트를 작성했는데, 이 스크립트는 주로 AWS API 호출을 통해 인스턴스를 시작하고, 스냅샷을 연결하고, elb 및 경로 항목을 생성합니다.

위 그림과 같이, 관련된 모든 백업은 복원을 위해 DR 리전으로 복사됩니다.

복사할 백업 유형은 크게 세 가지입니다.

  1. EBS 스냅샷: 사용자 지정 로직을 구축하여 사용 가능한 모든 백업과 그 진행 상황 및 완료 여부를 지능적으로 추적합니다.  AWS 한도를 넘지 않고 전체 스냅샷 사본을 얻고자 노력합니다.
  2. S3 스냅샷: cross s3 동기화를 사용하며, 이는 매우 효과적으로 작동합니다. 단 몇 분만에 기본 리전에서 DR 리전으로 데이터를 복사할 수 있습니다.
  3. RDS 스냅샷: AWS RDS CopyDBSnapshot API를 사용하여 RDS 스냅샷을 복사합니다.

DR을 위한 파일럿 라이트 설정

재해 복구 미리 설정빠른 시작을 위해, 재해 복구를 위한 게이트웨이를 얻으려면 몇 가지 서비스가 실행 중이어야 합니다. VPC, 서브넷, Route53 항목을 설정하는 것도 여기에 포함됩니다. 이를 위해 사용자 지정 도구를 구축했습니다. 비슷한 CIDR 구성과 서브넷 마스킹으로 VPC를 만들고, 경로 항목의 경우 새 서브넷이 생성될 때마다 DR 리전에도 자동으로 생성되도록 합니다. 이를 위해 AWS API 호출을 통해 기본 리전의 서브넷 정보를 파악하고, 서부 리전에 해당하는 서브넷을 만들었습니다.

없을 경우 복원을 시작하기 위한 항목을 얻을 수 없는 필수 서비스를 파악합니다. 이는 인증 서버(ldap/IPA, 있는 경우), 빌드 서버 또는 모니터링 서버일 수 있습니다. 이러한 서비스는 항상 실행 중이어야 합니다. 즉 시작 및 설정한 후 어떠한 예기치 못한 상황에서도 항상 DR 리전으로 항목을 가져올 수 있도록 이러한 서비스를 계속 실행함을 뜻합니다.

또한 종속된 AWS 서비스를 사용할 수 있어야 합니다. 예를 들어 S3 버킷을 DR 리전에서 사용할 수 있어야 하고 항상 기본 리전과 동기화해야 합니다. 많은 구성, 속성 파일, 바이너리가 S3에 있기 때문에 이 단계는 중요합니다. 애플리케이션이 계속 작동되도록 하려면 DR 리전에서 이를 사용할 수 있도록 해야 합니다. 이를 위해 S3 교차 리전 복제 기능을 사용합니다. 이는 객체를 빠르고 거의 동시에 동기화하여 놀라운 작업을 수행합니다.

재해 복구 용량 계획의 그림

용량 계획

이제 규모를 고려하여 DR의 필요 용량을 알아내야 합니다.

애플리케이션 관점에서 첫 단계는 DR 리전에서 필요한 구성을 사용할 수 있는지 확인하는 것입니다. 이때 필요한 구성이란 DB별로 다른 파라미터일 수도 있고 사용자 지정된 설정 관련 파라미터일 수도 있지만, 기본적으로 애플리케이션이 작동하는 데 필요한 모든 것을 말합니다. 위 그림과 같이, 복원하는 각 파트너가 당사 DB에 저장한 속성을 토대로 다양한 서비스의 필요 용량을 파악합니다. 예를 들어 파트너 Z는 ES 클러스터 70개, MongoDB 40개, RDS 30개, SOLR 20개가 필요합니다. 다음 단계에서는 모든 서비스를 종합적으로 고려하여 특이한 것을 찾아냅니다. 파트너 간에 클러스터 DB를 공유하므로, 최초의 필요 용량에 있던 클러스터 중 일부를 실제로 다른 파트너들도 공유할 수 있기 때문입니다. 이렇게 해서 최종적인 필요 용량을 파악하고, 이를 인스턴스 유형별로 나눕니다. 위 그림과 같이 Elasticsearch 등 서비스마다 인스턴스 유형이 서로 다릅니다. 마지막으로 해당 인스턴스 유형의 총 필요 용량을 파악하는 일이 남았습니다.

첫 번째 단계가 명확해지면 ELB 및 경로 항목을 몇 개나 생성해야 하는지 알아냅니다. AWS API로 얻은 ELB 및 경로 항목 정보에 대한 메타데이터를 보유하고 있습니다. 이 정보는 서부에 항상 준비되어 있습니다. 이 방법으로 필요 용량의 정확한 수를 알아내고, 인프라를 추정합니다. 여기에는 EC2, ELB 및 경로 항목을 위한 용량 계획도 포함됩니다.

원활한 복구를 위해서는 위 단계 모두 중요하고 서로 밀접하게 관련되어 있으며, 가급적 이를 자동화하는 것이 좋습니다. 우리는 AWS API 호출을 사용한 Perl로 사용자 지정 스크립트를 작성하여 이 모든 단계를 자동화했습니다.

재해 발생 시

우선 순위 정하기

존재하는 여러 서비스 중에 가장 중요한 서비스를 기준으로 시작의 우선 순위를 정하고 서비스의 EC2 인스턴스를 시작해야 합니다. 서비스를 세 가지 세트로 나누는 것이 좋습니다. 이는 핵심적인 서비스를 쉽게 시작할 수 있도록 하기 위한 중요한 결정입니다. 우리가 피하고자 하는 주요 방해 요소는 AWS의 용량 또는 한도 문제입니다.  서비스를 나누면 API 호출 수가 적어지며, AWS가 그 시점에 보유하고 있는 티어 1 서비스에 사용 가능한 인스턴스 유형을 모두 활용할 수 있습니다. 두 번째 세트와 세 번째 세트는 다음에 시도합니다. 이러한 접근 방법의 장점은 우선 AWS API 호출을 너무 많이 사용하지 않고, 복원이 충돌하지 않는다는 것입니다. 이를 위해 다시 사용해야 할 것 같은 AWS API 호출 출력을 캐시하는 캐싱 로직을 개발했습니다. 이를 통해 API 호출 수를 50% 줄일 수 있습니다. 두 번째는 사용 가능한 용량이 대부분 가장 핵심적인 서비스에 할당된다는 점입니다.

용량에 대비한 플랜 B

당장 재해가 발생하면 원하는 인스턴스를 마음대로 시작하지 못할 수 있으므로 실행 시간 인텔리전스를 구축할 필요가 있습니다.

우선 순위가 두 번째나 세 번째인 서비스를 할 때쯤이면 사용 가능한 용량을 다 써버렸을 수도 있습니다. 따라서, 용량 한도를 이미 늘렸습니다. 그러나 어떤 인스턴스 유형은 DR 시점에 AWS에서 사용하지 못할 수 있고, 이로 인해 전체 DR 작업이 위험에 빠질 가능성이 있습니다.

이러한 위험을 완화하기 위해 플랜 B를 수립했습니다. 플랜 B가 준비되고 자동화를 통해 인텔리전스를 구축하여 동일한 패밀리의 다른 인스턴스 유형을 시작합니다. 이 인텔리전스를 구축하기 위해 AWS CloudWatch를 사용합니다. AWS CloudWatch 측정치의 정보를 사용하여 기본 리전의 인스턴스 사용량을 분석합니다. 이를 통해 현재 인스턴스 패밀리 및 유형을 사용할 수 없는 경우에 사용할 수 있는 인스턴스 패밀리 및 유형을 알아낼 수 있습니다. 다시 말해 r3.xlarge 인스턴스 유형을 사용하는 특정 서비스를 예로 들면, CloudWatch 측정치 덕분에 이 서비스가 사용하고 시작해 볼 수 있는 다음 인스턴스 유형을 정하기 위한 모든 정보를 확인할 수 있습니다.

새 인스턴스 유형을 결정하고 나면 인스턴스 개수를 계산해야 합니다. 예를 들어 r3.2xlarge에서 r3.xlarge로 한 단계 아래로 가면 용량을 두 배로 늘려야 할 수 있으며, 한 단계 위로 가면 용량을 절반으로 줄여야 할 수 있습니다. 따라서 실행 시 이를 계산해야 합니다.

다른 AWS 서비스 복원 및 시작

ELB, Route 등 EC2 이외의 서비스 시작이 이제 트리거됩니다. 기본 리전의 S3에서 동기화된 메타데이터를 사용하여 이러한 서비스를 불러옵니다. 메타데이터 정보에는 이 서비스를 시작하는 데 필요한 정보가 들어 있습니다. ELB의 경우 ELB 유형(내부 또는 외부), 인증서 정보, 연결된 서브넷, 연결된 인스턴스입니다. 경로 항목의 경우 DNS 레코드 유형과 그 값입니다.

구성을 위해 EC2 인스턴스 정보가 필요할 수 있으므로 EC2를 시작한 후 이를 시작합니다. 예를 들어 경로 항목에는 EC2 인스턴스의 퍼블릭 IP 주소 정보가 필요할 수 있습니다.

애플리케이션 복원

위 단계를 실행했으면 절반은 온 것입니다. AWS에서 리소스를 가져왔고 애플리케이션 요구 사항에 따라 이를 구성할 수 있었기 때문입니다. AWS에서 얻고자 하는 필요 용량이 대부분 처리되었습니다. 나머지는 주로 애플리케이션 및 로직과 관련이 있습니다. 코드베이스를 사용할 수 있게 준비해 두는 것과 필요 시 DR 리전에 바로 빌드를 배포할 수 있도록 하는 것도 여기에 포함됩니다.

직면한 문제 및 수정

위 모델을 구현한 후 API 호출과 관련된 몇 가지 문제에 직면했습니다. 복원 규모로 인해 엄청난 수의 API 호출이 발생했고, AWS에서는 이를 조정했습니다. API에서 보내는 막대한 정보를 캐시하기 위해 인텔리전트 캐싱 시스템을 개발했습니다. 그 결과 AWS API 호출이 처음의 4분의 1로 줄었습니다.

이 블로그 게시물에서 DR 프로세스의 계획 방식에 대한 아이디어를 얻으시기 바랍니다. DR 계획을 수립하고 주기적으로 테스트하는 것은 자연재해나 인재 발생 시 비즈니스 운영이 중단되지 않도록 하는 데 매우 중요합니다. 자세히 알아보려면 Sprinklr 웹 사이트를 방문하십시오.

이 글은 소셜 미디어 통합 관리 서비스인 Sprinklr의 책임 설계자인Senthilkumar Ramaswamy와 DevOps 책임 엔지니어 Rakesh Pillai가 작성한 AWS Startup 블로그의 Large scale disaster recovery using AWS regions의 한국어 번역입니다.

떠오르는 스타트업 소개 – 레코벨, 메쉬코리아, 블로코

AWS는 스타트업을 사랑합니다!

세상을 변화시키기 위한 열정과 창의력으로 새롭고 흥미 진진한 비즈니스 및 애플리케이션을 구축하기 위해 모인 사람들이 만든 스타트업을 위해 AWS는 다양한 프로그램을 제공하고 있습니다. 앞으로 연재로서 색 다르게 좋은 서비스로 국내외에서 주목 받고 있는 스타트업 서비스와 그들이 AWS를 어떻게 활용하고 있는 지에 대해 전해 드리고자 합니다. (해외의 주요 스타트업은 영문 블로그 시리즈를 참고하세요.)

AWS 클라우드를 통해 세상을 바꾸고 있는 떠오르는 스타트업을 소개합니다!

이번에는 아래 스타트업을 소개합니다.

레코벨은 소셜커머스나 인터넷 쇼핑몰 등 전자상거래 기업에게 상품 추천 및 개인화 마케팅 솔루션을 제공하는 기업입니다. 쉽게 설명 드리면 데이터를 활용해 기업과 고객이 원하는 서비스와 제품을 딱 찾아 맞춤형으로 제공해주는 아주 스마트한 서비스라고 할 수 있습니다. 개인화 추천 서비스, 개인화 마케팅 서비스, 그리고 키워드 광고 대행 서비스를 제공하고 있고 최근에는 뉴스 추천 서비스를 신설하게 되었습니다. 국내 약 200여개 신문사 데이터를 수집하고 분석해서 실시간으로 맞춤뉴스를 제공하고 있습니다.

이 중에도 주력 서비스는 개인화 추천 서비스인데, 쇼핑몰에 방문하는 고객 개개인 성향에 맞춰 메인 화면을 제공하고 추천 상품을 제시하는 서비스입니다. 고객이 원하는 제품을 보여주기 때문에 구매까지 성공적으로 이루어져 고객사 매출 상승으로 이어집니다.

레코벨에서는 AWS의 다양한 서비스들을 활용해서 사용자에게 서비스를 제공하고 있습니다. 데이터를 수집하여, 분석하고, 제공하는 일련의 과정들이 모두 AWS 인프라위에 올라가 있습니다. EC2, RDS 와 같은 서비스를 이용하여 기본적인 인프라를 구성하고 있으며, S3 를 이용해서 각 단계에서 나오는 데이터 산출물을 저장합니다. Full Managed Service 인 Kinesis 를 이용해서 데이터를 수집하거나, 실시간으로 분석하는데 사용합니다 Redshift 를 이용하여 추천엔진을 만들고 있습니다.

AWS의 가장 큰 장점은 적은 인원과 비용으로 확장가능한 서비스를 할 수 있다는 점입니다. 현재 레코벨에서는 2명의 개발자로 300개 이상의 사이트에 서비스를 하고 있습니다. 특히, AWS의 Kinesis, SQS, Redshift와 같은 full managed service를 이용하여 관리에 대한 부담을 줄이고, 효율적인 자원활용으로 많은 비용을 절약하고 있습니다.

레코벨의 서비스에 대한 자세한 내용은 웹사이트에서 보실 수 있습니다!

메쉬코리아는 IT 기반의 물류 스타트업입니다. ‘부릉(VROONG)’이라는 물류 브랜드를 통해 단순히 물건을 전달하는 기존 배송 서비스뿐만 아니라 정보와 정보를 연결해 새로운 가치를 창출하고 있습니다. 현재 프리미엄 배송 서비스 ‘부릉 프라임(VROONG Prime)’, 통합 물류관리 솔루션 ‘부릉 TMS(VROONG TMS)’, 프리미엄 배달 책자 ‘부릉 컬렉션(VROONG Collection)’, 신선식품 배송 서비스 ‘부릉 프레시(VROONG Fresh)’ 등의 서비스를 운영하고 있습니다.

전국 13,000여 명의 제휴 기사님들과 물류 거점이자 기사님들의 쉼터인 부릉 스테이션을 80여 개 보유하고 있으며, 연내 130여 개로 확충해 보다 정확하고 빠른 배송 서비스를 제공할 계획입니다.

특히, 자사의 IT 기술력을 총동원해 자체 개발한 통합 물류관리 솔루션 ‘부릉 TMS(VROONG TMS)’는 4차 산업혁명의 핵심 기술 중에 하나인 빅데이터 분석과 클라우드 기술 등을 적용해 물류 업계에서 혁신을 일으키고 있습니다. 배송기사들의 배송 패턴을 스스로 학습해 정교한 배송경로 제안이 가능하며, 국내 최초 클라우드 방식의 TMS로 초기 도입 비용이 낮으며 도입후에도 별도의 유지 보수 및 업그레이드 비용이 없다는 점이 특장점입니다.

메쉬코리아에서는 다양한 AWS 서비스를 사용하고 있습니다. EC2, RDS, S3는 모든 서비스에서 유용하게 사용하고 있으며, 캐쉬 및 빠른 데이터 접근을 위해 일부 서비스에서는 ElasticCache를 사용하고 있습니다. 서비스간의 통신들은 최근 SQS를 이용해 Queue 기반의 통신을 늘려가고 있는 상황입니다. 배송 트래픽의 경우 하루 중에도 시간 별로, 요일별로도 차이가 많이 나는데 EC2, ELB, Scaling Group을 이용하여 탄력적으로 시스템 자원을 관리하여 비용을 많이 절감하고 있습니다.

또한 Log 관리를 위해 ElasticSearch 서비스를 이용하고 있는데, 기존에 ElasticSearch를 직접 활용할 때보다 Managed Service를 사용하게 되어 관리 비용이 많이 줄어든 바 있습니다. 현재 ElasticSearch와 더불어 기능이 더 좋아지고 있는 Cloudwatch Log도 테스트 해보고 있습니다.

전반적인 서비스 모니터링엔 CloudWatch Dashboard와 SNS를 사용하고 있습니다. 회사 내 여러 서비스에 대한 지표들을 한눈에 바라볼 수 있게 만든 Dashboard를 사무실 중간에 띄워 놓고 언제나 볼 수 있도록 사용하고 있고, 혹시나 모를 장애 알람이나 경고 메시지를 Cloudwatch Alert + SNS + Lambda + Slack을 이용하여 Slack에서 실시간으로 받아보고 있습니다.

최근 메쉬코리아에서 Microservice Architecture로의 전환이 활발하게 이뤄지고 있는데요, 그에 따라 Cloud Formation이나 Code Deploy 사용을 조금씩 늘려가고 있습니다. 간단한 어플리케이션 배포를 위해서 Elastic Beanstalk도 활발히 사용하고 있습니다.

AWS의 가장 큰 장점은 물리 환경에서는 엄청나게 많은 인력과 시간이 들 작업을 단 몇 분, 몇 시간만에 Console 환경을 통해 빠르게 설정할 수 있다는 점으로 생각합니다. 또한 많은 서비스들을 Managed Service로 지원해주면서 쉽게 놓칠 수 있거나 관리하기 힘든 백업, HA 구성 등을 손 쉽게 구성할 수 있도록 도와주어서 다른 중요한 것에 더 집중 할 수 있도록 해줘 만족하면서 사용 중입니다.

메쉬코리아의 서비스에 대한 자세한 내용은 웹사이트에서 보실 수 있습니다!

블로코는 블록체인 기술을 현실화 시키는 기업입니다. 블록체인 개발 플랫폼인 ‘코인스택’을 통해 블록체인 기술을 도입하는데 가장 큰 걸림돌이었던 높은 기술/비용 장벽을 해결합니다. 금융. 사물인터넷(IoT). 제조. 공공 서비스 등 다양한 분야의 기업과 공공기관이 코인스택을 활용해 블록체인 기반 서비스를 구축하고 있습니다.

블로코는 이미 국내 주요 금융/카드사들과 함께 블록체인 기반 기술을 구축했으며, 국내 블록체인 최다 레퍼런스 기업으로 부상했습니다. 또한 국내 최초로 블록체인 플랫폼 GS인증을 획득하며 블록체인 기반 생체인증/전자문서 인증 상용화, 블록체인 기반 장외주식 서비스 상용화 등 국내 블록체인 시장을 이끌어가고 있습니다.

블록체인 기술은 기존 중앙집중식 플랫폼/서비스에 비해 높은 보안성과 낮은 비용 등의 장점을 갖춰 금융권을 시작으로 기존 비즈니스 프로세스를 완전히 바꿀 새로운 패러다임으로 떠올랐습니다. 하지만 이를 도입하는 과정이 복잡하고, 까다로운 설계 프로세스와 많은 자원을 요구하는 까닭에 많은 기업이 도입에 어려움을 겪고 있습니다. 블로코는 이러한 문제점을 개선하여 안전한 블록체인 생태계의 확장을 목표로 하며, 이 과정에서 AWS의 서비스를 최대한 활용하고 있습니다. 블로코는 AWS의 Amazon EC2, EBS를 이용하여 블록체인 노드를 구성하고 ELB, Router53 를 이용하여 기본적인 네트워크 인프라를 구성하고 있습니다. 블로코 홈페이지 역시 Amazon S3와 Amazon CloudFront 를 기반으로 운영하고 있습니다.

블로코의 서비스에 대한 자세한 내용은 웹사이트에서 보실 수 있습니다!

“AWS는 클라우드 기반으로 성공적인 비즈니스를 향해 나아가는 스타트업들을 위해 AWS를 시작하는 데 필요한 리소스를 제공하는 AWS Activate라는 스타트업 지원 프로그램을 운영하고 있습니다. 스타트업 지원에 대한 궁금한 점은 언제든지 알려주시기 바랍니다.”

–  박세정, AWS코리아 스타트업 비지니스 개발 매니저;

Startup Kit Serverless Workload 예제 프로그램 소개

“AWS를 시작하는 가장 쉬운 방법은 무엇입니까?”라는 질문을 흔히 받습니다. AWS Elastic Beanstalk 등을 이용해 시작하는 좋은 방법이 여러 가지 있지만, 서버리스 컴퓨팅 역시 좋은 대안으로 급부상하고 있습니다.

서버리스 컴퓨팅은 서버에 대해 신경 쓰지 않고도 어플리케이션 및 서비스를 구축하고 실행할 수 있도록 해줍니다. AWS Lambda 서비스는 AWS에서의 서버리스 컴퓨팅을 구성하는 가장 핵심 빌딩 블록입니다. 이 외에도 AWS는 서버리스 아키텍처를 지원하는 여러 가지 서비스를 제공합니다. 여기에는 Lambda와 함께 RESTful API를 생성 할 수 있는 Amazon API Gateway와 데이터베이스 클러스터 설정으로부터 자유로운 NoSQL 클라우드 데이터베이스 서비스인 Amazon DynamoDB가 포함됩니다.

다음 도표는 하나의 완전한 서버리스 아키텍처를 나타냅니다:

serverless-arch

다이어그램의 아래쪽 서비스 그룹은 RESTful API 서비스를 구현합니다. API Gateway는 API 요청 및 응답을 처리하여 비즈니스 논리를 구현하는 Lambda 함수에 매핑합니다. DynamoDB는 지속적인 계층입니다. 다이어그램의 맨 위에 있는 서비스 그룹은 프론트 엔드를 형성합니다. Amazon S3는 AngularJS 또는 React 앱과 같은 정적 웹 자산을 호스팅하며 프론트 엔드 서버를 실행할 필요가 없는 완전 관리형 서비스입니다. S3 앞단에는 전 세계 사용자들과 가까운 엣지 로케이션(edge location)에서 웹 콘텐츠를 효율적으로 전달하기 위한 콘텐츠 전달 네트워크(CDN)인 Amazon CloudFront가 있습니다.

최근까지 서버리스 어플리케이션을 구현할 때 고려해야 할 사항 중 하나는 효율적으로 배포하는 방법이었습니다. 이제는AWS의 고유 솔루션인 AWS SAM(Serverless Application Model)이 이 문제를 해결해 줍니다. AWS SAM을 사용하면 간단한 YAML 기반 설명 언어와 단 2 개의 AWS CLI 명령을 사용하여 서버리스 배포를 쉽게 관리할 수 있습니다. AWS를 시작하는데 있어 서버리스 아키텍처를 구축하는 것이 가장 쉬운 방법일 수 있습니다. 특히 인프라 관리에 익숙하지 않은 사용자에게는 더욱 그렇습니다.

이 글에서는 AWS Startup Kit을 소개합니다. Startup Kit은 AWS를 시작하는 방법에 대한 지침을 제공하며 스타트업에서 흔히 사용하는 기술을 도입한 워크로드의 예제를 포함합니다. “워크로드”는 고객에게 노출된 RESTful API, 분석을 위한 일괄 처리 작업 등과 같이 비즈니스 또는 운영 가치를 제공하는 AWS에서 실행되는 하나 이상의 관련 어플리케이션을 말합니다.

Startup Kit 구성 요소는 Startup Kit Serverless Workload입니다. Lambda Node.js 4.3 런타임을 사용하여 빌드되고 SAM과 함께 배포되는 TODO 어플리케이션의 샘플 RESTful API입니다. Github의 startup-kit-serverless-workload저장소에서 코드를 확인할 수 있습니다. AWS 계정을 아직 설정하지 않았다면 AWS 계정을 설정하고 AWS CLI를 설치해야 합니다(자세한 내용은 여기에서 확인하실 수 있습니다).

서버리스 아키텍처의 이점
서버리스 아키텍처를 사용하면AWS Well-Architected framework의 많은 이점을 얻을 수 있습니다. Well-Architected Framework에 대한 자세한 내용은 본 포스팅의 범위를 벗어나지만, 간략하게 프레임워크에 해당하는 5개의 요소가 아키텍처에 어떻게 적용되는지 살펴 보겠습니다. 다음 요약 차트에서 “HA”는 고가용성(High Availability)을 의미하며 “OS”는 운영 체제 (Operating System)이며 “IAM”은 AWS 서비스 및 자원에 대한 액세스를 안전하게 제어 할 수 있는 AWS Identity and Access Management service를 의미합니다.

API Gateway Lambda DynamoDB
보안 기본 설정값: HTTPS
호출의 대역폭 조절 가능
IAM 또는 무기명 토큰 인증을 사용하여 API 콜 보안
AWS 관리형 OS
Lambda 함수의 다른 AWS 리소스에 대한 액세스는 이에 할당된 IAM 역할로 제한
IAM은 DynamoDB 리소스에 대한 세분화된 액세스 제어 제공 DynamoDB호출은 AWS CloudTrail을 사용하여 추적 가능
신뢰성 AWS 관리형 HA와 확장성
별도로 지정하지 않는 한 API 콜은 제한 안됨
AWS 관리형 HA와 확장성
실패한 비동기 호출이 재시도 되고 데드 레터 큐(DLQ)에 저장
AWS 관리형 HA와 확장성
데이터는 AWS 리전에 세 번 복제
성능 효율 결과 캐시 활성화 가능
서버리스 리소스는 필요할 때만 소비.
서버리스 리소스는 필요할 때만 소비 서버리스 리소스는 필요할 때만 소비.
비용 최적화 API 호출을 라우팅하기 위해 역방향 프록시 플릿 실행 필요 없음 함수 수행 중에만 비용 발생; 미 작동시에 비용 없음 Cluster 관리 없음
하드웨어 용량 예측 필요 없음
운영 효율성 SAM과 자동화
API 버저닝과 배포의 쉬운 관리
기본 매트릭스 제공; 로깅 활성화
SAM과 자동화
람다 콘솔에 기본 매트릭스 제공
Lambda 콘솔에서 링크로 로그 액세스 혹은 Amazon CloudWatch 콘솔 직접 이동
SAM과 자동화
DynamoDB 콘솔에 기본 매트릭스 제공
DynamoDB 스트림으로 테이블  변화에 대한 트래킹 가능

위 표는 Well-Architected framework의 가장 기초 사항에만 해당됩니다. AWS에서 서버리스 아키텍처를 구축해 나가면서 아키텍처를 개선할 추가 고려 사항 및 방법에 대해서는 Well-Architected Framework 백서를 참조하십시오.

워크로드 도입을 위해 SAM사용하기
SAM은 서버리스 어플리케이션을 정의하기 위한 모델입니다. SAM을 사용하려면 템플릿 파일에서 YAML (또는 JSON)로 서버리스 자원을 설명하고 두 개의 AWS CLI 명령을 사용하여 코드를 패키징 및 배포하십시오. SAM 자체는 오픈 소스 프로젝트이며 GitHub에서 사용할 수 있습니다. SAM은 “함수”(Lambda사용), “API”(API Gateway 사용) 및 “SimpleTable”(DynamoDB 사용)의 세 가지 기본 서버리스 자원을 지원합니다.

또한, SAM은 함수(예 : API)의 이벤트 소스 및 함수의 환경 변수와 같은 속성을 지정할 수 있습니다. SAM 템플릿을 더 단순화하려면 API를 함수의 이벤트 소스로 지정하세요. 그렇게 하면 SAM에서 명시적으로 API 리소스를 선언할 필요가 없습니다. 아래의 SAM 템플릿은 함수 리소스를 지정하는 것이 얼마나 간단한지 보여줍니다. 첫 번째 함수 인 CreateFunction은 TODO 응용 프로그램의 DynamoDB 테이블에서 새 TODO 항목을 만들기 위해 API 호출을 구현합니다.

서버리스 어플리케이션의 나머지 부분에 대한 CreateFunction의 관계는 SAM 템플릿에 완전히 지정됩니다. 예를 들어, CreateFunction이 DynamoDB 테이블과 상호 작용하는 방법을 지정하기 위해 템플릿은 DynamoDB 쓰기 권한을 포함하는 IAM 정책 인 CreateFunction과 연관되며 DynamoDB 테이블을 참조하는 환경 변수도 지정합니다. API 이벤트는 CreateFunction을 호출하기 위해 지정됩니다. 이 이벤트는 경로 및 HTTP 메소드(이 경우 POST)로 설명됩니다. SAM 템플리트의 다른 기능은 모두 동일한 기본 패턴을 따릅니다

YAML
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: RESTful API for a TODO app, backed by a SimpleTable (DynamoDB) resource.

Resources:
  
  CreateFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.create
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        PostResource:
          Type: Api
          Properties:
            Path: /todo/new
            Method: post

  GetAllFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.getAll
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBReadOnlyAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /todo/all
            Method: get

  # API functions related to active TODO items
  
  GetActiveFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.getActive
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBReadOnlyAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /todo/active
            Method: get

  UpdateActiveFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.updateActive
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        PutResource:
          Type: Api
          Properties:
            Path: /todo/active
            Method: put

  # API functions related to completed TODO items
  
  GetCompleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.getComplete
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBReadOnlyAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /todo/complete
            Method: get

  MarkCompleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.markComplete
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        PutResource:
          Type: Api
          Properties:
            Path: /todo/complete
            Method: put

  DeleteCompleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.deleteComplete
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        DeleteResource:
          Type: Api
          Properties:
            Path: /todo/complete
            Method: delete

  Table:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
         Name: todo_id
         Type: String
      ProvisionedThroughput:
         ReadCapacityUnits: 5
         WriteCapacityUnits: 5

시작하기 전에, AWS CLI를 설치하거나 이전에 설치한 버전을 업데이트하세요. 본 포스팅에 사용된 일부 명령은 이전 버전의 AWS CLI에 없을 수 있습니다. AWS CLI와 연결하는 IAM 사용자는 IAM 역할을 생성하는 기능을 포함하는 관리자 권한이 있어야 합니다. Startup Kit Serverless Workload 배포를 시작하려면 GitHub에서 코드의 zip 파일을 다운로드하거나 다음 명령을 사용하여 GitHub 리포지토리를 복제하세요.

git clone https://github.com/awslabs/startup-kit-serverless-workload.git

배포를 계획중인 AWS 리전에서 SAM이 배포 아티팩트(Artifacts)를 넣을 수 있는 기존 Amazon S3 버킷을 가지고 있는지 확인하거나 다음 AWS CLI 명령을 사용하여 새로운 버킷을 만듭니다:

aws s3 mb s3://<your-bucket-name>

다음으로, 간단히 두 개의 AWS CLI 명령을 실행하면 됩니다. 첫 번째 명령인 package의 경우 s3-bucket 인수를 S3 버킷의 이름으로 바꿉니다. 두 번째 명령인 deploy의 경우 template-file 인수를 출력 템플릿 파일의 전체 경로로 바꿉니다.

aws cloudformation package \
--template-file serverless.cfn.yml \
--output-template-file serverless-xfm.cfn.yml \
--s3-bucket <your-bucket-name>
aws cloudformation deploy 
--template-file <path-to-file/serverless-xfm.cfn.yml> \
--stack-name StartupKitServerless \
--capabilities CAPABILITY_IAM

Deploy 명령이 완료되었다고 표시되면, 작업 워크로드가 실행 중인 겁니다! 이 두 명령은 SAM으로 작업할 때 배포 워크 플로(work flow)의 핵심입니다. 예를 들어, 코드를 수정하고 변경 사항을 배포하려는 경우, 패키지를 실행하고 명령을 다시 배포하기 만하면 됩니다. 그런 다음, 워크로드를 테스트하려면 API의 호출 URL을 가져옵니다.다음 bash 코드를 복사하여 터미널에 붙여 넣어 다른 지역 (예 : us-east-1)의 AWS 지역 코드 “us-west-2″를 현재 지역으로 바꾼 다음, 반환하시면 됩니다:

x=`aws cloudformation list-stack-resources --stack-name StartupKitServerless | grep -A2 'AWS::ApiGateway::RestApi' | grep 'PhysicalResourceId' | awk '{print $2}' | tr -d '"' | tr -d ","`; echo "https://$x.execute-api.us-west-2.amazonaws.com/Stage/"

(호출 URL를 가져오는 다른 방법으로는 API Gateway console에서 StartupKitServerless를 선택하고, 왼쪽 탐색 창에서 스테이지를 선택한 다음, 스테이지 목록에서 스테이지를 선택하면, API의 호출 URL이 이제 오른쪽 상단에 나타납니다. 마지막 URL에 ‘/ Stage’를 포함하여 전체 URL을 복사하면 됩니다.) ‘Create API’를 사용하여 일부 TODO 항목을 추가하여 테스트를 시작하세요. 그러면 다음 명령을 사용하여 수행할 수 있습니다:

curl -X POST -H 'Content-Type: application/json' -d '{"todo_id": "1001", "active": true, "description": "What TODO next?"}' https://<invoke-URL-for-your-API>/todo/new

작성한 활성 TODO 항목을 가져 오려면 다음 명령을 실행하세요:

curl https://<invoke-URL-for-your-API>/todo/active

유사한 명령을 사용하여 다른 모든 API 호출을 테스트할 수 있습니다.

AWS SAM 및 서버리스 아키텍처를 사용하는 것은 AWS를 시작하는 가장 쉬운 방법 중 하나입니다. Startup Kit Serverless Workload에 관한 제안, 의견 또는 수정 사항이 있으면 GitHub에 요청해주세요. 앞으로 더 많은 Startup Kit으로 찾아 뵙겠습니다!

이 글은 Introducing the ‘Startup Kit Serverless Workload’의 한국어 번역으로 이창수 AWS 솔루션즈 아키텍트가 번역해 주셨습니다.

떠오르는 스타트업 소개 – 원티드, 뱅크샐러드 및 아자르

AWS는 스타트업을 사랑합니다!

세상을 변화시키기 위한 열정과 창의력으로 새롭고 흥미 진진한 비즈니스 및 애플리케이션을 구축하기 위해 모인 사람들이 만든 스타트업을 위해 AWS는 다양한 프로그램을 제공하고 있습니다. 앞으로 연재로서 색 다르게 좋은 서비스로 국내외에서 주목 받고 있는 스타트업 서비스와 그들이 AWS를 어떻게 활용하고 있는 지에 대해 전해 드리고자 합니다. (해외의 주요 스타트업은 영문 블로그 시리즈를 참고하세요.)

이번에는 우선 아래 스타트업을 소개합니다.

  • 원티드 (원티드랩) – 지인추천 기반 채용 서비스
  • 뱅크샐러드 (레이니스트) – 금융비교 추천 서비스
  • 아자르(하이퍼커넥트) – 소셜 디스커버리 앱

원티드(원티드랩) – 지인추천 기반 채용 서비스
원티드랩은 지인추천 기반의 채용서비스 원티드를 운영하고 있습니다. 오프라인에서 알음알음 이뤄지는 지인 추천 및 헤드헌팅 사업모델을 모바일로 구현했습니다. 지인을 추천하고 채용되면 추천인/합격자는 100만원 이상의 보상을 받을 수 있습니다. 2017년 5월 현재까지 2년간 1,000개 이상의 기업고객(AWS, 페이스북, 넥슨, SKT, 이베이, 라쿠텐 등)을 확보하고 월 60~100명의 채용 성사(국내 Top 5 서치펌 수준)가 이루어 집니다. 기업으로부터 채용 성공 수수료를 받아, 일정 부분을 추천인/합격자에게 제공하고 있습니다.

http://cdn.besuccess.com/wp-content/uploads/2016/02/Wantedinside.png

지인들의 추천 네트워크를 통해 그 일에 잘 어울리는 사람에게 빠르게 노출할 수 있고, 지인의 추천을 통해 콜드콜이나 광고보다 더 설득력 있게 전달합니다. 기존 헤드헌팅 대비 50% 이상 경제적인 비용으로 채용이 가능하고, 6만건 이상의 합격, 불합격 데이터를 학습한 인공지능(AI)을 통해, 성공률 높은 매칭 제공하고 있습니다.

원티드랩에서는 AWS의 다양한 기술을 활용해서 사용자에게 서비스를 제공하고 있습니다. Amazon EC2, ELB, RDS, ElastiCache 를 이용해서 기본적인 인프라를 구성하고 있으며, Amazon S3를 이용해서 이미지와 사용자 컨텐츠를 저장하고 있습니다. AWS Certificate manager에서 발급 받은 인증서를 Amazon CloudFront 에 붙여 사용함으로써 저렴한 비용으로 SSL 환경을 유저에게 제공하고 있습니다.

Amazon S3에 이벤트가 발생하거나 API Gateway로 요청이 발생 하였을 때, AWS Lambda를 이용해서 문서와 텍스트에 대해서 데이터 분석을 위한 전처리를 하고 있으며, 채용 기업들의 뉴스와 같이 주기적으로 필요한 외부 데이터 수집을 하고 있습니다. AWS의  완전 관리 서비스인 Elasticsearch에 분석용 데이터를 축적하고 이를 기반으로 개인화된 서비스를 제공하고 있고, CloudWatch를 이용해서 추가적인 모니터링 환경을 구성하지 않고 안정적인 인프라 모니터링을 하고있습니다.

AWS의 가장 큰 장점은 적은 인원과 비용으로 HA 구성, 인프라 관리를 할 수 있다는 점입니다. 현재 한국과 일본 등에 글로벌 서비스를 제공하고 있는 원티드랩은 AWS의 다양한 global region을 이용해서 손쉽게 글로벌 서비스로 확장 할 수 있었습니다. 특히, AWS의 API Gateway, Lambda와 같은 AWS의 완전 관리형 서비스를 이용하여 관리에 대한 부담을 줄이고, 효율적인 자원활용으로 많은 비용을 절약하고 있습니다. 플랫폼이 주는 기술적인 장점 외에도 AWS 한국/일본팀 및 커뮤니티 협력을 통해서 우수한 클라우드 엔지니어들을 국내외 최고의 IT 기업들의 채용과 연결해 주는 것을 기대하고 있습니다.

원티드 웹사이트에서 채용 정보를 확인하세요!

뱅크샐러드(레이니스트) – 금융비교 추천 서비스
레이니스트는 금융에 존재하는 정보의 비대칭성을 해결해 더 나은 의사 결정을 돕는다는 미션 아래에 뱅크샐러드를 운영하고 있습니다. 뱅크샐러드는 금융상품 선택부터 관리까지, 사용자의 금융 생활을 책임지는 개인 금융 관리 서비스입니다. 국내 최대 규모의 금융상품 데이터를 기반으로 개인별 최적의 금융상품을 추천해 주는 뱅크샐러드 웹 서비스를 운영하며, 각종 금융상품을 한 곳에서 모니터링하고 지출과 수입을 관리할 수 있는 혁신적인 가계부 앱 서비스 또한 제공하고 있습니다.

뱅크샐러드는 서비스 출시 이후 끊임없이 사용자를 만나며 발전하고 있으며, 꾸준한 성장을 바탕으로 현재는 국내 최고의 금융 상품 추천 서비스로 자리매김하고 있습니다.

레이니스트는 AWS를 적극적으로 활용하여 뱅크샐러드를 운영하고 있습니다. 이를 통해 레이니스트는 인프라 운영 및 관리에서 오는 비용을 최소화할 수 있었으며, 뱅크샐러드의 핵심 가설에 집중할 수 있었습니다.

레이니스트는Amazon EC2, Amazon S3, Amazon CloudFront, Amazon RDS를 활용하여 뱅크샐러드 서비스에 필요한 서버 환경을 손쉽게 구축할 수 있었으며, Amazon Redshift, Amazon Data Pipeline, Amazon Athena를 활용하여 데이터 분석 환경을 손쉽게 구축할 수 있었습니다.

레이니스트뱅크샐러드에 대한 더 자세한 내용은 웹사이트에서 확인하세요!

아자르(하이퍼커넥트) – 글로벌 영상 메신저
하이퍼커넥트는 비디오 & 소셜네트워킹 분야의 테크 스타트업입니다. 시간, 언어, 공간의 제약을 넘어 인류 개개인의 도달 가능한 인간관계를 전 세계로 넓힌다는 미션을 갖고, 기술을 통해 문화, 인종, 국적, 종교의 차이로 인한 거리를 좁힐 수 있는 길을 만들어가고 있습니다.

동영상 기반 소셜 디스커버리 플랫폼 아자르(Azar)는 WebRTC 기술을 모바일에 최초로 적용한 사례로, 현재 전 세계 200여 개 국가에서 폭넓게 인기를 얻으며 200억 회에 달하는 누적 매치를 기록하고 있습니다.

아자르는 손가락으로 화면을 넘길 때마다 새로운 친구들을 만나 실시간으로 영상 대화를 나눌 수 있는 앱으로, 일상에서 접할 기회가 없었던 새로운 국가의 친구들과 직접 소통하며 서로의 문화와 언어에 대해 배울 수 있는 것이 특징입니다. 하이퍼커넥트는 아자르 앱을 통해 만난 사람들이 보다 쉽게 소통할 수 있도록 돕는 새로운 기술 개발에도 지속적으로 투자해 왔습니다.

영상 대화 중 실시간으로 사용자의 얼굴을 인식해 움직이는 스티커(액티콘 Acticons)를 도입해 서로 처음 만난 사용자들이 쉽게 어색함을 덜 수 있게 했고, 사용자의 음성을 인식해 상대방의 언어로 번역해주는 실시간 음성 통역 기능을 개발, 이종언어 사용자들이 언어 장벽 없이 의미있는 대화를 나눌 수 있도록 돕고 있습니다.

하이퍼커넥트는 영상 대화가 이뤄지는 동시에 적용되는 이같은 복잡한 기술과 전 세계 곳곳에서 동시에 발생하는 동영상 트래픽을 안정적으로 운영하고, 일 4천만 회의 매치에서 생성되는 방대한 양의 데이터를 효율적으로 관리하기 위해 AWS의 다양한 서비스를 활용하고 있습니다. Amazon EC2, Amazon RDS, Amazon SES 등을 통해 인프라 관리 비용을 절감하고 있으며, Amazon S3를 도입해 서비스 데이터를 저장하고 있습니다. 또한 아자르 관련 분석 데이터를 가공하고 사용하기 위해 Amazon Redshift, Amazon EMR 등을 활용하고 있습니다.

하이퍼커넥트아자르에 대한 더 자세한 내용은 웹사이트에서 확인하세요!

AWS는 위의 업체처럼 클라우드 기반으로 비즈니스 성공을 향해 나아가는 스타트업들과 이에 투자하는 액셀레이터, 벤처캐피털를 위해 AWS를 시작하는 데 필요한 리소스를 제공하기 위해 설계된 AWS Activate 스타트업 지원 프로그램을 운영하고 있습니다. 스타트업 지원에 대한 궁금한 점은 언제든지 알려주시기 바랍니다.

–  박세정, AWS코리아 스타트업 비지니스 개발 매니저;