[レポート] 【17-A-3】サーバレスにおける開発プロセス戦略 @ Developers Summit 2017 #devsumi

毎年2月に目黒雅叙園にて開催されているデベロッパーの祭典『Developers Summit』。2017年の今年も02/16(木)〜02/17(金)の2日間に渡って行われ、私個人としても例年通り参加してきました(2012年以降6年連続)。当エントリでは聴講セッションのうちの1つ、『サーバレスにおける開発プロセス戦略』の内容についてレポートしたいと思います。

• Developers Summit 2017 エンジニアとして生きる、技術の先にある現実に踏み出す
• 【17-A-3】 サーバレスにおける開発プロセス戦略 | Developers Summit 2017

目次

• 当セッションの登壇者
• パネルディスカッション内容：本編
• 各者自己紹介＆サーバレスの概要について
• Q.サーバレスを導入したシステム、及び導入で得られたメリットについて
• Q.導入の経緯
• Q.導入時に苦労した点等
• Q.ユニットテストについて
• Q.システムのステージ環境管理
• Q.リリース管理
• Q.フレームワークツール
• Q.サービスレベル目標
• Q.さいごに
• まとめ

　

当セッションの登壇者

当セッションにて登壇されたモデレータ及びパネラー陣の方々は以下となります。デブサミ公式サイトのセッション情報よりプロフィール部分を抜粋、拝借致しました。

• 【17-A-3】 サーバレスにおける開発プロセス戦略 | Developers Summit 2017

モデレーター

吉田 真吾氏 [セクションナイン]

パネラー陣

猪飼 大志氏 [日本経済新聞社]

生井 智司氏 [ミクシィ]

相馬 賢司氏 [ワイヤ・アンド・ワイヤレス]

(セッション開始前に談笑する登壇者陣。左から吉田氏、生井氏、相馬氏、猪飼氏)

　

パネルディスカッション内容：本編

ここからがパネルディスカッションの本編内容となります。(※登壇者氏名については以下敬称略とさせて頂きます)

　

各者自己紹介＆サーバレスの概要について

吉田：

皆さんこんにちは！高いところから失礼致します。

今日はサーバレスにおける開発プロセス戦略というお題で、普段現場でサーバレスなシステムを作っている方々にお話を聞いてみたいと思います。サーバレスなシステムを既に検討、構築、運用しているという方は？(そこそこの数手が挙がる)あ、結構増えていますね。

ではまず、各者自己紹介の後、皆さん経験済みの方もまだこれからだという方もいるかと思いますので、サーバレスについての簡単な概要の説明を行い、その後に適宜テーマについてディスカッションして行きたいと思います。

吉田：

本日のモデレータを努めます吉田と申します。株式会社セクションナインで社長兼平社員をやっております。つまり社員1人の会社ですね。AWS導入からdockerize等の相談や実装等をやっています。

吉田：

サーバレスの簡単なご紹介から。初めて聞く際は『サーバの無い世界』をイメージしちゃいそうですけど、初出の記事は2012年に出た以下の記事だと言われています。

• Why The Future Of Software And Apps Is Serverless - ReadWrite

吉田：

当初の段階から、別にサーバを無くそうという話では無くて、サーバの調達モデルが"所有"から"利用"に変わる、更に調達のリードタイムがどんどん短くなる事によって開発者はサーバの事を意識しなくても良くなる、というような世の中になっていくだろう、と言われています。

そこから5年の月日を経て現在。サーバレスの文脈で言われるのは、functional saas,とfunctional as a service。それぞれ特徴の違うサービス。今日は後者がメイン。今日参加されているパネラーの皆様はAWSのユーザーなのでAWS Lambdaを中心としたアーキテクチャの開発プロセスの話になっています。

今日はAWS Lambdaを中心としたお話に終止してしまうかと思いますが、Function as a Serviceに関して言うと、GoogleとかMSとか、それ以外のサードパーティベンダも似たようなサービスをローンチしています。

• AWS Lambda - Serverless Compute
• Azure Functions—サーバーレス アーキテクチャ | Microsoft Azure
• Cloud Functions - サーバーレスなマイクロサービス  |  Google Cloud Platform
• Iron.io | Serverless Multi-cloud for Enteprise
• Apache OpenWhisk

