バッチの分散処理を実現する日立のグリッドバッチソリューション

売上の集計や分析など、さまざまな領域で行われているバッチ処理の高速化を支援する、日立製作所のソリューションを解説します。

バッチ処理が抱えている現状の課題

業務のあらゆる分野でITが活用されアプリケーションの多様化がすすみ、ITの用途は広がり続ける一方です。今後も企業が蓄積しているデータ量は日々増え続けることが予想され、各種業務システムの中で使用されているバッチ処理への負荷が増大し続けていることが新たな問題として浮上しています。

通常、バッチ処理はコンピュータリソースに余裕のある夜間、あるいは休日に行われます。ただ、処理すべきデータが増えてバッチ処理に時間がかかるようになると、規定の時間内に作業が終わらない、いわゆる「突き抜け」と呼ばれる状態に陥ってしまいます。突き抜けが発生すれば翌日の業務に影響を及ぼすことも考えられるため、極めて重大な問題であると言えます。

こうした課題を解決するため、日立製作所が提案しているのが「グリッドバッチソリューション」であり、具体的には新製品である「uCosminexus Grid Processing Server」でバッチ処理の効率化を実現可能にしています。

uCosminexus Grid Processing Serverのポイントは3つ。1つはバッチ処理をサーバ単位で分散、並列化を図ることで高速化を図るというもの。2つ目がITコストの適正化です。高価なサーバから価格対性能比が向上し続けているIAサーバを活用することで、ITコスト削減を実現できるというわけです。そして3つ目が基幹系業務システムのバッチ処理にも対応できる、高い可用性を実現している点となります。

図1 バッチ処理の並列実行による高速化
図1 バッチ処理の並列実行による高速化

それでは、グリッドバッチソリューションを導入することにより、どういったメリットがあるのかについて詳しく見ていきましょう。

バッチ処理の並列化で高速化を実現

従来のバッチ処理は、単体のハードウェアを使って実施するケースがほとんどでした。このためバッチ処理を高速化するには、ハードウェア自体の性能を高める必要があります。一方、日立製作所のグリッドバッチソリューションであれば、バッチ処理を分割し、複数のサーバを使って並列処理することにより高速化を実現します。つまり、システムのスケールアップではなく、スケールアウトによる高速化が図れるシステムということになります。

バッチ処理に時間がかかる要因として、データベースがボトルネックになっていることが挙げられます。バッチ処理をいくら多重化しても、データベースにおけるI/O処理が間に合わなければ、パフォーマンスを向上させることができません。そこでグリッドバッチソリューションでは、ジョブの並列化を行うために、データを分散して処理する仕組みを備えています。これにより既存のバッチ処理の仕組みを大きく変えることなく、分散処理を実現しているわけです。

ITコスト削減につながる点も見逃せません。従来のバッチ処理は高価な大型のUNIXサーバなどを使って行われていましたが、グリッドバッチソリューションはコストパフォーマンスが高いIAサーバを並列で利用することができます。このため、バッチ処理の対象となるデータが増大した場合でも、高価なサーバを買い換えるのではなく、安価なIAサーバを追加することで対応できるというメリットが生まれています。また業務量の増加に応じてサーバを増やせるため、IT投資を最適化できるのも大きなポイントではないでしょうか。

基幹業務など信頼性が求められる分野にも対応できる、高い信頼性を備えている点もグリッドバッチソリューションの特徴です。複数のサーバで分散処理を行っている際、1台のサーバにハードウェアトラブルなどが発生しても、自動的に別のサーバに処理を移行して処理を継続する仕組みが備えられています。従来は実行系と待機系を用意し、実行系にトラブルが生じればすべての処理やデータを待機系に切り換えるという形で可用性を担保していましたが、グリッドバッチソリューション環境では、複数台のサーバを並列で利用するため、切り替える処理やデータを局所化することで、パフォーマンスの縮退を最小限に抑えられます。

これらの特徴は、現在話題となっているプライベートクラウド環境と相性がよい点も見逃せません。クラウドとして用意されたサーバリソースを、昼間はオンライン処理に利用し、夜間はバッチ処理に利用するといった使い方が可能です。同社の「JP1/IT Resource Management」を利用すれば、プライベートクラウドのリソースプールを一元的に管理し、リソースの予約やサーバ配備などの管理も容易に実現することが可能になります。

図2 プライベートクラウド環境でのバッチ適用
図2 プライベートクラウド環境でのバッチ適用

なお、バッチの分散処理を実現する環境として「Hadoop」という選択肢もあります。Hadoopはオープンソースで公開されている分散処理環境であり、大規模データ解析などといった用途で使われ始めています。では、uCosminexus Grid Processing ServerとHadoopではどういった違いがあるのでしょうか。

まず大きなポイントになるのが、それぞれのソリューションの狙いが異なっている点です。uCosminexus Grid Processing Serverでは、データ分散の柔軟性やCOBOLへの対応など既存資産を活用した開発が可能であること、そして障害を局所化することによって終了時間を厳守するといったことに重点が置かれています。

一方のHadoopは、システム基盤へのインストールやセットアップの容易性、並列処理を意識することなく開発できること、周辺の開発ツールを拡充させるといったことが重視されています。さらに自由度の高さもHadoopの強みとなっていますが、そのために運用ツールとの連携など作り込みが必要な部分も少なくありません。

