ID:62272さん

1. お客様のビジネス課題 お客様である某大手メーカは、データセンター(以降DC)のハウジン グ契約の期限切れを迎え、これまでのDCの利用コストの高さという課題も考慮し、契約更新をせず、DC移転に踏み切った。 お客様は、既存DCに、約200台の自社ラックをハウジングしていた。ただ、2021年の3月末に契約が切れ、その9ヶ月 前(2020年6月末)までに、契約更新をするか否かを決める必要があった。他のDCと比較して、既存DCの利用コストが高いため、そのコストを削減したい、 というお客様が抱える課題もあり、それを解決するため、引き続きの契約更新はせず、他のDCへの移転をお客様は決定し、Cloudへの移行も検討していた。 2. 本案件におけるお客様との関係およびプロジェクトの体制 お客様のビジネス課題を解決するために、早速社内でプロジェクトチームが立ち上あがり、 私は、今回のお客様のビジネス課題を、技術的な視点で検討し、解決策に導くための、提案活動におけるリードアーキテクトとして、本案件に参画することになった。 私はリードアーキテクトとして、積極的に技術的議論・提案検討を行った。 定例検討会では、ディスカッション形式で、お客様の要求をヒアリングして、 検討内容を持ち帰り、提案チームメンバーと共有し、不足した技術資料などの 検討用材料の収集を主導して行い、次回の際にご報告してから、さらにディス カッションしていくという検討サイクルで進めた。 お客様との定期的な打ち合わせを行いながら、非機能要件を纏め、移行後の Architecture Overviewの作成、Operational Modelを用いた移行手順の検討(移行のイメージの図示)、Solution Overviewを用いたより詳細な移行手順の可視化、そして、今回のArchitectural Decisionの過程(代替案やリスク)の検討をしながら、提案を進めていった。また、お客様の課題を解決する、具体的なソリューションアプローチ、手法、移行の際のツールの選択等について、お客様と幾度か会話し、理解をして頂くとともに、それぞれの理由を説明することで、お客様の不安を取り除くことができた。 3. 設計したソリューションの説明およびお客様にもたらすメリット 計10ラック、全152サーバで構成された8システムをIBM Cloudに移行するマイ グレーションアーキテクチャを設計した。 アーキテクチャを構成するコンポーネントとして以下に示す。 ・ベアメタルサーバ(以降BMS、冗長化構成) ・Enduranceストレージ(IBM Cloudブロックストレージ) ・DirectLink (IBM Cloudへ接続する専用線/冗長化構成) ・Virtual Router Appliance(以降VRA、冗長化構成) 既存DCから東京DCへの移行ツールとしてはZerto Virtual Replication(以降 Zerto)を採用。移行の手順として、まず、移行先の東京DCに、IBM Cloud環境を構築した後、移行元からZertoを用いてVMの高速移行を行う。 上記の設計によってお客様にもたらすメリットとして以下6つに示す。 (1)既存の152台のサーバを22台のBMSに集約させたことによるコストメリット (2)Zertoを使用することで、異なるハイパーバイザー環境が混在する既存環境 でも移行することが可能 (3)Zertoを使用することで、VMの高速なレプリケーション機能により、高速な 移行を実現可能。これはお客様の要求である「移行にあまり工数をかけたくな い、スピーディに移行作業をしたい」を満たす。 (4) VCS(VMwareアプライアンス)を採用することで、自動プロビジョニングによるデリバリー工数の削 減でコストを低減することが可能。 (5) NSX L2 VPNにより、L2延伸を実現し、移行後のIPアドレス変更作業等を減 らすことができ、上記(3)のお客様の要求を実現可能。 (6)グループ会社は現行でIBM Cloud環境を使用し ているため、IBM Cloud環境構築および移行の実績があり、ノウハウも蓄積されているので、スピーディーな新環境の構築、移行が可能。 4. ソリューション設計上における主な技術的な決定、およびそれがお客様にもたらすメリットとリスク回避 本案件において、多くの技術的決定をしてきたが、全体的なアーキテクチャ設計方針を一番最初に考えるにあたり、クラウドネイティブのアーキテクチャ(コンテナ)にするのか、IBM Cloudを採用したアーキテクチャ(VM)にするのかという設計方針決定が重要になる。 当初、私は、コンテナ、OpenShiftを用いたクラウドネイティブのアーキテクチャ設計を考えていたが、既存システムのアプリケーションの変更作業 (場合によっては作り直し)等が生じ、移行工数が多くなるため、非機能要件を満たさないことになる。また、初物であるため、PoC期間を設ける必要があることや、導入の過去実績が薄く、移行時に不具合が生じる場合に移行が大幅に遅延するリスクがある。それによるお客様のコスト面の損失、IBMへの信頼度の低下のリスクも想定され、それらのリスク回避を行った。 以上の理由により、今回は、クラウドネイティブではなく、これまでもグループ会社で行われたことがあり、過去実績のある、IBM Cloud環境(VM)に移行するアプローチに決めた。 移行方針が定まった後、お客様に改めてIBM Cloudのメリット・移行実績について説明し、移行先となる環境を今一度ご理解頂き、安心して検討頂けるよう尽力した。 5. 業界の方向性を踏まえたソリューション提案 お客様が属する製造業界におけるIT投資の動向として、2020年以降に基幹系システムのクラウド移行が進み、インフラ分野では、クラウドサービスに高い投資意欲が見られ、クラウドシフトが進んでいる。特に、お客様に関係するOA 機器分野では、ペーパーレス化が進む中、国内市場の縮小とともに海外展開が加速し、販路拡大の戦略が今後必須となる。業界の方向性を見据えたとき、グローバル展開を見越したインフラ基盤でなければならず、より柔軟かつ拡張性のあるインフラ基盤が必要不可欠である。今回の設計したマイグレーションアーキテクチャは、まさに業界の方向性にマッチしたものであり、また、今回 のDC移転を起点とし、移転後に考慮すべきことを、お客様の中期経営計画をふまえ、お客様が属する業界のIT投資動向も考慮しながら、以下6テーマを提示した。これを軸に技術ロードマップおよびToBeアーキテクチャを作成し、お客様と情報共有を行った。 (1)クラウド基盤強化:オンプレミス環境からクラウド環境への移行によるさら なるコスト削減、および高可用性システム構成 (2) ネットワーク基盤強化:今後想定されるデータ量の増加に備え、NW基盤の 最適化(SD-WAN/インターネットブレイクアウト等) (3) セキュリティ基盤強化:新規拠点立ち上げや、グローバル展開を見据え た、ネットワーク/セキュリティ基盤の強化 (4) IT統制の強化:グループ会社のモニタリング、ITIL準拠したITガバナンスの強化 (5) 運用自動化:構築・運用の自動化によるコスト最適化 (6) コラボレーション基盤強化:グループ会社内のコミュニケーション効率化 のための基盤整備・強化 上記はいずれも今後考慮すべきテーマであり、今回の提案では、お客様の業界の方向性を踏まえた提案であったと言える。 6.プロジェクトにおける自身の役割およびアーキテクトとしてのタスクと責任 私は、本プロジェクトにおいて、お客様のビジネス課題を抽出し、技術的な視点でソリューションを検討・解決に導くための、提案活動におけるリードアーキテクトとして活動した。 以前より私は、お客様のオンプレミス環境にある基幹システムをIBM Cloudへ 移行するための、アーキテクチャ構成および移行手法の検討、バックアップ戦略や費用見積もり等、Cloud化案件に多く携わっていたこともあり、本プロジェクトにおいて、Cloud化の提案検討の主要メンバーとして以下のタスクおよびそれに付随する責任を負い、チームメンバーと協力しながら、期限内に提案をまとめることができた。 (1) リードアーキテクトとしてのお客様との折衝 (2) 非機能要件の整理および其々に対するソリューションアプローチの検討 (3) 移行先アーキテクチャの策定 (4) 移行ソリューションおよび移行手順の検討 (5) アーキテクチャを構成するコンポーネントや移行ツール等の技術的決定 (6)DC移転後に考慮すべき技術的事項および将来を見据えた技術ロードマッ プ、ToBeアーキテクチャの提言 7. 結果 お客様との定例検討会で、幾度か議論をした結果、提案したIBM Cloudへの移行案は受け入れられた。ただお客様内部での検討により、できるだけ早く既存 DCから移転をしたいとのことから、一旦Cloud化せず、まずは他DCへの物理移転をしてハウジングという形にしてから、のちにCloudへ移行していくという方針となった。お客様からは、これまで様々の検討、サポートしてくれたIBMに対して、以下の三つの観点から、非常に信頼できるテクニカルパートナーとして評価されていると感じている。 (1) 定例検討会において、お客様、IBM両側の認識の確認およびプロジェクトで 考えるべきことを整理するため、ToBeアーキテクチャの全体構成図や、移行のイメージを確認するためのオペレーショナルモデル、ソリューション概要図など、それぞれのWork Productを事前に準備して打ち合わせでは効果的に使い、 議論した内容を都度反映して更新し、それぞれの成果物の品質を高めながら、 お客様の要求に対して常に真摯に受け止め、それを前向きの姿勢で検討し、提案を進めていたこと。 (2)目先の課題だけでなく、お客様の中期経営計画から課題を抽出し、お客様が属している業界内のIT投資動向、トレンド情報を共有して、お客様の将来を見据えた、技術ロードマップとそれに沿ったToBeアーキテクチャを提示して議論を重ね、お客様のビジネス成長を長期的にお手伝い、サポートしていくという 真のビジネスパートナーとしての立ち回りであったこと。 (3)Cloudへの移行を検討する際、設計したアーキテクチャの精査や、移行ソリューションの実現可能性について、提案チーム内のみならず、お客様の意見も取り入れつつ、他部門の技術スペシャリストも巻き込み、慎重かつスピーディーな提案をしていたこと。 また、お客様はCloud 化の検討については、非常に前向きな姿勢であり、 Cloud化は将来検討項目の一つとして挙げられている。今後引き続き、お客様グループのCloud 化支援をしていく予定である。

