IPU (Informatica Processing Unit) 周りの IDMC (Intelligent Data Management Cloud)の進化

こんにちはMitzです。この記事は インフォマティカ Advent Calendar 2023 Day 10 の記事として書かれています。今日はコネクタネタを封印して、この1年でのIPU (Informatica Processing Unit) 周りの IDMC (Intelligent Data Management Cloud)の進化について語ります。

PODとリージョン

2023年は春先にEMSE1, APNE2、そして秋にUSE7と合計3つ（赤字）のPOD(Point of Delovery)が追加されたので、商用POD数は遂に20(APJ:5, EMEA:5, NA:11)を突破しました。

普段あまり気にしなくて良いのですが、ここで少しだけ、IDMCにおけるリージョンとPODの関係について解説します。端的に言えばPODより上位の単位がリージョンです。上図の通り、殆どの場合リージョンに存在するPODは一つです。今のところ、例外的にリージョンに複数PODが存在するのは、NAのAWSリージョンとNAのAzureリージョンで、NAのAWSリージョンには6つのPOD、そして、NAのAzureリージョンには2つのPODが存在します。では、リージョン数はいくつかというと16(APJ:5, EMEA:5, NA:6)です。

因みに、普段弊社メンバーがどちらを使って会話をする事が多いかというとリージョンです。ということで、必要な前置きが済んだので本題に入ります。

クロスリージョンでのIDMC利用

IPUベースのライセンスではクロスリージョン（複数リージョンを利用する形態）でのIDMC利用は簡単にできます。複雑な手続きやオプションの追加購入は必要ありません！要は契約開始時にどのリージョンにOrgを作成したのかに関わらず、どのリージョンにもOrgが追加作成・利用可能という事です。拡張イメージを仮想的なシナリオに沿って図で見ていきましょう。

グローバルでのIDMC活用拡大シナリオ（仮）

APNE1(Azure Japan)リージョンでIDMC利用開始

グローバルカンパニー A社はデータ連携基盤として、法的要件とネットワークのレイテンシーの観点でAPNE1(Azure Japan)リージョンを選択。本稼働後は国内のデータ連携基盤として徐々に適用範囲拡大中。

北米の現地法人向け専用環境としてUSE7(OCI NA)リージョンの利用追加

北米DWHの構築にあたりIDMCの利用可否について北米の現地法人からHQである日本のDX担当部門が相談を受ける。北米現地法人がOCI(Oracle Cloud Infrastructure)を非常に活用している現状と、運用の観点から独立性を担保したほうが適切と判断し、USE7(OCI NA)リージョンにOrgを追加作成。

国内のデータ連携基盤の可用性向上対策としてAPNE2(ASW Japan)の利用追加

APNE1(Azure Japan)で稼働しているデータ連携基盤のミッションクリティカル度合いが高まったため、スケジュールされたサービス利用不可時の状況に備え、本番環境のコールドスタンバイとしてAPNE2(AWS Japan)リージョンにOrgを追加作成。

残念ながら、2023年12月現在、リージョン間でのアクティブ-アクティブな構成を実現するサービスや機能は提供されていません。よって、本番環境のコールドスタンバイを稼働するには、恒常的なアセットの同期、IDMCの処理をキックするためにPODのホスト名やURL等の変更が必要になります。

IPU的運用コスト

IPUベースのライセンスでは、複雑な手続きやオプションの追加購入は不要で、多くの事がIPU消費で賄われます。Org(Organization、組織)もその一つです。契約開始時に作成したProduction Orgを除き、他はOrg一つ当たり6 IPUを毎月消費します。この仮想シナリオでは下図の水色の部分に含まれるProdcition Org以外の三つのSandbox Org、二つのAdditional Production Orgがそれぞれ6 IPUを毎月消費しますので、合計5 * 6 = 30 IPUを消費します。

IPUメータリングダッシュボードのクロスリージョン対応

