NEO ZION MANAGEMENT, LLC.
クラブザイオン
Home事業方針実績会社情報
Success
Success

ZION's project review プロジェクト 「Hit the Big Time! 〜あるシステム移行プロジェクトの話〜」第1回

Hit the Big Time! 〜あるシステム移行プロジェクトの話〜

今月からのプロジェクトレビューコーナーは、昨年某社様で実施させて頂いた音源データ管理システムの旧システムから新システムへの移行プロジェクトに関して焦点をあて、担当した成田、西澤により、数回に渡って振り返っていきたいと思います。
この移行プロジェクト(ここでは大人の事情により以降、便宜的にMusic data Migration Project、略してMMPと呼ぶ)は、耐用年数経過前の旧システムから、OS、設置拠点などの環境が異なる新システムへのプログラムや音源データ、データベース情報の移行を目的とした、平たく言いますと「システム引越し」プロジェクトであり、昨年、初期検討期間含め、ほぼ丸1年近くをかけて実現したものです。
と、言葉にしてしまうとこのように数行になってしまいますが、テラバイト級の情報データ移行、更に業務時間帯は止められない運用中のシステムの切替、周辺システムへの影響調査等々、解決すべき問題は山積みでした...

MMPシステム移行計画、カウントダウン開始!

システム移行の目的自体は、「旧システムから必要なものを取り出し、新システムに移し変える」とシンプルに説明できますが、それを実現するためには、各々のシステムの拠点、拠点間のネットワーク、限られた時間、対応可能な作業メンバの制限など、様々な要因を加味した上で、膨大かつ複雑な計画、作業が必要になります。
全体の工程としては、移行計画/設計、新システムの擬似/スモール環境での動作検証、新システム環境構築、試験、データ移行、システム切替といったフェーズに分かれるものですが、こうした作業の一つとっても失敗は許されず、作業漏れや手順の間違いは命取りとも言えます。
特に今回のMMPプロジェクトでは、システム切替時の切替作業で利用できる時間として、業務時間帯以外の深夜帯の約9時間(正確には万一の際の切戻し復旧の時間も考慮するため7時間)しか許されていませんでした。
このような状況の場合、システム移行計画を検討する上での最も重要なポイントは、

・切替当日の作業を極力減らし、事前作業可能なものはできる限り行っておく

という点につきます。
こうした観点から、計画を進める上で、まずは事前に対応可能な作業を選別していった訳ですが、その中でもひときわ長時間かかることが予想されるものがありました。

巨大データ領域への挑戦!

旧システムのストレージ領域自体が、かなりの大きさのものでしたので、覚悟はしていましたが、移行対象として切替までに最低移行が必要な情報データがデータベース以外だけで、テラバイト級であることが判明したのです。
単純に旧システムから新システムへデータ転送が終るまで、ひたすらそのデータを流し続けられれば、それほど気にする必要のないデータ量であるかもしれません。
しかし、旧システム自身、日々の業務の中で使用されており、また、運用中のネットワークトラフィックという観点からも、業務中はシステムに対する負荷をかけられないこともあり、事前にテストした結果、夜間の負荷が少ない時間を狙っての1日200GB程度のデータ転送が何とかできる、ということでした。
これらのことから、必要情報データを新システムへ転送し終わるのに単純計算で2〜3ヶ月かかることがわかりましたが、切替実施予定日程までの期間までに、問題なくスケジューリングできたため、まずはデータの移行先である新システム用のサーバ、ストレージ、ネットワーク環境の構築、整備に取り掛かりました。
同時にデータ移行用ツールの開発にも取り掛かり、順調にやるべきことをやっていったのです。

青天の霹靂 〜 What do you do?

そのような中、その報告は突然舞い込みました。
「新システムのストレージ領域の構築中に、カタログスペック上は可能な動作ができないものが発見されて作業が止まっています。」
このプロジェクトにも参画して頂いていたハードウェア・ベンダのエンジニアからのものでした。新システム環境構築にあたって、事前にスモールシステムでの動作検証は行っていたのですが、今回稼働予定のシステムでは、世界でも類をみない大きさのファイルシステムが必要だったため、ここに来て問題が発覚したというわけです。
これは、情報データ移行先の環境が整わない、つまり、一番時間のかかる情報データの移行を進めることができない、ということを意味しており、対応如何によっては、プロジェクト全体スケジュールに多大な影響を及ぼすことになります。
当時開催していたプロジェクト検討会議の中でも、この問題に対して、参画メンバ全員で議論を重ねました。
その結果、