吉田：

そして、本日はこんな前提とゴールでお話していきたいと思います。

吉田：

今私、FacebookでServerlessCommunity(jp)というものを運営しています。現在250名程のコミュニティになっています。そこで先日、どんなツールを使っているかのアンケートを取ってみました。結果は以下の様な形で、色々なツールの名前が挙がってきた形となりました。(※セッション内容で発表された図を情報として書き起こしたものとなります)

順位	ツール名	用途	人数
1.	Serverless Framework	開発フレームワーク・デプロイ(Node)	35
2.	Apex	複数Lambda関数のデプロイ(Node)	12
3.	Lamvery	複数Lambda関数のデプロイ(Python)	9
4.	Swagger	API定義・設計	8
5.	AWS Serverless Application Model (SAM)	開発フレームワーク・デプロイ (CloudFormation)	7
6.	Postman	RESTのリクエスター・テストツール	7
7.	Microsoft Visual Studio	統合開発環境(IDE)	5
8.	AWS CLI	コマンドラインツール	5
9.	Eclipse	統合開発環境(IDE)	3
10.	Python Serverless Microframework for AWS (Chalice)	開発フレームワーク・デプロイ(Python)	2

吉田：

また、上記のアンケートが好評でしたので続けて第2弾として『Serverlessのどんな話が聞きたいか？』というテーマでアンケートを取ってみました。結果は以下。開発プロセスに関する関心が多かった。これが今回のセッションを行おうというモチベーションに繋がっている部分になります。(※セッション内容で発表された図を情報として書き起こしたものとなります)

順位	テーマ	人数
1.	Serverless開発の手法・ツール・CI/CDパイプライン	32
2.	どう選ぶ？ VM vs コンテナ vs サーバレス2017(事例／パネル)	25
3.	Voice/Bot/Text Analysis/Cognite in Serverless	11
4.	Serverless API(REST/GraphQL)	10
5.	Serverless Single Page Applications	7
6.	Serverless ストリームデータプロセッシング	5
7.	IoT分野でのサーバレスの活用	3
8.	Serverless Machine Learning	3

吉田：

では続きましてパネラーの皆様の自己紹介を。

生井：

『家族アルバム みてね』を開発中、この中で一部Lambdaを使っています。

子供の写真、動画を共有・整理アプリ - 家族アルバム みてね

相馬：

当社は公衆無線LAN事業者。外で目にする事かと思いますがwi2というSSIDでサービスを提供しています。最近では訪日外国人向けにTRAVEL JAPAN Wi-Fiというサービスを提供しています。今日はサーバレスというテーマで、拡張性とスピードを保ちつつどういう風に利用出来るか、という部分で 色々情報が吸収出来ればと思い参加しました。よろしくお願いします。

TRAVEL JAPAN Wi-Fi｜Wi-Fi ソリューション｜Wi-Fi ソリューションを提供するワイヤ・アンド・ワイヤレス

猪飼：

iOSの電子版アプリと紙面ビューワーアプリを作成、後者の方でAWS Lambdaを使っています。去年の10月にSeverlessConfにて紙面ビューワーアプリの話をしたところバズり、その流れというか縁もあってこの場に居ます。

日本経済新聞 紙面ビューアーを App Store で

サーバーレスな事例が次々登場―ServerlessConf Tokyo 2016レポート | Think IT（シンクイット）

各者自己紹介を終えた所で、それぞれのトピックに関してのディスカッション、事例実践例等の紹介がなされて行きました。以降はテーマ毎の内容となります。

---

　

Q.サーバレスを導入したシステム、及び導入で得られたメリットについて

生井：

『家族アルバム みてね』のバックエンドで利用しています。元々少人数で開発を行っており、写真をアップロードする機能を作っているけど作りはかなり素朴。APIサーバでアップロードを受け付けたらその場でサムネを生成、終わったらS3にアップロードして処理が終了したらクライアントに『成功』と返しています。サムネ生成の部分を非同期にしたくて、ImageMagick等の処理を行っているところをLambda側に逃してアップロードの高速化を測りたかったのがありました。

吉田：

実際やってみてどうでしたか？

生井：

