Puppetのケーススタディ

「私はオープンソースプロジェクトとの連携を強く信じています。私たちは、Tekton、Knative、Ambassador、gVisorなど、製品の機能を支える多くのプロジェクトに貢献してきました。」

-- Noah Fontes氏、Puppet社シニアプリンシパルソフトウェアエンジニア

Relay by PuppetはKnativeを使用してあらゆるものにワークフローをもたらします

Puppet は、インフラストラクチャ自動化を専門とするソフトウェア会社です。同社は2009年に、運用に携わる人々の最も複雑な問題のいくつかを解決するために設立されました。2019年頃、チームは、クラウド運用チームが手動のワークフロープロセスに依存しているため、最新のクラウドネイティブアプリケーションを効果的に管理できないことに気づきました。グループは、クラウド環境のセキュリティ、コンプライアンス、および費用対効果を維持するために、最新のアーキテクチャによってトリガーされるイベントを接続するプラットフォームを構築する機会を見出しました。これは、クラウドネイティブのワークフロー自動化プラットフォームである Relay がどのようにして作成されたのか、そしてKnativeとKubernetesがビジネスプロセス自動化をどのように近代化し、強化するのかについてのストーリーです。

DevOpsのための接着剤

PuppetがTektonベースのワークフロー実行エンジンをトリガーするためにKnativeの能力と柔軟性を初めて探求し始めたとき、彼らは自分たちの旅がどこへ行くのかよくわかりませんでした。Knativeは魅力的な機能セットを提供していたため、彼らは構築と実験を始めました。彼らはイベント駆動型のDevOpsツールを構築したかったのです。彼らは、単なる別の継続的インテグレーション製品を構築することに興味はありませんでした。さらに、探求を続けるうちに、彼らは何か柔軟で、単一の分野に縛られないものを望んでいることに気づきました。彼らが何を構築していたとしても、それは一つの市場だけに焦点を当てるものではありませんでした。Knative Serving によって実現されるサーバーレスアプリケーションと関数が、クラウドベースのビジネスプロセス自動化サービスに最適であることに気づき、ターゲットが明確になりました。この認識から、彼らはクラウド運用チームが複数のクラウドとSaaS製品をレガシーソリューションとともに採用する際に発生する統合とイベントに関する問題を解決するのに役立つクラウドワークフロー自動化製品である Relay を構築しました。

コンテナとWebhook

コンテナとWebhookは、Relayアーキテクチャの重要な要素です。コンテナを使用すると、Puppetは、企業がワークフローを個別のビジネスユニットとして構成および展開できるクラウドベースのソリューションを提供できます。コンテナは自己完結型の環境を提供するため、レガシーサービスやパッケージを含めることもできます。これは、ビジネス顧客にとって不可欠な機能であることが証明されました。たとえば、Dockerイメージに含めることができるものはすべて、Relayワークフローの一部にすることができます。「コンテナは分離を提供するため、コンテナに焦点を当てました」と、PuppetのシニアプリンシパルソフトウェアエンジニアであるNoah Fontes氏は説明します。「コンテナは個別のユニットを提供します。実行することで、ユーザーは複雑なシステムのメンテナンス負担を軽減できます。」完全に設定可能なWebhookを許可することで、あらゆる種類のビジネスプロセスを組み込むために必要な柔軟性がユーザーに提供されます。Webhookを使用すると、RelayはほぼすべてのWebベースのAPIと対話して、サードパーティのSaaS製品、クラウドサービス、Webアプリケーション、さらにはシステムユーティリティにわたる、豊富でフル機能のワークフローをトリガーできます。Knative Servingは、Relayに重要なインフラストラクチャを提供します。Webhookとサービスが自動的にスケーリングされることを可能にし、ゼロにまでスケールダウンすることさえできます。これにより、Relayは、少数のユーザーのみが使用するユーザーを含む、ほぼすべての統合をサポートできます。自動スケーリングを使用すると、これらのサービスは使用されていない間はリソースを消費しません。

Knative Servingとは何ですか？

最新のクラウドベースのアプリケーションは、いくつかのアプローチを通じて大規模なスケーリングの課題に対処しています。これらのほとんどの中核にあるのは、コンテナの使用です。コンテナとは、単一のアプリケーション、単一のサービス、または単一の関数を実行する個別のコンピューティングユニットです。このアプローチは非常に強力であり、サービスは需要に応じて消費するリソースの数をスケーリングできます。ただし、これはすべて素晴らしいことですが、管理と設定が難しい場合があります。この高度なアーキテクチャを提供するための最も成功したソリューションの1つは、Knative Servingです。このフレームワークはKubernetes上に構築されており、サーバーレスアプリケーション、サービス、および関数の展開と管理をサポートします。特に、Knative Servicesは、構成、展開、および管理が容易であることに重点を置いています。

ワークフローの統合

オープンアーキテクチャにより、Relayは数十の異なるサービスとプラットフォームをワークフローに統合できます。Relay integrations GitHubページを見ると、これらの統合のリストが表示され、オープンソースコミュニティへのコミットメントが示されます。「私はオープンソースプロジェクトとの連携を強く信じています。私たちは、Tekton、Knative、Ambassador、gVisorなど、製品の機能を支える多くのプロジェクトに貢献してきました」とFontes氏は述べています。

結果：自動化されたインフラストラクチャ管理

RelayのインフラストラクチャはGoogle Cloud Platformで実行されていますが、すべての主要なクラウドサービスプロバイダーのサービスを含むワークフロー、統合、ステップ、およびトリガーのライブラリです。Relayのお客様は、Microsoft Azure、AWS、Oracle Cloud Infrastructureなどを統合できます。これらの統合をSaaSオファリングと組み合わせることで、真にインフラストラクチャ管理のZapierになりつつあります。「お客様は、Web APIとして実装するのが最適な場合が多いワークロードの管理に関して、多様なニーズを持っています。私たちの製品は、Knativeを搭載したサーバーレスマイクロサービス環境を提供し、従来の展開アーキテクチャの管理とメンテナンスのオーバーヘッドなしに、この複雑なツールを構築できるようにします。私たちはコスト削減を彼らに還元し、誰もがより幸せになります」とFontes氏は述べています。KnativeやTektonなどのシステムによって提供される既存のインフラストラクチャがなければ、Relayの構築と展開は不可能だったでしょう。Fontes氏のチームは8人を超えるエンジニアに成長することはありませんでした。Fontes氏によると、Relayの計画を固めたら、わずか3か月で本番環境に移行することができました。

「Knativeのおかげで、Relayのリリースは予想よりも簡単でした。」と、シニアプリンシパルソフトウェアエンジニアのNoah Fontes氏は述べています。

Knativeは、Kubernetesインストールの複雑な詳細を抽象化し、開発者が重要なことに集中できるようにすることで、スケーラブルで安全なステートレスアーキテクチャを迅速に利用できるようにすることを目指しています。