さくらのクラウドの件

2011年11月に導入されたさくらのクラウド、最低価格が月額2500円と安く大きな話題になったにも関わらず、春先に大規模なストレージ障害に見まわれ、新規募集を停止した。ここまでは記憶にあったのだけど、その後ニュースを聞かないな、と思って調べてみた。まとめると、6月の予定では9月中に新規募集を再開する予定らしい。頑張って欲しい。

まだ完全に復旧していない？

2012/3/23付けで新規申込み受付の一時中止というアナウンスが出ていた。半年近く経つから当然復旧しているのかと思ったら、まだ新規募集してない。私がニュースを見としていただけだと思ってたけど、実はまだ完全に復旧できていないのか。。

経緯

このページに障害に関する報告がまとまっている。

2011/12/9 -12/24 にストレージに不具合
  • サーバがダウンし、起動してこない
  • サーバは立っているけれど、ディスクアクセスに失敗することがある
2012/1/13
  • 集中型ストレージへのアクセス集中が問題 - アクセス制限で対処
  • サーバダウンはKVMのバグ
  • 解約したカスタマのデータ削除の失敗
  • それを解決しようとしたプログラムのバグで、別のカスタマのデータ削除(！)
  • バックアップを取ることになっているのだが、アクセス集中でとれていない
2012/1/27
  • アクセス制限を解除
2012/2/24
  • ストレージの増設予定をアナウンス
2012/3/16
  • ストレージの追加完了。新規アカウントはそちらへ。
  • ストレージ性能が断続的に遅くなる症状は改善されていない。原因はストレージにあり。
2012/3/23
  • 新規受付中止

なにがあったのか

報告書が上がっている。要するに、ストレージシステムのテストが足りていなかった、ということなのだが、幾つかに分けて書かれている。

ストレージサーバとの接続が切れる

両方共死活監視に失敗して意図的に切っていた、という。。。

  • pingでストレージの死活監視をしていたら、パケットロスで誤認識してしまい、接続断
  • IB のSMからの死活監視にストレージサーバのインターフェイスが答えなくて、接続断
ストレージ上のファイル数に対するスケーラビリティ問題

ユーザのディスクはストレージ上のファイルとなるが、これが増えたらおかしくなった、という話。

  • クローンが遅くなりタイムアウト
  • これは直接関係ないが、ファイル数を減らそうとして間違って他のユーザディスクを消したり
アクセス増大に対するスケーラビリティ
  • 単に性能低下
  • 監視もできなくなる
  • ファイルコピープロセスが暴発
ストレージ

ストレージって何使ってるんだろう、というのでちょっとぐぐってみると、こんなページが見つかった。OracleのSun ZFS Storage 7320 Appliance、だそうだ。

対応

外部ベンダの製品だとどうしてもターンアラウンドが長くなるので、内製のストレージシステムに置き換えるのだそうだ。publickeyの記事によると、IAサーバ+Linux+IB で iSCSI接続。

ベータテストを行なって、9月から再度募集の運びとか。

所感

結果から言えばOracleがチューニングに失敗してケツまくった、という形に見える。Oracleの方からは何もアナウンスが出ていないようだけど、こういう場合って代金どうなるんだろうなあ。。

本質的な問題は、実環境の規模でのテストがOracleの側でもさくらの側でも出来なかった、ということに尽きるだろう。しかしクラウド環境だと同じ規模の環境を用意することは、普通不可能なので両社を責めるのは酷かもしれない。

しかし、小さく初めて、徐々に大きくしていくなどの、リリースエンジニアリングをしていれば、被害はもう少し小さくできたのではないだろうか。その点は悔やまれる。

自社のエンジニアが完全に理解できる範囲で作りなおす、という方針は正しいような気がする。4大クラウドベンダはどこも自社開発の技術だし。正直、IBなのにiSCSIなのか、という気もするけど、ここも理解できている技術で、ということなのだろう。

ぜひぜひ、頑張っていただきたい！

すごいHaskellたのしく学ぼう!

技術書

Miran Lipovača

Haskell入門書。一見軽い入り口だけの本のようにも見えるが、内容的には結構ハードでガンガン進むので、読み流しているとガンガン置いて行かれる。コンパクトにまとまった良書ではあるが、この本を読んだだけではHaskellの深奥にはたどり着けない気がする。ある程度わかった人が読むと、いろいろ腑に落ちるのではないかと。

