注目すべきオープンソースクラウドネイティブプロジェクト 9 つ

コンテナを使用してアプリケーションを開発する慣行が普及するにつれて、クラウドネイティブアプリケーションも増加しています。クラウドネイティブアプリケーションは次のように定義されます。

「クラウドネイティブテクノロジーは、コンテナにパッケージ化されたサービスを使用して構築され、マイクロサービスとしてデプロイされ、アジャイル DevOps プロセスと継続的デリバリーワークフローを通じて柔軟なインフラストラクチャ上で管理されるアプリケーションの開発に使用されます。」

この定義では、クラウドネイティブアプリケーションを構成する 4 つの不可欠な要素について言及しています。

容器
マイクロサービス
デブオプス
継続的インテグレーションと継続的デリバリー (CI/CD)

これらのテクノロジーはそれぞれ独自の歴史を持っていますが、相互に補完し合い、短期間でクラウドネイティブのアプリケーションとツールが驚異的な勢いで成長することを可能にしました。この Cloud Native Computing Foundation (CNCF) のインフォグラフィックは、今日のクラウドネイティブアプリケーションエコシステムの規模と幅広さを示しています。

クラウドネイティブコンピューティング財団プロジェクト

とにかく待って見てください！と言いたいです。これはほんの始まりに過ぎません。 NodeJS の出現が数え切れないほどの JavaScript ツールの爆発的な成長を引き起こしたのと同様に、コンテナテクノロジの人気もクラウドネイティブアプリケーションの急激な成長を促進しました。

幸いなことに、これらのテクノロジーを規制し、相互に接続する責任を負う組織が複数存在します。その 1 つが Open Containers Initiative (OCI) です。これは、Linux Foundation の支援のもとで「オープンな業界標準のコンテナ形式とランタイムを作成することを明確な目的として設立された」軽量のオープンガバナンス機関 (またはプロジェクト) です。もう 1 つは CNCF です。これは、「クラウドネイティブコンピューティングをユビキタスかつ持続可能なものにすることに特化したオープンソースソフトウェア財団」です。

CNCF は、クラウドネイティブアプリケーション全般に関するコミュニティの構築に加えて、プロジェクトがクラウドネイティブアプリケーションに関する構造化された管理を確立するのを支援します。 CNCF は、成熟度レベル (サンドボックス、インキュベーション、または段階的) の概念を作成しました。これは、下の図の「イノベーター」、「アーリーアダプター」、「早期大量採用」に相当します。

CNCF プロジェクトの成熟度レベル

CNCF は、各成熟度レベルごとに詳細な基準を開発しました (読者の便宜のために以下にリストします)。プロジェクトは、技術監督委員会 (TOC) から 3 分の 2 の承認を得た場合にのみ、インキュベーションレベルまたは卒業レベルに移行できます。

サンドボックスレベル

サンドボックスステータスの資格を得るには、プロジェクトに少なくとも 2 つの TOC スポンサーが必要です。詳細な手順については、CNCF サンドボックスガイド v1.0 を参照してください。

孵化レベル

注: インキュベーションレベルは、プロジェクトに対する包括的なデューデリジェンスを実施することが期待される出発点です。

インキュベーションレベルに入るには、プロジェクトはサンドボックスレベルの要件に加えて、次の要件を満たす必要があります。

少なくとも 3 人の独立したエンドユーザーによって本番環境で正常に使用されており、これらのエンドユーザーが TOC によって十分な品質と範囲を備えていると判断されていることを実証します。
コミッターの数を適切な数に保ちます。コミッターはコミット権限を持つ人、つまりプロジェクトの一部または全体への貢献を受け入れることができる人として定義されます。
進行中のコミットとマージされた貢献が多数表示されます。
これらの指標はプロジェクトの種類、範囲、規模によって大きく異なる可能性があるため、TOC にはこれらの基準を満たす活動レベルを決定する権限があります。

卒業

サンドボックスまたはインキュベーティングレベルを卒業するには、または新しいプロジェクトを卒業プロジェクトとして承認するには、プロジェクトが以下の条件に加えてインキュベーティングレベルの基準を満たす必要があります。

組織から少なくとも 2 人のコミッター。
コアインフラストラクチャプログラムのベストプラクティスバッジを取得および維持しています。
独立したサードパーティのセキュリティ監査を完了し、次の例と同様の範囲と品質の結果を公開しています (解決済みの重大な脆弱性を含む)：https://github.com/envoyproxy/envoy#security-audit、卒業前にすべての重大な脆弱性を解決する必要があります。
CNCF 行動規範を採用します。
プロジェクトのガバナンスと配信プロセスを明確に定義します。 GOVERNANCE.md ファイルにそれらをリストし、現在のコミッターと名誉コミッターを示す OWNERS.md ファイルを参照するのが最適です。
少なくとも 1 つのプライマリリポジトリ (例: ADOPTERS.md またはプロジェクト Web サイト上のロゴ) を持つプロジェクト採用者の公開リスト。
TOCから過半数の票を獲得し、卒業段階に入ります。プロジェクトが十分な成熟度を証明できる場合は、サンドボックスレベルから段階的レベルへの直接移行を試みることができます。プロジェクトは無期限にインキュベーション状態のままになることもありますが、通常は 2 年以内に完了することが期待されます。

