Category: Amazon ElastiCache

 この投稿では、Amazon ElastiCache ワークロードに適したノードサイズとクラスタートポロジを決定するプロセス、および考慮すべき重要な要素について説明します。この投稿は、Redis とそのコマンドについて十分な知識があり、Amazon ElastiCache for Redis とオンラインでのクラスターサイズ変更、スケーリング、Amazon EC2 から ElastiCache へのオンラインでの移行、汎用およびメモリ最適化ノード、強化された I/O などの機能を理解していることを前提としています。 基準の推奨事項 エントリーレベルの小規模 (2,000 件以下の TPS と 10 GB 以下のデータサイズ) とおよび規模 (TPS が 2,000〜20,000 件、データサイズが 10 GB〜100 GB) のキャッシュワークロード (一時的なスパイクも発生する可能性があるものを含む) 使用中は、次世代の汎用バースト可能 T3 標準キャッシュノードである T3 ファミリーからキャッシュノードを選択します。ワークロードに ElastiCache を使い始めたばかりの場合は、無料利用枠の T3.micro キャッシュノードから始めてください。負荷を増やすと、T3.medium キャッシュノードまで増加できます。 最新ノードタイプは最新世代の CPU とネットワーク機能をサポートしているため、中規模から大規模 (20,000 の TPS と100 GB のデータサイズを超える) ワークロードの場合は、M5 または […]

この記事は、Tinder 社の William Youngs 氏 (ソフトウェアエンジニア) 、Daniel Alkalai 氏 (シニアソフトウェアエンジニア) 、Jun-young Kwak 氏 (シニアエンジニアリングマネージャー) らの寄稿によるものです。Tinder は、2012 年に大学のキャンパスで生み出され、世界で一番利用されているマッチングアプリに成長しました。現在までに、このアプリは 3 億 4,000万件以上ダウンロードされており、190 の国々において 40 以上の言語で利用されています。2019 年の第3四半期時点において、Tinder には 570 万人の登録者がおり、ゲーム以外のアプリの中では世界で最も成長しているものとなっています。 Tinder の業務は、毎日 20 億件におよぶメンバーからのアクションに対応しながら 300 億件のマッチングをホスティングするために、低レイテンシーを Redis ベースのキャッシングにより実現しています。ここで行われるデータオペレーションの主体は読み込みです。次に示す図が、当社のバックエンドマイクロサービスにより大規模な回復性を実現するための、基本的なデータフローアーキテクチャを説明しています。 図 1 キャッシュアサイドアプローチ このキャッシュアサイドアプローチでは、データを要求されたマイクロサービスは、信頼できる情報源である永続的データベースストア (主として Amazon DynamoDB ですが、PostgreSQL、MongoDB、Cassandra も使用する場合もあります) を参照する前に、まず、Redis によるキャッシュへのクエリを行います。このサービスでキャッシュミスが発生した場合は、Redis に対して真実の情報源から値の埋め戻しが行われます。 図 2 EC2 で Redis をシャードする構成 当社では、Amazon ElastiCache […]

