Category: Customer Cases


AWS Step Functions를 통해 서비스 플로우 개선 – 코카콜라 지불 서비스 사례

Amazon의 혁신 문화에 대한 프레젠테이션을 할 때가 많은데 이때마다 Amazon 창업자인 Jeff Bezos의 말을 인용한 슬라이드로 시작합니다.

고객과 함께 머리를 맞대고 앉아 우리가 어떻게 그들의 창의성을 강화시켰는지 알아보고, 함께 새로운 꿈을 추구하는 것을 좋아합니다. 올해 초에 AWS Step Functions 및 기타 AWS 서비스를 사용하여 Coke.com Vending Pass 프로그램을 지원한 방법을 알아보기 위해 Coca-Cola Company의 Patrick과 대화를 나눈 적이 있습니다.

이 프로그램에는 Coca-Cola Vending Pass를 사용하여 모바일 결제를 지원할 수 있는 기능을 갖춘 자동 판매기에서 제품을 구매하여 얻은 음료 보상이 포함됩니다. 참가자는 자신의 NFC 지원 휴대폰을 갖다 대서 Apple Pay 또는 Android Pay 구매를 완료함으로써 자동 판매기에서 자신을 식별하고 향후 무료 자동 판매기 구매를 위한 크레딧을 획득할 수 있습니다.

AWS SNS 토픽과 AWS Lambda 기능의 조합을 통해 기존 백엔드 코드 중 일부에 대한 한 쌍의 호출을 시작하여 자동 판매기 포인트를 계산하고 참가자의 레코드를 업데이트했습니다. 그러나 백엔드 코드는 반응이 느리고 시간 종속성이 있어 Vending Pass 참가자에게 혼동을 줄 가능성이 있는 업데이트 누락이 발생할 수 있었습니다. 이 문제에 대한 초기 해결책은 매우 간단했습니다. 즉, 두 호출 사이에 90초 지연을 포함하도록 Lambda 코드를 수정하는 것이었습니다. 이것으로 문제는 해결되었지만 아무 이유도 없이 프로세스 시간을 소비했습니다(Lambda 함수 사용에 대한 요금 청구는 100ms 간격으로 요청 기간을 기반으로 함).

솔루션을 보다 비용 효율적으로 만들기 위해 팀은 AWS Step Functions를 사용하여 매우 간단한 상태 시스템을 구축했습니다. 이전 블로그 게시물에 썼듯이 Step Functions는 구축하기 쉬운 시각적 워크플로를 사용하여 분산 애플리케이션 및 마이크로서비스의 구성 요소를 규모에 따라 조정합니다.

Coke는 매우 간단한 상태 시스템을 구축하여 비즈니스 로직을 간소화하고 비용을 절감했습니다. 사용자는 동등하게 간단하거나 순차 및 병렬 실행 등의 기타 Step Function 기능과 의사를 결정하고 대체 상태를 선택할 수 있는 기능을 사용할 수 있습니다. Coke 상태 시스템은 다음과 같습니다.

FirstStateSecondState 상태(작업 상태)는 Step Functions가 90초 지연(대기 상태)을 구현하는 동안 적절한 Lambda 함수를 호출합니다. 이 수정 사항을 통해 로직을 간소화하고 비용을 절감했습니다. 함께 정상적으로 작동되는 방식은 다음과 같습니다.

다음 단계
이 초기 성공으로 인해 서버리스 컴퓨팅에 대해 자세히 알아보고 다른 프로젝트에 이 서버리스 컴퓨팅의 사용을 고려하게 되었습니다. Patrick은 생산성의 향상과 개발자의 행복을 이미 실현했다고 말했습니다. 개발자는 더 이상 서버를 프로비저닝할 때까지 기다릴 필요가 없으며 이제 (Jeff의 말처럼) 자신의 창의성을 발휘하고 자신의 꿈을 추구할 수 있습니다. 그들은 Step Functions를 사용하여 애플리케이션의 확장성, 기능성 및 안정성을 향상시킴으로써 Coca-Cola Vending Pass의 초기 사용을 훨씬 능가할 것으로 예상합니다. 예를 들어 Coke는 Lambda, Step Functions, API Gateway를 사용하여 영양 정보를 식품 서비스 파트너에게 게시할 수 있는 서버리스 솔루션을 구축했습니다.

