第2回 データの管理、「サービスレベル」でしてみると……：データで戦う企業のためのIT処方箋（1/2 ページ）

データ活用には「データ管理」も大切です。でも、どうすればいいのでしょうか。今回は「データにまつわるサービスレベル」という視点を紹介します。

[森本雅之，ITmedia]

　データ管理に限らず、ITシステムを用いたサービスを導入する際には、定めた目標の実現に必要な機能・性能を洗い出して、具体的なシステム構成に落とし込む作業が必要です。日本ではほとんどのユーザー企業がベンダーやSIerと一緒に、あるいはお任せして要件を詰めていきますが、まずは業務に応じてITサービスが基本的に実現すべき目標――「サービスレベル」を定めます。

　サービスレベルは「サービス品質」ともいわれますが、ITシステムの設計では“根”や“幹”に当たり、ここから必要な“枝”や“葉”に広げて具体的な検討に進み、決定していくものとなります。サービスレベルや、定めたサービスレベルを説明・記載した「サービスレベルアグリーメント」（SLA）については、ITILなどでも定義されている用語ですので、ご存知の方も多いと思います。

　では、いったい何を決めればよいのでしょうか。今回は、ベンダーやSIerに提案を求める際、または自社で要件を検討する際に必要なサービスレベルについて掘り下げます。

サービスレベルの検討項目とは

　データの管理やデータ管理を支える基盤システムを検討する際に、分かりやすいところでは各種の「性能」のほか、システムがどれだけ利用可能な状態でいられるかを示す「可用性」、万一トラブルが発生した際にどれだけ早く利用可能な状態に戻す必要があるかを示す「復旧性」といった項目を検討し、定義します。

　次の表に、データの利活用において重要となる主なサービスレベルの項目を例示します。

表：主要なサービスレベル項目（※記載数値は一般的な例です）

　表の数値は一般的なものであり、実際の利用環境や要件で変動しますので、一つの目安として参考にしていただければと思います。

　3つの観点について具体的にみていきましょう。

性能

　「性能」そのものは非常に明確ですが、IOPS（1秒間の読込／書込可能回数）とスループットの関係について注意が必要です。第1回でも触れた仮想化技術が一般的になったことで、システムの集約度は年々高まり、1つのシステムで発生するデータ処理の数が顕著に増大しています。

　従来はスループット（MB/s、GB/s）での試算だけで済むこともありましたが、いまでは高度に集約されたリアルタイムデータベース（RDB）システムや仮想デスクトップインフラ（VDI）など、通信されるデータ量ではなく、「どれだけ高速にやりとりできるか」でIOPSがボトルネックになる事例が多くなっています。このことから、特に主要な業務システムではIOPSで試算し、検討を要するケースが増えつつあります。大半のエンタープライズ向け業務アプリケーションには、利用環境で必要な性能を洗い出すためのサイジングガイドやツールが提供されています。特にIOPSについてはそれらを参考にすることが重要です。

　IOPS性能としては、重複排除技術による処理数の削減など、効率化できるソリューションも身近になってきています。これらは改めて紹介します。

可用性

　後述する「復旧性」とは異なり、データの重要度による常時／非常時アクセス性の担保という観点です。「多重度」では従来のシステム設計を踏襲することが多いかと思いますが、保持期間と応答時間に関して注意が必要です。

　なぜなら、ビッグデータ活用が目的で保持期間を「永久」と定義するシステムがあれば、法令順守の目的で読み出しが数年に1回程度しかないシステムも出てきているからです。コストを抑え、ROIの高いシステムを設計するために、第1回の図2（下図参照）で示したデータ種類ごとに、この要件の定義が必要です。

データ種別の分類

復旧性

「復旧性」は可用性の一部ではありますが、構成・設計によって利用する技術が異なる場合があります。そのため、明示的に別途定義すべき項目になります。

　復旧レベル目標は、災害復旧（DR）など一時的に別システムや別サイトで動作させる場合に必要な項目です。以前は性能劣化を危惧して同一構成によって定義・設計するか、検討が難しいので定義しない（できない）、というケースがほとんどでした。しかし、最近ではクラウドコンピューティングでのCPUやメモリなどのリソースの増減とサーバ数の増減を活用すれば、DR時に必要な性能を適切に定義し、コストの抑制と運用効率の向上を実現できるようになりました。スモールスタートの定義・設計も可能なので、ぜひ検討項目に加えるほうが良いでしょう。