クラウドネイティブについて簡単に解説 - コンセプトからトレンドまで

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​

この記事を読んだら

• 非常に実用的なクラウド ネイティブ用語を学びます。
• クラウド ネイティブとは何かを理解します。
• クラウド ネイティブの重要な要素を理解します。
• 2022 年のクラウド ネイティブ トレンドに関する洞察。

クラウドは場所ではなく、IT を実行する方法です。

– デルテクノロジーズの創設者、マイケル・デル氏。

1. クラウド ネイティブとは何ですか?

クラウド ネイティブは、文字通りクラウド コンピューティングとネイティブ (クラウド コンピューティングのネイティブ) を意味します。

クラウドの観点から見ると、クラウドは安定したコンピューティングとストレージ リソースを提供するオブジェクトとして見ることができます。これを実現するために、クラウドは仮想化、柔軟な拡張、高可用性、高いフォールト トレランス、自己回復などの基本的な属性を提供します。

ネイティブをもう一度見てみると、クラウド ネイティブはクラウド上で実行される従来のアプリケーションとは異なります。従来のアプリケーションの中には、SOA (サービス指向アーキテクチャ) アーキテクチャに基づいて構築され、クラウド上に配置されるものもあります。これらの従来のアプリケーションでは、クラウドの利点を十分に活用できません。

クラウドは分散アーキテクチャであるため、そのネイティブの居住者もこの機能に準拠する必要があります。よく言われるように、ローカル環境と気候がローカルの人々を決定します。ローカル環境と気候が適切でない場合は、非常に悪いことになります。マイクロサービスには分散設計の属性があります。

第二に、PaaS（Platform as a Service）として、クラウドネイティブのライフサイクル全体をクラウドの概念に基づいて実装する必要があるため、これを実現するには自動化された開発プロセスが必要です。

これらは、クラウド ネイティブの文字通りの解体です。 Cloud Native Computing Foundation (CNCF) が提供する公式定義を見てみましょう。

クラウド ネイティブ テクノロジーにより、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの最新の動的環境でスケーラブルなアプリケーションを構築および実行できるようになります。コンテナ、サービス メッシュ、マイクロサービス、不変のインフラストラクチャ、宣言型 API などがこのアプローチの例です。

これらの技術により、回復力があり、管理しやすく、監視可能な疎結合システムが可能になります。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、影響の大きい変更を頻繁かつ予測どおりに行うことができます。

公式の定義によると、クラウド ネイティブとは次のとおりです。

• コンテナ、サービス メッシュ、マイクロサービス、不変のインフラストラクチャ、宣言型 API 上に構築された、弾力的にスケーラブルなアプリケーション。
• 耐障害性が高く、管理と監視が容易な自動化テクノロジーに基づいた疎結合システムを構築します。
• クラウド ベンダーが提供するサービスから切り離すことができる、統合されたオープン ソース クラウド テクノロジー エコシステムを構築します。

クラウド ネイティブはスピードと俊敏性が重要です。企業のビジネスシステムは、ビジネス能力を実現するためのツールから、ビジネスのスピードと成長を加速するための戦略的変革の武器へと進化しています。

同時に、ユーザーの要求が高まるにつれて、ビジネス システムはますます複雑になっています。顧客は、迅速な応答性、革新的な機能、ダウンタイムゼロを期待しています。

パフォーマンスの問題、繰り返し発生するバグ、迅速な反復処理ができないといった問題は、もはや許容されません。このような状況が発生すると、ユーザーは競合他社を訪問することになります。

2. クラウドネイティブの重要な要素

クラウド ネイティブのスピードと俊敏性は、さまざまな要因から生まれます。

この章では、最も重要な 6 つの要素について説明します。

（１）クラウドインフラ

クラウド ネイティブ システムは、クラウド サービス モデルを最大限に活用します。これらのシステムは、動的な仮想化クラウド環境で動作するように設計されています。彼らは、PaaS コンピューティング インフラストラクチャと管理サービスを広範に活用しています。基盤となるインフラストラクチャは使い捨てとして扱われ、数分でプロビジョニングされ、自動化によってオンデマンドでサイズ変更、拡張、または破棄されます。

クラウド ネイティブの分野では、「Pets vs. Cattle」と呼ばれる類推概念があります。これは文字通り、ペットと牛を意味します。

ペット

