1．取り組みの背景

住友ゴムグループは，独自のゴム技術を活かしたタイヤ・スポーツ・産業品事業を世界中に展開しており，2020年末時点のグループ連結子会社・関係会社は約100社，連結従業員数は約40,000名の規模である［1］．

国内事業を支える主要な181システムは，サーバ840台，ネットワークやディスク装置などの機器4,000台で構成されるITインフラに支えられている．

1990年代，NECメインフレーム時代の当社のITインフラは，本社である兵庫県神戸市にあったが，1995年の阪神淡路大震災で大きな被害を受けたため，大阪千里のオフィスビル（以下，大阪オフィス）を借りてITインフラを作り直した．以後，大阪オフィスでメインフレームからオープンシステムへのダウンサイジングや，サーバ仮想化，災害対策としてデータ遠隔地保管などを行ってきた．

しかし空調設備や非常用電源設備等の老朽化により大阪オフィスで大きな更新投資が必要になることを契機に，抜本的にITインフラを見直す「次期ITインフラ構想」を2017年から立ち上げた．

 

2．次期ITインフラ構想策定

2.1　目標設定

2017年当時，大阪オフィスは設立から22年が経過しており，空調設備や非常用電源設備は，交換かオーバーホールの選択を迫られていた．いずれの選択肢もコスト試算の結果は数億円と高額で，機能・コスト・リスクの面で投資根拠に乏しいため，担当者は「どうしたものか」と頭を痛めていた．そんな折，NECが兵庫県に最新型のデータセンタを開設していることを知り，思い切って新しいデータセンタへITインフラを移設すれば問題を解決できるのではという選択肢が浮上した．

また同年は，企業のクラウド利用が増加し，ITインフラをクラウドへ全面移行する事例が盛んに喧伝されたころである．弊社事業部門でもIoTやビッグデータといった，クラウドを前提としたアプリケーションが話題となる状況で，クラウド活用の在り方と合わせて「次期ITインフラ構想」の検討が必要だった．

その中で検討チームは，次期ITインフラに求める要件を以下に整理した．

• ①高い可用性：タイヤ生産工場は3交代制で24時間稼働しており高い稼働率が求められる．販売・物流システムも同様で，これは必須要件である．
• ②新技術に対応：IoTやビッグデータなどの新しいワークロードに対応できること．
• ③コスト最適化：要求に応じて柔軟にリソースの拡張縮小ができること．

2.2　課題整理

まず2017年当時のITインフラを説明する．

当時は，メインデータセンタ（以下，メインDC）を関西，災害対策用データセンタ（以下，災対DC）を関東に保有しており，平常時は各拠点・事業所からメインDCの業務システムを利用している．メインDCのバックアップデータを災対DCへ複製することで，大規模障害時にシステムを災対DCでリストアできる構成としている．

またメインDC被災時はネットワークの経路設定を変更することで，災対DCでメインDCと同じIPアドレスがそのまま使用できる仕組みとなっている．ただし，災対DCは平常時にネットワークから隔離される．

2.2.1　課題

在るべき姿と現状を対比すると，メインDC・災対DCそれぞれに課題があった．

メインDCの課題は，空調設備や非常用電源設備が古く2020年1月以降は保全部品が確保できないこと，仮想化により機器の高集約化が進んだ結果サーバラックの約半数が使われていないこと，またリソース調達が数年分の先行投資となるため余剰リソースが生まれること，IoTやビックデータといった新技術への需要を満たす基盤（運用・スキル・体制）がないこと，最後にデータセンタとして作られた建物と比較して耐震性能や設備に劣ることである．

一方の災対DCの課題は，個別のシステム復旧が行えないこと，大規模障害に備えてメインDCと同量のリソースを保持しているが，平常時はネットワークから隔離しているために使用されないことである．

メインDC，災対DCの課題を表1に示す．

2.3　対策検討

大阪オフィスと災対DCには前述の表1に述べた課題があるため，これらを一体に捉え，次期ITインフラ構想について3つの選択肢を整理した．

