編集

次の方法で共有

Azure に IBM Sterling Order Management をデプロイする

Azure Database for PostgreSQL
Azure Files
Azure Red Hat OpenShift
Azure Virtual Machines
Azure Virtual Network

このアーキテクチャは、Azure での Sterling Order Management Software (OMS) 環境の実装を示しています。 この記事では、Sterling OMS のインストール方法の詳細については説明しません。 インストール プロセスの詳細については、「Sterling Order Management Software のインストール」を参照してください。

Red Hat ロゴは Red Hat, Inc. の商標です。これらのマークを使用することが、保証を意味するものではありません。 Apache® および Apache ActiveMQ は、Apache Software Foundation の米国およびその他の国における登録商標または商標です。 これらのマークを使用することが、Apache Software Foundation による保証を意味するものではありません。

アーキテクチャ

Azure での Sterling OMS IBM 注文管理システムのデプロイメントをサポートするコンポーネントとサービスを示すアーキテクチャ ダイアグラム。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークロードは内向きまたは外向きにデプロイすることができます。 要件に最適な構成を使用してください。

ワークフロー

このアーキテクチャは、次の方法でインフラストラクチャの要件を満たします。

  • コンテナー ホスティング プラットフォームを使用して可用性ゾーン全体に高可用性ワークロードをデプロイします。 Azure Red Hat OpenShift をお勧めします。
  • フル マネージド データベース サービスが、OMS システムのバックエンド データベースとして機能します。 現在、Sterling OMS では IBM Db2、Oracle Database、PostgreSQL がサポートされています。 Azure Database for PostgreSQL をフレキシブル サーバー オプションで使用することをお勧めします。
  • スケーラブルで高可用性のセットアップにより、Java Message Service (JMS) API に準拠する IBM MQ などのメッセージ・ブローカーを実行するための環境を提供します。 この図には、このセットアップは含まれていません。 要件に応じて、クラスター内にある場合も、クラスターの外部にある場合もあります。
  • プライベート エンドポイントは、接続されているすべてのサービスへのネットワーク トラフィックを分離し、保護します。
  • 追加のオプションの Azure 仮想マシン (VM) は、管理と開発の目的で使用されます。
  • Premium と Standard の Azure Files 共有は、ログ ファイルやその他のアプリケーション構成データのストレージを提供します。

Components

  • Azure Red Hat OpenShift により、可用性の高いフル マネージド OpenShift クラスターがオンデマンドで提供されます。 これらのクラスターは、Microsoft と Red Hat によって共同で監視および運用されます。

  • Azure Virtual Network は、Azure 内のプライベート ネットワークの基本的な構成ブロックです。 ノード間の通信、Azure サービス、ハイブリッド接続のニーズに対して仮想ネットワークが使用されます。

  • Azure Files は、SMB および NFS プロトコルを介してアクセスできる、クラウドのフル マネージド ファイル共有を提供します。 このソリューションでは、Azure Files は、クラスター内にあるデータベースとシステムのステートフル データをホストします。

  • Azure Bastion は、パブリック IP アドレスを介した露出なしに、VM へのシームレスで強化されたセキュリティ RDP および SSH アクセスを提供する、完全に管理されたサービスです。 このソリューションでは、Azure Bastion は省略可能です。 Azure Bastion とサブネットを使用すると、任意のワーカー ノードまたはオプションのジャンプ ボックス マシンへのセキュリティが強化されたアクセスを提供できます。

  • Azure Database for PostgreSQL は、PostgreSQL データベース エンジンに基づいた、フル マネージド リレーショナル データベース サービスです。 Azure Database for PostgreSQL は、予測可能なパフォーマンスと動的なスケーラビリティを提供し、ビジネスクリティカルなワークロードに適しています。 そのフレキシブル サーバー デプロイ モデルでは、データベース管理機能と構成設定に対してきめ細かい制御と柔軟性が提供されます。

  • Azure Virtual Machines は サービスとしてのインフラストラクチャ (IaaS) オファーです。 Virtual Machines を使用して、オンデマンドのスケーラブルなコンピューティング リソースをデプロイできます。 このソリューションでは、Azure の Linux VM を使用して、OMS Azure ベースのリソースとサービスを管理するためのジャンプ ボックスを提供します。

