Amazon Web Services ブログ

Apache Flink と Amazon Kinesis Data Analytics for Java アプリケーションを使用して、ストリーミングアプリケーションを構築、実行する

ストリーム処理によってリアルタイムデータの収集、処理、分析が容易となるため、洞察が継続して生まれ、新たに生じる状況にも素早く対応できるようになります。この機能は得られた洞察の価値が、時間の経過とともに減少する場合に役立ちます。つまり検出した状況に迅速に対応できればできるほど、この反応がより価値のあるものとなります。たとえば不正なクレジットカードのトランザクションが発生し、それを分析してブロックするようなストリーミングアプリケーションを考えてみましょう。そのアプリケーションを従来のバッチ指向のもの、つまりその日の営業を終了する際に不正な取引を識別して、翌朝にはレポートを生成するアプローチと比較してみてください。

洞察の価値が時間の経過とともに下がっていくのは、よくあることです。そういう訳でストリーム処理をすると、分析アプリケーションの価値が大幅に向上するのです。ただしデータを継続的に受信し処理するストリーミングアプリケーションを構築して運用するのは、従来のバッチ指向の分析アプリケーションを運用するよりもはるかに困難です。

この投稿ではこうした課題に対処するため、Apache Flink と Amazon Kinesis Data Analytics for Java アプリケーションを使用する方法について解説します。自己管理環境と比較して運用上のオーバーヘッドを大幅に削減できるマネージドサービスに基づいて、信頼性が高く、スケーラブルで、可用性の高いストリーミングアーキテクチャを構築する方法を探ります。特に Kinesis Data Analytics for Java アプリケーションを使用して、Flink アプリケーションを準備および実行する方法に焦点を当てています。このため、ソースコードと AWS CloudFormation テンプレートを含む例に言及したシナリオを使用します。この例に沿ってご自身の AWS アカウントを使用するか、特定の要件に従ってコードを修正してください。

ストリーミングアプリケーションを実行する上での課題

ストリーミングアプリケーションを構築する際、ダウンストリームシステムは当然のことながら、出力が継続的でタイムリーに生成にされることを前提としています。したがって、ストリーミングアプリケーションの可用性に関する極めて難易度の高い条件を必要とします。さらに従来のバッチベースのアプローチと比較して、運用上の問題に取り組む時間がはるかに少なくてすむようになります。バッチ処理のシナリオでは営業日の終わりに 1 度実行するジョブが失敗し、失敗したジョブを再実行しても、結果が必要な翌朝までには計算を完了することができます。対照的にストリーミングアプリケーションが失敗した場合、出力を使用するダウンストリームシステムは予想される出力が間に合わなくなると、数分以内もしくはもっと早く影響を受ける可能性があります。

その上、失敗した場合、バッチ処理の場合のように中間結果をすべて削除して失敗した処理ジョブを再実行することはできません。ストリーミングジョブの出力はダウンストリームシステムが使用し続けます。すでに使用した出力を取り消すことは簡単ではありません。したがって処理パイプライン全体は失敗時に再起動するアプリケーションによって起きる複製がより影響を受けやすくなります。さらにストリーミングアプリケーションの計算では、アプリケーションの実行が失敗したときにデータが破損したり失われたりする可能性がある内部状態に、影響を受けることがよくあります。

最後に指摘すべき重要なことは、ストリーミングアプリケーションは多くの場合、さまざまな量のスループットを処理します。そのため現状の負荷に応じて、アプリケーションを拡張することが理想的です。負荷が増大した場合、ストリーミングアプリケーションをサポートするインフラストラクチャを拡張して、プリケーションが過負荷になり、遅延が起き、そして関連性がなくなった結果を生成するようなことがないようにしなければなりません。一方負荷が減少した場合は、必要以上のリソースをプロビジョニングしないことで、ここでもインフラストラクチャを拡張しコスト効率を維持する必要があります。

Flink および Kinesis Data Analytics for Java アプリケーションを基本にした、信頼性が高くスケーラブルなストリーミングアーキテクチャ

Apache Flink は、非有界および有界のデータセット上のステートフル計算に合わせて調整してあるオープンソースプロジェクトです。ストリーミングデータを分析する際に Flink はさまざまな API (Java や SQL を含む)、リッチ時セマンティクス、および状態管理機能をサポートし、よく起こる課題に対処できます。きっちり 1 度の処理セマンティクスを維持しながら、障害から回復することもできます。このため Flinkはストリーミングデータを低いレイテンシーで分析するのに最適です。

