初版: 2018/7/10

著者: 田畑義之, 株式会社日立製作所 (GitHubアカウント: @y-tabata)

本記事は、あくまで執筆者の見解であり、所属企業及びRed Hatの公式なドキュメントではありません。

昨今API管理の分野が注目を集めています。筆者は、API管理製品の一つ、3scaleに着目し、検証やパッチ投稿を進めていました。最近2.2がリリースされ、大きく機能強化されて面白くなってきたため、紹介します。

はじめに

2018年5月31日、Red Hat 3scale API Management Platform (以下、3scale)のバージョン2.2がリリースされました。2017年10月27日の2.1のリリースから約7か月ぶりの新バージョンです。

本稿では、3scale 2.2の新機能を紹介します。

3scaleとは

3scaleとは、Red Hatが開発するAPI管理製品です。

3scaleは、APIの認可認証分析、流量制御、管理者ポータル、開発者ポータル、Swaggerエディタ、CMS、収益化など、APIゲートウェイに求められる基本的な機能を一通り備えています。

また、Kubernetesのエンタープライズ版であるOpenShift上で動くため、下記の特徴を持ちます。

• 用途に合わせて柔軟にデプロイやスケールができる
• 障害時の影響範囲を局所化できる
• 障害から自動で復旧できる

さらに、認可認証に関しても、昨今注目のOSSであるKeycloakと連携することで、OpenID Connectに対応することができます。

3scaleは、APIcast、System、Backend、Zyncの4つのコンポーネントから成り、そのうちSystem以外の3つのコンポーネントはオープンソース化されています。Systemも近いうちにオープンソース化される見込みです。

2018年6月25日時点では、完全なOSS化はまだなものの、Red Hat社のContainer Catalogにて3scaleのコンテナイメージが公開されているため、コミュニティ版のOpenShiftであるOpenshift Origin上でも、自己責任・無保証で3scaleを使うことができます。サポートが必要な場合は、Red Hat社よりサブスクリプションの購入が必要です。

また、コミュニティが活発なため、良い機能であると判断されれば、自分のコードを入れ込むことができます。 このように自分のコードが受け入れられるところも3scaleの魅力の一つです。

2.2の新機能

2.2の新機能を紹介します。

2.2の新機能の中でも、目玉の機能は下記2つです。

• マルチテナント
• ポリシー

本稿では上記2つの機能を紹介します。

他の新機能の詳細はリリースノートをご参照ください。

マルチテナント

マルチテナントとは、その名の通り、1つの3scaleを複数のAPI管理者が共同で利用するための機能です。このとき、もちろん1テナントのAPI管理者は、他のテナントのリソースを参照することはできません。 マルチテナントは、下記ユースケースで有効です。

• 複数企業に対し、API管理サービスを提供する
  マルチテナント機能がない場合、企業ごとに3scaleインスタンスを立ててサービスを提供する必要がありますが、マルチテナント機能を用いると、1つの3scaleで複数企業に対してサービスを提供することができます。
  これにより、マシンリソースの削減および管理負荷の軽減を実現できます。

2.1までの課題

3scaleには、2.1以前、もともとAdminユーザとMemberユーザの2種類のユーザがいました。

• Adminユーザ: すべてのリソースにアクセスできる
• Memberユーザ: Adminユーザの補佐役という立ち位置で、Adminユーザから割り当てられたリソースにのみアクセスできる

2.1以前も、Memberユーザに対して異なるリソースを割り当てることで、アクセス可能なリソースを制限することはできましたが、開発者ポータルやダッシュボードなど、一部アクセス制限できない機能も存在し、マルチテナント機能としては不完全でした。

2.2では

2.2では、新たにMaster Adminユーザというユーザが追加されました。

• Master Adminユーザ: テナントを管理する

Master Adminユーザの追加に伴い、マスター管理者ポータルが追加され、Master Adminユーザは当該ポータルを用いて、テナントを管理します。マスター管理者ポータルの見た目は、管理者ポータルと似ていますが、下図のように、左上にMasterと表示されます。Adminユーザによる管理者ポータルの見え方は2.1以前と変わりませんが、他テナントのリソースを参照することはできません。

OpenShift上では、マスター管理者ポータル用のコンテナが1つ増えました。

マスター管理者ポータルを用いて、テナントを追加してみます。

テナントが追加されました。

