AWS Lambda/Kinesis Stream Best Practice

개요

Kinesis Stream을 Lambda와 연계시키기 위해서는 Event source mapping을 중간에 설정해주어야 한다.

물론 어려운 과정은 아니며, 이렇게 되면 아래와 같은 Data Flow가 구성된다.

 

이러한 아키텍처가 구성되었을 때, 어떻게 해야 고가용성/고성능의 아키텍처를 구현할 수 있을까에 대해 글을 써보고자 한다.

Scale Out

먼저, Kinesis Stream으로 유입되는 데이터가 많아졌을 경우, 어떤 대응이 필요한지에 대해 고민해보았다.

간단히 생각해보면, Shard의 개수를 늘리면 되는데, 이 때 과연 Lambda는 어떻게 확장해주어야 하는가?

결론적으로, Kinesis Stream에서 Shard가 증가하게 되면 이것의 개수만큼 Lambda 개수가 자동으로 늘어나게 된다.

즉, 성능을 향상시키기 위해서는 Lambda를 고려하지 않고 Kinesis Stream의 Shards 개수만 늘려주면 처리성능이 횡적으로 확장되게 된다.

출처

 

Auto Scale

Shard Auto Scale에 대해 굉장히 잘 설명된 글

https://medium.com/slalom-data-analytics/amazon-kinesis-data-streams-auto-scaling-the-number-of-shards-105dc967bed5

 

Kinesis Stream Metric

모니터링은 어떻게 해야 할까? 다행히 Kinesis Stream은 AWS 서비스이므로 여러가지 Cloudwatch Metric 지표를 제공하며, 아래 출처에서는 "권장 Amazon Kinesis Data Streams 지표"도 제공하기 때문에 실 서비스 반영 시 해당 지표는 필수적으로 모니터링을 하여 적절한 퍼포먼스를 유지해야겠다.

출처

 

Lambda Best Practice

그렇다면, Lambda의 Best Practice는 어떻게 되는가? AWS Document에서는 이 또한 도큐먼트를 통해 가이드를 제공해주고 있다. 특히, 아래 항목은 유심히 확인해보아야 할 것 같다. 상세 내용은 출처 참조..

• 핵심 로직에서 Lambda 핸들러를 분리합니다. .

• 실행 콘텍스트 재사용을 활용하여 함수 성능을 향상시킵니다.

• Lambda 함수를 테스트하는 성능

• 서로 다른 배치 및 레코드 크기로 테스트
  

• IteratorAge에 대해 Amazon CloudWatch를 사용

출처

 

향상된 팬아웃

데이터 스트림을 소비하기 위한 전용 소비자를 생성하여 이를 event source mapping 시켜버리는 방법이다. 이를 통해서 전용 처리량을 할당받을 수 있으므로 성능을 향상시킬 수 있다.

Lambda 함수는 데이터 스트림의 소비자 애플리케이션입니다. 이 함수는 각 샤드에서 한 번에 한 개의 레코드 배치를 처리합니다. Lambda 함수를 데이터 스트림에 매핑하거나(표준 반복자), 스트림의 소비자에 매핑할 수 있습니다(향상된 팬아웃).

지연 시간을 최소화하고 읽기 처리량을 최대화하려면 데이터 스트림 소비자를 생성하십시오. 스트림 소비자는 각 샤드에 대해 전용 연결을 설정하므로 스트림에서 읽는 다른 애플리케이션에 영향을 주지 않습니다. 전용 처리량은 많은 애플리케이션에서 동일한 데이터를 읽거나, 큰 레코드를 갖는 스트림을 재처리하는 경우에 유용합니다. 출처

참조/ 예시코드