APIによる利用

　Swiftをストレージサービスとして利用するための最も基本的な手順は、SwiftのREST APIを用いてアクセスすることである（参考：公式ドキュメント「OpenStack ObjectStorage Deveoper Guide」）。このAPIは、Swiftの基になったRackSpaceのCloudFilesのREST APIと基本的に同じものであるため、CloudFiles用の各種ライブラリをそのまま利用することができる。GitHubから、Java、Python、C#、Ruby、PHPといったさまざまな言語のライブラリが提供されている。

　Swiftの第二版（Bexar）からは、必要最低限なAmazon S3互換APIもサポートされており、これを利用してAmazon S3などと透過なストレージサービス（参考：Achieving S3 API compatibility with OpenStack Swift using SMEStorage）を提供している会社もある。

GUI、CLIによる利用

　Swiftを利用するための最も一般的な方法は、GUI（Graphical User Interface）ツールを使用することである。代表的なツールとしてはCyberduckやCloudBerryがある。これらは、SwiftまたはAmazon S3のRESTプロトコルを使用してアクセスする。

　なお、シェルスクリプトなどの中からCLI（Command Line Interface）ツールによってSwiftにアクセスしたい場合、curlコマンドなどを用いることも可能である。これについてはクラウドインテグレーション事業者のクリエーションラインによる日本語の詳しい検証報告があるので参照されたい（参考：OpenStack Storage（Swift）調査報告書）。

ファイルシステムインタフェースでの利用

　Linuxの場合、s3fsと呼ばれるツールがあり、Amazon S3のストレージ領域をあたかも通常のファイルシステムであるかのようにmountできる。これは、LinuxのFUSE（Filesystem in Userspace）と呼ばれる仕組みを利用して実装されている。

　Swiftでもcloudfuseと呼ばれるツールを用いて同様のことが可能である。FUSEは、細かいアクセスを繰り返す場合はあまり効率が良くないが、一般のアプリケーションを無修正のまま使えるため、特に大量のアップロード／ダウンロードを行いたい場合は便利に使える。

ストレージサービスとしての仕様

　本節では、Swiftのストレージサービスとしての主要な仕様を列挙する。

• データの格納単位は「オブジェクト」と呼ばれる。一般的にいうファイルに対応すると考えればよい
• オブジェクトは「コンテナ」に格納される。コンテナとは、一般的にいうフォルダもしくはディレクトリに相当する概念であるが、1階層のみ作成可能である
• オブジェクトのサイズの上限は5Gバイトである（Amazon S3のオブジェクトサイズの上限は、現在5Tバイトまで拡大されているため、相対的にかなり小さく見える。しかし、Swiftにはsegmentationと呼ばれる概念があり、最大5Gバイトのオブジェクトを複数まとめて1つの巨大なオブジェクトとして扱える仕組みが導入されている）
• ユーザーもしくはグループごとに、オブジェクト単位の粒度でアクセス制御を行うことができる

　このように、基本的な機能は一通り使用することができる。

拡張性

　後述のアーキテクチャの節で説明する通り、SwiftもNovaと同様にモジュラーな構造になっており、オブジェクトの実体を保持するサーバ（Object Server）を追加することによって、運用中に動的に全体容量を増加させることができる。

対故障性

　Swiftが格納するデータは、メタデータも含めて複数のサーバに分散・冗長化して格納されるため、1台のサーバが故障しても直ちにデータが失われることはない。

　また、Swiftにはzoneと呼ばれるサーバをグループ化する概念がある。zoneは、サーバ、ネットワーク、電源など、可能な限りお互いに隔離された構成とすることが推奨されている。前述の冗長化されたデータは、このzoneをまたがってレプリケーションされる（デフォルトでは3重）ため、Swiftによるオブジェクトストレージサービスの運用者は、zoneをうまく設計することにより対故障性を高く保つことができる。Swiftの運用管理マニュアルでは、各種の設定値や指針について、RackSpaceの運用環境で得られたベストプラクティスも紹介されている。

アーキテクチャ

　図1にSwiftのアーキテクチャを示す。

図1　Swiftのアーキテクチャ（cactus）

　Swiftの基本的な構成要素には以下の5種類のサービスがある。ぞれぞれの役割は以下の通りである。

Swiftを構成する5つの要素

　これらのサーバ群は、Ringファイルを参照しながら協調動作する。Ringファイルは各種の論理的な名前と実体の対応関係を保持する。特徴的な点として、Ringファイルの更新は管理者の責任ということが挙げられる。つまり、容量追加のためにObject Serverを追加した場合には、管理者が全サーバのRingファイルを更新する必要がある。一般にSwiftのようなクラスタ構成を取る場合、そのクラスタを構成する個々のサーバの死活監視処理がボトルネックやトラブルの原因となることが多い。しかしSwiftでは、自分で死活監視処理をせずに外出しする、割り切ったシンプルな設計となっている。

　なお、上記5種類のサーバ群の他に、SwiftにはReplicator、Updater、Auditorと呼ばれる処理がある。

　Replicatorは、ネットワークやディスク装置が故障した場合などに、レプリカの冗長度を保つためにレプリケーション処理を行う。

　Updaterは、何らかの理由によって内部管理情報の更新が間に合わなかった場合などに、更新処理要求をキューイングしておいて遅延更新を行う。例えば、高負荷時にオブジェクトのアップロードを行ったときに、Container Serverへの情報更新が間に合わないことがある。この場合、一時的にアップロードしたはずのオブジェクトが一覧に表示されないなどの現象が見られることを意味する。これは、クラウド時代特有のeventual consistencyと呼ばれる性質の1つである。

　Auditorは、サーバ単位で内部のデータ整合性のチェックを行い、必要があれば他のサーバ上のレプリカからコピーを行って整合性を回復する。

　なお、Auth Serverは次版で名称と位置付けが変更される見込みである。これは、これまでNovaとSwiftが認証・認可機構を独立に実装しており、仕様に違いがあったものを、OpenStack全体で統合していくことを目指す動きの一環である。

まとめ

　今回は、Swiftの特徴、アーキテクチャ、利用するためのツールなどの全体的な説明を行った。Swiftがシンプルなアーキテクチャを特徴とすることや、商用サービス由来であることもあり、既に実用の域に達していることをご理解いただけたと思う。

　次回は、比較的小規模な構成を題材に取り、実際にSwiftの動作環境を構築して利用するための具体的な手順を紹介する。

伊藤雅典

株式会社NTTデータ 技術開発本部

シニアITスペシャリスト。専門分野はオペレーティングシステム一般。専門以外には進化論などに興味を持つ。現在はインタークラウド連携の研究開発に従事する他、JOSUG、VIOPS、GICTFなどの各種団体・コミュニティーで活動中。趣味は子育て。