Route 53 とスポットインスタンス を利用してスパイクを処理する
＊この記事は「CDP Advent Calendar 2013 on Zusaar」の22日分のエントリーになります。 #awscdp #jawsug
CDP Advent Calendar 2013 on Zusaar
CDP！CDP！みなさん使ってますか？CDPを。
直接的にパターンにならなくても、パターンを意識してシンプルに設計出来ると
いいですよね。本当に。
今回はそんなCDPに既存のパターンを組み合わせた提案を1つ
配慮が足らない部分もあるかと思いますが少しお付き合いください。
はじめに
スパイクってどの程度の？
そもそもAuto Scaling を利用すれば対応できるのでは？
というあたりは、以下の発表資料にグラフを載せています
グラフを見ると
で、そこからのグラフ画像だけ転載
上の画像が1週間分のグラフで下の画像が1ヶ月分のグラフですが
それぞれ タケノコみたいに生えてる部分がっ！
これは意図して特異的なグラフ画像を採用していますが
実際のグラフであることは間違いないです
ある程度予測可能かつ日時や時間限定でのスパイクアクセスに対応したい場合
単純にAuto Scalingの設定を変更して最低稼働台数をピークに合わせて
もいいのですが、今回は別の方法を提案してみたいと思います
Route 53 を使う
Route 53には重み付けラウンドロビンを行うことができます
この機能を使ったCDPが私の好きな「Weighted Transitionパターン」ですね
Route 53のこの機能は非常に有用かつ柔軟で、重み係数を0にすると0に設定
された側にリクエストを送信しなくなります。
今回提案するパターンのポイントの1つとなります
EC2 スポットインスタンス を使う
Route 53以外でパターンのポイントとなるのが「Amazon EC2 スポットインスタンス 」です
リザーブドインスタンスを持っている場合や、料金なんて関係ないっていう
富豪の方はこの限りではありませんが、前述した通り期間が限定的なので
スポットインスタンスとの相性がいいのは間違いないと思います。
実際の構成案
じゃー実際にはどうやって使うのか？
前提条件としては以下のような場合を想定しています
- 大量アクセスになる可能性が予測可能
- 例えばTV放送が決まっている
- 気象条件でアクセスが変わる傾向が見えている
- など
- アクセス増加が期間限定的
- 1日や1時間など比較的短い場合
- スポットインスタンスを使う場合
- クリティカルなシステムではない
- 応答不能になるのは避けたい
まずは基本の「CDP:Scale Outパターン 」での実現の場合
すぐに思いつくのがAuto Scalingの設定変更となります
これまではAWS マネージメントコンソールから操作が出来ませんでしたが
先日のアップデート で操作可能になっています。
それじゃーそれで設定変更・追加すればいいじゃんって話になりますが
それだと話が終わっちゃいますのでご容赦ください
Weighted Expandパターン
正常稼動している仕組みに手を入れたくないって場面は少なからず
あったりしますよ。ＡＷＳなら同じ簡単に作れて試せてしまうので
あんまり困らないんですけども、前述しているように限定的な期間の為に
いろいろやるのか？っていう部分もあり悩みどころですね
そんなときこそ今回の提案パターン！
見ていただければ単純なのでわかると思いますが
Auto Scaling を設定して構成してある方には手を付けず
Route 53 の機能で別の構成にアクセスを流します
この別の構成はAuto Scaling の設定をあえて行わず
手動でEC2の増減を行えるようにしてあります
また、この別構成でスポットインスタンスを積極的に利用することにより
既存構成でのAuto Scaling 設定を変更した場合より料金を抑えられると思います
注意点
前提条件にも書いてありますが、ある程度の条下での提案ですので
それに伴う注意点があります
また、簡単な検証は行っていますが実際に使用するまえにはご自身での確認をお願いします。
- Route 53 のTTL設定
- ラウンドロンビンの設定を行うので当然だが最初からTTLを短く設定する必要がある
- TTLが短くてもDNSリゾルバキャッシュで片側にしかアクセスが来ない場合がありそう
- スポットインスタンスのコントロール
- 大量アクセス対応時の作業
- ELB暖気運転の申請などの大量アクセス時の作業は忘れずに行う必要がある
- RDSなどを背負っている場合
- 単純なWebサーバやアプリケーションサーバであれば問題はない
- 背後にRDSなどがある場合は当然ながらこの部分の考慮が必要となる
＊他にも何かお気づきの点がありましたら、ぜひフィードバックをお願い致します！
利点と拡張性
今回の提案の利点とその他の思いつく拡張性は
- 既存環境に手を入れずにRoute 53の設定変更だけ
- 利用する場合、利用が終わった場合どちらでも既存環境からの切り離しが容易
- Route 53を使うことにより柔軟に拡張可能なパターン
- レイテンシを気にしないのであれば、東京リージョンである必要もない
- 既存環境と一時環境という構成なのでRoute 53の重み付けラウンドロビン対象が2つである必要もない
- スポットインスタンスを利用する場合
- 金額面でのコストがかからない
- 金額のリミットが決まっているなら、一時間環境を既存環境よりも高性能なインスタンス郡で構築することも可能
- レイテンシを気にしないのであれば、海外リージョンを使うことも出来る
- 海外リージョンは金額が安いのも魅力的
- 海外リージョンは時差の関係で東京リージョンのピークタイム時に海外リージョンは真夜中のアイドルタイムとなっていてスポットの確保が容易で種類も多い場合がある
- 一時環境の利用用途
- 大量アクセスを処理するための用途以外にも使用できる可能性
- A/Bテストのような性能比較
- 既存環境のメンテ・更新中の一時的受け入れ先として利用
となります
既存環境との関係がなくRoute 53によって祖結合になっているため
一時的に何かを行う場合には非常に有用かと思います。
最後に
まだまだな感じもありますが、こんなCDPいかがでしたでしょうか？
何かありましたらぜひフィードバックをお願いします
みんなで楽しくCDP！CDP！
最後に先日目撃したあのパターンの写真をどうぞ！
