「パブリッククラウドサービスプロバイダーは急速に拡大しているにもかかわらず、賢明にビジネスを行っていると思われる」（リンティカム氏）

　大手パブリッククラウドサービスプロバイダーの中では「Amazon Elastic Compute Cloud」（Amazon EC2）が前年比で最長のアップタイムを記録し、全リージョンの総ダウンタイムは2.47時間であったことが米CloudHarmonyの調査によって明らかになった。CloudHarmonyはカリフォルニア州ラグナビーチに本社を構え、クラウドサービスプロバイダーのアップタイムを監視する独立系のサードパーティー企業だ。

　CloudHarmonyによると、「Microsoft Azure」のコンピューティングサービスのダウンタイムは約40時間にものぼり、大手クラウドサービスプロバイダーの中で最低の結果を記録している（Microsoft Azureでは2014年11月18日に複数の地域にわたる大規模なクラウド障害が発生し大きく報じられている）。

　「他のクラウドサービスより提供期間が長く、安定しているものもある。その安定は、これまで苦境に立たされたときに他のクラウドサービスより熱心に問題を解決することで得たものだ」とCloudHarmonyの創設者であるジェイソン・リード氏は語る。

　リンティカム氏によると、アップタイムの向上に寄与するものは幾つかあるという。具体的には、エクスペリエンス、フェイルオーバー構成のためのデータセンター増設、オートメーションの推進、密接な社内のコミュニケーション、障害を引き起こすパターンを突き止める能力の向上などだ。

　企業がクラウドサービスを購入するときには総所有コストを考慮する。障害が相次ぐことは最大の不安材料となる。そのため、クラウドサービスプロバイダーはサービスを維持する。

トップを走るAWS

　近年「Amazon Web Services」（AWS）では大規模なクラウド障害が発生していた。だが、2014年はクラウド障害に関して非常に静かだったと同社のパートナー企業は話す。

　AWSのAPNコンサルティングパートナーで米ワシントン州リバティレイクを拠点とする2nd Watchで最高技術責任者（CTO）を務めるクリス・ブリースナー氏は「サービスへの影響や遅延はいくらかあったものの、把握している限り顧客の環境でダウンタイムは発生していない」と語る。

　2nd Watchは、クラウド障害が発生したときに、そのことを顧客に早期警告するシステムとなるアプリを作成する計画を立てていた。だが、この計画は開発の優先リストの最下位事項に落ち着いている。

　「障害が全く発生しなくなったのだ」（ブリースナー氏）

　ブリースナー氏によると、これはAWSが信頼性の高い大規模なインフラ設計分野における専門性を高めてきたことと、苦しみながら成長してきたことに起因するという。AWSがたどった道は、これから成熟期を迎えるクラウドサービスプロバイダーに影響を与えている。

　AWSの副社長を務め、著名なエンジニアでもあるジェームス・ハミルトン氏は、2014年の「AWS re:Invent」カンファレンスでAWSの大規模なイノベーションについてプレゼンを行った。

　AWSは独自のネットワーク、ストレージ、サーバ機器を設計することで、コストの削減と信頼性の向上を実現したとハミルトン氏はいう。

　また、プレゼンで次のようにも述べている。「企業はネットワーク機器メーカーに大量の複雑な要件を提示する。そして、ネットワーク機器メーカーは、これらの要件に基づいて数千万行にも上るコードを記述するが、このような膨大なコードのメンテナンスを行うことは不可能である。だが、このようなものが企業に納品される。AWSはそのようなことは行っていない。当社のネットワーク機器の信頼性が他社のものより高い理由は問題を難しく考えていないからだ」

　AWSはインフラの監視メトリックスを週1回というペースで強化することに腐心している。それが信頼性の向上につながったとハミルトン氏はいう。AWSのアベイラビリティーゾーン（AZ）のシステムは、AZ内にある複数のデータセンターを接続する。これらのデータセンターは同期的にミラーリングされ、高可性を実現している。「Amazon Relational Database Service」（Amazon RDS）などのサービスでも同様に「マルチAZ配置」を提供している。そのため、データが保存される冗長なロケーションの数は増加している。

