Amazon Managed Grafana を用いて Amazon EKS Anywhere 上に構築した 5G O-RAN 拠点向けオブザーバビリティ

オープンで、仮想化された、インテリジェントな 5G の推進における重要なステップにおいて、オープン無線アクセスネットワーク (O-RAN) の普及が挙げられます。O-RAN は、無線アクセスネットワーク (RAN) の柔軟性と導入速度の向上を目指し、同時にクラウドアーキテクチャの採用による資本コスト及び運用コストの削減を目指しています。 O-RAN は、RANを O-RU (O-RAN Radio Unit)、O-DU (O-RAN Distributed Unit)、O-CU (O-RAN Central Unit)、RIC (RAN Intelligent Controller) などの複数のコンポーネントに分解することでこれを実現します。これらのコンポーネントは、必要に応じてプログラム可能な Acceleration Abstraction Layer (AAL) を追加して、汎用サーバー上でコンテナ化されたソフトウェアとして実行できます。コンテナ化された RAN ネットワーク機能のホスティングを可能にする、基盤となるクラウドコンピューティング層は、O-RAN 標準では O-Cloud とも呼ばれます。

このアーキテクチャは、下の図1 に示すように、3つのオープンレイヤとして表せます。汎用ハードウェアサーバーは、コンテナ化された RAN 機能を実行するためのコンテナランタイムをホストします。最も一般的に使用されているコンテナランタイムは Kubernetes で、このブログでも使用しています。分かり易くするために、O-CU と O-DU のソフトウェアアプリケーションのみを紹介します。

図1. O-RAN 拠点のレイヤ

O-RAN テクノロジーは本質的に分解された構成 (disaggregation) となっており、通信サービスプロバイダが各レイヤに複数のサプライヤを持つことを可能とします。一方でその為、様々なタイプのハードウェア及びソフトウェアの監視とオブザーバビリティ (可観測性) に課題が生じ得ます。通常、全てのベンダが独自の要素管理システム (EMS: Element Management System) を提供しますが、異なるシステムを使用して発生した問題を相互に関連付けるのは不便です。

このブログでは、Amazon Managed Grafana を Prometheus や OpenTelemetry などの一般的に使用されているオブザーバビリティソリューションと併用して、O-RAN 拠点の 3 つのレイヤ (サーバー、Kubernetes クラスタ、O-RAN アプリケーション) 全てをサプライヤ間で一律に監視する方法について説明します。このオブザーバビリティを AWS リージョンに集約することで、通信サービスプロバイダはクラウドの信頼性と運用のし易さを享受できます。これにより、通信サービスプロバイダは O-RAN が提供できるよう設計された柔軟性に方向転換できるようになります。

ここでは Prometheus サーバーの例として Amazon Managed Service for Prometheus、OpenTelemetry コレクターの例として AWS Distro for OpenTelemetry (ADOT)、汎用 (COTS) サーバーで使用可能な Kubernetes ランタイムの例として Amazon EKS Anywhere を使用しています。ただし、このブログのほとんどの概念は、選択したハードウェアと Kubernetes ディストリビューションに適用できます。AWS で O-RAN を構築する方法に関する一般的なガイダンスについては、このホワイトペーパーを参照ください。

エッジサーバー可用性の監視

サーバー層については、重要な監視の例と、サーバーが到達可能/利用可能かどうかを示します。サーバーの可用性について示した手法は、詳細なサーバーオブザーバビリティにも使用できます。

オプション 1: Redfish REST API を使用してサーバー状態を監視する

Redfish は、ユーザーがスタンドアロンサーバーなど様々なデバイスや環境を管理できるようにする、使いやすく実装が簡単な RESTful インターフェイスを定義するベンダ間の業界標準です。多くの場合、Baseboard Management Controller (BMC) は Redfish プロトコル、リソース、および機能を実装して、システムのリモート管理機能を提供します。O-RAN エッジの主要なサーバーサプライヤのほとんどは、Redfish 標準をサポートしています。HPE サーバーは Redfish 対応の iLO インターフェースを使用します。同様に Dell の iDRAC と Supermicro も Redfish のサポートを提供しています。サーバーサプライヤの Redfish 準拠については、こちらで確認できます。

