ownCloud Infinite Scale 用の S3 オブジェクトストレージの設定方法

ownCloud Infinite Scaleは、ファイルブロブにはS3互換のオブジェクトストレージを使用し、ファイルメタデータはPOSIX準拠のファイルシステム上に保持することができます。まず理解すべきは、この分離という概念です。S3は、あらゆるローカルデータディレクトリの代替としてそのまま使えるわけではありません。サポートされているs3ng構成では、オブジェクトストレージにバイナリファイルコンテンツが格納され、メタデータはローカルファイルシステムやNFSなどのPOSIXストレージ上に保持されます。

このガイドは、2026年10月時点で公開されているownCloud Infinite Scaleストレージの最新ドキュメントに基づいています。このガイドは、s3ngドライバーを初めて使用する管理者向けに作成されており、Docker Compose、systemd、Kubernetes、またはその他のデプロイ方法に適用する前に、構成を理解できるようになっています。

このガイド全体を通して使用されている公式リファレンスは、ownCloud S3ストレージのドキュメント、Storage-Usersサービス構成、および一般的なストレージに関する考慮事項です。

ownCloud Infinite ScaleにおけるS3の意味

S3は、Amazonが最初に導入したオブジェクトストレージAPIです。S3互換サービスは、データをバケット内にオブジェクトとして保存し、HTTPベースのAPIを通じて操作を提供します。ownCloud Infinite Scaleは、s3ngストレージドライバを使用して、ファイルブロブをこのようなバケットに配置します。

POSIXストレージとは、Infinite Scaleがメタデータに対して期待するファイルシステム動作を提供するファイルシステムのことです。この場合s3ng、メタデータはS3バケットに移動されません。ownCloudは、ブロブはS3に移動されるがメタデータはPOSIXストレージ上に残ることを明示的に文書化しています。

この区別によって、よくある間違いを防ぐことができます。それは、Infinite Scaleをバケットに指定して、サーバーの状態全体がそこに保存されていると誤解してしまうことです。実際にはそうではありません。バックアップとリカバリの計画では、POSIX側のメタデータとS3側のブロブの両方を網羅する必要があります。

ステップ1：バケット、メタデータストレージ、認証情報、およびネットワークパスを準備する

Infinite Scaleを変更する前に、次の4つのものを準備してください。

• 専用のS3バケット。
• メタデータ用のPOSIX準拠パスs3ng。マルチノード展開の場合、ownCloudは共有ストレージについて慎重に検討することを推奨します。複数のInfinite Scaleインスタンスがメタデータパスにアクセスする必要がある場合は、NFSが一般的に使用されます。
• Infinite Scaleが必要とするバケット権限のみを持つアクセスキーとシークレットキー。
• Infinite ScaleのホストまたはコンテナからS3エンドポイントへのネットワーク接続性（通常はHTTPS経由）。

バケットを公開しないでください。Infinite Scaleは認証情報を使用してバケットへの認証を行うため、パブリックアクセスは不要であり、また望ましくもありません。また、専用のサービスIDを作成できる場合は、広範な管理者認証情報を再利用しないようにしてください。

Amazon S3を使用する場合、エンドポイントとリージョンはAWSの規約に従います。他のS3互換プロバイダーを使用する場合は、そのプロバイダーのドキュメントでエンドポイントの形式、リージョンの動作、TLS要件、ポリシー構文を確認してください。ownCloudは、暗号化の詳細などの動作がプロバイダーによって異なる場合があることを特に警告しています。

ステップ2：s3ngドライバを有効にし、S3接続設定を指定します。

コアストレージ設定は ですSTORAGE_USERS_DRIVER=s3ng。Storage -Usersサービスは、ユーザーファイルのストレージを担当する Infinite Scale コンポーネントです。公式構成では、システムストレージドライバも通常のocisバックエンドに維持されます。

最小限の環境変数セットは次のようになります。

STORAGE_USERS_DRIVER=s3ng
STORAGE_USERS_S3NG_ROOT=/var/lib/ocis/storage/users
STORAGE_SYSTEM_DRIVER=ocis

STORAGE_USERS_S3NG_ENDPOINT=https://s3.example.com
STORAGE_USERS_S3NG_REGION=us-east-1
STORAGE_USERS_S3NG_ACCESS_KEY=YOUR_ACCESS_KEY
STORAGE_USERS_S3NG_SECRET_KEY=YOUR_SECRET_KEY
STORAGE_USERS_S3NG_BUCKET=ocis-files

例示されている値はプレースホルダーです。プロバイダから発行されたエンドポイント、リージョン、バケット、および認証情報を使用してください。秘密鍵を公開 Git リポジトリにコミットしないでください。コンテナオーケストレーションでは、認証情報を Compose ファイルやマニフェストに直接埋め込むのではなく、プラットフォームのシークレット管理メカニズムを使用することをお勧めします。

デプロイ方法によって、これらの変数の配置場所が決まります。Docker Compose によるデプロイでは、Infinite Scale サービスのenvironmentセクションに配置するか、環境ファイルから読み込むことができます。systemd によるデプロイでは、環境ファイルまたはユニット構成を使用できます。Kubernetes では、通常、Secret と Deployment または StatefulSet を介してこれらの変数を挿入します。重要なのは変数名であり、周囲の構文はプラットフォームによって異なります。

ステップ3：Infinite Scaleに必要なバケット権限を付与する

バケットポリシーとは、認証されたIDがバケットとそのオブジェクトに対して実行できるアクションを制御する、IDおよびアクセス管理（IAM）ルールです。ownCloudは、s3ngドライバに必要なポリシーパターンを公開しています。

