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
480
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
241226 推しに嫌われないためにわたしたちはなにをすべきか vol.0
east_takumi
0
40
「楽しい」を優先できる コミュニティ運営を作っていく vol.0
east_takumi
0
14
241116 Momento CacheみたいなのをAWSだけでできないか考えてみた
east_takumi
0
12
241012 おらたちに力をわけてくれ!!JAWS FESTA 2023から1年、地方とコミュニティのこれからを語り合いたい!
east_takumi
0
170
241004_JAWSPANKRATION2024-オペレーションの振り返り
east_takumi
0
27
240803 Webエンジニアが_One_Observability_Workshop_から始めるO11y.pdf
east_takumi
0
34
240601 最近GAしたAI Gatewayってなんだ?
east_takumi
0
13
240516「のうさば」から紐解く サメの郷土料理のお話
east_takumi
0
85
240423 CloudFrontのOACが Lambda Functions URLに対応!! ...って何が嬉しいの?
east_takumi
0
41
Other Decks in Technology
See All in Technology
Oracle Exadata Database Service(Dedicated Infrastructure):サービス概要のご紹介
oracle4engineer
PRO
0
12k
チームが毎日小さな変化と適応を続けたら1年間でスケール可能なアジャイルチームができた話 / Building a Scalable Agile Team
kakehashi
2
220
#TRG24 / David Cuartielles / Post Open Source
tarugoconf
0
560
[IBM TechXchange Dojo]Watson Discoveryとwatsonx.aiでRAGを実現!事例のご紹介+座学②
siyuanzh09
0
110
【NGK2025S】動物園(PINTO_model_zoo)に遊びに行こう
kazuhitotakahashi
0
210
完全自律型AIエージェントとAgentic Workflow〜ワークフロー構築という現実解
pharma_x_tech
0
330
SpiderPlus & Co. エンジニア向け会社紹介資料
spiderplus_cb
0
860
2025年のARグラスの潮流
kotauchisunsun
0
790
デジタルアイデンティティ技術 認可・ID連携・認証 応用 / 20250114-OIDF-J-EduWG-TechSWG
oidfj
2
590
Cloudflareで実現する AIエージェント ワークフロー基盤
kmd09
0
280
【JAWS-UG大阪 reInvent reCap LT大会 サンバが始まったら強制終了】“1分”で初めてのソロ参戦reInventを数字で振り返りながら反省する
ttelltte
0
130
ABWGのRe:Cap!
hm5ug
1
120
Featured
See All Featured
RailsConf 2023
tenderlove
29
970
Rebuilding a faster, lazier Slack
samanthasiow
79
8.8k
Typedesign – Prime Four
hannesfritz
40
2.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.5k
Bash Introduction
62gerente
610
210k
Making Projects Easy
brettharned
116
6k
The World Runs on Bad Software
bkeepers
PRO
66
11k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7.1k
Scaling GitHub
holman
459
140k
Code Review Best Practice
trishagee
65
17k
Designing Experiences People Love
moore
139
23k
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