技術の世界で、キャッシュはどこにでもあるものです。CPU は L1、L2、および L3 キャッシュを使用し、携帯電話はアプリのデータをローカルにキャッシュします。ストリーミングサービスはエッジでコンテンツをキャッシュし、ブラウザーは画像をキャッシュするなどです。 同じことは、データベースにも言えます。 もし、ゲームのサイトで、毎回リーダーボードが表示され、そのたびに、クエリが合計を行い、ゲームのすべてのプレーヤーをソートする必要があったらどうでしょうか。または、eコマースのサイトに行くたびに、特定の製品の価格をそれぞれの顧客のディスクから読み取らなければならないとしたらどうでしょうか。パフォーマンスは受け入れがたいものであり、コンピューティングの量でコストはかなり高額になります。 データベースで、キャッシングの主な動機として、パフォーマンスとコスト節約の 2 つが挙げられます。ミリ秒のパフォーマンスでは十分ではないときにマイクロ秒のパフォーマンスを求める場いいでも、一般的に使用されるデータをキャッシングすることにより、データベースから費用のかかる運用を外したい場合などです。 ソリューションの概要 この記事では、Amazon DocumentDB (MongoDB 互換性を使用) および Amazon ElastiCache を統合して、マイクロ秒の応答時間を達成し、コスト全体を減らす方法を示します。次の図では、この記事のソリューションに対するアーキテクチャを示しています。 この例の運用データベースは、Amazon DocumentDB です。これは高速で信頼性があり、容易にクラウドでの Mongo DB互換のデータベースをセットアップ、運用、およびスケールすることができる完全管理型のデータベースです。Amazon DocumentDB で、MongoDB で使用しているものと同じアプリケーションコードを実行し、同じドライバ、およびツールを使うことができます。 Amazon DocumentDB の柔軟性のあるドキュメントモデル、データタイプ、インデックス作成機能を使用して、コンテンツを素早く、直感的に保管し、クエリすることができます。たとえば、ショッピングサイトやカタログのユーザーレビューやでもビデオ、POS 端末の在庫リスト、トレーディングプラットフォームの財務取引などです。 キャッシングレイヤーの場合、Amazon ElastiCache を使用します。これは、AWS の分散型メモリ内キャッシュ環境を容易にセットアップ、管理、スケールできるようにします。ElastiCache は高いパフォーマンス、サイズ変更可能で、コスト効率の良いメモリ内キャッシュを提供する一方で、分散型キャッシュ環境のデプロイと管理に関連付けられた複雑性を排除します。ElastiCache は、Redis と Memcached エンジンの両方と互換性があります。 気に入った歌を見つけることができるようにするアプリケーションを構築することにより、これらの 2 つのサービスを統合する方法を示します。REST API クライアントを使用して、アプリケーションのエンジンに歌のタイトルを送信します。 アプリケーションエンジンは、要求された歌の歌手の名前と可視を含むドキュメントを ElastiCache レイヤーから取得することにより、API 要求を処理します。その歌の要求がすでに前もってあった場合、ElastiCache による読み取りが行われます。そうではない場合、アプリケーションエンジンは Amazon DocumentDB にクエリし、要求されたドキュメントを JSON ドキュメントとしてアプリケーションに返します。 […]

ゲームリーダーボードを使用すると、プレイヤーは互いのパフォーマンスを比較できます。この重要なソーシャル機能により、プレイヤーの関わり合いが高められ、競争が促進されます。リーダーボードのデータは、同様のスキルレベルの競争相手とプレイヤーをマッチングさせるゲーム内のアルゴリズムに活かすこともできます。 この記事では、伝統的なリレーショナルデータベースを使用してゲームリーダーボードを構築および拡張することに関する課題を探ります。また、Redis などの最新のインメモリデータストアを活用して、非常に効率的でスケーラブルなソリューションを提供する方法についても検討します。 この提案されたソリューションは、リーダーボードストレージとクエリをリレーショナルデータベースからより汎用性の高い Amazon ElastiCache for Redis に向かうことを後押しします。ここで概説したアプローチは、ゲームリーダーボードだけでなく、一般にアプリケーション内でランキングを生成するあらゆる状況に適用されます。 背景 従来のリレーショナルデータベースを使用して基本的なリーダーボードを構築する手順はシンプルです。通常、以下の手順が含まれます。 テーブルを作成します。 スコアが変更されたときにスコアを挿入または更新します。 テーブルをクエリして、スコアの降順でランキングを取得します。 以下が基本的なリレーショナルデータベースのリーダーボードの実装です。 +———+———+——+—–+———+——-+ | Field | Type | Null | Key | Default | Extra | +———+———+——+—–+———+——-+ | user_id | int(11) | NO | MUL | NULL | | | score | int(11) | NO | MUL | NULL | | +———+———+——+—–+———+——-+ […]

