APIを使う際の注意点
はじめに
- 普段の業務では Azure を使っています
- 主に API Management + α
- つまり API を 提供する人/利用する人 全体を通して管理しています・・・
- が、クラウドの機能を利用している以上、
クラウドサービスが提供する API の いち利用者 でもあります - 今回は API利用者 として気づきを少しまとめてみます。
クラウドサービスが提供するAPIとは
- AWS/Azureなどのクラウド内の リソースを管理/操作するためのAPI です
- 例: VMを作成する、起動/停止させる、リソースの一覧や状態を取得する・・・etc
- ここでは クラウドAPI と記載します
クラウドAPIを扱う上で必要なモノ
アカウント
- クラウドを操作するアカウントです
- Azure では
Azure Active Directoryアプリ
,サービスプリンシパル
などと呼ばれています
- Azure では
- クラウドによってお作法は異なると思いますが、基本的には一般的なユーザアカウントと同様に権限管理ができます
キー(シークレット)
- アカウントに紐付いた キー(シークレット) がなければ操作できません
- キーの発行はいくらでも可能
- 任意のタイミングで破棄ができる
- 失効期限が設定可能
- ・・・といった機能が備わっていることが多いです
クラウドAPIを使う
前提
- 使い方としてシンプルな、バッチアプリ や デーモンアプリといったアプリからの利用を想定します
限られた人間しかアクセスできないセキュアな実行環境で、
不特定多数からアクセス・実行されることがない・・・という想定です - Webアプリ、モバイルアプリなど、パブリッククライアントから利用される場合は、
認証フロー や キー管理 などが絡み、複雑となるため、今回は割愛します
流れ
- アプリを実行
- 認証用のエンドポイント へアクセス
- アカウント情報(アカウント/キー)で認証し、アクセストークンを得る(期限付き)
- 今度は 操作用のエンドポイント へアクセスし、API経由でクラウドを操作する
- アクセス時には 3. で取得したアクセストークンを使用する
- アプリを終了
認証用のエンドポイント
- 認証を行うためのエンドポイント(操作用のエンドポイントとは別に専用に用意されていることも)
- Azure例: https://login.microsoftonline.com など
操作用のエンドポイント
- クラウドを操作するためのエンドポイント
- Azure例: https://management.azure.com など
クラウドAPIを使う際の注意
- 権限を適切に設定する
- リクエストは失敗する前提で実装する
- 複数のエンドポイントを抑えておく
- リトライをする
権限を適切に設定する
- ある程度の規模の組織でお仕事をしていれば当たり前の話・・・ではありますが
- 一般的なユーザ管理の前提に従い、適切な権限を割り振ります
- 不必要にアカウントに対し 強く、広い権限を与えない
- 特にアプリからの利用だと、実装次第では何でもできてしまうので…
- できて良い操作、できたらダメな操作を明確化し、必ずテストする
- リソースを区分する
リソースグループ
など、分かりやすい単位で事故が起きないよう工夫する
リクエストは失敗する前提で実装する
複数のエンドポイントを抑えておく
- クラウド自体がもし 複数のエンドポイント を提供していれば、すべて抑えておく
- 認証用のエンドポイント、操作用のエンドポイント、両方ともあればチェックしておく
- どのエンドポイントで操作しても同じ結果になることもテストする
とある実例
- とあるアプリ:1つのエンドポイントでのみ認証をする
- ある日、アプリの認証に失敗し、数時間経たないと再度認証成功しない という事象が発生
(俗に言う 一時的な 垢バン のような状態?) - しかしクラウドサービス(Azure)サポート窓口曰く、リクエスト自体が到達していないため、
おそらく途中の 社内ネットワーク経路のどこかでエラーや制限 に引っかかっていそう・・・? - ただ社内NWは厳重に管理されており、プロキシやゲートウェイなど いくつもの事業所を経由し
インターネット上のクラウドサービスへと辿り着くため、
どこで問題が起きているのか 特定しづらい
解決への糸口
- 試しに 垢バン(?)中に 別の認証エンドポイント を試行したところ、認証成功した
- 時間をかけて丁寧にネットワーク調査をするのが恒久対応としては理想だが、現実的に難しい場合も
対策
- 以下の3つの認証エンドポイントを順に試し、NGなら次… と認証を行うようにした
- https://login.microsoft.com
- https://login.microsoftonline.com
- https://login.windows.net
- 加えて 後述 の リトライ対応 を施した
リトライをする
- 基本的に何回も実行しても影響が少ない 認証(トークン取得)や
GET
系のリクエストであればリトライをする POST
/PUT
/DELETE
のリトライは、状況に応じて行うこと- 例えばリトライ処理自体のミスにより 無駄なリソースが大量に生成されたり…
といった事故が起きないことは、必ずテストする
- 例えばリトライ処理自体のミスにより 無駄なリソースが大量に生成されたり…
- Azure では なんと再試行のベストプラクティスについても論じ、ドキュメントとして事細かに記載があります
- 一時的な障害の処理
- 再試行する際のインターバルの取り方にすら方針を細かく分類しているのにはびっくりしました。。。
- 一時的な障害の処理
実例
- クラウドサービス上から、大量の情報を取得(GET)する必要があった
- ただしクラウドサービスに負荷をかけないよう、一定時間を空けつつ、リクエストを送る
- そのため、処理完了に毎回 5分程度 かかる
- 初期はリトライ対応していなかった
- つまり どれか一つのリクエストがたった1回失敗しただけで最初からやり直すことに…
- 実際に運用していて結構ツラい… ので、あらかじめリトライ処理は入れておいた方が良いです。。
まとめ
- クラウドAPIを使う場合の注意点などをまとめました
- クラウドAPI… と書いていますが、
一般的なAPIでも同様のテクニックは検討してみても良いかもしれません
- クラウドAPI… と書いていますが、
- エンドポイントが複数あると安心
- どのエンドポイントでも同じ結果になることは要チェック
- リトライだいじ
- 複数エンドポイントとの組み合わせでより安定した仕組みにできます