SKU「Regional Standard Class A Operations」のカウントが異常に増えていた原因と解決方法

GCP料金レポートの「Cloud Storage」サービス「Regional Standard Class A Operations」のカウントがAPI呼び出しをそれほどしている覚えがないかつサイトを立ち上げて間もない(PVもほぼ無い)にもかかわらず月間「134,160」とかになっていたので調査。

調査方法

Cloud Storageへのアクセスのログを取りその内容を調査

ログ取得方法

こちらの「使用状況ログとストレージログ」を一部参考にログの取得設定を行いました。

ログ取得の準備

ログ書き込み用バケットの作成

バケット名は一応ログ用と分かりやすい名前にしておく。
ロケーションも他のバケットと同じに。

ログ用バケットのロール設定

バケットを作成したらバケット詳細の「権限」から権限の追加を行います。

設定したら「保存」を選択。

ログを取りたいCloud Storageのロギングステータスを確認

ここからはVMインスタンスにSSHで接続してコマンドで確認します。

Cloud Storageのロギングステータスを確認コマンド

gsutil logging get gs://[ログを取りたいバケット名]

コマンドを実行するとCloudSDK認証のコマンドを実行するようにと出てくるので実行。

gcloud auth login [Googleアカウント]

コマンド実行した際に出てきたURLをブラウザに入力し、アクセスします。
※SSH接続は後で認証コードを入力するのでそのままにしておく。

Googleアカウントログインをして、GoogleCloudSDKのアクセスを許可します。

許可をすると認証コードが表示されるのでコピーします。

次にコピーした認証コードを入力。

認証コード入力が終わったら、もう一度ロギングステータスの確認。

ロギング設定が有効ではないと出てきた。

ロギングを有効にする

次のコマンドでロギングが有効になるように設定。

gsutil logging set on -b gs://[ログを書き込むバケット名] gs://[ログを取りたいバケット名]

ロギングが有効になっているかどうか確認。

これでログを取ることができるのでログ書き込み用バケットにログファイルがあつまるまで待ちます。
「使用状況ログ」と「ストレージログ」の2種類のファイルが作られます。

BigQueryでログを確認するための設定

メニューから「BigQuery」を選択

既存のプロジェクトから「データセットを作成」

データセットができたら情報画面へ

次にテーブルを作成

テーブルはログの種類ごとに作成します。
・「使用状況ログ」：「usage」
・「ストレージログ」：「storage」
としますが、「ストレージログ」の方はログ内容としては「バケットの 24 時間の平均サイズ」のみなので
今回は「使用状況ログ」の方のみで進めます。

「GCS バケットからファイルを選択」の「参照」を選択して、
ログ書き込み用バケットを選択

ログ書き込み用パケット内のファイル一覧が表示される

「[ログを取りたいバケット名]usage・・・」というファイル名で入っており、
すべてを対象ファイルとして選択したいので、
ファイル名に「[ログを取りたいバケット名]usage*」と入力

次にスキーマの設定ですが、
スキーマ設定する前にGoogleで用意されているスキーマをダウンロード（ダウンロードページ）

usageテーブル用：cloud_storage_usage_schema_v0
storageテーブル用：cloud_storage_storage_schema_v0

ダウンロードができたら設定
スキーマの「テキストとして編集」に切り替えて
「cloud_storage_usage_schema_v0.json」の中身をコピーして貼り付け

ログの1行目はヘッダー行なので詳細オプションで1行目をスキップするように設定
設定できたら「テーブルを作成」

テーブルが作成できたら「usage」テーブルを確認。
「プレビュー」を選択

ログ内容を確認

プレビュー画面でログの「cs_uri」を確認してみると以下のようなログがたくさん存在する

/storage/v1/b/[バケット名]/o?prefix=sites%2F1%2F2022%2F03%2F&fields=items%2Fname%2Citems%2Fsize%2Citems%2Fupdated%2Citems%2FtimeCreated%2CnextPageToken

URLエンコードされているので見やすいように変換

/storage/v1/b/[バケット名]/o?prefix=sites/1/2022/03/&fields=items/name,items/size,items/updated,items/timeCreated,nextPageToken

さらに、こんなログも発見

/storage/v1/b/[バケット名]/o?prefix=sites/1/2022/03/wpcf7_uploads/.htaccess/&fields=items/name,items/size,items/updated,items/timeCreated,nextPageToken

CloudStorageのAPI資料を調べてみたところ、おそらくこちらのAPIと思われ
料金対象「クラスAオペレーション」の「storage.objects.list」になりカウント増大になっていると推測。

プラグイン関連でこれらのアクセスをしそうなものを考えた結果
「WP-Stateless」と「Contact Form 7」がアクセスしそうだったのでこのプラグインの処理を調査。

プラグイン関連の調査①

まず、「WP-Stateless」のプラグイン内の処理を調査。

調査したところ、「WP-Stateless」の設定で
「File URL Replacement」の設定を「Enable Editor & Meta」にしていると

「wp-stateless/lib/classes/class-bootstrap.php」の「convert_to_gs_link」内で「wp_upload_dir()」が呼び出されてディレクトリだけ作成するようなコードになっている
この部分でGCSにアクセスしているのではと推測。

最終的に「wp_mkdir_p」メソッドでディレクトリ作成しているようなので
こちらの中にチェック用にPHPのログ出力を埋め込んでみたところ、
チェック用ログが出力されたのでこの部分で間違いないと判明。

対応方法：「File URL Replacement」の設定を「Enable Editor & Meta」から「Enable Editor」に変更

プラグイン関連の調査②

続いて、「Contact Form 7」のプラグイン内の処理を調査。

ログで「wpcf7_uploads/.htaccess」となっていたのでこれが生成されている個所を捜索

「wpcf7_init_uploads」こちらのメソッド内の「wpcf7_upload_tmp_dir」メソッドでアップロード用のディレクトリを作成している個所を発見。
そのあとに「.htaccess」ファイルも生成している模様。

こちらでもPHPのチェック用ログを確認。

対応方法：アップロード用のディレクトリはGCSではなくてもよく、ソースコードを確認すると「WPCF7_UPLOADS_TMP_DIR」で別の場所に変更可能だったので別定義させて対応。

sudo vi /opt/bitnami/wordpress/wp-config.php

ここに別のアップロード先の定義を記述

define( 'WPCF7_UPLOADS_TMP_DIR' , 'uploads/wpcf7_uploads' );

対応後の結果

変更対応して数日、「Regional Standard Class A Operations」のカウントが1日で3000とか増えていましたが、50未満ぐらいに減りました。
まだ少し残っていますが一旦解決。

この時の各プラグインは以下バージョンになります。
「WP-Stateless」：Ver.3.1.1
「Contact Form 7」：Ver.5.5.6