注目に値する9つのプロジェクト

この記事ではすべての CNCF プロジェクトを網羅することはできませんが、卒業および育成されたオープンソースプロジェクトの中で最も興味深い 9 つを紹介します。

卒業プロジェクト

卒業プロジェクトは成熟しているとみなされ、多くの組織に採用されており、CNCF ガイドラインに厳密に準拠しています。ここでは、最も人気のあるオープンソースの CNCF 卒業プロジェクトを 3 つ紹介します。 (これらの説明の一部は、プロジェクトの Web サイトから改変したものであることに注意してください。)

1. Kubernetes（ギリシャ語で「舵取り」の意味）

クベネフィット！ Kubernetes について言及せずにクラウドネイティブアプリケーションについて語ることはできるでしょうか? Google が開発した Kubernetes は、コンテナベースのアプリケーション向けの最も有名なコンテナオーケストレーションプラットフォームであることは間違いありません。また、オープンソースツールでもあります。

コンテナオーケストレーションプラットフォームとは何ですか?通常、コンテナエンジンは複数のコンテナを単独で管理できます。しかし、数千のコンテナと数百のサービスについて話す場合、それらのコンテナの管理は非常に複雑になります。ここでコンテナオーケストレーションエンジンが役立ちます。コンテナオーケストレーションエンジンは、コンテナの展開、管理、ネットワーク、可用性を自動化することで、多数のコンテナの管理に役立ちます。

Docker Swarm と Mesosphere Marathon もコンテナオーケストレーションエンジンですが、Kubernetes がこの競争に勝ったと言っても過言ではありません (少なくとも今のところは)。 Kubernetes は、Red Hat OpenShift の一部である Kubernetes の Origin コミュニティディストリビューションである OKD などのコンテナーアズアサービス (CaaS) プラットフォームも生み出しました。

開始するには、Kubernetes GitHub リポジトリにアクセスし、Kubernetes ドキュメントページからドキュメントと学習リソースにアクセスします。

2. プロメテウス

Prometheus は、2012 年に SoundCloud で構築されたオープンソースのシステム監視およびアラートツールです。それ以来、多くの企業や組織が Prometheus を採用しており、このプロジェクトには非常に活発な開発者およびユーザーコミュニティがあります。現在では、会社から独立して管理される独立したオープンソースプロジェクトとなっています。

Prometheus を理解する最も簡単な方法は、24 時間 x 365 日稼働する必要がある実稼働システムを視覚化することです。完璧なシステムはなく、障害を軽減する技術（フォールトトレラントシステムと呼ばれる）はありますが、問題が発生した場合には、できるだけ早くそれを検出することが最も重要です。ここで、Prometheus のような監視ツールが役立ちます。Prometheus は単なるコンテナ監視ツールではありませんが、クラウドネイティブアプリケーションを持つ企業の間で最も人気があります。さらに、Grafana を含む他のオープンソース監視ツールも Prometheus を利用しています。

Prometheus を使い始める最良の方法は、GitHub リポジトリをダウンロードすることです。 Prometheus をローカルで実行するのは簡単ですが、コンテナエンジンをインストールする必要があります。詳細なドキュメントは Prometheus の Web サイトでご覧いただけます。

3. 特使

Envoy (または Envoy Proxy) は、クラウドネイティブアプリケーション向けに設計されたオープンソースのエッジプロキシおよびサービスプロキシです。 Lyft によって作成された Envoy は、単一のサービスとアプリケーション向けに設計された高性能 C++ 分散プロキシです。また、多数のマイクロサービスで構成されるサービスメッシュアーキテクチャ向けに設計された通信バスおよびユニバーサルデータプレーンでもあります。 Envoy は、Nginx、HAProxy、ハードウェアロードバランサー、クラウドロードバランサーなどのソリューション上に構築されています。 Envoy は各アプリケーションと並行して実行され、プラットフォームに依存しない方法で共通機能を提供することでネットワークを抽象化します。

インフラストラクチャ内のすべてのサービストラフィックが Envoy メッシュを通過すると、一貫した可観測性を通じて問題領域を視覚化し、全体的なパフォーマンスを調整し、インフラストラクチャ機能を 1 か所に追加することが容易になります。基本的に、Envoy プロキシは、組織が本番環境向けにフォールトトレラントシステムを構築するのに役立つサービスメッシュツールです。

