アプリケーション通信のAPIとメッセージングの違い

Phil Wilkins | Oracleのクラウド開発者エバンジェリスト| 2022年12月

ソフトウェアは他のソフトウェアと通信する必要があります。アプリケーションのある部分のソフトウェアが、アプリケーションの別の部分とサービスを要求したり、データを交換したりする必要がある場合があります。あるいは、あるアプリケーションが、まったく別のアプリケーションにサービスを要求したり、データを交換することが必要になります。

このような通信に使われる代表的な仕組みとして、アプリケーションプログラミングインターフェース(API)とメッセージングがあります。

APIとメッセージングの違いは、時に混乱を招くことがあります。それは、この用語が曖昧なまま飛び交っているからです。APIという頭字語自体には明確な意味がありますが、後述する理由により、この用語はいくつかの異なる意味を持つようになりました。メッセージングという言葉は、システム間通信のほとんどをカバーするために非常に大雑把に使われることが多々あります。そこで、APIとメッセージングの本当の意味を明らかにしましょう。

APIの詳細な定義

大まかに言えば、APIとは、そのソフトウェアがどのようにサービス要求を受け取り、それに応答できるかを定義した契約です。その契約は、ソフトの開発者が定めています。

簡単そうに思われますか。一面では、その通りです。実際には、APIの暗黙の意味は、会話の対象によって変わることがあります。APIという略語を紐解くと、あるソフトウェアが別のソフトウェアと相互作用するためのインターフェース、あるいは「契約」を意味します。APIについての議論は、そのハイレベルなアーキテクチャの定義に焦点を当てられることもあれば、開発者がAPIを実装する具体的な方法を詳細に説明する、非常に細かなものもあります。

APIに関する書籍や記事の中には、APIをドアに例えて、APIの特徴を説明しているものがあります。例えば、自動で開く食料品店のドアや、超高セキュリティな銀行の金庫室のドアなどもにも例えられるでしょう。アプリケーションの契約、つまりドアの特性は、以下のような考慮事項に対処するのに役立つでしょう。

  • APIの機能の概要ドアに例えると、お客様が立ち止まって何かに触れる必要もなく開くのでしょうか(食料品店のドア)、それともアクセスをコントロールし、ドアの向こうにあるものを守るのでしょうか(銀行の金庫室)。
  • ソフトウェアのパフォーマンスを発揮させるために、どのようなペイロード(送信データ)をサポートする必要があるのでしょうか。例えば、ソフトウェアが銀行口座番号とセキュリティ認証を受け取り、その銀行口座の残高を回答するような場合です。
  • そのサービスを行うために、どのようなデータをやり取りするのでしょうか。例えば、有効な口座番号やセキュリティ認証の内容を正確に定義し、レスポンスの内容を決めることが重要です。ここで重要なのは、曖昧なままでは間違いにつながるということです。
  • ドアの住所はどこでしょうか。これは通常、リクエストのためのユニバーサル・リソース識別子(URI)がどのように形成されるかを意味します。つまり、リクエスタは実際にどのようにAPIとやり取りをするのでしょうか。
  • 通信にはどのプロトコルを使用するのでしょうか。HTTPやFTPなどのよく知られたテクノロジーから、STOMPやQUICのような特殊なプロトコルまで、さまざまなものがあります。
  • API利用者が遵守すべき条件とは何でしょうか。暗号化の詳細、APIを呼び出す頻度の制限、商用サービスのチャージバックの仕組みなどが含まれます。
  • APIはどのようなことを保証するのでしょうか。それには、リクエストが特定の時間内に認識または実行されるといった、APIのサービス・レベルの保証などが含まれる場合があります。

アプリケーション開発におけるメッセージングの定義

APIが、ソフトウェアがサービス・リクエストをどのように送受信するかの条件を定義する一方で、メッセージングは、あるシステムから別のシステムに情報を送信するためのプロセスです。キーワードはプロセスです。

