クラウドネイティブなデータベースはなぜコンピュートとストレージを分離するのか

この記事は hacomono Advent Calendar 2025 の12日目の記事です。

基盤本部で今後のhacomonoのアーキテクチャ設計をしている @bootjp と申します。
今年はマイクロサービス化に向けての社内共通のイベントバスの設計や基盤周りの設計/実装を行っていました。

以前にはこのような記事を書き、分散システムや分散データベース、分散ストレージなどが大好きです。

「Goで作って理解するRaftベースRedis互換KVS」という同人誌も書いています。
もし興味のある方はお手にとってみてください。

はじめに

今回は「クラウドネイティブデータベース」と言われる、昨今のデータベースにおけるコンピューティングとストレージの分離について、どのような動機でこの構成になったのか、利用者としてどのようなメリットがあるのか、そしてトレードオフは何かということについて記事を書かせていただきます。

用語の定義

コンピュート (Compute) ステートレスな計算層: データベース処理における「計算・処理」を担当する部分です。CPUやメモリを使用し、SQLのパース、実行計画の作成、キャッシュ管理などを行います。重要なのは、この層は「ステートレス（状態を持たない）」として扱えるよう設計されている点です。万が一このノードが故障しても、永続化されたデータそのものは失われません。
ストレージ (Storage)ステートフルな保存層: データを実際に「永続化（保存）」する部分です。ここがシステムの「正（Source of Truth）」となります。クラウドネイティブDBにおいては、単なるディスクではなく、分散ファイルシステムやオブジェクトストレージなどが用いられ、自己修復機能やデータの多重化を担当する「ステートフル（状態を持つ）」で高信頼な層として機能します。

クラウドネイティブなデータベースとは？

クラウドネイティブなデータベースとはなんでしょうか？
Cloud Native Computing Foundationによってクラウドネイティブについては以下のように定義されています。

CNCF Cloud Native Definition v1.1

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。

これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。

https://github.com/cncf/toc/blob/main/DEFINITION.md#日本語版

※強調は筆者によるもの

私がクラウドネイティブデータベースを語るうえで重要になると考える要素は以下です。

近代的でダイナミックな環境
スケーラブルなアプリケーションを構築するための能力を組織にもたらす
回復性、管理力、および可観測性のある疎結合システムが実現
インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

つまりパブリッククラウドであるか、プライベートクラウドであるかを問わず、動的にスケールできるアプリケーションを構築するための能力をもたらすもの、そして回復性、管理力、および可観測性のある疎結合システムが実現でき、インパクトのある変更が最小限の労力で実現できるもの、と言えそうです。
この記事ではこれらの要素を兼ね備えたよりデータベースをクラウドネイティブなデータベースとします。
より具体的にはいわゆる通常のアプリケーションが利用するRDBMSとして（Online Transaction Processing）利用では Amazon Aurora、Amazon Aurora DSQL、Cloud Spanner、TiDB（TiKV）、Neon、Cloud AlloyDBなどを指します。
分析などの（Online Analytical Processing）の分野ではDatabricks、Snowflake、Cloud BigQuery、Amazon Athenaなどが相当すると考えています。
この記事ではアプリケーションがデータストアとして利用するRDBMSを掘り下げていきます。

クラウドネイティブデータベース以前の世界

従来のデータベースは、「DBサーバー」という一つの筐体の中に CPU・メモリ・ローカルディスクをすべて抱え込む密結合な設計が一般的でした。
オンプレミスの物理サーバや、初期のクラウド時代の仮想マシン上の RDBMS は、基本的に「そのマシンが落ちたら、そのマシンのディスクもアクセス不能になる」という設計で動作していました。そのため、レプリケーションによるセカンダリーを用意し、フェイルオーバーの仕組みを構築していた方も多いでしょう。
その後、ストレージ層がネットワークストレージ（SANやAWS EBSなど）に集約され、計算リソースと保存領域が物理的には分かれ始めました。しかし、アーキテクチャとしては依然として「1つのDBインスタンスが1つのボリュームをマウントする」形が主流でした。
GoogleのAlloyDBの紹介記事にあるように、近年では単にストレージを外出しするだけでなく「データベースのロジックを理解したインテリジェントなストレージ層」へと進化しています。

引用元: AlloyDB for PostgreSQL の仕組み: データベース対応のインテリジェントなストレージ

