AWS クラウド
キャッシュの使用を開始する

コンピューティングにおいて、キャッシュは、データのサブセットが保存される (通常は一時的) 高速なデータストレージレイヤーです。このため、同じデータのリクエストが今後発生した場合、データのプライマリストレージロケーションにアクセスするよりも高速にデータが供給されます。キャッシュにより、以前に取得または計算されたデータを効率的に再利用できるようになります。キャッシュ内のデータは、一般的に RAM (ランダムアクセスメモリ) などの高速にアクセスできるハードウェアに保存され、ソフトウェアコンポーネントとの相関関係にも使用されます。キャッシュの主な目的は、基盤となる低速なストレージレイヤーにアクセスする必要を減らすことで、データ取得性能を向上することです。通常、データベース内のデータは完全で耐久性があるのに対して、容量よりも速度が優先されるキャッシュでは、一般的に、データのサブセットが一時的に保存されます。

キャッシュは、オペレーティングシステム、コンテンツ配信ネットワーク (CDN) や DNS などのネットワーキングレイヤー、ウェブアプリケーション、データベースといったさまざまなテクノロジーのレイヤーにわたって適用して活用できます。

RAM やインメモリエンジンによってサポートされる高いリクエストレートまたは IOPS (1 秒あたりの入力/出力オペレーション数) のため、キャッシュによってデータ取得性能が向上し、規模に応じてコストを削減できるようになります。従来のデータベースとディスクベースのハードウェアを使用して同一の規模をサポートするには、リソースの追加が必要になります。このような追加のリソースによってコストは上昇するものの、インメモリキャッシュによる低レイテンシーのパフォーマンスは実現できません。

キャッシュを使用すると、Q&A ポータル、ゲーム、メディア共有、ソーシャルネットワーキングなどの読み取り操作の多いアプリケーションワークロードのレイテンシーを大幅に削減し、IOPS を改善できます。キャッシュされた情報には、データベースクエリの結果、計算負荷の高い計算、API リクエスト/応答、ウェブアーティファクト (HTML、JavaScript、イメージファイルなど) を含めることができます。レコメンデーションエンジンやハイパフォーマンスコンピューティングシミュレーションなど、データセットを操作して大量の演算を行うワークロードでも、キャッシュとして機能するインメモリデータレイヤーの利点を活用できます。これらのアプリケーションでは、数百個のノードにまたがる場合があるマシンのクラスター全体で、非常に大規模なデータセットにリアルタイムでアクセスする必要があります。基盤となるハードウェアの速度のため、このようなアプリケーションでは、このデータをディスクベースストアで操作することが大きなボトルネックとなります。

分散コンピューティング環境では、専用のキャッシュレイヤーにより、キャッシュから独立して、システムとアプリケーションを独自のライフサイクルで実行できるようになります。キャッシュに影響を与えるリスクはありません。キャッシュは、独自のライフサイクルとアーキテクチャトポロジを備え、さまざまなシステムからアクセスされる一元的なレイヤーとして機能します。これが特に必要となるのは、アプリケーションノードが動的にスケールインおよびスケールアウトされるシステムです。キャッシュがアプリケーションやキャッシュを使用しているシステムと同じノードにある場合、スケーリングがキャッシュの整合性に影響を与える場合があります。また、ローカルキャッシュを使用する場合、データを消費するローカルアプリケーションのみがローカルキャッシュを活用できます。分散キャッシュ環境では、データが複数のキャッシュサーバーにまたがる場合があるため、データのコンシューマーすべてに活用されるように、一元的な場所に保存されます。

