2023-12-18

Software Design 2024年1月号に寄稿した「Cloudflareの基本と運用のポイント」の補足と訂正

（2024-04-09追記）補足、訂正済みの記事がTech Blogで公開されました。

Software Design 2024年1月号で「Google Cloudを軸に実践するSREプラクティス」連載の最終回として、Cloudflareの基本と運用のポイントについて書かせていただきました。*1 読み返してみるとわかりづらい部分があったのでこのエントリで補足します。また、もし間違いがあったらこのエントリに訂正内容を追記します。

補足

p152: Developer Platform

運用上の課題としては、まだIAM(Identity and Access Management)に相当する機能がないため、サービス間の認可やユーザーアカウントごとの認可を細かく設定できません。

Developer Platformの文脈で、運用上の課題として上記のように書きました。 細かく設定できないという部分が抽象的すぎるため、具体例を補足して書き直してみました。

運用上の課題としては、まだIAM(Identity and Access Management)に相当する機能がないため、最小の権限でのワークロード実行制御ができません。
たとえば、「特定のCloudflare WorkersからはCloudflare R2の読み取りだけしかできない」といった制御です。
一方「特定のCloudflare Workersから特定のCloudflare R2のすべての操作」はBindingによる紐づけを前提としており、制御できるようになっています。

ユーザーアカウントに関しては、RBAC機能を利用してある程度権限が管理できますが、リリース環境ごとに権限を分離するなどの制御はできません。
とはいえ、IaCを前提としたGitリポジトリ側での統制により、ある程度担保できるでしょう。
また、管理コストは上がりますが、本番環境とその他の環境をアカウント(テナント)やドメイン単位で分離することも有効な手段です。

訂正

p146: Cloudflare DNS

(2023-12-20追記)

これを使うことがCDNをはじめとするCloudflareのEdge Serverによる最適化の恩恵を受けるため必須条件となります。通常、CDNサービスを利用するときは、任意のDNSプロバイダで、DNS Recordの向き先をそのCDNのEdge ServerのIPやホスト名に変更します。しかし、Cloudflareの場合は、Cloudflare DNSを使ってDNS Recordを管理しなければなりません。

こちらのCloudflare DNSの説明ですが、私の勘違いで事実と異なっていました。実際にはBusiness Plan以上であれば、任意のDNSプロバイダでCNAMEを指定してCloudflare Edge Serverへプロキシできます。つまり、Cloudflare DNSはCloudflare CDNを使うための必須条件はでありません。詳細は下記の公式資料を参照してください。

developers.cloudflare.com

*1:https://twitter.com/minato128/status/1734405264210809324

2023-12-06

GKE Upgrade Event を Datadog Monitor で Slack に通知する

Datadog GKE

はじめに

本投稿は、Datadog Advent Calendar 2023 の12/6の記事となります。

概要

Google Kubernetes Engine（GKE）を使っていると、クラスタのイベントをSlackに飛ばしたいことがあると思います。以下のGoogle Cloud公式の例はCloud Functionsを利用していますが、Datadogを使っている場合はDatadog Monitorで通知させるのがおすすめです。

cloud.google.com

こちらがDatadogを利用する場合の概要図です。

前提

GKEを使っていること
Datadogを使っていること
- DatadogのSlack連携が終わっていること

手順

1) GKEのクラスタ通知を有効にします

2) Pub/Subを作成し、Push EndpointにDatadog Logsを指定します

Endpoint
- https://http-intake.logs.datadoghq.com/api/v2/logs?dd-api-key=YOUR-KEY&dd-protocol=gcp&ddtags=project_id:minato128-sandbox
  - EventにはProject Numberしか入ってないので、project_idを指定しておきましょう

3) Datadog Monitorで、type_urlのUpgradeEventでトリガーさせるようにLog Alertを作成します

通知先をSlackに指定する
Conditional variables でRecover通知をしないようにしておく
- 検知したら1度だけ通知させるように

// Terraformのmessage部分
{{#is_warning}}
${slack_sample_warning_ch}
{{/is_warning}}

UpgradeEvent Format
クラスタ通知 | Google Kubernetes Engine（GKE） | Google Cloud

設定後の通知はこんな感じです。

Pros/Cons

Cloud Functionsの場合との相対的な比較です。

Pros

Cloud Functionsの作成・維持コストがない
- Datadog Monitorの作成・維持のほうが簡単（IaCされてるかどうかに関わらず）
- 維持コストとは
  - インフラ費用 + 管理コスト
IaCしない場合、ノーコードで設定できる
クラスタのイベントがログとして残り、履歴を遡って参照できる
- SecurityBulletinEvent
- UpgradeAvailableEvent
- UpgradeEvent

Cons

多少のディレイがある
- Datadog Monitorは最小1min間隔での検知なので、Cloud Functions方式より多少通知が遅いかもしれない
  - 計測したわけではないです
通知メッセージの表現力が低い
- Event payloadを使ってカスタマイズしたい場合は不向き

おわりに

以上、DatadogでGKE Upgrade Eventを通知する場合の手順やPros/Consの説明でした。持続可能な運用をしていくために、省力化・省コスト化を意識していきたいですね。

minato128 blog

minato128の公開メモ帳です。