APIとは
APIは「Application Programming Interface」の略で、簡単に言うと「ソフトウェアの機能を利用する際の決まりごと」です。世の中には様々なシステムがありますが、その機能がAPIとして共有されていればそのAPIを使うことで必要な機能を利用でき、無駄に開発することなく、より効率的にソフトウェア開発ができるようになります。
例えば、Google Mapsの機能もGoogle Maps API で利用できるようになっており、その位置情報を取得する機能(ジオコード)を利用する際にはAPIの場所をURLで指定し、利用するための鍵や場所を指定するためのキーワードを渡すのが決まりごとになっています。
APIという用語自体はコンピュータの世界では幅広い概念を表す用語ですが、インターネットとWebの普及により、最近ではAPIと言った時にはWebのAPIを表すことが多くなっています。上述のGoogle Maps APIもWeb APIとして公開されており、指定した場所の位置情報を結果として返す機能を提供しています。
例えば「恵比寿」という住所を指定して検索する場合は、以下のようなURLにリクエストを投げます。その際、APIの利用者を認証するために割り当てられた秘密の鍵を「key」というパラメータで渡し、「address」パラメータで「恵比寿」を指定し、さらに日本語を指定するために「language」というパラメータで「ja」を付けてGoogle Mapsのジオコード機能が利用されます。
https://maps.googleapis.com/maps/api/geocode/json?key=&address=恵比寿&language=ja
このリクエストの応答結果として、Web APIでは「JSON形式」というフォーマットで応答データが返ってくることが多く、そのレスポンス結果は以下のようなフォーマットで「恵比寿」に関する位置情報が返ってきます。APIをリクエストしたアプリケーションは、そのデータを処理して画面の表示などを行なっているわけです。
04 | "address_components": [ |
26 | "administrative_area_level_1", |
39 | "long_name": "150-0013", |
40 | "short_name": "150-0013", |
46 | "formatted_address": "日本、〒150-0013 東京都渋谷区恵比寿", |
62 | "location_type": "APPROXIMATE", |
74 | "place_id": "ChIJWRK3eBSLGGARCdO8OgKkE5w", |
APIを提供する企業は外部のアプリケーションからAPIの機能を利用できるようにしていますが、どのようなプログラミングで実装されているかまでは公開していませんし、APIを利用するアプリケーションもAPIがどのようなプログラミング言語で実装されているのかを意識する必要はありません。APIの決まりごとに従っていれば、アプリケーションは別のアプリケーションの機能を利用できるようになるのです。
GoogleやAmazon、Twitterのようなインターネット企業だけでなく、今では多くの企業がAPIを提供し始めています。APIを提供することで自社のサービスを利用してもらう機会が格段に広がり、さらにWeb APIを通じて多様なデベロッパーがAPIを利用した新規サービスを考えていくことで、自社だけでは考えつかないような新しいイノベーションが起こる可能性があるからです。
APIを利用することで、開発生産性を向上させることも可能です。APIとは何らかの機能を提供する仕組みであり、既にそのようなAPIが存在していれば同じ機能を一から開発する必要はありません。例えば、Uberは通信機能や課金の仕組みに他社のAPIを利用することで、より速く自社のサービスを展開できるようにしています。企業内のシステムでも、複数のシステムから共通して利用されるような機能があれば、それをAPIとして利用可能にすることで開発時間を短縮し、開発コストを削減してより速くアプリケーションをリリースすることもできるようになります。
また、Web APIで提供する機能を設計する際は「OpenAPI Specification (Swagger)」という仕様に基づいて記述することがデファクトスタンダードとなっています。これにより、インターフェース仕様をブラウザベースで管理でき、テストやコードの自動生成も行えるため、より効率的に開発を進めていくことができるようになります。
API管理とは
企業がアプリケーションを通じて何らかの機能を提供する上で、APIは必須要素になってきています。ただ、企業内には様々なシステムがあり、また各システムのAPIにも様々なユースケースがあります。多様なAPIを放置してしまうと企業のシステムはサイロ化が進み、必要なデータへすぐにアクセスできなくなるばかりではなく、企業にとって価値のあるデジタルデータを活用できなくなり、APIの本来の目的である再利用も実現できなくなってしまいます。APIをベースにアプリケーションが開発される機会は増えてはいますが、このような背景からもAPIを管理することの重要性がますます高まってきています。
では、そもそも「APIを管理する」とはどういうことでしょうか？ APIにはそれを提供する「APIプロバイダ」と利用する「APIコンシューマ」がいますが、API管理として求められる機能は、大きく以下の6つに分類できます。
- APIゲートウェイ
APIに対するリクエストを受け取り、セキュリティや流量制御などのポリシーのチェックを行い、APIの機能を実装したバックエンドシステムにリクエストを転送してレスポンスをクライアントに返す
- アクセス制御とセキュリティ
APIキーやOAuthやOpenID Connectなど、API利用における認証・認可の役割を担い、APIを安全に提供できるようにする
- API管理ポータル機能
APIの提供プランやポリシーの設定、本番用と検証用のAPIゲートウェイのデプロイ管理など、API公開に関する各種設定機能を提供する
- 分析とレポート機能
誰がどのAPIをどれくらい利用しているのかをモニタリングし、ダッシュボードで可視化する機能。API提供者はその情報を分析することで、APIの最適化が可能となる
- デベロッパーポータル
デベロッパーがAPIを利用するための仕様や使い方、チュートリアルなど、APIに関する情報を一元的に提供するポータルサイトのような仕組み。APIの利用申請などやAPI提供者とのやり取りを行う機能も提供する
- 課金と支払い管理
API提供者がAPIに関する課金ルール(登録料、定額制、従量課金など)を設定し、それに応じて請求書を発行する。API利用者がその料金を支払うことでAPIによるマネタイズが実現する
APIを管理する製品はこれらの機能を実装したソフトウェアで、図1のような仕組みになっています。
図1：API管理ソフトウェアの仕組み
APIの重要性が高まっている現在、APIの再利用性を高め、その利用状況を分析し、APIの継続的な改善を行っていくためにも、API提供者にとってAPI管理製品の導入は必須要素となりつつあります。
3scaleとは？
「3scale」はRed Hatが提供するAPI管理製品です。前述のAPI管理製品として必要な機能をカバーしており、さらに3scaleのコミュニティプロジェクトとしてすべてオープンソースとして公開されています。3scaleの最大の特徴は、機能ごとにモジュール化されているため、柔軟にデプロイメントできる点です。
表に3scaleを構成するモジュールを示します。
| 構成要素 |
説明 |
ソース |
APIcast
*英語では"アピキャスト"と発音 |
nginxをベースとした軽量でパフォーマンスとスケーラビリティに優れた3scaleのAPI Gateway。APIcastのポリシー機能はプラグイン形式となっており、APIcastの機能を柔軟に拡張することも可能 |
https://github.com/3scale/apicast |
| Porta |
3scaleの'System'と呼ばれるコンポーネントで、主に以下の機能を提供する- API提供者が利用する管理ポータル機能
3scaleの管理用API(Account ManagementとAnalyticsに関するAPI)API利用者向けのデベロッパーポータル- APIcastのデプロイに必要な設定情報
|
https://github.com/3scale/porta |
| Apisonator |
3scaleの’Backend’とも呼ばれるコンポーネントで、以下の構成要素が含まれる- Apisonator listener('3scale_backend')：APIリクエスト認証やレポートを行うための3scaleの管理用API(Service Management API)を提供
- Apisonator worker('3scale_backend_worker')：Apisonator listenerにキューイングされたジョブをバックグラウンドで実行(レポートの処理など)
- Apisonator failed jobs rescheduler('backend-cron')：Apisonator workerの処理に失敗したジョブをcronのスケジューラーで定期的に再処理する
|
https://github.com/3scale/apisonator |
| Pisoni |
Apisonatorのクライアントモジュール。3scaleのデータモデルの情報をApisonatorのデータストアにプッシュする |
https://github.com/3scale/pisoni |
| Zync |
3scaleのデータ(Application、Limit、Metric、Service)を他のシステムにプッシュしてデータを同期する機能を持つ。KeycloakのようなIdPと連携する際に使用される |
https://github.com/3scale/zync |
3scaleの構成モジュールの関係を図示すると図2のようになります。
図2：3scaleの構成要素
3scaleは当初から分散アーキテクチャで設計され、パフォーマンスとスケーラビリティに優れた製品です。API管理製品で全機能がすべてオープンソース化されている製品はあまりなく、今後オープンソースのコミュニティにおいても3scaleの価値が高まっていくことは間違いありません。
次回は、3scaleのオープンソース版を使用して、実際に環境を構築する手順を紹介します。
【コラム】3scale開発コミュニティの紹介
3scaleのGitHubコミュニティで公開しているリポジトリには、主要の4コンポーネントである、apicast、apisonator、porta、zync以外にも、例えばOpenShiftテンプレートを公開する3scale-amp-openshift-templatesや、3scaleの設定をコピーしたりインポートしたりできるツールを公開する3scale_toolboxなど多岐にわたり、その数は120に上ります(2018年11月現在)。
3scaleはまだOSS化されて日が浅いですが、コミュニティでの開発が進められており、不具合や欲しい機能があれば提案できます。筆者も流量制御機能やスコープベースのアクセス制御機能を提案し、取り込んでもらいました。本コラムでは、筆者の経験をもとに、3scaleコミュニティでの開発の進め方を紹介します。
3scaleコミュニティでは、GitHubのIssueをベースに開発が進められます。Issueの中で実現可否や取り込み要否、具体的な実装方法を議論します。実装方法がある程度固まった後、Pull requestを出し、3scaleコミッタのレビューを受けてマージされる流れです。例として、新機能を追加したい場合の大まかな流れを示します。
- GitHubのIssueチェック
既存のIssueと類似のIssueを立てるとIssueの管理が煩雑になるため、まずは既存のIssueに類似のIssueがないかを確認します。
- 3scaleのJIRAチェック
3scaleのJIRAも同様に確認しておきます。基本はGitHubのIssueで議論が交わされますが、JIRAのチケットで議論が交わされているものもあるため、JIRAも確認しておくことを推奨します。
- Issueの作成
類似のIssueが上がっていない場合はIssueを作成し、類似のIssueが上がっている場合はコメント等を追加して当該Issueを更新することで議論を開始します。JIRAで議論されているものに関しては、JIRAのチケットをリンクしてIssueを作成することでIssueの可読性が上がります。
- Issueでの議論
ユースケースベースで議論することが多いため、ユースケースをできるだけ具体的かつ正確に伝えることが大事です。このとき、ある程度実装方法が頭の中にイメージできていると、スムーズに具体的な実装方法の議論へと移行できます。
- Pull requestの作成
議論によって具体的な実装方法がある程度固まったら、コーディングしてPull requestを出します。細かい部分は置いて、とりあえずお試しでPull requestを出したい場合はタイトルの頭に“WIP”と付けましょう。まだ完成していないことがコミッタにもわかりますし、その認識の上でレビューしてくれます。議論から時間が経つと問題への熱が冷めてコミッタの反応が鈍くなることもあるので、できるだけ間を空けずにPull requestを出すことをお勧めします。リポジトリによってはPull requestを出すときに変更履歴やテストコードが求められるため、合わせて作成しましょう。
ちなみにAPIcastの場合はChange Logと単体テスト、統合テストを作成する必要があります。
- Pull requestのレビュー
Pull requestを出すとコミッタがレビューしてくれます。基本的に反応は早く、3日以内にレビューをしてくれることが多いです。レビューを重ねるごとにコードの追加・削除でコミットログが煩雑になってしまうことがありますが、3scaleコミュニティではコミットログをできるだけクリーンに保とうとしているので、そのような場合は最後にリベース等することを心がけてください。
- マージ
Pull requestがコミッタに承認されると、マージ可能な状態となります。現状マージは手動ですが、承認後すぐにマージされることが多いので心配無用です。コンフリクトが発生した場合は適宜修正しましょう。
コミットのためにチケットを切ったり、メーリングリストでやり取りしたりということがないので、比較的気軽にコミットできるという印象です。みなさんもぜひ本コラムを参考にコミットしてみてはいかがでしょうか。
