教えて！！プライベートクラウドの導入を成功に導くためのポイント

　パブリッククラウドとプライベートクラウド（ホステッドプライベートクラウド）の違いは「共有」と「専有」という言葉だけではクラウドの本質を理解するためには不十分です。

　そこで、パブリッククラウドとプライベートクラウドの本質的な違いを整理しつつ、プライベートクラウド導入の意義と成功に導くためのポイントを解説します。

▼ 目次
・ITインフラの利用形態の変遷
・プライベートクラウドの導入を成功に導くためのポイント

1. ITインフラの利用形態の変遷

　2000年代を振り返るとインターネットが世界的に広まり、ITシステムは急速なオープン化の波を迎えます。

　企業内にある様々な業務アプリケーションごとにITインフラが構築され、サイロ型の基盤が多数作られました。

　2000年代半ば、サーバー仮想化の技術が成熟し、サイロ化されたITインフラを統合化する取組みが増えました。

　さらに企業内や特定の利用部門（アプリ担当）に対して、仮想化統合された共通ITインフラを「サービスのように見せる」というサービス化の動きがはじまります。

　これが2000年代末に広まった「プライベートクラウド」の興隆です。

　「サービスのように見せる」という流れは、サービス事業者においても進みます。近年「IaaS（Infrastructure as a Service）」という言葉でおなじみのように、ITリソース（CPU、メモリ、ストレージ、仮想マシンなど）をインターネットを通じて提供する、さまざまなパブリッククラウドが展開されています。

図 1. 2000年代のITインフラの潮流

1-1. クラウド利用の実態

　クラウド時代へ進んできていますが、さまざまなIT調査会社を通じて実際の利用実態をみるとパブリッククラウドの企業利用の範囲は限定的で本格利用には至っていないようです。

　IaaSの本格的な普及が進んでいない要因は、さまざまですが情報システム部門のITインフラの作り方に一つの大きな要因があると考えられます。

　従来のサイロ型のITインフラでは、可用性やデータ保護方式、セキュリティ等への対処に多大な労力をかけて、システム個別に設計・構築・テストし、運用をしてきました。

　こうした状況に対してIaaSを利用することで、情報システム部門はITインフラの面倒を一切見る必要がなくなる・・・　IaaSにはそんな期待があったと思います。

　しかしながら、その期待にIaaS単体で応えることはできません。

　一般的なIaaSでは、サーバーやストレージ等のITリソースの提供はされますが、基幹系システムを例とするミッションクリティカルなシステムに求められるバックアップやセキュリティ対策などの多様な非機能要件や、OS・ミドルウェア監視や障害対応などの運用業務は提供されないため、引き続き情報システム部門にて設計・構築・運用が求められるためです。

　その結果、IaaSを利用しても従来のITインフラの作り方と本質的には変化せず、都度設計・個別運用が必要とされることが、クラウド利用の阻害要因の１つになっていると考えています。

1-2. プライベートクラウドの意義

　さて、IaaS単体では十分に情報システム部門の期待に応えられない理由を考察してきましたが、もう１つのクラウド形態である「プライベートクラウド」はどうでしょうか？

　プライベートクラウドはパブリッククラウドと異なり、「ITインフラ資産を自社で所有し、その設置場所が自社サーバールームになる」と解釈されがちです。

　しかし本質的な違いは「サービス提供仕様を自社で定義できるか、できないか？」にあります。

　パブリッククラウドの場合、ITインフラはクラウドサービス事業者が規定したサービス仕様に基づいて提供されます。

　一方プライベートクラウドは、自社の特殊な事情を踏まえて自社仕様のサービスを定義することができるため、一般的なIaaSでは不足しがちな可用性のパターンやバックアップ、監視、セキュリティといった様々な要件についても標準仕様を設けることができます。

　このような「プライベート・デザイン」でITインフラサービスを仕様化できるため、プライベートクラウドは、基幹系システムを例とするミッションクリティカルなITインフラ基盤の多様なニーズに応えられるクラウドになりえるのです。