第1の選択肢（付帯設備更新）は，付帯設備を新しい機材に入れ替えることで，老朽化問題を解消し大阪オフィスを継続利用する．同時に災対DCのネットワーク構成を見直し，平常時も災対DCのリソースを利活用できる仕組みとする．他案に比べ実施内容が簡素で変更に伴うリスクが小さい．ただし，大阪オフィスの耐震強度不足は解消されない．

第2の選択肢（クラウド移行）は，大阪オフィスと災対DCの全システムをパブリッククラウドへ移行することで，すべての課題解消を図る．クラウドの運用実績が社内にないことから，構成変更に伴うシステム改修コスト，並びにリスクは大きいが，外部ベンダの協力を得ることで補う．しかし，クラウドの仕様策定とシステム移行には数年を要する．

第3の選択肢（新DC移設）は，大阪オフィスの機器を耐震性能に優れる別のデータセンタへ移設することで，付帯設備老朽化や耐震強度不足の課題を解消する．未解決の課題は，機器の移設で可用性を確保した後に，クラウド利用を本格的に進めることで解消する．また同様に災対DCもクラウド化を進め，現在の全システム一括切り替え方式では対応できない小規模なシステム障害に対応していく．

これら3つの選択肢を評価した結果を表2に示す．

クラウド移行と新DC移設は，表2の①高可用性②新技術対応③コスト最適化をすべてクリアしており，どちらも次期ITインフラの構想に適している．しかしクラウド移行は，2020年1月までに大阪オフィスの付帯設備老朽化を解決できない．一方の新DC移設はスケジュールの工夫で大阪オフィスの付帯設備老朽化を解決できる．また，移設のリスクは，計画・実行時のリスク軽減策で対処できると判断した．

このような検討を経て次期ITインフラ構想には「新DC移設」案を選択した．

次期ITインフラ構想の概略を図3に示す．

2.3.1　実施に向けたスケジュール

前述の次期ITインフラ構想実現に向け，新DC移設，災対DCクラウド化，クラウド利用本格化の3本柱で活動を進めることとし，2018年4月に経営会議で承認を受けた．

以降は表3のスケジュールで，それぞれ実施計画の検討を開始した．

 

3．メインデータセンタの移設

3.1　移設機器棚卸と移設先DC選定

次期ITインフラ構想が承認され新DC移設が決定したため，既存のITインフラ運用の知見が豊富な6名を選抜して移設推進チームを結成，実行計画の立案に着手した．まず移設先のデータセンタを決定するため，9社に提案を依頼した．各社の提案を比較した結果，ファシリティとコストに最も優れていたNEC神戸データセンタ（以下，神戸DC）を新たなメインデータセンタに選定した．

続いて，神戸DCへ移設する機器を確定するために，大阪オフィスで機器の棚卸を行った．管理者の世代交代で資料が散失した機器や，使途不明な備品が数多く見つかり，棚卸の完了までに2カ月もの時間を要した．最終的に表4に示す機器を移設対象として選別した．

3.2　システム停止時間の調整

大阪オフィスから神戸DCへ機器を移設するということは，機器の停止，すなわち業務システムの停止が発生する．当初我々は8月の夏季休暇中に業務システムを1週間停止する前提で利用部門との停止調整に臨んだ．しかし，中国，タイ，トルコ，南アフリカ，アメリカ，ブラジルといった海外拠点が通常の営業日であることを考慮すると，業務システムの停止は2019年8月10日0時（UTC+9）からの72時間が限界との結論に達した．

この限られた時間内に，機器の解体，搬出，搬送，組上げ，各種結線，動作確認を完了して業務システムを起動しなければならない．

我々は，①移設対象の最小化，②移設作業の効率化，③障害対策の3点から移設によるリスク軽減を図った．

3.3　移設リスクの軽減

（1）移設対象の最小化

移設計画は1年以上に渡るため，この間のシステム開発に伴うサーバ増強は避けられない．しかし移設対象機器の増加や，移設後の動作確認対象が増えることは極力避けたい．そこで，事前に神戸DCへ仮想化基盤を構築することで，移設当日までの新規サーバ構築を引き受ける．同時に，既存の仮想サーバを事前に移行・動作検証することで移設当日の作業量軽減を図ることとした．また仮想化基盤が神戸DCにあることで，移設時のリスクとして想定される事故や故障時のバックアップとして活用できると考えた．

