クラウドネイティブテクノロジーとは何かについてお話ししましょう

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

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

https://ost..com

最近、コミュニティ内でクラウドネイティブとは何かを尋ねる人が多くいるのを目にします。幸いなことに、私はクラウドネイティブテクノロジーの初心者ユーザーです。現在使用しているクラウドネイティブテクノロジーには、マイクロサービス、Kubernetes、Docker、Istio、Serverless などがあります。今日はそれらについてお話ししましょう。

クラウドネイティブの起源

重要なゲスト

クラウドネイティブを紹介する前に、まずはクラウドネイティブ分野で最も影響力と権威のある組織とも言える重鎮ゲストのCNCFを紹介しましょう。

CNCF は Cloud Native Computing Foundation の正式名称で、2015 年 7 月 21 日に設立され、米国ポートランドで開催された OSCON 2015 で発表されました。当初のスローガンは、オープンソース技術を遵守し、統合して、マイクロサービスアーキテクチャの一部としてオーケストレーションされたコンテナを作成することでした。クラウドネイティブアプリケーションの推進と普及に尽力する重要な団体です。

CNCF の別のパノラマ写真は次のとおりです。

クラウドネイティブの定義

CNCFの定義

クラウドネイティブテクノロジーにより、組織はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの最新の動的環境でスケーラブルなアプリケーションを構築および実行できるようになります。コンテナ、サービスメッシュ、マイクロサービス、不変のインフラストラクチャ、宣言型 API などがこのアプローチの例です。
これらの技術により、回復力があり、管理しやすく、監視可能な疎結合システムが可能になります。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、影響の大きい変更を頻繁かつ予測どおりに行うことができます。
Cloud Native Computing Foundation は、オープンソースでベンダー中立なプロジェクトのエコシステムを育成し、維持することで、このパラダイムの採用を促進することを目指しています。私たちは最先端のパターンを民主化し、誰もがこれらのイノベーションを利用できるようにしています。
クラウドネイティブテクノロジーにより、組織はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。代表的なクラウドネイティブテクノロジーには、コンテナー、サービスメッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。これらの技術により、フォールトトレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブテクノロジーにより、エンジニアはシステムに頻繁かつ予測可能な重大な変更を加えることが容易になります。
Cloud Native Computing Foundation (CNCF) は、クラウドネイティブテクノロジーを促進するために、ベンダー中立のオープンソースエコシステムを育成および維持することに取り組んでいます。私たちは最先端のモデルを民主化することで、これらのイノベーションを大衆に利用できるようにします。
上記の内容は、CNCF Cloud Native Definition v1.0 - github.com から引用したものです。

重要な定義

クラウドネイティブが初めて推進された 2015 年、Matt Stine 氏は著書「Migrating to Cloud Native Architecture」の中で、クラウドネイティブアーキテクチャのいくつかの特徴 (12 の要素、マイクロサービス、セルフアジャイルアーキテクチャ、API ベースのコラボレーション、回復力) を定義しました。

2017 年、Matt Stine 氏は論調を変え、クラウドネイティブアーキテクチャの 6 つの特性 (モジュール性、可観測性、展開可能性、テスト可能性、置き換え可能性、処理可能性) をまとめました。 Pivotal の公式 Web サイトでは、クラウドネイティブを DevOps + 継続的デリバリー + マイクロサービス + コンテナという 4 つの主要ポイントにまとめています。

MattStine 氏は、クラウドネイティブは DevOps、継続的デリバリー、マイクロサービス、アジャイルインフラストラクチャ、コンウェイの法則などを含むアイデアの集合体であると考えています。

クラウドネイティブには、テクノロジー (マイクロサービス、アジャイルインフラストラクチャ) と管理 (DevOps、継続的デリバリー、コンウェイの法則、再編成など) の両方が含まれます。クラウド技術と企業経営手法の集合体ともいえます。

現時点では、CNCF の公式定義を標準として採用します。 CNCF の定義によると、クラウドネイティブの代表的なテクノロジには、コンテナー、サービスメッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。

クラウドネイティブの代表的な技術

マイクロサービス

マイクロサービスは、「マイクロ」とは何か、そして「サービス」とは何かという 2 つの側面から理解できます。

マイクロとは、狭義にはサイズが小さいことを意味します。

サービスはシステムと区別する必要があります。サービスは、比較的小規模で独立した機能単位の 1 つまたはグループであり、ユーザーが認識できる機能の最小セットです。

従来のモノリシックアーキテクチャは、システム全体として展開されます。一方、マイクロサービスは、独立したコンポーネント (ユーザーサービスや製品サービスなど) の単位として展開されます。

単一のアプリケーションでは、特定の業務の要求量が非常に大きいことがわかった場合、その業務のみを拡大することはできません。クラスターを実装するには、単一のアプリケーション全体をコピーし、別の環境をデプロイすることしかできません。マイクロサービスは、まさにモノリシックアプリケーションの欠陥のために誕生しました。近年人気が高まっている Docker は、マイクロサービスアーキテクチャに効果的なコンテナを提供します。

