サーバーレス+SPAでつくる！ユーザーご意見管理システム

CONFIDENTIAL ©NAVITIME JAPAN
サーバーレス＋SPAでつくる！
ご意見管理システム
株式会社ナビタイムジャパン
ACTS(研究開発部門) 木村尚俊
C-3
#devboostC

View Slide

Agenda
• 自己紹介・NAVITIMEについて
• ご意見管理システム
• 導入背景
• 構成検討〜開発まで
• 運用開始後の話
• まとめ

View Slide

自己紹介
木村尚俊 (きむらたかとし)
ACTS(研究開発部門) アプリグループ地図PJ
• 2014年新卒入社
• 経歴
• PC-NAVITIME/SPブラウザ版NAVITIMEのWebサービス開発・運用
• 法人向け乗換PKGの開発・運用
• NAVITIMEトラベル立ち上げ
• 現在の業務
• Android/iOSアプリ用の地図フレームワークの開発
• 地図配信サーバー環境の運用etc…

View Slide

NAVITIMEについて
会社名株式会社ナビタイムジャパン
設立 2000年3月1日
業務内容コンシュマー向けナビゲーションアプリ/Webサイ
トの運営・開発
通信カーナビゲーション事業
経路探索エンジンのライセンス事業など
従業員数 500名 ★うちエンジニアが8割以上！

View Slide

外国人&海外
公共交通
自動車
NAVITIME 乗換
NAVITIME
こみれぽ
バス
NAVITIME
ドライブ
サポーターカーナビ
タイム
トラック
カーナビ
NAVITIME Transit
NAVITIME for
Japan Travel
Plat by
NAVITIME
NAVITIME
Travel
ウォーキング
NAVITIME-ALKOO-
二輪車トラベル&フィットネス
自転車NAVITIME
ツーリングサポーター
月間ユニークユーザー数
約5,100万人有料会員数
約480万人
(2018/09時点)

View Slide

トータルナビ事業ヘルスケア事業
バス事業ドライブ事業
ツーリング事業メディア
トラベル事業
インバウンド事業キャリア協業事業
テレマティクス事業交通コンサル
ティング事業
ビジネス
ナビタイム事業
法人
ソリューション事業
･トータルナビアプリ
･乗換検索アプリ
･法人向けウォーキングコース
作成ツールの開発、販売
･バスアプリ
･公共交通事業者向け
ソリューションサービス
･各種カーナビアプリ
･自転車、バイクの
ナビアプリ
･旅行計画,予約アプリ
･海外乗換アプリ
･自治体向け観光アプリ
･外国人旅行客誘致等の
コンサルティング
･通信キャリア会社との
プロダクトアプリ
･国内外カーメーカー、車載機
メーカー向けOEMアプリ
･移動に関するビッグデータを
活用した各種コンサル
･動態管理ソリューション
･トラックアプリ
･サービス内で使用されている
機能をAPI,SDKで販売
事業領域
B to C B to B / B to G

View Slide


View Slide

1. 導入背景
2. 構成検討〜開発まで
3. 運用開始後の話

View Slide

(1)導入背景
• 最初の導入は「トラックカーナビ」
• 通常のカーナビに比べ、ユーザー層が絞られている
• ニーズが明確なご意見もおおい
ユーザーとコミュニケーションをとりながら
プロダクトを改善し、ロイヤリティ向上につなげたい！

View Slide

(1)導入背景
これまでは…
ユーザーからの
投稿
開発Tがご意見を見ながら
新機能や改善策を検討

View Slide

(1)導入背景
開発チームとユーザーの距離は大きい
• プロダクトを修正したことが伝わらない
• ユーザーの操作ミス等のサポートができない
• カスタマーサポートの部門はあるが、こちらは温度感高めのもの
• ライトなご意見を拾うことができない

View Slide

(1)導入背景
やりたいこと
ユーザーからの
投稿
開発Tがご意見を見ながら
新機能や改善策を検討
+
頂いたご意見に対してフィードバック
ユーザーへの
フィードバック

View Slide

