続いて2点目の注力分野であるセキュリティへの取り組みを紹介します。クラウドはセキュリティの懸念があるから移行できないと言うCIOが多いのは事実ですが、実情は異なります。セキュリティにおいても、実は感情論が多いのです。データセンターでのセキュリティ対策を、自社構築とAWSで比較すると、AWSのデータセンターでの対策が同等もしくは優れていることが証明されています。
AWSはセキュリティの面でもいろいろなイノベーションを行い、多数のツールやメカニズムを顧客に提供しています。顧客はツールを使用してAWSのリソースを細かく制御できます。これは自社データセンターにはない機能といえるでしょう。また、コンプライアンスやセキュリティに関するホワイトペーパーも公開しています。
障害は起こるという前提で設計
――4月に発生したサービス障害について教えてください。また、その後変化はありましたか？
工学博士の資格も持つWerner Vogels氏
4月に発生した障害は、あるアベイラビリティゾーン（AWSにおける区画の概念）にある1つのストレージに障害が発生したというもので、5年間トラブルがなかっただけに非常に遺憾に思っています。この障害によって、アベイラビリティゾーンを利用している一部の顧客に影響がありました。
AWSのサービスはストレージやデータベース（DB）のシステムを無限に拡張できますが、その背後で信頼性を確保するソフトウェアが動作しており、その上で顧客のソフトウェアを実行しています。そこで利用できるのがアベイラビリティゾーンです。
ただし、その影響範囲は限定的で、アベイラビリティゾーンを利用している大半の顧客には影響がありませんでした。また、影響のあった顧客に対しても、別のアベイラビリティゾーンを利用したフェイルオーバができていたので問題はありませんでした。AWSを仕入れて顧客にサービスを提供している企業に対しても、ほとんど影響なく済みました。
| 年 | 月 | 内容 |
|---|---|---|
| 2010 | 9 | Amazon Identity and Access Management（IAM）のプレビューベータを発表 |
| AWS Management ConsoleでAmazon VPCがサポート | ||
| Amazon EC2のマイクロインスタンスを発表 | ||
| Amazon Linux AMIを提供 | ||
| Amazon EC2にタグ付け、フィルタリング、インポートキーペアなどの機能を導入 | ||
| OracleがAmazon EC2上のエンタープライズソフトウェアを認証 | ||
| AWSがAWS SDK for PHPを提供 | ||
| 10 | Amazon RDSでRead Replicas（リードレプリカ）が発表 | |
| SUSE Linuxをサポート | ||
| AWS Management ConsoleでAmazon SNSがサポート | ||
| Amazon Elastic Load BalancingでHTTPSがサポート | ||
| Amazon Elastic MapReduceで稼働中のジョブフローについてサイズ変更可能に | ||
| 11 | Amazon S3のストレージ料金を引き下げ | |
| Amazon CloudFront正式版を提供、カスタムオリジンとSLAをサポート | ||
| Amazon S3でのマルチパート・アップロード機能を発表 | ||
| Amazon EC2でクラスタGPUインスタンスを発表 | ||
| ISO 27001の認証を取得 | ||
| 12 | Amazon Route 53を発表 | |
| PCI DSS準拠のレベル1として認定 | ||
| Amazon S3で大容量オブジェクトのサポートを発表 | ||
| Amazon EC2へのVMインポート機能を発表 | ||
| Amazon CloudFrontとAmazon Route 53の新しいエッジロケーションを発表 | ||
| アジア太平洋地域でAWS Import/Exportが利用可能に | ||
| 2011 | 1 | 新プレミアムサポートプランを発表し、既存のサポートプランの利用料金を半額に引き下げ |
| AWS Elastic Beanstalk（ベータ版）を発表 | ||
| Amazon Simple Email Service（SES）ベータ版を発表 | ||
| Management ConsoleがAmazon CloudWatch新機能をサポート | ||
| 2 | 第2四半期中にAmazon RDSでOracle Database 11g が利用可能になると発表 | |
| Amazon CloudFrontとAmazon Route 53の最新エッジロケーションをパリに設置 | ||
| Management ConsoleがAWS IAMで設定したユーザーをサポート | ||
| AWS CloudFormationを発表 | ||
| ベーシックサポートとプレミアムサポートが日本語で利用可能に | ||
| 新しいアジア太平洋（東京）リージョンを発表 |
障害はあったものの、それまでの5年間はストレージは安定稼働していた実績があります。実績があったゆえに、今回の障害によってアベイラビリティゾーン利用を後ろ倒しする顧客がいらしたことは事実です。今は耐障害性の高いアプリケーションを実現していただくために、AWSの全機能を利用していただけるように顧客に働きかけています。
そういった背景の中でわたしが個人的に注力している分野は、障害に耐えうるミッションクリティカルなシステムをどう設計するかということです。障害は起こるという前提で設計していくことで、どんな複雑な条件にも耐えられるシステムになります。
究極的な形で役立てている顧客の例では、米国のNetflixは「Chaos Monkey」を利用しています。Chaos Monkeyはランダムにサーバインスタンスを潰すツールであり、実際にサーバを止めてしまうというものです。それによって適切なアーキテクチャを実現できているか、想定した障害に耐えられるかどうかを人為的に試すことができるわけです。
クラウドの信頼性が低いという話ではなく、障害を前提とした設計をすることで潜在的な問題が見えてくるのです。自然の脅威を考えた場合、こうした備えが必要になってくるのではないかと思います。日本の顧客も、事業継続性の面でAWSに関心を寄せてくれています。
AWSの場合、東京はもちろん各地域に少なくとも2つのアベイラビリティゾーンを構築しています。物理的に建物が別になっているだけでなく、洪水や耐震性を考慮した上で相互に影響を受けないように分離しています。また、UPS（無停電電源装置）や待機用の発電機も別々に用意し、さらに異なる電力網を使用しています。それだけでなく、ティア1のネットワークも別々のプロバイダーから冗長性を持たせて接続しています。
分離されているアベイラビリティゾーンを利用することで、複合的かつ複雑な障害にも耐えうるアプリケーションを実行できます。少なくとも自社構築では実現が困難な次元のデータセンターを用意しているのです。
日本の顧客は、事業継続性を地域の概念を踏まえた上で実現しようとしています。たとえ東京リージョンがダウンしても、他のリージョンにフェイルオーバすることで事業を継続できることを求めています。
AWSはこの要求に応えることができ、しかもユニフォームデプロイメントモデルによって、どの地域でも同じサービス、同じインスタンスを提供しています。このため東京で開発したアプリケーションはシンガポールや米国西海岸でも走らせることができます。
また、バックアップを簡単にすることでリスタートを容易にするサービスがパートナー企業からも提供されています。たとえば東日本大震災の直後、日本赤十字社が自社で構築、運用していたサーバがアクセス増によりダウンしました。そこでパートナー企業であるサーバーワークスがシンガポールのデータセンターを使ってサイトを立ち上げる取り組みを行っています。
データセンターをシンガポールに移した理由は、日本ではまだ停電が続く可能性があり、可用性への懸念がゼロではなかった点が挙げられます。とはいえ、日本のユーザーに対して低遅延でコンテンツを提供しなければなりません。そこで「Amazon CloudFront」というCDN（コンテンツ配信網）を利用していただきました。
コストも重要な問題でした。コストを抑えて1円でも多く復興に使いたいという思いが強かったためです。クラウドの柔軟性や運用性の高さによって、資本投資、設備投資、運用コストまでも抑えることができたのです。
障害を前提とした設計を進めることで想定外の問題を予見し、いち早く対応を組み込むことで、サービスの信頼性が向上する。そのメリットを顧客に提供していきたいと考えています。
Keep up with ZDNet Japan
ZDNet JapanはFacebookページ、Twitter、RSS、Newsletter（メールマガジン）でも情報を配信しています。現在閲覧中の記事は、画面下部の「Meebo Bar」を通じてソーシャルメディアで共有できます。東日本大震災の情報は、特設サイト「ZDNet Japan after 3.11」にまとめています。