しかし、このままでは管理者ポータルにはアクセスできません。

OpenShiftで、system-providerサービスのRouteを追加します。

管理者ポータルにアクセスすることができました。

ポリシー

ポリシーとは、3scaleのAPI GatewayであるAPIcastに、任意の機能を実装するためのプラグインです。 本機能により、APICastにポリシーを追加することで機能拡張できるようになり、APIcastの拡張性が格段に向上しただけではなく、強力なポリシーの開発によって、APIcast自体の機能も強化されています。

ポリシーは、ポリシーチェーンという形で順序付けして定義します。

下図の例では、流量制御ポリシー、トークンイントロスペクションポリシー、APIcastポリシーの順番でポリシーチェーンに定義しています。APIのアクセス制御等を行うAPIcast自身の機能もAPIcastポリシーとして定義されています。各ポリシーは、特定のNGINXのフェーズごとに処理を実装しています。例えばAPIcastポリシーは、リライトフェーズ、アクセスフェーズ、ポストアクションフェーズに処理を実装しています。各ポリシーは、NGINXのフェーズごとに、ポリシーチェーンで定義した順番で処理を実行します。

2.1までの課題

実は2.1でも、ポリシー機能はテックプレビュー(Red Hat社により正式にサポートされない機能)で存在しました。しかし、下記のような構築・運用上の課題がありました。

• ポリシー定義時およびポリシーのプロパティ変更時は、イメージの作成およびAPIcastの再デプロイが必要なため、APIcastが瞬断される。
• ポリシーを利用する場合、管理者ポータルを用いたサービス(API)の設定変更は反映されなくなる。設定変更を反映する場合は上記同様、イメージの作成およびAPIcastの再デプロイが必要である。

2.2では

2.2では、テックプレビューが取れ、正式サポート機能になり、上記のような構築・運用上の課題もなくなりました。さらに、管理者ポータルのIntegrationビューで、ポリシーを設定できるようになりました。

上図のように、現在、下記ポリシーがデフォルトで選択可能です。

• トークンイントロスペクションポリシー (テックプレビュー)
  APIリクエストに付与されたアクセストークンの有効期限をチェックするポリシー。
• アップストリームポリシー
  APIリクエストを正規表現でパースし、マッチした場合、指定したURLをコールするポリシー。一つのサービス(API)による複数バックエンドを実現できる。
• 流量制御ポリシー (テックプレビュー)
  APIリクエストの流量制御を実現するポリシー。
• URL書き換えポリシー
  APIリクエストのパスを正規表現で置換し変更するポリシー。アップストリームポリシーとの違いは、URLのホストを変更できないことと、正規表現を使ってURLを置換すること。
• エコーポリシー
  APIリクエストの内容をそのままボディに出力してレスポンスするポリシー。
• SOAPポリシー
  APIリクエストのSOAPActionまたはContent-Typeヘッダを用いて、独自のマッピングルールを設定するポリシー。
• ヘッダポリシー
  APIリクエストおよびレスポンスのヘッダを変更するポリシー。
• CORSポリシー
  APIcastへのCORSリクエストを可能にするポリシー。
• キャッシュポリシー
  APIリクエストの認可認証結果をキャッシュすることで、スループットの向上およびBackendコンポーネント停止時の縮退運転を実現するポリシー。

また、2.2では独自のポリシーを導入することもできます。独自のポリシーをRed Hat社公式手順に沿って導入すると、管理者ポータルのIntegrationビューで独自のポリシーを選択できるようになります。

ポリシーをGUIで設定できるようになったことにより、APIcastを手軽にカスタマイズできるようになりました。

ポリシー機能の今後

冒頭でも紹介したように、3scaleの魅力の一つは、良い機能であると判断されれば、自分のコードが受け入れられるところです。

OSSで公開されているapicastリポジトリにプルリクエストを出すことで、新たなポリシーを提案することが可能です。現在活発に開発が進んでおり、筆者もコミュニティでの開発に参加しています。次のバージョン2.3に向けて、特に注目のポリシーを紹介します。

流量制御(Rate Limit)ポリシー

2.1以前の流量制御機能は、クライアントアプリケーションごとにAPIリクエスト数を制限することが主目的であり、Backendコンポーネントにて行われてきました。

しかし、APIバックエンド(リソースサーバ)を急激な流量増加から保護したい等の目的に適用しようとすると、下記課題がありました。

