IICS CDIのファイルリスナがS3へリスニングする際のAPIと料金について調べてみた
はじめに
データアナリティクス事業本部ビッグデータチームのyosh-kです。
IICS CDI ファイルリスナは、定義した場所にあるファイルをリスニングし、ファイルが到着or更新or削除されたことをトリガーとしてタスクフロー、ファイル取り込みタスク、B2B Gatewayパートナーフローなどを実行するコンポーネントです。S3といったクラウドストレージにアクセスし、ファイルをリスニングして読み込むことができます。今回は、IICS CDI ファイルリスナがS3へリスニングする際のAPI料金について調べたいと思います。
前提条件
- S3に格納されているファイルをリスニングし、ファイルリスナをトリガーとしてタスクフローを実行する条件で実装していきます。
- 事前にS3Connectorで任意のBucketへ接続できることを前提とします。
- 以下、処理の流れになります。
- ①ファイルリスナでS3のファイルをリスニングし、ファイルが到着したことをトリガーとしてタスクフローをSecure Agent上で実行します。
- ②タスクフローの中でマッピングを呼び出し、ソースをS3としてUnloadします。
- ③ターゲットをS3の別のPathとしてファイルをInsertします。
タスクフローの作成
マッピング
マッピングのソースには、任意のS3のパスを設定します。
マッピングのターゲットにも任意のS3のパスを設定します。 S3 Bucketはソース、ターゲットともに同一ですが、Pathを分けるようにしています。
マッピングタスク
先ほど作成したマッピングを選択し、それ以外はデフォルトのまま作成します。
タスクフロー
データタスクを追加し、先ほど作成したマッピングタスクを選択したらひとまずOKです。
ファイルリスナの作成
ファイルリスナ
ファイルリスナについては以下のように設定します。
| 項目 | 値 |
|---|---|
| ファイルリスナの名前 | 任意の名前 |
| ランタイム環境 | Secure Agent |
| ソースタイプ | コネクタ |
| ステータス | 有効 |
| 接続タイプ | Amazon S3 |
| 接続 | ファイルをリッスンするBucketと接続するコネクタ |
| フォルダパス | リッスン対象のファイルが格納されるパス |
| パターンタイプ | ワイルドカードを選択 |
| ファイルパターン | *(全て)を指定 |
| サブフォルダ内のファイルを確認 | フォルダパス内にあるサブフォルダもリスニングするかの設定ですが、今回はチェック無しを選択。 |
| アクション後 | ファイルを削除するかどうか選択できますが、今回は「なし」を選択。 |
| ファイル到着時に | 「到着」：リスニング対象のファイルが格納された時。 「更新されました」：リスニング対象のファイルが更新された時。 「削除されました」：リスニング対象ののファイルが削除された時。 |
| ルールを満たした場合はチェックを停止 | 最初のイベントが発生するとファイルリスナはフォルダのリスニングを停止します。 |
| ファイルの安定性を確認 | ファイルサイズが大きい場合にフォルダパスへのファイル書き込みが完了したかどうかを確認するチェックです。 |
| 最初の実行時にファイルが存在するかどうかを通知 | ファイルリスナを最初に実行する際に、既にフォルダパスにあるファイルについて通知するかどうかのチェックです。 |
| ファイルリスナが実行中でない場合にイベントを除外 | ファイルリスナが実行されていないときに発生するファイルイベントを除外するかどうかを決定するチェックです。 |
| スケジュール | 15秒間隔でファイルをリッスンしてどのようなAPIリクエストが送られてくるかを確認します。 |
| 障害管理 | 障害時の設定ですが、今回は特に使用しません。 |
コネクタソースタイプ用のファイルリスナの設定
FAQ: What is the use of "check file stability" flag in File Listener?
タスクフローのファイルリスナの設定
タスクフローとファイルリスナを紐づけるために、「開始プロパティ」から「バインディング」に「イベント」、「イベントソース」から「FileListenerTask」の先ほど作成したファイルリスナを選択します。選択後にパブリッシュをして紐付けの完了です。
ファイルリスナのリスニングについて
How does file listener work when the event type is set to Arrive
上記の資料の中でファイルリスナがトリガーとして通知するまでの処理の流れが記載されていましたので、簡単にみておきたいと思います。
- File listener will poll the provided directory every X seconds defined as per the file listener configuration.
- If the files pick for first run is true, it will match all the defined file patterns and picks the file.
- After the first pick, it takes a snapshot of the directory every X seconds. It will compare the previous snapshot and the current snapshot.
- After the comparison, the new files which have been arrived are taken into note.
- If the file stability is set for 10 seconds(default), it again checks after 10 seconds if the file size is changing or not. (This is to make sure that it won't pick the file which is still being copied/moved/written/incomplete).
- After step 5, it picks all the files and notifies to the associated task.
DeepLで日本語訳すると以下になります。
- ファイルリスナは、ファイルリスナの設定に従って定義されたX秒ごとに、提供されたディレクトリをリスニングします。
- 最初の実行のためのファイルのピックが真である場合、それはすべての定義されたファイルパターンに一致し、ファイルを選択します。
- 最初のピックの後、それはX秒ごとにディレクトリのスナップショットを取ります。それは前のスナップショットと現在のスナップショットを比較します。
- 比較の後、到着した新しいファイルは注意に取られます。
- ファイルの安定性が10秒に設定されている場合（デフォルト）、それは再び10秒後にファイルサイズが変化しているかどうかをチェックします。(これは、まだコピー/移動/書き込み/未完成のファイルを選択しないことを確認するためです）。
- 手順5の後、すべてのファイルをピックアップし、関連するタスクに通知します。
ファイルを指定した間隔でリスニングして、スナップショットの差分がないかをチェックしているようです。
AWS側の設定
今回、ファイルリスナが15秒間隔でS3へリスニングするため、その際のAPIログを取得したいと思います。そのためにCloudTrail LakeでS3のアクション記録を取得しようと思います。
※ S3のサーバーアクセスログはS3をサーバーとして見たときにアクセスログなのに対して、Cloudtrailは実際に実行されたアクションの記録を取るものなので、実際にどのようなアクションが呼ばれたかというのを知るためにも、Cloudtrailで取る必要があると考えました。
Athena を使用して Amazon S3 サーバーのアクセスログを分析するにはどうすればよいですか?
Amazon S3 のログ記録オプション
[アップデート] CloudTrailログ分析環境が超絶簡単に手に入る！「CloudTrail Lake」がリリースされました
【初心者向け】AWS CloudTrail Lakeとは
AWS CloudTrail で s3 ls コマンド(バケット指定あり)の api コール記録を確認する方法を教えてください。
CloudTrail Lake
サーバーアクセスログを格納するためのログバケットを作成します。以下の記事の内容も参考に設定をしてみてください。
CloudTrail Lakeで特定のS3バケットのデータイベントのみを収集するイベントデータストアを作成してみた
まずは、CloudTrailの画面からLakeのイベントデータストアを作成します。
イベントデータストア名、データの保存期間に任意の値を入力します。
イベントタイプはデフォルトのままで、CloudTrailイベントにはデータイベントを選択します。
データイベントの設定として、以下を設定します。
| 項目 | 値 |
|---|---|
| データイベントタイプ | S3 |
| ログセレクターテンプレート | カスタム |
| フィールド | resource.ARN |
| オペレーター | 次で始まる: |
| Value | arn:aws:s3:::cm-kasama-infa/ |
※Valueについては、/をBucketの末尾につけることが重要です。例えば、Value末尾を「bucket-name」とスラッシュなしにした場合、「bucket-name-log」というバケットのデータイベントも収集されてしまいます。
最後の確認画面で、イベントデータストアの作成ボタンを押下すれば完了です。
ファイルリスナの開始
2023/04/18 19:56:43より開始し、2023/4/18 20:17:08にファイルイベントでジョブを起動させました。
IICSジョブは正常に完了しました。
CloudTrail Lakeの解析
ここまでが事前の準備でしたが、いよいよここからが本題です。
ファイルリスナのAPI確認
2023-04-18 10:56:43.000〜 2023-04-18 11:56:43.000の15秒間隔でリスニングする際のClouldTrail Lakeを確認していきたいと思います。
以下のSQL文をCloudTrail Lakeのクエリから実行します。SQLを実行する前に結果をS3に保存にチェックを入れることでS3 Bucketにクエリ結果がcsvファイルとして出力されます。
select userIdentity,eventTime,eventSource,eventName,awsRegion,sourceIPAddress,requestParameters FROM <イベントデータストアID> where eventTime >= '2023-04-18 10:56:43.000' and eventTime <= '2023-04-18 11:56:43.000' and sourceIPAddress = '<Secure Agent ServerのIP>' order by eventTime asc
S3に出力されたcsvファイルを確認します。
SQLを実行した結果、Secure Agentから15秒毎に4リクエストが実行されていました。
以下、リクエストの詳細になります。同一のHeadBucektを2回、delimiterの有無でListObjectsを2回リクエストしていることがわかりました。
| eventName | requestParameters |
|---|---|
| HeadBucket | {bucketName=cm-kasama-infa, Host=cm-kasama-infa.s3.amazonaws.com} |
| HeadBucket | {bucketName=cm-kasama-infa, Host=cm-kasama-infa.s3.amazonaws.com} |
| ListObjects | {bucketName=cm-kasama-infa, encoding-type=url, prefix=source/, Host=cm-kasama-infa.s3.amazonaws.com} |
| ListObjects | {bucketName=cm-kasama-infa, encoding-type=url, prefix=source/, delimiter=/, Host=cm-kasama-infa.s3.amazonaws.com} |
ファイルイベント起動時のAPI確認
2023-04-18 11:17:56.000 〜 2023-04-18 11:17:58.000 にファイルイベント起動があることを確認しました。対象のPrefixには
flight_data_header.csv と flight_data_202303041152.csv の2ファイルが存在するので、それぞれへのリクエストがありました。1回のファイルイベント起動でPutObjectを除き、合計20回リクエストしていました。
| eventName | 回数 |
|---|---|
| HeadBucket | 9 |
| ListObjects | 9 |
| GetObject | 2 |
| PutObject | 1 |
※ PutObjectについては、ETL処理実行時のTargetに同Bucketを指定しているため記録されたログになります。
S3 API料金計算
これまでの調査で、ファイルリスナのS3 API料金はファイルリスナのリスニング間隔やイベント回数などによって大きく変化することがわかりました。今回は以下の設定で料金計算をしていきたいと思います。
- S3 Bucket
- 東京リージョンに配置
- リスニング対象パスには「header.csvを事前に配置」
- 1日1回のみファイルが格納される
- ジョブが終了したらイベント時に格納されたファイルは別パスに移動させる。(常にイベント起動前はheader.csv」のみの想定)
- ファイルリスナ設定
- ファイルパターン：※
- サブフォルダ内のファイルを確認：チェック無し
- ファイル到着時に：「到着」にチェック
- 次ごとに確認：15秒
- 実行：日次
- 開始日：2023/01/01
- 無期限に繰り返す：チェック
- 開始：0:00
- 次まで確認：23:55とします。
- タイムゾーン日本標準時、東京
※ 東京リージョンの場合、GET, HEADリクエスト共に1,000リクエストあたりS3標準で0.00037USD(1リクエストあたり0.00000037USD)です。
※ LISTリクエストは1,000リクエストあたりS3標準で0.0047USD(1リクエストあたり0.0000047USD)となります。
ファイルリスナーの料金
先ほどの調査結果より、15秒間に4回のリクエストでしたので、15秒間あたりの料金は以下になります。
0.00000037(HeadBucket) * 2 + 0.0000047(ListObjects) * 2 = 0.00001014(USD)
ファイルイベント起動時の料金
先ほどの調査結果より、ファイル起動時は20回のリクエストでしたので、料金は以下になります。
0.00000037(HeadBucket) * 9 + 0.0000047(ListObjects) * 9 + 0.00000037(GetObject) * 2 = 0.00004637(USD)
計算
| 項目 | 概要 | 式 | USD | 円 |
|---|---|---|---|---|
| 1分間の料金 | 15秒の料金を1分間に | 15:60 = 0.00001014:x | 0.00004056 | 0.0054 |
| 1時間の料金 | 1分間の料金を1時間に | 0.00004056 * 60 | 0.0024336 | 0.33 |
| 1日の料金 | (23時間 * 1時間の料金)＋(55分 * 1分間の料金) +ファイルイベント起動時の料金 | (23 * 0.0024336) + (55 * 0.00004056) + 0.00004637 | 0.05824997 | 7.82 |
| 1ヶ月(28日)の料金 | 28日 * 1日の料金 | 28 * 0.05824997 | 1.63099916 | 218.82 |
| 1ヶ月(30日)の料金 | 30日 * 1日の料金 | 30 * 0.05824997 | 1.7474991 | 234.45 |
| 1ヶ月(31日)の料金 | 31日 * 1日の料金 | 31 * 0.05824997 | 1.80574907 | 242.27 |
| 1ファイルリスナの1年間の料金 | (28日の料金 * 1) + (30日の料金 * 4) + (31日の料金 * 7) | (1.63099916 * 1) + (1.7474991 * 4) + (1.80574907 * 7) | 21.26123905 | 2,852.51 |
| 50ファイルリスナの1年間の料金 | 50ファイルリスナ * 1ファイルリスナの1年間の料金 | 50 * 21.26123905 | 1063.0619525 | 142,625.71 |
| 100ファイルリスナの1年間の料金 | 100ファイルリスナ * 1ファイルリスナの1年間の料金 | 100 * 21.26123905 | 2126.123905 | 285,251.41 |
※ 4/22現在、1ドル=134.17円の場合の計算です。
最後に
私が独自で調べた料金体系ですので、大きくは間違っていないと思いますが、参考程度にしていただけたらと思います。1ファイルリスナを24時間設定で運用すると年間で約3000円かかりますので、コストを抑えたい場合は、開始と次まで確認を要件に沿った時間に変更し、秒単位のリアルタイム性が求められるデータ連携でなければ、次ごとに確認の間隔を15秒以上に伸ばすことを検討するしてみると良いと思いました。
