コンテナとサーバーレスの特長、使い分け（初心者・非エンジニア向け）

NCDCのマーケティング担当、播磨です。

先日、AWS Builders Online Series​​でコンテナ、サーバーレス、マイクロサービスアーキテクチャなどについて学ばせてもらいました。

そこで学んだことを記事にまとめる第二弾です。
（AWS Builders Online Seriesの内容そのままではなく、かなり要約したり独自の視点も加えたりしながら内容はアレンジしています）

第一弾では「なぜクラウドネイティブなモダンアプリケーションが必要なのか​？​」というテーマを記事にしましたが、今回のテーマは「コンテナとサーバーレスの使い分け」です。
なお、元ネタのAWSのセッションでは「ある程度知識がある方向けの情報」とされていたのですが、僕自身はエンジニアではないので、この記事は初心者・非エンジニアでもわかりそうなところに重きを置いた内容だと考えてください。

コンテナとサーバーレスの何がいいのか？

まずはコンテナとサーバーレスが登場した歴史の簡単な紹介から。

下図は物理マシンから仮想マシンへ、仮想マシンからコンテナやサーバーレスへ…抽象化のレベルが上がるにつれて、エンジニアはビジネスロジックに集中できるようになるという概念を示した図です。

エンジニアが「ビジネスロジックに集中できる」だとわかりにくいので、少し説明を足しつつ言い換えると「サーバー管理のような手間がかかる部分は他人に任せて、ビジネス的な価値を産むアプリケーションの開発に注力できる環境を手に入れること」だといえます。

上図で見て欲しいポイントは次の通りです。

• 物理マシンの上にシステムを作っていた当時は、物理マシンを管理するさまざまな手間もかかるし、物理マシンを設定するための知識も求められた
• 仮想マシンが登場すると、物理マシンを管理する必要がなくなり、物理マシンの知識を持たなくてもよくなった（いつ頃からかというと、AWSは2006年にAmazon EC2をリリースしています）
• コンテナ（詳細は後述します）という技術が広まると、仮想マシンの中でもコンテナの部分だけを把握すればよくなり、より管理が楽になった（2013年にDockerというサービスがリリースされたことがきっかけ）
• サーバーレス（詳細は後述します）という技術が広まると、コンテナでは必要だった細かい設定も不要になり、あらゆる管理から解放された（AWSは2014年にサーバーレスサービスLambdaをリリースしました）

この時点ではコンテナやサーバーレスのイメージが掴めていない方もいるかもしれませんが「抽象化が進むと、エンジニアがビジネスロジックに集中できるようになる」という理屈はわかっていただけると思います。

サーバーの管理のような新たな価値を生まない手間をできるだけ減らして、スピーディーなシステムの立ち上げ・改善をできるようにする。これはシステムのモダナイゼーションを図るうえで重要なテーマなので、近年、コンテナやサーバーレスは多くのシステムで活用されています。
あるセキュリティベンダーの調査では78%もの新規アプリケーションがコンテナもしくはサーバーレスでつくられているそうです。

サーバーレスとは？

この記事のゴールは「コンテナとサーバーレスの使い分け」の説明ですが、比較しやすいように、コンテナとは？ サーバーレスとは？ それぞれ特長を確認していきます。
（そんなの知ってるという方は読み飛ばしてください）

まず、上図で抽象化のレベル最上位のサーバーレスから見ていきます。

アプリケーションを作るには、アプリケーションのコードを書く以外にも必要なものがあります。中でも重要なのはコードを動かす環境です（この辺りの話は先の抽象化の説明と一部重複します）。

コードを動かす環境として、物理マシンそのものを自社で管理するにせよ、仮想マシンを使うにせよ、マシン（コンピュータ）は必要です。
ただマシンがあるだけではアプリケーションは動かせないので、次にLinuxやWindowsなどのOSを選択する必要があります。OSの種類だけではなくバージョンも指定する必要があるかもしれません。
さらに、アプリケーションとOSの中間に存在するミドルウェアやランタイムというものを決めて、コードを動かす環境を整えていく必要があります。

従来のやり方では、アプリケーションそのものの開発をする前にこうした準備が必要でした。
もちろんアプリ開発の担当者がすべて自分自身でやる必要はないですが、多くの場合、マシンの上に何を載せて欲しいのか説明する手順書を用意してインフラ管理者に作業を依頼し、環境を用意してもらうのを待つ必要があったのです。
最初の設定時はもちろん、その他にも運用中に変更が生じたり、利用しているソフトウェアのバージョンアップが必要になったりすれば、その都度こうした対応が必要です。
要するに、アプリのコードを書く以外に面倒臭い工程がたくさんありました。

