サーバーレス環境で スピーディーに構築するLINE Platform アプリ

LPF REVUP 2020 大阪トラック登壇資料
https://revup.jp/

Transcript

1. αʔόʔϨε؀ڥͰ εϐʔσΟʔʹߏங͢Δ -*/&
   1MBUGPSN
   ΞϓϦ LPF REVUP 2020 େࡕτϥοΫ 2020.11.14 Sumihiro Kagawa
2. ⾃⼰紹介
3. 加川 澄廣（かがわ すみひろ） n Keywords l LINE API Expert l python , TypeScript, Nuxt.js, AWS, GCP l “LINE Pay API SDK for python“ Contributor sumihiro3 sumihiro.kagawa 3
4. 本⽇のテーマ
5. LINE Platform Application Serverless Architecture 5
6. サーバーレスとは︖
7. サーバーが無い︖ ではなく 7
8. サーバーの存在を 意識しない 8
9. サーバーレス nサーバーの存在を意識しない サーバー管理 スケーリング調整 ⾼可⽤性確保 リソース・コスト調整 9
10. サーバーレス nサーバーの存在を意識しない サーバー管理 スケーリング調整 ⾼可⽤性確保 リソース・コスト調整 サービス開発に注⼒できる 10
11. サーバーレス nいいこと尽くめでもない ⾃由度が低い 監視対象数は増加しがち 開発前に決めておくことは多い 開発費⽤は⾼くなるかも 11
12. サーバーレス n導⼊が向いているケース スタートアップ 新規事業 機能要件の更新頻度が⾼い事業 規模等の⾒積もりが難しい事業 12
13. サーバーレス・アーキテクチャの詳細 は、専⾨記事などをご参照ください https://aws.amazon.com/jp/serverless/patterns/serverless-pattern/ 13
14. LINE Platform アプリと サーバーレス との親和性
15. LINE pf アプリ と サーバーレス との親和性 nLINE の特徴 Ø ユーザーが⽇常使うサービス Ø ユーザーとの距離が近すぎる（良い意味で） Ø ミニアプリ普及でもっと⽣活に密接なる 15
16. LINE pf アプリ と サーバーレス との親和性 nそのため、LINE 上で動くサービスは更新頻度が⾼い Ø ユーザーを飽きさせない Ø 状況に応じて新しいことをどんどん取り込む - 利⽤状況の変化 - ニューノーマルなど世情の変化 Ø 実験的なサービスをやりやすい など 16
17. LINE pf アプリ と サーバーレス との親和性 nLINE Platform 上で動かすアプリでの特徴 認証は LINE 側で実施 ステートレスを求められがち ⾮同期処理がしやすい API 構成 UI は LINE アプリに依存しがち 17
18. LINE pf アプリ と サーバーレス との親和性 nLINE Platform 上で動かすアプリでの特徴 認証は LINE 側で実施 ステートレスを求められがち ⾮同期処理がしやすい API 構成 αʔόʔϨεͱͷ ਌࿨ੑ͕ߴ͍ UI は LINE アプリに依存しがち 18
19. LINE Platform アプリ での サーバーレスアーキテクチャ の使い所
20. Webhook イベントの 受け付けとリプライ （Messaging API / LINE Bot） 20
21. LINE Bot (Messaging API) nWebhook イベントの受け付けとリプライ Message, Follow, Post back, Beacon etc. Webhook event Reply API 21
22. Webhook イベントの受け付けとリプライ nWebhook イベントの受け付けとリプライ処理の流れ Webhook event リクエストの レスポンスでなくてOK︕ Webhook event Reply API 22
23. Webhook イベントの受け付けとリプライ nWebhook イベントの受け付けとリプライ処理の流れ Webhook event リクエストの レスポンスでなくてOK︕ Webhook event Reply API ඇಉظͰ0,ʂ 23
24. Webhook イベントの受け付けとリプライ nWebhook イベントのリクエスト受け付けと、リ プライは同⼀リクエスト内ではなくてよい Webhook event Response レスポンス = リプライ ではない 24
25. Webhook イベントの受け付けとリプライ n Webhook イベント受け付けと、リプライは分けて実⾏ l Webhook リクエストへのレスポンスは即返す l イベント処理はQueue を挟んで⾮同期での処理後に返す Webhook event Response Reply API Webhook処理 ビジネスロジック Reply API 実行 25
26. Webhook処理 ビジネスロジック Reply API 実行 Webhook イベントの受け付けとリプライ n Webhook イベント受け付けと、リプライは分けて実⾏ l Webhook リクエストへのレスポンスは即返す l イベント処理はQueue を挟んで⾮同期での処理後に返す Webhook event Response Reply API Webhook event の 振り分けのみ実施 実際のロジックは ⾮同期の後続で実施 Reply には時間的な 余裕あり（数⼗秒程度） 26
27. Webhook処理 ビジネスロジック Reply API 実行 Webhook イベントの受け付けとリプライ n 受け付けと処理・リプライを分ける⽬的 l ユーザーへのレスポンスを優先 l 責任分界点の明確化 Ø ビジネスロジックはLINE API への依存を薄くして他 Platform へも展開可とする Ø 単体テストをしやすく Webhook event Response Reply API LINE の「Webhookイベント オブジェクト」への依存は ここで留める ビジネスロジックは LINE API への依存を 薄くする 頻繁に利⽤する API 実⾏処理は分離・共通化 27
28. Messaging API 実⾏エラー時の リトライ処理 28
29. Messaging API 実⾏エラー時のリトライ処理 nAPI 再実⾏時に “リトライキー” を設定していないと https://developers.line.biz/ja/docs/messaging-api/retrying-api-request/ スクリーンショット 2020-11-10 13.44.02 "1* ϦΫΤετ͕ ೋॏͰ࣮ߦ͞ΕΔ৔߹΋ 29
30. Messaging API 実⾏エラー時のリトライ処理 nAPI 実⾏エラーに備え “リトライキー” の設定が推奨 https://developers.line.biz/ja/docs/messaging-api/retrying-api-request/ スクリーンショット 2020-11-10 13.44.02 -*/&
    QG
    ଆͰೋॏ࣮ߦΛ ੍ޚͯ͘͠ΕΔ 30