速度は安定しています。元々リクエスト完了3秒かかっていたのが0.6秒くらいで済むようになりました。アップロード数が増えてもLambda側をいじらずに、良い感じでスケールアップして動き続けてくれているのでパフォーマンスは維持出来ています。

相馬：

TRAVEL JAPAN Wi-Fiというサービスでapiのバックエンド、あとはログの収集の非同期処理でDynamoDBと接続して使っています。 サーバ構築やスケーリングの部分に関して工数を削減したかった。またアプリ開発に注力したかったのでLambdaを採用しました。運用、クラウド側でスケーリングをやってくれています。色々苦労した点もありますが、それについては後述します。

猪飼：

紙面ビューアでアプリ向けに画像を加工する部分をLambdaで構成しています。システムがS3に画像を書き込んだ処理を受けてLambdaが動いています。メリットとしては、2人の話にもあったようにLambdaがスケーリングしてくれるので、例えば正月等ピーク時にもLambdaが上手く処理してくれるので安心感があります。

吉田：

ちなみに1分で何ジョブくらい処理されてましたか？

猪飼：

(invokeで)18000回くらいですね。

吉田：

エラーは起きたりします？

猪飼：

いや、起きないですね。たまにタイムアウトしたりする事もありますが、3回までリトライ出来るのでそこで救えてますね。

吉田：

素晴らしい！

　

Q.導入の経緯

吉田：

導入しようと思った切っ掛けは何かありますか？また、導入しようと思った際、VMやDocker等と悩んだりしませんでしたか？

生井：

『みてね』の中に組み込んだ際、既にLambdaでサムネ生成という事例は聞いていた。『やっちゃえ』という側面はありましたが、 非同期でやろうとうなった場合、自前で運用環境をつくるのとLambdaを使うを比較した場合、直感的に後者が楽そうだなと思って選びました。

吉田：

元々使いどころが一足飛びしやすかった、ということでしょうか？

生井：

そうですね。失敗したときの処理を考慮する必要はありましたが、Lambdaで出来そうだなという直感はありました。

相馬：

うちの場合も『やっちゃえ！』です。サンプルも充実してましたし、新規に作ったものはLambdaでいこう、と。既存分、EC2で動いていたものについてはDockerでやろうかなと検討しています。後まだ着手はしていませんが、ポータビリティを上げる、メンテナンス性を上げるという点も考慮していこうかなと思っています。

猪飼：

(弊社のケースでは、)検討を行っていたタイミングではLambdaはまだ東京に来ていませんでした。その後Lambdaが東京に来て、サーバのおもりする必要がないと分かり、出来そうだな→やっちゃえとなりました。

吉田：

ちなみにちょっと戻っちゃいますが相馬さん、相馬さんのところの開発文化に「やっちゃえ」文化があったのか、相馬さんがやっちゃえだったのか、どちらになりますか？

相馬：

完全に後者ですね。当社に開発部署がなかったというのもあって、ベンダさんと話してEC2のスペックパラメータ仕様を比較しLambdaと比べたところ、Lambdaの方が良かったので選択しました。

　

Q.導入時に苦労した点等

生井：

Lambda導入時に苦労した点としては、当時(2015年時点)では実際の事例がまだそこまで多くなかったです。本番のデータ量とかコール回数等、スペックが耐えられるのか、という心理的不安もありました。この部分については実例を聞いて安心感を得られた部分もあります。エラーが起きた時のログを確認したときにCloudWatch Logsのログの見方がちょっと難しかったかな、とは思いました(笑)

吉田：

ちなみに今ログ見るのに工夫とかしてます？

生井：

タイムアウトが起きたかな、というパターンについてはある程度把握しているという感じです。その他は特に。

吉田：

ちなみに私、Lambdaのログは本番にデプロイしている物以外についてはCloudWatch Logsの方からSlackに連携してログを流しっぱなしにしています。本番環境については実行回数の問題等もあるので現実的では無いですが、とりあえず実行したらSlackをみとけば分かるようにはしていますね。

相馬：

アプリはJavaで作ったけど、クラスライブラリのロードに時間が掛かるなどありました。VPC内に置いたLambdaがAPI Gatewayのタイムアウト(30秒)に引っ掛かってしまって一部サービスが耐えられないようなエラー率を出したことも。一部は構成を変更して(ソース改修はせずに)EC2に戻したものもあります。

