sidekiq + redisの構築(Rails 4系) 4-1
インフラの準備を分割して書いていきます。
前提環境:
検証環境として、立てていきます。(EC2はのぞく)
EC2
EC2は立てている前提で、サーバにsshで接続して、redis(client)とmonitをインストール
# ssh -i ~/.ssh/[秘密鍵] ec2-user@example.co.jp $ sudo yum install -y monit $ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm $ sudo yum --enablerepo=remi install redis
ElasticCache(Redis 4)
費用面を抑えたいということで冗長性を犠牲にし、将来的に依存する構成・機能になった際には、タイプを上げること、ノードを増やして１ノードが落ちた際の対応を進めて、冗長性を高める(想定)。
要件が集計用のデータを扱うので、redisの障害により止まったとして、復旧後、再アップロードすることでよしとしてもらう(相談済)
アプリ側の制限として
- redisのメモリ不足を発生させないように、クラスのインスタンスを渡せるのだが、idを渡す。
- キューにエンキューするジョブは、再度ジョブを入力しても同じ結果になるようにする(通知系、データ集計.. etc)
- キューに保存する前に、DBにアクションのレコードを保存する
非同期で扱えるキューが有用なのは判断できているので、信頼性をそのほか(アプリケーション、DB)で担保します。(完全には不可能な場合は、再実行で対応できるように)
Elastic Cache
サービスからElastic Cacheを選択する。
サイドメニューからRedisを選択する。
作成するボタンを選択する
Redisの設定
- 名前: redis_
- 説明:
- エンジンバージョン:4.0.10
- ポート: 6379
- パラメータグループ: default.redis4.0
- ノードのタイプ: t2.cache.t2.micro
- レプリケーション数: 2
- 自動フェイルオーバーを備えたマルチAZ: チェック無し
- サブネット: デフォルト
- 優先アベイラビリティゾーン: 指定なし
セキュリティ
- セキュリティグループ: redis-cache: 6379をインバウンドで許可したセキュリティグループ(EC2に追加)
- 保管時の暗号化: チェック無し
- 送信時の暗号化: チェック無し
クラスターへのデータのインポート シードするRDBファイルのS3の場所:
バックアップ: 自動バックアップの有効か: チェック無し
メンテナンス メンテナンスウィンドウ: 指定無し
SNS通知のトピック: 通知の無効化
作成ボタンを選択する
次にクラスター名をクリックして、プライマリエンドポイントをコピーしてアプリケーションから参照できるようにする。
課題
サイズ変更に伴う指標の確認
スケーリング問題の早期通知の取得 – リシャーディングは計算処理能力を集中的に使用するオペレーションであるため、リシャーディング中は CPU 使用率をマルチコアインスタンスで 80% 未満、シングルコアインスタンスで 50% 未満にすることをお勧めします。Redis 用 ElastiCache メトリックスをモニタリングして、アプリケーションでスケーリングの問題が発生する前にリシャーディングを開始します。追跡すると有用なメトリックスは、CPUUtilization、NetworkBytesIn、NetworkBytesOut、CurrConnections、NewConnections、FreeableMemory、SwapUsage、BytesUsedForCache です。
上記の通知が発生した段階で利用するノードタイプを変更するタイミングの指標にする。
クラスター・レプリケーションへの変更タイミングの時間帯
また、メンテナンスのタイミングについて、今回指定無しにしているが、クラスター・レプリケーションへの変更を延期している場合にメンテナンスのタイミングで変更が行われる。この期間を指定して、変更時のアクセス障害が起きるのを回避もしくは起きづらい時間帯に指定する。(深夜帯にアクセスが起きづらいタイプのサービスでは、深夜帯に指定する) (ダウンタイムが発生する恐れがあり、ユーザのアクセスを防げない場合には、アプリのメンテナンスとして、ユーザに通知する措置が必要になってくる)
参考
Amazon ElastiCache （インメモリキャッシュ管理・操作サービス） | AWS