31. Messaging API 実⾏エラー時のリトライ処理 nとはいえ、リトライ判別処理を各所に実装︖ スクリーンショット 2020-11-10 13.44.02 https://developers.line.biz/ja/docs/messaging-api/retrying-api-request/ 31
32. Messaging API 実⾏エラー時のリトライ処理 n ビジネスロジックからAPI 実⾏処理を分離 l 責任分界点の明確化 Ø ビジネスロジックに LINE API 独⾃の仕様を 混⼊しない "1* ࣮ߦ 3FUSZ
    LFZ 3FUSZ
    LFZ 3FUSZ
    LFZ 3FUSZ
    LFZ ビジネスロジックから API 実⾏処理を分離する ビジネスロジック LINE API 実行 32
33. Messaging API 実⾏エラー時のリトライ処理 n ビジネスロジックからAPI 実⾏処理を分離 l API 実⾏側でもインフラに任せられる部分（リトライ）は任せる Ø インフラ側で担保されているのであれば、 むやみに⾃前で実装しない "1* ࣮ߦ API 実⾏エラーが発⽣しても Queue のリトライ機能で安全に 再実⾏できる Push API などの実⾏処理を共通化し、 リクエスト拒否（Conflict） 時は 再実⾏しないようにしておく 3FUSZ
    LFZ 3FUSZ
    LFZ 3FUSZ
    LFZ 3FUSZ
    LFZ ビジネスロジック LINE API 実行 33