AlloyDBの画像を見てわかるように、近年ではストレージをスケールするだけではなく、データベースに最適化したストレージ層の存在があります。
これはAlloyDBに限らず、Amazon Aurora、Amazon Aurora DSQL、Cloud Spanner、TiDB（TiKV）、Neonにも同様の設計思想が伺えます。
詳細な解説は後ほど行いますが、疎結合でかつスケールする環境に適応させるためにこのような手法が取られてきました。
以降では、「なぜコンピュートとストレージを分離するのか」という設計上の動機を主題に据え、その中で Aurora / Spanner / TiDB / Aurora DSQL / Neon を具体例として挟みながら、スケーラビリティ、疎結合、ライフサイクル、分散コンセンサスアルゴリズムといった観点から整理します。
また、本記事を書くもう一つの背景として、「ストレージを分離するとレイテンシーやスループットが悪くなるのではないか？」という不安にも触れておきたいと思います。

分離を必要とする課題背景

ノード追加時に負荷を少なく、より高速に

従来のアーキテクチャでリードレプリカを追加するステップを想像してください。プライマリーノードからスナップショットを転送し、その後の差分ログを適用して追いつく必要があります。DBサイズが数TBになると、このプロセスには数時間かかり、その間ネットワーク帯域とプライマリーノードのI/Oを消費し続けます。
また転送中はプライマリーノードに負荷がかかり、本番トラフィックのパフォーマンスに影響を与える可能性がありました。
一方、コンピュートとストレージを分離したアーキテクチャでは、新しいレプリカノードは共有ストレージ層に接続するだけで済みます。データの物理コピーは不要です。ストレージ層のメタデータを参照すれば即座にデータにアクセスできるため、ノード追加は数分〜数秒で完了します。プライマリーノードへの負荷も最小限で、本番影響を気にせずスケールアウトが可能になります。

きめ細やかなスケーリング管理

従来のアーキテクチャでは、EBSなどのネットワークストレージを利用することでストレージ容量を独立してスケールすることは可能でした。しかし、各DBインスタンスが独自のストレージボリュームを持つ設計では、先程の項でふれたように新しいリードレプリカを追加する際にデータコピーの時間と負荷という形で課題が残ります。
コンピュートとストレージを完全に分離したアーキテクチャでは、コンピュートノードがステートレスになります。つまり、新しいノードは共有ストレージ層に接続するだけで即座にデータにアクセスでき、データのコピーや同期を待つ必要がありません。これにより、読み取り負荷の急増に対して数秒から数分で新しいリードレプリカを追加できるようになり、きめ細やかで高速なスケーリングが実現します。

例えばAmazon Auroraでは、すべてのコンピュートノードが同じ分散ストレージ層を参照するため、リードレプリカの追加は瞬時に完了します。従来のようにデータベース全体のスナップショットを転送する必要がないため、スケーリングの俊敏性が大幅に向上します。

異なるライフサイクルの分離

従来のアーキテクチャでは、コンピュートリソース（CPU・メモリ）とストレージが密結合していたため、両者のライフサイクルを独立して管理することが困難でした。
例えば、一時的な負荷増加に対応するためにインスタンスをスケールアウトする場合でも、各インスタンスに紐づくストレージも一緒に用意する必要があり、リソースの無駄が生じていました。
クラウドネイティブの重要な定義の一つに「ダイナミックな環境でのスケーリング」があります。これは、負荷に応じてコンピュートリソースを柔軟に増減できることを意味すると考えています。
一方で、ストレージの必要容量はアプリケーションのデータ量によって決まり、負荷の変動とは直接的な関係がありません。この非対称性こそが、コンピュートとストレージのライフサイクルを分離する大きな動機となっています。
コンピュートとストレージを分離することで、それぞれのライフサイクルを独立して管理できるようになります。

コンピュートのライフサイクル: ピーク時には数分でリードレプリカを追加し、負荷が下がればすぐに削減できます。コンピュートノードはステートレスなので、起動・停止のコストが低く、必要な分だけ稼働させることでコストを最適化できます。
ストレージのライフサイクル: データ量の増加に応じて段階的に拡張し、一度確保した容量は削除されない限り維持されます。ストレージ層は常時稼働し、すべてのコンピュートノードからアクセス可能な状態を保ちます。

