クイックスタート: Azure portal から Azure Managed Instance for Apache Cassandra クラスターを作成する

[アーティクル]
08/15/2024

Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフルマネージドサービスです。このサービスでは、各ワークロードの特定のニーズに応じて構成をオーバーライドすることもできます。これにより、必要に応じて最大限の柔軟性と制御が可能になります

このクイックスタートでは、Azure portal を使用して、Azure Managed Instance for Apache Cassandra クラスターを作成する方法について説明します。

前提条件

Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。

マネージドインスタンスクラスターを作成する

Azure portal にサインインします。
検索バーで、Managed Instance for Apache Cassandra を検索し、結果を選択します。
[Create Managed Instance for Apache Cassandra cluster](Managed Instance for Apache Cassandra クラスターの作成) ボタンを選択します。
[Create Managed Instance for Apache Cassandra](Managed Instance for Apache Cassandra の作成) ウィンドウで、次の詳細を入力します。
- [サブスクリプション] - ドロップダウンリストから Azure サブスクリプションを選びます。
- [リソースグループ] - 新しいリソースグループを作成するか、既存のものを使用するかを指定します。リソースグループは、Azure ソリューションの関連するリソースを保持するコンテナーです。詳細については、Azure リソースグループの概要に関する記事を参照してください。
- [クラスター名] - ご自分のクラスターの名前を入力します。
- [場所] - ご自分のクラスターがデプロイされる場所。
- Cassandra バージョン - デプロイされる Apache Cassandra のバージョン。
- 拡張機能 - Cassandra Lucene Index を含む、追加される拡張機能。
- [Initial Cassandra admin password](最初の Cassandra 管理者パスワード) - クラスターの作成に使用されるパスワード。
- [Confirm Cassandra admin password](Cassandra 管理者パスワードの確認) - パスワードを再入力します。
- 仮想ネットワーク - 既存の仮想ネットワークとサブネットを選択するか、新しく新規作成します。
- ロールの割り当て - 仮想ネットワークでは、管理対象の Cassandra クラスターをデプロイできるようにするために特別なアクセス許可が必要です。新しい仮想ネットワークを作成する場合、またはアクセス許可を適用せずに既存の仮想ネットワークを使用する場合は、このチェックボックスをオンのままにします。 Azure SQL Managed Instance Cassandra クラスターが既にデプロイされている仮想ネットワークを使用する場合、このオプションをオフにします。
ヒント

VPN を使用する場合は、他の接続を開く必要はありません。
Note

Azure Managed Instance for Apache Cassandra をデプロイするには、インターネットへのアクセスが必要です。インターネットへのアクセスが制限されている環境では、デプロイは失敗します。 Managed Cassandra が適切に機能するために必要な、次の重要な Azure サービスへのアクセスが VNet 内でブロックされていないことを確認します。詳細については、「必要なアウトバウンドネットワーク規則」を参照してください。
- Azure Storage
- Azure KeyVault
- Azure 仮想マシンスケールセット
- Azure 監視
- Microsoft Entra ID
- Azure Security
- 自動レプリケート - 使用する自動レプリケーションの形式を選択します。詳細情報
- スケジュールイベント戦略 - スケジュールされたイベントについてクラスターで使用される戦略。
ヒント
- StopANY は、ノードに対してスケジュールされているイベントがあるときに、任意のノードを停止することを意味します。
- StopByRack は、特定のスケジュール化されたイベントに対して特定のラック内のノードの停止のみを意味します。たとえば、異なるラック内のノードに対して同時に 2 つ以上のイベントがスケジュールされている場合、1 つのラック内のノードのみが停止され、他のラック内の他のノードは遅延されます。
次に、 [データセンター] タブを選択します。
次の詳細を入力します。
- [データセンター名] - テキストフィールドにデータセンター名を入力します。
- [可用性ゾーン] - 可用性ゾーンを有効にする場合、このチェックボックスをオンにします。
- [SKU サイズ] - 使用可能な仮想マシン SKU サイズから選択します。
Note

