キャッシュとは?
コンピューティングにおいて、キャッシュは、データのサブセットが保存される高速のデータストレージレイヤーで、通常は一時的な性質のものです。これにより、それ以降に同じデータのリクエストが発生した場合、データのプライマリストレージロケーションにアクセスするよりも高速にデータが供給されます。キャッシュにより、以前に取得または計算されたデータを効率的に再利用できるようになります。
キャッシュの仕組みを教えてください。
キャッシュ内のデータは、一般的に RAM (ランダムアクセスメモリ) などの高速にアクセスできるハードウェアに保存され、ソフトウェアコンポーネントとの相関関係にも使用されます。キャッシュの主な目的は、基盤となる低速なストレージレイヤーにアクセスする必要を減らすことによって、データ取得のパフォーマンスを向上させることです。
通常、データベース内のデータは完全で耐久性があるのに対して、一般的にキャッシュにはデータのサブセットが一時的に保存され、容量よりも速度が優先されます。
キャッシュの概要
RAM とインメモリエンジン: RAM やインメモリエンジンでは高いリクエストレートや IOPS (1 秒あたりの入力/出力オペレーション数) がサポートされているため、キャッシュによってデータ取得性能が向上し、大きな規模でコストを削減できます。従来のデータベースとディスクベースのハードウェアを使用して同一の規模をサポートするには、リソースの追加が必要になります。このようにリソースを追加するとコストが上昇する一方、インメモリキャッシュによる低レイテンシーのパフォーマンスは実現できません。
アプリケーション: キャッシュは、オペレーティングシステム、コンテンツ配信ネットワーク (CDN) や DNS などのネットワーキングレイヤー、ウェブアプリケーション、データベースといったテクノロジーのさまざまなレイヤーに応用できます。キャッシュを使用すると、Q&A ポータル、ゲーム、メディア共有、ソーシャルネットワーキングなど、読み込みが多い数多くのアプリケーションワークロードのレイテンシーを大幅に削減し、IOPS を向上させることができます。キャッシュされた情報には、データベースクエリの結果、計算量の多い計算、API リクエスト/応答や、HTML、JavaScript、画像ファイルなどのウェブアーティファクトが含まれます。レコメンデーションエンジンやハイパフォーマンスコンピューティングシミュレーションなど、データセットを操作して大量の演算を行うワークロードでも、キャッシュとして機能するインメモリデータレイヤーの利点を活用できます。これらのアプリケーションでは、数百のノードにまたがる可能性のあるマシンのクラスター全体で、非常に大きなデータセットにリアルタイムでアクセスする必要があります。基盤となるハードウェアの速度により、ディスクベースのストアでこのデータを操作することは、このようなアプリケーションにとって重大なボトルネックになります。
デザインパターン: 分散コンピューティング環境では、専用のキャッシュレイヤーにより、キャッシュから独立して、システムとアプリケーションを独自のライフサイクルで実行できるようになります。キャッシュに影響を与えるリスクはありません。キャッシュは、独自のライフサイクルとアーキテクチャトポロジを持つ異種システムからアクセスできる中央層として機能します。これは、アプリケーションノードを動的にスケールインおよびスケールアウトできるシステムに特に関係があります。キャッシュがそれを利用するアプリケーションまたはシステムと同じノードに存在する場合、スケーリングはキャッシュの整合性に影響を与える可能性があります。さらに、ローカルキャッシュを使用すると、データを消費するローカルアプリケーションにのみメリットがあります。分散キャッシュ環境では、データは複数のキャッシュサーバーにまたがり、そのデータのすべてのコンシューマーの利益のために一元的に保存できます。
キャッシュのベストプラクティス: キャッシュレイヤーの実装では、キャッシュされたデータの有効性を把握することが重要です。正常なキャッシュは、高いヒットレートにつながります。つまり、取得される時にデータが存在しているということです。キャッシュミスは、取得されたデータがキャッシュに存在しない場合に発生します。TTL (有効期限) などのコントロールを適用して、必要に応じてデータの有効期限が切れるように設定できます。別の考慮事項は、キャッシュ環境に高可用性が必要かどうかという点です。これを実現するために、Redis などのインメモリエンジンを使用できます。場合によっては、プライマリロケーションからデータをキャッシュするのではなく、インメモリレイヤーをスタンドアロンのデータストレージレイヤーとして使用できます。このシナリオでは、これが適しているかどうかを判断するために、インメモリエンジン内に存在するデータに対して、適切な RTO (停止してから復旧までにかかる時間を表す目標復旧時間) および RPO (復旧でキャプチャされた最後のポイントまたはトランザクションを表す目標復旧時点) を定義することが重要です。さまざまなインメモリエンジンの設計戦略と機能を適用して、大部分の RTO および RPO の要件を満たすことができます。
レイヤー | クライアント側 | DNS | ウェブ | アプリ | データベース |
ユースケース | ウェブサイト (ブラウザまたはデバイス) からのウェブコンテンツの取得を高速化する |
ドメインから IP への解決方法 | ウェブ/アプリサーバーのウェブコンテンツの取得を高速化します。ウェブセッションの管理 (サーバー側) | アプリケーションのパフォーマンスとデータアクセスを加速する | データベースクエリリクエストに関連するレイテンシーを削減する |
テクノロジー | HTTP キャッシュヘッダー、ブラウザ | DNS サーバー | HTTP キャッシュヘッダー、CDN、リバースプロキシ、ウェブアクセラレーター、key/value ストア | key/value データストア、ローカルキャッシュ | データベースバッファ、key/value ストア |
ソリューション | ブラウザ固有 | Amazon Route 53 | Amazon CloudFront、Redis 用 ElastiCache、Memcached 用 ElastiCache、パートナーソリューション | アプリケーションフレームワーク、Redis 用 ElastiCache、Memcached 用 ElastiCache、パートナーソリューション | Redis 用 ElastiCache、Memcached 用 ElastiCache |
Amazon ElastiCache を使用したキャッシュ
Amazon ElastiCache は、クラウド内でのインメモリデータストアまたはキャッシュのデプロイ、運用、およびスケールを容易にするウェブサービスです。このサービスは、低速のディスクベースのデータベースに完全に依存せずに、高速の管理されたインメモリデータストアから情報を取得できるようにすることで、ウェブアプリケーションのパフォーマンスを向上させます。効果的なキャッシュ戦略を実装する方法の詳細については、インメモリキャッシュに関するテクニカルホワイトペーパーを参照してください。
キャッシュの利点
アプリケーションのパフォーマンスの向上
メモリはディスク (磁気または SSD) よりも桁違いに高速であるため、インメモリキャッシュからのデータの読み取りは非常に高速です (ミリ秒未満)。このきわめて高速なデータアクセスにより、アプリケーションの全体的なパフォーマンスが向上します。
データベースのコストを削減
1 つのキャッシュインスタンスは、数十万の IOPS (1 秒あたりの入出力操作) を可能にし、潜在的に多数のデータベースインスタンスを置き換えるため、総コストを削減できます。これは、プライマリデータベースがスループットごとに課金される場合に特に重要です。そのような場合、コストの節約は数十パーセントになる可能性があります。
バックエンドの負荷を軽減する
キャッシュは、読み込み負荷の大部分をバックエンドデータベースからインメモリ層にリダイレクトすることで、データベースの負荷を軽減し、負荷時のパフォーマンスの低下やスパイク時のクラッシュからデータベースを保護します。
予測可能なパフォーマンス
最新のアプリケーションでよくある課題は、アプリケーションの使用量が急増した時に対処することです。例としては、スーパーボウルや選挙日のソーシャルアプリ、ブラックフライデーの e コマースウェブサイトなどがあります。データベースの負荷が増えると、データを取得するまでのレイテンシーが長くなり、アプリケーション全体のパフォーマンスが予測できなくなります。高スループットのインメモリキャッシュを利用することで、この問題を軽減できます。
データベースのホットスポットを排除する
多くのアプリケーションで、有名人のプロフィールや人気のある製品など、データの小さなサブセットが他のデータよりも頻繁にアクセスされる可能性があります。これにより、データベースにホットスポットが発生する可能性があり、最も頻繁に使用されるデータのスループット要件に基づいて、データベースリソースのオーバープロビジョニングが必要になることがあります。共通キーをインメモリキャッシュに保存すると、オーバープロビジョニングの必要性が軽減されると同時に、最もよくアクセスされるデータに高速で予測可能なパフォーマンスがもたらされます。
読み取りスループット (IOPS) の増加
インメモリシステムにより、レイテンシーが短くなることに加えて、同等のディスクベースのデータベースと比較してはるかに高いリクエストレート (IOPS) ももたらします。分散サイドキャッシュとして使用される単一のインスタンスは、1 秒あたり数十万のリクエストを処理できます。
ユースケースと業種
-
ユースケース
-
業種
-
ユースケース
-
キャッシュのさまざまなユースケースの詳細
データベースキャッシュ
データベースが提供する速度とスループットのパフォーマンスは、どちらもアプリケーションの全体的なパフォーマンスに最も影響する要因になる可能性があります。そして、今日の多くのデータベースが比較的優れたパフォーマンスを提供していたとしても、より多くを必要とするアプリケーションが必要となるユースケースが数多くあります。データベースキャッシュを使用すると、スループットを劇的に向上させ、バックエンドデータベースに関連するデータ取得のレイテンシーを短縮できます。その結果、アプリケーションの全体的なパフォーマンスが向上します。キャッシュは、パフォーマンスを向上させるためにアプリケーションが利用できるデータベースへの隣接データアクセス層として機能します。データベースキャッシュレイヤーは、リレーショナルデータベースや NoSQL データベースなど、あらゆるタイプのデータベースの前に適用できます。データをキャッシュにロードするために使用する一般的な手法には、遅延読み込みと書き込みスルーメソッドなどがあります。詳細については、こちらをクリックしてください。
コンテンツ配信ネットワーク (CDN)
ウェブトラフィックが地理的に分散している場合、インフラストラクチャ全体を世界中にレプリケートすることは常に実現可能であるとは限らず、費用効果も間違いなく高くありません。CDN は、エッジロケーションのグローバルネットワークを利用して、動画、ウェブページ、画像などのウェブコンテンツのキャッシュされたコピーを顧客に配信する機能を提供します。CDN は、応答時間を短縮するために、顧客または発信元のリクエストの場所に最も近いエッジロケーションを利用します。ウェブアセットがキャッシュから配信されることになると、スループットが劇的に向上します。動的データの場合、多くの CDN を、オリジンサーバーからデータを取得するように設定できます。
Amazon CloudFront はグローバルな CDN サービスで、お客様のウェブサイト、API、動画コンテンツ、またはその他のウェブ資産の配信を高速化できます。他のアマゾン ウェブ サービス製品と統合されたこのサービスを利用すると、デベロッパーや事業主は、簡単にエンドユーザーに対してコンテンツを高速化できます。最低利用量の条件はありません。CDN の詳細については、こちらをクリックしてください。
ドメインネームシステム (DNS) キャッシュ
インターネット上で行われるすべてのドメインリクエストは、ドメイン名に関連付けられた IP アドレスを解決するために、基本的に DNS キャッシュサーバーのクエリを実行します。DNS キャッシュは、ISP や DNS サーバーを介して、OS を含む多くのレベルで発生する可能性があります。
Amazon Route 53 は、可用性と拡張性に優れたクラウドのドメインネームシステム (DNS) ウェブサービスです。
セッション管理
HTTP セッションには、ログイン情報、ショッピングカートリスト、以前に表示したアイテムなど、サイトユーザーとウェブアプリケーション間で交換されるユーザーデータが含まれます。ウェブサイトで優れたユーザーエクスペリエンスを提供する上で重要なのは、ユーザーの設定を記憶し、豊富なユーザーコンテキストを提供することにより、HTTP セッションを効果的に管理することです。最新のアプリケーションアーキテクチャでは、一元化されたセッション管理データストアを利用することが、数多くの理由で理想的です。その理由には、すべてのウェブサーバーで一貫したユーザーエクスペリエンスを提供できる、ウェブサーバーのフリートが弾力的である場合のセッションの耐久性が向上する、セッションデータがキャッシュサーバー間でレプリケートされる場合に高い可用性を実現できるなどがあります。
詳細については、こちらをクリックしてください。
アプリケーションプログラミングインターフェイス (API)
今日、ほとんどのウェブアプリケーションは API に基づいて構築されています。API は一般的に、HTTP 経由でアクセスできる RESTful ウェブサービスのことで、ユーザーがアプリケーションと対話できるようにするリソースを公開します。API を設計するときは、API に予想される負荷、API への承認、API コンシューマーに対するバージョン変更の影響、そして最も重要なこととして、API の使いやすさなどを考慮することが重要です。API がビジネスロジックをインスタンス化したり、リクエストごとにデータベースにバックエンドリクエストを送信したりする必要があるとは限りません。API のキャッシュされた結果を提供することで、最適で費用効果の高い応答が得られることもあります。これは、基になるデータの変化率に一致するように API 応答をキャッシュできる場合に特に当てはまります。例えば、製品掲載 API をユーザーに公開し、製品カテゴリが 1 日に 1 回だけ変更されるとします。API への呼び出しが行われるたびに、製品カテゴリリクエストへの応答が一日中同じになることを考えると、その日の API 応答をキャッシュするだけで十分です。API 応答をキャッシュすることで、アプリケーションサーバーやデータベースなどのインフラストラクチャへの負荷を排除できます。また、応答時間が短縮され、API がより高いパフォーマンスを発揮できます。
フルマネージド型サービスの Amazon API Gateway を利用すれば、デベロッパーは規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護を行えます。
ハイブリッド環境のキャッシュ
ハイブリッドクラウド環境では、開発したアプリケーションがクラウドに存在し、オンプレミスデータベースへの頻繁なアクセスを必要とする場合があります。VPN や Direct Connect など、クラウドとオンプレミス環境の間に接続を確立するために利用できるネットワークトポロジは数多くあります。また、VPC からオンプレミスデータセンターまでのレイテンシーは短い場合もありますが、全体的なデータ取得パフォーマンスを高速化するには、オンプレミスデータをクラウド環境にキャッシュすることが最適である可能性があります。
ウェブキャッシュ
ウェブコンテンツを視聴者に配信する場合、画像、HTML ドキュメント、動画などのウェブアセットを取得する際のレイテンシーの多くは、このようなアーティファクトをキャッシュし、ディスクの読み取りとサーバーの負荷を排除することで大幅に削減できます。サーバー側とクライアント側の両方で、さまざまなウェブキャッシュ手法を採用できます。サーバー側のウェブキャッシュでは、通常、前にあるウェブサーバーからのウェブ応答を保持するウェブプロキシを利用して、負荷とレイテンシーを効果的に削減します。クライアント側のウェブキャッシュには、以前にアクセスしたウェブコンテンツのキャッシュバージョンを保持するブラウザベースのキャッシュを含めることができます。ウェブキャッシュの詳細については、こちらをクリックしてください。
一般的なキャッシュ
メモリからのデータへのアクセスは、ディスクや SSD からのデータへのアクセスよりも桁違いに高速であるため、キャッシュ内のデータを活用することには多くの利点があります。トランザクションデータのサポートやディスクベースの耐久性を必要としない多くのユースケースでは、メモリ内の key-value ストアをスタンドアロンデータベースとして利用することは、パフォーマンスの高いアプリケーションを構築するための優れた方法です。速度に加えて、アプリケーションは費用効果の高いコストで高スループットの恩恵を受けられます。製品のグループ化、カテゴリのリスト化、プロファイル情報などの参照可能なデータは、一般的なキャッシュの優れたユースケースです。一般的なキャッシュの詳細については、こちらをクリックしてください。
統合キャッシュ
統合キャッシュは、オリジンデータベースから頻繁にアクセスされるデータを自動的にキャッシュするインメモリレイヤーです。最も一般的には、データがキャッシュに常駐している場合、基盤となるデータベースはキャッシュを利用して、インバウンドデータベースリクエストへ応答を送信します。これにより、リクエストのレイテンシーが短縮され、データベースエンジンの CPU とメモリの使用率が低下するため、データベースのパフォーマンスが劇的に向上します。統合キャッシュの重要な特徴は、キャッシュされたデータがデータベースエンジンによってディスクに保存されたデータと一致していることです。
-
業種
-
さまざまな業種とキャッシュの多様なユースケースの詳細
モバイル
モバイルアプリケーションは、コンシューマー向けデバイスの急速な採用と従来のコンピューター機器の使用の減少を考えると、信じられないほど急速に成長している市場セグメントです。ゲーム、商用アプリケーション、健康アプリケーションなど、今日のほぼすべての市場セグメントにモバイル向けのアプリケーションがあります。アプリケーション開発の観点からは、モバイルアプリの構築は、他の形式のアプリケーションの構築と非常によく似ています。プレゼンテーション層、ビジネス層、データ層という同じ関心領域があります。画面の領域と開発ツールは異なりますが、優れたユーザーエクスペリエンスを提供することは、すべてのアプリケーションで共通の目標です。効果的なキャッシュ戦略により、モバイルアプリケーションは、ユーザーが期待するパフォーマンスを実現し、大幅にスケーリングし、全体的なコストを削減できます。
AWS Mobile Hub は、モバイルアプリケーションの構築、テスト、および使用状況のモニタリングを目的として AWS クラウドサービスの検出、設定、およびアクセスの統合されたエクスペリエンスを提供するコンソールです。
IoT (モノのインターネット)
モノのインターネットは、デバイスおよび物理的な世界からデバイスセンサーを介して情報を収集し、データを消費するインターネットまたはアプリケーションに配信する背後にある概念です。IoT の価値は、キャプチャされたデータをほぼリアルタイムの間隔で理解できることです。これにより、最終的には、消費するシステムとアプリケーションがそのデータに迅速に応答できるようになります。例えば、GPS 座標を送信するデバイスを考えてみましょう。IoT アプリケーションは、その座標の近さに応じて関心のあるポイントを提案することで応答できます。さらに、デバイスのユーザーにまつわる設定を保存している場合は、推奨事項を微調整してその個人に合わせることができます。この具体例では、アプリケーションが座標に応答できる速度は、優れたユーザーエクスペリエンスを実現するために重要です。ここでは、キャッシュが重要な役割を果たす可能性があります。例えば、地理座標とともに関心のあるポイントを Redis などの key/value ストアに保存して、高速検索を可能にすることができます。アプリケーション開発の観点からは、プログラミングでそれが行えるなら、基本的に IoT アプリケーションをどのようなイベントにも応答するようにコーディングできます。IoT アーキテクチャを構築する際の重要な考慮事項には、取り込んだデータの分析に伴う応答時間、N 個のデバイスを拡張できるソリューションの設計、費用効果の高いアーキテクチャの提供などがあります。
AWS IoT は、インターネットに接続されたデバイスから、クラウドアプリケーションやその他のデバイスに簡単かつ安全に通信するためのマネージドクラウドプラットフォームです。
その他の資料: Managing IoT and Time Series Data with Amazon ElastiCache for Redis
広告技術
最新の AdTech アプリケーションは、パフォーマンスの点で特に要求が厳しくなります。AdTech の重要な成長分野の例は、リアルタイム入札 (RTB) です。これは、デジタルディスプレイ広告を最もきめ細かいインプレッションレベルでリアルタイムに処理するためのオークションベースのアプローチです。RTB は、2015 年の主要な処理方法で、プログラムで購入した広告の 74.0%、つまり米国では 110 億ドルを占めました (eMarketer Analysis 調べ)。リアルタイム入札アプリを作成する場合、時間どおりに入札を送信できるか、またそれが受け付けられるかで、ミリ秒がものを言う可能性があります。これは、データベースから入札情報を取得するのが非常に高速でなければならないことを意味します。データベースキャッシュは、ミリ秒未満で入札の詳細にアクセスでき、その高いパフォーマンスを実現するための優れたソリューションです。
ゲーム
ほとんどすべての最新ゲームで、インタラクティブ性が基本的な要件になっています。遅いゲームや反応のないゲームほどプレイヤーを苛立たせるものはなく、人気を博すことはめったにありません。パフォーマンスの要件は、モバイルマルチプレーヤーゲームではさらに厳しくなります。モバイルマルチプレーヤーゲームでは、1 人のプレーヤーが実行するアクションを他のプレーヤーとリアルタイムで共有する必要があるからです。キャッシュは、頻繁にアクセスされるデータに対してミリ秒未満のクエリ応答を行えるようにすることにより、ゲームをスムーズに保つ上で重要な役割を果たします。また、キャッシュは「スコア別で現在の上位 10 人のプレーヤーは?」など、同じデータが何度もクエリされる場合のホットキーの問題を軽減するのにも役立ちます。
AWS でのゲーム開発の詳細については、こちらをクリックしてください。
メディア
メディア企業は、絶えず変化する読者/視聴者の数の顧客に、大量の静的コンテンツを送信する必要性に迫られることがよくあります。例としては、Netflix や Amazon Video などの動画ストリーミングサービスがあります。これは、視聴者に大量の動画コンテンツをストリーミングします。これは、データがグローバルに分散されたキャッシュサーバーのセットに保存されるコンテンツ配信ネットワークに最適です。メディアアプリケーションのもう 1 つの側面は、負荷が急上昇し、予測できない傾向があることです。有名人がツイートしたばかりのウェブサイトのブログや、スーパーボウルの最中のアメフトチームのウェブサイトを想像してみてください。コンテンツの小さなサブセットに対するこのような大きな需要の急増は、キーごとのスループットが制限されているため、ほとんどのデータベースにとって課題です。メモリのスループットはディスクよりはるかに高いため、データベースキャッシュによって読み込みデータをインメモリキャッシュにリダイレクトすることで問題を解決できます。
e コマース
最新の e コマースアプリケーションはより洗練されており、ユーザーのデータやショッピング履歴に基づいたリアルタイムの推奨事項など、パーソナライズされたショッピング体験を提供しています。多くの場合、ユーザーのソーシャルネットワークを閲覧したり、友達が気に入ったものや購入したものに基づいて推奨したりすることも含まれます。処理に必要なデータの量は増加していますが、顧客がより我慢強くなったということはありません。したがって、アプリケーションをリアルタイムで実行し続けることは贅沢ではなく、必須です。適切に実行されたキャッシュ戦略は、アプリケーションパフォーマンスの重要な側面であり、アプリケーションの成功または失敗、販売の成否や顧客の喪失数に違いが出る可能性があります。
ソーシャルメディア
ソーシャルメディアアプリは世界を席巻しています。Facebook、Twitter、Instagram、Snapchat などのソーシャルネットワークには、増え続けるコンテンツを消費する膨大な数のユーザーがいます。ユーザーがフィードを開くとき、最新のパーソナライズされたコンテンツがほぼリアルタイムで表示されることを期待しています。各ユーザーはさまざまな人、画像、興味などを持っているため、これは静的なコンテンツではありません。これにより、基盤となるプラットフォームでより複雑なエンジニアリングが求められるようになります。ソーシャルメディアアプリは、主要なエンターテインメント、スポーツ、政治イベントの周辺で使用量が急増する傾向もあります。このようなスパイクに対する弾力性とリアルタイムのパフォーマンスは、複数のキャッシュレイヤーを使用することで実現できます。これには、背景画像など静的コンテンツのためのコンテンツ配信ネットワーク、ユーザーの現在のセッションデータを記録するセッションキャッシュ、親しい友人の最新ニュースや最近閲覧した画像など頻繁にアクセスするデータを保持するデータベースキャッシュが含まれます。
ヘルスケアとウェルネス
ヘルスケア業界はデジタル革命を経験しており、世界中のますます多くの患者がケアを利用し、アクセスできるようになっています。アプリケーションによっては、患者がビデオ電話で医師に診てもらうことを可能にしているものもあります。ほとんどの主要プロバイダーには、患者が診察結果を確認して医療スタッフとやり取りできるアプリがあります。健康の側面では、ユーザーの特定のセンサーアクティビティ (FitBit や Jawbone など) の追跡から、包括的な健康コーチングやデータに至るまで、多数のアプリケーションがあります。このようなアプリのインタラクティブな性質を考えると、高速なパフォーマンスが求められるアプリケーション、ビジネス、およびデータ層に対処する必要があります。効果的なキャッシュ戦略により、高速なパフォーマンスを提供し、インフラストラクチャ全体のコストを削減し、使用量の増加に応じてスケーリングできます。
AWS でのヘルスケアアプリの構築の詳細については、こちらをクリックしてください。
金融と金融テクノロジー
私たちが金融サービスを利用する方法は、ここ数年で劇的に進化しました。アプリケーションでは、銀行および保険サービスへのアクセス、不正検出、投資サービス、リアルタイムアルゴリズムによる資本市場の最適化などが利用できます。顧客の財務データへのリアルタイムアクセスを提供し、送金や支払いなどの取引を可能にすることは困難です。まず、ユーザーがほぼリアルタイムでアプリを操作したい他のアプリケーションと同様の制約があります。さらに、金融アプリケーションでは、セキュリティの強化や不正検出などの追加要件が課される場合があります。ユーザーが期待するパフォーマンスを実現するには、マルチレイヤーキャッシュ戦略を含む効率的なアーキテクチャが不可欠です。アプリケーションのニーズに応じて、キャッシュレイヤーには、ユーザーのセッションデータが保存されるセッションキャッシュ、静的コンテンツが保存されるコンテンツ配信ネットワーク、顧客が最近購入した 10 個の製品といった、頻繁にアクセスされるデータのデータベースキャッシュが含まれます。
AWS での金融サービスアプリケーションの詳細については、こちらをクリックしてください。
Amazon ElastiCache の使用を開始する
AWS アカウントにサインアップする
シンプルなチュートリアルで学ぶ
Redis クラスターの作成方法を学習します。
構築を開始する
ユーザーガイドでのヘルプを使って、構築を開始する。