翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Keyspaces (Apache Cassandra 向け) とは
Amazon Keyspaces (Apache Cassandra 向け) は、スケーラブルで可用性の高い、Apache Cassandra 互換のマネージドデータベースサービスです。Amazon Keyspaces を使用すると、サーバーのプロビジョニング、パッチ、管理、さらには、ソフトウェアのインストール、メンテナンス、運用も、ユーザーが行う必要がなくなります。
Amazon Keyspaces はサーバーレスであるため、使用するリソースに対してのみ課金され、アプリケーショントラフィックに応じてテーブルの拡大と縮小が自動的に行われます。スループットとストレージが実質的に無制限で、毎秒数千件のリクエストを処理できるアプリケーションを構築できます。
**注記**
Apache Cassandra は、データの大量を可能にするオープンソースのワイド列データストアです。詳細については、[「Apache Cassandra」](http://cassandra.apache.org/)を参照してください。
Amazon Keyspaces を使用すると、 AWS クラウドにおける Cassandra ワークロードの移行、実行、スケーリングが簡単になります。 AWS マネジメントコンソールまたは数行のコードをクリックするだけで、インフラストラクチャをデプロイしたりソフトウェアをインストールしたりすることなく、Amazon Keyspaces でキースペースとテーブルを作成できます。
Amazon Keyspaces では、現在使用している AWS のと同じ Cassandra アプリケーションコードと開発者ツールを使用して、 で既存の Cassandra ワークロードを実行できます。
Github で利用可能な [Amazon Keyspaces (Apache Cassandra 向け) の料金計算ツール](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra)を使用すると、既存の Apache Cassandra ワークロードに基づいて Amazon Keyspaces の月額コストを見積もることができます。Amazon Keyspaces の Cassandra nodetool ステータス出力と意図したサーバーレス設定からメトリクスを入力して、2 つのソリューション間の直接コストを比較します。この計算ツールは、既存の Cassandra デプロイと比較した Amazon Keyspaces の運用コストにのみ重点を置いていることに注意してください。インフラストラクチャのメンテナンス、運用オーバーヘッド、Cassandra のサポートコストなどの総所有コスト (TCO) 要因は含まれません。
使用可能な エンドポイント AWS リージョン と エンドポイントのリストについては、[「Amazon Keyspaces のサービスエンドポイント](https://docs.aws.amazon.com/keyspaces/latest/devguide/programmatic.endpoints.html)」を参照してください。
最初に以下のセクションを読んでおくことをお勧めします。
**Topics**
+ [Amazon Keyspaces: 仕組み](how-it-works.md)
+ [Amazon Keyspaces のユースケース](use-cases.md)
+ [Cassandra クエリ言語 (CQL) とは](what-is-cql.md)
# Amazon Keyspaces: 仕組み
Amazon Keyspaces では、Cassandra の管理にかかる管理オーバーヘッドが取り除かれます。その理由を理解するには、Cassandra アーキテクチャについて調べた上で Amazon Keyspaces と比較するとよいでしょう。
**Topics**
+ [高レベルのアーキテクチャ: Apache Cassandra と Amazon Keyspaces の比較](#how-it-works.cassandra-arch)
+ [Cassandra のデータモデル](#how-it-works.data-model)
+ [アプリケーションからの Amazon Keyspaces へのアクセス](#how-it-works.keyspaces-arch.accessing)
## 高レベルのアーキテクチャ: Apache Cassandra と Amazon Keyspaces の比較
従来の Apache Cassandra は 1 つ以上のノードで構成されるクラスターにデプロイされます。各ノードの管理と、クラスターのスケールに応じたノードの追加および削除は、ユーザーに責任があります。
クライアントプログラムは、いずれかのノードに接続して Cassandra クエリ言語 (CQL) ステートメントを発行することにより Cassandra にアクセスします。*CQL* は、リレーショナルデータベースで使用される一般的な言語である SQL に似ています。Cassandra はリレーショナル・データベースではありませんが、CQL は Cassandra 内のデータのクエリと操作のための使い慣れたインタフェースを提供します。
次の図は、4 つのノードで構成されるシンプルな Apache Cassandra クラスターを示しています。
![\[4 つのノードを含み、クライアントアプリケーションと通信する Apache Cassandra クラスターの図。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/keyspaces_cassandra-hi-level.png)
本番稼働用の Cassandra のデプロイは、1 つまたは複数の物理データセンターで数百台の物理コンピュータ上で動作する数百のノードで構成されている可能性があります。ソフトウェアのインストール、保守、および運用に加えて、サーバーのプロビジョニング、パッチ適用、管理を行わなければならないアプリケーションデベロッパーに、運用上の負担がかかる可能性があります。
Amazon Keyspaces (Apache Cassandra 向け) では、サーバーのプロビジョニング、パッチ適用、管理が不要なため、より優れたアプリケーションを構築することに集中できます。Amazon Keyspaces では、読み取りと書き込みの 2 つのスループットキャパシティモード (オンデマンドとプロビジョニング) があります。テーブルのスループットキャパシティモードを選択すれば、ワークロードの予測可能性と変動性に基づいて読み取りと書き込みの料金を最適化できます。
オンデマンドモード (デフォルト) - アプリケーションにより実行される実際の読み取りと書き込みに対してのみ料金が発生します。テーブルのスループットキャパシティを事前に指定する必要はありません。Amazon Keyspaces は、アプリケーショントラフィックの上昇と下降にほぼ瞬時に対応するため、トラフィックが予測不能であるアプリケーションに適しています。
プロビジョンドキャパシティモードでは、予測可能なアプリケーショントラフィックがあり、テーブルのキャパシティ要件を事前に予測できる場合に、スループットの料金を最適化できます。プロビジョンドキャパシティモードを使用する場合、アプリケーションに必要な 1 秒あたりの読み取り回数と書き込み回数を指定します。[オートスケーリング](https://docs.aws.amazon.com/keyspaces/latest/devguide/autoscaling.html)を有効にすると、テーブルのプロビジョンドキャパシティが自動的に調整されます。
ワークロードのトラフィックパターンについて詳しく学んだとおり、大量のテーブルトラフィックの発生が予想される主要なイベントなど、トラフィックの大幅なバーストが予想される場合は、テーブルのキャパシティモードを 1 日 1 回変更することができます。読み取り/書き込みキャパシティのプロビジョニングについては、「[Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する](ReadWriteCapacityMode.md)」を参照してください。
Amazon Keyspaces (Apache Cassandra 向け) では、耐久性と高可用性のために、3 つのデータコピーが複数の[アベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)に保存されます。さらに、データセンターと、セキュリティを非常に重視する組織の要件を満たせるように構築されたネットワークアーキテクチャーというメリットがあります。保管データ暗号化は、新しい Amazon Keyspaces テーブルを作成し、すべてのクライアント接続に Transport Layer Security (TLS) が必要になった場合に、自動的に有効化されます。その他の AWS セキュリティ機能には、[モニタリング](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html)[AWS Identity and Access Management](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_service-with-iam.html)、、[仮想プライベートクラウド (VPC) エンドポイント](https://docs.aws.amazon.com/keyspaces/latest/devguide/vpc-endpoints.html)などがあります。使用可能なすべてのセキュリティ機能の概要については、「[Amazon Keyspaces (Apache Cassandra 向け) のセキュリティ](security.md)」を参照してください。
Amazon Keyspaces のアーキテクチャを次の図に示します。
![\[クライアントアプリケーションと通信する Amazon Keyspaces の図。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/keyspaces-hi-level.png)
クライアントプログラムは、事前に定義されたエンドポイント (ホスト名とポート番号) に接続し、CQL ステートメントを発行して、 Amazon Keyspaces にアクセスします。利用可能なエンドポイントのリストについては、「[Amazon Keyspaces のサービスエンドポイント](programmatic.endpoints.md)」を参照してください。
## Cassandra のデータモデル
Amazon Keyspaces から最適なパフォーマンスの達成を目指す上で、ビジネスケースのデータをどうモデル化するかが重要になります。データモデルが貧弱だとパフォーマンスが大幅に低下する可能性があります。
CQL は SQL に似ていますが、Cassandra とリレーショナルデータベースではバックエンドが大きく異なっているため、別の方法でアプローチする必要があります。次に、考慮すべき重要な問題をいくつか取り上げます。
[**Storage (ストレージ)**]
テーブルで Cassandra データを可視化することができます。各行はレコードを表し、各列はそのレコード内のフィールドを表します。
**テーブルデザイン: クエリ重視**
CQL には `JOIN` がありません。したがって、データの形状と、ビジネスユースケースのためにデータにどうアクセスする必要があるかを考慮して、テーブルを設計する必要があります。これにより、重複データがある非正規化が生じる可能性があります。各テーブルを特定のアクセスパターンに合わせて設計する必要があります。
**パーティション**
データはディスク上のパーティションに保存されます。データが保存されているパーティションの数とパーティション間でデータの分散状況は、*パーティションキー*によって決まります。パーティションキーの定義方法は、クエリのパフォーマンスに大きな影響を与える可能性があります。ベストプラクティスについては、[Amazon Keyspaces でパーティションキーを効果的に使用する方法](bp-partition-key-design.md)を参照してください。
**プライマリキー**
Cassandra では、データはキーバリューペアとして保存されます。Cassandra のすべてのテーブルには、テーブルの各行を一意に識別するプライマリキーが必要です。プライマリキーは、必須のパーティションキー 1 つと、オプションのクラスタリング列 1 つ以上で構成されます。プライマリキーを構成するデータは、テーブルのすべてのレコードに対して一意でなければなりません。
+ **パーティションキー** — プライマリキーのパーティションキー部分は必須で、データが保存されるクラスターのパーティションを決定します。パーティションキーは、1 つの列である場合もあれば、2 つ以上の列で構成される複合値である場合もあります。単一列パーティションキーを使用すると、ほとんどのデータが単一のパーティションまたは非常に少数のパーティションに保存され、そのためにディスク I/O オペレーションの大部分を単一列パーティションキーが占める結果となる場合は、複合パーティションキーを使用した方がよいでしょう。
+ **クラスタリング列** – プライマリキーのオプションのクラスタリング列部分は、各パーティションにおけるデータのクラスター処理方法とソート方法を決定するものです。プライマリキーにクラスタリング列を含めると、クラスタリング列には 1 つ以上の列が存在します。クラスタリング列内に複数の列が存在する場合、クラスタリング列内の列の順序 (左から右) によってソート順序が決まります。
NoSQL 設計と Amazon Keyspaces の詳細については、「[NoSQL 設計の主な相違点と設計原則](bp-general-nosql-design.md)」を参照してください。Amazon Keyspaces およびデータモデリングの詳細については、「[データモデリングのベストプラクティス: データモデル設計時の推奨事項](data-modeling.md)」を参照してください。
## アプリケーションからの Amazon Keyspaces へのアクセス
すでに使用している CQL および Cassandra ドライバーを使用できるように、Amazon Keyspaces (Apache Cassandra 向け) には Apache Cassandra クエリ言語 (CQL) API が実装されています。アプリケーションの更新は、Cassandraドライバーの更新や、Amazon Keyspaces サービスエンドポイントを指すための `cqlsh` 設定と同じくらい簡単です。必要な認証情報の詳細については、「[Amazon Keyspaces の AWS 認証情報の作成と設定](access.credentials.md)」を参照してください。
**注記**
開始にあたっては、[GitHub](https://github.com/aws-samples/amazon-keyspaces-examples) で Amazon Keyspaces コードサンプルリポジトリにあるさまざまな Cassandra クライアントドライバーを使用して、Amazon Keyspaces への接続に関するエンドツーエンドのコードサンプルを利用することができます。
次の Python プログラムで Cassandra クラスターに接続してテーブルをクエリする場合を考えてみましょう。
```
from cassandra.cluster import Cluster
#TLS/SSL configuration goes here
ksp = 'MyKeyspace'
tbl = 'WeatherData'
cluster = Cluster(['NNN.NNN.NNN.NNN'], port=NNNN)
session = cluster.connect(ksp)
session.execute('USE ' + ksp)
rows = session.execute('SELECT * FROM ' + tbl)
for row in rows:
print(row)
```
Amazon Keyspaces に対して同じプログラムを実行するには、次の作業を行う必要があります。
+ **クラスターのエンドポイントとポートの追加**: 例えば、ホストを `cassandra.us-east-1.amazonaws.com` やポート番号 `9142` などのサービスエンドポイントに置き換えることができます。
+ **TLS/SSL 設定の追加**: Cassandra クライアントの Python ドライバーを使用して Amazon Keyspaces に接続するための TLS/SSL 設定の追加については、「[Cassandra Python クライアントドライバーを使用した Amazon Keyspaces へのプログラムアクセス](using_python_driver.md)」を参照してください。
# Amazon Keyspaces のユースケース
以下は、Amazon Keyspaces の使用方法のほんの一部です。
+ **低レイテンシーを必要とするアプリケーションを構築する** - 産業機器のメンテナンス、取引のモニタリング、フリート管理、ルートの最適化など、1 桁ミリ秒のレイテンシーを必要とするアプリケーション向けにデータを高速で処理します。
+ **オープンソーステクノロジーを使用してアプリケーションを構築する** – Java、Python、Ruby、Microsoft .NET、Node.js、PHP、C\$1\$1、Perl、Go など、幅広いプログラミング言語で使用できるオープンソースの Cassandra APIs とドライバー AWS を使用して、 でアプリケーションを構築します。コード例については、[Amazon Keyspaces (Apache Cassandra 向け) のライブラリとツール](examples-tools.md) を参照してください。
+ **Cassandra ワークロードをクラウドに移動** — Cassandra テーブルをユーザー自身が管理する場合は時間とコストがかかります。Amazon Keyspaces を使用すると、インフラストラクチャを管理する AWS クラウド ことなく、 で Cassandra テーブルをセットアップ、保護、スケーリングできます。詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) でのサーバーレスリソースの管理](serverless_resource_management.md)」を参照してください。
# Cassandra クエリ言語 (CQL) とは
*Cassandra クエリ言語* (CQL) は Apache Cassandra との通信に使用される主要言語です。Amazon Keyspaces (Apache Cassandra 向け) は、CQL 3.x API (バージョン 2.x との下位互換性あり) との互換性があります。
CQL では、データはテーブル、列、行に格納されます。この点で、CQL は構造化クエリ言語 (SQL) と似ています。以下は CQL の主要な概念です。
+ **CQL 要素** – CQL の基本要素には、識別子、定数、項、データ型があります。
+ **データ定義言語 (DDL)** – DDL ステートメントは、Amazon Keyspaces の AWS リソースであるキースペースやテーブルなどのデータ構造を管理するために使用されます。DDL ステートメントは、 のコントロールプレーンオペレーションです AWS。
+ **データ操作言語 (DML) ** – DML ステートメントは、テーブル内のデータを管理するために使用されます。DML ステートメントは、データの選択、挿入、更新、削除に使用されます。これらは、 でのデータプレーンオペレーションです AWS。
+ **組み込み関数** – Amazon Keyspaces は、さまざまな組み込みスカラー関数をサポートしています。これらの関数を CQL ステートメントで使用できます。
CQL の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) の CQL 言語リファレンス](cql.md)」を参照してください。Apache Cassandra との機能の違いについては、「[機能の違い: Amazon Keyspaces と Apache Cassandra](functional-differences.md)」を参照してください。
CQL クエリを実行するには、次の作業のいずれかを実行します。
+ AWS マネジメントコンソールで CQL エディタを使用する。
+ AWS CloudShell と [cqlsh-expansion](programmatic.cqlsh.md#using_cqlsh) を使用します。
+ `cqlsh` クライアントを使用する。
+ Apache 2.0 ライセンスの Cassandra クライアントドライバーを使用する。
CQL に加えて、 AWS SDKs と を使用して Amazon Keyspaces でデータ定義言語 (DDL) オペレーションを実行できます AWS Command Line Interface。
これらの方法を使用して Amazon Keyspaces にアクセスする方法については、「[Amazon Keyspaces (Apache Cassandra 向け) へのアクセス](accessing.md)」を参照してください。