カスタムアクションをデプロイする 3 つの方法

利用開始

カスタムアクションの最速のデプロイ方法は？ 最も汎用性が高く、ワークフローを完全にカスタマイズできるのは、どのような設定でしょうか？ カスタムアクションを受け取って処理するために選択する環境は、最終的なワークフロー手順でデータを使用して実行できることを決定する重要な要素です。 基本的な選択肢は次のとおりです。

1. Zapier、Integromat、Microsoft Power Automate などの自動化プラットフォームを使用したノーコードデプロイ
2. AWS Lambda や Azure Functions などのローコードソリューション。完全にメンテナンスされた環境で、シンプルなスクリプトを「ジョブ」として実行可能
3. お客様が運用および保守するサーバー

次の図に、カスタムアクションのアーキテクチャを示します。

ノーコード：Zapier へのデプロイ

Zapier の「クリックで作れる」インターフェイスは、アセット、コメント、ステータスイベントを Frame.io から一般的なアプリや生産性ツールに送信するための基本的なオートメーションに適しています。

長所：

• 使い方が簡単です。 ポイントアンドクリックでオートメーションを作成できます。
• Zap 履歴は Zapier のランタイムログツールで、各オートメーション実行での各ワークフロー手順のデータ I/O がまとめられています。
• プレミアムアカウントを購入すると、オートメーションに分岐ロジックを追加するためのツールであるパスを利用できます。

短所：

• Zapier の Webhook サポートには制約があり、カスタムアクションの実行時に Frame.io ユーザーに返す詳細なメッセージやインタラクションをサポートしていません。 この制約について、Zapier のサポート文書では次のように説明しています。

私たち [Zapier] は、Webhook の背後に Zap があるかどうか、またはそれが一時停止されているかどうかによらず、Webhook の収集時に、デバッグ情報のペイロードを含む成功メッセージを必ず返します…レスポンスは Zap がトリガーされる前に送信され、Webhook リクエストで実行されるので、Catch Hook URL に送信するリクエストへのレスポンスをカスタマイズする方法はありません。

• カスタムアクションが正しく機能していることを確認する際、Zapier の UI は煩雑な場合があります。 例えば、テスト中にテストデータをチェックして更新する必要があります。テストデータがライブデータと一致しない場合には、Zap 設計が実際には正しくても、Zapier が「偽陰性」をスローしてエラーを示すことがあります。 File URL などの重要なデータが、タスクはそれを予期しているのに利用できない場合、Zap がエラーで終了したり、予期した機能を実行しなかったりすることがあります。

ローコード：AWS へのデプロイ

カスタムアクションを AWS の API Gateway に送信して、Amazon の巨大なクラウドサービスと統合できます。 最もシンプルなパターンは、カスタムアクションに含まれる Frame.io イベントを、サーバーレス関数を実行するためのコンピューティングサービスである AWS Lambda に中継することです。 ファイルアーカイブサービスの設計例を次に示します。

長所：

• サービスに課金される前に、AWS 無料利用枠で毎月 320 万秒のコンピューティング時間が付与されます。
• API Gateway と Lambdas は、CloudWatch や X-Ray などの優れたテスト・監視ツールをサポートしています。
• サービスを拡張すると、大規模なファイルサイズ（500 GB 以上）に対応できます。

短所：

• 複数のサービスをつなぎ合わせたり（Webhook -> API Gateway -> Lambda 1 -> Lambda 2）、AWS Fargate のような新しいサービスの使い方を習得したりするのに、時間がかかる場合があります。
• AWS ドキュメントは、最新情報ではなかったり、重要な詳細情報が不足していたりすることがよくあります。 例えば、API Gateway を設定する場合に、ペイロードが Base64 エンコードされるかどうかを見極めるのは簡単ではありません。
• 構成が概して少々複雑です。

AWS へのカスタムアクションの導入の詳細手順については、ガイドを参照してください。 注意：カスタムアクションは、AWS に限らず、任意のクラウドコンピューティングサービス（Azure、Google Cloud Platform、Digital Ocean など）にデプロイできます。

サーバーの実行と独自コードのホスト

クラウドサービスは非常に便利ですが、データを全体的に制御するためのワークフロー用に、お客様が独自のサーバーを開発して導入する状況も考えられます。

当社の DevRel チームでは、Python での FastAPI サーバーの開発が好まれています。 これらは簡単に作成でき、カスタムアクションのリクエスト／レスポンスパターンに適しています。

長所：

• データのエンドツーエンドのフローを制御する。 これについては何の驚きもありません。
• クラウドへの追加の公開なしに、NAS またはファイルシステムにデータを同期する。

短所：

• サーバーの管理、独自のセキュリティ機能の構築、ネットワーク検出の処理、負荷対策などが必要。

こちらで用意したサンプルコードを複製して、カスタムアクションを処理する FastAPI サーバーをデプロイしてみましょう。

お客様のニーズに最適な設計について話し合いましょう

要件をコミュニティに投稿してください。お客様のワークフローに最適な設計の見極めをお手伝いします。