• 流量制御を非同期で行っているため、厳密な流量制御ができない
• アプリケーション単位の流量制御しかできない

これらの課題に対して、筆者は、APIcast側での流量制御をポリシーとしてパッチ投稿しました。基本的な機能についてはPR #648で提案し、採用されました。テックプレビューながら3scale 2.2から取り込まれています。

流量制御ポリシーでは、下記が可能です。

• APIcastが流量制御機能を持つことで、既存のアーキテクチャを踏襲しつつ、厳密な流量制御ができる
• サービス(API)単位およびグローバルでの(全サービスにわたる)流量制御ができる

また、本ポリシーでは、単位時間の上限値を制御する流量制御方法以外にも、下記の流量制御方法を新たに選択できます。

• バックエンドへのコネクション数を制御する方法
• 1秒間のリクエスト数を制御する方法(リーキーバケットアルゴリズム)

これらは、急激な流量増加からのAPIバックエンドの保護などに役立てることができます。

以上のように、2.2で導入された流量制御ポリシーは、既存の流量制御機能の課題を解決しつつ、ユースケースの幅を広げるという、非常に強力なものとなっています。

さらに、2.3に向けて下記のような改良パッチを提案し、取り込まれており、次バージョンではさらに使い勝手の良い流量制御ポリシーになっていくと思います。

PR #703: カウント値のキャッシュをRedisに保存した場合、プロパティの変更が適用されないことがあるという問題点(Issue #667)への対応。

PR #719: Liquidテンプレートをサポート。ngx.var.VARIABLEを用いた、APIリクエストのホストやパス単位の流量制御や、アクセストークン(jwt)を用いた、AudienceやIssuer単位の流量制御が可能となります。

トークンイントロスペクション(Token Introspection)ポリシー

3scaleはKeycloakと連携することで、OpenID Connectに対応したAPI認可・認証をサポートすることができます。ここで、OpenID Connectで発行されたアクセストークンが正当であるかのチェックが必要になります(改ざんされていないか、Keycloak側で無効にされていないか)。アクセストークンの正当性については、Keycloakに「トークンイントロスペクション」という形で問い合わせをすると確認できますが、確認ロジックをAPIバックエンドごとに実装するのは煩雑です。そこで、同僚の茂木さん(@tmogi001)がAPIcast側でトークンイントロスペクションを行うトークンイントロスペクションポリシー(PR #619)を提案し、採用されました。テックプレビューながら3scale 2.2から取り込まれています。

このポリシーについても、継続的な改良が加えられています。APIリクエストのたびにKeycloakにトークンイントロスペクションを行うとパフォーマンスに問題が生じるため、問い合わせ結果をキャッシュする機能(PR #655) がコアメンバにより開発され、導入されました。 また、筆者も開発に参加し、設定項目の入力を簡単にするユーザビリティ改善(PR #755)を提案し、採用されました。

スコープチェック(Keycloak Role Check)ポリシー

スコープチェックとは、APIリクエストが「リソース」にアクセスするために必要な「ロール」を持っているかどうかチェックする機能です。本機能により、クライアントごとの煩雑なアクセス制御に代わって、「ロール」を用いたダイナミックなアクセス制御ができるようになります。クライアントアプリケーションが要求し、エンドユーザが許可した「ロール」は、OpenID Connectで発行されたアクセストークンに含まれます。

スコープチェックの機能を、APIcastで持つのか、APIバックエンドで持つのか、Enterprise Service Busで持つのかに関しては、議論の余地があり、それぞれにメリット・デメリットがあるため、API管理者の好みやシステム要件により、スコープチェックの実装箇所は変わりますが、2.1以前はAPIcastでのスコープチェックは実現できませんでした。

「APIcastでのスコープチェック」という選択肢を実現し、より幅広いユースケースに対応できるように、筆者はPR #773でパッチ提案し、採用されました。

おわりに

本稿では、3scale 2.2の新機能を紹介しました。

マルチテナント機能とポリシー機能を筆頭に、多くの機能が追加され、3scaleは更なるパワーアップを遂げました。

現在も、コミュニティで活発な議論が交わされており、次バージョンでも更なるパワーアップが期待できます。

現在注目を集めているAPI管理の分野で、3scaleのコミュニティに参画し、自分好みのAPI管理を実現してみてはいかがでしょうか。