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
20230825 外部サービス提供のAPIを利用する機能を作るときの頭の中
Search
Takumi Abe
August 25, 2023
Technology
0
510
20230825 外部サービス提供のAPIを利用する機能を作るときの頭の中
2023/08/25 (金) フレッシュメンLT #0 夏祭りにて発表したLTの登壇資料。
https://connpass.com/event/285559/
Takumi Abe
August 25, 2023
Tweet
Share
More Decks by Takumi Abe
See All by Takumi Abe
250208 Discordに勉強会告知を⾃動でしたい!vol.2
east_takumi
0
4
250201 マネコンの進化についていけないので、MFA設定くらいは自動化して追いつく作戦
east_takumi
1
88
250125 Discordに勉強会告知を⾃動でしたい!vol.1
east_takumi
0
2
241226 推しに嫌われないためにわたしたちはなにをすべきか vol.0
east_takumi
0
67
「楽しい」を優先できる コミュニティ運営を作っていく vol.0
east_takumi
0
30
241116 Momento CacheみたいなのをAWSだけでできないか考えてみた
east_takumi
0
25
241012 おらたちに力をわけてくれ!!JAWS FESTA 2023から1年、地方とコミュニティのこれからを語り合いたい!
east_takumi
0
220
241004_JAWSPANKRATION2024-オペレーションの振り返り
east_takumi
0
49
240803 Webエンジニアが_One_Observability_Workshop_から始めるO11y.pdf
east_takumi
0
48
Other Decks in Technology
See All in Technology
DETR手法の変遷と最新動向(CVPR2025)
tenten0727
2
1.1k
Automatically generating types by running tests
sinsoku
1
440
AWSのマルチアカウント管理 ベストプラクティス最新版 2025 / Multi-Account management on AWS best practice 2025
ohmura
4
210
20250408 AI Agent workshop
sakana_ai
PRO
15
3.5k
バックオフィス向け toB SaaS バクラクにおけるレコメンド技術活用 / recommender-systems-in-layerx-bakuraku
yuya4
2
290
SRE NEXT CfP チームが語る 聞きたくなるプロポーザルとは / Proposals by the SRE NEXT CfP Team that are sure to be accepted
chaspy
1
570
SDカードフォレンジック
su3158
0
290
Стильный код: натуральный поиск редких атрибутов по картинке. Юлия Антохина, Data Scientist, Lamoda Tech
lamodatech
0
360
“パスワードレス認証への道" ユーザー認証の変遷とパスキーの関係
ritou
1
440
アセスメントで紐解く、10Xのデータマネジメントの軌跡
10xinc
1
360
AI Agentを「期待通り」に動かすために:設計アプローチの模索と現在地
kworkdev
PRO
2
390
こんなデータマートは嫌だ。どんな? / waiwai-data-meetup-202504
shuntak
6
1.7k
Featured
See All Featured
Optimizing for Happiness
mojombo
377
70k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
104
19k
Into the Great Unknown - MozCon
thekraken
37
1.7k
The Language of Interfaces
destraynor
157
24k
Speed Design
sergeychernyshev
29
880
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Thoughts on Productivity
jonyablonski
69
4.6k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Transcript
CAMPFIRE, inc. Takumi Abe 外部サービス提供のAPI を利用する 機能を作るときの頭の中
Takumi Abe { " 普段" : { " 会社": "
株式会社CAMPFIRE", " 職種": "Web バックエンドエンジニア", " 趣味": [ " 書道", " お酒" ] }, " コミュニティ活動": [ "JAWS-UG おおいた", "JAWS PANKRATION 2021 実行委員", "AWS Comunity Builder(Serverless)", "JAWS FESTA 2023" ], } }
ことの始まりは些細なことだった...
面白そうですね! ユーザーもほしそう! あべたく D ◯s ◯r ◯の垢情報とか連携できたら, もっとサービス拡張できそうだよね!
さてさてさ〜て,始めるとしますか〜 そもそもだけど,外部API との連携機能って ログインぐらいしか詳しく知らんからとりまぐぐって👀 ..... この機能ってClient がユーザーごとで違う... あっ.... あべたく
あれ... そもそもこんな実装してる事例 見たことないんだが... ここまでやって気づく API キーをDB に登録すること自体があまり推奨されてない (いやそりゃそう.... ) 必然的にルールもこれから作る...
とりあえず,今ある知識と 外部API の取り扱いの注意事項を整理 してできる限りで実装してみよう
前提事項 使用言語はRuby Ruby on Rails 6 系でのWeb 開発 サービスは既に数年稼働していて, アーキテクチャはWEB
サービスで基本的な EC2 + RDS ..( 以下略を想定 外部API はできる限り,EOL までが長いVersion での実装が希望
外部API を使う上で 気をつけること
https://zenn.dev/sky/articles/6f79982ca89ea3 超精密に知りたい方はこちら!!!
最新のメンテ状況,SDK があるか,権限周りは...etc. ドキュメントをしっかり読む API がエラーしたときのデータがずれることが無い ように処理順やリトライ/ 例外処理をきちんと定義 トランザクション管理ができている だれがなんの操作をしてるのかチェックできるように! req/res
のログを取る 一番気をつかう... きちんと暗号化されてる? トークンやキーの保管/ 運用方法を決める どこまでが自分たちでの守備範囲かをきめておく!! 連携解除( データ破棄) の仕様を決めておく 放置すると途中からAPI の仕様を理解してる人減る 自分以外にも分かる人/ ドキュメントを作る 阿部的に 外部API を使用する開発で 気をつけた/ 今後気をつけること
最新のメンテ状況,SDK があるか,権限周りは...etc. ドキュメントをしっかり読む API がエラーしたときのデータがずれることが無い ように処理順やリトライ/ 例外処理をきちんと定義 トランザクション管理ができている だれがなんの操作をしてるのかチェックできるように! req/res
のログを取る 一番気をつかう... きちんと暗号化されてる? トークンやキーの保管/ 運用方法を決める どこまでが自分たちでの守備範囲かをきめておく!! 連携解除( データ破棄) の仕様を決めておく 放置すると途中からAPI の仕様を理解してる人減る 自分以外にも分かる人/ ドキュメントを作る 阿部的に 外部API を使用する開発で 気をつけた/ 今後気をつけること
トークンやキーの 保管/ 運用方法を 決める ユーザー情報などと分けることで権限レベルを設定しやすくする 不正アクセス防止のために機密情報は載せない コードレビューのときに注意 1 管理テーブルを分ける 3
リフレッシュのタイミング 2 キーをログに残さない API を同時に叩いてエラーとかは全然あり得る 必ずトークンは1 つを参照,複数ある場合は有効なもの以 外はロック,アクセス不可にするなどで対応 4 DB に保存するならまず暗号化 フレームワークに搭載されているものを使うなり,KMS などを使うなりで対応
暗号化の候補 ActiveRecord モデルの特定の属性を暗号化するためのgem https://github.com/attr-encrypted/attr_encrypted Rails 側で保存するのは暗号化された値とKMS で管理してる暗号化キー AWS SDK で実装可能
attr_encrypted gem AWS Secrets Manager AWS KMS Rails 側で保存するのは対象のキー AWS SDK で実装可能
ドキュメントを しっかり読む API のバージョンアップやISSUE を要チェック 公式ドキュメントに無いことや新規仕様は実際に動かして みたら早かったりする 自分の言語でSDK などが展開されてるかは重要,Client などを
作らなくてもよくなる ただし,これもAPI のバージョンやメンテ具合をよく見ておく 1 メンテ状況の把握 3 権限周り 2 SDK があるか GUI の操作でないと付与できないパターンも合ったりする Permission についてのページをじっくり見ていく (それに乗ってなかったら,ISSUE あげる) どうしても無いときは概要文を見てるとヒントがあるかも👀
ドキュメントを しっかり読む バリめんどい... サービスによって統一されてるものもあれば,同じサ ービスでもエンドポイントによって違う,みたいなの もある💦 4 Rate 制限の把握 実例
User ステータスの変動に合わせて,post 処理を投げたい しかしRate 制限は抱えているユーザー数,更新が発生す る数を秒間でも超えてくる ...無理やりステータス管理させて回避してる....
Rate 制限 Sidekiq で実装👀 Job Sidekiq.yml Sidekiq とsidekiq-limit_fetch gem で対応可能
https://github.com/deanpcmad/sidekiq-limit_fetch
Rate 制限 AWS で実装👀 SQS + Lambda で実現可能 しかし,Lambda にAPI
キーなどを渡す必要が出てくる Secret Manager が必要になりそう💦 実行命令をキュー (+対象のuser_idとか) Access Tokenを登録 処理に必要な機密情報 規定並列処理数を 維持しつつ実行
自分以外にも分かる人/ ドキュメントを作る 運用段階に入ってからでいいやではなく, 設計段階からAPI 仕様を把握しておく人を作る レビューもだが,リリース直後になにか問題が 発生した場合などの調査がつまらない/ 相談相手 がいるだけで精神的な安全を確保できる
まとめ API キーの管理やクライアントの定義など様々なことが複雑化する 複雑化したものをいかに整理できるかやドキュメントなどで補完でき るかが勝負の鍵 連携機能としてユーザー提供する際には設計相談は入念に行う 制限内で安定稼働させるためにはキューなどの仕組みを使い同時実行数を制御 SDK で対策してる( 数秒待ってからリトライ)
してる場合もあるから,要確認 Rate 制限には要注意 環境変数で設定して間に合うのであれば,それがベスト ユーザーごとなどで( 潜在的に) 無数のキーを管理するのであれば, DB 設計/ 暗号化のタイミングの検討を忘れてはいけない API キーやトークン管理基準を必ず最初にきめる UI 決めやDB の設計など多くの「判断」に影響を与える 不安であればチームで一度読み合わせするなどもいいかも👀 API 仕様はチームで共有(自戒
みんなで快適なOpen API ライフを!
None