Category: 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 ハイパーバイザーのメモリを読み取ることもできません。 […]

Sam Dengler は、アマゾン ウェブ サービスのソリューションアーキテクトです。 このブログ記事では、チャットアプリケーションに関連する概念とアーキテクチャのパターンについて説明します。また、チャットクライアントとサーバーの実装の詳細、サンプルのチャットアプリケーションを AWS アカウントに展開する方法についても説明します。 背景情報 チャットアプリケーションを構築するには、クライアントがチャットルームの他の参加者に再配信されるメッセージを送信できる通信チャネルが必要となります。この通信は、一般に publish-subscribe パターン (PubSub) を使用して実装されます。このパターンでは、メッセージが中央トピックチャネルに送信されます。関係者は、このチャンネルをサブスクライブして更新の通知を受けることができます。このパターンでは､発行者の知識なしに受信者のグループを拡大または縮小できるように､発行者と受信者を切り離しています｡ PubSubは、クライアントが WebSockets を使用して通信するバックエンドサーバーに実装されます｡WebSockets は、クライアントとサーバー間で双方向にストリーミングされるデータのチャネルを提供する永続的な TCP 接続です。単一サーバアーキテクチャでは、1 つの PubSub アプリケーションが発行者と受信者の状態を管理し、WebSocket を介してクライアントにメッセージを再配布することもできます。次の図は、単一サーバー PubSub アーキテクチャ上の 2 つのクライアント間でメッセージが WebSocket を通過するパスを示しています。 単一サーバーアーキテクチャは､通信フローを説明するのに役立ちます｡しかし、ほとんどのソリューションビルダーはマルチサーバーアーキテクチャで設計したいと考えています。マルチサーバーアーキテクチャは、信頼性を高め、伸縮性を高め、クライアントの数が増えるにつれてアプリケーションを水平的に拡大するのに役立ちます。 マルチサーバーアーキテクチャでは、クライアントはサーバープールにトラフィックを転送するロードバランサーに対して WebSocket 接続を行います。これらのサーバーは、WebSocket 接続とそれを経由してストリーミングされるデータを管理します。WebSocket 接続が PubSub アプリケーションサーバーとの間で確立されると、その接続は永続化され、データは両方向のアプリケーションにストリームされます。ロードバランサーは、WebSocket 接続のリクエストを健全なサーバーに配信します。つまり、2 つのクライアントが異なるアプリケーションサーバーに WebSocket 接続を確立できます。   複数のアプリケーションがクライアントの WebSocket 接続を管理するため、アプリケーションはメッセージを再配布するためにそれらの間で通信する必要があります。この通信が必要なのは、メッセージが WebSocket を介して 1 つのアプリケーションサーバーにストリームアップされ、別のアプリケーションサーバーに接続されたクライアントにストリームダウンされる必要があるためです。クライアント接続を管理しているアプリケーションから PubSub ソリューションを外部に出すことで、アプリケーション間の共有通信の要件を満たすことができます。   次の図は、マルチサーバー PubSub […]

“信頼するが、確認する” – ロナルド・レーガン米国大統領、1987 このコメントで、レーガン大統領は、核軍縮条約の哲学について、ロシアの諺を引用しました。DevOpsにも同じ考え方が当てはまります！   Amazon ElastiCache for Redisは、自動化されたフェイルオーバとリカバリを備え、高可用性を提供しています。ElastiCacheクラスタを作成したければ、 Redis Cluster モードを使用し、クラスタ内のシャード数を設定します。各シャードには、1つのプライマリノード（読み取りと書き込み用）と0〜5つのレプリカノード（読み取りとフェールオーバー保護用）があります。1つのクラスタは、レプリカがゼロ（1ノード）のシャードと同じくらい小さくても、5つのシャード（5つのレプリカ（合計90ノード））を持つことができます。   AWSでは障害が頻繁に発生することはありませんが、いずれのマシンでも障害は発生します。レプリカノードに障害が発生すると、障害が検出され、数分でノードが置き換えられます。   Redis Cluster では、プライマリノードに問題が起きた時に、Redis Cluster は障害を検知しレプリカノードを新しいシャードのプライマリとして昇格させます。このプロセスは大体30秒程で実施されます。問題の起きたノードは入れ替えられ、クラスタのレプリカノードとして復帰します。Redis ClusterとElstiCacheを、エンジンとして Redis 3.2.4 と Cluster モードを有効にすることによって使うことができます。   これを信じてください…しかし検証するべきです。   ElastiCacheのテストフェイルオーバのおかげで検証は簡単です。マネジメントコンソールかAWS CLIを使用し、ElasiCache クラスタのいずれかのノード障害をシミュレートする事ができます、そして、どのようなプロセスで貴方のアプリケーションが動くのかも見ることができます。マルチシャード、もしくはシングルシャードの環境でもテストは可能です。さらに古いRedis 2.8の環境でもテストは可能です。 コンソールまたはAWS CLIを使用して、ElastiCacheクラスタ内の任意のノードの障害をシミュレートし、自分のアプリケーションでフェールオーバープロセスがどのように機能するかを確認できます。マルチシャード環境とシングルシャード環境、さらに古いRedis 2.8ブランチ環境でもフェールオーバーをテストできます。コンソールでこれを行うには、クラスタとシャードを選択してノードビューを表示し、次にフェールオーバープライマリを選択します。マネジメントコンソールでテストを行う際には、クラスタとシャードを選択してNode Viewを確認し、次にFailover primaryを選択します。   使用には注意してください。どのようなクラスタでも同じように動きます。なぜならどのクラスタも開発環境、テスト、本番かをAWSが知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。   自動フェイルオーバのテストを試してみてください！   翻訳は桑野が担当しました。原文はこちら。