Patrick과 그의 팀은 이제 기계 학습 및 인공 지능을 실험하고 있습니다. 그들은 프로토타입 애플리케이션을 구축하여 Instagram의 사진 스트림을 분석하고 맛과 향미의 추세를 추출했습니다. 애플리케이션(빠른 1일 프로토타입으로 구축)은 Lambda, Amazon DynamoDB, Amazon API Gateway, Amazon Rekognition을 사용했으며 Patrick의 말에 따르면 “큰 승리이자 조력자”였습니다.

서버리스 애플리케이션을 보다 신속하게 구축하기 위해 개발 팀은 서버리스 애플리케이션 프레임워크를 기반으로 하는 내부 CI/CD 참조 아키텍처를 생성했습니다. 이 아키텍처에는 내부 서비스 및 자산에 액세스할 수 있는 몇 가지 보일러플레이트 코드와 서버리스의 가이드 투어가 포함되어 있습니다. Patrick은 이 모델을 통해 유망한 프로젝트를 “컴퓨터를 가진 사람”에서 전체 개발 팀으로 쉽게 확장할 수 있다고 말했습니다.

AWS re:Invent에서 제 동료인 Tim Bray 다음으로 Patrick이 무대에 오를 예정입니다. 직접 만나기 위해서는 SRV306 – 현장에서의 상태 시스템! 고객이 AWS Step Functions를 사용하는 방법에 참석하시기 바랍니다.

참고) 2016년 AWS re:Invent에서 Cocacola가 직접 발표한 세션 동영상도 참고하시기 바랍니다.

Jeff

이 글은 Things Go Better With Step Functions의 한국어 번역입니다.

AWS 활용한 Amazon Prime Day 2017 성공 사례

올해로 세번째 맞는 지난 7월 11일 프라임 데이(Prime Day) 매출은 블랙 프라이데이(Black Friday)와 사이버 먼데이(Cyber ​​Monday)를 앞지르는 또 다른 신기록을 세웠으며, 아마존 소매 역사상 기념비적인 행사가 되었습니다. 30시간 행사 기간 동안 Prime 회원 수천만명이 Echo Dots, Fire 태블릿, 압력 쿠커, 에스프레소 머신, 충전식 배터리 등 다양한 제품들을 구입했습니다. 당일 수십만개의 저렴한 상품을 구매를 이용하기 위해 가입한 새로운 Prime 멤버십 회원수에 대한 기록도 세웠습니다. 아마존 고객은 주문을 위해 웹 사이트 뿐만 아니라 모바일 앱을 많이 사용했으며, 지난 프라임 데이 2배 이상의 모바일 주문이 있었습니다.

Powered by AWS
작년에 AWS가 Amazon의 가장 큰 이벤트를 어떻게 운영했는지에 대해 소개하면서, AWS 팀이 서버 준비, 자동화, 모니터링 등에 배웠던 것을 공유했습니다. 작년에 공유한 내용 모두 올해에도 해당되지만, 이번에 새로운 우수 사례 몇 가지를 소개하겠습니다.

