こんにちは。マクニカソリューションズ KTです。
[連載企画]マイクロサービス はじめの一歩 Part.2です。

私の業務は、DX(デジタルトランスフォーメーション)の実現をトリガーとして、DevOpsやMicroservicesが注目を浴びる中で、それらに対するアプローチ手法やソリューションを開発することです。
日頃から、先進的な技術思想やテクノロジーに近い立場で活動させて頂いていますが、それらはとても早いサイクルで進化していくことを強く実感しています。
多くの企業がDXの実現を目指す中で、より効果的なDevOpsへの取り組みやMicroservicesへのアプローチ手法と出会うことは非常に大切な要素で、本連載がそのきっかけになれるのであれば大変嬉しく思います。

前回、１回目の投稿では弊社エンジニアのminepiccoからマイクロサービスの概要について解説させて頂きました。
# １回目の投稿はこちらhttps://arimac.macnica.net/blog/cuttingedge/part1.html

連載２回目となる今回から、マイクロサービスの導入を考える場合の具体的なアプローチについて、幾つかの技術要素を紹介していきます。
今回は、マイクロサービスの利点を最大化するためのAPI Gatewayの実装について解説します。

マイクロサービスへのHTTP通信
前回の投稿の中でマイクロサービスは特定の機能に特化した、軽量で粒度の細かいサービス群が疎結合することによって成立するアーキテクチャであることを紹介しました。
では、この粒度の細かいサービス群やクライアントからサービス群への通信はどのような方式を利用して行われるのでしょうか。
一般的には軽量で操作性の高いREST APIがよく使われます。
REST APIを使うことでオーバーヘッドの少ないデータのみを効率的に受け渡しすることが可能になり、シンプルで軽量なマイクロサービスの利点を最大限に引き出すことが可能です。
クライアントはサービスを利用する際に、REST APIを使用していることを特に意識する必要はありませんが、下記のような仕組みで通信が成立しています。


REST APIに対する運用要件
次に、商用で使うような本番環境で、マイクロサービスに対してREST APIを使ったHTTPリクエストを行う場合を想定して下記のような構成を考えてみます。


上記のような構成でサービスを提供することは可能ですが、商用環境では下記のようなセキュリティに代表される、様々な運用要件が発生します。

そういった場合にどのような対応が必要になるでしょうか。

上記の構成の場合、No1とNo2に関しては個々のサービスAに対して個別にソリューションを実装する必要があり、対象サービスの数が増えると実装工数はもちろん、運用負荷も高くなります。また、No3に関しては新たにルーティングノードを追加する必要があります。
一般的に、マイクロサービスのような分散システムを構成した場合、管理対象のオブジェクトが増加することで、実装工数や管理工数の増加が問題になる傾向にあります。この問題を極力低減するためにはアーキテクチャデザインが鍵となります。

API Gatewayの実装
上記のような要件を満たすための最適解の一つとして、API Gatewayの実装が考えられます。
API Gatewayを実装することで、クライアントからのHTTPリクエストを受け付けるシングルポイントを設け、認証、HTTPS対応、ログ・メトリック取得、ルーティングといった様々な機能実装が最低限の実装工数で可能となります。また、シングルポイントであることから、運用負荷も最低限で抑えることができます。
具体的には下記のような構成になります。


上記の構成でマイクロサービスを運用する場合、システム管理者は先述した運用要件に対するオペレーションの全てをAPI Gatewayに対して実装することで達成できます。
システム運用が複雑になりやすいマイクロサービスアーキテクチャに於いて、運用工数を最低限に抑えることは非常に大きな意味を持っており、アーキテクチャデザインの段階で最も重要視するべき要素の一つと言えます。

いかがでしたでしょうか。連載2回目の今回はマイクロサービスへの具体的なアプローチの一つとして、API Gatewayの実装について解説しました。
次回は、マイクロサービスの注目度の増加と共に脚光を浴びているあのテクノロジーについて解説する予定です。
ご期待下さい!!