いま知るべき！「マイクロサービス」入門

マイクロサービスとは、一言でいえば、小さなスコープを提供するための仕組みのことです。小さなスコープとは、例えば、顧客管理機能、在庫管理機能、決済機能など、特定の用途に特化した範囲のことです。このスコープは、より小さな範囲とし、できるだけ単機能とすることが望ましいとされます。

■　マイクロサービスの特徴

マイクロサービスを表すキーワードは「独立性」であり、以下の特徴を持ちます。

・単機能
・疎結合
・個別配置（デプロイ）

これによって、ソフトウェアの品質上、以下のメリットがあります。

①拡張性が高い
様々なマイクロサービスを組み合わせることで、全体の機能を拡張することができる。

①変更が容易になる
修正が必要になった場合でも、影響範囲が修正されたマイクロサービスに限定される。
影響範囲の見極めが容易であり、テストの負荷も軽減される。

③分散処理が容易になる
個別機能をサーバに分散させて動作させることが容易である。


反対に、デメリットとしては、以下があげられます。

①性能の確保
マイクロサービスは、ネットワークの使用を前提とするため、プロトコルのオーバヘッドが発生する。複数のマイクロサービスを使うことで、これらのオーバヘッドが性能に影響を及ぼす可能性がある。

②信頼性の確保
マイクロサービスに保持されるデータが分散管理されることになる。そのため、エラー発生時のリカバリなど、マイクロサービス独自の対策を検討する必要がある。

■　vs モノシリックアプリケーション

ソフトウェアは、機能展開した後、機能毎に関数やクラスなどのAPIを定義する。それらの機能をさらに細かく分解し、関数化やクラス化を図っていき、それらを繋ぎ合わせることで作られていきます。
一般的に、VisualStudioなどのIDE（統合開発環境）を使って、コード作成し、コンパイル・リンクを実施することでプログラムというコンポーネントを作っていきます。このようにつくられたアプリケーションは、「モノシリック（一枚岩の）」アプリケーションと呼ばれます。

このような考え方は、ソフトウェア開発の原則である「構造化設計・プログラミング」に沿ったものです。しかし、この緻密に関数へと分割する考え方には、緻密であるが故に、特に拡張性と保守性という面において悪影響が顕在化してきました。レガシーと呼ばれるソフトウェアやシステムの刷新を行う上で足かせとなってきているのです。

そこで、マイクロサービスを使って、ソフトウェアやシステムをデザインする「マイクロサービス・アーキテクチャ」を採用する動きが進んできています。

■　マイクロサービス・アーキテクチャ

マイクロサービス・アーキテクチャでは、機能を部品としてマイクロサービス化する箇所と、UIやバックエンドとしてのミドルウェアなど、マイクロサービスを統合するモノシリックアプリケーションとして実現する箇所によって構成されます。以下に例を示します。

複数のマイクロサービスを統合するマイクロサービス化を図って多段にすることも可能です。
また、バックエンドとしてのミドルウェアは、BackEnd for Frontend（BEF）と呼ばれることもあります。

データを管理するデータベースは、マイクロサービスが個々に保持してもいいですし、アクセスするテーブルさえ別にするという形でもいいとされています。要は、データへ直接アクセスすることを極力なくすこと


・マイクロサービスのAPI

マイクロサービスは、関数やクラスを直接、呼び出すのではなく、疎結合のAPIとして提供されることになります。

マイクロサービスを実現するためのAPIテクノロジーとしては、現時点では、以下があります。
いずれも、ネットワークにはTCP/IPであり、転送プロトコルとしてHTTPを使います。

・REST API

弱者のためのREST API入門

・GraphQL

弱者のためのGraphQL入門

・gRPC

弱者のためのgRPC入門

REST APIは、マイクロサービスアーキテクチャの内部のだけではなく、他ユーザにサービスを公開するAPIとして、適しています。

GraphQLは、データベースのアクセスと中継するようなマイクロサービスを作成する場合に適しています。主に、上記で述べたBEFの役割として使われます。

gRPCは、主に、マイクロサービスアーキテクチャの内部のAPIとして使われます。

■　マイクロサービスのエラー処理とリカバリ

データを更新するマイクロサービスに関しては、エラー発生時のリカバリ処理をUIやミドルウェア側で設計する必要があります。

実現すべきリカバリ処理の仕組みは、一連の処理であるトランザクションを、復旧（ロールバック）できることです。しかし、RDBMSのような緻密なロールバックの仕組みを疎結合であるマイクロサービスで実現するためには、かなり難しいと言わざるを得ません。

リカバリ対応の方向性としては、例えば、一連のマイクロサービスの呼び出しをトランザクションとして管理するマイクロサービスを作成し、ロールバック機能を実現することになるでしょう。

そのマイクロサービスの中で、エラーが発生したマイクロサービスの前のマイクロサービスで、すでに更新されてしまったデータを「取り消す」ため、再度、該当のマイクロサービスを呼び出し、データを更新する必要があります。

そのためには、トランザクションを管理するマイクロサービスでは、すべてのマイクロサービスが完了するまで、必要であれば一時的にリクエストとレスポンスのデータを保持し、エラー発生時点でロールバックするマイクロサービスを特定することが求められます。

■　まとめ

数年前でしょうか、「APIエコノミー」という言葉が流行った時期がありました。
これは、マイクロサービスを提唱する動きでしたが、フェードアウトしてしまった感があります。
しかし、マイクロサービスのAPI技術や、マイクロサービス・アーキテクチャの考え方は、バックグラウンドで確実に進展しており、やがてメジャーとなっていくのではないかと思われます。

セキュリティの確保なども含めた各種課題への対応策など、今後の状況を注目する必要があると思います。