　AWSの顧客も、より回復性の高いアプリを作成した経験から学んでいる。Amazon RDSのリリース時、マルチAZ配置を使用していた顧客は26％だった。現在は40％が使用しており、最終目標は70％だとハミルトン氏は語る。

　「Amazon Aurora」など、AWSクラウドの中で新しい部類に入るデータベースではさらに高い回復性が提供される。それを支えるのは、基盤となるストレージエンジンのオーバーホールだ。Amazon Auroraのストレージエンジンはメインデータベースとは別に存在し、障害発生時には迅速に復旧できる。Amazon Auroraはデータのコピーを3つ作成し、AZ全体では6つのコピーを作成する。

　AWSのデータセンターはデザインも改良され、最適な信頼性を提供できるようになったとハミルトン氏は話す。同社のデータセンターには最大5万～8万台のサーバを設置できる。

　「さらに大きくすることは造作もないことだが、大きくすることで生じるリスクがある。それは、何か問題が起きたときの損失が莫大になることだ」（ハミルトン氏）

　AWSはスケールアップしながら可用性を最適化する方法を経験から学んだ。IaaS市場に後から参入したAWSの競合企業では、かつて米Amazon Web Services（Amazon）が経験した大規模な障害が発生することもあるだろうとハミルトン氏は予測する。

　「この先、米Microsoftや米GoogleがAmazonに勝負を挑むことがあるなら、どちらも大幅なスケーラビリティの拡張が必要になる。そのようなスケールアップを行う間、顧客は障害が頻繁に発生するリスクを負い続けることになるだろう」（ブリースナー氏）

　GoogleのクラウドがAmazonより優れている分野が1つある。それは、総障害発生時間だ。CloudHarmonyによると、「Google Cloud Storage」の総障害発生時間は14.23分（計8回）。「Amazon Simple Storage Service」（Amazon S3）の総障害発生時間は2.66時間（計22回）だという。

完全無欠なものはない

　連続してエラーが発生することはある。パブリッククラウドプロバイダーで大規模なクラウド障害が発生した場合、その原因はハードウェアインフラの障害ではなくヒューマンエラーであることが多い。そう語るのは、米Gartnerでアナリストを務めるジョーナ・コウォール氏だ。

　「クラウドサービスプロバイダーは障害を回避するためにあらゆるベストプラクティスを試している。だが、現在進行形で変化している複雑なシステムでは障害が起こるものだ。インフラとプロセスを複雑にしすぎていることが原因で企業の対応は遅れがちだ」とコウォール氏は指摘する。そして、クラウドはあるジレンマを抱えていると同氏は補足する。クラウドの魅力はスピードとアジリティだ。だが、十分な検査が行われないアップデートサイクルによってバグが残る可能性がある。このようなバグが顧客に問題をもたらす。

　定期的な再起動はコンピューティングのダウンタイムの原因となることが多い。また、インフラの管理がずさんであることの証拠になるとリード氏はいう。

　「クラウドサービスプロバイダーは障害を避けて通ることはできない。優良なプロバイダーは根本的な原因を調査する。調査結果に基づいて、ポリシーやソフトウェアのいずれかを変更して同じ一連の出来事が二度と起こらないようにするものだ」（リード氏）

　失敗から学んだことはプラットフォーム全体に役立つことがある。そう語るのは、米Rackspace Hostingのソフトウェア開発部門の統括責任者を務めるポール・ボッチオ氏だ。

　「業界が成熟するにつれて、大規模かつサポート可能な手段でサーバをどのように運用できるのか、お互いに学習するようになっていると」（ボッチオ氏）

