東洋合成工業株式会社様 導入事例

世界トップクラスのシェアを持つフォトレジスト用の感光性材料（感光材）と、高純度溶剤や香料材料などの化成品、並びに首都圏の化学品物流を支えるロジスティックビジネスを展開する東洋合成工業。創業65年を迎える老舗の化学メーカーである。フォトレジスト用感光材は、液晶ディスプレイや半導体集積回路を製造する際に欠かせない材料で、最先端の感光材に向けた技術開発にも力を注いでいる。

その東洋合成工業では、2015年に基幹系システムをクラウドに移行することになり、同時に障害や災害に対応するための冗長構成を採用することにした。東日本大震災の教訓を生かすための、安全安心のシステム構築である。東洋合成工業で情報システムを担当する同社 情報生産性向上推進部 担当課長の小林昭彦氏は、こう語る。「東日本大震災の頃は、本社と工場が千葉県市川市にありました。当時はクラウドを利用しておらず、サーバーも工場と同じ敷地にある本社に設置していました。震災ではサーバーラックが振動でずるずると動いてしまい、接続するケーブルが途切れるギリギリまで移動していました」

ケーブルの長さに余裕があったためサーバーの稼働を継続できたが、もう少し動いていたら情報システムに大きなダメージが加わるところだった。「工場は基本的に24時間動いていますから、基幹系システムには止められないものが多く、災害対策の必要性を強く意識するようになりました」（小林氏）。

SAPサーバーの保守切れでクラウド移行を決断

その後、2007年頃になると、内部統制報告制度のJ-SOXへの対応が求められるようになり、基幹業務システムとして使っていたGLOVIA/Process C1の後継システムを選定することになった。何社からか提案をもらった中で、J-SOX対応がしっかりしていたことから独SAP社のERP（統合基幹業務システム）「SAP」を導入。時は流れ、2015年頃にはSAP導入時に採用したサーバーが保守切れのタイミングを迎えた。「データはかなり溜まっていましたし、サーバーの入れ替えの費用もかさむことから、システムの刷新を考えました。オンプレミスとクラウドの双方で複数の提案をもらい、最も要件に合った富士通の提案でマイクロソフトのAzureに移行することにしました」（小林氏）。

採用したサービスは、「FUJITSU Cloud Service for Microsoft Azure（導入当時の名称はFUJITSU Cloud Service A5 for Microsoft Azure）」アプリ移行支援ツールPanayaによる検証工数の削減と、富士通のAzureサービスへの高い信頼感が決め手となった。クラウドへの移行の背景には、オンプレミスの保守の手間からの解放や、スケールアップ対応の柔軟さのほか、東日本大震災で体験した災害対策の考えもあった。敷地内にあったサーバーが震災の揺れで動いてしまい、トラブルになる寸前だったことがクラウドへの移行を後押ししたともいえる。

クラウドサービスとしてAzureを選択したのは、ベンダーロックを避けるためという理由があった。当時から東洋合成工業では、グループウエアやワークフローなどの情報系のシステムにすでにAmazon Web Servicesを利用していた。それだけに、生産、会計、在庫、販売など基幹にシステムを担うSAPのシステムは、情報系と同じAWSによるプラットフォームではなく、異なるプラットフォームとなるAzureを使うことでリスク分散を図る考えだ。AWSをすでに利用していたこともあり、Azureを利用した基幹業務システムのクラウド移行には大きな障壁はなかった。小林氏は「Azureのリージョンが東京であることを確認したりはしましたが、社内にクラウドに対する不信感はなく、スムーズに移行は進められました」と当時を振り返る。

2重、3重のバックアップ体制で業務を止めない仕組み

Azureへの移行に当たって、システム障害や災害時に対応できるようなバックアップ体制を整備した。「SAPには、業務で利用するほぼ全部のデータが乗っています。SAPが止まると生産も止まりますし、それが2日、3日と続いたら、入荷／出荷はもちろん、会計の支払い、請求にも困ってしまいます。止められないシステムなのです」（小林氏）。

