CelerData クラスターのアップグレード

CelerDataのBring Your Own Cloud (BYOC) アーキテクチャは、アップグレードやパッチ適用などのメンテナンス活動中の中断を最小限に抑えるように設計されています。すべてのシステムアップグレードはローリングアップグレード戦略を使用して実装され、ユーザーにほぼゼロのダウンタイム体験を保証します。

注記

あらゆる種類のアップグレードおよび通常操作中に高可用性を確保するため、本番クラスターには3つのコーディネーターノードを使用することを強くお勧めします。

このドキュメントでは、クラスターのアップグレードに関するよくある質問（アップグレード中に何が起こるか、所要時間、予想される影響、準備方法）への回答を提供します。

クラスターアップグレードの種類

クラスターで実行できるアップグレードには、主に2つの種類があります。

CelerData バージョンアップグレード（パッチ / マイナー）

これは、バグ修正、パフォーマンス改善、または新機能を適用するために、CelerDataデータベースエンジンを新しいバージョン（例：4.0.1から4.0.8）にアップグレードします。アップグレードは既存のノードでインプレースで実行され、各ノードでサービスが更新されたバージョンで順次短時間再起動されます。この種類のアップグレードでは、新しい仮想マシンはプロビジョニングされません。

AMIアップグレード（インフラストラクチャ / セキュリティパッチ適用）

これは、オペレーティングシステムのセキュリティ脆弱性、カーネルパッチ、またはインフラストラクチャの更新に対処するために、基盤となるマシンイメージ（AMI）をアップグレードします。AMIアップグレードでは、更新されたイメージを持つ新しい仮想マシンをプロビジョニングし、その後古い仮想マシンを廃止しますが、クラスターの構成とデータは保持されます。

注記

コンピュートノードクラスターの場合、AMIアップグレードにはカーネルの変更が伴うため、アップグレード中にコンピュートノード上のローカルキャッシュが失われます。キャッシュは、アップグレード後にクエリが実行されると自動的に再構築されます。

アップグレードプロセスの仕組み

すべてのCelerDataクラスターアップグレードは、ローリングアップグレードアプローチを使用します。このプロセスには、個々のクラスターノードを含む、クラスターのさまざまなコンポーネントを順次更新することが含まれます。アップグレードシーケンスは、制御された方法で重要なコンポーネントを対象とします。まずコンピュート（ウェアハウス）ノードがアップグレードされ、次にコーディネーターノードがアップグレードされます。この段階的なアプローチにより、アップグレード期間全体を通じてシステムの可用性が維持されます。

コーディネーターノードのアップグレード

バージョンアップグレード

• 各コーディネーターノードは、更新されたCelerDataバージョンで順次アップグレードされます。このプロセスの一環として、各ノードのサービスは短時間再起動されます。

• フォロワーコーディネーターノードが最初にアップグレードされます。リーダーコーディネーターノードは最後にアップグレードされ、これにより短時間のリーダー選出（通常数秒）がトリガーされます。

• 各コーディネーターノードには60秒間のグレースフルシャットダウン期間があります。この間、ノードは新しい接続の受け入れを停止します。60秒経過後もアクティブな接続が残っている場合、それらは強制的に終了されます。

AMIアップグレード

• AMIアップグレードでは、スケールアウト後にスケールインするアプローチを使用します。まず、更新されたAMIを持つ新しいコーディネーターノードがプロビジョニングされ（例：3ノードから6ノードへ）、その後、古いノードが廃止されます（3ノードに戻る）。

• このアプローチは、新しいノードが古いノードが削除される前にオンラインになるため（1 → 2 → 1）、単一のコーディネーターノードを持つクラスターでもAMIアップグレード中にダウンタイムが発生しないことを意味します。

コンピュート（ウェアハウス）ノードのアップグレード

バージョンアップグレード

• 各コンピュートノードは順次アップグレードされます。クエリ容量とデータ可用性を維持するため、一度に1つのノードのみが再起動されます。

• 各コンピュートノードには、再起動前に20秒間のグレースフルシャットダウン期間があります。

AMIアップグレード

• AMIアップグレードでは、更新されたイメージを持つ新しいマシンをプロビジョニングし、それらをクラスターに追加した後、古いマシンを一度に1台ずつ廃止します。

• 交換される各ノードにも、同じ20秒間のグレースフルシャットダウン期間が適用されます。

グレースフルシャットダウンによる中断の最小化

CelerDataのアップグレードプロセスの重要な機能は、グレースフルシャットダウン期間の実装です。このメカニズムは、アップグレードのためにノードがオフラインになる間、進行中のユーザーアクティビティへの中断を最小限に抑えるように設計されています。

• コンピュート（ウェアハウス）ノード：デフォルトで20秒間のグレースフルシャットダウン期間が適用されます。この短い期間により、ノードがアップグレードされる前に、実行中のクエリとプロセスが完了することができます。