この分離により、例えばAmazon Auroraでは、夜間のバッチ処理のために一時的にリードレプリカを追加し、処理完了後すぐに削除するといった運用が可能になります。従来のアーキテクチャでは、レプリカ追加時にデータコピーが必要だったため、このような柔軟な運用は現実的ではありませんでした。
また、Aurora Serverless v2やNeonのようなシステムでは、コンピュートノードを完全に停止し、アクセスがあったときだけ自動的に起動する「ゼロスケーリングキャパシティ」や「Scale to Zero」という概念も実現されています。これは、コンピュートとストレージが完全に独立しているからこそ可能な設計です。

Amazon Aurora Serverless v2 がゼロキャパシティへのスケーリングをサポート - AWS Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング - Amazon Aurora Scale to Zero - Neon Docs

ストレージの分離に伴う設計の見直し

コンピュートとストレージを分離するためには、アーキテクチャの根本的な再設計が必要でした。特に重要なのが、ログの扱いと分散合意の移行です。
コンピュートとストレージを分離したアーキテクチャでは、従来のデータベース設計における前提が大きく変わります。特に重要なのは、WAL（Write-Ahead Log）やBinlogといった変更ログのコンピュート層でのレプリケーション方式を廃止し、代わりにストレージ層における分散合意アルゴリズムを採用することです。
そして、その上で疎結合でかつスケールするように設計されたビルディングブロック上に再設計が行われています。

💡Tips: 「Log is the Database」によるボトルネックの解消

設計の見直しにおいて、もう一つの重要な転換点が「ネットワークに何を流すか」という発想の転換です。

従来のPostgreSQLなどのレプリケーションでは、WAL（変更ログ）の転送に加え、定期的なチェックポイント処理で「変更があったページデータ全体（Full Page Write）」もディスクへ書き出す必要があり、これがネットワーク帯域を圧迫するボトルネックとなっていました。

これに対し、AuroraやNeonなどのクラウドネイティブデータベースでは、「Log is the Database」という思想を採用しています。これは、コンピュートノードからストレージ層へ「ログレコード（変更差分）」のみを転送し、ページデータの生成やマージ作業はストレージ層側に任せるというアプローチです。

これにより、重たいページデータの転送をネットワークから排除し、分離アーキテクチャにおける通信レイテンシーの影響を相殺するほどの高いスループットを実現しています。

分散合意をストレージ層に移行

従来のデータベースでは、データの複製や分散合意のロジックがコンピュート層（DBインスタンス）に実装されていました。例えば、PostgreSQLのストリーミングレプリケーションやMySQLのグループレプリケーションでは、各DBインスタンスがWALやBinlogの送受信と適用を担当し、複数ノード間でのデータ整合性を保証していました。
しかし、コンピュートとストレージを分離したアーキテクチャでは、この分散合意の責任を徐々にストレージ層に移行することで、より効率的なデータ管理が可能になります。
Amazon Auroraを例にとると、ストレージ層自体がログの適用とクォーラムベースのレプリケーションを実装しており、3つのアベイラビリティーゾーンにまたがる6つのコピーのうち、書き込みには過半数のノードからの確認があれば成功とみなす仕組みになっています。
この設計により、コンピュートノード(DBインスタンス)は複雑なレプリケーション管理から解放され、SQLの実行やトランザクション管理といった本来の役割に集中できるようになります。
このアプローチにより、コンピュートノードは軽量になり、より高速なスケーリングが可能になります。
詳細な解説は後述しますが、具体的な実装例として以下のような実装例があります。

Amazon Aurora DSQL: マルチリージョンにまたがる分散SQLデータベースで、ストレージ層での分散合意により高い可用性を実現しています。
TiDB: SQLフロントエンド（TiDBサーバ）とRaftベースの分散KVS（TiKV）を分離し、コンピュートとストレージの独立したスケーリングを可能にしています。
AlloyDB: PostgreSQL互換のデータベースで、インテリジェントなストレージ層がログの適用と分散合意を担当し、コンピュートノードの負荷を軽減しています。
Neon: ストレージ層でのPaxosベースの分散合意によりデータの一貫性と可用性を両立しながら、コンピュートノードの軽量化を実現しています。

💡Tips: NewSQLやetcdで用いられるRaftの分散合意について

