DSP冒険の書 ~2章|ジョブ管理システムの構築

 

text:江川 聡子 日本アイ・ビー・エム システムズ・エンジニアリング

 

本章では、デジタルサービス・プラットフォーム基盤(以下、DSP基盤)においてIBM Workload Schedulerをベースとしたジョブ管理システムの構築事例を、IBM Cloudならではの2つの課題に絞って紹介する。

使用したツールおよび課題 

DSP基盤上でジョブ管理システムを構築するうえで筆者が使ったツールは、IBM Workload Scheduler(以下、IWS)というジョブ管理ツールである。20年以上の歴史と数々のお客様での利用実績がある。

このIWSを使用したジョブ管理システムを構築するにあたり、以下の2点が課題となった。

・IWSサーバーはゾーン障害を考慮して構成する。
・Red Hat OpenShift on IBM Cloud (以下、ROKS)クラスター上でジョブを管理する。

ゾーン障害への対応  

DSP基盤はゾーン1とゾーン2の2つのアベイラビリティ・ゾーンで構成され、ゾーン1の障害時にはゾーン2でサービスを継続する設計となっている。これに合わせて、ジョブ管理サーバーもゾーン1障害時にはゾーン2でサービスを継続できるように構成する必要があった。

オンプレミス環境では図表1に示すような2パターンの構成が考えられる。一般的には2つの仮想サーバーまたは物理サーバーに共有ディスクを接続し、ソフトウェアをその共有ディスクに導入するHAクラスター構成がポピュラーだが、DSP基盤はIBM Cloud上に構築されており、ゾーンをまたがったサービスIPやディスクストレージの共有はできない。このため、共有IPや共有ディスクを必要としないバックアップマスター構成を採用した。

図表1 IWSサーバーの一般的な冗長構成とその比較
図表1 IWSサーバーの一般的な冗長構成とその比較

 

また、IWSをバックアップマスター構成とする場合、データ・リポジトリとして使用するDb2はHA/DRによる冗長化が主流だが、これについても図表2に示すとおり、IBM Cloud VSI上でHA/DRを構成とする方法と、Db2 on Cloudを利用する方法の2パターンが考えられた。比較検討の結果、Db2 on Cloudを採用する構成とした。

図表2 IBM Cloud環境におけるIWS用Db2の冗長構成とその比較
図表2 IBM Cloud環境におけるIWS用Db2の冗長構成とその比較

 

DSP基盤で構築したゾーン障害に耐え得るIWSサーバ構成は、図表3のとおりである。ポイントは2つある。1点目はゾーン障害に対応できるよう、ゾーン1にマスターサーバー(MDM)を、ゾーン2にバックアップ・マスターサーバー(BKM)を配置した点だ。
2点目はDb2 on Cloudを利用した点である。ゾーン障害にも対応可能なDBインスタンスをクラウドサービスとして提供しているので、構築・運用にかかるユーザー負担を軽減できる。

図表3 ゾーン障害に耐え得るIWSサーバー構成
図表3 ゾーン障害に耐え得るIWSサーバー構成

ROKSクラスターのジョブ制御  

DSP基盤にはROKSクラスターでのジョブ実行要件があった。2つのアベイラビリティ・ゾーンそれぞれにクラスターがあり、ゾーン1障害時はゾーン2でサービスを提供することとなっているため、ジョブ管理基盤もゾーン障害に対応できるよう構成する必要があった。

この課題への対応として、IWSのKubernetes Plug-inとDynamic Agent Podを使用した。また、ゾーン障害に対応するために、IWSの動的プールを利用した。

一般的にKubernetesクラスターでバッチ処理を行う場合は、Kubernetes Jobを使用する。このKubernetes Jobは、kubectlコマンドやKubernetes Cron Jobで制御可能だが、これらの機能で先行ジョブの指定やジョブネットの分岐・集約を設定することは難しい。

そこで、IWSのKubernetes Plug-inとDynamic Agent Podを組み合わせることで、ROKSクラスターでのKubernetes JobをIWSから制御できるようにした。Dynamic Agent PodはKubernetesクラスターでIWSのDynamic Agentをパッケージングしたコンテナを実行するものであり、Kubernetes Plug-inを組み合わせるとDynamic Agent Podより任意のKubernetesクラスターやnamespaceを指定してKubernetes Jobを起動することが可能となる(図表4)。さらにIWSのスケジューリング機能により日時指定以外の複雑な起動条件も付与できるメリットがある。

図表4 Dynamic Agent Pod と Kubernetes Plug-in
図表4 Dynamic Agent Pod と Kubernetes Plug-in

 

ゾーン障害への対応には動的プールを使用した。動的プールとは、一定の条件を満たす複数のDynamic Agentをグループ化する機能である。プール内のDynamic Agentに対してあらかじめ定義しておいたルールでジョブを振り分けることができ、たとえばゾーン1のDAが利用できない場合はゾーン2のDAにジョブを振り分ける、と言った制御が可能となる(図表5)。

図表5 動的プール
図表5 動的プール

DSP運用基盤におけるROKSラスターでのIWSの実装を図表6に示す。各ZoneのROKSクラスターにはIWSのDAを導入し、IWSサーバーへKubernetes Plug-inを追加することで、IWSからのKubernetes Jobの実行管理を可能とした。またゾーン障害への対応として動的プールを活用し、通常時はゾーン1で、ゾーン1障害時はゾーン2へジョブが振り分けられるようにした。

図表6 IWSによるROKSクラスターでのジョブ制御

DSP基盤はIBM Cloud上に構築されているので、IBM Cloudならではの、IWSをベースとしたジョブ管理システムを構築するうえでのポイントを中心に紹介した。ゾーン障害を考慮したIWSサーバーの構成例やコンテナ基盤でのジョブ管理の実装例を示した。今後はパブリッククラウドやコンテナ基盤上でジョブ管理システムの構築が増えていくと思われるため、本稿が今後のプロジェクトの参考になれば幸いである。

 


江川 聡子 氏

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・プラットフォーム
シニアITスペシャリスト

入社以降、さまざまな業種の運用管理システムの構築に携わる。近年は主に、OpenShift、クラウド上のジョブ管理システム構築の技術支援を担当している。

2Job-Egawa 011

DSP冒険の書  Contens

0章 はじめに ~発表から1周年を迎えたDSP
1章 ログ管理システムの構築
2章 ジョブ管理システムの構築
3章 クローン環境の構築

このサイトの掲載内容は著者自身の見解であり、必ずしもIBMの立場、戦略、意見を代表するものではありません。

 

i Magazine・IS magazine]

More Posts