（2）移設作業の効率化

移設作業は，（A）大阪オフィスでの機器の解体，搬出，（B）搬送，（C）神戸DCでの組み上げ，各種結線，動作確認，の3パートからなる．特に結線をどれだけミスなく効率的に実施できるかが72時間死守に重要と考えた．

そこで，詳細な物理結線図を準備するため，1,000本のケーブル1本1本の接続元と接続先を調査した．これが予想以上に大変であった．たとえば，ネットワーク機器から滝のように伸びている配線を1本ずつケーブルテスターで辿って接続先を追跡し，機器の「2番ポート」に接続されていることを確認する．しかし，同種のサーバ機器でも型番の違いで，ポート位置に違いがあるため，「2番ポート」「場所はここ」と示すため，装置ごとに背面の写真やスケッチが必要となり，調査と物理結線図の完成までに2カ月間を要した．

（3）障害対策

①搬送時のリスク軽減対策

移設時のデータロストは何としても避けねばならない．ストレージなどの重要な機器は冗長構成を採用しているが，万一の事故で搬送中に両方の機器が失われるリスクは避けたい．また何らかのトラブルで機材が届かなければ，72時間で移設が終わらない恐れもある．こうしたリスクを軽減するため，以下の3グループを全8便に分散，さらに当日の渋滞や事故も考慮して2通りの輸送ルートを設定した．

• クラスタ構成などの冗長構成システム
• 外部ストレージ筐体とバックアップ装置
• その他サーバやストレージ，ネットワーク機器の正／副

また8月は外気温と湿度が高いため，移設機器の結露対策が必要である．このため神戸DCの敷地内で2時間ほど機器を留めて温度変化による結露を軽減する．

②障害時のバックアップからのリカバリ対策

業務システムの動作確認時に機材の故障が判明した状況を想定して，全サーバのバックアップの取得状況とリカバリ手順の確認を実施した．また移設当日のスケジュールに合わせたシステム停止とバックアップ取得のため，各業務システム担当者と夜間処理やバックアップ処理を調整し，スケジュールどおりに停止できるよう事前に対策する．

 

3.4　移設計画

大阪オフィスの付帯設備（空調設備や非常用電源設備）が保守期限（2020年1月）を迎えるまでに神戸DCへ物理機器を移設するため，表5のスケジュールを計画した．

3.4.1　神戸DCの仮想化基盤構築と仮想サーバ移行

2018年10月に神戸DCの利用契約をNECと交わし，ネットワークの敷設と仮想化基盤の構築に着手した．複数の拠点を同一のネットワークで接続する技術（以下，L2延伸）を利用して大阪オフィスと神戸DC間を接続した後，VMware社のvSphere Replication［2］を活用して，物理機器の移設前に61台の仮想サーバを大阪オフィスから神戸DCへ移行した．

3.5　移設当日

移設当日は，思いのほかスムーズに搬出が進行し，当初計画より2時間程前倒しで作業が進んでいた．一方，予定より早く機器が到着したことで，神戸DC側の作業が追い付かず，搬出を一時的に待機させることがあった．

万全の準備をしたつもりだが，①ネットワーク結線の作業者割当モレ，のような計画モレ，②作業スペース不足，③部品確認不足，のような想定外の事態が発生した．また予想したとおり，④機器故障も起こった．

想定外の問題

• ①ネットワーク結線の作業者割当モレ

  ネットワーク機器への結線内容を作業手順書に記述していたが，パッチパネルとネットワーク機器間，またはサーバ間の結線を行う作業者を明確にしていない個所があり，ネットワークの接続試験が予定より遅れた．

• ②作業スペース不足

  機器の実装や配線を行う数名の作業者が同じラック前に集中するタイミングで，スペースを十分に確保できず，順番待ちが発生した．

