それAmazon AppFlowでよくない？
Amazon AppFlowの話を出すと意外と知らない方が多くて、はぇ～ってなってます。
便利だし個人的には好きなサービスなので、これを機に知ってもらいたいなぁ…と思いながら書きます。
Amazon AppFlowを簡単に
Amazon AppFlowはSaasとAWS間のデータ転送をコーディングなしで実現できるサービスです。
一応SaasとAWS間と記載していますが、AWSサービス間のデータ転送（S3→S3とかS3→Redshiftとか）も実現可能です。
SalesforceとかServicenowとかDatadogとか諸々、Saasについてはみなさんご利用されていると思います。
その際、例えばServicenowだとテーブルの情報とか、Datadogとか監視系だとログ、メトリクスなどの情報をバックアップみたいに取得して保管しておいたり、そのデータをさらに分析などに利用したりすることがあるんじゃないかなと思います。
じゃあこういう場合ってどうやって転送させてますか？
Amazon AppFlowを使わない場合
１番初めに思いつくのは、データ取得のためのスクリプトを作って、それをインスタンスとかLambdaみたいなところで日次で動かして転送するとかかなと思います。
正直、コーディングスキルがあれば上記の方法でも特段問題ないとは思います。
ただLambdaで稼働させている場合などはデータ量が増えてくるにつれて実行時間が長くなって15分の制限に引っかかったりするんですよね（1敗）
また常時起動してるものに相乗りする形で動かせればよいですが、これだけのためにインスタンスを別途用意して管理するとかなると、それもそれで個人的には「うーん」となってしまいます。
Amazon AppFlowのメリット
フルマネージドであるため上記のようなデータ容量による実行基盤の時間の課題や管理問題などを解消しつつ、以下のようなメリットがほかにあるかなと思います。
- UIがわかりやすい＋コーディングが不要により迅速な構築が実現可能
- マネージドあるあるの使った分だけ課金で実行基盤の管理などが不要
- Privatelinkが有効になっているSaasアプリケーションであればインターネットに出さずにプライベートなデータ転送が実現可能
※AppFlowの細かい機能とかメリットとかはこちらを見てもらえればと思います。
実際にフローを作成してみる
とりあえず作るべ～ってことで今回はSlack→S3へとデータの転送を行う前提で進めます。
まずはSlack側で準備があるのでやっていきましょう。
ちなみにココとかココを参考にやっています。
Slackの設定
適当にワークスペース作成しましょう（既存のもの利用するのであれば不要）
App作成のところに飛んで、Create an Appします。
From scratchを選択
App NameとAppを入れ込むためのWorkspaceを選択してCreate App
遷移先のBasic InformationのところにApp Credentialsが表示されていると思うので、ClientIDとClient Secretをメモっておきましょう。
あとでAppFlowのコネクタを構築するときに利用します。
左のペインの「OAuth＆Permissions」を選択してRedirectURLとPermission Scopeを設定していきます。
Add New Redirect URLを押して、以下の通り入力してAdd押します。
https://ap-northeast-1.console.aws.amazon.com/appflow/oauth
入力したらSave押しておきましょう。
今回はAppFlowのコネクタは東京リージョンに作成するのでap-northeast-1にしていますが、太字の部分は作成するリージョンによって変更してください。
次にUser Token Scopesを設定していきます。
ここで設定したモノがAppFlow側で許可されるものになります。
とりあえずこんなもんにしておきますが、必要に応じて追加してください。
いろいろ設定終わったのでWorkspaceにAppインストールします。
左ペインのInstall Appをクリックして遷移先でInstall to Workspaceクリックします。
権限リクエストが来るので許可します。
一応Slackの方でちゃんと入ってるかは確認しておきましょう。
AWS側の設定
いよいよAWS側です。
AppFlowのサービス画面を開いて、フローを作成をクリックします。
フロー名を入れて次へを押します。
※今回はデフォルトKMSでデータの暗号化を行いますが、カスタマーマネージドキーで暗号化する場合は、「暗号化設定をカスタマイズ」にチェックを入れて別途設定してください。
送信元でSlackを選択して新規接続を作成をクリックします。
接続名は適当に入力して、クライアントIDとクライアントシークレットは先程Slack Appの設定でメモったものを、ワークスペース名にはワークスペースの名前を入れて、「接続する」を押します。
OAuthの画面が開くので許可するを押しましょう。
ウインドウが閉じたらSlackオブジェクトとSlackチャネルが選択できるようになっています。
（現状だとSlackオブジェクトはConversationsのみなのかな…）
今回はS3に送信するので送信先としてS3を選択し、バケットを選択します。
フローを実行したときにGlueのData Catalogテーブルを作成したり、S3に入れ込む際のファイル形式を変更（json/CSV/Parquet）できますが、今回は特段変更せずにいきます。
今回は、フローの実行トリガはスケジューリングせずにオンデマンドのままで設定します。
送信元と送信先のデータフィールドのマッピングが細かくできますが、今回は一括処理を選択します。
パーティション設定や妥当性確認については今回は変更せず。
とりあえず全量取得したいのでレコードフィルタリングもオフで。
設定に問題がなければ「フローを作成」を押します。
正常に作成されると以下のように緑ハイライトバーが出ます。
確認
今回は実行トリガをオンデマンドにしているので、フローを実行しましょう。
テスト用のSlackチャネルの中がホントに最低限のものしか入力されていないのですぐ終わりました。
実際にS3にモノが入っているか確認しましょう。
ちゃんと入ってますね。ﾖｶﾀ・・・。
中身は以下のようになっていてチャネルへの参加履歴とテキストチャット３つがしっかりとれていそうです。
テキスト内容見せれなくて申しわけのNASAですが、ちゃんと内容もjsonの中に記載されてたものと一致してました。
まとめ
というわけで軽い説明と実際にSlackからS3へとチャットデータを転送するフローを構築してみました。
今回は実施しませんでしたが、転送するデータを選択することで不要なデータの転送を防止したり、データの妥当性確認などができたりと凄く便利な機能がいくつもあります。
これまでコーデイングして複雑な処理をしていたり、それによって増加していた構築工数などの低減化を図ることも可能です。
もちろんデータの転送にあたってめちゃくちゃ高度な加工をしたりする場合は、AppFlow単体だとできないこともありますが、まず格納用のS3への転送はAppFlowで、そこから先はGlueなりLambdaなりで加工するなど工夫の仕方は無限大です。
単純なデータ転送フローの構築にあたっては、まずAmazon AppFlowの検討をしてみてはいかがでしょうか！！！！！！
みんなが使ってくれることでコネクタもたくさん増えてくれるよね、そうだよね○○太郎・・・
Discussion