最初に

目次

本項では Apache Cassandra を使い始めるにあたって必要な情報がまとめられている。Cassandra を初めて使用する人はまず一読する事を強くすすめる。

Cassandra のインストール

Apache Cassandra のサポートされているリリースを Linux サーバーにデプロイするための手順。
Cassandra は、以下を含む（が以下に限定されない）幅広い　Linux ディストリビューションで実行できる。
  • Ubuntu、 特に　LTS リリース 16.04 から 18.04
  • CentOS と 6.6 から 7.7 を含む RedHat Enterprise Linux (RHEL)
  • 2016.09 から Linux 2 を含む　Amazon Linux AMI
  • Debian ver. 8 と 9
  • SUSE Enterprise Linux 12
以上は　Apache Cassandra のサポートされている OS プラットフォームの全てを含むものではなく、また規範的なものでもない。 ただし、広く使用されていない Linux ディストリビューションを使用する際は、ユーザーは独自に徹底的なテストを実施することをお勧めする。 古い OS のバージョンでのデプロイは、本番環境で以前のバージョンのディストリビューションを使用した経験がない限り、推奨されない。
必要な環境
  • Oracle Java Standard Edition 8 または OpenJDK 8 のいずれかの Java 8 の最新バージョンをインストール。正しいバージョンの Java がインストールされていることを確認するには java -version を実行。
Note
 Cassandra 4.0（CASSANDRA-9608）では Java 11 の実験的サポートが追加された。 Java 11 での Cassandra の実行は実験的なものなので自己責任で行うこと。 詳細については NEWS.txt を参照。
  • cqlsh を使用する場合、 Python 2.7 または Python 3.6 以降の最新バージョンが必要。 Python の正しいバージョンがインストールされていることを確認するには python --version を実行。
インストール方法の選択
ほとんどのユーザーにとって、バイナリ tarball のインストールが最も簡単な選択となる。 tarball はすべてのコンテンツを単一の場所へ解凍し、バイナリとコンフィグファイルを独自のサブディレクトリーに配置する。 tarball のインストールの最も大きな特徴は、 root 権限を必要とせず、どの Linux ディストリビューションにもインストールできること。
パッケージ化されたインストールには root 権限が必要となる。CentOS および RHEL ベースのディストリビューションにおいて YUM を使用して Cassandra をインストールする場合は、 RPM ビルドをインストールする。 Ubuntu およびその他の　Debian ベースのディストリビューションにおいて APT を使用して Cassandra をインストールする場合は、 Debian ビルドをインストールする。 YUM を使用する場合も APT を使用する場合も両方 root 権限が必要であり、バイナリとコンフィグファイルは cassandra OS ユーザーとしてインストールされることに注意。
バイナリ tarball のインストール
  1. インストールされている Java のバージョンを確認。例：
$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
  1. Apache Cassandra Download サイトのミラーの1つからバイナリ tarball をダウンロードする。 たとえば、4.0 をダウンロードするには：
$ curl -OL http://apache.mirror.digitalpacific.com.au/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz
Note
 ミラーサイトはサポートされている各メジャーリリースの最新バージョンのみをホストしているので Cassandra の以前のバージョンをダウンロードするには Apache Archives にアクセスする必要がある。
  1. 任意：こちらに記載されているいずれかの方法を使用し、ダウンロードした tarball の整合性を確認する。たとえば、 GPG を使用してダウンロードしたファイルのハッシュを確認するには：
$ gpg --print-md SHA256 apache-cassandra-4.0.0-bin.tar.gz
apache-cassandra-4.0.0-bin.tar.gz: 28757DDE 589F7041 0F9A6A95 C39EE7E6
                                   CDE63440 E2B06B91 AE6B2006 14FA364D
署名をダウンロードサイトのSHA256ファイルと比較する： 
$ curl -L https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.sha256
28757dde589f70410f9a6a95c39ee7e6cde63440e2b06b91ae6b200614fa364d
  1. tarball を解凍する：