こう考えてみてください。

  • メッセージングとは、ある情報の塊であるメッセージを、サービス要求者からサービス提供者に(多くの場合、ブローカーと呼ばれる第三者を利用して)送信するプロセスを指します。

    実際で説明するには、企業がお客様にメールを送る場合を考えてみてください。サービス・プロバイダーは、携帯電話会社がメッセージを配信できるように、受信者の電話番号を知らなければなりません。しかし、ペイロードそのものは、携帯電話会社から見れば何でもいいのです。携帯電話会社は、あなたのテキストメッセージが英語なのかスペイン語なのか日本語なのか、それとも絵文字なのか、知る必要がありません。

  • メッセージングとは、メッセージを送り手からお客様へ届くまでに必要な裏側のすべての動作を指します。

    通信事業者やスマートフォン・メーカーが適切に仕事をしていることを信頼しているのですから、自分もお客様もメッセージング・プロセスの仕組みを理解する必要はありません。同様に、通信事業者はペイロードを理解する必要はなく、正しい相手に届けられ、文字化けや歪みがないことを確認するだけでいいのです。

メッセージング・プラットフォームの多くは、テクノロジーの制約に収まる限り、ペイロードには無頓着であることを、改めて強調しておきます。話を戻すと、スマートフォンや携帯電話会社は、文章が英語で書かれていようが絵文字で書かれていようが無関心です。

API、APIプラットフォーム、APIマネジメントの構成について、さらに詳しくご覧ください。

企業システムにおけるAPIとメッセージングの連携

企業向けソフトウェア・システムは、複数の独立した実行プロセスから構築されるため、プロセス間通信(IPC)が必要となります。ここでの通信は複雑で、トランザクションを実行するために、多くのAPIコールと多くの厳格なフォーマットのデータとの行き来が必要になることがあります。こうしたトランザクションは、ビジネス・ニーズを満たすために、慎重に編成され、正しい順序で完了しなければなりません。

例えば、お客様からの発注書を考えてみましょう。顧客データベースへのアクセス、在庫データベース、会計システム、請求書作成システム、クレジットカード課金システムへの問合わせ、在庫と顧客アカウントの調整、入庫依頼の作成、出荷依頼の作成、これらのプロセスを正しい順序で、正しく完了させる必要があります。

従来、このようなやり取りは、ファイル・システムやデータベースなど、何らかの共有ストレージを利用して行われてきました。しかし、より最新化された企業システムでは、プロセスが互いに直接通信することができ、プロセスを高速化し、問題(例えば、あなたの注文のための在庫がすでに前の注文により割り当てられている場合など)を取り除くことができます。

同期動作と非同期動作

私たちのコミュニケーションは、性質上、同期型と非同期型に特徴づけることができます。同期通信とは、通信の関係者全員が参加し、再送信が可能でなければならないことを意味します。この注文の例では、電子決済に関わるシステムは、リアルタイムに相互作用できるものでなければなりません。また、通信は非同期で行われ、通信を希望するシステムの当事者が同じ瞬間に存在する必要がないこともあります。これは、メールをやり取りするときの仕組みです。非同期で通信を行うには、情報の受け渡しを可能にするために仲介役の関与が必要です。