작년 프라임데이가 끝나고 며칠만에 모범 사례를 수집 공유할 뿐만 아니라, 개선을 위한 부분을 확인하고 미리 프로세스 감사 및 게임 데이를 통한 테스트를 준비하였습니다.

  • 프로세스 감사 – 프로세스 감사는 큰 이벤트에 앞서 준비 사항을 추적하고, 위험을 식별하고, 목표에 대한 진행 상황을 추적 할 수있는 공식적인 방법입니다. 각 서비스 팀은 준비 상태를 결정하는 데 도움이되는 일련의 상세한 기술 및 운영 질문에 응답해야 합니다. 기술 측면에서는 CNAME의 TTL(Time to Live)에 대한 중요한 검사를 포함하여 데이터베이스 장애가 발생한 후 복구 시간에 대한 질문도 있습니다. 운영 측면에서는 현장 담당 통화 직원, 비상 연락망 및 서비스 및 인스턴스 소유권에 대한 확인 등을 포함합니다.
  • 게임 데이 (GameDay) – 전 아마존 직원 제시 로빈스(Jesse Robbins)가 처음 시작한 이 모범 사례는 컴퓨팅 용량 계획 및 준비를 검증하고 필요한 모든 운영 방식이 예상대로 작동하는지 확인하기 위한 테스트 이벤트입니다. 시뮬레이션 중 이슈가 있는 경우, 팀이 문제를 빨리 식별하고 신속하게 해결하고 과정에서 문제 해결을 훈련시키는 데 도움이됩니다. 또한, 장애 조치 및 복구 기능을 테스트하고 숨어있는 잠재된 결함을 노출 할 수 있습니다. 게임 데이는 각 서비스팀이 확장 과정(페이지 뷰, 주문 등)를 이해하도록 돕고 테스트 할 수있는 기회를 제공합니다. 좀 더 자세한 사항은 Resilience Engineering: Learning to Embrace Failure 문서나 GameDay: Creating Resiliency Through Destruction 동영상을 참고하시기 바랍니다.

2017 프라임 데이 통계
올해의 운영 결과에 대해 아마존닷컴을 담당하는 AWS 팀이 대시 보드 및 로그 파일을 확인하고, 주목할 만한 통계치를 공유해 주었으며, 아래는 몇 가지 흥미로운 지표입니다 :

  • 블록 스토리지Amazon Elastic Block Store (EBS)의 사용량은 전년 대비 40 % 증가했으며 데이터 전송량은 52 페타 바이트 (50 % 증가)로 증가했으며 총 I/O 요청은 8 억 3500 만 개로 증가했습니다. (30 % 증가). 빠른 EBS의 탄력성 덕분에  프라임 데이 (Prime Day)가 끝나고 나서도 용량이 줄어들지 않았습니다.
  • NoSQL 데이터베이스 – Alexa, Amazon.com 사이트 및 Amazon Fulfillment 센터의 Amazon DynamoDB 요청은 총 3 조 3400 억회로서, 피크 타임 초당 1290 만 건에 이릅니다. 서비스 팀에 따르면 DynamoDB의 빠른 확장성, 일관된 성능 및 고 가용성으로 인해 어렵지 않게 프라임 데이의 요구 사항을 충족 할 수있었습니다.
  • 스택 생성 – AWS 리소스를 추가로 가져 오기 위해 Prime Day를 위해 약 31,000 개의 AWS CloudFormation 스택이 생성되었습니다.
  • API 사용 횟수AWS CloudTrail은 5 백억 개 이상의 이벤트를 처리하고 Prime Day를 지원하는 다양한 AWS API에 대한 4190 억 회 이상의 호출을 추적했습니다.
  • 구성 추적AWS Config는 AWS 리소스를위한 1 천 4 백만 개 이상의 구성 항목을 생성했습니다.

여러분도 할 수 있습니다!
프라임 데이 (Prime Day)만큼 크고 복잡한 중요한 이벤트를 진행하는 데는 많은 계획이 필요합니다. 이러한 유형의 이벤트를 염두에 두고 계시면, 대형 이벤트를 위한 인프라 준비하기에 대한 한국어 기술 백서를 살펴보십시오. 내부에서는 제품 출시 또는 계절적 트래픽 급증과 같은 계획된 확장성 높은 이벤트, 자동화, 탄력성, 비용 최적화, 이벤트 관리 등의 섹션을 원활하게 처리 할 수 ​​있도록 애플리케이션을 디자인하고 프로비저닝하는 방법을 배울수있습니다.

Jeff;

이 글은 Prime Day 2017 – Powered by AWS의 한국어 번역입니다.

AWS를 기반한 Amazon Prime Day 성공담

올해로 두번째였던 Amazon Prime Day에서 일일 판매 신기록을 달성했습니다. 하루 동안 전세계에서 주문된 수량은 블랙 프라이데이, 사이버 먼데이, Prime Day 2015의 기록을 뛰어 넘었습니다.

