トラブルシューティング

このページでは、Cloud Storage の使用中に発生する可能性のある一般的なエラーをトラブルシューティングする方法について説明します。

Cloud Storage などの Google Cloud サービスに影響するインシデントについては、Google Cloud Service Health ダッシュボードをご覧ください。

未加工リクエストのロギング

gcloud や Cloud Storage クライアント ライブラリなどのツールを使用する場合、リクエストとレスポンスの情報の多くはツールで処理されます。ただし、トラブルシューティングや、Stack Overflow などのフォーラムに質問を投稿する際に役立つ情報があると便利な場合があります。ツールのリクエスト ヘッダーとレスポンス ヘッダーを返すには、次の手順を使用します。

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

ruby
Google::Apis.logger.level = Logger::DEBUG

カスタム ヘッダーの追加

カスタム ヘッダーをリクエストに追加することは、デバッグ ヘッダーの有効化やリクエストのトレースなど、デバッグを目的とした一般的な方法です。次の例は、さまざまな Cloud Storage ツールでリクエスト ヘッダーを設定する方法を示しています。

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

using Google.Cloud.Storage.V1;

var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");

var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)

{
  Console.WriteLine(bucket.Name);
}

package main

import (
  "context"
  "io/ioutil"
  "log"
  "net/http"

  "cloud.google.com/go/storage"
  "google.golang.org/api/option"
  raw "google.golang.org/api/storage/v1"
  htransport "google.golang.org/api/transport/http"
)

func main() {

  ctx := context.Background()

  // Standard way to initialize client:
  // client, err := storage.NewClient(ctx)
  // if err != nil {
  //      // handle error
  // }

  // Instead, create a custom http.Client.
  base := http.DefaultTransport
  trans, err := htransport.NewTransport(ctx, base, option.WithScopes(raw.DevstorageFullControlScope),
            option.WithUserAgent("custom-user-agent"))
  if err != nil {
            // Handle error.
  }
  c := http.Client{Transport:trans}

  // Add RoundTripper to the created HTTP client.
  c.Transport = withDebugHeader{c.Transport}

  // Supply this client to storage.NewClient
  client, err := storage.NewClient(ctx, option.WithHTTPClient(&c))
  if err != nil {
              // Handle error.
  }

  // Use client to make a request
 }

type withDebugHeader struct {
  rt http.RoundTripper
}

func (wdh withDebugHeader) RoundTrip(r *http.Request) (*http.Response, error) {
  headerName := "X-Custom-Header"
  r.Header.Add(headerName, "value")
  resp, err := wdh.rt.RoundTrip(r)
  if err == nil {
    log.Printf("Resp Header: %+v, ", resp.Header.Get(headerName))
  } else {
    log.Printf("Error: %+v", err)
  }
  return resp, err
}

import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;

public class Example {

  public void main(String args[]) throws IOException {
    HeaderProvider headerProvider =
            FixedHeaderProvider.create("custom-header", "custom-value");
    Storage storage = StorageOptions.getDefaultInstance()
            .toBuilder()
            .setHeaderProvider(headerProvider)
            .build().getService();
    String bucketName = "example-bucket";
    String blobName = "test-custom-header";

    // Use client with custom header
    BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
    byte[] stringBytes;
    try (WriteChannel writer = storage.writer(blob)) {
      stringBytes = "hello world".getBytes(UTF_8);
      writer.write(ByteBuffer.wrap(stringBytes));
    }
  }
}

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

use Google\Cloud\Storage\StorageClient;

$client = new StorageClient([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bat'
       ]
   ]
]);

$bucket = $client->bucket('my-bucket');

$bucket->info([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bar'
       ]
   ]
]);

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

CORS 構成によるバケットへのアクセス

バケットに CORS 構成を設定していて、クライアント ブラウザからの受信リクエストが失敗する場合は、次のトラブルシューティングの手順を試します。

1. ターゲット バケットの CORS 構成を確認します。複数の CORS 構成エントリがある場合は、トラブルシューティングに使用するリクエスト値が、1 つの CORS 構成エントリにある値にマッピングされていることを確認します。

