Googleドライブのパフォーマンスを低下させない推奨設定 — AODocs KB(翻訳)

概要

原著者のご好意により許諾を得てKBを翻訳・公開いたします。


aodocs.comより

太字は訳文で追加いたしました。

Googleドライブのパフォーマンスを低下させない推奨設定 — AODocs KB(翻訳)

デプロイするドキュメント数が膨大な場合や、Googleドライブ上でのユーザー数が非常に多い場合(100人以上)には、GoogleドライブのUIのレスポンスタイムが増加したり、検索結果が不完全になったり、不定期にエラーメッセージが表示されたりするなどのパフォーマンス上の問題が発生する可能性があります。

本記事では、Googleドライブの個別のユーザーやチームがこうした問題を避けるためのベストプラクティスをご紹介します。GoogleドライブやAODocsに大量のコンテンツをインポートする前には、以下に記載されている情報のほかにAODocsの技術サポートチームにお問い合わせいただくことを強くおすすめいたします。ドキュメントのインポート時にパフォーマンス上の問題を回避するベストな戦略を見いだせるよう弊社チームが支援いたします。

ガイドライン

最も重要なガイドラインを以下に示します。

  • ドキュメントのオーナー権限(ownership)を集約する目的でグローバルな企業アカウントを用いる場合、大量のドキュメントを多数のユーザーが共有し、かつユーザーの利用頻度が非常に高い(ドキュメントを頻繁に更新するなど)状況でパフォーマンス上のボトルネックが発生する可能性があります。単一のAODocsライブラリに保存できるドキュメント数に厳密な上限はありませんが、AODocsできわめて多数のドキュメント(数万件)を扱う計画がおありの場合は、弊社技術サポートチームまでお問い合わせいただくことを強くおすすめいたします。弊社チームより、パフォーマンス低下を回避するAODocsドメインを設定するうえで有用なベストプラクティスおよびお客様に合わせた最適なガイドラインを提供いたします。ベストプラクティスについては本記事のセクションにて後述いたします。
  • Googleドライブでの共有パーミッション更新作業は低速です。特に、ファイル数が極めて多い場合や、関連する共有パーミッションが極めて多い場合(項目数が非常に多いフォルダに対して多数の共有パーミッションを追加または削除する状況や、パーミッションの更新をフォルダ内の全項目に対して反映する必要がある場合などが典型例です)に著しく速度が低下します。この問題を緩和するには、ファイルやフォルダに適用する共有パーミッションの個数を最小限に抑えることが極めて重要です。そのためには、可能な限りパーミッションを個別のユーザーではなくGoogleグループに割り当てるのがベストです。制限事項についてはこの後のセクションで後述します。
  • 多数のエンドユーザーの[マイドライブ] フォルダに共有フォルダを追加すると、パフォーマンス上の問題につながる可能性があります。あるフォルダ構造を多数のユーザー(数千人)で共有する必要がある場合は、ユーザーの[マイドライブ]フォルダへのプッシュは避け、別の共有方法を検討すべきです(AODocsのUI経由でアクセスできるAODocsライブラリを用いるとか、Googleサイトを用いるなど)。制限事項についてはこの後のセクションで後述します。

アカウントごとの制限事項

Googleドライブは百万単位のユーザー数に対応できる設計の、極めてスケーラブルなプラットフォームですが、Googleドライブのインフラではアカウントごとの処理能力に制約が設けられています。

上述のとおり、「多数のファイル」「多数の共有パーミッション」「頻繁なファイル操作」が組み合わさると、そのファイルを所有しているGoogleドライブアカウントが「オーバーロード」状態になり、エンドユーザー側でのパフォーマンスが目に見えて低下します。この問題が発生する可能性を避けるために、弊社では以下をおすすめいたします。

  • AODocsに保存されるコンテンツを複数のライブラリに分割する
  • Googleドライブで十分な個数のサービスアカウントを割り当て、Googleドライブの負荷をそれらのアカウントに分散する

弊社サポートチームでは、お客様固有のパラメータに応じた適切なストレージアカウント数の決定を支援いたします。