代替

Azure 環境へのネットワーク接続がある場合は、Azure Linux VM を使用する代わりに、既存のマシンからインストールを実行できます。

通常、次のサービスは必要ありませんが、効果的な代替手段になります。

  • Azure 上の IBM Db2 は、Azure Database for PostgreSQL のフレキシブル サーバー モデルの代替となるオプションです。 VM で IBM Db2 を実行する場合は、データベース サーバーの高可用性を実現するために、Azure Load Balancer と Pacemaker クラスタリング ソフトウェアの使用の詳細を確認してください。
  • Azure NetApp Files は、高可用性とハイ パフォーマンスを提供することで、あらゆる種類のワークロードをサポートします。 Azure NetApp Files は、Azure VM 上で実行される IBM Db2 ワークロードなど、IO に依存するワークロードに最適です。
  • Azure 上の Oracle Database は、Azure Database for PostgreSQL のフレキシブル サーバー モデルの代替となるオプションです。

シナリオの詳細

IBM Sterling OMS は、完全なオムニチャネル注文フルフィルメント プラットフォームを提供する注文管理システムです。 このシステムには、次のような機能が用意されています。

  • リアルタイムの在庫の可視性と需要。
  • 詳細に構成可能な注文のオーケストレーションとワークフロー。
  • マルチチャネルの返品と返品注文ステータスの逆物流管理。

Microsoft と IBM Sterling OMS チームのパートナーシップにより、このソリューションは Azure で最適に実行されるように構成されます。 この記事では、IBM およびインストールのパートナーからのサポートを受けているお客様向けに、Azure で OMS 10.0 以降を実行するための設計を提供します。 製品固有の質問に対する回答については、IBM チームにお問い合わせください。

考えられるユース ケース

次のような多くの業界やセクターで、OMS ソリューションが使用されています。

  • 小売
  • E コマース
  • 製造

OMS のその他のユース ケースについては、「IBM Sterling Order Management」を参照してください。

Recommendations

このガイダンスでは、Sterling OMS 10.0 Q3 2022 以降のバージョンがサポートされています。 これらのバージョンは、PostgreSQL と Azure Red Hat OpenShift コンテナー プラットフォームをサポートしてるため、Azure と統合する最善のオプションです。 独自のデプロイを構築する前に、「クイックスタート ガイド: Azure 上の Sterling Order Management」を使用して、Sterling OMS をデプロイしてください。 その後、デプロイと構成のしくみを理解すると、実装の設計要件をより迅速に判断できます。

Microsoft では IBM や他のパートナーと密接に協力して、ガイダンス、アーキテクチャ、クイック スタート ガイドにより Azure で最高のエクスペリエンスを提供できるようにします。 これらのリソースは、Microsoft Azure Well-Architected Framework で説明されているベスト プラクティスに従っています。 このドキュメントを範囲を超えるサポートについては、IBM アカウント チームにお問い合わせください。

デプロイに進む前に、設計に関する次の質問に回答してください。

  • Sterling OMS のデプロイは新しいものですか、それとも既存のデプロイを Azure に移行していますか?
  • どのようなバックエンド データベース プラットフォームを使用する予定ですか? データにはどのサイズのデータベースが必要ですか?
  • どのタイプの JMS ベースのメッセージ・ブローカーを使用する予定ですか?
  • メッセージング システムをどこにデプロイする予定ですか。
    • 同じ OpenShift クラスター内ですか?
    • 別のプラットフォームまたは VM 上のクラスターの外部ですか?
  • 既存のコンテナー レジストリがあり、それを使用し続ける予定ですか?
  • ワーカー ノードに必要な VM の数とサイズはどれくらいですか?
  • 暗号化関連のセキュリティ要件は何がありますか?
  • アクセス要件は何ですか、また ID プロバイダー (IdP) 統合に関するどのような考慮事項がありますか?
  • 接続のニーズは何ですか。 内部および外部 (エグレス) サービスに接続するには、どのようなファイアウォール規則が必要ですか?
  • 高可用性とディザスター リカバリーの戦略は何ですか?