L シリーズ VM SKU を使用して、ライトスルーキャッシュ (パブリックプレビュー) が導入されました。この実装は、末尾の待機時間を最小限に抑え、特に読み取り集中型ワークロードの読み取りパフォーマンスを向上することを目的としています。これらの特定の SKU にはローカルに接続されたディスクが装備されており、読み取り操作の IOPS が大幅に向上し、最終的な待機時間が短縮されます。

重要

ライトスルーキャッシュはパブリックプレビュー段階です。この機能はサービスレベルアグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。
- 不正解です。数 - 各 Cassandra ノードに接続する p30 ディスクの数を選びます。
- いいえ。数 - このデータセンターにデプロイされる Cassandra ノードの数を選びます。
警告

可用性ゾーンは一部のリージョンでサポートされていません。可用性ゾーンがサポートされていないリージョンを選択すると、デプロイは失敗します。サポートされているリージョンについては、こちらを参照してください。可用性ゾーンの正常なデプロイは、特定のリージョン内のすべてのゾーンでコンピューティングリソースが使用可能であることにも左右されます。選択した SKU、または容量が一部のゾーンで使用できない場合、デプロイは失敗する可能性があります。
次に、[確認と作成]>[作成] の順に選択します

Note

クラスターの作成には、最大 15 分かかることがあります。
デプロイが完了したら、リソースグループを調べて、新しく作成されたマネージドインスタンスクラスターを確認します。
クラスターノードを閲覧するには、クラスターリソースに移動し、 [データセンター] ウィンドウを開いて確認します。

データセンターのスケーリング

1 つのデータセンターを使用してクラスターをデプロイしたので、データセンターを強調表示し、Scale ボタンを選択して、水平方向または垂直方向にスケーリングできます。

水平スケール

ノードをスケールアウトまたはスケールインするには、スライダーを目的の数値に移動するか、単に値を編集します。終わったら、Scale を押します。

垂直スケール

ノード用の SKU サイズをスケールアップまたはスケールダウンするには、Sku Size ドロップダウンから選びます。終わったら、Scale を押します。

注意

スケーリング操作にかかる時間はさまざまな要因によって異なり、数分かかる場合もあります。スケール操作が完了したことを Azure から通知された場合、これは、すべてのノードが Cassandra リングに参加したことを意味するわけではありません。ノードは、すべてが "正常" の状態を示し、データセンターの状態が "成功" と表示されているときに完全にコミッションされます。スケーリングはオンライン操作であり、管理操作に関する記事でパッチの適用について説明されているのと同じ方法で動作します。

データセンターの追加

別のデータセンターを追加するには、[データセンター] ウィンドウで [追加] ボタンをクリックします。
警告

別のリージョンにデータセンターを追加する場合は、別の仮想ネットワークを選択する必要があります。また、この仮想ネットワークが、上記で作成したプライマリリージョンの仮想ネットワーク (およびマネージドインスタンスクラスター内のデータセンターをホストしているその他の仮想ネットワーク) に接続されていることを確認する必要があります。この記事では、Azure portal を使用して仮想ネットワークをピアリングする方法について説明します。また、以下の CLI コマンドを使用して、管理対象インスタンス・クラスターのデプロイを試みる前に、仮想ネットワークに適切な役割が適用されていることを確認する必要があります。
```
    az role assignment create \
    --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
    --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
    --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>
```
適切なフィールドに入力します。
- [データセンター名] - ドロップダウンリストから Azure サブスクリプションを選択します。
- 可用性ゾーンン - このデータセンターで可用性ゾーンを有効にする場合は、このチェックボックスをオンにします。
- 場所 - ご自分のクラスターがデプロイされる場所。
- [SKU サイズ] - 使用可能な仮想マシン SKU サイズから選択します。
- いいえ。数 - 各 Cassandra ノードに接続する p30 ディスクの数を選びます。
- いいえ。数 - このデータセンターにデプロイされる Cassandra ノードの数を選びます。
- 仮想ネットワーク - 既存の仮想ネットワークとサブネットを選択します。
警告

