多分わかりやすいサーバーレスアーキテクチャ入門その1 〜 Azure Functionsでハロワ！！〜

こんにちは、サイオステクノロジー技術部武井です。今回は、巷で何かと話題で、なんとなくバズワード化しているようにも感じる「サーバーレスアーキテクチャ」をわかりやすく紐解いていきたいと思います。全3回シリーズで、理論から実践まで幅広く取り扱いたい思います。まず第1回目は、AzureのサーバーレスアーキテクチャであるAzure Functionsでお決まりのハロワ(Hello Wordを表示する)をやってみます。

※全シリーズの記事一覧はこちら

今回はこちら → 多分わかりやすいサーバーレスアーキテクチャ入門その1 〜 Azure Functionsでハロワ！！〜
多分わかりやすいサーバーレスアーキテクチャ入門その2 〜サーバーレスアーキテクチャのメリデリ！！〜
多分わかりやすいサーバーレスアーキテクチャ入門その3 〜「Azure Functions」を使って、クラウドネイティブなLINE風チャットアプリを作ろう！！〜

1 サーバーレスアーキテクチャとは？
2 IaaSとPaaSとサーバーレスアーキテクチャの違い
3 とりあえずハロワ
4 最後に

サーバーレスアーキテクチャとは？

Microsoft Azure(以降、Azure)や、Amazon Web Services(以降、AWS)等のパブリッククラウドでアプリケーションを開発する際は、概ね以下のような手順を踏んでいたかと思います。

仮想マシンを作成し、実行言語やミドルウェアインストール
フレームワーク等をベースにアプリケーションを開発
アプリケーションをビルドし、仮想マシンにデプロイ

そして、仮想マシンは、起動している時間に比例して課金され、必要に応じてセキュリティパッチの適用、負荷が高くなれば仮想マシンの台数を増やしてスケールアウトをすることで性能増強をしてきました。オンプレミス上に構築するサーバーと比べて、物理面でのケア(ストレージの故障や熱対策など)から開放されたとはいえ、まだまだ手間のかかるものです。

サーバーレスアーキテクチャは、端的に言えば、仮想マシンを運用する時に発生した手間を軽減し、アプリケーションの開発・運用を楽にしてくれる、そんなサービスです。アプリケーションエンジニアは、仮想マシンの運用にかかる様々な手間から開放され、開発に集中出来るのです。

サーバーレスアーキテクチャはアプリケーション開発における大きなパラダイムシフトであることは間違いなく、その設計・実装を行うためには、発想の転換が必要になると感じております。

Azureにおけるサーバーレスアーキテクチャの代表格は「Azure Functions」です。Azure Functionsは以下の機能を持ちます。

プログラムの実行時間単位に課金される。(仮想マシンと違い、プログラムを動かしていない時間は課金されない)
Azure Blob Storage(AWSでいうところのS3)にファイルが作成された、Azure Queue Storage(AWSでいうところのSQS)にキューがプッシュされたなどの様々なイベントをトリガーにして起動する。
負荷に応じて、ほぼ無限にスケールアウトする。
セキュリティアップデートなどのメンテナンスが不要である。

と、なんだか嬉しいことづく目の感じがしますが、残念ながら、サーバーレスアーキテクチャは、ありとあらゆるケースにも対応できるような銀の弾丸ではありません。

言葉だけだと、なんだかわかりにくいので、以降は、サーバーレスアーキテクチャの対局をなす仮想マシン(以降はIaaS(Infrastracture as a Service)と呼びます)、IaaSとサーバーレスアーキテクチャの中間に位置するPaaS(Platform as a Service)との違いを説明する中で、サーバーレスアーキテクチャとは何者なのかというのを、私なりにわかりやすくご説明していきたいと思います。

そして、その後には、Azure Functionsを始めとする、Azureが提供する様々なサーバーレスアーキテクチャでLINE風なチャットアプリを作ってみることで、さらにサーバーレスアーキテクチャの本質に迫っていこうともくろんでおりますので、最後までお付き合い頂けますと幸いです。

IaaSとPaaSとサーバーレスアーキテクチャの違い

本章では、IaaS、PaaS、サーバーレスアーキテクチャの違いをご説明します。

