Fastly Compute ストレージのまとめ(2023年末版)
この記事は Fastly Compute (旧 Compute@Edge) 一人アドベントカレンダー 21 日目の記事です。
昨日までの記事で、揮発性ストレージと永続ストレージの両方について紹介してきました。個別の紹介が続いたので、ここで一度全種類をまとめて比較して見てみましょう。
揮発性ストレージ vs 永続ストレージ
公式Docに大分類の解説があるのでこちらを引用して紹介します。
| Cache API | ConfigStore / SecretStore / KVStore | |
|---|---|---|
| SDK からのアクセス | Read/Write | Read/Write (Config/SecretStore は Read のみ) |
| API 経由でのアクセス | Purge のみ | Read/Write |
| 揮発/不揮発(永続) | 揮発 | 不揮発(永続) |
| スコープ | POP ローカル | グローバル |
Cache API は無料で使えてかつアクセス速度も一桁ミリ秒レベルで使えるため、レイテンシを重視する場面以外でも色々な場面で活用できる使いやすい API となります。一方で永続ストレージの方はストレージの種別によって向き/不向きのシーンが明確に分かれてきます。
それぞれの API に適切なユースケースについては、公式ブログに簡単にまとめられているので紹介しておきます。公式 Doc の解説にもありますが、ConfigStore や SecretStore はマイクロ秒レベルでの Read 性能があるため[1]レイテンシ面では優位性がありますが、書き込みについて各種制限があり書き込めるデータサイズにも限りがあるため[2]、処理の種類に応じて書き込みに対して比較的柔軟に対応が可能な KVStore と組み合わせながら利用を検討していくイメージとなります。
- KVStore: 大規模なリスト型のデータや小〜中規模の静的なデータの管理など
- Config Store: 環境変数など
- Secret Store: API Key などのクレデンシャル管理など
揮発性ストレージの比較
公式Doc の一覧をベースに一部加筆修正して再掲します。
| Readthrough Cache | Simple Cache | Core Cache | |
|---|---|---|---|
| 概要 |
send()やfetch()等のバックエンドとの通信の結果得られたレスポンスをキャッシュする機構 |
get()、setOrGet() といったシンプルなインターフェースを提供する API |
Cache にアクセスするための低レベルの API で、Cache 機構のメタデータを含めた全ての要素へのアクセスとコントロールが可能 |
| 対応 SDK | Rust, Go, JS | Rust, Go, JS | Rust, Go, JS |
| 想定ユースケース | オリジンのコンテンツを自動でキャッシュ | シンプルな Key-Value キャッシュ | トランザクション含めた複雑な要件でのキャッシュ |
| Cache の鮮度 | HTTP セマンティクスに準ずる | コード上で明示的に指定 | コード上で明示的に指定 |
| リクエスト共有(Request Collapsing) | 自動で必要に応じて機能 | 常に On | 手動でコントロール |
| Streaming miss | ✅ (自動) | ❌ | ✅ (手動) |
| Revalidation | ✅ (自動) | ❌ | ✅ (手動) |
| サロゲートキー | ✅ | ❌ | ✅ |
| パージ | ✅ | ✅ | ✅ |
キャッシュ戦略をオリジンサーバ側の Cache-Control ヘッダに依存するようにアーキテクチャを構成していく場合には、現状では Readthrough Cache を活用するのが第一戦略となります。一方で Compute(エッジ)側でキャッシュ戦略をコントロールしていく場合には SimpleCache または CoreCache API を活用していくことになりますが、はじめに SimpleCache API を利用して開発を進めて、機能的に不足が生じてきたタイミングで CoreCache API の利用を検討するという流れがスムーズに開発を進められるかと思います。
Interoperability (相互運用性)について
最後に上記 3 つの Cache API を比較する上でいくつか補足です。公式Doc の interoperability の章に重要な備考が書いてあるためそちらを引用します。
Whether you use the readthrough cache, simple cache or core cache interfaces, data is stored in the same namespace, but interoperability is currently limited to the following:
Readthrough, simple, core cache 等いずれの Cache インターフェースを使う場合においても、データは同じ名前空間の中で保管されることが明記されています。その上で、提供される interoperability(相互運用性)としては次の内容が記載されています。
- Core cache インターフェースを使うことで、 Simple cache インターフェースにより読み書きされたデータを読み込んだり上書きしたりすることが可能
- Simple Cache は Core Cache API 経由で書き込まれたオブジェクトを読み込むことはできるが、上書きはできない
- Readthrough Cache は Simple/Core Cache との相互運用性はない
Cache API 間での相互運用性については以前 SimpleCache の記事でも少し触れていますのでそちらもあわせて参照してください。
まとめ
本稿ではこれまでに紹介してきた各種ストレージについて機能や特徴の比較をおこない、適切な使い方や使い所について検討をしました。明日からは Fastly Compute を使う際に知っておくと便利かもしれない細かい Tips について紹介してみたいと思います。
-
公式 Doc の解説 "Config stores are durable, globally consistent key-value stores for string keys and values, which offer extremely fast read performance (microseconds) at the edge" より引用 ↩︎
-
制限の詳細については先日の Dynamic Configuration に関する記事を参照してください ↩︎
Discussion