タグ別アーカイブ: ダウンタイム

米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る - Publickey

NetflixがChaos Monkeyで試していたシステムの中には、同社がバックエンドデータベースとして採用しているNoSQLのCassandraも含まれていました。実は同社の今回のブログはこの部分がいちばんの見所になっています。

Last year we decided to invest in automating the recovery of failed Cassandra nodes. We were able to detect and determine a failed node. With the cloud APIs afforded to us by AWS, we can identify the location of the failed node and programmatically initiate the replacement and bootstrap of a new Cassandra node.

昨年、私たちは落ちたCassandraノードの自動リカバリに取り組むことを決断した。落ちたノードを検出することは可能であり、AWSによるクラウドAPIでそれがどのロケーションなのかを判別できるため、それを置き換え、新しいノードを立ち上げるプログラムを実現した。

この自動化を実現した上で、Chaos MonkeyによるテストにはCassandraが加わり、サーバが落ちても動作し続けるように検証が続いたそうです。

この結果、今回のAmazon EC2のメンテナンスでは、運用中の2700を超えるCassandraノードのうち218がリブートされ、そのうち22ノードのリブートが失敗したにもかかわらず自動的に復旧が行われ、全体としてはダウンタイムゼロでAmazon EC2のメンテナンスリブートを乗り切ったと報告されています。

Netflixのブログは、「パーシステントレイヤー(データベースのような永続的データを担当するレイヤー)であっても、レジリエンス(障害などへの対応力や回復力)の計画を持つべきだ。もしCassandraをChaos Monkeyのテストに加えていなかったら、今回の話は別の結果に終わっていただろう」と結んでいます。クラウド上に展開したシステムをどのように設計し、テストすべきなのか、大きな示唆を与えてくれているのではないでしょうか。

引用元: 米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る - Publickey.

4億5000万ユーザーWhatsAppのエンジニアはたったの32人 「広告なし、ゲームはやらない」貫く – ITmedia ニュース

「450, 32, 1 and 0」。買収発表を受け、WhatsAppに投資していた著名ベンチャーキャピタルSequoia Capitalのジム・ゲッツ氏がWhatsAppの強さを4つの数字を挙げて説明している。 「450」は450 million、つまり月間アクティブユーザーの数。2億ユーザーに到達したのは9カ月前だったが、それから倍以上に増えた計算だ。ゲッツ氏によると4億5000万ユーザーへの到達は「史上最速」という。 「32」はエンジニアの数。同社の開発者は1人当たり1400万ユーザーを支えていることになり、IT業界では前代未聞のレベルだとしている。それでもErlangによって構築されたプラットフォームでは1日当たり500億のメッセージが飛び交い、ダウンタイムは0.1%以下。「ユーザーは電話への信頼と同様にWhatsAppを信頼している」という。 共同創業者のジャン・コウム氏の机には、「広告なし! ゲームはやらない! ギミックいらない!」という張り紙がしてあるという。このポリシーを貫くための数字が「1」だ。同アプリは2年目以降、年額0.99ドルの有料制になるが、わずかな金額を支払うことでユーザーはピュアにメッセージングサービスを利用できるようになっている。 「0」は、WhatsAppが完全に口コミだけで広まったことを示す。同アプリの成功は、マーケテ%2

引用元: 4億5000万ユーザーWhatsAppのエンジニアはたったの32人 「広告なし、ゲームはやらない」貫く – ITmedia ニュース.

2013年SMB(中小中堅企業)における仮想化データ保護報告書 | 仮想環境(VMware & Hyper-V)エンジニア技術ブログ

報告書の結論として、SMBの85%がバックアップとリカバリでのコストに関する課題をかかえていて、83%が機能の欠如、80%が複雑性を経験しています。

他の結果として:

●SMBでのリカバリー:仮想サーバは物理サーバよりも少し早い結果。

SMBの仮想サーバのリカバリはそれぞれで4時間21分、4時間51分で、物理サーバよりも少し速くなっています。

●Eメールなどの個別ファイルのリカバリーは12時間8分を要しています。SMBの62%はしばしば個別ファイルまたはアプリケーション・アイテムの抽出する必要以上にリカバリする必要があります。

●SMBのバックアップ・ツールの67%は複雑性を付加する可能性のあるエージェントを使用し、それらのSMBの76%はエージェントの複雑な管理、低パフォーマンス、バックアップとリカバリの両方における頻繁なファイルなどの問題に直面しています。

●SMBの63%は会社が成長すれば、今のバックアップ・リカバリー・ツールではデータとサーバの容量では効率が落ちると考えています。

●SMBの41%はITフェイル時でのダウンタイムは1時間当たり15万ドル以上としています。停電では、決められた回復時間では、これらの企業ではに60万ドル以上の費用が係るとしています。

●バックアップ・マシンの17%以上のリカバリー率はリカバリー時間とダウンタイムのコストを増加させています。8%のみがテストのことを考えていることは驚きではありません。

●現在、平均SMBの33%の仮想インフラはバックアップをしていません。

●SMBの55%が2014年までに仮想サーバ用のバックアップ・ツールの変更を予定しています。

引用元: 2013年SMB(中小中堅企業)における仮想化データ保護報告書 | 仮想環境(VMware & Hyper-V)エンジニア技術ブログ.