IT業界では、多くのバズワードのもと、とうてい現実的ではない可能性や空想が語られています。「サーバーレス」もそんなひどく誤解されているバズワードの1つです。このブログ記事では、妥当な「サーバーレス」の定義を提示し、なぜJenkins Xで「サーバーレスJenkins」という名称を使用するのかを説明します。
確かな定義を求めるのであれば、専門家グループに尋ねるのが一番です。Cloud Native Computing FoundationにはServerlessワーキンググループがあり、定義と具体的な使用シナリオの両方を提示するホワイトペーパーも発行されています。彼らの定義では、
サーバーレスコンピューティングとは、サーバー管理を必要としないアプリケーションを構築および実行するという概念のことです。
– – CNCF Serverlessワーキンググループ
Platforms as a Serviceは、アプリケーションを実行しスケーリングするという目的のため、必要なランタイムと自動スケーリング機能を提供します。ソースコードからアプリケーションをビルドするもの（git プッシュデプロイメントスタイル：Heroku）もあれば、バイナリパッケージデプロイを提供し、ビルドおよび継続的デリバリーワークフローは自由に実装できるもの（Google App Engine）もあります。
「Container as a Service」は、DockerとKubernetesの成長を背景として、それらが高密度のPaaS以上のものでない限り、マイクロサービスのデプロイメントではすでに一般的になっています。どちらの場合も、基本的な考え方は、Platform APIがすべてのインフラストラクチャの詳細を隠すということであり、開発者はサーバーやバックエンドの管理について心配する必要はありません。開発者の観点からは、サーバーリソースのメンテナンスに伴うオーバーヘッドを排除できます。
CNCF Serverlessワーキンググループのホワイトペーパーは、粒度の小さい開発およびデプロイメントモデルとして「Function as a Service」を非常に重視しています。FaaSでは、コードをビルド、実行、拡張する際に、基盤となるインフラストラクチャを考慮する必要はなく、意識する必要さえありません。
Function as a Serviceサーバーレスプラットフォームは、モノリスの分割をさらに推し進め、ファンクション、つまり、HTTPルーティングまたはイベントバスのいずれかで接続される単一のイベントエンドポイント単位でデプロイすることを可能にします。この開発モデルでは、開発者がファンクションをホストして実行するために必要なHTTPスタックを意識する必要はなく、イベントハンドラーを実装するだけです。
しかし、それだけではありません。CNCFワーキンググループの定義では、サーバーレスプラットフォームのもう1つの重要な側面は、「アイドル時のコンピューティングコストなし」です。
PaaSの自動スケーリングは、負荷が高くなったとき、より多くのリソースを割り当てることを可能にしますが、実際のトラフィックがコストを上回るビジネス価値を提供していないときでも、週7日24時間常に最低1つのアクティブインスタンスが実行されます。サーバーレスプラットフォームでは、ファンクションが実際に実行されているときにだけ計算コストが発生すると期待されます。ファンクションの実行パフォーマンスを低下させずに「0へのスケーリング」を実現する方法は、実装により異なる場合があります。特に、リクエストごとのコールドスタートのコストを考慮してください。HTTP API呼び出しごとにいちいちJVM全体をブートストラップしたくはないでしょう。プロバイダーを比較する際は、この点に注意してください。
Jenkins Xを見てみましょう
（Jenkins Xについてまったく知らない場合、この紹介をご覧ください)
Jenkins Xの「静的」デプロイメントでは、開発チームを定義し、それぞれが管理されたJenkinsマスターを使ってビルドと環境を処理します（詳しくはGitOpsに関する私の記事を参照）。この文脈でのJenkins Xは、チームごとにJenkinsマスターを実行するためのCaaSとしてKubernetesを使用します。その結果、Jenkins固有の落とし穴（ディスク使用量、ブランチをスキャンする際のGitHub APIレート制限など）に加えて、実行中のマスターを維持するためだけに、クラスターに永続的な負荷がかかります。
しかし、Jenkins XをサーバーレスJenkinsとしてデプロイすることもできます。「 サーバーレス 」、本当にそうでしょうか？またマーケティングのカリスマがバズワードの波に乗っているだけではないのでしょうか？
サーバーレスJenkinsでは、Jenkinsのマスタージョブ管理は、すべてProwで代替されています。Prowは、KubernetesコミュニティでKubernetesへのコントリビューションを管理するために多用されているコンポーネントです。ProwはGitHubイベントに応答するイベントベースのジョブオーケストレーターです。プッシュ、プルリクエスト、コメント、ラベルなどに反応して、なんらかのアクションをトリガーできます。これにより、Git（Hub）アクションによって作成されたイベントだけに基づいてコードレビューと検証ワークフロー全体を作成できます。Prowは一度インストールするだけのオーバーヘッドの低いサービスで、Jenkins Xクラスター上のすべてのホストされたチームにサービスを提供します。
Jenkins Xサーバーレスでは、サーバーレス「ファンクション」に相当するCI / CDは、Gitイベントに応答させたいGitリポジトリにホストされているJenkinsfileです。ここで、あなたが設計した素晴らしい機能のプルリクエストを作成したとしましょう。これによって作成されたイベント（GitHub のプルリクエスト）をProwがトラップし、設定（Jenkins Xによって自動的に設定されます）に応じてJenkins Pipeline Buildがトリガーされます。これは従来型のJenkinsマスターによって管理されるビルドキューの全面的な代替であり、完全にイベント駆動でKubernetesを利用したスケーラブルなビルド機能を提供します。
実際のPipelineの実行は一時的なJenkinsマスター内で行われます。一時的なJenkinsマスターは、ローカルのJenkinsfileに基づいて起動されたらすぐにビルドをトリガーし、ビルド完了後にシャットダウンするようにカスタマイズされています。Jenkinsfile Runnerの詳細はこちら 。
このアプローチの大きな利点は、チームの開発活動に合わせて簡単にCI / CDサービスを拡張できることです。アクティブでないチーム用にJenkinsマスターをホストするための不必要なリソースを消費することなく、ビルドやサービスに利用可能なリソースを増やすことができます。
►►「 アイドル時の計算コストなし 」 – ○
また、Jenkinsfile Runnerはビルド期間中しか実行されないため、プラグインのアップグレード、セキュリティのパッチ、ディスクのクリーンアップ、その他もろもろのJenkinsマスター管理作業はもう必要ありません。
►►「 サーバー管理を必要としない 」 – ○
CNCFワーキンググループによるサーバーレスの定義は、アプリケーションのホスティングに焦点を当てていますが、Jenkins Xサーバーレスは、同じ原則をCI / CDにも適用できることの完璧な証明であると思います。
その他のリソース
- Jenkins Xについてもっと詳しく知る
- Jenkins Xのインストール方法を学ぶ
- Jenkins Xのブレーンによるポッドキャストを聴く