Slice Intelligence는 Prime Day 2016 당일에 미국 전역의 전자 상거래 소비자 중 74%가 Amazon에서 구매를 했다고 보고 있습니다. 일일 글로벌 쇼핑 이벤트는 Amazon Prime 회원만을 대상으로하고 있으나, Prime 2015에 비해 올해의 트래픽 수준은 과거와 비교해서 최고였을 뿐만 아니라 Amazon Mobile App 에서의 주문량은 지난해 대비 2배나 상승했습니다. 전세계 Prime 멤버가 하루에 구입한 항목의 한 가지 예로, 장난감 2만개 이상, 신발 1만 켤레 이상 그리고 TV는 9 만대 이상의 판매를 기록하였습니다. (자세한 판매 통계 내용은 Amazon’s Prime Day is the Biggest Day Ever를 참고하시기 바랍니다.)

여러분도 예상하다시피 이렇게 대규모 규모의 단기 온라인 행사를 하려면, 급증하는 트래픽에 확장성 높은 인프라 대응이 가능해야 합니다.

AWS 기반의 확장성 이용
Amazon 쇼핑 웹 사이트는 대규모 웹 트래픽에 대응하기위해 많은 수의 EC2 인스턴스를 사용하고 있습니다. Prime Day 중 급증하는 고객 트래픽에 대응하기 위해 Amazon 쇼핑 서비스 팀은 다수의 EC2의 숫자를 늘렸는데, 이는 2009년에 AWS를 기반하여 Amazon.com을 운영했던 서버 용량을 한번에 추가했습니다. 각 컴퓨팅 자원은 전 세계 여러 AWS 리전에서 확보합니다.

7월 11일의 당일 아침은 날씨는 좋았고, Amazon 시애틀 본사 빌딩에 일부 구름이 끼어있었습니다. 오전 8시가 다가오는 무렵, Amazon 쇼핑 팀은 Prime Day 첫번째 아이템인 10개의 상품 출시 준비를 완료했습니다. (태평양 반대편은 거의 자정 무렵입니다.) 일본에서는 Prime Day 시작을 애타게 기다리는 Prime 회원들이 각자 스마트폰, 태블릿, 노트북에서 구매 가능 상태만 기다리고있었습니다. 가장 첫번째로 일본의 트래픽이 급증하기 시작하면 CloudWatch 메트릭스에서 Amazon CloudWatch 의 엔드포인트와 ElastiCache 노드에 모바일이나 웹 요청이 빠르게 증가하고 있음을 알 수 있습니다.

이 트래픽 파도가 지구를 일주하고 유럽에서 미국에 도달 할 때까지 약 40 시간, 그리고 클릭량을 측정하는 로그 항목은 850억 건을 기록했습니다. 올해 Prime Day 주문 수량은 작년에 비해 전 세계적으로 60% 그리고 미국 내에서만 50% 나 상승했습니다. 모바일에서는 100만 명이 넘는 Prime 멤버가 Amazon Mobile App을 처음 다운로드하고 응용 프로그램을 이용하였습니다. Prime Day에서는 아래 38 종류 (아래 서비스 포함)의 AWS 서비스 사용량이 크게 증가하였습니다.

Prime Day에서의 AWS 활용 사례
Prime Day에서 진행한 대규모 온라인 행사와 비슷한 이벤트를 가지는 AWS 고객을 위해 좀 더 자세하게 AWS 서비스 관점 에서 Prime Day에 대해 설명해드리겠습니다.

  • AmazonMobile Analytics 이벤트는 전주 같은 요일에 비해 1,661% 상승했습니다.
  • Amazon이 사용하는 CloudWatch 통계 수치는 Prime Day 당일 전주 같은 요일과 비교하면 전 세계에서 400 % 상승했습니다.
  • DynamoDB는 Prime Day 당일 전주 같은 요일과 비교하면 전 세계적으로 560억 건 이상의 요청에 대응했습니다.

