Skip to main content

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

あるバージョンのAlteryx Serverから別のバージョンへのアップグレードは簡単なプロセスですが、アップグレードをスムーズに実施できるようにするための、いくつかの考慮事項と準備手順があります。このページでは、アップグレードを計画する際に有用なドキュメントへのリンクや、考慮すべき手順を追ったアプローチなど、このプロセスのトピックの概要を説明します。

このドキュメントのすべての手順または推奨事項が、すべての環境やインストールに適用可能であるとは限りません。異なる計画を適用すべき場合もあります。

一般に、アップグレードプロセスは、次のような概略の手順で構成されています。

以下のセクションでは、これらの手順について説明し、作業の計画に役立つ説明を追加します。詳細な手順へのリンクが存在する場合は、インラインで表示されます。このドキュメントで提供されているすべてのリンクをまとめたリストは、 ガイドとヘルプ記事 セクションにあります。

これらの手順のチェックリストは、 Server Upgrade Checklistに記載されています。

Alteryxとそのパートナーは、アップグレードの計画と実行を支援できます。このプロセスについてサポートが必要な場合は、アカウントエグゼクティブにお問い合わせください。

新しい用語

Server 2022.3のリリースでは、Galleryという用語は廃止され、Server UIを使用するようになりました。本書の執筆時点では、ソフトウェアおよび文書に従来の用語が残っていますが、この文書では、該当するサービス、ノード、構成などに言及する際に「Server UI」を使用します。

セクション1環境の文書化

アーキテクチャと構成の把握

環境を完全に理解(および文書化)する必要があります。少なくとも、次のことを理解しておく必要があります。

  • インストールされているサーバーの数とその機能は何か。

    • 各環境(開発/品質管理/本番)に、コントローラー、Server UIのインスタンス、ワーカー、MongoDBサーバーがいくつあるか。

    • 高可用性(HA)環境を実行しているか。

  • 環境を視覚的に表現したアーキテクチャ図があるか。存在していない場合は、これを作成しておく良い機会です。

  • 使用中の環境で実行されているAlteryx Serverのソフトウェアバージョンは何か。

  • どのような追加ソフトウェアがインストールされているか。

    • カスタムRライブラリ

    • カスタムPythonライブラリ

    • サードパーティ製ユーティリティ

    • コネクタ

      • 必ずしもすべてのコネクタをアップグレードする必要はありません。一部のコネクタにはアップグレードが存在しない場合もあります。

  • データパック: Location Insights、Business Insights、Intelligence Suiteなど。

    • アップグレード中にこれらのアドオンの一致するバージョンを(利用可能な場合)インストールするのが、ベストプラクティスです。

    • ユーザーが設計したカスタムツール、またはコミュニティからダウンロードしたカスタムツール、その他の購入済みまたは無料のサードパーティツールおよびコネクタ。これらのリストをバージョン付きで作成します。

  • Alteryxシステム設定 構成ツールを使用して設定された構成オプション。次のものが含まれますが、これらに限定されません。

    • ワークスペース

    • ロギングディレクトリ

    • スケジューラーおよびエンジン有効化設定

    • 以下のものなどの永続性設定:

      • データベースタイプ

      • データフォルダー

      • 保存オプション

    • Server UI設定(URLおよびセキュリティ)

    • 認証方式とIDP情報

    • SMTP

    • Run Asユーザー

      注記

      これらの構成オプション(スケジューラー、エンジン、永続性、Server UI、SMTP設定、Run-Asユーザーなど)は C:\ProgramData\Alteryx\RuntimeSettings.xml にキャプチャされるため、管理者は設定を個別に記録する必要はありません。RuntimeSettings.xmlのコピーがあれば、これらすべてがプレーンテキストのXMLファイルで提供されます。

  • サービスログオンユーザー

  • 物理サーバーと仮想サーバーの仕様

  • MongoDBとPythonのバージョン

    • ユーザー管理型MongoDB : ユーザー管理型MongoDBのバージョンは、Serverのアップグレードからは独立したものです。Serverのアップグレードと並行して、ユーザー管理型のMongoDBを個別にアップグレードする必要がある場合があります。ユーザー管理インスタンスの場合、 Alteryx はサポートを提供いたしません。詳細については、 バージョンサポートポリシーを参照してください。

    • 組み込みのMongoDB : 組み込みのMongoおよびPythonのバージョンはServerのバージョンに従うため、別途配慮する必要はありません。埋め込みMongoDBバージョンの詳細については、 MongoDBスキーマリファレンス または バージョンサポートポリシーを参照してください。

    注記

    Pythonツールを使用している場合は、アップグレードの前に Server Upgrade Python Tool Environment Checklistを確認してください。

    注記

    スケジュールされたジョブ、コレクション、ワークフロー、メンバーシップのリストはMongoDBの一部であり、アップグレード中に失われることはありません。

