CloudFlow DatastoreがSQLに対応

フロー内でPostgreSQLを使って、Datastoreテーブルのクエリ・再構成・メンテナンスができるようになりました。

Datastoreテーブルは、フローの実行をまたいで情報を記憶するのが得意です。処理済みのリソース、アカウントごとのしきい値、ジョブの最終実行時刻などを保持できます。しかし、そのデータを横断して何かを計算しようとした途端、壁にぶつかっていました。Get、Insert、Upsert、Deleteで行の取得や保存はできても、列の平均を求めたり、2つのテーブルを結合したり、「今日の数値は過去30日間と比べて異常か?」という問いに答えたりすることはできません。そうしたロジックはCodeノードに書くしかなく、多くの場合、どこにも実装されないままでした。

この課題が解消されました。Datastoreノードに新しい Run SQL アクションが追加されました。

できること

Run SQLは、CloudFlow内のDatastoreテーブルに対して、完全なPostgreSQL構文のステートメントを実行します。テーブルは名前で参照でき、前のステップやフロー変数の値は :name パラメータでバインドできるため、Date/time変換で算出した日付をそのまま WHERE 句に組み込めます。エディタは入力中にステートメントを検証し、SELECT の場合はその場で出力スキーマを導出するため、フローを実行する前から後続のノードで各列を参照できます。

対応するのは SELECT だけではありません。このアクションは INSERT、UPDATE、DELETE に加え、自己メンテナンスするテーブルに必要なDDL(CREATE TABLE、列の追加・削除、一意制約)もカバーしています。フローが自ら履歴テーブルを作成し、そのデータを集計し、保持期間を過ぎた行を削除する。これらすべてが、わずか3つの短いステートメントで実現できます。ステートメントは、組織のテーブルにスコープを限定した制限付きデータベースロールの下で実行されます。また、データを変更するステートメントをテストする際には、実際の行に触れる前にエディタが確認を求めます。

まずはチュートリアルから

この機能の大部分を1つのフローで活用できる実践例として、Cost spike sentinel(コスト急増センチネル) を用意しました。毎朝、前日のサービス別AWS支出をDatastoreテーブルに記録し、CTEを使った1つの SELECT で各サービスを直近30日間の平均と比較して、ベースラインを50%以上上回っているサービスだけを返します。フィルターとSlack通知でこれをアラートに変え、DELETE でテーブルの履歴を90日分に保ちます。外部データベースもウェアハウスのジョブも不要です。

Cost spike sentinelチュートリアルでは、実際に使用するSQLも含めて、ゼロから構築する手順を解説しています。

Run SQLは、CloudFlowでDatastoreにアクセスできるすべてのユーザーが今すぐ利用できます。この機能を使って何かを構築した際は、特にこれまで外部データベースが必要だった実行をまたぐ分析などがあれば、ぜひお知らせください。最高のフィードバックは、実際のテーブルと実際のクエリから生まれます。