- IT Tips
READ MORE
原著者のご好意により許諾を得てKBを翻訳・公開いたします。
太字は訳文で設定いたしました。
デプロイするドキュメント数が膨大な場合や、Googleドライブ上でのユーザー数が非常に多い場合(100人以上)には、GoogleドライブのUIのレスポンスタイムが増加したり、検索結果が不完全になったり、不定期にエラーメッセージが表示されたりするなどのパフォーマンス上の問題が発生する可能性があります。
本記事では、Googleドライブの個別のユーザーやチームがこうした問題を避けるためのベストプラクティスをご紹介します。GoogleドライブやAODocsに大量のコンテンツをインポートする前には、以下に記載されている情報のほかにAODocsの技術サポートチームにお問い合わせいただくことを強くおすすめいたします。ドキュメントのインポート時にパフォーマンス上の問題を回避するベストな戦略を見いだせるよう弊社チームが支援いたします。
最も重要なガイドラインを以下に示します。
Googleドライブは百万単位のユーザー数に対応できる設計の、極めてスケーラブルなプラットフォームですが、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万ファイルのオーナーになるようにします(ライブラリが今後肥大化する余地も見込んであります)。コンテンツのアップロードには以下のシナリオが考えられます。
自動移行ツール(AODocsが提供するファイルサーバー移行ツールなど)を用いて、割り当てられたGoogleドライブアカウントに対して直接ファイルをアップロードする。
クラウドソース式アップロード: ユーザー数が多い場合(たとえば100ユーザーとします)は各自の[マイドライブ]フォルダに手動でファイルをアップロードしてもらい、その後にファイルのオーナー権限を最終的なストレージアカウントに譲渡する(AODocsのフォルダインポート機能を使うなどの方法で)ことを弊社からお客様に依頼します。
一括アップロード: 30万件のファイルを1つのGoogleアカウントでアップロードし、その後にオーナー権限を最終的なストレージアカウントに譲渡します。
弊社ではシナリオ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はどのシナリオであろうと、最終的にフォルダを個別のユーザーの[マイドライブ]フォルダに追加します。