この手順を簡単に行えるように、 Configuration and Architecture Checklistを用意しました。このチェックリストに記入することで、インフラストラクチャと構成の概要を確認できます。

ビジネスクリティカルなワークフローの特定

アップグレード計画の重要な部分は、アップグレードプロセスの一部として保護およびテストしようとするビジネスクリティカルなワークフローを特定することです。これらは通常、スケジュールに従って実行され、下流の作業(Alteryxの内部または外部)への依存関係として機能し、かつ/または重要なデータや出力を社内の主要な関係者に提供するワークフローです。基本的には、長期間使用できない場合に、ビジネスに悪影響を及ぼしうるワークフローを特定する必要があります。

重要なワークフローを特定すると、ターゲットバージョンを選択することができます。重要なワークフローに特定のバージョンと互換性のないツールやコネクタが含まれている場合は、ターゲットバージョンを選択するときにそのことを考慮する必要があります( Server Upgrade Version-to-Version Guideについては以下の セクション3 を参照してください)。これらのワークフローは、 アップグレード後のテスト (下記参照)のために変更し、QA計画に含めることもできます。

ビジネスクリティカルなワークフローのテストバージョンの作成

アップグレード後のQC中に重要なフローをテストする場合は、他の本番システムにデータを書き込む出力や、本番環境に保存される出力を生成する出力を無効にするか編集する必要があります。

ここでの一般的な方法論は、ターゲットのシステムとディレクトリにはアクセスするが、本番のファイルやテーブルのデータには上書きしないような、このフローの専用のテストバージョンを作成することです。

  • データ操作の場合は、出力をテーブルの専用テストバージョンに書き込むように変更します。

  • ファイル操作の場合は、異なるファイル命名規則を使用してファイルを書き込むか、テスト用サブフォルダに書き込みます。

これにより、本番環境に影響を与えずにエンドツーエンドのテストを実行できます。これらのテストワークフローは、同じ理由から本番テストでも使用する必要があります。

追加の考慮事項

組織で進行中の運用の中断を最小限に抑えるように、アップグレードアクティビティを計画およびスケジュールします。アップグレードウィンドウは、通常の営業時間外(可能な場合)や使用率が「軽い」期間にスケジュールします。たとえば、会計年度末、四半期末処理、毎月の監査などの期間にスケジュールを設定するのは避けます。

一部のクライアントは、アップグレードウィンドウを使用して、Alteryxマシンのオペレーティングシステム(OS)バージョンを再確認します。これを実施しようとする場合は、IT部門と協力して システム要件 を確認してください。OSを同時にアップグレードするかどうかは、アップグレード計画に必ず記載してください。Alteryxのアップグレード後に問題が発生した場合は、サポートエンジニアに通知されます。

セクション2Serverヘルスチェックの実行(オプション)

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

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

セクション3ターゲットバージョンの選択

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

注記

すべてのメジャーリリースは、24か月間にわたりサポートされます。組織で頻繁に更新を実施しない場合は、これが意思決定において重要です。

リリースノートを確認する

選択プロセスの最初のステップは、 リリースノート を読むことです。ここには、対象とする可能性のあるバージョンの新機能とプログラミングの変更点、およびバグ修正と既知の問題について詳しく説明されています。

