JaSST’23Tokyo 基調講演 元ネットフリックス・現Verica CaseyRosenthal氏の話を書き殴った
はじめに
JaSST’23Tokyoの基調講演は元ネットフリックスに在籍しカオスエンジニアリングを提唱した @CaseyRosenthal 氏でした。
オライリーから出ているカオスエンジニアリングの著者でもあります。
カオスエンジニアリングに関してはSREの探求などでも紹介されていて、概要は知っていました。
正直、「カオスエンジニアリングの概要になるのかな、ならある程度知っているしー」と思っていました。
結論…俺、バカでした 笑
提唱者自ら発する言葉から何が重要なのかという意図を汲み取れました。話を直に聞くって大事ですね。
ということで、会社のKibelaにメモを書き殴ったので、それをもう少しまとめようと思います。
可用性を向上させるために生まれたカオスエンジニアリング
基のスライド
基のスライドをぜひ参照してください。
結局何を言いたいかというと
カオスエンジニアリングとは
- システム上で安全に実験をすること
- 安全性のマージンがどれくらいあるか？
- 実験を促して学習をうながす
可用性
信頼性（Reliability）ではないことに意味があるなと。ネットフリックスでは、可用性（維持すること）が重要視されていたのでしょう。
ネットフリックスの黎明期ではこの可用性が低いことが大きな課題でした。
強制的に1日1回インスタンスを落とす
1つの対策として「強制的に1日1回インスタンスを落とす」ことをしました。この問題を解決をしないとエンジニアは何も仕事ができません。なので、解決策を必死に探します。
このプロセスが可用性の改善に大きな効果を生みました。
さらに、地域ごとのデータセンターを落としたり、より大規模に実施しました。
なぜ、このようなことをしたか
ビジネス的な課題をエンジニアに提示するためです。ネットフリックスのビジネスとして可用性が重要です。ネットフリックスが安定して見れなかったら使わなくなりますよね？
可用性が重要だという意識づけのために実施したそうです。実際に問題は無くなりました。
ネットフリックスの状況
スライドの7枚目ですが、マイクロサービス化していて、ものすごく不雑になっています。しかも、1日に何度もデプロイされています。
自身が携わるサービスと直接関連するサービスは理解しているが、遠くなると理解するのが難しいとのことです。
※大規模なマイクロサービスあるある
ネットフリックスの組織
ネットフリはCTOが不在で、縦の指揮系統が少ないので、エンジニア自身が自発的に動いて解決する文化があり、一人一人がやり方を考えて行動します。
3つの事例
ゲームデイ
ゲームデイとはインシデントに対してアイディアを出す日です。言いかえると、事象に対してこう振る舞うだろうと予測してその通りに起こるかを検証します。
スライド：P9-P13
- ステージングが発するメッセージがKafkaを経由してPUSH（通知）, LOGGING（ログ出力）, BILLING（決済）されるはず（振る舞いの予測）
- ステージング上のKafkaを止めてみた。
- 結果的にPUSH（通知）, LOGGING（ログ出力）, BILLING（決済）が止まるはず。
- しかし…
- PROD.が止まる！
- 原因：LOGGING（ログ出力）が本番からステージングのKafkaにメッセージングされていた行っていた。
マイクロサービス間のビジネスロジックの矛盾
スライド：P15-P21
- マイクロサービスPとマイクロサービスQがある
- Pはデータフォーマットするサービス（DBにアクセスしない）
- Qはデータを操作するサービス
- DBはカサンドラを利用している
- 高速化のためにRedisでキャッシュしている
- Redisで何かあったら、自動的にカサンドラに切り替える
- ある日Redisが落ちる
- サービスQはカサンドラからデータ取りに行くけどかなり遅い
- サービスQが404を出すが、サービスPは４０４として扱わない。Pで矛盾する
- オンラインサービス全体がとおちる
振り返り結果として、ビジネスロジックが矛盾していることが原因で、サービスPとサービスQが一緒の部屋にいて、話せば防げたのでは？
予期せぬアウテージ
スライド：P23-P33
- 1つのサーバのAPIがリクエストを受けて各マイクロサービスに処理を送る
- APIがロードバランサっぽい動ごきをしていた。
- 言語はJavaで古くからあるシステムで、シングルポイントで重要なので投資されていた
- 11月のショッピングホリデーでアクセスが増えるので、サイバーマンデーの1ヶ月前からコードフリーズ
- コードフリーズの2週間後（金曜日）にAPIで障害が発生し、リブートで回避したが40分かかった
- その後数時間で、全てのノードで障害が発生した
- コードフリーズしてるので、新規コードが原因ではない
- 原因がわからないので月曜日に監視するコードを挿入した
- 何週間かして同じ障害が金曜日に発生し、次々他のノードで障害が発生
- 監視するコードを挿入したしところは遅れて月曜日に障害が発生
- 原因は2ヶ月前に入れたコードでメモリリークが発生した
- それはリブートしてからしばらくして発生するものだった
- コードをデプロイすることで、メモリがリフレッシュされていたので、この障害が発生しなかった
- しかし、コードフリーズすることで、メモリがリフレッシュされずに、この障害が発生した
- コードフリーズしたのに安全性が下がった。
Vericaの活動
- Googleなどが公開しているインシデントデータを集めている
- 主に可能性だが、セキュリティなども含まれる
- どのようにしてインシデントが発生しているか、修正しているか、数学的に分析、リポート作る
可用性に関する誤解
誤解１ 事件を起こした社員を解雇すればいい
医療問題の例
- 医療問題を起こした医者を5%を解雇
- そうすることで医療裁判が減ると考えたが
- 結果医療裁判が増えた
なぜか？
- スキルが上がるとより難易度の高い手術をする
- その結果、医療ミスとなった
- 医療ミスをする医者は優秀であり、その医者をクビにした結果余計に医療ミスが増えた
誤解２ ベストプラクティスをまとめたランブックがあればいい
壊滅的な障害は非常なユニークなことが多いので、コストをかけてランブックを作っても見ても障害は発生する
誤解３ これまで起きた根本原因を直せば良い
- とある大きなIaaSで大規模障害が発生した
- その原因はyamlの記述ミス
- その結果、デプロイが失敗し数時間停止した
- 原因を分析した結果、原因となったコードと人は分かった
- 責任を属人化しても意味がない
- 人以外に不備があるのでは？
- Configrationの書き方、パーサーなど仕組みに不備があるのでは？
- ディレクターがコミュニケーションをさせていないとか？
- 適切な予算をつけていないのでは？
- インシデントの解析→色々な角度がある（違う考え方が重要）。
誤解４ 信頼性を定量的に測る
- 信頼性の指標には99.999%とか、MTTRとかある
- MTTRをネタに話をするにはいいが、正規分布にならない
- 指数関数的になるし、テイルが長い
- アウテージ（停止）の重篤度と期間に相関はない
- MTTRだけを見ても根本的な解決にはならない
誤解５ リスクを回避すれば安全性が高まる
- リスクを回避してばかりいると学べない
- 予想外が起こった時に何もできない
- たくさんのガードレールがあると、エンジニアが学ぶ機会がなくなり、いざという時に修復できない
誤解６ シンプル
- 複雑性には偶然と必然があるし、複雑性をゼロにすることはできない
- プログラムを書くということは複雑性を追加するということ
- 安全性が高いシステムの複雑性が高いというデータもある
誤解７ 冗長性
- 例:チャレンジャー
- 解析の結果オーリング（ゴムバンド）が原因
- 圧力が上がると接合部に燃料（？）が溜まる
- 冗長性を持たせようとオーリングを2本にした
- 2回目のフライトの後にオーリングにギャップ
- スペースシャトルをもう一台作成することはできなかった
- オーリングを2本にしたから大丈夫としたが爆発した
安全性に寄与しているのは？
3つの要素がある
- ECONOMICS / 予算
- WORKLOAD / 作業負荷
- SAFTY / 安全性
この3つはゴムでつながっている。離れ過ぎるとゴムが切れる。
例
- エンジニアがお金を使いすぎると会社が破綻する
- ネトフリのシステムはラップトップでできない
- エンジニアは崖に落ちるまで気がつかない（インシデントが起こることがわかっていればエンジニアは治す）
カオスエンジニアリングとは
- システム上で安全に実験をすること
- 安全性のマージンがどれくらいあるか？
- 実験を促して学習をうながす
ECONOMICS, WORKLOAD, SAFTYのもとになった経済学の例
フォードの例
4つの領域
- STATE / 汎用化（？）
- RELATIONSHIPS / 関係を限定
- ENVIROMENT / 環境
- REVERSIBILITY / 可逆性
STATE / 汎用化（？）
- 1910年リリースのモデルTは汎用化したことで、生産性が向上した
- 部品も汎用化した
RELATIONSHIPS / 関係を限定
- 組み立てライン化し、人の関係、部品の関係を限定した
- 当時の他の会社はチームで1つの車を作った（ハンドメイドに近い）
ENVIROMENT / 環境
- 当時のアメリカは独占状態であり新しい会社が入れない
- フォードはこの独占状態を壊したが、参入後は独占した
- 鉄道を廃止し道路を造った
REVERSIBILITY / 可逆性
- フォードはこれだけできなかった
- 生産ラインは設計上の意思決定を設計にフィードバックできなかった
これをソフトウェアに適用すると…
STATE / 汎用化（？）
どうにもできないくらい増える
RELATIONSHIPS / 関係を限定
- 例：マイクロサービス
- どんどん抽象化し、関係が広がる
ENVIROMENT / 環境
- コントロールできない
- 独禁法がある
REVERSIBILITY / 可逆性
- ここがソフトウェアの優位性（すぐにフィードバックする意識）
- ウォーターフォールからアジャイルへの転換
- CI/CDよりデリバリーが早くした
- システムの可逆性をコントロールできるので意思決定がボトムアップできる
- フィードバックループは可逆性あるアーキテクチャ
結論：ソフトウェアエンジニアは可逆性のプロであれ
官僚制の薦め（？）
（官僚制 / the Bureaucraticのニュアンスがわからない…笑。今までの話と矛盾している気がする）
- 氏曰く、要はこれw
- 官僚的なはアメリカ人嫌い（ルール作って守るのが苦手）
- 人をコントロールすることを官僚制とする
- ソフトウェア組織は官僚性を実現している
- 結構、縦構造（CTO→リーダー…）だが、これはソフトウェアエンジニアから責任を奪う
- ソフトウェアエンジニアが色々考える必要がある
CI/CDに加えてCV（Continuous Verification / 継続的検証）
- ビジネスのニーズを満たすため速さだけでなく壊さない時代に入ってきた
- ビジネスが継続的に続けられるか
- CVはヘッドライトで、望んだ通りのシステムになっているかを継続的に検証する
REACTIVE(反応)→PROACTIVE（先回り）
現状
- Disaster Recovery / 障害復旧
- Incident Response / インシデント管理
- Alerting / アラート
継続的検証することで先回りして、障害・インシデント・アラートを極小化する活動する
TESTING（テスト）→EXPERIMENTATION（実験）
現状
- Unit Testing / ユニットテスト
- Functional Testing / 機能テスト
- Integration Testing / 結合テスト
から
- Property-Based Testing / テストコード自動生成
- Load Testing / 負荷テスト
- Squeeze Testing / 圧迫テスト
継続的検証することで、これらのテストに依存しなくていいような状況を作る
METHODOLOGY（方法論）→TOOL（ツール）
現状
- Agile
- DevOps
- SRE
から
- Version Control / バージョン管理
- Continuous Integration / 継続的インテグレーション
- Continuous Delivery / 継続的デリバリー
継続的検証することで、可用性がある価値提供する
VALIDATION（出力の検証）→VERIFICATION（要求の検証）
現状
- Code Reviews / コードレビュー
- Static Analysis / 静的解析
継続的検証することで、出力の検証からビジネス要求の検証へ
KNOWN PROPERTIES（既知）→SYSTEM BEHAVIORS（システムの状態）
現状
- Monitoring / 監視
- Alerting / アラート
- Synthetic Monitoring / 外形監視
から
- Logging / ロギング
- Distributed Tracing / 分散トレーシング
- Obvervability
継続的検証することで、単純に知ることから状態による運用へ
Discussion