Sterling OMS

Sterling OMS バージョン 10.0.2209.0 が Azure でテストされています。 最新バージョンの Sterling OMS を使用することをお勧めします。

Sterling OMS 環境をサポートする Azure リソースをデプロイする前に、次の要件について確認してください。

  • Sterling OMS のシステム要件については、「システム要件」を参照してください。
  • Sterling OMS は、状態とデータ管理のためにリレーショナル データベース システムに依存しています。 サービス間通信と注文ワークフローのために、JMS 対応メッセージ ブローカー システムも必須です。 Sterling OMS では、環境内にデプロイできる複数のデータベースおよびメッセージ ブローカーのオプションがサポートされています。 詳細については、次のリソースを参照してください。

Azure Red Hat OpenShift

Sterling OMS は、Azure Red Hat OpenShift バージョン 4.10.15 でテストされています。 Azure Red Hat OpenShift をデプロイする前に、以下が必要です。

  • ドメインを決定します。 Azure Red Hat OpenShift をデプロイするときに、クラスターにデプロイされるすべてのサービスに追加されるドメイン名を指定します。
  • API とイングレスの可視性を決定します。 OpenShift クラスター API (管理用) とイングレス (デプロイされたアプリケーションとサービス用) をインターネットに接続する方法を決定します。 プライベート接続を使用して API またはイングレスを非公開にする場合、サービスをデプロイするネットワークに到達できるマシンからのみ、これらのエンドポイントに到達できます。
  • コントロール VM とワーカー VM のサイズと数を計算します。 Azure Red Hat OpenShift では、コントロール数は固定数であり、最小推奨サイズがあります。 Sterling OMS などのアプリケーション ワークロードを実行するワーカー ノードは、個別にサイズ設定されます。 インスタンスをデプロイするときは、クラスター内に必要なワーカー ノードの数と、それぞれの適切なサイズを考慮してください。 適切な数とサイズを判断するために、何らかのテストと検証が必要になる場合があります。 これらの値は、デプロイ内のエージェントの数と、実行するエージェントの種類ごとにポッドの数によって異なります。 デプロイ後、スケーリングする必要があるときにこれらの値を調整できます。

詳細については、Azure Red Hat OpenShift の「開始する前に」を参照してください。

環境のサイズを見積もる

最新の Ds シリーズ VM をワーカー ノードとして使用することをお勧めします。 たとえば、Dsv3、Dasv4、Dsv4、Dasv5、Dsv5 シリーズなどです。 これらの VM の最新バージョンは、最高のパフォーマンスを提供します。 より多くのノードをデプロイする場合は、Premium Storage を持つ VM のみを使用してください。

データベースの詳細

Sterling OMS にはさまざまなバックエンド データベース オプションがあるため、まずデータベースをホストするプラットフォームを決定することが重要です。 その後、そのプラットフォームのサイズに関する決定を行うことができます。 このプロセスでは、次の一般的なガイドラインに注意してください。

  • Azure Database for PostgreSQL、フレキシブル サーバー デプロイ モデル: スケールと冗長性のオプションの性質上、Azure で Sterling OMS ワークロードをホストする場合は、Azure Database for PostgreSQL のフレキシブル サーバー モデルが推奨される方法です。 インスタンスをデプロイするときに、以下のようにします。
    • 使用パターンに一致するコンピューティング レベルを選択します。 汎用レベルから開始し、適切な数のコアを選択することをお勧めします。 また、CPU、メモリ、IOPS はコンピューティング サイズの選択に関連付けられていることに注意してください。
    • 適切なストレージを追加します。 また、ストレージの増加によってコストが増加し、プロビジョニングされたストレージを縮小できないことにも注意してください。 そのため、最初のデータ サイズと予測される増加を把握することが重要です。
    • データベースへの接続を維持するエージェントの機能に影響を与える、max_connections などのサーバー パラメーターを調整します。
  • VM 上の Db2: Azure VM で Db2 を実行する場合、パフォーマンスや可用性など、対処する必要がある複雑な要素がいくつかあります。 Azure での高パフォーマンス Db2 デプロイの詳細な記事については、「Red Hat Enterprise Linux Server 上の Azure VM での IBM Db2 LUW の高可用性」を参照してください。 この記事では、サイズ設定とパフォーマンスに関する考慮事項について説明しています。 また、Pacemaker を使用する高可用性 Db2 クラスターをデプロイする方法についても説明します。
  • Oracle: 現在 Oracle Database を使用している場合、または Oracle に移行する予定の場合は、Azure で Oracle ワークロードを実行するために次のリソースについて確認してください。

