この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
セッション概要
irbbbです。2015年3月29日に開催された Developers.IO 2015 にて、アマゾンデータサービスジャパン株式会社の今井 雄太様に『DevOps in Action』というタイトルで、 アマゾンのお客様や海外の「面白い」「感心した」DevOpsっぽい事例を発表していただきました。カジュアルな話かとおもいきや、かなりディープが話がてんこ盛りでした。
本セッションは撮影禁止のため、文章だけのレポートとなります。
当日のスライドはこちらからダウンロード願います。
NetflixのSOAとデプロイについて
Netflixは全米VOD市場で35％のシェアを持つトップ企業
SOAについて
Service-oriented architecture(SOA)を採用し、サービスごとに独立して開発できる。 APIの互換性が保たれる限り、リリースやリファクタリングはサービスの開発チームに委譲できる。
ビルドパイプライン
このビルドパイプラインがこgitへのコミットごとに走り、任意のリビジョンに対して対応するamiを指定してテストやデプロイが可能になっている。
gitのdevelopブランチにpushしたコードは、テストが成功すると自動的にmasterにマージされ、ビルドパイプラインが走ってデプロイされる!
デプロイにはNetflix製のAsgardを使っている。 blue-greenデプロイの 思想でautoscaleグループを旧インスタンス群から新インスタンス群に切り替える。
NetflixのOSSへの取り組みいついて
NetflixはopsツールのOSS開発に積極的。 Netflixからzerotodockerというツールが提供され、docker環境があれば簡単に手元で試せるようになっている。
世界展開するマルチプレイヤーゲームのレイテンシとの戦い
クライアントとサーバの物理的な距離があると、FPSゲームはラグラグになってしまう。 例えば、大陸をまたぐとレイテンシは100msを超える
クライアントには中央サーバーに一度アクセスさせ、最寄りのゲームサーバーに振る。 ゲームデータもAmazon CloudFrontでエッジサーバから配信する
クライアントとゲームサーバはソケットを張りっぱなしなので、ELBを介さずに直接サーバーに接続する。 サーバはAWS CloudFormationとChefで環境構築。 ゲーム終了後はゲームログを中央サーバに送信する。
新しいゲームサーバが追加されると中央サーバーに通知・登録される。 中央サーバは各リージョンに通信すれば、PODの状態がわかる。サーバの増減も中央からPODに命令される。
NEXONのMMORPGへの取り組み
従来のMMORPGは1個のサーバ(やプロセス)にワールドを閉じ込める手法がよく使われてきた。
ゲーム内で距離が離れたプレイヤー同士はゲーム内でインタラクションがないと考え、遠くはなれた領域はサーバを分けてしまった。 1サーバが 処理するワールド領域の広さはユーザーの混み具合によって異なる。 狭い領域であっても、ユーザーが増えて混みすぎるとサーバを動的に分割し、一定ユーザを新サーバに順次再接続するよう振り分ける。
ユーザーデータはサーバ間で同期させる。
GraniのDevOpsへの取り組み
AWS事例では珍しく
- IIS8(Windows Server 2012)
- C#
と.NET系環境で動いている。
パフォーマンスへのこだわりが強い。Time To First Byte(TTFB)も同業他社に比べて早い。 インフラチームはアプリケーションレイヤーの運用を楽にするツールをたくさん作っている。 アプリケーションの処理をフックし、あらゆるログを取得している。 SQLも自動で実行計画がロギングされ、改善余地のあるものは通知される。手動運用にすると結局誰もやらなくなる。
Netflixのモニタリングへの取り組み
Netflix2度目の登場。
異常の検出
ログをかき集めで動きをモデル化し、期待する動きと実際の動きがずれているときはアラートを上げるようにした
参考 SPS : the Pulse of Netflix Streaming
A/Bテスト
NetflixではA/Bのような単純な2パターンではなく、膨大なパターンをテストしている。 膨大の組み合わせの中から、結果がよいパターンに自動的に収束させるフレームワークがある
人力でやると集計等が大変なので、試せるパターン数に限界がある。
参考 Netflix JavaScript Talks - Scaling A/B Testing on Netflix.com with Node.js
あらゆるメトリクスを取る
Atlasという監視プラットフォームを構築し、12億ものメトリクスを取得している。
まとめ
- インフラチームは「ツールチーム」であるべき
- テスト・ビルド・デプロイ以外にもビジネスを早く回せるようにするといったことでも貢献できる
- アプリとインフラで蜜に連携しないと、DevOpsはうまくまわらない
2