従来のデータ センターでは、サーバーはペットのように扱われます。つまり、意味のある名前が付けられ、ユーザーが管理する物理マシンです。同じマシンにリソースを追加することでスケールします。サーバーが病気になった場合は、正常な状態に戻す必要があります。

このモデルでは、サーバーは決してダウンすることのない重要なシステム コンポーネントと見なされます。一般的に言えば、それらは手動で作成、管理され、手動で「供給」されます。例としては、メインフレーム、スタンドアロン サーバー、HA (高可用性) ロード バランサー/ファイアウォール、マスター/スレーブ データベース システムなどが挙げられます。

牛

Cattle のサービス モデルは異なります。各インスタンスを仮想マシンまたはコンテナとして構成します。これらは同一であり、システム識別子が割り当てられます。インスタンスをさらに作成することでスケールします。インスタンスが利用できなくなっても、誰も気づきません。

Cattle のモデルは不変のインフラストラクチャを使用します。サーバーは修理または変更されません。サーバーに障害が発生したり、更新が必要になったりした場合は、サーバーが破棄され、新しいサーバーがプロビジョニングされます。この作業はすべて自動化によって行われます。

2 台以上のサーバーで構成されるアレイ。通常は自動化ツールを使用して構築され、どのサーバーも置き換え不可能ではありません。通常、アレイは障害が発生したサーバーを再起動するか、トリプルレプリケーションや消去コーディングなどの戦略を通じてデータを複製することによって「障害を回避する」特性を示すため、障害イベントでは人間の介入は必要ありません。

この例には、ネットワーク サーバーの配列、Cassandra クラスターなどのマルチマスター データ ストア、および負荷分散とマルチマスターが行われたほぼすべてのものが含まれます。

（２）モダンデザイン

クラウドネイティブアプリケーションをどのように設計しますか?あなたの建築はどのようなものになるでしょうか?どのような原則、パターン、ベストプラクティスに従いますか?重要なインフラストラクチャと運用上の問題は何ですか?

12の要素

クラウド アプリケーションを構築するにはどうすればよいでしょうか?業界で広く受け入れられている原則は 12 の要素です。

12 の要素は、クラウド ネイティブ アプリケーション アーキテクチャのパターンのコレクションです。これらのパターンは、どのようなアプリケーションがクラウド ネイティブ アプリケーションであるかを示すために使用でき、バックエンド サービスがクラウドに適しているかどうかを測定するために使用できます。

このセクションの反例は、テクノロジ自体が十分ではないことを意味するのではなく、ネイティブ機能の一部が複雑なアプリケーションの開発に十分対応していないことを意味します。

CodeBase - ベースラインコード

リビジョン管理で追跡される 1 つのコードベース、多数のデプロイ。

ベースライン コードは複数のコピーで展開し、バージョン管理を通じて追跡できます。

反例:複数の無関係なプロジェクトと数百万行のコードがすべて 1 つのウェアハウスに配置されます。異なる要件に応じて、プロジェクト倉庫を直接コピーして個別に開発し、複数の倉庫コードを同時に管理します。

依存関係 - 明示的かつ分離された依存関係

依存関係を明示的に宣言して分離します。

各マイクロサービスは依存関係を明示的に宣言し、相互に干渉することなく、システム全体に影響を与えることなく変更を受け入れることができます。

反例: Node.js の父である Ryan Dahl は、ゼロから始めて Deno を作成しました。 Deno のインポート リモート コードは、Node の世界では npm とは正反対であり、暗黙的な依存関係が生じます。 Golang も、1.13 より前に go モジュールがなかったときにこの原則に違反していました。言うまでもなく、サードパーティの依存関係が不明確だと簡単に「ポイズニング」につながり、コードの問題の特定、メンテナンス、引き継ぎに大きな負担がかかります。

構成 - 環境に合わせた構成の分離

環境内に構成を保存します。

構成データとビルド製品は完全に分離されており、構成データは個別に管理され、実行環境にのみ表示されます。

反例:環境関連の構成がコンテナ イメージやコード パッケージに混在しており、各環境を個別に構築してパッケージ化する必要があります。この方法は従来の開発モデルでは一般的です。

バックエンドサービス - 個別のバックエンドサービス

バックアップ サービスを添付リソースとして扱います。

バックエンド サービスを追加のリソースとして扱います。バックエンド サービスとは、データベース、キャッシュ、メッセージ キューなど、ネットワーク経由で呼び出され、プログラムの動作に必要なさまざまなサービスを指します。

