[セッションレポート]NetflixにおけるMicroservicesアーキテクチャ #reinvent

この記事は AWS re:Invent 2014、PFC304-JT - Effective Interprocess Communications in the Cloud: The Pros and Cons of Micro Services Architectures - Japanese Trackのレポートです。

スピーカーはNetflixのSudhir Tonse。

レポート

どうやってMicroservicesに変化していったのかを話したい。 これまで何度か本番環境が停止し、そこからたくさんのことを学んだ。それを共有したい。

Netflixについて。映画のストリーミングサービス。 PCやPS4などで再生できる。 ネットワークの1/3のトラフィックをNetflixが占めることがある。 20億以上のエッヂAPIリクエストがあって、500以上のMicroservicesが動いている。 そして30以上のエンジニアリングチームがある。

以前はデータセンタで、Tomcatで.warファイルを動かすような仕組みだった。 2009年からAWSへの移行を始めた。インターネット企業では一番最初にクラウドに移行した企業だと思う。

画一的なアプリケーションはどういった特徴があるのか？ たくさんの貨車が連結された汽車のようなものだ。

何百という種類のデバイスから、ロードバランサを経由して、画一的なアプリケーションがアクセスを受けていた。

これにはいいところがある。全てがコードになっているので、開発者がやり慣れた手法で操作ができた。デプロイも簡単。 スケーリングも簡単。アプリケーションをクローニングするだけ。 しかし組織がスケールされ、エンジニアが増えると、単純だったコードが複雑になっていく。 エンジニアのそれぞれのバックグラウンドが違うと使いたいテクノロジが違う。 自分の好きな言語で、自分のIDEで開発したいという要求が増える。 しかしそれは出来ない。画一的な、単一的なテクノロジで組まれたアプリケーションだったからだ。

またチームが増えると開発者が増える、コードも増える。 そうするとデプロイに時間がかかるようになる。 何か変更があると、その変更がどう影響するのかがわからない。 デプロイに2週間もかかるようになってしまった。

また、コンポーネントを個別にスケールできなくなってしまった。 何かのコンポーネントをスケールする場合には他のコンポーネントにも影響がある。

可用性にも問題があった。 2008年、サイトが6時間落ちた。なぜか？セミコロンが一つ足りなかったからだ。 Userスレッドが無限ループに陥り、数秒でwebサイトがダウンしてしまった。 一つの貨車に火災があったら全ての汽車を止めなければいけないように、 どこかに問題があると全てが停止してしまう。

ここで考えた。Microservicesのほうがいいのではないか？ここが転換期だった。

MicroservicesとSOAは違うのか？ SOAのように思われるかもしれない。 Microsrevicesはコードの数でも、チームのサイズでも、APIやエンドポイントの数で決まるわけではない。 原則として、一つの責任範囲、それぞれが明確なリーダーシップの範囲を持っている。 それぞれのエンジニアチームが、それぞれMicroservicesを担当し、DepOpsで責任を持つ。

画一的なアーキテクチャは密結合であり、Microservicesは疎結合であるアーキテクチャだ。 NetflixではこのMicroservicesアーキテクチャに変換するために1年半を要した。

なぜMicroservicesなのか？独立性によってスピードアップできる。 エンジニアチームが別のチームによってスピードダウンしたりストップすることがなく 個別に自由にエンジニアリングができる。 またツールも言語も、チームによって自由に選択ができる。 可用性の確保にもなる。あるサービスが落ちたとしても他のサービスには影響を与えない。 MicroserviceのアーキテクチャではUnixのpipeのように複数のサービスが連結される。

Microservicesの課題は？ それぞれのMicroservicesを制御するルールが必要だ。 Microserviceでは言語が自由だ。好きに使える。開発者には便利だ。しかし運用面では課題になる。 この解決のためにSideCarを使った。

もう1つの課題。たくさんのサービスをどう使うか、どこにどんなサービスがあるのかを管理する必要がある。 そこでRegistryサービスとしてEurekaを提供している。

これまでのサービスではリクエストは一つだった。しかしMicroservicesでは一つのリクエストが複数のサービスに分散される。 そうするとたくさんのトラフィックが発生する。どう解決するか。キャッシュを活用してる。

他に、ボトルネックがある。 様々なアプリケーションから依存されているサービスがある場合、ここがホットスポットになる。 どのように解決するか？一番最初にサービスを使ったときにHTTPヘッダに埋め込んで、渡していく。 これでサービスへの問い合わせ回数が減らせる。

スケーリングの課題。 リクエストが増えた場合、スケーリングするが、フロントのサービスだけスケールするわけにはいかない。 依存される、連結するサービスも全てスケールしないといけない。 AWSではAutoScalingがある。Microservicesを自動でスケールできる。 場合によっては予測型のオートスケールを使うこともできる。

ロードバランサ。 ELBはパブリックなELBであるため、内部的には使いたくない。 このためRibbonというソフトウェアLBで制御している。 おさらい。フロントはELBで、内部はより賢いソフトウェアLBを使うといい。

Microserviceの依存を考えたる。その時に重要なのは可視化。 それぞれのWebサーバに対し局所的な可視化ができれば依存関係が管理できる。 Netflix SALPというツールを作っている。まだOSSにはしていない。 依存関係が一元的に管理できる。

Microservicesで障害が出た場合、どのサービスが障害になった原因なのかがわからない。 障害の根本原因となるサービスを特定したい。 Netflix BiopSys。このツールを使うことで、何万ものインスタンスに対してSearchを実行できる。分散grep。 もう1つはログイベント。Netflix Suroによって実現。 イベントを集約し、HadoopやElasticsearchに取り込むことで分析が容易になる。

Microservicesのベストプラクティス。 セキュリティグループでサービスへのIOを制御する。 ベンジャミン・フランクリンの名言で「人生の中で確実なものは2つしかない。死と税金だ」があると もう1つ確実なものがある。 例えば主要なサービスが停止したらどうなるか？影響はわかららない。止めてみないとわからない。 NetflixではFault Injection Testingを行っている。 Simian Army。インスタンスをランダムに殺していくことでテストする。

デプロイは。NetflixではAsgardというツールを使っている。

Ribbonは本当に数行で作れている。とても簡単。

NetflixではたくさんのOSSを出している。私たちはコミュニティにたくさん還元している。ぜひ活用してほしい。

振り返り。

まとめ

Microservicesの考え方と活用、課題についてすごくわかりやすいセッションでした。