Best Practices for Event-Based Automated operation and maintenance

システムイベントは、クラウドリソースの状態変化を表します。エラスティックコンピューティングのシステムイベントを例に取ります。上の図は、エラスティックコンピューティングのイベントソースを表しています。

ユーザーにクラウドサーバーを提供するには、基盤となる物理インフラと中間の仮想化サービスが必要です。仮想化サービスの上でゲスト OS が動作し、最終的にユーザーにサービスが提供されます。

運用保守のシステムイベントの領域では、Alibaba Cloud が物理インフラと仮想化サービスの運用保守を担当しています。コンピューティング、ストレージ、ネットワークの各コンポーネントで障害が発生すると、Alibaba Cloud は運用保守タイプのシステムイベントを送信します。これらの運用保守システムイベントには、クラウドベンダーとユーザーが協力して運用保守を行う必要があります。

リソース状態変化のイベントについては、必ずしも障害や問題を示すものではありません。むしろ、イベント駆動型アーキテクチャを実装するための基盤となります。

上の図に示すように、いくつかの代表的なシステムイベントが表示されています。

予期しない例外の面では、インスタンスのダウンタイムがユーザーのサービス中断を引き起こす可能性があります。ローカルディスクインスタンスがダウンした場合、Alibaba Cloud はユーザーに代わってインスタンスのマイグレーションを判断できないため、ユーザー自身が対応する必要があります。

計画運用保守の面では、最も一般的なイベントはアクティブな運用保守です。システムメンテナンス計画によりインスタンスが再起動されます。コンピューティング、ストレージ、ネットワークなどの基盤ハードウェアに問題があるものの、即座に停止するほど深刻ではない場合です。

この場合、Alibaba Cloud は検出後に計画運用保守イベントをユーザーに送信します。ユーザーが一定期間内に応答しない場合、Alibaba Cloud はユーザーに代わってインスタンスを正常なハードウェアにマイグレーションします。

ユーザーが応答した場合、Alibaba Cloud が提供するメンテナンスウィンドウ内で、最も都合が良くサービスへの影響が最小のタイミングを選択できます。事前にインスタンスをマイグレーションすることで、計画再起動を回避できます。

コストの面では、インスタンスの有効期限切れにより停止する場合、システムは有効期限の 3 日前にイベントを送信します。ユーザーは自動更新などの方法で、自身で更新を計画する必要があります。

ステータス通知の面では、インスタンスライフサイクルステータスの変化は、ECS インスタンスの制御状態の変化を表します。たとえば、インスタンスの作成、インスタンスの起動、インスタンスのシャットダウン、インスタンスの解放などです。

上の図は、クラウドイベント運用保守のいくつかの一般的な形態を示しています。下から上に向かって、自動化の度合いが高くなります。Alibaba Cloud は、ユーザーがイベント運用保守の自動化に取り組むことを推奨しています。

第 1 のレイヤーでは、ユーザーは通知を待ってからコンソールにログインし、手動で処理を行います。

第 2 のレイヤーでは、ユーザーはイベント処理に対する一定の意識を持ち、自らイベント通知をサブスクライブします。

第 3 のレイヤーでは、ユーザーは一定の技術力を備え、自動または半自動の運用保守システムを構築しています。イベント駆動型アーキテクチャを通じて、必要に応じてさまざまなレベルのイベントメッセージを処理できます。処理中は、クラウドプロダクトの API を呼び出して運用保守を行います。

第 4 のレイヤーは、ホスティング型の自動化された運用保守です。ユーザーはイベントの運用保守ロジックを完全に Alibaba Cloud に委譲し、Alibaba Cloud のホスティング下で実行します。

02 イベント通知をより効果的にする

次に、イベント通知をより正確にする方法について説明します。CloudMonitor は、すべてのクラウドプロダクトのシステムイベント、統合クエリインターフェース、およびイベントアラーム機能を提供しています。

現在、100 以上のクラウドプロダクトが独自のイベント情報を CloudMonitor に送信しています。クラウドサーバー、クラウドデータベース、コンテナサービスなどが含まれます。