この投稿では Kinesis Data Analytics for Java アプリケーションを使用して、Flink アプリケーションをデプロイ、操作、および拡張する方法をご紹介します。あるシナリオを使用して、ニューヨーク市のタクシーフリートの利用統計情報をほぼリアルタイムで分析し、フリートの運用を最適化します。このシナリオでは、フリート内の移動が完了したすべてのタクシーの乗車に関する情報を収集しています。追跡情報には、乗車場所、下車場所、乗客数、および発生収益が含まれます。この情報は単純な JSON BLOB として、Kinesis データストリームに取り込まれます。そこからデータは Flink アプリケーションによって処理され、このアプリケーションは Kinesis Data Analytics for Java アプリケーションにデプロイされます。このアプリケーションは現時点のタクシー配車の要望が多い地域を識別します。得られた洞察は最終的に Amazon Elasticsearch Service まで継続されます。そこでは Kibana を使用して洞察にアクセスや視覚化が可能です。

このシナリオでは次のようなアーキテクチャとなり、データの取り込み、処理、および表示する 3 段階に分かれています。

インフラストラクチャのさまざまな側面を分割することはこのドメインではよく見られるアプローチであり、より密接に結合したアーキテクチャに比べていくつかの利点があります。

まず Kinesis データストリームはプロデューサーとコンシューマーを分けるバッファとして機能します。例えばノード障害から現在回復中の可能性がある処理層などの状態に関係なく、タクシーから生成されるイベントをデータストリームに確保できます。同様に、たとえ何らかの操作上の問題のために取得レイヤーまたは処理レイヤーが現在利用できなくても、派生データは Kibana を通して利用可能です。最後に重要なことを挙げると、すべてのコンポーネントは個別に拡張でき、個々の要件に応じて特別に調整したインフラストラクチャを使用できる点です。

このアーキテクチャにより、将来的に新しいテクノロジーを試作、採用することもできます。複数の独立したアプリケーションが Kinesis データストリームに格納されているデータを、同時に使用することができます。そのため本番時のトラフィックをコピーし、既存のアプリケーションの新しいバージョンがどのように機能するかをテストできます。一方、データ分析のために別のツールとテクノロジースタックを導入することもできます。ここでも既存の本番アプリケーションに影響を与えることなく実行できます。たとえば未加工のイベントデータを Amazon S3 にまで存続させるには、2 番目のコンシューマーとして Kinesis Data Firehose 配信ストリームを Kinesis データストリームに追加するのが一般的です。これでデータの長期的なアーカイブが容易になります。これを使用して、アドホッククエリの評価や履歴トレンドの分析を行うことができます。

全体的に見てもアーキテクチャのさまざまな側面を取り入れ、処理、表示に分散することで、いろいろなコンポーネントが適切に分離され、アーキテクチャがより信頼性の高いものとなります。さらに、さまざまな目的に応じて様々なツールを選択することができるようになり、時間の経過とともにアーキテクチャを変更または進化できる柔軟性が大幅に向上します。

この投稿の後半では、Apache Flink と Kinesis Data Analytics for Java アプリケーションを使用し、現時点でタクシー配車の要望が多い地域を特定します。ニューヨーク市の空港への平均乗車期間も導き出します。ただしこのアーキテクチャには、ここで説明しているものの代わりまたはこれに加えて、Apache Spark Structured Streaming や Kinesis Data Firehose などの他のツールを使って着信イベントを使用する選択肢もあります。

では始めましょう!

説明しているアーキテクチャの動作を確認するには、ご自身の AWS アカウントで次の AWS CloudFormation テンプレートを実行します。このテンプレートでは最初に、Kinesis データストリームからデータを読み取るために必要な Flink Kinesis Connecto rを含む、着信タクシー乗車を分析する Flink アプリケーションを構築します。次にインフラストラクチャを作成し、Flink アプリケーションを Kinesis Data Analytics for Java アプリケーションに送信します。

