CNCFが公開したクラウドネイティブ成熟度モデル：レベル2―コンテナ環境の本番移行はどう進めるか：完訳 CNCF「クラウドネイティブ成熟度モデル」（3）
CNCFが公開した「クラウドネイティブ成熟度モデル」を翻訳してお届けする本連載。成熟度のレベル2では、クラウドネイティブ環境を本番に移行する。この段階において、人（組織）、プロセス、ポリシー、テクノロジー、ビジネス成果の観点から何を行うべきかを説明した部分を掲載する。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
本連載では、Cloud Native Computing Foundation（CNCF）がWebサイトで公開した「クラウドネイティブ成熟度モデル」を翻訳し、成熟度段階ごとに掲載している。
これは、組織におけるクラウドネイティブの取り組みを5つの成熟度段階に分け、各段階で具体的に何をすべきかを示すガイド文書だ。テクノロジーをカバーしているのはもちろんのこと、人（組織）、プロセス、ポリシー、ビジネス上の成果（ビジネスアウトカム）の側面からも、やるべきことを示している。
今回は「レベル2―運用編」。 レベル1でクラウドネイティブの概念検証（PoC：Proof of Concept）を終えた組織が、次には何に注力し、具体的に何を実行すべきかについて説明した部分を掲載する。
レベル2では、最初のアプリケーションの本番運用を実現し、クラウドネイティブのツールとプラクティスに移行することを目標とする。
本番移行のため、信頼性とセキュリティに重点を置いてKubernetesクラスタを構築する。開発チームはKubernetesの基本的な操作に慣れ、ビルド／デプロイのプロセスを整備する。また、セキュリティ、モニタリング、オブザーバビリティをプロセスに組み込む。
また、レベル1で確立したKPI（Key Performance Indicator）に基づき、本番移行の成果をビジネスリーダーに伝えることが重要だという。
なお、本連載では、2023年1月初めにWeb公開された時点での内容を翻訳している。翻訳の文責は＠IT編集部 三木泉にある。
＊ライセンスについての注意書き：本記事はCC BY 4.0に基づき、「Cloud Native Maturity Model」を翻訳して掲載するものです。上記URLのページ最下部に、「©2023 The CNCF Authors | Documentation Distributed under CC BY 4.0」と記載されています。
レベル2―運用
クラウドネイティブ基盤が確立されており、この段階で本番環境に移行します。
人
人についての概要
各個人がトレーニングとスキルに積極的に投資しています。 その結果、少数のエキスパートと専門知識が育っています。クラウドスキルエンジニアと、プラットフォームスキルを提供する開発者グループの参加で、DevOpsが進展し始めました。クラウドネイティブの取り組みは、リーダー層のメンバーがオーナーシップを担うようになっています。
組織変革
組織の変革を進めます。プロジェクトチームを定義し、アジャイルプロジェクトグループを作って、迅速なフィードバック／テストのループを確立します。
チームと分散化
共通サービスとその責任の具体化を進め、ツールを集約化すると共に、クラウドネイティブでないツールの収束や利用停止を行います。
セキュリティ
チームは、Kubernetesクラスタのセキュリティに責任を持つのは誰か、どう管理するかに焦点を当てる必要があります。そのためには、セキュリティチームに参加してもらう必要があります。
開発者のアジリティ
チームは技術的に困難な問題に落ち着いて対応し、クラウドネイティブがどのように役立つかを理解できるようになっています。組織として分散化とビルドの自動テストにコミットし、一部の環境ではデプロイを自動化します。
開発者のスキルアップ
開発チームで、以下のようなKubernetesの基本的操作を実行できるメンバーが増えます。
- OperatorをKubernetes APIに接続する
- kubectlコマンドに慣れる
- リソースをリストし、表示する方法を理解する
- 基本動作を実行する（どのように機能するかについての理解は限定的
CNCFによる認定資格
組織は、レベル2またはレベル3の前後で、CKAおよびCKADの認定を検討するのがいいでしょう。
Certified Kubernetes Administrator（CKA）
このプログラムは、Kubernetes管理者の職務を遂行するためのスキル、知識、能力を持っていることを保証します。
Certified Kubernetes Application Developer（CKAD）
この試験は、Kubernetes上のクラウドネイティブアプリケーションを設計、構築、構成、公開する能力を認定します。
プロセス
プロセスについての概要
基本的アプリケーションの本番移行に重点的に取り組みます。この取り組みには、GitとCI（Continuous Integration）に精通することも含まれます。また、クラウド／コンテナネイティブなCI/CD（Continuous Integration/Continuous Delivery）システムの特徴を生かせる、構造化されたビルド／デプロイプロセスを導入します。
CI/CD
アプリケーションのために、クラウド／コンテナネイティブなCI/CDシステムの特徴を生かせる、構造化されたビルド／デプロイプロセスを導入します。
変更管理
この段階では、ソースコントロール管理（SCM）からデプロイまでのワークフローの基本的な理解を深め、SCMでコミットをマージ／タグ付けし、デプロイをトリガーできるようにします。
セキュリティ
コンテナや構成のスキャンなど、CIプロセスにセキュリティを組み込みます。
監査とログ
時間をかけて、ログの集約を定義します。
ポリシー
ポリシーについての概要
サービスが本番に近づくにつれて、初期的なポリシーを標準として合意し、その大部分を文書化します。
ポリシーの作成
初期的なリソースメトリックを定義し、データの収集を開始します。
コンプライアンス
手動あるいはシンプルなスクリプトにより、初期監査を実行します。
テクノロジー
テクノロジーについての概要
これは、本番環境への第一歩です。 レベル1では基盤の構築に取り組んできましたが、この段階では本番環境に移行します。 比較的小規模で単純なアプリケーションから始めたかもしれませんが、本番環境に飛躍するには、幾つかの重要なステップを踏む必要があります。 おそらく、モニタリングとオブザーバビリティ（可観測性）をワークロードに組み込む必要があるでしょう。鍵となるオブザーバビリティツールを導入し、RAM、CPUなどの標準メトリックについてクラスタの監視を開始します。アプリケーショントレーシングの評価を始めているかもしれませんが、コアメトリックの収集を開始しているのなら、あまり心配する必要はありません。この段階での焦点は、アプリケーションを本番環境で実行し、組織内でそれをサポートするのに十分なプラットフォームリソース、オブザーバビリティ、運用能力を確保することです。
インフラストラクチャ
ゴールは本番運用であるため、信頼性とセキュリティに重点を置いて本番用のKubernetesクラスタを構築したはずです。
コンテナとランタイムの管理
本番運用を進めます。 セキュリティ、ポリシー管理、ワークロードの構成ミス、リソースのリクエストと制限に関する設定に役立つように、本番環境の基礎を強化するツールを試します。 コンテナハイジーンの鍵となるセキュリティプラクティスの組み込みを進めます。
アプリケーションのパターンとリファクタリング
本番環境に達し、最初のAPIを公開します。 初めからマイクロサービスアプローチで進める場合は、「マイクロサービスファースト」なフレームワークの整備を検討してください。そうでない場合は、リフト・アンド・シフトに適したアプリケーションの移行を検討するか、アプリの移行は後回しにしてください。
アプリケーションのリリースと運用
本番環境における最初のステップとして、CIやリリースツール、kubectl、Kustomizeを使用して、最初の小さなアプリケーションをデプロイすることが考えられます。この時点までにKubernetesの構成に関する主要なスキルを習得することは、非常に重要です。
セキュリティとポリシー
開発グループと運用グループが、コンテナ、シークレット、セキュリティに関する優れたプラクティスに従っていることを確認してください。本番環境であるため、暗号化と認証・認可を確実に適用する必要があります。
テストと問題の検出
本番環境になったので、ステージング環境または開発環境で、セキュリティ、ポリシー管理、ワークロードの構成ミス、リソースのリクエストと制限、オブザーバビリティを支援するツールを試します。
ビジネス成果
クラウドネイティブが確立され、テクノロジストは本番環境に移行しています。レベル2におけるテクノロジー面での成果は、完全に機能するアプリケーションまたはアプリケーション群を、クラウドネイティブのツールとプラクティスに移行することですが、ビジネス上の成果は、こうした移行のメリットを評価する能力です。大部分の企業は、このレベルでプラトー（一時的な停滞期）を迎えます。そこで、クラウドネイティブの成熟度モデルが真価を発揮します。
レベル1で確立したKPIを使用して、成功を測定し、ステークホルダーに伝えます。
レベル2の運用フェーズでは、本番環境への移行に集中します。テクノロジーに関する標準を確立し、チームがこれを運用して、ポリシーとプロセスを実装します。ビジネス上の成果は、本番への移行にあります。組織のビジネスリーダーは、どのアプリケーションが移行するのか、その理由はなぜなのかを理解したいと考えます。ビジネスリーダーに計画を明確に伝えられるようにしてください。チームがレベル 2での活動を進めるにつれ、反復可能なパターンが生まれます。反復性により、移行対象のアプリケーションで得られた利点を、それほど手間をかけずに別のアプリケーションに適用できることは、ビジネス成果につながります。こうしたパターンは、開発、セキュリティ、運用の各チームで、オペレーションを合理化するのに役立ちます。
KPIには投資収益率（ROI）も含めることもできますが、レベル2では、レベル5に到達したときよりもROIが低いことを知っておいてください。理由は、レベル5では最適化を行っているのに対し、この段階ではツールの取得、適切なチームとスキルセットの確立に大きな投資を行っているためです。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。