2021年1月8日金曜日

REST APIへの不満爆発? API Worldで話題になったメッセージングのこれから。gRPC、Kafka、GraphQLの検討。2017年12月26日 09時00分 公開

https://techtarget.itmedia.co.jp/tt/news/1712/26/news07.html
シェアしました。

カルフォルニアで開催された「API World 2017」ではマイクロサービスのメッセージングプロトコルについて、RESTからの脱却や新しいプロトコル検討がされた。最新情報を含め幾つかトピックを紹介する。

[Fred ChurchvilleTechTarget]

関連キーワード

API | Apache | アプリケーション開発

画像APIの最新トピック

 カリフォルニア州サンノゼで開催されたカンファレンス「API World 2017」では、モノリシック(システムとしてさまざまな機能が集約されたもの。マイクロサービスの反対)なソフトウェアアーキテクチャから分散型のマイクロサービスベースアーキテクチャへの移行に関心を持つ人々が集まった。カンファレンスでは、特にマイクロサービスメッセージングプロトコルに関して多くのアドバイスと方向付けが行われた。メッセージングプロトコルとはデータ交換方式の規約である。

 本稿では、カンファレンスの参加者に提示されたマイクロサービスについての新事実や今後の見通しについて見ていこう。カンファレンスでは、RESTからの脱却、注目すべき最新で最高のメッセージングプロトコルとアーキテクチャが話題になった。

RESTからの脱却

 API World 2017では、マイクロサービスの標準メッセージングプロトコルとしてRESTを使用していることが議論になった。RESTは人気がある。だが、パネルセッションのメンバーはマイクロサービスのメッセージングプロトコルの進化に注目し、他の選択肢を検討する必要があることを提言した。

 ロンドンに拠点を置くAPIサポート基盤提供ベンダーHitchでリードエンジニアを務めるフラン・メンデス氏は次のように語った。「RESTful APIは人気があるが、多くの不満も抱えている。WebSocketがあっても、パターンを一致させるためにはコネクション(接続)のために高品質な仕組みが必要になるためだ。ユーザーはイベントドリブン型の別の選択肢を探している」

画像《クリックで拡大》

イベントドリブン型の効果

 テキサス州フリスコに拠点を置くテクノロジーアドバイジング企業Logic Keepersの最高技術責任者(CTO)兼取締役社長マーク・マカリー氏はカンファレンスの参加者に向けて、マイクロサービスで以前から利用されているRESTのブロッキングアーキテクチャの問題点と、イベントドリブン型のノンブロッキングアーキテクチャの効果を話題にした。

 「マイクロサービスに切り替えると、システムの応答性が極端に低下するという問題に直面する。誰もが応答性の非常に高いアプリケーションに慣れつつあり、既にユーザーエクスペリエンスの一部になっている」と同氏は話す。

 マカリー氏の説明では、入出力とデータベースのブロッキング、モノリスとパフォーマンス管理、内外のエンドポイントの不適切な管理という3つの問題が生じる可能性があるという。イベントドリブン型のアーキテクチャを目指せば、応答性と柔軟性の高い、イベントドリブン型非同期ノンブロッキングアプリケーションにすることができる。ここでいうブロックとは処理が開始する前に前の処理待ちが発生することを指す。同様に、同期とはプログラムの処理が終わるまで他の処理をしないことを指す。つまり非同期ノンブロッキングとは、処理開始前に待ちが発生せず※、他の処理が実行中の場合は別のプロセスで処理を継続することができる。

※注 正確には待ちが発生する場合は前の処理に戻り、システム返答待ちをせずにエラー処理など即座に後続処理ができる。

画像《クリックで拡大》

gRPC、Kafka、GraphQLの検討

 1つの提案は、オープンソースのリモートプロシージャコールシステム(gRPC)を調査するというものだった。gRPCは当初Googleが開発したシステムだ。Googleで製品管理リーダーを務めるバルン・タルワール氏は、gRPCはHTTP/2を用いるため、同氏が名付けた「多言語混在通信」という方法を実現できると説明する。

 「gRPCは、ストリーミング、クライアント側のストリーミング、サーバ側のストリーミング、メッセージの返信に役立つ可能性がある。多くのREST開発者は、これらをRESTで行うのが難しいことに気付いている」(タルワール氏)

 話題は、オープンソースのストリーム処理基盤「Apache Kafka」の使用に移った。その主な理由は、Apache Kafkaが持つ、メッセージ伝達のフォールトトレラントな性質にある。フォールトトレラントとはシステムの一部に問題が生じても全体が機能停止するということなく機能を縮小してでも動作し続けるような設計のことである。

 ブリティッシュコロンビア州バンクーバーのソーシャルメディア管理基盤プロバイダーHootsuiteでテクノロジー部門のディレクター兼任開発者を務めるマイク・サンプル氏は次のように述べた。「Apache Kafkaではブローカーを2~3つ利用できる。そのブローカーはパーティションを2~3つ格納できる。そのため、非常に強固になる」

 Apache Kafkaブローカーとはメッセージングを処理するコンポーネントの1つで、メッセージの配信とメッセージの購読の間でメッセージの受け渡しをする。ブローカーが複数利用できるということはメッセージの送受信をするための経路が複数持てるということだ。

 パネルセッションのメンバーが次に話題にしたのは、Facebook社内で開発されたデータクエリ言語GraphQLだ。この言語は、特に分散型開発チームでRESTアーキテクチャの代わりに使用する場合にメリットがある。

 「企業の開発チームは拡大する可能性がある。GraphQLはこのような場合に非常に役立つ。GraphQLはAPIゲートウェイと考えるべきで、このゲートウェイはさまざまなサービスにアクセスできる」こう説明するのは、パネルセッションのメンバーで、アトランタに拠点を置くArvataのCTOを務めるライアン・ブラン氏だ。だが、同氏はGraphQL用のツールがやや未成熟な点を懸念している。

全てが前向きな検討材料になった

 API World 2017の参加者は、マイクロサービスのセッション、特にマイクロサービスのメッセージングプロトコルに関するパネルディスカッションに前向きな反応を示した。

 「特に気に入ったのは、マイクロサービス間のさまざまな通信プロトコルと、そのプロトコルを使用する理由についての話題だ」と語るのは、金融サービス企業The Capital Group Companiesで上級アプリケーション開発者を務めるヘマ・ラージャシェーカラ氏だ。

 ラージャシェーカラ氏は同社がマイクロサービスの実装に移行する際のパフォーマンスの問題を軽減するために、マイクロサービスのメッセージングプロトコルに関する情報をさらに集めようと積極的に探しているという。

 「1つの心配はパフォーマンスだ。異なるマイクロサービス間の通信がパフォーマンスにどう影響するかが問題になる。そのため、話題になったgRPCとKafkaの違いを社に持ち帰り、何を採用するのがベストか検討する予定だ」と同氏は言う。

 音声通信やネットワーク関連サービスを提供するBlackfoot Telecommunications Groupでシステム統合アナリストを務めるバーブ・ホンケン氏はカンファレンスに参加し、特にマイクロサービスでのGraphQL言語の使用に関する議論に興味を持ったという。

 「ここに来るまでは、GraphQLについて知りたくなるとは思っていなかった。だが、今ではもっと知識を深めたいと思っている」(ホンケン氏)

この記事を読んだ人にお薦めの関連記事

0 コメント:

コメントを投稿