Webhook とは

Webhook は HTTP ベースのコールバック機能で、2 つのアプリケーション・プログラミング・インタフェース (API) 間の軽量なイベント駆動型の通信を可能にします。Webhook はさまざまな Web アプリケーションで使用され、相互のアプリケーションから少量のデータを受信します。また、GitOps 環境で自動化ワークフローのトリガーにも使用することができます。

Webhook はイベントソースを自動化ソリューションに接続することができるため、指定されたイベントが発生したときに IT アクションを実行する、イベント駆動型の自動化を起動する 1 つの方法となります。

API とは

API は、アプリケーション・ソフトウェアを構築および統合するための一連の定義、およびプロトコルです。API 間の通信は情報プロバイダーと情報ユーザーの間の契約とみなされることもあり、コンシューマー (呼び出し) から要求されるコンテンツとプロデューサー (応答) によって要求されるコンテンツを確立します。この関係はサーバー・アプリケーションを呼び出すクライアント・アプリケーションとも考えられます。このロールは、所定の状況でデータを要求するアプリケーションに応じて逆転します。  

Web API は通常 HTTP を使用して他のアプリケーションからデータを要求し、応答メッセージの構造を定義します。この構造は一般に XML または JSON ファイルの形式です。XML と JSON の両方とも他のアプリケーションが操作しやすい方法でデータを提示するため、好まれるフォーマットです。 

クライアント API がサーバー API にデータを要求するとき、呼び出しによって特定のイベントが発生したかを確認します。つまり、サーバーのデータがクライアントにとって役立つ方法で変更されていないかを確認します。このプロセス (ポーリングと呼ばれる) では、サーバーの API が該当するデータを送信するまで、クライアントは定期的に HTTP 要求を送信します。このデータはペイロードと呼ばれることもあります。 

クライアント・アプリケーションはサーバー・アプリケーションの状態を把握していないため、最新情報を取得しようとサーバーの API にポーリングし、特定のイベントが発生するまで何度も呼び出しを続けます。しかしサーバーは、情報が提供可能になって初めて要求されたデータを送信します。クライアント・アプリケーションは最新情報を要求し続け、該当するイベントが発生するまで待機します。

Webhook の違い

Webhook をセットアップするために、クライアントはサーバー API に一意の URL を提供し、認識したいイベントを指定します。Webhook のセットアップが完了すると、クライアントはサーバーにポーリングする必要がなくなります。指定されたイベントが発生すると、サーバーは該当するペイロードをクライアントの Webhook URL に自動的に送信します。 

Webhook はリバース API やプッシュ API と呼ばれることもよくあります。通信の責任をサーバーではなくクライアントに任せるからです。クライアントが HTTP 要求を送信する、つまりサーバーが応答するまでデータを求めるのではなく、 データが利用できるようになったときにサーバーはクライアントに HTTP POST 要求を 1 回送信します。その呼び名とは異なり、Webhook は API ではありません。API と連携して機能します。Webhook を使用するには、アプリケーションには API が必要です。 

Webhook という名前は、HTTP ベースの通信を意味する Web と、関係する可能性がある呼び出しやその他のイベントをアプリケーションにインターセプトさせるプログラミング機能のフッキングを示す hooking を組み合わせただけです。Webhook はサーバー・アプリケーションで発生したイベントをフックし、サーバーにペイロードをクライアントに Web 経由で送信するよう指示します。Jeff Lindsay 氏は 2007 年のブログ投稿「Web hooks to revolutionize the web」において、このコンセプトを世間に広めようとしました。

IT チームは Webhook で通信するアプリケーションを保護するためのさまざまな手法を使用しています。ほとんどの Webhook 対応アプリケーションは、ペイロードの要求ヘッダーにシークレットキーを追加しているので、クライアントはサーバーの ID を確認できます。Webhook は多くの場合、相互トランスポート層セキュリティ (mTLS) 認証で保護され、クライアントとサーバーの両方を検証してからペイロードを送信します。クライアント・アプリケーションが SSL 暗号化を Webhook URL に使用することも多く、転送されたデータの機密性を維持します。

Webhook の特長は以下のとおりです。