2. CORS リクエストの発行をテストする際は、CORS リクエストが許可されていない storage.cloud.google.com エンドポイントにリクエストを発行していないことを確認します。CORS でサポートされているエンドポイントの詳細については、Cloud Storage CORS のサポートをご覧ください。

3. 任意のツールを使用して、リクエストとレスポンスをレビューします。Chrome ブラウザでは、標準のデベロッパー ツールを使用してこの情報を確認できます。

   1. ブラウザのツールバーで Chrome メニュー（more_vert）をクリックします。
   2. [その他のツール] > [デベロッパー ツール] の順に選択します。
   3. [Network] タブをクリックします。
   4. アプリケーションまたはコマンドラインから、リクエストを送信します。
   5. ネットワーク アクティビティが表示されているペインで、リクエストを探します。
   6. [Name] 列で、リクエストに対応する名前をクリックします。
   7. [Headers] タブをクリックしてレスポンス ヘッダーを確認するか、[Response] タブをクリックしてレスポンスの内容を表示します。

   リクエストとレスポンスが表示されない場合は、以前の失敗したプリフライト リクエストがブラウザのキャッシュに残っている可能性があります。ブラウザのキャッシュをクリアすると、プリフライトのキャッシュもクリアされます。クリアされない場合は、CORS 構成の MaxAgeSec 値をデフォルト値の 1800（30 分）よりも小さい値に設定し、変更前の MaxAgeSec に設定されていた時間よりも長い時間待機したうえで、再度リクエストを試します。これにより新しいプリフライト リクエストが実行されて、新しい CORS 構成が取得され、キャッシュ エントリが削除されます。問題をデバッグし終えたら、MaxAgeSec を元の大きい値に戻して、バケットへのプリフライトのトラフィックを削減します。

4. リクエストに Origin ヘッダーがあること、およびヘッダー値がバケットの CORS 構成内の Origins 値の少なくとも 1 つと一致することを確認します。値のスキーム、ホスト、およびポートが正確に一致している必要があります。適切な一致の例を次に示します。

   • http://origin.example.com は http://origin.example.com:80 と一致しています（80 がデフォルトの HTTP ポートであるため）が、https://origin.example.com、http://origin.example.com:8080、http://origin.example.com:5151、http://sub.origin.example.com とは一致していません。

   • https://example.com:443 は https://example.com と一致しますが、http://example.com、http://example.com:443 とは一致しません。

   • http://localhost:8080 は http://localhost:8080 のみと正確に一致していて、http://localhost:5555 や http://localhost.example.com:8080 とは一致していません。

5. 簡潔なリクエストの場合、その HTTP メソッドが、バケットの CORS 構成にある Methods 値の少なくとも 1 つと一致していることを確認します。プリフライト リクエストの場合、Access-Control-Request-Method で指定したメソッドが Methods 値の少なくとも 1 つと一致していることを確認します。

6. プリフライト リクエストの場合は、Access-Control-Request-Header ヘッダーがあるかどうかを確認します。そのヘッダーがある場合は、各 Access-Control-Request-Header 値がバケットの CORS 構成にある ResponseHeader 値と一致することを確認します。プリフライト リクエストが正常に終了し、レスポンスに CORS ヘッダーが含まれるためには、Access-Control-Request-Header に指定したすべてのヘッダーが CORS 構成に含まれていることが必要です。

エラーコード

発生する可能性のある一般的な HTTP ステータス コードは次のとおりです。

301: Moved Permanently

問題: 静的ウェブサイトの設定中に、ディレクトリ パスにアクセスすると空のオブジェクトと 301 HTTP レスポンス コードが返されます。

解決策: http://www.example.com/dir/ などのディレクトリにアクセスしたときに、ブラウザがゼロバイトのオブジェクトをダウンロードして、301 HTTP レスポンス コードが表示された場合、バケットにはその名前の空のオブジェクトが含まれている可能性が非常に高くなります。これを確認して問題を解決するには、次のようにします。

1. Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
   

   [バケット] に移動

2. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」ボタンをクリックします。
3. gcloud storage ls --recursive gs://www.example.com/dir/ を実行します。出力に http://www.example.com/dir/ が含まれている場合は、その場所に空のオブジェクトがあります。
4. コマンド gcloud storage rm gs://www.example.com/dir/ で空のオブジェクトを削除します。

これで、http://www.example.com/dir/ にアクセスして、空のオブジェクトの代わりにそのディレクトリの index.html ファイルを返すことができます。

400: Bad Request

問題: 再開可能なアップロードの実行中に、次のエラーとメッセージを受信しました: Failed to parse Content-Range header.

解決策: Content-Range ヘッダーで使用した値が無効です。たとえば、Content-Range: */* は無効で、Content-Range: bytes */* として指定する必要があります。このエラーが表示された場合は、現在の再開可能アップロードがアクティブでなくなったため、新しい再開可能なアップロードを開始する必要があります。

401: Unauthorized

問題: 一般公開のバケットに直接、または Cloud CDN 経由でリクエストすると、HTTP 401: Unauthorized と Authentication Required のレスポンスで失敗します。

解決策: クライアントまたは中間プロキシによって、Cloud Storage へのリクエストに Authorization ヘッダーが追加されていないことを確認します。Authorization ヘッダーを含むリクエストは、空の場合でも、認証試行であるかのように検証されます。

403: Account Disabled

問題: バケットを作成しようとしましたが、403 Account Disabled エラーが発生しました。

解決策: このエラーは、関連付けられているプロジェクトの課金がまだ有効になっていないことを示しています。課金を有効にする手順については、プロジェクトの課金を有効にするをご覧ください。

課金が有効になっているにもかかわらず、このエラー メッセージが引き続き表示される場合は、サポートに連絡してプロジェクト ID と問題の状況をお伝えください。

403: Forbidden

問題: 特定のバケットまたはオブジェクトにアクセスするための権限が付与されているはずですが、アクセスを試みると 403 - Forbidden エラーが発生し、「[email protected] does not have storage.objects.get access to the Google Cloud Storage object」のようなメッセージが表示されます。

解決策: バケットまたはオブジェクトに対して、リクエストの完了に必要な IAM 権限がありません。リクエストを行うことができない場合は、次のことを確認してください。

1. 権限の付与先としてエラー メッセージに示されているメールアドレスが想定されたものかどうか。エラー メッセージに予期しないメールアドレスが表示されている場合や、「匿名の呼び出し側」が表示されている場合は、意図した認証情報がリクエストで使用されていません。リクエストに使用しているツールが、別のエイリアスまたはエンティティの認証情報で設定されている可能性があります。また、リクエストがユーザーの代わりにサービス アカウントによって行われている可能性があります。

2. エラー メッセージに示された権限が、必要であると想定していたものかどうか。想定外の権限が示されている場合は、使用しているツールがリクエストを完了するために別のアクセス権を必要としている可能性があります。たとえば、バケット内のオブジェクトを一括削除するには、まず gcloud を使用して、削除するバケット内のオブジェクトのリストを作成する必要があります。一括削除のこの部分では storage.objects.list 権限が必要ですが、オブジェクトの削除では通常、storage.objects.delete 権限のみが必要になるため、この追加の権限は想定されていないかもしれません。これがエラー メッセージの原因である場合は、追加で必要な権限を含む IAM ロールを付与します。

3. 目的のリソースまたは親リソースの IAM ロールが付与されているか。たとえば、プロジェクトの Storage Object Viewer ロールがあなたに付与されていて、オブジェクトのダウンロードを試みている場合は、そのプロジェクトのバケット内に対象のオブジェクトがあることを確認してください。別のプロジェクトの Storage Object Viewer 権限が誤って付与されている可能性があります。

