開発用サーバーの移行における要件定義について

今回は「開発用サーバーの移行」ついて書きます。私はアプリ開発が専門ですが、とある理由で基盤案件を担当したので備忘録として残しておきます。

設計や実装まで細かい内容も書けたらいいですが、まずは要件定義レベルで整理してみました。

サーバー移行の要件定義の進め方

サーバー移行も上流工程の進め方はアプリ開発と同じです。目的の確認からはじまり対象範囲や手段を検討整理のうえ、最終的に見積りを算出します。

１）目的・目標（効果）：Why
開発サーバー移行を移行する目的。
維持費削減、保守切れなど。

２）解決すべき課題：What
今回でいえば「開発サーバーの移行」が課題にあたる

３）対象範囲：Where
移行対象範囲を整理する

４）体制：Who
基盤エンジニアは確保が難しい。

５）移行方法：How
サーバーの移行先、移行方法の整理

６）納期：When
サーバー保守切れ等に伴う対応ならばその期日が納期

７）費用：How much
ハード、ソフト、エンジニアリング費用を算出

移行先の選定について

私が担当した案件では設置場所があったのでコストを抑えることができましたが、場所がなければクラウドが優勢だと感じます。下記、基本的な情報を記載します。

クラウド
事業者が用意したクラウド基盤を利用する形態。
例）AWS、Azure、GCPなど

オンプレミス
自社でハードウェアを用意する形態。
事業者のデータセンターを利用することも可能（ハウジング）

※ 維持費用
施設代・電気代・ハード保守費・人件費などによりクラウドの方が安くなる。
ただし、既にあるオンプレ環境にハードを追加する場合は、オンプレの方が安くなる場合もある。

移行対象範囲について

案件化するにあたって対象範囲が分かる資料が必要です。今回は下記資料を整理しました。

１）サーバー構成図
現行と移行後の構成図があると影響範囲が分かりやすい。

２）サーバー明細
詳細な情報が分かる一覧表も作成する。
項目例）サーバー名/ホスト名、OS、主要ミドルウェア、CPUコア数、メモリ量、ディスク量

３）稼働システム一覧
各サーバーにて稼働するシステムの一覧。
アプリ部隊に影響を伝えるのに便利。

４）ハードウェア構成
サーバーの配置場所。
オンプレの場合は空きラックがあるか確認すること。
（現行と新サーバーが同時に配置される期間が生じる）

非機能要件について

開発用のサーバー移行では、現行の非機能要件と同じにすれば問題はありません。ただ、その現行の要件が整理されていないこともあると思います（私の案件がまさにそれでした）。

そういうときは既存環境の設定をもとに「現行環境はこうなっているので、新環境も同じにします」といった説明ができると了承が得られやすいと思います。

以下、参考までに非機能要件の分類を紹介しておきます。

補足します。

① 可用性
開発用サーバーは顧客業務への直接影響するものではないので、障害発生から復旧までの時間は比較的余裕があります。ゆえに冗長性の必要性は低めです。

② 性能・拡張性
運用テスト環境（ステージング環境）は本番相当の応答性が求められますので、本番環境の応答性を調査して整理しておきます。

拡張性についてはサーバー全体のリソースに余裕を持たせて状況に応じて拡張できれば問題ありません。

③ 運用・保守性
稼働時間：
クラウド環境ならば夜間や休日にサーバーを停止することで若干のコスト削減をすることができます。

バックアップ（システム）：
サーバー構築後にシステムバックアップは取得して、何かしらの問題発生時に復元できるようにしておくと良いです。開発環境に関しては必要性は低いですが、ソースコードなどの重要な資産はバックアップを取得するようにします。

バックアップ（データ）：
ソースコードやジョブ定義など、復元が困難あるいは時間を要するものは、定期的にデータをバックアップを取得するようにしておきます。

システム監視
開発用サーバなので、監視の必要性は低いですが、前述のデータバックアップについては定常的に取得できていることを確認できるようにしておいた方が良いです。

④ 移行性
テスト
移行を判断するための判断材料（テスト内容）も整理しておきましょう、見積り工数に影響します。

移行
全てのサーバーを一括に移行するのではなく、段階的に移行をした方がリスクは低くなります。また移行にあたってのデータ移行も必要になるはずなので、メンテナンスの凍結期間が発生することは認識しておきましょう。

⑤ セキュリティ
運用テスト環境（ステージング環境）では、利用者に応じて社外からのアクセスも生じます。アクセス制限や認証認可についても整理しておきましょう。

⑥ 環境・エコロジー
クラウド利用では検討する必要はありませんが、オンプレならば耐震・温度・湿度・騒音といった要件も整理しなければなりません。必要に応じてメーカー営業に相談してみましょう。

見積りについて

ハードウェア、ソフトウェアライセンス、エンジニアリング費用の３つを見積ります。

１）ハードウェア費用（サイジング）

クラウドにせよオンプレにせよ、ハードウェアの費用を算出するには必要なリソースを算出しなければなりません。CPUコア数、メモリ量、ディスク量の３点を整理します。

これら３点は当然ながらサーバーの用途によって変わりますが、今回のように開発サーバー移行ならば現行と同程度のスペックにすれば基本的にOKです。もちろん現状の使用状況からリソースを削減しても構いません。

結合テスト環境（テスト環境）
不具合検証がメインのため、本番ほどのスペックは不要。

運用テスト環境（ステージング環境）
応答性など非機能面の検証もするため、本番と同等のスペックが望ましい。

オンプレ、クラウドのどちらにしても各社の比較を求められると思います。メーカー営業担当に問い合わせて１〜２週間ほど見積り回答に時間がかかるのでスケジュールは余裕が必要かと。

２）ソフトウェア・ライセンス費用

サーバー移行によって現在使用しているライセンスが使えなくなる場合もあるので注意が必要です。こちらもメーカー営業にライセンス条件を確認しなければなりません。

今回の案件で困ったのが過去にインストールしたDVDメディアやらライセンスコードが行方不明になっていたこと…

３）エンジニアリング費用

構築サーバーの種類によって多少は異なるものの、エンジニアリング作業は下記のようなものになります。見積手法は組織によると思いますが、私の組織ではタスク洗い出しからの工数積み上げにて算出しました。

エンジニアリング作業（例）
1. ハードウェア調達
2. ハードウェア設置
3. 詳細設計（パラメータシート作成、構築手順書作成）
4. 仮想環境構築
5. OSインストール
6. ミドルウェアインストール
7. AP/DB環境構築
8. その他設定（監視、バックアップなど）
9. 環境テスト
10. 環境移行
11. 既存環境廃止およびハードウェア撤去

また、構築にあたって多々の申請書を提出しなければならない会社もあるので、そういった作業もタスクとして確認しておいた方がいいと思います。結構時間を消耗します。

以上、開発サーバーの移行（要件定義）について書きました。環境を移行するにあたって現状調査をするのですが、そこで現状の問題点が浮き彫りになったりしてバタバタしますね…

また気づいた点があれば修正加筆します。

参考文献

IPA『高品質のための超上流工程における企業の課題・取組み事例集』

IPA『非機能要求グレード 実践セミナー』

SB C&S『クラウド vs オンプレミス徹底比較』

さくらのナレッジ『さくら石狩DCの業務体験』

当メディアの関連記事

要件定義工程の進め方

要件定義の成果物一覧と書き方（サンプルあり）