現在、Amazon ElastiCache という名前は、リアルタイムアプリケーションと同義に捉えられるようになりました。Redis の性能の高さ、シンプルさ、そして多様なデータ構造へのサポートは、非リレーショナルのキー値ストアとしては、最も人気のあるものの 1 つです。ビジネスに不可欠なリアルタイムのユースケースが Redis 上で増加する中で、可用性の保証は重要な課題となってきています。 高い可用性を実現するため、Redis 用 Amazon ElastiCache では Redis クラスターの設定をサポートし、すぐれたスケーラビリティと可用性を提供します。加えて Amazon ElastiCache では、自動フェイルオーバー機能を持つ複数のアベイラビリティゾーン (Multi-AZ) も提供しており、クラスターがゾーン間で 1 つ以上の複製を作る設定も可能です。主要ノード上で障害イベントが発生しても、Redis 用 Amazon ElastiCache では自動的に複製に対しフェイルオーバーが行われるので、高い可用性が保証されます。 最近、Redis 用 Amazon ElastiCache から、Redis アプリケーションのエンドツーエンドな可用性を向上させるための、いくつかの発表を行いました。 「Amazon ElastiCache for Redis で計画されたメンテナンス中のクラスター可用性が向上」は、自動フェイルオーバーを有効化したクラスターの、パッチ適用、更新、その他メインテナンス関連処理など、ノード置換が関係する作業中における可用性を高めるものです。Redis クラスター設定のセットアップには、Redis Cluster クライアントが使えます。これにより、予定したメインテナンスやノード置換も、書き込み中断をまったく生じずに完了します。非 Redis クラスター (非シャード) 設定では、DNS の更新時に最大で数秒間の短い書き込み中断が生じることがあります。 「Amazon ElastiCache for Redis がセルフサービスアップデートに対応開始」は、メインテナンスのための更新を開始するタイミングを制御することで、その作業の影響を最小化するものです。 「Amazon ElastiCache Redis にリーダーエンドポイントを開始」は、個別レプリカエンドポイントの変更点を管理する必要がなく、読込みトラフィックの接続を可能にするものです。これにより、アプリケーションが個別ノードエンドポイントの変更点を管理する必要性がなくなり、可用性を向上させます。この機能は、Redis クラスター設定に対しては、すでにRedis […]

Coffee Meets Bagel 社が、サービスやモバイルクライアントのレイテンシーをできるだけ短くしながら高品質のマッチングを作成するために、Elasticsearch を使用してリコメンデーションを事前に計算するという選択をしたアプローチ、およびリコメンデーションを保存して提供するために Redis を選択した理由について説明します。また、Amazon ElastiCache for Redis によって、エンジニアリングチームの管理およびインフラストラクチャメンテナンスの作業が、どのように簡略化されたかについても説明します。

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

日本時間 2018年6月13日 03:00 インメモリデータストアであるRedisのセキュリティアドバイザリが公開されました。Amazon ElastiCache によって管理される Redis互換のノードは、単一のエンジンが稼働する、お客様の VPC で独立したお客様専用のノードです。したがって、VPC の設定で明示的に許可されていない限りは、他のお客様がそれらのノードに対しアクセスすることはできません。 Amazon ElastiCache においても、アップデートを含む新しい Redis バージョンがリリースされました。2018年6月10日以降に起動された ElastiCache クラスターには、影響はありません。既存の ElastiCache クラスターをお持ちのお客様は、メンテナンスウィンドウにて新しいバージョンへのアップデートが予定され、順次実施されます。このアップデ―トは今回の問題に完全に対処できるよう設計されており、ElastiCache はデフォルトで意図しない外部からのアクセスを防ぎます。このアップデートに関して、お客様によるアクションは必要ありません。 本件に関してセキュリティの懸念がある場合は、http://antirez.com/news/119 をご覧ください。また、Amazon ElastiCache クラスターへのネットワークアクセスをセキュアに保つ方法は、”Amazon VPCs and ElastiCache Security”[1] をご覧ください。 [1]: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/VPCs.html   上記はAWS Japan Security Awareness Teamによって翻訳されました。原文は以下です： https://aws.amazon.com/jp/security/security-bulletins/AWS-2018-016/

Amazon ElastiCache は、Redis または Memcached での完全マネージド型のインメモリデータストアやキャッシュの設定を簡単にします。本日、ElastiCache が Redis 4.0 と互換になったことを発表いたします。これにより、すべての商用 AWS リージョンで、Redis 4.0 互換の ElastiCache ノードまたはクラスターを起動できるようになります。ElastiCache Redis クラスターは、テラバイト単位のメモリや毎秒当たり何百万回もの読み書きへスケールして、ゲーム、IoT デバイス、金融アプリケーション、ウェブアプリケーションなどの最も厳しいニーズに対応することができます。 AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) で Redis クラスターを起動する方法は、引き続き簡単です。新しい Redis 4.0 の機能を使ってみるための小さなクラスターを作成し、新しいバージョンを使用するために「Engine version compatibility」で 4.0 リリースを選択します。これにより、この記事を書いている時点で、4.0.10 互換のクラスターが起動します。 新機能 Least Frequently Used (LFU) キャッシュエビクションポリシー – Redis 4.0 は、新しい LFU キャッシュエビクションアルゴリズムを含めて多くのキャッシング機能が強化されたことで、Least Recently Used (LRU) より優れたパフォーマンスを実現できます。Antirez のブログが、いくつかの変更について深く掘り下げています。 非同期の FLUSHDB、FLUSHALL、UNLINK – […]

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション（KPTI）にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized（PV）インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]