次の方法で共有


Azure Managed Instance for Apache Cassandra での管理操作

Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 このサービスでは、各ワークロードの特定のニーズに応じて構成をオーバーライドすることもできます。これにより、必要に応じて最大限の柔軟性と制御が可能になります。 この記事では、このサービスで提供される管理操作と機能について説明します。 また、ハイブリッド クラスターを管理するときの Azure サポート チームとお客様の責任の切り分けについても説明します。

圧縮

  • 圧縮にはさまざまな種類があります。 現在、修復を使用してマイナー圧縮を実行しています ( 「メンテナンス」を参照)。 これを実行すると、Merkle ツリーの圧縮が実行されます。これは特殊な種類の圧縮です。
  • Cassandra では CQL ( など) を使用してテーブルに設定された圧縮戦略WITH compaction = { 'class' : 'LeveledCompactionStrategy' }に応じて、テーブルが特定のサイズに達すると自動的に圧縮が行われます。 実際のワークロードに応じた圧縮戦略を慎重に選択し、戦略外の手動圧縮は行わないことをお勧めします。

Patching

  • オペレーティング システムレベルのパッチは、約 2 週間の頻度で自動的に適用されます。

  • Apache Cassandra のソフトウェアレベルのパッチは、セキュリティの脆弱性が特定されたときに適用されます。 パッチ適用の頻度は変わる場合があります。

  • パッチの適用中、マシンは 1 ラックずつ再起動されます。 クォーラムの ALL 設定を使用しておらず、レプリケーション係数が 3 以上であれば、アプリケーション側でパフォーマンスが低下することはありません。

  • Apache Cassandra のバージョンは、X.Y.Z の形式になります。 サービス ツールを使用して、メジャー (X) バージョンとマイナー (Y) バージョンのデプロイを手動で制御できます。 一方、メジャー バージョンとマイナー バージョンの組み合わせに必要となる場合がある Cassandra のパッチ (Z) は自動的に適用されます。

注意

現在、このサービスは Cassandra バージョン 3.11 と 4.0 をサポートしています。 どちらのバージョンも GA です。 クラスターのデプロイ中に Cassandra のバージョンを指定する場合は、「Azure CLI クイック スタート (手順 5)」を参照してください。

メンテナンス

  • Nodetool の修復は、reaper を使用してサービスによって自動的に実行されます。 このツールは毎週 1 回実行されます。 ハイブリッド デプロイに独自のサービスを使用する場合は、これを無効にすることもできます。

  • ノードの稼働状況の監視は以下で構成されます。

    • Cassandra リング内の各ノードのメンバーシップをアクティブに監視する。
    • 仮想マシン、ネットワーク、ストレージ、Linux、サポート ソフトウェア障害などのインフラストラクチャの問題を自動検出し、自動軽減する。
    • CPU、ディスク、クォーラム損失、およびその他のリソースの問題を前もって監視する。
    • 障害が発生したノードを可能であれば自動的に復旧させ、自動生成された警告に応答してノードを手動で復旧させる。

サポート

Azure Managed Instance for Apache Cassandra では、マネージド クラスター内のデータ センターの可用性ついて、SLA が提供されます。 サービスの使用に関して問題が発生した場合は、Azure portal でサポート リクエストを提出します。

当社のサポートの特典は次のとおりです。

  • Cassandra インフラストラクチャの問題に対応する窓口を一本化 - IaaS チーム (ディスク、コンピューティング、ネットワーキング) に個別にサポートケースを作成する必要がありません。
  • パフォーマンスのボトルネック、サイズ設定、その他のリソース制約の問題に対する、電子メールでの予防的なアドバイス。
  • 24 時間 365 日のサポート体制 (深刻な障害に対する自動生成インシデントを含む)。
  • コミュニティによって承認されたパッチサポート (パッチ適用に関するページを参照)。
  • 社内の Java JDK/JVM エンジニアリング チームのサポート。
  • ソフトウェア サプライチェーン セキュリティを備えた Linux オペレーティング システムのサポート。

重要

Microsoft では、サポート ケースを通じてレポートされた問題を調査して診断し、可能な限り解決または軽減を行います。 ただし、CPU、ディスク、またはネットワークの問題を引き起こす Apache Cassandra の構成レベルの使用方法については、ユーザーが最終的責任を負います。

このような問題の例を次に示します。

  • 非効率なクエリ操作。
  • 容量を超えるスループット。
  • ストレージ容量を超えるデータの取り込み。
  • キースペースの誤った構成設定。
  • 不十分なデータ モデル戦略またはパーティション キー戦略。