反例:キャッシュ サービスとアプリケーション サービスを同じコンテナー イメージにパッケージ化し、/var/redis.sock などのドメイン ソケットを介してアクセスします。または、サードパーティ アプリケーション サービスのソース コードを独自のコードに直接コピーし、1 つのプロセスで相互に呼び出します。

ビルド、リリース、実行 - ビルド、リリース、実行を分ける

ビルド段階と実行段階を厳密に分離します。

各バージョンでは、ビルド、リリース、実行の各フェーズが厳密に分離されている必要があります。各バージョンには一意の ID が付けられ、ロールバック機能がサポートされている必要があります。 CI/CD システムは、この原則を実装するのに役立ちます。

反例:開発者がコードを変更した後、ローカルでパッチを作成し、運用および保守スタッフに送信します。彼は、変更内容を製品管理者に伝えるのではなく、特定のファイルを一括で置き換えるよう、運用保守担当者に直接口頭で指示します。

プロセス - ステートレス サービス プロセス

アプリを 1 つ以上のステートレス プロセスとして実行します。

各マイクロサービスは、実行中の他のサービスから分離された独自のプロセスで実行する必要があります。状態がある場合は、データベース、キャッシュなどのバックエンド サービスに外部化する必要があります。

反例:アプリケーション サービスの複数のインスタンスが相互に通信し、一部のメモリ データを共有します。または、自律的なクラスターリーダー選出、タスク分散などの機能を開発します。

ポートバインディング

ポート バインディングを介してサービスをエクスポートします。

各マイクロサービスは独立しており、インターフェースと機能は独自のポート上で公開される必要があります。そうすることで、他のマイクロサービスからの分離が実現します。

反例:展開用に提供されるパッケージは、Tomcat に配置された war ファイルと IIS に配置された dll ファイルです。通信プロトコル自体を記述するものではなく、バインディング ポートを指定するものでもありません。これは Tomcat/IIS の構成に完全に依存します。

同時実行性

プロセス モデルを介してスケール アウトします。

これはプロセス モデルを通じて拡張され、拡張にはプロセスとスレッドの 2 つの方法があります。プロセス アプローチにより、スケーラビリティが向上し、アーキテクチャが簡素化され、分離性が向上します。スレッド拡張によりプログラミングはより複雑になりますが、リソース効率は向上します。

反例:セッションをメモリに格納します。

使い捨て - 高速起動と正常な終了

高速起動と正常なシャットダウンにより堅牢性を最大限に高めます。

高速起動と正常な終了により、堅牢性を最大限に高めることができます。高速起動と正常な終了が実現された場合にのみ、サービスはより堅牢になります。

反例:負荷の高い Java サービスの起動には 10 分以上かかります。スケールダウンは、プロセスを強制終了するために kill -9 に依存します。サービスは、SIGTERM シグナルを受信して​​も「レームダック状態」にならず、プロセスをシャットダウンする前に要求が処理されるのを待つこともありません。

開発/本番環境の整合性

開発、ステージング、本番環境を可能な限り同じ状態に保ちます。

開発環境、プレリリース環境、オンライン環境など、アプリケーションのライフサイクル全体にわたって環境を可能な限り同じに保ちます。

反例:開発環境はコンテナ化されていませんが、生産ラインはコンテナ化されています。開発環境ではMariaDBが使用され、生産ラインではMySQLが使用されます。開発環境のデータベースにはマスターとスレーブの関係はありませんが、生産ラインはマスターとスレーブの同期で構成されています。このように、MySQL の読み取りと書き込みが分離されている場合、マスターとスレーブの同期における数ミリ秒の遅延により、開発環境では決して再現されない可能性のあるさまざまな奇妙なバグが発生します。

ログ - イベント ストリームとしてログに記録

ログをイベント ストリームとして扱います。

マイクロサービスによって生成されたログをイベント ストリームとして扱います。マイクロサービス アーキテクチャにおけるサービスの数が爆発的に増加しているため、呼び出しチェーンを分析して障害を迅速に特定する機能が必要です。

反例:ログ ファイルが保存されるパス、ログ ファイルのローテーション頻度、ログ ファイルが削除されるまでの保持期間など、多くの複雑な log4xx 構成がプロジェクトに書き込まれます。これは従来のソフトウェアでは必須ですが、クラウドネイティブ アプリケーションの場合は、標準出力/標準エラーへの印刷のみにしてください。アンチパターンのもう 1 つの例は、アプリケーション内のコードを通じて Kafka などのブローカーにログをスローすることです。これにより、アプリケーション サービスと Kafka が目に見えない形で結合されます。

