サーバーレスにすれば自然とマイクロサービス化されるわけではない

「マイル手帳」のバックエンドをServerless Frameworkで構築

2016年10月12日 07時00分更新

文● 重森大　編集●大谷イビサ

JAWS-UG東海道 in 浜松で行なわれた地元企業での活用事例発表、最後に登壇したのはエアーズの加藤匡邦さん。航空マイレージや各種ポイントを自動的に集計してくれる「マイル手帳」のバックエンドシステムを、Serverless Frameworkを使って構築したという。アプリのバックエンドになぜサーバレスシステムを取り入れたのか、そのために工夫した点はどこなのか。実際のシステム構成を示して紹介してくれた。

陸マイラー、空マイラーにポイントマニアまで満足させるマイル手帳

　加藤さんは飛行機移動を多用するのではなく、航空系クレジットカードを使ってマイレージを貯める「陸（おか）マイラー」だとまず自己紹介。この日も朝5時に起きて2時間かけてプレゼン資料を作成時したのち、新幹線を使って浜松入りした。

エアーズ加藤匡邦氏

「朝から2時間かけて作った資料を、完成後に間違えて削除してしまいました。その後、新幹線では愛用のポーチを車内に忘れてきてしまい、ハプニング続きの半日でした。悪いことは起こり尽くしたので、午後はいいことしか起こらないはずです」（加藤さん）

　そういうわけで、プレゼンに使われた資料は、一度作成して削除され、のちに思い出しながら再作成されたものとのこと。作業が終わって一段落して、気分を切り替えるためにデスクトップやゴミ箱を整理するというのは筆者もよくやる。そのときに必要なファイルまで削除してしまう……というのも、やはりたまにやってしまう。なので、加藤さんの無念さはとてもよくわかる。

　そんな加藤さんが紹介してくれたマイル手帳は、陸マイラーだけではなく、飛行機に乗ってマイレージを貯める空マイラー、各種クレジットカードでポイントを集めるポイントカードマニアのために作られたiPhoneアプリだ。マイレージやポイントを自動計算してくれるだけではなく、ポイント同士の交換も可能とのこと。

iPhoneアプリ「マイル手帳」

Serverless Framework採用の理由とその使い勝手は

　マイル手帳は、その処理のほとんどをモバイルアプリ側で行なう設計になっている。データも端末側にRealmで保管されており、バックエンド側はマイレージやポイントデータを収集してアプリと同期するなど補完的な機能に留められている。

「バックエンドで行なうのは、各ポイントサイトをクロールしてポイント情報を収集するなど補助的な機能のみ。複雑な処理を行なわないのでサーバーは不要と考えました。さらに、サーバーレスで構築すれば高いセキュリティを担保できるという期待もありました」（加藤さん）

　サーバーがなければ、乗っ取られる心配がない。認証情報もLambdaのメモリ内でのみ扱えば、漏えいが心配な個人情報を持たずに済む。CloudTrailやCloudWatchを利用した監査、監視も可能だ。もちろん、サーバー構築不要でスピーディにアプリをリリースでき、利用者増加に合わせてスケールできるなどクラウド一般のメリットも享受できる。

「しかしLambdaをそのまま使って手組みでバックエンドシステムを構築するのは簡単ではなさそうだと感じました。実際に実験してみたのですが、そのまま続けていくと手間がかかりすぎると感じたので、Serverless Frameworkを開発に採用することにしました」（加藤さん）

　Serverless Frameworkとは、AWS LambdaやMicrosoft Azure Functions、Google CloudFunctionsを使ってアプリだを作るためのフレームワークワークで、ビルドやデプロイ、アップデートなどサーバーレスアーキテクチャのライフサイクル管理を支援してくれるもの。直接コードを書くよりも簡単かつ安全に、CloudWatchのイベントやDynamoDBなどのリソースを利用できる。

　バックエンドシステムには8つのファンクションがあり、それぞれにバージョンナンバーがつけられている。開発が進めば各ファンクションのバージョンナンバーにはずれが生じるが、Serverless Frameworkで含むべきファンクションのバージョンナンバーを指定しておくことで自動的に必要なファンクションがインクリメントされる。

