APIゲートウェイという戦略

APIとマイクロサービスをまとめて管理する方法

APIとマイクロサービスは一緒に管理することができるのだろうか。本稿では、APIとマイクロサービスは個別よりも一緒に管理する方が良い理由と、その方法を解説する。

　ソフトウェアの世界では、ほぼ全てのものに関連があると考えられている。ただし、残念ながら新しいソフトウェアの概念の大半は、それに逆らう形で開発されているのが実情だ。現在、マイクロサービスとその管理は注目を集めている。そして、APIの仲介と管理にも関心が寄せられている。だが、この2つを同時に考慮して、これらの管理ソリューションを関連付けることはできるのだろうか。

　それは可能だ。そのためには、まずAPIとマイクロサービスの両方の管理について明確に定義する必要がある。そして、APIとマイクロサービスの管理目標を調和させるAPIゲートウェイモデルを作成し、APIとマイクロサービスの両方のメリットが確保できるようリスクを管理しなければならない。

APIとマイクロサービスの管理を定義する

　ソフトウェアアーキテクトや開発チームは、20年以上にわたって、アプリケーションを分散型サービスの集合体と見なしてきた。そして、この視点から生まれた全ての技法とアーキテクチャは、「コンポーネント化」と「バインド」という2つの問題を内包している。ここで言うコンポーネント化とは、ソフトウェアをどのように組み立てるのかという概念だ。一方のバインドは、個別のソフトウェアをどのように検出して関連付けるかを示す概念である。

　ソフトウェアをコンポーネント化すると、コードの再利用が進む。また、クラウド時代においては、アプリケーションのスケーラビリティと回復性も向上する。サービス指向アーキテクチャ（SOA）は、分散可能なコンポーネントの青写真として誕生した。だが、ソフトウェア設計の慣習では、SOAの原則の多くが時代遅れになっている。これがソフトウェアの専門家の間で一致している見解だ。このSOAに取って代わるのが、マイクロサービスだ。

　SOAでは、サービスはディレクトリ経由で検出され、構造化されたAPI経由でアクセスされる。構造化されたAPIには、セキュリティやアクセス権の管理などの機能が盛り込まれている。SOAは、本質的に細かいサービスではないのが一般的だ。つまり、SOAサービスでは、比較的複雑なタスクが実行され、APIの管理プロセスに付随するオーバーヘッドは問題と見なされていなかったことになる。

　一方、マイクロサービスは非常に細かいサービスだ。一般的にマイクロサービスは、特定のビジネス機能を実行するコンポーネントと見なされる。そして多くの開発チームは、マイクロサービスを作成するために、ビジネス機能を実用上のステップに分割しているのが実情だ。マイクロサービスは、シンプルなRESTful API経由でアクセスされることが多い。また、各マイクロサービスへのアクセスではネットワークとのやりとりが生じるため、時間がかかる。そのためマイクロサービスアプリケーションは、細かくなり過ぎないように留意して、パフォーマンスに影響を及ぼさないようにするだけでなく、セキュリティとコンプライアンスも管理しなければならない。これがマイクロサービスの管理だ。

　マイクロサービスで使用されるシンプルなAPIには、SOAのAPIに付随していたような機能はない。そして、大半のアプリケーションは、多くのマイクロサービスで構成されている。つまり、これまで単一のSOAサービスだったものが、6個以上のマイクロサービスで構成される可能性があるということだ。クライアント端末は、マイクロサービスごとにサービス呼び出しを行い、結果を組み立てる必要があるのだろうか。クライアント端末は、マイクロソフトサービスの所在や各マイクロサービスにどのようにアクセスするかを把握しているのだろうか。データの不正使用や傍受は、どのように防止するのだろうか。これに対処するのがAPIの管理だ。

APIゲートウェイの戦略

　「APIゲートウェイ」の人気が急上昇している。これは、APIとマイクロサービスの両方を管理しながら、両者のメリットを維持するフレームワークとして誕生したものだ。APIゲートウェイは、ファサードデザインパターンの実装である。APIのアップストリームをユーザーまたはクライアント端末に渡して、ダウンストリームのAPIをマイクロサービス側で呼び出す。APIゲートウェイは、APIとマイクロサービスの管理を調和させる経路を提供している。

この記事の著者

関連記事

• 

  マイクロサービスは小さく作ろうとすると失敗する

• 

  マイクロサービスのAPI実装で失敗しないための3大原則