サーバーレスとは、簡単にいうとこの面倒臭い部分を全部他人任せにして、自らは用意された環境に合うようにコードを書くだけでアプリケーションをつくれる仕組みです。
「他人任せ」にしたところはAWS等のクラウド事業者が勝手に良きようにしてくれると考えてください。

サーバー「レス」といっても実際にはクラウド事業者がどこかにサーバーを置いているため物理的にサーバーが存在しないわけではないのですが、サーバーレスは仮想サーバーすら常時起動はしない仕組みなので、利用者はサーバーを意識する必要がまったくないといえます。

下のサーバーレスを示すイメージを見ると、「Code」以外はすべて「Serverlessプラットフォーム」と一括りにされています。つまりアプリケーションのコードを書いて、与えられたプラットフォームに載せるだけという仕組みです。
AWSでいえばAWS Lambda​​というサービスを利用することで簡単にこのような状態を実現できます。

サーバーレスの制約

​​「Lambda​​というサービスを利用するだけ」なのでサーバーレスの導入は簡単なのですが、もちろんそれによる制約は生まれます。Lambda​​のお作法に則ってアプリケーションを作らなければいけません。

※サーバーレス＝AWS Lambdaではなく、例えばGCP（Google Cloud Platform）でもサーバーレスな構成は実現できるのですが、本記事内の説明はAWSの利用を前提とした話と理解してください

「Lambda​​のお作法」の代表的なポイントは、Lambdaはイベント駆動型のサービスであるため、Lambda以外のどこかからイベントを受け取る必要があることです。

必ずLambda以外のところでトリガーになるイベント（上の例では「画像がアップロードされた」）を用意する必要があります。
また、トリガーによって一瞬だけサーバーが起動しアプリが実行されますが、役割を終えたらすぐに消えるのも制約の一つです（短時間の動作が前提となります）。

ここで一旦簡単にまとめておくと

• サーバーレスの仕組みはサーバーの管理から完全に解放されるというメリットがある。
• 一方、イベント駆動等の前提条件があり、伝統的なアプリ開発とはお作法が違うため、その点がデメリットになる場合もある。

…という感じでしょうか。

伝統的なやり方とお作法が違うと何がデメリットなのかというと、自由にOSやミドルウェアやランタイムを選んでいた人にとっては、Lambdaでの開発は慣れない・わかりにくいものとなってしまうため学習コストがかかるかもしれません。

また、先に「AWS Lambda​​というサービスを利用すると簡単に実現できる」と書きましたが、それは「AWS Lambdaに依存したアプリを作る」こととイコールなので、いわゆるベンダーロックという問題も生じます（簡単に他のサーバーに載せ替えるようなことはできなくなります）。

コンテナとは？

面倒臭いサーバーの管理はやりたくないけど、サーバーレスほどの制約は受けたくない（自分で自由に設定できる範囲を広げたい）という場合に適しているのが、コンテナという仕組みです。
（これだとおそらくかなり雑な説明だと思いますが、サーバーレスとの対比という観点に絞ると、このような表現になります）

コンテナとは何かというと、アプリケーションを動作させるのに必要なライブラリやアプリケーションを１つにまとめたものです。
コンテナの中にはアプリケーションコードとともに、コードを実行するために必要なもの（ランタイム、ライブラリなど）がすべて含まれているので、そのコンテナをコンテナプラットフォームに乗せるだけでアプリケーションが動きます。

その名の通りの（容器、入れ物などを表す英語「container」に由来する）技術で、貨物輸送用のコンテナのように「大量のモノ（データ）を、早く、低コストで、簡単に、事故なく運搬する」ことが可能になります。
またサーバーレスとの違いに目を向けると「イベント駆動」や「短時間の処理のみ」という制約がないことも特長です。

下のイメージ図で「Code」のほかに「Middleware」と「Runtime」も自由に扱えるようになっているのがサーバーレスとの差です。
それ以外の部分は用意されているプラットフォーム（コンテナプラットフォーム）を使えば良いので、昔のやり方（OSから設定していたようなやり方）に比べれば管理の手間は大幅に削減されているといえます。

コンテナについてはこちらの記事でもう少し詳しく説明しているので、併せてご覧ください
Kubernetesの基礎から実際に使ってわかったメリット・デメリットまで解説

ここで一旦簡単にまとめておくと

• サーバーレスとは異なり、ランタイムやライブラリも自由にできるコンテナは制約が少なく、通常のOSを使ったアプリケーション開発とほとんど変わらない（細かく見れば違いはあるが、気づかない人もいる程度の違いなのだそうです）。
• 一方、サーバーレスと比較すると抽象度が高くないため、管理者が対応しなければならない範囲が広く、アプリケーションのコードを書く以外の経験やスキルが要求される。​​

