ページの本文へ

Hitachi

ミドルウェア ソリューション

JavaScriptをオンにするとブレッドクラムが表示されます。ミドルウェア ソリューション サイトのトップページはこちら。

バッチソリューション on クラウド

サーバーを必要な時に必要な分だけ使えるクラウド環境と、バッチを分散・並列実行して処理を高速化する分散バッチ処理基盤を組み合わせることで、バッチ処理の高速化とコストの最適化を実現します。

バッチソリューション on クラウドとは

バッチ処理システムは、ピーク時に備えてサーバーを用意することが一般的です。通常時は、データ量が少ないのでサーバーの一部が遊休リソースとなってしまいます。一方で、データ量が想定を超えると、バッチ処理が規定時間内に終わらないことがあります。遊休リソースを削減してコストを最適化すること、そして想定外のデータ量でも高速に処理して規定時間内に終わらせることが課題です。

「バッチソリューション on クラウド」では、バッチ処理の分散・並列実行を可能にして高速化を実現し、さらに、クラウド(Hitachi Cloud*1、AWS*2)を活用し、ミドルウェアを含めて従量課金で提供することにより、コストの最適化を実現します。

*1
Hitachi Cloud :日立が提供するクラウドソリューション Hitachi Cloud
*2
AWS:Amazon Web Services

本ソリューションは、分散して並列実行することが可能なバッチ処理に適用できます。
「バッチソリューション on クラウド」の特徴について説明します。

従量課金
クラウド活用で、ハードウェアも、ミドルウェアも従量課金の価格体系です。使った分だけの支払いなので、ピーク時と通常時でデータ量に差がある場合は、オンプレミスからクラウドに移行するだけでコストを最適化できます。
データ量の変動に対応
AWSのオートスケール機能を利用して、サーバーの追加や削除ができます。
例えば、データ量が増えた場合は、自動でサーバーを追加し、そのサーバーに分散処理をさせるといった運用が可能です。
要件に合わせた最適なクラウド
信頼性やセキュリティを重視したいのか、グローバルでのサービス展開を重視したいのか、などお客さまの要件に合わせてHitachi Cloudまたは、AWSを提案します。

このようなお客さまにお勧めします

  • バッチ専用サーバーは、遊休時間が長く、コストを最適化したい
  • 株価や為替といった市場動向に連動してデータ量が大きく変わるため、データ量の想定が困難であり、バッチ処理が規定時間内に終わらない危険性がある
  • メインフレーム上で稼働するバッチ業務をオープンサーバー上に移行し、コストを低減したい
  • 基幹系システムのバッチ業務を高速化したい

課題1:バッチ処理のコストを削減したい

【現状】バッチ処理システムは、ピーク時に備えた構成としているため遊休時間が長い

オンプレミス環境では、月末などのバッチ処理のピーク時に備えて、システム性能設計を行い、必要な台数のサーバーを確保します。そのため、通常時は、一部のサーバーが遊休リソースとなってしまい、ハードウェアも、ミドルウェアも無駄なコストが発生してしまいます。

ピーク時に備えた構成で、ハードも、ソフトも遊休リソースになっている!

【解決】クラウド活用により、必要な時に必要な分だけ使用することで遊休リソースゼロを実現

クラウドを活用することにより、ハードウェアもミドルウェアも従量課金の価格体系で利用できるようになります。これからは、あらかじめピーク時に備えて常時サーバーを確保しておく必要はないので、遊休リソースゼロを実現できます。これによりコストを最適化することができます。

従量課金で、ハードも、ソフトも遊休リソースゼロを実現!

試算では、1ヶ月あたりのバッチ処理システム利用時間を96時間とした場合、オンプレミスと比較してコストを約1/4に抑えることができました。

コスト削減イメージ

課題2:バッチ処理を時間内に確実に終わらせたい

【現状】想定を超えるデータ量を処理する場合、時間内に終わらない可能性がある

