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

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

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

前提条件

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

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

1. Azure portal にサインインします。

2. 検索バーで、Managed Instance for Apache Cassandra を検索し、結果を選択します。

   

3. [Create Managed Instance for Apache Cassandra cluster]\(Apache Cassandra クラスターのマネージド インスタンスの作成\) を選択します。

   

4. [Create Managed Instance for Apache Cassandra](Managed Instance for Apache Cassandra の作成) ウィンドウで、次の詳細を入力します。

   • サブスクリプション - ドロップダウンから Azure サブスクリプションを選択します。
   • [リソース グループ] - 新しいリソース グループを作成するか、既存のものを使用するかを指定します。 リソース グループは、Azure ソリューションの関連するリソースを保持するコンテナーです。
   • [クラスター名] - ご自分のクラスターの名前を入力します。
   • 場所 - クラスターをデプロイする場所。
   • Cassandra バージョン - デプロイする Apache Cassandra のバージョン。
   • Extention - 追加する拡張機能 ( Cassandra Lucene Index を含む)。
   • [Initial Cassandra admin password](最初の Cassandra 管理者パスワード) - クラスターの作成に使用されるパスワード。
   • [Confirm Cassandra admin password](Cassandra 管理者パスワードの確認) - パスワードを再入力します。
   • 仮想ネットワーク - 既存の仮想ネットワークとサブネットを選択するか、新しく作成します。
   • ロールの割り当て - 仮想ネットワークには、マネージド Cassandra クラスターのデプロイを許可するための特別なアクセス許可が必要です。 新しい仮想ネットワークを作成する場合、またはアクセス許可が適用されていない既存の仮想ネットワークを使用している場合は、このチェック ボックスをオンのままにします。 以前に Azure SQL Managed Instance Cassandra クラスターをデプロイした仮想ネットワークを使用する場合は、このオプションの選択を解除します。

   

   ヒント

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

   注釈

   Azure Managed Instance for Apache Cassandra のデプロイには、インターネット アクセスが必要です。 インターネットへのアクセスが制限されている環境では、デプロイは失敗します。 マネージド Cassandra が正常に動作するために必要な次の重要な Azure サービスへの仮想ネットワーク内のアクセスをブロックしていないことを確認します。 詳細については、「 必要な送信ネットワーク規則」を参照してください。

   • Azure Storage
   • Azure KeyVault
   • Azure 仮想マシンのスケールセット
   • Azure 監視
   • マイクロソフト エントラ ID
   • Azure セキュリティ
   • 自動複製。 使用する自動複製の形式を選択します。 詳細については、「 ターンキー レプリケーション」を参照してください。
   • イベント戦略をスケジュールします。 スケジュールされたイベントにクラスターによって使用される戦略。

   ヒント

   • StopANY は、ノードのスケジュールされたイベントがある場合にノードを停止します。
   • StopByRack は、特定のスケジュールされたイベントの特定のラック内の停止ノードのみを意味します。 たとえば、複数のイベントが異なるラック内のノードに対して同時にスケジュールされている場合、1 つのラック内のノードのみが停止します。 他のラック内の他のノードは遅延します。

5. 次に、 [データ センター] タブを選択します。

6. 次の詳細を入力します。

   • データ センター名。 テキスト フィールドにデータ センター名を入力します。
   • 可用性ゾーン。 可用性ゾーンを有効にする場合は、このチェック ボックスをオンにします。
   • SKU サイズ。 使用可能な仮想マシン SKU のサイズから選択します。

   

   注釈

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

   重要

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

   • いいえ 数. 各 Cassandra ノードに接続する p30 ディスクの数を選択します。
   • いいえ 数. このデータセンターにデプロイする Cassandra ノードの数を選択します。

   

   警告

   可用性ゾーンは、すべてのリージョンでサポートされているわけではありません。 可用性ゾーンがサポートされていないリージョンを選択すると、デプロイは失敗します。 詳細については、 Azure リージョンの一覧を参照してください。

   可用性ゾーンの正常なデプロイは、特定のリージョン内のすべてのゾーンでコンピューティング リソースが使用可能であることにも左右されます。 選択した SKU または容量がすべてのゾーンで使用できない場合、デプロイが失敗する可能性があります。

7. 次に、 確認と作成>作成を選択します。

   注釈

   クラスターの作成には最大 15 分かかる場合があります。

   

8. デプロイが完了したら、リソース グループを確認して、新しく作成されたマネージド インスタンス クラスターを確認します。

   

9. クラスター ノードを参照するには、クラスター リソースに移動し、[ データ センター ] ウィンドウを開きます。

   

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

単一のデータ センターを使用してクラスターをデプロイしたら、データ センターを強調表示し、[スケール] ボタンを選択することで、水平方向または垂直方向に スケーリング できます。

水平スケール

ノードをスケールアウトまたはスケールインするには、スライダーを目的の数値に移動するか、単に値を編集します。 完了したら、[スケール] を選択 します。

垂直スケール

ノードの SKU サイズをスケールアップまたはスケールダウンするには、[ SKU サイズ] から選択します。 完了したら、[スケール] を選択 します。

データセンターの追加

1. 別のデータセンターを追加するには、[ データ センター ] ウィンドウで [追加] ボタンを選択します。

   

   警告

   別のリージョンにデータセンターを追加する場合は、別の仮想ネットワークを選択する必要があります。 また、この仮想ネットワークが、以前に作成したプライマリ リージョンの仮想ネットワークに接続されていることを確認する必要があります。 また、マネージド インスタンス クラスター内のデータセンターをホストしている他の仮想ネットワークも必ず確認してください。 詳細については、「 仮想ネットワークピアリングを使用して仮想ネットワークを接続する」を参照してください。

   また、次の 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>
   

