Netflix のスケール - オートメーション編

遅くなったけど続編。前回 TODO にしてたスケールアウトのオートメーションあたり。AWS のオートスケールについては、本家ドキュメントに一通り書いてあります。その機能を大まかにまとめると、
  • スケールアウト、バランシングが自動化できる
    • 複数のゾーン (Availability Zone) にまたがっていても一元管理できる (AZRebalance
    • ELB を指定してインスタンスを追加できる
  • 不健全なインスタンスを自動的に入れ替えれる

>>> オートスケールの設定

大きく分けると 3 つのステップ
  1. CPU やメモリ等のリソースを識別する
  2. CloudWatch に各リソースをモニタリングするためのメトリクスを作成する
    デフォルトでモニタリング可能なリソースが用意されている (デフォルトで用意されているリソース
    • EC2 の CPU 負荷、ディスク I/O、ネットワーク I/O
    • ELB のホスト数 (健全/不健全)、リクエスト数、レイテンシ
    Netflix 推奨は ELB の rps (req/sec
    クラスメソッドさんがカスタムメトリクスの追加について超わかりやすく解説されています。
  3. リソースの変化に基づくアラームやオートスケール等のポリシーを定義する
    • ポリシーベース: 負荷が高くなったら EC2 インスタンスを増やし、負荷が減ったら EC2 インスタンスを減らす
    • スケジュールベース: 負荷の予測が可能な場合は、インスタンスの増減をスケジュールする (バッチ処理にも素敵

>>> Netflix がオートスケールから学んだこと

Netflix さんが実際にオートスケールを運用して、その結果をフィードバックされています。以下抄訳とかメモとか
  • 早めにスケールアップ
    例えば負荷テストで 25rps (rec/sec) を超えると待ちが発生するとする。その場合は待ちが発生しないように、20rps を超えた際にキャパシティーを増やすよう設定する。この rps の上限設定は以下の目的がある。
    1. オートスケールイベントのトリガーでは間に合わない程の、予想をはるかに超える rps もありうる
    2. このバッファーが "キャパシティスパイラル" を回避するセーフティーネットとなり、徐々にキャパシティを増やせるようになる
    3. インスタンスの起動失敗によるキャパシティ不足を予防する (追記
    Netflix の推奨設定
    • 目標値 (25rps 等) の 75% (20rps 等) が目安
    • イベントのトリガーは 5 分 ～ 10 分 (EC2 やアプリケーション等、インスタンスの起動時間を考慮
    メモ): rps による効果的なオートスケールには、まずちゃんと負荷テストするのが大事
  • ゆっくりスケールダウン
    スケールダウンを開始する時間は、スケールアップを開始する時間より長くする。上記の例に引き続き、例えば 5 分間 20rps を超えた場合にスケールアップするとする。この場合、20 分間 10rps 未満の場合にスケールダウンする。 時間差は 4 倍にする 。理由は、ご検出によるスケールダウンを防ぐため。例えば、中間層のサービスの場合、周辺サービスが完全、部分的な機能停止した場合にもスケールダウンしてしまう可能性があります。周辺サービスがオンラインに戻った時に、中間層のサービスのキャパシティが足りない可能性があります
  • Availability Zone のキャパシティ
    複数の AZ にまたがってオートスケールグループを作成する際、パーセンテージベースのスケールポリシーを使うのは注意が必要。小規模の場合は特に。負荷が偏り、キャパシティ不足のゾーンが出来てしまう。
    ※ パーセンテージベースのスケールポリシーを使う場合の注意点をそのうち公開してくれるっぽい
  • 細かいアップ/ダウンアラームを避ける
    細かいアラームを設定するとキャパシティのスラッシングが発生する。例えばロードアベレージを小さな値でアラームを設定してしまうと、予期しないスケールが発生する。発生時間が短ければさらなる問題が。例えば、ログローテーションやCPU スパイクによりスケールしてしまう。
  • シンメトリックな Percent
    キャパシティのスラッシングを防ぐために、シンメトリックにオートスケールポリシーを作成する。例えば 10% 拡大し、10% 縮小する。2 つが異なっている場合は、極端なキャパシティーの増加が発生し、その後すぐ削除される (ほんとは 10 インスタンスの追加のはずが、100 インスタンス追加して、90 インスタンス削除するとか) ことによるキャパシティのスラッシングが発生します。
  • シンメトリックな Period (1分 ～ 2週間)
    CloudWatch は 300, 600 等集計期間が異なると、総計の結果が異なります。細かい値の場合は特に。これにより意図しないスケールが発生する可能性がある。

>>> Eureka (LB / フェイルオーバーツール

ふたたび V 先生ドリブン。Netflix が先日 Eureka というツールを OSS として公開しています。簡単に言うと、Web トラフィックを対象にしたロードバランシング / フェールオーバーツールが ELB, CloudWatch なのに対し、中間層のサービス (Netflix の場合は Cassandra, memcached 等) を対象にしたロードバランシング / フェールオーバーツール。P2P 型ロードバランサ？以下、抄訳
なぜ Eureka が必要なのか 一般的なロードバランサは IP やホスト名をベースに動作しますが、AWS ではロードバランサへのサーバの追加と削除が必要。また、AWS は中間層のサービス用のロードバランサを提供していないため。
ELB と何が違うか ELB は Web トラフィックをロードバランスするためのソリューション。 Eureka は中間層のサービス用。理論的には ELB 配下に中間層のサービスを配備できるけど、それだとインターネット上に公開することになってしまう。
ELB を含むプロクシベースのロードバランサはセッション維持 (sticky session) 機能を提供しますが、Eureka はデフォルトではセッション維持を提供しない。Netflix の中間層のサービスはほぼステートレスであり、AWS 上でのオートスケールではセッション維持のないロードバランスの方が良い。
ELB が代表的なプロクシーベースのロードバランサなのに対し、Eureka は インスタンス/サーバ/ホスト レベルでロードバランスする。クライアントインスタンスが通信するサーバのすべての情報を知っている。
もうひとつのプロクシベースのロードバランサと Eureka の大きな違いは、利用可能なサーバの情報をクライアントがキャッシュしているため、ロードバランサーが停止してもすぐに復帰できること。少量のメモリを必要とするけど、復帰が早い。プロクシーを介さず、サーバーとダイレクトに通信するため、若干レイテンシも下がる (素敵)。
Route 53 と何が違うか Route 53 はネーミングサービスなのに対し、Eureka は中間層のサーバにネームを提供する。Route 53 も AWS 意外のデータセンタ用に DNS レコードをホスト出来る。また、AWS 内でレイテンシベースのルーティングも出来る。Eureka は内部 DNS と似ており、インターネット上の DNS とはまったく関係がないし、どの AWS リージョンのサーバかも知らない。Eureka の主な目的は単一リージョン内の負荷分散。
Route 53 へ中間層のサーバ群を登録し、AWS セキュリティグループでアクセス制限をすることもできるけど、サーバ名はインターネット上からアクセス可能。また、Route 53 は、大抵の DNS サーバベースのロードバランシングと同様にサービスが落ちている、もしくはアクセスできない (インスタンスが落ちた) サーバへのルートへもバランスしてしまう欠点があります。
どこで使うの？
  • ELB に登録したくない、もしくは外部からのトラフィックにさらされたくない中間層のサービスを持っている
  • シンプルなラウンドロビンロードバランサがほしい
  • セッション維持の必要がない
  • クライアントベースのロードバランサがほしい
asgard と統合して、より素敵な中間層のロードバランシングソリューションを開発中だそうです。
うむ。Web アプリケーションについては結構簡単にオートスケール設定できるのですが、中間層のオートスケールは必要になってから勉強ということでｗ

>>> 追記) AWS な先生方より


話はめっちゃ飛びますが、なんと先日 "みんなのPython 第三版" のレビューに参加させて頂きました (柴田先生のブログ)！おかげさまで改めて楽しく Python 3 系の勉強をすることができました。この場を借りてお礼申し上げます。柴田さん第三版おめでとうございます！！！買いましょう

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？
続きを読む

Django と Python 3 - #python_adv

Django-ja の方からきました。こんにちわ。さて、昨日の Ian 先生のブログ にも書いてある通り、ついに Django にも本格的に Python 3 の足音が近づいてきました。ただし現在 alpha 版が公開されている 1.5 では "実験的" なサポートで、1.6 以降で正式にサポートする予定となっています。あくまでも "実験的" であり、プロダクションでの利用は "非推奨" となっています。Django コミュニティでは、この 1.5 でサポートをテストしてもらい、そのフィードバックを呼びかけています。なのでプロダクションでの利用は 1.6 まで待ちでしょうね。また Python 3 サポートと同時に、Django 1.4 では Python 2.4 がサポートから外れ、1.5 では Python 2.5 がサポートから外れます。これで 1.7 以降から django.utils 配下が軽くなっていくんでしょうかね (現在は 3 サポートのためにさらに増えてる)。 バージョン 下位互換 Python サポート 2.5 2.6 2.7 3.2 3.3 Django 1.4 > 1.2 ○ ○ ○ - - Django 1.5 > 1.3 - >= 2.6.5 ○ >= 2.7.3 △ 実験的 △ 実験的 Django 1.6 > 1.4 - >= 2.6.5 ○ >= 2.7.3 ○ ○ Python 2.5 系を利用している場合は、1.6 のリリースまで (2013 後半ぐらい?) に Python 2.6.5 以上 (2.7.3 以上を強く推奨) への移行が必要です。1.5 は今月 (2012/12) 中にリリース予定とのことなので、今のうちに Python 3 へ移行方法を抑えときたいなと。以下 Django ドキュメントの翻訳作業がてら " Porting to Python 3 " を元にご紹介。さすが
続きを読む