• コーディネーターノード：クラスターの管理と受信リクエストの処理における重要な役割を考慮し、コーディネーターノードには、操作のシームレスな引き継ぎを確実にするため、デフォルトで60秒間のより長いグレースフルシャットダウン期間が割り当てられます。

アップグレード中のタブレットの自動リバランス

バージョンアップグレード中、ノードの再起動中に不要なデータ移動を防ぐため、タブレットのリバランスは自動的に無効になります。アップグレード中およびアップグレード直後には、一時的なタブレットの不均衡が見られる場合があります。アップグレードが完了するとリバランスは自動的に再開され、システムは徐々にタブレットの分散を均等化します。

アップグレード中の予想される影響

次の表は、クラスターアップグレード中のさまざまなワークロードへの予想される影響をまとめたものです。

領域	影響	復旧
アクティブなクエリ	再起動中のノードにヒットするクエリは失敗します。他のノード上のクエリは影響を受けません。	クライアントの再試行により自動的に復旧します。再接続後、クエリは正常なノードにルーティングされます。
クライアント接続	再起動中のコーディネーターノードへの既存の接続は、60秒のグレースフルシャットダウン期間後に切断されます。	接続プールまたは再試行ロジックを持つクライアントは、数秒以内に利用可能なコーディネーターノードに再接続します。
データ取り込み (ストリームロード)	再起動中のノードをターゲットとするアクティブなストリームロードジョブは失敗する可能性があります。	取り込みクライアント (例: Flink/Kafka コネクタ) によって再試行されるべきです。一時的な中断のみです。
ルーチンロード	再起動中のコンピュートノード上のルーチンロードタスクは一時的に中断されます。	ノードがオンラインに戻ると自動的に再開されます。手動での介入は不要です。
長時間実行クエリ (15秒以上)	再起動中のノードで実行されている場合、終了する可能性が高くなります。	クライアントアプリケーションによって再試行される必要があります。
コンピュートノードローカルキャッシュ (AMIアップグレードのみ)	カーネル変更のため、AMIアップグレード中にコンピュートノード上のローカルキャッシュは失われます。	後続のクエリが実行されると、キャッシュは自動的に再構築されます。アクションは不要です。
タブレットバランス (バージョンアップグレード)	アップグレード中はタブレットのリバランスが自動的に無効になります。一時的な不均衡が予想されます。	アップグレード完了後、リバランスは自動的に再開されます。
データ整合性	影響なし。データはアップグレードプロセスによって影響を受けません。	該当なし。すべてのデータはそのまま保持されます。

アップグレードにはどのくらい時間がかかりますか？

アップグレードプロセスは非常に効率的で、通常、ノードあたり約1〜2分かかります。完全なクラスターアップグレードに必要な合計時間は、クラスター内のノードの総数に直接依存します。大規模なクラスターでは、当然ながらアップグレード期間は長くなりますが、それでも予測可能です。

クラスターサイズ	アップグレードタイプ	推定所要時間
小規模 (3 コーディネーター + 3 コンピュート)	バージョンアップグレード	5 – 10 分
小規模 (3 コーディネーター + 3 コンピュート)	AMI アップグレード	15 – 20 分
中規模 (3 コーディネーター + 5–10 コンピュート)	バージョンまたはAMIアップグレード	15 – 30 分
大規模 (3 コーディネーター + 10+ コンピュート)	バージョンまたはAMIアップグレード	30 – 60 分

アップグレードとアップグレード後の検証のために、約1時間のメンテナンスウィンドウをスケジュールすることをお勧めします。

ダウンタイムの予測

3つのコーディネーターノードを持つ本番クラスター (推奨)

3ノードのコーディネーター設定では、両方のアップグレードタイプでほぼゼロのダウンタイムが実現されます。1つのコーディネーターノードがアップグレードされている間も、他の2つはクエリを処理し続けます。リーダーコーディネーターがアップグレードされる際には、短いリーダー選出が発生します (通常は数秒)。再試行ロジックを持つクライアントは、一時的な接続の途切れを経験するだけです。

1つのコーディネーターノードを持つクラスター

単一コーディネータークラスターのダウンタイム動作は、アップグレードタイプによって異なります。

**AMIアップグレード:**ダウンタイムなし。AMIアップグレードはスケールアウト/スケールインのアプローチ (1 → 2 → 1) を使用するため、古いコーディネーターノードが削除される前に新しいコーディネーターノードがオンラインになります。クラスターは常に利用可能です。

**バージョンアップグレード:**単一のコーディネーターノードが新しいバージョンで再起動されている間 (通常1〜3分)、完全に利用できない期間が発生します。この期間中、クエリは処理できません。

