Netflix のスケール

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

• The Netflix Tech Blog
• @slideshare
• @github

>>> サービスの規模

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...

IaaS = Ops without Hardware; PaaS = Devs without Ops; SaaS = Business without Devs; by @ adrianco

- Fabian Lange (@CodingFabian) March 8, 2012

Netflix が定めたゴール。

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

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

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

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

集中から分散へ。蜜結合から祖結合へ。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 のシステムアーキテクチャの図。

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

>>> Netflix のテクノロジー

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

• 主な OS: CentOS 5
• 主な言語/WAF: Java 6 or 7/Tomcat
• RDB: MySQL
• 分散 KVS: Cassandra (高可用性にすぐれ、スケーラブルだったため
• • Jenkins + Jmeter でパフォーマンステスト
  • Cassandra 用ヘルパー Priam を OSS として公開
    バックアップ・リカバリ、設定、AWS サポート (複数リージョン, S3 バックアップ, ...)、JVM の管理, 監視など (@github)
  • Cassandra クライアント Astyanax を OSS として公開 (@github)
  • Why Cassandra
• ログ解析: Hadoop with Hive (Amazon EMR
• • 50 ノードで 0.6T bytes / day のログを解析
• コーディネーション: Zookeeper
• デプロイ/テスト等: Jenkins (1600 jobs, 2000 builds / day, 2TBytes build datas
• • Jenkins の利用用途
  • • ビルドパイプラインの構築
    • Cassandra のメンテナンス
    • 自動化されたテスト、デプロイ
    • インフラ のハウスキーピング
  • Job を Grooby ベース の DSL で書けるプラグインを OSS として公開 (@github)

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

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

• 早くスケールアップ、遅くスケールダウン
• AWS のオートスケールは強力だけど、もろ刃の剣
• 正しい設定とテストが必要

>>> 監視

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 でのベンチマーク

  

  • 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 日本に来ないかなー。週末は槍ヶ岳 :)