アプリケーションから便利にキャッシュを使いたい!
そんな時、AWSに素敵なサービスがあるようです!
そうです、ElastiCacheです!

そもそもキャッシュって?一般的な使いどころは?

ElastiCacheが適している用途のうち、「インメモリデータキャッシュ」の欄に一般的な使いどころが簡単にまとめられています。
(より具体的なキャッシュ戦略についても!)

さて、ElastiCacheとは?

分散型メモリキャッシュ

複数のキャッシュノードから成るキャッシュクラスターを、数分以内に作成できる

– 【AWS発表】 Amazon ElastiCache – 分散型メモリキャッシュの新サービスを発表

ふむ。

Memcached または Redis を使用する既存のアプリケーションは、ほとんど変更を加えずに ElastiCache を使用できます。

– Amazon ElastiCache とは

なんか分散型とかむずかしそうですが、Memcached や Redis をAWSがよしなにやってくれるやつというところでしょう!

ひとまず EC2 から ElastiCache(Redis) を使えるように設定してみて、習うより慣れてみましょう!

目標

EC2 から ElastiCache(Redis) に接続できるようにする

※ ElastiCache は同 VPC 内の EC2 からアクセスする前提のようです。
※ こちらは例外: AWS 外部からの ElastiCache リソースへのアクセス

手順

1. AWS コンソールから「ElastiCache」を選択

AWSコンソールから「ElastiCache」を選択