あらゆる種類のアップグレードおよび通常の運用中に高可用性を確保するため、本番クラスターには3つのコーディネーターノードを使用することを強くお勧めします。

コンピュートノードのダウンタイム

個々のコンピュートノードは、再起動中に約20〜30秒のダウンタイムを経験します。ノードは一度に1つずつアップグレードされるため、クラスター全体としては、残りの正常なノードを通じてクエリを処理し続けます。

推奨されるクライアントの準備

クラスターアップグレードの影響を最小限に抑えるため、以下の準備をお勧めします。

再試行/再接続ロジックの確認

• クエリクライアント (JDBC、MySQLクライアント、アプリケーション接続プール) で自動再試行および再接続ロジックが有効になっていることを確認してください。

• ほとんどの標準的なMySQL互換接続プール (HikariCPなど) は、一時的な切断を自動的に処理します。

• アプリケーションが長時間持続する永続的な接続を使用している場合は、短い切断に耐え、再接続できることを確認してください。

メンテナンスウィンドウのスケジュール

• CelerDataチームと連携し、トラフィックの少ない期間または確立されたメンテナンスウィンドウ中にアップグレードをスケジュールしてください。

• クエリ量と取り込み負荷が最も低い時間帯を選択することをお勧めします。

• 週末、祝日、または重要なビジネスイベントの直前にアップグレードをスケジュールすることは避けてください。

取り込みの一時停止または削減 (任意だが推奨)

• 可能であれば、アップグレードが開始される前に、データ取り込み (ストリームロード、ルーチンロード、Kafkaコネクタ) を一時的に停止または削減してください。

• これにより、取り込みジョブの失敗の可能性が減り、ローリング再起動中のトラフィックが最小限に抑えられます。

• アップグレードが完了したことが確認された後、すぐに取り込みを再開できます。

互換性の確認 (メジャーバージョンアップグレードの場合)

• 一部のメジャーバージョンアップグレードでは、基盤となるランタイムの更新 (例: JDKバージョンの変更) が必要になる場合があります。CelerDataチームは、アップグレードプロセスの一部としてこれらの更新を処理します。

• これにより、各ノードの再起動に数秒余分にかかる可能性があることをクライアントは認識しておく必要がありますが、クライアント側でのアクションは不要です。

プロアクティブなインシデント管理とロールバック

アップグレードプロセスが問題に遭遇し、停止する稀なケースでは、CelerDataチームは自動監視システムを通じて積極的に通知を受け取ります。チームの即時介入により、迅速な診断と解決が保証されます。是正措置には以下が含まれる場合があります。

• アップグレードのロールバック: システムを以前の安定した状態に戻し、すぐに完全な機能を復元します。

• 進行中の問題の修正: ホットフィックスを適用するか、根本的な問題を解決して、アップグレードが正常に完了できるようにします。

• AMIアップグレードの場合、古いマシンイメージは保持され、迅速なフォールバックに使用できます。

注記

すべてのバージョンダウングレードが安全であるとは限りません。一部のバージョンでは、後方互換性のないメタデータ変更が導入されています。CelerDataチームは、アップグレードを進める前に、常にダウングレードの互換性を検証します。

クイックリファレンス概要

質問	回答
全体的な停止はありますか？	いいえ。ローリングアップグレードです。ノードは一度に1つずつアップグレードされます。
クエリは失敗しますか？	再起動中のノードにヒットするクエリは失敗する可能性があります。リトライロジックがこれを自動的に処理します。
アップグレード全体の所要時間はどのくらいですか？	ノードあたり約1～2分。クラスターサイズに応じて、通常合計5～60分です。
ノードごとのグレースフルシャットダウンは？	コーディネーター: 60秒。コンピュート: 20秒。
データは安全ですか？	はい。アップグレード中にデータ損失や破損はありません。
何かする必要はありますか？	リトライロジックが導入されていることを確認してください。オプションで取り込みを一時停止します。メンテナンスウィンドウに合意します。
ロールバックは可能ですか？	はい、事前に検証されたロールバック計画があれば可能です。一部のバージョン制約が適用される場合があります。
コーディネーターノードは3つと1つどちらが良いですか？	3ノード: すべてのアップグレードでほぼゼロダウンタイム。1ノード: AMIではゼロダウンタイム、バージョンアップグレードでは1～3分。
コンピュートノードのキャッシュは失われますか？	AMIアップグレード時（カーネル変更）のみです。キャッシュは自動的に再構築されます。

お問い合わせとサポート

アップグレードのスケジュール設定や、特定の環境への影響についてご質問がある場合は、CelerDataソリューションアーキテクトにご連絡いただくか、専用のSlackチャンネルを通じてお問い合わせください。

アップグレード中に共同監視セッションを手配し、すべてがスムーズに進行することを確認させていただきます。