CNCFが公開したクラウドネイティブ成熟度モデル：レベル1―コンテナへの取り組み開始直後にやるべきこと：完訳 CNCF「クラウドネイティブ成熟度モデル」（2）

CNCFが公開した「クラウドネイティブ成熟度モデル」を翻訳してお届けする本連載。第2回は、成熟度のレベル1に当たるクラウドネイティブ環境の構築フェーズにおいて、人、プロセス、ポリシー、テクノロジー、ビジネス成果の観点から何を行うべきかを説明した部分を掲載する。

[CNCF Cartografosワーキンググループ，著]

　本連載では、Cloud Native Computing Foundation（CNCF）がWebサイトで公開した「クラウドネイティブ成熟度モデル」を翻訳し、成熟度段階ごとに掲載している。

　これは、組織におけるクラウドネイティブの取り組みを5つの成熟度段階に分け、各段階で具体的に何をすべきかを示すガイド文書だ。テクノロジーをカバーしているのはもちろんのこと、人（組織）、プロセス、ポリシー、ビジネス上の成果（ビジネスアウトカム）の側面からも、やるべきことを示している。

　前回のプロローグ編では、クラウドネイティブの歩みを進めるためのの前提条件が示された。

　今回は「レベル1―構築編」。クラウドネイティブの取り組みを始めたばかりの組織が何に焦点を当て、具体的に何を実行すべきかについて説明した部分を掲載する。

　レベル1では、概念検証（PoC：Proof of Concept）あるいは単一アプリケーションの試験的運用に成功することを目指す。本番環境には達しない。このレベルでは、Kubernetes基盤を導入し、基本的なツールとテクノロジーを実装して実験的な利用を行う。まだ、プロセスの自動化に力を入れることはない。

　セキュリティについては、できるかぎり早くクラウドネイティブ環境への組み込みを始めるべきだという。

　また、クラウドネイティブの取り組みを組織的に評価するためのKPI（Key Performance Indicator）を、この段階で確立すべきだとしている。

　なお、本連載では、2023年1月初めにWeb公開された時点での内容を翻訳している。翻訳の文責は＠IT編集部 三木泉にある。

連載目次

第1回　プロローグ編

第2回　レベル1―構築編（本記事）

第3回　レベル2―運用編

第4回　レベル3―スケール編

第5回　レベル4―改善編

第6回　レベル5―最適化編

＊ライセンスについての注意書き：本記事はCC BY 4.0に基づき、「Cloud Native Maturity Model」を翻訳して掲載するものです。上記URLのページ最下部に、「©2023 The CNCF Authors | Documentation Distributed under CC BY 4.0」と記載されています。

---

レベル1―構築

　チームはベースラインとなるクラウドネイティブ実装をしますが、本番運用には至りません。

人

人についての概要

　クラウドネイティブフレームワークによって、ビジネスとテクノロジーの目標達成を目指しています。 チームは関連テクノロジーに不慣れですが、基本的な技術的理解と前提条件をある程度備えています。 ビジネスリーダーは、クラウドネイティブの利点を理解しています。

組織変革

　トランスフォーメーションの過程で受けられる組織的なサポートは限定的であり、この段階では概念実証 （PoC）フェーズ、あるいは単一のアプリケーションのみに専念します。

チームと分散化

　チームは、Kubernetesを中心としたクラウドネイティブツールを検討しているでしょう。 ただし、検討のための検討ではなく、本番運用を目標とします。一般的に、全ての作業は正式なMVPプログラム内で行われます。

セキュリティ

　クラウドネイティブを実装する人たちは、セキュリティに力を入れる必要があります。 この段階ではデフォルトのセキュリティ設定が使用され、本番運用前の段階で機能します。 時間をかけてオープンソースのセキュリティ状況を把握し、本番運用前環境でセキュリティPoCを実施して、開発、運用、セキュリティの各チームが、クラウドネイティブワークロードで何をする必要があるのかを理解できるようにします。

開発者のアジリティ

