こんにちは。
今回は、CAF (Cloud Adaption Framework) についてです。
日本語に直訳すると、クラウド導入フレームワークなので、雑な言い方をするとクラウドを導入するときに検討するプロセスについての知識集って感じで捉えるといいと思います。
ちなみに、CAF のターゲットとなる人は、IT に関わる人だけではありません。
例えば、ビジネスの意思決定者だったり、そこに近い人。あとは、新規サービスを起案していく人とかにも関係しています。
なので、IT じゃない人もこの記事をみて、「なるほどわかった！」になると嬉しいけど、ドキュメントをそのまま引用してる部分が多いので、なかなか分かりづらいかもw
本論に入る前に
MS 赤間さんが、CAF について超わかりやすいドキュメントを作ってて、2022 年の年末に FaceBook でリリースしてくれてるんですよね。
このドキュメントを見て、自分の理解が誤っている部分もあったのもあったので、もう一度自分の理解を整理するために、今回の記事を書いてみました。
ぜひ、元となった赤間さんの資料もご覧ください。
CAF とは
CAF
ってことで、まずは CAF とはから。
冒頭にも書いた通り、CAF とは、クラウドを導入するときに検討するプロセスについての知識集です。
僕のイメージでは、PMBOK（Project Management Body of Knowledge) のクラウド導入版に近い感覚です。ただ、PMBOK については、僕は第 6 版までしか知らないから、第 7 版とはちょっと違うのかも。。。
CAF は 3 つのプロセス群に別れます。
- クラウドジャーニーを計画/実行するプロセス郡
- Azure を使う場合の運用管理や統制を行うプロセス群
- 組織・人材論
CAF 以外にもある、フレームワーク
CAF 以外にも、知っておくといいフレームワークは、以下があります。
- Azure アーキテクチャ センター – Azure Architecture Center | Microsoft Learn
アーキテクチャーカットで、Microsoft Azure を導入する際のサンプルとなるアーキテクチャのナレッジ集。
多分、ここで参考となるアーキを見ておけば、大体の場合はどうにかなると思います。 - Microsoft Azure Well-Architected Framework – Azure Architecture Center | Microsoft Learn
5 つの柱(信頼性、運用最適化、コスト、セキュリティ、パフォーマンス)の視点で、レビューカットで品質向上を目指す際に使うフレームワーク。
Microsoft Azure だけに留まらず、システム構築の際のチェックポイントの参考となるフレームワーク。
WAF については、すごく雑にまとめた記事を前にも書いたなw
クラウドジャーニーを計画/実行するプロセス郡
このプロセスは、クラウドを導入していくときの企画〜実際に導入するまでのプロセスです。
で、本質的には、クラウドを導入しようとしてクラウドを導入することってないはずですよね。
クラウドを導入するのは、ビジネスで何かを実現するための手段ですから、手段が目的になることは絶対にないはず。
ビジネス的に何かを達成するために、クラウドを導入していくわけですがいきなりクラウドで作ることもできるものもあれば、時間をかけてクラウドに徐々にマイグレーションしていく必要も出てくるわけです。
時間がかかるってなってくると、コスト的な問題で時期がずれたり、他との兼ね合いでタイミングずれたりすることもあると思います。
なので、計画(クラウドジャーニー)が必要になってくるわけです。
で、クラウドジャーニーを考える際には、最初から全部を計画仕切らないでもいいと思います。
と言うのは、ここで時間を費やしすぎると、後続の作業をやる時間がなくなるからです。
なので、達成すべき目的とその成果をちゃんと測定することを計画し、測定結果を評価して、クラウドジャーニーを改善することを計画する PDCA をちゃんと回せばいいと思います。
1.戦略(Strategy)
まずは、ビジネス上の成果をもとに、何を達成すべきかを定義する必要があります。
定義、明文化すべきことは、主に以下の4つ
- クラウドを導入する動機
例えば、データセンターを廃止してトータルコストの削減を行うとか
- クラウドを導入したことによるビジネス上の予測される成果
例えば、データセンターを廃止することでファシリティーに関わる費用や、運用コスト(人件費を含む)の削減と、クラウドを移行を行なってどれくらいの年数でクラウド導入に関わる費用を回収して、その後どれくらいのコスト効果を見込むかとか。
多分、このシナリオの場合、新規システムはいきなり Azure 上で構築されるので、新規サービスの市場投入のスピードアップや、スケーラビリティを持った弾力性のあるシステム構築が今後の成果として見込める可能性があります。
これらの成果を特定するためには、様々な関係者と対話をすることが大切ってドキュメント上で記載されてます。
- 財務上の考慮事項
オンプレミスからクラウドに変更した場合、財務的にもCAPEX(投資費用[固定費])からOPEX(運用費用[変動費])と変更になります。
また、オンプレではあったデータセンターなどの減価償却も、クラウドを利用することで無くなります。
また、広い視点で見れば、二酸化炭素の排出量削減などの効果も見込めます。 - 技術的な考慮事項
オンプレミスでは実現できない、クラウドならではの技術的なメリットがあります。
例えば、こんな項目がドキュメントでは記載されています。- スケーラビリティ
- 可用性
- セキュリティとコンプライアンス
- 容量の最適化
- 持続可能な IT インフラストラクチャ
ちなみに、戦略のアンチパターンもドキュメントに載ってます。
2.計画(Plan)
戦略をベースに、より具体的でかつ実現可能な計画を策定します。
- デジタル資産
デジタル資産とは、ざっくり言っちゃうと、サーバ、アプリ、データなどの IT 資産のことを指します。
これらを棚卸しし、それぞれのワークロードを分析しでどのように合理化(Rationalization)していくかドラフトアーキテクチャを決定していったり、優先順位を決定します。
ちなみに、Rationalization が合理化って訳されているんですが、方針決定とかそういう意味なんだと思います。
The five Rs of rationalization(合理化の 5R ) では、以下が挙げられています。- リホスト(Rehost)
アーキテクチャ全体への変更を最小限に抑えて、現在の状態の資産を選択されたクラウド プロバイダーに移動すること。いわゆる、Shift-and -Lift ですね。
- リファクター(Refactor)
PaaS ベースのモデルに適合するように、アプリケーションを少しリファクタリングすること
- 再設計(Rearchitect)
クラウド ネイティブではないアプリケーションをクラウドネイティブ化するようにソリューションを再設計することです。
- 再構築(Rebuild)
そもそもアプリケーションが古くなっていて、今のビジネスニーズに対応できないようなケースの場合、クラウドに持っていくこのタイミングで新しく作り直しちゃいましょうという場合のことです。
- リプレイス(Replace)
SaaS サービスを組み合わせて置き換えちゃいましょうという場合のことです。
- リホスト(Rehost)
- 初期の組織配置
クラウド導入に際しては、「クラウド導入」の役割の人と「クラウドガバナンス」を担う役割の両方が必要です。
この段階では、最終的な組織ではなく、最初の一歩で上記 2 つの役割の責任者を決めるってくらいでいいんだと思います。
よくありがちなのが、「クラウド導入」の役割は必ず着くと思うのですが、「クラウドガバナンス」の役割が疎かになりがちです。
クラウド ガバナンス チームは、「クラウド導入がビジネスを新たなリスクにさらさないようにするために、必要な検査と均衡を提供します。 リスクが不可欠な場合、このチームはこれらのリスクを軽減または管理するための適切なプロセスとコントロールが実施されるようにします。」の役割なので、セキュリティとか運用とかその辺もあると思いますし、社内ルールとの調整とかもはいってくるイメージで捉えています。
また、この組織が成熟していくと、「組織・人材論」の Input になる感じです。
- スキル準備の計画
クラウド導入は、新しいスキルの獲得が必要だから、しっかり計画しましょう！
ってことが、書かれてると思っていたけど、それだけじゃなかったw
例えば、クラウド導入すると、データセンターの社員はクラウドアーキテクトとかにジョブチェンジが発生します。これは、その写真にとってはとても不安なものだと思います
逆に、現職にはないロールやプロセスも必要になります。
そういうことを考慮した、スキルの獲得計画を立てましょうということでした。
ちなみに、導入フェーズの必要スキルについてドキュメントには記載されてます。
- クラウド導入計画
これまでやったことを元に、クラウド導入計画を立てます。
手順は以下になります。- 前提条件: 計画を作成する前に、前提条件の手順がすべて完了していることを確認
- 戦略的入力
- 明確な動機: クラウドを導入する理由
- 定義されたビジネス成果: クラウドの導入によって見られることが期待される結果
- 業務上の正当な理由: ビジネスの成功を測定する方法
- 戦術的入力
- デジタル資産の合理化: 導入計画における上位 10 個の優先度のワークロードは何ですか。 計画には追加のワークロードがいくつ含まれる可能性がありますか。 クラウド導入の候補と見なされる資産の数はいくつですか。 初期の作業では、移行またはイノベーションのアクティビティにより大きな重点を置きますか。
- 組織の調整: 導入計画の技術的な作業はだれが実行しますか。 ガバナンスとコンプライアンスの要件の遵守に対する責任者はだれですか。
- スキルの対応性: 必要なタスクを実行するために何人が割り当てられていますか。 その人たちのスキルはクラウド導入作業にどの程度合致していますか。 技術的な実装をサポートするためにパートナーと提携していますか。
- 戦略的入力
- ワークロードを定義し、優先順位を付ける: 最初の導入バックログを設定するために、最初の 10 個のワークロードに優先順位を付けます
- ワークロードに合わせて資産を調整する: 優先順位付けされたワークロードに対応するために必要な資産 (提案されたものか既存のもの) を特定します。
- 合理化決定を見直す: 合理化決定を見直し、移行またはイノベーションの導入パスの決定を微調整します。
- イテレーション計画とリリース計画の確立: “イテレーション” は、作業を実行するために割り当てられた時間ブロックです。 “リリース” は、生産プロセスへの変更をトリガーする前に行うべき作業の定義です。
- タイムラインを見積もる: 最初の見積もりに基づいて、リリース計画のための大まかなタイムラインを設定します。
- 前提条件: 計画を作成する前に、前提条件の手順がすべて完了していることを確認
ちなみに、計画のアンチパターンもドキュメントに載ってます
また、「戦略的な移行評価と準備ツール (SMART)」もありますので、ここでチェックしてみるのも大事だと思います。
3.クラウド導入準備(Ready)
クラウドの導入の前段階として、そのワークロードをホストするためのランディングゾーンを計画します。
- Azure セットアップガイド
- リソースの整理: 管理階層を設定し、アクセス制御、ポリシー、およびコンプライアンスを一貫性のある方法でリソース グループに適用し、タグ付けにより関連するリソースを追跡します。
- Management Group
- リソースタグ
- アクセスの管理: ロールベースのアクセス制御を使用して、ユーザーに必要なアクセス許可だけが付与されるようにします。
- RBAC
- コストと課金の管理: サブスクリプションの種類を確認し、課金のしくみを理解し、コストを管理する方法について学びます。
- Cost Management
- ガバナンス、セキュリティ、およびコンプライアンスの計画: 適用される法的要件に準拠できるように、ポリシーとセキュリティの設定を適用および自動化します。
- Azure Blueprint
- Azure Policy
- Microsoft Defender for Cloud
- 監視とレポートの使用: リソース全体を可視化することで、問題を見つけて修正し、パフォーマンスを最適化し、顧客の行動に関する分析情報を取得します。
- Azure Policy
- Azure Service Health
- Azure Advisor
- Microsoft Defender for Cloud
- Microsoft Sentinel
- Azure を最新の状態に保つ: 製品の最新情報を把握して、プロアクティブなアプローチで変更管理を行えるようにします。
- リソースの整理: 管理階層を設定し、アクセス制御、ポリシー、およびコンプライアンスを一貫性のある方法でリソース グループに適用し、タグ付けにより関連するリソースを追跡します。
- クラウド運用モデル
- 一般的なモデルとして、以下の4つがある。
- Azure ランディング ゾーン
ランディングゾーンはざっくりいうと、Azure に色んなワークロードを載せる際に必ず発生する、ID、Network、ガバナンス、セキュリティなどの共通的な基盤のことです。
ドキュメントには、ランディングゾーンの種類についても書いてあったけど、それはちょっと上手く言語化できなかったです。
多分、インフラ手動で1つのNWの中に全部まぜるタイプとか、アプリケーション主導なんだけどアプリ側に委任しちゃって、ランディングゾーンを作る部分だけをインフラ側でやるとか、ランディングゾーンの運用と構築でタイプがわかれるよねってことだと思うんですけど、どんな種類があるかって考えるよりは、組織に合わせて考える方がいいんだろうなって思いました。
設計原則ってのがあるので、キーワードだけまとめておこっと
- サブスクリプションの民主化
- ポリシー主導ガバナンス
- 単一のコントロールおよび管理プレーン
- アプリケーション中心のサービスモデル
- Azure ネイティブの設計とロードマップに合わせる
- ターゲット アーキテクチャへのユーザー体験
クラウドを導入するのは、ビジネスの優先順位に合わせながらビジネスを阻害せずにやっていくわけで、すぐにクラウド化というのはできないので、長期的な視点でやっていく必要があるわけで、以下のマイルストーン(オンランプ)を立てて進めましょう。
- Start
ベスト プラクティスと実証済みのアーキテクチャ パターンに基づいて新しいクラウド環境を実装しようとしている、クラウド導入ユーザー体験の開始段階 (“グリーンフィールド” とも呼ばれる) にいる組織向けです。
Azure ランディング ゾーンの概念アーキテクチャから開始して、推奨される終了状態を理解します。
次に、各設計領域について確認します。 これらの領域を使用して、要件に最適なランディング ゾーンを設計および実装するために必要な考慮事項と意思決定を形成する、主なテーマを理解します。
- Align
既存の環境があるが、Azure ランディング ゾーンのターゲット アーキテクチャとベスト プラクティスに合わせるために変更を必要としている組織向けです (“ブラウンフィールド” とも呼ばれる)。
Ready 手法のガイダンスに合わせるための環境のリファクタリングに対する意思決定ポイントと技術的アプローチを理解するためには、ブラウンフィールドからの移行ガイダンスを使用します
- Enhance(強化)
既にベスト プラクティスに沿っているが、コントロールまたは機能の追加が組織で検討されている環境向けです。
管理、ガバナンス、セキュリティなど、クラウド環境のための主要な進行中のプロセスを強化する一環として考慮事項を説明する記事を探索してください。
- Start
- Azure ランディング ゾーンの設計領域
各 Azure ランディング ゾーンの実装オプションからは、デプロイ アプローチと定義された設計原則が提供されます。- 環境の設計領域
- Azure の課金と Active Directory テナント
テナントの適切な作成、登録、および課金の設定は、初期の重要な手順です。
この項目は、 Azure のサブスクリプションの構成およびその管理についての設計を行う感じです。
- ID 管理とアクセス管理
ID およびアクセス管理は、パブリック クラウドの主要なセキュリティ境界です。 セキュリティで保護され、完全に準拠したアーキテクチャの基盤になるものです。
この項目は、AAD を使った Azure 全体のリソースへのアクセス権を中心とした ID 管理について設計を行う感じです。
オンプレ AD と統合するケースもあると思いますし、緊急アクセス用管理者アカウントなども用意するのもありますし、多要素認証などの認証の話もありますし、マネージド ID のようにリソースへのアクセス制限など、割と重要だけど領域が広い箇所の設計ですね。
- ネットワーク トポロジと接続
ネットワークと接続性の決定は、どのようなクラウド アーキテクチャでも同様に重要な基本的な側面です。
ここは文字通りネットワークの設計です。
ただ、これまでのオンプレミスでやっていたネットワークの設計とはだいぶ異なります。
多分、一番大きな違いは、Azure の仮想ネットワークを使った場合、この仮想ネットワークって自社のネットワークじゃなくて、別のネットワークにプライベートに接続してるってことなんだと思います。
この辺は、今年 1 年間、様々なお客様と悩んできたのですが、オンプレミスの NW の拡張で、オンプレミスの NW(セキュリティ) ルールに従って、オンプレミスと同じようにするのは、ちょっと難しいって感じましたね。
- リソースの編成
クラウド導入の規模が拡大するにつれて、サブスクリプションの設計と管理グループの階層に関する考慮事項は、ガバナンス、運用管理、導入パターンに影響を与えます。
この項目は、「Azure の課金と Active Directory テナント」と近い関係ですが、複数のサブスクリプションを横断的に管理する手法について設計する感じです。
また、リソースの命名ルールやタグ付けルールとかもこの項目で設計する感じです。
- Azure の課金と Active Directory テナント
- コンプライアンスの設計領域
- Security
クラウド環境を保護するためのコントロールとプロセスを実装します。
この項目では、環境全体のセキュリティ基盤を設計することが目的となります。
ここにまとめきれないので、ドキュメントを読んで頂くのが良さそうです。
- 管理
クラウドで安定して継続的な運用を行うには、可視性、運用コンプライアンス、保護および復旧機能を提供する管理ベースラインが必要です。
キーワードだけ拾って書いとこっと
- 運用ベースライン
- インベントリと可読性
- アプリケーション中心のプラットフォーム監視
- セキュリティ監査ログ
- Azure データ保持のしきい値とアーカイブ要件
- 運用のコンプライアンス
運用をしていくと、想定外の設定とかをする人とかが出てきちゃってそれで思いがけないことが起きるって割とよくあるじゃないですか。
それを、Azure Policy などを使って逸脱した設定ができないようにしていきましょう的な検討です。
個人的には、セキュリティホールとならないように色々制限するって部分は、本当はセキュリティルールでフォローしてあげて、ここでは間違ってメチャンコ大きい VM とかを作った時に、本当に大丈夫？って言ってあげるような優しさを持って設計をしてほしいなぁ〜w
- 保護と回復
保護と回復はまぁー障害復旧なので、これについてはリンクのドキュメントで考慮点が色々書いてあるんですが、一番のポイントは、RTO(Recovery Time Objective) と RPO(Recovery Point Objective) をまず決めること。
これがないと話が前に進まないので、ひとまずでいいからまずは決めることが大切。
運用してれば見直し入る箇所ではあるので。だって、SLA 100% をみんな求めるけど、そんなこと目指すとめちゃめちゃお金かかるけど、そこまでやってペイすることってできますか？
- インベントリと可読性
- 高度な運用
- プラットフォーム管理
ワークロードが、SAP、WVD、AVS、SQL などの共有プラットフォームに依存していることはよくあることで、これを 複数のワークロードで使われている場合は、個別検討するのは効率的ではないので統合的に運用設計をしましょうって話ですね。
- ワークロードの管理
ドキュメントを読むと、ワークロードの監視と管理の運用のことっぽい感じですね。
あと、1つのワークロードで発見したことを、周知することで他のワークロードの改善にもつながるってことも書いてる気がします。
- プラットフォーム管理
- 運用ベースライン
- ガバナンス
ガバナンス ポリシーの監査と適用を自動化します。
設計領域のキーワードだけ拾っておこっと
- コスト管理
- セキュリティベースライン
- リソースの整合性
- ID ベースライン
- デプロイ高速化
- プラットフォームの自動化と DevOps
最適なツールとテンプレートを配置し、ランディング ゾーンとサポート リソースをデプロイします。
- Security
- 環境の設計領域
4.クラウド導入(Adapt)
ここまでに設計したことをもとに、実際に導入をしていきます。主なアプローチとしては、以下の3つがあります。
それぞれドキュメントにまとまってるので、そちらをご覧ください。
Azure を使う場合の運用管理や統制を行うプロセス群
統制、管理、セキュリティの 3 つの視点で、運用管理や統制を行うガイドラインを制定するプロセスです。
ドキュメント上にも書いてあるのですが、1 度決めて終わりというよりは、運用をしながら改善をし続けるプロセスとなります。
1.統制(Governance)
統制のプロセスでは、5つのガイドラインを整備します。
また、CAF では、以下の手順で最初のガバナンスの基盤を構築すると書かれています。
- 方法論を確立する: クラウド導入フレームワークでクラウド ガバナンスを推進する手法の基本的な理解を確立し、最終状態のソリューションについて熟考を開始します。
- ガバナンス ベンチマーク ツールを使用する: 現在の状態と将来の状態を評価し、フレームワークを適用するためのビジョンを確立します。
- 最初のガバナンス基盤を確立する: 小規模で簡単に実装できるガバナンス ツールのセットを使って、ガバナンス体験を始めます。 この最初のガバナンス基盤は、実用最小限の製品 (MVP) と呼ばれます。
- 最初のガバナンス基盤を改善する: クラウド導入プランの実装全体で、最終状態へと進みながら、ガバナンス コントロールを繰り返し追加して具体的なリスクに対処します。
2.管理(Manage)
管理のプロセスでは、緊急度と影響度をもとに、サービスSLA を定義してそれに沿って運用を回していくことを考えるものとなります。
また、これらの運用を考える上で、3 つの基本原則と 3 つの拡張ベースラインをに分けてまずは基本原則をやって、そこから拡張していくというようなアプローチが定義されてます。
また、アンチパターンにも記載されているのですが、「ビジネス上の成果ではなく、ツールに焦点を当てる」やり方の場合は、結局目指すべきレベルが決まってこないので、あまりうまく機能しないことが多い項目になってきます。
基本原則
インベントリと可視性
運用について適切に判断するためには、運用状態のデータを取得することと、そのデータを可視化することが大切です。
まずは、データを取って分析できるようにするという部分で、以下のサービスを利用します。
| Process | ツール | 目的 |
|---|---|---|
| Azure サービスの正常性の監視 | Azure Service Health | Azure で実行されているサービスの正常性、パフォーマンス、診断 |
| ログの一元化 | Log Analytics | すべての可視性のための一元的なログ |
| 監視の一元化 | Azure Monitor | 運用データと傾向の一元的な監視 |
| 仮想マシンのインベントリと変更の追跡 | Azure Automation の変更履歴とインベントリ | ゲスト OS レベルの VM のインベントリと変更の監視 |
| サブスクリプションの監視 | Azure activity log | サブスクリプション レベルの変更の監視 |
| ゲスト OS の監視 | Azure Monitor for VMs | VM の変更とパフォーマンスの監視 |
| ネットワーク監視 | Azure Network Watcher | ネットワークの変更とパフォーマンスの監視 |
| DNS の監視 | DNS Analytics | DNS のセキュリティ、パフォーマンス、操作 |
運用のコンプライアンス
運用のコンプライアンスでは、運用が中断することを極力減らすことが目的となる運用について整備します。
| Process | ツール | 目的 |
|---|---|---|
| 更新プログラムの管理 | Azure Automation の Update Management | 更新プログラムの管理とスケジューリング |
| ポリシーの適用 | Azure Policy | 環境とゲストのコンプライアンスを確保するためのポリシーの適用 |
| 環境の構成 | Azure Blueprint | コア サービスの自動化されたコンプライアンス |
| リソース構成 | 必要な状態の構成 | ゲスト OS と環境のいくつかの側面の自動構成 |
保護と復旧
保護と復旧では、運用上防ぐことができない中断が発生した際に、早期に復旧しビジネスへの影響を軽減させる目的とした運用について整備します。
| Process | ツール | 目的 |
|---|---|---|
| データの保護 | Azure Backup | クラウド内のデータと仮想マシンをバックアップします。 |
| 環境を保護する | Microsoft Defender for Cloud | ハイブリッド ワークロード全体でセキュリティを強化し、高度な脅威保護を提供します。 |
拡張ベースライン
基本原則を拡張して整備していく項目は、以下のようなものがあります。
| 規範 | Process | ツール | 潜在的な影響 | 詳細情報 |
|---|---|---|---|---|
| インベントリと可視性 | サービスの変更の追跡 | Azure Resource Graph | Azure のサービスに対する変更が視認しやすくなると、負の影響をより迅速に検出したり、より迅速に修復できる場合がある。 | Azure Resource Graph の概要 |
| インベントリと可視性 | データの視覚化 | Azure Sentinel | データの即時視覚化と分析 | Sentinel で収集されたデータを視覚化する |
| インベントリと可視性 | IT サービス マネジメント (ITSM) の統合 | IT Service Management Connector | ITSM に自動接続されることにより、認識が早くなる。 | IT Service Management Connector (ITSMC) |
| 運用のコンプライアンス | 操作の自動化 | Azure Automation | 変更により迅速および正確に対応するために運用のコンプライアンスを自動化する。 | Azure の管理ベースラインの改善 – Cloud Adoption Framework | Microsoft Learn |
| 運用のコンプライアンス | ゼロ トラスト | Azure Sentinel | ゼロ トラスト ブックでは、Microsoft が提供するセキュリティ機能がフル活用されています | Sentinel ゼロ トラスト ブック |
| 運用のコンプライアンス | パフォーマンスの自動化 | Azure Automation | リソース固有のスケーリングやサイズ変更に関する一般的な問題を解決するために、パフォーマンスの予測によって運用のコンプライアンスを自動化します。 | Azure の管理ベースラインの改善 – Cloud Adoption Framework | Microsoft Learn |
| 運用のコンプライアンス | マルチクラウド操作 | Azure Automation の Hybrid Runbook Worker | 複数のクラウド間での操作を自動化する。 | Hybrid Runbook Worker の概要 |
| 運用のコンプライアンス | ゲストの自動化 | Desired State Configuration (DSC) | エラーと構成のずれを減らすためのゲスト オペレーティング システムのコードベースの構成。 | DSC の概要 |
| 保護と復旧 | 侵害通知 | Microsoft Defender for Cloud | セキュリティ違反復旧トリガーを含むよう保護を改善。 | Azure の管理ベースラインの改善 – Cloud Adoption Framework | Microsoft Learn |
| 保護と復旧 | 脅威ハンティング | Azure Sentinel | 悪意のあるアクティビティを検出して保護するのに役立つハンティング クエリが組み込まれています | Sentinel の脅威ハンティング |
プラットフォームの特殊化
数あるプラットフォームやワークロードの中でも、ビジネス的なインパクトや影響度が高い環境に向けて、基本原則を拡張するようなケースの時です。
ドキュメントでも影響度が高い 20% 程度に向けてってことで、全部に対して同じようにやるのはなかなか厳しいものになると思います。
| Process | ツール | 目的 | 推奨される管理レベル |
|---|---|---|---|
| システム設計を改善する | Microsoft Azure Well-Architected Framework | プラットフォームのアーキテクチャ設計の改善による操作の向上 | 該当なし |
| 自動修復 | Azure Automation | プラットフォーム固有の自動化による高度なプラットフォーム データへの対応 | プラットフォームの運用 |
| サービス カタログ | マネージド アプリケーション センター | 組織の標準を満たす承認済みソリューションのセルフサービス カタログの提供 | プラットフォームの運用 |
| コンテナーのパフォーマンス | コンテナーに対する Azure Monitor | コンテナーの監視と診断 | プラットフォームの運用 |
| サービスとしてのプラットフォーム (PaaS) データ パフォーマンス | Azure の SQL 分析 | PaaS データベースの監視と診断 | プラットフォームの運用 |
| サービスとしてのインフラストラクチャ (IaaS) データ パフォーマンス | SQL Server の正常性チェック | IaaS データベースの監視と診断 | プラットフォームの運用 |
ワークロードの特殊化
ワークロードの特殊化は、反復的なアプローチで次の 4 つのプロセスの規範的な実行で構成されます。
- システム設計を改善する: 中断を効果的に最小限に抑えるために、特定のワークロードの設計を改善します。
- 修復を自動化する: 一部の改善は費用効果が高くありません。 このような場合、修復を自動化し、中断の影響を抑える方が合理的です。
- ソリューションをスケーリングする: システム設計と自動修復を改善したら、サービス カタログを使用してそれらの変更を環境全体にスケーリングできます。
- 継続的な改善: さまざまな監視ツールを使用して、段階的な改善点を見つけることができます。 これらの改善点は、システム設計、自動化、スケーリングの次のパスで対処できます。
またドキュメントでも、「文化の変化」という項目があり、クラウドを使ってアプリをクラウドネイティブ化していくというのは、少なくないことなのですが、それに伴って上記の改善が入っていくというようなのがイメージしやすいかもしれません。
また、このケースの場合に Application Insights を使ったケースも増えてくると思います。
| 要件 | ツール | 目的 |
|---|---|---|
| アプリケーションの監視 | Application Insights | アプリケーションの監視と診断 |
| パフォーマンス、可用性、使用状況 | Application Insights | アプリケーション ダッシュボード、複合マップ、使用状況、トレースを使用した高度なアプリケーション監視 |
3.セキュリティ(Secure)
セキュリティの項目では、以下 3 つに分けて整備を行います。これらができるようになると、DevSecOps の世界が近づくんじゃないっすかね〜。
- リスクの分析
セキュリティ担当者が、ビジネスを理解してその専門性を発揮し、プロセスとデジタル資産に対するセキュリティリスクを洗い出し、意思決定者に通知をするプロセス。
- セキュリティの統合
セキュリティ作業を日常の運用作業に組み込んで運用するプロセスです。
- ビジネスの回復力
インシデントが発生しても、ビジネスを継続的に運用ができるようにする仕組みづくりのプロセスです。
また、この項目では、以下の 5 つの領域で整備をします。
- アクセス制御
デジタル資産へのアクセス制御なので、Azure でいうと 認証であったり、RBAC であったりと AAD 周りの機能にマッピングされるようなイメージでいいんじゃないかなー。
ネットワーク分離型かゼロトラスト型かみたいな話題も出てくる領域ですが、この言葉にはあんまりとらわれなくてもいいんじゃないかなーって思いつつ、RBAC はやった方がいいと思うんすよねー。
- セキュリティ運用
セキュリティ運用のベスト プラクティスも合わせて確認した方がいいかも。
- 資産の保護
Get Security : セキュリティ標準を適用していく運用
Set Security ： 継続的に運用が維持されていることを確認するための運用
- セキュリティ ガバナンス
セキュリティ運用を行なっていくための、組織や役割、優先度などを取り決めるルールみたいなイメージかな。なので、Azure でどうこうって話ではないです。
でも、この取り決めがないと、うまく機能しないっすね。
- イノベーションのセキュリティ
ウォーターフォールだと、アプリがリリースされてから初めてセキュリティ診断ってなるけど、ここを、DevOps を組み合わせてリリースのタイミングでセキュリティ診断をできるようにしたり、DevSecOps まで踏み込んで日常的な運用の中にセキュリティ作業まで含めるようなこと。
多分これも、いきなり全部やるんじゃなくて、徐々に進めるほうが結果早くできるようになる気はしますね。
組織・人材論
Organize
クラウド導入には、多くの人が関係しますし、ビジネスの人もITの人もと、組織横断での導入になっていくと思います。
また、オンプレミスのスキルだけでは不十分で、クラウドのスキルを持った人も必要になります。
ですので、CAF では組織・人材論の項目があるんです。
以下の 4 つのステップで進めることがドキュメントに記載されています。
- 構造の種類:実際の運用モデルに最も適した組織構造の種類を定義します。
- クラウドの職務:クラウドの導入と運用に必要なクラウドの職能について説明します。
- チーム構造を成熟させる:さまざまなクラウドの職務を遂行できるチームを定義します。
- RACI マトリックス: 提供された RACI マトリックスを使用して、クラウド オペレーティング モデルの機能に応じたロールを各チームにマップします。 このマトリックスには、責任、説明責任、相談を受ける、最新情報を把握するといったロールが含まれます。
機能としては、以下のようなものがあるとよさそうです。
- クラウド戦略:技術的な変更をビジネス ニーズに合わせます。
- クラウド導入:技術的なソリューションを提供します。
- クラウド ガバナンス:リスクを管理します。
- 中央 IT チーム:既存の IT スタッフからのサポート。
- クラウド運用:採用されたソリューションをサポートおよび運用します。
- クラウドのセンター オブ エクセレンス:導入の品質、速度、回復性を向上させます。
- クラウド プラットフォーム:プラットフォームを運用し、成熟させます。
- クラウド自動化:導入とイノベーションを促進します。
- クラウド データ:データを管理し、分析ソリューションを有効にします。
- クラウド セキュリティ:情報セキュリティ リスクを管理します。
まとめ
CAF については、前半半分って PO とか割とビジネスに近い人向けで、後半がランディングゾーンに関わるところなのでアーキテクト向けなのかなっていう印象です。
で、このフレームワークが一番言ってるのは、まず、計画してそのあと改善しようってことだと思うんです。
ビジネスも変わるので、それを実現するシステムも変わって、ワークロードも変わるのでプラットフォームも変わるから、最初に決めてそれで終わりなんて絶対に無理ですよねー。
あと、Azure もどんどん新しい機能が提供されるんで、より便利になっていったりするし。
なので、CAF を読んでまずできそうなところから徐々に着手していくのがいいと思います。
それと、MS がだしてるドキュメントなのに、IT じゃない部分もすごく多く書かれているという印象で、今、クラウド化に向けて悩んでいる方は、もしかしたら IT の問題よりもビジネス上の課題がないかを確認した方がいいかもしれないですね。
その時に、今が本当に正しいのか？っていう視点のもと整理していった方がいい部分も結構ありそうな気がしますよ。
コメント