Networld Access to the Cloud Computing

Home > NetApp > 導入事例 > エプソントヨコム

導入事例インデックスへ

導入事例  ： エプソントヨコム

2011.09.01

「損失データ=ゼロ・復旧時間=3時間」を達成
NetAppのレプリケーション機能が東日本大震災から重要データを救った！

詳細な資料はこちらからPDF（884KB）

東北地方を中心に壊滅的な被害をもたらした東日本大震災。水晶デバイスやセンサの開発・製造を手がけるエプソントヨコム株式会社様（ 以下、エプソントヨコム）でも、大きな影響がありました。福島第一原発から直線距離で16kmに位置する福島事業所が、避難指示区域に指定されたのです。これにより、重要なデータを納めたサーバに近づくことができず、データを取り出すことも不可能に。しかし、同社では、直前にネットワールドが提供したNetApp社製ストレージ「FAS2020」をファイルサーバとして導入し、拠点間レプリケーション機能を活用したディザスタリカバリシステムを構築していました。この機能により、重要な業務データを一切失うことなく、3月14日正午には東京本社のバックアップ機でシステムを再開することに成功しました。

世界トップシェアを誇る水晶デバイスのエキスパート

東京都・日野市に本社を置くエプソントヨコムは、水晶デバイスや各種センサなどの開発・製造を手がける企業である。普段の生活で直接目にすることこそ少ないが、多くの工業製品が水晶デバイス抜きには成り立たない。携帯電話やデジカメ、テレビ、自動車など、その例を挙げていくときりがないくらいだ。同社はこの分野でグローバルトップシェアを誇る世界的なリーディングカンパニーである。
同社の情報システム構築・運用を担当するセイコーエプソン マイクロデバイス事業本部デバイス情報化推進部 課長 征矢 英昭氏は「長年にわたり培った小型化・高集積技術が我々の強み。IT部門でも情報インフラのグループ最適化を推進し、リードタイム短縮やコスト削減を下支えしています」と説明する。

ファイルサーバをNetAppで統合 拠点間でのレプリケーションも実施

同社では2010年春より、全国各地の製造拠点に導入されているファイルサーバの統合・再構築プロジェクトに着手した。その背景について、セイコーエプソン マイクロデバイス事業本部 デバイス情報化推進部 主任 八代 立氏は、「以前利用していたWindowsベースのファイルサーバは信頼性が低く、しばしば障害によるトラブルが発生していました。またバックアップもテープベースだったため、システムの復旧やデータのリストアにかなりの時間が掛かっていました」と振り返る。　
拠点のファイルサーバには、設計データや技術資料、生産計画を立案するための基本情報など、重要な業務データが数多く蓄積されている。「こうしたデータが使えなくなると拠点の業務にも支障が出てしまうため、高信頼で安定的なストレージ基盤を早急に構築する必要があると感じました」と征矢氏は語る。　
そこで同社では、長野県・富士見事業所の開設を機に、既存のファイルサーバ群の再構築を実施。ネットワールドが提供するNetApp社製ストレージ「FAS2020」シリーズを富士見事業所、福島事業所に2台ずつ導入し、2010年10月より本稼働を開始させた。また、2011年2月には、宮崎事業所にも2台のNetApp FAS2020が導入されている。　
八代氏は製品選択のポイントについて「NetAppには、SnapShot機能とレプリケーション機能『SnapMirror』が備わっていますので、テープベースだったバックアップ運用をDisk to Diskに切り替えることができます。また、別々の拠点に筐体を配置することで、簡単にディザスタリカバリが行える点も魅力でした」と語る。

震災当日のSnapMirrorが成功「RPO＝ゼロ」を実現