• ポーリングの必要性がない：クライアント・アプリケーションのリソースを節約できます。 
• 迅速にセットアップできる： アプリケーションが Webhook をサポートしている場合、サーバー・アプリケーションのユーザー・インタフェースから容易にセットアップできます。ここでクライアントがアプリケーションの Webhook URL を入力し、関心のあるイベントなど、基本的なパラメーターを設定します。   
• データ転送を自動化する：指定されたイベントがサーバー・アプリケーションで発生すると、ペイロードは即座に送信されます。この交換はイベントによって開始されるので、データがサーバーからクライアントに転送されると、リアルタイムのデータ転送と同様に、迅速に発生します。
• 特定の軽量ペイロードに適している： Webhook では送信するデータ量をサーバーが決定し、ペイロードの解釈と生産的な方法での使用はクライアントに任されています。クライアントはデータ転送の正確なタイミングやサイズを制御しないので、Webhook は２つのエンドポイント間の少量の情報を、多くの場合は通知の形式で処理します。

Webhook が使用される主な目的は、2 つのアプリケーション間の通信を単純化することですが、Infrastructure-as-code (IaC) ワークフローを自動化し GitOps プラクティスを実現するためにも使用できます。

IaC (Infrastructure as Code) とは 

IaC (Infrastructure as Code) は、手動のプロセスではなく、コードを使用してインフラストラクチャの管理とプロビジョニングを行うことを言います。IaC においてバージョン管理は重要な要素であり、設定ファイルは他のソフトウェアのソースコードファイルと同じようにソース管理を行う必要があります。インフラストラクチャをコードとしてデプロイするということは、インフラストラクチャをモジュラー・コンポーネントに分割し、自動化を使ってさまざまに組み合わせることもできるということです。

IaC を使用してインフラストラクチャ・プロビジョニングを自動化することにより、開発者は、アプリケーションを開発またはデプロイするたびに、サーバー、オペレーティングシステム、ストレージ、およびその他のインフラストラクチャ・コンポーネントのプロビジョニングと管理を手動で行う必要がなくなります。インフラストラクチャを体系化することで、プロビジョニングに使用するテンプレートを作成できます。これは手動で実行することもできますが、これらのプロセスは Red Hat® Ansible® Automation Platform など、エンタープライズレベルの望ましい状態 (desired state) のエンジンで自動化できます。

GitOps とは

GitOps は、IaC の進化形とみなされることも多いのですが、オープンソースのバージョン管理システムである Git を使用して、インフラストラクチャとアプリケーションの構成を管理するための戦略的アプローチです。GitOps プラクティスに従い、開発者は宣言的インフラストラクチャおよびアプリケーションの信頼できる唯一の情報源として Git を使用し、インフラストラクチャのプロビジョニングとデプロイメントの自動管理に Git プルリクエストを使用します。Git リポジトリにはシステムの全体の状態が含まれているため、変更の記録を確認して監査することができます。 

Webhook が役立つ場面

Webhook は Git 中心のデプロイメント・パイプラインの実装と管理に必要なステップを削減し、IaC ワークフロー全体を自動的に起動するために使用できます。git リポジトリを信頼できる情報源とする GitOps 環境では、Webhook は 2 つのアプリケーション間と同様に機能し、特定のイベントによってトリガーされると、1 つの API がもう片方の API にペイロードを送信します。違いは、Webhook をトリガーするイベントのタイプと、ペイロードの受信側の動作にあります。

このコンテキストでは、git リポジトリはサーバー・アプリケーションの役割をし、インフラストラクチャの状態を管理する望ましい状態のエンジンはクライアント・アプリケーションの役割を担当します。Webhook を使用すると、git リポジトリで変更が行われる度に望ましい状態のエンジンに通知することができます。コードの一部が更新されてリポジトリにプッシュされると、このイベントによって Webhook がトリガーされます。リポジトリはペイロードを望ましい状態のエンジンの Webhook アドレスに自動的に送信し、コードの変更を通知します。

望ましい状態のエンジンが自動化をサポートしている場合、これらの Webhook は IaC ワークフローを起動し、コード変更を自動化されたアクションに変えることもできます。たとえばシステム管理者は、Webhook のペイロードを受信するたびに実行される自動化を設定し、管理対象ホストに新しいコード変更を自動的に適用し、デフォルト状態に戻すことができます。自動化のトリガーとして Webhook を使用するこの方法は、人が関与することなく他の IT アクションを実行するように拡張することができ、イベント駆動型の自動化として知られるプロセスを可能にします。

