クラウド コンピューティング アーキテクチャ設計の 6 つの原則に従っていますか?

クラウドコンピューティングは、私たちの日常生活や仕事、勉強に直接的な影響を感じることはないかもしれませんが、ITインフラとして、私たちが利用しているさまざまなアプリケーションを静かに支えています。

クラウドコンピューティングの概念、開発の歴史、製品体系については、多くの書籍やクラウドサービスプロバイダーの公式ドキュメントで紹介されているため、ここでは詳細には触れません。クラウド コンピューティングの全体的なアーキテクチャとサービス機能は、図 1 に示すように、クラウド コンピューティング アーキテクチャ システムという別の観点から理解できます。この図は、インフラストラクチャ、クラウド コンピューティング オペレーティング システム、製品システム (セキュリティとコンプライアンス、監視と管理を含む)、ソリューション システム、サービス システムなど、クラウド コンピューティングのボトムアップ構造をまとめたものです。

図1

完全な技術アーキテクチャ設計にも段階的なプロセスがあります。まず、需要分析を収集し、需要分析に基づいてアーキテクチャを設計し、評価と改善を行い、提供と実装を行い、その後、図 2 に示すように運用を継続します。

図2

アーキテクチャ設計の各段階では、前段階の結果をインポートし、設計プランを出力したり、現段階での処理後の環境を構築したりして、段階的に完全なソリューションの設計を進めていきます。

（１）需要分析フェーズでは、ユーザーが需要の問題点を入力し、分析後に需要分析表が出力されます。

（２）アーキテクチャ設計フェーズでは、要件分析表に従って適切な設計パターンをマッチングさせ、完全なアーキテクチャ設計計画を形成します。

（３）評価・改善フェーズでは、完成したアーキテクチャ設計計画を評価し、優れたアーキテクチャ設計原則を参考に評価・改善を行った後のアーキテクチャ設計計画を出力します。

（4）デリバリー・実装フェーズでは、評価・改善されたアーキテクチャ設計計画に基づいて環境構築を行い、クラウドプラットフォーム上に業務を展開し、アーキテクチャ設計に準拠したクラウド環境を提供します。

（５）アーキテクチャの継続運用においては、ソリューションと現在の業務運用状況を入力し、継続的な検査、分析、評価（書籍「クラウドアーキテクチャ」第１１章参照）を実施し、改善策を出力し、再構築と改善を行い、新たなニーズに基づいたソリューションを繰り返し提供します。

クラウド コンピューティングに基づくアーキテクチャを設計する場合、すべての技術ソリューションは特定の原則に従う必要があり、これはアーキテクチャ設計で追求すべき目標でもあります。

図 3 は、合理的な展開、ビジネスの継続性、弾力的な拡張、パフォーマンス効率、セキュリティ コンプライアンス、継続的な運用を含む、アーキテクチャ設計の 6 つの原則を示しています。

図3

これら 6 つの原則は、建築設計で考慮する必要があるさまざまな角度を表しています。これらの原則に同時に従うことによってのみ、完全なアーキテクチャ ソリューションを設計できます。ただし、実際の状況では、複雑なアーキテクチャ ソリューションを構築するために、すべてのデザイン パターンをすべてのアーキテクチャ設計に組み込む必要はありません。これら6つの原則は後ほど一つずつ紹介され、それぞれの原則のサブ項目に基づいて設計が行われます。

1. 合理的な展開

パブリック クラウドへのビジネス システムの展開には、仮想マシンの形でのクラウド ホストの使用と、より高性能な物理クラウド ホストの使用が含まれます。ホスティング サービスには、ホストされたアプリケーションとホストされた物理サーバーが含まれます。

これまでの IT リソースの状況、コンプライアンス要件などにより、多くの企業はまだクラウドに移行していません。このような状況に対応するため、クラウド コンピューティング オペレーティング システムは、独立したソフトウェアおよびサービスとして抽出され、パッケージ化され、ユーザーのプライベート環境に展開されます。 「あらゆる」ユーザーに公開されているパブリック クラウドとは異なり、プライベート展開は少数の指定されたユーザーのみが利用できます。