$ tar xzvf apache-cassandra-4.0.0-bin.tar.gz
ファイルは apache-cassandra-4.0.0/ ディレクトリに解凍される。このディレクトリが tarball のインストール場所となる。
  1. tarball のインストール場所には、スクリプト、バイナリ、ユーティリティ、コンフィグ、データ、ログファイルのディレクトリが含まれる：
/
    bin/
    conf/
    data/
    doc/
    interface/
    javadoc/
    lib/
    logs/
    pylib/
    tools/
インストールのコンフィグについては、Cassandra のコンフィグを参照。
  1. Cassandra の実行：
$ cd apache-cassandra-4.0.0/
$ bin/cassandra
Note
 上記は Cassandra を認証された Linux ユーザーとして実行する。
スタートアップの工程を監視するには： 
$ tail -f logs/system.log
Cassandra が立ち上がると system.log に下記の様なメッセージが出力される： 
INFO  [main] 2019-12-17 03:03:37,526 Server.java:156 - Starting listening for CQL clients on localhost/127.0.0.1:9042 (unencrypted)...
  1. Cassandra のステータスを確認：
$ bin/nodetool status
正常に動作している場合、出力のステータスカラムに UN が表示される（”Up/Normal”の略）。
また、データベースに以下で接続する事も可能： 
$ bin/cqlsh
Debian パッケージのインストール
  1. インストールされている Java のバージョンを確認。例：
$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
  1. Cassandra の Apache リポジトリを cassandra.sources.list に追加する。 最新のメジャーリリースは 4.0 で、対応するディストリビューション名は 40x （接尾辞の”x”が付いている）。 古いリリースは、 C* 3.11 シリーズは 311x 、 3.0 は 30x 、 2.2 は 22x 、 2.1 は 21x を使用する。 たとえば、バージョン 4.0（ 40x ）のリポジトリを追加するには：
$ echo "deb http://www.apache.org/dist/cassandra/debian 40x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
deb http://www.apache.org/dist/cassandra/debian 40x main
  1. Apache Cassandra リポジトリキーをサーバー上に信頼できる鍵として追加する：
$ curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  266k  100  266k    0     0   320k      0 --:--:-- --:--:-- --:--:--  320k
OK
  1. ソースからパッケージインデックスを更新する：
$ sudo apt-get update
  1. APT で Cassandra をインストールする：
$ sudo apt-get install cassandra
Note
 インストールの一部として Cassandra という新しい Linux ユーザーが作成される。Cassandra サービスもこのユーザーとして実行される。
  1. インストール完了後、自動的に Cassandra サービスが立ち上がる。スタートアップの工程を監視するには：
$ tail -f /var/log/cassandra/system.log
Cassandra が立ち上がると system.log に下記の様なメッセージが出力される： 
INFO  [main] 2019-12-17 03:03:37,526 Server.java:156 - Starting listening for CQL clients on localhost/127.0.0.1:9042 (unencrypted)...
インストールのコンフィグについては、Cassandra のコンフィグを参照。
  1. Cassandra のステータスを確認：
$ nodetool status
正常に動作している場合、出力のステータスカラムに UN が表示される（”Up/Normal”の略）。
また、データベースに以下で接続する事も可能： 
$ cqlsh
RPM パッケージのインストール
  1. インストールされている Java のバージョンを確認。例：
$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
  1. Cassandra の Apache リポジトリを /etc/yum.repos.d/cassandra.repo に（ root ユーザーとして）追加する。 最新のメジャーリリースは 4.0 で、対応するディストリビューション名は 40x （接尾辞の”x”が付いている）。 古いリリースは、 C* 3.11 シリーズは 311x 、 3.0 は 30x 、 2.2 は 22x 、 2.1 は 21x を使用する。 たとえば、バージョン 4.0（ 40x ）のリポジトリを追加するには：
[cassandra]
name=Apache Cassandra
baseurl=https://downloads.apache.org/cassandra/redhat/40x/
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://downloads.apache.org/cassandra/KEYS
  1. ソースからパッケージインデックスを更新する：
