ORACLE WHITE PAPER | 2018 2 1...MemcachedおよびRedisを使用した Oracle Cloud Infrastructureでの高可用性分散キャッシュ・レイヤーのデプロイ ORACLE WHITE

MemcachedおよびRedisを使用したOracle Cloud Infrastructureでの高可用性分散キャッシュ・レイヤーのデプロイ ORACLE WHITE PAPER | 2018年2月 | バージョン1 .0

0 | ORACLE WHITE PAPER: DEPLOYING MEMCACHED AND REDIS IN-MEMORY CACHING ON ORACLE CLOUD INFRASTRUCTURE

目次

このホワイト・ペーパーの目的 4

対象範囲と前提 4

概要 4

MemcachedとRedis 2

Oracle Cloud InfrastructureでのMemcachedの設計 3

デプロイメント・プラン 3

インスタンス・シェイプの選択 3

Oracle Cloud InfrastructureでのMemcachedクラスタの構築 3

キャッシング方法 5

キャッシュアサイド 5

リードスルー 6

ライトスルー 7

ライトバック 9

Memcachedのスケーリング - コンシステント・ハッシュ 10

Oracle Cloud InfrastructureでのRedisの設計 11

デプロイメント・プラン 12

インスタンス・シェイプの選択 12

Oracle Cloud InfrastructureでのRedisクラスタの構築 13

クラスタ化されていない複数のADデプロイメント 13

複数ADへのクラスタ化されたデプロイメント 14

Oracle Cloud InfrastructureにおけるRedisのバックアップとリストア 15

結論 16

参考資料 16



このホワイト・ペーパーの目的このホワイト・ペーパーは、Oracle Cloud Infrastructure (OCI)にデプロイするソリューションを構築しているオラク

ル社のお客様とパートナを対象としています。このホワイト・ペーパーでは、最も広く使用されている2つのインメ

モリー・キャッシュ・エンジンを比較します。それはRedisとMemcachedです。インメモリー・キャッシングの

ユース・ケースを理解し、キャッシングの一般的な設計パターン、パフォーマンスの考慮事項、Oracle Cloud Infrastructureにデプロイする際のベスト・プラクティスについて説明します。

このホワイト・ペーパーを読み終わる頃には、どちらのキャッシング方法がお客様のユース・ケースに適している

か、RedisまたはMemcachedを使用してそれをどのように設計するかを明確に理解できます。最後に、Oracle Cloud Infrastructure上のアプリケーションにインメモリー・キャッシング・レイヤーをデプロイしてスケーリングする方法

を説明します。

対象範囲と前提キャッシングは、オペレーティング・システムからネットワーキング(CDN)、ドメイン・ネーム・システム(DNS)、Webアプリケーション、データベースに至るまで、テクノロジ・スタックの各レイヤーに活用できますが、それぞ

れを詳しく説明することはしません。このホワイト・ペーパーの範囲は、インスタンス固有のプライベート・

キャッシュとは対照的な、大規模分散システムに関連するインメモリー共有キャッシング・レイヤーに厳密に限定

されています。

このドキュメントの範囲外の製品やトピックが数多くあります。すべてのトピックはリストしませんが、Oracle Cloud Infrastructureにインメモリー・キャッシング・ソリューションを設計する上で必要な追加コンポーネントとし

て、仮想クラウド・ネットワーク(VCN)、IDアクセス管理(IAM)、セキュリティ・リスト、ロード・バランサが挙げ

られます。このドキュメントの読者は、これらのサービスに精通することが推奨され、そのリンク先が「参考資料」

の項に記載されています。

概要コンピューティングにおいて、キャッシュは、操作の結果が格納される高速のデータ・レイヤーで、比較的速度の

遅いプライマリ・データ・ストアからアクセスするよりも速く、将来のリクエストがフェッチされます。キャッシ

ングは、プライマリ・データ・ストアにアクセスせずに、アクセス頻度の高いデータ・アイテムを迅速に取得でき

るようメモリーに格納して、アプリケーション・パフォーマンスを向上します。キャッシングを適切に利用すれば、

アプリケーションのパフォーマンスが向上するだけでなく、コストを大幅に低減できます。

キャッシングは、Webサイトを高速化する最も効果的な技術の1つであり、最新のWebアーキテクチャに不可欠に

なっています。効果的なキャッシング戦略により、Webサイトを最大限活用し、データベースの負荷を緩和して、

ユーザー・エクスペリエンスを向上させることができます。パフォーマンスが非常に高いアプリケーションを作成

する上で、最大にして唯一の要因は、効果的なキャッシング戦略だと言ってよいかもしれません。プライマリ・

データ・ストアからデータに繰り返しアクセスするアプリケーションの場合、次のいずれかの条件に一致していれ

ば、キャッシングが最も効果的です。

• プライマリ・データ・ストアで演算集中型の問合せが実行される • プライマリ・データ・ストアには比較的、静的データが格納される • プライマリ・データ・ストアの速度が比較的遅い • プライマリ・データ・ストアへの同時接続のサポートが制限されている

キャッシングは、読取り頻度が高く、変更頻度が低いデータに効果的です。キャッシングを重要な情報の信頼でき

るソースとして使用しないでください。いかなる情報も失うことができないアプリケーションには、より永続的な

プライマリ・データ・ストアの使用をお薦めします。それでは、MemcachedおよびRedisが提供するインメモ