ハイブリッド アーキテクチャでは、パブリック クラウドやプライベートに展開されたプラットフォーム、従来の VMware、OpenStack 仮想化プラットフォーム、物理サーバーなどのリソースを集中的に管理およびスケジュールできます。ハイブリッド アーキテクチャは、ローカル環境を変更せずにコンプライアンス要件を満たすという利点だけでなく、豊富なクラウド プラットフォーム リソースと十分なサービス機能の利点も享受できます。ハイブリッド アーキテクチャは、現在の企業のクラウドへの移行における中間状態でもあり、今後も長期間存在し続けるでしょう。

越境電子商取引や海外ゲーム展開などのシナリオでは、世界中の複数のリージョンが使用されます。サービスとデータをユーザーの近くに展開すると、ネットワークの遅延が短縮され、アクセス エクスペリエンスが向上します。そのため、世界中のユーザーにできるだけ近い場所に展開する方法に重点を置き、同期データの保存と処理のソリューションを実現するために、グローバル展開が組み込まれています。

ハードドライブ、クラウド ホスト、可用性ゾーン、リージョン、クラウド サービス プロバイダーを信頼することはできません。ビジネスを展開する際には、ビジネスの継続性を向上させ、リソースとサービスの面で単一のクラウド サービス プロバイダーの欠点を補い、クラウド サービス プロバイダーの技術的なロックインや商業的制約の一部から身を守るために、複数のパブリック クラウド プラットフォームを選択する必要があります。

2. 事業継続性

ビジネス継続性とは、主に高可用性、高信頼性、および災害復旧を指します。設計モデルもこのロジックに基づいています。

• 高可用性とは、ビジネス リソースに障害が発生した場合に、冗長性やその他の設計によってビジネスの中断を回避することを意味します。
• 高い信頼性 (継続的な運用) とは、ビジネス運用のリソースに障害がなく、ビジネスがサービスを継続的に提供できることを意味します。
• 災害復旧とは、ビジネス運用環境が破壊された場合に、アプリケーションとデータを別の環境に復元する機能を指します。

冗長性とビジネス継続性は、アーキテクチャ設計のすべての層に実装する必要があります。冗長性がない場合は単一障害点となり、単一障害点に障害が発生すると、ローカル サービスが停止します。

• ストレージ製品: ブロック ストレージは 3 つのコピーを通じて冗長性を実現します。 1 つのコピーでエラーが発生した場合、他のコピーを使用してデータを検証および復元します。オブジェクト ストレージは、消去コードを使用してデータ冗長性の検証を実装し、回復可能性を提供します。オブジェクト ストレージは、単一のリージョンがオブジェクト ストレージの単一ポイントになることを防ぐために、リージョン間のレプリケーションを提供します。
• バックアップ ソリューション: クラウド内の可用性ゾーンとリージョン全体でデータをバックアップし、データのコピーが 1 つしか保存されないようにすることで、信頼性を向上させます。ハイブリッド アーキテクチャでは、データをクラウドにバックアップします。ローカル環境のデータが破損した場合は、クラウド バックアップ ファイルを通じて復元できます。
• 災害復旧計画：業務システムの災害復旧を実施し、現在の業務環境が単一点化することを防ぎ、業務全体の可用性とリスク耐性を向上させます。
• 高可用性: クラウド ホストと可用性ゾーンの冗長性は、可用性ゾーン全体にわたる負荷分散展開によって実現されます。グローバル負荷分散により、地域やクラウド プラットフォーム全体にわたる高可用性が実現されます。

3. 弾性膨張

密結合されたシステムは拡張が容易ではなく、ソフトウェアのバグやシステム障害が発生した場合に問題を解決することが困難です。各システムコンポーネントを呼び出すプレッシャーは異なり、小さな問題が段階的に拡大し、ビジネス全体の中断を引き起こす可能性があります。システムの弾力的な拡張性を維持するには、まず動的データと静的データの分離を含め、システム コンポーネントを分離する必要があります。分離されたコンポーネントは機能的にユニット化され、それぞれが独自の機能を実行できます。

