データアーキテクチャとCAP定理：どこで衝突するのか？

データアーキテクチャとCAP定理：衝突する場所は？

編集者のコメント：Joep Kokkelerはこの秋のODSC Westのスピーカーです。彼のトーク、「KappaデータアーキテクチャでCAPを捕捉する」もぜひチェックしてください！

さまざまなデータアーキテクチャについて話す前に、まずはCAP定理に焦点を当てましょう。CAP定理は、一貫性、可用性、信頼性の3つのうち、システム（現時点ではアシッドトランザクションを除く）で2つを選ぶことができるが、すべてを選ぶことはできないと述べています。これに対処するには、アーキテクチャの選択時に適切な選択をすることができます。

アーキテクチャについて話すとき、人々は常にどのアーキテクチャタイプを指すのかを知っていると想定しています。しかし、もし知らなかったらどうでしょうか？たとえば、あなたがラムダアーキテクチャの技術的な実装を知っているが、これが他の実装と比較してどういう意味なのかわからない場合はどうでしょうか。

• 「サンフランシスコ大学データサイエンスカンファレンス2023年データソン（Datathon）は、AWSおよびAmazon SageMaker Studio Labと提携して開催されます」
• 「Androidのための10最高のデータ復旧ツール」
• 「AIと大学フットボールの未来」

簡単な例えを使って説明しましょう。

皆さんは一度は動物園に行ったことがあると思います。様々な種類の動物がいて、それらの動物の世話をするためには様々なスキルが必要です。動物園を運営するためには、適切な知識を持っているか、または動物の世話をする方法を知っている人を雇う必要があります。アーキテクチャを選ぶこともほぼ同じです。すべての実装についてすべてを知る必要はありませんが、自分が取り組んでいるものを知る必要があります。

モノリス

まず、モノリスアーキテクチャから始めましょう。その名前が示すように、それは大きくて古く、多くのスペースを取り、おそらくは象です。具体的には、アフリカのブッシュ象であり、周りの人たちと一緒に生まれた頃からアーキテクチャという用語が生まれた頃から世話をする方法を知っています。1人のインターンが偉大な獣と一緒に働こうとしましたが、その後、多くの問題を引き起こしたため、モノリスの世話をするのはその頃に生まれた人が最善です。

マイクロサービス

次はマイクロサービスです。マイクロサービスアーキテクチャでは、各サービスが独自の責任を持つことが重要です。時にはその責任が溢れて、あっという間にミニモノリスを実行していることになります。そして、若い灰色の象を自分が望む場所に導くためには、全く異なるスキルセットが必要です。マイクロサービスに対する私の最も適切な比較は、オオカミの群れです。野生の中で、群れは直線的に前進します（エネルギーを節約するため）し、全員が正しい順序で並んでいます。そして、パックの各位置には特定の責任があります。

インターネットで広まっている画像があります。そこでは、雪の中で野生の群れを見ることができ、キャプションには前のオオカミが病気や年老いていると書かれています。それらが取り残されたり攻撃されたりしないように注意する必要があります。雪の中での移動は多くのエネルギーを必要とするため、すでに弱っているオオカミを前に置くのは意味がありません。マイクロサービスも同様で、最初のサービスは少し肥大化しているかもしれませんが、他のサービスのために重い作業を行います。ラムダアーキテクチャは、そのコンポーネントのサイズが小さく、常に複数のコンポーネントを必要とすることで知られています。

それで、それはもっともアライグマのグループに似ています。アライグマのグループは「集団」と呼ばれます。複数のラムダのグループを実行するとは言わずに、あなたの指導の下にいくつかの集団がいると考えてください。アライグマとラムダの共通点は、責任をできるだけ小さくする必要があることです。そうしないと、アライグマはそのままにしておくでしょう。過去には、アライグマが実際にやりたいことをするまでに数分かかることがありましたが、それを解決するためにやることを与えることで対処しました。これにより、アライグマが仕事をするのが簡単になり、仕事の結果を次のアライグマに渡すことができます。そして、あなたのコントロール下には、あなたが望むことをしてくれる多くの集団があります。

カッパ

最後に、カッパアーキテクチャです。太ったペンギンを想像してください、「マダガスカルへの脱出」のあの人たちのようなペンギンです。ペンギンは常にグループで移動する必要があるため、カッパアーキテクチャの中には、ただ微笑んで手を振っているたくさんのペンギングループがいます。しかし、実際には、アーキテクチャを非常に速く、準備ができて賢くしたいのです。ですから、同じペンギンでも背中にロケットを取り付けたものを想像してください。それが私たちのカッパアーキテクチャの基礎です。たくさんのペンギンにたくさんのロケットが取り付けられています。カッパアーキテクチャで働くためには、ロケットの科学者である必要はありません。

結論

これで私たちはどのような種類のビーストを見ているのかを把握しましたが、Cap定理のすべての3つのコンポーネントを持つアーキテクチャを実装するにはどうすればよいでしょうか？Cap定理に最適なビースト（またはロケットを持つペンギン）は何なのかを知るために、この問題の詳細な説明と、異なる実装についてのライブデモを見るために、ODSC Westのサンフランシスコで私に会いに来てください。

著者について：

Joep Kokkelerは、エネルギーから衣料品製造までさまざまな市場でデータ製品の開発、エンジニアリング、アーキテクチャ、可視化の経験を12年以上積んでいます。彼はチームがデータを扱うのが上手になり、ライブに行き、プロダクションに滞在するために必要なツールと知識を提供することに焦点を当てています。

彼はTeqnationプログラム委員会のメンバーであり、サッカー中にKafkaとHueの使用についてプレゼンテーションを行い、Hololensでの開発と展開、Gitlabを使用したトータルDevOps、データサイエンス製品の進化、PoCからプロダクションへの弾力的なスタックの使用、Devoxx Londonでの自転車でのXbox Kinectについて活動していました。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!