マイクロサービスをサーバレスで構築するのが適しているケースとは？：コンテナで構築するのと何が違うのか

　コンテナを使用すると、アプリケーションやマイクロサービスが、ホストサーバと分離されて運用される。コンテナ内部でソフトウェアを実行するには、開発者は実行予定のコードに基づいたコンテナイメージを作成し、コンテナを管理する環境も構築して、その環境内にコンテナイメージをデプロイしなければならない。デプロイしたコンテナは、エンジニアが手動で稼働を停止するか、エンジニアの代わりにコンテナを管理するオーケストレーションツールがコンテナを終了させるまで、継続的に運用される。

　コンテナの課金モデルは、利用するホスティング形態により大きく左右される。一般に、コンテナを運用する場合、インフラのリソースの料金を継続的に支払う必要がある。つまり、コンテナが要求をアクティブに処理していなくても、コンテナはオンデマンドではなく継続的に運用されるため、コンテナをホストするために必要なリソースの料金が発生することになる。

　従って、サーバレスとコンテナには主に次のような違いがある。

• サーバレスがオンデマンドでのみ実行されるのに対し、コンテナは継続的に実行される・サーバレスのデプロイにはホスティング環境の設定を必要としないが、コンテナには必要
• ほとんどの場合、サーバレスは特定のクラウドサービスにデプロイされるのに対し、コンテナはパブリッククラウドやオンプレミスなど多種多様な環境で容易に運用できる
• コンテナはアプリケーションがアイドル状態でも課金されるのに対し、サーバレス関数は実行時間にのみ料金が発生する

サーバレスでマイクロサービスを構築する場合の課題

　サーバレスで1つ以上のマイクロサービスをデプロイする場合、デプロイ後のマイクロサービスは、サーバレスプラットフォームから呼び出されたときのみアプリケーション内でアクティブになる。

　またサーバレスベースのマイクロサービスは、デプロイメントとアップデートのプロセスも異なる。マイクロサービスをアップデートする場合、オーケストレーションツール内に新しいコンテナイメージをプッシュするのではなく、新しいバージョンのコードをデプロイしなければならない。

　こうしたプロセスは複雑な手作業のプロセスになり、コンテナ化したマイクロサービスよりも複雑になる可能性がある。また、こうしたプロセスは、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインにそれほど緊密には統合されないのが一般的だ。そのため、マイクロサービスのコードを更新する場合、開発環境からサーバレスプラットフォームに移動するための作業で自動化できないものが増える。

　また、マイクロサービスの管理にサービスメッシュを使用する場合、サーバレスマイクロサービスをサービスメッシュに統合するのが難しくなる可能性がある。AWS Lambdaなどのサーバレスプラットフォームでは、サービスメッシュのサポートは限定的だ。サービスメッシュは主にコンテナ化されたマイクロサービス間のコミュニケーションを管理する目的で設計されている。そのため、サーバレスでサービスメッシュが機能するように構成するのは、極めて複雑なプロセスになる。

マイクロサービスにサーバレスを使用するタイミングは？

　一方で、マイクロサービスをサーバレスとしてデプロイする方が適している特定の条件もある。次のようなマイクロサービスにはサーバレス関数が適している。

• 通常とは異なる種類のユーザーリクエストを処理する機能など、アプリケーションの中核部分ではなく、たまにしか必要とされない機能を提供するマイクロサービス
• 頻繁にはアップデートされず、アップデートを手動でデプロイできるか、サーバレスプラットフォームの限定的なCI/CDを使用して自動適用できるマイクロサービス
• サービスメッシュに統合する必要がないか、サービスメッシュを使用しないアプリケーションのマイクロサービス