ownCloud Infinite ScaleとNextcloud 28の比較：パフォーマンスとRAM使用量について解説

ownCloud Infinite ScaleとNextcloud 28はどちらもセルフホスト型のファイル同期と共有機能を提供できますが、その実現方法は大きく異なります。この違いは、メモリ負荷、リクエスト遅延、スケーリング動作、そしてデプロイメントに必要なチューニング作業量を予測する際に重要になります。

まず最も重要な注意点として、「Infinite ScaleはX MB、Nextcloud 28はY MBを使用する」といった信頼できる普遍的な数値は存在しません。RAMの消費量は、有効化されたサービス、同時ユーザー数、バックグラウンドジョブ、ストレージバックエンド、PHPワーカー数、キャッシュ、プレビュー、オフィス統合、アプリケーションなどによって変化します。公式ドキュメントにも両製品ごとに異なるメモリ使用量に関するガイダンスが掲載されているため、これらの数値を直接的なベンチマークとして扱うのは誤解を招く可能性があります。

ライフサイクルに関する問題もあります。Nextcloud 28（Hub 7とも呼ばれる）は2023年12月にリリースされ、2024年12月にサポートが終了しました。28.x の最終リリースは28.0.14です。2026年10月以降は、通常のバグ修正やセキュリティアップデートは提供されなくなります。したがって、この比較は、既存のNextcloud 28のインストール状況を把握したり、移行を計画したりする場合には役立ちますが、新しいNextcloud 28の導入を推奨する場合には適していません。Nextcloudの公式メンテナンスおよびリリーススケジュールを参照してください。

アーキテクチャの違いが、パフォーマンス上のトレードオフの大部分の原因となっている。

ownCloud Infinite Scale（設定やドキュメントではoCISと略されることが多い）は、Go言語のサービス群として構築されています。デフォルトのランタイムでは、単一のプロセス内で組み込みサービスを起動し、組み込みのスーパーバイザーで監視できます。ownCloudによると、この設計によりメモリ使用量を削減できるだけでなく、デプロイメントのスケールアウトが必要な場合には、個々のサービスを他のノードに移動することも可能です。このプラットフォームは、コア操作にPHPや従来のアプリケーションデータベースを必要としません。詳細については、公式のInfinite ScaleアーキテクチャドキュメントとInfinite Scale管理概要を参照してください。

Nextcloud 28は、おなじみのPHPウェブアプリケーションモデルを採用しています。一般的な運用環境のスタックには、ApacheやNginxなどのウェブサーバー、PHPまたはPHP-FPMワーカー、サポートされているリレーショナルデータベース、そして通常はメモリキャッシュが含まれます。Nextcloudの公式ドキュメントでは、ローカルキャッシュにはAPCu、組織的なデプロイメントにおける分散キャッシュとトランザクションファイルロックにはRedisを推奨しています。これによりNextcloudは非常に柔軟になりますが、同時に、メモリ予算全体が1つのサーバープロセスではなく、複数の独立したプロセスとサービスに分散されることを意味します。

RAM使用量：公式数値が実際に意味すること

ownCloudの現在の本番環境導入例では、最低4～6GBのメモリを推奨しており、ウイルス対策スキャンを有効にすると追加のメモリが必要になると明記しています。この数値は「oCIS自体が常に4～6GBを消費する」という意味ではありません。ドキュメントに記載されている設定には、オフィスパッケージやその他の必要なコンポーネントも含まれています。詳細については、公式のInfinite Scale本番環境導入例を参照してください。

Nextcloud 28 の要件に関するドキュメントでは、従来とは異なるアプローチが取られています。RAM の必要量はユーザー、アプリ、ファイル、アクティビティによって大きく異なると述べ、プロセスごとに最小 128 MB、推奨 512 MBを指定しています。これは、複数のワーカー プロセスが同時にアクティブになる可能性がある PHP-FPM では特に重要です。そのため、高並行処理用に構成されたサーバーは、プロセスごとの値よりもかなり多くのメモリを確保できます。Nextcloud 28 のシステム要件を参照してください。

ファイル中心のワークロードにおいて、どちらの方が動作が軽く感じられる可能性が高いでしょうか？

ワークロードが主に認証、ブラウジング、同期、アップロード、ダウンロード、共有である場合、Infinite ScaleのGoランタイムとサービス設計は、PHPリクエストスタックに関連するオーバーヘッドの一部を削減できます。ownCloudは、サービス通信の一部にgRPCなどのバイナリプロトコルを内部的に使用しています。アーキテクチャ的に、これによりInfinite ScaleはPHPワーカープロセスを増やすことなく、高い並行処理能力を実現するための確実な道筋を得ることができます。

これは、普遍的なスループットの優位性を保証するものではありません。ストレージのレイテンシはファイル操作に大きな影響を与える可能性があり、TLSやリバースプロキシはオーバーヘッドを増加させ、メタデータの動作は選択したストレージドライバに依存し、オプションのサービスによってプロファイルが変わります。ownCloudのストレージに関するドキュメントでは、ローカルストレージ、NFS、S3をバックエンドとするデプロイメントごとに、メモリとパフォーマンスの最適化方法が異なることが明示的に説明されています。Infinite Scaleのストレージに関する考慮事項を参照してください。

Nextcloud 28 は、適切にチューニングすれば優れたパフォーマンスを発揮します。ドキュメントによると、メモリ キャッシュはサーバーのパフォーマンスを大幅に向上させることができます。APCu は頻繁に使用される PHP オブジェクトをローカルで繰り返し再構築することを回避し、Redis は分散キャッシュ データとトランザクション ファイル ロックを処理できます。単一の組織サーバーの場合、Nextcloud 28 はローカル キャッシュに APCu を、分散キャッシュとロックに Redis を使用することを推奨しています。Nextcloud 28 のメモリ キャッシュに関するドキュメントを参照してください。