CloudMonitor は、ユーザー側に対して 2 種類のサービスを提供しています。

1 つ目は、ユーザーがアクティブにクエリを実行する方法です。コンソールまたは OpenAPI を通じてシステムイベントをクエリします。

2 つ目は、システムからユーザーへのイベント通知です。CloudMonitor のイベントアラームルールに基づいて、イベント通知機能をサブスクライブします。

CloudMonitor の通知チャネルは 2 つのカテゴリに分かれます。

1 つ目は人向けのチャネルです。電話、SMS、メール、および Webhook ベースのツール（DingTalk、Lark など）が含まれます。

2 つ目は自動化された運用保守プログラムや運用保守システム向けのチャネルです。メッセージキュー、Log Service、Function Compute、URL コールバックなどがあります。ソフトウェアライブラリを活用して、イベントの自動処理を実現できます。

上の図は、CloudMonitor イベントの一般的なフォーマットを示しています。100 以上のクラウドプロダクトのシステムイベントが CloudMonitor に収集された後、統一イベントモデルに統合されます。

イベントデータは JSON 形式で、外層はイベントの公開属性です。たとえば、イベントの一意な ID、イベントソース、イベントレベル、イベント名、イベントの発生時刻と場所などです。

content フィールドはイベントの内容を表します。特定のイベントタイプに関連付けられています。クラウドプロダクトのイベントロジックにより、イベントごとに異なる内容が決まります。

EventRule はイベントフィルタールールで、公開属性とイベント内容に基づいてイベントをマッチングさせます。

Rule Targets はイベント通知の送信先です。その中で、アラーム通知は電話、SMS、メール、DingTalk ボットなどの手動通知を表します。Message Service キュー、Function Compute、URL コールバック、Log Service などは、プログラムによる自動消費に使用されます。

マッチングするイベントアラームルールに合致するイベントが発生すると、CloudMonitor はイベントを対応するターゲットにルーティングします。複数のターゲットが選択されている場合、各ターゲットに通知されます。

イベント通知をより効果的にするため、Alibaba Cloud はタグを使用してリソースをグループ化し、アラームルールの粒度を細かくしています。その後、動的ラベルルールを通じて CloudMonitor のアプリケーショングループを作成します。

これにより、アプリケーショングループとタグは 1 対 1 の関係になります。ユーザーはアプリケーション管理システムでタグをインポートしてアプリケーショングループを作成することもできます。アプリケーション管理が CloudMonitor のアプリケーショングループを自動設定します。

次に、グループに基づいてアラームルールを作成します。まず、役割と責任に応じて異なる連絡先グループを作成します。次に、イベントの重大度と受信者に基づいて複数のアラームルールを分割します。

さらに、ユーザーは CloudMonitor のフィルタリング機能を使用して、粒度の細かいフィルタリングを行うことができます。1 つのイベントには、インスタンスの作成、解放、起動、停止などのステータスが含まれる場合があります。キーワードフィルタリングまたは SQLFilter を通じて、特定のステータスタイプを正確にフィルタリングできます。

通知方法の選択では、イベントのレベルに応じて異なる通知方法を選択します。イベント通知がスパムメッセージや迷惑メールになることを避けるため、DingTalk グループアラームを推奨します。

イベントルールを精緻化した後、イベントアラームテンプレートを作成します。テンプレートを N 個のグループに適用することで、アラームルールのバッチコピーを実現し、メンテナンスの負荷を軽減します。

03 イベント駆動型運用保守アーキテクチャ

OpenAPI ベースのリソースステータスのポーリングによる状態変化の取得は、リアルタイム性能が低く、冗長なリクエストが多く、システム消費が高く、フロー制限のリスクがあり、複数のクラウドプロダクト API に依存するため複雑さがさらに増します。Alibaba Cloud はイベント駆動型アーキテクチャの改善により、リアルタイム性能と安定性を向上させ、システム消費を削減しました。