あとはCloudWatchのイベントで定期的に関数をコールしてLambdaを立ち上げているのもありますね。Lambdaならではの開発の都合を良く分かっていなかった部分もあり、構成変更せざるを得ない部分もありました。

吉田：

別に無理せず戻した方が全然良いんなら戻した方が良いですよね。

相馬：

ですよね、精神的にもそのほうが楽です。

猪飼：

Lambdaをリリースしてから日が経っていなかったので、ユースケースもなく手探り感があったのが辛かったですね。ユニットテストは書けるけど、通しで『ピタゴラスイッチ的』な仕組みをテストするのは大変でした。実はEC2を使った方もあって、出来なかったらそっちを使えばいいかな？というのもありました。

　

Q.ユニットテストについて

吉田：

今少しお話にも出ましたけど、ユニットテストについて、これはどんな方法で行っていますか？あと、そもそもローカルで頑張ってるのか、クラウドでやってるのか、そういうところもあればお聞かせください。

猪飼：

基本的にはユニットテストはローカルで出来るようにしています。ただユニットテストは出来るけど、S3とか他のイベントソースが多くなってくるとなかなか難しくなりますね。そういうところは自分でイベントを流して動作確認を行っています。あとE2Eテストを動かしていて、確認もしています。開発後の運用フェーズの話ですけれども。Lambdaに登録するハンドラーにはBusiness objectを分離するような、S3とかのAWS固有リソースが出てこないような薄い書き方を心掛けています。

相馬：

ローカルでやってます。CI回してます！と言いたいところですが...Lambdaはリクエストハンドラに処理書かないとか、対応はしています。全体の正常性については、ピタゴラスイッチ的なAPIを繋いでいくような仕組みになってるのでAPIを叩いて裏まで到達しているかの確認はしています。

生井：

テストフレームワーク等は使ってないです。サムネ生成がシンプルなので、入力はs3からのJSON→結果として生成した画像が生成される、という作りになっています。なので、JSONを渡して画像を生成した事が確認出来るように、シンプルにはしています。

　

Q.システムのステージ環境管理

吉田：

個人的に、最近すごく迷っている部分ではあるんですけれども、開発／ステージング／本番環境等の環境管理に関する部分です。 この部分については、AWS Lambdaのエイリアス機能であったり、API Gatewayのステージ機能等が利用出来るかと思います。 これら機能を使って1つの関数の中で切り替えていく事は出来るけれども、使いづらい部分もあるのではないか、と思っています。 その辺どう管理していますか？

生井：

(Lambdaのエイリアス機能等は)使ってないです。環境毎のデプロイはDev用の関数としてfixを付けています。そしてDevの関数にはDev用のs3を用意する、という対応にしています。

吉田：

なるほど、環境が面毎にあって対応している、ということですね。

相馬：

同様に、今のところは全ての環境毎にプレフィクスを付けて管理しています。別関数別環境。最近は環境の数も増えてデプロイミスも何度かあったので、最近はデプロイ自動化を検討していますが、差分を吸収するような構成を考えています。吉田さんが仰られた関数を使うようにはしたいですね。

猪飼：

生井さんと同じく、使ってはいないです。アカウントで環境を分けて同じ構成をデプロイしています。

吉田：

日経さんの方でこれらの機能をつかってみたい、というモチベーションはない？

猪飼：

複雑になりそうな感じもしているので、そこへのモチベーションはあまり無いですね。

　

Q.リリース管理

吉田：

どんなフローでリリース管理を行っているのか、どんなツールを使っているのか。開発や本番でリリース方法に違いはあるか？などをお伺い出来ればと思います。

猪飼：

基本的にはGithubにプッシュしてCIを回してデプロイする構成を取ってますが、これはあまり動いてはない事もあります…小さい関数の場合は自分でzipにかためてデプロイするという事もあります。開発や本番での管理方法に違いはありません。

相馬：

ソース管理はGitを使っています。同じツリーの中にシステムの関係するソースコードを格納してビルドしています。 AWS CLIを使ってJenkinsからキックするデプロイ方法を取っています。

生井：

