gcloud storage cpで発生する storage.objects.get No such object エラーの真相
はじめに
Cloud Storageへのファイルアップロードのために、gcloud storage cpコマンドを使用すると、Cloud Loggingに、storage.objects.get No such objectというエラーが出力されます。
ファイルアップロードのコマンドをgsutil cpコマンドに変更すると、上記のエラーは出なくなります。
なぜでしょうか？
gcloud storage cpコマンドとgsutil cpコマンドの違いを調べてみました。
Cloud Logging
原因
gcloud storage cpは、パフォーマンス向上のために並列・分割アップロード（parallel composite upload）を自動的に利用します。この際、アップロード処理の一部でオブジェクトの存在確認やリスト取得など、追加のAPI呼び出し（例：object.getやobjects.list）が発生します。
公式ドキュメントにも、gcloud storage cpコマンドがパフォーマンス向上のために並列・分割アップロードを自動的に利用し、その際にバケットやオブジェクトのメタデータ取得（API呼び出し）が発生するという記載があります。
storage/parallel_composite_upload_compatibility_check: 安全チェックを切り替えるプロパティ。Trueの場合、gcloud storageは、次のすべての条件を満たす場合にのみ並列複合アップロードを実行します。
アップロードされたオブジェクトのストレージクラスがSTANDARDになっている。
転送先バケットに保持ポリシーがない。
転送先バケットでデフォルトのオブジェクト保持が有効になっていない。
なお、これらの条件を確認するために、gcloud CLI はアップロード コマンドの一部として宛先バケットのメタデータを取得します。
Falseの場合、gcloud storageはチェックを行いません。デフォルトの設定はTrueです。
反対に、gsutil cpコマンドの場合は、単純なアップロードのため、オブジェクトのチェックを行いません。
最後に
ただ単に、そのコマンドを使うのではなく、副作用なども調べて、他のコマンドと比較した上で慎重に検討するべきだと思いました。
Discussion