特定のサーバーで Redfish が有効になっている (または追加のソフトウェアやライセンスを使用して Redfish を有効にできる) 限り、次の図に示すように、Redfish REST 仕様を使用して監視が行えます。

図2. Redfish API を使用したサーバー監視

Redfish 対応サーバーは、/redfish/v1/EventService/Subscriptions でイベントサブスクリプションサービスを定義します。ここで、監視サービスなどのクライアントは次の情報を使用してサブスクライブできます。

イベント受信側クライアントがイベント送信を予期するリスナー URI。Redfish サービス内でイベントがトリガされると、そのサービスはリスナー URI にイベントを送信する
送信するイベントのタイプ

詳細については、Redfish 仕様の「Eventing」章を参照してください。

例を使用して、Redfish 対応の iLO インターフェースを備えた HPE サーバーを監視してみましょう。

1. Amazon API Gateway のこのドキュメントに記載されている手順を使用して、API Gateway でリスナー REST API を作成します。

2. 次のようにサーバーの Redfish サービスで必要なイベントをサブスクライブします。

POST /redfish/v1/EventService/Subscriptions/

Request Body:

{
    "Destination": "https://{restapi-id}.execute-api.{region}.amazonaws.com/{stage}",
    "Context": "Some context",
    "RegistryPrefixes": [
        "StorageDevice",
        "NetworkDevice",
        "iLOEvents",
        "ResourceEvent"  
    ],
    "HttpHeaders": {
        "Content-Type": "Application/JSON",
        "Odata-Version": "4.0"
    },
}

ここで

Destinationはステップ 1 で作成したリスナー API。

Contextには、拠点の詳細など、提供したい任意の静的情報を使用できます。

RegistryPrefix は、サブスクライブしているサーバーイベントのリストです。

HttpHeadersは、イベント POST 操作に必要な任意の HTTP ヘッダーです。

3. サブスクライブしているイベント (この例では ILOEvent ‘ServerPoweredOff’) が発生すると、Refish は次のような POST イベントをリスナー API に送信します。

{
    "EventID": "myEventId",
    "EventTimestamp": "2023-02-13T14:49:20Z",
    "Severity": "Critical",
    "Message": "This is a test event message",
    "MessageId": "iLOEvents.2.1.ServerPoweredOff",
    "MessageArgs": [
        "NoAMS",
        "Busy",
        "Cached"
    ],
    "OriginOfCondition": "/redfish/v1/Systems/1/"
}

4. リスナー API の POST バックエンドを AWS Lambda の Python 関数として設定し、サーバーイベントを処理して Amazon Timestream に書き込みます。

5. Amazon Managed Grafana のデータソースとして Amazon Timestreamを追加します。

6. Amazon Timestream データを使用してアラートを作成するように Amazon Managed Grafana を設定します。

オプション2: Prometheusの「up」メトリクスを使用してサーバー状態を監視する

監視対象のサーバーが Kubernetes クラスタの一部である場合は、Prometheus を使用して監視できます。Prometheus は各インスタンスのスクレイピングに対して、次のように稼働時系列 (up time series) のサンプルを保存します。

up {job=」<job-name>「, instance=」<instance-id>「}: 1 インスタンスが正常でアクセス可能な場合は 1、スクレイプが失敗した場合は 0。

次の図に示すように、up メトリクスはサーバーの健全性監視に使用できます。

図3.　Node Exporter 「up」メトリクスを使用したサーバー監視

1. Node Exporter などのノードを監視できるユーティリティを Kubernetes クラスタ内のデーモンセットとしてインストールします。例として、Node Exporterは、全てのノードの up メトリクスを次の形式で収集します。

up{instance="192.168.1.50:9100",job="node-exporter",nodename="hostname-121"}