…という感じでしょうか。

コンテナとサーバーレスの使い分け

コンテナとサーバーレスの特長はわかった。でも、自分がつくりたいアプリではどちらを選択すべきなのか迷う…という方もいるのではないでしょうか。実際、AWSの方もよく「コンテナとサーバーレスのどちらがいいのか？」と質問されるそうです。

そんな人のために、AWS Builders Online Series​​のこのセッションでは「コンテナ／サーバーレス（AWS Lambda）の選択に役立つデシジョンツリー（Decision Tree）」を紹介していました。
とてもわかりやすかったので、そのまま紹介します。
これが最後のテーマ「コンテナとサーバーレスの使い分け」です。

多少知識があれば上の図だけでも十分理解できそうですが、一応各ステップの詳しい説明もこの下に書いておきます。

デシジョンツリー

管理単位は？

管理したい対象がプラットフォーム全体なのか？アプリケーションコードなのか？

• アプリケーションコード単位でコントロールしたい→サーバーレスの検討を継続
• マニフェストファイルを使ってプラットフォーム全体のことを一気にコントロールしたい→コンテナが向いている

実行時間は？

Lambdaではタイムアウト時間を1秒から15分の間で設定します。

• 最長でも15分以下→サーバーレスの検討を継続
• 15分以上かかる可能性がある→コンテナが向いている

メモリサイズは？

Lambdaでは128MBから10GBの間で設定します。

• 10GB以下のメモリでOK→サーバーレスの検討を継続
• 10GB以上のメモリがほしい→コンテナが向いている

（なおメモリサイズは先の実行時間に影響するので、メモリと実行時間はセットで検討する必要があります）

CPU処理のみか？

LambdaではCPUのみが利用可能です。最近はマシンラーニングでGPUを使いたいというニーズも多いようですが、CPU以外が必要なものにはLambdaでは利用できません。

• CPUのみでOK→サーバーレスの検討を継続
• CPU以外も使う→コンテナが向いている

ステートレス処理か？

Lambdaはステート（状態）を保持する機能を持たないため、ひとつひとつのアクセスごとの対応となります。

• ステートレス処理でOK→サーバーレスの検討を継続
• ステートレスでは困る→コンテナが向いている

※NCDCのエンジニアに聞いたところ、コンテナなら必ずステートを保持できる（ステートフル）というものではないらしいです。そのため一概に「ステートフル＝コンテナ向き」とは言えないのですが、ここではあくまで「Lambda単体でステートフルは実現できない」という制約を説明していると捉えてください。
なお、サーバーレスの場合もLambdaでステートを保持しようとせず外部のDBを併用するような仕組みなら実現は可能とのこと。このあたりの詳しいことを相談したい方はお問い合せください。

バースト制限内か？

Lambdaにはバースト（一時的な負荷増大時に処理性能を上げる仕組みのこと）の制限があり、並行起動できる数に制限があります（数はリージョンにより異なる）。

• バースト制限内でOK→サーバーレスの検討を継続
• バースト制限内で収まらない→コンテナが向いている

その他の検討項目

AWSの方が説明されていたディシジョンツリーを紹介しましたが、これは基本的な内容で、もちろんこれ以外にもLambda採用の検討に用いる項目はあります。
NCDCのエンジニアに聞いたところ、例えばLambdaが停止状態から起動するまでの時間（Cold Startといいます）も、Lambdaを採用するか否かを検討する際によく議題になるそうです。

大事なのは「適材適所」で使うこと

闇雲にサーバーレスとコンテナの優劣を比較しようとしても意味はありません。上記のデシジョンツリーでいくつか判断のポイントが挙げられているとおり、アプリの特性から適性を見ることが重要です。
適性が高いものをサーバーレスでつくれば多くのメリットが得られますが、適性が低いものを無理やりサーバーレスで実現しようとすると、メリットどころか苦労ばかりが大きくなるかもしれません。

コンテナとサーバーレスの使い分けを考える際は、アプリの特性・機能要件に加え、非機能要件やさまざまな条件も考慮して、総合的な評価をした上で適材適所な選択を行うことが大切です。

コンテナやサーバーレスの相談はぜひNCDCへ

NCDCではここで取り上げたコンテナやサーバーレス、またはマイクロサービスなどの新しい技術を導入したい企業に、アーキテクチャコンサルティングや、リファレンス実装、技術コンサルティングなどのサービスを提供しています。

ビジネスモデルやビジネスプロセス、非機能要件等を考慮し、サーバーレスとコンテナの比較検討などを行う段階からご支援が可能です。
設計から実装まで幅広くカバーしていますので、システムのモダナイゼーションでお悩みの方は是非ご相談ください。