クラウド ネイティブとは実際には何を意味するのでしょうか?

多くの場合、クラウド ネイティブに関する会話では、コンテナ化やマイクロサービスなどのテクノロジの選択に直接焦点が当てられます。これらは確かにクラウド ネイティブ プロジェクトの潜在的なコンポーネントですが、唯一のものではありません。このシリーズの記事では、テクノロジーとインフラストラクチャはもちろん、アーキテクチャ、設計、そしておそらく最も見落とされがちな人材とプロセスなど、さまざまな観点からクラウド ネイティブを検討します。簡単に言えば、クラウド ネイティブとは、クラウドに移行するだけでなく、クラウド インフラストラクチャとサービスの独自の機能を活用してビジネス価値を迅速に実現することを意味します。

[[391851]]

クラウド ネイティブの概念は、その用語自体が使用される前から存在していました。ある意味、クラウド ネイティブは、パブリック クラウド プロバイダーがコンピューティング能力の弾力性のあるインスタンスへの簡単かつ手頃なアクセスを提供し始めたときに始まりました。そうなると、この新しいインフラストラクチャの柔軟性と、それに伴うビジネス上の利点を活用するアプリケーションをどのように作成するかという疑問が生じます。

クラウド ネイティブのアプローチとテクノロジーは過去 10 年間で大きく変化し、現在も進化を続けていますが、クラウド ネイティブ アプリケーションが達成しようとしている中核的な技術目標とビジネス目標は変わりません。これらには以下が含まれます:

• 俊敏性と生産性: ビジネス指標に基づいた迅速なイノベーションを実現します。メンテナンスのリスクを軽減し、環境を最新の状態に保ちます。
• 弾力性とスケーラビリティ: ダウンタイムなしで自己修復と継続的な可用性を実現します。弾力的なスケーリングと無制限の容量の認識を提供します。
• 最適化と効率: インフラストラクチャと人的リソースのコストを最適化します。場所とプロバイダー間の自由な移動を可能にします。

これらの目標については、後の投稿でクラウド ネイティブの「理由」を確認するときにさらに詳しく説明しますが、この単純な定義からでも、クラウド ネイティブの範囲が新しいジャンルに移行するだけではないことは明らかでしょう。インフラストラクチャー。しかし、これらの目標は正確である一方で、それがクラウド ネイティブに具体的にどのように適用されるのかはわかりにくいです。クラウド ネイティブが実際に何を意味するのかを定義するには、さらに作業を行う必要があります。

マイクロサービスなどのクラウド ネイティブに関連する一般的な参照ポイントや、12factor アプリなどの古いチェックリストを見ると、クラウド ネイティブはアーキテクチャ スタイルの説明であり、他のオプションもそれに従うという結論に至るかもしれません。クラウドネイティブ アーキテクチャが存在することに疑いの余地はありません。ただし、クラウド ネイティブ プラットフォームで成功するには、企業はより総合的な視点を持つ必要があります。アーキテクチャとインフラストラクチャの決定に加えて、組織とプロセスに関する決定もあります。これにより、重要な実装が実現します。

テクノロジーだけではビジネス成果は得られない

次の図は、これらの決定がどのように相互作用するかを示しています。

テクノロジーだけではビジネス成果は得られない

これらの側面がどのように相互にリンクされているかの良い例と、リンクが壊れた場合に何が起こるかについての警告については、弊社の記事「不完全なクラウド ネイティブ導入の回避」で説明されています。このシリーズの記事では、クラウド ネイティブの成功が、アーキテクチャと設計、テクノロジーとインフラストラクチャ、人材とプロセスという 3 つの重要な調整領域における変更の調整とどのように結びついているかを示します。それぞれを詳しく見ていきましょう。

テクノロジーとインフラストラクチャ: 「クラウド ネイティブ」の文脈における「クラウド」とは何でしょうか?

10 年以上前、「クラウド」という言葉は主に場所に関するものでした。これは通常、インターネット経由でアクセス可能な、他者のデータセンターにあるインフラストラクチャを指します。しかし、今日では「クラウド」は、そのインフラストラクチャとどのようにやりとりするかについて、より多くのことを表します。実際、場所の要素はほとんどなくなり、現在では独自のデータ センターでクラウドのような施設 (「プライベート クラウド」) を運用することが一般的になり、その間でサービスとワークロードを実行するハイブリッド ソリューションも実現されるようになりました。

したがって、今日のクラウドでは、インフラストラクチャとどのようにやりとりするかが重要になり、少なくとも次のものを提供する必要があります。