多くの人は、クラウド ネイティブの世界におけるさまざまなログ収集および処理コンポーネントの威力を理解していないため、ログを stdout/stderr に出力するだけでは十分ではないと考えています。私たちは伝統的な慣習に慣れており、「単一責任の原則」を忘れています。

管理プロセス - 管理タスクを分離

管理タスクを 1 回限りのプロセスとして実行します。

バックグラウンド管理タスクを 1 回限りのプロセスとして実行します。運用環境での一部のツール操作は 1 回限りである可能性があるため、ローカルではなく運用環境で実行することが最適です。

反例:アプリケーション サービスの実行環境にデータベース クライアントをインストールし、運用および保守担当者が手動で一連の SQL を実行してデータベースを変更します。または、いくつかの操作および保守スクリプトをインストールし、それらをマシンの cron テーブルに配置して、いくつかのスクリプトを定期的に実行します。

3. マイクロサービス

（1）マイクロサービスとは何か？

マイクロサービスアーキテクチャとは、小さなサービスのグループを開発することで、独立したアプリケーションシステムを開発することです。各サービスは独立したプロセスとして実行され、他のサービスとの軽量な (通常は HTTP API) 通信メカニズムを使用します。

これらのサービスはビジネス機能を中心に構築されており、完全に自動化されたデプロイメント メカニズムを通じて個別にデプロイできます。これらのサービスは最小限の集中管理機能 (Docker など) を使用し、さまざまなプログラミング言語やデータベースを使用することもできます。

マイクロサービスの粒度をどのように決定するか、つまり「マイクロ」という言葉をどのように定義するか?

この質問に対する正しい答えはビジネスや組織の状況によって異なるため、コンセンサスはありません。

サービスを小さくしすぎると、実行時のオーバーヘッドと運用の複雑さがマイクロサービスの利点を上回ってしまうため、悪い習慣と見なされます。サービスが細分化されすぎると、機能をライブラリにパッケージ化したり、機能を他のマイクロサービスに移動したりするなど、他のアプローチを検討する必要があります。

したがって、マイクロサービスの「マイクロ」は単に「小さい」という意味ではなく、「適切」という意味で理解できます。

（２）マイクロサービスの利点

1. クラウドネイティブ システムにはマイクロサービスが含まれており、次のような利点があります。
2. 構成サービスは規模が小さいため、サービス境界が明確に定義された 1 つ以上の小規模チームによって最初から構築できます。これにより、必要に応じて開発作業を拡大しやすくなります。
3. これらのサービスは開発後、個別にデプロイできるため、人気のあるサービスを簡単に識別し、アプリケーション全体とは独立して拡張できます。
4. マイクロサービスは、障害の分離も改善します。 1 つのサービスに障害が発生しても、必ずしもアプリケーション全体の機能が停止するわけではありません。バグが修正されたら、アプリケーション全体を再デプロイするのではなく、対応するサービスだけをデプロイできます。
5. マイクロサービス アーキテクチャに伴うもう 1 つの利点は、より標準化された、画一的なアプローチを採用する必要がなく、必要な機能に最適なテクノロジー スタック (プログラミング言語、データベースなど) を簡単に選択できることです。

次の表は、モノリシック アーキテクチャとマイクロサービス アーキテクチャの比較を示しています。

（３）マイクロサービスのデメリット

全ての物事には二つの側面がある。マイクロサービスには多くの利点がありますが、マイクロサービスの使用によってもたらされる課題にも対処する必要があります。

複雑

まず、サービス間の通信が複雑になる可能性があります。アプリケーションは、すべてが安全に通信する必要がある数十または数百の異なるサービスで構成されている場合があります。

第二に、マイクロサービスのデバッグはより困難になります。アプリケーションが複数のマイクロサービスで構成され、それぞれに独自のログがある場合、問題の原因を追跡することが困難になる可能性があります。

最後に、マイクロサービスの設計、開発、展開、テストはより複雑になります。

インターフェース制御

各マイクロサービスには独自の API があり、アプリケーションは一貫性を保つためにそれに依存します。マイクロサービスとやり取りする外部システムに影響を与えることなく、マイクロサービスに簡単に変更を加えることができますが、API (インターフェース) を変更すると、その変更に下位互換性がない場合、マイクロサービスを使用するすべてのアプリケーションが影響を受けます。

