Amazon Web Services: 大規模障害から1年、あるスタートアップの視点
ジェフ・マレック著
2011年4月に発生したAmazon Web Servicesの大規模障害から1年が経ったなんて信じられません。しかし、数日間オフラインになったあの辛い1週間の記念日に、私たちの体験を振り返る良い機会だと考えました。
キース・スミスと私が約3年前にBigDoorを立ち上げた時、エリック・ライスのリーン・スタートアップの原則を多く取り入れて事業を推進することにしました。私たちは毎週、製品の改善を繰り返すことで、お客様のために常に革新を続けています。私たちは非常に小規模なチームで運営しており、常に無駄の削減に努めています。
運用に関しては、当初からラックスタックとケーブル接続モードに費やす時間を最小限に抑え、製品開発に集中できる時間を最大限に確保することに注力していました。Amazon Web Services によってそれが可能となり、市場投入までの時間が短縮され、サーバー仮想化ならではの俊敏性も実現できました。
過去 12 か月を振り返り、障害への対応として行った変更を再検討すると、いくつかの価値ある観察結果が浮かび上がります。
- AWSは、コミュニケーションと透明性の問題に対処するための措置を講じました。（Keith SmithによるGeekWireのオリジナルゲスト投稿をご覧ください：Amazon.comの真の問題は障害ではなく、コミュニケーションです）
- Elastic Block Store が提供するものが必要または希望する場合、オプションは変更されていませんが、リスクは変更されている可能性があります。
- EBS IOP パフォーマンスは、私たちや私が話を聞いた他のすべての AWS EBS ユーザーにとって、依然として最大の懸念事項です。
AWS コミュニケーション： AWS アカウント担当者と優秀なソリューションアーキテクトとの定期的なミーティングが実現しました。これらのミーティングは私たちにとって非常に大きな意味を持っています。Amazon.com 内で何が起こっているかを把握できるという点が大きなメリットですが、メールでは解決に永遠にかかってしまうような無数の質問にも答えを得られるという点も大きなメリットです。
しかし、これはあくまで私たちの意見です。（もし違う経験をされた方がいらっしゃいましたら、ぜひコメントをお願いします。）いずれにせよ、Amazonが大きな変化をもたらすと思われる、まだ2つの大きな取り組みがあります。
- 発生した問題に対処するために過去 1 年間に何をしたかを、独自の根本原因分析とリストされた解決策を参照しながら公開します。
- 製品ロードマップの何らかの形を一般公開するか、少なくともすべての AWS 顧客に公開します。
2番目の質問については、こうした情報を秘密にして競合他社の詮索の目から遠ざけておくべきという考えは誰もが理解しています。しかし、何がいつ起こるのかを私たち全員がより正確に把握できる、低リスクの方法が必ずあるはずです。
Amazonは、競合他社の追い上げを心配する必要がないというユニークな立場にあります。私の知る限り、Amazonほど幅広いサービスを提供している企業は他にありません。（関連記事：今日の統計：インターネットユーザーの3分の1がAmazonのインフラを利用したサイトにアクセス）
Elastic Block Storeオプション： EBSドライブの利便性、永続性、バックアップ機能を求める場合、昨年の障害の影響で大きな変化はありません。新たな緩和策や機能は提供されていません。エフェメラルストレージは常に利用可能であり、ソフトウェアRAID経由でさらに優れたパフォーマンスを得ることができます。しかし、当社の場合、エフェメラルストレージでバックアップされたインスタンスの起動は遅すぎる（テストでは2～3倍）ため、急増するトラフィックやアプリケーションホストのスケーリンググループのニーズに対応できません。また、データベースホストで非永続的なRAIDストレージを使用することは、様々な理由から現実的ではありません。
ここでの 1 つの潜在的な選択肢として、EBS リソースをより安価にし、リージョン間で管理しやすくすることが大いに役立つでしょう。
障害への対応としていくつかの小規模な対策を講じましたが、最終的にはEBSのリスクプロファイルはほぼ変わりませんでした。Amazonがこのような事態を再発させないという確信のもと、猛スピードでイテレーションと製品開発を継続することを選択しました。1年後、その賭けは報われたようです。
EBS の使用に伴う全体的なリスクは変化しましたか? 上記の私の質問 1 を参照してください。
Elastic Block Storeの1秒あたりの入力操作数（Input Operations Per Second）のパフォーマンス：先週、PerconaのMySQL Liveカンファレンスに出席し、講演を行いました（興味のある方はスライドをご覧ください）。シャーディングとデータベースパフォーマンスに関する議論の中で、AWSと仮想化全般に関する話題も数多くありました。大きな不満は、現時点では多くの人がほぼ当然のことと考えていることですが、依然としてElastic Block Storeの1秒あたりの入力操作数（Input Operations Per Second、EBS IOP）、特に書き込みが遅く、唯一予測できるのは予測不可能な点であるという点です。EBS IOPのパフォーマンスは非常に変動しやすいのです。
これを軽減するために、キャッシュやバッファリングなど、様々な対策を講じています。昨年はデータベースシステムをシャーディングし、単一のモノリシックなプライマリデータベースホストから32のシャードノードに移行しました。また、EBSを活用して構築された新しいリアルタイムカスタムBIプラットフォームをテストしています。HTTPリクエストに関しては、当社のAPIは障害発生前の1年間のトラフィック量を数か月で低レイテンシ（平均約0.4秒）で処理できるようになりました。しかしながら、EBS IOPパフォーマンスの一時的な大幅な低下は依然として時折発生しています。
しかし、全体的なパフォーマンスは昨年と比べて実際に向上したのでしょうか？上記の私の質問1をご覧ください。
私の推測では、Amazon は IOP パフォーマンスの問題に対処するために懸命に取り組んでいますが、私たち全員がそれを知っていれば素晴らしいと思います。上記の私の質問 #2 を参照してください。
短期的な思考を持つ議員たちのひどい意思決定の結果として、AWS の使用に対して現在支払わなければならないワシントン州の法外な新しい税金を考慮しても、今年は素晴らしい年であり、2012 年は BigDoor と AWS の両方にとってさらに良い年になりそうです。
それで、Amazon Web Services に対する私の最後のリクエストは、少し過去を振り返って、皆さんの側から将来を考えてみてはどうでしょうか。
ジェフ・マレックは、シアトルのスタートアップ企業BigDoorの共同創業者兼CTOです。BigDoorは、ウェブサイトが独自のゲーミフィケーション型リワードプログラムを簡単に作成できるサービスを提供しています。Twitterで@bigdoor 、ジェフは@jpmalekでフォローできます。