1. お客様のビジネス課題 2019年9月、お客様である某大手メーカは、従業員用メールシステムとして使用していたHCL Verse(Smart Cloud Notes、以降Verse)が2020年7月にEOS(サービス終了)のアナウンスを受けて、従業員の生産性低下等の影響を最小限に留めながら、従業員メールシステムの刷新を行うという課題に直面していた。お客様にとって、電子メールは社内外との主要な情報連携手段であ り、ビジネスの促進、生産性向上のためのコミュニケーション面における重要なインフラである。また、お客様は、本社である東京を中心に、北海道、関東、中部、近畿、関西、九州に全17以上の国内工場と、乳製品、喫茶店を含む国内子会社、さらに、豪州、タイ、台湾などの日本国外子会社を持つ大企業グループでもある。そのため、今回のメールシステムのEOSはお客様にビジネス上、国内外の事業所間、顧客との間の情報連携に、大きなインパクトを与え、システムの刷新は重要検討課題であり、緊急を要するもので あった。 2. 本案件におけるクライアントとの関係およびプロジェクトの体制 お客様のビジネス課題を解決するため、社内では、早急にアカウントチーム (営業チーム)とともに、提案チーム(アカウントチーム+アーキテクトチーム+技術スペシャリスト)が立ち上がった。 私は、今回のお客様のビジネス課題を技術的な視点で検討し、解決策に導くための提案活動におけるアーキテクトチームの一員として参画した。 そして、リードアーキテクトの支援を行い、共にシステムアーキテクチャの検討に携わることになった。 本プロジェクトにおいて私は主に、後述のデータ移行時に必要なIBM Cloudの アーキテクチャ検討に携わった。 アカウントチームからの検討会議のフィードバックを元に、課題の整理、ソリューション案についての以下の検討をアーキテクトチームが実施した。その中で、私は主に、機能要件、非機能要件を満たすデータ移行時に必要なIBM Cloudのアーキテクチャ、アーキテクチャを構成するコンポーネントおよび実際の移行手順についての検討に携わった。 以下が私が主に携わった検討活動である。 (1)お客様の課題からブレイクダウンした機能要件および非機能要件を抽出し、それぞれの要件に対する具体的なソリューションアプローチについての検討 (2)データ移行時のIBM Cloudの全体のアーキテクチャについての検討 (3)具体的なデータ移行方法・手順、移行スケジュール(それに伴う移行までの時間)についての検討 (4)アーキテクチャを構成するコンポーネント(例:サーバやストレージの種類等)やその代替案を示し、最終的に用いるコンポーネントの決定についての検討 (5)データ移行手法およびその際に用いる移行ツール、バックアップ案の検討 3. 本案件における問題の範囲および複雑さ 今回お客様は、新しく採用する従業員用メールシステムとして、Office365(以降O365)の採用を決定したが、Verse上に蓄積されている大量のNotesメール データ(約10TB)をいかに保全し、新メールシステムへ円滑に移行するかが重要な検討課題となった。 それは、お客様の従業員にとって、電子メールは社内外との主要な情報連携手段であり、過去メールデータはお客様の生産性を支える情報資産として、新システム移行後も従来同様にアクセスできることが必須事項であると考えられたためである。 本プロジェクトは以下のような考慮点があったので、複雑なものであった。 (1) 既存のVerseのサービス終了期限と必要移行準備期間から、約2ヶ月という短期間での提案が必要という、「時間的な制約」があったこと。 (2) VerseとO365という異なるシステム間のデータ変換という技術的ハードルがあったこと。 (3) 移行元のVerseがコントロール困難なSaaS提供業者(HCL)であることによる不確実性が含まれていたこと。 (4) お客様の厳しい予算制約によるコスト最適化のプレッシャーが存在したこ と。 (5) 約10TBの大量のNotesメールデータをスムーズに、かつ期間内に移行可能 なのかという懸念点に対して、IBM Cloudを用いた移行方法、移行時間を含めた技術的なハードルがあったこと。 (6)扱うのが機密性の高いお客様のメールデータということから、セキュリ ティ、高可用性を満たさなければいけないこと。 上記(1)~(6)に示すように、様々な側面・ドメインから本案件を考えなければならなかった。 また、本プロジェクトの提案スコープ外ではあるが、以下の検討もアーキテク トチームで行った。 従業員のメール基盤がO365になった際に、インターネットのトラフィック量が多くなる可能性が予想されるため、例えば、インターネットブレイクアウトなどによるトラフィックの負荷を軽減する案が考えられ、将来的に発生しうる課題に対応できるアーキテクチャ構想も考えられた。これに関して、リード アーキテクトとともに、アカウントチームに進言しており、それが、お客様へ の将来的なアドバイスへの提供となった。 4. 設計したソリューションの説明およびお客様にもたらすメリット 社内アカウントチームとの検討会議、各技術担当との連携を通して、リード アーキテクトのもと以下のソリューション設計検討に携わった。中でもデータ 移行用のIBM Cloud構成検討について私は主に担当した。 1-1. ソリューションの全体像について 今回は、Verseからのすべてのメールデータをエクスポートして、O365のデー タ形式に変換してから、O365にデータをインポートする一時的な移行環境を IBM Cloudで構築する。また、O365の導入支援も本提案に含まれる。さらに、Domino環境、データ変換ツールの環境の構築や、それらを用いたメールデータの移行作業の実施といったサービス提供も提案範囲である。 1-2. データ移行用IBM Cloudの構成部分について アーキテクチャを構成するコンポーネントは以下の通りである。 ・Virtual Server Instance(以降VSI) ・Enduranceストレージ (VMware用およびバックアップ用ブロックストレージとして) ・Juniper vSRX (Edge Gateway/Firewallとして) IBM Cloudの移行環境のアーキテクチャとして、Dominoサーバ(VSI)で構築し、 VMware用およびバックアップ用ストレージとして、Enduraceストレージを採用した。また、ネットワークセグメンテーションとしてVLANを使用する。移行データの保全を図るため、マルチAZ(Availability Zone)構成として設計した。上記のうち、EnduranceストレージとvSRXは其々冗長構成をとる。また、バックアップ用ストレージを異なるAZに配置することにより、移行データの保全をはかるアーキテクチャを実現。 上記の設計によりお客様にもたらすメリットとして以下に示す。 今回はお客様のメールデータを扱うため、そのデータが失ってしまうことは あってはならない。そのためデータの保全が重要であり、ここでは本ソリュー ションの可用性、データの保全を担保する設計がお客様にもたらすメリットを記述する。 (1)アーキテクチャを構成する各コンポーネントが冗長構成をとることで、各装 置の一部が故障しても動作が引き継がれ、データの移行作業を継続することが 可能となる (2)マルチAZのアーキテクチャを採用することで単一AZに障害が起きても、 バックアップデータの保全を担保することが可能となるため、お客様のデータ がなくなるといった事態を防ぐことが可能となる 1-3. 移行の流れ 移行の流れとして、Verseからエクスポートされた過去メールを含むすべてのメールアーカイブをDomino Replica機能を用い、IBM Cloud Dominoサーバへデータを転送し、移行先のO365に適したデータ形式になるよう変換してインポートする。その際、データ移行完了までの一時環境としてIBM Cloudを使用し、データ形式変換ツールとしてMNEツールを使用。 5. ソリューション設計上における主な技術的な決定、およびそれがお客様にも たらすメリットとリスク回避 本案件において、データ移行時に必要なIBM Cloudのアーキテクチャを設計するにあたって、構成するコンポーネントの技術的決定の検討に自分は主に携わった。 まず、メンテナンスの場合VMの再起動が許容されているので、ベアメタルサー バ(以降BMS)ではなく、コストが抑えらえれるVSIを採用した。そのことで、 お客様にはコスト削減のメリットがある。また、ストレージとして、サーバの内蔵ストレージやオブジェクトストレージも考えられたが、10TB以上の容量が 必要であり、IOPSが保証されいている点から、ブロックストレージである Enduranceストレージを採用している。さらに、バックアップ手法として、 Veeamなどのツールも検討対象であったが、追加の構成を最小限に抑え、スケジュールベースのバックアップを有効にするため、Enduraceストレージのスナップショットとレプリケーション機能を用いることにした。また、単一デー タセンターではなくマルチAZを採用した。これにより、データの保全を図り、 セキュアなデータ移行を提供することを可能にした。 6. 業界の方向性・標準を踏まえたソリューション提案 VerseからO365へのデータ移行際のデータ変換のため、今回はMNEツールを用 いた。 3rd-Partyの過去事例や実績を見ると、VerseからO365への移行はよく見られる事例であり、業界の方向性の一つであると考えられる。その移行の際に用いる データ変換ツールは一般的にMNEツールであることが多い。MNEツールは Quest Software社発のものであり、VerseからO365への移行際のデータ変換 ツールとして十分な実績がある。有名な過去事例として、コカ・コーラ様のメールデータ移行プロジェクトがある。Lotus Notesの3,000個のメールボックスをMicrosoft Exchange Serverに完全に移行し、移行期間が33 %短縮され、予定より2ヶ月前倒しで作業が完了した。その利便性により、コンサルティング費用を削減することに成功している。また、MNEツールの提供先であるQuest Software社は30年以上にわたり多くの大企業様とビジネスを展開しており、実績のあるベンダーである。今回は十分な実績があり、VerseからO365へのデータ変換の標準ツールである MNEツールを提案することにした。 私は、MNEツールの事例調査および本案件への適用に関する検討にも携わった。 7. プロジェクトにおける自身の役割およびアーキテクトとしてのタスクと責任 私は本プロジェクトにおいて、リードアーキテクトのもとで、移行アーキテク チャの検討、ソリューション提案検討を行なった。 提案チームのメンバーとして以下のタスクおよびそれに付随する責任を負い、 メンバーと協力しながら期限内に提案を纏めることができた。 ・データ移行用のIBM Cloud基盤のアーキテクチャ検討 ・データ移行ソリューションの提案検討 ・アーキテクチャを構成するコンポーネントの策定/移行ツールの検討 ・アーキテクチャ検討過程の文書化 8. プロジェクト中における主な問題およびそれを克服するために実行したこと 今回のプロジェクトの中で、元々BMSで構成を組むことを検討したが、コスト 低減のためすべてVSIに見直す方針となった。 方針決定後、VSIの制約によって、NICの性能が10Gbpsから1Gbpsに落ちることが判明し問題となった。これは、ネットワークアクセスだけでなく、スト レージアクセスのスループットの上限にもなる。サイジングガイドでは、2000 ユーザーアクセス時のディスク転送量は56Mbps(10分平均)程度であり、こ の点はスループット上限1Gbpsでも問題ないと思われる。しかし一方で、大ボ リュームのIOが予想されるメンテナンスタスク時のディスク転送量はガイド上 でも不明であり、これが1Gbpsでは不足する可能性も否定できない。そのため、VSIではなく、BMSにする案もアカウントチームに進言したが、議論の結 果、今回は低コストの点およびプロジェクトの時間的な点を考慮し、移行性能を早期に見極め、必要に応じて構成を見直すという方法をとることになった。 9. 結果 2019年11月末、お客様はIBMからの提案を採用し、契約が締結された。 この受注に至った要因として、提案構成がデータ保全および移行の確実性を重視しながらも、必要十分なサイジングでコストとのバランスを取り、提案価格を抑えることができた点が大きいと考えられる。加えて、今回設計したデータ 移行用アーキテクチャが、お客様の要件に十分に満たし、本案件のワークロー ドを十分にこなすことが可能である点も含めて、アカウントチーム、お客様に納得していただけたからであるとも考えている。 また今回の提案を経て、お客様よりO365導入の要件定義を引き続きIBMにお任せしたいとのことで受注を頂いた。このことからも、今回のプロジェクト活動から、お客様から一定な信頼を得ることができ、本提案はお客様にとって満足度が高いものであったと考えられる。 後に、本プロジェクトに関して社内記事として公開された。主な内容として以下に示す。 「市場や社内での実績が乏しい移行作業であったが、アーキテクト、ベンダーを含め迅速に技術的なアセスを行い、早く移行作業を進めることができた。 また、適切なリスクマネジメントにより、結果として、遅延なく、期間内に新 O365環境の構築および、全てのデータ移行を完了することができた。 お客様からも、予定通りの検討、構築、移行、本番化への尽力について、感謝の言葉を頂いた。」とのこと。 また、「クイックな構築が可能なIBM Cloudで、理論上で最高効率となるよう に、データ転送が可能なアーキテクチャデザインによって、結果、余裕をもって移行作業を完遂することができた」と、デリバリチームからコメントを頂いている。 上記より、実行可能性の観点から、今回設計し、提案したデータ移行用アーキテクチャおよび移行計画は、十分にデリバリー実行可能なものであったと、 デリバリーチームからの高評価なフィードバックやコメントから判断した。また、直接ではないが、お客様から感謝の言葉を頂いたとのことで、 アーキテクトとしてのやりがいを感じたとともに、引き続きお客様の期待に添えられるよう、ますます精進していかなければいけないと強く感じている。