4. 特定のバケットまたはオブジェクトへのアクセス権限が、コンビニエンス値を通じて付与されたものであるか。コンビニエンス値に付与されたアクセス権を削除すると、以前にリソースにアクセス可能であったプリンシパルが、リソースにアクセスできなくなることがあります。

   たとえば、[email protected] はプロジェクト my-example-project に対するオーナー（roles/owner）基本ロールを持っているとします。また、プロジェクトの IAM ポリシーによって、コンビニエンス値 projectOwner:my-example-project に Storage オブジェクト作成者（roles/storage.objectCreator）ロールが付与されているとします。この場合、[email protected] には、my-example-project 内のバケットに対する Storage オブジェクト作成者のロールに関連付けられた権限を持っていることになります。この付与が削除されると、[email protected] は Storage オブジェクト作成者ロールに関連付けられた権限を失います。

   このような場合は、目的の操作を実行するために必要なバケットレベルまたはオブジェクト レベルの権限を自身に付与することで、バケットまたはオブジェクトへのアクセス権を回復できます。

5. 特定の権限の使用を禁止する IAM 拒否ポリシーがあるか。IAM 拒否ポリシーが設定されているかどうかを確認するには、組織管理者にお問い合わせください。

403: Forbidden

問題: storage.cloud.google.com からコンテンツをダウンロードしているときに、ブラウザで URL を使用してオブジェクトに移動すると、403: Forbidden エラーが発生します。

https://storage.cloud.google.com/BUCKET_NAME/OBJECT_NAME

解決策: storage.cloud.google.com を使用してオブジェクトをダウンロードする方法は、認証済みブラウザでのダウンロードといいます。この方法では、Cookie ベースの認証が行われます。オブジェクトへのアクセスを追跡するように、Cloud Audit Logs のデータアクセス監査ログを構成している場合、この機能の制限により、追跡されたオブジェクトを認証済みブラウザでダウンロードできません。ただし、次のいずれかが適用される場合は、この限りではありません。

• オブジェクトが公開読み取り可能である
• オブジェクトが Google Cloud コンソールからアクセスされている

認証済みブラウザで別途ダウンロードしようとすると、403 レスポンスが返されます。この制限は、Cookie ベースの認証に使用される Google ID のフィッシングを防ぐために存在します。

この問題を回避するには、以下のいずれかを行います。

• 認証済みブラウザでのダウンロードではなく、未認証のダウンロードをサポートする直接 API 呼び出しを使用します。
• 影響を受けるオブジェクトへのアクセスを追跡する Cloud Storage のデータアクセス監査ログを無効にします。データアクセス監査ログはプロジェクト レベル以上で設定されます。また、複数のレベルで同時に有効にすることもできます。
• 除外を設定すると、データアクセス監査ログの追跡から特定のユーザーを除外できます。指定したユーザーは、認証済みブラウザでダウンロードを実行できます。
• allUsers または allAuthenticatedUsers のいずれかに読み取り権限を付与すると、影響を受けるオブジェクトを公開し、読み取り可能にすることができます。データアクセス監査ログには、公開オブジェクトへのアクセスは記録されません。

409: Conflict

問題: バケットを作成しようとしましたが、次のエラーが発生しました。

409 Conflict. Sorry, that name is not available. Please try a different one.

解決策: 使用しようとしたバケット名（gs://cats や gs://dogs など）は、すでに使用されています。Cloud Storage ではグローバルな名前空間を使用しているため、バケットに既存のバケットと同じ名前を付けることはできません。まだ使用されていない名前を選んでください。

412: Custom constraints violated

問題: リクエストが 412 orgpolicy エラーで拒否されます。

問題: リクエストが 412 Multiple constraints were violated エラーで拒否されます。

解決策: セキュリティ管理者チームに、リクエストの送信先となるバケットが、カスタム制約を使用する組織のポリシーの影響を受けるかどうかを確認します。バケットは、互いに競合する組織のポリシーの影響を受ける場合もあります。たとえば、あるポリシーではバケットに Standard ストレージ クラスが必要と指定され、別のポリシーではバケットには Coldline ストレージ クラスが必要と指定されています。

429: Too Many Requests

問題: リクエストが 429 Too Many Requests エラーで拒否されます。

解決策: Cloud Storage で特定のリソースに許可されるリクエスト数の上限に達しました。Cloud Storage の上限については、Cloud Storage の割り当てをご覧ください。