34. ユーザー⾏動履歴の記録・分析 34
35. ユーザー⾏動履歴の記録・分析 n ユーザーへの即応を優先 l ⾏動履歴の記録や分析など、即応が求められないものは極⼒⾮同期で処理する Ø その他 - エラー通知、課⾦に必要なサービス利⽤履歴の記録など ユーザーへのレスポンスは 最優先で返す 形式が求められない場合は 既存の可視化ツールを活⽤ （kintone, QuickSight など） データ分析⽤の処理はDB トリガーや 定期実⾏などで後から処理する 35
36. LIFF アプリ on SPA 36
37. LIFF アプリ on SPA nLINE アプリ（Native app）上のアプリだからこそ ページ切り替えを素早く⾏う l ユーザーからすれば Native app/Web app の違いなど気に しない Ø 逆に⾔うと Native app 相当のものが求められる 現状、SPA (Single Page App) を選択 37
38. LIFF アプリ on SPA nSPA + クラウドストレージ + CDN l LIFF アプリやミニアプリには、従来のWeb アプリと⽐べ、 画⾯切り替え時間が短い SPA を選択 SPA 部分のアプリリソースをS3 に 配置し、CloudFront でCDN 配信する BFF （Backend For Frontend） となる API は API Gateway + Lambda で展開する 38
39. SSG x LIFF で 静的サイトを LIFF アプリ化 39
40. SSG x LIFF で静的サイトを LIFF アプリ化 nLIFF を静的サイトに組み込んでユーザー⾏動を分析 l オウンドメディアやブログを LIFF アプリ化 Ø サイト上で実⾏される LIFF SDK (JS) でLINE ログインす ることでユーザー識別も可能 - LINE アプリ上で表⽰すれば、ログイン操作不要でユーザー識別可 - LIFF SDK は LINE アプリ内ブラウザ以外にも対応しているため、既存サイ トにも簡単に適⽤できる 40
41. SSG x LIFF で静的サイトを LIFF アプリ化 n Headless CMS + SSG(Static Site Generator) + LIFF SDK l CMS でのコンテンツ更新時に、コンテンツを静的サイトとして⽣成 Ø アクセスの度にDB 等へアクセスしないので⾼速 - いわゆる JAMStack 構成 メディア担当者などが CMS で 記事を更新時にビルド（SSG）実⾏ SPA と同様にサイトリソースをS3 に 配置し、CloudFront でCDN 配信する LIFF SDK で LINE ログインや、 ShareTargetPicker などを利⽤できる 41
42. 開発事例
43. LPF REVUP 2020 Landing Page n静的サイト + LIFF を JAMStack 構成で構築 l LIFF + Headless CMS + SSG の例 Ø 登壇情報の配信 + 予約状況の表⽰ - セッション情報などのコンテンツは microCMS へ事務局担当者が投稿 • 投稿をトリガーにして、SSG がメディアサイトをビルド - CDN であるNetlify へ配信 - 予約状況は connpass API を実⾏してセッションページなどに表⽰ - ShareTargetPicker などの LIFF 機能を利⽤ 43
45. 頻繁に利⽤する API 実⾏処理は分離・共通化 予約状況のみ外部API で 都度取得 45
47. LPF REVUP 2020 Landing Page n システム構成 l Headless CMS Ø microCMS l SSG Ø Nuxt.js (Full static generation） l CDN Ø Netlify Hosting l BFF Ø Netlify functions l CD Ø Netlify 47
48. LPF REVUP 2020 LP (https://revup.jp) Netlify Functions REVUP 事務局 microCMS Netlify NuxtJS Vue.js LIFF 開発者 GitHub connpass Speaker Deck 更新通知 コンテンツ取得 ビルド＆デプロイ git push 更新通知 ソースコード取得 システム構成図 セッション、スピーカー などのイベント情報編集 参加者 サイト閲覧・申込み 48
49. C向けオンライン予約システム nBot + LIFF でサービス提供 l 予約フォーム Ø 予約データを⼊⼒すると BFF 経由で記録、予約担当者へ通知 l 診断フォーム Ø LIFF アプリ上でいくつかの質問に回答してデータ収集、BFF 経由でユーザー情報としてデータ登録 - データ記録と並⾏して、分析データをS3 へ保管し データ分析（Firehose + Athena + Lambda + QuickSight）へ 49
50. C向けオンライン予約システム n システム構成 l フロント Ø SPA (Nuxt.js) + S3 + CloudFront l BFF Ø API Gateway + Lambda + DynamoDB + SQS + SNS (Email + kintone) l データ分析 Ø Firehose + Athena + Lambda + QuickSight l CD Ø GitHubActions + Zappa 50
51. システム構成図 ユーザー SPA (LIFF) 管理者 予約・診断 予約・診断 予約・診断 予約・診断 予約通知 診断データ分析 診断データ確認 ユーザー 予約・診断 データ確認 予約・診断 51 BFF データ分析
52. LINE Pay Drink Bar nLIFF + LINE Pay API で構築 l 書籍「 LINE API 実践ガイド」に掲載した実装例 Ø ドリンクの注⽂・決済・くじ引き - LIFF アプリ • 商品⼀覧での選択 • ドリンク抽出画⾯でのプログレス表⽰ • くじびき抽選など - サーバーサイド • LINE Pay API、obniz Cloud と連携 52
53. ঎඼Ұཡ ܾࡁ࣮ߦ ܾࡁ׬ྃ υϦϯΫநग़ நબ։࢝ நબ׬ྃ 画⾯遷移 53
54. LINE Pay Drink Bar n システム構成 l フロント Ø SSR（Nuxt.js） + Google App Engine l サーバーサイド Ø Nuxt.js + Firestore l CD Ø GitHubActions + firebase CLI l ハードウェア Ø obniz + エアーポンプ + シリコンチューブ 54
57. LINE Pay Drink Bar （ソフトウェア） LINE Pay Drink Bar （ハードウェア） obniz Board ユーザー LINE LINE Front-end Framework (LIFF) エアーポンプ Google App Engine Cloud Firestore NuxtJS Vue.js 決済実⾏ 注⽂・決済 ドリンク注⽂・決済 システム構成図 ドリンク抽出 57
58. まとめ
59. まとめ nまずやってみる場合サーバーレスを最初の選択肢に l 必ず適する訳ではないが、⽴上げ期には良い選択肢 nLINE Platform アプリとの親和性は⾼い l API 実⾏箇所だけ使うのでも良いかも n組み合わせは要件次第でいくつものパターン有り 59
60. 宣伝
61. 書籍「LINE API実践ガイド」発売中︕ nLINE API はコレを⾒れば分かる l Expert 達が思い思いに綴った480P Ø なんと 8.3円/ページとお買得︕ Ø 最終章（7.2）のHW 連携を担当 l 本イベントで Twitter キャンペーン 実施中︕ https://book.mynavi.jp/ec/products/detail/id=117310 （税込: 3,993円） 61
62. SNS アカウントなど @sumihiro3 Sumihiro.Kagawa LINE API Expert 62
63. ご清聴 ありがとうございました︕
64. E.O.C.