こんにちは。
今回は、API Management について。
ぶっちゃけちゃうと、前職ですぐそばに、API Management のスペシャリストの上坂さんがいたので、自分で勉強しないでもいいかな〜ってサボってたんですよねw
でも、時間が経って自分でも勉強しないといけない時が来てしまいましたw
ということで、API Management の勉強を始めたので、忘備録を残しておこうとおもいます。
ちなみに、上坂さんの極上スライドのリンクもここに貼って置こっと♪
Azure Api Management 俺的マニュアル 2020年3月版 (slideshare.net)
API Management とは
API Management をざっくり言っちゃうと、組織で管理する API のゲートウェイの機能を持つ PaaS サービスです。
API Management の主な機能を、次の章で簡単にまとめてみました。
API Management の主な機能
API Management は、主に、「Gateway」、「管理インターフェース」、「開発者ポータル」の 3 つの機能があります。
Gateway
まずは、Gateway の機能について、ドキュメントより拾ってくると、このような機能が記載されています。
“Azure API Management ゲートウェイ” は、すべての API からのすべての呼び出しを受け入れる
Azure エンドポイントです。 ゲートウェイには次の機能があります。
- API のサブスクリプション キーと他の資格情報を検証します。
- 使用量クォータとレート制限を適用します。
- バックエンドとの互換性のために必要に応じて API を変換します。
- 各呼び出しを適切なバックエンド サーバーにルーティングします。
- バックエンドの応答をキャッシュします。
- 分析ワークロード用に呼び出しメタデータを収集します。
ドキュメントの内容を整理すると、Gateway は、コンシューマー(API の接続元のアプリで、モバイルアプリとか Web アプリとか IoT デバイスとか)にエンドポイントを提供する機能です。
このエンドポイントで、API 自体に変更を入れずに、視覚情報の検証とかスロットリングを行い API をセキュアに利用いただけるようにしたり、応答する際に不要な情報(応答header に技術スタックがわかってしまうような場合に、その情報を削除した形で応答するなど、既存の公開できないような API も Gateway の機能を使うことで、公開できるモダンな状態に持っていくような機能を持っています。
管理インターフェース
“Azure API Management 管理インターフェイス” は、お使いのサービスと API を管理できる一連の Azure portal ページおよびツールです。 サービスのプロビジョニング、スケーリング、監視に加えて、次の場合は管理インターフェイスを使用します。
- API 仕様の定義またはインポート
- クォータやレート制限などの使用ポリシーの実装
- セキュリティ ポリシーの設定
- ユーザーの管理
- API の製品へのパッケージ化
- API の変換の定義
- API のリビジョンとバージョンの管理
- API メタデータに対する分析の実行
ドキュメントの内容を整理すると、管理インターフェースは、Gateway で提供する機能を管理 / 設定 / 構築を行う機能と、Gateway で提供する API の変更に伴う Gateway 側の変更管理、あとは開発者ポータルを利用するための管理と言った、管理機能っすね。
開発者ポータル
“Azure API Management 開発者ポータル” は、開発者が次の方法で API を対話操作でき、完全にカスタマイズできる Web サイトです。
- 各 API のドキュメントの確認。
- 対話型コンソールを使用した API の試用。
- さまざまなプログラミング言語でのコード サンプルの確認。
- API のサブスクライブと、API サブスクリプション キーの取得。
- 開発者の使用状況に対する分析の実行。
ドキュメントを見ると、開発者ポータルは、API をコールするためのコンシューマ向けに API の情報提供を行うポータルです。
機能についての軽いまとめ
と言うことで、機能的には、API Management で API を公開するときに必要な機能として、API の利用者向けの機能と、API の提供者向けの機能の両方を兼ね備えたサービスになります。
個人的には、公開できるような API になっていなくても、API Management でラッピングすることで公開できる API になってくるもはめっちゃいいと思いますし、API Management 自体を仮想ネットワーク内に閉じ込めることもできるので、社内の内部的な部分での API の入り口としてガバナンスを聴かせていくと言うのも一つの方法だと思います。
API Management の料金
ただネックとなるのは料金です。
統合的な機能を持っているサービスなので、1 つのシステムだけで使う場合、高いと感じる人が多いんです。
でも、API Management の機能を使うことで、より多くのコストを抑えられるシーンがあると思うので、トータルで見るとすごくコストメリットが出てくるサービスだと思います。
特に、オンプレのレガシーシステムをモダン化をして DX に取り組みたいと考えている方には大きな手助けになるんじゃないかな〜？
また、PoC などで使える SLA なしの料金が安い Developer や、使用量によって料金が変わる コンサンプションモデルも出てきているので、試しやすくはなってきていると思います。
API Management を使用する判断ポイント
MS Learn の 「Azure API Management の概要」 の中に、「どのようなときに Azure API Management を使用するか」というページがあります。
その中に、意思決定の基準という記載があります。
API Management を使う際に、1 システムの中で使うためには、金額的には少し高いのは事実だと思います。なので、API の数が増えてこないと、コストメリットが低いのは事実だと思います。
でも、コンサンプションモデルも結構安いんじゃないかなーって思うけど、これはちょっとわからないので、API 開発している人のご意見をいただけるとありがたいですね。
後の、API の変更率とか API の管理の負荷というのは、書いてある通りだと思うので、API GW としての機能というよりも、管理機能っていうところも含めて、考えてみるとメリットは出てくるように思います。
まとめ
API Management 高いから使わないって、すごく勿体無いような気がするんですよね。
もし、既存資産で API を持っている方々は、API Management を使ってラップしてあげることで、まだしばらく使うこともできると思うんですよね。そういう人がいるかはわからないで書いてますがw
あと、なんとなく最近ずっと、フュージョン開発みたいに、市民開発者とプロ開発者をわけてプロ開発者の開発範囲を狭めて市民開発者とわけていくのって、もっと進まないといけないよなーとか、ぼんやりと思う時がありまして、そうなってくると、「プロ開発者の人たちは API 開発に進んで行って、市民開発者の人は、Power Apps からカスタムコネクタを使って、API を実行する」みたいなことがもっと進むんじゃないかなってなんとなく思うんです。
そうなってくると、API を管理するのが欲しくなって、結果、API Management に行き着くんじゃないかなーって気がするんですよね。(ほんとかどうかは知らんけど)
逆に、そうならないところって、今と同じ IT の生産力をどうやって確保するんだろうって思っちゃうんですよね。
ということで、API Management 触ったことない方は是非触ってみましょう♪
って、今さら触り始めた僕がいうことではないかw
コメント