ある顧客は以前、クラウドプロダクトの API をポーリングしてイベント情報を取得し、運用保守システムに保存していました。運用保守チームはイベントを運用保守ポータルにプッシュし、各業務システムがイベントへの対応を担当していました。業務システムは Alibaba Cloud コンソールに直接アクセスしません。

複数のクラウドプロダクトを使用しているため、運用保守システムには N 個のポーリングコードが含まれており、リアルタイム性能も低い状態でした。

システムをイベント駆動型アーキテクチャに変換します。初期化段階で、システムは CloudMonitor にイベントアラームルールを設定します。クラウドプロダクトからイベントが発行されると、CloudMonitor がイベントのマッチングを検出し、指定された顧客のメッセージキューにイベントをプッシュします。顧客の運用保守システムはメッセージキューからイベントメッセージを取得して保存し、運用保守ポータルにプッシュします。

上記の対応により、コードロジックが簡素化され、リソース消費が削減され、リアルタイム性能と安定性が向上しました。

Auto Scaling の面では、インスタンスが解放されると、ECS コントロールプレーンがインスタンスステータス変化イベントを発行します。CloudMonitor はルールに基づいて Auto Scaling のメッセージキューにルーティングします。その後、Auto Scaling はイベントメッセージを消費してインスタンス情報を取得します。Auto Scaling はスケーリンググループからインスタンスを削除し、スケーリングルールに従って次の操作を実行します。

04 クラウドホスティングによるイベント運用保守

運用保守スケジューリングシステムの OOS は、運用保守タスクを自動的に管理および実行できます。従来の手動運用保守やスクリプトベースの運用保守と比較して、低い導入障壁、標準化された安全な操作、高い効率、簡単なメンテナンス、無償という特長があります。

OOS オーケストレーションでは、イベント運用保守機能が提供されています。まず、イベントルールを設定してリソース範囲を制限します。次に、イベントトリガー後に実行する運用保守テンプレートを選択し、テンプレートパラメータを設定します。

Alibaba Cloud が提供するプリエンプティブルインスタンスは、比較的安価なインスタンスです。プリエンプティブルインスタンスの購入後、1 時間の保護期間があります。1 時間経過後、インスタンスはいつでも解放およびリサイクルされる可能性があります。リサイクルの 5 分前に、プリエンプティブルインスタンスからインスタンス中断通知が発行されます。

OOS のイベント運用保守を通じて、インスタンスがリサイクルされる前に、関連付けられたすべての負荷分散から削除し、ビジネスに影響を与えずにグレースフルオフラインを実現します。

運用保守テンプレートには 5 つのステップがあります。

1 つ目は eventTrigger です。プリエンプティブルインスタンスの解放イベントを監視します。

2 つ目は describeSLB です。解放されるプリエンプティブルインスタンスの負荷分散 ID を取得します。

3 つ目は setBackendServers です。解放されるインスタンスの負荷分散上の重みを 0 に設定します。

4 つ目は waitConnectionExpire です。確立されたネットワーク接続が切断されるまで待機します。

5 つ目は removeBackendServers です。解放されるインスタンスを負荷分散のバックエンドサーバーリストから削除します。

Q&A リンク、ユーザーの質問と回答

Q1 ROS と OOS を連携したリソースオーケストレーションのベストプラクティスはありますか

A：問題ありません。ROS は OOS テンプレートと実行をリソースとして定義し、OOS テンプレートの実行をサポートしています。OOS オーケストレーションは API 経由で行われるため、OOS 内で Resource Orchestration Service (ROS) API を呼び出してリソーススタックを作成できます。

Q2 OOS オーケストレーションのテンプレートは自分で設定する必要がありますか

A：いいえ。オーケストレーション機能では、一般的な運用保守シナリオが提供されており、コンソールで「設定」をクリックするだけで実行できます。

Q3 バーストパフォーマンスインスタンスの性能が制限された場合はどうなりますか

A：サービスに影響が出る可能性があります。バーストパフォーマンスインスタンスの使用が期待通りかどうかを確認する必要があります。インスタンスをアップグレードするか、非バーストタイプのインスタンスに置き換えることができます。