EventBridgeでAthenaの実行結果を受けとると完了待ちのポーリングが不要となる話

本記事は「AWS その2 Advent Calendar 2020」の17日目の記事です。

内容

今年2020年の3月より、Athenaのクエリの状態移行がEvengBridgeに対応しました。

つまり、これを使えば従来のように「forループでGetQueryExecutionを実行してAthenaの実行完了を待つ...！！」というポーリングが不要となります。革命ですね。
また、もしLambda経由でAthenaのクエリを実行などをする場合は、Lambdaの起動時間が圧倒的に節約されます。

設定方法

とりあえずLambda関数を用意する

EvengBridgeでルールを作成するときに、Lambda関数を選択する項目があるため、先に関数を用意しておきましょう

おおよその最低限の処理

def lambda_handler(event, context):

        currentState=event_dict['detail']['currentState']
        previousState=event_dict['detail']['previousState']
        query_execution_id=event_dict['detail']['queryExecutionId']

        if currentState == 'FAILED' and previousState =='RUNNING' :
           # 失敗した旨をSlackなどで通知する
           （割愛）

        if currentState == 'SUCCEEDED' and previousState =='RUNNING' :
           # query_execution_id を元に後続処理をする
           （割愛）

一応 previousState も見ていますが、SUCCEEDED or FAILEDだけ見ても良いのかもしれません。

いずれにせよ

print(json.dumps(event))

みたいな感じでeventの中身を一度見ると掴みやすいです。公式ドキュメントはこちらです。

後続処理に紐づけ得る情報が揃っているかを確認します。言い換えると、当然ながら EventBridgeで通知されるイベント内容を元に、全体設計をする必要があります。

EvengBridgeへ移動

ちなみにかつてAmazon CloudWatch Eventsと呼ばれていたものが、いまはAmazon EventBridgeと名前を変えています。

イベントパターン

イベントパターンを選択し、AWS→Athena→すべてのイベント、を選択します。

ターゲット

ターゲットとして「Lambda 関数」を選択し、機能という欄にLambda関数が一覧で表示されるのでここで選択します。

この後、ルールを作成すると自動的にLambda側にもトリガが設定されます。

注意点

何をもって処理対象とするかの判定の話

この機構を使うのであれば、Lambda経由の実行のためのワークグループなど、専用のワークグループを作成しておく必要があると考えます。
手動で流したものから何から拾ってしまうため、組織内などで利用する場合は特に注意が必要となります。

例えば1つしかワークグループが無い中で無条件で queryExecutionId を元に後続処理をしてしまうと、手動で流したクエリもその処理に乗ってしまいます。

簡易な設定としては「カスタムパターン」を選択して、以下のような形にすることでワークグループで絞られます(またはAWS→Athenaを選択したあとに「編集」をすると自動的にカスタムパターンとなります)。

{
  "source": [
    "aws.athena"
  ],
  "detail-type": [
    "Athena Query State Change"
  ],
  "detail": {
    "workgroupName": [
      "xxxxxxxxxx"
    ]
  }
}

運用してみて

注意点は一定あるかと思いますが、Lambda経由でAthenaを実行をしたいケースではLambda上でポーリング処理を持つと、Lambda自体のタイムアウトなどを含めどうしても綺麗にならない点がある点が、EventBridgeによりだいぶスッキリしました！