メッセージ キューの詳細

Sterling OMS には、JMS ベースのメッセージ ブローカーが必要です。 最も一般的には、IBM MQ が使用されます。 Azure で高可用性 IBM MQ インスタンスを実行する最善の方法は、Ibm MQ Helm Charts for Kubernetes のデプロイを使用することです。 これらの既存の Azure Red Hat OpenShift クラスター内の chart を個別のワーカーにデプロイして、ワークロードを分離できます。 必要に応じて、IBM MQ を VM に手動でデプロイしてインストールすることもできます。

標準デプロイの一環として、デプロイ時にキューを定義できます。これにより、インスタンスのスピンアップに必要な構成時間が短縮されます。 標準デプロイでは、キュー・マネージャーのアクティブ・インスタンスが 1 つとパッシブ・インスタンスが 2 つ作成されます。 デプロイが完了したら、SSH を使用して現在のリーダー ポッドに接続し、JMS バインド ファイルを定義できます。 その後、そのファイルを使用して、Sterling OMS デプロイ用の構成マップを作成できます。

IBM では、Apache ActiveMQ などの他の JMS ベースのメッセージ キュー システムもサポートしています。 詳細については、「Sterling Order Management Software のメッセージ キュー」を参照してください。 デプロイのオプションはソリューションごとに異なります。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

資産メンテナンスのライフサイクルへのアクセスと可視性の維持は、組織が効率的に運用し、アップタイムを維持できる最大の機会の 1 つです。 環境のセキュリティ態勢を強化するには、セキュリティで保護された認証を使用し、ソリューションを最新の状態に保つことが重要です。 暗号化を使用して、アーキテクチャとの間でやり取りされるすべてのデータを保護します。

Azure では、IaaS とサービスとしてのプラットフォーム (PaaS) のモデルを使用して、Sterling OMS を提供しています。 Microsoft は、次のレベルでセキュリティ保護をサービスに構築します。

  • 物理データセンター
  • 物理ネットワーク
  • 物理ホスト
  • ハイパーバイザー

メジャー リリースの Azure Red Hat OpenShift の最新の修正プログラムが適用されたバージョンなど、ハイパーバイザーの上の領域に対して選択するサービスとテクノロジを慎重に評価してください。 アーキテクチャに適切なセキュリティ コントロールを提供するようにしてください。 IaaS システムのセキュリティにパッチを適用して維持する責任があります。 Azure Red Hat OpenShift などの PaaS サービスについては、Microsoft がその役割を果たします。 Azure Red Hat OpenShift のアップグレードを開始することはできますが、これは Microsoft と Red Hat によるフル マネージドです。 Azure Red Hat OpenShift の修正プログラムの適用とアップグレードの詳細については、「Azure Red Hat OpenShift クラスターをアップグレードする」を参照してください。

ネットワーク セキュリティ グループを使用すると、仮想ネットワーク内のリソースとの間のネットワーク トラフィックをフィルター処理できます。 これらのグループを使用して、Sterling OMS のサービスへのアクセスを許可または拒否するルールを定義できます。 たとえば、次のようになります。

  • メッセージ ブローカーまたはバックエンド データベースが使用する特定のポートやサービスなど、デプロイされたインフラストラクチャの他のすべての部分へのアクセスをブロックする。
  • Sterling OMS と OpenShift クラスターにアクセスできる場所を制御する。

