IBM Cloudで始めるサーバーレス・アーキテクチャ　～IBM Cloud Functions入門

････････

 

 

　クラウド上でのシステム構築がデファクト・スタンダードとなった今日、Amazon Web Servicesの「AWS Lambda」を皮切りに、「サーバーレス」あるいは「FaaS（Function as a Service）」という言葉を耳にする機会が増えている。

 

　サーバーレスとはどのような背景で出てきた概念なのか、どんな場面で適用すべきサービスか、そしてIBM Bluemix Platform（以下、Bluemix）で提供されるサーバーレス・モデルのソリューションである「IBM OpenWhisk」とはどのようなものか。本稿では、このそれぞれについて解説していく。

 

 

　サーバーレスとは、「運用すべき常駐プロセスをもたず、イベントが発生したときにだけ事前に登録した処理を行うアーキテクチャ・モデル」を指す。最近ではFaaSと呼ばれることも多いが、これは過去に「アプリケーションを動かすためのDBなどバックエンドサーバーの構築や管理を、開発者は気にする必要がない」という意味で「サーバーレス」が使われた経緯があり、それとの混同を避けるためである。

 

　ここからは、サーバーレスがこれまでのサーバー・モデルとどう違うのかを説明していこう。

 

　従来のサーバー・モデル（図表1の左図）では、アプリケーションが動かすランタイム（アプリケーション・サーバー）を事前に導入・設定し、その上に行いたい処理をすべて含んだアプリケーションをデプロイする、という形態を取っていた。

 

 

 

　このモデルでは、アプリケーションを動かすランタイムは、外部あるいは内部の処理の呼び出しがいつ来ても対応できるように、つねに稼働し続ける必要がある。そして不測の事態に備えて、稼働し続けるランタイム・プロセスをつねに監視する必要が、アプリケーションの運用時に求められる（クラウドの提供形態により実装方法やユーザーとしての責務は異なる）。

 

　これに対してサーバーレス・モデル（図表1の右図）では基本的に、ランタイム・プロセスがつねに稼働し続けることはない。実施したい処理に合わせて「コード断片（関数レベルの手続き型のコード）」と「イベント（実行のタイミング）」を事前に実行環境に登録しておくのである。

 

　コード断片は、たとえば図表2のようなものを用意する。利用するプログラミング言語、クラウド・プロバイダーのサービス仕様に合わせて実装する必要がある。イベントは、図表3のように「データベース・レコードの作成／変更／削除」や「ある指定時刻を過ぎたら」など、コード断片で定義した処理の契機となるトリガーを指定する。

 

 

 

 

　コード断片とイベントの両方を定義しておくと、定義されたイベントが発生すればコード断片を動かすのに必要なランタイムが起動され、処理が実行される。そして、実行後は不要なリソースであるとして削除／停止される。こうした一連の流れを繰り返すことによって、つねに稼働し続けるプロセスをもたずにシステムを実装できることになる。このモデルがサーバーレス・モデルである。

 

　サーバーレスの考え方自体は最近出てきたものではない。Wikipediaによると、2006～2007年に提供されていた「Zimki」と呼ばれるホスティング型のWebアプリケーション開発環境がサーバーレス発想の起源とされる（＊1）。

 

････････

（＊1） http://bit.ly/is16_ow001　

････････

 

 

　WebブラウザのみでWebアプリケーション開発が行える、サーバーサイドも含めてJavaScriptでプログラミングできるなど、手軽に開発に取り組めるサービスとして提供されていたが、当時はAWS（Amazon Web Services）やGoogle App Engineなどのクラウドサービスが登場したばかりのころで、その重要性が認識されず、1年でサービス終了となってしまった。そして、クラウドの普及が進んだ2014年にAWS Lambdaがリリースされ、それを皮切りにサーバーレスが着目を浴びるようになった。

 

　サーバーレスは将来的なアーキテクチャ・モデルであり採用はまだ先、と思われる方も多いかもしれない。しかしながら日本経済新聞社（＊2）や毎日放送（＊3）など本番環境においてサーバーレスを活用する事例がWebで公開され始めている。サーバーレスは今まさに採用を検討すべきアーキテクチャ・モデルなのである。

 

････････

（＊2） AWS導入事例：株式会社 日本経済新聞社
（＊3） 『MBS動画イズム444』サーバーレス・アーキテクチャを全面採用　http://bit.ly/is16_ow002

････････

 

 

　サーバーレスを活用するには、そのメリットと考慮点をきちんと理解しておくことが重要である。メリットとしては、次の3点が挙げられる:

 

　パブリック・クラウドでは処理に要した実際の時間が課金対象となるため、従来のIaaS／PaaS型の課金モデルと比べると無駄なランニング・コストを抑えられ、コストの適正化が図れる。

 

