Snow LeopardでEmacs 23.3にパッチをあててビルドした時のメモ。

Ryan Dahl氏（Node.jsのひと）のビデオを見ていたら、最後にサンプルコードをgistコマンドで鮮やかにGistに公開する様子が大変かっこよかったので、gist.gemをインストールした。

$ gem install gist
$ gist hello.js
https://gist.github.com/960284

Gistの認証情報は、以下のように環境変数でも設定できるし、

$ export GITHUB_USER=juno
$ export GITHUB_TOKEN=mysecretgithubtoken

すでにGitHubを常用していて以下のようにgit-config(1)でユーザー名が設定されていれば、たぶん何も設定しないでOK。

$ git config --global github.user
juno

このブログのMarkdownエンジンをBlueFeatherから、Redcarpetに変更した。Markdown Extra記法が使えなくなったけれど、今のところは影響なさそう。

AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、である」調にしたため多少偉そうに見えるかもしれませんが、原文はとても誠実な表現で書かれていますので、その点は誤解なきよう。

一部、文意が汲めなかった部分は原文を併記していますので、ご意見・ご指摘などがありましたら@junyaまでお願いします（@irohirokiさん、アドバイスありがとうございます）。

Resolved: Widespread Application Outage

• Herokuを4年間運用してきて最大の障害
• 専用データベースを利用している大規模アプリケーションでは最大16時間のダウンタイム
• 共有データベースを利用している小規模アプリケーションでは最大60時間のダウンタイム
• アプリケーションのデプロイについてはプラットフォームの広範囲にわたり約76時間（3日間以上）の間不可能となった
• 要するに、大失敗を起こしてしまった

On Specifics

• 問題の発端はAWSの障害
• 以降ではAWS側の障害についても触れるが、Herokuユーザーの受けた被害について彼らを責めるつもりはない
• 先週ユーザーが被ったダウンタイムについてはHerokuに100%の責任がある

What Happened: First 12 Hours

• April 21, 2011 at 8:15 UTC (Heroku本社では午前1時)
  • 監視システムからの警告が届く
  • ステータスページに問題発生の一報を掲載（Twitterでは@herokustatus）
  • 広範囲に渡るネットワークエラーによって、Webやキャッシュ、ルーティングサービスがタイムアウトしていることを確認
  • 調査を始めるとともに、AWSに対して最重要度のサポートチケット作成を行った
• 最初の数時間は、挙動のおかしいインスタンスをシャットダウンして新しいインスタンスに置き換える作業を試みた
  • これは、EC2に問題が発生した場合にいつも我々がとる手段
  • Herokuのプラットフォームは通常であればこの方法で復旧し、ユーザーにとってはごく小さい障害で済む
  • しかし、今回は事態が悪くなっていっていることがわかった
• 最大の問題は我々が使用してるEBSドライブだった（AWSの永続化ブロックストレージ）
  • Herokuでは状態を保存する必要のあるインスタンス（メインはデータベースだが、その他のノードも少数）についてEBSを利用している
  • EBSドライブがどんどん予測できない挙動を示しはじめた
  • 一部のドライブは、新しいインスタンスに接続し直しても完全に反応しなくなってしまった
• 成功の可能性がある対処方法を聞くためAWSのテクニカルアカウントマネージャーと1日中連絡をとっていたが、残念ながらそれらも役には立たず、障害はどんどん拡大していった
• これまでの前例から見て、このような場合にわれわれがとるべき最善の方法は、サービスを動かしつづけるようベストを尽くしつつ（異常なインスタンスを停止させるなど）AWSが問題を解決するのを待つことだ
  • このような事態が1〜2時間異常続くことは稀だった
• 今回の場合、EC2の障害は最終的に約12時間となった
  • 木曜日の午後には新しいインスタンスを一斉に立ち上ることができ、我々は1〜2時間ほどで復旧ができるものと考えていた
  • アプリケーションの大半は木曜日の午後には復旧したが、残りのアプリケーションを復旧させるには非常に時間がかかってしまった

What Happened: The Long Haul

• 残念なことに、EC2はほぼ完全に稼働していたが、EBSシステムはそうではなかった
  • AWSステータスページで確認できるように、EBS障害は最終的に80時間超となった
• 16時間以内に大部分のアプリケーションが復旧したが、障害を受けている共有データベースを利用したアプリケーションも多くあった
  • これらのアプリケーションを新しいサーバーにデプロイし直すのに必要となるgit pushを受けるサーバーなど、いくつかのサーバーにも問題が発生していた
• そこからの48時間は、弊社のエンジニアがAWSと共に可能な限り早くサービスを復旧させることに費やされた
  • 36時間の間、EBSディスクが応答を返し始めるとともにサーバーが徐々に稼働し始めるのを、ゆっくりではあるが確認できた
• gitサーバーの問題によってデプロイができないアプリケーションを持つユーザーとも協力して対応にあたった
  • そういったユーザー向けにはケースバイケースでデプロイ用の新しいリポジトリを作成した（我々がオリジナルのサーバーを稼働させるために作業をする傍ら、彼らはそちらにデプロイを行うことができた）