マイクロサービス アーキテクチャ モデルでは、企業の運用に不可欠な多数の API が生成されます。したがって、インターフェース制御が重要になります。

コスト上昇

企業内でマイクロサービス アーキテクチャを機能させるには、セキュリティとメンテナンスのサポートを備えた適切なホスティング インフラストラクチャが必要であり、また、すべてのサービスを理解して管理できる熟練した開発チームも必要です。

すでにこれらのものをお持ちの場合は、マイクロサービスへの移行にかかるコストが低くなる可能性があります。しかし、現在モノリシック アーキテクチャを実行しているほとんどの企業は、移行するために新しいインフラストラクチャと開発者リソースに投資する必要があります。

4. コンテナ

（１）コンテナとは何か？

コンテナはクラウドネイティブ ソフトウェアを実現するのに最適です。

Cloud Native Patterns の著者である Cornelia Davis 氏は、「コンテナーはクラウド ネイティブを実現する優れた手段です」と述べています。

Cloud Native Computing Foundation は、企業がクラウド ネイティブ ブループリントを実現するための最初のステップとして、マイクロサービス コンテナ化も使用しています。

コンテナはオペレーティング システムの仮想化の一種です。単一のコンテナを使用して、小さなマイクロサービスやソフトウェア プロセスから大規模なアプリケーションまで、あらゆるものを実行できます。

コンテナには、必要なすべての実行可能ファイル、バイナリ、ライブラリ、および構成ファイルが含まれています。ただし、サーバーやコンピューターの仮想化アプローチとは異なり、コンテナーにはオペレーティング システム イメージが含まれません。したがって、オーバーヘッドが少なく、より軽量で持ち運びが容易です。

マイクロサービスをコンテナ化するのは難しくありません。ソフトウェア コードと必要なすべてのコンポーネント (ライブラリ、フレームワーク、その他の依存関係など) を 1 つのバイナリ ファイル (コンテナー イメージ) にパッケージ化するだけです。イメージはコンテナ レジストリに保存されます。コンテナ レジストリは、コンピューター、データ センター、またはパブリック クラウド上に配置できます。

アプリケーションが起動またはスケーリングされると、コンテナ イメージが実行中のコンテナ インスタンスに変換されます。インスタンスは、コンテナ ランタイムがインストールされている任意のコンピューター上で実行されます。コンテナ化されたサービスのインスタンスをいくつ必要とするか決定できます。

次の図は、それぞれ独自のコンテナー内にある 3 つの異なるマイクロサービスがすべて同じホスト上で実行されていることを示しています。

形。容器

各コンテナは独自の依存関係とランタイムのセットを維持しており、それらは互いに異なる場合があります。図から、異なるバージョンの製品マイクロサービスが同じホスト上で実行されていることがわかります。

各コンテナはホスト オペレーティング システム、メモリ、プロセッサを共有しますが、互いに分離されています。これは、上記の 12 の要因の依存原則の良い例です。

（２）コンテナの利点

軽量で持ち運びに便利

コンテナ内で実行されるアプリケーションは、複数の異なるオペレーティング システムやハードウェア プラットフォームに簡単にデプロイできます。ホストのオペレーティング システム カーネルを共有できるため、コンテナーごとに個別のオペレーティング システムを用意する必要がなくなり、アプリケーションは仮想マシン (VM) でも、任意のインフラストラクチャ (ベア メタル、クラウド) で同じオペレーティング システムを実行できるようになります。

コスト削減

コンテナーにはオペレーティング システム イメージが含まれていないため、従来の仮想マシン環境やハードウェア仮想マシン環境よりも必要なシステム リソースが少なくなります。

アプリケーション開発の改善

開発者は、あるホスト環境でコンテナを操作するときに、別のホスト環境で使用するのと同じツールを使用できるため、オペレーティング システム間でコンテナ化されたアプリケーションの開発と展開が容易になります。また、コンテナはアジャイル DevOps 作業をサポートし、開発とテストを加速し、生産サイクルを短縮します。

コンテナとVM

仮想マシン (VM) は、物理ハードウェア システム (外部または内部に配置) 上に作成される仮想環境であり、仮想コンピュータ システムとして機能し、CPU、メモリ、ネットワーク インターフェイス、ストレージなどのハードウェアの完全なセットをシミュレートします。