• ③部品確認不足

  移設先のラックにストレージを実装する段階で，搭載用ブラケットの取付け用穴が移設前のラックと異なり組付けできないことが判明した．対応部材の調達を待つ時間はないと判断し，急遽重量物用の棚板を手配し，ストレージを棚板の上に結束バンドで固定する対応となった．また，ネットワーク機器と光ケーブルを接続する部品（SFP Module）が想定以上に必要となる問題が発生したが，保守用に確保していた予備部品を割り当てることでことなきを得た．

• ④機器故障

  慎重を期して作業は行われたが，懸念していた機器の故障が5件発生した．しかし機器の移設を事前にメーカー各社へ通知していたため，スムーズに保守作業が行われた．

3.6　まとめ

解体・運搬・搬入は予定していたとおりに進行したが，その後の機器搭載，ケーブル整線，結線，システム起動に想定より多く時間を要したため，2日目に入った段階で進捗に遅れが見え始めた．この遅れを挽回する為に，予備人員を投入する徹夜体制で巻き返しを図った．

約200名を動員した移設対応は，いくつか発生した想定外の問題をすべて解消し，当初計画より3時間早い69時間で全作業工程を終えることができた．

4．災害対策データセンタのクラウド化

4.1　災対DCの課題と対策

メインDCの移設を進めつつ，災対DCのクラウド化に着手した．前述のとおり，災対DCはメインDCが利用できなくなるような大規模障害を想定した設計のため，次の3つの課題があった．

• ①全システム一括復旧のみ（個別のシステム復旧に対応していない）
• ②大阪オフィスと同量のリソースが必要
• ③平常時はネットワークから隔離されており，殆どのリソースが使用されない

障害を受けた範囲に応じて仮想サーバを立ち上げられる環境があれば①②の課題を解決できる．しかし，クラウド移行が困難な物理サーバのリカバリ先である災対DCを完全になくすことはできない．

そこで，セキュリティ被害や小規模のシステム障害であれば，メインDCとペアで動作し，大規模障害であれば災対DCとペアで動作するクラウド環境があれば理想的と考えた．

4.2　VMware Cloud on AWSの検討

2018年4月当時，災対DCの使用率の向上と，コスト削減を検討していた我々は，2017年8月から米国でサービスを開始していたVMware Cloud on AWS（以下，VMC）［3］に着目し，上手くサービスを活用することで，DR用途として必要なときに必要なだけ，最適なリソースを調達できるのではないかと仮定し，VMCの情報収集を開始した．

継続して情報収集を行っていると2018年11月から国内でもVMCのサービスが始まるという情報を得たため，我々が理想と考える災対DCの実現性についてベンダ各社と協議検討を積み重ねた．その結果，以下の要求事項を満たすことが確認できた．

• VMCは平常時，最小構成となる3台で運用し，障害規模に応じて拡張する．
• 平常時はメインDCとVMC間をL2延伸で接続し，小規模な障害はVMCでリカバリする．
• メインDCの大規模障害時には，災対DCとVMC間をL2延伸で接続しメインDCの代用とする．
• メインDCの災対用バックアップデータは，Amazon S3［4］に保存する．障害時にはAmazon S3からデータを取り出しVMCへリストアする．

2019年11月に上記構想をまとめ，表6の計画で構築に着手した．なお，大規模障害時のVMC想定リソースは表7のとおりである．

4.3　構築ベンダの選定

VMCの構築経験を持つ6社にRFPを発行して，構築ベンダの選定を行った結果，技術力・実績・コスト面に優れたA社を選定した．

4.4　構築時の問題

構想どおり，VMCの構築作業はスムーズに進行したが，Veeam Backup & Replication （以下，Veeam）［5］による，バックアップとリストアの目標時間が達成できず，チューニングが必要となった．

（1）神戸DC→Amazon S3バックアップ時間超過

目標復旧時点（RPO）は1日前としているため，日次バックアップを24時間以内に完了しなければならないが，24時間7分とやや超過した．

