ITエンジニアのCAPの定理

CAPの定理というのがある、

「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。

説明をwikipediaにゆずると、

・一貫性 (Consistency):
全てのノードにおいて同時に同じデータが見えなければならない。

・可用性 (Availability):
ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。

・分断耐性 (Partition-tolerance):
システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース(ネットワーク分断)を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計は可用性が成立しない。

この定理によると、分散システムはこの3つの保証のうち、同時に2つの保証を満たすことはできるが、同時に全てを満たすことはできない。可用性を成立させるには単一障害点をなくさないといけないが、すると、ネットワーク分断が発生した際、システムがバラバラに分裂してしまい、単一障害点があればそこを基準に一貫した応答ができるが、単一障害点をなくしてしまうとシステムの応答の一貫性が成立できなくなるという定理。

となる。

相反する3つの特性が同時に2つしか満たせないのではないか、というこの定理、
もしかしたら、ITエンジニアのモチベーション維持に関しても言えるのではないかという話が今回の話です。

※これね、チームメンバーで焼肉いった時のよもやま話なので、細かいところはスルーでお願いします。

ITエンジニアのCAPの定理

エンジニアが自分の関わるサービス・プロダクトに対して、モチベーションを維持するための特性として以下のものがあるんじゃないかと感じている。

Cash(自分が関わっているプロジェクトでお金を稼げていること):

サービスにユーザーが沢山居て、お金が稼げている。ポジティブなものもネガティブなものもあるが、feedbackが多くてやる気が出るし、給料という分かりやすい収入に繋がるので、モチベーション維持にも繋がりやすい。

Awesome Engineering (ソフトウェアエンジニアリングが素晴らしいこと):

コードが綺麗、 テストが書きやすい、定期的にカバレッジが計測される等。
成果物がメンテンナンス可能な状態であり、整流化されていて気持ちがいい。

Postmodern Technology (新しい流行の技術が使われていること):

いわゆるエンジニアが好きな新しい流行の技術が使われている事。まだ世の中でその技術が浸透しきっていないが、流行の技術に乗ることで自分の能力向上にもなるし、うまく行けばその技術の第一人者になれる。

ちょっと強引だけど、Cash, Awesome Engineering, Postmodern Technologyで CAPの定理。

これらの全てを満たすことは難しいのではないかというのが今回の説。


■Cashを満たした場合、
使っている人も増えてフィードバックが増えて楽しい。

ただお金を稼いでいるサービスはその機能を継ぎ足し継ぎ足ししていくし、関わる人も増える傾向にある、その結果重厚長大なものになりやすく、スケジュールに追われやすい。

結果、人が増えることやスケジュールに追われることでコードが綺麗じゃなくなったり、テストがされなくなったりして、徐々にソフトウェアエンジニアリングで担保したかった領域(Awesome Engineering)が失われることになる。

■Awesome Engineeringを満たした場合、
自分達の成果物が常にきれいな状態に保つ、それによりメンテナンス可能な状態が続くし、整流化されていて気持ちがいい。
ただし、Postmodernな技術はまだノウハウが溜まりきっていないため、そんな整流化されていない事が多い。
結果バッドノウハウによってソースコードが綺麗じゃなくなったりする。
凄い技術者ならPostmodern technologyとAwesome Engineeringを両立できるのかもしれないが、それをやるには割りとまとまった時間が必要だし、そうするうちにコストがかかり、結果Cashを満たす機会が失われることになりかねない。

■Postmodern Technologyを満たした場合、
流行の技術を使ってエンジニアとしてこれまでにない新しい価値をエンドユーザーに提供することができる。また、そこまで行かなくても最新技術に追従することでスキル向上になる。

ただし、新しい価値がエンドユーザーに受け入れられるかどうかはまた別な問題。うまく受け入れられればCashとPostmodern Technologyを満たせるが、やっぱり、ノウハウが溜まりきっていない技術はAwesome Engineeringと両立は難しい。

というわけでどうすればいいのか

いや、書きたかっただけであんまり落ちはないんだけど。

CAPを満たすことは難しいけど、不可能ではない気もする。
少なくとも技術者の力量次第で A と P は満たせる気がする。後は会社の方針や経営、企画等の要望提供側からの理解があれば C を満たした後も 持続可能な エンジニアリングを続けられる。。。んじゃないかなー。。。

さらに言えばエンジニアの全てがCAPを同じプライオリティにおいているわけじゃなさそうだしなー。それに応じてベストな人材配置ができればいいような気がする。

CとA重視の堅実なRDB系エンジニア、CとP重視の流行りモノ好きなHBase系エンジニア、AとP重視の研究職っぽいCassandra系エンジニアとかにまた分類できそうだけど、長くなりそうなのでこの辺で。