IaaS(Infrastracture as a Service)

ご存知の通り、一般的に「仮想マシン」と言われるもので、パブリッククラウドサービスよりOSが既にインストール済みのサーバーが提供される形態となり、OSより上のレイヤーの構築・運用は、システム管理者に任されております。

IaaSにおけるシステム管理者の責任範囲を図にしました。下図はアプリケーション稼働環境の構成を階層化したものです。まずOS(LinuxやWindowsなど)があり、その上でランタイム(JavaやPHPなどの実行言語)が稼働し、そのランタイムによってミドルウェア(ApacheやTomcat)が動作し、そのミドルウェア上で、アプリケーションフレームワーク上で開発したアプリケーションが稼働するという構図になっております。

上図で、色のついている部分がシステム管理者の責任範囲になり、図からもわかりますように、OSからアプリケーションまでのすべてのレイヤーをシステム管理者は面倒を見なければなりません。よって、IaaSにおいて、アプリケーションの稼働までに至る道筋は以下の通りとなります。

仮想マシンを作成する。
JavaやPHPなどのランタイムをインストールする。
ApacheやTomcatなどのミドルウェアをインストールする。
SpringやCakePHPなどのフレームワーク上でアプリケーションを開発する。
アプリケーションをビルドする。
ビルドしたアプリケーションをミドルウェア上にデプロイする。

長い道のりですね^^;しかしながら、従来のアプリケーション開発においては、何の疑いもなく、上記のステップを踏んでいたのではないでしょうか？

そして運用管理面においても、OSのセキュリティアップデートや、ミドルウェア、アプリケーションフレームワークへの脆弱性対応なども、システム管理者の責任において、実行することとなります。

PaaS(Platform as a Service)

PaaSを提供するパブリッククラウドの代表的なサービスは、AzureのAzure App Service、AWSのElastic Beanstalk、SalesforceのHerokuなどがあります。

PaaSでは、IaaSにおいて、システム管理者の責任範囲であった「OS」「Runtime」「Middleware」が、パブリッククラウドの責任範囲になります。

PaaSにおけるシステム管理者の責任範囲を図にしました。

グレーの部分がシステム管理者の責任範囲外、それ以外の色がついている部分が責任範囲内になります。このアーキテクチャにおいて、アプリケーションを稼働させるためのプロセスは、パブリッククラウドによって異なる部分はありますが、概ね以下のようになります。

SpringやCakePHPなどのフレームワーク上でアプリケーションを開発する。
アプリケーションをビルドする。
ビルドしたアプリケーションをミドルウェア上にデプロイする。
ZIPなどの形式で圧縮して、パブリッククラウドの管理画面からアップロードする。

IaaSと比べで、OS、ランタイム、ミドルウェアの管理が省かれ、かなり手順が楽になりました(๑•̀ㅂ•́)و✧

もちろん、運用管理面においても、OSのセキュリティアップデートや、ミドルウェアの脆弱性対応などは、パブリッククラウド側で行ってくれます。PaaSを提供するパブリッククラウドの代表的なサービスは、AzureのAzure App Service、AWSのElastic Beanstalk、SalesforceのHerokuなどがあります。

しかしながらそれより上のレイヤーは相変わらず、システム管理者の責任で実施することとなります。例えば、アプリケーションフレームワーク(SpringやCakePHP等)で脆弱性が発覚した場合は、脆弱性が解消されている最新版でアプリケーションを修正・再ビルドし、PaaSにアップロードしなければなりません。

それでも、IaaSに比べれば、アプリケーションを稼働させるまでの手間がかなり軽減されました。

サーバーレスアーキテクチャ

いよいよ本命のサーバーレスアーキテクチャです。先程の例に従いまして、サーバーレスアーキテクチャにおけるシステム管理者の責任範囲を図にしました。

だいぶグレーの部分が多くなってきました。サーバーレスアーキテクチャでは、OSやランタイム、ミドルウェアはもちろんのこと、アプリケーションフレームワークさえも不要で、実行するコードのみを記載すれば、プログラムが実行出来る仕組みになっております。

例えばAzureのサーバーレスアーキテクチャである「Azure Functions」ではAzureの管理画面からコードを書くだけで、簡単にRest APIが作れたりします。