アイコンは「エ」ラスティック…の「エ」ですね(適当
斎藤工の「工」かな?(適当

2. Get Started Now

Get Started Nowをクリック

3. エンジンを選ぶ

エンジンを選ぶ

今回はRedisでいきましょう。

4. クラスター設定

クラスター設定

…なんか急にむずくなりますね。

クラスターって何…。
– ElastiCache クラスター

まあ一つ一つ見ていきましょう。

まずは前半部分。

  • Engine Version
    とりあえず最新にしときます。
  • Port
    Redis のデフォルトポート番号は 6379 ですね。
  • Parameter Group
    パラメータグループとな。なんかRedisの設定を一部アレンジできるようです。
    今回はデフォルトで。
  • Enable Replication
    チェックするとRedis のレプリケーションが有効になります。今回は有効で。
    チェック外すと後半部分の設定項目が変わりますね。
  • Multi-AZ
    レプリケーションにチェックが入ってると出てきます。
    チェックするとMulti-AZが有効になって、なんかあった時に自動フェイルオーバーが発動するようです(マスターに何かあった時にレプリカの一つがマスターに昇格する的なやつ)。
    注意事項もいろいろ。t2 インスタンスだとサポートされてないとか。
    – マルチ AZ と自動フェイルオーバーをサポートするレプリケーショングループ (Redis)

次に後半部分。レプリケーションするバージョンです。

  • Replication Group Name / Description
    レプリケーショングループなるものを作成することになるようです。
    名前と説明は今回適当に。
  • Node Type
    サーバスペックですね。今回テスト用なんで、一番小さい t2 インスタンスで良かったんですが、いろいろ制約があるので、今回は cache.m3.medium に。
  • Name of Primary / Name (s) of Read Replica (s)
    名前はレプリケーショングループのものがそれぞれ適用されるようですね。
  • Number of Read Replicas
    リードレプリカ数を指定します。今回は2つで。
  • S3 Location of Redis RDB file
    Redisのバックアップファイル(スナップショット)を指定したS3のパスに配置しておくと、起動時にそのファイルを読み込んで起動してくれるようです。今回は特に必要ないので空欄のままで。

Q: S3 に保存された独自の RDB スナップショットを使用して、Redis 用 ElastiCache クラスターのウォームスタートを行うことはできますか?

はい。コンソールの [Launch Cache Cluster] ウィザード、または CreateCacheCluster API から、クラスターを作成する際に RDB ファイルの S3 の場所を指定できます。

– よくある質問

5. さらに設定

Configure Advanced Settings

…うーむ。
続いてネットワークやバックアップ間隔、メンテナンスについての設定です。
今回は VPC 内にクラスターを起動する前提です。
VPC?て方はこちらの記事を!
– 【AWS入門】ゼロからVPCを作ってみる

  • Network & Security
    • Cache Subnet Group
      あらかじめ「キャッシュサブネットグループ」ってもんを作っときます(後述)。
      今回は「test-lab-subnet-group」ってのを作っといたので、それを選択します。
    • Availability Zone (s)
      • Primary / Read Replica (s)
        今回はデフォルトで。
    • VPC Security Group (s)
      クラスターへのアクセスを制限するために、VPC で作成したセキュリティグループを選択します。複数設定可能です。今回はあらかじめ「test-lab-ElastiCache」というセキュリティグループを作成しておきました。
      – VPC のセキュリティグループ
  • Backup
    • Enable Automatic Backups
      チェックして自動バックアップを有効にします。
    • Backup Retention Period
      設定した間隔で自動バックアップを行います。今回はデフォルトの「1日」ごとに。
    • Backup Window
      バックアップ可能な時間のことを「バックアップウィンドウ」って言うんですね、知らなかった…。今回は仮に、深夜3時(JST)からの1時間としてみます。

      Q: バックアップウィンドウとは何ですか? なぜそれが必要ですか?

      推奨されるバックアップウィンドウは、お使いの Redis 用 ElastiCache クラスターバックアップが開始される、ユーザーが定義した期間です。これは、1 日の特定の時間にバックアップを実行したり、使用量が特に高い時間帯にバックアップを避けたりしたい場合に役立ちます。

      – よくある質問

  • Maintenance
    • Maintenance Window
      こちらはパッチ適用などのプラットフォームのメンテナンス時間を設定する項目のようです。仮に木曜日の深夜4時(JST)からの1時間としてみます。

      Q: メンテナンスウィンドウとは何ですか?キャッシュノードは、ソフトウェアメンテナンス中も使用できますか?

      Amazon ElastiCache のメンテナンスウィンドウは、要求または必要とされるイベントで、ソフトウェアのパッチ適用が発生した際に、それをコントロールする機会として考えることができます。「メンテナンス」イベントが特定の週に予定されている場合、お客様が特定した60分のメンテナンスウィンドウ中の一定の時点で、開始されて完了します。

      – よくある質問

    • Topic for SNS Notification
      Amazon SNSと連携して、クラスターのイベントの通知を設定することが可能のようです。
      今回は設定せず。
      – ElastiCacheAmazon SNS 通知の管理

途中、「キャッシュサブネットグループ」てのが出てきました。これは各クラスターが稼働するサブネットを指定するものになります。
– サブネットおよびサブネットグループ

作り方は以下のような感じです。

  1. Create Cache Subnet Group
    Create Cache Subnet Groupを選択
  2. VPC を選択して、サブネットを追加
    VPC を選択して、サブネットを追加

6. 設定を確認して、レプリケーションを起動

レプリケーショングループを起動

ついに起動の時が!

エラー

なんか怒られた…。
キャッシュサブネットグループに ap-northeast-1c のサブネットがないよってことらしいです(手順 5. の Availability Zone の設定で、一部 ap-northeast-1c を指定してるにもかかわらず!)
登録してるサブネットを確認してみると、確かに ap-northeast-1c のものがありませんでした…。

サブネットを追加して再度起動ボタンを押したら…

サブネットを追加して再度起動

行けましたね!

7. EC2 から接続確認

では適当な EC2 インスタンスを立ち上げて、Redis への接続を確認します!

先ほど立ち上げた ElastiCache クラスターと同じ VPC 内にインスタンスを起動します。
(今回は、起動する際に専用のサブネットを新規作成しました)

VPC 内にインスタンスを起動

はじめて t2.nano 使いました(余談

このインスタンスにログインして、Redis のクライアントをインストールします。

[sourcecode lang=”bash”][ec2-user@ip-10-0-0-13 ~]$ sudo yum –enablerepo=epel install redis[/sourcecode]

また接続先URLとして、レプリケーショングループ一覧から確認できるエンドポイントURLを指定します。

エンドポイントURLを指定

いざ接続!

いざ接続!

あれ…全然応答がない。

ElastiCache 側のセキュリティグループの設定で、さっき起動したインスタンスからのアクセスが許可されてないのが、敗因でした。

インスタンスからのアクセス許可

適当に追加しました(本当はインスタンスのIPとかじゃなくてセキュリティグループ作って指定しよう!)。
さて…

セキュリティグループを作って指定しよう

キターーー!

キターーー!

操作も問題なさそうです。

まとめ

ElastiCache 素敵。

メリット

あわせて読みたい記事