分離後、コンポーネントとサービスが拡張され、つまり、データベース層の拡張を含むコンピューティング リソースの垂直拡張、水平拡張、自動スケーリングが行われ、ハイブリッド アーキテクチャを通じてローカル環境のコンピューティング、ストレージ バックアップ、セキュリティ保護、製品サービス機能が拡張されます。アプリケーションやデータの移行もシステム全体の拡張として考えられます。ある環境から別の環境に移行する場合、システムは弾力的な拡張を維持し、必要なときに迅速に移行を実行できる必要があります。最後に、バランスを取る必要があります。コンポーネントの分離、リソースおよびサービスの拡張の後、基盤となる分離と拡張によって発生するインターフェイスの不一致などの問題を防ぐために、統合アクセス ポイントが必要です。これらはすべて、バランシングとグローバル ロード バランシングに含まれます。

デカップリングはあらゆるレベルで実現されます。メッセージ キューは、コンポーネントとイベント間の通信を分離するために使用されます。 Redis などの共有ストレージは、ステータス データをコンピューティング リソースから分離するために使用されます。クラウド ホストはリソースではなくサービス用に展開する必要があり、リソースはビジネスから切り離す必要があります。ストレージは、バインド可能な EIP とバインド解除可能な EIP を使用して、弾力的にマウントおよびマウント解除可能なクラウド ハード ディスクを実装します。セキュリティ保護は、DDoS 保護、WAF 保護などを通じてコン​​ピューティング リソースから切り離されます。ネイティブのコンピューティング機能とストレージ機能を使用して、ビジネスをクラウド プラットフォームの特性から切り離し、複数のクラウド プラットフォームにわたってビジネスをスケーラブルにします。

コンポーネントの分離はスケーラビリティの前提条件であり、次の方法で実現できます。

• ステートレスな状態を維持し、状態データを Redis に保存します。
• 負荷分散に組み込むと、容量の拡張や削減がビジネス全体に影響を与えなくなります。
• メッセージ キューと API ゲートウェイの分離により、プロデューサーとコンシューマーは互いに影響を与えることなく拡張できます。
• サービスのグローバルな負荷分散を実現し、ハイブリッドアーキテクチャとマルチクラウド環境でバックエンドサービスを拡張できるようにします。

4. パフォーマンス効率

多くのソリューションとケースでは、高い同時実行性とトラフィックの急増によってもたらされるパフォーマンスの課題が伴います。パフォーマンス効率における主な目標は、アプリケーションのパフォーマンスを検出して改善し、リソースとコンポーネントの効率を向上させることです。

1 つ目はコンピューティング パフォーマンスです。高構成のクラウドホストや物理クラウドホストを使用することで、単一マシンのパフォーマンスを向上させ、クラスターの形でサービス全体のパフォーマンスを拡張することができます。

2 番目はストレージとキャッシュです。 Redis を使用してホット データをキャッシュし、一時的なステータス データを保存し、メモリ内で計算を実行すると、ビジネス パフォーマンスが向上します。各レイヤーでキャッシュを使用し、静的ファイルを CDN 経由でキャッシュし、ヒットしないファイルについてはソースに戻ります。 Redis を介してデータベースをキャッシュし、データベース アクセスを高速化します。ホットな設定ファイルとホットなデータを Redis 経由でキャッシュし、事前にロードしてアクセス時間を短縮します。

2つ目は、ネットワークパフォーマンスの最適化です。ビジネスをグローバルに展開する場合、最適なデータセンターを選択し、グローバル基本ネットワーク、CDN、グローバルアプリケーションアクセラレーションに基づいてネットワークパフォーマンスを向上させ、リクエストアクセラレーション効果を実現します。

最後に、アプリケーション パフォーマンス監視とストレス テストが導入され、アプリケーションの観点から現在のパフォーマンス状態を評価し、問題のボトルネックを特定し、的を絞って問題を解決します。

5. セキュリティとコンプライアンス

セキュリティ コンプライアンスは、一方ではビジネス セキュリティ保護のニーズを満たすことであり、他方ではセキュリティ監視のコンプライアンス要件を満たすことです。これら 2 つの側面は、具体的な実装中に相互に関連しています。

まず、ユーザー アカウントと権限の管理から始め、適切な担当者に適切なアカウントとロールを割り当て、最小限の権限を付与し、API または CLI を介してアクセスするプログラムまたは担当者に適切な公開キー、秘密キー、および権限を割り当て、オブジェクト ストレージ ファイル トークンへの一時アクセスを厳密に管理します。次に、セキュリティシステム全体において、端末セキュリティ、データセキュリティ、ネットワークセキュリティ、アプリケーションセキュリティ、およびログ、動作、データベース操作の監査があります。最後に、情報セキュリティ技術 2.0 の要件、Web サイトの登録要件、GDPR などのさまざまな地域のビジネスおよびデータ プライバシー要件を満たすシステムがあります。

