Netflixのシステムは、2枚のピザに秘密があった。マイクロサービスアーキテクチャ(Micro Service Architecture)　

仕事帰りの電車の中で今、ハマっているのが、
「Jessica Jones　Season2」
Season１ではまってしまってSeason2でも「ドップリと首まで浸かる状態」で観ています。

Netflixについては、以前、「カオスエンジニアリング」について記事にしましたが、今回は、開発手法について調べてみました。

世界的なサービスで抜群の安定感と配信スピードを誇るNetflix
その根本的なシステムは、マイクロサービスアーキテクチャ(Micro Service Architecture)という手法で組まれていました。

今回の
「IT小僧の時事放談」
では、
「Netflixのシステムは、2枚のピザに秘密があった。マイクロサービスアーキテクチャ(Micro Service Architecture)」
と題して
「巨大Webサービスを支える必然から生まれた手法」
についてご紹介いたします。

今回も小難しい話をできるだけ簡単に解説しながらブログにしました。
最後まで読んでいただけたら幸いです。

スポンサーリンク

巨大かつ最上級

Netflixは、巨大なサービスです。

ネットフリックス（英: Netflix, Inc.、NASDAQ: NFLX）は、アメリカ合衆国のオンラインDVDレンタル及び映像ストリーミング配信事業会社。
本社はカリフォルニア州ロスガトスに置かれている。10万種類、延べ4200万枚のDVDを保有し、レンタル向けに1,600万人の顧客を得ている。また、ストリーミング配信では既存のコンテンツに加え、独占配信やオリジナル作品も扱っている。
2017年12月の時点で190ヵ国以上で配信事業を展開する。
アメリカのほか、オランダ、ブラジル、インド、日本、韓国にオフィスを構える。
Wikipedia

本数の発表はありませんが、半端ない数であることは、わかります。
また、オリジナルドラマが多く　しかもそのレベルが非常に高い。
連続ドラマが多いので、ストーリー、映像に関しても「映画以上」の面白さです。
映画並みの予算を使って作成されています。
アニメだと、今年「DEVILMAN」が、発表されて、その内容に高い評価がありました。
ネット配信だからできる、映像とストーリー、地上波では、「絶対に放映されない大人向けの内容」でした。

このような、世界的なサービスは、どのように構築されているのか？

ヒントは、「2枚のピザ」にあったようです。

2枚のピザでまかなえる開発チームの集合体

Netflixのサービスは、Amazon Web Services（AWS）の上に構築されています。
そしてAmazon Web Servicesの中でも別格とも言えるシステムになっています。

その秘密のひとつに「ツーピザチーム」と呼ぶ小規模チームの集合体の集まりがあります。
一つ一つの機能を分割して一定のルールで連結して全体を構成しています。
この手法により　機能追加、変更などを「すばやく」、「確実」、「少ない工数」で実現しているわけです。

簡単に言えば、機能を分割して、機能を少人数で開発、一定のルールで連結して全体を構成する。

その機能の１単位を　2枚のピザ（ツーピザチーム）でまかなえるぐらいのチームで独立して開発をする。

これを

「マイクロサービスアーキテクチャー」(Micro Service Architecture)と呼ばれる開発手法です。

例えば

顧客ID管理
顧客視聴管理
顧客決済管理

など顧客情報管理を細分化してそれぞれ別のチームが開発して連携をする。
実際には、この例以上の細分化がされていると思いますが、こんな感じだと思ってください。

全体に影響が出にくいサービス

全体を１つのシステムとして構成した場合、１箇所の障害が、全体に影響する可能性があります。
例えば
「決済でトラブった場合、配信ができなくなる」
というような状況です。

これでは、サービスの信頼性が失われ、顧客が離れます。
このような構造を「モノリシック（一枚岩）」と言います。

それに対して、小さいサービス（Micro Service）を組み合わせた場合
例えば
「決済でトラブった場合、決済サービスだけ影響を受けるが、配信は継続できる」
「決済サービスだけ修正を行い」
「決済サービスを可動させて正常復帰」
つまり、別のサービスの影響を受けにくいという利点があります。

さらに、それぞれの小さいサービス（Micro Service）は、独立しているため、サービスに合った技術を使うことができます。

しかし、これを実現するには、大きなハードルがあります。

適切なサービス分割、組織体制や運営ルール

小さなサービスを連携するわけですが、適切なサービス分割、組織体制や運営ルールが必要になります。

ある開発チームが、他の開発チームの担当しているところに影響が出るときは、
「チーム同士で話し合う」
ということで解決しているそうです。

また連携するために必要なツールを自作しています。

・複数の開発言語やツールを連携可能にするツール　「Prana」
・どこにどんなサービスがあるのかを管理するレジストリツール「Eureka」
・サービス同士の依存関係を可視化する「Salp」
・数万の機能の集合を検索を実行する「BiopSys」
などなど　必要に応じて作成して、そしてこれらのいくつかを公開しています。

前回のブログで紹介したXXXも公開されています。
※公開場所は、GitHubというサービスです。

クックパッドもマイクロサービスで開発

クックパッドもマイクロサービスで開発されています。
https://cookpad.com/

クックパッド開発者ブログに記載されています。
http://techlife.cookpad.com/entry/2014/09/08/093000

少し専門的なページですが、小さいサービスを連携して全体を形作っているということでは同じです。

でも大変

じゃぁ　みんな同じにすればいいのに
という話ですが、そう簡単なものではありません。

小さいサービスをどうやってわけるか？
小さいサービスをどうやって連結するか？

それだけでも大掛かりなものになります。
また、このような手法を取り入れるためには、開発を含めた会社全体の意識を変えることが必要になってきます。

開発組織を独立した複数の小さなチームに分割し、それぞれのチームが自らの利用技術を決め、継続的に開発していくスタイルを想定しています。ここで心配になることとして、日本的な受託開発の現場とマイクロサービスの考え方は相性が良くない場合が多い。
「マイクロサービス」のメリットをざっくり言うと「変化に対応しやすい」こと──ただしファウラー氏は“使い過ぎ”を警告
https://knowledge.sakura.ad.jp/3377/

Netflixのように巨大なシステムをマイクロサービス化するには、時間がかかると思います。
しかしマイクロサービス化していなかったら、このような巨大システムは、まともに動かないと思います。

[amazonjs asin="4873117607" locale="JP" title="マイクロサービスアーキテクチャ"]
書籍も販売されているので詳しく知りたい方は、読んでみて下さい。

まとめ

前回、ブログにした
「カオスエンジニアリング」
そして今回ご紹介した
「マイクロサービスアーキテクチャ」

どちらも　オリジナルで構築したそうです。
個人のスーパースターではなく　意識の高いエンジニア集団なんだろうな

さて「Jessica Jones　Season2」
この先どうなることやら　気になるなぁ

今日も、安定したストリーミングで楽しみましょう。

[amazonjs asin="B01N0310NI" locale="JP" title="マーベル/ジェシカ・ジョーンズ シーズン1 COMPLETE BOX Blu-ray"]

参考資料
数千のマイクロサービスで期間短縮、知られざるNetflixのシステム開発体制
http://tech.nikkeibp.co.jp/it/atclact/active/17/020600228/020600001/
日経XTECH

クックパッドとマイクロサービス
http://techlife.cookpad.com/entry/2014/09/08/093000
クックパッド開発者ブログ

スポンサーリンク