SQL Server: 何をおいてもデータ保護

  • [アーティクル]

SQL Server で管理している企業データ ストアの高可用性を確保することは、すべてのデータ管理戦略において必要不可欠です。

Paul S. Randal

データは、いつでも格納および取得できなければ、ビジネスは停止します。どの企業にとっても、データは人材の次に重要な資産になっています。多くの場合、SQL Server 2008 または SQL Server 2008 R2 が、データ管理戦略の中核を担っています。このように考えると、開発者とデータベース管理者は事業継続の一翼を担っています。

ただし、ビジネスの部門マネージャーからデータ層の管理者に、どの程度の決定的なガイダンスが提供されていて、ビジネス要件は明確に伝達されているのでしょうか。また、情報は、技術の専門家が生産的な戦略を立てられるような形で伝達されているのでしょうか。

市場区分によっては、セキュリティ監査、データの暗号化、データの保持など、インフラストラクチャについて厳しい法令順守の要件を満たす必要があります。この要件を満たせない場合、ビジネスには、罰金が科せられたり、譴責されたりします。また、最悪の場合、競争の激しい市場では、評判を落としたり、今後の利益の損失を招くこともあります。

データ管理戦略を調整する

セキュリティ、レポート、負荷管理、監査など、ビジネス部門のリーダーが簡単かつわかりやすく伝達できる要件もあります。さいわい、このような要件は、SQL Server 2008 のフレームワークでも簡単に実装できます。

  • データのセキュリティ要件には、静的なデータを暗号化する透過的なデータ暗号化、コンピューターや暗号化したデータと違う場所に暗号化キーを格納できる拡張キー管理などの機能を使用して対応できます。
  • レポートの要件には、SQL Server Reporting Services の機能を使用して対応できます。
  • ワークロードのパフォーマンスは、リソース ガバナーを使用して予測できます。
  • 総合的な監査の要件には、SQL Server Audit を使用して対応できます。

ただし、あまり適切に伝達されていない重要な 2 つのビジネス要件があります。それは、システムのダウンタイムと許容できるデータの損失です。これらは、それぞれ目標回復時間 (RTO) および目標回復ポイント (RPO) と呼ばれます。残念ながら、ビジネス部門のマネージャーが RTO と RPO について考慮するのを怠り、大惨事が発生したときに、データ層が必要なレベルで保護されていないことが判明するという事象はよくあることです。これがダウンタイムやデータの損失につながります。

ビジネス部門のマネージャーとデータベース管理者のどちらであっても、ビジネスで必要なレベルでデータ層が確実に保護されているかを把握しているかどうか今すぐ考えてみてください。保護されていないことが判明した場合、この状況を解決するために何をしますか。

パニックになったり、現状に甘んじたりするのは適切な対応ではありません。来週までに戦略を導入するための訓練を行うという対応は、大惨事の原因になるだけです。適切かつ包括的な SQL Server の高可用性と障害回復 (HA/DR) 戦略を設計して実装するには、慎重さと勤勉が必要です。問題を無視すると、災難を呼び寄せることになり、そのような行為は業務上の過失であるも同然です。

要件を考慮する

成功する戦略を設計するうえで欠かせないのは、まず、ビジネス要件を理解することです。それから、ビジネス要件とビジネスの制限事項のバランスを取る必要があります。この段階では、IT 部門のリーダーとビジネス部門のリーダーが、実際に会って、物を見て話をする必要があります。戦略の要件には、ビジネスの運営に必要なデータごとに、次の要素を含める必要があります。

  1. 会社のデータ ストアにある他のデータを比較して、このデータは、どの程度重要ですか。ビジネス部門のマネージャーは、すべてのデータの優先順位が高く、同様に保護する必要があると主張することが往々にしてあります。少量のデータなら問題ありませんが、複数の SQL Server インスタンスに数 TB ものデータがある場合は非現実的です。
  2. 会社は、どの程度のデータ損失に耐えられますか。ビジネス部門のマネージャーが、どのようなデータ損失も望んでいないことは理解できますが、必ずしも実用的であるとは限りません。
  3. データは、どのくらいの期間利用できなくてもビジネスに支障がありませんか。ビジネス部門のマネージャーは、ダウンタイムを望んでいないと思いますが、実際問題として、それは実現不可能です。ただし、それに近い状態は実現できます。
  4. 1 つ目または 2 つ目の要素は、1 日のうちで変化しますか。または、週末に変化しますか。これは要件に対応するうえで大きな影響があります。ダウンタイムとデータの損失をなくすという目標は、24 時間 365 日ではなく、平日の 9 a.m. から 5 p.m. などのように期間を限定すれば、達成しやすくなります。
  5. データの可用性と耐久性を確保するために、ワークロードのパフォーマンスが低下することは許容できますか。データの損失を完全に抑えられるテクノロジでは、トランザクション ログ レコードまたは I/O サブシステムの書き込みを同期的にミラーリングする必要があります。どちらも処理の遅延につながるので、トレードオフが発生します。