このように両者は狙いが異なり、そのため得意分野も違っています。uCosminexus Grid Processing Serverがもっとも得意としているのはエンタープライズ領域における分散処理であり、そこで求められる要件を満たすため機能が数多く搭載されています。前述したとおり基幹系に多く残るCOBOL資産を活かせるほか、厳密な排他処理が可能であることや異常検知・再実行保証の仕組みが用意されているのはHadoopに対する大きなアドバンテージでしょう。運用ツールとして幅広く利用されているJP1との連携が可能で、運用負荷を抑えられる点も魅力となっています。

スケーラビリティを高める3つのポイント

それでは、グリッドバッチソリューションのシステム構成をチェックしていきましょう。大きく「統合運用管理」「アプリケーション層⁠⁠、そして「データ層」の3つに分かれています。

図3 グリッドバッチソリューションの構成
図3 グリッドバッチソリューションの構成

まず統合運用管理のレイヤーでは、ジョブのスケジューリングや実行監視などを担います。これを実現するのが「JP1/Automatic Job Management System 3」です。アプリケーション層では、複数のコンピュータのリソースを利用し、並列、分散処理を行います。これらの機能を提供するのが「uCosminexus Grid Processing Server」であり、さらに実行環境として「uCosminexus Batch Job Execution Server」が用意されています。データ層では各種ファイルシステム、あるいは複数のデータベース製品を利用することができます。

図4 グリッドバッチソリューションで提供される機能
図4 グリッドバッチソリューションで提供される機能

グリッドバッチソリューションでは、これらを利用し、まずデータを分割します。大きなデータをシリアルで処理するのではなく、小さなデータに分割してパラレルでバッチ処理を行うことで、高速化を図っていくというわけです。

こうしてパラレルで処理する際には、いくつかのポイントがあります。まず1つは、ローカルディスク方式ではなく、ファイル共用方式で処理を行う選択があるという点です。ファイル共用方式であれば、データ転送が不要になるほか、ジョブを実行するサーバを固定せずに済むため、負荷分散が容易になるというメリットがあります。

ディスク非共用方式のデータベースを利用することも重要でしょう。データを分割しても、そのデータがすべて1つのデータベースに蓄積されていた場合、結局そのデータベースにアクセスが集中し性能干渉が発生してしまいます。つまりスケーラビリティに限界があるというわけです。しかしディスク非共用方式のデータベースを利用し、テーブルを複数のデータベースに分割して保存しておけば、ジョブを実行している個々のサーバからのアクセスが分散することになるため、性能干渉が発生しません。スケーラビリティを高める上では、こうした仕組みは必須と言えるのではないでしょうか。

データへのアクセスにおいて見逃せないのがストレージのパフォーマンスの低さです。CPUがいくら高速に処理を行っても、データの読み込みや書き込みが遅ければ待ち時間が発生し、結果的に全体のパフォーマンスが低下してしまいます。この課題を解決する上で有用なのが「インメモリ機能」で、データを高速なメモリ上に配置することでディスクアクセスの頻度を抑え、処理を高速化します。

並列処理を加速する日立のデータベースとファイルシステム

こうした要件を満たすデータベース、あるいはファイルシステムとして日立製作所から提供されているのが「HiRDB」「Hitachi Striping File System」です。

日立製作所のHiRDBは、純国産のリレーショナルデータベースであり、自社開発にこだわっているのがポイントです。このため安心してサポートを受けられるという大きな利点が生まれています。

HiRDBは1つのデータベースを複数のサーバに分割する、パラレルサーバによる並列処理に対応しているため、ディスク非共用型のデータベースとして活用できます。さらにインメモリ機能を用意するなど、グリッドバッチソリューションにおいて最適なデータベースであると言えます。そのほか日本独自の文字コードのサポートなどにより、メインフレームで培われたCOBOL資産を継承できる点も魅力です。

図5 並列処理で威力を発揮するHiRDB
図5 並列処理で威力を発揮するHiRDB

Hitachi Striping File Systemは日立製作所のスーパーコンピュータ分野で培われた技術を投入した共有ファイルシステムです。これを利用することでサーバ間でファイルコピーが不要になる、ファイル共用方式でバッチの分散処理が可能になるほか、厳密なファイル排他管理機能が組み込まれているため、単一サーバと同等のデータ一貫性が保証されます。ディスクへのアクセスはファイバチャネル経由となるため、ネットワークへの負荷を抑えられるのもポイントでしょう。そしてファイルをメモリに常駐させるインメモリ機能が用意されているので、バッチ処理時間の短縮もサポートしています。

図6 ファイル共用方式で各サーバから直接データにアクセス可能
図6 ファイル共用方式で各サーバから直接データにアクセス可能

運用負荷を低減する豊富な支援機能も用意

このようにuCosminexus Grid Processing Serverを中核としたソリューションを導入することにより、バッチ処理に係わるさまざまな課題を解決することが可能です。ただ、それによって運用業務が複雑化するようでは、導入時の大きな敷居となってしまいます。

そこでuCosminexus Grid Processing Serverでは、GUIを利用してジョブを定義するためのインターフェイスが用意したり、あるいはデータの分割支援やジョブ定義の容易にするための仕組みを提供したりすることで運用負荷を低減しています。こうした配慮も、ソリューション選定時には大きなポイントになるのではないでしょうか。

図7 運用負荷を最小限に抑えながら、バッチ処理の負荷分散を実現
図7 運用負荷を最小限に抑えながら、バッチ処理の負荷分散を実現

バッチ処理の高速化には強いニーズがある一方、情報システム部門はITコストの適正化という期待にも応えなければなりません。こうした難しい課題を解決するソリューションとして、日立製作所のグリッドバッチソリューションは考慮する価値のあるソリューションでしょう。

おすすめ記事

記事・ニュース一覧