自動デプロイはしていません。環境毎にデプロイをミスったらやばいというのもありますので、そこを解決する方法として、環境毎にvpcごとに異なるようにして、IAMも異なるものを割り当てて安全性を確保するようにはしています。デプロイツールはApexを使い、node.jsで書いたコードやnpmのパッケージをまとめてアップロードしています。

　

Q.フレームワークツール

吉田：

開発にあたって使っているフレームワークなどありましたら教えてください。ちなみに先程出てきましたApex、 ライブラリをまとめて居るのに使っていますが便利ですね。サーバレスコミュニティのアンケートでも2位にランクされていました。

生井：

Go言語で実装されているので導入が楽なので使いやすいとは思います。

相馬：

Serverless Framework導入に向けて検証を行っています。API GatewayとLambdaの紐付を出来るのでそれをバージョン管理して必要なところだけ改修なりリリースを出来るようにしていきたいですね。

吉田：

確かにこういうフレームワーク使った方が楽ですよね。アンケート5位にランクされた、AWS公式のAWS Serverless Application Model(SAM)についても同じようにAPIのエントリと関数をセットで管理出来るので今後人気を二分してくるのでは、と思っています。

猪飼：

紙面ビューア作成当時にはフレームワークが無かったので使っていません。Apex使っているところは社内では幾つか出てきました。SAMはまだ試していないです。 個人的にはServerless Frameworkが興味がありますね。

吉田：

カバー範囲がいまのところ一番広そうですもんね。DynamoDBやStepFunctionsも使えますし。

　

Q.サービスレベル目標

吉田：

残り時間5分。毛色を変えてこんな質問をしてみたいと思います。サーバレスで開発するにあたって、システムに対してサービスレベル目標は考えましたか？考えていた場合、具体的なSLO(目標)/SLI(指標)があれば。

生井：

サービス・システムの指標は用いていない。元々サービスを良くしたいというのを掲げていたのでアップロードの時間計測は行っていました。エラー率についてはタイムアウトでエラーがたまに出る事が分かりました。そのあたりはリカバーしてちゃんと動くようにしています。目標値というものはありませんがスムーズに動いています。

相馬：

APIコールのエラー率を0.8%に掲げています。当初はJMeterで負荷掛けてLambdaのタイムアウトが出ないように、まぁポツポツ出てはいるんですけれども...

吉田：

設定した事で切り戻しの判断も出来た、ということですね。

相馬：

はい。無理してLambdaを使わなくても、ということです。

猪飼：

特には無いです。朝刊を確実に見せられればと、というのがあるので。

吉田：

なるほど。しかも今、全部上手く行ってますしね。

　

Q.さいごに

吉田：

ではそろそろ時間という事で最後の質問を。サーバレスに向いているシステムの見極めポイントなどあれば何か。今日参加された皆さんのヒントになれば。

猪飼：

長く時間が掛かる、大きなシステムを作ろうとすると苦労すると思います。開発体制にも向き不向きがあると思います。大規模人数になるとコストも大変。少数の方が向いていますね。小規模体制。そういう体制で使うツールとしてはサーバレスは適していると思います。

相馬：

時間掛かるものは不向きだな、と思います。リクエストキューイング的なものであれば効果を発揮するのでは、と思います。個人的には軽めのJavaScript/Pythonでコードの長くないもの、システム全体で非同期で稼働するものであればフィットするかなと。APIコールに対応してリクエストを返さなければ行けない、というのはあまり向いていないかもしれません。

生井：

必要なときにだけ動いて欲しい、というのはLambdaを使えば簡単に作れます。イベント駆動でやれば行ける、イベント駆動で作れるものが向いているのでは。

吉田：

という事で以上とさせて頂きます。皆様、是非サーバレスの開発を今後どんどん進めていってより良い、より素早い開発フローを洗練させて行って頂ければと思います。ありがとうございました。

　

まとめ

デブサミ2017、『サーバレスにおける開発プロセス戦略』のディスカッションセッションの内容は以上となります。開発者が直面しているであろうトピックについて様々な切り口でディスカッションがなされていた様に思います。正直1コマ45分では全然足りなかったのではないか、と感じた内容の濃さでした。当エントリをお読みになっている方々に取っても何かしらの改善・前進のヒントになるものが得られたのであれば幸いです。