リー・キャッシング・ソリューションを見ていきましょう。


MemcachedとRedis RedisとMemcachedはどちらもインメモリーのキー値ストアで、よく似ているように見えますが、中身はかなり違

います。

Memcachedは、広く普及しているインメモリー・キー値ストアです。高速で柔軟性が高く、軽量です。管理しやす

い設計が高速なデプロイの後押しとなり、大量のデータ・キャッシュに関連する多くの問題を解決します。そのAPIを使用すると、複数のマシンに分散している大規模なハッシュ表へのアクセスが可能になります。Memcachedサー

バーはマルチスレッドであるため、複数のコアを提供する大規模なインスタンス・シェイプを有効活用できます。

Redisは広く普及しているオープンソースのインメモリー・データ構造ストアで、キーと値のペアだけでなく、幅広

いデータ構造をサポートしています。string、hash、list、set、範囲問合せによるsorted set、bitmap、hyperloglog、半径問合せによる地理空間索引などのデータ構造がサポートされます。Redisにはレプリケーションが組み込まれて

おり、複数の可用性ドメイン間の重複を簡単に識別できます。また、様々なレベルのディスク永続性もサポートさ

れています。Redisはシングル・スレッドのため、複数コア・インスタンスのメリットはあまりありません。

Redisにはレプリケーションが組み込まれ、ディスク永続性オプションもあるため、インメモリー・キャッシングが

サポートされた非リレーショナル・データベースと考えるとわかりやすいでしょう。逆に、Memcachedは純粋な軽

量のキャッシング・ソリューションです。次に、どちらか一方を選択する際に役立つ決定要因をいくつか示します。

Memcachedを使用

• キャッシングのみが主な目的で他に何もない場合

• キャッシングしているデータが、HTMLコード・フラグメントなど、比較的小規模で静的である場合。

Memcachedの内部メモリー管理の効率がより高くなるのは、最もシンプルなユース・ケースです。

• 大規模なインスタンス・サイズで実行していて、複数のコアを使用したマルチスレッド・パフォーマンス

が必要な場合。Memcachedはマルチスレッドのため、計算リソースを増やすことで、簡単にスケール・

アップできます。

Redisを使用

• listやhashe、set、sorted set、bitmap、hyperloglogなど、より高度なデータ・セットが必要な場合

• アプリケーションにパブリッシュ/サブスクライブ(pub/sub)機能が必要な場合

• キャッシングだけでなく、ディスクのさらなる永続性(その結果としての一貫性も含む)が必要な場合

RedisまたはMemcachedを使用

• 成長に伴い、キャッシュ・レイヤーを水平方向にスケール・アウトする予定の場合。Memcachedの場合は、

ノードをさらに追加するだけで、Redisの場合は、組込みのクラスタリングにより実現可能です。

• 強力な一貫性を維持するために、キャッシングにチェックおよび設定操作が必要な場合。Memcachedでは、

すぐ利用できる状態でこれがサポートされており、Redisでは、オプティミスティック・ロックを可能にす

る同じような操作でこれを実現します。


Oracle Cloud InfrastructureでのMemcachedの設計

デプロイメント・プラン

Memcachedデプロイメントの主な目標は、データベースから可能なかぎり読取りをオフロードすることです。一般

的に、データに必要な量より多めにキャッシュ領域を用意することをお薦めします。トラフィックの急増に備えて

十分なバッファを確保し、データベースの負荷が高くならないようにするためです。Memcachedを正常にデプロイ

するには、データの初期ボリューム・サイズ、将来のデータの増加、冗長性オプションなどの複数のファクタに、

管理者が重み付けすることも必要です。

インスタンス・シェイプの選択

Memcachedクラスタには、インスタンスを1つ以上含めることができます。必要なクラスタ・メモリー容量は、大

規模なインスタンスをいくつか、あるいは小規模なインスタンスを多数使用することで獲得できます。どちらの方

法にも代価があります。

少数の大規模インスタンスを選択する場合: この場合、インスタンスを1つ失うと、バックエンドのデータ

ベースに重大な影響があります。プラス面では、Oracle Cloud Infrastructureでサイズの大きなインスタン

スを使用すると、最大25Gbpsという非常に高いネットワークI/Oが実現されます。Memcachedのマルチス

レッド特性を考慮すると、サイズの大きなインスタンスで提供される複数のコアを効果的に使用すること

も可能です。パフォーマンスが高く、サイズの大きなインスタンスでMemcachedに適したよい例は、

VM.DenseIO1.4インスタンス・タイプで、4つのOCPUコアと60GBのメモリーが提供され、ネットワーク

I/Oも拡張されています。

多数の小規模インスタンスを選択する場合: この場合、インスタンスを1つ失ってもデータベースの負荷が

大幅に高くなることはありませんが、代償として、ネットワークI/Oが低下します。ネットワークI/Oが低け

れば、パフォーマンスの問題の原因となることは明らかです。キャッシュのアクセス・パターンによって

は、キャッシュのパフォーマンスを低下させるTCPインキャストなどの問題の原因となる場合もあります。

パフォーマンスが高く、サイズの小さなインスタンス・シェイプでMemcachedデプロイメントに適したよ

い例は、2つのOCPUコアが提供されるVM.Standard2.2で、マルチスレッディングと30GBのインスタン

ス・メモリーを利用するオプションもあります。

