第8回 SDS導入のきっかけと効果、あえて一斉導入しなかった国内商社の場合データで戦う企業のためのIT処方箋(1/2 ページ)

前回はSDSの一斉導入に踏み切った欧州のユーザー企業事例をご紹介しました。今回は“あえて”一斉導入をしなかった国内の専門商社のケースを取り上げてみます。

» 2016年05月24日 08時00分 公開
[森本雅之ITmedia]

あえて一斉導入せずの理由

 専門商社のA社がストレージ基盤の改善に取り組んだのは、度重なる災害などを契機とした経営課題に、ビジネスの継続性へ対する要求の高まりがあったからでした。自社だけでなく、商社として取引先や仕入先までを考慮すれば、基幹業務の保全ではなく業務復旧を担保する必要があります。多種多様な基幹システムに対して統合的な管理基盤の構築が必要と判断しました。

 とはいえ、各拠点でそれぞれ別々にシステムを管理、運用していた関係から、OSやストレージなどシステム環境が多種多様であり、簡単には統合できない状況でした。そこで全社横断的にプロジェクトを立ち上げ、課題の整理と採用テクノロジーの選定を進めることになりました。

 導入課題には、大きく次の点が挙がりました。

  • 複数のデータセンター構成:単一データセンターで一元管理している場合、被災や建屋障害時の影響を回避できない
  • ストレージ環境の一元管理:管理者が限られるため、複数製品の組み合わせによる運用負荷がリソース上耐えられない
  • 実装コスト:ストレージ製品に対するハードウェアや専用ソフトウェアに対する投資費用以外にも、継続的に発生するネットワーク専用回線費用が高額になる
  • 将来のシステム拡張への対応力:既存環境に特化したシステムでは、対応範囲の拡大が難しい

対策は?

 全社プロジェクトとして検討した結果、あるべき姿としては「統一されたシステム基盤による汎用サービスの提供がベストである」という方向性が共通認識して得られたものの、限られたメンバーで運用すること、災害復旧(DR)側のデータセンターの要員準備といった人的な要件など、すぐに変えられない課題も明確になり、まずは運用負荷の削減を主軸として選定を進めることになりました。

 そのため、既存のサーバやストレージ基盤を大きく変えることなく追加で導入ができること、汎用性が高いことが最優先項目になりました。加えて、既存の各種アプリケーションに影響なく利用できることも、現場側の負担を減らす(増やさない)ためには必須要件でした。コスト的にもできる限り負担を押えたい、という経営層の意向もありました。

 これらの要件を考慮すれば全面刷新をできないことから、まずはデータ保護の要件面から統一する、という段階的な導入を決めました。対策としては次の通りです。

  • 現行環境に対するデータ保護、DR対策として自動化が可能なソフトウェアを利用する
  • DRセンターでは原則として全て仮想化基盤で構築、運用し、将来は本番系も全て同様の構成として統合基盤とする
  • データベースやコミュニケーション基盤、ERP、EDIといった主要な基幹システムを第一フェースの対象とし、その後数年を通じて順次対象を拡大する
  • 復旧のRPO(復旧ポイント目標)やRTO(復旧時間目標)はできる限り最新の状態で利用できるよう全て伝送と自動化でまかない、極力人手を排除する
  • 現場やセンターの担当者に向けて、運用イメージが分かるよう基本的なアーキテクチャから教育を実施して、統合管理の運用効率を改善する

 A社ではなかなか眼鏡にあう製品が見つからず、選定は多岐に、かつ長期にわたってしまいましたが、最終的にはSDSのアーキテクチャを持つデータ保護基盤の採用に至りました。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