第7章 Cassandraでアプリケーションを設計する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
前の章では、Cassandraがデータをどのように表現するのか、Cassandraデータ・モデルをどのように作成するのか、Cassandraのアーキテクチャがデータをクラスターに分散して迅速かつ確実にアクセスできるようにする仕組みについて学んだ。次は、この知識を実際のアプリケーション設計に応用する番だ。
ホテル・アプリケーション・デザイン
第5章で始めたホテルのドメインに戻ろう。ホテル、空室状況、予約を表現するために作成したCassandraデータモデルを活用するアプリケーションの開発を依頼されたとしよう。
データ・モデルからアプリケーションへはどのように移行するのか?結局のところ、データモデルは真空中には存在しない。あなたが設計したテーブルからのデータの書き込みと読み取りを担当するソフトウェア・アプリケーションが存在しなければならない。そのようなアプリケーションを開発するために、多くのアーキテクチャアプローチを取ることができるが、この章ではマイクロサービスアーキテクチャスタイルに焦点を当てる。
Cassandraとマイクロサービス・アーキテクチャ
過去数年間、マイクロサービス・アーキテクチャ・スタイルは、クラウド・ネイティブ・アプリケーションの規律の基礎となってきた。ゼロからクラウド用に設計されたデータベースであるCassandraは、クラウドネイティブ・アプリケーションに自然にフィットする。
ここでは、マイクロサービスアーキテクチャの利点に関する完全な議論を提供するつもりはないが、このトピックに関する優れた情報源であるSam Newmanの著書『Building Microservices』(O'Reilly)で紹介されている原則のサブセットを参照する:
- カプセル化
-
カプセル化は、"ひとつのことをうまくやることに集中したサービス"、あるいは "単一責任の原則 "と言い換えることもできる。
対照的に、多くの企業ではデータベースが中心的な統合ポイントとして機能している。アプリケーションはリモートプロシージャコール(RPC)やメッセージングインターフェースのような他のアプリケーションへのインタフェースを公開するかもしれないが、あるアプリケーションが他のアプリケーションのデータベースに直接アクセスすることもよくある。
図7-1. データベースによる統合とマイクロサービスでは対照的である。
- 自律性
-
マイクロサービスアーキテクチャにおいて自律性とは、他のマイクロサービスに依存することなく、各マイクロサービスを独立してデプロイできる能力のことを指す。この柔軟性は、停止時間なしにデプロイされたアプリケーションの一部を独立して進化させ、サービスの新バージョンを徐々に導入し、これらのデプロイのリスクを最小限に抑えることができるという大きな利点がある。
自律性のもう1つの意味は、各マイクロサービスが、そのサービスに最も適したテクノロジーを使用して、独自のデータストアを持つことができるということである。この柔軟性については、"Polyglot persistence ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access