オーナーシップの譲渡と「最初の」オーナー権限の重要性

Googleドライブでは、あるファイルのオーナー権限を同一G Suiteドメイン内の別アカウントに譲渡できます。1つのファイルのオーナーは1人に限定されるため、ファイルのオーナー権限をアカウントAからアカウントBに譲渡する場合、アカウントBはそのファイルの新しいオーナーになり、そのオーナー権限に関連する以下の特権が与えられます。

  • そのファイルの削除(ゴミ箱への移動なども)はユーザーBのみ可能
  • そのファイルのサイズの分、ユーザーBのストレージ容量(quota)は減少する
  • ファイルのオーナー権限を別アカウントに譲渡できるのはユーザーBに限られる
  • そのファイルの共有パーミッションを他の編集者が更新できるかどうかはユーザーBのみ指定可能

ただしパフォーマンスを考慮すると、そのファイルは元のオーナー(ユーザーA)にまだ紐付けられており、上述のアカウント単位の制限事項は、オーナーがユーザーAのまま変わっていないかのように適用されます。その結果、Googleドライブに大量のファイルを保存する場合のストレージ戦略を定義する場合は、それらのファイルの「最終オーナー」の数とともに、「元のオーナー」(ファイルを最初に作成またはアップロードしたアカウントなど)の数も考慮しておく必要があります。

たとえば、30万件のファイルを保持しているオンプレミスのファイルサーバーをGoogleドライブに移行する場合を考えてみましょう。弊社チームの推奨事項に従えば、割り当てるGoogleドライブアカウントは5人とし、あらゆるファイルを「偏りなく」その5つのアカウントに割り当て、1つのアカウントが最終的に6万ファイルのオーナーになるようにします(ライブラリが今後肥大化する余地も見込んであります)。コンテンツのアップロードには以下のシナリオが考えられます。

シナリオ1

自動移行ツール(AODocsが提供するファイルサーバー移行ツールなど)を用いて、割り当てられたGoogleドライブアカウントに対して直接ファイルをアップロードする。

  • この場合オーナー権限の譲渡は発生せず、各ファイルの「最初のオーナー」がそのまま「最終オーナー」となります。上述のパフォーマンス制約は、最終的なストレージアカウントに通常どおり適用されます。

シナリオ2

クラウドソース式アップロード: ユーザー数が多い場合(たとえば100ユーザーとします)は各自の[マイドライブ]フォルダに手動でファイルをアップロードしてもらい、その後にファイルのオーナー権限を最終的なストレージアカウントに譲渡する(AODocsのフォルダインポート機能を使うなどの方法で)ことを弊社からお客様に依頼します。

  • この場合、AODocsに30万個のファイルにはそれぞれ異なる「最初のオーナー」が100人いることになり、しかも「最初のオーナー」ごとのファイル数が多くなりすぎないので、期待どおりパフォーマンスの問題は発生せずに済みます。

シナリオ3

一括アップロード: 30万件のファイルを1つのGoogleアカウントでアップロードし、その後にオーナー権限を最終的なストレージアカウントに譲渡します。

  • この場合、最終的なオーナーが所有するファイルは3万件を超えないにもかかわらず、「元のオーナー」1人がいったん全30万件のファイルを所有する形になり、上述したパフォーマンスボトルネックがこのアカウントで発生することになります。

弊社ではシナリオ1をおすすめしています。「元のオーナー」と「最終オーナー」がシンプルに一致するというメリットがあるので、不測の事態や副作用の心配がないためです。

シナリオ2は、ユーザー1人あたりの最大アップロードファイル数が十分小さい(数千程度)場合に限って利用可能です。

シナリオ3は上述の制約をことごとく超えてしまうため、何としても避けるべきです

パーミッションを共有するときのパフォーマンス

Googleドライブで「サーバーの負荷」となる最大の原因は、パーミッション共有の操作です。1件のファイルやフォルダにパーミッションを1つ追加または削除するたびにGoogleドライブサーバーの内部でデータベースを更新しなければなりません。このため、Googleドライブのサーバーの負荷は、ファイルやフォルダごとのパーミッション共有の平均件数に強く関連します。

