Scality RINGの仕組みを理解する：S3互換API・NFS・SMBで使える分散ストレージ

Scality

Last updated at 2026-04-29Posted at 2026-04-29

はじめに

Scality RINGは、複数台のサーバとディスクを束ねて、1つの大きなストレージ基盤として利用するための分散ストレージソフトウェアです。

特徴は、1つのストレージ基盤に対して、複数のアクセス方法を提供できることです。

例えば、同じScality RINGクラスタに対して、

あるサーバからはS3互換APIでオブジェクトストレージとして使う
あるサーバからはNFSでファイルサーバのように使う
Windows系の環境からはSMBで共有フォルダのように使う

といった構成ができます。

Scality RINGは、オブジェクトアクセスだけでなく、NFS、SMB、FUSEなどのファイルアクセスにも対応するストレージ基盤として紹介されています。(株式会社ブロードバンドタワー)

Scality RINGを一言でいうと

Scality RINGは、複数のサーバに搭載されたディスクをまとめて、1つの巨大なストレージとして扱うための仕組みです。

通常のストレージでは、1台のストレージ装置や1台のサーバに容量や性能が依存します。

一方、Scality RINGでは、複数台のサーバをまとめて1つのストレージクラスタとして構成します。

利用者やアプリケーションから見ると、裏側に何台のサーバがあるかを強く意識せずに、大きな1つのストレージとして扱えます。

Scality RINGの基本構成

Scality RINGは、大きく分けると次のような要素で構成されます。

ざっくり言うと、Connectorがアクセス入口で、Storage Nodeが実際にデータを保持する部分です。

アプリケーションはScality RINGの内部構造を直接意識しません。
S3互換API、NFS、SMBなどのプロトコルを使ってConnectorにアクセスします。

Ciscoの資料では、Scality RINGの主要構成要素として、RING Connectors、MESA、Storage Nodes、IO daemons、Supervisorなどが説明されています。(Cisco)

Scality RINGはどうやって構築するのか

Scality RINGは、基本的にはLinuxが動作する複数台のx86サーバ上に構築するソフトウェア定義ストレージです。

Linuxサーバ複数台に役割を持たせて、1つのRINGクラスタとして構成します。

Ciscoの検証資料でも、Scality RINGをRed Hat Enterprise Linux上にデプロイする構成が紹介されています。(Cisco)
また、Scality RINGはStorage Node、Connector、Supervisorなどの要素で構成されます。(Cisco)

構築後のイメージは次のようになります。

構築時に用意する主なもの

Scality RINGを構築する場合、主に次のようなものを用意します。

用意するもの	役割
Linuxサーバ	Scality RINGを動かす土台。Storage NodeやConnectorとして使う
HDD / SSD	実データを保存するディスク
管理ネットワーク	Supervisorから各ノードを管理・監視するためのネットワーク
データネットワーク	S3、NFS、SMBなどのデータ転送に使うネットワーク
Connector用サーバ	S3、NFS、SMBなどのアクセス入口になるサーバ
Supervisor	RING全体の管理・監視を行う管理コンポーネント
ロードバランサ / VIP	S3 Connectorなどを冗長化し、1つのエンドポイントとして見せるために使う

本番環境では、Storage NodeにHDD/SSDを多く搭載した物理サーバを複数台用意し、ConnectorやSupervisorを別サーバまたはVMとして配置する構成が一般的です。
小規模な検証環境ではVMを使う場合もありますが、容量・性能・耐障害性を評価する場合は、実際のディスク本数やネットワーク帯域も重要になります。

Scality RINGの構築は、Linuxサーバ群にStorage Node、Connector、Supervisorという役割を割り当て、ネットワーク・ディスク・アクセス経路を含めて分散ストレージ基盤として設計する作業です。

Scality RINGは商用のエンタープライズ向けストレージ製品です。
そのため、一般的なOSSのように、インターネット上の手順だけで気軽に本番構築するものではありません。

Scality RINGへのアクセス方法一覧

Scality RINGでは、用途に応じて複数のアクセス方法を利用できます。

アクセス方法	種類	主な用途	使い方のイメージ
S3互換API	オブジェクトアクセス	アプリケーションからオブジェクトを保存する	バケットに対してPUT/GETする
AWS CLIのS3コマンド	オブジェクトアクセス	コマンドラインからオブジェクトを操作する	`aws s3 cp`、`aws s3 ls`など
SDK	オブジェクトアクセス	アプリケーションに組み込む	Python、JavaなどからAPI操作
sproxyd	オブジェクトアクセス	RINGネイティブのREST API	キー/バリュー型で直接アクセス
NFS	ファイルアクセス	Linux/UNIX系サーバから利用	`mount -t nfs`でマウント
SMB	ファイルアクセス	Windows系クライアントから利用	共有フォルダとして利用
FUSE / LocalFS	ファイルアクセス	Linux上でローカルFS風に扱う	マウントしてファイル操作
管理GUI / 管理CLI	管理用	状態確認、管理、監視	管理画面や管理コマンドで操作

Scality RINGのConnectorには、S3、sproxyd、NFS、SMB、FUSEなどがあり、オブジェクトアクセスとファイルアクセスの両方に対応します。(株式会社ブロードバンドタワー)

