- 2016/09/07 掲載
サーバーレスアーキテクチャとは何か？ AWSの「Lambda」と「EC2」を比較して解説
CIOのためのAWS最新動向（1）
ITインフラの選択肢が広がる中で、Amazon.com（以下、アマゾン）により提供されているクラウドサービス「Amazon Web Service（以下、AWS）」が存在感を示しています。今回は、数多くのAWSプロジェクトに携わるcloudpack CTO 鈴木宏康 氏が、近年エンタープライズIT業界で注目されつつある新たな概念である「サーバーレスアーキテクチャ（サーバーレス）」の定義やメリット・デメリット、AWSにおけるサーバーレス型サービス「AWS Lambda（以下、Lambda：ラムダ）」と「EC2」の違い、サーバーレス普及によるITインフラの将来像などについて解説します。
連載一覧/関連記事
cloudpackの考える「サーバーレスアーキテクチャ」とは
最近、エンタープライズIT業界で「サーバーレスアーキテクチャ」あるいは「サーバーレス」という言葉を耳にするようになりました。このサーバーレスとは、いったいどのような概念なのでしょうか。サーバーレスの文脈で登場するサービスには、アマゾンの「Lambda」、グーグルの「Google Cloud Functions」、IBMの「OpenWhisk」、マイクロソフトの「Azure Functions」など様々なものがあり、定義が異なっていますので、ここではcloudpackの考える「AWSにおけるサーバーレス」の意味を解説します。
AWSにおけるサーバーレスとは、「Amazon S3、DynamoDB、Lambdaを活用することで、インスタンスベースの仮想サーバー（EC2、ElastiChache、Redshiftなど）を使わずにアプリケーションを開発するアーキテクチャ」を指します。
一般にシステムの運用には、プログラムを動かすためのサーバーが必要です。そしてそのサーバーは、常に稼働していなければなりません。サーバーレスは、サーバーを必要としないので、それ自体のコストがかからないのはもちろん、運用や保守のコスト、さらにシステムの開発工数を減らす効果もあり、コストの削減につながりやすいとされています。
LambdaはAWSの年次イベント「re:Invent 2014」で発表された、サーバーを必要としないイベント駆動型のプログラム実行環境です。
ここでいう「サーバーを必要としない」というのは、Lambda自体が「サーバーを使っていない」ということではありません。Lambdaをはじめ、実際のクラウドサービスはサーバー上で動いていますので、その言葉通りに解釈するのは若干違和感があります。そこで別の観点から表現すると、サーバーレスアーキテクチャの定義は「サーバーを必要とせず、かつ時間による従量課金サービスを利用しない（後述）アーキテクチャ」とも言い換えられるでしょう。
AWSの「EC2」と「Lambda」は何が違うのか？
関連記事
それでは、AWSの仮想マシン「EC2」と「Lambda」を比較してみましょう。
EC2のインスタンスは、汎用的なサーバーです。起動直後はOSがインストールされただけの状態なので、すぐにシステムで利用することはできません。アカウントなどの初期設定をし、システムの提供に必要なデータベースソフトやHTTPサーバーソフトなどの各種ミドルウェアをインストール・設定して環境を整えていくことで、ようやくプログラムを動かせる環境が整います。
一方Lambdaでは、インフラ環境の整備が必要ありません。Lambdaの実行環境は、AWSが提供してくれるからです。開発者は、事前にインフラ環境の準備をする必要がなく、プログラムを用意さえすれば、直ちに実行できます。
LambdaにはAWSの各種サービス（ストレージ、データベース、メッセージ、電子メール、ログなど）が用意されており、それらを糊付けするように組み合わせることで、簡単にシステムを運用できるようになります。例えばメールを送信すると、それがトリガーとなって、Lambda関数がコールされ、差出人のアドレスをデータベースに書き出せる「メールアドレスの自動登録システム」などが構築できます。
（出典：cloudpack提供資料）
EC2とLambdaは、課金の仕組みにも違いがあります。EC2では、利用分（仮想サーバーのインスタンスを立ち上げている時間）だけ課金されます。起動したインスタンスのなかで、プログラムが1回動こうが100回動こうが、料金は一定になります。
これに対してLambdaは、プログラムを実行した「時間（100ミリ秒単位）」×「回数」で課金されます。つまり、同一サービスを構築する際に、EC2を使うか、Lambdaを使うかによって、料金が異なってくる場合があります（注1）。
（注1）経験上インパクトは少ないのですが、正確性のために述べておくと、プログラムの実行によるデータ転送量とディスクI/Oの頻度などによっては、プログラムの実行時間と回数以外に課金が発生する場合があります。
（出典：cloudpack提供資料）
例えば、1日数回のペースでバックアップを取るケースです。EC2では仮想サーバーのインスタンス1台ぶん立ち上げて待機しておき、定時になったらバックアッププログラムを起動するため、コストも1日分かかってしまいます（1時間単位の課金）。
Lambdaでは、定時のみプログラムを実行できるため、コストも数回の実行時間のみで済むわけです。つまり、従来のように仮想サーバーを立て、継続的にインスタンスを動かす思想とは全く異なるアーキテクチャが、AWSにおけるサーバーレスの考え方なのです。
こうしてみると、LambdaのほうがITインフラのコストを最適化しやすいように思えますが、制約やデメリットもあります。例えば、1回の処理時間は最大でも5分以内に制限されていること、開発言語はPython、JavaScript（Node.js）、Javaのみと限られていること、同時起動数はアカウント（リージョン）あたり100に上限が設定されていること（上限アップの申請は可能）などです。
（出典：cloudpack提供資料）
これらの条件から逸脱する場合には、EC2を使うことになるでしょう。またEC2でも効率よく利用できるならば、Lambdaよりもコスト的に有利になるケースもありますので、ケースバイケースで適用していくほうがよいでしょう。
Lambdaを使って開発したWebサービスの例
Lambdaのメリットについて、他の事例を用いてもう少し説明しましょう。ここで想定するのは、いつアクセスされるのか分からないようなWebサービスを使う場合です。このWebサービスをEC2を使って構築する場合、たとえ1日に100回ぐらいのアクセスしかない場合でも、1日中ずっと仮想サーバーのインスタンスを立ち上げておく必要があります。しかし、Lambdaであれば、アクセスした回数分だけのコストで済むわけです。そう考えると、Lambdaは利用頻度が少ないWebフロントシステムにも適していることが理解できるでしょう。
ここでは詳しいことは割愛しますが、Lambdaは、イベント駆動型プログラミング（スクリプト）によってシステムを動かすことになります。何かスケジュールされたイベントが発生したり、事前に割り当てたURLが（API Gatway経由で）アクセスされた場合、あるいは前出のようなAWSの各種サービスがトリガーになって、「Lambda関数」と呼ばれるスクリプトが起動する仕組みになっています。以下の図はモバイルプッシュ配信システムの例ですが、Lambdaを使った場合、EC2の場合と比較すると約5分の1のコストで開発できます。
（出典：cloudpack提供資料）
（出典：cloudpack提供資料）
サーバーレスの本質は「ITインフラの変動費化」にある
ここまで説明すると、ある程度は想像がつくと思いますが、最近サーバーレスが注目されるようになった理由は、なによりITコスト面でメリットがあるからに他なりません。別の表現をすれば、インフラの「固定費」をどれだけ「変動費」にできるかということです。これがサーバーレスにしたい本質的な理由になります。オンプレミスの場合は、ITコストは固定費として認識されていました。また、クラウドサービスに移行したとしてもEC2のような仮想サーバーを構築している場合は、社内にインフラがあるかないかの違いだけで、利用した時間分だけの固定費がかかっているのと同様だったのです。
一方、サーバーレスのLambdaでは、ITコストを完全に変動費に置き換えられます。変動費になったほうが用途の幅が広がり、スモールスタートもしやすくなるわけです。
サーバーレスが注目されたもう1つの理由は、共通化された運用の手間を吸収してくれるということです。EC2ではログの管理やセキュリティパッチを当てるなど、ある程度のお守りが求められますが、LambdaではAWS側で面倒なことをやらずに済むように担保してくれるため、上位アプリケーションの開発に専念できるわけです。
これはAWSにおける「責任共有モデル」という考え方に関わる話になりますが、詳細は別の回で説明させていただく予定です。いずれにしても、共通化された運用をやってもらえるということは、人件費の削減にかかわる問題であり、セキュリティのリスク回避にもつながります。自分たちで何でもやるよりも、大規模でスケールメリットがあるAWSに委ねたほうが、ITインフラの品質を向上させることができるのです。
サーバーレスで企業のITインフラはどう変わるか？
サーバーレス化が普及することによって、ITインフラの固定費が変動費に変わり、ITコストも抑えられるようになるでしょう。さらに、共通化された運用をAWS側でやってもらえれば、小規模企業でも高品質なプロダクトをつくれるようになっていくわけです。そうなれば当然ながら、新たなチャレンジの機会も増えてくるはずです。もし新たなシステムやサービスが上手くいかなければ新しいものに変更すればよいため、そのサイクルも短くなります。結果的に、世の中に良いシステムやサービスが残り、企業に導入されていくことになるでしょう。
いずれ将来的には、企業の基幹系や情報系でもサーバーレスの仕組みが導入されることになると予想されます。例えば、まずは基幹システムをマイグレーションによって移行し、その周辺の運用システム（ジョブサーバーなど）をつくり替える際に、運用系をLambdaで置き換えていく可能性は十分にあり得ることです。
この潮流が大きくブレイクするのは、おそらく大企業の基幹システムが全面的にAWSに刷新し、いくつかの成功事例が出てきたときでしょう。そうなれば、他社の基幹系でも新たに「サーバーレス・マイグレーション」が採用されるようなトレンドになるかもしれません。
次回は、AWSマイグレーション検討のポイントについてご紹介したいと思います。
関連記事
関連コンテンツ
関連タグ
タグをフォローすると最新情報が表示されます
あなたの投稿
PR
PR
PR