「ただ、デプロイは言うほど簡単ではありません。8つあるファンクションすべてに対して、依存するライブラリをパッケージングする必要があります。またServerless Frameworkで管理しているリソースとAWS上のリソースが一致していないと競合するので、整合性を確認しながらデプロイする必要があります。これを開発用ビルド、ベータテスト用ビルド、リリース用ビルドと3段階に分けて行ないます」（加藤さん）

デプロイ時には意外と手間がかかる

　ビルドごとに含むべきファンクションのバージョン管理や、デプロイ時のライブラリパッケージング作業は面倒くさいだけではなく、CLIを使った手作業がヒューマンエラーを引き起こしかねない。エアーズはこうした課題を、デプロイ作業を自動化するスクリプトを作成時にはすることで解決したそうだ。

バックエンドシステムの具体的な動きについても解説

　iPhoneアプリケーションとバックエンドシステムとの連携やデータの流れについて、実際の動きが解説されたのもこのプレゼンの注目ポイントとなった。実際にリリースされているアプリの裏側が解説されたので、エンジニアにとっては参考になる情報も多かったことと思う。

マイル手帳システム構成図

「モバイルアプリはCognitoから未認証ユーザーとしてのアイデンティティを取得し、API Gatewayを介してLambdaをキックします。そうすると、Lambdaが各サイトをクロールしてマイレージやポイントのデータを取得してくる仕組みです。モバイルアプリから受け取った各サイトの認証情報を生データのまま持っておくのは危険なので、Key Management Serviceを使って暗号化したのちにDynamoDBに格納しています」（加藤さん）

　登録後は、スケジュールされたタイミングでCloudWatch EventsからLambdaをキックする。Lambdaは各ユーザーの認証情報を使ってWebサイトからポイント残高情報などを読み取り、SNSを使ってメッセージとしてモバイルアプリに配信する。アプリはこれを受け取ってRealmに保存しており、ユーザーが見る情報はすべてアプリ側に持たせる仕様になっている。

「Webサイトのクロールでエラーが発生する場合があるので、エラー処理用の画面をS3に配置してあります」（加藤さん）

サーバーレス化がもたらしたメリットとデメリット、そして今後の課題

　アプリのバックエンドをサーバーレスで構築したことで得られた最大のメリットは、求めていたセキュリティを確保できたことだ。認証情報が生データとして扱われるのはLambdaのメモリ内だけなので、社内のエンジニアでさえもユーザー情報をのぞき見ることのできないシステムを実現できた。またサーバー構築が不要なのでリリース作業時の負担がないこと、インスタンスとして稼動し続ける訳ではないのでサービス監視アラートに悩まされないことなども運用後の大きなメリットに挙げられていた。

「実際に作ってみてわかったことは、サーバーレスにすれば自然とマイクロサービス化する訳ではないということです。Rails脳なので、思ったよりもモノリシックなつくりのサービスになりました」（加藤さん）

　他にも、実際にサーバーレス化に取り組んでみてわかったことはあるようだ。そのひとつが、API Gatewayのタイムアウトが意外と厳しいということ。30秒でタイムアウトするのだが、Webサイトのクロールが時間内に終わらないことが予想よりも高い頻度で発生しているそうだ。

「これからはRailsじゃなくてサーバーレスだよなと思って作りましたが、機能を増強していくうちに管理アプリがほしくなるなど要望がふくらみ、Virtual Private Cloud内にRailsアプリケーションを置いて連携させることも今では検討しています」（加藤さん）

　サーバーレスが話題だからといって、何でもサーバーレス化すれば使い勝手がよくなる訳ではなく、他の技術同様に使い方や、使いどころを見極める必要があるようだ。

■関連サイト

10月22日（土）、「JAWS Festa 東海道 2016」が開催！

10月22日、AWSのユーザーグループであるJAWS-UGが主催する大型コミュニティイベントであるJAWS Festaが今年は名古屋工業大学で開催される。今年のテーマは「クラウド・IoTの最前線、みんなで学べば怖くない！〜一緒に熱くなれる仲間を見つけよう〜」ということで、学ぶだけのセミナー形式勉強会にならない多彩な企画が用意されているという。

詳細はこちら