NewSQLと呼ばれる強い一貫性を提供する分散データベースの一部やKubernetesで用いられるetcdで使われているRaft Consensus Algorithmという分散合意アルゴリズムがあります。 Raft Consensus Algorithmの仕組みやメリットそして得手/不得手を発表したスライドがございますので、よろしければ御覧ください。

NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意

高い耐久性を持つクラウドストレージ基盤の活用

クラウドネイティブなデータベースの多くは、永続化層として高い耐久性を持つクラウドストレージ基盤（オブジェクトストレージや分散ファイルシステム）を活用しています。
これらの基盤は、データを複数のアベイラビリティーゾーンに自動的に複製し、極めて高い耐久性を提供します。従来のデータベースでは、各DBインスタンスがローカルディスクやEBSボリュームにデータを保存し、レプリケーションによって冗長性を確保していましたが、この方式では各インスタンスでストレージコストが発生し、管理の複雑さも増していました。
コンピュートとストレージを分離したアーキテクチャでは、WALやスナップショットをクラウド基盤のストレージに保存することで、耐久性の担保をインフラ側に委譲できます。
例えば、NeonではAmazon S3（オブジェクトストレージ）を、AlloyDBではGoogleのColossus（分散ファイルシステム）を利用し、データベースの変更ログ(WAL)を継続的に保護する仕組みを実装しています。これにより、障害時にはログから高速にデータを復元でき、コスト効率と信頼性の両立が可能になります。

また、こうした大規模分散ストレージの利用により、ポイントインタイムリカバリやブランチング(データベースの任意時点からの分岐)といった高度な機能も実現しやすくなります。

どのように分離しているのか

Amazon Aurora

Amazon Auroraは、クラウドネイティブデータベースの先駆けとして、コンピュートとストレージの分離を実現した代表的な実装です。Auroraの最大の特徴は、各DBインスタンス(コンピュート層)の下に、3つのアベイラビリティーゾーンにまたがる共有分散ストレージ層を配置していることです。
このストレージ層は、データを6つのコピーとして複製し、過半数のノードからの確認があれば成功とみなすクォーラムベースのレプリケーションを採用しています。

💡Tips: なぜAuroraは6コピーなのか

ちなみになぜ6つのコピーかというと書き込みには過半数の4ノードの確認が必要という設計において、最大2つのノードの障害に耐えられるようにするためです。 3つのアベイラビリティーゾーンそれぞれに2つのコピーを配置することで、1つのAZ全体が失われても、残りの2つのAZの4つのコピーで書き込みクォーラムを満たすことができます。

💡Tips: Auroraにおける「合意」と「Quorum」

本記事では便宜上「分散合意」という言葉を使っていますが、厳密にはデータベースによってその実装は異なります。

TiKVやCockroachDBなどがRaftプロトコルを用いて「リーダー選出からログ複製まで」フルに分散合意を行うのに対し、Amazon Auroraのアプローチは少し異なります。Auroraでは、トランザクションの順序決定（Ordering）は単一のWriterインスタンスが行いますが、ストレージへの書き込み耐久性（Durability）の担保に「Quorum（定足数）」の考え方を用いています。

6つのコピーのうち4つ（過半数以上）からの書き込み成功応答（Ack）をもって永続化とみなすこの仕組みは、広義には合意形成の一種ですが、リーダー不在の分散合意アルゴリズムとは区別して「Quorumベースのレプリケーション」と呼ばれることが多いです。

Spanner

Google Spannerは、グローバルに分散されたリレーショナルデータベースで、コンピュートとストレージの分離に加えて、TrueTime APIと呼ばれる独自の正確な時刻取り扱い技術を活用しています。
Spannerのアーキテクチャにおいて特徴的なのは、コンピュートノードである「Spanserver」がPaxosグループの参加者となり、合意形成の責任を持っている点です。
各Spanserverは「タブレット」と呼ばれるデータのシャードを管理します。Spanserverはトランザクションのログ（WAL）を生成し、Paxosアルゴリズムを用いて複数のレプリカ間でログの合意形成を行います。そして、合意されたログやデータは、永続化層である分散ファイルシステム「Colossus」へと書き込まれます。
つまり、Spannerにおいては「分散合意やトランザクション管理を行うステートフルなコンピュート層」と、「単にファイルを高い耐久性で保存するストレージ層（Colossus）」という役割分担がなされています。これにより、計算リソースのスケールと、データの永続化・耐久性の担保を分離して扱うことを可能にしています。