パーミッションの変更は、Googleドライブで明示的に共有や共有解除の操作を行ったときだけではなく、項目を別の親フォルダに移動したときにも発生します。追加されるコンテンツに、新しい親の共有パーミッションが適用されるためです。

たとえば、ファイルが100件ある経理書類というフォルダをユーザー2名で共有し、それとは別に財務というフォルダをユーザー10名(うち2名は経理書類にもアクセス可)で共有しているとしましょう。このとき誰かが経理書類フォルダを財務フォルダの中に移動すると、Googleドライブは経理書類フォルダ内のすべてのファイルにユーザーを8名追加しなければならず、808パーミッションの変更が必要になります(経理書類フォルダ自身に8名、個別のファイルに8名)。

したがって、共有されているドキュメントの集まり全体のパフォーマンスは、「総ファイル数」および「ファイルごとに追加または削除される共有パーミッションの件数」におおよそ「比例」します。この影響を緩和するために、共有パーミッションの設定には少数のGoogleグループを用い、個別のアカウントを大量に用いないことを強くおすすめします。

個別のユーザー10名を、(同じユーザー10名を含む)1つのGoogleグループに置き換えることでパフォーマンスが著しく向上するでしょう。そのグループに11番目のユーザーを追加してもパーミッションの変更は不要です(既にそのグループでファイルを共有済みなので)。しかし11番目のユーザーを共有フォルダに追加してしまうと、フォルダ内のファイルの数だけパーミッション変更が繰り返し発生してしまいます。ここでご注目いただきたいのは、GoogleドライブとAODocsはどちらも「グループのネスト」(他のグループのメンバーをグループに含めること)を完全にサポートしていることです。つまり、1つのGoogleグループに複数のGoogleグループを含めることで、大量の共有パーミッションを置き換えることもできるのです。

Googleドライブで行ったいくつかのデプロイを測定したところ、ドキュメントを1万件含むフォルダツリー1つに対していくつかのパーミッションを更新するだけで4時間以上かかることがあります。

フォルダの「サブスクリプション」

あるユーザーの[マイドライブ]にファイルかフォルダを1つ追加すると、そのユーザーはその項目に「サブスクライブされた(subscribed)」とみなされ、以後そのユーザーのGoogleドライブアカウントからそのファイルやフォルダにアクセスできるようになります(キーワード検索の検索結果に表示されるようになるなど)。この登録による紐づけは、Googleドライブの全文テキスト検索/監査ログ/アクティビティパネルなどのバックオフィス活動に関連する内部動作に若干影響が生じます。この紐づけの本当の効果とは、そのユーザーの[マイドライブ]内のファイルやフォルダ([マイフォルダ]内のサブフォルダ内も含む)を変更するたびにそのユーザーに通知が送信され、それによって全体のパフォーマンスに影響が生じることです。個別の通知のコストは大したことはありませんが、1つのファイルやフォルダの「サブスクライバ」が数千人にものぼる場合(数千人ものユーザーが各自の[マイドライブ]フォルダ内に同一のファイルかフォルダを持っている場合など)、パフォーマンスが著しく低下します。

Googleドライブのインフラ設計ではこのようなシナリオのサポートは想定されていないため、弊社では1つのファイルまたはフォルダの「サブスクリプション」を300人未満に抑える(1つのファイルやフォルダを300人以上の[マイドライブ]に決して配置しないようにするなど)ことを強くおすすめします。上述の共有におけるパフォーマンスの場合と異なり、「サブスクリプション」の制限事項はファイルやフォルダの共有方法とは無関係です。項目を単一のGoogleグループで共有しようと、複数のGoogleグループで共有しようと、ユーザーのリストで明示的に共有しようと、AODocs Pushを用いて[マイドライブ]の項目に追加される「サブスクリプション」の個数はまったく同じです。AODocsはどのシナリオであろうと、最終的にフォルダを個別のユーザーの[マイドライブ]フォルダに追加します。

関連記事

Googleスプレッドシートのセル内に画像をぴったり表示する方法

ExcelやGoogleスプレッドシートにデータをためるときに気をつけていること

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

関連する記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