原因調査の為，神戸DCとAWS［6］間のネットワーク帯域を調べると，使用率が低い状態だった．そのため送信元の神戸DCのネットワーク機器設定および受信先のAmazon S3を調査したが，原因特定には至らなかった．我々が管理する神戸DC側の調査は容易だが，直接見えず，確認できる範囲が限られるAWS側の調査は可能性を潰すのに時間を要した．最終的に消去法で，Veeamの転送ジョブの多重度が低すぎたことが判明，見直し後22時間30分と目標時間に収めることができた．

（2）Amazon S3→VMC リストア時間超過

大規模障害時の目標復旧時間（RTO）は72時間であったが，190時間を要した．

性能に影響する要素は，主に以下4点である．

• Amazon S3のデータ送信スループット
• AWS-VMC間のネットワークのスループット
• Veeam Gateway［7］サーバのスループット
• VMC 仮想ホストのディスクI/O

これらを総合的にチェックし，リストアジョブの同時実行数変更，リストア先仮想ホストの分散という2点を見直したことで上記スループットが改善し，目標復旧時間を大幅に上回る32時間という結果を達成することができた．

問題解決にあたっては環境構築の経験の深いパートナーを選んだことが奏功した．

いずれの問題もAmazon S3やVMCといった自社で管理していない仕組みを利用していることで，問題発生時の原因調査や切り分けが複雑で時間がかかるということを改めて痛感した．

5．クラウド利用の本格化

5.1　クラウドIaaSの構築と構築先の選定

メインDCの移設，災対DCのクラウド化を進めつつ，我々は次期ITインフラ構想で策定したコスト最適化に取り組むため，クラウドIaaSの構築を進めていくことにした．

このクラウドIaaSの構築先として，AWSとAzure［8］を比較検討した結果，情報量が多く，ガートナー社の評価にて国内外でリーダに位置するAWSを選定した．両方に構築する案もあったが，経験不足の我々がいきなりマルチクラウドに臨むのは困難であると判断し，まずは1カ所に絞りしっかりと運用を固めるほうがよいと判断した．

また，構成検討・構築を行うに辺りクラウドの専門知識とノウハウが要求されることから，NECの「クラウド導入支援サービス」［9］を利用することとした．

5.2　計画

2019年6月までにクラウドIaaSを構築する予定とした．また，本格的な利用を始める前に，社内で実績を積む必要があると考え，社内専用システムである人事・経理系システムを同年7月から移行することにした．

5.3　クラウドIaaSの本格利用開始

クラウドIaaSの設計構築，および人事・経理系システムの移行が問題なく完了し，社内実績ができたことから，2021年から本格的にクラウドIaaSをサーバ構築のプラットフォームとして活用する計画を立てた．年内には31台の新規サーバを構築する予定である．

また，クラウドIaaSの更なる利用を促進するため，神戸DCの仮想化基盤で稼働している開発用サーバをクラウドIaaSへ移行する予定である．神戸DCの仮想化基盤は，サーバを停止してもコストは変化しないが，クラウドIaaSではサーバを停止すればコストを抑えることができる．休日や夜間といった業務時間外は停止可能な開発用サーバを移行することで，コストダウンを図れる見込みである．

5.4　仮想化基盤のリソース削減

今後クラウドIaaSへの移行を進めることで，神戸DCの仮想化基盤を縮小できる．試算では5年間で仮想化基盤の機器を60台から30台まで削減可能と見込む．

6．取り組みの成果

今回，自前のデータセンタの老朽化対策を発端とした，クラウド活用を見据えた次期ITインフラ構想実現への取り組みをご紹介した．振り返ってみると困難な活動であったが，さまざまな課題を複合的に考え実践した結果，弊社のITインフラは従来にない俊敏性や柔軟性を得た上に，余剰コストを削減するという成果に至ることができた．

一方で新たな課題として，クラウドネイティブサービスの技術者不足が上げられる．

弊社は現在，業務システムのワークロードをオンプレミスからクラウドへ移行する活動に取り組んでいるが，将来的には災対DCもすべてクラウドに移行したいと考えている．

弊社の取り組みがクラウド化の検討および活用の一例として，皆様の参考になれば幸いである．