つまりサーバーレスアーキテクチャでは、IaaSよりもPaaSよりも手間なく簡単にアプリケーションを動かすことが出来る実行環境と言えます。

内部的には以下のような仕組みとなっています。

様々なイベント(HTTPリクエスト、ストレージへのファイルの配置、データベースへのレコード登録)などをトリガーとして、コンテナが起動、様々な処理を行い、処理が終了すると、コンテナは破棄されます。一昔前に隆盛を迎えたCGIの仕組みにも似ていますが、コンテナはCGIに比べて非常に高速に起動します。また、処理を終了後、コンテナを破棄するので、プロセス常駐型のアプリケーションと違い、サーバーのリソースを非常に効率的に活用することが出来ます。CGIのようにリソースを有効活用し、プロセス常駐型アプリケーションのように高速なレスポンスであることから、上記の仕組みは「モダンCGI」などと呼ばれたりします。

ちなみに、IaaS、PaaS、サーバーレスアーキテクチャの違いですが、先程の図を並べてみると一目瞭然ですね。システム管理者の管理対象が、IaaS→PaaS→サーバーレスアーキテクチャと進むに連れて、どんどん減っているのがわかります。

とりあえずハロワ

説明が長くなってしまいました。やっぱり理解を深めるためには、手を動かしてみるのが一番で、そんなときのハロワ(Hello World)です。GETメソッドで特定のURLにアクセスすると、以下のJSONを返すRestAPIをAzure Functionsで作成してみます。

{
  "message":"Hello,World!!"
}

Azureポータルにログインして、「リソースの作成」をクリックして、「function」と入力してフィルターすると「Function App」が出てきますので、クリックします。

「作成」をクリックします。

「アプリ名」は任意の名称、「サブスリプション」「リソースグループ」は環境に応じたもの、「Storage」は「新規作成」をチェック、「場所」は自分が住んでいるところに一番近いところ、他は以下のように入力して、「作成」をクリックします。

しばらくすると、Azureポータルの上の通知アイコン(鈴みたいなやつ)に以下のように作成に成功した旨が表示されるので「リソースグループに移動」をクリックします(切れてますが)。

「関数」のとなりにある「+」をクリックします。

今回はRestAPIを作成しますので、「webhook + API」を選択して、言語は「JavaScript」を選択します。言語は何でもいいのですが、私がJavaな人間なので、JavaScriptにしました。最後に「この関数を作成する」をクリックします。

こんな感じでAPIが出来ます。

上記のコードを以下のコードに書き換えて下さい。

module.exports = function (context, req) {
    var json = {
        "message":"Hello,World!!"
    }

    context.res = {
        body: json
    };

    context.done();
};

以下の様になるはずです。「関数のURLの取得」をクリックして下さい。

Azure Functionsで作成したRest APIを実行するためのURLが表示されます。「コピー」をクリックすると、クリップボードにURLをコピーできます。

上記でコピーしたURLを元に以下のcurl文でリクエストを投げてみてください。

# curl https://test-hello-world.azurewebsites.net/api/HttpTriggerJS1?code=XXXXXX
{"message":"Hello,World!!"}

おお(๑•̀ㅂ•́)و✧

ちゃんとハロワが返って来ました。

こんなに簡単にRest APIが作成出来ました。

IaaSの環境では、仮想マシン作って、PHPとかJavaインストールして、ApacheとかTomcatインストールして、プログラム書いてビルドしてデプロイして・・・なんて感じでしたけど、Azure Functionsでは、Azureポータルからコード書いて一発です。なんて便利なんでしょう。

最後に

いかがでしたでしょうか？まずは、ハロワをやってみてましたが、サーバーレスアーキテクチャの便利さはご理解頂けたかと思います。次回は、IaaSやPaaSと比較したサーバーレスアーキテクチャのメリット・デメリットを解説致します。

次回はこちら → 多分わかりやすいサーバーレスアーキテクチャ入門その2 〜サーバーレスアーキテクチャのメリデリ！！〜

ご覧いただきありがとうございます！この投稿はお役に立ちましたか？

役に立った役に立たなかった

3人がこの投稿は役に立ったと言っています。