みやぎ生活協同組合いわて生活協同組合生活協同組合共立社の3生協は,共同運用する商品発注システムを,UNIXからWindows 2000の最上位版であるWindows 2000 Datacenter Server上に移行する。
■UNIXアプリケーションの移行は,マイクロソフトのServices for UNIXを使い,既存のプログラムをできるだけ生かす形で実現する計画である。
■既存システムの移行と同時に,自動発注や電子発注台帳システムなど,商品発注や在庫管理を効率化するシステムも新規開発する。

図1●3生協の商品発注システムの概要
各店舗からの発注データは,メインフレーム や集配信サーバーを介して,発注サーバー(EOS サーバー)に送られる。このデータを発注サーバーで発注用に加工し,発注先に提供する。
 みやぎ生活協同組合,いわて生活協同組合,生活協同組合共立社の3生協は,共同運用するUNIXの商品発注システムを,2000年9月に提供が始まったWindows 2000 Datacenter Serverに移行する(図1[拡大表示])。開発を担当するのは,宮城県仙台市に本拠を置く生活協同組合連合会コープ東北サンネット事業連合。2001年初頭に一部システムを,同年4月には中核となる電子発注(EOS:Electric Order System)サーバーを本番稼働させる予定である。

 3生協の商品発注システムを大まかに分けると,(1)商品の発注処理を行うEOSサーバー,(2)商品の原価や特売情報などを格納する商品マスター・データベース・サーバー,(3)商品の売上実績を格納する販売実績データベース・サーバー ――がある。

 いずれも構築から年月が経っており,性能を強化する必要があった。新システムはそれを達成した上で,自動発注などの新機能を装備する。

 EOSサーバーは,店舗から来る発注データを,商品マスター・データをもとに,発注先に渡すデータに変換する機能を持つ。3生協では,店舗増などで,EOSサーバーの負荷が増大していた。発注数は3生協合わせて,1日10万件を超えることもあるという。

 EOSサーバー自体は生協ごとに分かれており,負荷を分散していたが,同じ処理を平行して行うバックアップ・サーバーが3生協で1台だった。そこでは,処理能力が限界に達し,発注先に約束した時間までに処理を完了するのが困難になりつつあったという。2001年にはさらに店舗を増やす計画があり,サーバーの増設か既存サーバーの増強が必須になっていた。

コスト重視でOSの移行を決定

 当初は,日本アイ・ビー・エムのAIXで構築した既存のUNIXシステムをベースにサーバーの増設や性能強化を検討した。それが2000年の春ごろから,Windows 2000 Datacenter Serverが候補に上がってきた。UNIXとWindowsの両方を候補にシステムの移行を検討した結果,2000年7月にWindowsへの移行を決めた。

 「最も安くて性能が高いものを選んだら,Windowsだった。もちろんUNIXからUNIXへの移行のほうが楽だったが,コストを重視した」(サンネットのシステム部開発課システムエンジニアの高久亨一課長)という。費用は,既存のサーバーの残リースやアプリケーションの移行を考慮しても,従来のリース料・保守料の範囲内に抑えることができた。

 ダウンの許されない発注システムでWindowsを採用することに対しても,「Datacenter Serverでは,マイクロソフトが99.9%以上の稼働率を保証するとしていた。信頼性の問題はないと判断した」(サンネットのシステム部開発課白根孝夫課長)。

事前検証で処理性能を確認

図2●3生協が導入したサーバー機の構成
サーバー機は日本ユニシスのES7000 を2 台導入した。ES7000 は,1 台のサーバーを4 プロセッサ単位で論理的に分割して,複数のOSを搭載できる(パーティショニング機能)。今回搭載したWindows 2000 Datacenter Server は6 システム。Microsoft Cluster Service を使ってクラスタ化し,信頼性を高めている。

 「サーバー機である日本ユニシスのEnterprise Server ES7000の拡張性や信頼性も決め手になった」(高久課長)。ES7000は,最大32プロセッサを搭載可能なハイエンド・サーバーである。3生協は,16プロセッサを搭載するES7000を2台導入した。

 ES7000は,搭載するプロセッサ4個の「サブポッド」という単位でハードウエアを論理的に分割,それぞれに別々のOSを搭載できるという特徴を持つ。今回3生協では,2台のES7000に6つのDatacenter Serverを導入する(図2[拡大表示])。そして,OSが標準装備するクラスタ・サービスを使って3組のクラスタを構成し,信頼性を高める。

 処理性能については,最も負荷のかかるEOSサーバーのアプリケーションをテスト環境に移行して検証した。テストには,本番のサーバー機よりも下位機種である日本ユニシスのES5085Rを使った。その結果,既存システムで約1時間かかった発注処理が,5分弱で完了することが分かった。これを基に,本番機の仕様を確定した。別々だったいわて生協と生協共立社の発注サーバーの機能を,1台に統合することも可能だった。