• セルフプロビジョニング: 新しい仮想リソース (サーバー、ストレージ、ネットワーク) を即座に取得します。
• 弾力性: 需要に応じてリソース (およびそれに関連するコスト) を自動的に拡大または縮小します。
• 自動回復: リソースは、介入なしに、サービスの可用性への影響を最小限に抑えて障害から回復するように設計されています。

ただし、クラウド プラットフォームと概念が成熟するにつれて、クラウド ネイティブ クラウドは実際にはインフラストラクチャの抽象化も強化されることを意味します。

• 不変のデプロイメント - コンテナイメージベースのデプロイメントなど
• 宣言型構成 - 基盤となる状態を提供する「コードとしてのインフラストラクチャ」
• ランタイムに依存しない - プラットフォームは、コンポーネント（コンテナなど）をその内容を知ることなくブラックボックスとして扱います。
• コンポーネント オーケストレーション - 共通の宣言型ポリシーと構成を通じて管理 (監視、スケーリング、可用性、ルーティングなど) を可能にします。

クラウド ネイティブの初期の頃は、これらの機能は高度に独自のものであることが多かったのですが、現在では、Kubernetes などのコンテナやコンテナ オーケストレーション機能の形で、この機能はほぼどこにでもあります。したがって、上記のリストはコンテナの用語に非常に特化していますが、インフラストラクチャからさらに抽象化され、将来的にさらに重要になる可能性のある、サーバーレス/サービスとしてのサービスなどの他のオプションがあることを認識する価値があります。

ビルド自動化、サービス メッシュ、ロギング、トレース、分析、ソフトウェア定義ネットワークとストレージなど、さらに多くのものを含めることができます。ただし、クラウド プラットフォームのより独自の側面については後ほど説明します。これらも時間の経過とともにさらに標準化されることを期待します。したがって、この文脈では、「クラウド」は実際には、上記に挙げた特殊な特性を持つインフラストラクチャとテクノロジーを指します。

アーキテクチャと設計: 「クラウド ネイティブ」における「ネイティブ」とはどういう意味ですか?

「ネイティブ」とは、「クラウド上で実行される」だけでなく、クラウド プラットフォームの独自の機能を具体的に活用するソリューションを構築することを意味します。アプリケーションは、基盤となるクラウド インフラストラクチャの利点を魔法のように継承するだけでなく、その操作方法も教える必要があります。

ここでは言葉の使い方に細心の注意を払う必要があります。 「クラウド プラットフォームの独自性」を指すために「ネイティブ」を使用する場合、特定のクラウド プロバイダーのベンダー固有の側面を意味するものではありません。これは「クラウド プロバイダー ネイティブ」となり、移植性とオープン スタンダードの使用に関する目標とは実際には完全に矛盾することになります。私たちが言っているのは、すべてのクラウド プラットフォームに概念的に共通するものです。つまり、これらは、インフラストラクチャとテクノロジーに関する前のセクションで強調した内容です。

建築とデザインに重要な意味を持ちます。たとえば、水平方向に拡張でき、自動回復メカニズムと連携できることを保証するソリューションを作成する必要があります。これは、クラウド ネイティブがマイクロサービスの概念と最も重なる部分です。たとえば、次のコンポーネントの記述が含まれます。

• 最小化された状態
• 依存関係を減らす
• 明確に定義されたインターフェースを持ち、
• 軽量
• それは一度限りの

これらについては次の記事でさらに詳しく説明しますが、これまでのところ最も重要なことは、これらがすべて高度に相互依存しているということです。たとえば、高さの状態を持つ 1 回限りのコンポーネントを作成したい場合、それははるかに困難になります。依存関係を減らすと、基本的にコンポーネントの軽量化に役立ちます。明確に定義されたインターフェースがあれば、使い捨てコンポーネントの再インスタンス化などが容易になります。これは、クラウド ネイティブ アプローチに移行するには、多くの関連領域で同時に変更が必要になるという、より広範なポイントのほんの一例にすぎません。私たちが発見したこれらのクラウドネイティブ コンポーネントは、互いに補完し合います。

人材とプロセス: 「クラウド ネイティブ」は組織や仕事のやり方をどのように変えるのでしょうか?

明らかではないかもしれませんが、アーキテクチャと基盤となるインフラストラクチャに関する上記の仮定と決定を使用すると、人々とプロセスへのアプローチ方法を根本的に変える機会が得られます。実際、これらの変更は必要だったと言えるでしょう。

以下では、マイクロサービス アプローチの人材とプロセスへの影響について説明します。