Oracle Cloud InfrastructureでのMemcachedクラスタの構築パブリック・クラウドにMemcachedをデプロイする場合、一般的な設計方法では、リージョン内の複数の可用性ド

メイン(AD)にMemcachedインスタンスをデプロイします。Oracle Cloud Infrastructureにおいて、ADは独立したデー

タセンターで、相互に分離されていて、フォールト・トレラントであるため、同時に障害が発生する可能性は非常

に低くなります。これにより、キャッシュ・クラスタの高可用性が保証されます。また、AD間のレイテンシはおよ

そミリ秒であるため、キャッシュのパフォーマンスに大きく影響することは多少なりともありません。

インターネットからキャッシュ・インスタンスへのアクセスを制限するには、セキュリティ・リストとプライベー

ト・サブネットを使用します。MemcachedやRedisには、認証や暗号化の本格的な機能がないため、インスタンス

をプライベート・サブネットで起動することをお薦めします。Memcachedが関連するキャッシングの設計パターン

には様々なものがあり、データベースがインスタンスと直接やり取りすることがないため、データベース層への直

接アクセスを必要としないパターンもあります。Memcachedインスタンスをコールするのは、アプリケーション層

のインスタンスのみです。これについては、「キャッシング方法」の項で、さらに詳しく説明します。それでは、

デプロイのステップを順に見ていきましょう。

• アプリケーション・サーバー、Memcachedサーバーおよびデータベース・サーバーの格納に十分な大きさ

のVCNを作成します。VCNの作成方法および関連するベスト・プラクティスの詳細は、参考資料の『VCN Overview and Deployment Guide』を参照してください。


• 2つの別々の可用性ドメインに、2つのパブリック・サブネット(AD1とAD2とします)を作成し、要塞インス

タンスとパブリック・ロード・バランサをホスティングするDMZサブネットとして機能させます。Oracle Cloud Infrastructureでは、VCNのサブネットは特定のADにバインドされています。各可用性ドメインにサ

ブネットを1つずつ作成します。可用性ドメインとサブネットの詳細は、「参考資料」の項のOCI Networkingの概要を参照してください。

• アプリケーション・サーバー間のトラフィックをロード・バランシングするパブリック・ロード・バラン

サのペアを作成し、DMZサブネットに配置します。OCIのパブリック・ロード・バランサは、高可用性を

実現するため、設計により、アクティブ/スタンバイのペアになっています。アクティブとスタンバイは、

サブネットも可用性ドメインも別のところに配置する必要があります。詳細は、OCI Load Balancingの概

要を参照してください。

• AD1とAD2に2つのプライベート・サブネットを作成し、アプリケーション・サーバーを格納します。どち

らのサブネットも、VCNは同じにしてください。

• AD1とAD2にプライベート・サブネットを2つずつ作成し、Memcachedインスタンスを格納します。

• AD1とAD2にその他のプライベート・サブネットを2つずつ作成し、データベース・サーバーを格納します。

アプリケーション要件に基づき、OCIのDatabaseサービスを選択して、任意の種類のOracleデータベース

を作成できます。詳細は、参考資料のOCI Databaseの概要を参照してください。

• 作成したサブネットに適切なルート・ルールとセキュリティ・ルールを作成します。キャッシュ・サー

バーのサブネットに忘れずにセキュリティ・ルールを作成し、使用されている適切なキャッシング方法に

基づいて、アプリケーション・サーバーやデータベース・サーバーがキャッシュ・インスタンスとやり取

りできるよう、TCPとUDPのポート11211へのインバウンド・アクセスを許可してください。ルート・

ルールとセキュリティ・ルールの作成の詳細は、「参考資料」の項のセキュリティ・リストとルート表の

概要を参照してください。

OCIにMemcachedクラスタが正常にデプロイされたら、お客様のユース・ケースに基づいて、適切な種類のキャッ

シング・アルゴリズムでキャッシュ・クラスタを構成する必要があります。キャッシング方法を決定したら、適切

なセキュリティ・リスト・ルールのセットを適用し、キャッシュ・クラスタとのインバウンドとアウトバウンドの

通信を簡素化します。これについては、次で説明します。

図1 – OCI上の分散Memcachedアーキテクチャ


キャッシング方法方法はいくつかあり、適切なものを選択すると、大きな違いが生まれます。キャッシング方法は、データとデー

タ・アクセス・パターンによって異なります。つまり、データの書込みと読取りがどのように行われるかです。次

に例を示します。

• アプリケーションの書込みは多いか。(時間ベースのログなど) • データの書込みは一度で、読取りは複数回か。(ユーザー・プロファイルなど) • 返されるデータは常に一意か。(検索問合せなど)

様々なキャッシング方法を見ていきましょう。

キャッシュアサイド

特にMemcachedが関連するキャッシュでは、おそらく、これが最も一般的に使用されているキャッシング方法です。

キャッシュがそばに配置され、アプリケーションはキャッシュとデータベースの両方に直接アクセスします。

キャッシュアサイドの方法では、即時ではなく、初めて読取りが行われたときにのみデータがロードされます。

• アプリケーションはまず、キャッシュを確認します。 • キャッシュにデータがある場合は、キャッシュ・ヒットです。データが読み取られ、クライアントに返さ

れます。

• キャッシュにデータがない場合は、キャッシュ・ミスです。アプリケーションは追加の操作をいくつか

