OpenTelemetry とメインフレーム

メインフレームは、銀行、保険、政府機関、小売、航空業界を中心に、世界で最も重要なワークロードの大部分を引き続き処理しています。

メインフレームは多くの場合、ハイブリッドアーキテクチャの中核に位置し、Web やモバイルのフロントエンド、マイクロサービス、クラウドプラットフォームのすべてがメインフレームの基幹システムに依存しています。

このセクションでは、メインフレームが OpenTelemetry ベースのオブザーバビリティ戦略にどのように適合するかを説明し、既存のテレメトリーパイプラインとの統合に関するガイダンスを紹介します。

対象読者

このコンテンツは、次のような方を対象としています。

• 主に分散/クラウドネイティブ環境（Kubernetes、VM、サーバーレスなど）で作業している方。
• メインフレームとは何か、なぜ重要なのか、メインフレームのワークロードをエンドツーエンドのオブザーバビリティにどう組み込むかを理解する必要がある方。

前提条件

メインフレームの事前経験は不要であり、このセクションの内容を活用するために COBOL や z/OS の専門家である必要もありません。 ただし、トレース、メトリクス、ログ、OTLP、Collector など、OpenTelemetry の概念に精通していることが前提です。

メインフレームとは

メインフレームとは、最高レベルのセキュリティと信頼性で毎日数十億件のトランザクションを処理するように設計されたデータサーバーです。 詳細な概要については、What is a mainframe? を参照してください。

メインフレームの例として、以下をホストする IBM Z システムがあります。

• トランザクション処理（例: CICS®、IMS™、および類似のサブシステム）
• バッチ処理（JCL 駆動のジョブ、スケジューラー）
• 高価値な基幹データベース（「信頼できる唯一の情報源」であるデータベースやファイル）

ベンダーや製品によって詳細は異なりますが、ほとんどのメインフレーム環境はオブザーバビリティに影響を与える共通の特性を備えています。

• 非常に高いスループットと厳格なレイテンシー/可用性の要件
• 長期にわたるアプリケーションとデータフォーマット
• 厳格なセキュリティおよびコンプライアンスの制約

メインフレームが OpenTelemetry アーキテクチャにどう位置付けられるか

OpenTelemetry の観点から見ると、メインフレームは通常、より大きなハイブリッドシステムの一部です。

• フロントエンドと API は、ブラウザ、モバイルアプリ、または API ゲートウェイで動作します。
• マイクロサービスとミドルウェアは、コンテナ、VM、またはマネージドクラウドサービスで動作します。
• コアビジネスロジックとデータはメインフレーム上に存在し、MQ、HTTP(S)、gRPC、メッセージバス、または独自プロトコルを介してアクセスされます。

典型的なアーキテクチャでは、テレメトリーの流れは次のようになります。

• 分散サービスが OpenTelemetry SDK と Collector を介してトレース、メトリクス、ログを送信する。
• 統合層（API ゲートウェイ、ESB、MQ ブリッジ、データストリーミングプラットフォーム）がクラウドのリクエストとメインフレームのアクティビティを関連付けるインターセプションポイントとして機能する。
• メインフレーム常駐コンポーネントがイベント、SMF レコード、ログ、トレーススパン、またはメトリクスを生成し、OpenTelemetry 形式に変換またはエクスポートする必要がある（多くの場合、プラットフォーム外で動作する Collector またはゲートウェイを介して行われる）。

このセクションの目標は、メインフレームと非メインフレームのシステム全体にわたる単一の一貫した全体像を把握できるよう、これらの点をつなぐことです。

メインフレームの違い

OpenTelemetry をメインフレームのコンテキストで利用する際、多くの場合以下のような点に遭遇します。

• 異なるメンタルモデル
  • ホスト、Pod、サービスのかわりに、LPAR、アドレス空間、ジョブ
  • オブジェクトストレージバケットのかわりに、データセットや VSAM ファイル
• 既存のテレメトリーとフォーマット
  • System Management Facilities（SMF）レコード
  • SYSLOG
  • LOGREC
  • サブシステムログ
  • ジョブログ
  • パフォーマンスモニター
  • これらのソースは、OpenTelemetry で定義されたトレース、メトリクス、ログに解析・マッピングする必要があることが多い
• アクセスと変更の制約
  • 本番メインフレームには、厳格な変更管理とアプリケーションコードの変更が制限されていることが多い。
• スケールと信頼性への期待
  • テレメトリーソリューションは、SLA に影響を与えることなく非常に高いトランザクションレートに対応する必要がある。
  • データパイプラインは、規制要件を満たすのに十分なロバスト性とセキュリティを備えている必要がある。

これらの特性は OpenTelemetry の利用を妨げるものではありませんが、テレメトリーをどこで、どのように収集、変換、エクスポートするかに影響を与えます。

OpenTelemetry がどう役立つか

OpenTelemetry は、メインフレーム環境に適用できる以下のような構成要素を提供します。

• トレース、メトリクス、ログのためのベンダー中立のデータモデル
• 標準的で相互運用可能なトランスポートプロトコルとしての OTLP
• OpenTelemetry Collector は以下のことが可能です
  • 複数のプロトコルやフォーマットからデータを取り込む
  • データを変換・エンリッチする
  • 変換されたデータを任意のオブザーバビリティバックエンドにエクスポートする

メインフレームのコンテキストでは、Collector は多くの場合プラットフォーム外（たとえば Linux サーバーやコンテナ上）で動作し、以下の間のブリッジとして機能します。

• メインフレーム固有のテレメトリーソース、および
• エンタープライズオブザーバビリティバックエンド（メトリクス/ログプラットフォーム、トレーシングバックエンド、APM ツール、SIEM、データレイク）

現在のステータス

メインフレーム環境向けの基盤となる OpenTelemetry 計装が利用可能であり、プラットフォームサポートは拡大を続けています。

歴史的に、メインフレームの計装のほとんどはベンダー提供でした。 多くのオブザーバビリティバックエンドベンダーが、独自のエクステンションやエージェントを提供し、メインフレームのテレメトリーをパッケージ化してバックエンドに送信しています。

ベンダー中立のテレメトリーに対する顧客の需要に応じて、最も広く使用されているメインフレームシステムのオペレーティングシステムとサブシステムソフトウェアを提供する IBM や、多くの独立系メインフレームソフトウェアベンダー（ISV）が、自社製品にネイティブの OpenTelemetry サポートを追加しています。

この移行は共通の用語とセマンティクスに依存しており、次のセクションで説明するワーキンググループがその定義を支援しています。

ワーキンググループとコミュニティ

OpenTelemetry on Mainframes Special Interest Group（SIG） は、現在以下に重点を置いています。

• 共通の用語とユースケースの定義
• メインフレームのユースケースに関連する仕様（OpenTelemetry セマンティック規約）、SDK、Collector コンポーネントのギャップの特定

この SIG には現在、IBM、Broadcom およびその他の ISV、オブザーバビリティバックエンドベンダー、および一部の顧客が参加しています。 ぜひご参加ください！

コントリビュートに興味がある方は、OpenTelemetry のリポジトリとウェブサイトで Community と SIG 情報をご覧ください。 ミーティングスケジュール、ミーティング議事録、およびコミュニケーションチャンネル（#otel-mainframes）もご確認ください。