REST APIを主に扱ってきた方であれば、WebSocket、Kafka、AMQPなどの非同期APIとそのプロトコルについてご存じない可能性がありますが、非同期APIというのは、複数のリクエストを同時に管理し、サービス間の通信を効率的に行うことができるようにするものです。
多くの似たようなタスクはこのような両方のAPIを使って実行することができますが、ユースケースの中には、特定のAPIを使った方がうまく管理ができる場合があります。そこで、同期APIと非同期APIの違いについて掘り下げてみましょう。
同期APIと非同期APIの違い
同期型と非同期型のAPIは、どちらもデータ要求を返すことで機能します。両者の大きな違いは、同期APIがデータやサービスに対するリクエストを即座に提供するのに対し、非同期のAPIは、リクエストの準備ができ次第、要求側にコールバックをする点です。
ところが、同期APIの場合、リクエストは順次発生し、やりとりがある度に完了するまで処理がブロックされ、となると、アプリケーションを使うクライアントへの応答時間が、アプリが提供する各マイクロサービスの応答時間の合計であるということになります。また、同期APIには、ユーザーが更新を希望する場合、データの修正を探すためにAPIを継続的に呼び出す必要があるという欠点があります。
こういったボトルネックを解決し、リアルタイム性を高めるには、APIをイベント駆動型または非同期にするという方法があります。 さらに、イベント駆動型アーキテクチャを採用することで、優れたユーザー体験やシステムの効率化などの大きなメリットがあります。
非同期APIは、非同期リクエストがバックグラウンドで処理され続ける間、ポーリングURLでAPIコールを即座に返すことで機能し、それによって、確実にアプリケーションの機能が維持され、アプリケーションのリソースがより新しいリクエストの処理のために解放されます。
さらに、同期APIは接続性が高く、レイテンシーの低い場所で最も効果的に機能することから、接続性が不足していたり、過飽和状態であったりする場合は、非同期APIの使用がいいでしょう。また、APIリクエストの中に実行時間が長いものがあるときは、リクエストの外に高価なオペレーションを考慮するとよく、そうすれば、このようなリクエストに対するレスポンスをより速く提供することができます。
例えば、REST APIの操作で処理に時間がかかることがありますが、クライアントを操作の完了まで待たせるよりも、即座にレスポンスを返し、後でリクエストを処理するのがベストです。
AsyncAPIを使ってイベント駆動型APIを確定する
AsyncAPIとは、イベント駆動型アーキテクチャを記述し、非同期アプリケーションを機械可読な形式で文書化することができるオープンソースツールです。
AsyncAPIの要素はOpenAPIと似ていますが、イベントの収容に関して追加機能がいくつかあり、WebSocket、Kafka、STOMP、JMA、AMQP、MQTT、HTTPなど多くの通信プロトコルやトランスポートを、イベントスキーマのフォーマットと一緒にサポートしています。
そのため、AsyncAPIでイベント駆動型アーキテクチャを確定すると、イベントのペイロード確定、チャンネル名、プロトコル、アプリケーションヘッダ、その他イベント関連のセマンティックが含まれるようになります。
APIのための非同期メッセージプロトコルとは
- Webフック
Webフックは、イベントに対して操作するAPIの一種と考えることができます。このサービスで、イベントが発生したときに、あるプログラムから別のプログラムへのデータ転送が可能になるため、サーバーからのリクエストに関しては、受信の確認以外の指定はありません。
データ送信のアプリがデータを受信するのではなく、通信を開始するため、これらは「逆API」としても知られています。Webサービスの相互接続性が高まる中、Webフックは、単数または複数のエンドポイントにリアルタイムでデータ更新やプッシュ通知を可能にする、より簡単なソリューションとして利用されており、それも強固なAPIソリューションを使うことなく実現されています。
- Webソケット
このプロトコルで、サーバーとクライアントは確実に双方向の通信ができます。これは、両方のエンティティが必要なときに必要な情報を共有できるということになりますが、Webソケット を使うと、サーバーにメッセージを送信し、サーバーにポーリングせずにイベント駆動型の応答を取得することができます。
ちなみに、Webソケットはポイントツーポイントの接続やPub-Sub（パブリッシュ/サブスクライブ）のサポートはありません。
- GraphQL のサブスクリプション
GraphQLは、APIに使われるクエリ言語であり、ライブクエリやサブスクリプションを通じて、GraphQL サーバーから非同期通信を行うことができます。GraphQLを利用したアプリにリアルタイム機能を追加したい場合はサブスクリプションがキーとなり、例えば、Facebookのライブコメントやストリーミングリアクション機能は、社内で開発したGraphQLサブスクリプションがあったからこそ実現できたものです。
ライブクエリは後から作られたもので、それほど広く使われているわけではなく、まだGraphQLサブスクリプションの一部ではありません。ちなみに、サブスクリプションとクエリの主な違いは、サブスクリプションはイベントを見るのに使われるのに対し、ライブクエリはデータを見るのに採用される点です。
GraphQLサブスクリプションはGraphQLに組み込まれており、単一のAPIエクスペリエンスを通じて非同期および同期のインタラクションを可能にします。つまり、1つのAPIでリクエスト・レスポンス型のコマンドやクエリだけでなく、非同期型のイベントベースの通知もサポートすることができるのです。
- SSE（サーバー送信イベント）
標準的なリクエスト・レスポンス型のインタラクションでは、クライアントがコネクションを開くとすぐにサーバーにHTTPリクエストが送信され、その後HTTPレスポンスを取得し、インタラクションが完了するとコネクションは閉じられます。つまり、これはクライアントがデータを要求するときに常に行われます。 一方、SSE（サーバー送信イベント）は、クライアントがクライアントとサーバーの接続を開くと同時に、サーバーから非同期にデータをプッシュすることができるようになります。クライアントが接続を確立すると同時に、サーバーはデータを提供し、新しいデータイベントが発生するたびにクライアントにデータを転送するため、このプロセスには「サーバー送信イベント」という名前が付いています。
非同期APIの実用的な使用例
SNSであれ、銀行やゲームなどの他の分野であれ、非同期APIはアプリケーションのパフォーマンスを高め、応答性を上げるために広く利用されています。
メッセージのやり取り
世界中の何十億もの人々が、Facebook、Instagram、WhatsAppなどのアプリのメッセージ機能を利用して、つながりを保っているため、そのようなアプリが処理しなければならないユーザーインタラクションの数は膨大なものになります。
このようなアプリは、非同期APIを使って、応答でユーザーを待たせることなくバックグラウンドで多数の並列リクエストを処理します。この非同期リクエストの多くは、たとえば友人からの投稿やメッセージに関する通知など、一斉処理は必要ありません。
さらに、これらの中には、より高速な処理が必要なのもあり、例えばFacebookは、このような非同期リクエストの管理にAsyncを使用しており、何十億ものリクエストを効率的に処理します。
バンキング
非同期での取引は、信用取引が頻繁に行われる銀行では一般的であり、こういった取引は、加盟店と銀行の仲介役として機能するプロセッサーによって管理されます。
顧客はプロセッサがホストしているウェブサイトを通じて支払いを行い、販売店は取引を開始し、サーバーは後で返答しますが、顧客が取引を放棄した場合、サーバーは応答を送信しません。
クレジット取引における非同期 API は、銀行がホストする支払いサイトで、顧客が支払いの詳細を提供する必要があるさまざまなプロセッサの単一のエントリ ポイントとして機能します。そして加盟店は、取引が始まり次第、取引を処理する銀行の識別子を提供します。
ゲーム
最近、非同期型のマルチプレイヤーゲームが大流行していますが、これらは、リアルタイムのデータ交換なしに友人などとの対戦ができます。
非同期型のマルチプレイヤーゲームは、モバイルのプラットフォームで広く利用されており、プレーヤーが他のアクティビティで忙しくゲームが頻繁に中断されるため、非同期APIが採用されています。
まとめ
非同期APIを使うことで、応答性の向上やコミュニケーションの改善など、多くのメリットがあります。
さらに、アプリケーションの相互接続性と複雑性が増していることを受けて、非同期APIは今後も存在し続けるでしょう。ただし、どのような場合に使用し、どのような場合に同期APIに取って代わることができないかを知っておくことは不可欠であり、プロのデベロッパーは、これら両方のAPIに独自の利点があることを理解しており、アプリ内の通信を改善するためにハイブリッド・アーキテクチャを使うこともあります。
効果的なAPIの構築とアクセスには、Integrate.ioの無料トライアルをぜひこちらから始めてください。