導入当初は2台のNetAppを同一拠点内に設置し、ローカルレプリケーションを行っていたが、翌2011年よりバックアップ機を別の拠点に移す作業を開始。1月に福島事業所のバックアップ機を、2月に富士見事業所のバックアップ機を、それぞれ日野本社へ移設した。これにより、福島−日野間、富士見−日野間でディザスタリカバリが行える環境が実現した。　
「SnapMirrorは差分転送や重複排除機能に対応しており、転送するデータ量を減らすことができるため、回線がそれほど太くない拠点でも安心してレプリケーションが行えます。転送速度も高速で、10Mbpsの回線を80％に帯域制御した環境において、約8.4GBの差分データを3時間あまりで転送できます」と八代氏は説明する。そして、福島事業所のバックアップ機を移設したことが、2ヶ月後に発生する東日本大震災において、大きな意味を持つことになった。　
「地震が発生したのは、ちょうど主要拠点をつないだ遠隔会議を行っている最中。急遽会議を中止し、それぞれサーバルームの状態確認に走りました」と征矢氏は振り返る。幸い、機材が倒れるなどの被害はなかったが、安全確保のために従業員は一時建屋の外へ避難。福島事業所では、この時サーバルームをはじめ何箇所かのブレーカが落ちてしまったという。　
その後、大きな余震もしばらく続いてはいたが、ある程度安全が確認できたため、福島事業所でもシステムの通電を再開した。　
ところが、翌12日、福島第一原発の事故という想定外の事態が発生する。これにより、発電所から20km圏内に位置する福島事業所は避難指示区域に指定され、施設内に立ち入ることが不可能になった。避難にあたり事業所内の電源を落としたため、状況がまったく分からなくなってしまったのだ。　
しかし、11日にシステムの通電を再開していたことが功を奏した。「13日に日野本社のNetAppのログをチェックしたところ、11日夜間のSnapMirrorが成功していることが確認できました」と八代氏。つまり、震災当日も含めた全ての業務データが、無事日野本社のNetAppへレプリケーションされていたのだ。ディザスタリカバリでは、データ損失の許容度を測る指標としてRPO ( ※1 )が用いられるが、今回のケースではRPOはゼロ。完全なデータ保護を実現できたのである。

スピーディな業務復旧が事業継続と雇用維持に寄与

業務復旧に向けたアクションも素早かった。週明けの月曜日である14日、八代氏が日野本社へ出社し、バックアップ機への切り替え作業に取りかかった。　
「復旧の手順書などは作成していましたが、まさか実際に行う日が来るとは思わなかった。バックアップ機に万一のことがあればもう後がありませんので、さすがに緊張しました」と八代氏は語る。復旧作業を確実に行うために、ネットワールドのサポートも活用。八代氏は「操作の手順や方法など、細かい部分の確認が行えたのは非常にありがたかった」と続ける。　
バックアップ機への切り替え操作自体はそれほど複雑なものではなかったが、ミスなく作業を行うために入念な確認を実施。それでも、14日の昼過ぎには、全社に対してバックアップ機を公開した。ディザスタリカバリのもう一つの指標であるRTO ( ※2 )でいえば、約3時間(土日除く)で業務復旧に成功したことになる。　
「福島事業所の従業員は、原発事故により福島事業所が閉鎖され、再開の見通しが立たないため、他の拠点に異動して仕事を続けることになります。今までの業務データがすぐに使えるということは、全社的な事業継続の面でも、被災地の従業員の雇用維持という面でも、非常に重要な意味を持っているのです」と征矢氏は語る。　
もっとも、ここで事業継続に向けた対応が終わったわけではなかった。無事稼働を果たした日野本社のバックアップ機だが、今度は計画停電の影響を受けるおそれが出てきたのだ。　
「バックアップ機を中部電力管内の伊那事業所（長野県）へ移すことにしたものの、物流機能や道路事情が大混乱しており、平時のように配送業者を手配することもできない。幸い、当社では、日野と長野方面の事業所を結ぶシャトルバスを運行していますので、これに我々がNetAppを抱えて乗り込みました」と八代氏は苦笑する。伊那事業所での接続作業も3時間程度で終了し、夕刻発の帰りのバスに乗って帰ってこられたとのこと。「こうした作業が比較的簡単に行えるのも、NetAppの良さですね」と八代氏は語る。　
とかく大掛かりなイメージがつきまとうディザスタリカバリだが、今回のケースではNetAppの機能だけで充分なデータ保護が実現できた。「非常時は平常心で作業できるとは限らないため、複雑な仕組みを作ってもうまく機能しないと痛感しました。こうしたシンプルな仕組みの方がむしろ有効ではないでしょうか」と八代氏。同時に「こういう機能は、実際には使われずに、無駄な機能じゃないかと批判されているほうが幸せなのだと思います」と被災した実感を語る。　
同社ではビジネスの復旧、復興に向け、今後も様々な活動を展開していく構えだ。「IT面から事業を支える我々としても、会社の競争力強化に貢献していきたい。ネットワールドの提案やサポートにも引き続き期待しています」と征矢氏は語った。

※1 ) RPO　Recovery Point Objective：目標復旧時点
※2 ) RTO　Recovery Time Objective：目標復旧時間

page up