毎日の夜間バッチでは、オンライン業務の開始までにバッチ処理を終わらせる必要があります。しかし、想定を超えるデータ量を処理する必要がある場合、オンライン業務の開始までに、終わらない可能性があります。もし、終わらずに突き抜けた場合、業務に影響を与えてしまいます。

【解決】AWSのオートスケール機能を利用して、バッチ処理するサーバー数を増やして対応

データ量が増えた場合は、AWSのオートスケール機能で、サーバーを追加し、分散処理するサーバー数を増やして対応します。
オンプレミスとAWSの併用も可能です。オンプレミスのサーバーだけでは、想定を超えるデータ量を処理できない場合に、不足分をAWSで補うことができます。不要になったサーバーは削除できるので、無駄なコストはかかりません。

データ量に応じてサーバーを追加

課題3:メインフレームのバッチ処理を性能を落とさずにオープン化したい

【現状】オープン化によりコスト低減したが、単純な置き換えだけでは処理性能が出ない

コスト低減のためにメインフレームからオープン環境へ移行する場合、単純な置き換えではバッチ処理の性能が出ないことがあります。これは、メインフレームよりCPU性能が高くない場合があるということと、プログラムがマルチタスク/マルチスレッドで動作せず、CPUをうまく使いきれないことなどが要因です。

処理性能が出ない

【解決】バッチ処理の分散・並列実行で高速化を実現

分散バッチ処理基盤はバッチ処理を複数のサーバーに分散して並列実行します。このためCPU性能が高くなくても高速化を実現できます。さらに、クラウドを活用することで使った分だけの費用支払いとなり、単にオープン化する以上にコストを抑えることができます。

コストを低減できて、処理性能にも満足

分散バッチ処理基盤には、COBOL資産のバッチが数多くあります。大量データを分散処理するためのソフトウェアとしてHadoopというOSS*3がありますが、このCOBOL資産のバッチをHadoopで分散・並列実行しようとすると、Hadoopの処理モデルに書き直さなければなりません。しかし、日立の分散バッチ処理基盤なら、COBOL資産をそのまま活用できます。さらに、メインフレームからオープンへのスムーズな移行を支援する「レガシーマイグレーション支援ソリューション」も提供しています。

*3
OSS:Open Souce Softwere

課題4:基幹系システムのバッチ処理を高速化したい

【現状】Hadoopではエラー発生時、規定時間内に処理が終わらない

大量データの分析処理に向いているHadoopは、処理の途中でエラーが発生すると、最初からやり直さなければなりません。
例えば、1つのジョブをJOB1〜JOB9まで分散して並列実行する場合、JOB1〜JOB8までは正常に処理済みとなっていても、JOB9でエラーが発生すると、処理全体を再実行しなければなりません。大量データの分析処理では、多少のエラーを無視して処理を続行しても問題の無い場合が多いのですが、基幹系システムでは、そういうわけにはいきません。再実行のため、処理が長時間化することになります。

Hadoopの場合 イメージ図

【解決】分散バッチ処理基盤ではエラー発生時、部分再実行で処理の長時間化を抑制

分散バッチ処理基盤は、分散処理で一部のジョブにエラーが発生していても、処理全体をやり直す必要がありません。エラーが発生したJOB9を再実行するだけで済み、長時間化を抑制できます。生産管理や会計管理などの基幹系システムにも安心して使用することができます。

分散バッチ処理基盤の場合 イメージ図

紹介リーフレット

バッチソリューション on クラウドの詳細については、下記のリーフレットをご参照ください。

関連製品一覧

関連製品一覧
分類 機能 製品・ソリューション
バッチ 分散バッチ処理基盤 uCosminexus Grid Processing Server
言語 COBOL言語 COBOL2002

AWS Summit Tokyo 2015 レポート。バッチソリューション on クラウド展示。詳しくはこちら(新規ウィンドウを表示)

Adobe Readerのダウンロード
PDF形式のファイルをご覧になるには、Adobe Systems Incorporated (アドビシステムズ社)のAdobe® Reader®が必要です。