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
続きを読む

財務諸表 (Financial Statements)

※ 業務 & 英語の勉強 財務諸表 (Financial Statements) の種類 諸表名 英語表記 概要 損益計算書 Profit and Loss Statement [P/L] ※ Income Statement など様々 収益と費用の状態を表す 貸借対照表 Balance sheet [B/S] 資産、負債、純資産を表す キャッシュ・フロー計算書 Cash flow Statement [C/S] 資金の増減を表す 株主資本等変動計算書 Statements of Shareholders' Equity [S/S] 純資産の変動状況を表す 損益計算書 損益計算書とは 収益から費用を差し引いた利益を計算するためのもの 利益 (profit) = 収益 (revenue) - 費用 (expense) 損益計算書の構成 記載内容 英語表記 概要 売上高 Sales 販売した財やサービスの金額 売上原価 Cost of Sales 財やサービスを生み出すための経費 期首繰越高＋当期仕入高－期末棚卸高 - 売上総利益 Gross Profit = 売上高 - 売上原価 ※ 売上高総利益率 [ 粗利益率] (Shareholder Equity Ratio) = 売上総利益 / 売上高 販売費及び一般管理費 Selling and General Administrative expenses [SGA] 売上原価以外の企業を運営するための経費 販売費: 販売手数料、広告宣伝費など 一般管理費: 人件費、福利厚生費、交際費、賃借料、減価償却費、雑費など - 営業利益 Operating Profit = 売上総利益 - 販売費及び一般管理費 営業外収益 Non-operating income 本業以外で経常的に発生する収益 受取利息、有価証券売却益、配当金、不動産賃貸収入など 営業外費用 Non-operating expense 本業以外で経常的に発生する経費 支払利息、有価証券売却損など - 経常利益 Ordinary Profit = 営業利益 + 営業外収益
続きを読む

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 " を元にご紹介。さすが
続きを読む