• ワークロードでバケットに対して毎秒 1,000 件のリクエストが発生する場合は、リクエスト レートとアクセス配信のガイドラインで、ワークロードの段階的な増加や連続したファイル名の回避などのベスト プラクティスをご確認ください。

• ワークロードで特定のロケーションへの 50 Gbps 以上のネットワーク下り（外向き）が使用される可能性がある場合は、帯域幅の使用量を確認して、帯域幅の割り当ての問題が発生しないことを確認します。

Google Cloud コンソールのエラーを診断する

問題: Google Cloud コンソールを使用して操作すると、汎用のエラー メッセージが表示されます。たとえば、バケットを削除しようとするとエラー メッセージが表示されますが、操作が失敗した詳しい理由は表示されません。

解決策: Google Cloud コンソールの通知を使用して、失敗した操作に関する詳細情報を確認します。

1. Google Cloud コンソールのヘッダーにある通知ボタン（notifications）をクリックします。

   プルダウンに、Google Cloud コンソールで最近実行されたオペレーションが表示されます。

2. 詳細を確認したい項目をクリックします。

   ページが開き、操作に関する詳細情報が表示されます。

3. 各行をクリックして、詳細なエラー情報を開きます。

問題: Google Cloud コンソールを使用すると、特定の列が表示されません。

解決策: Google Cloud コンソールにその列を表示するには、列表示オプション アイコン（view_column）をクリックして、表示する列を選択します。

シミュレートされたフォルダとマネージド フォルダ

問題: バケット内の一部のオブジェクトが削除され、そのオブジェクトが格納されているフォルダが Google Cloud コンソールに表示されません。

解決策: Google Cloud コンソールでは、バケットの中身がディレクトリ構造のように表示されますが、Cloud Storage にはフォルダが基本的に存在しません。そのため、共通の接頭辞を持つすべてのオブジェクトをバケットから削除すると、そのオブジェクト グループを表すフォルダ アイコンが Google Cloud コンソールに表示されなくなります。

問題: マネージド フォルダを作成できません。

解決策: マネージド フォルダを作成するには、次の要件を満たしていることを確認してください。

• Storage オブジェクト管理者（roles/storage.objectAdmin）ロールなど、storage.managedfolders.create 権限を含む IAM ロールが付与されている。ロールの付与手順については、IAM 権限を使用するをご覧ください。

• 均一なバケットレベルのアクセスが、マネージド フォルダを作成するバケットで有効になります。

• バケットまたはプロジェクトに、バケットのリソースタイプ（storage.googleapis.com/Bucket）またはオブジェクトのリソースタイプ（storage.googleapis.com/Object）を使用する IAM 条件がありません。プロジェクト内のいずれかのバケットに、これらのリソースタイプのいずれかを使用する IAM 条件が設定されている場合、後で条件が削除されても、そのプロジェクト内のどのバケットにもマネージド フォルダを作成できません。

問題: バケットにマネージド フォルダがあるため、均一なバケットレベルのアクセスを無効にできません。

解決策: バケットにマネージド フォルダがある場合、均一なバケットレベルのアクセスを無効にできません。均一なバケットレベルのアクセスを無効にするには、まずバケット内のすべてのマネージド フォルダを削除する必要があります。

静的ウェブサイトのエラー

ここでは、静的ウェブサイトをホストするバケットを設定するときに発生する可能性がある一般的な問題について説明します。

HTTPS による配信

問題: ロードバランサを使用せずに HTTPS でコンテンツを配信するにはどうしたらよいですか。

解決策: https://storage.googleapis.com/my-bucket/my-object などの直接 URI を使用すると、HTTPS で静的コンテンツを配信できます。SSL 経由でカスタム ドメインからコンテンツを配信する別のオプションについては、次をご覧ください。

• Cloud Storage でサードパーティのコンテンツ配信ネットワークを使用します。
• Cloud Storage ではなく Firebase Hosting から静的ウェブサイトのコンテンツを配信します。

ドメインの確認

