AWS re:Invent2015参加レポ

技術本部の須藤(@strsk)です。前回から約1年ぶりの投稿です。
部署名は変わりましたが、相変わらずAmebaのソーシャルゲーム全般のインフラとプラスでピグも担当しています。いろんな理由でコラ画像を作る機会は減ってきました…。

さて、もう既に1ヶ月が経とうとしていますが、AWSが毎年ラスベガスで開催しているカンファレンス、re:Invent2015に参加してきたのでそのレポートになります。社内勉強会でも発表していてスライドはアップしたんですが、残念ながらアメブロにはembedできないのでリンクだけ貼っておきます。技術系のブログを書くには辛い仕様ですね！

re:Invent2015参加レポ // Speaker Deck

今回の記事では印象に残っているセッションについて詳細を記しておきます。（※英語の解釈に間違いがあるかもしれません(・_・;)）

基調講演

Keynote/基調講演(YouTube)

スピーカーは上級副社長アンディー・ジャシー氏。"Freedom"をテーマに、クラウドがもたらす7つの自由（アドバンテージ）について語りながら新サービスを発表します。参加者は1万9000人？だったらしく、横浜アリーナぐらいの大きさのホールで行われる演説はなかなか見応えがありました。とはいえ同時通訳のトランシーバーに集中していて、本人の声とかほとんど聞いてないですが…。
新サービスについては既に発表されているので割愛しますが、ひとつ選ぶとすればAWS Database Migration Serviceが気になっています。

Netflixのセッション

セッションは企業の事例を中心に回っていたんですが、Netflixのセッションがとても印象的でした。部屋も毎回大きく、世界的にも注目度が高い企業の1つだと思います。
オペレーショナル・エクセレンスという考え方を初めて知ったんですが、Netflixとしてのゴールを達成するための開発側の指針も一貫性があって、自分たちのインフラを考える上でのフレームワークとして参考にしたいなと考えているところです。

Engineering Netflix Global Operations In The Cloud/
クラウドでのエンジニアリング Netflix グローバルオペレーション(YouTube/SlideShare)

• 会員6500万人
  
• マルチAZ、マルチリージョンのアーキテクチャ（欧米3リージョン）
  
• 運用上の課題
  
  • 成長しつづける規模の中での品質維持と改善
    
  • 可用性と開発速度のトレードオフ
    
• Operational Excellence
  
  • 課題を解決するために目指しているもの
    
  • 競争優位性になるほどオペレーションが洗練されている状態
    
  • 品質と開発速度のトレードオフの差を小さくする（変化率のカーブをシフトする）
    
• Operation Engineering
  
  • オペレーショナル・エクセレンスであるためのエンジニアリングの文化
    
• Spinnaker
  
  • Netflix製クラウドマネジメントツール、自動化のプラットフォーム
    
  • リージョンをまたいだクラウドの管理ができる
    
• Stash, Gradle, Ubuntu, Jenkins, Spinnaker
  
• 洞察とリアルタイム解析
  
  • O(bserve)O(rient)D(ecide)A(ct) loop
    
  • 時系列データ（Observe）を4つのアルゴリズムで解析（Orient）、投票し（Decide）アクションを決める（Act）
    
  • これらを自動化することでリカバリまで6分～8分かかっていたものが30秒で完了
    
• Kepler
  
  • Netflix製のマシンラーニングで例外を検知するシステム
    
    • density-based clusteringアルゴリズムを使っている
      
  • Eメールやページで通知、OOS、デタッチ、teminateまで実行可能
    
• カオスエンジニアリング
  
  • 様々な障害に耐えるためのシステムを構築するための実験の規律
    
  • Xenの脆弱性対応で200台中20台のCassandraが再起動失敗したときもリカバリまで自動化していたため問題なかった
    
• Flux
  
  • Netflix製トラフィック可視化ツール
    
  • 3リージョンへのリクエスト状態を見ることができる
    
  • リージョン障害のリカバリを1分程度で実行できる（シミュレーション時）
    
• レバレッジを効かせるために
  
  • 運用ツールをプロダクトとして作る
    
  • モジュラーコンポーネントとして開発し、統合する
    

How Netflix Handles Up To 8 Million Events Per Second/
Netflixのキーストーン:Netflixが1秒あたり最大800万イベントのデータストリームを処理する方法(YouTube/SlideShare)

• Netflixが解析している"数値"
  
  • 5,500億イベント/日
    
  • 8,500万イベント+21GB/秒（ピーク時）
    
  • 1PB増加/日
    
  • 100以上のイベントの種類
    
• アーキテクチャ
  
  • 以前はChkuwaで収集しEMRで解析
    
  • 現在はさらにKeystoneというシステムを構築
    
• Keystone
  
  • ジョブマネージャのControl Planeと解析するData Planeで構成
    
  • Kafkaクラスターは優先度（中・高）で分離
    
  • Control PlaneのSamzaが各解析ツールへルーティング
    
    • Amazon S3、Elasticsearch、Kafka
      
  • リアルタイム処理にSpark Streaming
    
    • 映画の再生情報やABテストの解析など
      
  • Auditor、Winston、KaffeeでKeystoneをモニタリング
    
