Tweet
Tweet

Slide 1

Slide 1 text

© Cygames,Inc.

Slide 2

Slide 2 text

© Cygames,Inc. Frontend Engineer HTML5, JS,CSS 2013 Backend Engineer PHP, Mysql, Linux, Shell script…. 2014 2015 Infrastructure Engineer Nginx, Bigquery, Appengine, Python, Go, Kafka 2016 2017 Pagerduty, Chaos engineering 2018 Who am I 株式会社Cygames インフラエンジニア 和田 明久 ● Toil削減・自動化 ● CI/CDフロー改善 ● カオスエンジニアリング ● オンコール Lambda function, ECS, Athena

Slide 3

Slide 3 text

© Cygames,Inc. AGENDA ● なぜ導入したか ● カオスエンジニアリングとは ● カオスエクスペリメント事例 ○ 開発フェーズにおいて ○ インフラチームにおいて ● まとめと今後の展望

Slide 4

Slide 4 text

© Cygames,Inc. なぜ導入したか 運用タイトルが年々スケール ↓ サービス運用中の障害発生は不可避 ↓ プロアクティブな障害対応

Slide 5

Slide 5 text

© Cygames,Inc.

Slide 6

Slide 6 text

© Cygames,Inc. デイリーで50件前後のインシデントやアラート

Slide 7

Slide 7 text

© Cygames,Inc. 我々が直面した障害例... インパクト TTR 内容 サービス停止 6 hour ELBとWebサーバ間でセッション滞留発生 データ不整合 1 day ログをインサートしている Auroraでデータ不整合が発生した データ不整合 1 day 分散トランザクションのテスト漏れ 一部ユーザ ~ 2min RDS Failover 一部ユーザ ~ 2min VMホスト障害

Slide 8

Slide 8 text

© Cygames,Inc. 大規模な障害が発生すると ● ゲームブランドに対する信頼低下 ● ユーザエクスペリエンスの低下 ● 機会損失

Slide 9

Slide 9 text

© Cygames,Inc. データ引用元 https://www.jolt.co.uk/blog/outage-outrage/

Slide 10

Slide 10 text

© Cygames,Inc. 障害発生を事前対処したい

Slide 11

Slide 11 text

© Cygames,Inc. カオスエンジニアリング？

Slide 12

Slide 12 text

“Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.” http://principlesofchaos.org/

Slide 13

Slide 13 text

“Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.” http://principlesofchaos.org/ 検証の規律 不安定な状態にも耐えうる

Slide 14

Slide 14 text

https://www.flickr.com/search/?q=injection&l=4

Slide 15

Slide 15 text

https://www.flickr.com/search/?license=4&advanced=1&text=firedrill

Slide 16

Slide 16 text

© Cygames,Inc. Chaos in Practice 定常状態を仮定する 仮説を構築する 故障を発生させる 反証をあげる

Slide 17

Slide 17 text

© Cygames,Inc. Step1 定常状態を仮定する システムの振舞いを示す指標を用いて定常状態を定義 e.g. CPU Usage < 60% Connection < 2000 Latency 99th < 5s

Slide 18

Slide 18 text

© Cygames,Inc. Step 2 仮説を構築する 定常状態が通常と実験グループで継続する仮説を構築 e.g. ● EC2 インスタンスが全対比1%停止しても稼働率は99.99% ● CPU Usage 80 % 超過しても平均レイテンシーは 200ms 以内 ● RDS で Failover が発生してもロールバックが正常実行

Slide 19

Slide 19 text

© Cygames,Inc. Step 3 故障を発生させる 実際に起きうるイベントをシステムに付加する e.g. インスタンス 停止 Network 遮断 CPU Usage 100%

Slide 20

Slide 20 text

© Cygames,Inc. Step 4 反証をあげる 通常と実験グループのシステム出力を振り返り反証をあげる ● 反証された場合 ○ 同様のイベントに対する対策 ○ 構成変更やプログラム修正を行う ● 反証されない場合 ○ さらに故障度を上げても同様の振る舞いになるか

Slide 21

Slide 21 text

© Cygames,Inc. 定常状態 仮説反証 故障発生 仮説構築 Chaos Loop

Slide 22

Slide 22 text

© Cygames,Inc. その他 ● 文化・書籍・ツールなど https://github.com/dastergon/awesome-chaos-engineering ● Chaos Conf 2018 https://www.youtube.com/playlist?list=PLLIx5ktghjqKtZdfDDy uJrlhC-ICfhVAN

