クラウド対応性のアンチパターン
顧客のクラウド対応性フェーズでは、多くの場合にアンチパターンが発生します。 このようなアンチパターンが原因で、予期しないダウンタイム、ディザスター リカバリーの問題、可用性の問題が発生するおそれがあります。
アンチパターン: リリースされたサービスは運用の準備ができている想定する
クラウド コンピューティングは急速に進化しているため、多くの場合、新しいサービスのプレビュー版がリリースされます。 顧客は、利用可能な任意のクラウド サービスを運用環境で使用できると想定する傾向があります。 しかし、次のような理由から、問題が発生するおそれがあります。
- 通常、プレビュー サービスでは、稼働時間のサービス レベル アグリーメント (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 が実現されます。
クラウドベースのソリューションを設計するときは、"要件エンジニアリング" の基本的なプロセスに関与します。 SLA 推定機能を使用して、アプリケーションのエンドツーエンドの SLA を計算します。
アンチパターン: クラウド プロバイダーになる
一部の企業は、社内の IT 部署をクラウド プロバイダーにしようと試みます。 その場合、IT は参照アーキテクチャに対して責任を負います。 また、IT は、部署に IaaS と PaaS を提供する必要もあります。 このような作業は通常、IT のコア ビジネスの一部ではないため、結果として得られるサービス内容は、使いやすさ、回復性、効率性、セキュリティが備わっていないおそれがあります。
例: モノリシック マネージド クラウド サービスを提供する
企業の IT 部署が、IT と部署の仲介者として機能するクラウドのセンター オブ エクセレンス (CCoE) を確立します。 企業がクラウドに確実に準拠するために、管理取締役会は、モノリシックなエンドツーエンド サービスを提供するタスクを CCoE に割り当てます。 CCoE は、フル マネージドのクラウド VM をサービスとして注文するために、部署が使用できる社内クラウド調達ポータルを設定します。 ただし、IT は、プラットフォーム全体にアクセスして使用できるユーザーを制御します。 その結果、IT は、Azure によって提供されるすべてのサービスを部署が利用することを能動的に妨げます。 部署は、クラウド ポータルにアクセスできません。 部署は、Secure Shell (SSH) とリモート デスクトップ プロトコル (RDP) を介してのみ、注文したサーバーにアクセスできます。
いくつかの理由から、CCoE では、クラウドで使用可能な各サービスをラップするためにモノリシック管理サービスを提供するときに、問題が発生します。
- クラウドでは、複数のソリューション領域にわたって多数のサービスが提供されています。 IaaS ソリューションの開発と比較して、モノのインターネット (IoT) ソリューションと AI ソリューションの設計とエンジニアリングには、さまざまな専門知識とスキル セットが必要です。
- クラウド サービスは頻繁に変更されます。
- モノリシック サービスを提供しようとすると、IT は部署ではなくプロセスを管理し、市場投入までの時間が大幅に増加します。
推奨される結果: ガードレールを提供する
クラウド テクノロジを採用する場合は、IT ワークロードを開始することで、IT 部署がクラウドの経験を直接得られるようにします。 Azure の Microsoft Cloud 導入フレームワークを使用して、初めての導入プロジェクトを特定します。
一元操作などの成熟したクラウド運用モデルを使用します。これにより、IT はガバナンスのようなプラットフォーム ガードレールを定義する責任を負います。 これにより、部署は、IT が定義したガードレール内で、安全かつ一貫した方法でクラウド プロジェクトを採用できます。
すべての主要なプラットフォームは、設定、管理、および使用において大幅に異なるため、最初に主要なパブリック クラウド プロバイダーを 1 つだけ導入することを検討してください。
次のような IT ツールには、可能な限り SaaS ソリューションを使用します。
- コード リポジトリ。
- 継続的インテグレーションと継続的デリバリー (CI/CD)。
- コラボレーション システム。
クラウド ワークロードの場合は、大規模な操作を安全かつ確実に行える使い慣れた手順を使用するよう、IT に推奨してください。