エラスティック コンピューティング テクノロジーに関するオープン コース - CloudOps クラウドの運用とメンテナンスのシーズンは無事終了しました。Alibaba Cloud のエラスティック コンピューティング テクノロジーの専門家である Zheng Dayu 氏が、この記事で「自動化されたクラウドの運用とメンテナンスのための OOS の使用」というタイトルのコースを共有しました。このコースの内容は、クラウド上のリソースの運用と保守が直面する課題、OOS の自動運用と保守機能の秘密、OOS を使用したクラウド上での CloudOps の実践について説明します。
以下は、開発者が学ぶための彼のコース内容をまとめたものです。
1. クラウドリソースの運用保守の課題
クラウドリソースには以下のような特徴があり、まず大規模であるため、ユーザーは独自のインフラを構築する必要がなく、理論的には無制限にクラウドリソースを購入することができます。さらに、クラウド リソースの弾力性により、ユーザーは自分のニーズに応じていつでもどこでも必要なクラウド リソースを取得できます。これらすべてにより、クラウド リソースの規模が自社構築インフラストラクチャよりも大きくなります。次に、クラウド上にはさまざまな種類のリソースが存在します。従来のコンピューティング、ストレージ、ネットワーク リソースに加えて、クラウドはより多様なサービスを提供します。たとえば、データベース、メッセージ キュー、人工知能 AI、モノのインターネット、その他の種類のリソースです。
ユーザーは自分のニーズに応じて対応するリソースを購入できるため、独自のリソースを構築する面倒なプロセスが不要になります。クラウド上では各種クラウドサービスが提供されており、ユーザーは独自のビジネスロジックの開発に集中できます。クラウド リソース層に沈む技術アーキテクチャがますます増えています。これにより、ユーザーがインフラストラクチャの保守と管理に注意を払う必要がなくなる一方で、クラウド リソースのシナリオがより複雑になります。
クラウド リソースのこのような特性により、リソースの運用と保守も効率、コスト、セキュリティなどの面で相応の課題に直面します。
1. クラウドリソースの規模は急速に拡大している
まず、クラウド リソースの規模が急速に拡大しています。ビジネスの発展に伴い、クラウドリソースの規模は急速に拡大し、企業はより多くのコンピューティング、ストレージ、ネットワーク、その他のリソースを管理する必要があり、運用と保守の複雑さが大幅に増加し、企業は管理により多くの時間と人的リソースを投資する必要があります。これらのリソースを監視します。企業は、リソースの運用と保守の効率と信頼性を向上させるために、効果的な運用と保守のプロセスとツールを確立する必要があります。
以下では、特定のクラウド アカウントでのクラウド リソースの規模を例に挙げますが、初期段階ではビジネスは立ち上げ期にあり、需要を満たすために Web サービスをデプロイするために必要な ECS インスタンスは少数だけです。この期間のクラウド リソースの増加は比較的安定しています。これらの少量のリソースの管理は、手動の運用および保守方法、または単純な運用および保守スクリプトを使用して完了できます。しかし、ビジネスが発展し、API ビッグデータ サービスなどのサービスが提供されるようになると、リソースの規模は飛躍的に増大します。これまでと同じ運用・保守方法を採用すると、必要な人員も増加する一方です。現時点では、これまでの運用保守の経験を、自動化された手段によって少量のリソースから大量のリソースに一括コピーして、運用保守の効率を向上させる方法が課題となっています。
2. クラウド リソースのコストも急速に増加しています。
クラウド リソースのコストはリソースの規模に応じて増加するため、企業はリソース使用量の分析と監視、ダウンタイム節約モードや一時的な帯域幅のアップグレードなどの適切なコスト削減テストの導入など、効果的なコスト管理と最適化を実行する必要があります。同時に、これらのコストの最適化と運用保守の措置を自動的かつ文化的に適用する方法も課題となっています。
特定のクラウド アカウントでのクラウド リソースのコストを例にとると、初期段階では、企業は少量の ECS クラウド リソースのみを導入していましたが、いくつかのアプリケーションといくつかのコスト最適化のベスト プラクティスを通じて、クラウド リソースの全体的なコストを削減できます。削減。ただし、ビジネスが発展するにつれて、データベースやメッセージ キューなどを含む、より多くの ECS リソースやその他のクラウド リソースが導入されます。新しく導入されるリソースのコストを継続的に最適化する必要があります。クラウド リソースのコストは変動し、上昇傾向にあることがわかります。現時点では、クラウド リソースの利用率を向上させ、コストを削減する方法も当然のことながら新たな課題になります。同時に、これまでのコスト最適化の経験を新たに導入したリソースに自動的に拡張することで、手動による最適化を回避する方法も重要なポイントです。
3. セキュリティコンプライアンス問題の重要性がますます高まっている
クラウド上のセキュリティ コンプライアンスの問題には、データ漏洩、サービス システムの脆弱性の悪用、アカウント ハイジャック、サービス拒否攻撃、安全でないアプリケーション インターフェイスなどが含まれます。実際、これらのセキュリティ コンプライアンス問題に関しては、クラウド上で多くの優れたイベントが開催されています。
たとえば、クラウド リソースの規模が拡大するにつれて、企業はシステムの脆弱性を定期的に管理し、システム パッチを更新およびアップグレードし、既知のセキュリティの脆弱性を修復する必要があります。一部の企業または業界のコンプライアンス要件に対応するため、企業はクラウド リソースのコンプライアンス チェックを定期的に実施し、非準拠のリソースを修復する必要があります。
たとえば、一部の業界では高い信頼性要件があり、マルチ アベイラビリティ ゾーンや地域をまたいだ災害復旧が必要となるため、企業はコンプライアンス要件に従って対応するクラウド リソースを確認する必要があります。リソースが災害復旧要件を満たしていない場合は、対応する修正が行われます。プロセス全体には時間と労力がかかり、セキュリティ コンプライアンス要件の一部を自動的にチェックし、準拠していないリソースを自動的に修正する方法が、クラウドの運用と保守のもう 1 つの課題となっています。
4. CloudOps のベスト プラクティスを実装する方法
クラウド上のほとんどの運用および保守操作はオープン API にカプセル化されていますが、これらのベスト プラクティス シナリオは、多くの場合、単純な API 呼び出しや単純なクラウド上の操作ではありません。一連の運用・保守業務を組み合わせたものであり、多くのベストプラクティスをいかに自動でクラウドリソースに適用するかが課題となるが、OOS運用保守オーケストレーションサービスでは、こうしたタスクオーケストレーション機能を備えたプラットフォームを正式に提供している。
2. OOS の自動運用保守機能の秘密を明らかにする
OOS サービスについて簡単に紹介します。運用保守オーケストレーション サービスは OOS と呼ばれます。これは、自動化されたタスクの管理と実行を提供する、包括的な無料のクラウド自動化タスク オーケストレーション プラットフォームです。プラットフォームとして、一連の自動化されたタスクと実行機能を提供します。半自動化されたプラットフォーム機能とインフラストラクチャ、運用と保守およびコードのコードとしてのクラウド オフィスの概念。
まず、自動化機能に関して言えば、OOS はバッチ操作、リージョン間の動作条件制御、同時実行制御などの機能を提供し、複数リージョンや大規模なシステムなどの複雑なシナリオでも運用および保守タスクを効率的かつ安定して実行できます。ボリュームリソース。次に、OOS は承認や一時停止などの半自動機能もサポートしています。
たとえば、一部の重要な運用および保守作業では、実行前に関係者または主要担当者の承認が必要になる場合があります。この場合、OOS タスク プロセスに承認ステップを追加し、関係者に承認を通知し、承認後、自動的に操作が実行されます。さらに、OOS は、自動化できない一部の手順の操作の一時停止もサポートしています。自動化された操作を実行する前に、関係者が手動で確認する必要があります。その後、OOS は、即時操作、スケジュールされた操作、およびイベント駆動型操作など、さまざまなトリガー タイプもサポートしています。トリガー操作。
たとえば、コマンドをすぐに実行したい場合は、デフォルトの方法でもある第 1 レベルの操作を使用できます。明日の夜8時にコマンドを実行したい、または毎晩8時にコマンドを実行したい場合、このような定期的な操作や遅延した操作は、スケジュールされた操作によって実行できます。アラームの状態。たとえば、CPU 使用率が 80% を超えている場合はクリーニング操作が実行され、ディスク使用率が 80% を超えている場合は不要なファイルが削除されます。このとき、アラームを使用して操作やイベントをトリガーすることができます。これは、ECS イベントを例として、クラウドによって監視されるイベントと組み合わせられます。
ECS が初期化操作を実行するために開始されるとき、イベント操作を使用できます。これらの機能に基づいて、OOS は、ユーザーが ECS や製品をインストールして設定する必要がなく、安定した信頼性の高いホスティング サービスを提供します。OOS はオーケストレーションをサポートします。一般的に使用される 70 以上の Alibabaこれらの製品には、200 を超える運用および保守タスクのシナリオが用意されており、すぐに使用できるパブリック テンプレートが用意されています。さらに、すべての OOS 運用および保守操作をアクション トリオで監査できるため、ユーザーの監査ニーズを確実に満たすことができます。
上記のプラットフォーム機能に基づいて、OOS は強力な API オーケストレーション機能を構築しています。ECS インスタンスの起動とソフトウェアのインストールを例として挙げると、一般的な運用およびメンテナンス方法では、最初にインスタンスの起動を通じてサンプルを開始する必要があります。スター インスタンスの集中型インスタンスは非同期プロセスであるため、後続のソフトウェア インストール操作に進む前に、インスタンスが実行状態になるまで待つ必要があります。したがって、インスタンスを常に記述して、インスタンスのシステム状態を確認する必要があります。次に、インスタンスのステータスが実行中になるまで、come on running コマンド API を使用してソフトウェア コマンドをインストールします。インストール コマンド プロセスも非同期プロセスです。したがって、継続的なポーリングによってコマンドの実行が完了するまで待つ必要があります。コマンドの実行が完了したら、API で記述された呼び出し結果を介してコマンドの結果出力をクエリし、コマンドが期待どおりに実行されたかどうかを判断する必要があります。
OOS タスクプロセスでは、インスタンスの起動とインスタンスの起動を待つプロセスの最初の部分が、ACS、ECS、StartInstance というクラウド製品のアクションに分割され、そのプロセスで起動確立のプロセスが完了します。 。同時に、インスタンスが実行されるのを待ちます。アクションが完了すると、待たずにすぐにコマンドを実行できます。次に、インストールコマンドのアクションを同時に実行し、コマンドの実行が完了するのを待って、最後に結果を出力します。これら 2 つのアクションが完全に実行されると、現在の結果がタスクの出力に出力されるため、複雑なプロセスを維持することなく、コマンドが期待どおりに実行されたかどうかが一目でわかります。
その後、プラットフォーム機能と API オーケストレーション機能に基づいて、豊富な運用および保守シナリオが構築されました。一般的な運用および保守タスク、バッチ操作インスタンス、バッチ管理ソフトウェア、スケジュールされた電源のオンとオフ、帯域幅の一時的なアップグレード、イメージの作成および更新、およびディスクのクリーニングが含まれます。これらの一般的な運用および保守タスクは、ユーザーの使用状況の収集に基づいて当社によって抽象化されます。最も一般的に使用されるこれらの一般的な運用および保守タスクが抽出され、OOS コンソールに配置されます。
同時に、これらの操作のプロセスに対していくつかの最適化が行われます。さらに、OOS は、これらの基本機能の提供に加えて、ソフトウェア パッケージ管理、パラメータ管理、構成リスト、パッチ管理などのいくつかの補助的なシナリオ機能も提供します。ソフトウェア パッケージ管理とは、Alibaba Cloud エージェントまたはソフトウェア パッケージ管理ツールで管理できるソフトウェアをインスタンスにインストールすることです。
同時に、このソフトウェア パッケージは、企業が独自のソフトウェアを OOS にアップロードし、バージョン管理を通じて対応する ECS インスタンスにインストールすることもサポートします。パラメーター管理は、パラメーターのストレージ管理サービスを提供し、テキスト データと暗号化されたデータ形式の両方をサポートします。 MS は暗号化のセキュリティを確保するためにデータ側で使用されます。構成リストは、API では取得できない、クラウド サーバーの OOS の一部の内部情報を取得できます。
たとえば、システムへのソフトウェア パッケージのインストールに関する情報があり、ファイルのサイズやファイルの更新時間など、システム内のファイルに関する情報もあります。これらも API からは利用できません。したがって、構成リストを通じてこの情報を取得できます。自然なシナリオとして、今のソフトウェアのインストール情報を例として取り上げます。ソフトウェアがインストールされていない例や、バージョンの低いソフトウェアの例をフィルタリングすることで情報を更新できます。ソフトウェアがインストールされていますので、ソフトウェアを最新バージョンにアップデートしてください。
パッチ管理は、ECS インスタンスのパッチ システム パッチをスキャンまたはインストールします。
ユーザーは、パッチのスキャンやインストールの条件をニーズに合わせて柔軟に設定できます。たとえば、Windows 2022 オペレーティング システム、特別なパッチのみをインストールする、または中リスクおよび高リスクのパッチのみをインストールするなど、インストール中に特定のオペレーティング システム バージョンのパッチのみをインストールすることで、ユーザー定義のインストール ニーズを満たすことができます。
3. OOSクラウドを利用したCloudOps実践
1. 効率的な運用・保守：バッチ運用ECSシナリオ
まず、最も一般的に使用される ECS 操作をバッチ操作 ECS インスタンス シナリオに抽象化します。これらには、インスタンスの開始、インスタンスの停止、インスタンスの再起動、インスタンス内のファイルのダウンロード、更新タイプの更新と変更、インスタンス プロパティのエクスポート、インスタンス プロパティの変更、コマンドの実行、システム ディスクの交換、インスタンス ロールの追加などの機能が含まれます。ロール例を削除します。
ECS インスタンスの一括操作では、アカウント内のすべてのインスタンスを選択する方法や、選択されたインスタンスの数が比較的少ない場合には、該当するインスタンスを手動で選択する方法など、さまざまな方法でインスタンスを選択できます。インスタンスの数が多く、すべてのインスタンスが利用できない場合、手動で選択するのはさらに面倒ですが、インスタンスを csv で管理できます。CSV ファイルをアップロードして、インスタンスの大規模なバッチを選択します。インスタンスは CSV で最大 5000 個のインスタンスをサポートでき、ほとんどのシナリオに対応できます。
ユーザーのリソースがタグまたはリソース グループを通じて管理されている場合。たとえば、IT 部門のすべてのリソースにはそれに応じたラベルが付けられているか、IT 部門のリソース グループに属しています。このとき、タグやリソースグループを指定してインスタンスをフィルタリングすることができます。最後に、構成リスト機能があります。たとえば、構成リストの情報をフィルタリングすると、特定のソフトウェアのインスタンスがインストールされていない、または、特定のファイルの変更日は特定の時間内である、ある時点より前のすべてのインスタンス、さまざまなリッチ インスタンス フィルタリング メソッドをサポートできます。
さらに、OOS は強力なレート制御機能も提供し、周波数制御とバッチ制御の 2 つの形式をサポートします。たとえば、100 個の ECS インスタンスがある場合、同時実行数を 10 に設定すると、毎回 10 個のインスタンスが同時に操作されるようになります。1 つのインスタンスの操作が完了すると、次のインスタンスがそのスペースを補うために操作を実行し、常に 10 個のインスタンスが同時に動作するようにします。バッチ制御は、それ以上インスタンスが動作しないようにするためのものです。バッチが完了するまで操作が行われ、次のバッチが入ります。たとえば、各バッチには 10 個のインスタンスがあります。つまり、最初のバッチの 10 個のインスタンスがすべて実行されるまで、2 番目のバッチの 10 個のインスタンスは入ってきません。これが同時実行制御とバッチ制御の違いです。
同時に、OOS は強力な障害一時停止機能も提供します。障害一時停止モードが設定されている場合、バッチ内でインスタンスが失敗すると、失敗したインスタンスで一時停止されます。必要に応じてスキップするかスキップするかを選択できます。キャンセル。
一般に、一時的なエラー、または準備ができていないリソースの依存関係によって引き起こされたエラーの場合は、再確認した後にこれらの依存関係を手動で修正し、再試行できます。重要でない操作や、結果に影響を与えない無視できる操作がある場合は、それらをスキップすることを選択できます。現時点では、失敗したインスタンスは実行を継続しませんが、残りのすべてのインスタンスは実行を継続します。無視できない重要な操作の場合は、この時点でキャンセルすることを選択できます。こうすることで、以下のすべてのインスタンスが再度実行されることはなくなります。
2. 効率的な運用と保守: ECS アプリケーションのローリング アップグレード
2 番目のシナリオは、ECS アプリケーションのローリング アップグレードです。OOS は、SLb ECS クラウド アシスタントのアトミック機能をタスク シナリオのクラウド製品アクションにパッケージ化し、OOS の自動バッチ同時制御、エラー一時停止、再試行継続およびその他の制御機能によって補完されます。 ECS アプリケーションのローリング アップグレードのシナリオ。このプロセス中、サービスは常にオンラインである必要があります。したがって、アプリケーションのアップグレード プロセス中、すべての ECX インスタンスを一度にアップグレードすることはできません。ローリング アップグレードは、アプリケーションの少なくとも一部がいつでも利用できるようにするために、バッチで実行する必要があります。特定の時点でサービスを提供します。この時点で、OOS はその強力なバッチ機能を利用できます。
このシナリオを例にとると、oos はすべての ECS インスタンスを 3 つのバッチに分割し、一度に ECS インスタンスの 1 つのバッチのみを処理します。バッチの処理プロセスでは、まず、ecs インスタンスがバランス内で繰り返しアンロードされます。つまり、これらのインスタンスの重みが 0 に設定されます。これらのインスタンスはサービスを提供しません。ただし、他の残りのインスタンスは、サービスがオフラインにならないようにサービスを提供し続けています。アンインストール後、イメージ ECS イメージを更新するか、コマンド スクリプトを実行して、ECS アプリケーションを更新します。更新が完了したら、更新された ECS サービスをマウントします。ロードバランサーを使用して外部の世界にサービスを提供します。
次に、このバッチ内に実行に失敗したインスタンスがある場合、必要に応じて操作を再試行するかロールバックするかを選択して、サービスが常に安定していることを確認できます。更新のバッチが完了すると、外部サービスを提供するためにいくつかの SLb にマウントされます。この時点で、ECS インスタンスの 2 番目のバッチが選別され、ローリング アップグレード操作が ECS インスタンスの 2 番目のバッチで実行されます。次に、同じ操作の 2 番目のバッチがロールアウトおよびアップグレードされ、その後、操作の 3 番目のバッチが実行されます。すべての EC がアプリケーションの最新バージョンに更新されるまで。この時点で、ローリング アップグレードが終了するため、OOS の強力なバッチ処理およびタスク オーケストレーション機能を利用して、ECS アプリケーションのリリースの効率が向上します。
3. 効率的な運用と保守: パラメータ ウェアハウスを使用してインフラストラクチャ構成を管理
2 つのシナリオを例に挙げると、システム管理者は要件に応じて基本イメージのセキュリティ パッチを定期的に更新する必要があります。いくつかのセキュリティ上の脆弱性が関係するためです。そのため、定期的にセキュリティパッチを適用して更新する必要があります。ユーザーは、これらのミラーを自分のシステムに適用することで、これらのリソースを作成します。ただし、従来のシナリオでは、ユーザーがイメージを更新する場合、すべての rOS テンプレートを同時に更新し、古いイメージを新しいイメージに置き換える必要があります。パラメータ ウェアハウスを使用した後は、すべてのテンプレートでパラメータ ウェアハウス内の対応するパラメータを参照し、画像を更新した後、画像 ID を対応するパラメータに更新するだけで済みます。
次に、これらのイメージ ID を一元管理することで、すべてのテンプレートを最新のイメージに迅速に更新できます。これにより、すべてのテンプレートが一貫性を持たずに更新されたり更新されなかったりするため、ユーザーがすべてのテンプレートを手動で更新する煩雑さが回避されます。
もう 1 つのシナリオは、暗号化パラメーターに関して、アプリケーション管理者が近い将来 ECS と RDS のパスワードをローテーションする可能性があり、これらのパスワードがさまざまなシナリオで使用されることです。たとえば、クラウド リソースのパスワード ECS と rds を更新します。次に、たとえば、一部の rds データベース パスワードの場合、データベースに接続するためのアプリケーションでパスワード構成を取得します。パスワードは、一部の運用および保守作業中にも使用されます。同じ従来の方法の場合、パスワードを更新した後、アプリケーション管理者は複数の場所でコードと構成を更新します。漏れがあると事故や故障の原因となります。
OOS 暗号化パラメータを使用してパスワードを管理した後、アプリケーション管理者は、対応するパスワードを暗号化パラメータに入力するだけで済みます。たとえば、テスト環境と本番環境のパスワードを区別できます。その後、対応するクラウド リソースの操作、運用保守操作、またはアプリケーションの操作中に、パスワードの名前に従って、対応するパスワードが取得されます。これにより、ユーザーは各地に点在するリソースのパスワードを更新する必要がなくなり、運用保守効率が向上します。
4. コストの最適化: 自動化されたクラウド リソースのコスト最適化
OOS によって実装されるもう 1 つのシナリオは、リソース コストの自動最適化です。ユーザーのリソース使用率は、毎日周期的に変動することがよくあります。たとえば、一部のオフィス サービスでは、使用量のピークは午前 8 時から午後 6 時までであり、午後 6 時に退社すると、使用負荷は低下します。一部のゲームやエンターテイメント アプリケーションのサイクルは、オフィス サービスのサイクルとまったく逆になる場合があります。ピーク時間帯は退社後や週末です。現時点では、そのような経験を要約することにより、自動コスト最適化のための対応する理論的基礎が提供されます。コンピューティング リソースとネットワーク リソースを例として取り上げた 2 つのシナリオが、図に示されている 2 つのシナリオです。
シナリオ 1、コンピューティング リソース。ユーザーの問題点は、そのマシンが定期的に前例のないコストの無駄を引き起こしていることです。まず、ユーザーのマシン負荷のピークは午前 8 時から午後 12 時までです。午後 12 時から翌朝 8 時までは、実際にはロックダウンが緩い期間であり、ユーザーが見積もりを行う際には、ピーク時のコンピューティング リソースに基づいて見積もります。オフピーク時のリソースに基づいて見積もると、ピーク時にリソースが不足し、アプリケーションのサービス拒否が発生して障害が発生します。ただし、ピーク時のコンピューティング リソースに基づいて推定すると、低ピーク時にコンピューティング リソースが無駄に消費されます。
Ecs はダウンタイム節約モードを提供しており、ダウンタイム節約モードでは、ダウンタイム期間中にコンピューティング リソースを充電できません。ただし、ユーザーは平均モードを保存して自動化を完了するスクリプトを作成する必要があり、これもより複雑です。したがって、OOS は、ピーク時の自動起動と低ピーク時の自動シャットダウンを定期的に構成することにより、コストの最適化を実現するための完全なソリューション セットを提供します。朝の 8 時に、oos はブート操作をトリガーし、夜の 12 時にシャットダウン操作をトリガーします。このとき、使用されていないコンピューティング リソースの一部がリサイクルされるため、コストが削減されます。翌日のピークが来る前に、午前8時に再稼働し、午後12時に停止するという自動コスト最適化が何度も繰り返されます。
シナリオ 2 は、ネットワーク リソースの最適化です。実際、ネットワーク リソースにも使用量の山と谷があります。帯域幅使用のピーク時間帯は午前 11 時から午後 13 時までです。この時間帯のネットワーク使用量は他の時間帯に比べて明らかに高くなっています。それ以外の時間帯はオフピーク期間となります。このように、低ピーク時間帯に合わせて固定帯域を設定すると、ピーク時間帯には帯域がいっぱいになり、サービスが提供できなくなったり、障害が発生したりすることがあります。ピーク期間に基づいて固定帯域幅を見積もると、オフピーク期間の帯域幅が大幅に無駄になります。大きな帯域幅を使用すると、ピーク期間が短いためコストが高くなります。現時点では、ユーザーはピーク時にのみ一時的に帯域幅をアップグレードしたいと考えています。
ECS は、帯域幅を一時的にアップグレードする機能を提供します。ユーザーは、特定の期間および期間にアップグレードする帯域幅の量を指定できます。帯域幅は比較的一定の周期的な変動があるため、ユーザーは定期的に操作を実行できることを望んでいます。したがって、OOS では、スケジュールされた帯域幅と、コストを節約するためのアップグレード ソリューションも提供されており、帯域幅はユーザーが事前に設定した短時間 (11 時など) に高いレベルにアップグレードされ、その後 2 時間持続します。
ユーザーのオフピーク時には帯域幅を削減でき、これに基づいてさらなる操作を実行できます。たとえば、ピーク期間の到着時刻のユーザーの推定があまり正確でない場合、クラウド モニタリング アラームのトリガーを使用して、一時的な帯域幅のアップグレードを実行できます。たとえば、帯域幅の使用率が 70% を超えた場合、帯域幅が間もなく到着します。使用量のピーク時には、この時点で一時的な帯域幅が増加します。ピーク期間が終了すると、一時的な帯域幅は再び減少します。この操作を通じて、それほど周期的ではないいくつかのことを行うことができます。リソースの使用量を最適化できます。
5. セキュリティコンプライアンス: システムパッチのスキャンと修復
OOS には、セキュリティ コンプライアンス シナリオにおける多くのベスト プラクティスもあります。ベスト プラクティスの 1 つは、システム パッチのスキャンと修復をサポートし、ECS インスタンスの自動修正修復を実現できるパッチ管理機能です。
まず、パッチ管理では、各オペレーティング システムに対してすぐに使用できるデフォルトの固定制限が提供され、80% 以上のユーザーが設定なしですぐに使用できる効果を達成できます。パッチをインストールするための特別な要件があるユーザーのために、OOS は、デフォルトの固定制限の代わりにカスタマイズされた可変制限を使用するオプションも提供します。これらのオペレーティング システム レベルのタイプ、レベル、リリース時間に基づいてフィルタリングを行うことができます。パッチ、フィルター。たとえば、ユーザーの安定性要件が比較的高い場合は、セキュリティ オペレーティング システムとセキュリティ関連のパッチのみをインストールできますが、リスク レベルが高い場合は、拡張パッチや低次元パッチなどの最適化されたパッチはインストールされません。
同時に、ユーザーはリリース時期についての要件を持つこともできます。リリース時期は、インストールおよびリリースから 1 週間以上経過しても比較的安定しています。一部のパッチはリリースおよびテストされ、問題があることが判明したため、リサイクルされます。現時点で、パッチがリリースされてすぐにインストールすると、いくつかの隠れた危険が生じる可能性があります。パッチがリリースされて比較的長期間にわたってテストされると、その安定性は実際にはある程度保証されます。
さらに、パッチ管理も OOS の基本機能のようなもので、さまざまなインスタンス選択方法をサポートします。この手動によるタグの選択により、リソース グループの選択、構成リストの選択、およびパッチ管理がすべてサポートされます。このシナリオでは、たとえばリソースで、ユーザーはテスト環境用のリソースと運用環境用のリソースを持つことができます。
2 つのリソースには、異なる構成とテストが必要になる場合があります。安定性の要件がそれほど高くない可能性があるためです。したがって、毎日アップグレードできます。適切なパッチが入手可能になったらすぐにインストールしてください。実稼働環境ではリソースの安定性に対する要件がより高いため、毎週定期的に実行する必要があります。これらは、インスタンスを選択することで実現できます。さらに、パッチ管理では、スキャンのみを含むさまざまな修復方法もサポートされています。つまり、どれが修正され、どれがインストールする必要があるかをスキャンするだけで、実際にはインストールされません。まず、現在のインスタンスでの特定のパッチのインストール ステータスを確認します。
さらに、スキャンしてインストールしますが、このとき、パッチをスキャンするだけでなく、複雑で無期限の制限が設定されたシステム パッチもインストールされます。より重要なパッチとしては、Windows パッチ、Linux およびカーネル パッチがあります。場合によっては、有効にするためにインスタンスを再起動する必要もあります。ユーザーは、インストール後、必要に応じてインスタンスを再起動しないと言うことができます。現時点ではパッチはインストールされていますが、まだ有効になっていません。その後、ユーザーは、インスタンスを再起動してパッチを有効にするか、修正インストールの直後にインスタンスを再起動してパッチを有効にするための、より適切な時間と運用およびメンテナンスの期間をスケジュールできます。これらはすべてパッチ管理で設定できます。
パッチ管理では、即時修復や定期修復のスケジュール設定など、柔軟な処罰方法もサポートしています。パッチ管理には、Linux や Windows など、現在のさまざまなサーバー オペレーティング システムが付属しており、9 つの一般的なオペレーティング システムをサポートしています。Windowsサーバーに加えて、8種類のLinuxサーバーもサポートします。いくつかのバージョンには、Alibaba Cloud、Anolis、CentOS、RHEL、Debian、Ubuntu、Alma Linux、Rocky Linux が含まれます。
パッチ管理機能を通じて、ユーザーは Linux インスタンスや Windows インスタンスを含む ecs インスタンスのバッチを作成および修復できます。その後、パッチ管理のインストール スクリプトが、インスタンス内のオペレーティング システムの種類に応じて、対応するパッチをプルします。たとえば、Alibaba Cloud には対応するパッチ期間がかかります。Windows パッチ インスタンスの場合は、対応する Windows パッチ マシンがプルされて、パッチがインストールされ、スキャンが設定されます。
6. セキュリティ コンプライアンス: 構成監査と組み合わせたセキュリティ コンプライアンスの自動修復
さらに、構成監査は、リソースの継続的なコンプライアンスを確保するためのリソース監査サービスです。OOS と組み合わせられる自動コンプライアンス修復は、リソースを大量に消費するサービスです。非準拠リソースを検出するように監査サービスを構成します。さまざまなクラウド リソースを監査するように監査サービスを構成することで、これらの事前設定されたルールに基づいて、クラウド リソースの構成がセキュリティのベスト プラクティスおよびコンプライアンス要件に準拠しているかどうかを確認できます。監査ルールごとに、ユーザーは OOS の自動修復スキームを構成できます。デフォルトでは、構成監査によってどのリソースが準拠していないことが検出され、手動で修復する必要があるためです。OOS 自動修復ソリューションを使用すると、手動修復を回避できます。ユーザーは、構成監査でリソースの不準拠が検出されたときに、すぐに自動修復をトリガーできます。
図の写真を例に挙げると、これはクラウド リソース タグの革新です。クラウドリソース上で確認できます。実際には、ラベルには 3 種類あり、1 つは地域ラベル、もう 1 つは部門ラベル、つまり情報部門、もう 1 つはテスト環境や本番環境などの環境ラベルです。ECS OOS および VPC 上の各リソースには異なるラベルが付けられていることがわかります。監査の設定では、いくつかのコンプライアンス ルール要件を設定できます。
たとえば、今日割り当てられたルールは、指定されたラベル部門が存在する必要があることを意味します。会社が部門ごとに費用を分けるからです。あなたが部門としてラベル付けされていない場合、アカウントを分割するときにあなたを部門に含めません。これでは会計が不正確になり、すべてのコストをさまざまな部門に分割することができなくなります。したがって、構成監査ではすべてのリソースが検出され、一部のリソースに部門のラベルが付けられていないことがわかります。この時点で、彼はこれらのリソースを記録します。OOS は自動修復をトリガーし、事前に設定されたルールに従って、指定されたラベルを非準拠リソースに割り当て、リソース上のラベルを修復します。同時に、ecs はすべてのリソースに部門関連のラベルを付けるため、合理的かつ正確な会計が保証されます。
4. まとめ
クラウドは実際に、リソースの運用と保守の効率性、リソースのコスト、リソースのセキュリティとセキュリティ コンプライアンスの最適な時期など、さまざまなベスト プラクティスを提供します。OOS プラットフォームは、その強力なタスク オーケストレーション機能と追加の支援を使用します。運用と保守の機能により、自動化できます。さまざまな面でクラウド上のベスト プラクティスを実現します。ユーザーは、OOS、タスク オーケストレーション プラットフォーム、およびクラウド上の各製品のベスト プラクティスに基づいて、独自の自動運用およびメンテナンス プラットフォームを作成できます。OOS の最終的な開発方向は、独自のプラットフォーム機能を構築し、使用のしきい値を下げることでより多くのクラウド リソースをサポートし、より多くのクラウド リソース シナリオにベスト プラクティスを自動的に適用することです。その後、ユーザーは、OOS プラットフォームに基づいて、独自の自動運用保守プラットフォームをより便利かつ効率的に構築できます。
この記事は Alibaba Cloud のオリジナル コンテンツであり、許可なく複製することはできません。
Bilibiliは2度クラッシュ、テンセントの「3.29」第1レベル事故…2023年のダウンタイム事故トップ10を振り返る Vue 3.4「スラムダンク」リリース MySQL 5.7、莫曲、李条条…2023年の「停止」を振り返る 続き” (オープンソース) プロジェクトと Web サイトが 30 年前の IDE を振り返る: TUI のみ、明るい背景色... Vim 9.1 がリリース、 Redis の父 Bram Moolenaar に捧げ、「ラピッド レビュー」LLM プログラミング: Omniscient 全能&&愚かな 「ポスト・オープンソースの時代が来た。ライセンスの有効期限が切れ、一般ユーザーにサービスを提供できなくなった。チャイナ ユニコムブロードバンドが突然アップロード速度を制限し、多くのユーザーが苦情を申し立てた。Windows 幹部は改善を約束した: Make the Start」メニューもまた素晴らしいです。 パスカルの父、ニクラス・ヴィルトが亡くなりました。