このような複雑な企業向けメッセージング・システムは、さまざまな種類やパターンで提供されています。

  • サービス・バスサービス・バスは、異なるプロセス間の接着剤としての役割を果たし、上記の複雑なトランザクションのように、それらのプロセス間のオーケストレーションを実行します。サービス・バス・システムは通常、ペイロードをあるフォーマットから別のフォーマットに変換したり(テキストメッセージの例では英語からフランス語)、メッセージの内容に基づいてメッセージをルーティングしたり、あるいは複雑なトランザクションの状態に基づいて何らかの決定を行うなどの付加価値機能を組み込んでいます。例えば、タスクAとBを並行して行い、タスクBが正常に終了したらタスクCを行い、タスクBが失敗したらタスクDを行い、タスクDが失敗したら人間の介入を得るというようなことです。

    サービス・バス形式のメッセージングは、プロバイダーとコンシューマ間の「パイプ」でのメッセージング・ルーティングとスケジューリングの点でインテリジェンスが追加されているため、スマート・パイプを使用していると表現されることがあります。これはオーケストレーションとも呼ばれます。

    サービス・バスの図と説明メッセージ・プロバイダーはメッセージを提供するサービス・バスを呼び出します。そして、サービス・バスはメッセージを受け取り、コンシューマにルーティングします。ルーティングの間、メッセージは変換ロジックとフィルタリングを受ける可能性があります。

    サービス・バスの同義語はメッセージ・バスです。これらのテクノロジーがサービス指向アーキテクチャ(SOA)ソリューションに進化した当初は、メッセージ・バスとサービス・バスの間にいくつかの相違点がありました。現在では、実質的な差はありません。実際、名前が短縮されて単にバスと呼ばれることが増えています。

  • WebサービスWebサービスとは、広義では通常TCPとHTTPプロトコル(またはHTTPSやHTTP/2のようなバリエーション)を使用した、2プロセス間の直接同期通信のことを指しています。コンシューマとクライアントはポイント・ツー・ポイント接続で実現されます(ただし、プロバイダ側が複数の同時クライアント接続をサポートすることが一般的です)。2つのプロセスの間には、プロキシ(ネットワーク・ファイアウォールからAPIゲートウェイ、ウェブキャッシュまで)やネットワーク(スイッチやルーター)の仲介が入ることもありますが、プロバイダーも消費者もそのことに気づくことはないでしょう。

    Webサービス図、以下説明メッセージプロバイダは、消費者と直接通信を行います。送信プロセスは、両者が利用可能であることが条件となります。
  • メッセージ・ブローカー:メッセージ・ブローカーは、メッセージの提供者とメッセージの消費者の間の仲介役で、サービス・バスとWebサービスの両方に共通する部分を有しています。

    ブローカーはメッセージの送信者と受信者の間に存在し、通信中のメッセージを受信し、受信者がそれを消費するまで保存することになります。つまり、送信されるメッセージは、受信者がすぐに対応できるかを気にすることなく送信することができるのです。そのため、ブロッカーが動作している限り、いつかはメッセージが届くと確信できることから、この種の通信はしばしば非同期または「ファイア・アンド・フォーゲット」と表現されます。

    Webサービスとの類似点は、クライアントとブローカー間の接続がポイント・ツー・ポイント接続で表され、メッセージ・ブローカーの存在が機能的に見えないことに由来します。

    サービス・バスとの類似点は、ブローカーが受信したメッセージを受信者が利用可能になるまで保持するという付加価値サービスを提供することにあります。より堅牢なサービス・バスとは異なり、メッセージ・ブローカーは、特定のメッセージを受信したい宛先を把握し、宛先がタイムリーにメッセージを消費しない場合にどうするかといった単純なことを理解する以外には、最小限のインテリジェンスしか持ちません。

    ブローカー型のコミュニケーション・スタイルは、ダムパイプがあると表現されます。というのも、ブローカーのインテリジェンスは最小限であり、メッセージの送受信が必要なときに何が必要かをエンドポイントが理解する必要があるためです。このスタイルは、コレオグラフィ(サービス・バスのよりインテリジェントなオーケストレーションとは反対)と表現されます。

    メッセージ・ブローカの図と説明メッセージ・プロバイダはブロッカーにメッセージを渡します。その後、ブローカーは、コンスーマがメッセージを要求するか、メッセージを受け取ることができるようになるまで、メッセージを保持します。プロバイダはコンシューマに依存しません。

エンタープライズ・メッセージにおけるストリーミングの役割

