Slide 1
Slide 1 text
2018/12/10 (
火)
AWS re:Invent
報告会 by Yappli
そんなに遠くない
Chaos Engineering
株式会社 Speee
開発基盤ユニット
森岡周平 (@selmertsx)
Slide 2
Slide 2 text
Chaos Engineering
を
聞いたことがある人
Slide 3
Slide 3 text
Chaos Engineering
は
自分には縁遠いと思ってる方
Slide 4
Slide 4 text
本日はそういった方を
ターゲットにお話をします
Slide 5
Slide 5 text
今日のお話
このセッションでChaos Engineering
が身近に感じら
れたので、その体験をおすそ分けしたい！
Slide 6
Slide 6 text
今日の目的
Chaos Engineering
とは何か理解できる
Serverless
の分野に Chaos Engineering
を
適用する方法が分かる
Chaos Engineering
がちょびっと身近に感
じられる
気がついたら AWS
の話よりもChaos Engineering
の話メインに
なってしまい、完全に趣味全開のお話になってしまいまし
た...!!!
Slide 7
Slide 7 text
Agenda
自己紹介
Chaos Engineering
とは何か
Chaos Engineering
をServerelss
の分野に適用する
まとめ
Chaos Engineering
の概念について7
、Serverless
での実践事例
が3
くらいの割合で話します。Session
の中身を理解しやすくす
るためにChaos Engineerings
の原則について、セッションで話
されていた内容以外の情報も交えてお話をしていきます。
Slide 8
Slide 8 text
自己紹介
名前:
森岡周平
所属部署:
開発基盤ユニット
GitHub & Twitter
アカウント: @selmertsx
主業務: IDaaS
関連の諸々をServerless
で作る
技術: Ruby/Rails, TypeScript, AWS, GCP
最近の興味: AWS Amplify Console
で
サービスを作ってみたい
Slide 9
Slide 9 text
最近作ってるIDaaS
関連システム
現在、クラウド人材管理ツールが人事マスター
人材管理ツールのデータに応じて、従業員が適切なサービス
を適切な権限で見れるように、Serverless
で自動化する
※
人材管理ツールは人数課金で、かつ過去の履歴を保持しないためBigQuery
に履歴を残す
※
人材管理ツールは他社内サービスと密接に関わっており、安易にリプレイスできない
Slide 10
Slide 10 text
Agenda
自己紹介
Chaos Engineering
とは何か
Chaos Engineering
をServerelss
の分野に適用する
まとめ
Chaos Engineering
の概念について7
、Serverless
での実践事例
が3
くらいの割合で話します。Session
の中身を理解しやすくす
るためにChaos Engineerings
の原則について、セッションで話
されていた内容以外の情報も交えてお話をしていきます。
Slide 11
Slide 11 text
Chaos Engineering
の原則
意訳してみるとこんな感じ
Chaos Engineering
とは、分散システムが過酷な本番
環境でも耐えられる能力があるという確証を得るため
の実験規範
Slide 12
Slide 12 text
Chaos Engineering
の実践方法
Net ix
の論文も読んで整理してみた
Slide 13
Slide 13 text
Net ix
における
Chaos Engineering
採用背景
Slide 14
Slide 14 text
Net ix
は Microservices
を採用してる
Effective Interprocess Communications in the Cloud: The Pros and Cons
of Microservices Architectures AWS re:Invent 2014
Slide 15
Slide 15 text
Microservices
において
Net ix
が信頼性を高めるため
考えてきたアプローチ
Slide 16
Slide 16 text
従来の信頼性向上のためのアプローチ
システムへの INPUT (x)
を網羅的にリストアップ
x
に対して適切な OUPUT(y)
を実装する
想定される問題に対して、適切な対処を実装する
ことで障害を回避する
f(x)
はruntime con g
、機能更新などで動的に変化
Slide 17
Slide 17 text
Net ix
のケース
Microservices
において、あるシステムのOUTPUT
が他のシステムへのINPUT
挙動を網羅的に把握することが困難
「システム単体で正常に動いていること」 よりも
「何かあってもユーザーがコンテンツを視聴でき
ること」 を実現する設計にしなければならない
Slide 18
Slide 18 text
Net ix
のケース その2
一部のサービスが利用できなくなったとしても
全体としては稼働するサービスを設計していく
Chaos Engineering
はその教育のための取り組み
過去に障害を起こしたINPUT
を定期的に再現する
VM instance
が落ちる (chaos monkey)
サービス間のレイテンシー (latency monkey)
サービス間のリクエストの失敗
予期しないユーザーからのリクエスト
リージョン全体の障害発生 (chaos kong)
Slide 19
Slide 19 text
Production
環境に
障害(Failure)
を注入する実験
=
Chaos Experiments
Slide 20
Slide 20 text
Chaos Engineering
支援ツールGremlin
のデモから (re:Invent 2018)
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
Chaos Experiments
の補足説明
Steady State (
正常な状態)
をどう定義する
のか？
実験の影響範囲はどうなっているの？
なぜ実験を自動化しProduction
環境で行う
のか？
Slide 27
Slide 27 text
正常な状態 (Steady State)
の定義
Steady State
とは 「ユーザーから見えるサービス
が正常に動作していることを示す指標」
Net ix
では SPS (stream starts per second)
で表現
障害が発生しても SPS
に影響を与えないよう サー
ビス全体を設計する
Slide 28
Slide 28 text
実験の影響範囲を設定
Chaos Experiments
は全ユーザに行う訳ではない
実験は一部のユーザーのみ抽出 して行う (
実験群)
実験を受けないユーザーを 統制群 と呼ぶ
実験結果を、実験群と統制群で比較させる
比較する数値は主に SPS
を利用する
Slide 29
Slide 29 text
Production
で行う &
自動化する
Net ix
では 1
日に100
回程度デプロイ をしている
ユーザーの振る舞いを指標としているので、コー
ドで実現されたインテグレーションテストでは代
替できない
デプロイの度に、テスターによるリグレッション
テストをすることは難しい
Slide 30
Slide 30 text
Chaos Engineering
まとめ
Microservices
下の複雑化したシステムにおいては従来の方
法では安定性を保つことは困難である
過去、障害の原因となった外乱を自動で定期的にINPUT
し
それにサービスが耐え続けられるように設計・実装し続ける
このときサービス１つ１つが正しく動いている より
ユーザーが正常にサービスを利用できる を優先する
これらの取り組みが Chaos Engineering
である
Slide 31
Slide 31 text
この話を聴いて、思っていた
よりも Chaos Engineering
は
突飛な話じゃないと思った人
Slide 32
Slide 32 text
Agenda
自己紹介
Chaos Engineering
とは何か
Chaos Engineering
をServerelss
の分野に適用する
まとめ
Chaos Engineering
の概念について7
、Serverless
での実践事例
が3
くらいの割合で話します。Session
の中身を理解しやすくす
るためにChaos Engineerings
の原則について、セッションで話
されていた内容以外の情報も交えてお話をしていきます。
Slide 33
Slide 33 text
Serverless
で Chaos Engineering
Serverless
こそ Chaos Engineering
が重要である
Auth 0
、DynamoDB
などの外部サービスと連携す
ることが多い
依存する外部要素が増えると、Latency
の影響を受
ける機会も多くなる
Lambda A
からLambda B
を呼び出すとき、両方
cold
状態であったら実行に非常に時間が掛かる
Slide 34
Slide 34 text
対象のサービス (sample)
注入する障害 (Failure)
Latency Injection
Error Injection
https://github.com/theburningmonk/lambda-latency-injection-demo
Slide 35
Slide 35 text
Latency Injection
の実装
HTTP Request
の処理を上記のようにラップする
con g
はSSM Parameter Store
に格納
デプロイなしで即座に反映が可能
API Gateway
のCanary release
を使って影響範囲を制御して
も良さそうに見える (
資料にはない)
Slide 36
Slide 36 text
Error Injection
HTTP 5xx
Amazon DynamoDB
の throughput
を超える
AWS Lambda
の同時起動数を超える
Injection
のやり方
management console
上でLambda
の同時期同数を
設定する
Slide 37
Slide 37 text
Chaos Experiments
にあたっての注意
Staging
環境で十分にテストすること
マスキングした顧客データを持ってきてテスト
することは可能である
ロールバックプランを必ず用意しておくこと
必ず定時の中でやること
重要な日は避けること
Slide 38
Slide 38 text
Agenda
自己紹介
Chaos Engineering
とは何か
Chaos Engineering
をServerelss
の分野に適用する
まとめ
Chaos Engineering
の概念について7
、Serverless
での実践事例
が3
くらいの割合で話します。Session
の中身を理解しやすくす
るためにChaos Engineerings
の原則について、セッションで話
されていた内容以外の情報も交えてお話をしていきます。
Slide 39
Slide 39 text
まとめと所感
Chaos Engineering
をServerless
の分野に適用した
まだまだ手探り・力技感はあるものの、実現する
ための肌感はつかめた
今後の予定
僕たちのServerless
サービスでもエッセンスを取り
入れていく
障害を引き起こしたINPUT
を保持しておいて、再
発しないようリグレッションテストをするなど
近いうちにそんな話しが出来たらいいっすな！