Microsoft がサポート ケースを調査し、問題の根本原因が Apache Cassandra の構成レベルにある (また、Microsoft が管理する基盤となるプラットフォーム レベルの側面にはない) ことが検出された場合でも、ケースを閉じる前に、修正または軽減に関する推奨事項とガイダンスを提供いたします (可能な場合)。

Apache Cassandra でよくある、上記のようなアプリケーション レベルや構成レベルの問題を防ぐためには、メトリックを有効化したり、Azure Monitor の統合について理解を深めたりすることをお勧めします。

警告

Azure Managed Instance for Apache Cassandra では、DBA の日常的な管理用の nodetool コマンドと sstable コマンドも実行できます。詳細については、こちらを参照してください。 これらのコマンドの中には Cassandra クラスターを不安定にするものがあるため、非運用環境でテストした後にのみ慎重に実行する必要があります。 可能であれば、最初に --dry-run オプションをデプロイする必要があります。 Microsoft は、既定のデータベース構成やテーブルを変更するコマンドの実行に関する問題について、いかなる SLA やサポートも提供することはできません。

バックアップと復元

スナップショットのバックアップは既定で有効になっており、24 時間ごとに実行されます。 バックアップは内部の Azure Blob Storage アカウントに格納され、最大 2 日間 (48 時間) 保有されます。 最初の 2 つのバックアップにはコストはかかりません。 追加のバックアップには課金されます。価格に関するページを参照してください。 バックアップ間隔と保有期間を変更するには、ポータルでポリシーを変更します。

バックアップ スケジュールの構成ページのスクリーンショット。

既存のバックアップから復元するには、Azure portal でサポート リクエストを提出します。 サポート ケースを提出するときは、以下を実行する必要があります。

  1. 復元するバックアップのバックアップ ID をポータルから指定します。 これは、ポータル内にあります。

    バックアップ ID が強調表示された、バックアップ スケジュールの構成ページのスクリーンショット。

  2. ソース データセンターが削除されたかどうかをお知らせください。 これは、復元元となる正しいバックアップ アカウントを識別するために重要です。

  3. クラスター全体を復元する必要がない場合は、復元する必要があるキースペースとテーブル (該当する場合) を指定します。

  4. 既存のクラスターまたは新しいクラスターでバックアップを復元することをお勧めします。

  5. 新しいクラスターに復元する場合は、最初に新しいクラスターを作成する必要があります。 ターゲット クラスターがデータ センターの数の観点からソース クラスターと一致し、対応するデータ センターに同じ数のノードがあることを確認します。 新しいターゲット クラスターに資格情報 (ユーザー名/パスワード) を保持するか、復元してユーザー名/パスワードを最初に作成されたものでオーバーライドするかを決定することもできます。

  6. 新しいターゲット クラスターに system_auth キースペースを保持するか、復元してバックアップのデータで上書きするかを決定することもできます。 Cassandra の system_auth キースペースには、ロール、ロールのアクセス許可、パスワードなど、承認と内部の認証データが含まれています。 既定の復元プロセスでは、system_auth キースペースが上書きされることに注意してください。

Note

バックアップからの復元要求への応答にかかる時間は、作成するサポート ケースの重大度 (および応答時間に対応する SLA) と復元するデータの量の両方によって異なります。 ただし、復元を完了するまでの時間は、復元されるデータの量に大きく依存するため、SLA は提供されません。

警告

バックアップは誤削除のシナリオを対象としたものであり、geo 冗長ではありません。 したがって、リージョン全体が停止した場合のディザスター リカバリー (DR) 戦略として使用することは推奨されません。 リージョン全体の停止から保護するためには、複数リージョン デプロイをお勧めします。 複数リージョン デプロイのクイック スタートを参照してください。

セキュリティ

Azure Managed Instance for Apache Cassandra には、明示的なセキュリティ制御および機能が多数組み込まれています。

  • サプライ チェーンの制御によってセキュリティが強化された Linux 仮想マシン イメージ。
  • オペレーティング システム レベルでの Common Vulnerability & Exposure (CVE) 監視。
  • マネージド仮想マシンでホストされている Apache Cassandra と Prometheus の両方のソフトウェアの証明書ローテーション。
  • アクティブな脆弱性スキャン
  • アクティブなウイルス スキャン。
  • 安全なコーディング方法。

セキュリティ機能の詳細については、 こちらを参照してください。

ハイブリッド サポート

ハイブリッド クラスターを構成すると、サービスで実行される自動 reaper 操作によって、クラスター全体にメリットがもたらされます。 これには、サービスによってプロビジョニングされていないデータセンターが含まれます。 それ以外では、オンプレミスまたは外部でホストされているデータセンターの管理はお客様が行う必要があります。

次のステップ

次のいずれかのクイックスタートに取り組みます。