AWS監視の効率とコストを最適化：OTel 1.0形式（Protobuf）サポート開始

1. AWS OTEL 1.0（Protobuf）形式に正式対応

多くのお客様が、AWS環境のオブザーバビリティを担保するために、New RelicとAWS CloudWatch Metric Streamsを連携させています。

しかし、監視対象のAWSリソースが増加するにつれ、CloudWatchからNew Relicへ転送されるメトリクスデータの量もまた増大します。特に、従来の opentelemetry0.7（JSONベース）形式ではデータサイズが大きくなりがちで、データ転送コストや処理オーバーヘッドが懸念事項となることを、 New Relic では認識していました。

この課題を解決するため、 New RelicはAWS CloudWatch Metric Streamsから送信される OpenTelemetry 1.0 (Protobuf) 形式に正式に対応しました。

本アップデートの詳細は、公式のリリースノートでもご確認いただけます。

New Relicドキュメント: Support for AWS OTEL 1.0 format (October 13, 2025)

この対応により、お客様はAWSからNew Relicへ、よりコンパクトで高効率なProtobuf形式（OTel 1.0）を用いてメトリクスを送信できるようになります。

2. OTel 1.0形式へ移行し、監視効率を高める具体的な手順

AWS CloudWatch Metric Streamsを新規作成する際のデフォルト出力形式は opentelemetry0.7である場合があります。

New Relic では、AWS監視の効率化とコスト最適化の観点から、今回サポートが追加された opentelemetry1.0 形式の利用を推奨しています。

特に、 データ転送量が大きい大規模なお客様や、最新の技術標準の採用を推進されている先進的なお客様には、opentelemetry1.0 形式への移行（または新規採用）をお勧めします。

このアップデートは、 New Relicの「AWS CloudWatch Metric Streams連携」 をご利用の環境が対象となります。

既存の OTLP 0.7.0 形式から OTLP 1.0.0 (Protobuf) 形式への更新は、CloudWatch Metric Stream の出力形式を変更するだけで完了します。

ここでは、IaC（CloudFormation, Terraform）およびAWSコンソールでの具体的な設定変更方法を、推奨される順序で解説します。

1. CloudFormationによる設定変更

New RelicのUI経由で生成したCloudFormationテンプレート、あるいはカスタムテンプレートでインフラを管理されている場合、スタックの更新を行います。

AWS CloudFormation コンソールで、対象のスタック（例: NewRelic-AWS-Integration）を選択します。
「更新」を選択し、「既存のテンプレートを置き換える」を選びます。
テンプレート（またはパラメータ）を更新します。
- CloudWatch Metric Stream: OutputFormat プロパティ（またはパラメータ）の値を opentelemetry0.7 から opentelemetry1.0 に変更します。
スタックの更新を実行します。

（注：新規でスタックを作成する場合は、最初から OutputFormat に opentelemetry1.0 を指定して作成します。）

2. Terraformによる設定変更

TerraformでAWSインフラを管理されている場合、hashicorp/aws プロバイダの関連リソースを修正します。

CloudWatch Metric Stream リソースの更新:
- aws_cloudwatch_metric_stream リソース定義内の output_format 引数を変更します。
- 変更前 (旧): output_format = "opentelemetry0.7"
- 変更後 (新): output_format = "opentelemetry1.0"
terraform apply を実行して変更を適用します。

（注：新規で作成する場合は、最初から変更後の定義を使用します。）

3. AWSコンソールでの手動変更

IaCで管理されていない場合、AWSコンソールから直接変更します。これがリリースノートに記載されている手順となります。

AWS マネジメントコンソールで CloudWatch のサービスページに移動します。
ナビゲーションペインで「 メトリクス 」セクションにある「 ストリーム 」を選択します。
New Relicへのデータ転送に使用しているメトリックストリームを選択します。
「編集」をクリックします。
「 出力形式 (Output format) 」セクションで、選択を OpenTelemetry 0.7.0 から OpenTelemetry 1.0 (Protobuf) に変更します。
「 変更を保存 」をクリックします。

注意点：設定の確認（既存・新規共通）

OTel 1.0 形式による効率化のメリットを享受いただくためには、 意図的な形式の指定 が必要となります。