サービスメッシュアプリケーションには、Uber の Linkerd (後述) や Istio など、多くの代替手段があります。 Istio は、Envoy をサイドカーとしてデプロイし、Mixer の構成モデルを活用することで Envoy を拡張します。 Envoy の注目すべき機能は次のとおりです。

すべての「テーブルステークス」機能が含まれています (Istio などのコントロールプレーンと組み合わせた場合)
99%のデータは負荷がかかった状態でも低レイテンシを実現できる
コアL3/L4フィルターとして使用でき、すぐにL7フィルターを提供
gRPC と HTTP/2 (アップリンク/ダウンリンク) をサポート
API駆動、動的構成とホットリロードをサポート
指標の収集、追跡、全体的な監視に重点を置く

Envoy を理解し、その機能を検証し、そのメリットを最大限に享受するには、実稼働環境で Envoy を実行する豊富な経験が必要です。詳細については、詳細なドキュメントを参照するか、GitHub リポジトリにアクセスしてください。

インキュベーションプロジェクト

以下は、最も人気のあるオープンソース CNCF インキュベーションプロジェクト 6 つです。

4. rkt（ロケット）

rkt (「ロケット」と発音) は、Pod ネイティブのコンテナエンジンです。 Linux 上でコンテナを実行するためのコマンドラインインターフェイスを備えています。ある意味では、Podman、Docker、CRI-O などの他のコンテナに似ています。

rkt はもともと CoreOS (後に Red Hat に買収) によって開発され、詳細なドキュメントは同社の Web サイトで確認でき、ソースコードは GitHub でアクセスできます。

5. イエガー

Jaeger は、クラウドアプリケーション向けのオープンソースのエンドツーエンドの分散トレースシステムです。ある意味、これは Prometheus のような監視ソリューションです。しかし、使用例が拡張されている点が異なります。

分散トランザクション監視
パフォーマンスとレイテンシの最適化
根本原因分析
サービス依存性分析
分散コンテキスト伝播

Jaeger は Uber が構築したオープンソーステクノロジーです。詳細なドキュメントは Web サイトに、ソースコードは GitHub にあります。

6. リンカード

Envoy プロキシを作成した Lyft と同様に、Uber は実稼働レベルのサービス保守用に Linkerd オープンソースソリューションを開発しました。ある意味では、Linkerd は Envoy に似ており、どちらも構成やコードの変更を必要とせずにプラットフォームレベルの可観測性、信頼性、セキュリティを提供するように設計されたサービスメッシュツールです。

ただし、両者の間には微妙な違いがいくつかあります。 Envoy と Linkerd はプロキシとして機能し、接続されたサービスを通じてレポートを返すことができますが、Envoy は Linkerd のような Kubernetes Ingress コントローラーとして設計されていません。 Linkerd の注目すべき機能は次のとおりです。

複数のプラットフォーム（Docker、Kubernetes、DC/OS、Amazon ECS、または任意のスタンドアロンマシン）をサポート
複数のシステムを連携させるための組み込みのサービス検出抽象化
gRPC、HTTP/2、HTTP/1.xリクエストとすべてのTCPトラフィックをサポート

詳細については、Linkerd の Web サイトで確認し、GitHub でソースコードにアクセスしてください。

7. ヘルム

Helm は基本的に Kubernetes 用のパッケージマネージャーです。 Apache Maven、Maven Nexus、または同様のサービスを使用したことがある場合は、Helm の役割を理解しているでしょう。 Helm は Kubernetes アプリケーションの管理に役立ちます。「Helm Chart」を使用して、最も複雑な Kubernetes アプリケーションを定義、インストール、アップグレードします。 Helm はこれを実現する唯一の方法ではありません。もう 1 つの人気の概念は、Red Hat OpenShift 4 で使用される Kubernetes Operators です。

Helm を試すには、ドキュメントのクイックスタートガイドまたは GitHub ガイドに従ってください。

8. その他

Etcd は、分散システムで最も重要なデータを保存するために使用される、分散型の信頼性の高いキー値ストアです。主な機能は次のとおりです。

明確に定義されたユーザー向け API (gRPC)
オプションのクライアント証明書検証による自動 TLS
速度（最大10,000回/秒の書き込み）
信頼性（配布に Raft を使用）

Etcd は、Kubernetes や他の多くのテクノロジーのデフォルトの組み込みデータストレージソリューションです。つまり、独立して実行されたり、別のサービスとして実行されたりすることはほとんどありません。代わりに、Kubernetes、OKD/OpenShift、またはその他のサービスへの統合として動作します。ライフサイクルを管理し、API 管理機能のロックを解除するために使用できる etcd Operator もあります。

etcd の詳細についてはドキュメントを参照し、GitHub でソースコードにアクセスしてください。

9. クリオー

CRI-O は、Kubernetes ランタイムインターフェースの OCI 互換実装です。 CRI-O は、次のようなさまざまな機能に使用されます。