S3互換APIによるオブジェクトストレージとしての利用

Scality RINGは、S3 Connectorを利用することで、S3互換APIによるオブジェクトストレージとして利用できます。

ここで重要なのは、Scality RINGを「ファイルサーバ」としてだけではなく、API経由でデータを保存するストレージとして扱える点です。

アプリケーションやコマンドラインツールは、S3互換APIのエンドポイントに対してリクエストを送ります。
Scality RING側では、S3 Connectorがそのリクエストを受け取り、内部のRINGストレージへデータを保存します。

つまり、利用者から見るとS3互換のオブジェクトストレージとして使えますが、実際のデータはScality RINGの複数ノードに分散して保存されます。

S3互換APIでオブジェクトを保存するとはどういうことか

S3互換APIでは、データを通常のファイルシステムのような「ディレクトリとファイル」ではなく、バケットとオブジェクトという単位で扱います。

用語	意味
バケット	オブジェクトを入れる入れ物
オブジェクト	保存されるデータ本体
オブジェクトキー	オブジェクトの名前。パスのように見える文字列
メタデータ	オブジェクトに付随する情報

例えば、demo-bucketというバケットにlogs/app.logを保存する場合、次のようなイメージになります。

s3://demo-bucket/logs/app.log

ただし、これはLinuxの通常のファイルパスではありません。
S3互換APIにおける「バケット名」と「オブジェクトキー」です。

Scality RINGにS3 Connectorを用意すると、アプリケーションはHTTPベースのAPIを使って、オブジェクトを保存・取得・削除できます。

アプリケーションから見ると、「APIに対してオブジェクトをPUTした」だけです。
しかし裏側では、Scality RINGが複数のStorage Nodeへデータを分散して保存します。

なぜAWS CLIのS3コマンドでScality RINGを操作できるのか

AWS CLIという名前なので、AWS専用のコマンドのように見えます。

しかし、AWS CLIのS3コマンドは、接続先エンドポイントを指定することで、S3互換APIを提供するストレージにもリクエストを送れます。

Scality RING側にS3 Connectorがある場合、そのS3 ConnectorがS3互換APIのエンドポイントとして動作します。

そのため、AWS CLIのS3コマンドで、接続先をScality RINGのS3エンドポイントに向ければ、Scality RING上のバケットやオブジェクトを操作できます。

ポイントは、次の通りです。

Scality RINGがS3互換APIを提供する
AWS CLIのS3コマンドはS3 APIのリクエストを送れる
--endpoint-urlで接続先をScality RINGのS3 Connectorに変更できる
そのため、AWS CLIからScality RINGを操作できる

つまり、次のように理解するとよいです。

AWS CLIを使っているが、アクセス先は--endpoint-urlで指定したScality RINGのS3 Connectorである。

AWS CLIでScality RINGにアクセスする例

ここでは、Scality RINGのS3エンドポイントが次のURLだと仮定します。

https://s3.example.local

プロファイルを作成する

aws configure --profile scality

入力例です。

AWS Access Key ID [None]: <Scalityのアクセスキー>
AWS Secret Access Key [None]: <Scalityのシークレットキー>
Default region name [None]: us-east-1
Default output format [None]: json

リージョン名は環境によって異なるため、実際には管理者から案内された値を使用します。

バケット一覧を確認する

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3 ls

バケットを作成する

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3 mb s3://demo-bucket

ファイルをアップロードする

echo "hello scality" > hello.txt

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3 cp hello.txt s3://demo-bucket/hello.txt

オブジェクト一覧を確認する

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3 ls s3://demo-bucket/

オブジェクトをダウンロードする

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3 cp s3://demo-bucket/hello.txt ./downloaded-hello.txt

よりAPIに近い操作をする

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3api head-object \
  --bucket demo-bucket \
  --key hello.txt

aws s3は高レベルなファイル操作風のコマンドです。
一方、aws s3apiはよりAPIに近い操作を行うためのコマンドです。

NFSでアクセスする場合

Scality RINGは、S3互換APIだけでなく、NFSによるファイルアクセスにも対応できます。

Linuxサーバから見ると、通常のNFSサーバをマウントするような感覚で利用できます。

sudo mkdir -p /mnt/ring

sudo mount -t nfs \
  nfs-ring.example.local:/volume01 \
  /mnt/ring

マウント後は、通常のファイルシステムのように操作できます。

echo "hello via nfs" > /mnt/ring/hello.txt

ls -l /mnt/ring/

この場合、利用者からは普通のファイルサーバのように見えます。

Scality RINGでは、SOFSにより、NFS、SMB、FUSE経由のファイルアクセスを提供できます。(Cisco)

同じScality RINGをS3互換APIとNFSで同時に使えるのか

結論から言うと、同じScality RINGクラスタを、あるサーバからはS3互換APIで、別のサーバからはNFSで利用することは可能です。

イメージは次の通りです。

例えば、サーバAではオブジェクトストレージとして使います。

aws --profile scality \
  --endpoint-url https://s3.example.local \
  s3 cp app.log s3://log-bucket/app.log

