マイクロソフトナレッジナゲッツ の別のエピソードへようこそ司会のミルコピータースです 今日のトピックはほとんどの人が聞いたことはあるものの実際 に理解している人は少ないAPIです この用語はよく耳にすると思いますこれは自分が何を話しているのか わかっているように見せたいときに人々が使う技術用語の一つです しかし実際にはAPIはシンプルです それはあるソフトウェアが別のソフトウェアと通信するための方法にすぎません スマートフォンがサーバーにデータを要求します サーバーはそれを返しますこれがAPIと呼ばれるものです ここで20個50個または100個のAPIがあると想像してみてください それぞれが異なる認証異なるレート制限ドキュメントある場合を使用 する可能性があります突然2つのアプリ間の単純な会話 から始まったものが完全な混乱に陥ります 中央管理者がいないため各チームが車輪を再発明します あるチームは独自の認証システムを構築し別のチームは独自のログ システムを構築しますセキュリティのギャップが至るところ に現れます 開発者はどのAPIが何をするのか混乱しシステム全体で実際 に何が起こっているのかを一元的に把握できません Azureアピマネジメントはこの問題を解決します 単一のコントロールセンターを提供します APIの航空完成等のような ものと考えてくださいこのエピソードの終わりまでに それが実際に何であるかなぜ重要なのか全ての要素がどのように 組み合わさるのかが理解できますコーヒーを用意して早速始めましょう 問題はAPIが多すぎて制御できないことです これが現代のソフトウェアの現実です 10年前はおそらく一つの大きなアプリケーションモノリス一つのデータベース 一つのAPIというシンプルな構成でした 今日では同じアプリケーションが数十のマイクロサービスに分割 されている可能性があります各サービスはユーザーアカウント 支払い在庫通知など一つの処理を行いそれぞれが独自のAPIを公開 します突然システムへのエントリポイント が1050100個もできてしまいますここでこれらのAPIを使用するもの を構築しようとしている開発者を想像してみてください それぞれを見つけそれぞれの認証方法を検討する必要があります APIキーを使用するものもあればオースを使用する ものもあり何も使用しないものもあります レート制限を手動で処理しないとブロックされるリスクがあります それぞれが期待するデータ形式を理解する必要があります これは疲れる作業です運用面から見るとさらに悪化します 中央ゲートウェイがないため各チームはセキュリティとログ記録を各自 のサービスに手動で追加する必要があります うまく行うチームもあればエラーのログ記録を忘れるチームもあります 入力の検証を全く行わないチームもあります 一貫性がなくエラーが発生しやすくセキュリティ上の悪夢が起こり かねませんコンプライアンスはほぼ不可能 になります誰がいつ何にアクセスしたかを 証明する必要がありますかそれぞれ独自のログ形式を持つ 20つの異なるサービスから監査証石を取得するのは大変です システムが先月処理したAPIコールの数を確認する必要があります か12つの異なるダッシュボードから メトリクスを繋ぎ合わせる必要があります 重要なのは規模が大きくなるにつれてこれは単に苦痛を与える だけでなく機能しなくなるということです 中央制御ポイント がなければ開発者サービス顧客を増やすことはできません 建物を想像してみてくださいすべての部屋に異なる鍵がかか っていると想像してください受付やディレクトリはありません 訪問者は正しいドアを探してさまよい歩きイライラして最終的に 諦めます完全な混乱です これがAPI管理が解決するように設計された問題です アジュールアピマネージメントとは何ですか コントロールタワーですではアジュールアピマネージメント とは正確には何ですか最も簡単な定義は次の通りです バックエンドAPIとそれを使用するアプリウェブサイトデバイスパートナー の間に位置するマネージドサービスです しかし重要なのは単なるプロ機種ではないということです プロ機種はトラフィックを転送するだけでそれ以上の機能はありません アジュールアピマネージメントはAPIのライフサイクル全体をカバー します 公開保護監視そして最終的には廃止します 完全なコントロールセンターです3つの主要なコンポーネントに分けて 説明しましょう1つ目はゲートウェイです これは正面玄関です アプリまたはウェブサイトからの受信リクエスト は全てバックエンドに直接ではなく最初にゲートウェイに到達します ゲートウェイはリクエストを処理し設定したポリシーを適用し メトリックを収集し適切なバックエンドサービスに転送します 交通整理係と考えてください次は管理プレーンです ここでは全てを定義しますAPIポリシー製品サブスクリプション などですアジュールポータルコマンドライン またはバイセップやテラフォームのようなインフラストラクチャーズ コードを使用してこれを行いますここは全てがどのように動作する かを構成するコントロールルームです 次に開発者ポータルがありますこれは社内外の開発者がAPIを発見 したりドキュメントを読んだりサブスクリプションキーを取得 したりブラウザでAPI呼び出しを直接テストしたりできるセルフ サービスウェブサイトですPDFをメールでやり取りする必要 はもうありませんわかりやすい例えがあります 現代の空港を想像してみてくださいゲートウェイは滑走路です 全ての飛行機は最初にそこに着陸します 管理機は完成塔です交通を誘導しルールを設定し全て を監視しますそして開発者ポータルは情報掲示板 ですパイロットは飛行前にこれを確認 し誰とも話さずに必要な全ての情報を見つけることができます ではゲートウェイにズームインしてみましょう ここはアプリが実際に通信する部分であり本当の魔法が起こる 場所ですゲートウェイはAPIの正面玄関です アプリが実際に通信するのはゲートウェイなのでゲートウェイ について説明しましょうモバイルアプリウェブサイト iot デバイスからの全てのリクエストはまずゲートウェイに到達しバック エンドに直接アクセスすることはありません これが重要な点ですゲートウェイは最前線に位置し 単一のエントリーポイントとして機能します ゲートウェイはリクエストを転送する前にポリシーを適用できます ポリシーとはレート制限 ipフィルタリングヘッダー書き換え 認証チェックなどxmlまたはjsonで記述するルールです これらは全てバックエンドのコードを一行も変更することなく 実現できます具体的な例を挙げましょう api に無料プランとプレミアムプランがあるとします ポリシーを使用すると無料ユーザーは1分あたり5リクエストに制限 しプレミアムユーザーは100リクエストまで許可できます バックエンドは違いを認識することはありません リクエストを処理するだけですゲートウェイがポリシーの適用 を処理しますゲートウェイはキャッシュも処理 します滅多に変更されない商品リストなど データが繰り返しリクエストされる場合ゲートウェイはレスポンス をキャッシュして直接提供できますバックエンドに一切手を加える 必要がないためレスポンスが早くなりサーバーへの負荷も軽減されます データ変換も可能ですバックエンドがxmlを返す場合でも モバイルアプリはjsonを期待しますゲートウェイはオンザフライで 変換できますバックエンドもアプリも変更する 必要はありませんゲートウェイが変換を処理します また全ての呼び出し全てのリクエスト全てのレスポンス全てのエラーをログに記録します誰がいつ何を呼び出し何が起こった かの完全な監査証跡が得られますこれだけでもコンプライアンスのために 導入する価値がありますグローバルなユーザー層がいる場合は ゲートウェイを複数のリージョンに展開できますトラフィックは自動的に最も近い リージョンにルーティングされるためレイテンシが低くなりエクスペリエンス が向上しますもう一つゲートウェイは実際のバックエンド urlを隠しますクライアントにはゲートウェイアドレス のみが表示されますバックエンドサーバーはインターネット から隠されたままですこれはすぐに使える大きなセキュリティ メリットですポリシー全てを制御するエンジンでは先ほど述べたポリシーについて はどうでしょうかポリシーはapimを真に強力にする エンジンですポリシーはバックエンドコードに 触れることなくリクエストまたはレスポンスの動作を変更しますapiのラッパーと考えてくださいトラフィックが流れるにつれて 自動的に追加削除または変更を行うことができますポリシーはリクエストのライフ サイクルの4つのポイントで実行できますインバウンドリクエストがバックエンド に到達する前アウトバウンドレスポンスがクライアント に到達する前バックエンドリクエストがサービス に到達する直前およびエラー何かが失敗したとき一般的なインバウンドには呼び出し 元のIDを確認するためのjwtトークンの検証apiキーの確認urlの書き換えipアドレスによる制限などがありますこれらはすべてバックエンドが単一 のリクエストを見る前に実行されますアウトバウンドではレスポンス ボディを変換できますテキストの検索と置換機密フィールド の削除フォーマットの変更などが可能ですレスポンスをキャッシュして同じ リクエストがバックエンドに到達しないようにすることもできます内部情報が漏えいするヘッダー を削除することもできます具体的な例を挙げましょうapiがあらゆる場所に青という単語 を含む製品説明を返すとしますブランド名を変更して黄色に置き換え たいとしますバックエンドのコードを変更する代わり にアウトバウンドポリシーを一つ追加します青を検索し黄色に置き換えますこれで完了ですバックエンドは変更されませんレート制限とクォータポリシー はバックエンドを不正利用から保護します誰かのアプリが暴走して1秒間 に1万回apiに攻撃を仕掛け始めた場合ポリシーが介入して速度を 落としてくださいと指示しますバックエンドは健全な状態を維持 します高度なロジックが必要ですかポリシー内にカスタムcシャープ式 を記述できますこれらはパフォーマンスのためにコンパイル されますそのため実行時のコストは発生 しませんユーザーロールを検索したり動的な レート制限を計算したりリクエストヘッダーに基づいて条件付きで レスポンスを変換したりできます重要なポイントはポリシーを使用 するとapiを実行するコードに触れることなくapiの動作を制御できる ということですつまり変更が早くなりデプロイ が減りリスクが軽減されます製品とサブスクリプション消費者 向けのapiのパッケージ化これでapiが定義されポリシー が設定されゲートウェイが順調に動作していますしかし異なる顧客に異なるもの へのアクセスをどのように提供するのでしょうかそこで製品とサブスクリプション が登場しますapimではapiを製品と呼ばれるもの にグループ化しますバンドルと考えてください基本的なapiのみを含む無料ティア 製品を用意することができます読み取り専用アクセスのみの場合 もあり書き込み操作や管理エンドポイントを含む全ての機能を含む プレミアム製品を用意することもできます開発者は個々のapiを購読する のではなく製品を購読します公読すると公読キーが発行され ます実際には2つのキーが発行される ためダウンタイムなしで1つをローテーションできますこのキーはその製品内の任意 のapiを使用するためのパスです公読の仕組みはあなたが制御 できます製品は承認を必要とする場合があります公読者を手動で承認することも セルフサービスで公開することもできます誰でもサインアップしてすぐに アクセスできます公読前にユーザーが同意しなければ ならない法的条件を含めることもできますapiが機密データを扱う場合は これは重要ですこれがapiを収益化する方法です低レート制限の無料製品1分あたり5回呼び出しより高い制限またはより多くの エンドポイント1分あたり100回の呼び出しさらにプレミアム機能へのアクセスバックエンドは気にしませんゲートウェイは呼び出し元が 公読した製品に基づいて制限を適用します実際の例を以下に示しますカンファレンスアプリを構築している と想像してくださいセッションスケジュールスピーカーの略歴会場マップのapiを備えた参加者 向け製品を作成します次にリード生成apiも含むスポンサー 向け製品を作成しますスポンサーは参加者のバッジをスキャン して連絡先情報を取得できます同じバックエンド異なる製品異なる アクセスレベルこれら2つのサブスクリプション キーはローテーション用に設計されていますキーが侵害された場合は新しい キーを生成します2番目のキーを使用するとサービス を中断することなく切り替えることができます新しいキーを生成しアプリを 更新し古いキーを取り消しますシームレスです開発者ポータルapi利用者のための セルフサービスapi製品を設定しました次に開発者がそれらを見つける 必要がありますそれが開発者ポータルの役割です開発者ポータルは全てのapmインスタンス に組み込まれたウェブサイトです開発者はこれを使用してapiを参照 しドキュメントを読みエンドポイントをブラウザで直接インタラクティブ にテストしますセットアップは不要でメールのやり取り もありませんただしデフォルトでは公開されて いませんapmインスタンスを最初に作成する とポータルは存在しますが誰もそれを見ることができませんまずカスタマイズして公開する 必要がありますこれは意図的なものです未完成のポータルを世間に公開 したくはないでしょうブランドカラーやロゴをカスタマイズ したりapiドキュメントと一緒にブログ用のワードプレスコンテンツ を埋め込んだりすることもできます会社の外観や雰囲気に合わせて 完全にカスタマイズ可能です真の価値はセルフサービスです開発者はサインアップすると サブスクリプションキーが自動的に取得されすぐにapiの呼び出しを 開始できます手動でのメール送信も承認待ち もキーの取得方法を尋ねるサポートチケットもありません開発者自身が行うためサポート の負担が大幅に軽減されます変更ログやリリースノートも公開 できますapiを更新すると開発者はポータル で予期せぬ事態なく確認できますurlを知っている人なら誰でもアクセス できるように公開することもentra idテナントのユーザーのみ に制限して組織内のユーザーのみが閲覧できるようにすることも できますどちらのオプションも様々なユース ケースに対応しています開発者ポータルはapi管理を真の プラットフォームにするものですapiの転倒と考えてくださいこれがないと開発者はドキュメント を検索したり周囲に尋ねたりする必要がありますこれにより必要なものを見つけて 構築を開始できますセキュリティー認証認可シークレットセキュリティーがしっかりして いなければこのすべての機能は役に立ちませんそこでapimがidアクセスシークレット をどのように処理するかについて説明しましょうapimは複数の認証方法をサポート しています最もシンプルなのは先ほど説明 したサブスクリプションキーですしかし本番システムではオース 2ゼロjwtトークンクライアント証明書ipフィルタリングなどより 強力なものが必要になりますapiの機密性に応じてこれらをレイヤー 化します本番環境ではentra idでオース 2例を使用するのがベストプラクティスですその仕組みは次の通りですクライアントアプリはentra idから トークンを取得しapiリクエストと共に送信しますapimは署名発行者対象者有効期限 をチェックしてトークンを検証しますトークンが有効な場合apimはトークン を含めてリクエストをバックエンドに転送しますバックエンドはapimがすでに検証 済みであるためそれを信頼し再検証する必要はありません各サービスが処理しなければならない ことが一つ減りますさて秘密情報について話しましょうapiキー接続文字列証明書など はポリシーファイルやソース管理にハードコーディングしたくありませんapimには名前付き値という機能 があります秘密情報はapimに一元的に保存 しポリシー内で名前で参照します実際の値はポリシーコードには 表示されませんさらに良いことに名前付き値を azure keyfaultに接続できます秘密情報はkeyfaultに暗号化された 状態で保存されapimは実行時にそれらを取得しますDevOpsチームを含め誰も実際の秘密 値を見ることはできませんキーをローテーションする必要 がある場合はkeyfaultで更新するとapimが自動的に変更を検出しますapimはマネージドidもサポート していますこれによりapimは資格情報をどこにも 保存することなくkeyfaultやバックエンドapiなどの他のazureサービスに認証 できますazureがidを管理するため権限を付与 するだけで済みますまたネットワーク分離のためにapim を仮想ネットワーク内にデプロイできますこれがプレミアムティアですつまりazureフロントのポイント はバックエンドサービスをインターネットに直接公開する必要がないということ ですapimは外部から見える唯一のものですこの階層的なアプローチにより 多層防御が構築されますゲートウェイでの認証金庫内の シークレットバックエンド周辺のネットワーク分離各レイヤーが 次のレイヤーを強化します価格ティアどれがあなたに合っていますか では費用はいくらですかティアを見ていきましょう消費ティア固定月額料金なしでapi コールごとに支払いますプロトタイプ作成時など少量または バースト的なワークロードに最適ですまだ必要なものがわからない 場合はここから始めてください開発者ティアでは約50ドルの固定 月額料金が提供されますフル機能セットですがslaはありません 開発およびテスト環境に最適ですプレミアムのすべての機能を使用 できますが本番環境では使用できません基本ティアはエントリーレベル の本番環境ですスループットは低く仮想ネットワーク のサポートはありませんが実際のslaが提供されますプライベートネットワークが重要ではない 内部ツールや小規模プロジェクトに適していますほとんどの企業は標準ティア に落ち着きます仮想ネットワークのサポート 99.95%slaおよび優れたスループットが含まれますビジネス上重要なapiを実行している 場合はおそらくここに落ち着くでしょうプレミアムティアは最大限の信頼 性とプライベートネットワークを必要とするグローバル企業向け ですマルチリージョン展開セルフホストゲートウェイ 99.99%sla完全な仮想ネットワークインジェクションユニットあたり月額約2700からマイクロソフトはv2ティア ベーシックv2スタンダードv2プレミアムv2も導入しました含まれているリクエストクォーター と100万ごとの超過料金で価格設定を簡素化します複数のメーターを追跡する代わり にリクエストの明確なバケットを取得し追加使用料に対して単純 な増分で支払います選択方法は次の通りですテストには開発者から始めます本番環境ではスタンダードに移行 しますグローバルスケールまたはプライベート ネットワークが必要な場合はプレミアムを選択しますまたティアは後でいつでも移行 できることを覚えておいてください小規模から始めてニーズの変化 に応じて拡張しますAPI管理は多数のAPIが混沌としている 状況をゲートウェイポリシーセキュリティ開発者エクスペリエンス のための単一のコントロールセンターに集約します重要なのは単なるプロキシ以上 の存在であるということですAPIエコシステムの脳と神経系 のようなものだと考えてくださいAPI管理がなければ各チームが独自の認証 ログ記録レート制限を構築することになります結果として一貫性の欠如セキュリティ 上の脆弱性そして何が起こっているのかを一元的に把握できないという 事態に陥りますAPI管理を導入すればサービスごとに 車輪を再発明することなく一貫性セキュリティスケーラビリティ を実現できます簡単な演習をしてみましょう現在直接公開しているAPIを一つ 考えてみてください関数エンドポイントやアプリサービス などですAPI管理を全面に配置することでセキュリティ 体制や使用状況の監視能力はどのように変化するでしょうかこの演習をじっくり考えるだけ でもその価値がわかるでしょう次のステップはチャンネル登録 です今後のエピソードではAPIのインポート 方法最初のポリシーの適用方法リアルタイムでの使用状況の監視 方法をご紹介します理論から実践へとステップアップ できますこの情報が役に立った場合はアプリ 開発に携わっている方と共有してくださいこれで彼らは何ヶ月もの悩み を解消できるでしょう聞いてくれてありがとう