唯一の違いは、信頼できる情報源です。望ましい状態のエンジンを git リポジトリに接続する代わりに (この場合、コードの更新は人間がプッシュする必要があります) 、Webhook ではエンジンを特定のイベントのソースを監視するサードパーティ・ツールに接続することができます。これらのイベントソースが対象となるイベントを検出し、Webhook を起動すると、ペイロードは IT スタッフが一切の操作をすることなく、イベントを解決するための即時アクションを実行する自動化をいつでも開始できます。

イベント駆動型の自動化とは、IT 環境における条件の変化に自動的に対応して、問題を迅速に解決し、定型的な反復タスクを削減するプロセスです。イベント駆動型の自動化により、IT チームは、ハードウェアの問題、分散型サービス拒否 (DDoS) 攻撃、メモリ不足、アプリケーションの障害など、あらゆるイベントへの対応を体系化し、イベント発生時に必要なアクションが自動的に実行されるようにできます。

イベント駆動型のソリューションは、イベントのソースを監視するために、ServiceNow、Kafka、Prometheus、Sensu、Dynatrace、Appdynamics のようなサードパーティ・ツールやプラグインに依存しています。Webhook はこれらのイベントソースを自動化プラットフォームと接続するために使用することができ、ソースがイベントを検出すると、Webhook は適切な自動応答をトリガーします。

IT チームは、イベント駆動型の自動化を段階的に導入することで、平均復旧時間 (MTTR) を短縮し、チケットの自動作成などのまだ人間の関与が必要な機能を実行できます。そして、特定の問題が発生したときに適切なアクションが自動的に実行されるように、完全な自動修復に向けて徐々に取り組んでいくことができます。

Red Hat Ansible Automation Platform は、IT チームが企業全体で自動化を作成、管理、拡張できるように設計されたエンドツーエンドの自動化プラットフォームです。Webhook を使用して、GitHub や GitLab のようなサービスを介して Ansible Automation Platform と Git リポジトリを統合し、IaC や GitOps プラクティスをサポートすることができます。リポジトリリンクが設定されると、Ansible Automation Platform は Git システムから Git コミットをキャッチし、それらのイベントを使用して自動化ジョブをトリガーし、プロジェクトを更新してインベントリーを管理し、デプロイメントを実行します。

Webhook により、イベントがソース管理システムで発生したときに自動化を自動的に有効化できます。これにより、リポジトリを監視したり、変更の発生時に自動化ジョブを起動したりするための Jenkins などの CI/CD ツールを追加する必要がなくなり、GitOps のワークフローが単純化され、運用が効率化されます。Ansible Automation Platform は、さまざまな開発ツールやデプロイメントツールと連携できるため、使用するツールやプロセスに応じて GitOps のワークフローをカスタマイズすることができます。

Event-Driven Ansible によるミッションクリティカルな自動化

Ansible Automation Platform の一部である Event-Driven Ansible は、時間がかかるタスクを自動化し、あらゆる IT ドメインにおいて変化する条件に対応するために必要なイベント処理機能を提供します。IT 環境での条件に関する個別のインテリジェンスを含むイベントを処理し、イベントに対する適切な対応を判断し、イベントに対処または修復するための自動化されたアクションを実行できます。

Event-Driven Ansible は、チケット強化、修復、ユーザー管理などの IT サービス管理タスクや、その他のさまざまな IT プロセスの自動化に使用できます。ルールによって、イベントのソースを対応するアクションと結びつけます。Ansible Rulebook はイベントソースを定義し、イベントが発生したときに実行するアクションを「この条件の場合は、この動作をする」という条件付き命令の形式で記述します。設計したルールブックに従って、Event-Driven Ansible は指定されたイベントを認識し、適切なアクションと一致させ、自動的に実行します。

Event-Driven Ansible をイベントソースに接続するために、完全にサポートされている一般的な Webhook を使用することができますが、Event-Driven Ansible は、パートナーがそれぞれ固有のテクノロジーに対応できるように構築したソースプラグインのエコシステム・ライブラリも提供しています。これらの完全にサポートされたプラグインにより、コードを書いたり新しいイベントごとに Webhook をプログラムしたりすることなく、イベント駆動型の自動化を構築できます。関心のあるイベントと実行したいアクションが分かれば、これらの指示を Ansible Rulebook に書き込むことで、任意のイベントが既存の Ansible Playbook または必要な自動化ワークフローを自動的に実行できるようになります。