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
Messaging API 活用最前線
Search
Shoya
January 26, 2018
Technology
0
1.6k
Messaging API 活用最前線
LINE Developer Meetup in Kyoto#26 (
https://line.connpass.com/event/75147/
) での発表資料
Shoya
January 26, 2018
Tweet
Share
Other Decks in Technology
See All in Technology
Kiroと学ぶコンテキストエンジニアリング
oikon48
4
1.7k
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
430
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
0
120
mruby(PicoRuby)で ファミコン音楽を奏でる
kishima
2
490
ヘブンバーンズレッドのレンダリングパイプライン刷新
gree_tech
PRO
0
420
ヘブンバーンズレッドにおける、世界観を活かしたミニゲーム企画の作り方
gree_tech
PRO
0
410
クラウドセキュリティを支える技術と運用の最前線 / Cutting-edge Technologies and Operations Supporting Cloud Security
yuj1osm
2
240
DuckDB-Wasmを使って ブラウザ上でRDBMSを動かす
hacusk
1
140
生成AI時代に必要な価値ある意思決定を育てる「開発プロセス定義」を用いた中期戦略
kakehashi
PRO
1
240
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
shibayu36
0
140
おやつは300円まで!の最適化を模索してみた
techtekt
PRO
0
250
LLM翻訳ツールの開発と海外のお客様対応等への社内導入事例
gree_tech
PRO
0
420
Featured
See All Featured
The Language of Interfaces
destraynor
160
25k
How to train your dragon (web standard)
notwaldorf
96
6.2k
It's Worth the Effort
3n
187
28k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Speed Design
sergeychernyshev
32
1.1k
For a Future-Friendly Web
brad_frost
179
9.9k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Navigating Team Friction
lara
189
15k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.8k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Transcript
LINE Developer Meetup in Kyoto#26 Messaging API 活用最前線 白木 翔也
@morugu
白木 翔也 株式会社REACT - ミッション 人と人とのコミュニケー ションコストをゼロにする - 事業 ボット作成サー
ビス 「Engagebot」 SNS Twitter: @morugu Blog: blog.morugu.com
Engagebot LINE/Facebook のボット作成/ 運用サー ビス
Engagebot - TV ドラマ - ゲー ム - EC サイト
and more!
今日話すこと ( ボットの) 可能性を広げる ( ボットを) 安定して運用する
本題に入る前に
ボットを作ったことある方?✋
ボット開発 オウム返しで終わりがち 機能実装こそエンジニアの力の見せどころ 実戦投入してこそボットが活きる
作ったボットの機能 採用面接 スタンプラリー カウンセリング 画像加工 実況中継 リアルタイムリッチメニュー and more!
作ったボットの機能 採用面接 スタンプラリー カウンセリング 画像加工 実況中継 リアルタイムリッチメニュー and more!
採用面接
LINE 選考に合格したら即最終面接 スピー ド感のある採用試験
None
None
カウンセリング
遠隔漢方相談サー ビス LINE BOT で質問に回答 -> 薬剤師がチャットでカウンセリング -> 漢方薬を自宅に配送
None
None
今日話すこと ☑( ボットの) 可能性を広げる ( ボットを) 安定して運用する
LINE ボットユー ザー の傾向?
1 分だけ( アクセスが) すごい来る
X 軸: LINE Webhook からのリクエスト数 Y 軸: 時間
高負荷対策 1. 高負荷な時間を確認& 予測 2. キャッシュ戦略 3. Reply API とPush
API の使い分け
1. 高負荷な時間を確認& 予測
Auto Scaling では間に合わない 最短でも1~3 分ぐらいかかる 最初の1 分が勝負 高負荷になりがちなタイミング ドラマ放送10 分前(
一斉に配信するため) 広告配信 SNS で拡散された時(Instagram, Twitter 等) プレスリリー ス配信
2. キャッシュ戦略
ものすごいメッセー ジ量
応答に必要なワー ドのみキャッシュしておく それ以外は非同期でログデー タとして処理
None
3. Reply API とPush API の使い分け
Reply API ユー ザー からのメッセー ジ受信がトリガー 短時間有効なトー クンを使用して送信 トー クンの使用は1
回のみ Push API ユー ザー or 配信側がトリガー ユー ザー へ任意のタイミングで送信
API 制限 Messaging API を経由して送れるメッセー ジは API ごとに最大10,000req/1min
一斉に配信する場合(Push API) 10,000req/1min を超過しないように配信数を制限 Ex. 対象ユー ザー が、100,000 件の場合 -
9,000req/1min ぐらい - 約12 分かかる
ユー ザー が送ったメッセー ジに 応答する場合(Reply API & Push API) 超過すると429
Too Many Requests が来る -> リトライする仕組みを予め用意しておく Reply API が制限数に達したら, Push API を併用して使う策もあり -> 20,000req/1min まで上限を伸ばせる
今日話すこと ☑( ボットの) 可能性を広げる ☑( ボットを) 安定して運用する Complete❗
Enjoy Bot Life