Serverアップグレードのベストプラクティス

Alteryx Serverヘルスチェックは、Alteryx Server環境の使用パターンを理解するための貴重なリソースです。履歴使用パターンを分析して、Server環境の稼働の高さ、どのような最適化アクティビティが必要か、環境のサイズが適切かどうかを判断します。

詳細については、Alteryxアカウントエグゼクティブにお問い合わせください。

Serverソフトウェアのターゲットバージョンを選択します。社内のアップグレードの頻度によっては、最新のソフトウェアリリースよりも1つから複数前のバージョンを使用している場合があります。現在のバージョンとターゲットとの間のバージョン数に応じて、適用すべき考慮事項があります。ほとんどのクライアントは、新しいバージョンがリリースされるたびにアップグレードするわけではありません(1年の間に複数のリリースが存在する場合もあります)。また、常に最新のリリースを実行するとも限りません。多くのクライアントは最新より1つ前のリリースを選択します。

Alteryxのライセンスポータルにアクセスします。このサイトにアクセスするにはアカウントが必要です。サイトにアクセスすると、以下に例を示すように利用可能なダウンロードがすべて表示されます。

必要なすべてのソフトウェアをダウンロードして、プロセスの次のステップに進みます。ダウンロードのヘルプについては、製品のダウンロードとインストールのヘルプページを参照してください。

本番Serverをアップグレードする前に、非本番環境でアップグレードをテストし、プロセス手順を文書化することは、本番環境でプロセスをスムーズに実行し、ビジネスクリティカルなワークフローとサードパーティ製ツールが引き続き期待どおりに実行されるようにするための最良の方法です。問題が発生する場合は、その機会を捉えて問題を調査して修正し、修正手順を本番アップグレードの計画に追加します。このテストアップグレードで実行する手順と、QCフェーズで追加した修正手順が、本番環境のアップグレード「スクリプト」になります。

理想的には、サンドボックス/開発/テストの各Serverで同じバージョンから開始してアップグレードします。サンドボックス環境の詳細については、Alteryx Serverサンドボックス環境コミュニティの記事を参照してください。

マルチノード環境の場合でも、コントローラー + Server UI + ワーカーを実行する単一のマシンでのテストは有効です。同様に、ユーザー管理型MongoDBを使用している場合、テストマシンの組み込みMongoDBにデータベースバックアップを復元すると、アップグレードの検証に役立ちます。サンドボックスライセンスの詳細については、アカウントエグゼクティブにお問い合わせください。

最低限、新しいバージョンで重要なワークフローをテストするには、ターゲットバージョンのDesignerをユーザーのマシンにインストールする必要があります。手順については、「同じマシンへの別バージョンのDesignerのインストール」のヘルプページを参照してください。

非本番環境でのアップグレードのテストに成功し、アップグレードプロセスの文書化ができれば、本番環境のアップグレードを計画します。

適切なダウンタイムをスケジュールし、アップグレード中にServer上のワークフローが実行されないことをユーザーに通知する必要があります。ビジネスクリティカルなフローの場合、ユーザーは、新しくアップグレードされたテスト環境で実行したり、ローカルで実行したり、停止を計画して影響を受ける下流のオーディエンスに遅延を通知したりできます。

パッケージ化/自動化方法または手動インストールプロセスを使用してDesignerもアップグレードする場合は、インストールを完了するために必要な追加の時間とリソースを計画し、ユーザーベースにも通知してください。Serverはバージョン2022.3まではDesignerと下位互換性がありますが、これより新しいバージョンのDesignerは古いバージョンのServerでは動作しません。そのため、Serverのアップグレードは常にDesignerのアップグレードより前に行う必要があります。

このリストには、このドキュメントに記載されているすべてのリソースへのリンクと、Serverのアップグレードプロセスに役立つ追加のリソースがあります。