コンテナ化と仮想化は、どちらもアプリケーションを完全に分離して複数の環境で実行できるようにするという点で似ています。それらの主な違いはサイズと携帯性です。

仮想マシンは 2 つのうち大きい方で、通常はギガバイト単位で測定され、独自のオペレーティング システムを備えているため、リソースを大量に消費する複数の機能を同時に実行できます。仮想マシンでは利用できるリソースが大幅に増加しているため、サーバー、オペレーティング システム、デスクトップ、データベース、ネットワーク全体を抽象化、分離、複製、エミュレートできます。

コンテナははるかに小さく、通常はメガバイト単位で測定され、アプリケーションとそれが実行される環境のみが含まれます。

仮想マシンは従来のモノリシック IT アーキテクチャと高い互換性があり、コンテナはクラウド、CI/CD (継続的デリバリー)、DevOps などの新しい新興テクノロジーと互換性があります。

コンテナの特性により、コンテナ内のマイクロサービスはコンテナの移植性、互換性、スケーラビリティをすべて備えているため、マイクロサービスとコンテナはうまく連携できます。

（3）コンテナオーケストレーション

Docker などのツールはイメージを作成してコンテナを実行できますが、それらを管理するためのツールも必要です。コンテナ オーケストレーション ツールを使用して、コンテナの展開、管理、拡張、ネットワーク化を完了できます。コンテナ オーケストレーションは、数百または数千のコンテナとホストを展開および管理する必要がある企業に利便性を提供します。

では、コンテナ オーケストレーションは具体的に何を行うのでしょうか?

• スケジュール - タスクのスケジュール。

コンテナ インスタンスを自動的に提供します。

• アフィニティ/アンチアフィニティ-アフィニティ/アンチアフィニティ。
• ヘルスモニタリング - ヘルス検出。

障害を自動的に検出して修正します。

• フェイルオーバー、フェイルオーバー。

障害が発生したインスタンスを正常なマシンに自動的にリセットします。

• スケーリング - 自動スケーリング。

需要に応じてコンテナ インスタンスを自動的に追加または削除します。

• ネットワーキング-ネットワーキング。

コンテナ通信に使用されるネットワーク層を管理します。

• サービス検出 - サービス検出。

コンテナを相互に相対的に配置できるようにします。

• ローリング アップグレード - ローリング アップデート。

ダウンタイムゼロの展開のために増分アップグレードを調整し、問題のある更新を自動的にロールバックします。

コンテナ オーケストレーションは、12 の要素の扱いやすさの原則と同時実行性の原則を体現していることがわかります。

5. バックアップサービス

形。バックエンドサービス

動作中にネットワーク経由でアプリによって消費されるすべてのサービスは、バックエンド サービスと呼ばれます。従来のオペレーティング システムでは、これらのサービスには、ネットワーク経由、UNIX ソケット経由、またはサブプロセスとしてアクセスできます。例としては、以下のものが含まれますが、これらに限定されません。

• データベース (MySQL、PostgreSQL)。
• メッセージ キュー (Kafka、RabbitMQ)。
• ファイルストレージ（NFS、FTP）。
• ログサービス。
• キャッシュシステム。
• SMTP サービス。

独自のバックエンド サービスを管理することも、クラウド プロバイダーに管理してもらうこともできます。クラウド ベンダーは、所有する必要はなく、直接利用できる豊富なバックエンド サービスを提供します。

クラウドベンダーは大規模なリソースを運用し、パフォーマンス、セキュリティ、メンテナンスの責任を負います。クラウドネイティブ システムは、クラウド ベンダーが提供するバックエンド サービスに依存する傾向があります。この点で、多くの時間と労力を節約できます。自分でホストする場合、発生する運用上のリスクはさらに厄介なものになります。

ベストプラクティスは、バックエンド サービスをマイクロサービスに動的にバインドされる追加リソースとして扱い、構成情報は外部構成に保存することです。この原則は上記の 12 の要素で説明されています。

12 の要素のうちの要素 4 では、バックエンド サービスは URL を通じて公開されるべきであり、これによりリソースがアプリケーションから切り離され、交換可能になると述べています。

要因 3 では、構成情報をマイクロサービスから移動し、コード外部の構成管理ツールを通じて外部化する必要があることが規定されています。

バックエンド サービスも 12 の要素に「ステートレス サービス プロセス」の原則を取り入れ、依存するサービスを分離します。一部のアプリケーション サービスではすでに「ステートレス」を実現できます。