図 2. プライベートクラウドとパブリッククラウドの違い

2. プライベートクラウドの導入を成功に導くためのポイント

　プライベートクラウドのCritical Success Factors （CSF：成功に導くためののポイント）は下記になります。

ITインフラアーキテクチャの標準化
ITインフラ運用の階層化
ITインフラの社内サービス化

　上記に対し、いかに自社事情に沿って「プライベート・デザイン」ができるかが重要な成功要因となります。

図 3. プライベートクラウドの導入を成功に導く3つのCSF

2-1. ITインフラアーキテクチャ標準化

　プライベートクラウドのITインフラ基盤は、さまざまな業務システムが稼働する共通ITインフラ基盤となります。

　業務システムごとに重要度は異なるため、標準化 ≒ 単一化と捉えてしまうと要件を満たせない（または過剰）なケースが発生します。

　一方、システム単位にバラバラの設計を行ったのではコスト削減効果が出ません。

　そのため、ポイントとなるのはITインフラアーキテクチャに複数のデザインパターンを持つことです。

　下図はサーバーの可用性に基づき、複数のデザインパターンを定義したものです。

図 4. サーバー構成別、可用性のレベル

　高可用性のデザインAからシングル構成のDまで用意することで、重要システムの本番環境から周辺システムや検証・開発環境までのITインフラを、網羅的に提供することができます。

　プライベートクラウドでは、サーバー以外にもデータ保護（バックアップ）、セキュリティ対策、ジョブ運用などについて、アーキテクチャの標準パターンを準備しておくことが有効です。

　それでは、ITインフラのすべての領域を事前に標準パターン化し、利用者が必要なタイミングで即時提供することができるでしょうか。

　残念ながら、すべての領域について標準テンプレートを活用して容易に構築することはできません。

　たとえば、ネットワークについてはシステムごとにアクセス要件が様々であり、導入時に都度ネットワーク設定変更作業が必要とされます。

　こうしたケースには、サーバー同様にデザインパターンを複数用意し、パターンごとに構築手順までを整備しておくことが有効です。これにより、利用者との要件調整の負荷削減をはじめ、構築リードタイムの短縮を見込むことができます。

2-2. ITインフラ運用の階層化

　ある大手企業ののプライベートクラウド構築プロジェクトでの実施した分析では、プライベートクラウドに関するコストのうち、サーバーやラインセンス、データーセンター内ラック費用は全体の半分以下で、運用コストが6割のコストを占めていました。

　仮想化統合の事例ではサーバーやラック数を大幅削減するなど、コスト削減効果が謳われていますが、実際の削減効果は極めて限定的であり、運用コスト削減こそ真に手がけるべき領域であることがわかりました。

図 5. プライベートクラウドのTCP比率

　プライベートクラウドの運用の特徴は、運用体制が１対Ｎ型になることです。ITインフラは共通化され一つの体制となり、複数の業務システムを担当するチームに対して横断的に運用サービスを提供する体制となります。

　この時、クラウド提供者と利用者の運用責任分解点を明確にすることが重要です。

　クラウド提供者の運用スコープは、２つのアプローチで検討を進めることができます。

　プライベートクラウドの運用の特徴は、運用体制が１対Ｎ型になることです。

　ITインフラは共通化され一つの体制となり、複数の業務システムを担当するチームに対して横断的に運用サービスを提供する体制となります。

　この時、クラウド提供者と利用者側の運用責任分解点を明確にすることが重要です。クラウド提供者の運用スコープは、２つのアプローチで検討できます。

　１つは、利用者が直接操作できるかどうかの観点です。

　例えば業務システムを技術層に分解した場合、ハイパーバイザー以下の領域はアプリ担当者が直接操作することはできません。一般的なIaaSは、このような考え方に基づき役割定義をしていることが多いと思います。

