トラブルシューティング

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

Cloud Storage などの Google Cloud サービスに影響するリージョンとグローバルのインシデントについては、Google Cloud ステータス ダッシュボードをご覧ください。

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

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

Console

リクエストとレスポンスの情報の表示は、Google Cloud Console へのアクセスに使用しているブラウザによって異なります。Google Chrome ブラウザの場合:

  1. Chrome のメインメニュー ボタン()をクリックします。

  2. [その他のツール] を選択します。

  3. [デベロッパー ツール] をクリックします。

  4. 表示されたペインで [Network] タブをクリックします。

gsutil

リクエストで最上位の -D フラグを使用します。次に例を示します。

gsutil -D ls gs://my-bucket/my-object

クライアント ライブラリ

C++

  • HTTP トラフィック全体を取得するには、環境変数 CLOUD_STORAGE_ENABLE_TRACING=http を設定します。

  • RPC ごとにログを取得するには、環境変数 CLOUD_STORAGE_ENABLE_CLOG=yes を設定します。

C#

ApplicationContext.RegisterLogger を使用してロガーを追加し、HttpClient メッセージ ハンドラでロギング オプションを設定します。詳細については、よくある質問をご覧ください。

Go

環境変数 GODEBUG=http2debug=1 を設定します。詳しくは、Go パッケージ net/http をご覧ください。

リクエスト本文もロギングする場合は、カスタム HTTP クライアントを使用します。

Java

  1. 次の内容のファイルを「logging.properties」という名前で作成します。

    # Properties file which configures the operation of the JDK logging facility.
    # The system will look for this config file to be specified as a system property:
    # -Djava.util.logging.config.file=${project_loc:googleplus-simple-cmdline-sample}/logging.properties
    
    # Set up the console handler (uncomment "level" to show more fine-grained messages)
    handlers = java.util.logging.ConsoleHandler
    java.util.logging.ConsoleHandler.level = CONFIG
    
    # Set up logging of HTTP requests and responses (uncomment "level" to show)
    com.google.api.client.http.level = CONFIG
  2. Maven で logging.properties を使用します。

    mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command

詳細については、プラガブル HTTP トランスポートをご覧ください。

Node.js

Node スクリプトを呼び出す前に、環境変数 NODE_DEBUG=https を設定します。

PHP

httpHandler を使用して独自の HTTP ハンドラをクライアントに提供し、リクエストとレスポンスをロギングするためのミドルウェアを設定します。

Python

ロギング モジュールを使用します。次に例を示します。

import logging
import http.client

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

Ruby

.rb file の先頭、require "google/cloud/storage" の後に以下を追加します。

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

エラーコード

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

301: Moved Permanently

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

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

  1. Cloud Console で、Cloud Storage ブラウザページに移動します。

    [ブラウザ] に移動

  2. Google Cloud Console の上部にある [Cloud Shell をアクティブにする] ボタンをクリックします。Cloud Shell をアクティブにする
  3. gsutil ls -R gs://www.example.com/dir/ を実行します。出力に http://www.example.com/dir/ が含まれている場合は、そのロケーションに空のオブジェクトがあります。
  4. コマンド gsutil 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: UnauthorizedAuthentication Required のレスポンスで失敗しました。

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

403: Account Disabled

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

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

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

403: Access Denied

問題: バケット内のオブジェクトを一覧表示しようとしましたが、403 Access Denied エラー / Anonymous caller does not have storage.objects.list access のようなメッセージが返されました。

解決策: 認証情報が正しいことを確認します。たとえば、gsutil を使用している場合は、.boto ファイルに保存されている認証情報が正しいことを確認します。また、コマンド gsutil version -lconfig path(s) エントリを確認し、想定される .boto ファイルを使用していることを確認してください。

正しい認証情報を使用していることを確認したうえで、リクエストが(HTTPS ではなく)HTTP を使用してプロキシ経由でルーティングされている場合は、プロキシがそれらのリクエストから Authorization ヘッダーを削除するように構成されていないかを確認します。削除するよう構成されている場合は、リクエストに HTTP ではなく HTTPS を使用していることを確認します。

403: Forbidden

問題: storage.cloud.google.com から一般公開コンテンツをダウンロードしているときに、ブラウザを使用して一般公開オブジェクトに移動しようとすると403: Forbidden エラーが表示されます。

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

解決策: storage.cloud.google.com を使用してオブジェクトをダウンロードする方法を認証済みブラウザでのダウンロードといいます。この方法では、オブジェクトが allUsers に公開されている場合でも常に Cookie ベースの認証を行います。Cloud Audit Logs のデータアクセス ログを構成してオブジェクトへのアクセスを追跡すると、その機能の制限により、認証済みブラウザでのダウンロードを使用して、影響を受けるオブジェクトにアクセスできません。これを試行すると、403 レスポンスが返されます。

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

  • 認証済みブラウザでのダウンロードではなく、未認証のダウンロードをサポートする直接 API 呼び出しを使用します。
  • 影響を受けるオブジェクトへのアクセスを追跡する Cloud Storage のデータアクセス ログを無効にします。データアクセス ログはプロジェクト レベル以上で設定されます。また、複数のレベルで同時に有効にすることもできます。
  • データアクセス ログの除外を設定して、データアクセス ログから特定のユーザーを除外します。これにより、こうしたユーザーが認証済みブラウザでのダウンロードを実行できるようになります。