2. 適切なフィールドに記入してください。

   • データセンター名。 ドロップダウン リストから、Azure サブスクリプションを選択します。
   • 可用性ゾーン。 このデータセンターで可用性ゾーンを有効にするかどうかを選択します。
   • 場所。 データセンターがデプロイされている場所。
   • SKU サイズ。 使用可能な仮想マシン SKU のサイズから選択します。
   • いいえ 数. 各 Cassandra ノードに接続する p30 ディスクの数を選択します。
   • いいえ 数. このデータセンターにデプロイする Cassandra ノードの数を選択します。
   • Virtual Network。 既存の仮想ネットワークとサブネットを選択します。

   

   警告

   Azure portal では、データセンターを追加するときに新しい仮想ネットワークを作成することはできません。 既存の仮想ネットワークを選択する必要があり、データセンターがデプロイされているターゲット サブネット間に接続があることを確認する必要があります。 前に説明したように、デプロイを許可するために、仮想ネットワークに適切なロールを適用する必要もあります。

3. データセンターがデプロイされると、すべてのデータセンター情報を [データセンター] ウィンドウに表示できるようになります。

   

4. データ センター間のレプリケーションを確保するには、 cqlsh に接続し、次の CQL クエリを使用して各キースペースのレプリケーション戦略を更新し、クラスター全体のすべてのデータセンターを含めます。 システム テーブルは自動的に更新されます。

   ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
   

5. データが既に存在するクラスターにデータ センターを追加する場合は、 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 の構成を更新する

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

1. [設定] で Cassandra Configuration を見つけます。 構成を変更するデータ センターを強調表示し、[更新] を選択します。

   

2. 開いたウィンドウで、次に示すように、YAML 形式でフィールド名を入力します。 次に、[更新] を選択します。

   

3. 更新が完了すると、オーバーライドされた値が Cassandra Configuration ペインに表示されます。

   

   注釈

   オーバーライドされた Cassandra 構成値のみが Azure portal に表示されます。

   重要

   指定した Cassandra yaml 設定が、デプロイした Cassandra のバージョンに適していることを確認します。 Cassandra v3.11 の設定については Cassandra v3.11、v4.0 の場合は Cassandra v4.0 を参照してください。 次の YAML 設定を更新することはできません。

   • クラスター名
   • シードプロバイダー
   • 初期トークン
   • autobootstrap
   • クライアント暗号化オプション
   • サーバー暗号化オプション
   • transparent_data_encryption_options
   • 監査ログ記録オプション
   • 認証器
   • 承認者
   • ロールマネージャー
   • ストレージポート
   • ssl_storage_port（SSLストレージポート）
   • native_transport_port
   • native_transport_port_ssl
   • listen_address
   • リッスンインターフェース
   • ブロードキャストアドレス
   • ヒントディレクトリ
   • データファイルディレクトリ
   • コミットログディレクトリ
   • cdc_raw_directory
   • saved_caches_directory
   • エンドポイント・スニッチ
   • パーティショナー
   • rpc_address
   • RPCインターフェース

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

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

1. [概要] タブから Update パネルを見つけます。

   

2. ドロップダウン リストから Cassandra バージョンを選択します。

   警告

   バージョンをスキップしないでください。 3.11 から 4.0、4.0 から 4.1 のように、あるバージョンから別のバージョンに更新することをお勧めします。

   

3. [更新] を選択して保存します。

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

Cassandra 5.0 では、利便性と効率が向上する、マルチリージョン クラスターをデプロイするための合理化されたアプローチが導入されています。 ターンキー レプリケーション機能を使用すると、マルチリージョン クラスターの設定と管理がよりアクセスしやすくなり、分散環境間での統合と操作がスムーズになります。

この更新プログラムにより、複数のリージョン構成のデプロイと保守に関連する複雑さが大幅に軽減され、ユーザーは Cassandra の機能をより簡単かつ効果的に使用できます。

自動複製のシナリオ

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

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

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

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

トラブルシューティング

Azure CLI を使用して仮想ネットワークにアクセス許可を適用するときにエラーが発生した場合は、Azure portal から同じアクセス許可を手動で適用できます。 このようなエラーの例として、 "e5007d2c-4b13-4a74-9b6a-605d99f03501" のグラフ データベースでユーザーまたはサービス プリンシパルが見つかりません。 詳細については、「 Azure portal を使用して Azure Cosmos DB サービス プリンシパルを追加する」を参照してください。

クラスターに接続する

Azure Managed Instance for Apache Cassandra では、パブリック IP アドレスを持つノードは作成されません。 新しく作成した Cassandra クラスターに接続するには、仮想ネットワーク内に別のリソースを作成します。 このリソースは、アプリケーション、または 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 証明書の検証を行うことを義務付ける内部ポリシーがある場合は、各ノードの hosts ファイルに 10.0.1.5 host1.managedcassandra.cosmos.azure.com などのエントリを追加することで、このセットアップを容易にすることができます。 この方法を使用する場合は、ノードをスケールアップするたびに新しいエントリを追加する必要もあります。

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

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

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

• 自己署名証明書。 各ノードのプライベート証明書とパブリック証明書 (CA なし)。 この場合は、すべてのパブリック証明書が必要です。
• CA によって署名された証明書。 この証明書は、自己署名 CA でも、パブリック証明書でもかまいません。 この場合は、ルート CA 証明書とすべての中継局 (該当する場合) が必要です。 詳細については、 実稼働用の SSL 証明書の準備を参照してください。

クライアントからノードへの証明書認証または相互トランスポート層セキュリティ (mTLS) を実装する場合は、Azure CLI を使用して証明書を指定します。 次のコマンドは、マネージド インスタンス クラスターのトラストストアにクライアント証明書をアップロードして適用します。 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

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

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

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

次のステップ