【 DataStax 】Cassandra 4.1 へのアップグレード

2022.12.14 DataStax翻訳記事

はじめに
セキュリティと運用
Cassandra 開発者
クラウドネイティブの今後

はじめに

データベースインフラストラクチャは、実はあまりエキサイティングではありません。特にセキュリティや運用を重要視するチームメンバーにとってはそう考えられます。とりわけ10 年以上にわたって大規模インフラストラクチャを支えてきたデータベースなら、むしろできるだけ退屈であるべきなのです。煩雑な手作業の削減、事故の事前回避、監視性の向上、本番クラスターの稼働性維持に役立つ新しいツールに対して、あまりワクワク感はないでしょう。

昨年の Apache Cassandra 4.0 リリースは、おそらく歴史上最も安定したデータベースリリースでした。これがイノベーションの新サイクルの皮切りとなり、Cassandra の安定性が重要な基盤になっています。そして、Cassandra 4.1 は今日そのイノベーションを実現していますが、5.0 の検討も順調に進んでいます。完全な ACID トランザクション、リレーショナルスタイルのセカンダリインデックス、その他の画期的な機能が開発中です。そのことから、苦労して手に入れた安定性を維持するための Cassandra コミュニティの力強いコミットメントを感じ取れます。

Cassandra 4.1が出荷されたので、すぐに本番環境のクラスターに合わせてアップグレードできます。みなさんのクラスターやプロジェクトにとって、アップグレードが魅力的である理由を簡単に見てみましょう。詳細については、「Cassandra: The Definitive Guide – 3rd Edition」の共同編集者である Jeff Carpenter 氏による、オンデマンドウェビナーをご覧ください。

セキュリティと運用

オープンソースの Cassandra では、そのセキュリティ確保と同様、運用も困難な場合があります。4.1 リリースでは、クラスターの稼働性や性能を維持するための、新ツールと機能が提供されています。その 1 つが、CEP-10: Cluster and Code Simulations で、クラスター上でのシミュレート操作を実現しています。操作は繰り返し可能ながら擬似的にランダムであるため、状態空間の検証と正確性テストが可能です。この新しいインフラストラクチャが Cassandra の最先端の分散システムテストを進化させ、不具合の少ない高品質のオープンソースソフトウェアを提供します。

CEP-3: Guardrails は、オペレーターには有益な機能となるでしょう。これは、一般的なアンチパターンの防止用で、デフォルトでは無効になっています。 cassandra.yaml 内で設定するか、ランタイムに JMX を介して設定します。Warnings/Failures (警告/障害) はログに記録され、必要に応じてクライアントドライバーに送信されます。詳細については、ASF Cassandra ブログをご覧ください。ブログではさらに詳細な情報を紹介しています。
CEP-13: Denylisting は、Cassandra オペレーター向けの新しいツールで、ノード (とクラスター) 上のパーティションキーの過負荷の影響を軽減します。読み取り / 書き込みの過負荷、ライブセル / トゥームストーンによる飽和状態、または本番クラスターで DDOS 攻撃を受けている場合など、特定のパーティションキーをオペレーターが分離できます。
軽量トランザクション (LWT) を使用していますか ? CEP-14 では、Paxos 実装が v2 にアップグレードされ、それに伴い LWT のトランザクション性能も 50% 向上しました。また、可動範囲などのシナリオにおいて、データ整合性と一貫性が改善されています。
CEP-16: Auth Plugin Support for CQLSH では、Cassandra コマンドラインツールであるCQLSH の変更により、 LDAP、Kerberos などのストアに保存されている認証情報を取得して認証ができるようになりました。
CEP-9: SSLContext 作成プラグインでは、サードパーティの SSL/TLS プロバイダのための拡張ポイントを作成することで、エコシステムやカスタムビルドの統合をサポートします。
CQL でハッシュ化されたパスワードをサポートし、プレーンテキストの認証情報を廃止します。詳細については、ASF Cassandra ブログをご覧ください。
nodetool、バックアップとリストア、GRANT/REVOKE/LIST ステートメントが改良されました。

Cassandra 4.1 では、セキュリティと監視に役立つ新しいシステムテーブルも導入されています。ALL TABLES IN KEYSPACE では、キースペース自体へのアクセスは禁止しながら、キースペース内のすべての種類のテーブルとユーザーに対してアクセス許可できます。また、system.top_partitions では、パーティションサイズやテーブルごとのトゥームストーン数に基づいて、トップ (Linux スタイル !) パーティションを追跡します。このデータは、JMX と nodetool tablestats を介して公開されます。

Cassandra 開発者

