はじめに
先日開催された『クラウド食堂 #5 ~運用にまつわるLT会~』に参加＆LT登壇してきました。
発表タイトルは「AWSのサービス終了に備えるシステム運用」で、資料は👇️です。
AWSでは、次々に新しいサービスや機能アップデートが発表される裏側で、終了（あるいは新規受付終了）していくものも一定数存在します。
そういった終了がアナウンスされたサービスを本番ワークロードで利用している場合に、運用面でどのように立ち回っていくかという地味な内容でしたが、何かの参考になれば幸いです。
限られた時間だったので、S3 SelectとKinesis Data Analytics for SQLアプリケーションを取り上げました。それ以外にも、Cloud9, CodeCommit, CloudSearchなど、一定の利用者がいるサービスでも容赦なく新規利用受付が終了していたりするので、LTでは「情報をキャッチアップして早めに備えて対処しましょう」というメッセージで締めくくりました。
Kinesis Data Analytics for SQLアプリケーションからAmazon Managed Service for Apache Flinkへの移行
LTでお伝えしたかった大事なメッセージとしてもう一点、「代替サービスへの移行は思っているより大変な時もあるよ」という点があります。
具体例として、Kinesis Data Analytics for SQLアプリケーションからAmazon Managed Service for Apache Flinkへの移行について紹介します。
移行についてはAWS公式ブログに詳細にまとめられているので、まずは目を通しておくとよいでしょう。
上記のブログ記事からこぼれる話として、KDA SQLで提供されていた便利な機能の中には、Flinkに存在しない独自実装のものがあり、Flink側で完全に同じ挙動を実現するのが難しいケースがあります。本ブログ記事ではそのあたりを拾っていきます。
Stagger Windows
一番大変だったのは、こちらのデータ遅延処理に関する対応でした。
前提として、私たちのシステムはIoTのシステムであり、様々なメーカーのデバイスを取り扱っています。IoTのシステムでは、行儀よくリアルタイムにデータが定時送信されるだけではなく、データの遅延や順番の逆転(Out of Order) が日常的に発生します。
KDA SQLのStagger Windows（ずらしウインドウ）は、データの遅延も含めて、データが受信した場合の時刻を起点としてウィンドウが開き、ウィンドウ処理の境界を柔軟に調整する機能です。
例として下の図では、Window1〜Window3が順序よく到着し順序よく開かれたウィンドウ、Window4が遅延データとして開かれたウィンドウを表します。
Flinkには全く同じ機能はありませんが、Watermark、Allowed Latenessという設定によって、データの遅延に対する考慮がされています。
-
Watermark:
- Watermarkは、イベント時間に基づいて「これ以前のデータはすべて処理された」ことを示すタイムスタンプのマーカーであり、ウィンドウ操作などの処理をいつ確定させるかを判断するために使用されます。ざっくり言うと、「この時間までに生まれたデータは、もうだいたい全部届いたよ」と知らせてくれる区切りです。
-
Allowed Lateness:
- Watermarkより遅れて到着したデータについて処理の対象として許容するかどうかを設定する時間です。デフォルトは
0なので、Watermark よりも遅れて到着したデータはすぐに破棄されます。
- Watermarkより遅れて到着したデータについて処理の対象として許容するかどうかを設定する時間です。デフォルトは
設定方法ですが、Kinesis Data StreamsからDataStream APIを介してデータを処理するアプリケーション（カスタムロジック）内で設定します。
「多少の遅延」であればFlinkでもうまく取り扱うことができますが、「大きな遅延」についてはFlinkで取り扱うのは難しいと思います。
WatermarkやAllowed Latenessの設定値は、計算のリアルタイム性やリソースの消費とのトレードオフになります。Watermarkがなかなか進まないとウィンドウ計算（集計など）の結果の出力が遅れますし、Allowed latenessの期間が長いと結果が確定してダウンストリームに渡されるまでの時間が長くなってリアルタイム性が低下します。
私たちが取り扱うシステムでは、データが1日以上遅延する場合もあります。システム要件として、大きな遅延データについて、処理のリアルタイム性は妥協できますが、処理・分析そのものは取りこぼさないことがMUSTでした。
そこで移行後の構成ではFlinkで遅延データを適切に扱うために、Watermark、Allowed Lateness、そしてSide Outputs（サイド出力）を組み合わせて、以下のような二系統処理を実装しました。
Side Outputsを利用した遅延データ処理では、Allowed Lateness を超えて到着したデータ（Discardされるデータ）をメインストリームから分離し、別のストリームとしてキャッチします。これにより、極端に遅れたデータも失わずにケアすることが可能になります。
データの事前処理Lambda
KDA SQLでは、データの事前処理としてLambda関数を使用することができます。
私たちのシステムでは、Kinesis Data Streamsへのレコードの投入の際に、レコードの集約(aggregation)を行っています。そのため、事前処理用のLambda関数で集約解除(deaggregation)を行っていました。
Flinkの場合はこのあたりの前処理は KinesisDeserializationSchema として実装します。
サンプル(Java)も公開されています。
リファレンスデータ
KDQ SQLでは「リファレンスデータ」として、S3上に置かれた設定ファイルをテーブルとして参照してSQLで利用することができます。
Flinkの場合「コネクタ（テーブルAPIコネクタ）」の仕組みを使うことでほぼ同じことができます。
おわりに
Kinesis Data Analytics for SQLアプリケーションからAmazon Managed Service for Apache Flinkへの移行を深堀りし、サービス終了に備えるための運用についての紹介でした。
なお今回の移行についてはAWSのソリューションアーキテクトの方にも相談に乗っていただき、安心感をもって進めることができました🙇♂️
間もなくre:Invent 2025が始まりますし、それに先立って様々なAWSのアップデートが発表されていっていますね！
生まれゆくもの、消えゆくもの、両方キャッチアップして、持続可能なAWSインフラを運用していきましょう！
Discussion