データセンターを追加するときに新しい仮想ネットワークの作成を許可していないことに注意してください。既存の仮想ネットワークを選択し、前述のように、データセンターがデプロイされるターゲット　サブネット間に接続があることを確認する必要があります。また、デプロイを許可するには、適切なロールを VNet に適用する必要もあります (上記を参照)。
データセンターがデプロイされると、すべてのデータセンター情報を [データセンター] ウィンドウに表示できるようになります。
データセンター間のレプリケーションを確保するには、cqlsh に接続し、次の CQL クエリを使用して、各キースペースのレプリケーション戦略を更新し、クラスター全体のすべてのデータセンターを含めます (システムテーブルは自動的に更新されます)。
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
データが既に存在するクラスターにデータセンターを追加する場合は、履歴データをレプリケートするために rebuild を実行する必要があります。 Azure CLI で、以下のコマンドを実行して、新しいデータセンターの各ノードで nodetool rebuild を実行し、<new dc ip address> をノードの IP アドレスに置き換え、<olddc> を既存のデータセンターの名前に置き換えます。
```
 az managed-cassandra cluster invoke-command \
   --resource-group $resourceGroupName \
   --cluster-name $clusterName \
   --host <new dc ip address> \
   --command-name nodetool --arguments rebuild="" "<olddc>"=""
```
警告

キースペースレプリケーションの変更を適用するまで、アプリケーションクライアントが新しいデータセンターに書き込むのを許可しないでください。それ以外の場合、リビルドは機能しないので、サポートリクエストを作成し、チームが代理で repair を実行できるようにする必要があります。

Cassandra の構成を更新する

このサービスを使用すると、ポータルまたは CLI コマンドを使用して、データセンターの Cassandra YAML 構成を更新できます。ポータルで設定を更新するには:

[設定] で Cassandra Configuration を見つけます。構成を変更するデータセンターを強調表示し、[更新] をクリックします。
開いたウィンドウで、次に示すように YAML 形式でフィールド名を入力します。次に [更新] をクリックします。
更新が完了すると、オーバーライドされた値が Cassandra Configuration ウィンドウに表示されます。

Note

オーバーライドされた Cassandra 構成値のみがポータルに表示されます。
重要

指定した Cassandra yaml 設定が、デプロイした Cassandra のバージョンに適していることを確認します。 Cassandra v3.11 の設定については、こちらを参照してください。v4.0 については、こちらを参照してください。次の YAML 設定は更新できません。
- cluster_name
- seed_provider
- initial_token
- autobootstrap
- client_encryption_options
- server_encryption_options
- transparent_data_encryption_options
- audit_logging_options
- 認証子 (authenticator)
- authorizer
- role_manager
- storage_port
- ssl_storage_port
- native_transport_port
- native_transport_port_ssl
- listen_address
- listen_interface
- broadcast_address
- hints_directory
- data_file_directories
- commitlog_directory
- cdc_raw_directory
- saved_caches_directory
- endpoint_snitch
- パーティショナー
- rpc_address
- rpc_interface

Cassandra のバージョンを更新する

重要

Cassandra 5.0 およびターンキーバージョンの更新プログラムは、パブリックプレビュー段階です。これらの機能はサービスレベルアグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。

ポータルから直接、または Az CLI、Terraform、または ARM テンプレートを使用して、インプレースメジャーバージョンアップグレードを実行できます。

[概要] タブから Update パネルを見つける
ドロップダウンから Cassandra バージョンを選択します。

警告

バージョンをスキップしないでください。あるバージョンから別のバージョン (3.11 から 4.0、4.0 から 4.1 など) にのみ更新することをお勧めします。
[更新時] を選択して保存します。

ターンキーレプリケーション