diagram_cachingmicrosite
レイヤー クライアント側 DNS ウェブ アプリケーション データベース
ユースケース ウェブサイトからのウェブコンテンツの取得を高速化 (ブラウザまたはデバイス) ドメインから IP 解決 ウェブ/アプリケーションサーバーからのウェブコンテンツの取得を高速化。ウェブセッションの管理 (サーバー側) アプリケーションのパフォーマンスとデータアクセスを高速化 データベースクエリリクエストに関連するレイテンシーの低減
テクノロジー HTTP キャッシュヘッダー、ブラウザ DNS サーバー HTTP キャッシュヘッダー、CDN、リバースプロキシ、ウェブアクセラレーター、キー/値ストア キー/値データストア、ローカルキャッシュ データベースバッファ、キー/値データストア
ソリューション ブラウザ固有 Amazon Route 53 Amazon CloudFrontRedis 用 ElastiCacheMemcached 用 ElastiCacheパートナーソリューション アプリケーションフレームワーク、Redis 用 ElastiCacheMemcached 用 ElastiCacheパートナーソリューション Redis 用 ElastiCacheMemcached 用 ElastiCache

キャッシュレイヤーを実装する際、キャッシュされたデータの有効性を把握することが重要です。正常なキャッシュは、高いヒットレートにつながります。つまり、データが取得された時に存在するということです。キャッシュミスは、取得されたデータがキャッシュに存在しない場合に発生します。TTL (有効期限) などのコントロールを適用して、必要に応じてデータの有効期限が切れるように設定できます。別の考慮事項は、キャッシュ環境に高可用性が必要かどうかという点です。これを実現するために、Redis などのインメモリエンジンを使用できます。場合によっては、プライマリロケーションからのデータのキャッシュとは異なり、インメモリレイヤーをスタンドアロンのデータストレージレイヤーとして使用できます。このシナリオでは、これが適しているかどうかを判断するために、インメモリエンジン内に存在するデータに対して、適切な RTO (停止してから復旧までにかかる時間を表す復旧時間目標) および RPO (復旧でキャプチャされた最後のポイントまたはトランザクションを表す復旧ポイント目標) を定義することが重要です。さまざまなインメモリエンジンの設計戦略と機能を適用して、RTO および RPO の大半の要件を満たすことができます。

Amazon ElastiCache は、クラウド内のインメモリデータストアまたはキャッシュのデプロイ、運用、スケーリングを容易にするウェブサービスです。このサービスでは、低速のディスクベースのデータベースに完全に依存せずに、高速のマネージドインメモリデータストアから情報を取得できるようにすることで、ウェブアプリケーションのパフォーマンスが向上されます。

効果的なキャッシュ戦略を実装する方法の詳細については、インメモリキャッシュに関する技術的なホワイトペーパーを参照してください。

ElastiCache_Deep_Dive_2016
ElastiCache Deep Dive: Best Practices and Usage Patterns
15
アプリケーションのパフォーマンスの向上

メモリはディスク (磁気または SSD) よりも桁違いに高速であるため、インメモリキャッシュからのデータ読み取りは非常に高速 (ミリ秒以下) です。このきわめて高速なデータアクセスにより、アプリケーションの全体的なパフォーマンスが向上されます。

データベースコストの削減

単一のキャッシュインスタンスは、数十万単位の IOPS (1 秒あたりの入力/出力オペレーション数) に対応でき、多数のデータベースインスタンスを置き換える可能性があるため、総コストの削減につながります。これは、プライマリデータベースがスループットごとに課金される場合に、特に重要です。このような場合、価格の節約が数十パーセントポイントにもなる可能性があります。

負荷の軽減

重要な読み取り負荷の一部をバックエンドデータベースからインメモリレイヤーにリダイレクトすることで、キャッシュではデータベースの負荷が軽減されるため、負荷時の低速なパフォーマンスやスパイク時に発生するクラッシュでさえも防止できます。

予測可能なパフォーマンス

最新のアプリケーションにおける一般的な課題は、アプリケーションの使用量のスパイク時に対応することです。例えば、スーパーボウルまたは選挙期間中のソーシャルアプリケーション、ブラックフライデーの e コマースウェブサイトなどがあります。データベースへの負荷が増加すると、データを取得するレイテンシーが大きくなるため、全体的なアプリケーションのパフォーマンスを予測できません。高スループットのインメモリキャッシュを使用することで、この問題を軽減できます。

ホットスポットの排除