問題: ドメインを確認できません。

解決策: 通常、Search Console の確認プロセスでは、ドメインにファイルをアップロードするように指示されますが、関連するバケットを最初に作成しないと、これを行うことはできません。バケットは、ドメインの所有権の証明を行った後にしか作成できません。

この場合、ドメイン名プロバイダの確認方法を使用して所有権を確認します。これを実行する手順については、所有権の確認をご覧ください。ドメインの確認はバケットの作成前に行えます。

アクセスできないページ

問題: ウェブサイトから提供されるウェブページでエラー メッセージ Access denied が表示されました。

解決策: オブジェクトが一般公開として共有されていることを確認します。共有されていない場合は、その方法についてデータの一般公開をご覧ください。

以前にオブジェクトをアップロードして共有するよう設定していても、新しいバージョンのオブジェクトをアップロードした場合は、オブジェクトを一般公開として共有するよう再度設定する必要があります。これは、新しいバージョンのオブジェクトをアップロードすると、一般公開権限が置換されるためです。

権限を更新できませんでした

問題: データを公開しようとしたときにエラーが表示されました。

解決策: storage.buckets.setIamPolicy 権限または storage.objects.setIamPolicy 権限があることを確認します。これらの権限は、ストレージ管理者（roles/storage.admin）ロールなどで付与されます。storage.buckets.setIamPolicy 権限または storage.objects.setIamPolicy 権限があるにもかかわらずエラーが表示される場合は、バケットが公開アクセス防止の対象になっていることが考えられます。公開アクセスが防止されている場合は、allUsers または allAuthenticatedUsers にアクセスできません。公開アクセス防止は、バケットに直接設定されるか、上位レベルで設定された組織のポリシーによって適用される場合があります。

コンテンツのダウンロード

問題: ページのコンテンツがブラウザに表示されず、ダウンロードするように求められます。

解決策: ウェブ コンテンツ タイプを持たないオブジェクトとして MainPageSuffix を指定すると、サイト訪問者は、提供されたコンテンツを見る代わりに、コンテンツをダウンロードするよう求められます。この問題を解決するには、Content-Type メタデータ エントリを適切な値（text/html など）に更新します。手順については、オブジェクトのメタデータを編集するをご覧ください。

レイテンシ

レイテンシについて発生する一般的な問題は次のとおりです。Google Cloud Service Health ダッシュボードで、Cloud Storage などの Google Cloud サービスに影響するインシデントを確認することもできます。

アップロードまたはダウンロードのレイテンシ

問題: アップロード時またはダウンロード時にレイテンシが増えます。

解決策: アップロードとダウンロードのレイテンシに関して、次の一般的な原因を考慮してください。

• CPU またはメモリの制約: 影響を受ける環境のオペレーティング システムに、CPU 使用率やメモリ使用量などのローカル リソースの使用量を測定するツールが必要です。

• ディスク I/O の制約: ローカル ディスクの I/O が原因でパフォーマンスに影響することがあります。

• 地理的な距離: Cloud Storage バケットと環境の物理的な距離がパフォーマンスに影響することがあります（特に大陸をまたいでいる場合など）。影響を受ける環境と同じリージョンにあるバケットでテストすることで、地理的に離れていることがレイテンシにどの程度影響するかを特定できます。

  • 該当する場合は、影響を受ける環境の DNS リゾルバで EDNS(0) プロトコルを使用して、環境からのリクエストが適切な Google Front End 経由でルーティングされるようにする必要があります。

CLI またはクライアント ライブラリのレイテンシ

問題: Google Cloud CLI またはクライアント ライブラリの 1 つを使用して Cloud Storage にアクセスすると、レイテンシが増加します。

解決策: gcloud CLI とクライアント ライブラリは、必要に応じてリクエストを自動的に再試行します。この動作は、エンドユーザーから見るとレイテンシを効果的に増加させる可能性があります。Cloud Monitoring の指標 storage.googleapis.com/api/request_count を使用して、Cloud Storage が再試行可能なレスポンス コード（429 や 5xx など）を一貫して返しているかどうかを確認します。