$ sudo yum update
  1. YUM で Cassandra をインストールする：
$ sudo yum install cassandra
Note
 インストールの一部として Cassandra という新しい Linux ユーザーが作成される。Cassandra サービスもこのユーザーとして実行される。
  1. Cassandra サービスを立ち上げる：
$ sudo service cassandra start
  1. スタートアップの工程を監視するには：
$ tail -f /var/log/cassandra/system.log
Cassandra が立ち上がると system.log に下記の様なメッセージが出力される： 
INFO  [main] 2019-12-17 03:03:37,526 Server.java:156 - Starting listening for CQL clients on localhost/127.0.0.1:9042 (unencrypted)...
インストールのコンフィグについては、Cassandra のコンフィグを参照。
  1. Cassandra のステータスを確認：
$ nodetool status
正常に動作している場合、出力のステータスカラムに UN が表示される（”Up/Normal”の略）。
また、データベースに以下で接続する事も可能： 
$ cqlsh
インストールについての詳細
インストールに関する更なる詳細またはトラブルの解決については、トラブルシューティングを参照。

Cassandra のコンフィグ

単一ノードで　Cassandra を実行するには、 ./conf/cassandra.yaml にあるデフォルトのコンフィグファイルで十分でコンフィグを変更する必要はない。 ただし、ノードのクラスターをデプロイするとき、または同一ホスト上にないクライアントを使用するときはいくつかのパラメーターを変更する必要がある。
Cassandra コンフィグファイルは、 tarball の conf ディレクトリーにある。 パッケージの場合、コンフィグファイルは /etc/cassandra にある。
実行時（ランタイム）の主なプロパティー
Cassandra の設定のほとんどは、 cassandra.yaml で設定できる yaml プロパティを介して行われる。 少なくとも、次のプロパティの設定を検討する事を強くすすめる。
  • cluster_name: クラスターの名前。
  • seeds: クラスターシードの IP アドレスのリスト（コンマで分かち書き）。
  • storage_port: 必ずしも変更する必要はないが、このポートを塞いでいるファイアウォールが無い事を確認する。
  • listen_address: ノードの IP アドレス。他ノードはこの IP アドレスを使い本ノードと通信するので、変更する事が重要。または、 listen_interface を設定する事で Cassandra がどのインターフェースを使用するか指定し、次に使用するアドレスを設定する。必ず上記の両方ではなく片方のみを設定する事。
  • native_transport_port: クライアントが Cassandra と通信する時に使用するポート。storage_port 同様、このポートを塞いでいるファイアウォールが無い事を確認する。
ディレクトリの位置を変更
次の yaml プロパティーは各ディレクトリーの位置を制御する。
  • data_file_directories: データファイルが置かれているディレクトリー。
  • commitlog_directory: コミットログファイルが置かれているディレクトリー。
  • saved_caches_directory: 保存されたキャッシュが置かれたディレクトリー。
  • hints_directory: ヒントが置かれているディレクトリー。
パフォーマンス上の理由から、複数のディスクがある場合はコミットログとデータファイルを別々のディスクに配置することを検討すると良い。
環境変数
ヒープサイズなどの JVM レベルの設定は、 cassandra-env.sh で設定できる。 追加の JVM コマンドライン引数を JVM_OPTS 環境変数に追加すると、 Cassandra 起動時にこれらの引数が JVM に渡される。
ログ
使用中のロガーは Logback 。Logback のプロパティを変更するには、 logback.xml を編集する。デフォルトの設定では、INFO レベルのログは system.log に、DEBUG レベルのログは debug.log というログファイルにそれぞれ記録される。フォアグラウンドで実行すると、INFO レベルのログはコンソールに出力される。

インサートとクエリ

Cassandra の API は CQL (Cassandra Query Language) であり、 CQL を使用するにはクラスターに接続する必要がある。以下のどちらかの方法でクラスターへの接続が可能：
  • cqlshを使用
  • Cassandra のクライアントドライバーを使用