行ってデータベースに問合せをし、データを読み取り、それをクライアントに返して、同じデータに対す

る後続の読取りがキャッシュ・ヒットになるよう、そのデータをキャッシュに格納します。

キャッシュアサイドのキャッシュは、通常は汎用目的で、読取りが多いワークロードに最適です。キャッシュアサ

イドを使用するシステムは、キャッシュ・エラーに対する自己回復性があります。キャッシュ・クラスタが停止し

ても、データベースに直接アクセスすることで、システムは運用を継続できます。(ただし、負荷のピーク時に

キャッシュが停止した場合は、あまり役に立ちません。レスポンス時間が非常に遅くなり、最悪の場合には、デー

タベースが停止します。)

もう1つのメリットは、キャッシュのデータ・モデルと、データベースのデータ・モデルを別にできることです。

たとえば、複数の問合せの結果として生成されたレスポンスは、同じリクエストIDでキャッシュに格納できます。

キャッシュアサイドを使用した場合、最も一般的な書込み方法は、データベースにデータを直接書き込むことです。

これが発生すると、キャッシュとデータベースの一貫性がなくなる場合があります。これに対処するため、開発者

は一般的に、存続時間(TTL)を使用して、TTLの期限が切れるまで失効したデータの処理を続行します。データの鮮

度を保証する必要がある場合、開発者は、キャッシュ・エントリを無効にするか、後で説明するとおり、適切な書

込み方法を使用します。次に、OCIへのキャッシュアサイド・キャッシュの実装に必要なセキュリティ・リスト・

ルールを示します。

OCIへのキャッシュアサイド・キャッシュの実装に必要なステートフルなセキュリティ・リスト・ルール

方向ソース・サブネットプロトコルソース・ポート宛先ポート説明

イングレス <App subnet> TCP すべて 11211 Memcachedへのインバ

ウンド・アクセスを許可

イングレス <App subnet> UDP すべて 11211 memcachedへのインバ



図2 – キャッシュアサイド

キャッシュアサイド・キャッシュを実装するためのPython疑似コード

リードスルー

キャッシュアサイドとリードスルーのどちらの方法でも、即時ではなく、初めて読取りが行われたときにのみデー

タがロードされます。リードスルーとキャッシュアサイドは非常に似ていますが、主要な違いが少なくとも2つあり

ます。

• キャッシュアサイドでは、データベースからデータをフェッチして、キャッシュに移入するのはアプリ

ケーションの役割です。リードスルーでは通常、Memcachedライブラリによってこのロジックがサポート

されています。

• キャッシュアサイドとは異なり、リードスルー・キャッシュのデータ・モデルは、データベースと別にす

ることはできません。

リードスルー・キャッシュは、同じデータが何度もリクエストされ、読取りが多いワークロードに最適です。

ニュース記事がその一例です。デメリットは、データが初めてリクエストされた場合、結果は常にキャッシュ・ミ

スで、キャッシュにデータをロードするという余分な負荷が発生することです。


これは、Thundering herdと呼ばれます。Thundering herdの詳細は、このホワイト・ペーパーの「参考資料」の項を

確認してください。開発者は、問合せを手動で発行して、キャッシュを温める、または前もって温めることで、こ

れに対処します。キャッシュアサイド同様、キャッシュとデータベースの間でデータの一貫性がなくなる可能性も

あります。次で説明するとおり、解決策は書込み方法にあります。次に、リードスルー・キャッシュの実装に必要

なセキュリティ・リスト・ルールを示します。

OCIへのリードスルー・キャッシュの実装に必要なステートフルなセキュリティ・リスト・ルール


イングレス <App subnet> TCP すべて 11211 Memcachedへのインバウ

ンド・アクセスを許可

イングレス <App subnet> UDP すべて 11211 Memcachedへのインバウ

ンド・アクセスを許可

エグレス <cache subnet> TCP すべて 3306 MYSQL DBサブネットへ

のアウトバウンド・アク

セスを許可

図3 – リードスルー・キャッシュ

ライトスルー

この場合、アプリケーションがデータベースに書込みをすると、同時にキャッシュにも書込みが行われます。ライ

トスルー・キャッシュ単独では、それほどの働きをしているようには見えません。実際には、キャッシュが先で、

その後にメインのデータベースにデータを書き込んでいるため、さらに書込みを遅らせています。ただし、キャッ

シュアサイド・キャッシュと組み合せると、リードスルーのすべてのメリットが得られる上、データ一貫性も保証

され、キャッシュ無効化の技術を使用する必要がなくなります。


OCIへのライトスルー・キャッシュ・サブネットの実装に必要なステートフルなセキュリティ・リスト・ルール




イングレス <App subnet> UDP すべて 11211 Memcachedへのインバ


図4 – ライトスルー・キャッシュ


ライトスルー・キャッシュを実装するためのPython疑似コード。

ライトバック

アプリケーションがキャッシュにデータを書き込むと、すぐに認識され、少し遅れてデータベースにデータが書き

込まれます。これは、ライトビハインドと呼ばれることもあります。

ライトバック・キャッシュは書込みパフォーマンスを向上させ、書込みの多いワークロードに適しています。リー

ドスルーと組み合せると、最近更新され、アクセスされたデータが常にキャッシュにある混合ワークロードで効果

を発揮します。これは、特にRedisで採用されており(Memcachedではほとんど採用されていません)、負荷のピーク

