マイクロサービスをコンテナとサーバレスのどちらで運用するかはどのように決めればよいのか。その決定を大きく左右するのは、そのマイクロサービスで何を実行するかだ。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
マイクロサービスアプリケーションの設計や構築に当たっては、コンテナを使ってマイクロサービスをデプロイするのが自然な流れだ。コンテナは、そのスケーラビリティと、まとまりのある1つのアプリケーションアーキテクチャの一部として独立したサービスをホストできる能力から、マイクロサービスを構築する際のデファクトソリューションになっている。
だが、マイクロサービスの少なくとも一部をサーバレスとして運用する方が理にかなっている場合もある。
サーバレスとは、開発者がソフトウェアの実行をオンデマンドでトリガーできるデプロイメントモデルを指す。Amazon Web Services(AWS)の「AWS Lambda」やMicrosoftの「Azure Functions」などのサーバレスプラットフォームを利用すれば、サーバをプロビジョニングする必要なく、実行予定のコードをアップロードできる。Kubernetesクラスタ内でサーバレスを運用可能にする「Knative」などのフレームワークを使っても、同じことが可能になる。
事前に構成した条件を満たすたびに、サーバレスプラットフォームによってコードが自動的に実行される。コードはいったん呼び出されると完了するまで実行される。その後停止され、サーバレスプラットフォームから再び呼び出されるまで待機する。ほとんどの場合、サーバレスサービスはコードの実行時間に基づいて課金される。つまり、実行に費やした時間にしか料金が掛からない。
コンテナを使用すると、アプリケーションやマイクロサービスが、ホストサーバと分離されて運用される。コンテナ内部でソフトウェアを実行するには、開発者は実行予定のコードに基づいたコンテナイメージを作成し、コンテナを管理する環境も構築して、その環境内にコンテナイメージをデプロイしなければならない。デプロイしたコンテナは、エンジニアが手動で稼働を停止するか、エンジニアの代わりにコンテナを管理するオーケストレーションツールがコンテナを終了させるまで、継続的に運用される。
コンテナの課金モデルは、利用するホスティング形態により大きく左右される。一般に、コンテナを運用する場合、インフラのリソースの料金を継続的に支払う必要がある。つまり、コンテナが要求をアクティブに処理していなくても、コンテナはオンデマンドではなく継続的に運用されるため、コンテナをホストするために必要なリソースの料金が発生することになる。
従って、サーバレスとコンテナには主に次のような違いがある。
サーバレスで1つ以上のマイクロサービスをデプロイする場合、デプロイ後のマイクロサービスは、サーバレスプラットフォームから呼び出されたときのみアプリケーション内でアクティブになる。
またサーバレスベースのマイクロサービスは、デプロイメントとアップデートのプロセスも異なる。マイクロサービスをアップデートする場合、オーケストレーションツール内に新しいコンテナイメージをプッシュするのではなく、新しいバージョンのコードをデプロイしなければならない。
こうしたプロセスは複雑な手作業のプロセスになり、コンテナ化したマイクロサービスよりも複雑になる可能性がある。また、こうしたプロセスは、CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインにそれほど緊密には統合されないのが一般的だ。そのため、マイクロサービスのコードを更新する場合、開発環境からサーバレスプラットフォームに移動するための作業で自動化できないものが増える。
また、マイクロサービスの管理にサービスメッシュを使用する場合、サーバレスマイクロサービスをサービスメッシュに統合するのが難しくなる可能性がある。AWS Lambdaなどのサーバレスプラットフォームでは、サービスメッシュのサポートは限定的だ。サービスメッシュは主にコンテナ化されたマイクロサービス間のコミュニケーションを管理する目的で設計されている。そのため、サーバレスでサービスメッシュが機能するように構成するのは、極めて複雑なプロセスになる。
一方で、マイクロサービスをサーバレスとしてデプロイする方が適している特定の条件もある。次のようなマイクロサービスにはサーバレス関数が適している。
Copyright © ITmedia, Inc. All Rights Reserved.