Skip to content

Latest commit

 

History

History
198 lines (139 loc) · 11.8 KB

README-ja.md

File metadata and controls

198 lines (139 loc) · 11.8 KB

Kubernetes向けDORAメトリクス + CloudEvents & CDEvents

🌍 利用可能な言語: English | 中文 (Chinese) | 日本語 (Japanese)

注意: これは素晴らしいクラウドネイティブコミュニティの 🌟 コントリビューター によってもたらされました！

このチュートリアルでは、複数のソースからCloudEventsを消費し、Kubernetesネイティブなアーキテクチャ（クラウドに依存しない）を使用してDORAメトリクスを追跡できるコンポーネントのセットをインストールします。

このデモは、異なるイベントソースを観察し、これらのイベントをソフトウェアデリバリープラクティスに関連する意味のあるイベントにマッピングし、DORAメトリクスを計算するために集計できるようすることに焦点を当てています。

イベント変換フローは次のようになります：

  • 入力は、異なるソースからのCloudEventsです
  • これらのCloudEventsは、さらなる処理のためにCDEventsにマッピングおよび変換できます
  • DORA（またはその他の）メトリクスを計算するために集計関数を定義できます
  • メトリクスは消費のために公開できます（この例ではRESTエンドポイントを介して）

インストール

変換関数を実行するために、Knative Servingを使用したKubernetesクラスターを使用します。第8章のKnative Servingをインストールしたクラスターを作成する手順に従うことができます。

次に、Knative Eventingをインストールします。これはオプションでが、内部のKubernetesイベントを取得してCloudEventsに変換するKubernetes API Event Sourceをインストールするために使用します。

  1. Knative Eventingをインストールします
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.0/eventing-crds.yaml
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.0/eventing-core.yaml
  1. "dora-cloudevents"名前空間を作成します：
kubectl create ns dora-cloudevents
  1. PostgreSQLをインストールしてテーブルを作成します
kubectl apply -f resources/dora-sql-init.yaml
helm install postgresql oci://registry-1.docker.io/bitnamicharts/postgresql --version 12.5.7 --namespace dora-cloudevents --set "image.debug=true" --set "primary.initdb.user=postgres" --set "primary.initdb.password=postgres" --set "primary.initdb.scriptsConfigMap=dora-init-sql" --set "global.postgresql.auth.postgresPassword=postgres" --set "primary.persistence.size=1Gi"
  1. シンプルなCloudEventsモニターであるSockeyeをインストールします。これにはKnative Servingがインストールされている必要があります：
kubectl apply -f https://github.com/n3wscott/sockeye/releases/download/v0.7.0/release.yaml
  1. Kubernetes API Server CloudEvent Event Sourceをインストールします：
kubectl apply -f api-serversource-deployments.yaml

コンポーネント

このデモでは、CloudEventsをCDEventsに変換し、利用可能なデータを集計するために以下のコンポーネントをデプロイします。

  • CloudEvents Endpoint: すべてのCloudEventsを送信するエンドポイント。これらのCloudEventsはSQLデータベースのcloudevents-rawテーブルに保存れます。

  • CloudEvents Router: ルーティングテーブルを持つルーター。イベントをCDEventsに変換するためにルーティングします。このメカニズムにより、必要に応じて同じイベントタイプを複数のCDEventsに変換できます。このコンポーネントはcloudevents-rawテーブルから読み取り、イベントを処理します。このコンポーネントは設定可能な固定期間でトリガーされます。

  • CDEvents Transformers: これらの関数はCloudEvents Routerからイベントを受け取り、CloudEventsをCDEventsに変換します。結果はCDEvents Endpointに送信されます。

  • CDEvents Endpoint: CDEventsを送信するエンドポイント。これらのCloudEventsはSQLデータベースのcdevents-rawテーブルに保存されます。変換が不要なためです。このエンドポイントは、受信したCloudEventがCD CloudEventであることを検証します。

  • Metrics Functions: これらの関数は異なるメトリクスを計算し、特別なテーブル（おそらくテーブルごとに1つ）に保存する責任があります。これらのメトリクスを計算するために、これらの関数はcdevents-rawから読み取ります。デプロイメント頻度メトリクスの計算方法の例を以下で説明します。

  • Metrics Endpoint: 名前でメトリクスを照会し、フィルターを追加できるエンドポイント。これはオプションのコンポーネントです。これらのエンドポイントを使用せずに、メトリクステーブルからダッシュボードを構築することもできます。

dora-cloudevents-architecture

コンポーネントのデプロイとデータの生成