アップグレードパスを理解する - 現在の地点から目的の地点まで

一部のリリースでは、特定の先行バージョンからのアップグレードで追加の考慮事項があり、すべてのお客様に適しているわけではないバージョンも存在します。たとえば、バージョン間で移動するためにMongoDBをアップグレードすることが必要な場合があり、また、バージョン2022.3の場合は、ソフトウェアのデータ暗号化機能が強化されているため、Serverの該当バージョンは以前のバージョンと互換性がなく、ServerとDesignerを同時にアップグレードする必要があります。

Alteryxのヘルプとサポートのサイトには、 Server Upgrade Version-to-Version Guideがあり、Alteryx Serverのバージョンをアップグレードする際に注意する必要があるタスクと考慮事項が記載されています。このガイドは、2019.1から2022.1への移行など、複数のバージョンを一度にアップグレードする場合に特に役立ちます。アップグレードをスムーズに実施するには、段階的に手順を実行する必要があります。

バージョンの選択

利用可能なさまざまなバージョンと、アップグレードパスを決定する特別な考慮事項について学習したので、ターゲットバージョンを選択する準備ができました。ここで、 ダウンロード サイトに進みます。

セクション4ソフトウェアのダウンロード

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

  • Alteryx Server(最新および以前のバージョン)

  • Alteryx Designer

  • Alteryx Intelligence SuiteとInsightデータ

  • Alteryxがサポートするデータベースドライバ

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

バージョンパリティ

一般的に、ServerとDesignerは同じバージョンにしておくことをお勧めします。したがって、この時点で一致するDesignerインストーラをダウンロードしておくことが最も適切です。ただし、大規模なユーザーベースでDesignerをアップグレードするには、追加の計画とリソースが必要なため、Serverのアップグレードと同時にアップグレードを完了したくない場合があります。

Serverは一般的に、古いバージョンのDesignerと下位互換性があります。ただし、ターゲットバージョンのServerでサポートされている新機能が、古いバージョンのDesignerでは利用できないという点に注意する必要があります。

ServerおよびDesigner 2022.3については、プラットフォーム全体でのデータ暗号化の強化により、この下位互換性は存在しません。このバージョン以降にアップグレードする場合は、Designerを同時にアップデートする必要があります。 移行準備ツール のヘルプページには、このバージョンへのアップグレードを準備するための特別な手順が記載されています。 ダウンロード ページで取得できなくなった古いバージョンをダウンロードしようとしている場合は、 フルフィルメント にお問い合わせください。

セクション5サンドボックス/開発サーバーのアップグレードと結果の確認

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

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

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

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

1. バックアップを実行する

次のバックアップを実行します。

2. アップグレード前チェックを完了する

Alteryx Server: アップグレード前のチェック 」のコミュニティ記事にあるアップグレード前のチェック/ワークフローを実行することにより、Serverのアップグレードに関する多くの問題を回避できます。この手順では、クライアントがアップグレードを実行する際に直面する最も一般的な問題に対処し、それぞれに推奨される解決方法/手順を示します。

アップグレードを実行する前に、各環境でアップグレード前のチェックを実行することが重要です。たとえば、開発マシンでテストしている場合、アップグレードを完了する前に、開発環境でチェックを再実行し、指示された手順を実行する必要があります。

アップグレード中にワーカーノードでスケジューラーを無効にする

既定では、Serverのアップグレード中に実行するはずであったスケジュールは、Serverとノードが再起動するとすぐに起動します。サンドボックスでテストアップグレードを実行する場合は、ワークフローの開始によって本番システムに影響を与えたくない場合が多いため、この点に注意してください。

アップグレードの前にすべてのスケジュールを無効にし、実行するスケジュールを個別に決定することをお勧めします。

サービスの開始時にスケジュールを実行しない場合は、次のようにします。

  1. 各ワーカー(およびメインのServerノード)で Alteryxシステム設定 を実行します。

  2. [ ワーカー ] > [ 一般 ] > [ 未割り当てジョブを実行 ] の選択を解除します。

  3. ワーカーに一意のジョブタグ(「UPGRADETESTING」など)を付与します。