AWS는 다른 고객 기업와 같이 하나의 고객으로서 Amazon.com 쇼핑 서비스에 대응하고 있습니다. 같은 회사이지만 현재 두 조직은 비즈니스 파트너이며, 각종 지원 계​​획 및 요청을 하는 채널을 통해 상호 커뮤니케이션을 가지고 있습니다. 이러한 채널을 통해 일하는 방식을 통해, 다른 AWS 고객에게 제공하는 기술 지원과 의사 소통 프로세스를 개선할 수도 있었습니다. Amazon 웹 사이트 또는 모바일 앱을 AWS를 기반으로 진행하면, Prime Day처럼 단기간이면서 확장성이 꼭 필요한 큰 글로벌 이벤트를 저비용으로 제공할 수 있습니다.

AWS를 도입하기 전인 2002년에는 Amazon.com에서는 공휴일 및 휴가철 쇼핑 시즌 준비는 미리 계획해서 예산을 확정하고, 하드웨어 구입 등을 해야 했습니다. 하드웨어 구매는 트래픽 증가에 대응하는 데 도움이 되었지만, 트래픽이 평상시로 돌아 오는 즉시 Amazon.com에서 이용하지 않는 하드웨어를 낭비하고 소유해야만 했습니다. 이제 AWS의 글로벌 인프라 구조를 통해 아마존닷컴 뿐만 아니라 고객이 Prime Day와 같은 대형 온라인 이벤트를 실시하는 데 필요한 처리 능력을 손쉽게 추가 할 수 있도록 유연성과 비용 효율적인 방법을 사용할 수 있습니다. AWS는 프라임 데이 정도 규모의 온라인 이벤트를 실시하는데 필요한 대응해 줌으로서, Amazon 쇼핑팀은 고객에게 가능한 최고의 사용자 경험을 제공하는 데 전념 할 수 있게 되었습니다.

프라임 데이를 통해 배운 점
Amazon 쇼핑팀은 Prime Day를 잘 마친 후, 여러 가지 배운 점을 우리에게 알려주었습니다. (이는 비슷한 이벤트를 준비하는 AWS 고객에게도 도움이 될 것입니다.)

  • 계획 및 테스트 – 미리 계획하고 테스트를 하는 것이 필수적입니다. 과거 추세를 바탕으로 미래 트래픽 예측 계획을 수립하고 이에 따라 필요한 자원을 예측합니다. GameDay 방식으로 문제 발생시 대응을 사전에 준비합니다. 이는 인프라 및 웹 사이트의 여러 부분에서 의도적으로 장애를 일으켜 여러 장애가 발생했을 때의 상황을 시뮬레이션 하는 방법으로 Amazon의 GameDay에 대한 상세 내용에 대해서는 Resilience Engineering – Learning to Embrace Failure를 참고하시기 바랍니다.
  • 자동화 – 수동 작업을 줄이고 모든 자동화합니다. 위급 시에 자동으로 응답 할 수있는 서비스를 활용해야 합니다. 예를 들어 Amazon Route53를 사용하여 자동으로 확장하거나 트래픽 및 수요에 따라 EC2를 자동 확장 또한 Elastic Load Balancing을 사용하여 자동 복구를 가능하게 여러 리전과 가용 영역(AZ)에 걸쳐 트래픽을 분산합니다.
  • 모니터링Amazon CloudWatch 를 사용하여 유연하게 알림을 전달합니다. CloudWatch 모니터링을 통해 뛰어난 고객 경험을 제공할 수 있고, 상태를 항상 파악할 수 있도록 디자인되어 있습니다.
  • 발상의 전환 – AWS를 사용하여 다양한 온라인 이벤트에 대한 필요한 자원을 제공하고, 자사의 인프라에 대한 자신감을 통해 더 큰 이벤트를 진행할 수 있습니다.

앞서 언급했지만, 프라임 데이 규모의 단일 행사를 계획 및 실시하는 것이 매우 중요합니다. 대규모 행사를 계획하고, 지원 계획 과 서비스의 장점을 활용하여, 솔루션 설계자 및 기술 계정 관리자 그리고 APN 컨설팅 파트너 가 필요에 따라 협력할 수 있습니다. 여러분이 일회성 이벤트를 계획하고 있다면 꼭 알려 주시기 바랍니다. 관련해서 저희가 필요한 지원에 대한 다양한 경험과 컨설팅을 제공합니다.

– Jeff;

이 글은 How AWS Powered Amazon’s Biggest Day Ever의 한국어 번역입니다.