時に増加がうまく吸収されます。主なデメリットは、キャッシュ・エラーがあった場合に、データが完全に失われ

る可能性があることです。そのため、Memcachedを使用する場合は、適したキャッシング方法ではない可能性があ

ります。

OCIへのライトバック・キャッシュ・サブネットの実装に必要なステートフルなセキュリティ・リスト・ルール




イングレス <App subnet> UDP すべて 11211 Memcachedへのインバ


エグレス <cache subnet> TCP すべて 3306 MYSQL DBサブネットへ

のアウトバウンド・アク

セスを許可


idx = Zlib.crc32(key) % servers.size

図5 - ライトバック・キャッシュ

Memcachedのスケーリング - コンシステント・ハッシュ

Memcachedの基本バージョンは、軽量のキャッシング・サービスであるため、永続性やレプリケーション、フォール

トトレランスがネイティブでサポートされていません。これらのサービスを提供するMemcachedの拡張(membrainやmembaseなど)も多数ありますが、軽量のキャッシュという目的に反しています。クラウド上の複数ノードに

Memcachedのインスタンスを複数スケーリングしたら、トラフィックの負荷がインスタンス間に均等に分散されるよ

う、キーが一貫して分散されることが重要です。スケーラブルなMemcachedインフラストラクチャの作成に必要な機

能のうち最も重要なものは、コンシステント・ハッシュです。コンシステント・ハッシュは、水平方向にスケーリン

グする際に、データをパーティション化する優れたツールです。インメモリー・キャッシュのスケーリングに広く使

用されています。

Memcachedはシンプルなハッシュ表で、一意のキーが1つの値にマップされています。Memcachedインスタンスが1つの場合にはシンプルですが、複数ある場合はどうすればよいでしょうか。どのインスタンスにキー/値のペアを格納

すべきでしょうか。単純な方法は、キーをハッシュ化して整数にし、インスタンス・セットのサイズに基づいて剰余

演算を実行することです。特定のキーでは、毎回、同一のランダムなインスタンスがセットから返されます。

割り当てられたインスタンスのセットが変わらない場合には、うまく機能します。うまくいかなくなる可能性がある

のは、トラフィックが急増し、セットへの新しいインスタンスの追加が計画される場合です。これが実行されると、

ほとんどのキー・ハッシュのモジュール値も変更されます。つまり、Memcachedクライアントが間違ったインスタン

スを選択してルックアップ・ミスになるため、キャッシュしている負荷の高い操作の再実行が必要になり、バックエ

ンド・データベースがスラッシングされます。キャッシュ・コンテンツが古いサーバーから新しいサーバーに切り替

わるときは、本質的に、再計算が大量に発生します。


コンシステント・ハッシュによって、この問題がどのように解決されるかを説明します。コンシステント・ハッ

シュでは、剰余演算ではなく、1つのインスタンスにマップされた値の事前定義済の連続体が使用されます。各サー

バーにランダム整数N (Nはおよそ100または200)を選択し、それらの値をN * instance.sizeの値の配列にソートしま

す。あるキーのインスタンスを検索するには、キー・ハッシュ以上の最も近い値を探して、関連付けられているイ

ンスタンスを使用します。値は仮想円を形成します。キー・ハッシュは、その円上の点にマップされ、その点から

時計回りにインスタンスを探します。コンシステント・ハッシュの仕組みの詳細は、コンシステント・ハッシュに

関するDavid Karger氏独自の資料を参照してください。

Oracle Cloud InfrastructureでのRedisの設計 Memcachedとは異なり、Redisは、単にシンプルなキー値ストア・インメモリー・キャッシュにとどまりません。

Redisは、値により複雑なデータ型を含めることができるキー値データベースと言うことも可能で、それらのデータ

型には自動操作が定義されています。Redisは、インメモリー・キャッシュの概念と、従来のデータベースの永続性、

シャーディング、マスター/スレーブ・アーキテクチャを結び付けています。また、Redisはメモリーにlistやhash、set、sorted setなどの複雑なデータ構造を格納できます。Redisにはすぐに利用できる豊富な機能があるため、デプ

ロイメント・オプションも多岐にわたります。Oracle Cloud InfrastructureでRedisクラスタの設計を始める前に、

Redisの特徴を簡単に確認します。

• 単一インスタンス・アーキテクチャ: Redisは、Redisサーバーというシングル・スレッド・アプリケー

ションとして実行されます。Redisサーバーの役割は、メモリーにデータを格納することです。あらゆる種

類の管理に対応し、アーキテクチャの主要な部分を形成します。Redisクライアントは、Redisコンソー

ル・クライアントの場合も、Redis APIを使用する任意のアプリケーションの場合もあります。これまでに

説明したように、Redisはすべてをプライマリ・メモリーに格納します。プライマリ・メモリーは揮発性の

ため、Redisサーバーを再起動すると、格納したデータはすべて失われます。そのため、データを永続化さ

せる方法が必要です。

• 永続性: Redisでデータを永続化させる方法は2つあります。Redisデータベース・ファイル(RDB)または追

加専用ファイル(AOF)です。RDBはスナップショット形式の永続性フォーマットで、メモリー内のすべて

のデータがコピーされ、セカンダリ・ストレージに格納されます。これは指定された間隔で行われるため、