または、すべてのスケジュールを削除する方法については、 カスタマーサポート にお問い合わせください。

3. アップグレードの実行

マシン上でアップグレードを行う場合、アップグレードの実行は簡単なプロセスです。ターゲットマシンに新しいバージョンの新規インストールを実行する場合は、アップグレードパスに含まれないライセンスの適用を含む、さまざまな手順があります。既存のアクティブなライセンスは、アップグレードされたマシンで中断なく引き続き機能します。一般的なアップグレード手順は、 Serverのインストールまたはアップグレード に記載されています。

新規インストールとインプレースアップグレードに関するさまざまな手順が詳しく説明されており、ライセンス、システム要件、準備チェックリスト、MongoDBアップグレードなどに関する関連ヘルプファイル/記事へのリンクが含まれています。これらの多くは、このドキュメントの最後にある「 ガイドとヘルプ記事 」のセクションに記載されています。

予測ツールはメインインストールでアップグレードする必要があることに注意してください。サービスログオンユーザーを設定していた場合は、アップグレード後に再度設定する必要があります。アップグレードすると、Alteryx Serviceが削除され、再インストールされます。

マルチノード環境のアップグレード

マルチノード環境では、すべてのノードを同じバージョンにアップグレードし、「 マルチノードAlteryx Serverでサービスを再起動する方法 」のコミュニティ記事の「シャットダウン」セクションに示されている順序でノードをシャットダウンする必要があります。

すべてのノードをアップグレードしたら、同じドキュメントの「スタートアップ」セクションに記載されている適切な再起動順序に従ってください。

すべてが起動したら、必要なコネクタ、データパック、ドライバ、アドオン(Intelligence Suiteなど)、サードパーティ製ツールをすべてアップグレードします。

4. アップグレードのテスト/QC

Serverソフトウェアと該当するコネクタがアップグレードされたので、テストを開始します。

Alteryx Services

最初のテストは基本的なもので、 Server Upgrade Checklistのテストセクションにあります。

以下のことができますか:
  • Alteryx Serviceは実行されていますか?

  • 以下のことができますか:

    • Server URLへのアクセス。

    • 管理者ページ内で移動してユーザー、コレクションなどの表示。

    • DesignerからServerへのワークフロー公開。

    • ワークフローの実行。

    • 設定で許可されている場合、資格情報を指定したワークフローの保存と実行。

構成オプション

次に、 Alteryxシステム設定 構成ツールの構成オプションを調べて、設定が失われていないことを確認します。これらの設定は、「 環境の文書化 」セクションで説明されています。永続性設定、SMTPの構成など、変更が必要な場合は、この時点で変更してください。また、これらの変更を書き留めておき、本番環境をアップグレードする際に再利用してください。

注記

一部のアップグレードでは、一部の設定がアクティブに変更されます。たとえば、2022.1ではServerに対してAMPがオンに設定され、同時に実行できるワークフローの数が変更されました。

詳細については、必ず リリースノート を参照してください。

コネクタおよびドライバ

次のステップは、SharePointコネクタやO365コネクタ、SQL Server、Snowflake、DatabricksなどへのODBC/OLEDBコネクタなどの重要なシステムを対象に、コネクタとドライバをテストすることです。データの接続、読み取り、書き込みが可能であることを確認します。

重要なワークフロー

次に、 環境の文書化 」セクションにも記載されているように、ビジネスクリティカルなフローと、コネクタを使用するフローをテストします。この一連のテストでは、このガイドの「 ビジネスクリティカルなワークフローのテストバージョンの作成 」セクションで作成したワークフローのテストバージョンを使用します。これらのフローの未変更の本番バージョンを実行すると、本番の展開先は、これらのフローが通常通り実行されているかのように影響を受けます。

スケジューラーおよびServer UI

最後に、スケジューラーとServer UIを実行している場合は、これらもテストします。

  • ワークフローをスケジュールできるか。実行できるか。

  • 分析アプリは正常に動作するか。