NextcloudのRAMはどこに使われるのか

Nextcloud 28 では、「Nextcloud の RAM 使用量」は実際には複数の予算の合計です。PHP-FPM ワーカーは、有効になっている PHP モジュールとアプリケーション コードに応じてメモリを消費します。データベースは独自のバッファと接続メモリを必要とします。Redis はキャッシュされたオブジェクトとロックのためにメモリを消費します。APCu は各 PHP 環境にローカル キャッシュを保持します。プレビュー生成、ウイルス対策統合、Talk、全文検索、サードパーティ アプリケーションは、独自のプロセスやバックグラウンド アクティビティを追加する可能性があります。

このモデルでは、管理者は多くの調整手段を利用できます。PHP-FPMワーカーの制限を減らすことで、RAMが限られた小規模サーバーでも動作を維持できますが、負荷がかかるとリクエストがキューイングされる可能性があります。ワーカー数を増やすと、CPU、RAM、データベース接続、またはI/Oがボトルネックになるまで並行処理が向上します。低メモリ環境では、ローカルキャッシュにRedisを使用することでメモリを節約できますが、Nextcloudの公式ドキュメントによると、十分なRAMが利用可能な場合は、ローカルキャッシュにはAPCuの方が高速です。これは、すべてのホストに推奨される単一の設定ではなく、パフォーマンスとメモリのトレードオフです。

Infinite ScaleのRAMがどこに行くのか

Infinite Scaleも多数の論理サービスで構成されていますが、組み込みランタイムは1つのプロセス内で組み込みサービスを管理し、各サービスをGoルーチンで実行できます。ownCloudはこの仕組みを、分散デプロイメントのために個々のサービスを分離しつつ、プラットフォームを管理しやすい方法でパッケージ化するものだと説明しています。組み込みスーパーバイザーは障害が発生したサービスを再起動する機能も備えており、外部スーパーバイザーで全てのサービスを実行する場合と比較してメモリ使用量を削減できることが明記されています。

統合によって、単一ホスト上でのリソース動作の理解は容易になりますが、RAM使用量が固定されるわけではありません。CollaboraやOnlyOffice、ウイルス対策スキャン、外部IDサービス、RedisやNATSベースのコンポーネント、サムネイル処理、あるいはより大きなキャッシュを追加すると、フットプリントが変化します。サービスを個別のコンテナやKubernetesポッドに移動すると、分離性と水平スケーラビリティが向上する一方で、ベースラインのオーバーヘッドが増加する可能性があります。

ワークロード別のパフォーマンス比較

それらを公平に評価する方法

パフォーマンスが決定的な要素となる場合は、コミュニティのスクリーンショットや個別のメモリ数値に頼るのではなく、同じハードウェア上で両製品のベンチマークテストを実施してください。ストレージデバイスまたはバックエンド、ネットワークパス、TLS終端方式、テストファイルセット、ユーザー数、クライアント動作はすべて同じものを使用してください。定常状態の結果を記録する前にキャッシュをウォームアップするとともに、コールドスタート時の動作も別途測定してください。

有用な指標としては、ディレクトリ一覧表示、メタデータ操作、小ファイルアップロード、大ファイルアップロード、ダウンロード、共有作成のレイテンシの中央値と95パーセンタイル値、1秒あたりの完了リクエスト数、関連するすべてのプロセスにおける常駐メモリの合計、CPU使用率、ストレージIOPS、Nextcloudのデータベースレイテンシ、バックグラウンドジョブの影響などが挙げられます。アイドル状態のRAMは、負荷がかかっていないRAMとは別に測定してください。アイドル状態では小さく見えるシステムでも、同時使用時にははるかに多くのメモリが割り当てられる可能性があるためです。

Nextcloudの場合は、Webサーバー、PHP-FPM、データベース、Redis、およびその他のアプリケーションサービスを含めてください。Infinite Scaleの場合は、oCISサービスに加えて、リバースプロキシ、IDコンポーネント、オフィス統合、キャッシュ、およびストレージ関連サービスを含めてください。そうしないと、ベンチマークを装ったアーキテクチャ比較になってしまいます。

どちらを選ぶべきでしょうか？

最新のファイル中心プラットフォームを最優先事項とし、Go言語ベースのサービスアーキテクチャを重視し、PHPワーカーとコアサーバーに必要なリレーショナルデータベースを組み合わせた運用モデルを避けたい場合は、 ownCloud Infinite Scaleを選択してください。水平方向のサービス拡張や大規模なファイル共有環境を計画している組織にとって特に魅力的なソリューションです。

Nextcloudアプリのエコシステム、グループウェアとの連携、既存の管理知識、またはアプリケーションの互換性が、ランタイムレイヤーの最小化よりも重要な場合は、サポートされているNextcloudリリースを選択してください。現在Nextcloud 28を使用している場合、パフォーマンスチューニングは短期的には役立つ可能性がありますが、バージョン28は2024年12月以降サポート対象外となっているため、セキュリティライフサイクルを考慮すると、アップグレードを計画する方がより適切な理由となります。

決定の焦点がRAMにある場合、どちらのベンダーが公開している要件も、どちらが優れているかを断言する根拠にはなりません。Infinite Scaleのアーキテクチャは、PHPと従来のアプリケーションデータベースをコアスタックから排除し、効率的なサービス実行を意図的に実現するように設計されています。一方、Nextcloudは成熟したキャッシュ制御と高度に設定可能なPHP同時実行機能を提供しています。適切な選択は、実際に運用する予定の完全な本番環境スタックを、同じワークロードで比較し、個々のプロセスではなくシステム全体のRAMを測定することです。