サーバーレスな事例が次々登場―ServerlessConf Tokyo 2016レポート

「サーバーレス」の明確な定義は決まっていないが、おおよそは、アプリケーションを動かすプラットフォームをアプリケーション開発運用側が持たず、サービス側に任せる方式を指す。特に、AWS Lambdaのように、コードだけを用意しておき、APIリクエストやデータ追加などをトリガーとしてサーバー環境に割り当てて実行する、FaaS（Function as a Service）とも呼ばれる“泥縄”的なアーキテクチャについて言われることが多い。

「ServerlessConf」は2016年にニューヨークで始まり、その後ロンドンでも開かれた。日本での開催はそれに続くものとなる。主催したSection-9の吉田真吾氏は、カンファレンスの開会にあたって「ニューヨークでは『われわれの1～2年前と同じだね』と言われて悔しかったが、ServerlessConfをこんなに早く日本に持ってこれてうれしい」と語った。各発表でも、技術概要だけでなく、実際に導入した経験やそこで得られた知見などが語られた。

AWS、IBM、Azureによるサーバーレス解説

基調講演は、サーバーレスの代名詞ともいえるLambdaを提供しているAWS（Amazon Web Services）が登壇した。また、一般セッションでも、AWS Lambdaと同様のFaaSサービスをクラウドで提供しているIBMやMicrosoftの発表もなされた。3社のセッションで共通していたメッセージとして、グローバルに広がったクラウド基盤の上で動くことによる、スケーラビリティや信頼性が語られた。

AWSのOlivier Klein氏による基調講演では、モノリシックなアプリケーションからマイクロサービスに移行することによる拡張性や柔軟性について語り、その延長に「サーバーレスのマイクロサービス」を位置付けて、AWS CTOのWerner Vogels氏による「No server is easier to manage than no server」（サーバーがないのより管理が簡単なサーバーはない）という言葉を引用した。

AWS LambdaについてKlein氏は、フルマネージドなクラウド上で、API呼び出しや状態の変化をトリガーとして動き、自動的にスケールするものだと説明した。特に、オブジェクトストレージやデータベース、APIゲートウェイなど、多種多様なAWSのサービスをAWS Lambdaから利用できることや、それらのサービスをつなぐ役割となることが特徴だ。

AWS Lambdaのデモもなされた。まずFacebookページへの投稿があったときにSlackに流し、データベースにも格納するデモ。これにはAWSのLambdaとAPI Gateway、DynamoDBが使われ、FacebookのWebhookからLambdaを呼び出して実現した。

続いて、前の例のデータベースをWebブラウザーから利用する例。静的コンテンツをS3に置いてCloudFront経由でアクセスした。さらにChaliceフレームワークを利用し、ページ中からAPI Gateway経由でLambdaを呼び出して、メッセージを表示。さらに投稿も実現した。

最後は、音声アシストデバイスのAmazon Echoとつないだ例。開発キットのAlexa Skills KitによりAWS Lambdaとつなぎ、自然言語音声のコマンドにより、データベースに格納された投稿件数を自然言語音声で答えさせてみせた。

IBMのAndreas Nauerz氏とMarkus Thömmes氏は、クラウドサービスBluemix上で動くFaaSサービス「OpenWhisk」を紹介した。

まず、サーバーレス（FaaS）一般の特徴として、従来のモデルでは変更をポーリングし続けるのに対し、サーバーレスではイベントモデルで動いて、使ったぶんだけ料金を支払い、拡張前提になっていることを挙げた。そして、FaaSの中でのOpenWhiskの特徴として、複数言語対応や、オープンなエコシステム、オープンソース技術の採用などを挙げた。なお、オープンソース技術としては、NginxやConsul、Kafka、Dockerなどが使われているという。

デモでは、まず公式コマンドラインクライアントのwskの操作に始まり、「Hello world」と返すサービスを作る例や、アクションをチェーンして新しいアクションを作る例、GitHubの変更をSlackに通知する例などが紹介された。

Microsoftの牛尾剛氏とさとうなおき氏は、Microsoft Azure上のFaaSサービス「Azure Functions」を紹介した。冒頭で会場の参加者に使っているクラウドサービスを聞き、8割ほどがAWSユーザーだったということで、「AzureというのはEC2っぽいやつ。その上のAzure FunctionsはLambdaっぽいやつ。API managementはAPI gatewayっぽいやつ。BLOGストレージはS3っぽいやつ（笑）」と、ぶっちゃけた例で説明した。

デモではまず、カメラで撮ったユーザーの顔写真からその人の感情を分析して、それに応じて画面上の美少女キャラが反応を返すというゲームを試してみせた。写真のアップロードをトリガーにAzure Functionsが動き、そこからAzureのFace APIで感情を判断するという。

また、Twitterを検索した結果を感情分析（ポジティブ／ネガティブ）してSlack投稿する例もデモ。これにはWebのGUIでワークフローを定義するAzure Logic Appsが使われた。