ドキュメントの不備で移行に苦労

 EOSサーバーのアプリケーションは,極力手を加えず移行した。もともとはUNIXサーバー上のシェル・スクリプトからPL/SQLやC言語で記述したOracleアプリケーションを呼び出す仕組みである。Windows標準のバッチ・ジョブとして一から作成し直す方法もあったが,3生協はマイクロソフトのWindows Services for UNIX 2.0上で,UNIXのシェル・スクリプトを動かす方法を採った。

 Services for UNIXのUNIXシェル/コマンド機能を使うと,一般的なUNIXコマンドおよびユーティリティをWindows 2000上で実行できる。これでUNIXのシェル・スクリプトを大きく変更せずに,移行できた。「Services for UNIXを介して実行することによる性能低下もない」(移行作業を担当した日本ユニシス東北支店システム室の田中敦チーフSE)という。

 日本オラクルのPro*Cで作成していたC言語プログラムは,マイクロソフトのVisual C++でコンパイルし直した。環境変数やパスなどの修正はあったが,変更作業は最小限に抑えることができた。田中氏は,「OSが変わるよりも,Oracleのバージョンが7から8に変わったことの方が,違いは大きかった」と話す。

 苦労したのは「既存システムのドキュメントが整備されていなかった」(白根課長)こと。元のシステムは,日本アイ・ビー・エムとサンネットの共同開発だが,必要な情報があまり保存されていなかった。サンネットは,ドキュメントを整備し直した。

発注処理効率化の機能を新規開発

図3●開発中の商品発注用端末
Windows 2000 のターミナル・サービスを使ってサーバーにアクセスする。通信は無線L A N で行う。

 新システムでは,新しい機能も導入する。自動発注システムはその1つ。商品の売り上げから在庫量を管理するとともに,過去の販売実績を基に,商品を自動発注する。店舗での品切れをなくすのが目的だ。同時に店舗側の発注の手間も減らせる。3店舗に限定してテストを開始している。

 また,現在紙の発注台帳で行っている一部商品の発注を電子発注台帳に置き換える。EOB(Electric Order Book)と呼ぶこのシステムでは,過去の発注/売上実績,天気などを,発注数量の入力時に表示させて数量決定の参考にする。やはり商品を適正に発注するのが狙い。「紙の台帳では,過去の情報は2週間分しか反映できない。電子化してデータに継続性を持たせることが重要」(高久課長)という。

 EOBサーバーへの発注には,タッチ・パネル式の無線端末を採用した(図3)。Windows 2000のターミナル・サービスを利用してEOBサーバーにアクセスする。アプリケーションはサーバー側で動かし,端末から入力作業を行う仕組みだ。サーバーOSはWindows 2000 Advanced Serverで,ターミナル・サーバー機能を拡張するシトリックス・システムズ・ジャパンのMetaFrameを利用する。

SQL Serverも新たに採用

 新システムのデータベース管理システムにはOracle8iとSQL Server 2000の2種類を採用する。基本的には,既存システムから移行する部分に,互換性を重視してOracleを採用する。新規開発するEOBサーバーも,商品マスターDBや発注サーバーとの連携を考慮し,Oracleを採用した。

 一方,自動発注サーバーと,売上実績DBサーバーでは,SQL Serverを採用する。「テーブルへのローディングが高速なほか,マイクロソフトのOffice製品との親和性も高い。我々のつたない技術での評価では,SQL Serverの方が優れている」(白根課長)と判断した。SQL Serverの機能を使って売上分析も行う予定だ。

(森重 和春=morishig@nikkeibp.co.jp)