2025年1月から適用される、Cloud Monitoring アラートの新課金方法
みなさんこんにちは。クラウドエース バックエンドエンジニアリング部所属の唐津です。
Cloud Monitoringにおけるアラートの新課金方法が公開されたので、その内容を共有いたします。
要約
- 2025年1月7日以降、Cloud Monitoring のアラートポリシーに対する課金が開始される
- アラートポリシーにおいて、「条件数に応じた課金」と、「取得時系列データ件数に応じた課金」が導入される
- ポリシーを統合する、集計レベルを最適化するなどの対策により課金額を削減できる
- すでに Google Cloud との契約をしている場合、課金免除をリクエストすることができる
1. 概要
2025年1月7日以降、Cloud Monitoring におけるアラート設定に課金が開始されます。
月額課金の計算方法は以下の2つです。
- アラートポリシーにおいて、
$1.50 * {条件数}（条件数に応じた課金） - アラートポリシー内の条件において、
100万の時系列データ件数ごとに$0.35の課金（取得時系列データ件数に応じた課金）
これだけだと分かりにくいと思うため、それぞれの課金方法について、以下で詳しく説明いたします。
2. 条件数に応じた課金
2.1 条件数とは何か
アラートポリシーにおける条件（Condition）とは、一言でいうとアラートを通知するかどうかを判断する条件のことです。
例えば、「アラートポリシーの編集」画面からアラート条件の数を確認することができます。
図1. アラートポリシーの編集画面
また、「ポリシーの詳細」画面においては、グラフの数=条件数 になります。
図2. アラートポリシーの詳細画面
2.2 月額課金額の計算方法
こちらの計算方法は単純で、$1.50 * {条件数}が月額課金額となります。
3. 時系列データ件数に応じた課金
3.1. 時系列データとは何か
時系列データとは、Cloud Monitoring において収集されるメトリクスデータのことです。
アラートポリシーにおける時系列データの種類は、指標に基づいて監視されるリソース数と同等になります。 （GCE や Cloud SQLの CPU 使用率であれば稼働中のインスタンス数、Cloud Run であれば稼働中のリビジョン数）
図3. 時系列データ例：GCE インスタンスの CPU 使用率
ただし、公式ドキュメントに
Log-based alerting policies use log-match conditions. Log-match conditions return no time series.
と書かれていることから、ログベースの指標は時系列データには含めないようです。 （グラフには描画されるが、時系列データではない）
図4. ログベースの指標例：GCE インスタンス停止ログのカウント数
3.2. 時系列データ件数とは何か
時系列データ件数とは、Cloud Monitoring のデータストアからクエリによって取得したデータ数のことであり、こちらが月額課金の対象になります。
計算式は以下のようになります。
指標ごとの時系列データ件数 = {対象リソース数} * {取得回数}
通常のクエリの場合は30秒ごとにクエリが実行されるため、30日で86,400回となります。
4. 計算例
4.1. 例1：GCE インスタンス2つを監視する場合（条件は分けない）
- メモリ使用率、CPU 使用率を監視する
- 時系列データの集計方法、アラートトリガー設定を分ける必要はないので、条件も分けない
メモリ使用率
条件数に応じた課金：$1.50 * 1（条件数） = $1.50
時系列データ件数に応じた課金：$0.35 * 2（対象リソース数） * 86,400（クエリ実行回数） / 1,000,000 = $0.06048
合計：$1.50 + $0.06048 = $1.56048
CPU使用率
メモリ使用率と同じ
総計
$1.56048 * 2（指標数） = $3.12096 / 月
4.2. 例2：GCE インスタンス2つを監視する場合（条件は分ける）
- メモリ使用率、CPU 使用率を監視する
- アラートトリガー設定を分けたい（閾値を別にしたい）ので条件を分ける
メモリ使用率
条件数に応じた課金：$1.50 * 2（条件数） = $3.00
時系列データ件数に応じた課金：$0.35 * 2（対象リソース数） * 86,400（クエリ実行回数） / 1,000,000 = $0.06048
合計：$3.00 + $0.06048 = $3.06048
CPU使用率
メモリ使用率と同じ
総計
$3.06048 * 2（指標数） = $6.12096 / 月
4.3. 例3：GCE インスタンスの停止をログベースの指標を用いて監視する場合
条件数に応じた課金：$1.50 * 1（条件数） = $1.50
時系列データ件数に応じた課金：なし
合計：$1.50 / 月
5. 課金額を安くする方法
5.1. 不要なアラートポリシーを削除する
アラートポリシーを無効化しても課金対象外にはならないため、不要なアラートポリシーは削除してしまいましょう。
5.2. アラートポリシーや条件を統合する
例1、例2を見比べると分かりますが、同一指標において条件を分けると課金額が増えてしまいます。 また、アラートポリシーを分けると、必然的に条件も分けることになるのでアラートポリシーも同様です。
一方で、アラートポリシー自体の設定（アラートポリシー名や通知先）をカスタマイズしたい場合はアラートポリシーを分ける必要があります。 また、条件の設定（時系列データの集計方法やトリガー設定）をカスタマイズしたい場合は条件を分ける必要があります。
5.3. 対象リソース階層を高くする
監視対象のリソース階層を高くするほど、取得する時系列データ件数は少なくなり、課金額を削減できます。 例えば、GCE インスタンス単位ではなく、Instance Group 単位の監視で代用できる場合、取得する時系列データ件数を少なくできます。
5.4. 取得する時系列データを集計できるか検討する
課金額はクエリによって取得した時系列データ件数によって変動するため、集計関数（SUM、MAXなど）を利用し、取得件数を減らすことで課金額を削減できます。
5.5. 監視不要なリリースをフィルターで除く
監視不要なリリースがある場合にはフィルターを設定し、不要な時系列データを取得しないようにしましょう。 例えば、内部用の GCE インスタンスを監視対象外としたい場合は、インスタンス名やラベルを用いてフィルター設定できます。
5.6. 取得する時系列データの上限を設定する
もし PromQL や MQL のクエリ文を手動で設定して条件を作成している場合、以下のキーワードを使用することで、取得する時系列データの上限を定められます。
一方で上限を設定すると、時系列データ数が上限を超えた場合に取得できないデータが発生し、それによりアラートが発生しない不具合が発生する可能性があります。 そのため、個々の Kubernetes コンテナなどを監視するような、大量の時系列データを返す指標に対してのみ設定することが推奨されています。
5.7. クエリ実行間隔を長くする（PromQL のみ）
PromQLクエリを使用している場合、evaluationInterval フィールドをカスタマイズすることで、クエリ実行間隔を長くすることができます。 クエリ実行間隔を長くすると、取得する時系列データ件数が減少し、課金額を削減できます。
6. 課金免除申請
2025年1月7日以降も継続する Google Cloud 契約（コミット契約など）をすでに結んでいる場合、新課金の適用を契約更新まで免除してもらうように申請できます。 申請が承認されるかは顧客ごとにケースバイケースで判断されると書かれております。 免除対象の可能性がある場合は、こちらのフォームから申請してください。（課金免除申請は2024年11月1日まで）
5. まとめ
- 2025年1月7日以降、Cloud Monitoringのアラートポリシーにおける課金が開始される
- アラートポリシーを無効化しても課金対象外にはならないため、アラートポリシーの見直しが必要
- 課金免除申請を行うと、契約更新まで新課金の適用を免除される可能性がある
無駄な課金を防ぎ、快適な Google Cloud ライフを送りましょう！👍
Discussion