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
500
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
250201 マネコンの進化についていけないので、MFA設定くらいは自動化して追いつく作戦
east_takumi
1
70
241226 推しに嫌われないためにわたしたちはなにをすべきか vol.0
east_takumi
0
55
「楽しい」を優先できる コミュニティ運営を作っていく vol.0
east_takumi
0
20
241116 Momento CacheみたいなのをAWSだけでできないか考えてみた
east_takumi
0
17
241012 おらたちに力をわけてくれ!!JAWS FESTA 2023から1年、地方とコミュニティのこれからを語り合いたい!
east_takumi
0
190
241004_JAWSPANKRATION2024-オペレーションの振り返り
east_takumi
0
33
240803 Webエンジニアが_One_Observability_Workshop_から始めるO11y.pdf
east_takumi
0
39
240601 最近GAしたAI Gatewayってなんだ?
east_takumi
0
17
240516「のうさば」から紐解く サメの郷土料理のお話
east_takumi
0
98
Other Decks in Technology
See All in Technology
What's new in Go 1.24?
ciarana
1
110
手を動かしてレベルアップしよう!
maruto
0
210
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
190
IAMポリシーのAllow/Denyについて、改めて理解する
smt7174
2
210
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
640
スキルだけでは満たせない、 “組織全体に”なじむオンボーディング/Onboarding that fits “throughout the organization” and cannot be satisfied by skills alone
bitkey
0
170
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
290
DevinでAI AWSエンジニア製造計画 序章 〜CDKを添えて〜/devin-load-to-aws-engineer
tomoki10
0
120
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
290
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
2
640
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり
kzkmaeda
6
2.6k
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
320
Featured
See All Featured
The Cult of Friendly URLs
andyhume
78
6.2k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
4 Signs Your Business is Dying
shpigford
182
22k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Making Projects Easy
brettharned
116
6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The World Runs on Bad Software
bkeepers
PRO
67
11k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
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