システムに筋力トレーニングをさせるトレーナー!?カオスエンジニアって何者?

ノウハウ
DevOps アジャイル スクラム ドメイン駆動 SRE
システムに筋力トレーニングをさせるトレーナー!?カオスエンジニアって何者?

どうも、totokoです。

SNSやWEBサービスを始め、今はとにかくなんでもネットに繋がっている時代です。

そして同じ時間に沢山の人が接続しています。

そうなると当然気になるのは「こんなに同時に接続してるけど、よくもまあ落ちないものだなあ」と。思いません? 思わないかー。

まあ、確かに普段からそういうのを気にするのはお仕事としてエンジニアやってる人ぐらいでしょう。

しかし、よくよく考えてみるとすごくないですか?

もちろん同時接続数が数千とかだと対したことないのですが、例えばそれが数万、数十万、もしくは数百万以上の人が一度にそのサービスを利用しているのに、使っている側は全くストレスがないというのは。

例えば、YouTubeLIVEとかの配信サービスでは、人気の配信者だと同時に万人レベルで見ていることなんてザラにあります。

それなのに、見ている側は応答遅延(声や映像が遅れていたり、カクカクしたり)なく、世界中の他の視聴者たちと同じものを一緒に見ているのです。

他にも動画サービスサイト(ニコニコ動画やNetflix)でも同じことが言えます。一つのサービスの中に数えきれないほどの動画がアップロードされており、僕らユーザーはそれを何の気兼ねなしに好きなものをチョイスして、視聴することができているのです。

ですが、本当にずっとそのサービスは、超安定稼働し続けられるのでしょうか?

例えば何者かが意図的にサーバーをダウンさせたりとかして、他のユーザーが「あれ?このサイトに接続できない!」とか「さっきまで普通に使えていたのに使えなくなってる!」とかのトラブルが起きるなんてこともなくはないです。

実際問題、スマートフォンゲームや新しいWEBサービス等ではサービス開始時にそうそうにサーバートラブルで、終了時刻未定のメンテナンス中というのも普通にあります。

これがそんなに使っている人が少ないサービスとかでは別にいい(よくないのですが相対的に)のですが、Netflixレベルのユーザー数を抱えているサービスでは、一つの大きなサーバートラブルがサービスそのものへの信頼低下に繋がってしまうこともあるはずです。

「Aというサービスはちょくちょくサーバーが落ちるから、似たようなサービスのBを使おうかな」となってはせっかくのユーザーが離れてしまいます。

予期せぬトラブルは本当によくある

大きなサービスは大概「自動復旧システム」のようなものが用意されています。

要するに予備システムみたいなものですね。万が一本丸がダメでも、同じような能力を持った二の丸が、本丸の復帰までカバーしてくれる。 そのおかげで僕らユーザーは変わらずにサービスを使える。

これをもっと広義の言葉で言うと「分散システム」といいます。

沢山のコンピュータをネットワークで接続し、作業を分担させて稼働するシステムです。それによって一台、一台のコンピュータへの負荷を少なくでき、故障してもシステムがダウンしません。

これの反対の言葉が「集中システム」ですね。SF映画とかで「システムを破壊しないと、この世界は終わるわ」とか言ってる時のシステムは大概は集中システムなのでしょう。

いくら負荷が少ないとはいえ、分散システムは規模が大きくなると複雑になります。だって、あっちが落ちても変わらずサービス稼働させる必要があるのですから。

しかし、それでもシステムダウン(世に言う「落ちる」)は起きるわけで……。

それは結局「予期しないトラブル(振る舞い)」が発生するからなんです。

えー、システムダウンにも対応できるための分散システムなのに予期せぬトラブルってなんだよー! と思う人はいるでしょう。

例えば、今はもうないですが、以前は金曜ロードショーで天空の城ラピュタが放送されるたびに「バルス!」でTwitterは落ちていました。

これもTwitterから言わせてもらうと「日本人が同時にバルスと唱える」なんて「予期せぬトラブル(振る舞い)」なわけです。

そりゃそうでしょう。海外で作られたSNSサービスであるTwitterが、いくらスタジオジブリ作品とはいえ、日本人が昔から「ラピュタの時はお茶の間みんな集まってバルスと唱える」という所作があるなんて知らないんですから。

まあ、そんな感じで思わぬところに予期せぬ振る舞いというのは存在しているのです。

