Amazon Kinesis Data FirehoseでHTTPエンドポイントへのデリバリが可能に

原文(投稿日：2020/10/30)へのリンク

Amazon Kinesis Data Firehoseに先頃、ジェネリックなHTTPエンドポイントへのデータストリーミングのサポートが追加された。これにより、Amazon API Gatewayのサービス統合を通じて、新たなAWSサービスをデスティネーションとすることも可能になる。新機能の一部として、Datadog、MongoDB、New Relicなど、新たなサードパーティサービスプロバイダ用のインテグレーションも用意されている。

Amazon Kinesisは、"ビデオやデータストリームをリアルタイムで収集、処理、解析する"AWSのストリーミングデータプラットフォームであり、いくつかのサービスが用意されている。Kinesis Data Streamsは、ユーザがカスタムアプリケーションを実装する必要はあるが、最も高性能で柔軟性のある機能を提供する。組み込まれているLambdaインテグレーションを使うことは可能だが、それでもPrateek Mehrotra氏が先日説明した<ような運用上の課題は残る。対照的にKinesis Data Firehoseは、カスタムコードを必要とせずに"データストアや分析サービスに対してリアルタイムデータを用意しロードする"と同時に、AWS Lambda関数を経由したサーバレスなデータ転送も可能にする、完全マネージドなサービスである。特に注目すべきなのは、Kinesis Data Firehoseでは、Kinesis Data Streamsを直接コンシュームすることによって両サービスのメリットを組み合わせることが可能な点だ。

現時点では、Data FirehoseはAmazon S3、Amazon Redshift、Amazon Elasticsearch、および2017年以降はHTTP Event Collector経由でSplunkを、組み込みデスティネーションとしてサポートしている。独自のデスティネーションを可能にするジェネリックHTTPエンドポイントが今回追加されたことで、Amazon API GatewayのAWSサービスインテグレーションを使用することにより、Amazon DynamoDBやAmazon SNSといったAWSサービスも新たに使用できるようになった。これは同時に、DatadogやMongoDB、New Relicといった、他のサードパーティサービスプロバイダにプラットフォームを開放することにもなる。

ブログの紹介記事でImtiaz Sayed、Masudur Rahaman Sayem両氏が強調しているように、既存のKinesis Data Firehoseの機能については、"AWS Lambdaサービス統合、再試行オプション、デリバリ失敗時のデータ保護、アカウント間およびリージョン間のデータ配信など、すべてがサポートされている"。Firehose(消火ホース)という名称とは裏腹に、配信ストリームとHTTPエンドポイント間のすべてのトラフィックは、HTTPSを通じて転送中は常に暗号化されている。デスティネーションサービスが要求する場合は、アクセスキーによってサインインすることも可能だ。

図: Kinesis Data Firehose HTTPエンドポイントデータフロー(AWS Management Console経由)

Kinesis Data Firehoseデリバリストリームの生成には、以下のステップとコンセプトが関連する。

1. デリバリストリームの名称とデータソースの選択 — カスタムアプリケーション、Kinesisエージェント、ストリームに直接書き込みを行う他のAWSサービス、専用のインテグレーションを介してコンシュームするKinesisデータストリームなどが選択可能である。
2. オプションのレコード処理により、AWS Lambda関数を介したデータ変換の適用や、AWS Glueによるレコード形式の変換を行うことができる。
3. 新たなHTTPエンドポイントなどデスティネーションの選択や、配信エラーへの対処や全ソースレコードの保存を目的としたAmazon S3バックアッププランの設定が可能である。
4. パフォーマンスやセキュリティ、エラーログに関するさまざまなセッティングが可能である。

設定の完了した配信ストリームは、CloudWatchメトリクスや、HTTPエンドポイントのトラブルシューティング手段として推奨されるオプションのCloudWatchログを通じて、広範な監視オプションを提供する。サンプルデータを使用して配信システムをテストすることも可能だ。

AWS Servless HeroのEric Hammond氏は、twitterのスレッドでHTTPデスティネーションエンドポイントのポテンシャルについて認めながらも、採用時の課題について懸念を述べている。

この機能は、確かに興味深い問題のいくつかを解決してくれるかも知れませんが、そのような問題を抱える人たちのほとんどは、Amazon Kinesis Data Firehoseに答を求めようとはしないのではないでしょうか。[...] AWS内でAからBにデータを取得するために使うべき方法が決められなければ、次のプロジェクトに取り掛かろうと思うはずがありません。

Microsoft AzureのEvent Hubsも同様な機能を提供しており、Azure Blob Storage内のイベントをキャプチャしたり、そのイベントをEvent GridとWebhook、あるいはAzure Functionsベースのハンドラを経由して処理する手段として使用されている。Google Cloud PlatformのPubSubでは、公開されているHTTPSアドレスへのサブスクリプションのプッシュがサポートされている。オープンソースの分散イベントストリーミングプラットフォームApache Kafkaでは、他システムへのゲートウェイとしてKafka Connectを提供している。これにより、例えばCamel Kafka Connectorを使ってApache Camelコンポーネントを再利用することが可能になる。AWSも、Amazon Managed Streaming for Kafkaという名称のサービスとしてKafkaを提供している。

Amazon Kinesis Data Firehoseの資料としては、HTTPエンドポイントデリバリ要求および応答の仕様、HTTPエンドポイントのトラブルシューティング、AWS CLIリファレンス、APIリファレンスなどを含む開発者ガイドが用意されている。サポートはAmazon Kinesisフォーラムを通じて行われる。課金は基本的に、送出したデータ容量をベースに行われる。HTTPエンドポイントへの送信は、追加コストを伴わない。Amazon S3やAmazon Redshiftなどのターゲットに関わる料金は別途請求される。