Netflix のスケール

現在日本でサービスを提供していないため目にすることは少ないですが、AWS のベストプラクティスと呼び名が高い Netflix のスケールをメモ。ベストプラクティスと言われるだけあって、記事も解説も豊富です。まー規模が桁違い過ぎるので読み飛ばしていたってのが正直なところですが、V 先生ドリブンで資料を読み直しました。AWS の How-to 記事は日本語でも山ほどあったので、自社データセンターから AWS へ移行した過程を中心に書きたいと思います。Netflix のテクノロジーについては以下を参考にしました。

>>> サービスの規模

Netflix は主に北米で VOD と DVD 郵送レンタルサービスを提供している会社です。ほとんど VOD で、今後 DVD 郵送レンタルは縮小するらしい。AWS の資料も VOD がメインです。サービス規模を抜粋 (スライド) すると、

  • 会員数は 2500 万人弱
  • ピーク時は北米インターネットトラフィックの 30% 超を占有
  • 800 種類以上のデバイスからアクセス = 各デバイス用にエンコーディング
  • 月間 (2012/6時点) 総視聴時間は 10 億時間超 = ユーザ 1 人当たり、1 日約 1 時間視聴
  • API リクエスト数 は 420 億 RPM = 約 15,000 RPS

今現在も急成長中とのことです。桁違いですね。はい。

>>> AWS 移行前の課題