これは比較的わかりやすい例ですが、場合によっては「影響そのものは小さいのに、それが膨らんで全体に影響を及ぼす」というものがあったりします。つまり、個別自体では全然問題ない設定とかが、システム全体に悪影響を及ぼすというケースです。

虫歯みたいなものです。一つの歯の問題と思ったら、他の歯だったり、体だったりに影響を出しているみたいな……。

そこで登場カオスエンジニアリング

そんなこと言っても、システムは日に日に複雑化しているのに「予期せぬ振る舞い」に対処せよってんなむちゃな……。

そこでそのような「システムの複雑性に対処する」方法が「カオスエンジニアリング」です。

なんだか格好いいですね。闇のプログラマーを彷彿させます。 彼らは絶賛稼働中のシステムに対して、「わざと」サーバーダウンなどの障害を発生させ、それによってちゃんとシステムが復旧するのかを「実験」する人たちです。

ここでのポイントは「わざと」障害を起こして、システムの振る舞いを「実験」するということです。

テストではなく、実験というのが、このカオスエンジニアリングのキモなんですよね。

要するに「あれをやってみたらシステムはどうなる?」ということを沢山システムに行ってその振る舞いによって、システムの弱点を見つけ、その情報を知見として深めていく行為をするんです。

それをカオスエンジニアリングと呼ぶのです。

システムの超回復!

筋トレの仕組みは簡単に言うと、「筋肉をいじめて、超回復のときに倍で回復! 筋力アップ!」というわけです。

このカオスエンジニアリングも一種の筋トレといえるでしょう。

システムに対して、意図的に障害を起こして、それによって早期復旧するための「回復力」を高めてあげたり、より強固なシステムにするための知見を深めたり……。

これまでは「よっしゃシステム作った!」→「トラブル発生、なんとか復旧した」→「このトラブル回避のために〇〇をしよう」という、どちらかというと、受け身に近いかたちでした。

しかし、カオスエンジニアリングの考え方では「トラブル発生するまえに、こっちで日頃からシステム虐めて、耐えられるようにするためにシステムを鍛えよう」というどちらかというと、能動的なものです。

よく筋トレする人は先日はなんちゃら筋をトレーニングしたから、今日はほんじゃら筋のトレーニングをしようと、自分の体(筋肉や体調)に対して理解できるようになります。

カオスエンジニアリングも同じように、大規模で複雑な分散システムの全貌を掴みやすくなり、「このシステムはここが弱い」とか「ここは強いから、同じような対応を別の部分の処理に行かせないだろうか?」や「他社のシステムで〇〇というトラブルが発生したらしいけど、ウチのシステムは、そこに関してはしっかりと鍛えているから安心してください」と、サービス(システム)に対して確信を持つことができます。

必要なのは安心感

機械学習を用いたサービスを~とか、AIによる大規模なシステムを~と最近はより複雑なシステムを用いたものが増えてきています。

そうなった場合、ユーザーは何を基準にするのか、それは使いやすさとかもありますが、何よりも「安心感」なのだと思います。

「ウチのサービスは、カオスエンジニアが日頃から自社のシステムに対して障害を起こし、システムの頑強性等を見ています。しかもそれはお客様が使っている本番の環境でなんですよ。

でも、一回もトラブルのお知らせしていませんよね? つまりそういうことです」

と、自分たちも自信をもってユーザーにシステムやサービスを提供できるようになるのです。

一番怖いのは「確証はないけど、まあ大丈夫でしょう」というのが不安なのです。

やっぱり最後は作った人達が「うちのものは大丈夫! なんたって〇〇してるからね!」と言ってくれるものなんです。

物理的なものは分かりやすいですが、目に見えないシステムもこの安心感が欲しいのです。

関連するイベント

【初心者:ハンズオン】Pythonスクレイピングによるデータフレーム

【初心者:ハンズオン】Pythonスクレイピングによるデータフレーム

日時
2018/06/30(土) 12:00〜16:00
会場
阿佐ケ谷アニメストリート 第5区画 SEN STAGE本館(阿佐ヶ谷アニメストリート真ん中の区画になります。当日は看板を目印でお越しください)
住所
166-0004 東京都杉並区阿佐ケ谷南 2丁目40−1 阿佐ケ谷アニメストリート 第5区画 SEN STAGE本館
主催
Walker Insudtries データサイエンス部