　組織は分散化に取り組み、「team of teams」（訳注：小規模のチームが協働して1つのチームとして機能する組織のあり方）を採用します。 これは現場にとって不可欠な要件です。チームはさまざまな成熟度段階にわたって、自動化テスト、メトリクス、フィードバックのためのツールを実装していきます。

　開発者は既に、「Agile Manifesto（アジャイルソフトウェア開発宣言）」について学び、スクラムフレームワークを採用（必ずしも運用は含まない）しているかもしれません。開発者は、外部依存関係を自身で解決しようとする可能性があり、これによってフィードバックが遅くなったり、各スプリントにおける機能開発が不完全になったりしがちです。

開発者のスキルアップ

　人材の成熟度を高めるため、開発チームのスキルアップが必要になります。

　この段階で、アプリケーションチームは「Twelve Factor App」、マイクロサービス、クラウドネイティブパターンのトレーニングを受けます。 また、開発チームをブートストラップするために、クラウドネイティブの概念やkubectlなどのツールに精通している開発者が必要になります。

CNCFによる認証

　Cloud Native Computing Foundation（CNCF）は、Kubernetes、Prometheus、Envoyなど、急速に成長している多くのオープンソースプロジェクトのベンダー中立的な活動の場として機能しています。

　クラウドネイティブインフラストラクチャの持続可能なエコシステムを構築するためには、チームとしてCNCF認定資格に投資することが重要です。ただしレベル 1では、資格を取得することはほとんどありません。

プロセス

プロセスについての概要

　アプリケーションに関する機能要件（アプリケーションの機能とコード）と非機能要件（パフォーマンス、容量、可用性など）の両方をマッピングし、組織をどうスケーリングさせるかを定義します。 この段階では、フィードバックはSlack、メール、電話などを使って手動で行われ、修正も手動で行われます。 一方でGitワークフローを定義し、反復性の実装を開始します。 脆弱（ぜいじゃく）なシステムは具体的なリスクをもたらすため、プラットフォームとテクノロジーのライフサイクルを管理し、アップデート、特にセキュリティアップデートを定期的に適用する必要があります。 こうしたアップデートは、アドホックで手動によって適用するか、ディストリビューションに含まれる更新システムを使用することになるでしょう。

CI/CD

　クラウドネイティブ・トランスフォーメーションの中核となるのは、CI/CD（Continuous Integration/Continuous Delivery）の採用です。 CI/CDは、最新のソフトウェア開発手法に基づいてアプリケーションを構築、テスト、デプロイするのに役立ちます。 CI/CDプロセスは次第に成熟していきます。

　CI/CDを既に行っているなら、クラウドネイティブ環境に統合していく必要があります。 既存のベストプラクティスを取り入れ、これを改善していくことも求められます。

変更管理

　デプロイメントをコントロールするには、変更管理を実装する必要があります。この段階では変更管理プロセスが整っていないでしょう。 代わりに、アドホックなリクエストに基づいて変更が実行されています。

セキュリティ

　クラウドネイティブ環境のセキュリティを保つには、プラクティスまたはプロセスを通じて、セキュリティのツールとプラクティスをできるかぎり早くクラウドネイティブ環境に組み込むことが欠かせません。 「シフトレフト」という用語は、テストまたはセキュリティに関連するプラクティスを、プロセスのできるだけ早い段階へ組み込むことを指すのによく使う言葉です。 セキュリティはクラウドネイティブ成熟度モデルの全段階に関わります。組織におけるクラウドネイティブセキュリティを成熟させようとするセキュリティチームを支えるため、人、プロセス、ポリシー、テクノロジーの取り組みを組み合わせることができます。

　行動を起こしましょう。セキュリティの旅はここから始まります。 実装のあらゆる側面でセキュリティを考慮し、一級市民として扱いましょう。

監査とログ

　実装するべきプロセスには、ロギングと監査が含まれます。 これは、内部要件を満たすためや、コンプライアンス業務をサポートするために行われます。

　この段階では、おそらく手動のログスクレイピングがアドホックで実施されており、集約的なログポイントやSIEM（Security Information and Event Management）がないことが考えられます。

