プライベートクラウド導入を成功に導くための3つのポイント(第3回)
~ITインフラの社内サービス化~

pexels-photo-335907-1

パブリッククラウドとプライベートクラウド(ホステッドプライベートクラウド)の違いは「共有」と「専有」という言葉だけではクラウドの本質を理解するためには不十分です。
パブリッククラウドとプライベートクラウドの本質的な違いを整理しつつ、プライベートクラウド導入の意義と成功に導くためのポイントを解説します。

第1回目ではクラウド利用の実態に触れつつ、基幹業務系システムなどミッションクリティカルなITインフラ基盤の多様なニーズに応えられるプライベートクラウドの意義について解説しました。第2回目では本題となるプライベートクラウド導入を成功に導く1つ目カギの「ITインフラアーキテクチャ標準化」と2つ目のカギ「ITインフラ運用の階層化」の一部について解説しました。

ここからは、「ITインフラ運用の階層化」について深堀し、3つ目のカギ「ITインフラの社内サービス化」についてさらに話を進めます。

ハイライト
● プライベートクラウド導入を成功に導くポイント②――ITインフラ運用の階層化
● プライベートクラウド導入を成功に導くポイント③――ITインフラの社内サービス化

② ITインフラ運用の階層化(つづき)

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

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

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

もう1つは、運用標準化が可能かどうかの観点です。下図ではOS・MW層との間で分界点を設定していますが、汎用的なOS・ミドルウェア製品に対する監視や定型的な変更作業などは、業務システム固有の要件は少なく、共通的な運用を行うことが可能な場合も多くあります。このような共通運用をクラウド提供者側で集中的に担うことで、更なる運用コスト削減を狙うことができます。

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

プライベートクラウドの運用コストを抑制していくには、運用業務を可視化し、その業務量や難易度などの観点から必要なスキルと費用のバランスを考慮して、階層化した運用体制を組むことが有効です。運用には、日常的に行うシステム監視やバックアップのような業務から、クラウド基盤の増強計画など頻度は少ないものの専門性やユーザフォローを要する業務など、応対性質が異なる様々な業務があります。これらを業務量の多さの軸と、利用者側とのユーザ接点の大小の軸で整理します。下図の例では、3つに分類し、この分類にそって運用体制を階層化します。

クラウド運用業務の階層と運用体制
stage and organization

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

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

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

③ ITインフラの社内サービス化

3つ目の成功のポイントは「ITインフラの社内サービス化」です。

サービス化とは、標準化されたアーキテクチャと運用を、利用者(アプリ担当)に対して適切に利用できるよう、利用申請方法や提供機能のメニュー化などを整備することです。従来の個別システムでは、設計書やパラメータシートがITインフラの仕様を表現するドキュメントでしたが、プライベートクラウドでは利用者がITインフラの細かなドキュメントを把握することなく、容易にサービス仕様や制約事項を理解できる状態にすることが重要です。

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

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

プライベートクラウド関連のサービスドキュメントイメージdoc-image

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

最後に

このように、プライベートクラウドに失敗しないためには、単にどんなサーバーやストレージを選ぶかではなく、どのような“プライベート・デザイン”を設計するかが重要です。

そして、プライベート・デザイン設計では、①パターン化したITインフラアーキテクチャの標準化、②運用コストを最適にする運用階層化、そして③利用者視点でわかりやすいサービス化の3点に注力することがプライベートクラウドの成功の秘訣です。

関連記事:
プライベートクラウド導入を成功に導くためのポイント(第1回)
プライベートクラウド導入を成功に導くためのポイント(第2回)

編集: ビジネスonIT

Pocket

コメント