そこで、まずAzure上のSAPのバックアップ体制を整えた。1つがAzureの東日本リージョンに設けた本番系のシステムの日次のバックアップ。これにより定常的なデータのバックアップ体制を確保し、さらに東日本リージョンで重大なトラブルが生じたときのために、Azureの西日本リージョンの待機系システムに週次でデータをバックアップしている。仮に東日本リージョンのシステムがダウンしても、業務の継続にできるだけ支障がないようにする配慮である。「しかし、バックアップはあくまでもバックアップです。基本的には冗長化して本番系のシステム自体が止まらないようにする必要があります。情報系で利用していたAWSでは冗長構成を採るときに共有ディスクが利用できたのですが、Azureでは共有ディスクが使えませんでした。そこで、データをレプリケーションできるサイオステクノロジーのDataKeeperを利用することにしました」（小林氏）

DataKeeperを使うことで、冗長化したSAPの本番系システムにつながるそれぞれのストレージの間でクラスタ構成を作り、データを常にレプリケーションして整合性が取れた状態を保つことができる。共有ディスク構成が使えないAzureの上でも、共有ディスクを利用している場合と同等の可用性を保つことが可能になる。「Azureのサービスを利用している富士通に問い合わせたところ、DataKeeperの提案がありました。要求に対する十分な性能と機能を持つことがわかったので導入することにしました」（小林氏）。

東日本リージョンの本番系システムを冗長構成にすることで、トラブルや災害への第一段階の対応を行う。その上で、冗長化した構成でも復帰できない場合には東日本リージョンの日次のバックアップを利用、Azureの東日本リージョンに深刻なダメージがあったような場合には西日本リージョンの週次のバックアップを用いるという3段階の守りを固めた。

こうしたバックアップ体制を採ってAzureで基幹業務システムを稼働させるようになってから、東洋合成工業の基幹業務システムは大きなトラブルには見舞われていないという。「稼働当初はたまにフェイルオーバーすることがありましたが、その際も問題なくフェイルオーバーが実行されていました。現在ではフェイルオーバーも起こることはなくなり、手離れがいいシステムになっています」と小林氏はこのバックアップ体制を高く評価する。

フルバックアップ時のエラー通知でDataKeeperの“作動”を確認

そんな中で、実はドキッとしたことがあったという。それは、DataKeeperからのエラー通知メールだった。「クラスタリングしているEドライブに何かあるとメールで通知が来る設定にしているのですが、ときどきエラーメールが届き、最初は何が起こっているのかと心配しました。ところが、これは週に1回マシンを落としてフルバックアップをしているときに、クラスタリングしているディスクを1台ずつ立ち上げることに起因していました。1台のディスクが立ち上がったとき、もう1台が起動していないと、“片方のディスクがない”ことをDataKeeperが通知してくれていたのです」（小林氏）。原因がわかってからは、このエラーメールをDataKeeperがきちんと作動していることの知らせと思えるようになったという。

今後の中期対応としては、SAPの現行バージョンのサポート切れが起こる「SAPの2025年問題」への取り組みが求められるという。実際には、まだ具体的な方針を検討する以前の段階だが、小林氏は「新しいアーキテクチャのS/4 HANAに移行したときに、クラスタリングする必要性があればDataKeeperを採用すると思います。それだけDataKeeperを信頼しています」と語る。

元々現場で働いていた小林氏だけに、情報システムの担当が長くなった今でも現場とのコミュニケーションはスムーズだ。現場が情報システムに何を求め、どんなスパンで対応していくことを求めていくかが、そのコミュニケーションから肌で感じているようだ。「現場のシステムは止まったら困るものが多いですから、信頼のおけるツールを選ぶことが情報システム担当の役割だと思います」。そう語る小林氏にとって、DataKeeperは無口だけれども信頼できる静かな相棒と言えそうだ。

東洋合成工業株式会社様 導入事例PDF版はこちら