Azure でのキャリア グレードのワークロード

ミッション クリティカルなシステムは主にアップタイムの最大化に重点を置き、多くの業界に存在します。 通信業界では、それらは キャリアグレードシステムと呼ばれています。 これらのシステムは、次のドライバーの 1 つ以上が原因で開発されます。

• 生命または傷害の損失を最小にする。
• 罰金の支払いを回避するために、信頼性に関する規制要件を満たす。
• 競合他社へのチャーンを最小限に抑えるために、顧客へのサービスを最適化する。
• ビジネスまたは政府機関のお客様との契約上のサービス レベル アグリーメント (SLA) を満たす。

この一連の記事では、 ミッション クリティカルなワークロードの設計手法 を適用して、Azure で信頼性の高い回復性と利用可能な通信ワークロードを構築および運用するための規範的なガイダンスを通知します。

注意

このシリーズの記事では、通信業界で 99.999% ('5 9s') レベルの信頼性を設計する際に、ミッション クリティカルな考慮事項を追加することに重点を置いています。

キャリア グレードのワークロードとは

ワークロードという用語は、一般的なビジネス目標または一般的なビジネス プロセスの実行をサポートするアプリケーション リソースのコレクションを指します。API やデータ ストアなどの複数のサービスが連携して、特定のエンド ツー エンド機能を提供します。

ミッション クリティカルという用語は、重要な財務コスト (ビジネス クリティカル) または人的コスト (安全クリティカル) が使用不能またはパフォーマンスの低さに関連する重要度の分類を指します。

キャリアグレードのワークロードは、ビジネスクリティカルとセーフティクリティカルの両方でピボットします。1 暦年あたりわずか数分または数秒のダウンタイムで運用するための基本的な要件があります。 このアップタイム要件を達成しないと、広範な生命の損失、重大な罰金、または契約上の罰則が発生する可能性があります。

ワークロードの 運用 上の側面には、信頼性の測定方法と、それを満たすか超える必要があるターゲットが含まれます。 信頼性の高いシステムは、通常、99.999% のアップタイム (通常は "5 9s" と呼ばれます) または 1 年間の 0.001% ダウンタイム (約 5 分) を目標としています。 一部のシステムでは、99.9999% のアップタイム、または年間 30 秒のダウンタイム、またはさらに高いレベルの信頼性が目標です。 これには、スケジュールされたメンテナンス、インフラストラクチャの障害、人的エラー、ソフトウェアの問題、さらには自然災害など、あらゆる形態と停止の原因が含まれます。

使用されるプラットフォームは、専用の専用ハードウェアから市販のハードウェアから OpenStack または VMware クラウドへと進化してきましたが、通信会社は、年間 5 分間のダウンタイム≤達成するサービスを一貫して提供し、多くの場合、予定外の停止によるダウンタイム≤ 30 秒を達成しています。

一般的な課題は何ですか?

キャリア グレードのワークロードの構築は、次のメイン理由の課題です。

リフトアンドシフトアプローチ

通信会社には、既存のインフラストラクチャで期待される動作を提供する適切に設計されたアプリケーションがあります。 ただし、パブリック クラウド インフラストラクチャにそのままこれらのアプリケーションを移植しても回復性に影響を与えないと 想定する前 に注意する必要があります。

既存のアプリケーションでは、基になるインフラストラクチャに関する一連の想定が行われます。これは、オンプレミスからパブリック クラウドに移行する場合に当てはまる可能性は低いです。 アーキテクトは、新しい現実に対応するために、インフラストラクチャとアプリケーションの設計をまだ保持し、調整していることをチェックする必要があります。 また、アーキテクトは、新しいインフラストラクチャがオンプレミスに存在する制限を取り除く機会も探す必要があります。

たとえば、オンプレミス システムのアップグレードは、新しいデプロイを作成するのに十分なハードウェアを安全な方法で作成し、ゆっくりと移行するために十分なハードウェアを維持できないため、実施する必要があります。 このアップグレード パスにより、アップグレードとロールバックの管理方法に関する多くの要件が生成されます。 これらの要件は複雑になり、アップグレードの頻度が低く、慎重に管理されたメンテナンス期間でのみ許可されることを意味します。

ただし、パブリック クラウドでは、既存のデプロイと並行して新しいデプロイを作成するのが妥当です。 このプロセスにより、アプリケーションの運用設計が大幅に簡素化され、ユーザーエクスペリエンスと期待が向上します。

モノリシック ソリューション

さまざまなミッション クリティカルな業界の経験は、望ましいレベルの可用性を実現するモノリシック ソリューションを構築しようとすることは現実的ではないことを示しています。 複雑なシステムでは、障害の原因となる可能性が多すぎます。 代わりに、成功したソリューションは、個別の独立した冗長な要素で構成されます。 各ユニットには比較的基本的な可用性 (通常は約 99.9%) がありますが、合計ソリューションを組み合わせると、必要な可用性の目標が達成されます。 その後、キャリアグレードのエンジニアリングの技術は、冗長な要素に共通する唯一の依存関係が、全体的な可用性に最も大きな影響を与えるため、絶対に必要なものであることが保証されます。多くの場合、設計の他の何よりも桁が大きくなります。

ゾーン冗長の構築のみ

Microsoft Azure Availability Zonesを使用することは、ハードウェア障害やローカライズされた環境問題による停止のリスクを軽減するための基本的な選択肢です。 ただし、主に次のような理由で、キャリア グレードの可用性を実現するだけでは不十分です。

• Availability Zones (AZ) は、1 つのリージョン内の任意の 2 つのゾーン間のネットワーク待機時間が 2 ミリ秒≤するように設計されています。 AZ は広く地理的に分散することはできません。 そのため、AZ は、洪水や大規模な停電などの自然災害による障害の相関リスクを共有します。これにより、リージョン内の複数の AZ が無効になる可能性があります。

• 多くの Azure サービスはゾーン冗長になるように明示的に設計されているため、それらを使用するアプリケーションは、可用性の向上の恩恵を受けるために明示的なロジックを必要としません。 サービス内のこの冗長性機能には、各ゾーン内の要素間のコラボレーションが必要です。 多くの場合、1 つのゾーンでソフトウェア障害が発生し、他のゾーンで相関障害が発生する、避けられないリスクがあります。 たとえば、ゾーン冗長サービスで使用されるシークレットまたは証明書に関する問題は、すべての AZ に同時に影響を与える可能性があります。

主要な設計領域は何ですか?

キャリア グレードのワークロードを設計する場合は、次の点を考慮してください。

設計領域	説明
フォールト トレランス	アプリケーション全体が何らかのレベルで動作し続けることができるように、アプリケーション設計では避けられない障害を許容する必要があります。 設計では、障害点を最小限に抑え、フェデレーション アプローチを採用する必要があります。
データ モデル	設計では、データベースの整合性、可用性、およびパーティション許容度のニーズに対応する必要があります。 キャリア グレードの可用性では、アプリケーションが複数のリージョンにデプロイされている必要があります。 このデプロイでは、アプリケーションのデータをこれらのリージョン全体で管理する方法について慎重に考える必要があります。
正常性のモデリング	効果的な正常性モデルでは、すべてのコンポーネント、プラットフォーム、アプリケーションを監視できるため、問題をすばやく検出し、自己復旧やその他の修復を通じて対応できます。
テストおよび検証	アプリケーションの設計と実装を十分にテストする必要があります。 さらに、ソリューション全体としてのアプリケーションの統合とデプロイをテストする必要があります。

次のステップ

まず、キャリア グレードのアプリケーション シナリオの設計原則を確認します。

設計原則