Pickup(247)クラウドは単なる他人のコンピュータではない——。後編となる今回は、クラウドプロバイダーの情報開示について説明する。Network」から、@IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。※本稿は2021年9月に公開されたものです。>>〔前編〕はこちらクラウドサービスの障害は、全てのレジリエンス(回復力)メカニズムが不調に陥った結果として(時には障害につながるようなレジリエンスメカニズムの故障が起こった場合に)発生する。クラウドサービスがダウンするのは大抵の場合、1つまたは複数のソフトウェアのバグが原因だ。それらに設定ミスや何らかの人為的ミス——新しい設定やソフトウェアバージョンのデプロイ(展開)プロセスに関連することなどが相まって、ダウンする傾向がある。クラウドサービスの障害は、物理的な障害に関係していることはめったにない。一般的に、これまで物理的な障害が顧客に明らかになったのは、それに対するレジリエンスを提供するソフトウェアが何らかの不調に陥った場合に限られる。あまりにも多くの顧客が、クラウドの障害を単純かつ根本的に物理的なものと考えている。「サーバが故障するから複数のサーバを使うべきだ」「データセンターがダウンするから、別のデータセンターにDR(ディザスタリカバリー)できなければならない」といった具合だ。このモデルは、クラウドやデジタル時代にはそぐわない。企業は、継続的な可用性とレジリエンスを追求する必要がある(アプリケーションに障害が発生した場合に、ビジネス機能を継続するための、段階的なサービスレベル低下などの方法を含む)。クラウド全体の障害だけでなく、アベイラビリティゾーン(AZ)やリージョン、グローバルレベルで発生し得る、サービス単位の障害にも備えなければならない。したな障害は小規模で、実質的には「停止」ではなく、「不安定化」にすぎないことがあるため、サービスエラーに柔軟な耐性を発揮できるアプリケーションが必要となる。これらのことから、クラウドユーザーはリスクに対する考え方を変え、これまでとは異なる設計と運用をする必要がある。同様にクラウドプロバイダーを信頼すること、それも賢く信頼することが重要だ。ユーザー企業がより多くの情報に基づいて意思決定できるように、クラウドプロバイダーは幅広い情報開示を通じてサービスの透明性を高める必要がある。次のような情報開示が求められる。通常、SLOは金銭的な条項を含むサービスレベル契約(SLA)とは異なるものだ。クラウドプロバイダーが社内的に設定する自己評価の基準であり、企業にとってこれを知ることは、自社アプリケーションの設計と社内SLOの設定に役立つ。企業がクラウドサービスのレジリエンスの在り方を理解し、それを踏まえて設計するのに役立つ。サービス依存関係マップの文書化これにより、企業は使用する各サービスの依存関係の連鎖を理解したり、サービスXがダウンした場合にサービスYがそれに代わる最良の選択肢かどうかを検討したり、トラブルシューティングをより円滑に行ったりすることができる。公開ステータスダッシュボードサービスの状態を明確に示し、サービスの運用実績が確認できる確かな履歴データも提供する。企業にとって、トラブルシューティングやユーザーとのコミュニケーションに役立つ。停止の根本原因分析(RCA)の公開これにより、企業は停止が発生した理由を理解し、今後、同様の障害を防ぐためにどんな対策が取られるかを知ることができる。RCAの過去の蓄積も、有益な資料になる。非常に多くの停止が新しいデプロイや設定変更に関連しており、エラーバジェットを含むSRE(サイトリライアビリティエンジニアリング)の原則がクラウドプロバイダーにかなり浸透していることから、停止には興味深いパターンがよく見られる。エラーバジェットが枯渇すると変更が凍結される傾向があり、これは断続的な停止につながる。した不安定な状態が、顧客にとって予測不可能な間隔で再発することがある。SaaSの普及や、IaaSとPaaSの本番環境での利用拡大により、ミッションクリティカルなクラウドアプリケーションは一般化しつつある。クラウドの運用やレジリエンス、BC(事業継続)/DRに関する考え方を近代化する時期に来ている。クラウドのリスク管理では、リスクを回避するのではなく、賢く軽減する必要がある。先進的な企業では、現時点でクラウドを単に回避することは受け入れないだろう。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。