• 今後やること
  
  • イベントディスカバリと可視化
    
  • Auditor/Kaffeeのオープンソース化
    

The Life of a Netflix Engineer Using 37% of the Internet/
インターネットの37％を使用するNetflixエンジニアの1日(YouTube/SlideShare)

• COREチーム（Critical Operations and Response Engineering Team）所属のオペレーションエンジニア
  
• COREチームのゴール
  
  • カスタマー・エクスペリエンスを守る
    
  • ユニークな失敗
    
    • イノベーションに失敗は付き物
      
  • コンスタントな改善
    
• Netflixについて
  
  • 顧客の喜びと真実の瞬間の獲得
    
  • 2009年にクラウドへの移行を開始し2015年に完了
    
  • 欧米3リージョンに展開
    
  • 100個のマイクロサービス
    
  • 1,000回/日の本番環境への変更
    
  • 10,000台のインスタンス
    
  • 100,000回/分の顧客とのやりとり
    
  • 1,000,000人の顧客
    
  • 1,000,000,000個のメトリクス
    
  • 10,000,000,000時間のストリーミング
    
  • 10人のオペレーションエンジニア（No NOC）
    
• どうやって実現しているか？
  
  • DevOpsの文化
    
    • コードやデプロイへのオーナーシップ
      
    • 24x7の対応
      
    • インシデントのレビュー
      
    • 正直でオープンなフィードバック
      
  • オーナーシップを楽に
    
    • サービスディスカバリ
      
    • ツール同士の連携
      
    • 継続的デプロイ
      
    • 永続的なデータ
      
  • 洞察
    
    • メトリクスや運用の洞察
      
  • クラウドとして考える
    
    • データセンターでの考えは使わない
      
  • 驚きをなくす
    
    • ステートレスなアプリケーション
      
    • データの冗長性
      
    • 障害の投入
      
      • Chaos Monkey
        
      • Chaos Kong
        
• クラウドが保証すること
  
  • インスタンスは死ぬ
    
  • リソースは共有する
    
  • アーキテクチャは変わる
    
  • もう光（ランプ）を見ることはない
    
• Make things better
  

その他

Turbine: A Microservice Approach to 3 Billion Game Requests/
Turbine:1日あたり30億のゲームリクエストに対するマイクロサービスのアプローチ(YouTube/SlideShare)

• コンシューマゲーム（WBG）はモノリシック
  
• モバイルゲーム（MG）はマイクロサービス
  
• 複数のゲームをAWSでどう管理するか
  
  • ゲームごとにアカウントを1つ
    
  • 環境ごとに1VPC
    
  • コアサービス以外の環境とは接続しない
    
• メトリクスはstatsD->Librato
  
• アプリケーションレイヤーのスケールポイントが多い（WBG）
  
  • シングルインスタンスにまとめてスケールさせる→SLICEと呼んでいる
    
  • リソース効率は悪くなるが構成シンプルになって運用しやすい
    
• イベントデータの収集はKafka
  
  • r3.xlarge,10TB GP2のbroker6台で25万メッセージ/秒を処理
    
• データストアに利用しているMongoDBのスケール問題
  
  • バージョンは2.6.9
    
  • r3.2xlarge,2TB GP2,3AZ構成
    
  • データが大きすぎて既存のバックアップが使えない
    
  • バグFIXやパッチを当てて解決
    
• MongoDBのスケールの歴史
  
  • write lock問題
    
    • 読み込み時にスパイクする
      
    • Linux kernelの更新とシャードを倍にすることで解決解決（12shard->24shard）
      
  • プロセスストールによるフェイルオーバー
    
  • CPUのsystemがスパイクしてmongodがストール
    
  • RAMのサイズが大きすぎてLinuxのメモリコンパクションに時間がかかるのが原因
    
  • インスタンスサイズを下げて解決
    
• 選択的な性能劣化
  
  • キャッシング
    
    • 2つのエンドポイントをキャッシングしたことによりアプリレイヤーの50％のネットワークスループットを抑制
      
  • 絞り
    
    • 読み込みを優先するために書き込み数を制御
      
    • システム影響はあるが顧客への影響が少ないリクエストをブロック
      
    • 絞りはさまざまな問題を引き起こす
      
• 今後やること
  
  • さらなるマイクロサービス化
    
  • immutablilityを取り入れる
    
  • さらなるチームを越えた協力
    
  • さらなるAmazonサポート
    

最後に

初めて海外のカンファレンスに参加しましたが、わかりやすく技術力と英語力の欲望を掻き立てられて帰ってきました。弊社でもクラウド化は進んでいるものの、まだ物理の考え方が抜け切れていない部分もあり課題だと思っていたタイミングだったため凄く刺激になりました。
カジノで負けた額が僕を育ててくれるのだと信じて引き続き精進していきたいと思います。