そのほか、通信ログからSIMの不正利用を検出する例などもデモされた。

日経電子版が本番環境でサーバーレスを活用

新しい技術というと実運用で使われるまでに時間がかかると思われがちだが、カンファレンスではサーバーレスについて日本での事例もいくつか紹介された。

カンファレンスで紹介された中でも最も本格的な事例が、日経新聞の猪飼大志氏が紹介した、日経電子版アプリ「紙面ビューアー」での採用例だろう。

紙面ビューアーは新聞紙面と同じレイアウトで記事を読めるアプリだ。内部では、データとして大きな紙面画像が与えられるのを元に、分割やリサイズ、記事の矩形切り取り、シャープ化、フォーマット変換などの作業が発生するという。しかも、変換作業は朝刊と夕刊の発行時が主だが、紙面更新が不定期にある。そのため、通常のバッチ処理だとサーバーを常に起動して定期的にポーリングして処理する必要がある。しかも、記事が多い日のスケールアウトも課題だったという。

それらを考えていたときに、AWS Lambdaが東京リージョンに来たので採用したということだった。変換の1フェーズごとにLambdaを起動し、変換した結果をS3に格納し、それによって次の処理のイベントが発生する仕組みを採用している。S3を経由するのは、確実に処理するためとのことだった。この仕組みで、朝刊前の時間帯には1分間に18,000回の実行がなされており、いまのところLambda由来のエラーは起きていないという。さらに、EC2を動かし続けてポーリング運用するよりかなり安く動いていることも報告された。

そのほか、アプリ内からのユーザーの要望投稿もLambdaを使って処理。さらに社内用途でも、ChatOpsのためのSlackの/コマンドをLabmdaで実装しているという。

Gunosyによるau向けアプリ「ニュースパス」も、同じくニュースアプリでサーバーレスを採用した例だが、使い方は日経電子版とまた異なる。

現在、多くのモバイルアプリでは、ほとんどの処理をサーバー側が受け持ち、端末上のモバイルアプリはビューの役割だけを受け持つようになっている。しかし、現在のスマートフォンはCPUパワーなどリソースを潤沢に持つため、ロジックの一部を端末側でやってもいいのではないか、とGunosyの松本勇気氏は論じた。

そこでニュースパスでは、認証認可やログ、通知管理などの機能を端末側に持たせた。たとえば認証認可は、サーバー側でまとめて処理するのではなく、端末とAWS Cognitoで直接やりとりする。そして、Cognitoを起点にAWS Lambdaを走らせて、サーバーレスで設定値を配信用システムに格納するという。また、ログでは、端末のすべてのアクションをAWS Kinesisで収集し、AWS Lambdaを介してログ用S3に格納しているという。

松本氏は、AWS Cognitoなどで遭遇したハマりどころなども紹介した。そしてまとめとして「サーバーレスは銀の弾丸ではない」と語った。

Game Server Services株式会社（GS2）は、創業したばかりの会社で、ゲームのバックエンドサービスを提供する。現在、ベータテスターを募集中。このシステムをAWS Lambdaを使ってサーバーレスとマイクロサービスで構築したと丹羽一智氏は発表した。

GS2でサーバーレスを採用した理由について、事前のアクセス数予想が難しいゲームサーバーならではの「スケーラビリティ」と「可用性」、障害時のオペレーションを任せられることや複数のアベイラビリテイゾーン（AZ）などによる「保守性」、事前にサーバーインスタンスを用意しておくことが必要ないことによる「価格優位性」が挙げられた。

GPSトラッキングプラットフォーム「Trackrr.io」でも、サーバーレスとマイクロサービスを採用している。サーバーレスにした理由はスモールスタートのためと株式会社スタイルズの高橋裕樹氏は説明。さらに、1,500台のデバイスからのプッシュに対応するというプラットフォームで、実装に専念できるほか、「プロトコルをHTTPSからMQTTに変える」といった変更にも柔軟に対応できたという。なお、管理コンソールについては割り切ってサーバーインスタンスを立てたとのことで、「共通部分はサーバーレスにしないという割り切り」と説明した。

サーバーレスだけで業務アプリを組むか？ 実践者たちが議論

1日の最後には、登壇者から松本氏（グノシー）、猪飼氏（日経）、照井氏を集めてサーバーレスについて語りあうパネルディスカッション「Serverless Geeks Panel」も開かれた。ファシリテーターは伊藤直也氏。

伊藤氏はまず、サーバーレスの定義として、サーバやOSを管理しないというインフラのオペレーションの面と、FaaSのようなアプリケーションのアーキテクチャの面の2種類が混在していることを指摘した。これについて、伊藤氏自身はアーキテクチャの面が本質ではないかという意見だったが、パネリストは三者三樣（「両方大事」も含め）だった。

また、「サーバーレス」という名前が曖昧なのではないかという声については、厳密な言葉をつけても意味がわからないし、むしろこの名前だからこそ注目されてバズワード的に広まったのではないかと、笑いを交じえて語られた。

