開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 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)CTO 鈴木宏康

アイレット(cloudpack)CTO 鈴木宏康

アイレット株式会社取締役CTO。1975年、愛知県生まれ。東京工業大学大学院修士課程修了。在学時よりベンチャー企業でインターネットに関する業務に携わり、現在はクラウド(主にAmazon Web Services)上での開発・運用を軸とした事業の、業務の中心として活躍。最近は、携わるさまざまなAWSプロジェクトに対し、プロジェクトの成功を加速させるために、どのようにサーバーレスアーキテクチャを利用するべきかを、常に模索している。

photo
「サーバーレスアーキテクチャ」の基本を解説!



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をはじめ、実際のクラウドサービスはサーバー上で動いていますので、その言葉通りに解釈するのは若干違和感があります。そこで別の観点から表現すると、サーバーレスアーキテクチャの定義は「サーバーを必要とせず、かつ時間による従量課金サービスを利用しない(後述)アーキテクチャ」とも言い換えられるでしょう。

photo
Lambdaは、スクリプト(Lambda 関数)を実行するための実行環境であり、AWSのさまざまなサービスを組み合わせることができる

AWSの「EC2」と「Lambda」は何が違うのか?

関連記事
 それでは、AWSの仮想マシン「EC2」と「Lambda」を比較してみましょう。

 EC2のインスタンスは、汎用的なサーバーです。起動直後はOSがインストールされただけの状態なので、すぐにシステムで利用することはできません。アカウントなどの初期設定をし、システムの提供に必要なデータベースソフトやHTTPサーバーソフトなどの各種ミドルウェアをインストール・設定して環境を整えていくことで、ようやくプログラムを動かせる環境が整います。

 一方Lambdaでは、インフラ環境の整備が必要ありません。Lambdaの実行環境は、AWSが提供してくれるからです。開発者は、事前にインフラ環境の準備をする必要がなく、プログラムを用意さえすれば、直ちに実行できます。

 LambdaにはAWSの各種サービス(ストレージ、データベース、メッセージ、電子メール、ログなど)が用意されており、それらを糊付けするように組み合わせることで、簡単にシステムを運用できるようになります。例えばメールを送信すると、それがトリガーとなって、Lambda関数がコールされ、差出人のアドレスをデータベースに書き出せる「メールアドレスの自動登録システム」などが構築できます。

画像
Lambdaとよく組み合わせて使われる主なAWSのサービス。ストレージ、NoSQLデータベース、メッセージ、電子メール、リソースモニタリング、ログモニタリング、キューイングなどが用意されている
(出典:cloudpack提供資料)


 EC2とLambdaは、課金の仕組みにも違いがあります。EC2では、利用分(仮想サーバーのインスタンスを立ち上げている時間)だけ課金されます。起動したインスタンスのなかで、プログラムが1回動こうが100回動こうが、料金は一定になります。

 これに対してLambdaは、プログラムを実行した「時間(100ミリ秒単位)」×「回数」で課金されます。つまり、同一サービスを構築する際に、EC2を使うか、Lambdaを使うかによって、料金が異なってくる場合があります(注1)。

(注1)経験上インパクトは少ないのですが、正確性のために述べておくと、プログラムの実行によるデータ転送量とディスクI/Oの頻度などによっては、プログラムの実行時間と回数以外に課金が発生する場合があります。

画像
Lambdaの課金の仕組み
(出典:cloudpack提供資料)


 例えば、1日数回のペースでバックアップを取るケースです。EC2では仮想サーバーのインスタンス1台ぶん立ち上げて待機しておき、定時になったらバックアッププログラムを起動するため、コストも1日分かかってしまいます(1時間単位の課金)。

 Lambdaでは、定時のみプログラムを実行できるため、コストも数回の実行時間のみで済むわけです。つまり、従来のように仮想サーバーを立て、継続的にインスタンスを動かす思想とは全く異なるアーキテクチャが、AWSにおけるサーバーレスの考え方なのです。

 こうしてみると、LambdaのほうがITインフラのコストを最適化しやすいように思えますが、制約やデメリットもあります。例えば、1回の処理時間は最大でも5分以内に制限されていること、開発言語はPython、JavaScript(Node.js)、Javaのみと限られていること、同時起動数はアカウント(リージョン)あたり100に上限が設定されていること(上限アップの申請は可能)などです。

画像
Lambdaにおける代表的な制約
(出典:cloudpack提供資料)


 これらの条件から逸脱する場合には、EC2を使うことになるでしょう。またEC2でも効率よく利用できるならば、Lambdaよりもコスト的に有利になるケースもありますので、ケースバイケースで適用していくほうがよいでしょう。

Lambdaを使って開発したWebサービスの例

 Lambdaのメリットについて、他の事例を用いてもう少し説明しましょう。ここで想定するのは、いつアクセスされるのか分からないようなWebサービスを使う場合です。

 このWebサービスをEC2を使って構築する場合、たとえ1日に100回ぐらいのアクセスしかない場合でも、1日中ずっと仮想サーバーのインスタンスを立ち上げておく必要があります。しかし、Lambdaであれば、アクセスした回数分だけのコストで済むわけです。そう考えると、Lambdaは利用頻度が少ないWebフロントシステムにも適していることが理解できるでしょう。