　もう１つは、運用標準化が可能かどうかの観点です。

　下図ではOS・MW層との間で分界点を設定していますが、汎用的なOS・ミドルウェア製品に対する監視や定型的な変更作業などは、業務システム固有の要件は少なく、共通的な運用を行うことが可能な場合も多くあります。

　このような共通運用をクラウド提供者側で集中的に担うことで、更なる運用コスト削減を狙うことができます。

図 6. クラウド提供者の運用スコープモデルScope Model

　プライベートクラウドの運用コストを抑制していくには、運用業務を可視化し、その業務量や難易度などの観点から必要なスキルと費用のバランスを考慮して、階層化した運用体制を組むことが有効です。

　運用には、日常的に行うシステム監視やバックアップのような業務から、クラウド基盤の増強計画など頻度は少ないものの専門性やユーザフォローを要する業務など、応対性質が異なる様々な業務があります。

　これらを業務量の多さの軸と、利用者側とのユーザ接点の大小の軸で整理します。下図の例では、３つに分類し、この分類にそって運用体制を階層化します。

図 7. クラウド運用業務の階層と運用体制

Tier 1

　非常に業務量が多くかつ定型的な処理業務です。例えば障害監視からイベント通知までの処理です。これらは監視システムをはじめ、RunBookAutomationなどのオペレーション自動化などのITによる自動化に向く業務です。

Tier 2

　比較的難易度は低くかつ業務量が多い運用業務です。障害切り分けや定型的な変更作業（サービスリクエスト）などの業務は手順書などを用意することで、平均的なITスキルのSEにて対処可能です。また、複数の業務システムで共通的に運用できますので、SE体制をシェア化することができます。

Tier 3

　非常にハイレベルのエンジニアスキルを要する障害分析や、パフォーマンス改善などの業務です。この階層では、利用者への適切な説明などユーザ接点の濃い業務を担うため、技術スキルはもとより、長年の業務経験が求められます。利用者からは高スキルのSEを求められがちですが、運用費用もパラレルに上がってしまいます。そのためコスト分散可能なシェア型SE体制や自動化システムの導入などにより、運用体制を整備することが重要です。さらにこの運用体制の階層化は、プライベートクラウドのサービスインまでの対策では終わりません。ライフサイクル期間中、業務の定型化・自動化を継続的に推進し、引き続き運用コストの原価低減を進めることが重要です。

2-3. ITインフラの社内サービス化

　サービス化とは、標準化されたアーキテクチャと運用を、利用者（アプリ担当）に対して適切に利用できるよう、利用申請方法や提供機能のメニュー化などを整備することです。

　従来の個別システムでは、設計書やパラメータシートがITインフラの仕様を表現するドキュメントでしたが、プライベートクラウドでは利用者がITインフラの細かなドキュメントを把握することなく、容易にサービス仕様や制約事項を理解できる状態にすることが重要です。

　大量の文書や複雑な文書を利用者に公開しても、「読まれず」「理解されない」事が多くなり、結果としてプライベートクラウド構築後にルールを無視した独自の設計を要求される原因にもなりかねません。

　そのため、アプリ担当の利用シーンごとに、サービス利用ガイドや申請書、マニュアルなどの必要ドキュメント類の設け、その利便性を高める工夫が求められます。

図 8. プライベートクラウド関連のサービスドキュメントイメージ

　なお、サービスメニュー化にあたっては、提供者視点で提供物だけを示すのではなく、利用者が判断しやすく簡潔な選択肢を用意することが重要です。

　また、メニュー選択のために、可用性やデータ保護レベル（RTO/RPO）、コンプライアンスや監査対応の観点など、利用者視点にたって業務システムの要求事項に基づく選択基準を付記することも有効です。また利用コストについても、ITインフラや運用が共通的に利用されるため、従来のサイロ型システムとはコスト配賦方式が異なるため、予め配賦のルールや仕組みを整備する必要があります。