データセンター完全ガイド：特集
2017年、データセンター／クラウド基盤はこう選ぶ！
「デジタルビジネスを駆動するITインフラ」の観点で自社ベストの選択を
2017年5月31日 11:00
[Part 3] Technology Focus
AWS Lambdaに見る、サーバーレスアーキテクチャの本質的な価値
クラウド環境での新しいソフトウェアの実装方法として「サーバーレスアーキテクチャ」が注目を集め始めている。クラウドの普及でさまざまなIT リソースが仮想化／抽象化され、サービスとして利用可能になったが、サーバーレスアーキテクチャの台頭は、プログラム実行環境もそうした流れに沿って進化していることを示している。本パートでは、Amazon Web Services（AWS）の「AWS Lambda（ラムダ）」に備わる特徴を確認しながら、このアーキテクチャの本質的な価値を探ってみたい。 text：渡邉利和
アウトソーシング指向の発展
データセンターが果たす役割は時代と共に変化してきたが、メインフレーム時代から一貫して提供されている役割の1つに、「アプリケーションロジックを実行する場となること」が挙げられる。ITインフラを運用するのは、突き詰めれば「何らかのアプリケーションロジックを実行するため」であり、その具体的なプラットフォームとなるハードウェアを設置し運用するための設備がデータセンターである。
とはいえ、初期のメインフレームはきわめて高価だったこともあり、アプリケーションの実行の前に、「コンピュータ（ハードウェア資産）の保護／保全」が最重視された。データセンターの要件として堅牢性や物理／情報セキュリティレベルの高さが挙がるのは、高価な物理資源であるコンピュータを保護するために必要だからだ。
企業のIT部門がサーバーの運用管理に取り組む場合も、アプリケーション層よりもずっと多くの労力を下層のITインフラの維持のために費やしているのが実情だろう。ハードウェア自体の障害対策はもちろん、OSやミドルウェア、ネットワークといったアプリケーション実行のためのソフトウェアスタックが正常稼働し続けるようにすることが重要で、非常に負担の重い作業である。
商用データセンターやクラウドサービスの普及は、基本的には“アウトソーシング”の考え方で発展してきたと言える。ITシステムから汎用的な部分を抽出し、事業者側は規模の効果で高性能なサービスを低コストで提供し、ユーザー側は、自社で手がけなくてもよい汎用的な部分を利用するという関係が成り立ったからだ。
サーバーレスアーキテクチャの実体
前置きが長くなったが、サーバーレスアーキテクチャにおける“サーバーレス”の意味は、「ユーザー側で運用管理すべきITリソースの中から“サーバーが除外された”」ということになる。
ユーザーが本当に注力したいのは昔も今もアプリケーションロジックの実行なのだが、その“下準備”に手間がかかるのがIT運用管理の問題点の1つだ。そのうちハードウェアの調達に関しては、今ではほぼIAサーバーに統一されるかたちでコモディティ化が進み、仮想化によってハードウェアごとの差異が隠蔽されて“抽象化された処理能力”として扱えるようになったため、クラウドサービスのユーザーにとっては運用管理の対象からすでに外れている。
しかし、仮想サーバーの場合、ハードウェアは抽象化されるものの、ソフトウェアスタックに関しては従来どおりであり、OSやミドルウェアを組み合わせてアプリケーションの実行環境を構築し、セキュリティアップデートなどを適宜行いながら維持に努める作業は物理サーバーと特に違いはない。それどころか、実は仮想化によってソフトウェアスタックの段数は増えており、運用管理の負担としては物理の時代よりむしろ増大しているケースが見られる。
サーバーレスアーキテクチャでは、サーバーハードウェアとアプリケーションロジックの間に介在しているソフトウェアスタックの部分をサービス化して取り除いてしまう仕組みだととらえることができる。構成的にはPaaS（Platform as a Service）に近いのだが、PaaSが従来型のソフトウェアスタックを事業者側があらかじめ用意したものであるのに対し、サーバーレスアーキテクチャは、ソフトウェアスタックの抽象化を、ユーザーがその存在を意識しなくて済むレベルまで推し進めたものという違いがある。
いわば、クラウドサービスでの運用を前提とした、スクリプト型言語のランタイム環境と考えることもできる。サーバーレスアーキテクチャが利用可能なクラウドサービスとして提供されるようになったことで、ユーザーはITシステムの抽象化のレベルをさらに一段階推し進め、「アプリケーションロジックのことだけ考える」ことが可能になったわけだ。
AWS Lambdaの特徴
AWS Lambdaは、市場ではサーバーレスアーキテクチャの代表格のように見られている。だが、AWS自身は同サービスをサーバーレスアーキテクチャであるとは言っていない。「インフラを一切気にすることなくアプリケーションコードを実行できるコンピュートサービス」というのが同社の提供意図になる（図1）。
また、同社は、AWS環境で提供されるフルマネージドサービス全体をサーバーレスアーキテクチャだとも表現しており、Lambdaは同社のフルマネージドサービスを構成するコンポーネントの1つという位置づけになる。
Lambdaの実体は、ユーザーのアプリケーションロジックの実行を支援するコード実行環境だ。対応するプログラミング言語は現時点でNode.js、Java、Python、C#の4種類で、各言語に対応したネーティブライブラリやカスタムライブラリの利用もサポートしている。
処理時間ベースの料金で利用
ユーザー側で選択可能なリソースはメモリ容量で、それを増やせば基本的に処理性能が向上することになる。利用料金はコードの実行時間（実時間ベース）を基準に算出される。コードが実行されていないとき（待機中など）には料金が発生しない点が、従来の仮想サーバーの料金体系との決定的な違いだ。
逆に言えば、常時コードが実行中といった忙しい処理にLambdaを使ってしまうとコストが跳ね上がる可能性がある。そのため、コスト面で有利になるのは、「普段は実行されることはないが、時々発生する」類の処理で、この処理のために仮想サーバーを用意しても、稼働時間の大半は待機しているだけといった状態になる。
負荷の軽い処理であれば、他の仮想サーバーに相乗りで実行させる手もある。だが、めったに実行されないものの、いざ実行されるときに相応の処理能力を要するような処理では悩ましいことになる。この手の処理をLambdaで記述して動かせば、実際に処理が行われた時間のみ課金されるので、コスト効率が向上する。
イベント駆動型で動作
「コードが実行されたときだけ」からもうかがえるとおり、Lambdaのコード実行はイベント駆動型（Event-Driven）プログラミングを基本としている。AWS環境のさまざまなサービスや、ユーザーのシステムやアプリケーションが発生させたイベントをきっかけにコードが呼び出され実行される仕組みだ（図2）。
Lambdaが受け取ることができるイベントの発生元を「イベントソース」と呼ぶ。そのリストにはAmazon S3、DynamoDB、Kinesis、Cognito、Auroraといったデータストア、Cloud Formation、CloudTrail、Cloud Watch、Configといったリポジトリ、Alexa、API Gateway、「AWS IoT」などのエンドポイント、SES、SNS、Cron eventsの各イベント／メッセージ・サービスが並ぶ。AWS上で利用可能なサービスはおおむねLambdaのイベントソースにすることができると考えてよい。
単純な例を挙げると、Amazon S3をイベントソースに登録しておき、S3のファイルストレージ領域に画像データが書き込まれたら、Lambdaがサムネール作成用コードを実行しその画像のサムネールを生成するといった使い方が考えられる（図3）。イベントソースにAmazon API GatewayやCron eventsが含まれていることから、任意のWebアプリケーションのAPIを介してコードを起動することや、一定時間ごとに自動起動するコードを準備することも可能だ。
サーバーレスアーキテクチャとしてのLambdaの強み
サーバーレスアーキテクチャのメリットとして、サーバーの運用管理の負担が完全になくなる点がまず挙げられる。Lambdaの場合、単にモニタリングを行うレベルにとどまるものではなく、いわばスケーリングや耐障害性確保といった高度なレベルまですべてAWS側で面倒を見てくれるということである。したがって、ユーザー側では処理能力が不足した場合にはどうするかといった対処をあらかじめ用意する必要はない。処理能力は必要に応じてLambda側で自動的に追加されると想定し任せておけばよいわけだ。
耐障害性に関しても同様で、サーバーがハードウェア障害を起こした際にどう復旧するかといった心配は不要で、登録したコードの実行継続はAWS側で保証してくれることになる。
Lambdaには、こうした当然に期待されるメリットだけでなく、AWSならではの強みも存在する。まず、上述のとおりAWS上のさまざまなサービスをイベントソースとすることができる点はAWSユーザーにとって非常に魅力的だ。すでに利用中のサービスをLambdaで有機的に統合し、高度なイベント処理や自動化を実現できる仕組みが整っており、同社が以前からアピールする、組み合わせによる価値の相乗効果が得やすいわけである。
もちろん、AWSユーザーがいったんこのメリットを享受すると、他の環境に移行することがより困難になるだろう。現時点ではAWSのほか、この分野への参入を表明しているクラウドベンダーはいくつかあるが、後発の場合、ユーザーにとってより魅力的な環境を提供できないと、今後も進化を遂げるであろうLambdaへの対抗は難しそうだ。
マイクロサービスのトレンドに合致
また、Lambda自体の機能というわけではないが、現在のソフトウェア開発のトレンドであるマイクロサービス（Microservices）との親和性が高いのも強みと言えそうだ。マイクロサービスは、ソフトウェアを特定の機能（サービス）を実現する小さな（マイクロ）コンポーネントとして実装し、その組み合わせによって必要な処理を実現するというものだ。古くはライブラリに始まり、XML Web Services やSOA（Service Oriented Architecture）など、さまざまな手法で実装が試みられてきたコンセプトでもある。
Lambdaの場合、イベント駆動型で対応した処理をシンプルに記述するかたちをとるため、自然と小規模な目的特化型のコードになりやすい。さらに、環境にAmazon API Gatewayが含まれることから、他のモジュールとの連携も実現が容易だ。
市場や顧客ニーズの変化への迅速な対応が企業の必須課題となった今、アプリケーションロジックの開発は、現在ではビジネスの成長を直接左右する可能性も持つ重要な取り組みとなっている。かつての大規模なITプロジェクトのように、要件定義だけで数カ月を掛けるような開発サイクルではなく、今日判明したニーズに即してただちに対応するといった身軽さが求められるようになってきている。すぐに開発して即実環境で試し、問題があれば即座に修正といったスタイルである。
マイクロサービスに関しては、過去にさまざまな実装があって、いずれもあまり大きな成果を挙げられなかった事実もあるが、こうした背景から今後確実に定着していくだろうと目されている。Lambdaをはじめとしたサーバーレスアーキテクチャのサービスもこのトレンドと歩調を合わせてITシステムの中核に近い位置を占める可能性があるだろう。
事業者に今求められるソフトウェア技術力
サーバーレスアーキテクチャの台頭は、データセンター／クラウドサービス事業者に対しユーザー企業の求める要件がさらに高度化していることを象徴する動きだともとらえられる。
かつてのデータセンターは不動産業にたとえられるほど、スペース提供者の側面が強いものだった。冒頭でも述べた、施設としての高い堅牢性やセキュリティレベルを確保するための各種の施策はいずれも「提供するスペースの価値を高める取り組み」である。
しかし、Lambdaの提供におけるAWSの取り組みを見て分かるように、ユーザー企業がデータセンターやクラウド事業者に求めるサービスは、物理的なファシリティではなく、ITシステムの運用管理のサポートというより抽象レベルの高いレイヤに移りつつある。
“X”aaS、といった言葉を頻繁に聞くようになったことからも分かるとおり、現在のITインフラは何もかもをサービス化する方向に突き進んでいる。すでに競争の場はハードウェア層ではなくなっており、事業者もサーバーの安定的な運用ノウハウやユーザーのアプリケーションロジック開発を支援するだけの開発力といったソフトウェア技術のノウハウで競う状況になってきている。
もちろん、データセンターの根本要素として信頼性と品質が高いファシリティが求められることは今後も変わらないが、それだけではユーザーを集めることはできなくなり、いわばコモディティ化していく状況が見えてきている。データセンター事業者も、あらたなソフトウェアのトレンドに注意を払い、ソフトウェア、サービスの技術力を高めていく取り組みにより投資していく必要があるだろう。