インフラ・運用デザインパターン定義書 サンプル V1.0 2015/03/27 ※本書は、インフラ・運用デザインパターンプロジェクトのサンプルドキュメントです Sample 目次 1. 2. 3. 4. 5. 6. 背景 本書の目的と位置付け 前提 現状の課題とアプローチ 定義 デザインパターン定義 1 Sample 1.背景 私達がITサービスやITシステムをユーザーに提供する際の要件定義や設計を行うシーンにおいて、考慮しなければ ならないアーキテクチャや構成方法、関連製品などは仮想化技術の発展・浸透とともに非常に多岐に渡りつつある。 これらアーキテクチャや構成方法、関連製品、運用性などをすべて把握し、様々な観点から適切な提案、要件定義 ができないエンジニアが多数存在するのが現状である。そのようなエンジニアが携わった案件では、顧客からの要 求に対する不適切な評価の元、オーバースペックまたは逆に要件が満たされていない・マージンが少ない等の、顧 客要求にマッチしないインフラ構成などが提案・構築されることもあり、導入後の余剰設備化や早期の設備増加も しくは後の運用コストの増加に繋がることも珍しくない。 本プロジェクトではクラウドオーケストレーションソフトウェアの開発をきっかけに、今一度インフラ構築や運用 の体系化に着目し、クラウドファーストの時代にあるべき運用を検討するとともに、アーキテクチャ検討や要件定 義等の上流工程の品質向上とコスト削減を支援するデザインパターンの定義を試み、クラウドオーケストレーショ ンソフトウェアの意義・定義の明確化を目指す。 2 Sample 2.本書の目的と位置付け ITサービスやITシステムの提供に必要となるインフラ基盤および、インフラの運用について広い視点での相互関係 を整理し、フレームワークとなるべき骨格をデザインパターンとして組み立てることで、「標準的なインフラ構 成」などの概念的表現でも関係者間での早期の知識共有・情報共有を図ることが可能となる。 本書ではインフラ・運用のデザインパターンを作成するにあたり、「インフラ・運用デザインパターンとは何 か？」を定義することを目的とする。 インフラ・運用デザインパターン定義書 （本書） 作成 指針 インフラ・運用デザインパターン書 （仮） 3 Sample 3.前提 本プロジェクトでは以下の前提の元、記載を行う。 1. 永続的な内容を目指さず、技術・時代の潮流に合わせた継続的な定義更新を前提とする。 2. インフラ・運用デザインパターンはすべてを網羅的に記載することを目的としない。 3. インフラ・運用デザインパターンはプライベートクラウドを含むクラウド技術・サービスの利用を前提とする。 4. インフラ・運用デザインパターンは特定の仮想化技術、クラウド技術・サービスに影響されない記載を前提と する。ただし、特定の仮想化技術、クラウド技術・サービスがデファクトになっている場合は、記載内容や記 載方法に注意したうえで特定の仮想化技術、クラウド技術・サービスを記載する。 4 Sample ４.現状の課題とアプローチ 5 Sample ４.現状の課題とデザインパターン定義へのアプローチ 最終的にビジネスに結び付く実証実験や製品開発において、課題の定義は非常に重要である。課題の定義を誤れば、 製品の方向性やマーケティングも相対的に誤ったものになる可能性がある。 本プロジェクトでは課題の正当性を十分に考慮したうえで、以下の流れで課題をデザインパターンへのインプット として取り扱う。 非機能要求グレードからの仮パターン定義 （メインストリーム） 課題抽出源の定義 課題抽出 デザインパターン定義 課題への アプローチ検討 6 Sample ４-1.課題抽出源の定義 課題抽出源 の定義 課題抽出と 課題整理 課題への アプローチ検討 課題解決の 方向性導出 ＜課題の抽出源＞ 評価軸は、“情報源”に対する一般的な評価軸（客観性、定量性）を採用。専門性は本件独自の評価軸。 課題抽出源については、入手の可能性や評価軸から見た妥当性から列挙。 本件において、最低限確保しなければならない課題抽出源を定義。 N o 課題の抽出源 説明 1 【PJチーム自身】 プロジェクトチーム自身の意見 プロジェクトチームによる実務経験、 仮説による基底となるインプットを 定義し、ベースとなる課題を設定 する。 2 【PJチーム関係者】 プロジェクトチームの意思を正しく理解 し、的を得た課題を提供してくれる チーム以外の関係者 プロジェクトチーム以外による実務 経験、仮説による基底となるイン プットを定義し、ベースとなる課題 を設定、補完する。 3 【専門家】 本件に関する知見を広く持つ専門家 へのインタビュー 公的、もしくは準公的に認知され ている専門家の意見をインプットと し、裏付けを強固にする。 4 【一般意見】 一般意見（インターネット記事、書 籍等からの分析） 一定レベル以上の公的、もしくは 準公的な意見をインプットとし、最 低限の裏付けを確保する。 5 【専門意見】 専門意見（コンサル会社のアンケー ト集計等） 公的、もしくは準公的に認知され ている専門家の意見、定量分析 結果をインプットとし、裏付けを強 固にする。 評価 専門性 客観性 定量性 △ （基準） △ （基準） △ （基準） ○ ○ （情報量によ る） （人による） ◎ △ △ △ デザインパターン 項目整理 入手可能な 情報 ◎ ◎ （情報量によ る） △ ◎ （記事内容によ る、宣伝傾向注 意） ○ ◎ ◎ ◎ ◎ ◎ （人による） ○ 7 Sample ４-2.課題抽出源の定義 課題抽出源 の定義 課題抽出と 課題整理 課題への アプローチ検討 課題解決の 方向性導出 デザインパターン 項目整理 ＜参考：課題抽出源の評価＞ 本件において、最低限確保しなければならない課題抽出源を定義するための評価可視化。 専門意見を確保できればベスト、最低ラインは一般意見の確保。専門家意見までしか確保できない場合は専門性 が若干低くなるため要注意。 専門性 専門意見 高い 一般意見 専門家 PJチーム 自身 PJチーム 関係者 今回、入っては いけないゾーン 低い 客観性・定量性 低い 高い 8 Sample ４-3.課題抽出と課題整理 ＜課題の整理＞ 課題抽出源 の定義 課題抽出と 課題整理 課題への アプローチ検討 課題解決の 方向性導出 デザインパターン 項目整理 本件では、インフラ・運用において想定される課題の抽出・整理・評価を行う。課題抽出源は、社内意見、社内関係者意見、専門家、 一般意見、専門意見を抽出源としている。これらから抽出された情報をキーワードで分類し、傾向を整理をした結果、以下のNo１~４ が主な課題として認識できた。整理した結果の課題内容、傾向説明と重要度を以下に示す。重要度とは、抽出したキーワードの出現率 の高い順から重要性を◎（とても重要）、○（重要）、△（普通）の三段階で表現している。 N o 主な課題 課題内容、傾向説明 コスト（管理・ 運用、構築） • 初期構築コスト、ソフトウェアライセンス、保守契約などの維持コストを低く抑えたい • 遊休設備をできるだけ削減したい • 運用にかかる人件費を低く抑えたい（少ない人数、高コスト要員の削減） 2 スキル・技術 • 高集約・高効率・高可用性の技術を採用したいが、トラブルや事故は避けたい • オープンソースなどの技術を採用したいが、安定して分かりやすいものを採用したい • 情報が入手しやすく、将来性のある技術を採用したい 3 品質 • コスト、品質をバランスよく検討し、無駄な投資は避けたい • 導入初期はもちろんのこと、年数を経ても安定した品質を保つようにしたい • 品質を保つための手段が明確になっているアーキテクチャを採用したい 4 構成管理 • コンピューティングリソースの拡張性・収縮性を生かす、適切な構成管理を実施したい • 構成管理作業を自動化し、運用コストを削減したい 1 5 その他 重要度 「その他」は、上記、4つ以外の課題である「安定稼働」、「インシデント」、「問題管理」、「時間提供」、「提供 時間」、「事故発生」などが該当する。これらは、課題の抽出源から該当するものがあまり多くはなく、（下記 の理由により、）上記4つと比べて重要度は低くい傾向と思われる。 ★ヒント★ 主な課題は、課題抽出源から導き出した結果として上記、No1~4が挙げられたが、各現場によって課題は異なる為、それぞれの現場での課 題抽出と整理の検討が必要となる。 9 Sample ４. 課題へのアプローチ 課題抽出源 の定義 課題抽出と 課題整理 課題への アプローチ検討 課題解決の 方向性導出 ＜課題へのアプローチ＞ 抽出できたそれぞれの課題に対し、アプローチ方法を検討する。 各所で散見されたコストを優先解決課題とし、その他の課題も含めてアプローチを以下のように検討した。 コスト 初期構築コスト の抑制 初期構築 規模の見極め 構築エンジニア スキルの見極め 維持・運用コスト の抑制 運用体制、 運用内容の見極め インフラ基盤の スモールスタート 柔軟なリソースの 拡張性 サービスレベルの スモールスタート 非機能要件への ソフトウェア的対応 ロースキルでも ハイリターンな基盤 ロースキルを補うテン プレート等の存在 構築品質の確保 構築結果の テスト自動化 スモールスタート 監視の充実と 運用作業自動化 デザインパターン 項目整理 左記の７点をアプローチ先 として検討する 運用品質の確保 HW・SW保守 通常運用・保守運用 の手動作業削減 運用ルールの ソフトウェア化 保守費の低減 クラウドサービス、 OSSの積極利用 10 Sample ４. 課題解決の方向性 課題抽出源 の定義 ＜課題解決方向＞ 課題に対して抽出できたそれぞれのアプローチ方法をまとめる。 課題抽出と 課題整理 課題への アプローチ検討 課題解決の 方向性導出 デザインパターン 項目整理 柔軟なリソースの 拡張性 非機能要件への ソフトウェア的対応 クラウドサービス、 OSSの積極利用 ロースキルを補うテン プレート等の存在 構築結果の テスト自動化 仮想化基盤 の採用 パブリッククラウド の利用 構成管理ツール の採用 可用性・信頼性 OSS利用 性能・拡張性 OSS利用 オーケストレーション ツールの採用 OSSの安定利用 OSSをベースとしたオーケス トレーションの仕組みをテン プレート化する テンプレート作成 運用のスクリプト化 監視の充実と 運用作業自動化 運用ルールの ソフトウェア化 汎用的な利用方法 の検討 テンプレートをデザインパターンとして整理する 評価項目は非機能要求グレードとする ★ヒント★ 本件の課題解決の方向性は、本件独自のアプローチ方法により導き出された結果である。上記は、あくまでサンプルであり必ず、全てのアプ ローチ方法が上記結果になるとは限らない。各現場にて、課題解決についてのアプローチ方法は検討が必要である。 11 Sample ４.現状の課題とデザインパターン定義へのアプローチ 課題抽出源 の定義 課題抽出と 課題整理 課題への アプローチ検討 課題解決の 方向性導出 デザインパターン 項目整理 ＜デザインパターンと非機能要求の整理＞ デザインパターンの項目を決定するうえで、非機能要求グレードを主たる評価項目として採用するが、非機能要求グレー ドの全項目でパターンを導出すると非常に多くのパターンが導出される。 そのため、デザインパターン定義時には非機能要求グレードのモデルシステムシートにある大項目レベルの項目と、本プ ロジェクトで抽出された課題項目をインプットとしてデザインパターンの評価項目を定義する。 評価項目 大項目 1 内容 小項目 構築期間（稼働費） インフラ・アプリケーション全体のシステム構築にかかる工数を示す。 稼働期間 システムの稼働期間を示す。稼働期間は、運用にかかる工数、ライセンス等の費用算出目安となる。 ナレッジ入手 インフラ・アプリケーション全体のシステム構築に必要なナレッジの入手性を示す。ナレッジが少なくなれば高単価エンジ ニアのアサインやプロフェッショナルなコンサルティングサービスが必要となる場合が発生する。 稼働率 システムが要求する稼働率を示す。 目標復旧水準 システムが要求する障害時の目標復旧水準を示す。 6 大規模災害対策 システムが要求する大規模災害時の事業継続性を示す。 7 リアルタイム性 システムが要求する情報のリアルタイム性を示す。 拡張性 システムが要求するインフラ基盤に対するスケール性を示す。 トラフィック システムが要求するサーバーに対するトラフィックのキャパシティを示す。 10 トランザクション システムが要求するサーバーに対するトランザクションのキャパシティを示す。 11 運用時間 システムが要求する運用時間を示す。 12 バックアップ・リカバリ システムが要求するバックアップレベルを示す。バックアップ量が多い場合、可用性の目標復旧水準や事業継続性を 担保するためのアーキテクチャを選択しなければならない。 監視 システムが要求する監視レベルを示す。外的(BIA)、内的(RCA)、リアルタイム性等で評価する。 メンテナンス システムが要求する可用性とセキュリティを考慮し、メンテナンス性を示す。高可用性であればその分、必要にして十 分なメンテナンス性を確保しなければならない。 移行性 システム移行時に必要な移行量（データ量、移行頻度）を示す。移行量が多い場合、コストに影響が発生する。 セキュリティ システムが要求するセキュリティレベルを示す。システムの公開範囲、データ重要性等を考慮し、必要にして十分なセ キュリティレベルを確保しなければならない。 2 3 コスト スキル 4 5 8 9 13 可用性 性能 運用性 14 15 移行性 16 セキュリティ ★ヒント★ 評価項目は、デザインパターン基本表において、各システムの評価を行う項目となる。各現場によって課題や注視している観点が異なる為、 評価項目を見直したうえで定義する必要がある。 12 Sample ５.定義 13 Sample ５.定義 インフラ・運用デザインパターンにおける、主なキーワードのスコープや言葉の意味などを定義する。 No 1 定義の対象 説明 インフラ 本書における「インフラ」が指し示すスコープを定義する。 2 運用 本書における「運用」が指し示すスコープを定義する。 企業によって「運用」の言い回しや指し示す範囲が異なる為、本書における「運用」が指し示すスコープ を定義が必要。定義はITILから引用し、それを元にTIS独自定義に置き換える。 3 非機能要求マトリクス インフラ構築・運用を評価項目、評価観点を軸に整理し、検討における指針を定義したマトリクス。 4 担当者 インフラ構築・運用における担当者を役割とともに定義する。 14 Sample ５.定義 5-1．インフラ 本プロジェクトにおけるインフラは、純粋なオンプレミスは含めず、プライベートクラウドを含むクラウドサービス を提供する基盤におけるソフトウェア、ハードウェアなどのモノや機能を指すものとする。また、以下の部分は含め ない。 SaaS … サービス固有の要求条件が前提となり、デザインパターンの抽出が困難であるため現時点は除外。 ファシリティ … ソフトウェアによるコントロールがデフォルトの潮流である状態ではないため現時点は除外。 共通 オンプレミス クラウド（パブリック・プライベート） SaaS Service、Application Application Framework Cloud Control 監視、バックアップ、認証、課金等 PaaS IaaS Platform Application Middle Service、Application 本書でのインフラが指し示 す範囲（赤点線） Application Framework Platform Application Middle Service、Application Application Framework Platform Application Middle OS Container OS VM ハイパーバイザ 物理基盤 サーバー OS ストレージ ネットワーク サーバー ストレージ ネットワーク ファシリティ （DC、ラック、空調、電源…） 15 Sample ５.定義 5-2．運用 本プロジェクトにおける運用は、通常運用・保守運用・障害時運用を指すものとする。基本的にはアプリケーショ ンおよびインフラの構築から導入、導入後の運用までPDCAを網羅した運用体系として記載する。 アプリケーション・インフラの初期構築 性能・可用性の要件（KPI） インフラ サイジング・設計 調達 構築 SV・OS NW Storage MW HW OS ミドルウェア 導入 設定項目定義 NW Storage 初期のフルバックアップ 定期バックアップ パッチ適用 バッチ オンライン 初期データ、移行データ バックアップ設計 バックアップ実装/テスト JOB管理 運用の 記載範囲 日々の運用（通常運用） イベント毎の運用（保守運用） システム拡張 アプリの デプロイ バックアップ アプリケーション リリース 定期運用作業 （バックアップ等） ユーザー 問い合わせ 監視 ウィルスチェック 報告業務 CPU、メモリ、ディスク等のリソース プロセス、ポート等の死活 サービスデスク 問題管理 ↓ 次のアクションを検討 インシデント（障害回復要求） インシデント（サービス要求） 変更管理／ 構成管理／ リリース管理 障害対応 報告 障害対応・保守体制 イベント： 構築系 運用系 ★ヒント★ 本ページの運用定義は、TIS仕様となっている。言い回しもしくは、運用体系が異なる場合は、修正もしくは、追記が必要となる。 16 Sample ５.定義 5-3．非機能要求マトリクス 本プロジェクトにおけるインフラ・運用デザインパターンのインプット情報は、IPAが提供する非機能要求グレー ドとなる。 非機能要求グレードに対して、本プロジェクト独自に評価観点をマトリクスとして整理し、デザインパターンを追 記したものが非機能要求マトリクスとなる。詳細は非機能要求マトリクスの章で説明する。 非機能要求 グレード 評価観点 評価項目 Level１～５ 可用性 性能 評価内容 … 非機能要求 マトリクス デザインパターン１（プライベートクラウド） デザインパターン２ （パブリッククラウド） 評価項目 調達観点 コスト スキル プライベート クラウド観点 運用観点 調達観点 パブリック クラウド観点 運用観点 評価観点 可用性 … 評価内容 17 Sample ５.定義 5-4．担当者 非機能要求マトリクスの運用項目に登場する担当者、フェーズごとの役割を概要レベルで共有する。この中でイン フラにおける担当およびフェーズは青点線の箇所がスコープとなり、運用における担当およびフェーズは赤点線の 箇所がスコープとなる。 主たるフェーズ 担当者名 役割説明 システムオーナー （社内、お客様） １つのシステムにおける、主管 担当者。要件を決め、完成し たシステムを使って業務を運用 する。 構築担当 （AP、インフラ） インフラ運用設計 運用担当 オペレータ アプリケーションの開発、インフラ の構築を行う担当者。要件定 義をインプット情報とし、設計・ 調達・構築・試験・導入を行う。 主にインフラの運用設計を行う 担当者。初期の運用設計に 加え、問題管理やキャパシティ 管理等の維持対応も実施。 企画・要件定義 設計・調達 開発・試験 導入 運用 （対応頻度低い） （障害時に対応） （運用見直し発生時） 監視時に発生した障害への対 応や新たな運用対象が追加さ れた場合の導入、定期的な報 告業務等の担当者。 日々の監視や定型作業、障 害や問い合わせの一次受けを 実施する担当者。 ★ヒント★ 本ページの担当者定義はTIS仕様となっている。担当者名、役割説明、担当するフェーズが異なる場合は、各状況に合わせて記載内容を 修正する必要がある。 18 ６.デザインパターン定義 19 Sample 6-1.インフラ・運用デザインパターン定義説明 インフラ・運用デザインパターンはさまざまなシステムを想定したうえで、システムの構築や運用に必要な評価・検討項 目を列挙したマトリクスとして定義する。 評価・検討項目は非機能要求の主たる分類である、 可用性 性能 運用性 移行性 セキュリティ に加え、 コスト スキル を定義する。 マトリクスは、デザインパターンの種類を把握するための「インフラ・運用デザインパターン基本表」と左記のインフ ラ・運用デザインパターン基本表の詳細を定義する「非機能要求マトリクス」の２表で構成する。 インフラ・運用デザインパターン基本表 詳細化 非機能要求マトリクス ★ヒント★ 上記、７つ以外でシステムの構築や運用に必要な評価・検討項目がある場合は、「４.現状の課題とデザインパターン定義へのアプローチ」 にて検討した上で追加すること。 20 Sample 6-2.構築・運用全体概要 デザインパターンの対象となるシステムの初期構築・導入から運用、また次の構築への基本サイクルを示す。システム規 模やシステムの特性が異なっても根本的なサイクルは変わらない。ただしパブリッククラウド利用時には以下の青い点線 部分において構築コスト、運用コストの大きな削減を見込むことが期待できる。 アプリケーション・インフラの初期構築 性能・可用性の要件（KPI） インフラ サイジング・設計 調達 構築 SV・OS NW Storage MW HW OS ミドルウェア 導入 設定項目定義 NW Storage 初期のフルバックアップ 定期バックアップ パッチ適用 一連の作業として 実行することが多い （赤点線内） バッチ オンライン 初期データ、移行データ バックアップ設計 バックアップ実装/テスト イベント毎の運用（保守運用） システム拡張 アプリの デプロイ バックアップ JOB管理 日々の運用（通常運用） アプリケーション リリース 定期運用作業 （バックアップ等） ユーザー 問い合わせ 監視 ウィルスチェック 報告業務 CPU、メモリ、ディスク等のリソース プロセス、ポート等の死活 サービスデスク 問題管理 ↓ 次のアクションを検討 インシデント（障害回復要求） インシデント（サービス要求） 変更管理／ 構成管理／ リリース管理 障害対応 報告 障害対応・保守体制 運用方法 ・ツール ・マニュアルによる 手動作業 ・臨時マニュアル 作業 イベント： 構築系 運用系 21 Sample 6-3.インフラ・運用デザインパターン基本表 インフラ・運用デザインパターン基本表は、縦軸をコスト・スキル・可用性・性能・運用性・移行性・セキュリティの非 機能要件＋αの評価項目とし、横軸はオンライン処理／バッチ処理やトラフィック特性などのシステム特性ごとにパター ンとして列挙。また、横軸（パターン）に組織内インフラ・運用ポリシーやKPIに影響を与えうる主要項目として「Web、 想定利用者数、トラフィック、トランザクション、クリティカル制約、外部公開」を縦軸に設け、パターンの網羅性を把 握可能とする。これらのパターンを評価観点とする。 また評価項目と評価観点から導き出される内容を評価内容とし、検討しているシステムがどのデザインパターンに当ては まるかを判断する時の目安として使用する。 デザインパターン1 評価項目 コスト デザインパターン2 デザインパターンｎ 評価観点 スキル 可用性 … 評価内容 22 Sample 6-3-1.インフラ・運用デザインパターン基本表 ＜デザインパターンの評価項目定義＞ デザインパターンは以下の項目を評価し、詳細を定義する。 評価項目はそのデザインのスペックというべきものを 表す内容になる。詳細とは、レベル説明という項目名で段階評価にしたものが各評価項目ごとに定義されている。 評価内容の記載は各評価項目に定義されているレベル説明を記載する。 No 評価項目 説明 1 コスト 初期構築コスト、運用管理コスト等。 2 スキル・技術 実際の現場で不足しがちな情報。エンジニア確保の面で検討課題ともなる。 3 可用性 非機能要求グレードベース。稼働率、目標復旧水準、大規模災害対策。 4 性能 非機能要求グレードベース。リアルタイム性、拡張性、トラフィック、トランザクショ ン、データ量、DB分散。 5 運用性 非機能要求グレードベース。運用時間、監視、メンテナンス。 6 移行性 非機能要求グレードベース。移行の容易性。 7 セキュリティ 非機能要求グレードベース。外的要因、内的要因それぞれに対するセキュリティ対策。 上記は以下の情報構成を実現したものとなる。 非機能要求グレード ⇒ 可用性、性能、運用性、移行性、セキュリティ 本PJで定義した オリジナルの課題 デザインパターン定義 オリジナル課題 ⇒ コスト、スキル・技術 ★ヒント★ デザインパターン評価項目定義は、前ページで定義した「4-3 課題抽出と課題整理」にて抽出した課題を評価項目にしている。各現場に 課題に合わせて評価項目の検討が必要。追加した評価項目に合わせて評価内容、観点も追記する必要あり。 23 Sample 6-3-2.インフラ・運用デザインパターン基本表 ＜デザインパターンの評価観点定義＞ デザインパターンは以下の観点で分類し、詳細を定義する。評価項目はそのデザインの特性というべきものを表す 内容になる。 No 観点 説明 1 WEB WEBサイトであるかの有無。 2 想定利用者数 システムを利用する想定人数を3段階で表す。 大／中／小 3 トラフィック トラフィックのレベルを3段階で表す。 特／大／中／小 4 トランザクション トランザクションのレベルを3段階で表す。 5 クリティカル制約 クリティカル制約があるかの有無。オンライン／オフライン、Web／バッチ処理 6 外部公開 外部公開を行うかの有無。 トラフィックやトランザクションのレベルが非常に高く、通常のシステム構築に対して 応用が効きにくい等の特性を持つ 評価項目と性質的観点をマトリックスで表現し、デザインパターンを定義する。 別途ファイル「インフラ・運用デザインパターン基本表」を参照 ★ヒント★ デザインパターン評価項目定義は、前ページで定義した「4-3 課題抽出と課題整理」にて抽出した課題を評価項目にしている。各現場の 課題に合わせて評価項目の検討が必要。追加した場合、評価項目に合わせて評価内容、観点も追記する必要あり。 24 Sample 6-4.非機能要求マトリクス 非機能要求マトリクスは、縦軸をIPA監修の非機能要求グレード＋αの評価項目とし、横軸はインフラ向け評価項目と運用 向け評価項目、そこにコストおよびスキル要素を加えた調達観点の３点を主たる評価観点とする。基本的には１つのデザ インパターンに対する非機能要求を評価表としてまとめたものが非機能要求マトリクスとなる。※1つのデザインパター ンに対してプライベートクラウド・パブリッククラウドの2パターンの非機能要求マトリクスが存在する。 調達観点 ⇒ インフラ構築および運用におけるコストおよびスキル観点の指針 プライベートクラウド観点 ⇒ プライベートクラウドとして構築する時の観点 パブリッククラウド観点 ⇒ パブリッククラウド上に構築する時の観点 運用観点 ⇒ 「いつ、だれが、どうやって運用するか」を判断するための観点 また評価項目と評価観点から導き出される内容を評価内容とし、検討しているシステムがどのような観点で設計・構築し なければならないかを判断する時の目安として使用する。 デザインパターン１（プライベートクラウド） 評価項目 調達観点 プライベート クラウド観点 運用観点 デザインパターン２ （パブリッククラウド） 調達観点 パブリック クラウド観点 運用観点 コスト スキル 可用性 … 評価観点 評価内容 ★ヒント★ 上表の項目また、内容は、各構築現場の条件に合わせた書き換えが必要になる場合がある。 インフラ・運用デザインパターン基本表にて、評価項目を修正した場合は、非機能要求マトリクスの評価項目に反映する必要がある。 上記、3点以外にも評価観点として加える必要がある場合は追加し、各評価項目に記載をする。 25 Sample 6-4-1.非機能要求マトリクス 調達評価観点 本デザインパターンではハイブリッドクラウドは定義対象外とし、プライベートクラウドの「オンプレミス」か、パブ リッククラウドサービスを利用する「クラウド」の２環境それぞれにおいて、デザインパターンの対象となるシステムを 構築するときの評価観点を示す。 調達における評価観点は下記の３点を主軸とする。 基盤構築コスト ⇒ オンプレミス（プライベートクラウド）を選択するか、パブリッククラウドを選択するかを確認する。 システム予算との見合い 可用性の確保 拡張性の確保 運用性の確保 セキュリティの確保 ツール化コスト ⇒ 作業頻度を基とする人的コスト、作業の事故発生率・事故発生時のビジネス影響度を基とするリカバリコストを ツール化コストと比較し、適切なツール化・運用自動化を選択する。 要員調達 ⇒ 基盤構築やツール開発・ツール導入において、適切なスキルを持つ要員を確保できるかを確認する。 26 Sample 6-4-2.非機能要求マトリクス 調達評価指針 非機能要求マトリクスの調達項目の評価方法を共有する。マトリクス内部の調達項目の記載は下表を基本として記載する。 具体的な製品に直結する記載は避け、必要な検討観点に漏れが出ないように指針レベルでの記載を保つ。 時間的条件（いつ） 主たる作業項目 初期構築時 頻度 体制的条件 （だれが） 方式的条件 （どうやって） 実行 ・可用性、拡張性、運用性、セキュリティ等を考慮し、 プライベートクラウドかパブリックかを比較 インフラ：製品選定、ベンダ選定 運用：取扱いスキル確認 インフラ：製品選定、ベンダ選定 運用：取扱いスキル確認 基盤構築 初回のみ システムオーナー、構築担当 ー 冗長化、バックアップ等の具 体的な方針決定 初回のみ システムオーナー、構築担当、運用 担当者 ー 監視構築 初回のみ システムオーナー、構築担当、運用 担当者 ー インフラ：製品選定、ベンダ選定 運用：取扱いスキル確認 拡張・増設 不定期 システムオーナー、構築担当、運用 担当者 ー インフラ：製品選定、ベンダ選定 運用：取扱いスキル確認 定期バックアップ ｎ日 オペレータ ツール自動 作業頻度、作業ボリュームの大きさと ツール化コストの比較。頻度が低い場合は手動。 監視 常時 オペレータ ツール自動 作業頻度、作業ボリュームの大きさと ツール化コストの比較。頻度が低い場合は手動。 ウィルスチェック 常時 オペレータ ツール自動 作業頻度、作業ボリュームの大きさと ツール化コストの比較。頻度が低い場合は手動。 報告 ｎ日 オペレータ ー 作業頻度、作業ボリュームの大きさと ツール化コストの比較。頻度が低い場合は手動。 通常運用 保守運用 調達的条件 システム拡張 ｎカ月 （システムによる） オペレータ、運用担当者 ツール自動、マニュアル手動 パッチ適用 ｎカ月 （システムによる） オペレータ、運用担当者 ツール自動、マニュアル手動 ｎカ月 （システムによる） オペレータ、運用担当者 ツール自動、マニュアル手動 ｎ日、ｎカ月 （システムによる） オペレータ、運用担当者、 システムオーナー アプリケーションリリース QA 臨時手動 インシデント ｎ日、ｎカ月 オペレータ、運用担当者、 （システムによる） インフラ運用設計、システムオーナー 障害対応 ｎ日、ｎカ月 （システムによる） 運用担当者、構築担当、 システムオーナー ツール自動、マニュアル手動、 臨時手動 （インシデントの内容による） ツール自動、 臨時手動 報告 ｎ日 （システムによる） 運用担当者 ー 障害時運用 作業頻度、作業ボリュームの大きさとツール化コスト の比較。頻度が低ければ手動にて実施。 作業ボリュームが大きい場合、および事故発生時の 影響度が極めて大きい場合はツール化を検討。 インシデント管理・ナレッジ管理システムの導入 インシデント管理システム導入、 システム正常チェックツールコスト等の検討 システム正常チェックツールコスト等の検討 インシデント管理・問題管理システムの導入 27 Sample 6-4-3.非機能要求マトリクス インフラ評価観点 本デザインパターンではハイブリッドクラウドは定義対象外とし、プライベートクラウドの「オンプレミス」か、パブ リッククラウドサービスを利用する「クラウド」の２環境それぞれにおいて、デザインパターンの対象となるシステムを 構築するときの評価観点を示す。 インフラにおける評価観点は下記の３点を主軸とする。※インフラは、主にインフラ構築および設備拡張のことを指す。 サーバ ⇒ コンピューティングリソースを指す。 ⇒ オンプレミスの場合、ハイパーバイザ上の仮想コンピューティングリソースとハイパーバイザを稼働させる物理 リソースの２層について判断が必要。 ストレージ ⇒ ストレージリソースを指す。 ⇒ ストレージには主にDBとログのデータが保存されるが、ログは様々なフォーマットが存在するという特殊性 から統合監視が必要かどうかの観点を確認する。 ネットワーク ⇒ ネットワークリソースを指す。基本的にはサーバと同じ管理体系。 上記の３点を表にまとめると以下のようになる。 オンプレミスの場合 オンプレミスの場合 オンプレミス（プライベートクラウド） クラウド（パブリッククラウド） 仮想化基盤 物理基盤 サーバ サーバ ストレージ NW サーバ ストレージ ストレージ NW NW 28 Sample 6-4-4.非機能要求マトリクス インフラ評価指針 非機能要求マトリクスのインフラ項目の評価方法を共有する。マトリクス内部のインフラ項目の記載は下表を基本として 記載する。具体的な製品に直結する記載は避け、必要な検討観点に漏れが出ないように指針レベルでの記載を保つ。 サーバ ストレージ 可用性 冗長化 レプリケーション 性能 拡張 拡張性 運用保守 監視 ・増設の容易性 ・リソース確保 ・オートスケール バックアップ／リカバリ NW DB ログ 冗長化 レプリケーション 冗長化 レプリケーション レプリケーション 冗長化 拡張 拡張 拡張 拡張 ・増設の容易性 ・リソース確保 ・オートスケール バックアップ／リカバリ ・増設の容易性 ・リソース確保 ・オートスケール バックアップ／リカバリ ・増設の容易性 ・リソース確保 ・オートスケール バックアップ／リカバリ ・増設の容易性 ・リソース確保 バックアップ／リカバリ ・パフォーマンス監視 ・障害監視 ・予兆監視 ・パフォーマンス監視 ・障害監視 ・予兆監視 ・パフォーマンス監視 ・障害監視 ・予兆監視 ・パフォーマンス監視 ・障害監視 ・予兆監視 ・統合監視 ・パフォーマンス監視 ・障害監視 ・予兆監視 ・アンチウィルス ・FW ・暗号化 暗号化 暗号化 暗号化 ・FW ・監視 ・暗号化 移行 セキュリティ 29 Sample 6-4-5.非機能要求マトリクス 運用評価観点 運用における評価観点は下記の３点を主軸とする。 時間的条件 ⇒ 作業頻度の高い「通常運用」 ⇒ 通常運用より作業頻度は低いが確実に実施が予定される「保守運用」 ⇒ 実施が予定されない「障害時運用」 体制的条件 ⇒ 5-4で定義されている担当者 方式的条件 ⇒ ツール等による自動化された作業（マニュアル整備されている）である「ツール自動」 ⇒ マニュアル整備されており、マニュアルに従った手作業である「マニュアル手動」 ⇒ マニュアル整備されておらず、臨時的・突発的な要素の強い手作業である「臨時手動」 体制的条件（誰が） システムオーナー 時 間 的 条 件 （ い つ ） 構築担当 通常運用 △ 保守運用 頻度：中 頻度：低 運用担当 (初期導入時) 頻度：高 障害時運用 インフラ運用設計 方式的条件（どうやって） △ △ (大きな決断時に指示 (臨時的な不具合への する場合あり) 対応) オペレータ ツール自動 ● ● ● △ △ (キャパシティ管理等) (動作確認対応) ● ● (一時切り分け) △ マニュアル手動 臨時手動 ○ （現在はツールに なりつつある） △ ● ★ヒント★ 体制的条件（誰が）⇒ 「5-4 担当者」で定義した内容に変更があった場合は、「体制的条件」の記載内容を見直す必要あり。 方式的条件（どうやって） ⇒ ツール自動、マニュアル手動、臨時手動以外にないか確認。 表内の体制的条件（誰が）、方式的条件（どうやって）の内容が担当プロジェクトと異なる場合は変更すること。 ● 30 Sample 6-4-6.非機能要求マトリクス 運用評価指針 非機能要求マトリクスの運用項目の評価方法を共有する。マトリクス内部の運用項目の記載は下表を基本として記載する。 具体的な製品に直結する記載は避け、必要な検討観点に漏れが出ないように指針レベルでの記載を保つ。 時間的条件（いつ） 主たる運用項目 運用準備 通常運用 保守運用 実行 確認 保守契約（HW、SW） システム導入時、n年 システムオーナー ー ー 運用環境・体制の整備 システム導入時 運用担当者、システムオーナー、インフラ運用設計 ー ー 運用マニュアル作成 システム導入時 運用担当者、システムオーナー、インフラ運用設計 ー ー 短期的に発生する 定期作業 ｎ日 オペレータ ツール自動 ツールの正常稼働を確認。 異常があった場合は担当者へメールで連絡。 中期的に発生する 定期作業 n週 オペレータ ツール自動 ツールの正常稼働を確認。 異常があった場合は担当者へメールで連絡。 監視 常時、随時、定期 オペレータ ツール自動 ツールの正常稼働を確認。 異常があった場合は担当者へメールで連絡。 ウィルスチェック 常時 オペレータ ツール自動 ツールの正常稼働を確認。 異常があった場合は担当者へメールで連絡。 報告 ｎ日 運用担当者、システムオーナー ー ー システム拡張 ｎカ月（システムによる） オペレータ、運用担当者 ツール自動、マニュアル手動 システム正常チェックツールによる確認、もし くは目視確認。 パッチ適用 ｎカ月（システムによる） オペレータ、運用担当者 ツール自動、マニュアル手動 システム正常チェックツールによる確認、もし くは目視確認。 ｎカ月（システムによる） オペレータ、運用担当者 ツール自動、マニュアル手動 システム正常チェックツールによる確認、もし くは目視確認。 QA ｎ日、ｎカ月 オペレータ、運用担当者、システムオーナー インシデント ｎ日、ｎカ月 オペレータ、運用担当者、 インフラ運用設計、システムオーナー 障害対応 ｎ日、ｎカ月 運用担当者、構築担当、システムオーナー ツール自動、 臨時手動 システム正常チェックツールによる確認、もし くは目視確認。 報告 ｎ日 運用担当者 ー ー アプリケーションリリース 障害時運用 頻度 方式的条件（どうやって） 体制的条件 （だれが） ★ヒント★ 主たる運用項目 ⇒ 「5-2．運用」で定義内容に合わせて更新する。 体制的条件 ⇒ 「5-4 担当者」で定義内容に合わせて更新する。 臨時手動 QAのクローズ。 ツール自動、マニュアル手動、 システム正常チェックツールによる確認、もし 臨時手動 くは目視確認。インシデントのクローズ。 （インシデントの内容による） 31
© Copyright 2024 Paperzz