(1)導入背景
【他社事例】
無印良品 IDEA PARK
ユーザーからの投稿を
プロダクト新規開発や改善に
反映している
企業側もユーザーの投稿へ
返信し、ステータスを反映
している

View Slide

1. 導入背景

View Slide

(2)構成検討〜開発まで
要件を整理
ユーザーができること
• プロダクトへのご意見を投稿できる
• 自分の投稿をあとから確認できる
• ナビタイムからの返信を確認できる
• さらに返信できる
• 他ユーザーに公開するか選べる(許諾)
• 他ユーザーのご意見を閲覧できる
• 自分が気になる投稿にリアクション
できる(いいね！など)
ナビタイム側ができること
• ユーザーからのご意見を一覧で見れる
• アプリバージョンetcで絞り込める
• ご意見に対して返信できる
• 他ユーザーへの公開/非公開を設定できる
• ご意見を管理できる
• 担当の割当
• 優先度の設定
• メモ(ユーザーには非公開)
• 制限
• 関係者外からは閲覧不可にする
(個人情報保護の観点)

View Slide

現在のプロダクトの全体構成
アプリ用
APIサーバー
社内共通
APIサーバー
スポット情報
DBなど
経路探索
エンジン

View Slide

どのあたりの開発が必要か
アプリ用
APIサーバー
社内共通
APIサーバー
スポット情報
DBなど
経路探索
エンジン
ご意見用API
+ DB
管理用GUIツール
今回の開発で
手が加わる部分

View Slide

つまり、
• ご意見を投稿・取得できるAPI
• ご意見を管理するGUIツール
をどうやってつくるか？を検討していけばOK！

View Slide

ほかに考えなければならなかったこと
Webツール系の開発経験が浅い人でも
開発・運用しやすいようにしてほしい！
約3ヶ月間でS-inできる状態まで
一通り作って欲しい！
極力シンプルな構成で作っておいたほうが安心…？

View Slide

シンプルな構成で思いつくところ
AWS環境で構築する前提で

View Slide

アプリ用
APIサーバー
GUIツールをSPAで
EC2 + RDSで
APIサーバー
or

View Slide


View Slide

アプリ用
APIサーバー
GUIツールをSPAで
EC2 + RDSで
APIサーバー
or
ここが
NG→

View Slide

Ph.1のターゲットであるトラックカーナビは、
• ご意見の投稿数は数十件/日程度
• APIアクセス自体も数百件/日あるかないか…
• 他ユーザーのご意見一覧取得、自分のご意見一覧取得、など
問題点 EC2インスタンスを常時稼働させるコストがかかる
スモールスタートで何かシステムを導入したい場合には適さない

View Slide

そこで、サーバーレスアーキテクチャに注目
• APIのリクエスト数に比例する従量課金のようなイメージで
コストを考えられる
• AWSでサーバーレス構成のAPIを構築したときのコストは
EC2インスタンスの常時稼働に比べて激安
• ある程度のスケーラビリティも確保されている
• 社内的に利用事例が少なかったので試すチャンス

View Slide

ざっくりとコスト見積もり
• APサーバー利用時
• EC2インスタンス
t2.micro の2台構成 → 1ヶ月あたり約20.8USD
• これに加えて、RDSインスタンスやELB等の料金
• サーバーレス構成
• API Gateway
想定月間アクセス 3,000req/month → 1ヶ月あたり約4.2USD
• Lambda
100万リクエストまでは無料
• これに加えて、DynamoDBの料金
約2,300 円/月
約470 円/月
＿人人人人人＿
＞およそ＜
＞ 5分の1 ＜
￣Y^Y^Y^Y^Y
￣

View Slide

要件を満たせるか？

View Slide

要件を満たせるか？【アプリケーション側】
• Lambda上ですべて実装可能か？
• 複雑なビジネスロジックは含まれていないのでOK
• 社内の既存資産(ライブラリ)などに依存していない
• AWSの他サービスとの連携はSDKが用意されているので難しくはない
• リリース〜実運用までのフローを組めるか？
• SAMを用いれば既存のアプリケーションと同じ感覚で利用できる
見込みが立った

View Slide

