なぜキャッシュを検討するのか？
2024年7月9日から、CognitoのM2M認証（Client Credentials）が有料になるとの発表があったためトークン発行のキャッシュを検討していたので記事に残しておきます。
これによりAPI利用するシステム単位での固定料金に加えて、トークン発行回数による従量課金モデルになりました。
この従量課金のトークン発行回数のところは、コスト影響が発生するためキャッシュを検討します。
方式検討
有料化の発表前の5月に公式ドキュメントにAPI Gatewayによるキャッシュの方法が追加されているので、まずはこの方式以外でキャッシュができないか検討します。
案1：AWS公式のAPI Gateway方式
公式ドキュメントを見る限りは、ざっくりですが以下の通り。
- API Gatewayをプロキシとして採用
- 追加実装はなく、AWSの構成を変更するのみで導入可能
- API Gatewayのキャッシュ機能を利用
- キャッシュの保持期間は最大1時間
- キャッシュするサイズでコストが段階的に決まってくる（記事作成時点の料金）
キャッシュメモリサイズ (GB) 時間あたりの料金(USD) 月の料金(USD) 0.5 0.028 20.832 1.6 0.054 40.176 6.1 0.245 182.28 - API Gatewayのキャッシュサイズは、以下のことから0.5GBあれば十分となる。
- 1トークンリクエストあたりのキャッシュ対象サイズ
ヘッダー(byte) ボディ(byte) 合計(byte) 779 779 1,558 - API利用するシステム数の上限（API GWでのキャッシュ利用可能サイズごとのトークンキャッシュ上限）は以下の通り。
MAX0.5GB MAX1.6GB MAX6.1GB 344,590 1,102,687 4,203,996
- 1トークンリクエストあたりのキャッシュ対象サイズ
案2：API Gateway＋Lambda＋DynamoDBの方式
- Cognitoのトークン発行をLambdaでプロキシ
- クライアントIDごとにTokenをDynamoDBに保持
- DynamoDBで発行時間を保持して有効期限内なら利用
- 不要になったデータはDynamoDBのTTL機能で自動削除
- キャッシュ利用時の有効期限管理はLambdaで実装
- CognitoでのToken有効期限は最大24時間指定可能あるが2時間にしておく
- 有効期限が1時間以下の場合は新規にToken発行を行う
ざっくり比較
ざっくりと比較してみましたが、基本的に実装は大したレベルではないので新規導入なら案2の1択かと思います。
既存案件でも、1年間は無償期間は継続しているので基本的には案2で良いかと思いますが、対応できるリソースと期間次第では案1も選択肢になりうるのかなと個人的には思いました。
| 比較項目 | 案1 | 案2 |
|---|---|---|
| 月額コスト | 20ドルちょい | 1ドル未満 |
| 実装要否 | 不要 | 必要 |
| 柔軟性 | 無し | 有り （実装でどうとでも） |
| メンテナンス | 特に無し | Lambdaランタイム更新 （2年に1回ぐらい） |
| 実現難易度 | 超容易 | 容易 |
※コストはキャッシュ機能実現にかかわる部分のみです
最後に
APIを利用するシステムが社内であれば「絶対にキャッシュして使ってね」という手もあるかもしれないけど、サービスとして提供する場合はそうもいかないですよね。
また、APIを利用するシステムのバグで、なぜか大量にトークン発行をされるというテロに近い行為ができてしますのを避けるためにCognitoのM2M認証を利用する場合はキャッシュの検討を必ずしましょう！
また機会があれば、案2における実装編も書こうと思います。