重要

この環境で公開およびスケジュール/実行するアプリは、本番バージョンではないことを確認してください。これらのフローの未変更の本番バージョンを実行すると、本番の展開先は、これらのフローが通常通り実行されているかのように影響を受けます。

5. エラーをメモしてサポートを受ける

テストで明らかになった次のような問題をカタログ化します。

  • 開始しないサービスやエラーを報告するサービス。

  • MongoDBスキーマまたは暗号化の移行の失敗。

  • 実行されないワークフロー、または実行で予期しない結果やエラーが発生するワークフロー。

  • 動作しないコネクタ。

  • MongoDBのエラー。

Server Upgrade Checklistには、前のセクションでの一般的なトラブルシューティング手順がいくつか記載されています。アップグレードプロセスでエラーが発生し、ガイドに記載されている一般的なトラブルシューティング手順で解決できない場合は、カスタマーサポートを受けられます。アップグレードの計画や実行についてサポートが必要な場合は、アカウントエグゼクティブが解決案を提示できます。

6. ロールバック/復元の実行

テストおよびQCフェーズで明らかになった問題を解決できなかった場合は、ロールバックまたは復元を実行します。ロールバックまたは復元の前に、カスタマーサポートに提供するため、または次回のアップグレードに先立って内部レビューで使用するために、Serverマシンからログファイルを収集しておくと良いでしょう。スナップショット/バックアップがある場合は、すぐに復元して、次回のアップグレードを計画できます。スナップショット方法が実施できない場合は、「 How To: Downgrade Alteryx Server 」のコミュニティ記事に示されている従来のロールバック方法に従うことができます。

セクション6本番アップグレードのスケジュール

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

注記

本番アップグレードは、テスト環境で作成した「スクリプト」に従い、環境間のアーキテクチャの違いに固有の変更を加味します。たとえば、テスト対象の環境がシングルノードアーキテクチャで、本番環境ではワーカーとServer UI用に別々のノードがある場合、本番環境では追加のインストール手順が存在します。計画するときにこれに注意してください。

プロのヒント : Alteryx Server UI経由の Server通知 を追加の通信チャネルとして使用すると、保留中のアップグレードについてユーザーに通知できます。アップグレードの情報は、社内のAlteryxコミュニティ(SharePoint、Confluence、Yammer、Teamsなど)に投稿することもできます。

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

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

重要

ビジネスの中断を最小限に抑えられる日程でアップグレードを計画することを忘れないでください。詳細および推奨事項については、「 追加の考慮事項 」を参照してください。

セクション7本番アップグレードの実行

Server のアップグレード

このセクションの手順の概要は、 セクション5 の手順1~6を反映したものになります。詳細およびヘルプリンクについては、該当するセクションを参照してください。

Designerのアップグレード(オプション)

本番環境が稼働したら、Designerインストールをアップグレードできます(プランに含まれている場合)。Designerは、Serverにインストールされているバージョンよりも新しいバージョンにすることはできません。このアップグレードは、ユーザーのマシンに直接影響します。Designerのアップグレード手順については、 Designerのアップグレードを参照してください。

DesignerとServerの互換性

Designerのバージョンは、接続先のServerのバージョンと同じか、それより以前のものである必要があります。 例外はServer 2022.3以降で、暗号化の変更により少なくともDesigner 2022.3が必要です

Designerのバージョンは、接続先のServerより新しいものにすることはできません。

一致の必要があるのはバージョン(Year.Release)のみで、パッチの一致は必要ありません。

Serverのアップグレードと同様に、アップグレードされたDesignerバージョンをテストし、ワークフローが引き続き実行できて、Serverへの接続が可能であることを確認する必要があります。Serverアップグレードのベストプラクティスと同様に、Designerアップグレードのテストは、少数のユーザーマシンで行うように計画してください。

ガイドとヘルプ記事

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

アップグレードの準備

環境のバックアップと復元

アップグレードの実行

追加のリソース