ただし、ステートレス性を実現するために、内部アプリケーションに何らかの変更を加える必要がある場合もあります。ステートレス性は水平拡張の前提条件であり、サーバーレス アプリケーションではさらに必要になります。

6. 自動化

ご覧のとおり、クラウド ネイティブでは、マイクロサービスとコンテナ化を使用して、スピードと俊敏性を実現します。しかし、それだけでは十分ではありません。これらのシステムが実行されるクラウド環境をどのように構成しますか?アプリケーションに機能や更新を迅速に展開するにはどうすればよいでしょうか?

まず、IaC (Infrastructure as Code) の概念を理解しましょう。

Infrastructure as Code (IaC) とは、手動のプロセスではなくコードを通じてインフラストラクチャを管理および構成することを指します。 「プログラム可能なインフラストラクチャ」と呼ばれることもある IaC を使用すると、インフラストラクチャの構成を完全にソフトウェア プログラミングとして実行できます。

IaC は、データセンター内の物理ハードウェアから仮想化、コンテナー、クラウド コンピューティングへのインフラストラクチャ管理の移行を支援します。 IaC では、ネットワーク、仮想マシン、ロード バランサ、接続トポロジがすべて高級言語を使用してコーディングされ、アプリケーション開発が依存する環境が標準化されます。

一度コーディングすれば、DevOps は変動する需要に応じてインフラストラクチャを起動、解体、拡張できます。この俊敏性により、ソフトウェアの開発、テスト、展開がより迅速かつ容易になります。

（１）インフラ自動化

特定のツール (Azure Bicep など) を使用して、必要なクラウド インフラストラクチャを宣言的に記述できます。リソースの名前、場所、容量はパラメーター化され、動的になります。作成したスクリプトはバージョン管理されます。このスクリプトを呼び出すことで、さまざまなシステム環境で一貫性があり繰り返し可能なインフラストラクチャを構成できます。

副作用を引き起こすことなく、同じスクリプトを繰り返し実行できます。チームがアセットを更新したい場合は、スクリプトを編集して再実行できます。

記事「コードとしてのインフラストラクチャとは」で、著者の Sam Guckenheimer は次のように説明しています。「IaC を実装するチームは、安定した環境を迅速かつ大規模に提供できます。手動で環境を構成する必要がなくなり、コードを使用して理想的な環境の一貫性が確保されます。IaC を使用したインフラストラクチャの展開は繰り返し可能で、構成のずれや依存関係の欠落によって発生する運用上の問題を防ぎます。DevOps チームは、統一された一連のプラクティスとツールを使用して、アプリケーションとそれをサポートするインフラストラクチャを迅速かつ確実に大規模に提供できます。」

（２）導入の自動化

前の 12 の要因のうちの要因 5 では、ビルド、リリース、実行の各段階で各バージョンを厳密に分離する必要があると述べられています。各バージョンには一意の ID が付けられ、ロールバック機能がサポートされている必要があります。

「ビルド、リリース、実行」の 3 つの段階を分離する必要があることを強調するのはなぜでしょうか?

利点は2つあります。

責任と関心の分離。開発およびテスト担当者は構築を重視し、製品マネージャーはリリースを重視し、運用および保守担当者は運用を重視します。

組立ライン モデルでは、各段階に専用のツールと方法論が備わっており、効率性が向上し、段階間にバッファ スペースが確保されます。

これら 3 つの段階の分離をどのように実現するのでしょうか?組立ラインの稼働は人力だけでは保証されないため、自動化システムが非常に重要です。

CI/CD システムは、この原則を実装するのに役立ちます。独立したビルドおよび配信手順を提供し、ユーザーがすぐに利用できる一貫性のある高品質のコードを確保するのに役立ちます。

1. 開発者は、開発環境で、コードの「内部ループ」を繰り返し実行し、デバッグしながら機能を開発します。
2. 完了すると、コードは GitHub や BitBucket などのコード リポジトリにプッシュされます。
3. その後、CI はアプリケーションを自動的にビルド、テスト、パッケージ化します。
4. リリース フェーズでは、CD システムはパッケージ化されたデータ、外部アプリケーション、および環境構成情報を不変のバージョンに結合します。リリースは指定された環境にデプロイされます。各バージョンは識別可能である必要があります。
5. 最後に、リリースされた機能が本番環境で実行されます。

これらのテクノロジーを使用することで、企業はソフトウェアのリリース方法を根本的に変えました。多くの企業は四半期ごとのリリースからオンデマンドのアップデートに移行しています。