ネットで出た「現時点で『サーバーレスだけで業務アプリを組む』みたいなことを考える人はアーキテクチャ分かってないなと思う」という、否定的ともとれる意見については、4人とも比較的肯定的だった。論点は主に2つで、「現時点で」という点については、いまのところ起動のオーバーヘッドがあることや、フレームワークやデプロイ方法などのエコシステムが未成熟なことなどが指摘された。また、業務アプリケーションのようにドメインモデルやロジックが重いアプリケーションをサーバーレスで動かすかどうかについては、少なくとも現状では小さな関数を主体としたグルー的な使われ方が中心であるという指摘や、将来的に不可能ではないかもしれないがやるべきではないという意見などが出た。

なお、会場からの質問の枠では、主催の吉田氏から「ニューヨークで日本より1〜2年進んでいると言われたのは、『サーバーレスですべてできるかどうか』といった議論を越えて、すでに使える分野でサーバーレスが使われてビジネスとしての実績を作っているところだった」との意見も出た。

サーバーレスのアーキテクチャではイミュータブルでステートラスな特性によりスケールするのが特徴ということについても議論された。マイクロサービス＋サーバーレスの構造がプログラミングでのアクターモデルに似ていて、だからスケールするという声や、そのままマイクロサービスに分割したら増えすぎて困ったという声、マイクロサービスはドメインモデルで分割しないと失敗するという声などが出た。

そのほか、実行単位の話や、FaaSやPaaSなどの立ち上がり速度、サーバーレスでは料金見積りが難しいという問題、サーバーレスにフレームワークが必要かどうかの論議などが語られた。

最後の締めくくりで、伊藤氏が「思っていた以上にみんな（「すべてサーバーレス！」のようなノリではなく）冷静だなと思った」とまとめていたのが印象的だった。

サーバーレスに関する発表が多数

そのほか、カンファレンスでは1日のあいだにさまざまな発表がなされた。

Cloud AcademyのAlex Casalboni氏は、機械学習のプラットフォームにサーバーレスを使う例を紹介した。背景としては、データサイエンティストのDevOpsとの違いや、MLaaSサービスの制約を説明。ただし、機械学習そのものをLambdaで動かすわけではなく、機械学習の結果をサーバーレスなシステムで利用する例や、データ収集にLambdaを使ってEC2上で機械学習を実行する例が紹介された。

A Cloud GuruのPeter Sbarski氏は、経験を交じえて学んだ「サーバーレスの原則」を説明した。「Use a compute service to execute code on demand (aka don't run a server)」（コードを動かすコンピュートサービスをオンデマンドで使う）、「Write single-purpose stateless functions」（単一目的のステートレスな関数を書く）、「Design push-based, event-driven pipelines」（プッシュベースのイベントドリブン）、「Create thicker, more powerful front ends」（リッチでパワフルなフロントエンド）、「use third party services」（サードパーティのサービスを活用）の5項目が語られた。

Engine YardのAllan Espinosa氏は、コンウェイの法則「Organizations which design systems... are constraint to produce designs which are copies of the communication structure of these organizations」（システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう）をテーマに、各種オープンソースプロジェクトの運営の問題や、サーバーレスなどにおける提供者や利用者などのコミュニケーションについて語り、「コンウェイの法則で重要なポイントは、『組織の柔軟性は設計にとって重要』ということだ」と説明した。

ランチセッションの「Unlimited Frameworks」では、照井将士氏がさまざまなサーバーレスフレームワークを紹介し、それぞれの特性と適した分野などを説明した。

同じくランチセッションの「Firebaseを使ったサーバーレスWebアプリケーション開発」では、佐々木季羽る氏（Section-9）が、GoogleのMBaaSサービス「Firebase」について解説。特に、「Googleが買収したあと、ほかのGoogleの機能と連携させている」のを特徴として語った。

ライトニングトークの「MQTTを利用してGITHUB PAGESでアプリケーションをホストするYetAnoerアプローチ＋α」では、ニフティの森藤大地氏が、WebブラウザをサーバーにしてMQTTでアクセスさせるという意味で「サーバーレス」な「MQTTPRESS」を発表して会場を湧かせた。

同じくライトニングトークの「Time to shift WordPress to Serverless」では、DigitalCubeの堀家隆宏氏が、WordPressを記事を書くときなどだけDockerで起動し、コンテンツは静的なページとしてS3に置く「Shifter」を紹介した。現在βテスト中。

3つめのライトニングトークの「Realmで実現するサーバーレスアプリケーション」では、Realmの岸川克己氏が「Realm Mobile Platform」をデモを交じえて紹介した。Realm Mobile Platformは、モバイル向け組み込みデータベースRealm（現在はRalm Mobile Databaseに改名）のサーバーサイド機能を提供するクラウドサービスで、複数デバイス間のデータ同期や認証、変更通知などに対応するという。