翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

e コマースアプリケーション用の Amazon ElastiCache (Valkey)

e コマースアプリケーションは、アプリケーションサーバーとデータベース間のインメモリキャッシュレイヤーの利点があります。Valkey を実行する Amazon ElastiCache は、製品カタログエントリ、インベントリ数、検索結果、ユーザーセッションなど、頻繁にアクセスされるデータに対してミリ秒未満の読み取りレイテンシーを提供し、データベースの負荷を軽減し、トラフィックの急増時の応答時間を短縮します。

クラスターの設定

データボリューム、スループット要件、運用設定に基づいてクラスタータイプを選択します。

ほとんどの e コマースアプリケーションでは、サーバーレスは本番環境への最も簡単なパスを提供します。トラフィックベースラインが予測可能で、クラスタートポロジ、ノードタイプ、スケーリング動作をより詳細に制御する必要がある場合は、ノードベースのクラスターに移行します。

製品データの主要な設計

データ型間での衝突を避けるために、キャッシュキーを予測可能、デバッグ可能、スコープ設定するように設計します。

主要な設計のベストプラクティス:

データ型別の TTL 戦略

カスタマーエクスペリエンスに影響を与えずにデータが変更される頻度と古くなる可能性に基づいて TTL (time-to-live) 値を設定します。

キャッシュアサイドパターン

キャッシュアサイドパターン (レイジーロードとも呼ばれます) は、e コマースアプリケーションの最も一般的なキャッシュ戦略です。アプリケーションは最初にキャッシュをチェックし、キャッシュミスに対してのみデータベースをクエリします。

読み取りパス (擬似コード)

FUNCTION getProduct(productId):
    cacheKey = "product:" + productId

    // Step 1: Check the cache
    cachedValue = cache.GET(cacheKey)

    IF cachedValue exists:
        RETURN deserialize(cachedValue)    // Cache hit — sub-millisecond

    // Step 2: Cache miss — query database
    product = database.query("SELECT * FROM products WHERE id = ?", productId)

    IF product not found:
        RETURN null

    // Step 3: Write to cache with TTL
    cache.SET(cacheKey, serialize(product), EXPIRE = 300)    // 5 minutes

    RETURN product

書き込みパス (擬似コード)

FUNCTION updateProduct(productId, updatedFields):
    // Step 1: Update the database (source of truth)
    database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)

    // Step 2: Invalidate the cache (don't update it)
    cache.DELETE("product:" + productId)

    // Next read will trigger a cache miss and repopulate from database

キャッシュ障害の処理

FUNCTION getProductWithFallback(productId):
    TRY:
        RETURN getProduct(productId)    // Normal cache-aside path
    CATCH cacheConnectionError:
        // Cache is unavailable — fall back to database directly
        RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
        // Log the error, trigger an alarm, but don't fail the request

キャッシュ障害によってパフォーマンスが低下し (レスポンスが遅くなります）、機能が損なわれないようにアプリケーションを設計します。データベースはフォールバックとして機能します。

キャッシュ無効化戦略

無効化により、ユーザーは更新後に現在のデータを確認できます。変更を表示する速度に基づいて戦略を選択します。

Amazon CloudFront を CDN レイヤーとしても使用するマーケットプレイスアプリケーションの場合、両方の階層にわたって無効化を調整します。ElastiCache キーを削除し、CloudFront キャッシュ無効化 (またはキャッシュタグ無効化) を送信して、アプリケーションレイヤーとエッジレイヤーの両方で更新されたコンテンツを表示するようにします。

接続管理

モニタリングする主要なメトリクス

よくある質問

Serverless とノードベースのどちらを使用すればよいですか?

トラフィックが予測不可能な場合 (新しいマーケットプレイス、季節的な急増）、キャパシティプランニングを回避する場合、またはチームがキャッシュオペレーションの専門知識を持っていない場合は、Serverless を使用します。トラフィックパターンが安定している場合、シャーディングをきめ細かく制御する必要がある場合、または持続的なスループットにより、ノードベースのコスト効率が向上します。

Valkey または Redis OSS を使用する必要がありますか?

新しいデプロイには Valkey を使用します。Valkey は新しい ElastiCache クラスターのデフォルトエンジンであり、Redis OSS コマンドおよびデータ構造と完全に互換性があり、継続的な開発を受け取ります。既存の Redis OSS クラスターは引き続き機能します。インプレースエンジンアップグレードを使用して、都合の良いときに Valkey に移行します。

キャッシュが使用できない場合はどうなりますか?

アプリケーションは、キャッシュを依存関係ではなく最適化として扱う必要があります。キャッシュが使用できない場合は、データベースの直接クエリにフォールバックします。応答時間は長くなりますが、アプリケーションは機能し続けます。マルチ AZ を有効にすると、完全なキャッシュが利用できなくなることはまれです。通常、レプリカへのフェイルオーバーは 30 秒以内に完了します。

必要なメモリを見積もるにはどうすればよいですか?

計算: (キャッシュする一意の項目の数) × (項目あたりの平均サイズ) × (Valkey データ構造のオーバーヘッド係数 1.2)。オーバーヘッドはオブジェクトのサイズとデータ型によって異なります。オブジェクトが小さいほどオーバーヘッドが比例して高くなります。たとえば、2 KB の 100,000 個の製品で、それぞれ 1.2 倍のオーバーヘッド = 約 240 MB です。セッションデータ、検索結果、インベントリ数を追加します。ヘッドルームから開始し (使用可能なメモリの 60% をターゲットとして使用）、 DatabaseMemoryUsagePercentage メトリクスをモニタリングして調整します。