連載：いまさら聞けないWindows Serverの開発活用術 第2回　Windows上の開発環境の障害やトラブルへの事前対策 亀川 和史 2012/07/20

Page1 Page2 Page3

　現在の開発環境では、通常、仮想環境も使用しているだろう。仮想環境では、1台の物理的なサーバの中に複数の異なる仮想的なサーバ環境を構築できるため、大変便利な半面、仮想的なサーバ台数が増えてしまいがちだ。台数が増えれば、比例して管理が複雑になる。だからこそ仮想環境を運用している開発現場では、サーバ管理にも注力する必要がある。

　にもかかわらず開発者は、つい開発作業だけに熱心になって、開発サーバの運用をおろそかにしてしまっていないだろうか？ サーバ自身は壊れても、最悪、買い換えればよい。しかし、サーバの中にあった失われたデータは二度と戻ってこない。そうならないための転ばぬ先の杖として、バックアップやトラブル対応は重要である。

　そこで今回は、仮想環境を運用する開発者向けに、各種バックアップの基本および、サーバ・トラブルを検知する方法について解説する。

■開発サーバのトラブル対応

●サーバ／ミドルウェアのバックアップ

　何よりも重要なのが「データ・バックアップ」だ。

　Windows Server自体は再インストールし直すこともできるが、データはバックアップから戻すしかない。バックアップを取っていない状態でデータを保存しているサーバが故障すると、現在の作業が全て消失してしまうだけでなく、過去の履歴も全て消失してしまうことになる。「現在の情報だけあればいい」と思う方もいるかもしれないが、「この修正は、なぜ、いつ、誰が行ったのか」といった履歴は（問題発生時の解決や、新機能追加時の方針決定の手がかりとして）非常に重要だ。

　特に第1回で書いたようにTeam Foundation Server（以降、TFS）やSubversionなどのソース・コード管理ツールで履歴を管理している場合、サーバ内に全ての情報が格納されている。従って、開発環境のバックアップの重要性は、このようなツールが導入される前と比較にならないくらい大きくなっている。

　そこで、一般的な開発時に使用する主なソフトウェアの基本的なバックアップ方法を一通り理解しておこう。

●OS環境の基本的なバックアップ方針

　一般的なサーバ群の実運用環境（以降、本番環境）では、物理サーバごとにサイジングを行い、仮想環境のためのバックアップ環境も用意する（そのため、ディスクの容量不足によるバックアップ不備という問題も起きにくい）。

　また、Windows Server 2008 R2のHyper-VとSystem Centerを使えば、「物理サーバの障害時に、仮想環境を別のHyper-Vホストで起動する」という高可用性機能を使用することもできる。このような高可用性対応を施す場合、当然ながら、高可用性仮想マシン環境用の共有ディスクや、障害発生時に備えるためのサーバを余分に用意しておくため、コスト（＝費用）がより大きくなる。

　さらに、System Center製品の1つである「Data Protection Manager（DPM）」というバックアップ用のソフトウェアを使えば、ソース・コードなどのファイル以外にもHyper-Vの仮想環境を丸ごと（＝ホストレベル・バックアップ）、バックアップ領域に取得することもできる。しかしそうすると、仮想環境のOS丸ごとの容量に加えて差分用のディスク領域が必要になるため、必然的にバックアップ用の領域は大きくなる。

　一方、（本番環境ではなく）開発環境では、「上記のような初期・運用コストの増大」と、「故障頻度や、（高可用性対応しない場合に）復旧までにかかる追加投資コスト」をはかりにかけて、結果的に「高可用性に対応しない」という判断をすることもよくある。開発環境の場合は、「サーバ環境の即時復旧」よりも「開発のソース・コードやドキュメントといった、プログラマーが作成したドキュメントなどのデータの復旧」の方が重要だ。こういったデータはしっかりとバックアップを取得して、サーバそのものの復旧にはある程度目をつぶった方が（コストを抑えるうえで）いいだろう。

　これはひとえに「高可用性に対応した場合の初期・運用コスト」と「（高可用性に対応しない場合の）障害発生時の復旧の手間」のバランスの問題なので、どちらにしなければならないということではない。一年に一度しか起きないかもしれない程度であれば、それに備えるコストと復旧のコストをしっかり考えようということだ。

　ただし、唯一の例外はActive Directoryのドメイン・コントローラだ。ドメイン・コントローラのバックアップに関しては、OSがサポートする手段（下記のリンク先を参照）でバックアップ・データを取得する必要があるので、注意してほしい。

• TechNet： ステップ バイ ステップ ガイド - AD DS のバックアップと回復
• TechNet： 仮想化ドメイン コントローラーのバックアップと復元に関する考慮事項

【コラム】低コストになったWindows Server 2012の高可用性環境構築

Windows Server 2008 R2のHyper-Vでは、System Center Virtual Machine Managerを使用して、なおかつクラスタ共有ボリューム（CSV）を使用しなければ、高可用性仮想マシン環境を構築できなかった。しかし、Windows Server 2012では高価な共有ディスクを使用することなく高可用性環境を構築できる。 　もちろん仮想マシンを複製するためのディスク領域は別途必要だが、Windows Server 2008 R2のHyper-Vと比べてかなりコスト面の敷居が下がったため、リリース後導入を検討してみてはどうだろうか。

●SQL Serverデータベースのバックアップ方針

　SQL Serverは、ほかのマイクロソフト製品と併用されることが多く、そのバックアップは重要だ。例えば開発者が使うソフトウェアでは、TFSやSharePointがSQL Serverを前提にしている。また、多くのアプリケーションでSQL Serverは活用されている。そこでここでは、SQL Serverのバックアップおよび、復旧、メンテナンスの基本を押さえておこう。