　米サンアントニオにあるRackspaceの本社では、ボッチオ氏はデスクに大きなモニターを2台並べて、同社のパブリッククラウドのメトリックスを監視している。クラウドで新たに出現する領域は注目を集めている。だが、アップタイムの維持ほど社内で重視されるものは皆無に等しい。

　「顧客はクラウドが常時利用できるものだと考えている。そのため、その点については真剣に取り組んでいる」（ボッチオ氏）

　2009年以降、Rackspaceは全てのデータセンターで99.999％のアップタイムを売りにしている。毎週会議を行い、システムパフォーマンスについて議論し、定期メンテナンスのスケジュールが重複しないようにしている。同社は各データセンターの高い回復性と冗長性を強調している。迅速に問題を診断し、他のデータセンターに問題が流れ込まないようにするためにはクラスタの分離が必要不可欠であることを学んだとボッチオ氏はいう。

　CloudHarmonyの調査によると、Rackspaceのコンピューティングクラウドが2014年にダウンしていた時間は全てのリージョンを合わせて7.52時間だったという。だが、ハイパーバイザー「Xen」のバグが原因で再起動を行う必要があったとき、同社の対応は批判を受けて世間の注目を浴びた。

　「解決すべき問題が発生したときに、制約があって問題について話すことができないと、顧客に状況を説明するのは難しい」とボッチオ氏は語る。

　Rackspaceは熱心なサポートを他社との差別化要因として挙げている。だが、ボッチオ氏は、サポートスタッフに頼らなくても顧客が望み通りの物を手に入れられる状態を実現できれば、なお良いだろうと同僚に話している。

　「確かに問い合わせの電話に応対するスタッフはいる。だが、わざわざ連絡をしたくないと考える顧客が大半を占めるだろう」（ボッチオ氏）

課題として残る透明性

　クラウドサービスプロバイダーは数週間分のアップタイムの情報を各社のWebサイトに掲載している。米TechTargetがアクセスした中では、前年比データを提供しているプロバイダーはなかった。

　リード氏によると、クラウドサービスプロバイダーは情報を公開することを嫌がる。システムで小規模な中断や部分的な障害が発生しても言及しないプロバイダーもいる。ステータスページの信頼性も問題となる可能性がある。プロバイダーが自社でサイトをホストしていて、障害によって顧客の監視ダッシュボードが消えてしまった場合は問題が複雑になる。

　「この問題の一端に、多くの大手エンタープライズクラウドサービスプロバイダーは、クラウドが正常に動作しているかどうかを顧客が検証できる手段を制限していることがある。これは特にSaaSに当てはまる」（コウォール氏）

　コウォール氏によると、ほとんどの人は世界中の場所から、ログインして数分おきに幾つかの動作を行うソフトウェアを設定してユーザーをエミュレートし、クラウドの性能を確認しようとする。だが、このような行為はシステムに負荷が掛かるのでクラウドサービスプロバイダーからは煙たがられている。プロバイダーはこのような行為を契約書によって制限しようとする。つまり、プロバイダーは安定性に関する責任を負わされたくないと考えている可能性が高い。この状況は問題だとコウォール氏は補足する。

　「システム内で許可される行為に関しては、クラウドサービスプロバイダーとの交渉が必要だ」（コウォール氏）

　クラウドサービスプロバイダーはクラウドに関する透明性を向上し、顧客がシステムで何が起きているか把握できるように努めなければならないとRackspaceのボッチオ氏はいう。

　「顧客はスタックの下位レベルの状態まで知りたいと考えている。現状では顧客が利用を尻込みすることになる。そのため、当社ではスタック全体で今まで以上の透明性を実現するための方法を研究している」（ボッチオ氏）

　Googleは本稿執筆のためのインタビューを拒否した。だが、Googleからは「Google Cloud Platform」の信頼性を高めることに尽力しているという声明文が届いた。本稿に対してMicrosoftからのコメントは得られなかった。