• マイクロサービスとは、小規模な自律的なチームでサービスを構築することを意味します。これは単にコンウェイの法則を応用したものです。システムを小さく分離されたコンポーネントで構成したい場合は、明確に定義され制御されたインターフェースを通じてのみ、チームを小さくし、他のチームと密に結合されないようにする必要があります。
• マイクロサービスとは、アジャイル手法を使用し、開発プロセスに DevOps の原則を適用することも意味します。そうでない場合、このアプローチの核となる強みである、エンドツーエンドのフィードバックとコードの迅速な反復をどのように実現するのでしょうか。一方、DevOps は、継続的インテグレーションや継続的デリバリー/デプロイメント (CI/CD) などのさらなるプロセス改善を意味します。
• DevOps では、自動テスト (テスト駆動開発を含む場合があります) などの他の特定の技術プロセスを採用する必要があり、トランクベースの開発を強く推奨します。テスト サイクルを最小限に抑えたいという願望から、人々が仕事に取り組む方法 (ペア プログラミングなど) の変更を検討することになるかもしれません。

同様に、コンテナ テクノロジーは、必要なスキル、役割、プロセスに影響を与えます。

• クラウド インフラストラクチャでは、特定のランタイム スキルや製品スキルではなく、Kubernetes の知識などの一般的なクラウド プラットフォーム スキルを使用して、より多くの運用 (展開、スケーリング、高可用性など) を実現することがよくあります。これにより、複数の技術分野で作業する人々の学習曲線が大幅に短縮され、より広範な役割と知識の共有が可能になり、効率が向上し、コストが削減されます。また、サイト信頼性エンジニアが可能な限り運用タスクを自動化するよう奨励します。
• コンテナ、特にコンテナ イメージ テクノロジーは、CI/CD パイプラインの自動化を簡素化し、ビルド/リリース サイクル時間を短縮して生産性を向上させます。ビルド パイプラインの実装の均一性が高まると、より簡単に保守できるようになり、より幅広いユーザーが使用できるようになります。
• 不変のコンテナ イメージと宣言型のインフラストラクチャをコードとして組み合わせることで、さまざまな環境間でのデプロイメントの一貫性を向上させることができます。これにより、テストと診断のコストが削減され、展開速度が向上し、ダウンタイムが短縮されます。プロセスの観点から見ると、これにより信頼性、パフォーマンス、セキュリティ テストなどの側面で「シフト レフト」が可能になります。その結果、開発者がコードの運用品質に対してより大きな責任を負う、DevOps/DevSecOps 文化が生まれました。

「クラウドネイティブ」の意味をまとめると

これまで議論してきたことをまとめると、クラウド ネイティブは 3 つの異なる観点から定義する必要があることがわかります。

• インフラストラクチャの複雑さを抽象化するプラットフォーム。 （インフラとテクノロジー）
• インフラストラクチャの抽象化（アーキテクチャと設計）を活用したソリューション
• 開発、運用、ビジネスプロセスの自動化、開発チーム（人材とプロセス）の自律性の向上

現在、技術面ではコンテナ化に多くの注目が集まっていますが、重要なのは技術そのものではなく、技術の自己構成、弾力性、自動回復などの特性です。

アーキテクチャ的には、抽象的なインフラストラクチャにより適切にマッピングされる、より軽量で、きめ細かく、最小限のステートフルなコンポーネントを作成するために、マイクロサービス原則が最もよく使用されます。適切な設計原則がなければ、当社のソリューションはプラットフォームのメリットを享受できません。たとえば、動的にスケーリングしたり、きめ細かい回復力を提供したり、高速なビルドとデプロイメントを提供したり、プラットフォーム上の他のアプリケーションと運用上の一貫性を維持したりすることはできません。

多くの場合、人やプロセスの変更はクラウド ネイティブから切り離されていると考えられていますが、実際には両者は密接に関連しており、定義的な特性の一部であると私たちは考えています。ソフトウェア開発ライフサイクルの自動化が不十分な場合、チームは日常的なタスクに多くの時間を費やす必要があり、ビジネス価値の提供に費やす時間が減ることになります。煩わしいトップダウンの組織およびガバナンス構造では、ビジネスにおける革新に必要な自律性をチームに提供できません。

したがって、クラウド ネイティブが実際に何を意味するのかをより具体的に定義した上で、次のステップに進み、前の図を拡張することができます。

上の図では、これらの側面の主要な要素に関する情報をいくつか提供しています。このシリーズの今後の記事では、クラウド ネイティブ ソリューションを構築する「方法」を検討し、人材とプロセスの問題から始めて、各要素を詳細に検討します。

しかし、クラウドネイティブの完全な導入は容易ではなく、企業の支援が必要であることはすでに明らかです。そこで、別の投稿では、クラウド ネイティブで成功するために必要な取り組みについて学んだことをまとめ、そもそもクラウド ネイティブに移行する「理由」と、どのようなメリットを実現したいのかをもう一度考えてみましょう。