Slide 23

Slide 23 text

© Cygames,Inc. まとめると ● ITシステムの障害訓練 ● 信頼性・可用性・保守性 の向上 ● システムを無秩序に故障させることではない

Slide 24

Slide 24 text

© Cygames,Inc. カオスエクスペリメント事例

Slide 25

Slide 25 text

© Cygames,Inc. 実施対象 開発環境もしくはサービス影響のないシステムが対象 ● 運用タイトルの本番環境では未実施 ● 運用タイトルの開発環境で実施 ● ゲームサービス以外で実施

Slide 26

Slide 26 text

© Cygames,Inc. 実施対象 https://aws.amazon.com/compliance/shared-responsibility-model/

Slide 27

Slide 27 text

© Cygames,Inc. モニタリング方法 ツール 対象 例 Mackerel Resource CPU・Memory・Disk Usage NewRelic Processing PHP・Memcached・Mysql 処理時間 ElasticSearch Response AVG/MEDIAN/95th/99th Web Server Response Time

Slide 28

Slide 28 text

© Cygames,Inc. Mackerel

Slide 29

Slide 29 text

© Cygames,Inc. New Relic

Slide 30

Slide 30 text

© Cygames,Inc. Elastic Search Service

Slide 31

Slide 31 text

© Cygames,Inc. カオスエクスペリメント事例 ~開発フェーズにおいて~

Slide 32

Slide 32 text

© Cygames,Inc. カオスチーム編成 アドバイザー 1 マネ・サブマネ陣 5 インフラ 2

Slide 33

Slide 33 text

© Cygames,Inc. 実施方法 ● タスクフォース的に招集 ● 週1回MTGで反省と今後のアクション決定 ● 構成はビジネスサイド以外 ● 期間は最長で9ヶ月のもの

Slide 34

Slide 34 text

© Cygames,Inc. 実験対象のアーキテクチャ ● WEB / Cache / Database ● モノリスな構成 ● リクエスト数は実験内容に依存

Slide 35

Slide 35 text

© Cygames,Inc. Internet AWS Cloud

Slide 36

Slide 36 text

© Cygames,Inc. AWS Cloud Internet cache proxy web

Slide 37

Slide 37 text

© Cygames,Inc. 故障方法例 ※ https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FaultInjectionQueries.html コンポーネント イベント EC2 Stop, Reboot ElastiCache Stop, Reboot ECS Stop Task RDS(Mysql) Reboot, Failover RDS(Aurora) Reboot, Failover, Fault Injection Queries (※) Network Switch Security Group, Network ACL Allow / Deny

Slide 38

Slide 38 text

© Cygames,Inc. 定常状態 仮説反証 故障発生 仮説構築 Chaos Loop

Slide 39

Slide 39 text

© Cygames,Inc. 事例1　RDS Failover

Slide 40

Slide 40 text

© Cygames,Inc. AWS Cloud Internet cache proxy web

Slide 41

Slide 41 text

© Cygames,Inc. 定常状態 仮説反証 故障発生 仮説構築 Chaos Loop 99th percentile < 5s 正常に ロールバックされる 反証された RDS Failover

Slide 42

Slide 42 text

© Cygames,Inc. 事例1 振り返り ● 結果 ○ リクエストはタイムアウト ○ 部分的にロールバック ○ 同一性が崩れるパターンが発生 ● アクション ○ テーブルを水平分割 ○ 同一ユーザのデータは同一DBへ保存 ○ セッションが滞留するためカーネルパラメーターを調整

Slide 43

Slide 43 text

© Cygames,Inc. 事例2　ElastiCache Reboot

Slide 44

Slide 44 text

© Cygames,Inc. AWS Cloud Internet cache proxy web

Slide 45

Slide 45 text

© Cygames,Inc. 定常状態 仮説反証 故障発生 仮説構築 Chaos Loop 99th percentile < 5s 起動中のElastiCacheに 切替る 反証された ElastiCache Reboot

Slide 46

Slide 46 text

© Cygames,Inc. 事例2 ElastiCache Reboot ● 結果 ○ Cache Proxyの状態がサーバごとに異なりキー分散の不整合が発生 ● アクション ○ Cache Proxyの状態が異常なサーバをELBから除外