確かに、Cassandra 4.1 リリースは主にセキュリティと運用を重視したものですが、だからといって Cassandra 開発者や CQL 開発者向けのメリットがないわけではありません。

CQL クエリ用の GROUP BY 句が改良され、時間の範囲によるグループ化ができるようになりました。
LWT の条件付きの更新に対して CONTAINS や CONTAINS KEY 条件をクエリに使用できるようになり、次のようなクエリが可能になりました。

UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS 5

素晴らしい ! ここまで読み進んでいるということは、何か役立ちそうなものを見つけたのでしょう。

では、アップグレードについてご説明します。4.0 から 4.1 への大きな変更点は 2 つあります。

cassandra.yaml での設定
Paxos v2 へのアップグレード

CASSANDRA-15234 において、以前のパラメータ名との下位互換性を維持しつつ、cassandra.yaml のパラメータ名を標準化しました。タイプデータレート、データストレージ、期間用のパラメータの単位についても、下位互換性を維持したまま、制約をなくしました。パラメータのオーバーロードに関する新しいフラグを設け、Cassandra 構成の強化と文書化に関する改善とバグ修正を行いました。こちらで詳細を精査していただき、起動時に構成を再確認して、コーナーケースすら見逃していないことを確かめてください。そのためには、Settings Virtual Table だけでなく、cassandra.yaml から読み込まれた値のログの確認もお勧めします。というのも、一部のプロパティは後にプログラム的に変更されるデフォルトで null 値になっていて、変更されるとSettings Virtual Table のクエリの際、その値が見えるようになるためです。新しい 4.1 構成でのタイプデータレート、データストレージ、期間のパラメータは、新しいフォーマット (数値 + 単位) で追加されています。

GitHub 上の Cassandra リリースノートには、4.0 から 4.1へのアップグレードに関する注意事項 (および LWT ユーザー向けの Paxos v2 アップグレード情報) が詳しく記載されています。何か疑問があれば、コミュニティフォーラムにアクセスしてください !

クラウドネイティブの今後

Cassandra のコアプロジェクトとエコシステムの両方が動き出しています。4.1 の新しいプラグインで作成された拡張ポイントは次のとおりです。

Memtable (永続メモリ、trie memtables)
ネットワーク暗号化
認証
スキーマストレージサービス (etcd など)
システム全体のガードレール

新しいエコシステムへの扉が開かれました ! database-as-APIs を提供する Stargate、Cassandra と Kubernetes を調和させる K8ssandra 、etcd といったプロジェクトや、DynamoDB API for Stargate に関する調査研究など、Cassandra エコシステムはますます成長しています。

既に Apache Cassandra 5.0 の構築にも取り組んでいます。その取り組みの筆頭として、画期的な変更点 2 つが挙げられます。それは、完全な ACID トランザクション と SAI / Storage Attached Indexes (リレーショナルスタイルのセカンダリインデックス) です。

CEP-15 General Purpose Transactions は、Apple 社とミシガン大学による長年の研究に根ざした画期的な技術です。これは、次世代の分散型コンセンサスプロトコルをベースに構築されています。このプロトコル Accord（※PDFファイル）は、Cassandra のようなリーダーレスアーキテクチャに準じたもので、Spanner や Raft などのオプションとは異なります。これらのオプションに限定すると、Cassandraユーザーの期待であったリニアなスケールとアップタイムを保証するトランザクションの提供方法が Cassandra にはありませんでした。Accord は 1 回のラウンドトリップでコンセンサスを達成し、複雑なリーダーフェイルオーバーメカニズムは不要です。つまり、それによって Cassandra は、完全な ACID トランザクションを提供しながら、ユーザーの期待に沿うことができるのです。

CEP-7: Storage Attached Indexes (リレーショナルスタイルのセカンダリインデックス) は、DataStax Astra DB や DataStax Enterprise 上でのみ利用可能だった商用版の機能です。今回 DataStax から OSS コミュニティにコントリビュートしなおしました。リレーショナルスタイルのセカンダリインデックスは、OLTP アプリケーションの強力な武器になります。Cassandra で初めて使う場合は、こちらの Jeff Carpenter 氏による入門書をご覧ください。

以上のことから、Cassandra とその周辺のイノベーションのスピードが加速し、クラウド上で生まれ変わったことは間違いありません。Apache オープンソースの詳細については、Web ページまたはコミュニティのディスカッションをご覧ください !

Cassandra をご検討ですか ? ぜひ Apache Cassandra ページをご覧ください。

原文：It’s time to upgrade to Cassandra 4.1
著者：Pieter Humphrey