アプリケーションを構築しインフラストラクチャを作成するプロセスには、全体で 20 分ほどかかります。AWS CloudFormation スタックの作成後、Flink アプリケーションは Kinesis Data Analytics for Java アプリケーションとしてデプロイされます。その後、データストリーム内のイベントを受信するのを待ちます。チェックポイント機能が有効になっていると、Kinesis Data Analytics for Java アプリケーションがユーザーの代わりにチェックポイントを管理するため、アプリケーションは基盤となるインフラストラクチャに障害が起こってもシームレスに回復できます。加えて着信トラフィックの変化に応じて自動スケーリングが設定されるため、Kinesis Data Analytics for Java アプリケーションがリソースを自動的に割り当てや削除を行い、アプリケーションをスケーリング (つまり並列処理に適合) します。

Kinesis データストリームを生成するために、ニューヨーク市での過去のタクシー配車の公開データセットをデータストリームに再生する Java アプリケーションを使用します。この Java アプリケーションは、AWS CloudFormation がプロビジョニングした Amazon EC2 インスタンスにすでにダウンロードされています。インスタンスに接続して JAR ファイルを実行するだけで、イベントをストリームに取り込むことができます。

以前に実行した AWS CloudFormation テンプレートの出力セクションから、正しいパラメーターを含め以下のコマンドをすべて取得できます。

$ ssh ec2-user@«Replay instance DNS name»

$ java -jar amazon-kinesis-replay-1.0.jar -stream «Kinesis data stream name» -region «AWS region» -speedup 3600

speedup パラメータによって、過去の実際に発生したイベントと比較して、データが Kinesis データストリームに取り込まれる速度を決定します。これらのパラメータを与えた場合、Java アプリケーションは 1 秒以内に 1 時間の履歴データを取り込みます。これはつまり毎秒およそ 1 万 3 千個のイベントと 6 MB のデータのスループットが得られることとなり、Kinesis データストリームを完全に充足します (詳細は後述)。

次に、作成した Kibana ダッシュボードを使用して、派生データを調べます。または独自の可視化を作成し、Kibana でデータを検索することもできます。

https://«Elasticsearch endpoint»/_plugin/kibana/app/kibana#/dashboard/nyc-tlc-dashboard

用意された Kibana ダッシュボードにはヒートマップと折れ線グラフがあります。ヒートマップではタクシーが現時点で必要とされている場所が可視化されており、マンハッタンでタクシーの需要が最も高いことを示しています。さらにマップ上では周辺地域と比較して、JFK 空港とラガーディア空港も極めてタクシーの需要が高い場所であることを示しています。折れ線グラフはこれら 2 ヶ所の空港への平均乗車時間を可視化したものです。次の図は、夕方になると突然低下していますが日中を通して着実に増加していく様子を示しています。

この投稿では、Elasticsearch クラスターは AWS CloudFormation テンプレートのパラメータとして指定された IP アドレス範囲からの接続を受け入れるように設定されています。本番ワークロードの場合、たとえば Amazon Cognito for Kibana のアクセスコントロールを使用して、Elasticsearch ドメインのセキュリティをより強化することが望ましいといえます。

アーキテクチャを拡張してスループットを向上させる

この投稿では、Kinesis データストリームを意図的にアンダープロビジョニングしているため、Java アプリケーションはデータストリームを完全に飽和させています。Java アプリケーションの出力を詳しく調べると、「リプレイラグ」が増え続けていることが分かります。つまりプロデューサーは指定した speedup パラメータに従って必要なだけ高速にイベントを取り込むことができないことを示しています。

Amazon CloudWatch ダッシュボードを介してアクセスすることで、データストリームのメトリクスをより詳しく調べることができます。これで WriteProvisionedThroughputExceeded メトリクスがわずかに増加したことが分かります。それぞれのリクエストが抑制されるため、およそ 0.4 パーセントのレコードはストリームに受け入れられません。言い換えれば、データストリームはあまりにも多くのイベントが進行中であるときは特に、プロデューサーが新しいイベントの取り込みを一時停止すると、プロビジョニングが不十分になることを示します。

コンソール上で数回クリックし、API 呼び出しを使用してそれぞれ 6 から 12 にシャード数を更新するだけで、データストリームのスループットを増加することができます。本番環境の場合、この手順を自動化することもできます。Kinesis データストリームを自動的にスケールする方法の詳細については、ブログ投稿の「Scaling Amazon Kinesis Data Streams with AWS Application Auto Scaling」をご参照ください。

ストリームのスケーリング操作が終了すると「リプレイラグ」が減少し、より多くのイベントがストリームに取り込まれる様子が分かります。