CQLSH
cqlsh は、CQL を介して Cassandra を扱うためのコマンドラインシェル。すべての Cassandra パッケージに同梱されており、Cassandra 実行ファイルと一緒に bin/ ディレクトリーに置かれる。コマンドラインで指定された単一のノードに接続する。例えば： 
$ bin/cqlsh localhost
Connected to Test Cluster at localhost:9042.
[cqlsh 5.0.1 | Cassandra 3.8 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
cqlsh> SELECT cluster_name, listen_address FROM system.local;

 cluster_name | listen_address
--------------+----------------
 Test Cluster |      127.0.0.1

(1 rows)
cqlsh>
より詳細なドキュメントについては、cqlsh：CQL シェルを参照。
クライアントドライバー
多くのクライアントドライバーがコミュニティーから提供されて、既知のドライバーの一覧は次の項に記載している。 各ドライバーの使用方法の詳細については各ドライバーのドキュメントを参照すると良い。

クライアントドライバー

以下は、言語ごとに整理された既知の Cassandra クライアントドライバーの一覧。ドライバーを選択する前に、そのドライバーがサポートする Cassandra のバージョンと機能を確認する事を強くすすめる。
Java
Python
Ruby
C# / .NET
Nodejs
PHP
C++
Scala
Clojure
Erlang
Go
Haskell
Rust
Perl
Elixir
Dart

プロダクション環境に関する推奨点

cassandra.yaml ファイルと jvm.options ファイルには、本番環境での使用に関するいくつかの注意事項・推奨する点が記載されている。本項では、これらのファイル内のメモ書きについてさらに詳しい説明を提供する。
Tokens（トークン）
複数のトークン（vnodeと呼ばれる）を使用すると、新しいノードをクラスターにブートストラップするときに、より柔軟な拡張とより多くのストリーミングピアの使用が可能になる。これにより、ストリーミングの悪影響（I/O および CPU オーバーヘッド）を制限し、クラスター拡張のインクリメントが可能になる。
しかしトークンが増えると、引き換えにより多くのピアとデータを共有することになり、可用性が低下する可能性がある。詳細については、こちらの論文（PDF ダウンロード）を読むことをすすめる。
使用するトークン数は次の設定で変更可能： 
num_tokens: 16
以下は、最も一般的なトークン数とそれぞれを使用するタイミングと理由を簡単に記述したもの：
トークン数 説明

1

可用性の最大化、クラスターサイズの最大化、ピア数の最小化、しかし柔軟性の無い拡張。拡張の際にバランスを保つには常にクラスターサイズを２倍する必要がある。

4

柔軟性と可用性の程よい組み合わせ。最終的に３０ノードを超えるクラスターに推奨される。バランスを保つには、ノードを約２０％追加する必要がある。クラスターを縮小するとクラスターのバランスが崩れる可能性がある。

16

定期的に拡張および縮小するクラスターに最適だが、大きなクラスターでは可用性に問題が生じる可能性がある。50ノードを超えるクラスターには推奨されない。
トークン数を設定するだけでなく、トークンの割り当てを均等にするために、allocate_tokens_for_local_replication_factor も設定することが非常に重要。
Read Ahead（先読み）
Read Ahead はページキャッシュに読み込まれたデータをできるだけ多く保持しようとするオペレーティングシステムの機能。この機能の目的は、ディスクでのシークタイムが理由で待ち時間のペナルティが高い読み取りで追加のスループットを使用して待ち時間を減らすこと。Read Ahead を活用することにより OS は追加のシークのコストをかけずに追加のデータをメモリに取り込むことができる。これは、使用可能な RAM がホットデータセットの大きさよりも大きい場合にうまく機能するが、ホットデータセットが使用可能な RAM よりもはるかに大きい場合には問題になる可能性がある。使用可能なメモリに対してホットデータセットのサイズが大きくなると、Read Ahead の利点は減少する。
小さなパーテーション（通常はパーテーションキーが無いテーブル、がこれに限定されない）とソリッドステートドライブ（SSD）では、Read Ahead がレイテンシーの利点なしにディスクの使用量を増加させてしまう事がある。場合によっては、最大で５倍のレイテンシーとスループットへのペナルティの増加が見られる事もある。読み取り重視の小さいキー・バリューテーブル（１KB未満の行）は特に上記の問題が起こりやすい。
以下のRead Ahead 設定を推奨する：
ハードウェア 初期設定

回転ディスク

64KB

SSD

4KB
Linux システムでは、blockdev ツールを使用して先読みを調整できる。
たとえば、次のようにして /dev/sda1 のRead Ahead を4KBに設定できる： 
blockdev --setra 8 /dev/sda1
Note
 blockdev は、Read Ahead する512バイトセクターの数を受け取る。上記の例の引数の 8 は 4KB と同等。
システムはそれぞれ異なるため、上記の推奨は初期設定として使用し、SLA およびスループット要件に基づいてチューニングすることをすすめる。 Read Ahead がディスクリソースの使用に与える影響を理解するには、トラブルシューティングの項を注意深く読むことをすすめる。
Compression（圧縮）
圧縮データは、固定サイズのバイトバッファを圧縮してデータをディスクに書き込むことによって格納される。バッファサイズは、スキーマ設定の compression map の chunk_length_in_kb 要素によって決定される。
Cassandra 4.0 以降、デフォルト設定は 16KB となった。
圧縮バッファ全体をディスクから読み取る必要があるため、圧縮チャンクの長さを大きく設定しすぎると、小さなレコードを読み取るときにかなりのオーバーヘッドが発生する可能性がある。デフォルトの Read Ahead 設定と組み合わさると、特定のワークロードで大量に読み取りが増幅される可能性がある。
LZ4Compressor はデフォルトの推奨圧縮アルゴリズムとなる。
Compression に関する追加情報は、The Last Pickle Blog（外部ブログ：英語）にて確認できる。
Compaction（コンパクション）
さまざまなワークロードに対して使用できるさまざまなコンパクションストラテジーがある。これらのさまざまなコンパクションストラテジーについて該当するドキュメントを熟読し、どのコンパクションストラテジーが使用している環境に最適かを判断することをすすめる。異なるテーブルが、同一クラスター内でも異なるコンパクションストラテジーを使用する事は多々ある。
Encryption（暗号化）
クラスターが既に本番環境のトラフィックを処理している時ではなく、始めに本番環境のクラスターを設定するときにピアツーピア暗号化とクライアントサーバー暗号化を設定する方が格段に容易に設定できる。最終的に（任意の形式での）ネットワーク暗号化を使用する予定がある場合は、なるべく本番環境前の初期段階に設定することをすすめる。暗号化に関するコンフィグを将来的に変更することは不可能ではないが、ミスをするとダウンタイムやデータ損失が発生する可能性がある。
キースペースは NetworkTopologyStrategy を使用
本番クラスター・プロダクションキースペースでは SimpleStrategy は使用せず、NetworkTopologyStrategy（NTS）を使用する必要がある。 例えば： 
create KEYSPACE mykeyspace WITH replication =
{'class': 'NetworkTopologyStrategy', 'datacenter1': 3};
Cassandra は NetworkTopologyStrategy を使用すると複数のラックとデータセンターを活用できる。
ラックと Snitch（スニッチ）のコンフィグ
クラスターが立ち上がりデータを持った後にラックの構成または変更することはサポートされていない操作である。 単一のラックから複数のラックへの移行もサポートされていなく、データが失われる可能性がある。
GossipingPropertyFileSnitch の使用はオンプレミスまたは混合クラウド環境向けの最も柔軟なソリューションとなる。Ec2Snitch は AWS EC2 のみの環境で信頼できる。

本ドキュメントに関するお問い合わせ

株式会社INTHEFOREST
©2020 株式会社INTHEFOREST
ホーム
ドキュメント