開く必要があるポート番号と範囲は、多くの要因によって異なります。 考慮すべき対象の一部は次のとおりです。

  • サービス間通信用のポート 443。
  • Azure Database for PostgreSQL のフレキシブル サーバー オプションとしてポート 5432 など、データベース固有のポート。
  • IBM MQ のポート 1414 などのメッセージ・キューのポート。

次の点も考慮します。

  • Azure Red Hat OpenShift のクラスター ノードには、送信インターネット アクセスが必要です。 このアクセスを提供できない場合、これらのノードは、少なくとも Azure Resource Manager とサービス ログ エンドポイントにアクセスできる必要があります。
  • IBM は、バックエンド・データベースなどの共通サービスを共有する複数の Sterling OMS アプリケーションを実装するためのガイダンスを提供しています。 このようなデプロイには、アプリケーション間のファイアウォールに関する考慮事項もあります。 詳細については、「アプリ間通信用のファイアウォール ポートを開く」を参照してください。

Azure Red Hat OpenShift 以外の他のノードにアクセスする必要がある場合は、必要に応じて Azure Bastion を使用して VM にアクセスできます。 セキュリティ上の理由から、VM へのアクセスを制御するネットワーク セキュリティ グループを構成せずに、VM をネットワークまたはインターネットに公開しないでください。

Azure ディスク ストレージのサーバー側暗号化 (SSE) は、データの保護に役立ちます。 SSE はまた、組織のセキュリティとコンプライアンスのコミットメントを満たすのにも役立ちます。 Azure マネージド ディスクでは、SSE はデータをクラウドに永続化するときに、保存データを暗号化します。 この動作は、既定で OS とデータ ディスクの両方に適用されます。 OpenShift では、既定で SSE が使用されます。 Azure Red Hat OpenShift では、クラスター内の OS ディスクに対するカスタマー マネージド暗号化キー (CMEK) もサポートされています。

認証

Azure Red Hat OpenShift のために OAuth を構成する必要があります。 詳細については、Azure Red Hat OpenShift ドキュメントの認証と認可の概要に関する記事を参照してください。

インフラストラクチャを保護する

デプロイする Azure リソースへのアクセスを制御します。 Azure のすべてのサブスクリプションは、Microsoft Entra テナントとの間に信頼関係があります。 Azure ロールベースのアクセス制御 を使用して、組織内のユーザーに Azure リソースに対する適切なアクセス許可を付与します。 特定のスコープでユーザーまたはグループに Azure のロールを割り当てて、アクセス権を付与します。 スコープには、サブスクリプション、リソース グループ、または 1 つのリソースを指定できます。 インフラストラクチャに対するすべての変更を必ず監査してください。 監査の詳細については、「Azure Monitor アクティビティ ログ」を参照してください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

Sterling OMS の標準的なデプロイは、次のコンポーネントで構成されます。 これらのコンピューティングベースのリソースの多くは、ニーズに合わせて調整できます。 たとえば、IBM MQ エージェント・ノードをスケールアップして、スループットを向上させることができます。

Azure Red Hat OpenShift (OMS 用)

  • 3 つの制御 VM (Standard_D8s_v5)
  • 3 つの worker VM (Standard_D8s_v5)

その他のリソース

  • 1 つの仮想ネットワーク (/16)、次のサブネットを検討。
    • Azure Red Hat OpenShift コントロール ノード サブネット (/24)
    • Azure Red Hat OpenShift ワーカー ノード サブネット (/24)
    • 必要に応じてデータ サブネット (/27)
    • 必要に応じて追加の VM サブネット (/27)
    • 必要に応じて管理サブネット (/30)
  • フレキシブル サーバー オプションを使用する Azure Database for PostgreSQL のインスタンス 1 つ
  • Azure Container Registry のインスタンス 1 つ
  • 2 つの Azure Storage アカウント
  • 3 つの DNS ゾーン
  • 2 つのロード バランサー
  • 1 つのジャンプ ボックス VM
  • Azure Bastion