bucket-name以下のポリシー内の「実際のバケット名」を置き換えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket-name"]
    },
    {
      "Sid": "ActionsInBucketContext",
      "Effect": "Allow",
      "Action": [
        "s3:*Object",
        "s3:*MultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": ["arn:aws:s3:::bucket-name/*"]
    }
  ]
}

アクセス拒否エラーを解決するために、s3:*アカウント内のすべてのバケットに権限を付与しないでください。まずはドキュメントに記載されているバケット単位の権限から始め、S3プロバイダーがプロバイダー固有の同等の権限を要求する場合にのみ、それに応じて権限を調整してください。

ステップ4：Infinite Scaleを再起動し、ストレージパスを確認します。

デプロイメントの通常の再起動手順に従って設定を適用してください。たとえば、systemd インストールでは を使用しsystemctl restart ocis、Compose デプロイメントでは影響を受けるサービスコンテナを再作成または再起動します。起動直後にログを確認し、認証、DNS、TLS、リージョン、または権限のエラーがないか確認してください。

S3プロバイダのCLIを使用してバケット一覧を表示することで、ホストと認証情報がバケットにアクセスできることは確認できますが、それだけではInfinite Scaleが正しくブロブを書き込んでいることは証明されません。より適切なエンドツーエンドテストは、Infinite Scaleを起動し、ownCloudのWebインターフェースから小さなファイルをアップロードし、再度ダウンロードして、サービスログでエラーを確認することです。

インストールされている Infinite Scale バージョンに ownCloud がドキュメント化した blobstore メンテナンス コマンドが含まれている場合は、 も使用できますocis storage-users blobstore check。ownCloud では、このコマンドは構成済みの blobstore に対するアップロード/ダウンロード/削除の往復操作であると説明しています。バージョン固有の構文については、公式の blobstore 検証ドキュメントを参照してください。

元のファイル名が通常のS3オブジェクトとして表示されるとは期待しないでください。

よくある誤解の一つは、バケットを閲覧して、<S3> のような見慣れたユーザーフォルダツリーを期待することですDocuments/report.pdf。Infinite Scale は S3 をブロブストアとして扱い、ユーザー向けのファイルシステムとしては扱いません。s3ngドキュメントに記載されているキー形式はスペース ID とブロブ ID に基づいており、人間が読みやすい名前空間はメタデータから再構築されます。

つまり、キーが見慣れないからといって、バケット内のオブジェクトを手動で名前変更、再編成、または削除してはいけません。ユーザーファイルはownCloudを通して管理してください。バケットを直接操作すると、メタデータとブロブ間の関係が壊れる可能性があります。

大容量ファイルのアップロード：制作前にマルチパートファイルのサイズを確認してください

S3はマルチパートアップロードを使用して、大きなオブジェクトを複数のパートに分割します。ownCloudのドキュメントにSTORAGE_USERS_S3NG_PUT_OBJECT_PART_SIZEは、パートサイズを制御する方法が記載されています。明示的な値が指定されていない場合、ドキュメントに記載されているデフォルト値は16MiBです。

Amazon S3では、1回のマルチパートアップロードで最大10,000個のパートを許可しています。1パートサイズが16MiBの場合、パート数の制限に達するまでに約160GiBまでアップロードできます。ユーザーが定期的に大容量ファイルをアップロードする場合は、大規模な転送が失敗するのを待つのではなく、サービス開始前に必要なパートサイズを計算しておくことをお勧めします。

トレードオフは単純明快です。パーティションサイズを大きくすると、リクエスト数を減らしつつ、より大きな最大ファイルサイズに対応できますが、メモリ、バッファリング、再試行、転送特性も変化します。ownCloudは、受信ファイルデータはバッファリング中に一時的なストレージを必要とするため、容量計画にはリモートバケットだけでなく、他の要素も考慮する必要があると指摘しています。

よくある問題とその最初に確認すべきこと

S3ブロブとPOSIXメタデータをまとめてバックアップする

s3ngバケットはストレージ状態の半分にすぎません。ownCloudのバックアップに関するドキュメントによると、分散S3セットアップには、構成、システムデータ、メタデータ、およびブロブを含める必要があります。復元に関するドキュメントでも同様に、これらのデータセットを一貫して復元する必要があるとされています。

本番環境のサービスでは、メタデータのマウントポイント、バケット、認証情報またはロール、構成ファイル、およびバックアップ手順を同じランブックに記述してください。設計に頼る前に、リカバリテストを実施してください。関連する公式資料は、ownCloudのバックアップガイドと復元に関する考慮事項です。

おすすめの出発地点

初回導入時は、設計をシンプルに保ちましょう。ブロブ専用のS3バケットを1つ、永続的なPOSIXメタデータパスを1つ、ドキュメントに記載されているバケット権限を持つ専用のサービスID、オブジェクトストレージエンドポイントへのHTTPS接続、そして想定されるファイルサイズに変更が必要でない限り、デフォルトのマルチパート設定を使用します。

設定後、ネットワークと認証情報によるバケットへのアクセス、ストレージエラーのないInfinite Scaleの起動、ownCloudを介した実際のアップロード/ダウンロードという3つのレイヤーを個別に検証します。これらのチェックに合格したら、監視、バックアップ、ライフサイクルルール、パフォーマンスチューニングに進みます。この手順により、各テストが異なる疑問に答えるため、「S3が正常に動作する」という単一の結果を全か無かで判断するのではなく、トラブルシューティングがはるかに容易になります。