• アカウントシステムでメインアカウントとサブアカウントを設定し、公開鍵と秘密鍵を管理します。適切なロールを設定し、アカウントとロールに必要な最小限の権限を割り当てます。
• ACL を通じてネットワーク アクセスを制御します。セキュリティ グループを通じてクラウド ホストによって開かれるポートを制限します。サブネットとルートを介してサブネット間の通信を制御します。イントラネット VPC への内部アクセスのみを必要とするデータベースとクラウド ホストを構成し、アクセスを許可する VPC をセットアップし、外部ネットワークから切断するように設定します。
• DDoS、cc、SQL インジェクション、XSS などの攻撃を防ぎます。
• セキュリティ監査、アクセスログや操作ログの保存、低頻度保管、アーカイブ保管などを段階的に実施します。

6. 継続中の業務

クラウド プラットフォームによって提供されるリソースとサービスにはすべて SLA があります。クラウド ホストの SLA は通常 99.95% です。ユーザーが構築する業務システムは、クラウドリソースやクラウドサービスのSLAに基づいて構築され、その上で可用性と信頼性を高めた業務システムが構築されます。自社の業務システムにおいては、サービスの可用性などを示すSLAを策定する必要もあります。ユーザ業務のSLAを策定後、SLA閾値に応じて高可用性フロー制限値を設定し、業務全体のサービス可用性とデータ信頼性を総合的に評価し、障害時の緊急対策を規定することができます。

継続的な運用中は、クラウド リソース、クラウド サービス、イベント、ユーザー アプリケーションが監視され、アラームが設定されます。アラーム条件が満たされると、電話、SMS、電子メール、DingTalk、WeChatなどを介して関係者に通知され、アラームはコールバック機能に引き継がれます。これにより、自動障害処理または対応する緊急計画が実現され、手動介入が削減されます。

クラウド リソース、イベント、アプリケーションの動作状態の包括的な監視を含め、アーキテクチャ設計のすべてのレイヤーで監視とアラートを実行する必要があります。監視が必要なユーザー定義のリソースとサービスについては、異常な状況をタイムリーに検出するために、合理的かつ効果的なアラーム戦略を構成する必要があります。 Advisor を通じてクラウド プラットフォームの検査が実装され、リソースの変更を継続的に監視し、ビジネス アーキテクチャを定期的に評価し、ビジネス アーキテクチャが引き続きビジネス ニーズに一致しているかどうかを迅速に識別します。

さらに、自動化された応答および処理機能も必要です。自動スケーリングは、CPU などの指標を監視することでクラウド ホストの数を自動的に増減できます。タイマーを介して一定期間ごとにクラウド ホストの数を増減します。イベント駆動型の応答を実装し、イベント メッセージによってスクリプト、コールバック関数、その他の操作の実行をトリガーし、インテリジェントな運用と保守を実現し、イベントやアラームに応じて運用と保守操作を自動的にトリガーし、運用と保守スクリプトを配置し、インテリジェントな運用と保守によって手動の運用と保守を削減します。

消費とビジネスコストの変化をタイムリーに検出し、コストを最適化します。急激な消費を回避し、コスト管理を実現するために、口座残高アラーム値を設定します。リソースの使用期間を評価し、時間単位で課金されるリソースを月単位または年単位で課金されるように変換して、リソースの使用を最適化します。 Advisor で推奨されるコスト最適化を通じて未使用の EIP を解放し、CPU などの指標に基づいてクラウド ホストの数を減らすかクラウド ホストの構成を下げ、オブジェクト ストレージを処理するときにイントラネット経由でクラウド ホストにアクセスして、外部ネットワーク アクセスのトラフィック コストを削減します。マルチクラウド展開によりコストの最適化が実現されます。リソースは、複数のクラウド プラットフォームのリソース価格に基づいて選択されます。他のクラウド プラットフォームでより低い単価のインスタンス クラウド ホストに入札することで、OLAP ビジネスを処理するための最適な組み合わせが選択されます。