Azure VM で Db2 を実行する場合や、Azure Red Hat OpenShift 環境に IBM MQ をデプロイする場合など、個々のデプロイは異なる場合があります。 見積もりの例を確認するには、コスト計算ツールを使用します。 構成はさまざまなため、デプロイを最終決定する前に、IBM のサイズ設定チームに構成を確認してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

Azure Red Hat OpenShift には、自己復旧、スケーリング、回復性のための組み込みの機能があり、Azure Red Hat OpenShift と Sterling OMS が正常に動作するようにします。 Azure Red Hat OpenShift と Sterling OMS は、障害が発生して回復するパーツ用に設計されています。 自己復旧のための重要な要件は、十分なワーカー ノードがあることです。 Azure リージョン内のゾーン障害から復旧するには、可用性ゾーン間で制御ノードとワーカー ノードのバランスを取る必要があります。

Sterling OMS と Azure Red Hat OpenShift では、データベース ストレージを使用して、Kubernetes クラスターの外部に状態を保持します。 ログとその他のアプリケーション リソースは、ストレージ アカウントに保持されます。 障害発生時にストレージの依存関係が引き続き機能するようにするために、可能な場合は必ずゾーン冗長ストレージを使用してください。 この種類のストレージは、ゾーンで障害が発生しても引き続き使用できます。 また、データベースのデプロイでも、マルチゾーン構成を考慮する必要があります。

人的エラーは一般的に起こるため、できるだけ多く自動化を使用して Sterling OMS をデプロイしてください、。 完全なエンドツーエンドの自動化を設定するためのサンプル スクリプトについては、GitHub の「クイックスタート ガイド: Azure 上の Sterling Order Management」を参照してください。

このシナリオのデプロイ

開始する前に、「システム要件」で Sterling OMS の 要件を確認してください。 また、次のリソースが用意されていることを確認してください。

  • "閲覧者" のアクセス許可による Azure サブスクリプションへのアクセス。
  • サブスクリプションに対する "共同作成者" および "ユーザー アクセス管理者" のアクセス許可を持つ、アプリケーションの登録またはサービス プリンシパル名。
  • Azure DNS ゾーンへのドメインまたは委任されたサブドメイン。
  • IBM Sterling OMS のエンタイトルメント キー。
  • IBM 推奨のクラスター サイズ設定。
  • 要件に応じて、既存の仮想ネットワークまたは新しい仮想ネットワーク。 2 つの空のサブネットを持つ新しい仮想ネットワークを作成する例については、「チュートリアル: Azure Red Hat OpenShift 4 クラスターを作成する」を参照してください。
  • 具体的なデプロイに対する高可用性とディザスター リカバリーの要件。
  • OpenShift Operator カタログを介して Sterling OMS をデプロイするときに使用する OMEnviroment 構成ファイル omenvironment.yaml。

前提条件に対処する方法など、Azure に Azure Red Hat OpenShift と Sterling OMS をインストールするための詳細なガイドについては、「クイックスタート ガイド: Azure 上の Sterling Order Management」を参照してください。

デプロイに関する考慮事項

手動でデプロイすると間違って構成する可能性があるため、ワークロードを手動でデプロイするのではなく、コードとしてのインフラストラクチャ (IaC) を使用してワークロードをデプロイすることが現在のベスト プラクティスです。 コンテナーベースのワークロードは、構成ミスに対してセンシティブであり、生産性が低下する可能性があります。

環境を構築する前に、「クイックスタート ガイド: Azure 上の Sterling Order Management」を参照して、設計パラメーターの理解を深めてください。 クイック スタート ガイドは、運用環境に対応したデプロイを目的としたものではありませんが、ガイドの資産を使用して、デプロイ用の運用グレードのメカニズムにアクセスできます。

IBM では、インストールを支援する専門サービスを提供しています。 サポートについては、IBM チームにお問い合わせください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

  • Aneesh AR | シニア Cloud Services ブラック ベルト
  • Vijaya Bashyam | シニア テクニカル スタッフ メンバー
  • James Read | EMEA プリンシパル ソリューション アーキテクト
  • Andy Repton | Managed OpenShift ブラック ベルト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