【ITニュース解説】Object Storage Can Replace a Database Under Four Contracts

オブジェクトストレージは、特定の厳しい条件が揃えば、データベースのように扱うことが可能である。しかし、これはオブジェクトストレージが一般的なデータベースの代わりになるという意味ではない。オブジェクトストレージは、キーに対応するバイト列（ファイルのようなデータ）を保存する仕組みであり、データベースが提供するような複雑なデータの管理や操作機能は、本来持っていない。それでも、特定の「ワークロード」、つまりデータへのアクセスや処理の仕方が合致する場合に限り、サービスの管理や設定情報を保存する「コントロールプレーンストア」のような用途で、データベースの代わりに利用できるケースがあるのだ。

最も重要なのは、どのような「データ形状」か、そしてアプリケーションがデータに対してどのような「質問」（検索や操作）をするかによって、最適なストレージは決まるという点だ。オブジェクトストレージが適しているのは、データが組織（テナント）ごとにきれいに分割され、書き込みの頻度が低く、ほとんど競合が発生せず、キーを指定して直接読み取る（ポイントルックアップ）だけで十分な場合である。また、データの履歴が一度書き込まれたら変更されない（追記専用）という性質も重要になる。これらの条件のうち一つでも変わると、オブジェクトストレージでデータベースの代わりをさせるのは途端に難しくなる。例えば、一つのデータに同時にたくさんの書き込みが発生したり、複数のデータにまたがる複雑な操作（トランザクション）が必要になったり、保存されたデータに対して自由な条件で検索（アドホッククエリ）したいような場合は、オブジェクトストレージでは対応が困難であり、無理に使うとシステムが複雑になり、性能も悪化する可能性が高い。このような複雑なワークロードでは、最初からデータベースを使うのが賢明である。

データベースを利用する際に、通常求められる四つの重要な機能や保証がある。それは「一意性」「トランザクション」「インデックス」「履歴」である。 「一意性」とは、例えばユーザーIDのように、特定のデータが重複して登録されないことを保証する機能だ。 「トランザクション」とは、複数の操作を一つのまとまりとして扱い、すべて成功するか、すべて失敗して元に戻るか、どちらかの状態になることを保証する仕組みを指す。これは、銀行口座の送金のように、引き出しと預け入れが両方成功するか、両方失敗するかのどちらかでなければならないような場合に不可欠である。 「インデックス」は、データを効率よく検索するための仕組みで、辞書の索引のようなものだ。これにより、大量のデータの中から特定の情報を素早く見つけ出すことができる。 最後に「履歴」は、データの変更履歴を追跡し、いつ、誰が、どのようにデータを変更したかを記録する機能である。

オブジェクトストレージは、これらのデータベースが標準で提供する機能をそのままは持っていない。しかし、一部のサービスは二つの基本的な機能を提供している。それが「強い書き込み後読み取り一貫性」と「条件付き書き込み」だ。 「強い書き込み後読み取り一貫性」とは、データを書き込んだら、その変更がすぐに読み取り操作に反映されることを意味する。これにより、古いデータを見て誤った判断をしてしまうリスクを防ぐことができる。 「条件付き書き込み」は、特定の条件が満たされた場合にのみ書き込みを許可する機能である。例えば、「まだ存在しないキーにだけ新しくデータを作成する」とか、「ある特定のバージョンのデータが変更されていない場合にだけ、そのデータを更新する」といった操作ができる。これは、複数の操作が同時に行われる際にデータの整合性を保つための基本的な手段となるが、完全なトランザクションシステムとは異なる点に注意が必要である。

これらの二つの基本機能を使って、データベースの四つの保証を再構築する方法を見てみよう。 「一意性」を確保するためには、キーがまだ存在しない場合にのみ新しいデータを作成する「条件付き作成」を利用する。例えば、ユーザーのメールアドレスのハッシュ値をキーとして使用し、そのキーがオブジェクトストレージに存在しない場合にのみ新しいユーザーレコードを作成することで、同じメールアドレスが二重に登録されるのを防ぐことができる。 「トランザクション」のような操作は、一つのオブジェクトに対する変更に限られる。具体的には、まず既存のデータを読み込み、アプリケーション側で必要な計算や変更を行い、そしてその結果を、読み込んだ時と同じバージョンのデータが変更されていないことを条件に、新しいデータとして置き換える、という手順を踏む。もし途中でデータが他のプロセスによって変更されていれば、条件付き書き込みは失敗し、アプリケーションは再試行する必要がある。この再試行される処理は「純粋」でなければならない。つまり、処理中にメール送信や外部サービスへの支払い要求のような「副作用」があってはならず、何度実行しても同じ入力に対して同じ出力を返し、外部の状態を変更しないように設計する必要がある。 「インデックス」は、オブジェクトのキー名そのものを検索パスとして設計することで実現する。例えば、メールアドレスのハッシュ値をキー名の一部に含めることで、そのハッシュ値を使って直接オブジェクトを読み出すことができる。しかし、これはあらかじめ設計された特定の検索パターンにしか対応できない。新しい種類の検索をしたい場合は、それに対応する新しいキーパターンを設計し、既存のデータを全て新しいキーで再作成する（バックフィル）という作業が必要になる。これは大きな手間であり、一般的なデータベースのように自由なクエリはできない。 「履歴」は、データを追記専用の形式で保存することで実現する。例えば、バージョンごとに異なるキーを割り当てたり、イベントが発生するたびに新しいオブジェクトを異なるキーで追加したりすることで、過去の変更を記録し、後から追跡できるようにする。これらのオブジェクトは一度書き込まれたら変更されないため、データの監査証跡としても機能する。