ポリシー

ポリシーについての概要

　私たちは、ポリシーの採用が段階的に行われるものであることを認識しています。 リスク選好度は組織によって異なります。ポリシーを定義して適用するためのガイドとして、このドキュメントを活用してください。 レベル5までに成熟度を完全に上げることになりますが、その道のりの長さは組織ごとに異なります。

　この段階では、チームは限定的な文書化したポリシーを用意し、クラウドに構築しているサービスをサポートします。

ポリシーの作成

　組織のポリシーとコンプライアンス要件を、クラウドネイティブ環境用に変換する必要があります。

　時間をかけて、アプリケーションの機能要件とアーキテクチャ要件を理解してください。

コンプライアンス

　特に規制の厳しい業界では、コンプライアンスを達成するためにポリシーを整備する必要があります。 コンプライアンスについては、達成すべきことがさまざまです。

　時間をかけて、CIS（Center for Internet Security）、NIST（National Institute of Standards and Technology）、PCI（Payment Card Industry）などのコンプライアンス要件を理解してください。 そして、コンプライアンスのためにSLO（Service Level Objectives）と優先順位を設計してください。 これには時間を要し、本番稼働前の要件とはならないかもしれませんが、実稼働に移行するにつれて重要性が増します。

テクノロジー

テクノロジーについての概要

　この段階では、Kubernetesの最初の実験的利用と導入を行います。 比較的基本的なツールとテクノロジーから始めます。 既存のツールセットを評価して、新しい環境にどのように適合するか（クラウドネイティブでうまく機能するものとそうでないものは何か）を確認します 。 自動化は限定的なものにとどまりますが、心配する必要はありません。現段階での重点はベースラインテクノロジーを実装することです。まだ本番環境には入りません。

インフラストラクチャ

　クラウドインフラストラクチャをオンプレミスまたはオフプレミスで構築していきます。 ネットワーク、ファイアウォール、IAM（Identity and Access Management）、アクセス制御とポリシー （の必要に応じた変更）などのサポートテクノロジーを早期に検討することは役に立ちます。Kubernetesの最初の実験的導入の結果、多くのトピックが見つかるので、対処してください。こうしたトピックは、クラウドネイティブへの移行における「パンくずリスト」のような存在です。 RBAC（Role-based Access Control）ポリシー、ロードバランサーやイングレス構成、クラスタダッシュボード、特権アクセス（またはその欠如！）、コンテナロギングなどがあります。 目的は、「ペット」から「家畜」に移行することです。そのため、Infrastructure as Code（IaC）ツールを使用して、Infrastructure as a Service（IaaS）のための宣言型ソリューションに投資します。この段階で、統合的なDevOpsプラクティスがまだない場合は、今後運用を担当するチームに慣れてもらいましょう。

コンテナとランタイムの管理

　当初は、コンテナの構築だけに集中する必要があります。 最初のステップの1つは、アプリケーションのCIにコンテナビルドを追加することです。 また、イメージのためにコンテナレジストリを採用する必要があり、バージョン管理とタグ付けを検討して、どのコードが使用されているかを正確に把握できるようにしなくてはなりません。

アプリケーションのパターンとリファクタリング

　できれば現段階での重点はベースラインテクノロジーを実装することです。できることと、メンバーが慣れていることを確認します。可能な限り、クラウドネイティブの取り組みをマイクロサービスアプリケーションから始めてみてください。 理にかなっているなら、既存のモノリシックアプリケーションで試してもいいでしょう。これにより、kubectl、ネットワーク接続、その他のトピックなど、クラウドネイティブの取り組みに必要なツールと依存関係が明らかになります。

　組織は、マイクロサービスのパターンとアーキテクチャを確認し、アプリケーションの具体的な姿を理解する必要があります。 レイテンシ、回復力、スケーリング、サードパーティツールなどの非機能要件は、必ず考慮する必要があります。 モノリスを変換する場合、アプリケーションに大幅な再設計が必要になることがあります。モノリスのリファクタリングには状態管理に関する作業が必要になるため、検討してください。 コードに精通している既存の開発者がクラウドへの移行に参加できるよう、知識がコードに残るようにしてください。 クラウドと既存の資産との相違を最小限に抑えてください。 この演習により、クラウドネイティブへの移行にコミットしなければならないことを全員が理解できるようになります。