ただし直接結果を得るには、より多くのイベントを処理する必要があります。そのため今度は Kinesis Data Analytics for Java アプリケーションは過負荷となり、増え続ける着信イベントに対応できなくなります。これは、CloudWatch に公開されている millisBehindLatest メトリクスを通じて確認できます。このメトリクスはミリ秒単位の取り込み時間に応じて、Kinesis Data Analytics for Java アプリケーションが現在読み取っている最も古いレコードとストリーム内の最新のレコードとの時間差を報告するものです。そのためストリームの先端から、どれだけ処理が遅れているかが分かります。

これらのメトリクスが示すように、スケーリング操作が終了してから 10 分後、処理はストリーム内の最新のイベントからすでに 3 分以上の遅れが出ています。さらに悪いことに、着実に遅れ続けており、この差は継続的に広がっています。

ただし Kinesis Data Streams とは対照的に、Kinesis Data Analytics for Java アプリケーションはネイティブで自動スケーリングをサポートしています。数分後、メトリクスでスケーリングアクティビティの効果を確認できます。処理が Kinesis データストリームの先端に追いつくと、millisBehindLatest メトリクスはゼロに達するまで減少し始めます。

ここで、millisBehindLatest メトリクスが減少し始める直前に急上昇していることに注意してください。これは、Kinesis Data Analytics for Java アプリケーションのスケーリングが今日は機能しているためです。実行中のアプリケーションを拡張するため、アプリケーションの内部状態はいわゆるセーブポイント状態に維持されます。このセーブポイントは Kinesis Data Analytics for Java アプリケーションによって、スナップショットとして公開されています。その後アプリケーションの実行中のインスタンスが終了し、より多くのリソースとさらに高い並列性を持つ同じアプリケーションの新しいインスタンスが作成されます。次にアプリケーションの新しいインスタンスはスナップショットからその内部状態を取り込み、現在終了したインスタンスが中断しているところから処理を再開します。

この結果スケーリング操作は処理の短い中断を引き起こし、このためメトリクスの急上昇が起こったのです。ただしこの操作はプロデューサーとコンシューマーには見えません。プロデューサーはアプリケーションからうまい具合に切り離されているので、Kinesis データストリームへの書き出しを続けることができます。同様にコンシューマーは Kibana を使用してダッシュボードを表示できますが、最新のデータはまだ処理されていないため表示されない可能性があります。

少し戻って、これまで行ったことを復習しましょう。完全に管理された、可用性が高く、スケーラブルなストリーミングアーキテクチャを作成しました。1 秒間に最大 2 万 5 千個のイベントを取り込んで、分析しました。数回クリックするだけで Kinesis データストリームと Kinesis Data Analytics for Java アプリケーションを拡張でき、アーキテクチャのスループットが 2 倍になりました。アーキテクチャは完全に機能しており、ひとつもイベントを失うことなくイベントの受信と処理を続けながら、これらすべてを実行しました。他のコンポーネントと同じくらいシームレスに、Elasticsearch クラスターをスケーリングすることも可能です。ただしこれは関心の高いブログ読者の宿題として、ここでは実行せずにおいておきます。

ゼロから同じようなものを構築するのに、何が必要だったかを思い出してみましょう。

Kinesis Data Analytics for Java アプリケーションのための Flinkアプリケーションを準備する

ストリーミングアプリケーションの動作を見てきたので、今度は Kinesis Data Analytics for Java アプリケーションで Flink アプリケーションをデプロイし実行するために必要なものを見てみましょう。

他のデプロイ方法と同様に、Flink アプリケーションを最初に構築し、アプリケーションを実行するために必要なすべての依存関係を含む FAT JAR にパッケージ化します。次に生成した FAT JAR を Amazon S3 にアップロードします。その後 S3 上の FAT JAR の場所といくつかの追加設定パラメータを使用して、Kinesis Data Analytics for Java アプリケーションで実行できるアプリケーションを作成します。それには、クラスターにログインして Flink ランタイムに直接ジョブを送信する代わりに、それぞれの FAT JAR を S3 にアップロードします。次に API 呼び出し、コンソール、AWS CLI をそれぞれ使用してやりとりができる Kinesis Data Analytics for Java アプリケーションを作成します。

Flink の設定とランタイムパラメータを調整する

有効な Kinesis Data Analytics for Java アプリケーションを取得するには、Flink アプリケーションの FAT JARに特定の依存関係が含まれている必要があります。Apache Maven を使用して Flink アプリケーションを構築するには、プロジェクトの .pom ファイルに別の依存関係を追加するだけです。