RDBの最後のスナップショットより後に書き込まれたデータが失われる可能性があります。AOFは変更ロ

グ形式の永続性フォーマットで、サーバーが受信したすべての書込み操作が記録されます。そのため、す

べての操作が永続化されます。AOFの使用による問題は、すべての操作がディスクに書き込まれるため、

負荷の高いタスクだということです。また、AOFファイルのサイズは、RDBファイルより大きくなります。

• バックアップとリカバリ: Redisには、データ・ストアのバックアップとリカバリのメカニズムがありませ

ん。そのため、ストレージがクラッシュしたり、その他の災害が発生したりすると、すべてのデータが失

われます。RDBまたはAOFのスナップショットを使用し、それをOracle Cloud InfrastructureのObject Storageに格納することで、耐久性の高いストレージを実現できます。これについては、Redisクラスタの

設計を開始してから説明します。

• 部分的な高可用性: Redisでは、高可用性の目的と、書込みワークロードから読取りワークロードを分離す

る目的の両方のために、レプリケーションがサポートされています。Redisでは、読取りレプリカという1つ以上のノードに非同期的にデータがレプリケートされます。これはマスター/スレーブ・アーキテクチャ

に似ており、Redisのプライマリ・ノードが読取りと書込みの両方を処理するマスターで、読取りレプリカ

は読取りのみを処理します。すべてのスレーブには、マスターとまったく同じデータが格納されています。

マスター・ノードに障害(ディスク上のデータ損失を伴うマスターのクラッシュ)が発生した場合、Redisには、スレーブをマスターに変換する機能があります。このアクションの実行に使用できるモニタリング・

ソリューションが数多く存在し、最も普及しているRedis Sentinelでは、Redisインスタンスのサービス検

出と自動フェイルオーバーに対応しています。


• 最大の高可用性: 複雑ではありますが、クラスタリングにより、Redisインスタンスの可用性を最高レベル

にすることができます。Redisでクラスタリングを実現するには、データをパーティション化してレプリ

ケートします。パーティション化では、複数のRedisインスタンスにデータをシャーディングしますが、各

インスタンスに含まれるのはキーのサブセットのみになります。これにより、データ・ボリュームが増加

した場合に、特定インスタンスの負荷の一部がなくなり、ノード障害の場合の影響も低減されます。Redisでは、レンジ・パーティション化やハッシュ・パーティション化など、パーティション化のプリミティブ

型がサポートされています。マルチディメンションのsetやlist、hashなどのデータ構造は水平方向にシャー

ドできないため、コンシステント・ハッシュはネイティブではサポートされていません。ただし、シンプ

ルなキーと値のペアを格納するためだけにRedisを使用している場合は、コンシステント・ハッシュを使用

できます。

デプロイメント・プラン

Redisを正常にデプロイするには、管理者が複数のファクタを重み付けする必要があります。

• ワークロードのタイプ: 書込みの多いワークロードは本質的に、大量のメモリーを必要とする傾向にありま

すが、Redisの場合は、AOFスナップショットの取得や、クラスタ・プライマリとフェイルオーバーするレ

プリカとの同期、またはフェイルオーバー後におけるクラスタ・プライマリへのレプリカの昇格で追加の

メモリーが必要になります。インスタンスのメモリー・サイズは、データのみで必要な量の2倍にして選択

することをお薦めします。

• メモリー: 現在必要なメモリーの量に、データの増加率も考慮してください。

• 操作モード: Redisを非クラスタ・モードで実装する場合は、すべてのデータと、前述のようなオーバー

ヘッドに対応するために、インスタンスに十分なメモリーが必要であることを考慮してください。クラス

タ・モードで実装する場合は、スナップショット/同期のオーバーヘッド用のメモリーに対応するだけでな

く、シャード用に十分な量のメモリーを用意することも事前に計画しておきます。これは、Redisバージョ

ン3.x以前では、クラスタの再シャーディングは簡単なプロセスではなく、ダウンタイムの原因となる傾向

があるためです。

インスタンス・シェイプの選択

Redisのパフォーマンスに直接影響する要因は複数あり、インスタンス・シェイプの選択で重要な役割を果たします。

詳細は、Redisのベンチマークを参照してください。

• ネットワーク帯域幅: 多くの状況で、Redisのスループットは、CPUで制限されるよりも前に、ネットワー

クの影響を直接受けます。Redisは、最適なパフォーマンスのために、少なくとも10GbpsのNICの使用を

推奨しています。

• CPU: Redisはシングル・スレッドであるため、キャッシュが大きく、コア数が多くない高速なCPUが適し

ています。古いハイパーバイザを使用すると、この問題の悪化に拍車がかかります。

• 仮想化: Redisは、ベアメタル・インスタンスと比較した場合、仮想環境では実行速度が大幅に落ちます。

ネストした仮想化はどのようなものでも、使用するとこの状況を悪化させるだけです。

前述の要件をすべて考慮すると、Redisのパフォーマンスが最適になるのは、仮想化されておらず、ネットワークが

最適化された高メモリー・インスタンスです。優れたパフォーマンスを必要とする書込みの多いワークロードが大

量にある場合は、オラクルのBM.Standard1.36ベア・メタル・インスタンスを使用できます。このインスタンスでは、

仮想化されていない環境だけでなく、10GbpsのネットワークI/Oと36 OCPUの256GBのメモリーも提供され、複数