プロキシ サーバー

問題: プロキシ サーバー経由で接続しています。どのような操作が必要ですか。

解決策: プロキシ サーバー経由で Cloud Storage にアクセスするには、以下のドメインへのアクセスを許可する必要があります。

• accounts.google.com: OAuth2 認証トークンを作成するため
• oauth2.googleapis.com: OAuth2 トークンの交換を実行するため
• *.googleapis.com: ストレージ リクエスト用

プロキシ サーバーまたはセキュリティ ポリシーがドメインによる許可リスト登録をサポートしておらず、代わりに IP ネットワーク ブロックによる許可リスト登録のみをサポートしている場合は、プロキシ サーバーを Google IP アドレスの全範囲に合わせて構成することをおすすめします。アドレスの範囲を確認するには、ARIN で WHOIS データのクエリを行います。定期的にプロキシ設定を確認し、Google の IP アドレスと一致させることをおすすめします。

oauth2.googleapis.com と storage.googleapis.com を一度だけ検索して取得した個別の IP アドレスでプロキシを構成することはおすすめできません。Google サービスは、時間の経過に伴って変化する場合がある多数の IP アドレスにマッピングされた DNS 名を介して公開されているため、一度だけの検索に基づいてプロキシを構成すると、Cloud Storage への接続が失敗することがあります。

プロキシ サーバーを介してリクエストをルーティングする場合は、ネットワーク管理者に確認して、プロキシによって認証情報を含む Authorization ヘッダーが取り除かれないようにしてください。Authorization ヘッダーがない場合、リクエストは拒否され、MissingSecurityHeader エラーが発生します。

Storage Insights のエラー

問題: インベントリ レポートの構成で、毎日複数のインベントリ レポートが生成されます。

解決策: バケットに 1,000,000 個を超えるオブジェクトがある場合、複数のインベントリ レポートをシャードとして生成できます。インベントリ レポートの構成では、バケット内のオブジェクト 1,000,000 個ごとに 1 つのインベントリ レポートが生成されます。たとえば、3,500,000 個のオブジェクトを含むバケットがある場合、そのバケットのインベントリ レポートの構成では、指定した頻度で 4 つのインベントリ レポート シャードが生成されるほか、生成されたインベントリ レポート シャードの数とシャードのファイル名を含むマニフェスト ファイルも生成されます。

問題: インベントリ レポートが宛先バケットに表示されません。

解決策: インベントリ レポートの構成を作成しても、転送先バケットでインベントリ レポートが生成されない場合は、次の点を確認してください。

• インベントリ レポートの構成で指定した開始日が、インベントリ レポートの生成日と一致していることを確認します。開始日の指定方法については、インベントリ レポート構成を作成するをご覧ください。

• インベントリ レポートの履歴を表示して、不具合とその根本原因を確認します。インベントリ レポートの履歴を表示する手順は次のとおりです。

  1. Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
     

     [バケット] に移動

  2. バケットのリストで、インベントリ レポートの構成を含むソースバケットの名前をクリックします。

  3. [バケットの詳細] ページで、[インベントリ レポート] タブをクリックします。

  4. インベントリ レポートの構成のリストで、確認するレポートを生成したインベントリ レポート構成の UUID をクリックします。

  5. [インベントリ レポートの履歴] セクションで不具合を確認します。[ヘルプ]（help）にカーソルを合わせると、不具合が発生した理由の詳細が表示されます。

• プロジェクト レベルのサービス エージェントに、インベントリ レポートの読み取りと書き込みに必要な IAM ロールが付与されていることを確認します。手順については、サービス エージェントに必要なロールを付与するをご覧ください。

問題: インベントリ レポートの生成でランダムな遅延が発生します。

解決策: インベントリ レポートの生成間隔はさまざまです。最大で 1 日遅れることもあります。

次のステップ

• サポート オプションについて学習する。
• Cloud Storage に関するよくある質問のその他の質問の回答を確認する。
• Error Reporting が Cloud Storage のエラーの特定と把握にどのように役立つかを確認する。