今日では、多くの企業が、IT インフラの開発スピードを高めて時代の最先端に立つために、技術プロセスを進化させる方法を模索しています。こうした進化を実現するにはリードタイムの短縮が必要であり、そのためには最新のプラットフォームに素早く、確実にデプロイできなければなりません。
このようなデプロイを実現するためによく使われている技術として、サーバーレスとコンテナの 2 つが挙げられます。これらの技術はどのようなもので、どこが違うのでしょう？そして、どちらがアプリケーション開発に適しているか判断するにはどうすればよいのでしょうか？この記事では、サーバーレスとコンテナを比較して主な相違点を確認するとともに、みなさんが次のプロジェクトでどちらを採用すべきか判断する際のポイントもご紹介します。
サーバーレスとは？
“サーバーレス = サーバーを使わない” という表現は、やや実態とずれています。実際のところ、サーバーレスコンピューティングでは、サーバー上でワークロードを実行するからです。このサーバーは、開発者から見えないところで機能をホストしており、開発者の管理対象ではありません。そのため、開発者が実際に作業する部分がサーバーレスである、と言ったほうが正確でしょう。
ほとんどのサーバーレス機能は、用途が 1 つだけの小規模かつ軽量のプログラムです。用途には、データベースからの顧客の詳細の取得や、通知の表示など、さまざまなものがあります。
サーバーレス機能はほとんどのクラウドプロバイダーで提供されており、FaaS (サービスとしての機能) とも呼ばれます。有名なものとしては、AWS Lambda、Azure Functions、Google Cloud Functions などがあり、いずれも独自のエコシステムに多数のインテグレーションを展開しています。API エンドポイントやマイクロサービスを提供するのであれば、サーバーレスが最適でしょう。
コンテナとは？
コンテナの説明には、昔から、”貨物コンテナを積んで大海原を進むコンテナ船” というたとえがよく使われます。
コンテナとは、自己完結型で軽量の仮想化技術です。仮想マシン (VM) に似ていますが、仮想化するのはコンピューター全体ではなく、ゲストオペレーティングシステム (OS) とアプリケーションだけです。そのため、VM よりもセットアップが高速で簡単です。コンテナ船のたとえで言えば、船自体がホスト OS とハードウェアに、貨物コンテナがゲスト OS とアプリケーションに相当します。
ビルドしたコンテナは、Amazon Elastic Container Service (ECS) や Docker などを使用することでデプロイ、実行できます。ただし、DevOps の現場では、コンテナのデプロイ先には Kubernetes クラスタを選ぶことがほとんどです。
既存のモノリシックアプリケーションをクラウドネイティブアプリケーションに再構築するのであれば、コンテナが有力な候補になります。ただし、コンテナを効率よく利用するには、アプリケーションを小さく分割することをおすすめします。
サーバーレス vs コンテナ: 類似点と相違点
サーバーレスアプリケーションとコンテナアプリケーションには、似通っている点も、大きく異なっている点もあります。
サーバーレスとコンテナの似ているところ
開発にサーバーレスとコンテナのどちらを使う場合でも、基本的に、アプリケーションをホストするサーバーやインフラのことを気にする必要はありません。ホストのハードウェアおよび OS が、ゲストのアプリケーションおよび OS とは分離されているからです。DevOps に導入する場合、サーバレスやコンテナで使用されるハードウェアを意識する必要はありません。
サーバーレスとコンテナはともに、プロビジョニングするハードウェアを CPU やメモリ、ネットワークなどの性能が高いものに置き換えるだけで拡張できます。
例外は、オンプレミスインフラでコンテナを使用するケースです。この場合、ハードウェアのプロビジョニングは手作業であり、通常は専門のインフラチームが担当します。
また、トラフィックの増減など、ニーズに応じたスケーリングも可能です。コンテナの場合、オープンソースのオーケストレーションシステムである Kubernetes を利用すれば数秒で水平スケールを行えます。同様に、多くの FaaS サービスでも、重要なメトリクス (アプリケーションにルーティングされるリクエストの件数など) に応じて自動的にスケールアウトできます。
サーバーレスとコンテナはともに、CircleCI などの継続的インテグレーションプラットフォームに対応しています。自動化ツールを利用すれば、ビルドが正常に完了するたびに、コンテナイメージまたはサーバーレス機能の新バージョンをインフラプロバイダーにデプロイできます。
サーバーレスとコンテナの異なっているところ
これら 2 つの技術には似ているところもありますが、本質的な違いがあるため、それぞれのユースケースは同じではありません。
サーバーレスとコンテナはともにエラスティックであるため、必要に応じてスケールイン/アウトを行えます。しかし、DevOps でコンテナを採用する場合、特定の基準に応じてスケーリングを自動で行うには、Kubernetes のようなコンテナオーケストレーションソフトウェアが必要です。一方、一般的な FaaS プラットフォームには、こうした自動スケーリング機能がデフォルトで用意されています。
ほとんどのサーバーレス機能は小規模かつ自己完結型の機能であり、役割は 1 つだけです。一般的に稼働時間は短く、数分、あるいは顧客向けであれば数秒です。一方のコンテナは、規模が大きく稼働時間の長いアプリケーションや、役割を複数持つアプリケーションに適しています。
コンテナが適している用途は次のとおりです。
- 従来のオンプレミスインフラから移行する
- 既存のモノリシックアプリケーションをクラウドネイティブにする
- 1 回の実行時間が数時間に及ぶアプリケーションをデプロイする
重大な相違点はプロバイダーの料金体系であり、サーバーレスでは料金は実行にかかった時間の分だけです。これとは対照的に、コンテナではインスタンスをスピンアップし、少なくとも一部は 24 時間 365 日実行することになるので、コストが高くなりがちです。小規模でサーバーレスに適しているアプリケーションをコンテナで動かすと、リソースのムダ使いのせいで不要なコストが瞬く間にかさみ、環境への負荷も大きくなってしまいます。
しかし、コンテナ向けのサーバーレスサービスも存在します。たとえば、AWS Fargate はコンテナのホストおよび実行用プラットフォームであり、発生する料金はコンテナの実行が完了するまでの時間の分のみです。
もう 1 つの相違点として、サーバーレスにはベンダーロックインの懸念があります。関連サービスと統合するには利用中のベンダーのコードが必要なので、特定のエコシステムに縛られやすいと言えます。
対照的に、コンテナでは特定のベンダーに依存することはありません。このような中立性のおかげで、コンテナはどのような言語にも対応しています。一方、サーバーレスアプリケーションでは、限られた言語しか使えません。また、どの言語を使用できるのかは、プロバイダーごとに異なります。
アプリケーション開発におけるサーバーレスとコンテナの選び方
アプリケーションにサーバーレスとコンテナのどちらが適しているかを判断する場合は、上述の要素すべてを考慮に入れることをおすすめします。ただし、判断するうえで一番重要な要素は、アプリケーションアーキテクチャのサイズと構造です。また、料金などの要素も判断材料に入れてください。
小規模なアプリケーションや、複数のマイクロサービスに分割しやすいアプリケーションであれば、サーバーレスアプリケーションとしてデプロイするのがおすすめです。一方、大規模で複雑なアプリケーションは、コンテナの方が適しているかもしれません。実装するサービスが密結合であり、マイクロサービスに分割しづらいのであれば、コンテナが有力な候補になります。
また、サーバーレスサービスには制限があるので、アプリケーションによってはコンテナが向いているケースもあります。たとえば、アプリケーションの言語がサービスのサポート対象外である場合や、アプリケーションの実行時間が長い (機械学習アプリケーションなど) 場合がこれに該当します。
ただし、サーバーレスとコンテナのどちらかを選ばなければいけないわけではありません。サーバーレスとコンテナは相互排他的ではないからです。コンテナが必要なときにはコンテナを使い、サーバーレスが適しているときにはサーバーレスも組み合わせるというように、両方を同時に使ってもよいでしょう。前述のように、これら 2 つの技術のギャップを埋める、コンテナをホストするサーバーレスサービスも存在します。
まとめ
サーバーレスとコンテナはともに、イノベーションの早期実現につながるスケーラブルなクラウドネイティブアプリケーションを開発するうえで有用です。それぞれの始め方については、次のチュートリアルをご覧ください。
サーバーレスとコンテナのどちらを採用する場合でも、CircleCI の継続的インテグレーションプラットフォームを導入してビルド、テスト、デプロイを自動化することをおすすめします。ご自身に適したサーバーレス/コンテナの使い方をつかめたら、CI/CD パイプライン (英語)で開発プロセスを最適化および効率化する方法もご覧ください。