というわけで私には表面的にしか理解できなかったので、ちゃんと手を動かして勉強してみます。

すごいHaskellたのしく学ぼう!
すごいHaskellたのしく学ぼう!
posted with amazlet at 12.09.01
Miran Lipovača
オーム社
売り上げランキング: 3474
Amazon.co.jp で詳細を見る

Amazon 2011年4月の障害

Amazon EC2

古い話だけどこちらも。publickeyの記事より。2011年4月21日から23日にかけて生じた大規模障害。こちらがamazonからの発表。EBSの構成について詳しく書かれていて非常に興味深い。あんまり関係ないけど、このページすっごく読みにくい。改行幅が小さすぎ、英語向けに調整されたスタイルシートをそのまま使ってるんじゃないか？1行の文字数が多すぎ。

症状

アメリカ東部のリージョンで、EBS(Elastic Block Store)へのアクセスができなくなった。このEBSというのは、普通のコンピュータで言うところのHDDなので、アクセス出来ないとEC2のインスタンスが全然動かない、ということになる。

EBSの構造

  • EBSは、プライマリとセカンダリの2系統のネットワークで接続された多数のEBSノードから構成されている。
  • EBSでは、データは複数のノードにレプリケーションされる。データはプライマリ・レプリカに対して書き込まれる。書き込みは即座に他のノードのレプリカに反映される。
  • レプリカとの通信がとれなくなると、プライマリ・レプリカを持つノードはクラスタ上の別の領域を確保して新たにレプリカを作成する。この動作中はレプリカがない状態になるので、書き込みは不可となる。
  • リージョン全体のEBSを管理するコントロール・プレーンと呼ばれるサービスがある。このサービスはすべてのAZにまたがって存在する。
何が起こったか
  • プライマリネットワークのルーティングを変更しようとして誤ってセカンダリネットワークにルーティングしてしまった。セカンダリは容量が少なく、すぐにパンクした。その結果特定のノード群に対するネットワーク接続が、プライマリ、セカンダリの双方で途絶した。このネットワーク障害はすぐに復旧されたが、EBS内部ではすでにドミノが倒れ始めていた。
  • レプリカを失ったノード群は、新たにレプリカを作成するために検索を開始した。通常はすぐに終わる動作だが、大量の検索リクエストが発生したため輻輳した。多くのノードはレプリカを見つけることができずスタックした。また、リクエストを連続して行う仕様だったためネットワークへの負荷は増大した。
  • 障害があったAZが、コントロールプレーンサービスからの司令を処理できなくなったため、コントロールプレーンサービスのスレッドが枯渇し、他のAZの処理もできなくなってしまった。
  • EBSに依存した他のサービス、たとえばRDSなども当然スタックした。
所感

わずかなオペレーションミスがトリガーとなり、障害が拡大していくのは悪夢のようだ。複雑に相互に依存したシステムはいきものみたい。こういう種類のシステムを設計するには、全く違う方法論が必要なんじゃないだろうか。

Amazon Glacier

Amazon EC2

Amazon Glacier なるサービスが公開された。Glacierは氷河。データを凍りづけにするってことか。

なんなのか

要するに（おそらくは）テープバックアップストレージのクラウドサービスである。非常に安価である代わりに読み出し速度は非常に遅く、読み出しに数時間もかかる。

特徴

  • 暗号化して保存。通信路もSSLなので安心。
  • 99.999999999%のdurability だそうだ。9が11もならんでる。。イレブンナインというやつか。。複数の施設でそれぞれ複数のデバイスに書き込んでいるとのこと。すべての書き込みが終わらないとSUCESSを返さないので、書き込み失敗ということもない。
  • リージョンを指定できる。
  • ディスクを直接送りつけるImport/Exportサービスにも対応
  • 今後S3と連携しシームレスにバックアップするサービスを導入予定
  • 読み出し時には、読み出しジョブを投入する。実行には3.5-4.5 時間かかるとのこと。

お値段

場所によって違うが例によって最安のUS East で $0.01 / GB 月 。1T で10ドル。S3が $0.1/GB 月ぐらいだから、だいたい10分の1。