AWS に移行する前の Netflix は、

  • 単一の Web アプリケーション: Java/Tomcat = war ファイル
  • 単一のデータストア: Oracle rac
  • 単一のデータセンター
  • バックアップなし (Wow

という構成だったようです。The エンタープライズ！って感じですね。2008 年に DB の障害で DVD レンタルサービスが 3 日間停止するなど、この運用は以下のような問題があったようです。

  • データセンタが SPOF
  • データベースが SPOF 。単一データベースの限界。スキーマ変更等サービスのリプレイス時にサービスが停止する
  • Web アプリケーションの一部のバグが全体に影響する

サービスの成長は喜ばしいですが、それに伴うインフラの成長は大変です。成長が急激な場合は特に。

>>> インフラの再検討 / AWS への移行

Netflix 曰く "我々はデータセンタの構築がビジネスなわけではない"。ということで、インフラの再検討です。What is cloud...

Netflix が定めたゴール。

  • Faster: データセンタよりも低いレイテンシへ
  • Scalable: データセンタのキャパシティにとらわれない
  • Available: 可用性の向上 (複数のデータセンターへ
  • Productive: 自動化やツールを使ったアジャイル開発へ

このゴールを実現するために試行錯誤した結果、データセンタを AWS へ丸投げ (abandon) することに。その理由をピックアップすると、

  • 早急にデータセンターを見直す必要があった (障害、サービスの拡大、SPOF をなくす、、、
  • 他にも CDN はあるけど、AWS ほどスケールして機能が豊富なサービスがない
  • ユーザやデバイスの成長は予測できない
  • クラウドコンピューティングには未来がある

等々。AWS なら "堅牢なインフラを短期間で作れる" ってことですね。Netflix のデータセンタとクラウド上に構築する際のアーキテクチャの比較。これも参考になります。

Netflix Datacenter vs Cloud Arch

集中から分散へ。蜜結合から祖結合へ。SPOF をなくしていく。

>>> AWS 上にサービスを構築していく

AWS へのシステムの構築や移行にあたり、アーキテクチャの参考になるリファレンスが公式サイトに公開されています。このリファレンスを参考にサービスをピックしていくのもいいと思います。Netflix では提供されているサービス (PaaS) では実現できないものについては、AWS の IaaS 上にプライベート PaaS を追加していくというアプローチ。Netflix service = AWS PaaS + Netflix PaaS (on AWS IaaS) ですね。

例えば、Oracle から SimpleDB (PaaS) へ一度移行しましたが、レイテンシが高い、自動シャーディングが実現できない、バックアップ等の問題があったため EC2, S3 (IaaS) 上に Cassandra で分散 KVS (プライベート PaaS) を構築したそうです。

Netflix のシステムアーキテクチャの図。

Netflix deployed on AWS

2009 年以降、左側から順にシステムを AWS にステップを踏んで移行したとのこと。構築及び運用のエンジニアは 50+α 人。どこも少数先鋭ですね。最初に AWS のサービスだけで実現でき、かつ切り離しやすい、コンテンツとログ解析をクラウドへ。次に、Cassandra 等のプライベート PaaS を構築し、プレイヤー、web サイト、巨大な API を順に移行。って感じですかね。

>>> Netflix のテクノロジー

Netflix が AWS 上で利用しているテクノロジーの抜粋。

>>> AWS におけるスケールアウト / インのオートメーション化

AWS auto scaling (@github) TODO: 後で :)

>>> 監視

AWS にデプロイしたサービスの監視方法。レイヤー毎に監視。

  • 外部からの URL 監視: Keynote
  • ELB やインスタンスの監視: Amazon CloudWatch
  • リソース監視: AppDynamics (Java, .Net とか
  • リソース監視: Epic (RRD ベースの内製ツール
  • ログ: Hadoop

>>> AWSを利用して得た5つの教訓

このブログ記事より。実際に移行、運用してみてわかったこと。

  • 自社データセンタとクラウドは全く違う (Dorothy, you're not in Kansas anymore)
    • データセンタにおける設計からデプロイまでのプロセスは全く違う
    • 今までの知識を捨て、クラウド環境でのオペレーションに切り替える必要がある
    • 例えば、データセンタではハードウェア障害がほとんどなかったので、セッションごとのメモリ管理がベストアプローチだった。しかし AWS では単一インスタンス (仮想ハードウェア) の障害発生率が高い
    • 例えば、データセンタでは富豪インフラ (大容量、超高速、高信頼性なネットワークとか) が当たり前だったけど、AWS のネットワークはレイテンシが低い
  • 共用は難しい
    • クラウド上に顧客に利用してもらうシステムを設計する際、レスポンスのレイテンシを考慮したい
    • しかし AWS のモデルはハードウェア、ネットワーク、ストレージ等リソースの共有であるため、共用に左右される
    • あきらめるか、供用しないよう AWS リソースを管理する (おそらく、より高速なプランは、よりリソース配分が大きいから、低レイテンシが求めるなら、ある程度高いプランにしろってこと？
  • 障害を回避する最善策は、常に障害を発生させる (Dropbox に引き続き。。
    • すべてのシステムは疎結合である必要がある
    • 障害が発生してもいいように分散させている
    • 例えば検索機能が障害で落ちても、ストリーミングは落とさない
    • 障害時の備えがあったとしても、それを常時テストしていないと、いざという時に動作しないかもしれない
  • 実際のスケールから学ぶ
    • AWS に移行する前、そのプラットフォームを研究し、テストシステムを構築。現実的なトラフィックパターンのシミュレーションを試みた
    • AWS を選択するには役に立ったけど、アーキテクチャの選択には役に立たなかった
    • 構築の初期段階で、ユーザの全てのリクエストトラフィックを複製し、単純に繰り返した。これによりボトルネックや設計ミスが特定できた
  • やり続ける
    • 膨大なタスクと、データセンタと AWS とオペレーションがまったく違うことで路頭に迷った時もあった
    • ハードルにぶつかったときに、それと戦う ための根性と信念が大事

Netflix はこれらの教訓から、 2011/4 月の AWS 大規模障害の際にもサービスを継続することができたようです。WIRED は、この記事を引用し、サービス停止は Amazon のせいではなく、利用者のせいと述べています。でもどんだけ冗長化して、障害対策をやっているとしても想定外のことは発生します。学習して、実行して、テストして、やり続けるのが重要だなーと。

>>> OSS

Netflix は AWS の Know-How 等を OSS として公開してらっしゃいます。

  • Chaos Monkey: 無作為にインスタンスを落として、クラウド環境の耐障害性をテストするツール
  • Asgard: AWS Management Console +α クラスタリング (オートスケール な Web コンソール

>>> TIPS (っていうか気になったもの

  • AWS アカウントは目的毎に 4 種類使い分けている
    • paastest: 開発・テスト用 (デプロイ
    • paasprod: プロダクション用 (自動スケール
    • paasaudit: センシティブサービス用 (SOX, PCI 等
    • paasarchive: ディザスタリカバリ用 (バックアップ 等
  • AWS with SSD でのベンチマーク

    Cassandra disk vs SSD bench mark

    • SSD hi1.4xlarge × 15 インスタンス で
      Disk m2.4xlarge × 48 インスタンス + Memcached m2.xlarge × 38 インスタンス と同様のスループットが出せる
    • さらにレイテンシが 1/5 程度短縮され、コストも半分に抑えることが出来る
    プラン CPU メモリ ストレージ ネットワーク IOPS スループット コスト

    m2.4xlarge

    26 ECU

    68GB RAM

    2 × 840GB / Disk

    1 Gbit

    500

    100M bps

    $1.8/h

    hi1.4xlarge

    35 ECU

    60.5GB RAM

    2 × 1,000GB / SSD

    10 Gbit

    100,000

    1G bps

    $3.1/h

    スケールアップによる問題解決とスケールアウトによる問題解決が柔軟にできるのも AWS の魅力ですね。
    話は変わりますが、以前 DeNA さんのインフラ勉強会にご招待頂いた時に、"スレーブは RAID 0 でスループットを向上させている" と教えていただきました。High I/O インスタンスの登場で幸せになれるサービスも多いのではないかと思います。

  • IT オペレーション部門がなくなる
    • オペレーションは AWS API が担当。雲の向こう側でお仕事
    • データセンタの運用に必要なスタッフがフラット。海外にデータセンタを構築するのも
    • 開発者がプロダクションに直接デプロイ、実行できるようになる

規模でかいのと、理解不足なのと、資料がいっぱいるのとでまとめるの難しかったです。。。目に留まったものを駄々書きした感じ。Netflix 日本に来ないかなー。週末は槍ヶ岳 :)

コメント

コメントを投稿

このブログの人気の投稿

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 の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む