のRedisサーバーを単一インスタンスで実行するオプションもあります。通常のワークロードの場合は、低いコスト

で優れたパフォーマンスが得られるVM.DenseIOインスタンスを使用できますが、仮想化のオーバーヘッドがありま

す。


Oracle Cloud InfrastructureでのRedisクラスタの構築 Redisの一般的な設計パターンでは、書込みが非常に多い小規模なデータ・ワークロードがRedisに誘導され、大規

模なBLOBのデータはSQLまたは結果として一貫性の高いディスク上のデータベースに誘導されます。Redisは、

ディスク上のデータベースに格納されているものと同じデータのサブセットのインメモリー・コピーを維持するた

めに使用される場合もあります。Redisにはある程度のACIDプロパティがありますが、その実装は簡単ではありませ

ん。アプリケーションに厳密なACID要件がある場合は、Oracle Cloud InfrastructureのDatabaseサービスのような本

当のRDBMSを使用して、原子性や一貫性、分離性、永続性を保証することをお薦めします。それでは、OCIにRedisインスタンスをデプロイしてスケーリングする一般的な2つのパターンを順に見ていきましょう。

クラスタ化されていない複数のADデプロイメント

Redisで読取りレプリカを使用すると、読取りと書込みのワークロードを分離できます。分離することにより、アプ

リケーションの成長に伴ってレプリカを追加すれば、読取りをスケーリングできます。このシナリオでは、2つの

別々の可用性ドメイン(AD)にRedisノードをデプロイしますが、こうすることで、AD全体で予想外に障害が発生し

た場合でも、高可用性を実現できます。アプリケーション・サーバーからの書込みを処理するRedisマスターを一方

のADに配置し、読取りを処理する複数の読取りレプリカ(スレーブ)を両方のADに配置します。また、Redis Sentinelもプロビジョニングして、マスターに障害が発生した場合に、読取りレプリカの1つをマスターに変換して、

Sentinelが迅速にフェイルオーバーするようにします。それでは、デプロイのステップを順に見ていきましょう。

• アプリケーション・サーバー、Redisサーバーおよびデータベース・サーバーの格納に十分な大きさのVCNを作成します。VCNの作成方法および関連するベスト・プラクティスの詳細は、『仮想クラウド・ネット

ワークの概要およびデプロイメント・ガイド』を参照してください。

• 2つの別々の可用性ドメインに、2つのパブリック・サブネット(AD1とAD2とします)を作成し、要塞インス

タンスとパブリック・ロード・バランサをホスティングするDMZサブネットとして機能させます。Oracle Cloud Infrastructureでは、VCNのサブネットは特定のADにバインドされています。各ADにサブネットを1つずつ作成します。

• アプリケーション・サーバー間のトラフィックをロード・バランシングするパブリック・ロード・バラン

サのペアを作成し、DMZサブネットに配置します。OCIのパブリック・ロード・バランサは、高可用性を

実現するため、設計により、アクティブ/スタンバイのペアになっています。アクティブとスタンバイは、

サブネットも可用性ドメインも別のところに配置する必要があります。


らのサブネットも、VCNは同じであることを確認してください。

• AD1とAD2にプライベート・サブネットを2つずつ作成し、Redisインスタンスを格納します。一方の可用

性ドメインにRedisマスターを配置し、読取りレプリカをAD1とAD2に分散します。最後に、これらのイン

スタンスにSentinelを設定し、Redisインスタンスのアクティブ・モニタリングを可能にします。



を作成できます。

• 作成したサブネットに適切なルート表ルールとセキュリティ・リスト・ルールを作成します。Redisサー

バーのサブネットに忘れずにセキュリティ・ルールを作成して、TCPポート6379へのインバウンド・アク

セスを許可し、アプリケーション・サーバーやデータベース・サーバーがRedisインスタンスとやり取りで

きるようにします。


図6 – OCIにおける複数ADへのクラスタ化されていないRedisのデプロイメント

複数ADへのクラスタ化されたデプロイメント

クラスタ化されたアーキテクチャでは、複数のRedisインスタンス間でデータのパーティション化とレプリケーショ

ンを行います。これは、1つのRedisインスタンスによってメモリーに格納されるデータのボリュームが、非常に大

きい場合に特に便利です。特定のマスターには常にキーのサブネットのみが格納されるよう、データが複数のマス

ター・ノードにシャーディングされます。クラスタ化されていない場合と同様に、マスターのデータを複数の読取

りレプリカにレプリケートして、読取りと書込みを分散できます。このシナリオでは、2つの別々の可用性ドメイン

(AD)にRedisマスター・ノードを配置し、それぞれに実際のデータのサブセットを格納します。シャーディング・ロ

ジックは、お客様のユース・ケースに基づいて決定できます。それぞれのADに、複数の読取りレプリカを配置し、

マスターからの読取りを処理します。それでは、デプロイのステップを順に見ていきましょう。

• アプリケーション・サーバー、Redisサーバーおよびデータベース・サーバーの格納に十分な大きさのVCNを作成します。VCNの作成方法および関連するベスト・プラクティスの詳細は、『仮想クラウド・ネット

ワークの概要およびデプロイメント・ガイド』参照してください。

• 2つの別々のADに、2つのパブリック・サブネット(AD1とAD2とします)を作成し、要塞インスタンスとパブ

