注目すべきオープンソースのクラウドネイティブツール7つ

「クラウド ネイティブ」という言葉を聞いて、最初に思い浮かぶのは Kubernetes でしょうか?現在、Linux に次ぐ 2 番目に大きなオープンソース プロジェクトである Kubernetes は、クラウド ネイティブ界の大物です。しかし、CNCF 分野や、より広範なクラウド ネイティブ コミュニティには、他にも多くのプロジェクトがあります。

以下は、Kubernetes を使用していない、またはすべてのワークロードに Kubernetes を使用していないチームに役立つクラウド ネイティブ ツールのリストです。

1. ノマド

Kubernetes 以外にもコンテナ オーケストレーターがあることをご存知ですか?その 1 つが、HashiCorp の人たちが作った Nomad です。

Kubernetes よりもシンプルなアーキテクチャを備えているため、Docker Swarm よりもスケーラブルでありながら Kubernetes ほど複雑ではないものが必要な場合には、良い選択肢となる可能性があります。ただし、Kubernetes と Nomad のどちらかを選択する必要はありません。一部のチームでは、異なるワークロードに両方を使用しています。 Nomad の一般的な使用例は、バッチ処理ジョブの実行です。

Nomad は他の HashiCorp ツールと非常にうまく統合されており、非常に高速です。さらに、Cilium を Nomad の CNI として使用することもできます。

いくつかのコンテナをオーケストレーションする必要があり、Kubernetes はやり過ぎと思われる場合は、Nomad を試してみてください。

2. プルミ

私はインフラストラクチャ・アズ・コードの世界で数年間を過ごしてきましたが、このトピックは今でも非常に興味深いです。しばらくの間、Terraformがクラウドプロビジョニングツールの分野で勝利したと思っていましたが、おそらく今でもそうかもしれませんが、Pulumi[6]はより新しい選択肢です。

Terraform に精通している方は、HashiCorp 構成言語 (HCL) が使用されていることをご存知でしょう。これは本格的なプログラミング言語ではなく、ドメイン固有言語 (DSL) です。カスタム DSL の問題の 1 つは、DSL と、どのようなパターンが有用であるかを学習するために、ユーザーに追加の負担がかかることです。

Pulumi は異なるアプローチを取りました。 Pulumi を使用すると、すでに知っている言語を使用し、Pulumi SDK を使用して必要な特定の Pulumi ビットを抽出できます。これは基本的に、コードにクラウド リソースを構成する機能を追加するライブラリです。サポートされている言語は、Python、Go、JavaScript、TypeScript、C#です。つまり、Pulimi コードを書くときには、テスト ツールを含む、選択した言語のエコシステム全体にもアクセスできることになります。

一般的に、ユーザーが希望する言語で作業できるようにするのが最善のアプローチだと思いますが、HCL のような宣言型 DSL の利点の 1 つは、ユーザーが記述するコードがべき等性を持つことが保証されることです。手続き型言語では、コード内の論理エラーによって予期しない結果が生じる可能性があります。それがここでの大きなトレードオフです。

全体的に、私はPulimiのアプローチがとても気に入っています。 HashiCorp は最近、Terraform 用のクラウド開発キット (現在はベータ版) を構築しました。これにより、Pulumi と同じ言語で Terraform 用のコードを記述できるようになり、これも Pulumi のアプローチを支持するものです。

3. サノス

誰もが Prometheus を使用しています。これは間違いなく、Kubernetes やその他のクラウドネイティブ アプリケーション向けの最も人気のある可観測性ツールの 1 つです。しかし、Prometheus を高可用性とスケーラビリティを実現するにはどうすればよいでしょうか?それらのデータをどのように活用しますか?

ここで Thanos が登場します。GitHub README には、「Thanos は、既存の Prometheus デプロイメントにシームレスに追加できる、無制限のストレージ容量を備えた高可用性メトリック システムを形成するために組み合わせられるコンポーネントのセットです。」と記載されています。ストレージの管理は、メトリクス収集において大きな問題となることが多いため、無制限のストレージ容量は魅力的であり、Thanos は Prometheus に高可用性も追加します。

私はサノスのデザインコンセプトが好きです:

• 各サブコマンドは1つのことを実行し、それをうまく実行する必要があります
• 連携して動作するコンポーネントの作成
• コンポーネントの読み取り、書き込み、実行を容易にする

