山崎製パン 計算センター 運用課 課長代理の日下部 昭彦氏によると、大手食品メーカーの工場は製造のみを分担する場合が多いが、同社の工場では新製品の開発から、顧客との商談、受注、製造、配送までを行っている。配送業務も外務委託ではなく、自社で物流機能を抱えている点も強みの1つだ。

　国内工場は、その地域の取引先企業や消費者の嗜好（しこう）や地域特性に合わせてビジネスを展開している。そのため、業務プロセスやITシステムは各工場で異なっている。

　山崎製パンは現在、日本全国でおよそ1400種類の商品を販売しているという。だが、1つの工場で生産できるアイテム数は多くても500種類。生産していない商品を受注した際は、他の工場に発注し、工場間で生産調整をしている（図1）。

　このように、同社では、日本全国に点在する各工場が地域に根差し、自主独立体制で経済活動を行っている。本社はその全体管理機能を担い、計算センターもその本社組織の1つである。

30年来の基幹システムを再構築

　山崎製パンは30年にわたり、工場ごとのメインフレームで基幹システムを分散稼働していた。この基幹システムをSOA（Service Oriented Architecture）基盤をベースにIAサーバへとオープン化し、以下の3種の処理を集中処理できるようにした。

• 各工場で発生する受注データを一元化する受注処理
• 工場間の生産調整が容易にできる発注処理
• 工場と販売店を結び配分・配送を行う物流処理

　「得意先の店舗数は10万店舗強、ピーク時の受注件数は1時間に200回を超えることもあった。1日の受注件数は約400万件、印刷する伝票枚数は社内外向けで1日に計21万枚に達する。とても大きな規模のシステムである」と日下部氏は説明する。

　同社は基幹システムの再構築に当たって、「自社開発・自社運用」「運用保守コストの削減」という2つのチャレンジに挑んだという。

　従来、メインフレームは自社開発・自社運用、オープン系システムは開発を外部に委託し、運用保守は自社で行っていた。だが今回は、「ビジネスの重要なことは自前で行う」（日下部氏）という企業文化に従い、オープン系システムの構築も自社開発・自社運用に転換することを決めた。その一環として、JP1を利用した監視システムの自社開発にも踏み切った。

　運用保守コストの削減については、府中センターと大阪センターの2拠点で分担していた運用オペレーションを1拠点に集中させることで、運用工数の削減を進めた。SOAによる標準インタフェースの採用により、最大40％の工数削減、変化に強いシステム作りが可能となった。JP1のジョブ監視業務を可能な限り合理化することにも取り組んだ。

　「山崎製パンの業務は24時間365日稼働しており絶対に止まることが許されない、ミッションクリティカルなシステム。従来は、府中と大阪にホストコンピュータを設置し、そのホストの中で国内20工場向けに区切った仮想マシン（VM）とバックアップ機を稼働させていた。また当時は、府中センターが止まると東日本の工場が止まり、大阪センターが止まると西日本の工場が止まるといったように、相互のバックアップ体制は構築できていなかった」（日下部氏）

　基幹システムのオープン化に伴い、メインフレームの機能を府中センターのIAサーバに集約。それにより余った大阪センターは、災害対策（DR）用サイトへと位置付けを変え、災害時に、府中センターに変わって国内工場の運用業務を引き継げるようにした。

　システム構成は、ジョブ運用管理サーバに「JP1/AJS3（JP1/Automatic Job Management System 3）」、統合監視サーバに「JP1/IM（JP1/Integrated Management）」「JP1/PFM（JP1/Performance Management）」、イベント通知サーバに「JP1/IM-TELstaff」「JP1/Cm2/NNMi（JP1/Cm2/Network Node Manager i）」を利用。業務サーバ群は「Red Hat Enterprise Linux」で構築した。

オープン系システムを監視する2つの方針

　前述の通り、山崎製パンはこれまでメインフレーム中心の運用体制だったため、システム担当者のほとんどがオープン系システムに慣れていなかった。そこで、運用監視を安全かつ確実に実施するため、「監視業務に必要なスキルを少なくする」「メインフレームで培った安全運用の文化を踏襲する」という2つの方針を決めた。

　具体的には、1つのジョブに複数のプログラムを割り当てることを禁止した。それによりプログラム単位の実行状況がJP1/AJS3でグラフィカルに把握可能となった。「シェルスクリプトやシステムログを読み解くスキルがなくても、JP1の画面から状況が分かるように設計した」（日下部氏）

　ジョブをジョブネットとしてまとめる粒度は運用監視の粒度を基準とした。ジョブの監視で「チェックポイント」となる部分でジョブネットを分割し、システム遅延の視認性を高めた。

　さらに、異常終了したジョブは、ジョブネットの先頭から再実行するようにした。例えば、4つのジョブ（A、B、C、D）で構成するジョブネットのどこで異常終了が発生しても、その異常終了したジョブが属するジョブネットの先頭からジョブを再実行することで、どのオペレーターでも安全かつ確実に対応できるようにした。

　リラン（再実行）ポイントが複数になる場合は、ジョブネットの中に別のジョブネットを定義するネストジョブネットで分割し、リランポイントが必ずジョブネットの先頭になるよう工夫を凝らした。ジョブネットは複雑にならないよう、ネストは1階層に制限している。

膨れ上がるジョブとジョブネットの数