2. OpenTelemetry コレクターの「Prometheus Receiver」コンポーネントを使用して、Node Exporter のメトリクスをスクレイピングします。以下の ADOT のサンプル構成を使用して、Node Exporter からスクレイピングが可能です。 ADOT コレクターは EKS Anywhere のキューレーションパッケージとして提供されている点を留意下さい。キューレーションパッケージは EKS Anywhere をコンテナランタイムとしてより便利にするソフトウェアのパッケージです。

 receivers:
        prometheus:
          config:
            global:
              scrape_interval: 30s
              scrape_timeout: 10s
            scrape_configs:
              - job_name: 'node-exporter'
                kubernetes_sd_configs:
                  - role: endpoints
                ec2_sd_configs:
                relabel_configs:
                  - source_labels: [ __address__ ]
                    action: keep
                    regex: '.*:9100$'
                  - action: replace
                    source_labels: [__meta_kubernetes_endpoint_node_name]
                    target_label: nodename

3. OpenTelemetry コレクターの「Prometheus Remote Write Exporter」コンポーネントを使用して、Prometheus リモート書き込み対応のバックエンド (Amazon Managed Service for Prometheus など) にメトリクスを送信します。

exporters:
  prometheusremotewrite:
    endpoint: {{ prometheusRemoteWriteUrl }}

4. Prometheus バックエンドにアラートルールを作成します。

{
    "alert": "NodeTargetMissing",
    "expr": "up{instance=~\".*9100.*\", job=\"node-exporter\", nodename!=\"\"} == 0",
    "labels": {
        "severity": "critical"
    },
    "annotations": {
        "summary": "Node target with name {{ $labels.nodename }} is missing",
        "description": "A Node target has disappeared.\n  LABELS = {{ $labels }} for more then 30 seconds"
    }
}

5. このドキュメントで説明されているように、Amazon Managed Service for Prometheus (または任意の Prometheus) をデータソースとして使用するように Amazon Managed Grafana を設定します。

6. このドキュメントの手順に従って Amazon Managed Grafana のアラートを視覚化し、Prometheus アラートマネージャーをデータソースとして使用します。

Kubernetes コンテナランタイムの監視

オプション 2 と同様の設定を使用して、kube-state-metrics、Node Exporter、Container Advisor などのユーティリティをクラスタにインストールします。これらのユーティリティはクラスタを監視し、アラートや有益なダッシュボードの作成に使用できるメトリクスを生成します。

オプション 2 のステップ 2 ～ 6 に従って、メトリクスをスクレイピングし、アラートを作成し、Amazon Managed Grafana でアラートを視覚化します。Amazon EKS Anywhere のサンプルアラートルールについては、この GitHub の投稿を参照してください。

Kubernetes メトリクスが Amazon Managed Grafana で利用できるようになると、広大なマーケットプレイス上で、Amazon Managed Grafana にインポートできる事前設定された Grafana Kubernetes ダッシュボードにアクセスできるようになります。

O-RAN アプリケーションの監視

vDU、vCU、AAL などの O-RAN アプリケーションは、Kubernetes コンテナランタイム上でマイクロサービスとして実行され、メトリクスを生成してエクスポートできる必要があります。この機能を作成するかどうかはアプリケーションベンダ次第です。ここでは、下図が示すように、一般的に使用される次の 2 つの方法のいずれかを使用してアプリケーション監視が可能です。

図4. メトリクスを使用した O-RAN アプリケーション監視

オプション 1: O-RAN アプリケーションが Prometheus でスクレイピングできるメトリクスを公開する

Prometheus は、装備されたアプリケーションからメトリクスを「スクレイピング」することによって機能します。O-RAN アプリケーションは Prometheus 準拠のメトリクスを生成し、HTTP 経由で利用できるようにすることが可能です。この機能を提供するかどうかは、O-RAN アプリケーションベンダ次第です。

OpenTelemetry コレクターの「Prometheus Receiver」コンポーネントを使用して、O-RAN アプリケーションから公開されているメトリクスをスクレイピングし、次の例のように Prometheus バックエンドにエクスポートします。それから、前の Kubernetes コンテナランタイム章で説明したように、O-RAN アプリケーションメトリクスを Amazon Managed Grafana で視覚化できます。