ストリーミング・テクノロジーの中には、データ処理の要素をサポートできるものもありますが、この議論では、ストリーミングはメッセージングのやや特殊な形態と見なすことができます。ここでいうストリーミングとは、Webサービスやメッセージブローカーが通信を実装しているかどうかに関係なく、IPCテクノロジーを通じて同じ宛先に連続したイベントのフローを送信する行為を指します。(サービス・バスの余分なインテリジェンスが必要とされるには、あまりにも多くのデータが、あまりにも速く流れるため、サービス・バスが関与することは非常に稀です。)

ストリーミングでは、継続的なデータの流れに加え、通常、ほぼリアルタイムまたは低レイテンシでの接続が期待されます。これは、Netflixなどのサービスが、従来はビデオ・ストリーミングと呼ばれていたことを考えれば、驚くことではありません。プロバイダから新しい映像が送られてくる間や、メッセージ・ブローカーが映像をあるフォーマットから別のフォーマットに変換する間に、映像コンテンツが止まったり始まったりするようなことは、確かに避けなければなりません。

Webサービス・ストリーミングに一般的に用いられるテクノロジーは、WebSocket、gRPCストリーム、GraphQLサブスクリプションです。仲介されたメッセージングストリーム(Kafkaなどのテクノロジーを使用)に関しては、ブローカーの仕組みを利用して、送信されたイベントの「スライス」を見ることができる場合があります。これにより、ストリーム自体に関する情報など、貴重なインサイトを収集することができます。これが、ストリーミング分析という用語の由来です。

ストリーミング分析に適用されるロジックは高度であっても、メッセージブローカーは判断やメッセージ操作を行わないため、ブローカーは依然として無能と見なされています。このようなストリーミング分析機能は、よくKafka Streamsのようなテクノロジーで実装されます。

APIとメッセージングの業界標準

APIやメッセージング・システムは、説明するのは簡単ですが、その詳細や技術的特性は非常に複雑です。曖昧さは許されないので、正確な業界標準と文書化、そして理想的にはこれらの標準の最適な適用が実際に必要になってきます。

特にAPIについては、10年以上前から開発が行われている分野です。業界では、Webサービスの一種であるRESTベースのAPIのためのOpenAPI仕様が採用されており、これはおそらく最新のエンタープライズ・ソフトウェアで使用される最も一般的なAPIのタイプです。

API(およびストリーミング)では、メッセージとその伝送の側面を定義し、記述するための標準が多数追加されています。これには、プロトコル・バッファ(Protobufとも呼ばれ、gRPCで使用)、最近では、GraphQL、JSON Schema、YAMLが含まれます

非同期メッセージング領域では、ここ数年、多くのメッセージング要件に対応するため、OpenAPIやその他の進化する標準からのアイデアを採用したAsyncAPIと呼ばれる定義にまとまった取り組みが成功を収めています。

最新の分散アプリケーションは、別々のソフトウェアであるサービスの集合体として実装されており、同じサーバー上で動作することも、そうでないこともあります。APIは、サービスを要求したり、情報を交換したりするために、これらのソフトウェアが互いにやり取りするための方法を提供します。メッセージング・システムは、非同期通信を促進するインフラストラクチャを提供し、API呼び出しのためのインテリジェントな仲介者を提供します。これは、非常に単純なもの(スマートフォンのメールの仕組み)の場合もあれば、非常に複雑なもの(複雑なマルチステップ・ビジネス取引のオーケストレーションなど)の場合もあるでしょう。分散したサービス同士がAPIを使って直接通信するのは言うまでもありません。幸い、進化する手法や標準により、データベースの呼び出しからストリーミング・メディアまで、あらゆる場面でAPIを使用することが可能になっています。そして、これらのAPIやメッセージング標準は進化と発展を続け、最新の分散ソフトウェア・アーキテクチャへの移行をより早く、簡単に、そしてより安全に実現しています。