容器

オープンソースソリューションプロバイダーである Red Hat の公式 Web サイトに記載されているコンテナーの定義:

Linux® コンテナは、システムの他の部分から分離されたプロセスの集合です。

これらのプロセスを実行するために必要なすべてのファイルは別のイメージによって提供されるため、Linux コンテナーは移植可能であり、開発からテスト、本番環境まで一貫しています。

コンテナーはプロセスレベルの分離を提供し、オペレーティングシステムによって管理されるリソースを相互に分離されたグループに分割し、相互に分離されたグループ間のリソース使用の競合を解決できます。たとえば、アプリケーション APP 1 は Centos オペレーティングシステムでのみ実行できます。 APP2 は Ubuntu オペレーティングシステムでのみ実行できます。 APP1 と APP2 を同じオペレーティングシステム上で同時に実行すると、競合が発生します。コンテナ技術はまさにこのような問題を解決できます。現在主流のコンテナ技術には、Docker、LXD、RKT などがあります。

ドッカー

コンテナに関して言えば、Docker について話さなければなりません。

2010年、数人のひげを生やした若者が米国サンフランシスコで「dotCloud」という会社を設立しました。同社は主にPaaSベースのクラウドコンピューティング技術サービスを提供しています。具体的には、LXC に関連するコンテナ技術です。

LXC は、Linux コンテナ仮想化テクノロジー (Linux コンテナ) です。

その後、dotCloud はコンテナテクノロジーを簡素化および標準化し、Docker と名付けました。

Docker プロジェクトは、コンテナイメージを使用して、アプリケーションの実行に必要な完全な環境、つまりオペレーティングシステム全体のファイルシステムを直接パッケージ化します。

このアプローチは、長い間 PaaS ユーザーを悩ませてきた一貫性の問題に対する解決策と見なすことができます。「一度リリースすればどこでも実行できる」Docker イメージを作成することの重要性は、開発環境とテスト環境を統合することすらできない Buildpack を作成することよりもはるかに高いです。

Docker プロジェクトにより、コンテナテクノロジの使用のハードルが大幅に下がりました。軽量、ポータブル、仮想化されており、言語に依存しません。プログラムを作成したら、それをサーバーに投入し、どこにでも展開して実行できるイメージにします。開発・テスト・本番環境が完全に統合されており、リソース管理や仮想化も行えます。

オープンソースのアプリケーションコンテナエンジンである Docker は、開発者やシステム管理者が分散アプリケーションを構築、公開、実行できるように設計されたプラットフォームです。一般的な Docker プラットフォームには、Kubernetes、OpenShift V3、Flynn、Deis などがあります。

Docker を使用すると、開発者はさまざまなアプリケーションと依存パッケージをポータブル Docker コンテナにパッケージ化し、Docker コンテナをリソースのセグメンテーションとスケジューリングの基本単位として使用し、ソフトウェアランタイム環境全体をカプセル化して、Linux マシンに公開することができます。

クベネフィット

コンテナを使用する場合は、コンテナのライフサイクルを調整および管理する必要があります。ここで Kubernetes について言及する必要があります。

Kubernetes という単語はギリシャ語に由来し、操舵手または航海士を意味します。 K8s はその略称であり、「ubernete」の 8 つの文字を数字の「8」に置き換えたものです。 Kubernetes はまったく新しい発明ではありません。これは、Google が社内で使用していた Borg をベースに改良した汎用コンテナオーケストレーションスケジューラです。 2014 年 6 月にオープンソース化されました。

2015年にGoogleはLinux Foundation傘下のCloud Native Computing Foundation（CNCF）に寄贈し、KubernetesはCNCFの最初のプロジェクトとなりました。

CNCF でホストされている一連のプロジェクトは、クラウドネイティブアプリケーションのライフサイクル全体の管理に特化しており、デプロイメントプラットフォーム、ログ収集、サービスメッシュ、サービス検出、分散トレース、監視、セキュリティなど、さまざまな分野でオープンソースソフトウェアを通じて完全なソリューションセットを提供しています。

クラウドアプリケーションのデプロイメント標準として、Kubernetes はビジネスアプリケーションに直接向けられており、クラウドアプリケーションの移植性を大幅に向上させ、クラウドベンダーロックインの問題を解決し、クラウドアプリケーションをクラウド間でシームレスに移行し、ハイブリッドクラウドの管理にも使用できるため、エンタープライズ IT クラウドプラットフォームの新しい標準となっています。

サービスメッシュ

サービスメッシュとは、サービス間の通信を処理するために使用されるインフラストラクチャ層を指します。

これは、最初に Buoyant (Service Mesh プロジェクト Linkerd を開発した会社) によって提案され、社内で使用されました。同社は2016年9月29日に初めてこの用語を公に使用した。

サービスメッシュは通常、マイクロサービスアプリケーションの構成可能なインフラストラクチャ層に使用されます。 Istio (Google、IBM、Lyft がサポート) は、最もよく知られているサービスメッシュアーキテクチャです。