アップロードはただだが、ダウンロードには$0.1/GBぐらいの費用がかかるのは GlacierもS3も同じ。

月1T10ドルというのは、2TのHDDが100ドルぐらいで買えちゃうことを考えると結構微妙ではある。。。S3との価格差がわずか10倍というのは、利便性を考えると、納得行かないところか。

所感

ファーストサーバの件から考えても、たしかにテープバックアップのような、安価な超大容量のストレージは必要だが、テープ装置はメンテナンスのコストがかかりすぎて、よっぽど大規模な事業所でもないと、なかなか導入できない。バックアップとってるけどリカバーしたことがなくて、いざやろうと思ったら読めなかった、って話もよく聞くし。ひょっとしたら一番クラウド化して嬉しい分野かも。
Amazonの目の付け所はさすがだなあ。。

しかし、これを使っても1Pのデータを1年保持するにはざっくり1000万円か。。やっぱりデータ保持は大変だよ。

ファーストサーバの件

これも古い話だがまとめておく。2012年6月20日に発生した障害。
日経の記事。こちらも。
最終報告の記事。

何が起きたのか

ファーストサーバは、レンタルサーバ会社。主に仮想環境のホスティングを行なっている。そのホスティング環境上のファイルが大規模に消失し、しかもバックアップがなかった。
本来ホスティングビジネスではバックアップはユーザの責任なので問題はないといえばない様な気もするのだが、まずいことに、サイボウズOfficeによるSaaS的なこともしており、こちらはユーザに対してバックアップを保証していた。というかユーザにバックアップをとる方法が提供されていなかったとか。これはひどい。

障害の原因

非常にかいつまんで書くと、

  • パッチを当てるためのプログラムにバグがあり、
  • それを検証環境で動かしたにもかかわらずバグを見つけることができず、
  • 本番環境に適用したのだが、バックアップ環境にも自動的に適用された

という3つのミスが積み重なり、このような結果になったとのことである。

原因の本質

しかし、障害の本質は、ファーストサーバーには「バックアップ環境」はあったが、データバックアップはなかった、ということにある。ここでいうバックアップ環境はダイナミックスタンバイしている環境で、Availabilityを高めるための仕掛けにすぎず、本質的にはデータを保護するための仕掛けではない。しかしファーストサーバーでは、このバックアップ環境を持って、データ保護としていたらしい。バックアップ環境は、ハードウェア障害に対しては意味があるが、ソフトウェア障害や今回のようなオペレーションミスに関しては意味が無い。

昨年2月には、GMailがやはりソフトウェア障害で特定のユーザに対してすべてのデータセンター上のデータを消すという荒業をみせたが、この際にはちゃんとテープアーカイブから復旧されている。当時Googleがテープアーカイブ取ってんのか。。と驚いたものだが、この種の障害に対しては、やはりテープが有効なのか。

もう一つの本質は、この保守作業が、ベテラン作業員によるマニュアル化されていない作業だったことである。管理に問題があったと言わざるをえないだろう。

所感

SaaS環境として使っていた企業への賠償がどうなるのか気になるところ。バックアップ不要をうたっていたようなので、賠償責任は免れないだろうが、被害額の算出はどうするんだろう。プライスレスとしかいいようがない。

クラウドにデータを預けることを、お金を銀行に預けることに例えることがある。ちゃんとした銀行を選ぶように、ちゃんとしたクラウドプロバイダを選べば良い、ということ。しかしデータとお金には本質的な差がある。お金は第三者が補償することができる。つまり最悪銀行がつぶれても大丈夫なように政府なり保険会社なりが保証することが可能である。しかしデータではそうは行かない。。。できることは複数のサービスプロバイダに複製を置くことぐらいだが、データ漏洩の可能性や費用を考えるとなかなか。。

AmazonのGlacierは、こういうバックアップの受け皿なのだろうか。

ZooKeeper を使ってみる(2)

ZooKeeper

1年半ぶりにZooKeeperネタ。複数サーバを立てるには、というお話。まずは同一ホストに複数のZooKeeperノードを立ててみる。

設定ファイル

設定ファイルをノードごとに用意する必要がある。最小限の設定ファイルは、下記のようになる。

tickTime=2000
dataDir=/tmp/zookeeper/1
clientPort=2181
initLimit=5
syncLimit=2
server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