Cassandra 5.0 では、利便性と効率が向上する、マルチリージョンクラスターをデプロイするための合理化されたアプローチが導入されています。ターンキーレプリケーション機能を使用すると、マルチリージョンクラスターの設定と管理にアクセスしやすくなり、分散環境全体にわたる統合と操作を円滑に行うことができます。この更新により、複数リージョン構成のデプロイと保守に関連する複雑さが大幅に軽減され、ユーザーは Cassandra の機能をより簡単かつ効果的に使用できます。

ヒント

None: 自動レプリケートは「なし」に設定されます。
SystemKeyspaces: すべてのシステムキースペース (system_auth、system_traces、system_auth) を自動レプリケートします
AllKeyspaces: すべてのキースペースを自動レプリケートし、新しいキースペースが作成されたかどうかを監視し、自動レプリケート設定を自動的に適用します。

自動レプリケーションのシナリオ

新しいデータセンターを追加すると、Cassandra の自動レプリケート機能では nodetool rebuild をシームレスに実行して、追加されたデータセンター全体でデータが正常にレプリケーションされるようにします。
データセンターを削除すると、キースペースから特定のデータセンターが自動的に削除されます。

オンプレミスでホストされている外部データセンターの場合、外部データセンタープロパティを使用してキースペースに含めることができます。これにより、Cassandra では、これらの外部データセンターを再構築プロセスのソースとして組み込むことができます。

警告

自動レプリケートを AllKeyspaces に設定すると、キースペースのレプリケーションが次を含むように変更されます。WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } これが目的のトポロジでない場合は、SystemKeyspaces を使用し、これらを自分で調整し、nodetool rebuild を Azure Managed Instance for Apache Cassandra クラスターで手動で実行する必要があります。

クラスターの割り当て解除

非運用環境では、クラスター内のリソースの一時停止または割り当て解除を行って、それらに対する課金を回避できます (ストレージに対して引き続き課金されます)。最初に、クラスターの種類を NonProduction に変更し、次に deallocate にします。

ヒント

クラスターの種類は、開発コストを節約するためにのみ "非運用" として使用する必要があります。これらは、より小さな SKU で提供される可能性があるため、運用環境のワークロードの実行には使用しないでください。

警告

"非運用" として定義されているクラスターの種類には、SLA の保証は適用されません。
割り当て解除中にスキーマや書き込み操作を実行しないでください。これにより、データが失われ、まれにスキーマが破損し、サポートチームによる手動の介入が必要になることがあります。

トラブルシューティング

Azure CLI を使用して Virtual Network にアクセス許可を適用するときにエラー ("Cannot find user or service principal in graph database for 'e5007d2c-4b13-4a74-9b6a-605d99f03501' ('e5007d2c-4b13-4a74-9b6a-605d99f03501' に対するユーザーまたはサービスプリンシパルがグラフデータベース内で見つかりません) " など) が発生した場合、Azure portal から同じアクセス許可を手動で適用できます。この方法についてはこちらを参照してください。

注意

Azure Cosmos DB のロールの割り当ては、デプロイの目的にのみ使用されます。 Azure Managed Instance for Apache Cassandra には、Azure Cosmos DB に対するバックエンドの依存関係はありません。

クラスターに接続する

Azure Managed Instance for Apache Cassandra では、パブリック IP アドレスを持つノードが作成されないため、新しく作成された Cassandra クラスターに接続するには、VNet 内に別のリソースを作成する必要があります。これは、アプリケーション、または Apache のオープンソースクエリツール CQLSH がインストールされている仮想マシンにすることができます。テンプレートを使用して、Ubuntu 仮想マシンをデプロイできます。

CQLSH からの接続

仮想マシンがデプロイされたら、SSH を使用してマシンに接続し、次のコマンドを使用して CQLSH をインストールします。

# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre

# Install the Cassandra libraries in order to get CQLSH:
echo "deb http://archive.apache.org/dist/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra

# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false

# Connect to CQLSH (replace <IP> with the private IP addresses of a node in your Datacenter):
host=("<IP>")
initial_admin_password="Password provided when creating the cluster"
cqlsh $host 9042 -u cassandra -p $initial_admin_password --ssl