既存の連携設定をご利用の場合: お客様の既存環境への影響を避けるため、すでに opentelemetry0.7 形式で連携されている場合、設定は 自動的には変更されません 。上記いずれかの方法による 1.0 への更新をご検討ください。
新規で連携設定を作成する場合: 現時点ではCloudWatch Metric Streams作成時のデフォルト出力形式は opentelemetry0.7で作成されます。新規に作成される場合も、OTel 1.0 のメリットを享受するためには、必ず「出力形式」として OpenTelemetry 1.0 (Protobuf) を 明示的に選択 していただく必要があります。

3. アップデートの技術的意義：GZIP(JSON) vs Protobuf

手順は上記で完了しますが、では、一体なぜ OTel 1.0 (Protobuf) へ移行することが推奨されるのでしょうか。

GZIP圧縮を考慮してもProtobufが優位な理由

ここで、経験豊富なエンジニアであれば、このような疑問を持つかもしれません。「従来の opentelemetry0.7 (JSON) 形式も、Kinesis Data FirehoseでGZIP圧縮されて転送されているはずだ。それでも opentelemetry1.0 (Protobuf) にメリットはあるのか？」

この疑問は非常に的を射ています。結論から言えば、 GZIP圧縮を考慮した比較であっても、Protobuf（OTel 1.0）への移行メリットは依然として大きい のです。

なぜなら、鍵はデータ構造自体の「 冗長性 」にあるからです。

GZIPは、ペイロード内に 繰り返し出現する文字列 を検知し、効率的に圧縮（辞書化）します。従来の OTel 0.7 (JSON) 形式は、構造を定義するために多くの「キー名（テキスト）」をデータ自体に含んでいます。

概念的なJSONペイロード（OTel 0.7）のイメージ:

{
  "resourceMetrics": [
    {
      "scopeMetrics": [
        {
          "metrics": [
            {
              "name": "MyMetric",
              "summary": {
                "dataPoints": [
                  {
                    "attributes": [
                      { "key": "attrKey1", "value": { "stringValue": "attrValue1" } },
                      { "key": "attrKey2", "value": { "intValue": 123 } }
                    ]
                    /* ... 他のデータ ... */
                  }
                ]
              }
            }
          ]
        }
      ]
    }
  ]
}

ご覧のように、"resourceMetrics"、"scopeMetrics"、"key"、"stringValue" といった キー名自体がペイロードの大部分を占めます 。GZIPはこれら繰り返されるキー名を圧縮しますが、それでも元のデータの多くが構造定義（キー名）に使われている事実に変わりはありません。

一方、OTel 1.0 (Protobuf) はバイナリ形式です。 Protobufは、あらかじめ定義されたスキーマに基づき、JSONのようなテキストの「キー名」を使いません。代わりに、 フィールド番号（例: 7）とワイヤタイプを示すタグ（バイナリ）を使います。

概念的なProtobufペイロード（OTel 1.0）のイメージ:

/* (これは実際のバイナリではなく、構造のイメージです) */
/* resourceMetrics (フィールド番号 1) */
  /* scopeMetrics (フィールド番号 2) */
    /* metrics (フィールド番号 1) */
      /* name (フィールド番号 1): "MyMetric" */
      /* summary (フィールド番号 9) */
        /* dataPoints (フィールド番号 1) */
          /* attributes (フィールド番号 7) */
            /* key (フィールド番号 1): "attrKey1" */
            /* value (フィールド番号 2) */
              /* stringValue (フィールド番号 7): "attrValue1" */
          /* attributes (フィールド番号 7) */
            /* key (フィールド番号 1): "attrKey2" */
            /* value (フィールド番号 2) */
              /* intValue (フィールド番号 5): 123 */

Protobufは、"stringValue" という11バイトのキー名の代わりに、わずか1バイト程度のタグ情報で「これはフィールド番号7（stringValue）である」と表現します。

つまり、 Protobufは圧縮する以前の段階で、すでにJSONよりもはるかにデータ密度が高い（冗長性が排除されている） 形式なのです。

したがって、「GZIP圧縮されたJSON」と「GZIP圧縮されたProtobuf」を比較した場合でも、元のデータ密度が高いProtobuf側が、最終的により小さなデータサイズとなります。これは、AWSからのデータ転送量（Egressコスト）の削減と、New Relic側でのデータ処理（デコード）負荷の低減の両方に寄与します。

4. まとめ：New RelicとOpenTelemetryによる、継続的なオブザーバビリティの最適化

New Relicは、OpenTelemetryというオープンスタンダードな技術の採用と発展に強くコミットしています。

今回の OpenTelemetry 1.0 形式への対応は、そのコミットメントの一環であり、お客様がAWS環境のオブザーバビリティを、より低コストかつ高効率で実現するための重要な機能強化です。