initLimit はフォロワー（リーダ以外のノード）がリーダに接続して同期する際の時間の（チック数での）上限。initLimitが5でtickTimeが2000msなのでこの場合は10秒が上限になる。
SyncLimit はfフォロワーがリーダに対して同期遅れになっていても許される時間の上限（チック数）、だそうだ。よくわからないけど。
同一ノードなので dataDir はそれぞれ異なるようにしないといけない。clientPortも同様。

server エントリでノードを指定する。番号はノード番号、後ろの2つはポート番号。これも同一ホスト上なので一つづつずらしてある。

myid

ちょっとハマったのはmyidというファイルを用意しないといけないということ。$(dataDir)/myid として、１とか２とか書かれたファイルが必要。こんなスクリプトを書いて生成してやる。

mkdir /tmp/zookeeper
mkdir /tmp/zookeeper/1
mkdir /tmp/zookeeper/2
mkdir /tmp/zookeeper/3

echo '1' > /tmp/zookeeper/1/myid
echo '2' > /tmp/zookeeper/2/myid
echo '3' > /tmp/zookeeper/3/myid

起動

コンナスクリプトで一括して起動してやる。

export CLASSPATH=zookeeper-3.4.3.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf
java -cp $CLASSPATH org.apache.zookeeper.server.quorum.QuorumPeerMain conf/zoo.1.cfg &
java -cp $CLASSPATH org.apache.zookeeper.server.quorum.QuorumPeerMain conf/zoo.2.cfg &
java -cp $CLASSPATH org.apache.zookeeper.server.quorum.QuorumPeerMain conf/zoo.3.cfg &

トラブル

なぜかタイムアウトばかりして接続できない状態になった。よく見ると、サーバの残骸？のようなJavaプロセスがいて、それを消したら正常に動作するようになった。全く良くわからないのだが、接続がそちらのプロセスに行ってしまって接続できていなかったのかもしれない。。不思議。。

Mat Honan の件

さんざんあちこちで書かれているけど、備忘録としてまとめておく。
ソースはこちら。

何が起きたのか

もとGIZMODEでWiredに移った人気ブロガー？のMat Honanのさまざまなアカウントがハックされ、Twitter に彼のアカウントでひどいTweetが投稿された。それだけでなく iPhone, iPad, Macbookの類がすべて消去された。犯人の目的はTweetで、消去は目的ではなかったと思われる。

どこからどうなったのか

住所を取得

運用しているサイトのドメインのWHOISから入手

Amazon からクレジットカードの下4桁を取得

まず、犯人はAmazon に電話し、新しいクレジットカードを登録する。これには住所を用いる。
一度電話を切り、再度Amazonに電話し、新しいクレジット番号と住所を使ってアカウントをリセット。ログイン権を得る。ログインすると、本来用いていたクレジットカードの「下4桁」が表示される。

.me アカウント奪取

Appleに電話し、住所とクレジットカードの下4桁で認証させ、.me アカウントをリセットさせて奪取。.me アカウントはApple IDなので、これで iCloudの権限を奪取。iPhone, iPad, Macbook を盗難時の remote wipe機能を用いて消去。

Google アカウント奪取

.me アカウントがGmailのセカンダリアドレスになっていたので、パスワードをリセットで新規パスワードをセカンダリに送らせることでGoogleアカウントを奪取

Twitterアカウント奪取

あとは、パスワードリセットすればテンポラリパスワードがGoogle アカウントに送られてくるのでやりほうだい。

問題はなにか？

本質的にはセカンダリアドレスを登録しておいたことが、セキュリティホールになっている。複数の侵入手段があるので、最も弱いところが全体の強度になってしまうわけだ。

複数のアカウントが連携していると、同様に最も弱いリンクから芋づる式になる。

そもそも、クレジットカードの番号の扱いに関するコンセンサスが無いというのも問題。下4桁だけを表示しないところもあれば、下4桁だけを表示する場合もある。あわせると復元できてしまうし。。。

所感

家族写真が全部消えてしまった、というのには戦慄を禁じ得ない。。クラウドにおける認証のあり方を考えてしまう。まあ、そもそもクレジットカードそのものが、重要性のわりにはあまりにずさんな仕掛けだよなあ。。