まず、以下のコマンドを実行してコンポーネントと変換関数をデプロイします：

kubectl apply -f resources/components.yaml

ブラウザでhttp://sockeye.default.127.0.0.1.sslip.io/にアクセスして、CloudEventsをモニタリングするためにSockeyeを開きます。

次に、設定が正しく動作していることをテストするために、default名前空間に新しいDeploymentを作成します。

kubectl apply -f test/example-deployment.yaml

この時点で、Sockeyeに大量のイベントが表示されるはずです：

sockeye

デプロイメント頻度関数（変換と計算）がインストールされている場合、デプロイメント頻度エンドポイントにクエリを実行してメトリクスを確認できるはずです。Cronジョブを使用してデータを定期的に集計しているため、これには最大で数分かかる場合があることに注意してください：

curl http://dora-frequency-endpoint.dora-cloudevents.127.0.0.1.sslip.io/deploy-frequency/day | jq

作成したデプロイメントに応じて、次のような出力が表示されるはずです（私はnginx-deploymentとnginx-deployment-3という2つのデプロイメントを作成しました）：

[
  {
    "DeployName": "nginx-deployment",
    "Deployments": 1,
    "Time": "2023-08-05T00:00:00Z"
  },
  {
    "DeployName": "nginx-deployment-3",
    "Deployments": 1,
    "Time": "2023-08-05T00:00:00Z"
  }
]

デプロイメントを変更したり新しいものを作成したりしてみてください。コンポーネントはdefault名前空間内のすべてのDeploymentをモニタリングするように設定されています。

すべてのコンポーネントはdora-cloudevents名前空間にインストールされていることに注意してください。以下のコマンドを実行して、ポッドとKnative ServicesのURLを確認できます：

dora-cloudevents名前空間のKnative ServicesのURLを確認します：

kubectl get ksvc -n dora-cloudevents

実行中のポッドを確認します。Knative Servingを使用しているため、使用されていないすべての変換関数が常に実行されている必要がないことが興味深いです：

kubectl get pods -n dora-cloudevents

最後に、データを集計するすべてのCronJob実行を確認するには、次のコマンドを実行します：

kubectl get cronjobs -n dora-cloudevents

開発

開発用にkoを使用してdora-cloudeventsコンポーネントをデプロイします：

ko apply -f config/

メトリクス

https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.mdより

デプロイメント頻度

deployment frequency

新しいまたは更新されたデプロイメントリソースを探します。これは、以前に設定したAPIServerSourceを使用して行われます。

フローは次のようになります：

graph TD
    A[API Server Source] --> |writes to `cloudevents_raw` table| B[CloudEvent Endpoint]
    B --> |read from `cloudevents_raw` table| C[CloudEvents Router]
    C --> D(CDEvent Transformation Function)
    D --> |writes to `cdevents_raw` table| E[CDEvents Endpoint]
    E --> F(Deployment Frequency Function)
    F --> |writes to `deployments` table| G[Deployments Table]
    G --> |read from `deployments` table| H[Metrics Endpoint]
Loading

バケットの計算：日次、週次、月次、年次。

これは1日あたりのデプロイメント数をカウントします：

SELECT
distinct deploy_name AS NAME,
DATE_TRUNC('day', time_created) AS day,
COUNT(distinct deploy_id) AS deployments
FROM
deployments
GROUP BY deploy_name, day;

TODOと拡張

  • cloudevents_rawおよびcdevents_rawテーブルに処理済みイベントメカニズムを追加します。これにより、CloudEvents RouterとMetrics Calculation Functionsが既に処理済みのイベントを再計算するのを避けることができます。これは、最後に処理されたイベントを追跡するテーブルを持ち、CloudEvents RouterとMetrics Calculation Functionsが新しいテーブルに対して結合することで実現できます。
  • デプロイメント頻度メトリクスのバケットを計算するクエリをdeployment-frequency-endpoint.goに追加します：週次、月次、年次。頻度ではなくボリュームを計算するためのブログ投稿を確認してください：https://codefresh.io/learn/software-deployment/dora-metrics-4-key-metrics-for-improving-devops-performance/
  • 汎用コンポーネント（CloudEvents Endpoint、CDEvents Endpoint、CloudEvents Router）用のHelmチャートを作成します。
  • PostgreSQL helmチャートのテーブル作成を自動化します（https://stackoverflow.com/questions/66333474/postgresql-helm-chart-with-initdbscripts）
  • 変更のリードタイムの関数を作成します。

その他のソースと拡張