この場合は、特定のデータが、アクセスできないか、損失したときにビジネスに与える影響を考慮します。顧客、企業イメージ、および法令順守に与える潜在的な影響をじっくり考えて数量化すると驚かれるかもしれません。

制限事項を考慮する

HA/DR 戦略の設計と実装では、制限事項を考慮する前に、技術的な設計に着手するというミスがよくあります。つまり、計画段階に戻ったり (時間とお金の浪費)、ビジネス要件を満たさない基準以下の戦略を実装することになります。

技術的な制限と非技術的な制限は、どちらも多数あります。通常、最も重要な要素は予算です。ハードウェアが増えれば消費電力が増えます。消費電力が増えると、熱放散が増えます。熱放散が増えると、空調設備が必要になります。空調設備が増えると、さらに消費電力が増えます。その結果、より広い場所が必要になり、物理的なインフラストラクチャにかける予算を増やす必要があります。ハードウェア、SQL Server や Windows の追加ライセンス、ネットワーク帯域幅、追加のシステムやデーターセンターの管理を担当する追加要員にかかるコストも考慮する必要があります。

妥協点と企業のジグソー パズル

すべての技術的な制限事項を熟知したら、あとは、最適な妥協点を見つけるだけです。ビジネスにとって重要なデータの優先順位リストが必要です。対応が必要な制限事項が判明したら、最も重要なビジネス要件を満たすのに役立つテクノロジを評価します。

重要なのは、新しいビジネス要件を満たすために、安易に既存のテクノロジを採用しないようにすることです。ビジネスの優先順位に照らし合わせて適切に評価しないでテクノロジに飛びついたり、採用したりしないでください。早い段階で尽力して、プロセスを適切に調査することをお勧めします。このようにすると、長期的には、時間とお金を節約できるより良い戦略を立てられます。

購入可能なテクノロジでビジネス要件を満たせない場合は、ビジネス部門のリーダーと話をし、ビジネス要件を変更して、予算との折り合いを付ける必要があります。たとえば、同期テクノロジを購入する予算がない場合に、技術者として、データ損失を全面的に回避するというビジネス要件に同意するのは意味がありません。大惨事が発生したときには、ビジネス部門のマネージャーの期待に応えることができないばかりか、IT スタッフが、その事態の責任を問われることになります。

HA/DR 戦略を設計するときの最大の難関は、組織の全体的な IT 戦略と協調性を持たせることです。たとえば、大企業でデータベース管理者を務めている場合、Windows サーバー、ネットワーク、ストレージ、インフラストラクチャの整備などをそれぞれ担当しているチームが存在している可能性が高いでしょう。大惨事が発生してから 4 時間以内に使用できるようにする必要があるデータベースがある場合、それを実現するためには、他のすべてのチームの協力を仰ぐ必要があるかもしれません。また、チーム間の駆け引きと関係も考慮する必要があります。また、他のチームは、データ層チームと同じサービス レベル アグリーメント、ビジネス全体の期待と取り決めに同意する必要があります。

テスト

データ層が十分に保護されていないと感じる場合は、HA/DR 戦略がビジネスで適切にテストされていない可能性が高いと思われます。HA/DR 戦略の設計と実装では、システムを実際にテストして、危機的な状況が発生したときに対応できるようにすることが不可欠です。

ただし、言うは易し、行うは難しです。ダウンタイムを引き起こす可能性のあるテストの実施をビジネス部門のマネージャーに承諾してもらうのは容易なことではありません。ですが、すべての人がオンサイトで作業をしているときにテストを実施した方が、大惨事が発生して、その状況に介入して、迅速に問題を修正することができるから良いという議論を展開することもできます。もう 1 つの選択肢は、少数のスタッフしかいない休日の 2 a.m. に大惨事が発生したときに問題となる設計を特定することです。

ダウンタイムやデータの損失に対してデータ層が十分に保護されていないことが判明するかもしれませんが、SQL Server 2008 または SQL Server 2008 R2 を使用して HA/DR 戦略を実装するオプションは多数あります。さまざまなテクノロジとトレードオフを理解し、他の企業が正常に展開したアーキテクチャを確認してみてください。詳細については、次のホワイト ペーパーとブログの投稿を参照してください。

有効な戦略を導入するための努力をしてください。それがビジネスを保護して、予期しないダウンタイムを回避するための唯一の方法です。

Paul Randal

Paul S. Randal は SQLskills.com の代表取締役であり、Microsoft Regional Director でもあり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。また、SQL Server 2005 では DBCC CHECKDB/repair コードを記述し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Paul は障害回復、高可用性、およびデータベース メンテナンスの専門家であり、世界中のカンファレンスで定期的に講演を行っています。彼のブログは、SQLskills.com/blogs/paul (英語) で公開しており、Twitter は twitter.com/PaulRandal (英語) でフォローできます。

関連コンテンツ