画像
EC2とLambdaの違い。サーバーレスのLambdaは、従来のように仮想サーバーを立て、継続的にインスタンスを動かす思想とは全く異なるアーキテクチャーだ。プログラム実行時間×回数で課金される

 ここでは詳しいことは割愛しますが、Lambdaは、イベント駆動型プログラミング(スクリプト)によってシステムを動かすことになります。何かスケジュールされたイベントが発生したり、事前に割り当てたURLが(API Gatway経由で)アクセスされた場合、あるいは前出のようなAWSの各種サービスがトリガーになって、「Lambda関数」と呼ばれるスクリプトが起動する仕組みになっています。以下の図はモバイルプッシュ配信システムの例ですが、Lambdaを使った場合、EC2の場合と比較すると約5分の1のコストで開発できます。

画像
Lambdaを使ったモバイルプッシュ配信システムの例
(出典:cloudpack提供資料)


画像
モバイルプッシュ配信システムのケース(コスト比較)
(出典:cloudpack提供資料)


サーバーレスの本質は「ITインフラの変動費化」にある

 ここまで説明すると、ある程度は想像がつくと思いますが、最近サーバーレスが注目されるようになった理由は、なによりITコスト面でメリットがあるからに他なりません。別の表現をすれば、インフラの「固定費」をどれだけ「変動費」にできるかということです。これがサーバーレスにしたい本質的な理由になります。

 オンプレミスの場合は、ITコストは固定費として認識されていました。また、クラウドサービスに移行したとしてもEC2のような仮想サーバーを構築している場合は、社内にインフラがあるかないかの違いだけで、利用した時間分だけの固定費がかかっているのと同様だったのです。

 一方、サーバーレスのLambdaでは、ITコストを完全に変動費に置き換えられます。変動費になったほうが用途の幅が広がり、スモールスタートもしやすくなるわけです。

 サーバーレスが注目されたもう1つの理由は、共通化された運用の手間を吸収してくれるということです。EC2ではログの管理やセキュリティパッチを当てるなど、ある程度のお守りが求められますが、LambdaではAWS側で面倒なことをやらずに済むように担保してくれるため、上位アプリケーションの開発に専念できるわけです。

 これはAWSにおける「責任共有モデル」という考え方に関わる話になりますが、詳細は別の回で説明させていただく予定です。いずれにしても、共通化された運用をやってもらえるということは、人件費の削減にかかわる問題であり、セキュリティのリスク回避にもつながります。自分たちで何でもやるよりも、大規模でスケールメリットがあるAWSに委ねたほうが、ITインフラの品質を向上させることができるのです。

サーバーレスで企業のITインフラはどう変わるか?

 サーバーレス化が普及することによって、ITインフラの固定費が変動費に変わり、ITコストも抑えられるようになるでしょう。さらに、共通化された運用をAWS側でやってもらえれば、小規模企業でも高品質なプロダクトをつくれるようになっていくわけです。

 そうなれば当然ながら、新たなチャレンジの機会も増えてくるはずです。もし新たなシステムやサービスが上手くいかなければ新しいものに変更すればよいため、そのサイクルも短くなります。結果的に、世の中に良いシステムやサービスが残り、企業に導入されていくことになるでしょう。

 いずれ将来的には、企業の基幹系や情報系でもサーバーレスの仕組みが導入されることになると予想されます。例えば、まずは基幹システムをマイグレーションによって移行し、その周辺の運用システム(ジョブサーバーなど)をつくり替える際に、運用系をLambdaで置き換えていく可能性は十分にあり得ることです。

 この潮流が大きくブレイクするのは、おそらく大企業の基幹システムが全面的にAWSに刷新し、いくつかの成功事例が出てきたときでしょう。そうなれば、他社の基幹系でも新たに「サーバーレス・マイグレーション」が採用されるようなトレンドになるかもしれません。

 次回は、AWSマイグレーション検討のポイントについてご紹介したいと思います。

〔参考資料〕
cloudpackサーバーレス開発ホワイトペーパー:
https://cloudpack.jp/whitepaper/serverless.html

関連記事

この記事のご感想をお聞かせください。~サーバーレスアーキテクチャとは何か? AWSの「EC2」と「Lambda」を比較して解説(t)

ご投稿いただいた内容は、個人情報を含まない形で今後の編集の参考や弊社メディアでご紹介させていただくことがございます。 あらかじめご了承ください。(正しくご投稿いただいた場合、このアンケートフォームは今後表示されません)

1. この記事はあなたの業務に役立ちましたか?

2. あなたはこの記事をどこで知りましたか?

3. この記事のご感想やご意見など、ご自由にお書きください


データセンター・ホスティングサービス... ジャンルのトピックス

データセンター・ホスティングサービス... ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!