リック・ロード・バランサをホスティングするDMZサブネットとして機能させます。Oracle Cloud Infrastructureでは、VCNのサブネットは特定のADにバインドされています。各ADにサブネットを1つずつ作

成します。

• アプリケーション・サーバー間のトラフィックをロード・バランシングするパブリック・ロード・バランサ

のペアを作成し、DMZサブネットに配置します。OCIのパブリック・ロード・バランサは、高可用性を実現

するため、設計により、アクティブ/スタンバイのペアになっています。アクティブとスタンバイは、サブ

ネットもADも別のところに配置する必要があります。詳細は、OCIのLoad Balancingを参照してくださ

い。


らのサブネットも、VCNは同じにしてください。

• AD1とAD2にプライベート・サブネットを2つずつ作成し、Redisインスタンスを格納します。一方のADに

Redisマスターを1つ配置し、2つ目のADに別のマスターを配置します。同じADにマスターの読取りレプリ

カを作成します。最後に、これらのインスタンスにSentinelを設定し、Redisインスタンスのアクティブ・モ

ニタリングと、障害が発生した場合のマスターのフェイルオーバーを可能にします。




を作成できます。

• 作成したサブネットに適切なルート・ルールとセキュリティ・ルールを作成します。Redisサーバーのサブ

ネットに忘れずにセキュリティ・ルールを作成して、TCPポート6379へのインバウンド・アクセスを許可

し、アプリケーション・サーバーやデータベース・サーバーがRedisインスタンスとやり取りできるように

してください。

図7 – OCIにおける複数ADへのクラスタ化されたRedisのデプロイメント

Oracle Cloud InfrastructureにおけるRedisのバックアップとリストア前述したように、永続性は、AOFおよびRDBの形式でRedisに組み込みます。Redisは、特定の間隔でポイントイン

タイム・スナップショットを取得するか、書込みが行われるたびにディスク上の追加専用ファイルに非同期で書き

込むことで、データをディスクに定期的にバックアップしています。ディスク上でバックアップのボリュームが増

大した場合は、これらのバックアップをより耐久性の高いストレージに保存して、インスタンス障害の場合にも

バックアップが失われないようにする方法が必要です。

Oracle Cloud InfrastructureのObject Storageは、耐久性が高く、拡張性に優れたオブジェクト・ストアで、Redisのバックアップ・スナップショットを保存する一元的なストアとして使用できます。Object Storageでは、AWSのS3など、その他のプロバイダのオブジェクト・ストアと互換性のあるAPIも提供されているため、Redisバックアップ

をOracle Cloud Infrastructure上のObject Storageに移行することも可能です。Object Storageの詳細は、Oracle Cloud Infrastructureのドキュメントを参照してください。

注意: Redisのバックアップの実装を計画している場合、Redisでは、バックアップ中に余分なメモリーが消費さ

れることを覚えておいてください。これは、Redisが書込みセマンティクスで標準のコピーを使用し、バックアッ

プ・データを書き込むバックグラウンド・プロセスを分岐するためです。メモリー要件の詳細は、このホワイ

ト・ペーパーのRedisデプロイメント・プランの項を参照してください。


結論このホワイト・ペーパーでは、MemcachedとRedisを使用して、Oracle Cloud Infrastructureに可用性の高い分散

キャッシング・レイヤーを設計する説明をしました。このホワイト・ペーパーで説明したステップに従うことで、

MemcachedまたはRedisクラスタを簡単にデプロイし、アプリケーションのパフォーマンスと自己回復性を高める

キャッシング方法を使用できます。また、分散インメモリー・キャッシング・レイヤーに関連するユース・ケース

やベスト・プラクティス、いくつかのスケーリング方法についても説明しています。

参考資料

• Oracle Cloud Infrastructureの概要

• Oracle Cloud Infrastructure Networkingの概要

• Oracle Cloud Infrastructureセキュリティ・リストの概要

• Oracle Cloud Infrastructureルート表の概要

• Oracle Cloud Infrastructure Load Balancingの概要

• Oracle Cloud Infrastructure Databaseの概要

• Oracle Cloud Infrastructure Computeの概要

• VCNのデプロイメントおよびベスト・プラクティス・ガイド

• MemcachedのWiki

• Redis Sentinel

• キャッシング方法

• TCPインキャスト

• Redisのベンチマーク

• The Twelve-factor app

• コンシステント・ハッシュの参照

Oracle Corporation, World Headquarters Worldwide Inquiries 500 Oracle Parkway Phone: +1.650.506.7000 Redwood Shores, CA 94065, USA Fax: +1.650.506.7200

CONNECT WITH US

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2018, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記

載されている内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、

口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、

いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本

文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もっ

て得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信すること

はできません。

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標であ

る場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、

SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。0218

ホワイトペーパー: MemcachedおよびRedisを使用したOracle Cloud Infrastructureでの高可用性分散キャッシュ・レイヤーの

デプロイ2018年2月著者: Abhiram Annangi

Documents

ORACLE WHITE PAPER | 2018 2 1...MemcachedおよびRedisを使用した Oracle Cloud Infrastructureでの高可用性 分散キャッシュ・レイヤーのデプロイ ORACLE WHITE

ORACLE WHITE PAPER | 2018 2 1...MemcachedおよびRedisを使用した Oracle Cloud Infrastructureでの高可用性分散キャッシュ・レイヤーのデプロイ ORACLE WHITE