　監視業務に必要なスキルを少なくするジョブ構成、安全運用のためのジョブネット分割指針と再実行ポイントの標準化といったこれらの施策は、ジョブとジョブネットの数を大きく増加させる要因となった。新規システムの規模を見積もったところ、ジョブネット数は5万件、ジョブ数は40万件に達したという。「これらの膨大なジョブおよびジョブネットを1つの拠点で集中監視し、かつ運用コストを削減するには、簡単で確実にシステムを監視するための工夫が必要となった」と日下部氏は振り返る。

　さらに、山崎製パンのシステム監視には、次の要件を満たすことが求められた。

• 工場別、サブシステム別の階層を分けた管理
• 遅延や未実行が業務に影響を与えるジョブネットの監視（約8000件のジョブネットが対象）
• 時間帯ごとのグループ監視

　この3つの要件に対応するために、まず検討したのはJP1/AJS3の「サマリー監視画面」の利用である。サマリー監視画面を使えば、階層の異なる任意のジョブネットを監視でき、工場別、業務別であっても時間帯ごとに監視可能ではないかと考えた。

　だが、大きな課題が判明した。サマリー監視画面は端末ごとに1種類しか監視定義を登録できなかったのだ。「工場別、サブシステム別に階層を分けて管理することはできるが、8000件のジョブネットを監視するには1つの画面では収まらず、時間帯ごとのグループ監視も切り替えができなかった」（日下部氏）

　そこで同社は、複数のサマリー監視定義を使い分けるためのツールを自社で開発。サマリー監視の定義は「JP1/AJS-View」クライアントの「ユーザー指定オプションファイル」に書き込んでいる。このファイルを監視タイミングに応じて差し替えることで、複数種類の監視定義を切り替えることができるようになった。

　NAS（Network Attached Storage）に保管した数百種類のオプションファイルは、複数のクライアントで共有可能となった他、画面表示に関する多様な設定を含むため、画面の標準化・共通化にもつながった。

Excel連動と監視モニターの構築

　「サマリー監視画面だけでは、ジョブの遅延や異常が一目で分かりにくいという現場の声があった」と日下部氏。視認性の向上、ジョブ運行の記録という観点から「Microsoft Excel」とJP1を連動させる監視ツールを作成した（図2）。

　平常時はExcelの処理一覧表で全工場を俯瞰して監視。異常や遅延が発生した際はJP1のサマリー監視画面を起動し、原因を究明している。

　ジョブの異常終了や遅延、インフラ障害を見える化する独自の監視モニターも構築した。この監視モニターでは、オープン系システムとメインフレームを同時に監視可能。どの工場でどのようなインシデントが発生しているかを色と音で通知する仕組みとなっている。

　本社と府中センター、大阪センターに監視モニターを設置し、計算センターのメンバー全員が基幹業務および周辺システムの現在の状況を把握できるようにしている。

性能テストで見えた課題

　ジョブ数40万件、ジョブネット数5万件、さらにピーク時間帯のジョブ実行数が秒間20件に達すると想定された大規模な運用管理システムなだけに、リソースのサイジングを慎重に検討する必要があった。

　「JP1/AJS3は、1つのスケジューラサービスに対して、2CPUコアを割り当てるのが推奨値というのが分かっていた。また、1スケジューラサービス当たり、20万ジョブ／日に抑えなければ、安定稼働できないという制約もあった」（日下部氏）

　ベンダーとのやりとりや直近の類似事例から類推した結果、当初はCPUは「Intel Xeon E5630」の4コアCPU／2.53GHz、メモリは8Gバイト、スケジューラサービス数は2つと見積もった。

　性能テストでは、総ジョブ数40万件、ピーク時間帯のジョブ実行数は秒間20件というように全工場稼働時の状態を再現。ピーク時間帯の受注処理やジョブ起動を遅滞なく行えるかどうかを検証した。

　さらに、夜間バッチ処理後のスケジューラサービスの起動時間もテストのポイントとなった。同社では、夜間バッチの処理中にデータベースをはじめ、さまざまなシステムのメンテナンスを実施しており、その際に業務ジョブが誤動作しないようにスケジューラサービスを停止している。「夜間バッチが終了してから5分以内にスケジューラサービスが起動する必要がある」と日下部氏は説明した。

　検証の結果、当初のシステム構成では、秒間20秒のジョブ実行数では、ジョブの起動に遅延が発生した。1秒当たり10件以上のジョブを起動すると、遅延が発生し始め、実際には1秒当たり6件以下のジョブ数が適切だと分かった。

　スケジューラサービスの起動に20分かかることも判明。起動時間を短縮するには、起動時にスケジューラサービスが読み込むジョブの件数と、保存されている実行履歴の情報量を減らす必要があった。

粘り強い試行錯誤でメインフレームに匹敵する安定稼働を実現

　この性能テスト結果を踏まえ、本番環境では、Xeon E5630の4コア／2.53GHzを2つの計8コア、メモリは16Gバイト、スケジューラサービスは予備も含めて6つに増強した。

　実行履歴数も見直し、当初は1律で10世代のジョブの実行履歴を保存していたが、チューニング後は1日1回のジョブは3世代まで、1日複数回（おおむね2～3回）のジョブは10世代までとした。これにより、スケジューラサービスの起動時間を短縮した。後続ジョブネットを呼び出す場合には時間差を設けることで、処理の集中を見直した（図3）。

　「システムの刷新を進める途中、われわれの基幹システムは本当に動くのかと悩んだが、粘り強く試行錯誤を繰り返した結果、今ではメインフレームに匹敵する安定稼働を実現した」と日下部氏は締めくくった。