💡Tips: TrueTime APIに関する余談

TrueTime APIの本質は、ノード間のクロックのゆらぎを正確に扱える点にあります。分散システムでは各ノードのクロックに微妙なずれが生じますが、TrueTime APIは現在時刻を単一の値ではなく、確実に正しい時刻を含む時間区間（[earliest, latest]）として返します。この設計により、Spannerはグローバルに分散されたトランザクションの順序付けを可能にし、外部一貫性（External Consistency）を保証する仕組みとなっています。 GPS衛星と原子時計による時刻同期は、この時間区間の幅を可能な限り小さく保つための実装手段であり、TrueTime APIの本質的な価値は、クロックの不確実性を明示的にモデル化し、それを分散トランザクション処理に組み込んでいる点にあります。

TrueTime APIや分散システムにおける時刻の取り扱いの課題は去年のアドベントカレンダーで触れておりますので興味がある方はぜひ読んでいただきたいです。

TiDB

TiDB であれば、SQL フロントエンド（TiDB サーバ）と、Raft を用いた分散 KVS である TiKV が分離されています。
TiDB サーバはステートレスなコンピュート層として動作し、クライアントからのSQLクエリを受け取って最適化・実行計画を作成します。一方、TiKVはRaft Consensus Algorithmによって3つ以上のレプリカで構成されるストレージ層を形成し、データの永続化と分散合意を担当します。
この分離により、TiDBはコンピュート層を水平にスケールさせつつ、ストレージ層の耐障害性を独立して確保できる設計となっています。

Amazon Aurora DSQL

Amazon Aurora DSQLは、2024年12月に一般提供が開始された分散SQLデータベースです。従来のAuroraが単一リージョン内でのコンピュートとストレージの分離に焦点を当てていたのに対し、Aurora DSQLは単一のリージョンだけではなく、複数のリージョンにまたがる強い一貫性を持つトランザクション処理を実現しています。すべてのリージョンで書き込みと読み取りの両方を処理できる設計になっています。
Aurora DSQLの最大の特徴は、journalと呼ばれる独自の分散トランザクションログを用いたアーキテクチャです。
journalは、トランザクションログを管理する分散ストレージシステムで、各リージョンに配置されたjournalノードがデータの永続化と複製を担当します。従来のAuroraでは単一リージョン内のストレージ層がクォーラムベースのレプリケーションを行っていましたが、DSQLではこのjournal層がリージョン間での同期レプリケーションを実現しています。
また、DSQLはACID準拠の強い一貫性を提供しながら、リージョン障害時のデータロスなしでの自動フェイルオーバーを実現しています。これは、journal層が複数リージョンにまたがってトランザクションログを同期的に複製し、どのリージョンからでも最新の一貫した状態を読み取れるようにしているためです。

💡Tips: Aurora DSQLは分散合意を回避していると主張している点について

興味深いのは、Aurora DSQLが公式ドキュメントで「分散合意アルゴリズムを回避している」と説明している点です。これは、journal層の設計により、従来の分散合意プロトコル（Paxos、Raftなど）が必要とする複数ラウンドの通信を削減し、より効率的なレプリケーションを実現していることを示唆しています。

依然として分散合意の機能自体はJournal層の内部実装に含まれている可能性がありますが、コンピュート層から見ると、複雑な合意プロセスを意識することなく、強い一貫性を持つトランザクションを実行できるようになっているようです。

コンピュートとストレージの分離に伴うパフォーマンスへの懸念とトレードオフ

コンピュートとストレージを分離することで、ネットワーク越しのI/Oが発生するため、パフォーマンスが低下するのではないかという懸念を持つ方もいるかもしれません。
ネットワークレイテンシによるオーバーヘッドは存在し、分散合意アルゴリズム(PaxosやRaft)を用いた場合も、複数ノード間での合意形成のために追加の通信ラウンドが必要となり、これもレイテンシーのオーバーヘッドとしてデータベースのパフォーマンスとして顕在化します。
実際には、これらのレイテンシーオーバーヘッドは存在するものの、多くのクラウドネイティブデータベースが、従来のモノリシックなアーキテクチャと同等、あるいはそれ以上のパフォーマンスを実現しています。（すくなくとも論文などでそのように主張している物が多いです）

引用元: Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

