データ連携をサーバーレスで実現｜オンプレSAPからAzureへ

記事をシェアする:

昨今オンプレミスのデータセンターからクラウドへのデータ連携を実施しているケースは数多くありますが、それに応じてデータ連携に特化した優れたソフトウェア・ツールの選択肢も増えており、どのように実現するべきか？という課題解決の参考になれば幸いです。本事例では、オンプレのSAPデータをクラウド（Microsoft Azure）へデータ連携するために、Azure Batch（IBM外のWebサイトへ）サービスを利用することで目的を実現しています。

System Architecture Design

今回の事例では、グローバルで利用されているSAPのデータを、Blue Yonder（IBM外のWebサイトへ） のDemand 360（以降：D360) へ、様々な要件を満たしデータを連携する必要がありました。
要件の一部を参考として記載しておきます。

• 将来EDIの導入を考慮し、複雑なETL（Extract Transform Load）処理をデータ連携基盤（以降：IF基盤）に実装せずシンプルな処理（join, convert, calculation, format check）を実装すること。
• グローバルのタイムゾーンを考慮し、ジョブのスケジューリングが可能なこと。
• VPNや専用線は利用せず、インターネットでセキュアなデータ連携を実施すること。
• IF基盤の非機能要件を満たし、かつコスト最適化及び運用保守の優位性を考慮し、クラウドの標準サービスを利用したアーキテクチャーで実現すること。
• 連携先システム（D360）は、Microsoft Azureのサービスとして提供されているため、IF基盤もAzureを前提として検討すること。

アーキテクチャーの全体像（一部コンポーネント省略）は、以下のようになります。

アーキテクチャー決定のポイント（一部）
各ナンバー1〜7は、アーキテクチャー全体像のArchitecture Decision Numberのコンポーネントを採用するためのポイントとなります。

1. データ連携はバッチ処理のため、仮想マシン（以降：VM）を複数年リザーブドで利用するか、サーバーレスによる実行時間での利用とのコスト面での比較検討を実施しました。
2. 今後、複数のバッチ処理が並列実行される可能性を考慮した拡張性やVMを利用する場合のセキュリティー対策として、マルウェア対策のソフトウェア導入など、様々な非機能要件を考慮した比較検討を実施しました。
3. バッチ処理のジョブ実行に必要な要件が少なく複雑なジョブ実行条件もないため、ジョブ管理ツールを導入するか、Azure BatchのJob Schedulerの標準機能で実現可否の検討を実施しました。
4. 各Region側にSFTPサーバーを構築し、バッチ処理のトリガーはAzure側で制御することで、Region側ではデータ連携の対象データをSFTPサーバーにUploadするだけでよく、Business user への負担を軽減できるよう検討を実施しました。また、D360には標準機能としてSFTPサーバーが準備されており、データ連携に利用する通信はSFTPプロトコルで統一しました。
5. サーバーレスのAzure batchサービスをプライベートなネットワークで利用することで、セキュリティーを確保し、外部通信はNAT GatewayやNetwork Security Group（以降：NSG）で実現することを検討しました。
6. アプリケーションは、実行環境やライブラリの依存関係を管理することなく利用できるように、コンテナー化（IBM外のWebサイトへ）することを検討しました。コンテナー・イメージの保存先として、脆弱性のスキャンも可能なAzure Container Registry（以下：ACR）を利用することを検討しました。また、アプリケーションのデータ管理はAzure Blob Storageを利用しています。
7. IF基盤における監視機能は、Azure Monitorの標準機能を利用し、アプリケーションのログもLog Analytics Workspaceに集約することで、Azure Monitorのメール通知機能を利用することを検討しました。

ETL Application Design

アプリケーション開発においては、Visual Studio Code（以下：VS Code）に拡張機能（Azure Account, Azure Tools）を追加し、VS Codeで開発したアプリケーションをDocker Desktopでビルドして、コンテナーイメージを作成し、ACRへデプロイしています。
余談になりますが、2021年からDocker Desktopが有償化され、困惑された方々も多いかと思います。OSSを利用する上での懸念事項の１つとして考慮しておく必要があると考えています。