　SQL Server Expressエディションでデータベースを新規作成すると、そのバックアップ方式は「単純」が既定値になっている（次の表を参照）。

方式	説明
完全	データの追記・削除は、「トランザクション・ログ」と呼ばれる別ファイルに記録される。トランザクション・ログのバックアップ（以降、ログ・バックアップ）を取るまで、このトランザクション・ログが増えていく
一括ログ	完全を補完するためのもの。最小限のログ操作しか記録されない。例えばデータベース移行時などのデータの更新・追加が発生するときは、「一括ログ」で行った後、「完全」に戻すといった場合に使用する
単純	データベースに直接追記する。ログ・バックアップはない
SQL Serverのバックアップ方式

　なお、本番環境で使用されることを想定した、SQL Server Standard／Enterpriseエディションでは「完全」が既定値だ。もちろんこれはGUIで既定の状態でデータベースを作成する場合の話である。手動により意図的に「単純」に設定する場合もある。

　SQL Serverでのデータベース新規作成時に、上記の「単純」「一括ログ」「完全」を選択できるが、この選択によってバックアップ作業の手間や、必要なディスク容量に重要な差が出る。開発者が使う場合は、「完全」か「単純」のいずれかでよい。

　SQL Serverのバックアップに関して詳しくは、下記のリンク先を参照されたい。

• SQL Server データベースのバックアップと復元
• トランザクション ログ
• SQL Server 2008 R2自習書(バックアップと復元)

○SQL Serverデータベースのバックアップの間隔

　バックアップの間隔も重要だ。

　本番環境では、「完全」でデータベースを運用して、定期的にログ・バックアップを行い、障害に備えるという運用をしているだろう。その場合、トラブル発生タイミングから戻せる間隔を合意しておく必要がある。次の図は、完全バックアップとログ・バックアップを定期的に実施した場合の、時系列でのデータベース状態のイメージ図である。

完全バックアップとログ・バックアップを定期的に実施した場合の、時系列でのデータベース状態のイメージ図

ちなみに、「完全」バックアップでは、ログ・バックアップを行わない限り、SQL Serverのトランザクション・ログがどんどん蓄積される。初めてSQL Serverを使った人は、恐らく一度はディスク空き容量を枯渇させたことがあるのではないだろうか。

　開発環境の場合、本番環境のように10〜30分ごとにバックアップを取っても（そこまで大きな変更がないので）意味がない場合が多いだろう。従って、一概に「どういう間隔でバックアップしなければならない」という推奨は難しいが、最初は以下の時間でログ・バックアップを取得してみてはどうだろうか。

朝始業前（8時ごろ）
昼休み中（12〜13時）
定時後（18時〜）

　上記のような時間帯で作業を区切りにするか、バックアップの時間を周知しておけばよいだろう。開発者はバックアップ開始前までにTFSに（ソース・ファイルを）チェックインしておけばデータがバックアップされるため、「チェックイン後の最新が保存されていない」という状況を防ぐことができる。

　バックアップは、SQL Serverエージェントを使用する。完全バックアップとログ・バックアップだけではなく、データベースの整合性確認、インデックスの統計の再計算などのメンテナンス・タスクも定期的に行っておく必要がある。こういった定期的なメンテナンス・タスクは、開発用のサーバを夜間に停止しない場合であれば、夜間に行えばよい。筆者が行っているメンテナンス・タスクの例を挙げる（次の図を参照）。

定期的なメンテナンス・タスクの一例

　バックアップを取っただけで安心してはいけない。取ったバックアップが戻せなくてはバックアップの意味がない。たまには別のサーバに復旧作業を行って、バックアップ・データが正しいかどうか、復旧手順が正しいかどうかを手作業で確認しておくべきだ。手作業による毎回の復旧が面倒であれば、「どのような手順で復旧させられるかを調べて、その手順をスクリプトなどにまとめて、ある程度自動化しよう」という動機にもなるだろう。自分が面倒なことは、間違いなく他人も面倒なので、できる限り自動化することが好ましい。

　実行したバックアップは同じサーバに保存しておくと、サーバのディスクが壊れたときに復旧できなくなるので、必ず別の信頼できるサーバ、もしくはストレージに移動させよう。現在であれば、何らかのソフトでバックアップ・データを暗号化して、距離的に離れた外部のAmazon Web Services（AWS）やWindows Azureのストレージを使うという方法を検討してもいいだろう。

●Team Foundation Serverのバックアップ方針

　TFS 2010以降の場合、「TFS Power Tools」というツールが公開されており、複雑なバックアップ処理を行ってくれるので、ぜひ使ってほしい。

• TFS Power Tools December 2011（英語）

　もちろん、SQL Serverから直接、バックアップを取得することも可能だ。しかし、TFSデータのみのバックアップを取りたい場合には、TFS Power Toolsによるバックアップは極めて簡単だ。逆に言えば、TFS以外のSQL Serverのデータベースのバックアップおよび、SQL Serverのメンテナンス・タスクが実行されないため、前述のようなログ・バックアップ、データベースの整合性チェックなどの保守は、SQL Serverのメンテナンス・タスクで別途行う必要があるので注意してほしい。

　次のページでは、開発時にサーバ上で発生する、さまざまな性能問題に対処する方法を説明する。

INDEX
	［連載］いまさら聞けないWindows Serverの開発活用術
	第2回　Windows上の開発環境の障害やトラブルへの事前対策
	1．開発サーバのトラブル対応
	2．開発中の性能やトラブルに対処する（1）
	3．開発中の性能やトラブルに対処する（2）

「いまさら聞けないWindows Serverの開発活用術」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）