Our Response

• 我々の監視システムは問題を正しく検知した
  • 待機中のエンジニアは直ちに問題の重大さを認識して、問題発生時の責任者（Incident Commander）を起こした
  • 責任者はAWSと連絡を取り、問題対処にあたるようHerokuエンジニアを起こし始めた
• 問題が長時間に渡ることが明らかになると、運用チームは8時間シフトの緊急問題指揮ローテーションを組み、常に万全の体制で事態に対処できるよう務めた
  • サポートチーム、データチーム、エンジニアリングチームも24時間体制で対応にあたった
• 我々は大部分の無料ユーザーよりも大口の課金ユーザー（top-paying customers）の復旧を優先した
  • 無料のアプリケーションよりも、専用データベースを利用した顧客の復旧が早かったのはそのため
  • 我々は、この優先順位付けが理にかなったものであると考えているが、同時にすべてのユーザーに対しても高いレベルのサービスを提供できるようにも努力をする
  • 課金ユーザーにとっての障害時間（大部分が16時間未満）は無料ユーザーのそれ（いくつかのケースでは3日間）よりも短いものではあったが、我々は今回のダウンタイムをすべてのアプリケーションが復旧するまでの時間として計測する
• 問題解決までの間、ステータスページの更新を行った
  • 更新内容が詳細に欠けているとか、（ほとんどの更新内容が）直前の内容の繰り返しでしかないといった声もあった
  • これは今後改善していきたい点の1つだが、実際には思っているよりも難しいことでもある
  • 長い一連の時間、バックアップからDBをリストアするとか代替システムをオンラインにする、といったことがあるため、1時間毎の更新では状況が大きく違ってるように見えない（There are large swaths of time where it's simply a matter of continuing to restore databases from backups and otherwise bring replacement systems online - one hour doesn't look too different from the next.）
  • 重要なのは、すべてを稼働させるために我々全員が復旧に取り組んでいたということであり、またステータス更新はそれを皆さんに伝えるためのものである

改善

• IaaSレイヤーでの障害は必ず発生するもの
  • その障害からユーザーを守ることがHerokuの責務であり、それらの事柄を抽象化することが我々の価値の1つである
  • エンジニアたちは、今回のようなインフラレベルの障害に我々が対処できるようアーキテクチャを変更することについて議論している
• 今回の経験からIaaSについて学んだ大きなことがある
  • 1つのリージョン内の複数のゾーンに分散することは、我々が考えていたようなパーティショニングとはならない
    • 複数リージョンへの分散について詳しい調査を始める
    • これまでにも同様のことを検討したことはあった（ユーザーはネットワーク遅延または法的な理由で物理的に近い場所を望むため）
    • ユーザーやアドオンプロバイダー（ネットワーク遅延が影響するアドオンの場合はインフラを複数リージョンに分散させる必要がある）への影響を避けられない大きなプロジェクトとなる
    • 可用性において複数リージョンが有効であることが明らかになったため、より高い優先度で検討していく
  • ブロックストレージはクラウド向きの技術ではない
    • EC2やS3などのAWSサービスはこの4年間でどんどん安定し、信頼性も高まり、性能も向上してきた
    • 残念ながらEBSはそれほど改善されないどころか、実際には悪くなっている
    • 世界でも有数のインフラエンジニアであるAmazonの従業員がうまく稼働させられないものは、恐らく誰にもできないだろう
    • ブロックストレージは物理的に特定の場所に依存しており、容易に転送することができないためクラウド向きではない
    • EBSへの依存をどのように減らしていくのかは難しい問題
  • すべてのデータベースに対して連続的にバックアップをとる
    • 専用データベースを迅速に復旧できたのはバックアップがあったから
    • Herokuの新しいPostgreSQLサービスでは、自動的にデータベースのリカバリができるよう連続的なバックアップを行う仕組みがある
    • ここしばらくの間、このバックアップシステムを共有データベースサーバーにも移植しており、今回の障害発生時にはテストが完了した段階だった
    • 現在、すべての共有データベースサーバーをこの新しいバックアップシステムにアップデート中で、2週間以内にはすべてのサーバーに適用される

まとめ

• 今回の障害は受け入れがたいもの
• このようなことはもう二度と起こしたくないし、そうならないよう懸命に取り組んでいる
• 不満を抱いて当然のユーザーからの協力と寛容さは素晴らしいものだった
• ユーザーからの信頼に感謝するとともに、その期待に応えられるようにしていく

ActiveRecord::Baseを継承していないクラスでattr_accessibleを使う方法（for Rails 3）。

class Person
  include ActiveModel::MassAssignmentSecurity

  attr_accessor :name, :role
  attr_accessible :name

  def initialize(values = {})
    sanitize_for_mass_assignment(values).each do |k, v|
      self.send("#{k}=", v)
    end
  end
end

• Module: ActiveModel::MassAssignmentSecurity::ClassMethods