Best Practices for Event Based Automated Operation and Maintenance

01 なぜシステムイベントは重要なのか

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

ユーザーに ECS を提供するには、基盤となる物理インフラと中間層の仮想化サービスが必要です。仮想化サービス上でゲスト OS を実行し、ユーザーにサービスを提供します。

運用保守システムイベントにおいて、Alibaba Cloud は物理インフラと仮想化サービスの運用保守を担当します。コンピューティング、ストレージ、ネットワークコンポーネントに障害が発生した場合、Alibaba Cloud は運用保守システムイベントを発出します。これらの O&M システムイベントは、クラウドベンダーとユーザーが連携して共同で運用保守を行う必要があります。

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

上の図に、代表的なシステムイベントを示します。

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

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

この場合、Alibaba Cloud は検出後に計画 O&M イベントをユーザーに発出します。ユーザーが一定期間内に対応しなかった場合、Alibaba Cloud はユーザーに代わって正常なハードウェアへインスタンスをマイグレーションします。

ユーザーが対応した場合は、Alibaba Cloud が提供する運用ウィンドウ内で、最も有利でサービスへの影響が最小限となるタイミングを選択できます。事前にインスタンスをマイグレーションすることで、計画再起動を回避できます。

コストに関して、有効期限切れ時にインスタンスがダウンする場合、システムはインスタンスの有効期限切れの 3 日前にイベントを発出します。ユーザーは自動更新などの更新方法を自身で計画する必要があります。

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

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

第 1 層は、ユーザーが通知を受動的に受け取り、コンソールにログインして手動で処理するレベルです。

第 2 層は、ユーザーがイベント処理の意識をある程度持ち、イベント通知を能動的にサブスクライブするレベルです。

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

第 4 層は、ホステッド型の自動運用保守です。ユーザーはイベントの運用保守ロジックをすべて Alibaba Cloud に委ね、Alibaba Cloud がホストします。

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

次に、イベント通知をより正確にする方法について説明します。Cloud Monitor は、すべてのクラウドプロダクトのシステムイベント、統一されたクエリ入口、およびイベントアラーム機能を提供します。

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

Cloud Monitor はユーザー側で 2 種類のサービスを提供します。

1 つ目は、ユーザーが能動的にクエリを実行する方法です。コンソールまたは Open API を介してシステムイベントをクエリできます。

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

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

1 つ目のカテゴリは人向けです。電話、SMS、メール、および DingTalk や Feishu などの Webhook ベースのツールを含みます。

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

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

イベントデータは JSON 形式で、外層にはイベントの共通属性（イベントの一意な ID、イベントソース、イベントレベル、イベント名、イベントの発生日時とリージョンなど）が含まれます。

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

EventRule はイベントのフィルタリングルールで、イベントの共通属性と内容に基づいてイベントをマッチングします。

Rule Targets はイベント通知のターゲットです。その中で、アラーム通知は人向けの通知を表し、電話、SMS、メール、DingTalk ボットなどを含みます。メッセージサービスキュー、Function Compute、URL コールバック、Log Service などは、プログラムによる自動消費に使用されます。

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

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

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

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

さらに、ユーザーは Cloud Monitor のフィルタリング機能を使用してきめ細かいフィルタリングを行えます。1 つのイベントに、インスタンスの作成、解放、起動、停止などのステータスが含まれる場合があります。キーワードフィルタリングまたは SQL フィルターを使用して、特定のタイプのイベント内の特定の状態を正確にフィルタリングできます。

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

イベントルールを精緻化した後、イベントアラームテンプレートを作成します。テンプレートを N 個のグループに適用します。これにより、アラームルールの一括複製を実現し、メンテナンス負荷を軽減します。

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

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

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

複数のクラウドプロダクトを使用しているため、O&M システムには N 個のポーリングコードがあり、リアルタイム性能は十分ではありませんでした。

システムをイベント駆動アーキテクチャに改造します。初期化フェーズで、システムは Cloud Monitor にイベントアラームルールを設定します。クラウドプロダクトからイベントが公開されると、Cloud Monitor はイベントのマッチングを検出し、指定された顧客のメッセージキューにイベントをプッシュします。顧客の運用保守システムはメッセージキューからイベントメッセージをプルし、保存して運用保守ポータルにプッシュします。

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

弾力的スケーリングに関して、インスタンスが解放されると、ECS 管理コントロールはインスタンスステータス変更イベントを発出します。Cloud Monitor はルールに基づいて弾力的スケーリングのメッセージキューにルーティングします。次に、弾力的スケーリングはイベントメッセージを消費してインスタンス情報を取得します。弾力的スケーリングはスケーリンググループからインスタンスを削除し、スケーリングルールに従って次の操作を実行します。

04 クラウド上のホステッド型イベント運用保守

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

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

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

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

O&M テンプレートには 5 つのステップがあります。

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

2 つ目、describeSLB。解放されたプリエンプティブインスタンスに関連する負荷分散 ID をクエリします。

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

4 つ目、waitConnectionExpire。確立されたネットワーク接続が切断されるのを待ちます。

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

Q&A リンク、ユーザー Q&A

Q1 リソーススケジューリングで ROS と OOS を連携するベストプラクティスはありますか？

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

Q2 OOS の O&M オーケストレーションのテンプレートは必ず設定する必要がありますか？

A：いいえ。オーケストレーションでは一般的な運用保守シナリオ用のテンプレートが用意されており、コンソールで操作できます。設定をクリックしてください。

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

A：サービスに影響が出る可能性があります。バーストパフォーマンスインスタンスの使用が想定通りかどうかを確認する必要があります。インスタンスのアップグレードまたは非バーストパフォーマンスインスタンスへの置き換えをご検討ください。