Amazon Connect를 이용한 Outbound Call 서비스 개발하기

Changhoon Hyun
HBsmith
Published in
7 min readMay 22, 2019

--

안녕하세요. HBSmith의 현창훈 입니다. 이번에는 최근 사용한 Amazon Connect를 사용해서 만든 서비스에 대해서 소개 하겠습니다.

왜 아웃바운드 콜 서비스를 개발하게 됐는가

HBSmith는 QA를 자동화 하고 테스트가 실패하면 pagerduty로 알림 전화를 받고 실패한 고객들에게 연락 드립니다. pagerduty를 내재화 하기 위해서 서비스를 개발하게 됐습니다.

중간에 HBSmith 없이 직접 user 에게 보낼 수 있도록 하는것을 목표로 합니다.

Pagerduty를 내재화 하게 된 이유

1.비싸다

  • On call 담당자가 여러명이면 더 비싸진다.

2. 오직 outbound call 기능만 필요하다.

3. 한국어를 지원하지 않는다.

  • 밤에 영어로 알림 전화가 오면 정신 없어서 내용을 인지하기 힘들다.

요구사항

  • On call담당자에게 event 기반으로 outbound call을 해줘야 한다.
  • TTS로 한국어를 읽어줘야 한다.
  • 담당자가 전화를 받고 resolve 할 수 있어야 한다.
  • n번 시도해서 resolve가 안되거나 담당자의 액션에 의해 escalation이 돼야 한다.
  • 받을때까지 계속 루프를 돌면서 전화를 걸어줘야 한다.

내재화를 위한 도구 선택

Amazon Connect

콜 센터를 구축할 수 있는 Amazon의 managed service 입니다.

장점

  • Managed service라서 개발과 관리가 편하다.
  • polly와 쉽게 연동된다.

단점

  • IaC를 지원하지 않는다.
  • 전화를 미수신 하거나 중간에 끊는 경우 등의 event를 지원하지 않는다. connect에서 미리 정의한 contact flow의 제한적인 액션만 가능하다.

Twilio

전화, SMS, 영상통화 등을 가능하게 해주는 서비스

장점

  • IaC가 가능하다.
  • 다양한 API와 event를 지원한다.

단점

  • 구현 해야 할 코드가 상대적으로 많아진다.
  • 실행을 위한 추가적인 인프라를 관리해야 한다.

우리의 선택은 Amazon Connect

  • 최대한 단순하고 빠르게 개발 / 배포 하는게 중요했다.
  • AWS Tech Partner로서 AWS에 대한 기술적 경험을 늘릴 수 있다.

Architecture에 대한 고민

기존 구조

기존에는 API 서버에서 Pagerduty로 trigger 할 Message를 전달하고 Lambda가 trigger 했습니다.

1. SQS에 들어온 대로 connect만 trigger 하는 구조

위 아키텍쳐는 기존 구조에서 SQS만 교체해서 변경을 최소화 하고 서비스간 독립성이 명확하다는 장점이 있습니다. 하지만 워크로드를 다시 검토 해보니 단순히 Queue의 Message에만 의존적인 구조로 할 수 없다는것을 깨달았습니다.

2. SQS 대신 DB를 사용하고 Lambda가 전화걸 대상을 Polling하는 구조

Outbound call에는 실시간으로 다양하게 상태가 변경되기 때문에 웹이나 담당자의 액션에 의해서 리스트에서 제거되거나 Message가 변경돼야 했습니다. 그래서 DynamoDB 또는 Aurora Serverless에 데이터를 넣고 상태를 관리하는 방법을 고민했습니다.

DynamoDB

  • Key Value 기반으로 관리할 수 있는 심플한 데이터 구조와 쿼리에 적합하다.
  • Managed Service
  • 많은 WCU / RCU가 필요한게 아니어서 프리티어로 커버 가능할 것으로 예측됨.

Aurora Serverless

  • 새로운 기술적 경험을 축적할 수 있습니다. HBSmith는 AWS Tech Partner로서 AWS에서의 새로운 경험을 중요하게 생각합니다.
  • Managed Service
  • Aurora Serverless는 connection의 scale out에 제약이 있지만 현재 워크로드에는 제약사항에 해당되지 않을거라고 판단함.

Aurora Serverless의 제약사항

결정된 Architecture

기존 API Server가 Amazon Connect를 trigger 하고 기존 DB에서 상태 관리

최대한 독립적인 서비스를 구상 했으나, 기존 서비스와 의존성이 생기더라도 단순하게 가자는 팀의 의견이 있었습니다. HBSmith는 최대한 심플하고 단순한 구조를 기반으로 빠르게 배포 하는것을 최우선으로 생각하기 때문에 팀의 의견을 수렴하여 위와 같은 구조를 최종적으로 결정 했습니다.

Amazon Connect를 이용한 구현

다양한 국가의 번호도 온디맨드로 관리 가능합니다.

미리 정의된 음성 파일이나 TTS를 읽어주고, 사용자에게 입력을 받는 등의 액션을 코딩 없이 관리 할 수 있습니다. Polly의 서연이 추가 돼서 더 관리하기 편해졌습니다.

AWS Lambda와의 통합도 가능합니다. 미리 관리 콘솔에서 어떤 Lambda를 사용할지 지정 해줘야 합니다. 저는 resolve를 눌렀을 때, escalation을 눌렀을 때, 다른 번호를 입력하거나 time out 됐을 때 호출 될 Lambda를 각각 정의해서 사용 했습니다.

AWS의 managed service 답게 Amazon Connect의 log도 cloudwatch로 관리 가능합니다. Contact Flow의 action 단위로 찍어줍니다.

사용자에게 TTS를 해주는 서연이 기록된 cloudwatch log

유의사항

  • 한국 리전에는 Amazon Connect가 없습니다. HBSmith는 도쿄 리전을 사용 합니다.
  • Outbound call을 한국 번호로 걸기 위해서는 Support ticket 을 열어서 whitelist에 KR을 추가해야 합니다. 미리 Amazon Connect Instance를 생성하고 해당 instance에 대해서만 추가 됩니다.
  • 전화를 거는 것은 비동기로 처리 되지만 Contact Flow 외에는 event를 받을 방법이 없습니다.
  • 전화를 받지 않으면 자동으로 한번 더 걸어줍니다.
  • IaC가 되지 않는 것이 운영에 부담이 될 수 있습니다. 저희는 QA에서 리소스를 삭제 후 다시 생성하는 과정에서 Connect에서 사용하는 Lambda에서 permission 관련 문제가 발생한 사례가 있었습니다. IaC를 했다면 개발 과정에서 미리 발견 됐을 문제입니다.

AWSKRUG serverless 소모임에서 발표한 자료를 공유합니다. 감사합니다.

https://www.slideshare.net/changhoonhyun/amazon-connect-outbound-call

--

--