LASSIC Media らしくメディア
BASE特性｜ACIDと対をなす一貫性の考え方
大量のアクセスをさばく大規模なサービスでは、一台のデータベースにすべてを預けるのではなく、複数のサーバへデータを分散させる構成がよく採られます。ところが分散させると、「どのサーバを見ても、つねに同じ最新の値が返る」という状態を保つのが難しくなります。そこで登場するのが、厳密な一貫性を少しゆるめる代わりに、使い続けられることと規模への強さを優先する考え方——BASEです。
BASEは、従来の堅いデータベースが重んじてきたACIDと対をなす設計思想として知られています。どちらが優れているという話ではなく、扱うデータの性質に応じて選び分けるものです。この記事では、発注者やプロジェクトマネージャー、これからシステムの設計に関わる方に向けて、BASEの意味とACIDとの違い、そして使い分けの勘所を整理していきます。
BASE特性とは
BASE特性とは、分散したシステムでデータを扱うときの考え方の一つで、厳密な一貫性よりも、使い続けられることと規模への強さを優先する設計思想を指します。BASEは三つの言葉の頭文字をつないだ呼び名で、「基本的に使える（Basically Available）」「状態は移ろいうる（Soft state）」「いずれ整合する（Eventually consistent）」という三つの性質を表しています。
この考え方が生まれた背景には、扱うデータの量とアクセスが桁違いに増えたことがあります。従来のように一台に集めて厳密にそろえようとすると、規模が大きくなるほど処理が追いつかず、止まりやすくなります。そこで、「更新した値がすべてのサーバへ行き渡るまでには少し時間がかかってもよい」と割り切り、そのぶん止まりにくく、増やしやすいシステムを目指す——これがBASEのねらいです。
「いずれ整合する」という言い回しがBASEの肝です。更新した直後は、見るサーバによって古い値が返ることもありますが、時間が経てば全体が同じ値に落ち着きます。この「少しの間のずれ」を許すかどうかが、次に見るACIDとの分かれ目になります。
この記事のポイント
- BASEは、厳密な一貫性をゆるめ、可用性と規模への強さを優先する分散システムの設計思想です。
- 「基本的に使える・状態は移ろう・いずれ整合する」の頭文字で、結果整合性がその核です。
- 厳密さを重んじるACIDと対をなし、扱うデータの性質に応じて選び分けます。
BASEを構成する3つの要素
BASEという呼び名を作る三つの言葉には、それぞれ意味があります。順に見ていきましょう。
| 要素 | 意味 |
|---|---|
| 基本的に使える | 一部に不具合が起きても、システム全体としては応答を返し続ける |
| 状態は移ろいうる | 値が行き渡る途中では、サーバごとに内容が一時的に食い違うことを認める |
| いずれ整合する | 更新がすべてのサーバへ伝わりきれば、最終的には同じ値に落ち着く |
三つに共通しているのは、「その瞬間に完全にそろっていること」よりも、「止まらず動き続け、いずれ整うこと」を重んじる姿勢です。とくに三つめの「いずれ整合する」は、結果整合性とも呼ばれ、BASEを語るうえでの中心にあたります。厳しく言えば「一時的なずれ」を抱えることになりますが、その代わりに、一部のサーバが不調でもサービス全体は動き続けられる、という強さが得られます。
ACIDとの違い
BASEを理解するには、対になるACIDと並べて見るのがいちばんの近道です。ACIDは、銀行の口座振替のように「全部成功か、全部なかったことにするか」を厳密に守り、つねにそろった状態を保つ考え方でした。両者を対比してみましょう。
| 観点 | ACID | BASE |
|---|---|---|
| 重んじること | 厳密な一貫性 | 可用性と規模への強さ |
| 一貫性の保ち方 | つねにそろっている | いずれそろう（結果整合性） |
| 得意な場面 | 金額や在庫など厳密さが要る処理 | 大量アクセスをさばく大規模なサービス |
| 主な使われ方 | 従来の関係データベース | 分散型のデータベース（NoSQLなど） |
この違いの背景には、分散システムの宿命ともいえる制約があります。サーバ同士をつなぐネットワークが一時的に途切れたとき、「そろっていること」と「使えること」の両方を同時には保ちきれない、という関係です。ACIDは前者を、BASEは後者を選ぶ、と捉えると分かりやすくなります。下の図は、両者の立ち位置を表したものです。
くり返しになりますが、これは優劣の話ではありません。厳密さが欠かせない場面ではACIDが向き、規模と止まりにくさが問われる場面ではBASEが向きます。扱うデータが何を求めているのかによって、選ぶ側が変わるだけです。
どう使い分けるか
ACIDとBASEのどちらに寄せるかは、「そのデータに、一瞬のずれが許されるか」で考えると整理しやすくなります。判断の目安を挙げておきます。
厳密さが欠かせないのは、たとえば口座の残高や決済、在庫の引き当てのように、一瞬でも値がずれると実害につながるデータです。二重に引き落とされたり、売り越したりといった事態は避けたいため、こうした処理にはACIDの考え方が向きます。
一方で、多少のずれが業務上問題にならないデータもあります。投稿への反応の数や、閲覧数の集計、おおよその在庫表示などは、更新が全体に行き渡るまで少しの時間差があっても、大きな支障にはならないのです。むしろ、アクセスが集中しても止まらず応答を返し続けることのほうが価値を持ちます。こうした領域では、BASEの考え方がなじみます。
実際の大規模なシステムでは、この二つを一つのサービスのなかで組み合わせることも珍しくありません。お金にかかわる中核はACIDで固く守りつつ、反応数や表示のような周辺はBASEで軽やかにさばく、という具合です。どのデータをどちらで扱うかを見極めることが、規模と正確さを両立させる勘所になります。
発注・開発でおさえる点
BASEかACIDかという選択は、システムの土台に関わる判断です。発注や設計の段階で意識しておきたい点を挙げます。
データごとに求める厳密さを整理する
すべてのデータを一律に扱うのではなく、「一瞬のずれも許されないデータ」と「多少のずれなら許容できるデータ」を仕分けておきます。この仕分けが、どこをACIDで守り、どこをBASEに委ねるかの判断材料になります。業務の要件に直結するため、発注する側からも整理して示しておきたい観点です。
結果整合性の見え方を確かめておく
BASEを採る箇所では、「更新した直後は、まだ古い値が見えることがある」という振る舞いが利用者にどう映るかを、あらかじめ確かめておきます。たとえば投稿直後に反応数が一瞬ずれて見えても支障は小さいですが、画面の作り方によっては誤解を招くこともあります。どこまでのずれなら許容できるかを、要件として言葉にしておくとよいでしょう。
拡張の見通しをふまえて選ぶ
扱うデータ量やアクセスが将来どこまで増えそうかは、BASEとACIDの選択に関わります。当面は一台で厳密に扱えても、規模の拡大が見込まれるなら、早い段階から分散を前提に据えておく判断もあるのです。目先だけでなく、先の伸びを見越して方針を定めておくことが、後の作り直しを抑えます。
よくある誤解と勘所
BASEは言葉の印象から、実際とずれた受け取られ方をされがちです。代表的なつまずきを表にまとめました。
| よくある誤解 | 実際のところ |
|---|---|
| BASEはデータがそろわない | いずれはそろう。ずれるのは行き渡るまでの一時的な間だけ |
| BASEのほうが新しく優れている | 優劣ではなく用途の違い。厳密さが要る処理はACIDが向く |
| ACIDとBASEはどちらか一方だけ | 一つのサービス内で、データごとに使い分けることも多い |
| NoSQLなら自動でBASEになる | 製品や設定で挙動は変わる。どうそろうかは確認が要る |
勘所をひとことでいえば、BASEは「一瞬のずれを認める代わりに、止まりにくさと規模を手に入れる」考え方だと捉えることです。厳密さと引き換えに得るものがある、という取引の関係を押さえておくと、どのデータをどちらで扱うべきかの判断がしやすくなります。すべてを厳密にそろえようとせず、データの性質に応じて力の入れどころを変える——その見極めが、大規模なシステムを支える土台になります。
まとめ
- BASEは、厳密な一貫性をゆるめ、可用性と規模への強さを優先する分散システムの設計思想である。
- 「基本的に使える・状態は移ろう・いずれ整合する」の頭文字で、結果整合性がその核にあたる。
- つねにそろった状態を保つACIDと対をなし、どちらが優れているという話ではない。
- 厳密さが要る処理はACID、大規模で止まりにくさが問われる領域はBASEが向く。
- 一つのサービス内でデータごとに使い分けることも多く、求める厳密さの仕分けが勘所。
よくある質問
BASEとACIDは、どちらを選ぶべきですか。
扱うデータの性質によって変わるため、一律にどちらがよいとはいえません。口座の残高や決済、在庫の引き当てのように、一瞬のずれも許されないデータには、厳密な一貫性を守るACIDが向くのです。一方、投稿への反応数や閲覧数の集計のように、多少のずれが業務上問題にならないデータには、止まりにくさと規模に強いBASEがなじみます。実際の大規模なシステムでは、中核はACID、周辺はBASE、というように一つのサービスのなかで使い分ける形もよく採られます。
結果整合性とは、どういう意味ですか。
結果整合性とは、更新した値がすべてのサーバへ行き渡るまでには時間がかかるものの、最終的にはすべてが同じ値に落ち着く、という一貫性の保ち方です。更新した直後は、見るサーバによって古い値が返ることもありますが、しばらくすれば全体がそろいます。BASEの核となる考え方で、「その瞬間の完全な一致」よりも「止まらず動き続け、いずれ整うこと」を優先する場面で用いられます。反応数の表示のように、一時的なずれが支障になりにくいデータと相性がよい仕組みです。
BASEはCAP定理とどう関係しますか。
深く関わっています。CAP定理は、分散システムでネットワークが途切れたとき、一貫性と可用性の両方を同時には保ちきれない、という関係を示したものです。この分かれ道で、BASEは可用性のほうを選ぶ立場だと捉えると分かりやすくなります。つまり、ネットワークに問題が起きても止まらず応答を返し続けることを優先し、一貫性については「いずれそろう」という結果整合性で補う、という組み立てです。CAP定理が制約を示し、BASEがその制約のなかでの選び方を表す、という関係になります。
NoSQLを使えば、自動でBASEになりますか。
一概にそうとはいえません。分散型のNoSQLはBASEの考え方と相性がよいのですが、製品や設定によって、一貫性の保ち方は変わるのです。同じNoSQLでも、より厳密な読み取りを選べるものもあれば、結果整合性を基本とするものもあります。そのため、利用する製品がデータをどのようにそろえるのか、どの設定でどう振る舞うのかを、資料で確かめたうえで設計することが欠かせません。名前だけで判断せず、実際の挙動を押さえることが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、データ設計や分散システムのアーキテクチャ方針づくりから実装、公開済みシステムの見直しまでを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。一貫性の設計やデータベースの選定でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