　サーバーレスは、要求／イベントごとに処理用の計算リソースを獲得し、利用者が意識することなく自動でスケーリングして処理を行うモデルである。サーバー・インスタンス台数の見積もりやスケーリングの設計といった煩わしい作業が基本的に不要になる。

 

　サーバーレスの処理は手続き型プログラミングで済むため、何をどう処理したいかを整理して順に実装すればよい。クラスやスレッド・プールの設計など、従来のアプリケーション開発で行うオブジェクト指向プログラミングが必須とならないので、シンプルに処理を記述できる。

 

　一方、デメリットに関しては、主に以下の3点が挙げられる:

 

　サーバーレスでは、常駐プロセスではなくイベントごとに計算リソースを確保するので、計算リソース作成の時間などが上乗せされる。その結果、実行までの時間にムラが生じやすい。また、従来のサーバー・モデルではKeepAlive接続やキャッシュなど、処理をより高速化・最適化させるための仕組みが使えないので、即時に応答を返す必要がある、迅速性が求められる処理にはサーバーレスは向かない。

 

　サーバーレスでは、イベントごとに計算リソースを確保し、実行後は計算リソースを削除／停止する動作を繰り返す。このため、クラウド・プロバイダーが１処理に対するタイムアウトを実装上設けている場合は長時間処理し続けることのできないサービスもある。したがってストリーミング処理や機械学習など、時間がどうしてもかかるような処理にはサーバーレスは向かない。

 

　サーバーレスにおいて、計算リソースの確保はイベントごとであり、処理すべきデータ量など、処理の重みは基盤として判断されない。そのため、計算リソースに対して割り当てられるメモリ量が処理すべきデータ量に対して不足し“Out of Memory”が発生する、あるいは処理時間が大きくかかってしまい、クラウド・プロバイダーが定めるタイムアウトを迎えて処理が中断する、といった事象が発生する恐れがある。インプットとなるデータ量が定まらない処理にはサーバーレスは向かない。

 

 

　ここまでは、サーバーレスという用語／概念についての一般的な説明であった。ここからはサーバーレス・アーキテクチャを実現するIBM OpenWhiskについて説明する。

 

　IBM OpenWhiskは、IBM Bluemix上でFaaSとして提供されるイベント駆動型（サーバーレス）プログラムの実行環境である。特徴としては、Node.js（v6）、Python（v2.7）、Swift（v3）、Java（v8）の４種類のプログラム言語およびDockerに対応しており、以下のBluemix内外のサービスとの連携をデフォルトでサポートしている点が挙げられる（2017年4月現在）。

 

・ Cloudant NoSQL Database

・ IBM MessageHub （Kafka）

・ Push Notification

・ Weather Company Data for IBM Bluemix

・ Watson Translator

・ Watson Speech to Text/Text to Speech

・ GitHub

・ Slack

 

　ほかのFaaSプロバイダーとの違いは、Dockerへの対応により、上記４種類のプログラム言語以外の言語も利用できることと、オープンソースなのでオンプレミス環境でも環境を構築可能なことである。

 

　IBM OpenWhiskで開発する際に必要な基本用語をまとめたものが、図表4である。

 

 

 

　開発の手順としては、最初にBluemixにログインしOpenWhiskのトップ画面にアクセスする（図表5）。ここで「ブラウザ開発」と「OpenWhisk CLIを利用した開発」の2つが選択できる。

 

 

　「ブラウザ開発」とはその名のとおり、ブラウザを利用してGUIで開発を行う方法で、比較的簡単にコードを作成し実行できる。もう1つの「OpenWhisk CLIを利用した開発」はブラウザ開発で可能なすべてに加えて、よりきめ細かな作り込みが可能だ。2つの違いをまとめたものが図表6である。

 

 

　どちらの方法がよいかは一概に言えないが、動作の確認にはブラウザで開発し、コードの開発にはより細かな設定が可能なCLI、という使い分けをお勧めする。

 

　実際の開発の流れを示したのが図表7である。

 

 

　ブラウザ開発の場合、トップページから「開発」というリンクを押すことにより表示されるエディタ画面でアクションを作成でき、さらにシーケンスの設定、自動化の設定、トリガー／ルール設定までを実施できる。

 

＊

 

　本稿ではサーバーレスというアーキテクチャの概要と、その実装であるIBM Open Whiskの概要について説明した。細かな制約や実際の開発例などには触れていないが、画面からうかがえるように直感的な操作と簡単なスクリプトの記述で実装が可能である。ぜひ読者のみなさんにも、自身で体験していただきたい。なお、開発例などはBluemixのドキュメント（＊4）をはじめとして、Webで多数公開されている。そちらも、ぜひ参照されたい。

 

････････

（＊4） Bluemix – Documents　https://console.ng.bluemix.net/docs/

････････

 

 

････････

 

 

 

････････