<!—pom.xml ->
<project>
    ...
    <dependencies>
        ...
        <dependency>
            <groupId>com.amazonaws</groupId>
            <artifactId>aws-kinesisanalytics-runtime</artifactId>
            <version>1.0.1</version>
        </dependency>
    </dependencies>
    ...
</project>

パラメータを作成または更新する際に、作成した Kinesis Data Analytics for Java アプリケーションに渡すパラメータを指定できます。これらのパラメータは基本的に、プロパティグループの一部であるプロパティマップに含まれるキーと値のペアです。

"ApplicationConfiguration": {
    "EnvironmentProperties": {
        "PropertyGroups": [
            {
                "PropertyGroupId": "FlinkApplicationProperties",
                "PropertyMap": {
                    "InputStreamName": "...",
                    ...
                }
            }
        ]
    },
    ...
}

その後 Kinesis Data Analytics for Java アプリケーションのランタイムからアプリケーションコードにあるこれらのパラメータの値を取得できます。たとえば以下のコードスニペットは、アプリケーションが接続する Kinesis データストリーム名を FlinkApplicationProperties プロパティグループから取得します。

Map<String, Properties> applicationProperties = KinesisAnalyticsRuntime.getApplicationProperties();

Properties flinkProperties = applicationProperties.get("FlinkApplicationProperties");

String kinesisStreamName = flinkProperties.getProperty("InputStreamName");

同じメカニズムを使用して、通常はパラメータまたは設定オプションとして Flink ランタイムに直接指定されている Kinesis Data Analytics for Java アプリケーションの他のプロパティ (チェックポイント設定およびアプリケーションの並列処理など) を設定します。

"ApplicationConfiguration": {
    "FlinkApplicationConfiguration": {
        "CheckpointConfiguration": {
            "ConfigurationType": "DEFAULT"
        },
        "MonitoringConfiguration": {
            "ConfigurationType": "CUSTOM",
            "MetricsLevel": "TASK",
            "LogLevel": "INFO"
        },
        "ParallelismConfiguration": {
            "ConfigurationType": "DEFAULT"
        }
    },
    ...
}

この設定ではチェックポイント設定と並列処理設定は、デフォルトのままになります。この状態だとチェックポイント設定と自動スケーリングが有効になり、Kinesis Data Analytics for Java アプリケーションの初期の並列処理が 1 に設定されます。さらにログレベルが INFO に強化され、CloudWatch メトリクスがアプリケーションのすべてのサブタスクについて収集されます。

Flink Kinesis Connector を構築する

Kinesis データストリームからデータを読み取る Flink アプリケーションを構築しているとき、Flink Kinesis Connector が Maven Central から利用できないことに気付くかもしれません。実は自分でこれを構築する必要があるのです。次の手順で最近の Apache Flink リリース用のコネクタを構築します。ただし Kinesis Data Analytics for Java アプリケーションは Flink 1.6.2 に基づいているため、今日はこの特定のバージョンを使用できます。

$ wget -qO- https://github.com/apache/flink/archive/release-1.6.2.zip | bsdtar -xf-

$ cd flink-release-1.6.2

$ mvn clean package -B -DskipTests -Dfast -Pinclude-kinesis -pl flink-connectors/flink-connector-kinesis

コネクタが AWS CloudFormation テンプレートによってすでに構築されており、S3 に格納されていることに注意してください。次の Maven コマンドを使用し、そこからコネクタの JAR ファイルをダウンロードしてローカルの Maven リポジトリに配置するだけです。

$ mvn install:install-file -Dfile=flink-connector-kinesis_2.11-1.6.2.jar -DpomFile flink-connector-kinesis_2.11-1.6.2.pom.xml

Flink Elasticsearch シンクを Amazon Elasticsearch Serviceと統合する

1.6 のリリース以降、Apache Flink には HTTP を介した Elasticsearch API をサポートする Elasticsearch Connector が付属しています。そのため Amazon Elasticsearch Service が提供するエンドポイントと、ネイティブにやりとりができます。

Elasticsearch クラスターのパブリックエンドポイントに対するリクエストの認証方法を決めるだけです。個々の IP をホワイトリストに登録して、クラスターにアクセスできます。ただし Amazon Elasticsearch Service エンドポイントに対する認証の方法については、IAM 認証情報と署名バージョン 4 の署名プロセスを使って AWS リクエストに認証情報を追加する方法を推奨します。

