はじめに
本記事はCloud Center of Excellence（以下、CCoE）について、CCoE立ち上げに関する視点から基本的な考え方について記載しています。
クラウドファーストという言葉が意味する通りに、クラウドインフラの利用はITサービスを実現するための手段として第一に考えるべき戦略の一つです。
近年、パブリッククラウドのサービスを提供するクラウド事業者は、クラウド活用に有効な手段としてCCoEという役割に着目し、その重要性を謳っています。
※本記事の内容は、あくまで考え方の一例であり、必ずしも全ての考え方がシステムに適合したり、ここに書いている内容で満たされている訳ではありません。
CCoE
CCoEは、CloudとCenter Of Excellence（以下、CoE）を組み合わせた造語です。
CoEという単語はビジネス用語として、ITに関わらず様々な業界、行政、研究所などで使用されてきました。
業界や組織によって役割は異なりますが、組織の中間拠点や、横断組織等ハブ的機関を意味します。
すなわち、組織の中核となる専門分野の集団として位置づけられていることが多く、IT業界ではCloudの推進組織としてCCoEという言葉が使われています。
CCoEの導入目的
CCoEは役割ではなく、DevOpsの様に文化に近い概念だと考えています。
何故ならば、導入する組織やポジションによって視座が異なるため、CCoEに求められる役割や考え方は変わってくるからです。
CCoEを組織に導入して正しく機能させるためには、以下に示す様な組織的な課題に対して、CCoEの導入目的を正しく設定することが重要だと考えています。
- クラウド戦略
- ガバナンス
また、導入したら終わりではなく、運用開始後SLAやコストなど定量的に分析できる指標をKPIとし、継続的にビジネスを支えていくことが重要だと思います。
クラウド戦略
ビジネスの基本的原則である戦略は元々、軍事用語からきています。
「戦略なくして戦術なし」と言われる様に、戦略ありきでクラウドを目的ではなく、目的を達成するための手段として考えます。
Why? Do you use AWS?
ITサービスをローンチするために、クラウドインフラとしてAWSを利用する組織は多いと思います。
「何故、AWSを利用するのか？」
ビジネス要件を理解した上で、コストや機能等何らかの軸を持って、クラウドの選定理由を持つことが重要です。
また、ビジネスに影響を与える意思決定については、必ず経営層と合意を取ることも必要不可欠です。
パブリッククラウド・プライベートクラウド
ビジネスでコストを重要視するのであれば、プライベートクラウドの構築も一つの戦略です。
OpenStackを利用することで独自のプライベートクラウド環境を構築することができます。
しかし、将来的なコスト削減の効果は大きいと思いますが、構築するための導入コストや、運用コストが大きいため、現実的に導入するのは総合的に難易度が高いのが現状です。
理由として、何らかの問題が発生してもオープンソースソフトウェア（OSS）のため、パブリッククラウドと比較すると、サポートなどの保証は充実しておりません。また、AWSなどと比べると採用面に対するハードルへの影響も大きいと思われるため、小規模で流動的な組織の場合、導入は難しいと思われます。
責任共有モデル
クラウドを利用するために責任共有モデルの理解は必要です。
また、SIerなどITベンダーの場合、顧客にも説明を行い、理解させることが望ましいです。
責任共有モデルはシステムに対する自由度や、コストなどトレードオフの性質を持っています。
例としてAWSでDBサーバを構築する際に、EC2を選択する場合はRDSと比べて、自由度が高く料金は安くなりますが、運用コストは高くなります。
端的に言うとレイヤーに対する責任分解、セキリュティの観点からデータ保護など遵守すべき法令やガイドライン等、検討しないといけないことはたくさんあります。
AWSの場合は以下資料が参考になります。
特に、セキュリティという観点ではクラウドを提供する側と、利用者側での相互理解が重要です。
責任共有モデルの概念を正しく理解してシステムを作り込むことで、野球で言うポテンヒットを防ぎ、システムを健全な状態に近づけることができるでしょう。
ガバナンス
ガバナンスはビジネス用語として、企業統治の意味合いで使用されていることが多く、主にガバナンス強化というフレーズで使用されることが多いと思います。
ビジネス上のガバナンス強化に伴い、ITサービスの開発・運用プロセスへの影響度は大きいため、ただルールを作ったら終わりではなく、効果的に機能させるための仕組み作りが重要です。
ガイドライン
パブリッククラウドを利用して、SaaS型ビジネスモデルを構築し、ITサービスを展開する事業者は今後も増えていくと思いますが、クラウドの利用にはまだまだ課題があります。
従来、オンプレミスのシステムにおいてインフラを構築する際のフレームワークは非機能要求グレードが利用されてきました。
「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。
クラウドファーストの今、パブリッククラウドを利用してITサービスを構築する際に、非機能要求グレードの様な認知度があり汎用的なツールが存在しないため、サービスや組織の成長に伴い、ガバナンス強化のフェーズでクラウドの運用課題が顕在化する組織が多いのではないかと思います。
従って、ITサービス構築時にクラウドインフラの設計技法に関するフレームワークを利用することで、運用フェーズでのコストを下げることができると考えています。
例えば、情報セキュリティ対策の指針としては以下に示す、総務省が公開しているガイドラインの活用が効果的ではないかと思います。
この総務省の公開している資料は、JIS Q 27000などを基に、ガイドラインを策定しているため、日本の国家規格に準拠していることになります。
従って、この様なガイドラインに準拠することで国が求める基準を満たし、システムの品質や安全性を表現することができます。
なお、AWSの場合、AWS Well-Architectedを利用することでAWSにおけるアーキテクチャのベストプラクティスを使ったインフラの構築ができます。
AWS Well-Architected フレームワークは、以下5本の柱を基本としています。
- 運⽤性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
詳細についてはAWS Well-Architected フレームワークのドキュメントを参照。
また、現在はホワイトペーパーとして公開されていたものがAWS Well-Architected Toolにサービス化されているので、ベストプラクティスについて導入しやすい仕組みになっています。
利用方法についてはAWSコンソール画面からワークロードを作成し、レビューを行う項目にチェックを入れてレビューを行う作りになっています。レビュー完了後、ワークロードに対するリスクが表示されます。
内部統制
内部統制はITサービスの開発・運用プロセスに対して大きく影響します。
例えば運用ルールを策定していない場合、何らかの開発で構築したサーバリソースなどが残り続けて、全く使用していないのに毎月課金され続けるというのはよくある話です。
クラウドリソースを利用するための運用ルールを策定することで、無駄な支出を防ぐことができます。
スタートアップなど人の流動性が高い組織で多いと思いますが、後から使用していないリソースを削除するにしても、消して大丈夫かなどの確認作業が発生し、時間が経過すればするほど対応に手間がかかります。
また、クラウドリソースなどを変更した場合、作業や変更に関わる履歴を残すことで運用を円滑にします。
具体的には以下の様な誰が、何のために、何を、どうやって変更したか等の情報があると良いと思います。
- Who?
- Why?
- What?
- How？
AWSの場合、以下のサービスがあります。
AWS CloudTrailを利用することで、ユーザーのアクティビティをAPIレベルでトラッキングして証跡管理を行うことができます。また、AWS Configでは設定変更の履歴を管理できます。
そして、Amazon GuardDutyや、AWS Security Hubを組み合わせて、システム上に存在する脆弱性に対する脅威を検出し、リスクを低減することができます。
おわりに
トイレットペーパーのサイズは日本のJIS規格によって標準化されていて、114mmと決められています。そのため、どこのメーカーの商品を買っても備え付けのホルダーに取りつけることができます。
システム的に言うと、例えばLinuxの場合、Filesystem Hierarchy Standardと言う概念があります。
クラウドインフラの場合、CCoEを軸にして普遍的かつ、不変的にシステムを作り込むことがこれから求められるスキルではないかと思いました。