注目の記事

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

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

DSC_0011

スピーカーはNetflixのSudhir Tonse。

DSC_0027

レポート

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

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

DSC_0012

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

DSC_0013

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

DSC_0014

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

DSC_0015

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

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

DSC_0016

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

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

DSC_0017

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

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

DSC_0018

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

DSC_0019

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

DSC_0020

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

DSC_0022

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

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

DSC_0023

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

DSC_0025

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

DSC_0028

ロードバランサ。 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。インスタンスをランダムに殺していくことでテストする。

DSC_0031

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

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

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

振り返り。

DSC_0034

まとめ

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