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

マイクロサービスをコンテナとサーバレスのどちらで運用するかはどのように決めればよいのか。その決定を大きく左右するのは、そのマイクロサービスで何を実行するかだ。

» 2023年11月30日 12時00分 公開
[Chris TozziTechTarget]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 マイクロサービスアプリケーションの設計や構築に当たっては、コンテナを使ってマイクロサービスをデプロイするのが自然な流れだ。コンテナは、そのスケーラビリティと、まとまりのある1つのアプリケーションアーキテクチャの一部として独立したサービスをホストできる能力から、マイクロサービスを構築する際のデファクトソリューションになっている。

 だが、マイクロサービスの少なくとも一部をサーバレスとして運用する方が理にかなっている場合もある。

サーバレスとコンテナの違い

 サーバレスとは、開発者がソフトウェアの実行をオンデマンドでトリガーできるデプロイメントモデルを指す。Amazon Web Services(AWS)の「AWS Lambda」やMicrosoftの「Azure Functions」などのサーバレスプラットフォームを利用すれば、サーバをプロビジョニングする必要なく、実行予定のコードをアップロードできる。Kubernetesクラスタ内でサーバレスを運用可能にする「Knative」などのフレームワークを使っても、同じことが可能になる。

 事前に構成した条件を満たすたびに、サーバレスプラットフォームによってコードが自動的に実行される。コードはいったん呼び出されると完了するまで実行される。その後停止され、サーバレスプラットフォームから再び呼び出されるまで待機する。ほとんどの場合、サーバレスサービスはコードの実行時間に基づいて課金される。つまり、実行に費やした時間にしか料金が掛からない。

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

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

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

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

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

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

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

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

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

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

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

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

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。