・ハードウェアベンダ側の尽力による修正プログラムの早期リリース
・上記リリースまでの間のバックアッププランの採用
(データ転送に時間がかかる主な理由として、拠点が離れているためのネットワークス ループットに影響されるための転送量の限界、旧システムに対しての業務時間帯に負荷をかけられない、ということが導き出せ、かつ、幸いにもシステム切替時にすぐに利用するのではなく、近い将来に利用する、当初は余裕のある同様の問題が出ないストレージ領域も別にあったため、その領域にも一度情報データを蓄積しておき、万が一の場合は、ここから同一拠点システム内で情報データを戻す、というプラン)

といった案での計画遂行をお客様にもご理解頂き、進めることになりました。
その後、何とか修正プログラムのリリースまで漕ぎ着け、情報データの移行作業もスケジュールへの大きな影響を与えることなく、終焉の目処をつけることができたのでした。
このように、最初の山をプロジェクト参画メンバーが、一丸となって乗り切ったのですが、ここでの勝因は、問題の影響範囲の冷静な分析、その結果に基づくバックアッププラン含めた臨機応変な対応計画を打ち出せたこと、といえるでしょう。

しかしながら、勿論、これだけでプロジェクト自体が終ったわけではありません。
次回は、この続き、システム切替にまつわる話を中心に振り返ってみたいと思います。




ZION's project review プロジェクト 「Hit the Big Time! 〜あるシステム移行プロジェクトの話〜」第2回

Hit the Big Time! 〜あるシステム移行プロジェクトの話〜
システム切替での悲喜こもごも

前回から始まりました昨年某社様で実施させて頂いた音源データ管理システムの移行プロジェクト、MMP(Music data Migration Project)プロジェクトレビュー。 第2回の今回は、プロジェクトの山場でもあったシステム切替を中心にお話ししたいと思います。

計画と事前作業

MMPでは一般的なプロジェクト同様に、システム切替に向けて以下の2つを軸にリリースの準備を進めました。

・切替前日までの準備(事前にできる作業の実施)
・切替当日の準備(タスクの洗い出しやタイムスケジュール作成など)

事前作業としては、膨大な音源データの移行の計画的な実施、新システムとのネットワーク上の接続確認、クライアントアプリケーションのアップデート、当日のシステム切替をサポートするプログラム配布と、すべてはスムーズな切替のためのものです。
特にインフラであるネットワークはどこか1箇所でも接続できなければシステムが動かない重要な部分であり、またもっとも初歩的なミスが起きやすい部分でもあります。 システム切替で変更するIPアドレスや利用するポートをすべて洗い出し、関係するネットワークすべてに対しての導通確認が必要ですので、ここは地道に、そして確実に1箇所ずつ確認を行いました。

また、当日の準備で大切なのが、やはり切替のタイムスケジュールの作成です。切替作業として与えられたのは7時間。業務が停止し、翌日の業務が開始するまでの間に、切替を完了、または万が一の切戻しの復旧完了が絶対でした。 従ってこの7時間が純粋に切替作業に使えるギリギリの時間でした。 この時間内でのタイムスケジュールは、初期で想定されるタスクを並べた叩き台レベルで既に15分刻みの実施が必要であるという現実を認識したとき、少し緊張したことを覚えています。

何をそこまでに感じたのかというと、切替当日に少なからず設定変更がほぼすべてのサーバに必要で、またその対象となるサーバの台数が多く、更には切替時に一斉に移行する必要がある業務データのボリュームも大きかったからです。 業務で使用するデータベースのトランザクションデータは一部を除いて切替前から何日もかけて移行していては業務が停止してしまいますし、既に稼働中のシステムのサーバ入替でもあったため、平行稼働もできない状況でした。
システム切替は、当日の一斉移行が大前提だったのです。

ただ、その不安は事前のデータ移行のリハーサルを重ね、移行対象データを効率化し、想定作業時間の精度も上げたことで徐々に払拭されて確実なスケジュールとなってきました。

