このエントリは2019/06/19現在の情報に基づいています。将来の機能追加・廃止に伴い、記載内容との乖離が発生する可能性があります。また、外部キャッシュ機能は本日現在パブリック・プレビューです。
Azure API Managementのキャッシュ
Azure API Managementにはキャッシュ機構があり、応答した結果をキャッシュにためてレスポンスを向上させる仕組みが標準で備わっているが、外部キャッシュとして、Azure Cache for Redisを利用できる（Azureで提供しているものだけでなく、一般のRedisインスタンスも利用可能）。
Azure API Management で外部の Azure Cache for Redis を使用する / Use an external Azure Cache for Redis in Azure API Management
https://docs.microsoft.com/azure/api-management/api-management-howto-cache-external
外部キャッシュのメリット
以下のドキュメントに記載の通り、従量課金でAzure API Managementを利用すると、組み込みのキャッシュが利用できないが、外部キャッシュを使えばキャッシュ機構を利用できる。その他、キャッシュの構成をより細かく制御したり、利用中のAzure API Management の価格レベル以上のデータをキャッシュしたりでき、さらに、キャッシュ管理のライフサイクルをAPI Managementインスタンスのライフサイクルから切り離すことができる。そのため、メンテナンスやインスタンス移行時にもキャッシュを再作成しなくてすむ、といったメリットが考えられる。
Azure API Management レベルの機能に基づく比較 / Feature-based comparison of the Azure API Management tiers
https://docs.microsoft.com/azure/api-management/api-management-features
キャッシュ ポリシー
以下の2種類のポリシーがある。
- 応答キャッシュポリシー (Response caching policies)
- 有効期間（TTL）内の応答を保持、利用するしくみ
- 値キャッシュポリシー (Value caching policies)
- キーを使い値を格納、利用、削除できるしくみ
- 特定のFragmentを格納することができる
API Management のキャッシュ ポリシー / API Management caching policies
https://docs.microsoft.com/azure/api-management/api-management-caching-policies
構成
ドキュメント、というかチュートリアルの通り。以下には流れのみを記載。
- Azure Cache for Redisのインスタンスを作成
- （まだ作成していなければ）Azure API Managementインスタンスの作成
- そこそこ時間がかかります…
- 1.で作成したCacheを2.で作成した（もしくは既存の）Azure API Managementインスタンスに関連付ける。
- ドキュメントのスクリーンショットではあたかも2で作成したキャッシュインスタンスを選択するように見えるが、実際には「カスタム」しか選択できない。
- 接続文字列は、Azure Cache for Redisの設定＞アクセスキーにある接続文字列を指定（その他のインスタンスであれば該当する接続文字列を指定する）。
- 設定が終了したら保存をクリック
実際に使ってみる
簡単のため、国内の空港を3レターコードで取得するようなAPIを作成し、そのAPIを使うことにした。Redis Cacheへの格納を確認するため、Azure Portalから利用可能なRedisコンソールを使う。
応答キャッシュの場合
テスト前のキャッシュの状況は以下の通りで、キャッシュに何もない状態。
この段階で、FUK（福岡）を検索したところ、以下のようにキャッシュに追加されたことがわかる。
Redisコンソールで確認すると、データが格納されていることはわかるが、エンコードされていてよくわからない…。
簡単なRedisクライアントアプリケーションを作成して確認したところ、APIレスポンス自体をCacheしていた。
値キャッシュの場合
同じAPIでQuery Parameterをキーに、レスポンスのJSONを文字列としてキャッシュに格納することにした。最初はまだ何も入っていない状態。
コードとしてFUKを指定してAPIを呼ぶと、キャッシュにキーが追加されていることが確認できる。キーに対応する値が文字列として格納されていることも確認できる。
先ほどのRedisクライアントで内容を確認すると、レスポンス本体を文字列として保持していることを確認できた。
まとめ
外部キャッシュを簡単に利用可能であることを確認できた。また、応答キャッシュポリシーの場合、レスポンスがまるごと格納されていたが、値キャッシュの場合はほぼ指定した形式で格納されていたことがわかった（先頭にヘッダーと思しきものが付加されている）。
TTLはRedisの機能を使っているため、値キャッシュでその気になればTTLを-1にして永続化することも可能ではある。
値キャッシュは確かに開発の自由度が高いが、API Management外からのデータ更新は想定されていないことは留意すべきである。
Logico Inside 