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
330
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
新卒から4年重ねて持ってる荷物をおろしたい
east_takumi
0
100
231207 主催をしたいまだからこそ言いたい!これからは「コミュニティ」だ!
east_takumi
0
25
230902 業務でAWS触らないけど自分がAWS認定試験の勉強する理由
east_takumi
0
110
20230722 Webエンジニアの Cloudflare Pagesハンズオン 挑戦記
east_takumi
0
56
20230723 Snyk みんな触ってみない?(圧
east_takumi
0
45
20230511 AWS-UG おおいたの今後を コミュニティの掛け算も含めて考えてみる
east_takumi
0
190
20230411 社内コミュニティを作るに向けてコミュニティマーケティングで整理してみた
east_takumi
0
470
20230225 「佐賀パターン」ってなに...?
east_takumi
0
99
20221120 九州からJAWS DAYS 2022を堪能して考えるこれから
east_takumi
0
76
Other Decks in Technology
See All in Technology
ServiceNow Knowledge Learning Rise up
manarobot
0
210
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
260
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
170
VSCodeの拡張機能を作っている話
ebarakazuhiro
1
650
AWS学習者向けにAzureの解説スライドを作成した話
handy
2
100
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
2.1k
アクセス制御にまつわる改善 / Improving access control
itkq
0
560
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
6
560
Google Cloud Next '24でブログを10本書いた方法と勉強会を沸かせた方法
yasumuusan
0
310
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
1
550
いいたいことちゃんという
tkengo
0
110
Azure犬駆動開発の記録/GlobalAzureFukuoka2024_20240420
nina01
1
230
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1356
200k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
116
18k
Imperfection Machines: The Place of Print at Facebook
scottboms
260
12k
Building Better People: How to give real-time feedback that sticks.
wjessup
355
18k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.6k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
2
3.4k
Code Review Best Practice
trishagee
55
15k
Ruby is Unlike a Banana
tanoku
96
10k
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