要件を満たせるか？【データ側】
• KVSを利用するデータ設計ができるか？
• Lambda + RDSの組み合わせはアンチパターン
(コネクションプーリングができない等の問題)
• 正規化は基本的にしない(冗長にデータを持つこともありうる)
• 1レコードあたりの上限(400KB)に収まるかどうか
• DynamoDBのキーやインデックスの設定方法も重要
• KVSのデータ設計でアプリケーション実装が行えるか？
• トランザクションが利用できない状況を許容できるか

View Slide

(参考)サーバーレスで考える前のデータ設計最初はER図作ってもいいかも
→同じPKのものを1つのテーブルにまとめていき
アプリケーションが実装できるならOK

View Slide

ちなみに、最近はもうちょいやりやすくなった(多分)
• DynamoDBでのトランザクションサポート
• 今までBatchWrite/Getしていた部分がTransactionWrite/Getが可能に
• Aurora Serverless Data API (まだBeta)
• API経由でRDBMSを利用できる
• トランザクションの保証はされない？
• 将来的な選択肢となりうるかも

View Slide

実際に開発フェーズに入ってからの話
1. アプリケーション編

View Slide

◆AWS SAM (Serverless Application Model)
• API, Lambda関数, DynamoDBの各リソースによって構成され
る
アプリケーションの定義を記述できる
• 定義自体はCloudFormationの拡張
• デプロイもCFnで行える
• ローカルでも実行可能(aws-sam-cli)
• 内部でDockerコンテナを立ち上げLambda実行した結果を得られる

View Slide

◆開発環境をつくる
• LambdaのランタイムはNode.jsを利用することに
• ご意見を管理するツールのSPA開発でJS知識が必要になる
• 逆に言えばフロントの開発ができれば学習コストが低い
• TypeScriptで実装 → webpackで実行するLambda関数を出力
• 型のある優しい世界
• sam-cliを利用してローカルでAPIを立ち上げて開発
• DynamoDB環境もローカルでDockerコンテナを利用して再現可能

View Slide

◆開発フロー 1. アプリケーション編
TypeScriptでLambda関数を実装
SAMのテンプレートを用いて
CFnによるデプロイ
SAMのテンプレートを用いて
SAM CLIでのローカル実行

View Slide

プロジェクト作成〜ローカル実行までの手順は
Qiita記事で公開しておりますのでぜひ御覧ください！
https://qiita.com/navitime_tech/items/70432345d930c2bc1a
14

View Slide

◆デプロイ時にはもう一工夫
• API Gateway側の定義をSwaggerで記述
• SwaggerへのAPI Gateway用拡張記法が用意されている
• API仕様書も同時に作成できるので一石二鳥
• SAMのテンプレート側にもAPI Gatewayの設定を追記

View Slide

◆デプロイ時にはもう一工夫 1. アプリケーション編
Swagger SAM
Template

View Slide

◆デプロイまでのフロー 1. アプリケーション編
ビルド結果
などを通知
webpackビルド
CFnによるLambda + API GWの更
新

View Slide

◆実際にSAMで作ってみて
• 設定を記述していく部分が多いかも？
• 慣れれば通常のアプリケーション開発と変わらない
• ローカルでAPI実行できるのは嬉しい
• 都度Lambda関数をアップして…みたいなのが無くてよかった
• Lambda実装もそこまで辛くなかった
• TypeScriptとaws-sdkのおかげ
• ユニットテストも入れられる(CIで実行もできる)ので安心

View Slide

◆ハマるポイント
• Swagger定義インポート時のエラーがちょっと不親切
• 書き方は正しくても、API GW側ではサポートしていないケースも
• 環境毎にSAMのテンプレートファイルが必要になる
• 一部を変数にして共通化しようとしたが、うまく動かない…
• Swaggerのファイルも同じ問題が…
• DynamoDBの操作クエリが少々クセがある

View Slide

実際に開発フェーズに入ってからの話
2. 管理ツール・SPA編

View Slide

◆管理GUIツールは特に悩まずSPAで
• BFFにあたる部分はプロダクト向けAPIとは別に新たに構築
• とはいえ、同じくSAMで作っているので技術スタックは同じ
2.管理ツール・SPA編
SPAをS3で
静的サイトホスティング
アプリ用
APIサー
バー
ご意見DB(共通)