以上がクラウドネイティブの6つの重要な要素です。 2022年のクラウドネイティブの新しいトレンドを見てみましょう。

3. クラウドネイティブのトレンド

過去数年間、IT 業界ではクラウドネイティブ テクノロジーが急激に成長してきました。 2022 年に向けて、注目すべき 5 つの主要なクラウド ネイティブ トレンドをご紹介します。

1. クラウドネイティブ環境におけるWebAssemblyの台頭

WebAssembly は、クラウドネイティブ ソフトウェアのコンポーネントに使用できる、高性能、クロスプラットフォーム、多言語のソフトウェア サンドボックス環境へと進化しました。コンテナ ランタイムと WebAssembly (WASM) の間には驚くべき類似点があるため、Kubernetes を使用して WASM コンポーネントをオーケストレーションできます。

WasmCloud、WasmEdge、KubeEdge、Krustlet などのプロジェクトにより、WASM はクラウド ネイティブの世界の第一級の存在になっています。

WebAssembly としてパッケージ化されたソフトウェアをコンテナ化されたソフトウェアと一緒に実行することは可能です。 Kubernetes はこれら 2 つのコンポーネントをシームレスに調整できます。

2. クラウドネイティブセキュリティ

サイバーセキュリティの重要性が増すにつれ、クラウドネイティブセキュリティも2022年にさらに注目されるようになるでしょう。

今後さらに注目される分野は、ソフトウェアサプライチェーンとeBPF（Extended Berkeley Packet Filter）の2つです。

ソフトウェアサプライチェーン

ソフトウェアのサプライ チェーンは、現実世界のビジネス サプライ チェーンに似ています。リソースは消費され、一連のステップとプロセスを経て変換され、最終的に顧客に提供されます。

現代のソフトウェア開発は、パブリック ドメインのさまざまなコンポーネントをオープン ソース プロジェクトとして組み立て、統合することから構成されます。複雑なソフトウェア サプライ チェーンでは、1 つのソフトウェアが侵害されると、複数の展開に重大な損害が発生する可能性があります。したがって、ソフトウェア サプライ チェーンのセキュリティを確保することが不可欠です。

電子BPF

もう 1 つのエキサイティングなトレンドは eBPF です。これにより、クラウド ネイティブ開発者は安全なネットワーク、サービス メッシュ、および可観測性コンポーネントを構築できるようになります。

3. Kubevirtが主流に

Kubevirt は、Kubernetes がコンテナのように仮想マシンをオーケストレーションできるようにするオープンソース プロジェクトです。

仮想マシンとコンテナを実行することにより、従来のワークロードをマイクロサービスベースのアプリケーションと簡単に統合できます。

2022年には、KubevirtとKubernetesのアプリケーション統合が急激に増加します。

4。Gitopsは、継続的な展開の標準になります

Gitopsは、おなじみのGitベースのワークフローをもたらし、クラウドネイティブワークロードの管理をリリースします。 Gitを単一の真実の源として使用して、状態を制御するために、迅速にロールバックする能力と相まって、Gitopsを強力なメカニズムにします。

2022年には、Gitopsがマルチテナントとマルチクラスターの展開をサポートするために進化し、数万のKubernetesクラスターを簡単に管理できます。おそらく、Gitopsは継続的な展開のゴールドスタンダードになるでしょう。

5。ハイブリッドおよびマルチクラウドアーキテクチャ

ハイブリッドクラウドサービスは、すべての関係者の利点を組み合わせることができます。迅速かつ頻繁にアクセスする必要があるデータは、パブリックサーバーに維持できますが、監視されたアクセスを備えたプライベートサーバーには、より機密のデータを保持できます。よく統合されたバランスの取れたハイブリッドクラウド戦略は、両方の世界の最高を企業にもたらします。

マルチクラウドモデルは、個々のアプリケーション環境、ビジネス要件、可用性のニーズに最適なさまざまなクラウド製品を選択するのに役立ちます。今後、より多くの企業が、特定のクラウドベンダーへのアーキテクチャに依存することはほとんどなく、完全にクラウドネイティブアプリケーションを開発する必要があります。

多くの大企業はすでにハイブリッドとマルチクラウドの戦略を標準として採用していますが、2022年には、より多くの企業がこれらのモデルの利点を認識し、クラウドの弾力性と俊敏性を享受するためにそれらを受け入れます。

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​.