サーバレスアーキテクチャ/マイクロサービス向きの使い方について

これから新機能をマイクロサービスとして作る場合、どういった用途であれば向いている言えるでしょうか。向き不向きを正しく把握できれば、開発しやすく、かつメンテナンスしやすいシステムが作れるはずです。

サーバレスアーキテクチャは長時間のアクセスが求められるような仕組みは不向きです。そのため、データベースもRDBMSよりNoSQLであったりKVSのものが向いていると言えます。一瞬のアクセスで結果を受け取って返す、といったものが向いています。

長時間の処理が必要なものは現状のサーバ環境を使った仕組みのが安心でしょう。

基本的にマイクロサービスでは1つのサービスが1つの処理を行います。そのため自然とコード量も短くなるでしょう。あまり長くなると処理時間もかかってしまいます。必要があれば複数のマイクロサービスを組み合わせることもできるでしょう。

APIが1URLに対して1リソースとして独立性、明確さをメリットとしているようにマイクロサービスも1つ1つのURLでできることを明確にすることで使いやすくなります。

サーバで大量のアクセスをさばこうと思うと相当なリソースが必要ですが、サーバレスアーキテクチャの場合は気にすることはありません。大量のアクセスをまとめて処理できます。かつ、処理が終わったらサーバが存在していないのと同じで料金もかかりません。

ただし大量のアクセスによってバッグエンド側に影響を及ぼす可能性があります。サーバレスアーキテクチャが問題なかったとしても、従来のアーキテクチャ部分が残っていると、そこがボトルネックになるはずです。

サーバレスアーキテクチャの欠点として、最初の処理に対してレスポンスが非常に悪いという問題があります。これはリクエストによって実行環境がデプロイされるためです。一度起動した後、アクセスがあればしばらく実行環境は残り続けるのでレスポンスは維持されます。

そのため、利用側としても即応性が求められるような場所には利用しない方が良いでしょう。もちろん常にアクセスが発生しているならばレスポンスが良いはずですが、それも100%とは言い切れません。

サーバレスアーキテクチャでは個々の機能単位でコードが独立しています。そのため、一部だけライブラリをバージョンアップしたりハードウェアリソースをアップグレードすることもできます。複雑性を増すのであまりお勧めしませんが、柔軟なシステム構成を実現できるでしょう。

開発陣が大きなチームになってきた時、システム全体を把握するのは大変ですがマイクロサービスであれば個々のシステムについて理解していけば良いというメリットがあります。

マイクロサービスでは基本的にJSONやXMLを返却するものが多いようです。実際、APIをマイクロサービスで実現するのは相性が良いでしょう。マイクロサービス同士でメッセージを交換する際にもAPIが使われます。

逆にHTTPであったり、画像などを返すのであれば従来のアーキテクチャで十分と言えるでしょう。RESTful APIもリソース単位で独立しているように、サーバレスアーキテクチャでシステムを構築する際にはまずAPIを軸に考えていくのが良いでしょう。

マイクロサービスを突き詰めていくと何でもマイクロサービス化したくなります。しかし向き不向きがあり、向いていないものまで変えてしまうと却って変更やバージョン管理が煩雑になったりします。決して銀の弾丸ではありません。

特性を正しく判断してサービス開発に活かしてください。