組織では、多くの場合、クラウド導入の準備フェーズ中にアンチパターンが発生します。 このようなアンチパターンが原因で、予期しないダウンタイム、ディザスター リカバリーの問題、可用性の問題が発生するおそれがあります。
アンチパターン: リリースされたサービスは運用の準備ができている想定する
クラウド コンピューティングは急速に進化しているため、多くの場合、組織は新しいサービスのプレビュー バージョンをリリースします。 組織は、運用環境で使用可能な任意のクラウド サービスを使用できることを前提とする傾向があります。 しかし、次のような理由から、問題が発生するおそれがあります。
- 通常、プレビュー サービスでは、稼働時間のサービス レベル アグリーメント (SLA) は提供されません。
- 多くの場合、新しいサービスは、既に利用可能なクラウド サービスほど成熟していません。
例: 運用環境でプレビュー サービスを使用する
研究機関が、運用環境でプレビュー クラウド サービスを使用します。 このサービスはユース ケースに適しているようですが、研究所ではサービスを十分に評価していません。 また、その参照アーキテクチャの要件とガイドラインに従っていません。
予期しないダウンタイムにつながるプレビュー サービスで問題が発生します。 この機関は、一般的にクラウド サービスが、保証されているほど成熟しておらず、回復力もないと見なすようになりました。
推奨される結果: 運用環境で事前承認済みのクラウド サービスを使用する
プレビュー段階の新しいサービスを評価する場合は、概念実証 (POC) シナリオでのみこれらのサービスを使用します。 これらのサービスは SLA がないため、運用環境では使用しないでください。 クラウド サービスを承認する際の機能と成熟度の適切なバランスを決定します。 クラウド サービスを迅速に評価するために確立されたフレームワークについては、「クラウド サービス デュー デリジェンス チェックリスト」を参照してください。
アンチパターン: 回復性と可用性の向上を想定する
クラウド コンピューティングは、多くの場合、オンプレミスのコンピューティングよりも大きい利点があります。 たとえば、次のようになります。
- 回復性の向上: 障害、エラー、またはローカライズされたインフラストラクチャ インシデントに耐え、ユーザーが目に見える中断なしに動作を続けます。
- 可用性： 重大なダウンタイムなしで正常な状態で動作します。
ほとんどのクラウド サービスにはこれらの利点があるため、多くの組織では、すべてのクラウド サービスが既定で回復性と高可用性を提供すると想定しています。 実際には、これらの機能を使用するには、多くの場合に追加のコストとさらなる技術的労力が必要となります。
例: 高可用性を想定する
スタートアップは、サービスとしてのインフラストラクチャ (IaaS) にミッション クリティカルなアプリケーションを実装します。 このスタートアップ企業の開発者は、稼働時間 SLA が 99.9% の仮想マシン (VM) を調査しました。 コストを削減するため、1 つの VM と Premium Storage を使用します。
VM に障害が発生しても、そのアプリケーションは復旧できません。 予期しないダウンタイムが発生しました。 クラウドによって既定で高可用性が実現されることを想定していました。 パフォーマンスの保証は次の内容によって異なることを認識していませんでした。
- サービスとしてのプラットフォーム (PaaS) やサービスとしてのソフトウェア (SaaS) などのサービス モデル。
- 負荷分散された可用性セットや可用性ゾーンなどの技術アーキテクチャ。
推奨される結果: 回復性とコストとのバランスをとりながら、発生するエラーを減少させる
障害の範囲を減らすことができるアーキテクチャのベスト プラクティスについては、信頼できる成熟したリソースを参照してください。
高い回復性や可用性など、コストと機能の適切なバランスを決定します。 通常、回復性が高いほどコストが増加します。 次に例を示します。
- 単一の VM では、99.9% の稼働時間が保証された SLA を実現できます。
- 同じワークロードを実行する 2 つの VM では、99.95% から 99.99% までの間の稼働時間の SLA が実現されます。
クラウドベースのソリューションを設計する際に 、要件エンジニアリング の重要なプロセスに取り組みます。
アンチパターン: クラウド プロバイダーになる
一部の組織では、社内の IT 部門をクラウド プロバイダーにしようとします。 その場合、IT は参照アーキテクチャに対して責任を負います。 また、IT は、部署に IaaS と PaaS を提供する必要もあります。 このような作業は通常、IT のコア ビジネスの一部ではないため、結果として得られるサービス内容は、使いやすさ、回復性、効率性、セキュリティが備わっていないおそれがあります。
例: モノリシック マネージド クラウド サービスを提供する
企業の IT 部署が、IT と部署の仲介者として機能するクラウドのセンター オブ エクセレンス (CCoE) を確立します。 企業がクラウドに確実に準拠するために、管理取締役会は、モノリシックなエンドツーエンド サービスを提供するタスクを CCoE に割り当てます。 CCoE は、フル マネージドのクラウド VM をサービスとして注文するために、部署が使用できる社内クラウド調達ポータルを設定します。 IT は、プラットフォーム全体にアクセスして使用できるユーザーを制御します。 その結果、IT 部門は、Azureが提供するさまざまなサービスを使用することを積極的に防止します。 部署は、クラウド ポータルにアクセスできません。 Secure Shell (SSH) と リモート デスクトップ Protocol (RDP) を介してのみ、注文したサーバーにアクセスできます。
いくつかの理由から、CCoE では、クラウドで使用可能な各サービスをラップするためにモノリシック管理サービスを提供するときに、問題が発生します。
- クラウドでは、複数のソリューション領域にわたって多数のサービスが提供されています。 IaaS ソリューションの開発と比較して、モノのインターネット (IoT) ソリューションと AI ソリューションの設計とエンジニアリングには、さまざまな専門知識とスキル セットが必要です。
- クラウド サービスは頻繁に変更されます。
- モノリシック サービスを提供しようとすると、IT は部署ではなくプロセスを管理し、市場投入までの時間が大幅に増加します。
推奨される結果: ガードレールを提供する
クラウド テクノロジを導入する場合は、IT 部門に IT ワークロードから始めることで、クラウドに対する直接的な経験を得ることができます。 Microsoft クラウド導入フレームワーク for Azure を使用して、最初の導入プロジェクトを特定します。
適切な クラウド運用モデルを選択します。 すべての主要なプラットフォームは、設定、管理、および使用において大幅に異なるため、最初に主要なパブリック クラウド プロバイダーを 1 つだけ導入することを検討してください。
次のような IT ツールには、可能な限り SaaS ソリューションを使用します。
- コード リポジトリ。
- 継続的インテグレーションと継続的デリバリー (CI/CD)。
- コラボレーション システム。
クラウド ワークロードの場合は、大規模な操作を安全かつ確実に行える使い慣れた手順を使用するよう、IT に推奨してください。
次のステップ
- 信頼性の重要な要素の概要
- 最初の導入プロジェクト