ぜひこの機会に、CloudWatch Metric Streamsの設定を見直し、より効率的なデータ連携へのアップデートをご検討ください。

5. 【コラム】CloudWatch Metric Streamsの出力形式（OTel 0.7 vs 1.0）ペイロードサイズ簡易検証ガイド

記事本文で解説した OTel 0.7 (JSON) と OTel 1.0 (Protobuf) のGZIP圧縮後のデータサイズ差について、実際の環境で簡易的に検証する手順をご紹介します。

この検証では、New Relicのエンドポイントの代わりに、 S3バケット をデータ（GZIP圧縮ファイル）の出力先として使用します。

検証の前提条件

AWSアカウントおよび適切なIAM権限（CloudWatch, Kinesis Firehose, S3の作成・編集権限）
メトリクスを生成しているAWSリソース（例: EC2, Lambdaなど）

検証手順

公平性を期すため、 同一のメトリクスソース （include_filter で同一の名前空間を指定）から、 2つの異なる形式 で出力するストリームを並行稼働させ、S3に保存されるファイルサイズを比較します。

ステップ1: S3バケットの準備

検証データを保存するためのS3バケットを1つ準備します。（例: my-metric-stream-benchmark）

ステップ2: Firehoseの作成 (OTel 0.7用)

Kinesis Data Firehose コンソールで配信ストリームを新規作成します。
ソース: 「Direct PUT」を選択します。
送信先: 「Amazon S3」を選択します。
配信ストリーム名: 例: benchmark-firehose-otel07
S3送信先:
- S3バケット: ステップ1で作成したバケットを選択します。
- S3プレフィックス: otel07/ （区別のため）
- 重要: 「S3圧縮」が GZIP に設定されていることを確認します。（これがデフォルトです）
他はデフォルト設定で作成します。

ステップ3: Firehoseの作成 (OTel 1.0用)

ステップ2と同様の手順で、もう一つの配信ストリームを作成します。
配信ストリーム名: 例: benchmark-firehose-otel10
S3送信先:
- S3バケット: ステップ1で作成したバケットを選択します。
- S3プレフィックス: otel10/
- 重要: 「S3圧縮」が GZIP に設定されていることを確認します。
他はデフォルト設定で作成します。

ステップ4: Metric Streamの作成 (2種類)

CloudWatch コンソールの「ストリーム」で、「メトリックストリームの作成」をクリックします。
ストリームA (OTel 0.7用):
- 「メトリクスを選択」で、比較対象とする名前空間（例: AWS/EC2, AWS/Lambda）を選択します。
- 「設定」: 「既存のFirehose配信ストリームを選択します」を選び、ステップ2で作成した benchmark-firehose-otel07 を指定します。
- 「出力形式」: OpenTelemetry 0.7 を選択します。
- 名前: 例: benchmark-stream-otel07
- ストリームを作成します。
ストリームB (OTel 1.0用):
- 重要: ストリームAと 完全に同一の 名前空間を選択します。
- 「設定」: ステップ3で作成した benchmark-firehose-otel10 を指定します。
- 「出力形式」: OpenTelemetry 1.0 を選択します。
- 名前: 例: benchmark-stream-otel10
- ストリームを作成します。

ステップ5: データ収集と結果の比較

2つのストリームを稼働させ、S3バケットにデータが蓄積されるのを待ちます（例: 1時間〜数時間）。
AWS CLIやS3コンソールを使用し、同一期間（例: 特定の1時間分）に蓄積されたオブジェクトの合計サイズを比較します。

AWS CLIでの合計サイズ確認例:

# OTel 0.7 の特定の1時間分の合計サイズを取得 (例: 10時台)
aws s3 ls --summarize --recursive s3://my-metric-stream-benchmark/otel07/2025/10/27/10/

# OTel 1.0 の同じ1時間分の合計サイズを取得 (例: 10時台)
aws s3 ls --summarize --recursive s3://my-metric-stream-benchmark/otel10/2025/10/27/10/

Total Size: として表示される値を比較することで、OTel 1.0 (Protobuf) 形式がいかにGZIP圧縮後も効率的であるかを確認できるはずです。

By 伊藤覚宏, LeadTechnicalSupportEngineer

New Relic株式会社　リードテクニカルサポートエンジニア OSSの運用監視ソフトウェアの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経て現職。テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。

本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。

780+ インテグレーションを導入し、スタック監視を無料で開始しましょう

詳細を見る

In this article