View Slide

◆SPAを何で作るか
今回はVue.jsを採用
• 社内事例がまだ少なかった
• 学習コストが(他フレームワークに比べ)低い
• 実際に触ってみた感じの感触もよかった
• 個人的に触ってみたかった

View Slide

◆実際にVueで作ってみて
• Vue CLIでベースはすぐに構築できた
• Vue RouterやVuexも導入が楽だった
• カスタマイズしたのは、検証環境ビルド用設定を追加した位
• UIフレームワークも豊富で作り込みが必要な部分が少ない
• 今回はElement UIを採用
• なにより、とりかかりやすい
• 公式の日本語ドキュメントも充実している

View Slide

◆ハマりポイント
• S3の静的サイトホスティング利用時のルーティング
• アプリケーション側で実装したルーティングに直接アクセスできない
• 前段にCloudFrontをおいてカスタムエラーページをすべてindex.htmlに向け
る
• ログイン情報管理のための処理フロー
• id/passやセッション管理自体はCognitoを利用したためそこまで難しくない
• ナビゲーションガードで都度認証チェックをおこなう
• 無駄なリクエストが発生しないシーケンスに行き着くまでが難しい

View Slide

◆開発当初のジレンマ
• コンポーネント設計どこまでちゃんとやるか問題
• Atomic Designはやらなかった
• そこまで複雑なアプリケーションではないので
Pageとそれに含まれるComponentくらいの粒度で収めた
• JavaScript vs TypeScript
• TSだとコンポーネントのユニットテストが実行できなかった
• 迷った末に生JSで実装することに…
時には妥協も大事…

View Slide

◆実際の画面 2.管理ツール・SPA編

View Slide

1. 導入背景

View Slide

(3)運用開始後の話
S-inして…
• 大きな問題は特になし
• 半年近く経過したが、安定して稼働している
• 自分がいなくてもひとまず運用もできている
サーバーレスでの開発に踏み切ってよかった！
一安心。。

View Slide

本番環境ならではの問題
APIの死活監視はどうすればいいの？
• APサーバー稼働なら GET /ping で監視できた
• Lambda関数は独立しているから難しい…？
各Lambda関数のエラーをCloudWatchで監視
→一定時間内に一定数のエラーが出たらアラーム(slack通知)

View Slide

この先ぶつかるであろう問題
• 結局どこまでスケールできるのか
• 他プロダクトで横展開できる設計にはなっている
• 同時リクエストどこまで耐えられるか、見極めるポイントが難しい
• APIの仕様が複雑になっていく
• Dynamoだと検索がしんどい
• webpackでbundleされるjsの肥大化→Lambdaのアップロード制限に…
• aws-sdkだけ除外する、とかできれば嬉しい(詳しく調査できていない)

View Slide

おそらく、これらの問題にぶつかる頃が
このシステムをリプレイスするタイミングかも
• 今の構成でもこれらの問題は解決できているかも
• APサーバーでコストを抑えて稼働させる方法も
新たに出てきているかもしれない
少なくとも、今の規模感ではそこまで考えなくて良い

View Slide

まとめ

View Slide

まとめ
サーバーレスが向いていそうなもの
• 小さいアプリケーションなら十分
• モックでは足りないプロトタイプ用API
• 社内ツール
• SPAで作ると楽！
• (頑張れば)CMSとかも作れる
• microservice化の足がかりに
• 現在モノリシックなシステムを徐々に分割していくときの選択肢として

View Slide

ありがとうございました

View Slide

サーバーレス+SPAでつくる！ユーザーご意見管理システム

サーバーレス+SPAでつくる！ユーザーご意見管理システム

NAVITIME JAPAN
PRO

More Decks by NAVITIME JAPAN

Other Decks in Technology

Featured

Transcript

サーバーレス+SPAでつくる！ユーザーご意見管理システム

サーバーレス+SPAでつくる！ユーザーご意見管理システム

NAVITIME JAPAN PRO

More Decks by NAVITIME JAPAN

Other Decks in Technology

Featured

Transcript

NAVITIME JAPAN
PRO