オブジェクトストレージを活用したシステムでは、テナント（顧客などの独立した利用者単位）ごとにデータを隔離するために、顧客ごとに専用の「バケット」という保存領域を割り当てる設計が考えられる。これにより、ある顧客のデータが別の顧客からアクセスされることを防ぎ、セキュリティを強化できる。具体的なキーの設計としては、例えば、members/{ハッシュ値}.jsonのようなパターンでメンバー情報を保存し、versions/{チャネルID}/{作成日時}.pbのようなパターンで設定のバージョン履歴を保存する。作成日時には、時系列順に並ぶULID（ユニバーサルユニーク辞書順ソート可能識別子）のようなユニークなIDを使うと、オブジェクトのリストを時間順に取得しやすくなる。しかし、これはあくまでキーの設計に依存するため、任意の日付範囲でソートするといった一般的なデータベースの機能とは異なる。

「条件付き書き込み」は単一のキーに対する同時変更から保護する強力な機能だが、その限界を理解することが重要だ。これは、複数のキーにまたがる操作をまとめてアトミック（不可分）に行うことはできない。例えば、一つの操作で二つのオブジェクトを変更する場合、片方が成功し、もう片方が失敗するという状況が発生し得る。このため、複数のオブジェクトにまたがる整合性を保証する必要がある場合は、アプリケーション側で複雑なロジックを実装するか、その整合性を諦める必要がある。

インデックスと履歴の設計は、オブジェクトストレージを使う上で特に大きな影響を及ぼす。インデックスはキー名に組み込まれるため、あらかじめ決められたアクセスパターンにしか対応できない。新しいクエリが必要になるたびに、新しいキーパターンを設計し、既存のデータを再構築する手間が発生する。これは「手書きのインデックス移行」とも言えるもので、システム運用上の継続的なコストとなる。履歴についても、状態とイベントの書き込みが別々に行われる場合、状態は更新されたがイベントの記録が失敗するといった「ずれ」が生じる可能性がある。完全な監査ログが必要な場合は、定期的にデータの整合性を確認し、不足があれば修正する「調整プロセス」が必要になる。また、データの削除もデータベースとは異なる。キーを削除すると、そのデータが「最初から存在しなかった」のか、「一度存在したが削除された」のかの区別がつかなくなる。履歴を保持したい場合は、削除されたことを示す「トンブストーン」のようなオブジェクトを残したり、古いバージョンのオブジェクトを削除せず保持するなどの工夫が必要となる。これにより、ストレージ容量は増え続けるため、一定期間後に古いデータを自動的に削除するライフサイクルポリシーを設定することが一般的である。

地理的に分散した複数リージョンで書き込みを行う場合は、さらに複雑な問題に直面する。それぞれのリージョンで独立して条件付き書き込みが成功し、後になってデータが同期された際に競合が発生し、どちらかの変更が失われる可能性があるのだ。これを解決するには、「どのリージョンをプライマリ（主）とするか」という明確な書き込みポリシーが必要となる。例えば、書き込み操作は常に一つの特定のリージョンに集中させ、他のリージョンからの書き込みはエラーとして処理する、といった運用が必要になる。読み取りはレプリカ（複製）から行ってもよいが、書き込みの整合性を保つためには、このような明示的なルールが不可欠だ。また、繰り返し競合が発生するような「ホットキー」に対する書き込みは、再試行が延々と続き、システムが実質的に停止する「ライブロック」を引き起こすリスクがある。これを避けるためには、リトライ回数に上限を設けたり、指数バックオフ（再試行の間隔を徐々に長くする）のような戦略を取り、それでも解決しない場合はアプリケーションにエラーを通知するべきである。

最終的に、オブジェクトストレージをデータベースの代替として採用するかどうかを決定する際には、いくつかのチェックポイントがある。まず、データが顧客ごとにきれいに分離できるか、書き込み量が少なく競合が稀か、読み取りはキーによる直接検索で十分か、そして履歴は追記専用で不変な性質を持つか、といった点がワークロードの条件に合致するかを確認する必要がある。次に、オブジェクトストレージを採用することで何を諦めることになるかを理解することが重要である。複数オブジェクトにまたがるアトミックな操作ができないこと、自由な検索（アドホッククエリ）が不可能で、新しいクエリには手動でのインデックス移行が必要になること、監査ログの完全性が自動的には保証されないため調整プロセスが必要なこと、単純な削除ができないこと、そして複数リージョンでの書き込みには複雑な競合解決ポリシーが必要なこと、といった制約を受け入れることができるかどうかが問われる。もしワークロードがこれらの条件に適合し、諦める制約も許容できるのであれば、オブジェクトストレージをデータベースの代わりに利用することは有効な選択肢となり得る。しかし、もしワークロードが適合しないのであれば、無理にオブジェクトストレージでデータベースを構築しようとするのではなく、最初から適切なデータベースを使うのが現実的で賢明な判断だ。システム設計においては、ワークフローやデータの特性がストレージエンジンを決定するべきであり、データの形状が変化した際には、それに合わせてストレージの選択も見直す必要がある。