この事例におけるETL処理フローは、以下のようになります。

ETL処理をAzure Batchで実行するために、batch shipyard（IBM外のWebサイトへ）を利用しました。Batch Shipyardは、Azure Batchでのコンテナベースのバッチ処理におけるワークロードのプロビジョニング、実行、および監視を支援するツールとなります。今回の事例では、Batch Shipyardの標準テンプレート（IBM外のWebサイトへ）を使用して、ジョブの展開およびスケジュールを実施しました。
標準テンプレートにおける設定ファイルのカスタマイズ対象は、青枠部分になります。

事例のETLアプリケーションでは、高度なジョブ管理が必要ではありませんでしたが、エラー時のジョブの再実行は、運用で回避する方針としています。１つ方法を記載すると、Azure PortalからCloud Shellを起動し、ジョブを実行するコマンドを記載したShellファイルを保存したBlob Storageをマウントして、Cloud Shellからジョブを再実行する方法も考えられます。より高度なジョブ管理が必要な場合、例えば複数ジョブが正常終了した場合に、次のジョブを実行する要件がある場合には、ジョブのステータス情報を別途管理して、Azure Function等でジョブのステータスを確認した上で、Azure Batchのジョブを起動するなど、工夫が必要になるかと思います。そのため、再度ジョブ管理ツールを導入するべきか検討することをお勧めします。

Operational Design

運用保守については、この事例で固有の考え方というのは存在せず、一般的なシステム開発において運用保守を実施する方法について検討しました。
運用体制を明確化し、定型運用作業フローを検討し、実施する手順を整理しています。非定型作業においては、エラーの内容に対応した作業フローを検討し、そのフローを実現する手段としてAzure Monitorによるアラート通知機能を利用しています。具体的には、監視対象に対して条件（閾値 ）を設定し、アラート通知先を定義したアクショングループを利用し、アラートの通知先にメールを送信しています。

今回の事例でも記載したAzure Monitor の標準機能は多くの方が利用されていると思いますが、クラウドサービスの標準機能を利用する上でも考慮が必要であると考えています。
MicrosoftのSecurity policyにより、メール本文にアラート内容の詳細を添付できないようになり、代わりに対象のログの保存先であるLog Analytics Workspaceへのリンクがメールに記載される仕様に変更されました。そのため、アラート内容を確認するためにAzure Portalへのアクセスが必要になりました。本来Azure Portalにアクセスする必要がないユーザーに対しても、アクセス制御を検討する必要がありました。

Summary

今回の事例では、様々な要件を満たした上でAzureの標準サービスを活用し、オンプレミスからクラウド間のデータ連携を、低コスト・高セキュリティーかつ運用保守性に優れたシステム設計構築を実現できたと考えています。今後も基幹システムのデータをクラウドに連携し、データ分析＆活用を進めていくために必要なデータ連携を実現する選択肢の１つになればと思います。

Business Value

最後に技術的な内容ではなく、IBM & Blue Yonderをビジネス目線で一言付け加えさせていただきます。今回の事例において、データ連携先となるBlue Yonderシステムは、現在日本におけるサプライチェーン改革を実現するための、グローバルで実績のあるソリューションになります。

欧米では、サプライチェーンの改革が顧客満足、企業成長につながるという認識が強く、今後日本市場においても、サプライチェーンをエンド・ツー・エンドで、見える化、最適化を実現するためのソリューションの導入が加速していくことが予想されます。サプライチェーンの改革を日本国内で実現していくことをIBM & Blue Yonderのパートナーシップで進めていけるのではないかと考えています。また、IBMコンサルティング事業部としても、導入計画のプロジェクト支援や現場プロセスの改善に向けたIT技術の設計支援ができるのではないかと考えています。

関連情報

IBM Services for Microsoft