一方、サーバBではNFSとして使います。

sudo mount -t nfs nfs-ring.example.local:/volume01 /mnt/ring

cp report.txt /mnt/ring/

どちらも裏側では、同じScality RINGのストレージ基盤を利用します。

ただし「同じデータを両方から同じように見える」とは限らない

ここは重要です。

同じRINGクラスタをS3互換APIとNFSで同時利用できることと、S3で保存したオブジェクトをNFS側からそのまま同じファイルとして見られることは別です。

S3互換APIでは、データは次のように見えます。

s3://bucket-name/object-key

NFSでは、データは次のように見えます。

/mnt/ring/path/to/file

S3互換APIはオブジェクトストレージの考え方です。
NFSはディレクトリとファイルを前提としたファイルシステムの考え方です。

そのため、設計としては次のように分けて考える必要があります。

観点	説明
同じRINGクラスタをS3用・NFS用に使う	可能
S3領域とNFS領域を分けて使う	一般的な設計としてあり得る
S3でPUTしたものをNFSで同じファイルとして見る	構成・機能・バージョンに依存
NFSで作ったファイルをS3 APIで同じオブジェクトとしてGETする	構成・機能・バージョンに依存
S3とNFSから同じデータを同時更新する	整合性やロックの考慮が必要

つまり、

同じScality RINGをS3互換APIとNFSで同時に使うことはできる。
ただし、同じデータを両方のプロトコルから自由に読み書きできるかは、設計と製品仕様の確認が必要。

という理解が正確です。

S3互換APIとNFSの考え方の違い

S3互換APIとNFSは、どちらも「データを保存する」という意味では似ています。
しかし、データの扱い方はかなり違います。

比較項目	S3互換API	NFS
データの単位	オブジェクト	ファイル
入れ物	バケット	ディレクトリ
アクセス方法	HTTP API	ファイルシステム操作
主な操作	PUT / GET / DELETE	open / read / write / close
向いている用途	アプリ連携、ログ、バックアップ、画像、動画、アーカイブ	既存アプリ、共有ファイル、Linuxサーバ間のファイル共有
見え方	`s3://bucket/key`	`/mnt/path/file`

S3互換APIは、アプリケーションがAPI経由でデータを保存する用途に向いています。
NFSは、既存のLinuxアプリケーションや運用スクリプトが、通常のファイルとして読み書きする用途に向いています。

Scality RING内部では何が起きているのか

S3互換APIでオブジェクトを保存する場合も、NFSでファイルを書き込む場合も、最終的にはScality RING内部のStorage Nodeにデータが保存されます。

RING内部では、データを複数のノードに分散して保存します。
そのため、1台のサーバや1本のディスクに依存する構成よりも、大容量化や耐障害性を実現しやすくなります。

データ保護の考え方

分散ストレージでは、ディスクやサーバの故障は前提として考えます。

Scality RINGでは、データを守るために主に次のような方式が使われます。

方式	概要	特徴
Replication	データを複数コピーして保存する	シンプルで分かりやすい
Erasure Coding	データとパリティを分散保存する	容量効率がよい
Geo-replication	複数拠点間で複製する	DR対策に使える

Replicationは、同じデータを複数のノードにコピーする方式です。

Erasure Codingは、データを複数のチャンクとパリティに分けて分散保存する方式です。

Scality RINGは、レプリケーションやイレイジャーコーディングを選択でき、広域分散構成にも対応すると説明されています。(株式会社ブロードバンドタワー)

Scality RINGが向いている用途

Scality RINGは、大量の非構造化データを扱う用途に向いています。

用途	理由
バックアップ保存先	大容量データを保管しやすい
ログ保管	大量のログをAPI経由で保存しやすい
画像・動画保管	オブジェクトストレージと相性がよい
アーカイブ	長期保存、大容量保存に向いている
ファイル共有基盤	NFS/SMBで既存環境に接続しやすい
プライベートクラウド基盤	自社環境内でS3互換APIを提供できる
SaaSの裏側のストレージ	アプリケーションからAPIで保存しやすい

特に、アプリケーションからはS3互換APIで保存しつつ、既存のサーバ群からはNFS/SMBで扱いたい、というような環境では、マルチプロトコル対応のメリットが出ます。

注意点

Scality RINGは便利ですが、設計時には次の点に注意が必要です。

1. S3互換APIとNFSは意味論が違う

S3互換APIはオブジェクト単位、NFSはファイル単位です。
同じ「保存」でも、更新方法、ロック、整合性の考え方が違います。

2. 同じデータを複数プロトコルから扱う場合は設計が必要

S3互換APIとNFSから同じデータを読み書きしたい場合、名前空間や同時更新時の挙動を確認する必要があります。

3. 対応APIは製品バージョンで確認する

S3互換といっても、すべてのAPIや挙動が完全に同一とは限りません。
利用したいAPI、CLI、SDK、アプリケーションが対象バージョンでサポートされているか確認が必要です。

4. 運用設計が重要

分散ストレージでは、ノード追加、ディスク障害、容量監視、性能監視、リバランス、バックアップ、DRなどを含めた運用設計が重要になります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up