この理由として、いくつかの技術的な工夫が挙げられます。まず、ストレージ層が専用に最適化されることで、単一のコンピュートノードに縛られない並列度の高いI/O処理が可能になります。
もちろん、コンピュートとストレージの分離以外にも並列処理に対する最適化をはじめとしたさまざまな最適化がなされています。
また、コンピュート層では積極的なキャッシング戦略が採用されており、頻繁にアクセスされるデータはメモリ上に保持されるため、ネットワークI/Oの頻度そのものが削減されます。AlloyDBやNeonでは、インテリジェントなキャッシュ層を設けることで、読み取りパフォーマンスを大幅に向上させています。
重要なのは、このアーキテクチャをトレードオフの観点から評価することです。コンピュートとストレージの分離によるネットワークオーバーヘッド、そして分散合意アルゴリズムによる通信オーバーヘッドのレイテンシーの悪化は存在します。
しかし、それと引き換えに得られるメリットは極めて大きいものです。

スケーラビリティ: コンピュートリソースを独立してスケールでき、需要の変動に柔軟に対応可能
可用性: コンピュートとストレージが独立して障害に対処でき、システム全体の信頼性が向上
運用効率: データコピー不要でインスタンスの追加・削除が可能になり、運用コストが大幅に削減
コスト最適化: 使用するリソースに対してのみ課金され、Serverless構成ではさらにコスト効率が向上

結果として、コンピュートとストレージの分離や分散合意アルゴリズムによるオーバーヘッドは、アーキテクチャ全体の最適化（並列処理、キャッシング、高速ネットワーク）により吸収されます。
そしてスケーラビリティ、可用性、運用効率、コスト最適化といった実用上のメリットが、多くのユースケースでこれらのオーバーヘッドを上回る価値を提供します。
一方で、レイテンシー要件が厳しいワークロードは考慮が必要です。例えば、広告配信やリアルタイム取引システムや高頻度トレーディングのような、ミリ秒単位のレイテンシが求められる用途では、ネットワークオーバーヘッドが許容できない場合があります。
このようなケースでは、従来のモノリシックなアーキテクチャや、コンピュートとストレージを同一ノードに配置する設計の方が適している可能性があります。

まとめ

冒頭で、CNCFによるクラウドネイティブの定義の中で私が重要である要素として「近代的でダイナミックな環境」「スケーラブル」「回復性のある疎結合システム」「インパクトのある変更を最小限の労力で」といった要素を挙げました。
これらを実現しようとした時、従来の「コンピュートとストレージが密結合したアーキテクチャ」では、物理的なデータの制約（コピー時間、ディスク容量、障害時の巻き添え）がどうしてもボトルネックとなり、動的なスケーリングや疎結合性を達成することは困難でした。
つまり、昨今のデータベースにおいてコンピュートとストレージの分離が進んでいるのは、クラウドネイティブな特性をデータベースに実装するための、必然的なアーキテクチャの発展だったと言えます。

「動的でスケーラブル」であるために:
- データの物理コピーという制約からコンピュートを解放し、ステートレスにすることで、秒単位でのインスタンス追加や Serverless (Scale to Zero) を実現しました。
「回復性のある疎結合」であるために:
- 分散合意や修復の責任をストレージ層へ委譲し、コンピュートが落ちてもデータは生き続ける、あるいはその逆も許容できる堅牢なシステムを構築しました。
「インパクトのある変更を最小限の労力で」行うために:
- 従来であれば「数時間のデータコピー」や「慎重なフェイルオーバー手順」を要したリードレプリカの追加や障害復旧といったインフラへの影響が大きい変更を、単なるコンピュートノードの接続操作という低コストで予測可能な作業に変えました。

hacomonoではエンジニアを募集しています

この記事で解説したような、アーキテクチャの背景にある思想を深く理解し、トレードオフを考慮しながら最適な技術選定ができるエンジニアをhacomonoでは積極的に募集しています。
私たちは、単に「新しい技術を使う」のではなく、「なぜそのアーキテクチャが選ばれたのか」「どのような課題を解決しようとしているのか」を理解し、自社のビジネス要件や技術的制約と照らし合わせて判断できる人材を求めています。
クラウドネイティブなシステム設計に興味があり、分散システムやデータベースアーキテクチャについて深く考えることが好きな方は、ぜひhacomonoの基盤本部で一緒に働きませんか？
詳細は以下の採用情報をご覧ください。