Slide 47

Slide 47 text

© Cygames,Inc. 事例3　EC2 上のプロセス停止

Slide 48

Slide 48 text

© Cygames,Inc. AWS Cloud Internet cache proxy web

Slide 49

Slide 49 text

© Cygames,Inc. 定常状態 仮説反証 故障発生 仮説構築 Chaos Loop 99th percentile < 5s Return 200s マスターデータ参照 反証された WEBサーバ上 Cache Process停止

Slide 50

Slide 50 text

© Cygames,Inc. 事例3 EC2 上のプロセス停止 ● 結果 ○ キャッシュ接続エラーで後続処理に移らなかった ○ SPOF ● アクション ○ 冗長化 ○ ALB health_check にてローカルキャッシュの接続性確認する

Slide 51

Slide 51 text

© Cygames,Inc. 実験はさらに膨大化 ● 示した事例はごく一部 ● 障害パターンは増加 ● 障害対応フローチャートも作成

Slide 52

Slide 52 text

© Cygames,Inc. Chaos Sheet 数百項目に...

Slide 53

Slide 53 text

© Cygames,Inc. 障害発生時の対応フローチャート

Slide 54

Slide 54 text

© Cygames,Inc. 本環境に適用されたこと ● シングルポイント冗長化 ● カーネルパラメーター最適化 ● DB設計変更 ● ALB health check の詳細実装

Slide 55

Slide 55 text

© Cygames,Inc. 章まとめ ● ロジック内・外における脆弱性を認識 ● 発生しがちな故障イベントに対する事前対策 ● 障害発生時の対応フローを構築

Slide 56

Slide 56 text

© Cygames,Inc. カオスエクスペリメント事例 ~インフラチームでの事例~

Slide 57

Slide 57 text

© Cygames,Inc. インフラカオスチーム編成 サブマネ 1 インフラ 1

Slide 58

Slide 58 text

© Cygames,Inc. インフラチームの領域 ● オンプレ運用・監視 ● クラウド運用・監視 ● オンコール対応 ● ログ収集基盤 ● MW・クラウドサービス導入支援 ● ...etc

Slide 59

Slide 59 text

© Cygames,Inc. 実施対象 ● サービス影響厳禁 ● 手をつけられるところからやろう ● ログの解析ツールへのロード処理を ECS化していた

Slide 60

Slide 60 text

© Cygames,Inc. 事例 ECS Task の停止

Slide 61

Slide 61 text

© Cygames,Inc. AWS Cloud Instances ECS Containers Elastic Search Service へのログインポート処理

Slide 62

Slide 62 text

© Cygames,Inc. 定常状態 仮説反証 故障発生 仮説構築 Chaos Loop Received ≒ Deleted Load Latency < 60s Taskが停止しても ロード処理に無影響 反証されなかった ECS Task 停止

Slide 63

Slide 63 text

© Cygames,Inc. 事例 ECS Task の停止 ● 結果 ○ SQS Deleted と Received は変化なし・遅延も数秒以下 ○ Task 数が多い可能性示唆 ● アクション ○ 故障率を上げても同様の結果になるか確認する

Slide 64

Slide 64 text

© Cygames,Inc. 章まとめ ● できるところからやっている ● 仮説通りのポジティブな結果だと安心 ● 指標化が不十分な箇所が明確化

Slide 65

Slide 65 text

© Cygames,Inc. まとめと今後の展望

Slide 66

Slide 66 text

© Cygames,Inc. 導入によるメリット ● 信頼性・可用性・保守性の向上 ● SPOF・脆弱性認知 ● 障害発生を前提としたコード実装

Slide 67

Slide 67 text

© Cygames,Inc. AWSだから手軽にできた ● インスタンス起動・停止 ● NW遮断 ● DB Failover ● ECS task 起動・停止

Slide 68

Slide 68 text

© Cygames,Inc. プロダクション環境で実践するための課題 ● プロダクトチームとの交渉 ● モノリスからマイクロサービスへ ● 影響範囲の最小化 ● 自動化

Slide 69

Slide 69 text

© Cygames,Inc. 今後 ● Failure Fastな設計推進 ● マイクロサービス化推進 ● カオスエンジニアリング推進

Slide 70

Slide 70 text

© Cygames,Inc. We are hiring chaos engineer !!

Slide 71

Slide 71 text

Thank you!