平成31年 春 午前II

Tweet

問1

イのCAPの定理が正解。エのベイズの定理は関係なさすぎる。よく選択肢に入れてきたものだ、と思うほど関係なさすぎる。ベイズの定理が気になる人はググってください。

アムダールの法則

ある計算機システムとその対象とする計算についてのモデルにおいて、その計算機の並列度を上げた場合に、並列化できない部分の存在、特にその割合が「ボトルネック」となることを示した法則である。とwikipediaに書いてあるが、ようするに並列化して処理速度あげようとしても限界があるよ、ということを言っている。一台のPCで10000回計算すると10000秒かかる処理があったとして、じゃあ、PCを2台にすると、半分の5000秒で済むか？というと、オーバーヘッドや同期待ちなどでそんなにうまくはいかないよ、という感じのお話。同時に二つまでしか満たさないという理論とは全く関係ない。

CAPの定理

正解。
ＣＡＰの「Ｃ」「Ａ」「Ｐ」について。

• Consistensy。一貫性。いつでも一貫して正しいデータになる。分散DBなどでサーバAにアクセスしたときと、サーバBにアクセスしたときで得られるデータが違うとかはNG。
• Availabilility。可用性。いつでもデータにアクセスできる。クラウドのDBみたいなものがイメージに近い。
• Partition-tolerance。分断耐性。ネットワークが一部接続できなくなってもデータにアクセスできる。

CAP定理のポイントは、一貫性と可用性と分断耐性を同時に満たすことはできず、最大2つまでしか保証できないという点です。

Pを捨ててCとAを保証

いつでも一貫して正しいデータ(C)に、いつでもデータにアクセスできる(A)ようにするにはネットワークで接続されていること(P)が重要です。しかし、ネットワークがダメになった場合は、CもAも維持できません。それでもCとAを保証しろ！というなら、ネットワークにつながず、一台のサーバ内で運用すれば維持できます。相当重要な機密情報のデータがあるサーバみたいなイメージ。

Aを捨ててCとPを重視

いつでも一貫して正しいデータ(C)に、ネットワークが切れてもアクセスできるようにする(P)には、いつでもアクセスできる(A)ことをあきらめるしかない。つまり、データの一貫性が崩れたら、サーバにアクセスできないようにしてからデータの整合性を回復し、その後アクセスできるようにするような感じ。オンラインゲームによくある、夜間はメンテナンスのため接続できません、みたいなイメージ。

Cを捨ててPとAを重視

ネットワークが分断されても(P)、いつでもアクセスしたい(A)場合。これはさすがに一貫性(C)を捨てるしかない。ネットワークが分断されると、サーバ間で一貫性は維持できない。かといって、一貫性を回復させるためにアクセスを遮断し、回復してから接続させるオンラインゲーム方式も嫌だ、という場合。基本的に多少データに不整合があってもいいから、常にアクセスしたいような場合です。不整合は時間差で帳尻合わせします。ブロックチェーンやgithubで複数人とソースコードを編集する場合がこのタイプ。

BASE特性

不正解。
BASE特性は、CAPの定理に「ちょっともの申す」みたいな話。BASE特性はクラウドのDB向けのような話。暗にCAPの定理を古いとディスってる。どこが古いのか？クラウドだとネットワークの分断耐性が強くないといけない。これをCAPの定理に当てはめると、一貫性か、可用性を捨てるしかない。つまり、上述のオンラインゲーム方式かgithub方式のどちらを選べという状況になる。オンラインゲーム方式にした場合は、「夜間接続ダメよ」になるし、github方式すると「最新のソースはgithubにあるとは限らない」になるので、サーバのデータは常にちょっと古い、みたいな状況になる。クラウドは「可用性」が超重要。ときどきデータにアクセスできない、というのは本気で困る。年末サーバを停止しますとか言われたら、メンテナンスできなくなってしまう。
よって、基本的には可用性と分断耐性を重視しようぜ、だけど、一貫性を捨てろというのは、それはそれで使えないので、時間差があってもいいから一貫性も頑張ろうぜ！と言っているのがBASE特性。

Base特性はこんな感じ。
Basically Avalilable(基本的に動け、止まるなよ）
BASE特性の「BA」。クラウドだから常にサービスは止めるな提供しろという24時間365日働き続けろというコンビニ特性。

Soft-State(緩いステータス)
BASE特性の「S」。ステータスは厳密じゃなくていいやという特性。githubのマスターが最新かというとそういうわけではなく、作業者のＰＣの中のソースが最新なんてことはよくある。それでいいから動け、止まるな、という特性。

Eventual Consistency(どっかのタイミングでマージしようぜ)
BASE特性の「E」。いくら一貫性を捨てるといっても、エンドレスに一貫性がないのはだめなので、gitみたいにどこかでマージして最新の状態にしようぜ、みたいなイメージ。実際はそんなに悠長な同期じゃなくて、データの一貫性はもうちょっと頻繁にやるはず。

BASE特性について、わかればいいやのレベルで解説しましたが、BASE特性は不正解。