Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サーバーレス+SPAでつくる!ユーザーご意見管理システム
Search
NAVITIME JAPAN
PRO
December 15, 2018
Technology
0
56
サーバーレス+SPAでつくる!ユーザーご意見管理システム
2018年12月15日開催「Developers Boost~U30エンジニアの登竜門~」にて発表した資料です。
NAVITIME JAPAN
PRO
December 15, 2018
Tweet
Share
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
22
14k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
260
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
88
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
2.3k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.3k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
220
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.2k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.2k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.2k
Other Decks in Technology
See All in Technology
Lexical Analysis
shigashiyama
1
150
【若手エンジニア応援LT会】ソフトウェアを学んできた私がインフラエンジニアを目指した理由
kazushi_ohata
0
150
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Taming you application's environments
salaboy
0
190
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
140
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
550
Can We Measure Developer Productivity?
ewolff
1
150
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.1k
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
410
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.4k
複雑なState管理からの脱却
sansantech
PRO
1
150
Featured
See All Featured
Teambox: Starting and Learning
jrom
133
8.8k
How to Ace a Technical Interview
jacobian
276
23k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
KATA
mclloyd
29
14k
Done Done
chrislema
181
16k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
120
Music & Morning Musume
bryan
46
6.2k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Transcript
CONFIDENTIAL ©NAVITIME JAPAN サーバーレス+SPAでつくる! ご意見管理システム 株式会社ナビタイムジャパン ACTS(研究開発部門) 木村 尚俊 C-3
#devboostC
CONFIDENTIAL ©NAVITIME JAPAN Agenda • 自己紹介・NAVITIMEについて • ご意見管理システム • 導入背景
• 構成検討〜開発まで • 運用開始後の話 • まとめ
CONFIDENTIAL ©NAVITIME JAPAN 自己紹介 木村 尚俊 (きむら たかとし) ACTS(研究開発部門) アプリグループ
地図PJ • 2014年新卒入社 • 経歴 • PC-NAVITIME/SPブラウザ版NAVITIMEのWebサービス開発・運用 • 法人向け乗換PKGの開発・運用 • NAVITIMEトラベル立ち上げ • 現在の業務 • Android/iOSアプリ用の地図フレームワークの開発 • 地図配信サーバー環境の運用etc…
CONFIDENTIAL ©NAVITIME JAPAN NAVITIMEについて 会社名 株式会社ナビタイムジャパン 設立 2000年3月1日 業務内容 コンシュマー向けナビゲーションアプリ/Webサイ
トの運営・開発 通信カーナビゲーション事業 経路探索エンジンのライセンス事業 など 従業員数 500名 ★うちエンジニアが8割以上!
CONFIDENTIAL ©NAVITIME JAPAN NAVITIMEについて 外国人&海外 公共交通 自動車 NAVITIME 乗換 NAVITIME
こみれぽ バス NAVITIME ドライブ サポーター カーナビ タイム トラック カーナビ NAVITIME Transit NAVITIME for Japan Travel Plat by NAVITIME NAVITIME Travel ウォーキング NAVITIME-ALKOO- 二輪車 トラベル&フィットネス 自転車NAVITIME ツーリングサポーター 月間ユニークユーザー数 約5,100万人 有料会員数 約480万人 (2018/09時点)
CONFIDENTIAL ©NAVITIME JAPAN NAVITIMEについて トータルナビ事業 ヘルスケア事業 バス事業 ドライブ事業 ツーリング事業 メディア
トラベル事業 インバウンド事業 キャリア協業事業 テレマティクス事業 交通コンサル ティング事業 ビジネス ナビタイム事業 法人 ソリューション事業 ・トータルナビアプリ ・乗換検索アプリ ・法人向けウォーキングコース 作成ツールの開発、販売 ・バスアプリ ・公共交通事業者向け ソリューションサービス ・各種カーナビアプリ ・自転車、バイクの ナビアプリ ・旅行計画,予約アプリ ・海外乗換アプリ ・自治体向け観光アプリ ・外国人旅行客誘致等の コンサルティング ・通信キャリア会社との プロダクトアプリ ・国内外カーメーカー、車載機 メーカー向けOEMアプリ ・移動に関するビッグデータを 活用した各種コンサル ・動態管理ソリューション ・トラックアプリ ・サービス内で使用されている 機能をAPI,SDKで販売 事業領域 B to C B to B / B to G
CONFIDENTIAL ©NAVITIME JAPAN ご意見管理システム
CONFIDENTIAL ©NAVITIME JAPAN ご意見管理システム 1. 導入背景 2. 構成検討〜開発まで 3. 運用開始後の話
CONFIDENTIAL ©NAVITIME JAPAN (1)導入背景 • 最初の導入は「トラックカーナビ」 • 通常のカーナビに比べ、ユーザー層が絞られている • ニーズが明確なご意見もおおい
ユーザーとコミュニケーションをとりながら プロダクトを改善し、ロイヤリティ向上につなげたい!
CONFIDENTIAL ©NAVITIME JAPAN (1)導入背景 これまでは… ユーザーからの 投稿 開発Tがご意見を見ながら 新機能や改善策を検討
CONFIDENTIAL ©NAVITIME JAPAN (1)導入背景 開発チームとユーザーの距離は大きい • プロダクトを修正したことが伝わらない • ユーザーの操作ミス等のサポートができない •
カスタマーサポートの部門はあるが、こちらは温度感高めのもの • ライトなご意見を拾うことができない
CONFIDENTIAL ©NAVITIME JAPAN (1)導入背景 やりたいこと ユーザーからの 投稿 開発Tがご意見を見ながら 新機能や改善策を検討 +
頂いたご意見に対してフィードバック ユーザーへの フィードバック
CONFIDENTIAL ©NAVITIME JAPAN (1)導入背景 【他社事例】 無印良品 IDEA PARK ユーザーからの投稿を プロダクト新規開発や改善に
反映している 企業側もユーザーの投稿へ 返信し、ステータスを反映 している
CONFIDENTIAL ©NAVITIME JAPAN ご意見管理システム 1. 導入背景 2. 構成検討〜開発まで 3. 運用開始後の話
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 要件を整理 ユーザーができること • プロダクトへのご意見を投稿できる • 自分の投稿をあとから確認できる
• ナビタイムからの返信を確認できる • さらに返信できる • 他ユーザーに公開するか選べる(許諾) • 他ユーザーのご意見を閲覧できる • 自分が気になる投稿にリアクション できる(いいね!など) ナビタイム側ができること • ユーザーからのご意見を一覧で見れる • アプリバージョンetcで絞り込める • ご意見に対して返信できる • 他ユーザーへの公開/非公開を設定できる • ご意見を管理できる • 担当の割当 • 優先度の設定 • メモ(ユーザーには非公開) • 制限 • 関係者外からは閲覧不可にする (個人情報保護の観点)
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 現在のプロダクトの全体構成 アプリ用 APIサーバー 社内共通 APIサーバー スポット情報
DBなど 経路探索 エンジン
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで どのあたりの開発が必要か アプリ用 APIサーバー 社内共通 APIサーバー スポット情報
DBなど 経路探索 エンジン ご意見用API + DB 管理用GUIツール 今回の開発で 手が加わる部分
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで つまり、 • ご意見を投稿・取得できるAPI • ご意見を管理するGUIツール をどうやってつくるか?を検討していけばOK!
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ほかに考えなければならなかったこと Webツール系の開発経験が浅い人でも 開発・運用しやすいようにしてほしい! 約3ヶ月間でS-inできる状態まで 一通り作って欲しい! 極力シンプルな構成で作っておいたほうが安心…?
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで シンプルな構成で思いつくところ AWS環境で構築する前提で
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで アプリ用 APIサーバー GUIツールをSPAで EC2 + RDSで
APIサーバー 管理用GUIツール or
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで アプリ用 APIサーバー GUIツールをSPAで EC2 + RDSで
APIサーバー 管理用GUIツール or ここが NG→
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで Ph.1のターゲットであるトラックカーナビは、 • ご意見の投稿数は数十件/日程度 • APIアクセス自体も数百件/日あるかないか… •
他ユーザーのご意見一覧取得、自分のご意見一覧取得、など 問題点 EC2インスタンスを常時稼働させるコストがかかる スモールスタートで何かシステムを導入したい場合には適さない
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで そこで、サーバーレスアーキテクチャに注目 • APIのリクエスト数に比例する従量課金のようなイメージで コストを考えられる • AWSでサーバーレス構成のAPIを構築したときのコストは
EC2インスタンスの常時稼働に比べて激安 • ある程度のスケーラビリティも確保されている • 社内的に利用事例が少なかったので試すチャンス
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ざっくりとコスト見積もり • 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  ̄
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 要件を満たせるか?
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 要件を満たせるか?【アプリケーション側】 • Lambda上ですべて実装可能か? • 複雑なビジネスロジックは含まれていないのでOK •
社内の既存資産(ライブラリ)などに依存していない • AWSの他サービスとの連携はSDKが用意されているので難しくはない • リリース〜実運用までのフローを組めるか? • SAMを用いれば既存のアプリケーションと同じ感覚で利用できる 見込みが立った
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 要件を満たせるか?【データ側】 • KVSを利用するデータ設計ができるか? • Lambda +
RDSの組み合わせはアンチパターン (コネクションプーリングができない等の問題) • 正規化は基本的にしない(冗長にデータを持つこともありうる) • 1レコードあたりの上限(400KB)に収まるかどうか • DynamoDBのキーやインデックスの設定方法も重要 • KVSのデータ設計でアプリケーション実装が行えるか? • トランザクションが利用できない状況を許容できるか
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 要件を満たせるか?【データ側】 (参考)サーバーレスで考える前のデータ設計 最初はER図作ってもいいかも →同じPKのものを1つのテーブルにまとめていき アプリケーションが実装できるならOK
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 要件を満たせるか?【データ側】 ちなみに、最近はもうちょいやりやすくなった(多分) • DynamoDBでのトランザクションサポート • 今までBatchWrite/Getしていた部分がTransactionWrite/Getが可能に
• Aurora Serverless Data API (まだBeta) • API経由でRDBMSを利用できる • トランザクションの保証はされない? • 将来的な選択肢となりうるかも
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 実際に開発フェーズに入ってからの話 1. アプリケーション編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆AWS SAM (Serverless Application Model) •
API, Lambda関数, DynamoDBの各リソースによって構成され る アプリケーションの定義を記述できる • 定義自体はCloudFormationの拡張 • デプロイもCFnで行える • ローカルでも実行可能(aws-sam-cli) • 内部でDockerコンテナを立ち上げLambda実行した結果を得られる 1. アプリケーション編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆開発環境をつくる • LambdaのランタイムはNode.jsを利用することに • ご意見を管理するツールのSPA開発でJS知識が必要になる •
逆に言えばフロントの開発ができれば学習コストが低い • TypeScriptで実装 → webpackで実行するLambda関数を出力 • 型のある優しい世界 • sam-cliを利用してローカルでAPIを立ち上げて開発 • DynamoDB環境もローカルでDockerコンテナを利用して再現可能 1. アプリケーション編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆開発フロー 1. アプリケーション編 TypeScriptでLambda関数を実装 SAMのテンプレートを用いて CFnによるデプロイ
SAMのテンプレートを用いて SAM CLIでのローカル実行
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 1. アプリケーション編 プロジェクト作成〜ローカル実行までの手順は Qiita記事で公開しておりますのでぜひ御覧ください! https://qiita.com/navitime_tech/items/70432345d930c2bc1a 14
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆デプロイ時にはもう一工夫 • API Gateway側の定義をSwaggerで記述 • SwaggerへのAPI
Gateway用拡張記法が用意されている • API仕様書も同時に作成できるので一石二鳥 • SAMのテンプレート側にもAPI Gatewayの設定を追記 1. アプリケーション編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆デプロイ時にはもう一工夫 1. アプリケーション編 Swagger SAM Template
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆デプロイ時にはもう一工夫 1. アプリケーション編 Swagger SAM Template
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆デプロイ時にはもう一工夫 1. アプリケーション編 Swagger SAM Template
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆デプロイまでのフロー 1. アプリケーション編 ビルド結果 などを通知 webpackビルド
CFnによるLambda + API GWの更 新
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆実際にSAMで作ってみて • 設定を記述していく部分が多いかも? • 慣れれば通常のアプリケーション開発と変わらない •
ローカルでAPI実行できるのは嬉しい • 都度Lambda関数をアップして…みたいなのが無くてよかった • Lambda実装もそこまで辛くなかった • TypeScriptとaws-sdkのおかげ • ユニットテストも入れられる(CIで実行もできる)ので安心 1. アプリケーション編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆ハマるポイント • Swagger定義インポート時のエラーがちょっと不親切 • 書き方は正しくても、API GW側ではサポートしていないケースも
• 環境毎にSAMのテンプレートファイルが必要になる • 一部を変数にして共通化しようとしたが、うまく動かない… • Swaggerのファイルも同じ問題が… • DynamoDBの操作クエリが少々クセがある 1. アプリケーション編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで 実際に開発フェーズに入ってからの話 2. 管理ツール・SPA編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆管理GUIツールは特に悩まずSPAで • BFFにあたる部分はプロダクト向けAPIとは別に新たに構築 • とはいえ、同じくSAMで作っているので技術スタックは同じ 2.管理ツール・SPA編
SPAをS3で 静的サイトホスティング アプリ用 APIサー バー ご意見DB(共通)
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆SPAを何で作るか 今回はVue.jsを採用 • 社内事例がまだ少なかった • 学習コストが(他フレームワークに比べ)低い
• 実際に触ってみた感じの感触もよかった • 個人的に触ってみたかった 2.管理ツール・SPA編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆実際にVueで作ってみて • Vue CLIでベースはすぐに構築できた • Vue
RouterやVuexも導入が楽だった • カスタマイズしたのは、検証環境ビルド用設定を追加した位 • UIフレームワークも豊富で作り込みが必要な部分が少ない • 今回はElement UIを採用 • なにより、とりかかりやすい • 公式の日本語ドキュメントも充実している 2.管理ツール・SPA編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆ハマりポイント • S3の静的サイトホスティング利用時のルーティング • アプリケーション側で実装したルーティングに直接アクセスできない •
前段にCloudFrontをおいてカスタムエラーページをすべてindex.htmlに向け る • ログイン情報管理のための処理フロー • id/passやセッション管理自体はCognitoを利用したためそこまで難しくない • ナビゲーションガードで都度認証チェックをおこなう • 無駄なリクエストが発生しないシーケンスに行き着くまでが難しい 2.管理ツール・SPA編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆開発当初のジレンマ • コンポーネント設計どこまでちゃんとやるか問題 • Atomic Designはやらなかった
• そこまで複雑なアプリケーションではないので Pageとそれに含まれるComponentくらいの粒度で収めた • JavaScript vs TypeScript • TSだとコンポーネントのユニットテストが実行できなかった • 迷った末に生JSで実装することに… 2.管理ツール・SPA編 時には妥協も大事…
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆実際の画面 2.管理ツール・SPA編
CONFIDENTIAL ©NAVITIME JAPAN (2)構成検討〜開発まで ◆実際の画面 2.管理ツール・SPA編
CONFIDENTIAL ©NAVITIME JAPAN ご意見管理システム 1. 導入背景 2. 構成検討〜開発まで 3. 運用開始後の話
CONFIDENTIAL ©NAVITIME JAPAN (3)運用開始後の話 S-inして… • 大きな問題は特になし • 半年近く経過したが、安定して稼働している •
自分がいなくてもひとまず運用もできている サーバーレスでの開発に踏み切ってよかった! 一安心。。
CONFIDENTIAL ©NAVITIME JAPAN (3)運用開始後の話 本番環境ならではの問題 APIの死活監視はどうすればいいの? • APサーバー稼働なら GET /ping
で監視できた • Lambda関数は独立しているから難しい…? 各Lambda関数のエラーをCloudWatchで監視 →一定時間内に一定数のエラーが出たらアラーム(slack通知)
CONFIDENTIAL ©NAVITIME JAPAN (3)運用開始後の話 この先ぶつかるであろう問題 • 結局どこまでスケールできるのか • 他プロダクトで横展開できる設計にはなっている •
同時リクエストどこまで耐えられるか、見極めるポイントが難しい • APIの仕様が複雑になっていく • Dynamoだと検索がしんどい • webpackでbundleされるjsの肥大化→Lambdaのアップロード制限に… • aws-sdkだけ除外する、とかできれば嬉しい(詳しく調査できていない)
CONFIDENTIAL ©NAVITIME JAPAN (3)運用開始後の話 おそらく、これらの問題にぶつかる頃が このシステムをリプレイスするタイミングかも • 今の構成でもこれらの問題は解決できているかも • APサーバーでコストを抑えて稼働させる方法も
新たに出てきているかもしれない 少なくとも、今の規模感ではそこまで考えなくて良い
CONFIDENTIAL ©NAVITIME JAPAN まとめ
CONFIDENTIAL ©NAVITIME JAPAN まとめ サーバーレスが向いていそうなもの • 小さいアプリケーションなら十分 • モックでは足りないプロトタイプ用API •
社内ツール • SPAで作ると楽! • (頑張れば)CMSとかも作れる • microservice化の足がかりに • 現在モノリシックなシステムを徐々に分割していくときの選択肢として
CONFIDENTIAL ©NAVITIME JAPAN ありがとうございました