これが一番伝えたかったことなのですが、2023年4月のメジャーリリースでIPUメータリングダッシュボードのクロスリージョン対応が実現しました。（※それ以前はIPU消費状況のレポートを個別に作成してお客様に提供していました。）この仮想シナリオの例で説明すると、APNE1に配置されたProduction OrgのJPN データ連携基盤 本番環境にログインすると、他リージョンのOrgを含む全てのOrgでのIPU消費状況が確認できます。

IPUメータリングダッシュボードのプレリリース環境での対応

突然出てきたプレリリース環境という言葉ですが、商用リージョンにIDMCのメジャーリリースが適用される前に動作検証をするためのOrg専用リージョンです。（※プレリリース環境参考情報へのリンクはNTTデータ様の記事をご参照ください。）

このプレリリース環境のOrgもやはり毎月6 IPUの消費で利用可能なのですが、2023年8月のスタンダードリリースでIPUメータリングダッシュボード対応が実現しました。

IPU消費未対応のサービス

Private Link

お客様が利用中のクラウドプラットフォームプロバイダー上の仮想ネットワークとIDMCのPOD間との通信をセキュアにするPrivate LinkがAPNE1(Azure Japan)でも、APNE2(AWS Japan)でも利用可能になっていますが、このPrivate Linkの利用には別途契約が必要です。（※Private Linkへの対応済サービスはProduct Availability Matrixで要確認）

Assurance Package

こちらはIDMCリリースによるインパクトを分析・レポートするサービスで、有効化されるとマイサービスから利用可能になりますが、別途契約が必要です。また、サービスが提供されているリージョンが少なく、残念ながらAPNE1(Azure Japan)でも、APNE2(AWS Japan)では未対応です。

MDM SaaS

こちらはご存じの方も増えてきているとは思いますが、念のため記載しておきます。MDM SaaSの利用には別途契約で、現在のところIPUの消費でMDM SaaSのサービス群を利用する事は出来ません。

CDIのIPU詳細レポートでプロジェクト別＆フォルダ別の集計が可能なりました

UIだとどうしても重くなってしまうので、必要に応じて各サービスの詳細レポートをダウンロードしてIPU消費の集計に活用いただいています。2023年10月のメジャーリリースで、CDIのIPU詳細レポートにプロジェクト名カラムとフォルダー名カラムが追加されました。

Data IntegrationメーターのIPU詳細レポート例

下図のレポートでは、Fカラムにプロジェクト名、Gカラムにフォルダー名が存在することがわかります。（※因みに10月リリース以前に実行されたタスクではこれら二つのカラムは空白になっています。）

あとは、プロジェクト名やフォルダー名でフィルターして、OカラムのMetered Valueを集計した値に0.16(2000時間未満での係数を採用)をかけ合わせると、CDIでのIPU消費が算出できるという訳です。

GCS_mtin プロジェクトのIPU消費

不要なカラムを非表示にして、GCS_mtin プロジェクトでフィルターしたところ、OカラムのMetered Valueは、1.540555 Compute Hoursでした。ですので、このプロジェクトでの消費IPUは、1.540555 * 0.16 = 0.2464888 IPU となります。

Testing_Chan フォルダーのIPU消費

GCS_mtin プロジェクトでのフィルターした結果をさらにTesting_Chan フォルダーところ、OカラムのMetered Valueは、1.475555 Compute Hoursでした。ですので、このプロジェクトでの消費IPUは、1.475555 * 0.16 = 0.2360888 IPU となります。

プロジェクト別＆フォルダ別の対応済IPUメーター

現在のところプロジェクト別＆フォルダ別にIPU消費が集計可能なメーターはこの二つのみです。

• Data Integration
• Advanced Pushdown Optimization (SQL ELT)

参考リンク

PAM for Informatica Intelligent Cloud Services (IICS)

おわりに

今年こそは2本にとどめるつもりだったのに結果的に3本書いてしまいました。発展途上な部分もまだまだありますが、少しずつ改善している事もあるなーとしみじみ実感しています。ということで、前半担当Mitzの今年の投稿はこれが最後（のはず）です、目を通していただいた皆様ありがとうございました。よいお年をお迎えください。（流石にまだ早いかwww）