AWS、わざとクラウドに障害を発生させて耐障害性を検証できるサービスを提供開始 29
ストーリー by nagazou
いわゆるストレステスト 部門より
いわゆるストレステスト 部門より
Amazon Web Services（AWS）は15日、新サービス「AWS Fault Injection Simulator」の提供を開始したと発表した。この新サービスは、クラウドに対して意図的にサーバの終了や遅延、データベース障害といった障害を引き起こすことができる。これにより、システムの応答を観察することなどにより、アプリケーションの耐障害性を検証できる。こうした意図的に障害を発生させる方法は「Chaos Enginieering」と呼ばれ、Netflixが2012年に採用したことで広く使われるようになったという。AWS Fault Injection Simulatorは、東京リージョンを含む世界各地の商用AWSリージョンで利用可能となった。ただし開設されたばかりの大阪リージョンと中国のリージョンは対応していないとしている（AWSブログ、Publickey、CodeZine）。
みずほ銀行 (スコア:1)
「わ、わざと障害を発生させて対障害性を検証していただけなんだから！」
Re:みずほ銀行 (スコア:2, おもしろおかしい)
障害に対する性能はないことが無事わかりましたね。
めでたしめでたし
Re: (スコア:0)
用法・用量を守って、経営を損なわない障害を心掛けましょう。
Re:みずほ銀行 (スコア:1)
経営陣に対する精神的負荷テストもできて良かったんじゃない？
Re: (スコア:0)
なお、本当に精神的負荷を受けたのは利用者と休日返上で対応にあたった行員の模様
このテストを「受ける」側も (スコア:1)
ベテランが寝てるとか旅行に出かけてる、とかで稼働できない場合に
限られたリソースで応急処置をとるにはどうすんべ、とかも考えるといいんだろうね。
本当に最悪の場合は、旅行中のベテランに連絡をとる必要もあるんだろうけど
その時にベテランはどんな装備を持ってれば対応できるだろうか、
iPad持ってれば大丈夫、いやせめてSurfacePro持っておきたい、とか。
みんなそういう事やってる？
うちは大してクリティカルな案件ないし、そのあたり真面目に考えてないんよなあ。
Re: (スコア:0)
ベテランがいない場合にもトラブルに対処できるよう練習するためのサービスなのでは？
というか自分がそのベテランなら、このサービスでトラブルを仕掛けておいて隠れて見守るが
Re: (スコア:0)
クリティカルなシステムであれば、そのベテランが単一障害点になっている状態がまずいと思う。
そもそも人材が足りず余裕が無いからそれが起こるのだと思うけど、それはそれとして、
理屈で言えばそのレベルで問題の対処を提案できる人間が複数(できれば多数)存在するべきという話になるかと。
誰か特定個人が知識を抱え込むことが無いようにレビューを運用し、システム作業も担当者を固定しないように、チームやプロジェクトを設計する。
そりゃまあ、障害なんて想定外の事態だから障害に発展するのであって、その障害が並の技能じゃ解決できないようなものなら
スーパーマンに泣きつくしかないかもしれないけど。
Re: (スコア:0)
その程度の予測可能な事態で休暇中のやつを呼び出さないといけないって残ってる連中は無駄飯食らいか。
そんなことしないといけない時点で組織として終わってる。
Re: (スコア:0)
トラックナンバーを考えたら、その状態が不味い。
旅行先で事故に有ったら、引き継ぎ出来ずに終わりだよね。
Chaos Monkey by Netflix (スコア:1)
NetflixがAWS用に開発したChaos Monkeyを、AWS自身が「車輪の再発明」したものかしら?
Re: (スコア:0)
マネージドサービスというものでしょう。
インフラ側で障害を再現してくれるならよりリアルだし手軽でもある。
Re:Chaos Monkey by Netflix (スコア:1)
マネージドサービスというものでしょう。
そんなのは記事を見れば判るさ。
で、それはAWSが実装したものなのか、Chaos Monkeyを利用したものなのか?
インフラ側で障害を再現してくれるならよりリアルだし手軽でもある。
クラウド利用者がChaos Monkeyなどを利用して発生させることができるものより、クラウド提供者が発生させることができるものには、当然差がある。
例えば、そのユーザシステムが載っている物理的な機器に障害を起こす、みたいなことは、クラウド提供者でなければ発生させることはできない(物理占有機サービスを除く)。
けど、このマネージドサービスは、そう言うものまでサポートしてるのかな?
Re: (スコア:0)
このサービスの提供の為にAWSが物理的に障害を起こしている発想は無かったなあ。
Re:Chaos Monkey by Netflix (スコア:1)
このサービスの提供の為にAWSが物理的に障害を起こしている発想は無かったなあ。
私もそんなことまでサポートしているとは思いません。
「インフラ側で障害を再現してくれるならよりリアルだし手軽でもある [srad.jp]」というコメントを書く人なら、そんなことを想定しているのかな、と。
もし物理的障害をサポートしてないのなら、「よりリアル」にはならなさそう。
Re: (スコア:0)
成果物の一部は https://github.com/netflix/chaosmonkey [github.com] にあるし、再発明というよりは、積極的に再実装したものかと。
Re: (スコア:0)
ライセンス大丈夫なのかな？
掃除のおばちゃん機能 (スコア:0)
掃除のおばちゃん機能をONにすると、派遣会社からおばちゃんがやってきてコンセントを抜いてくれます
Re: (スコア:0)
このネタよくみるとけど、いつぐらいまでの話なんだろ。
データセンターの類ってマシンルームと呼ぶようなところには掃除のおばちゃんなんか入れないんだよね。
大昔にデータセンターでなくオフィスにパソコンを置いてたサーバにしてた時分の話なんだろうけど、今時ネタにするには時代錯誤もいいとこじゃないか。
Re:掃除のおばちゃん機能 (スコア:1)
オフィスにパソコンを置いてサーバにしてるところ、まだまだありますよ。
派遣のおばちゃんがいるような大企業は知りませんけど、私が出入りしてる中小企業では見掛けます。
さすがにコンセント抜くのはないですが、掃除機や湯沸かし器と同じコンセントに繋いでてブレーカー落ちたことはありました。
Re: (スコア:0)
大手企業でも「あるある」ですよ。
大手企業だと顧客からの要請で立ち上げなればならない社内サービスでも、
サーバとして申請すると監査やら情シスやら経営やらの承認が必要になってしまうので、
「ちょっとお高めのPCです」って申請してこっそりやる、というのが常態化したりします。
しかもそれがないと業務が停止するようなものがあったり・・・・
Re: (スコア:0)
まともなセキュリティで運用してる会社ならサーバルームは掃除のおばちゃんどころか
かなり限られた人間しか入れないよなあ、とか。
エンジニアでも直接インフラ担当してる人間以外はふつう入れない気がする。
Re: (スコア:0)
CO2やハロゲンの消火設備があって人間が立ち入るのは危険まである
Re: (スコア:0)
メインフレーム機が毎日ほぼ一定時刻に応答を停止するから調べてみたら毎日カートリッジ引っこ抜いて雑巾で拭いて戻していた、とあかいうメインフレームの耐障害性を称える逸話が元ネタじゃなかったっけ。つまりメインフレームの時代。
Re:掃除のおばちゃん機能 (スコア:1)
それが元ネタなの?
毎朝掃除のおばちゃんが掃除機の電源を確保するために、機器が接続されているコンセントを抜いて、掃除が終わったら戻してた、って話は聞いたことがあるけど、カートリッジを引っこ抜いて、という話は聞いたことないなあ。
Re:掃除のおばちゃん機能 (スコア:1)
いっそ正直に顧客にも (スコア:0)
昨今のシステム複雑化を踏まえ、サーバの火災訓練(とでも言っておく)を実施いたします。
実際に一部サーバが停止し、予備装置が作動します。
閑散時間帯を指定し、万全の対策にて臨みますが、お客様各位におきましては、極めて重要な取引は遅延いただけますと幸いです。
# で、テスト顧客(無人)を用意
Re: (スコア:0)
いや、無人じゃだめだ。その調子で、キャッシュカードが取り込まれちまっただろ。
行員に指示して、ATMでテスト取引させるんだ。
これが終わりの始まりだった (スコア:0)
まさか、これが原因で「スパルタクス」が誕生しようとは、誰も予想していなかった。