MEMO: Mastering Chaos - A Netflix Guide to Microservices

## MEMO: Mastering Chaos - A Netflix Guide to Microservices

https://www.youtube.com/watch?v=CZ3wIuvmHeM

- はじめに

    - Josh Evans (Netflix)
    - ストリーミング・ビジネスにシフトした時に在籍
    - マイクロサービスを AWS で走らせる

- マイクロサービスとは
    - マイクロサービスでないもの
        - 2000年ごろの Netflix DVD センター
        - "JavaWeb" と呼ばれる単一のアプリ モノリス
        - 全てが密につながっている  DB に表を追加するだけで大変
    - モジュール化、カプセル化
    - スケーラビリティ、負荷の分散
    - 仮想化＋サービス弾性
    - Netflix の例
        - AB テスト、ユーザー情報、商品推薦、キャッシュ
    - 抽象化
        - マイクロサービス
        - キャッシュ
        - クライアント・ライブラリー
        - これらを全てまとめてマイクロサービス

- チャレンジと解法
    - サービス間のリクエスト
        - ネットワーク障害の場合、他のサービスを巻き添えにする
        - Hystrix リトライ、フォールバック
    - テスト
        - Fault Injection Testing (FIT)
            - 人工トランザクション
            - リアルタイム・トラフィック
        - どうテストの範囲を決めるか
        - 10個のマイクロサービスがそれぞれ99.99% の稼働率
            - 全体では 99.9% の稼働率 (１年間で8-9時間のダウン)
        - クリティカルなマイクロサービスを特定する
    - クライアント・ライブラリ
        - 共通のパターン、ロジックをまとめる → モノリスに逆戻り！
    - 永続性 (Persistence)
        - CAP 定理
            - ネットワークが分断されているときは、一貫性と稼働性のどちらかを犠牲にしなければいけない
        - cassandra
            - 結果整合性
            - クライアントは一つのノードに書く → 他ノードに伝播
    - 2012年のクリスマスイブに AWS 障害
	    - 全てのサーバーをus-east-1 に置いた → 3つのリージョンに分散
    - ステートレス・サービス
	    - DBではキャッシュではなく、ノードが死んでも問題ない
	    - オートスケールが重要
	    - トラフィックの急激な増加、性能のバグに強い
	    - Chaos Monkey に強い
	 - ステートフル・サービス
		- DBやキャッシュ
		- ノードが死ぬと障害
		- 顧客のデータが１つのノードにしかないと、サーバーにアクセスできない
	- EVCache
		- 複数の az に同時に書く
		- 常に利用可能だと思って良い　よくスケールする
		- 頼りすぎ→バッチ処理からも呼ばれるように→障害があるとサービスとDBを道連れ
		- 解法→オンラインとオフラインを分ける
		- リクエスト単位のキャッシュ
	- 多様性
		- 運用ドリフト　→　色々な値が自然と変化
		- 障害　→　パターンの同定　→　自動化　→　応用
		- 色々な慣例
	- 多言語化
		- ほとんどは JVM
		- 色々な言語のサービスが増える
		- 多様性のコスト → ツール、ベースイメージ、ノード管理、ライブラリ　全て言語・スタックごとに用意
	- 障害の時間
		- 平日、９時に多い
		- 変更、デプロイが障害につながる
- Conway's Law
	- ソフトウェアの構造は、それを生み出した組織の構造を反映する