いざ、システム切替の夜

なんとかリリースできる状態にまで準備ができ、システムリリースの当日を迎えました。 切替作業はお客様の業務が終了してからの深夜の実施となるため、当日は夜20:00にお客様を含めた関係者が集まり、業務終了が確認された後のGOサインで作業開始です。

データベースの移行はリハーサルを重ねていた甲斐もあり、予想以上に順調なスタートができました。
また、多くのサーバの設定変更はお客様のシステム担当の方の協力もあり、分担して実施できましたし、最終の差分データの抽出、移行も特に問題なく完了していました。 これも、地道な事前準備が実を結んだ結果、作業は順風満帆、描いたシナリオ通りにこのまま終わるかに思えたその時、問題は発生したのです・・・

すべては想定外だった明け方

切替作業はタイムスケジュール通り、終盤に近づいた明け方、あとはシステムの最終確認であるスルーテストを残すのみとなりました。 しかし、ここで動作確認を始めた時に、いくつかの問題が発生しました。 アプリケーションで必要な設定ファイルの移行漏れがいくつか発覚したのです。 外はうっすらと明るくなり始めたこの頃、メンバーはリカバリ作業に追われました。
幸い、どれも旧システムへ切り戻す程の障害に発展する問題はなかったため、システム切替の朝をなんとか迎えることができました。

新システムでの業務開始の朝

そして、業務開始の直前、業務の現場では多くのクライアントアプリケーションが立ち上がり始める時間帯となりました。 既に全クライアントにはサーバの状態を見て接続先を自動的に変更する切替プログラムを配布していたので、基本的に何もできることはありません。 ここから先は、無事に業務開始を待つばかり。 我々はサーバ側でクライアントからの接続数や負荷状態をモニタする等、そっと状況を見守ることしかできませんでした。

切替作業の本当の結果が出るのは、この業務開始の瞬間です。待つ間はほんの少しの時間にしか感じませんでしたが、メンバーにはやや緊張した空気が流れていました。 ただ、我々裏方の慌ただしかった深夜切替作業をよそに、業務はいつも通りに開始したのでした。

ということで、今回はシステム切替を中心に振り返ってみました。 どんなに準備万端でも絶対に何かが起きるという心の準備と、事が起きても慌てず冷静な判断や対処ができる心の余裕を持つことが重要であると言えます。 しかし、やはり重要なのは事前の準備です。 理想だけ言うならやり過ぎだと感じるぐらいが、実はちょうど良いのかもしれません。

しかし、スケジュールの関係上、なかなか事前準備に十分な時間を使える案件はそうはありません。 MMPでは膨大なデータの計画的な移行が大きなテーマの1つだったこともあり、比較的早い段階から事前の検討に入ることができました。 そして、メンバー全体が共通の認識を持つことができたことが、無事にリリースできた1つの要因だったと言えるかもしれません。

さて、今回のシステム切替には、実はまだ続きがあります。 次回は、更にこの後のお話を含めて、プロジェクト全体を振り返ってみたいと思います。




ZION's project review プロジェクト 「Hit the Big Time! 〜あるシステム移行プロジェクトの話〜」最終回

Hit the Big Time! 〜あるシステム移行プロジェクトの話〜

5月より始まりました昨年某社様で実施させて頂いた音源データ管理システムの移行プロジェクト、MMP (Music data Migration Project)プロジェクトレビュー。
前回までのお話で、無事システム切替を終え、新システムでの業務が始まったところまでをお届けしました。
第3回の今回は最終回として、前回からの続きからプロジェクトのゴールに至るまでのお話とともに 今回のプロジェクト全体を振り返ってみたいと思います。

ゴールはそこにあらず

競馬に例えれば、第四コーナーを回って最後の直線上り坂。
この坂を先頭で上りきれば、ゴールは目前ですがここで気を抜くと勝利をつかむことはできません。 勝利への最大の難関は、この上り坂を上った後ゴール直前に訪れるものです。 システム構築の現場においても同様のことがいえ、今回のシステム移行プロジェクトでも前回お話しした 「システム切替」が、ここでいう「上り坂」にあたるものといえるでしょう。 ここでシステム切替=システムリリースがこのようなシステム移行プロジェクトの場合、ゴールでは?と感じる方も いるかもしれません。