アプリケーションからの接続

CQLSH と同様に、サポートされている Apache Cassandra クライアントドライバーのいずれかを使用してアプリケーションから接続するには、SSL を有効にし、証明書の検証を無効にする必要があります。 Java、.NET、Node.js、Python を使用した Azure Managed Instance for Apache Cassandra への接続についてはサンプルをご覧ください。

クラスターノードの IP アドレスを適切なドメインにマップしない限り、証明書の検証は機能しないため、証明書の検証を無効にすることをお勧めします。アプリケーションに対して SSL 証明書の検証を行うことを義務付ける内部ポリシーがある場合は、各ノードのホストファイルに 10.0.1.5 host1.managedcassandra.cosmos.azure.com などのエントリを追加することにより、これを容易に実施できます。この方法を採用する場合は、ノードをスケールアップするたびに新しいエントリを追加する必要もあります。

Java の場合は、アプリケーションが最終的な待機時間に敏感な投機的実行ポリシーを有効にすることも強くお勧めします。このしくみとポリシーを有効にする方法を示すデモについては、こちらを参照してください。

注意

ほとんどの場合、Azure Managed Instance for Apache Cassandra に接続するために証明書 (rootCA、ノードまたはクライアント、トラストストアなど) を構成またはインストールする必要はありません。 SSL 暗号化は、クライアントで使用されているランタイムの既定のトラストストアとパスワードを使用して有効にできます (Java、.NET、Node.js、Python のサンプルを参照)。これは、Azure Managed Instance for Apache Cassandra の証明書がその環境によって信頼されるためです。まれに、証明書が信頼されていない場合は、それをトラストストアに追加する必要があります。

クライアント証明書を構成する (省略可能)

クライアント証明書の構成は任意です。クライアントアプリケーションは、上記の手順が実行されている限り、Azure Managed Instance for Apache Cassandra に接続できます。ただし、必要に応じて、認証用のクライアント証明書を追加で作成して構成することもできます。一般に、証明書を作成するには、次の 2 つの方法があります。

自己署名証明書。これは、各ノードのプライベートおよびパブリック (CA なし) 証明書を意味します。この場合は、すべてのパブリック証明書が必要になります。
CA によって署名された証明書。これは、自己署名 CA でも、パブリック CA でもかまいません。この場合は、ルート CA 証明書 (Preparing SSL certificates for production の手順を参照) と、すべての中継局 (該当する場合) が必要になります。

クライアントからノードへの証明書認証または相互トランスポート層セキュリティ (mTLS) を実装する場合は、Azure CLI を使用して証明書を提供する必要があります。下のコマンドにより、Cassandra Managed Instance クラスターのトラストストアにクライアント証明書がアップロードされて適用されます (つまり、cassandra.yaml 設定を編集する必要はありません)。適用されると、クラスターでは、クライアントの接続時に証明書を検証するための Cassandra が必要になります (Cassandra client_encryption_options の require_client_auth: true を参照)。

resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --client-certificates /usr/csuser/clouddrive/rootCert.pem /usr/csuser/clouddrive/intermediateCert.pem

リソースをクリーンアップする

このマネージドインスタンスクラスターを引き続き使用しない場合は、次の手順でそれを削除します。

Azure portal の左側にあるメニューで、 [リソースグループ] を選択します。
一覧から、このクイックスタートで作成したリソースグループを選択します。
リソースグループの [概要] ペインで、 [リソースグループの削除] を選択します。
次のウィンドウで、削除するリソースグループの名前を入力し、[削除] を選択します。

次のステップ

このクイックスタートでは、Azure portal を使用して、Azure Managed Instance for Apache Cassandra クラスターを作成する方法について学習しました。これで、クラスターの操作を開始できます。

Azure Databricks でマネージド Apache Spark クラスターをデプロイする

次の方法で共有

クイックスタート: Azure portal から Azure Managed Instance for Apache Cassandra クラスターを作成する

前提条件

マネージドインスタンスクラスターを作成する