Thanos は CNCF インキュベーション プロジェクトであり、メトリックを収集/保存する場合は試してみる必要があります。

4. など

etcd は Kubernetes クラスターのデータ ストアとして最もよく知られていますが、これを使用してさらに多くのことができます。

etcd は、サービス検出や構成データの保存など、Zookeeper や Consul などのツールでよくカバーされる一部のユースケースに使用できる分散キー値ストアです。これは Raft コンセンサス アルゴリズム (Consul のコンセンサス プロトコルも Raft に基づいています) を使用し、使いやすい CLI と API を備えています。

etcd を他のキーバリューストアと比較したい場合は、ドキュメント内に役立つページがあります。

ユースケースによっては、Consul や Vault のようなものがより適している可能性がありますが、キー値ストアのオプションを評価するときは etcd を念頭に置いてください。

5. クマ

仮想マシンを覚えていますか?多くの人がまだそれらを使用しており、コンテナ化されたワークロードを実行していないチームは、Istio や Linkerd などのサービス メッシュの使用に苦労していることがわかりました。

Kuma は、Kubernetes だけでなく VM でも動作するように設計されたサービス メッシュです。 Kuma は Envoy 上に構築されており、チームは Zipkin や Datadog を使用して、Mutal TLS、ヘルスチェック、サーキットブレーカー、分散トレースなどのポリシーを構成できます。 Envoy を使用すれば、これらの機能の多くを自分で作成できると思いますが、Kuma はそれらを管理するための中心的な場所を提供し、Envoy の複雑さの一部を抽象化します。

Kuma がサポートする戦略タイプのリストは印象的です。 Kuma は、サービス メッシュにカオス エンジニアリングを追加したい場合に備えて、基本的なフォールト インジェクションもサポートしています。

Kuma は Kong チームによって作成され、オープンソースの Kong Gateway と統合されます。 Kuma は CNCF に寄贈され、現在は CNCF サンドボックス プロジェクトとなっています。

6. シグストア

Solarwinds のハッキング以来、ソフトウェア サプライ チェーンのセキュリティは業界で大きな懸念事項となっています。これは多くのソフトウェア プロジェクトが解決する必要のある問題であり、リソースが少ないオープン ソース プロジェクトではさらに困難になることがよくあります。 Sigstore は、プロジェクトの管理者が成果物に簡単に暗号署名し、他のユーザーがそれらの署名を検証したり監視したりできるようにするオープンソース ツールのセットです。 sigstore ツールセットの概要は、Web サイトでご覧いただけます。

では、なぜ私はソフトウェアに署名するための新しいツールにそれほど興味を持っているのでしょうか?ロサンゼルスの KubeCon で Bob Callaway 氏と Dan Lorenc 氏による素晴らしい講演を聞きました。その講演では、シグストアなしで同じプロセスを実行するのがいかに難しいかが示されていました。プロセス全体がいかに簡単だったかには本当に感心しました。また、sigstore ツールがもたらす透明性も気に入りました。

ソフトウェア リリースを構築したり使用したりする場合は、sigstore を理解するために時間を費やす価値があります。 Linux Foundation や Google、Red Hat、VMware などの企業からのサポートにより、sigstore はほぼ確実に業界標準になるでしょう。

7. オープンテレメトリー

OpenTelemetry は、OpenTracing プロジェクトと OpenCensus プロジェクトが統合されたときに作成された分散トレース標準です。この合併により、トレース分野の混乱が大幅に軽減され、OpenTelemetry は Honeycomb、Datadog、New Relic、Dynatrace などの大手ベンダーに採用されました。

それはツールというよりも仕様です。 OpenTelemetry 仕様は最近バージョン 1.0 に達しました。トレースは分散システムを実行するチームにとって重要な問題であり、OpenTelemetry は現在広く使用されている共通仕様を提供することで、観測可能性の分野に大きな影響を与えています。これにより、可観測性ツールの大きな問題であるベンダー ロックインを軽減できます。 OpenTelemetry プロジェクトには API と SDK、Open Telemetry Collector などが含まれているため、少なくともいくつかのツールが含まれていることに安心しました。 OpenTelemetry Registry[21]で利用可能なものを確認できます。