勿論、予定通りのシステムリリースに向けて、常に最善を尽くし、稼働開始をすることが一つの目標ではあります。 しかし、システムを利用する側、つまり、お客様にとってのシステムの稼動開始は、本来やりたかったことの始まりであり、 ゴールではありません。 新しいシステムを手段として活用し、その結果として目的を達成することがプロジェクト全体としての本当のゴールといえます。

本プロジェクトの目的の1つに、耐用年数経過前に旧システムを新たなハードウェア上にデータを移行し、新システム基盤を構築する ことで安定した業務を行えるようにする、ということがありました。言うなれば、今回のプロジェクトの真のゴールとしては、 新システム上での業務の安定化までの道筋をつける、といったことになるのです。

最後の試練

さて、MMPでの話に戻ります。
システム切替を終えたその日は、システム動作の問合せ対応などに追われはしましたがその後の2〜3日は問題もなく、 平穏に過ぎていました。もうこのまま大丈夫かと思い始めた矢先、それは突然、しかもその後も数回同じような状況が 起きたのです。

業務で利用しているクライアントからアクセスができない。

報告を受けた都度、すぐにシステムで何が起こっているのかをまず把握することに努め、業務で使えるようにすることを 最優先にトラブル復旧処理を行いました。それぞれ起きている事象は把握できたため、またトラブルが起きた際の一時的な対応策は 打つことができましたが、根本的な解決ではありません。
――移行作業自体は大きな問題なく完了したのに、これでは真の目的達成ができない。
お客様、ハードウェアベンダ含め、昼夜問わず原因究明に努めました。トラブルが起きるとどうしても 先入観で原因を考えてしまいがちですが、調査というのは、本来客観的な事実を積み上げていくことが大事になります。

システム側面からこれを行うには、システム上に残されたデータ、ログといったものから事実を抽出する以外に他ありません。 とにかく時系列にそれらを追い、並べ、客観的事実を導き出すといったこの地道な作業を行った結果、何れのケースもミドルウェア、 ハードウェアでの不具合が原因であったことがわかりました。 ベンダ側からもこれに対する対応策が提示され、これを実施することで根本的な解決を行うことができ、ようやく事態が 収束していったのです。

このように最後の最後での大きな山場をクリア、お客様とのプロジェクト報告会を無事実施し、とうとうゴールに 到達することができました。思いおこせば、ここに至るまでいろいろなことがありましたが、やり遂げた時は、 感慨もひとしおでした。

歴史に学ぶ

「愚者は経験に学び 賢者は歴史に学ぶ」
(愚者は自分の経験でしか学べないが、賢者は他者の経験でも学ぶの意)

このような言葉もあるようにプロジェクトも終った後に一度振り返ってみることも重要です。 今回テーマとしてとりあげたシステム移行プロジェクトを材料に、成功に導くポイントに関して 今までの話の中からエッセンスを取り出し、以下に今一度列挙しておきたいと思います。

・プロジェクトの早期段階からの移行計画策定開始

・各種前提条件の洗い出し
(各々のシステムの拠点、拠点間のネットワーク、業務に影響しない限られた時間、 対応可能な作業メンバなど)

・移行必要対象データの洗い出し/データ量の算出

・実環境でのデータ移行時のスループット算定

・最も大きいデータを移行するのにかかる時間をシュミレーションし、それを軸に全体スケジュールを策定

・設定変更が必要な周辺システム
(システムを切り替えることで影響の出る範囲)の洗い出しと、 変更方法の具体的手法の検討

・事前に作業可能/不可能の判別を行い、切替当日の作業を極力減らし、事前作業可能なものはできる限り実施

・切替当日作業のシミュレーション/リハーサルの入念な実施
(やり過ぎと感じるくらいおこなっても損はなし)

・トラブル時の原因調査は先入観で判断せず、客観的な事実の積み上げによって行うことが重要


そして何より、

・プロジェクト参加メンバ全体での目的・目標の共有

が根底で最も重要なことだと考えます。

以上となりますが、これらが「歴史」として皆様の今後の参考になれば幸いです。

PageTop
Copyright(c) 2007 NEO ZION MANAGEMENT, LLC. all right reserved.