AWS 固有の署名プロセスを認識しない Flink Elasticsearch Connector を拡張するには、Maven Central から入手可能なオープンソースの aws-signing-request-interceptor を使用します。リクエストが Amazon Elasticsearch Service エンドポイントに送信される直前に呼び出される Elasticsearch シンクに、インターセプターを追加するだけです。次にインターセプターは Kinesis Data Analytics for Java アプリケーション用に設定されているロールのアクセス許可を使用して、リクエストに署名します。

final List<HttpHost> httpHosts = Arrays.asList(HttpHost.create("https://...")));

ElasticsearchSink.Builder<T> esSinkBuilder = new ElasticsearchSink.Builder<>(
    httpHosts,
    new ElasticsearchSinkFunction<T>() {
      ...
    }
);

final Supplier<LocalDateTime> clock = () -> LocalDateTime.now(ZoneOffset.UTC);
final AWSCredentialsProvider credentialsProvider = new DefaultAWSCredentialsProviderChain();
final AWSSigner awsSigner = new AWSSigner(credentialsProvider, "eu-west-1", "es", clock);

esSinkBuilder.setRestClientFactory(
    restClientBuilder -> restClientBuilder.setHttpClientConfigCallback(
        callback -> callback.addInterceptorLast(new AWSSigningRequestInterceptor(awsSigner))
    )
);

esSinkBuilder.build();

シリアル化可能なリクエストのインターセプターを取得する必要があるため、GitHub リポジトリの実際のコードは少しですがより高度であることに注意してください。けれども、リクエストに署名するための基本的なアプローチは変わりません。

Flink アプリケーションをモニタリングおよびデバッグする

Kinesis Data Analytics for Java アプリケーションの実行中は、Flink を実行しているクラスターに直接アクセスすることはできません。これは基盤となるインフラストラクチャがサービスによって完全に管理されているためです。ただ API を通してサービスとやりとりするだけです。ただし CloudWatch と CloudWatch Logs を介すれば、それぞれのメトリクスとログ情報を取得できます。

Kinesis Data Analytics for Java アプリケーションはアプリケーション全体のメトリクスからアプリケーションのオペレーターの個別の処理におけるメトリクスまで、さまざまな運用上のメトリクスを公開しています。どのレベルの詳細が目的に適しているか、または必要とされているかを制御できます。事実、前のセクションで使用したメトリクスはすべて CloudWatch を通じて取得したものです。

運用上のメトリクスに加えて、CloudWatch Logs にメッセージを書き込むように Kinesis Data Analytics for Java アプリケーションを設定することもできます。この機能は Apache Log4j や Simple Logging Facade for Java (SLF4J) などの一般的なロギングフレームワークと、シームレスに統合しています。そのためデバッグや運用上の問題の原因を特定するのに役立ちます。

Kinesis Data Analytics for Java アプリケーションのログ記録を有効にするには、次のようにアプリケーションを起動するときに既存の CloudWatch のログストリームをログ記録オプションとして指定するだけです。

final Logger LOG = LoggerFactory.getLogger(...);

LOG.info("Starting to consume events from stream {}", flinkProperties.getProperty("InputStreamName"));

ログメッセージを CloudWatch Logs に保存した後は、CloudWatch Logs Insights を使用してクエリおよび分析が簡単に実行できます。

結論

この投稿では、Apache Flink および Kinesis Data Analytics for Java アプリケーションに基づいた、信頼性があり、スケーラブルで、可用性の高いストリーミングアプリケーションを構築しました。それだけでなく、毎秒最大 2 万 5 千個のイベントをほぼリアルタイムで取り込みかつ分析しながら、さまざまなコンポーネントの拡張も行いました。このシナリオは多くの部分でマネージドサービスを使用することによって実現できたため、基盤となるインフラストラクチャのプロビジョニングと設定に時間を費やす必要はありませんでした。

この投稿で使用しているアプリケーションと AWS CloudFormation テンプレートのソースは、参考として GitHub から入手できます。Flink アプリケーションの詳細と基盤となるサービスの設定を詳しく調べることができます。このようにして、インフラストラクチャの管理と運用に時間を費やす必要がなくなり、ストリーミング方式でデータを分析することに集中できるようになると、何を構築したいですか?

 

著者について

Steffen Hausmann は、AWS のスペシャリストソリューションアーキテクトです。