Docker や Kubernetes などのツールは「デプロイメントの問題を解決」しました。しかし、サービスメッシュの起源であるランタイムの問題はまだ解決されていません。 Service Mesh の登場により、マイクロサービスの接続、管理、監視における Kubernetes の欠点が補われ、Kubernetes のアプリケーションとサービスの管理が改善されました。

そのため、Service Meshの代表格であるIstioが登場すると、Kubernetesと連携して動作する強力なマイクロサービス管理ツールとして業界から高く評価されました。

不変のインフラストラクチャ

従来の可変サーバーインフラストラクチャでは、サーバーは継続的に更新および変更されます。このタイプのインフラストラクチャを使用するエンジニアと管理者は、SSH 経由でサーバーに接続し、パッケージを手動でアップグレードまたはダウングレードしたり、サーバーごとに構成ファイルを調整したり、新しいコードを既存のサーバーに直接展開したりできます。可変的なインフラストラクチャでは、災害が発生したときにサービスを再構築することが困難になることがよくあります。継続的な過度の手作業と記録の不足により、標準で初期化されたサーバーから同等のサービスを再構築することが困難になります。サービス操作中にサーバーを継続的に変更すると、プログラム内の可変変数の値が変更されることになり、一貫性のない状態の同時実行のリスクが発生します。サーバーにこれらの変更を加えると中間状態も導入され、予期しない問題が発生する可能性があります。

不変インフラストラクチャはプログラミングにおける不変の変数であり、割り当てが完了した後は変更できません。古いものを全体的に置き換えるには、新しいものだけを作成する必要があります。この特性により、この変数は並行環境で安全に使用できます。インフラストラクチャの最も基本的な不変性は、サービスを実行するサーバーがデプロイ後に変更されないことを意味します。メリットとしては、インフラストラクチャの一貫性と信頼性の向上、よりシンプルで予測可能な展開プロセスなどが挙げられます。構成ドリフトやスノーフレークサーバーなど、変更可能なインフラストラクチャでよく見られる問題を軽減または完全に防止できます。

宣言型API

宣言型 API では、システムが何をすべきかを宣言でき、システムはその状態に向かって進み続けます。「プロダクトマネージャー」と「開発」の間にはちょっとした関係があります。「製品マネージャー」は要件を提案する責任のみを負い、「開発」がそれをどのように実装するかについては気にしません。

要約すると:

Kubernetes はクラウドネイティブエコシステム全体の基礎であり、クラウドネイティブエコシステム全体は Kubernetes 上に構築されています。
コンテナは Kubernetes の基盤となるエンジンです。
Docker は最も広く使用されているコンテナツールです。
マイクロサービスは Docker に最適です。
サービスメッシュは、マイクロサービスの補助であり、k8s 上に構築されたリクエストベースのスケーリング機能です。
不変のインフラストラクチャは、現代の運用の基礎です。
宣言型 API は Kubernetes をコーディングする方法です。

クラウドネイティブの利点は何ですか?

一般的に、クラウドネイティブは、マイクロサービスの開発、テスト、展開、リリースのプロセス全体をオープンにすることができます。クラウドネイティブアーキテクチャでは、基盤となるサービスまたは API がクラウドに展開されます。これは、負担の大きい運用および保守作業をクラウドプラットフォームプロバイダーに移管することと同じですが、これはクラウドコンピューティングのインフラストラクチャが安価であることによるものです。私が個人的に考える次の 3 つの利点について詳しく説明します。

高速反復

クラウドネイティブアプリケーション開発を活用することで、デリバリーチームは反復的な自動化とオーケストレーションを使用して迅速に反復処理を実行できるようになり、開発者はビジネス開発にさらに集中できるようになります。

自動展開

クラウドネイティブアプローチは、ソフトウェア配信プロセスで開発環境やその他のさまざまな環境を構築するために多大な労力を必要とする従来の仮想化指向のビジネスプロセスよりもはるかに優れています。クラウドネイティブアーキテクチャは、自動化と構成の機能を備え、信頼性が高く、実証済みで、監査済みの既知の適切なプロセスを基盤としているため、繰り返しの手動介入を必要とせずに俊敏な結果を実現します。

独立性と効率性

クラウドネイティブはマイクロサービスアーキテクチャをもたらします。マイクロサービスとは、基本的に独立してリリースできるアプリケーションサービスです。したがって、大規模なアプリケーション全体への影響が少なく、アップグレードしたり、グレー表示したり、独立したコンポーネントとして再利用したりできます。各サービスは専用の組織によって個別に完了することができ、依存側は入力ポートと出力ポートを決定するだけで完全に開発できます。チーム全体の組織構造もより合理化されるため、コミュニケーションコストが低くなり、効率が高くなります。

結論として、クラウドネイティブは確かに多くの利便性をもたらしましたが、同時に、R&D および運用保守担当者への要求も高まりました。ますます複雑化するビジネス問題を解決するために、より適切なクラウドネイティブテクノロジーを選択する方法。