このページでは、Cloud Storage のベスト プラクティスの一覧を示します。このページの情報は、Cloud Storage を使用するアプリケーションを構築する際に留意すべき点のクイック リファレンスとしてお使いください。
このページは Cloud Storage の基本的な使い方を説明するものではありません。Cloud Storage を使い始めたばかりの方は、別のページからご覧になることをおすすめします。初めて利用する場合は、 Google Cloud コンソールでオブジェクト ストレージを検出するまたは gcloud ツールを使用してオブジェクト ストレージを検出するから始めることをおすすめします。
メディア ワークロードのベスト プラクティスについては、メディア ワークロードのベスト プラクティスをご覧ください。
命名
名前に関する要件と考慮事項については、バケットの命名とオブジェクトの命名をご覧ください。
トラフィック
Cloud Storage に送信されるトラフィック量の簡単な見積もりを行います。特に、以下の点を考えてください。
1 秒あたりのオペレーションの回数。バケットとオブジェクトの両方について、また作成、更新、削除オペレーションについて、1 秒あたりにオペレーションを何回行うか。
帯域幅。どれだけの量のデータをどれだけの期間送信するか。計算の誤りを避けるため、Wolfram Alpha などのツールの使用を検討してください。
キャッシュ制御。一般公開のオブジェクトに
Cache-Controlメタデータを指定すると、頻繁にアクセスするオブジェクトの読み込みレイテンシを改善できます。Cache-Controlなどのオブジェクトのメタデータの設定方法については、メタデータの表示と編集をご覧ください。
トラフィックのスパイクが最小になるようにアプリケーションを設計します。アプリケーションのクライアントの中に、更新を行うものがある場合は、1 日の中で分散させてください。
リクエスト レートの高いアプリケーションを設計する場合は、特定のオペレーションのレート制限に注意してください。特定のタイプの下り（外向き）の帯域幅の上限を確認し、リクエスト レートとアクセス配信のガイドラインに従います。最高のパフォーマンスを得るには、自動スケーリングを使用し、リクエスト レートを徐々に増加させる必要があります。
エラーを処理する場合:
大規模なトラフィック バーストによる問題を回避するには、アプリケーションで再試行方法を使用してください。
新しい接続を使用して再試行し、可能であればドメイン名を再度解決してください。こうすれば、再試行すると同じパスを通り、最初のリクエストがヒットしたのと同じ異常コンポーネントにヒットする「サーバー固定性」を回避できます。
アプリケーションでレイテンシが問題になる場合には、ヘッジされたリクエストを使用します。ヘッジされたリクエストを使用すると、再試行が高速化され、テール レイテンシを削減できます。これによってリクエストの期限が早まって、リクエストが早期にタイムアウトになる可能性はありません。詳細については、The Tail at Scale をご覧ください。
顧客がアプリケーションに期待するパフォーマンス レベルを理解しましょう。この情報は、新しいバケットを作成するときにストレージ オプションとリージョンを選ぶのに役立ちます。たとえば、分析アプリケーションでは、コンピューティング リソースを Cloud Storage バケットと同じロケーションに配置することを検討してください。
ロケーションとデータ ストレージ オプション
データを保存する最適な方法については、ストレージ クラスとバケットのロケーションをご覧ください。
ACL とアクセス制御
Cloud Storage リクエストは、バケットとオブジェクトを名前で参照します。その結果、ACL によって不正な第三者がバケットやオブジェクトを操作できないようにしていても、第三者がバケット名やオブジェクト名を使用してリクエストを試行し、エラー レスポンスからバケットやオブジェクトの存在を確認できます。したがって、バケット名やオブジェクト名の情報が漏洩することも考えられます。バケット名やオブジェクト名のプライバシーが心配な場合は、次のような予防策を講じる必要があります。
推測しにくいバケット名やオブジェクト名にする。たとえば、「
mybucket-gtbytul3」のような無作為なバケット名であれば、不正な第三者が名前を容易に推測できなくなります。また、他のバケット名の推測も防ぐことができます。バケット名やオブジェクト名の一部に機密情報を含めないようにする。たとえば、バケット名として
mysecretproject-prodbucketの代わりにsomemeaninglesscodename-prodを指定します。一部のアプリケーションでは、機密性の高いメタデータをオブジェクト名の中にエンコードするのではなく、x-goog-metaなどのカスタム Cloud Storage ヘッダー内に保持するほうが有用な場合があります。
多数のユーザーを明示的に列挙するのではなく、グループの使用をおすすめします。これによりスケーラビリティが向上するだけでなく、多数のオブジェクトのアクセス制御を一度に更新するための非常に効率的な手段も提供されます。さらに、ACL を変更するためにオブジェクトごとにリクエストを発行しなくて済むため、コストが低くなります。
アクセス制御のベスト プラクティスを確認し、実践してください。
Cloud Storage のアクセス制御システムには、オブジェクトが一般公開で読み取り可能であることを指定する機能が含まれています。この権限を公開して書き込むオブジェクトすべてについて、それが意図したものであることを確認してください。いったんインターネットに公開したデータは、多くの場所にコピーされるため、この権限付きで書き込まれたオブジェクトに対する読み取り制御を回復することは、事実上不可能です。
Cloud Storage のアクセス制御システムには、バケットが一般公開で書き込み可能であることを指定する機能が含まれています。この方法でバケットを構成することは多くの点で便利ですが、この権限は使用しないことをおすすめします。違法なコンテンツ、ウイルスなどのマルウェアの配布に悪用される可能性があり、バケットに保存されたコンテンツに対する法的および金銭的な責任はバケットの所有者にあります。
ユーザー アカウントを持たないユーザーが安全にコンテンツを利用できるようにする必要がある場合は、署名付き URL の使用をおすすめします。署名付き URL を使用すると、オブジェクトへのリンクを提供できます。アプリケーションの利用者は、オブジェクトにアクセスするために Cloud Storage での認証を必要としません。署名付き URL を作成するときには、アクセスの種類（読み取り、書き込み、削除）と期間を制御します。
データのアップロード
XMLHttpRequest（XHR）コールバックを使って最新の進捗状況を取得する際、進捗が円滑でない場合でも、接続をいったん閉じて再度開くという操作は行わないでください。これを行うと、ネットワークの輻輳時に不適切な正のフィードバック ループができます。ネットワークが輻輳している場合、XHR コールバックはアップロード ストリームからの確認応答（ACK / NACK）処理の背後に未処理のまま残ることがあり、この状況で接続を閉じて再度開くと、最も余裕がない状況にもかかわらずより多くのネットワーク キャパシティを使用します。
アップロード トラフィックについては、適度に長いタイムアウトを設定することをおすすめします。優れたエンドユーザー エクスペリエンスのために、アプリケーションの XHR コールバックが長時間呼び出されない場合に、クライアント ステータス ウィンドウを更新してメッセージ（「ネットワークが輻輳しています」など）を表示するようなクライアントサイドのタイマーを設定できます。このような状況が発生した場合、接続を閉じて再試行は行わないでください。
各リクエストに必要な帯域幅を削減するための簡単で便利な方法として、gzip 圧縮を有効にする方法があります。この方法では、結果を解凍するために CPU 時間が余分に必要になりますが、ネットワーク費用とのバランスを考えると、時間をかける価値は十分にあります。
通常、gzip 形式でアップロードされたオブジェクトも、gzip 形式で提供されます。ただし、
content-encoding: gzipと圧縮形式のcontent-typeの両方を含むコンテンツをアップロードすると予期しない動作が発生する可能性があるため、この操作はできるだけ避けてください。通信障害でデータのフローが中断してもデータの転送を再開できるように、再開可能なアップロードを使用することをおすすめします。また、XML API マルチパート アップロードを使用して、ファイルの一部を並行してアップロードすることもできます。これにより、全体のアップロードが完了するまでの時間を短縮できる可能性があります。
データの削除
データの削除に関するガイドラインと考慮事項については、オブジェクトの削除をご覧ください。また、データ ライフサイクルを制御する機能を使用して、アプリケーション ソフトウェアまたはユーザーによって誤ってデータが削除されるのを防ぐこともできます。