receivers:
  prometheus:
    config:
      global:
        scrape_interval: 30s
      scrape_configs:
        - job_name: oran_app_metrics
          static_configs:
            - targets: ["1.2.3.4:9091"]
              
exporters:
  prometheusremotewrite:
    endpoint: {{ prometheusRemoteWriteUrl }}

ここで、1.2.3.4:9091は、O-RANアプリケーション上のメトリクスサーバーのIPアドレスとポート番号です。

オプション 2: O-RAN アプリケーションが OpenTelemetry プロトコルを使用してメトリクスを転送する

O-RANアプリケーションは、例で挙げられているように、OpenTelemetry Protocol（OTLP）を使用して Prometheus 準拠のメトリクスを OpenTelemetry コレクター（ADOT コレクターなど）に送信することもできます。この機能を提供するかどうかは、アプリケーションベンダ次第です。

OpenTelemetry コレクターの「OTLP Receiver」コンポーネントを使用してメトリクスを受信し、次の例のように Prometheus バックエンドにエクスポートします。それから、前の Kubernetes コンテナランタイム章で説明したように、O-RAN アプリケーションメトリクスを Amazon Managed Grafana で視覚化できます。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  prometheusremotewrite:
    endpoint: {{ prometheusRemoteWriteUrl }}

結論

このブログでは、Amazon Managed Grafana を使用して O-RAN エッジ拠点 (O-Cloud) のすべてのレイヤを監視する複数の方法を学びました。これにより、ハードウェア/ソフトウェアのサプライヤに関係なく、地理的に分散した O-RAN 拠点のオブザーバビリティが一元化され、ひいては O-RAN ビジョンの達成に役立ちます。 AWS リージョンにオブザーバビリティ機能を持たせることで、AWS のマネージドサービスに付属する組み込みの耐障害性が得られます。さらに、補足的な AWS での人工知能/機械学習 (AI/ML) とデータ分析サービスを使用して、メトリクスを処理することもできます (例えば、メトリクスをインサイトに変換するなど)。その過程で、Amazon EKS Anywhere や ADOT など、O-RAN の導入に役立つ他の AWS サービスについても学びました。

この記事はアマゾンウェブサービスジャパンの黒田由民が翻訳を担当しました。 (原文はこちら)

著者

Prateek Shahane

Prateek Shahane は、Amazon Web Services (AWS) のシニアインダストリースペシャリストで、5G および通信デジタルテクノロジーを専門としています。AWS プロフェッショナルサービスの一員として、テレコムのお客様向けに革新的なクラウドソリューションと自動化フレームワークの設計と提供を主導しています。また、ネットワークプログラマビリティやテレコムの IT 近代化にも取り組んでいます。Prateek は 20 年以上にわたり、グローバル規模の通信サービスプロバイダと緊密に協業しています。

Luis Lopez

Luis Lopezは、Amazon Web Services (AWS) のプロフェッショナルサービス (テレコム) のシニアクラウドアーキテクトで、スペインを拠点としています。Luis はクラウドインフラストラクチャとネットワーキングを専門とし、テクノロジーに情熱を注いでおり、お客様が AWS で可能な技術を導入するためのソリューションを構築するのを支援しています。仕事以外では、家族や友人と過ごす時間を楽しんでいます。

Rajneesh Tyagi

Rajneesh Tyagi は、Amazon Web Services (AWS) のリードコンサルタントです。Rajneesh は高度なテクノロジーのオーケストレーション、自動化、コンテナ化、クラウドネイティブアーキテクチャ、CI/CD を専門としています。プラットフォームエンジニアリングのバックグラウンドを持つ Rajneesh は、特にテレコムと銀行の業界において、回復力がありスケーラブルな DevOps プラクティスの実装に注力しています。仕事以外でも、DevOps 環境の最新動向を探求することに熱心に取り組んでいます。

Amazon Web Services ブログ