EAI/ETL技術者のブログ

EAI/ETL技術者のブログ>ETL/バッチ処理のパフォーマンスチューニングを考える

  • バッチ処理
2019.08.07

ETL/バッチ処理のパフォーマンスチューニングを考える

ETL/バッチ処理のパフォーマンスチューニングを考える

【目次】
 ▶パフォーマンスの重要性
 ▶パフォーマンスが低下したら? ー 問題箇所(ボトルネック)の特定
 ▶パフォーマンスが低下したら? ー 問題改善
 ▶ETL/EAI処理/バッチ処理のパフォーマンスチューニングに対する解決策


こんにちは!

アシストでデータ連携製品(DataSpider/DMExpress)を担当している市毛です。

今回は、ETL処理、バッチ処理のパフォーマンスが低下した時の問題の見極めポイントと改善方法について
考察してみたいと思います。


パフォーマンスの重要性

まず、システムの安定運用において「パフォーマンス」は重要な要素であることは言うまでもありません。

参考情報として、経営層のアプリケーションパフォーマンスについての意識調査(※)の結果から考察してみます。

■経営層が考えるアプリケーションパフォーマンスの重要性
  ー 業績達成のために重要:98%
  ー 低下すると自分の業務にネガティブな影響がある:89%

■経営層が感じるアプリケーションパフォーマンス低下の発生頻度
  ー 週に1度 :58%
  ー ほぼ毎日:36%

この結果から、
 ・ビジネスの成功のためにはアプリケーションパフォーマンスが重要
 ・一方で、アプリケーションパフォーマンスの低下はシステム管理者の想定以上に発生している
ということがわかります。


パフォーマンスが低下したら? ー 問題箇所(ボトルネック)の特定


パフォーマンスの重要性をご理解いただいたところで、
実際にパフォーマンスが低下した場合に、どのように対応するべきかを考えてみたいと思います。

ここで、いきなり「パフォーマンスチューニング」を行おうとしても効果を得ることは難しいです。

まず必要なのは、どこでパフォーマンスが低下したのか「問題箇所(ボトルネック)を特定する」ことです。

ボトルネックとなる要素は大きく2つに分けることができます。

1.インフラリソース

2.アプリ/DB

ボトルネックの要素

ボトルネック要素

◯インフラリソース:
  CPU、メモリ、ネットワーク など

◯アプリ/DB:
  アプリケーション、SQL、DB など


ボトルネックを特定するには、

・インフラ/アプリの「視点別」のリソース状況 の可視化

 と

・「定期的」なリソース状況 と 「パフォーマンス低下時」のリソース状況 の可視化

が必要となると考えられます。

ここでは、下記のように、アシストで考えるボトルネック特定を含むパフォーマンス管理の
全体像でとらえていただくとわかりやすいかと思います。

パフォーマンス管理全体像




「サーバ/OSの視点」がインフラ、
「アプリケーションの視点」がアプリ/DB、
それに加えて
「サービスの視点」を用意しています。

ユーザーが体感するレスポンスを可視化して、パフォーマンス低下を事前に検知するという考えです。


パフォーマンスが低下したら? ー 問題改善


ボトルネックの箇所の特定ができて、初めて原因に対する「問題改善」のアプローチに移ることができます。

パフォーマンスチューニングは、問題改善アプローチの1つの手法となります。

また、問題改善アプローチはアプリ/DB/インフラリソースといった要素によって、その手段が異なります。

下記は、問題改善のための、ボトルネック要素とそれに対する手段、さらによくある課題を図式化したものです。

よくある課題

パフォーマンスチューニングと呼ばれる手段は、この図にも記載があるように、具体的には下記の要素が挙げられるかと思います。

・アプリケーションの処理ロジックの修正
・アプリケーションからデータベースアクセスするSQLの修正
・データベーステーブルの索引(インデックス)追加
・DBMSのパラメータの見直し

これらは、ある程度汎用的な手法もありますが、細かい部分はアプリケーション/SQL/データベースによって
有効な方法が異なります。

よって、何にでも効くオールマイティなパフォーマンスチューニングの手法は存在しない、と言えます。

限定的なパフォーマンスチューニングのノウハウになりますが、
アシストでは、Oracle Databaseのパフォーマンスチューニングのための教育/研修コースを提供しております。


ご紹介したような実践的なパフォーマンスチューニングのノウハウを習得してチューニングを実施する、
というのも一つの方法としてご検討いただければと思います。

ただし、一般的にパフォーマンスチューニングを行うには、高度なスキルセットと経験が必要となる分野です。

また、パフォーマンスチューニングというのは、目標値を達成するまで、

パフォーマンスチューニング手順

測定

(目標未達成であれば)

ボトルネック特定

ボトルネック改善

測定

・・・(繰り返し)

上記のイメージで、繰り返しての作業が必要となります。
そうなると想定していたよりも工数が膨らむ可能性も考えられます。


ETL/EAI処理/バッチ処理のパフォーマンスチューニングに対する解決策


このブログのテーマである「ETL/EAI処理」「バッチ処理」のパフォーマンスチューニングに関する
解決策としてご案内したいのは、最も賢い超高速ETLツール「DMExpress」です。

DMExpressの超高速の秘訣は「スマートETLオプティマイザ」という独自の自動チューニング機能を持っていることです。

処理対象の入力データソースや、稼働マシンのスペック情報を自動取得しそれらの情報をもとに処理アルゴリズムが動的に決定され、処理が動作するという代物です。

この自動チューニング機能により、

「開発者のパフォーマンスチューニングの工数が減る」

ということはもちろんですが、副次的なメリットとして、

「開発者自身で考慮する必要があった処理のパフォーマンスをツール側に任せられるため
 ”開発者のスキルに依存せずに”パフォーマンスの高いETL処理を構築できる」
 (=開発者アサインの幅が広がる)


ということも挙げられます。

DMExpressをもっと知りたい!と思われた方は、ぜひ詳細資料をご覧ください。


パフォーマンスに効く!「パフォーマンス障害への備えと対策」資料のご案内


1.傾向把握
2.事前テスト
3.障害検知/原因特定
4.問題改善
パフォーマンスに問題が起こった際に、上記4つの観点から最適なソリューションをまとめた資料です。
俯瞰して見られる資料になっていますので、ぜひご覧ください。


執筆者情報:

執筆者 市毛正浩

市毛 正浩 (いちげ まさひろ)
東日本技術本部 情報基盤技術統括部

2008年 株式会社アシストに中途入社。
EAI/ETL製品「DataSpider」「Syncsort DMExpress」の提案活動とお客様支援に
従事。

関連している記事

  • バッチ処理
  • ETLを学ぶ
2019.11.18

バッチ処理の基礎-リアルタイム処理との違いにも迫る!

レガシーシステムからのDXなど、再び注目を浴びる「バッチ処理」の基礎について解説します。バッチ処理とリアルタイム処理の違いについても考察しています!

  • バッチ処理
2019.07.18

バッチ処理の開発時によくある課題と最適なバッチ処理の開発手法についてまとめました

DXの要になる!?バッチ処理の開発時によくある課題を挙げ、最適なバッチ処理の開発手法について考察しています。

DataSpider DMExpress(DMX)

ページの先頭へ戻る