アプリケーションのリリースと運用

　コードとしてのインフラストラクチャ（IaC）を使用したクラスタの管理は、アプリケーションのリリースおよび展開の管理とは異なりますが、手法とツールの多くは共通しています。 Kubernetesを使い始めるときは、できるだけ多くの実地経験をまず積むことが重要です。 最初は、kubectlとKustomizeを使用してアドホックなデプロイを行います。

セキュリティとポリシー

　セキュリティ保護されたCI/CDパイプラインをまだ構築していない場合は、構築を開始してください。現在仮想マシンで行っていることとは、将来的に全く異なるものになることを忘れないでください。

テストと問題の検出

　開始直後は、最初の本番候補として選定したビジネスアプリケーションのテストの多くを、手動で実行します。 Kubernetesでは、全般的なネットワーク接続に注意を払い、アプリケーションをデプロイできることを確かめます。 スモークテストとUAT（User Acceptance Testing）テストを実施します。

ビジネス成果

　クラウドネイティブ成熟度モデルのレベル1では、チームがベースラインの実装を行い、本番前の状態にあります。 この段階ではPoCを成功させ、完了します。 PoCに基づき、クラウドネイティブがアプリの改善にどのように役立つかに関して、最初の調査結果を手に入れることになるでしょう。 開発環境では、例えば次のようなことが分かったはずです。

• より少ないリソースでアプリケーションを稼働できた（コスト削減／より効率的な使用）
• 新機能をより早く出荷できた（市場投入までの時間が短縮され、収益が増加する）
• ダウンタイムがなかった（顧客にとっての信頼性の向上）
• 回復力のあるクラウドアーキテクチャによりビジネス継続性が向上した

　このフェーズでは、クラウドネイティブの取り組みの達成度を測定する方法（最初の KPI）を決定します。 同様に、ステークホルダーに対して達成度をどのように示すかも重要です。クラウドネイティブの取り組みにおける達成は全て、この測定にマッピングされる必要があります。 そのため、KPIの確立はレベル1における主要な成果となります。1日目からすぐに結果が得られるわけではないことに注意してください。

　フォローする必要のある定量的および定性的なKPI（Key Performance Indicator）の例としては、次のようなものがあります。

• コストを最適化することで、アプリインフラストラクチャの支出を25%削減
• 開発コストを10%ダウン
• 可能な限り自動化を進めることで、開発チームによるアプリインフラストラクチャへの関与を15%削減
• コンテナ内のCVE（Common Vulnerabilities and Exposures）識別を自動化することで、アプリケーションのセキュリティを強化
• アプリケーションアクセスの制限および追跡によってコンプライアンスを向上。SOC 2への準拠を示す
• CI/CDパイプラインを実装することで開発ライフサイクルを加速し、四半期ごとに10%多くの機能を出荷
• 移行計画――組織によって異なるが、移行計画を用意しておく必要がある。 最初に移行するアプリケーションが1つであっても複数であっても、計画を確立する必要がある
• パフォーマンススコアの向上によって測定されるカスタマーエクスペリエンスの改善
• 情報サイロの解消：部門の孤立を防ぐ。独自の統合的なエコシステムを整備
• ビジネスとITの目標の整合性確保：全員が関与し、認識することで、目標を効率的に達成するためのリソースを適切に配置
• 社内コミュニケーションの改善：人材の交流により、知識を共有して新しい視点を提供

　このフェーズでは、ビジネス面での成果を調査し、ビジネス関係者に説明することが重要です。 エンジニアリングのリーダー、アプリケーションオーナー（財務、マーケティングなど）、CEO（最高経営責任者）、さらには取締役会との話し合いが必要です。 こうした議論と調整がなければ、次の段階への取り組みはほとんど評価されず、懐疑論さえも生まれるでしょう。