多くのアプリケーションでは、有名人のプロフィールや人気製品など、データの小さなサブセットへのアクセス数が他の部分よりも多くなる可能性があります。これにより、データベースにホットスポットが発生し、最も頻繁に使用されるデータのスループット要件に基づいて、データベースリソースの過剰プロビジョニングが必要になる場合があります。インメモリキャッシュに一般的なキーを保存することにより、過剰プロビジョニングの必要を軽減すると同時に、最も頻繁にアクセスされるデータに対して高速で予測可能なパフォーマンスを提供できます。

スループットの増加

低レイテンシーに加えて、インメモリシステムでは、同等のディスクベースのデータベースと比較して、はるかに高いリクエストレート (IOPS) が提供されます。分散されたサイドキャッシュとして使用される単一のインスタンスにより、毎秒数十万個のリクエストに対応できます。

  • ユースケース

    キャッシュのさまざまなユースケースの詳細

    データベースキャッシュ

    データベースで実現される速度およびスループット両方のパフォーマンスは、アプリケーションの全体的なパフォーマンスに最も影響を与える要素となる場合があります。また、現在多くのデータベースで比較的良いパフォーマンスが実現されているにもかかわらず、多くの場合、お客様のアプリケーションにさらに高いパフォーマンスが必要になることがあります。データベースキャッシュを使用すると、バックエンドデータベースに関連したデータ取得レイテンシーのスループットが大幅に向上し、レイテンシーを低減できます。このため、アプリケーションの全体的なパフォーマンスが向上します。キャッシュは、データベースに隣接するデータアクセスレイヤーとして機能し、アプリケーションのパフォーマンスを改善するために使用できます。データベースキャッシュレイヤーは、リレーショナルデータベースや 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 は RESTful ウェブサービスです。HTTP 経由でアクセスでき、リソースが公開されているため、ユーザーはアプリケーションとやり取りできます。API を設計する際、API で予期される負荷、これに対する許可、バージョン変更が API コンシューマーに与える影響、そして最も重要な点として、API の使いやすさを考慮することが重要になります。API では、すべてのリクエストに対して、ビジネスロジックのインスタンス化やデータベースへのバックエンドリクエストが必要になるわけではありません。場合によっては、API のキャッシュされた結果を供給することにより、最適化された最もコスト効果の高い応答が実現されます。このことは、特に基盤となるデータの変更率と一致するように API レスポンスをキャッシュする場合に当てはまります。例えば、ユーザーに製品一覧の API を公開しており、製品カテゴリが毎日 1 回のみ変更されるとします。製品カテゴリリクエストへの応答が 1 日中 API が呼び出されるたびに同じであるとすると、その日の API レスポンスをキャッシュするだけで十分です。API レスポンスをキャッシュすることで、アプリケーションサーバーやデータベースを含むインフラストラクチャへの負荷を排除できます。また、より高速な応答時間を得ることができ、より高性能な API を提供できます。

    Amazon API Gateway は完全マネージド型サービスで、開発者があらゆる規模で API の作成、配布、保守、モニタリング、保護を簡単に行うために役立ちます。


    ハイブリッド環境のキャッシュ

    ハイブリッドクラウド環境では、クラウド内に存在するアプリケーションを所有しながら、オンプレミスのデータベースへのアクセスが頻繁に必要となる場合があります。VPN や Direct Connect など、クラウド環境とオンプレミス環境の間の接続を作成するために採用できる多数のネットワークトポロジがあります。また、VPC からオンプレミスのデータセンターへのレイテンシーは低いとしても、オンプレミスのデータをクラウド環境にキャッシュすることにより、全体的なデータ取得性能を高速化できる場合があります。


    ウェブキャッシュ

    ウェブコンテンツを閲覧者に配信する場合、レイテンシーの多くは、画像、html ドキュメント、動画などのウェブアセットの取得に関係しています。このようなアーティファクトをキャッシュして、ディスク読み込みやサーバーの負荷を排除することで、レイテンシーを大幅に低減できます。サーバー側とクライアント側の両方に、さまざまなウェブキャッシュ手法を採用できます。一般的に、サーバー側のウェブキャッシュには、前面に配置され、ウェブサーバーからのウェブ応答が保持される、ウェブプロキシの利用が含まれます。これにより、効果的に負荷とレイテンシーを低減できます。クライアント側のウェブキャッシュには、以前にアクセスしたウェブコンテンツのキャッシュされたバージョンが保持される、ブラウザベースのキャッシュが含まれます。ウェブキャッシュの詳細については、こちらをクリックしてください。


    一般的なキャッシュ

    メモリからデータへのアクセスは、ディスクや SSD からデータにアクセスするよりも桁違いに高速なため、キャッシュ内のデータの活用には多くの利点があります。トランザクションデータサポートやディスクベースの耐久性を必要としないユースケースの多くでは、インメモリキー値ストアをスタンドアロンのデータベースとして使用することが、高性能アプリケーションを構築するための優れた手段となります。速度に加え、アプリケーションではコスト効果の高い価格で、高スループットの利点も活用できます。製品のグループ化、カテゴリ出品、プロファイル情報などの参照可能データは、一般的なキャッシュの優れたユースケースです。一般的なキャッシュの詳細については、こちらをクリックしてください。


    統合されたキャッシュ

    統合されたキャッシュは、元のデータベースから頻繁にアクセスされるデータが自動的にキャッシュされるインメモリレイヤーです。最も一般的に、基盤となるデータベースは、データがキャッシュ内に存在する場合、キャッシュを使用してインバウンドデータベースリクエストへの応答を実行します。このように、リクエストレイテンシーが低減し、データベースエンジンの CPU とメモリの使用率が削減されることで、データベースのパフォーマンスが大幅に向上します。統合されたキャッシュの重要な特性は、キャッシュされたデータとデータベースエンジンによってディスクに保存されているデータに一貫性があることです。

  • 業種

    キャッシュのさまざまなユースケースの詳細

    モバイル

    モバイルアプリケーションは、消費者の急速なデバイス導入や従来のコンピュータ機器の使用低下のため、急激な成長が著しい市場セグメントです。ゲーム、商用アプリケーション、ヘルスアプリケーションにかかわらず、現在、ほぼすべての市場セグメントでモバイルフレンドリーのアプリケーションを提供しています。アプリケーション開発の視点からは、モバイルアプリケーションの構築は、その他の形式のアプリケーションを構築する場合と非常によく似ています。プレゼンテーション層、ビジネス層、データ層という考慮事項は変わりません。画面サイズの制限や開発ツールは異なりますが、優れたユーザーエクスペリエンスを提供することは、すべてのアプリケーションで共通の目標です。効果的なキャッシュ戦略により、モバイルアプリケーションでユーザーが期待するパフォーマンスの実現、大規模なスケーリング、全体的なコストの削減が可能になります。

    AWS Mobile Hub は、モバイルアプリケーションの構築、テスト、使用状況のモニタリングのために AWS クラウドサービスの検出、設定、アクセスを行う、統合されたエクスペリエンスを提供するコンソールです。


    IoT

    IoT は、デバイスや物理的世界から、デバイスセンサーを通してインターネットまたはデータを消費するアプリケーションに情報を収集および配信する、という概念に基づいています。IoT の価値は、キャプチャされたデータをほぼリアルタイムの間隔で把握できるため、最終的に、消費システムやアプリケーションがデータにすばやく応答できるようになるという点にあります。例えば、GPS 座標を送信するデバイスがあります。IoT アプリケーションは、座標の近接性に応じて重要地点を提示することにより応答できます。さらに、デバイスのユーザーに関連する設定情報が保存されていれば、そのユーザーに合わせて推奨事項を微調整できます。この例では、優れたユーザーエクスペリエンスを実現するために、アプリケーションが座標に応答できる速度が重要になります。キャッシュはここで重要な役割を果たします。例えば、重要地点を地理的座標と共に Redis といったキー/値ストアに保存すると、高速な取得が可能になります。アプリケーション開発の視点からは、基本的に、プログラム的な意味があることを前提として、任意のイベントに応答するように IoT アプリケーションをコーディングできます。IoT アーキテクチャを構築する際の重要な考慮事項には、取り込みデータの分析、N 数のデバイスをスケールできるソリューションの構築、コスト効果の高いアーキテクチャの実現に関連する応答時間が含まれます。

    AWS IoT は、接続されたデバイスが簡単かつ安全にクラウドアプリケーションやその他のデバイスとやり取りできるマネージド型クラウドプラットフォームです。

    参考文献: Managing IoT and Time Series Data with Amazon ElastiCache for Redis


    広告技術

    最新の広告技術アプリケーションでは、特にパフォーマンスの要件が厳しくなっています。広告技術での成長が著しい分野の一例は、リアルタイム入札 (RTB) です。これは、デジタルディスプレイ広告の取引を最も細かいインプレッションレベルでリアルタイムに行う、オークションベースのアプローチです。RTB は 2015 年の主要な取引方法で、米国では、プログラムにより購入された広告の 74.0%、もしくは 11 億ドルを占めました (eMarketer Analysis による)。リアルタイム入札アプリケーションを構築する場合、1 ミリ秒によって、入札に間に合うか、または落札できないかの違いが生じます。つまり、データベースから入札情報をきわめて高速に取得する必要があります。データベースキャッシュでは、サブミリ秒で入札の詳細にアクセスできるため、このような高性能を実現するための優れたソリューションとなります。


    ゲーム

    対話機能は、大半の最新ゲームの基礎要件です。低速で応答のないゲームほどプレイヤーをいらいらさせるゲームはありません。このようなゲームは、ほとんど成功しません。モバイルマルチプレイヤーゲームでは、パフォーマンス要件がさらに厳しくなります。1 人のプレイヤーのアクションをリアルタイムに他のプレイヤーと共有する必要があるためです。キャッシュは、頻繁にアクセスされるデータにサブミリ秒単位のクエリレスポンスを提供することで、ゲームをスムーズに実行するために重要な役割を果たします。「現在スコアが上位 10 位のプレイヤーは誰か」といった同一データに複数回のクエリが送信される場合、ホットキーの問題を緩和することも役立ちます。

    AWS でのゲーム開発の詳細については、こちらをクリックしてください。



    メディア

    メディア企業では、読者数や視聴者数が常に変化する顧客に対して、大量の静的コンテンツを送信する必要が頻繁に生じます。例えば、Netflix や Amazon ビデオなどの動画ストリーミングサービスでは、大量の動画コンテンツを視聴者にストリーミングします。これは、グローバルに分散された一連のキャッシュサーバーにデータが保存されるコンテンツ配信ネットワークに最適です。メディアアプリケーションのもう 1 つの側面は、負荷の急増や予測不可能な傾向があるという点です。有名人がツイートしたばかりのウェブサイトのブログや、スーパーボウル期間中のフットボールチームのウェブサイトを想像してみてください。コンテンツの小さなサブセットへの需要のスパイクは、キーごとにスループットが制限されているため、大半のデータベースの課題となります。メモリにはディスクよりはるかに高いスループットがあるため、データベースキャッシュによって読み込みデータをメモリキャッシュにリダイレクトすることで、問題を解決できます。


    E コマース

    最新の e コマースアプリケーションは、より洗練されており、ユーザーのデータやショッピング履歴に基づいたリアルタイムの推奨事項を含め、パーソナライズされたショッピング体験を提供しています。多くの場合、ユーザーのソーシャルネットワークを確認し、ユーザーの友人が好きなものや購入したものに基づいて、推奨事項を提示することも含まれます。処理する必要があるデータ量は増加していますが、顧客を待たせるわけにはいきません。そのため、アプリケーションのパフォーマンスをリアルタイムに維持することは、贅沢ではなく、必須です。適切に実行されたキャッシュ戦略は、アプリケーションパフォーマンスの重要な側面で、これにより、アプリケーションが成功するか失敗するか、販売できるか顧客を失うかの違いが生じます。

    サンプルの e コマースアーキテクチャは、こちらをクリックしてください。


    ソーシャルメディア

    ソーシャルメディアアプリケーションは世界に旋風を巻き起こしました。Facebook、Twitter、Instagram、Snapchat といったソーシャルネットワークには、増加し続けるコンテンツ量を消費する、膨大な数のユーザーが存在します。ユーザーがフィードを開くと、ほぼリアルタイムに自分の最新のパーソナライズされたコンテンツを閲覧しようとします。各ユーザーにはさまざまな友人、画像、趣味などが含まれるため、これは静的コンテンツではありません。このため、基盤となるプラットフォームにおけるエンジニアリングの複雑さのニーズが増します。また、ソーシャルメディアアプリケーションは、主要なエンターテイメント、スポーツ、政治のイベントがあると、使用量のスパイクが生じやすくなります。このようなスパイクの弾力性とリアルタイムのパフォーマンスは、複数のキャッシュレイヤーを使用することで実現できます。これには、背景画像など静的コンテンツのためのコンテンツ配信ネットワーク、ユーザーの現在のセッションデータを記録するセッションキャッシュ、親しい友人の最新ニュースや最近閲覧した画像などの頻繁にアクセスするデータを保持するデータベースキャッシュが含まれます。


    ヘルスケア

    ヘルスケア業界でデジタル革命が起きているため、世界中のますます多くの患者が医療を利用し、医療にアクセスできるようになっています。一部のアプリケーションでは、患者が医師にビデオ相談で面会できます。また、ほとんどの大手プロバイダーでは、患者が検査結果を確認し、医療スタッフとやり取りできるアプリケーションを提供しています。ウェルネス面では、ユーザーの特定のセンサーアクティビティの追跡 (FitBit や Jawbone など) から包括的な健康指導およびデータに至るまで、多くのアプリケーションがあります。このようなアプリケーションにはインタラクティブな性質があるため、アプリケーション層、ビジネス層、データ層の高速なパフォーマンスのニーズに対処する必要があります。効果的なキャッシュ戦略により、高速なパフォーマンス、全体的なインフラストラクチャのコスト削減、使用量の増加に応じたスケーリングを実現できるようになります。

    AWS でのヘルスケアアプリケーションの構築に関する詳細については、こちらをクリックしてください。


    金融テクノロジー

    金融サービスを消費する方法は、ここ数年で劇的に進化しました。アプリケーションには、銀行および保険サービス、不正検出、投資サービス、リアルタイムアルゴリズムを介した資本市場の最適化などが含まれます。顧客の金融データへのリアルタイムのアクセス、送金などのトランザクション、支払いの実行が課題になります。まず、ユーザーがアプリケーションを操作する必要がある際、他のアプリケーションの場合と類似した制約が、ほぼリアルタイムで適用されます。さらに、金融アプリケーションには、セキュリティ強化や不正検出といった追加の要件を適用する場合があります。複数レイヤーのキャッシュ戦略を含む効率的なアーキテクチャは、ユーザーが必要とするパフォーマンスを実現するために重要です。アプリケーションのニーズに基づいて、キャッシュレイヤーには、ユーザーのセッションデータが保存されるセッションキャッシュ、静的コンテンツが保存されるコンテンツ配信ネットワーク、顧客が最近購入した 10 個の商品といった頻繁にアクセスされるデータのデータベースキャッシュが含まれます。

    AWS での金融サービスアプリケーションの詳細については、こちらをクリックしてください。

Amazon ElastiCache のような完全マネージド型サービスを使用して、クラウド内でキャッシュの使用を簡単に開始できます。これにより、セットアップの複雑さやキャッシュの管理が必要なくなり、組織に価値をもたらす作業に集中できるようになります。今すぐ Amazon ElastiCache にサインアップしてください。

Amazon ElastiCache の使用を開始する