409: Conflict

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

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

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

429: Too Many Requests

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

解決策: Cloud Storage で特定のリソースに許可されるリクエスト数の上限に達しました。Cloud Storage の上限については、Cloud Storage の割り当てをご覧ください。ワークロードでバケットに対して毎秒 1,000 件のリクエストが発生する場合は、リクエスト レートとアクセス配信のガイドラインで、ワークロードの段階的な増加や連続したファイル名の回避などのベスト プラクティスをご確認ください。

Google Cloud Console のエラーを診断する

問題: Google Cloud Console を使用してオペレーションを実行すると、汎用のエラー メッセージが表示されます。たとえば、バケットを削除しようとするとエラー メッセージが表示されますが、オペレーションが失敗した詳しい理由は表示されません。

解決策: Google Cloud Console の通知を使用して、失敗したオペレーションに関する詳細情報を確認します。

  1. Google Cloud Console のヘッダーにある [通知] ボタンをクリックします。

    Notifications

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

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

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

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

    次に、バケット削除オペレーションが失敗したときのエラー情報の例を示します。これは、バケット保持ポリシーによりバケットが削除されなかったことを表しています。

    バケット削除エラーの詳細

gsutil のエラー

発生する可能性のある gsutil のエラーは次のとおりです。

gsutil stat

問題: gsutil stat コマンドを使用してサブディレクトリのオブジェクトのステータスを表示しようとしましたが、エラーが発生しました。

解決策: Cloud Storage はバケットのオブジェクトの保存にフラットな名前空間を使用しています。 オブジェクト名にスラッシュ(/)を使用してオブジェクトが複数の階層からなる構造の中にあるように見せることはできますが、gsutil stat コマンドは最後のスラッシュをオブジェクト名の一部として扱います。

たとえば、コマンド gsutil -q stat gs://my-bucket/my-object/ を実行すると、gsutil は、my-bucket/my-object/ の下にネストされているオブジェクトへの操作とは異なり、オブジェクト my-object/ に関する情報を最後のスラッシュを含めて検索します。その名前のオブジェクトが存在しない場合、オペレーションは失敗します。

サブディレクトリを一覧表示するには、代わりに gsutil ls を使用します。

gcloud auth

問題: gcloud auth コマンドを使用して gsutil を認証しようとしましたが、バケットまたはオブジェクトにアクセスできません。

解決策: システムにスタンドアロン版と Cloud SDK の両方がインストールされている場合があります。gsutil version -l コマンドを実行して、using cloud sdk の値を確認します。False と指定すると、システムがコマンドを実行するときにスタンドアロンの gsutil が使用されます。このバージョンの gsutil をシステムから削除するか、gsutil config コマンドを使用して認証できます。

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

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

HTTPS によるサービスの提供

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

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

ドメインの所有権の証明

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

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

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

アクセスできないページ

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

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

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

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

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

解決策: オブジェクトまたはバケットに対して setIamPolicy 権限があることを確認します。この権限は、Storage Admin ロールなどで付与されています。setIamPolicy 権限があるにもかかわらずエラーが表示される場合は、バケットが公開アクセスの防止の対象である可能性があります。公開アクセスの防止により、allUsers または allAuthenticatedUsers にアクセスすることはできません。公開アクセスの防止は、バケットに直接設定されるか、上位レベルで設定された組織のポリシーによって適用される場合があります。

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

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

解決策: ウェブ コンテンツ タイプがないオブジェクトとして MainPageSuffix を指定すると、ページは表示されず、ページにアクセスしたユーザーはコンテンツをダウンロードするように求められます。この問題を解決するには、content-type メタデータ エントリを適切な値(text/html など)に更新します。これを行う方法については、オブジェクトのメタデータを編集するをご覧ください。

レイテンシ

レイテンシについて発生する一般的な問題は次のとおりです。また、Google Cloud ステータス ダッシュボードで、Cloud Storage などの Google Cloud サービスに影響するリージョン インシデントやグローバル インシデントの情報を確認できます。

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

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

解決策: gsutil perfdiag コマンドを使用して、影響を受けている環境からパフォーマンス診断を行います。アップロードとダウンロードのレイテンシに関して、次の一般的な原因を考慮してください。

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

  • ディスク I/O の制約: gsutil perfdiag コマンドの一部として、rthru_file および wthru_file テストを使用して、ローカル ディスクの I/O がパフォーマンスに及ぼす影響を測定します。

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

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

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

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

解決策: gsutil とクライアント ライブラリはいずれも、必要に応じてリクエストを自動的に再試行します。この動作により、エンドユーザーからはレイテンシが増加しているように見える場合があります。Cloud Monitoring の指標 storage.googleapis.com/api/request_count を使用して、Cloud Storage が再試行可能なレスポンス コード(4295xx など)を返しているかどうかを確認します。

プロキシ サーバー

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

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

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

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

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

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

次のステップ