企業環境への Tableau Server 導入ガイド

リファレンス アーキテクチャの Web 層には、次のコンポーネントが含まれている必要があります。

• Tableau クライアントから HTTPS 要求を受け入れ、リバース プロキシ サーバーと通信する Web 用アプリケーション ロード バランサー。
• リバース プロキシ: 
  • Tableau Server の独立したゲートウェイを導入することをお勧めします。
  • 冗長性とクライアント負荷の処理のために、少なくとも 2 台のプロキシ サーバーを使用することをお勧めします。
  • ロード バランサーから HTTPS トラフィックを受け取ります。
  • Tableau ホストへのスティッキー セッションをサポートします。
  • ゲートウェイ プロセスを実行している各 Tableau Server へのラウンド ロビン負荷分散用のプロキシを構成します。
  • 外部 IdP からの認証要求を処理します。
• フォワード プロキシ: Tableau Server は、ライセンス認証とマップ機能のためにインターネットへアクセスできる必要があります。フォワード プロキシの許可リストに Tableau サービスの URL を設定する必要があります。「インターネットとの通信」 (Linux(新しいウィンドウでリンクが開く)) を参照してください。
• クライアント関連のすべてのトラフィックは、HTTPS を介して暗号化可能:
  • クライアントからアプリケーションへのロード バランサー
  • リバース プロキシ サーバーへのアプリケーション ロード バランサー
  • Tableau Server へのプロキシ サーバー
  • IdP へのリバース プロキシで実行されている認証ハンドラ
  • IdP への Tableau Server

Tableau Server の独立したゲートウェイ

Tableau Server の独立したゲートウェイは、Tableau Server バージョン 2022.1 で導入されました。独立したゲートウェイは、Tableau 対応のリバース プロキシとして機能する Tableau ゲートウェイ プロセスのスタンドアロン インスタンスです。

独立したゲートウェイは、バックエンド Tableau Server への単純なラウンド ロビン負荷分散をサポートします。ただし、独立したゲートウェイは、エンタープライズ アプリケーションのロード バランサーとして機能するよう意図されていません。独立したゲートウェイは、エンタープライズ クラスのアプリケーション ロード バランサーの背後で実行することをお勧めします。

独立したゲートウェイには、Advanced Management ライセンスが必要です。

認証と認可

既定のリファレンス アーキテクチャでは、ローカル認証が構成された Tableau Server のインストールが指定されています。このモデルでは、クライアントは Tableau Server に接続して、ネイティブの Tableau Server ローカル認証プロセスによって認証される必要があります。このシナリオでは、認証されていないクライアントがアプリケーション層と通信する必要があり、セキュリティ上のリスクになるため、リファレンス アーキテクチャでこの認証方法を使用することはお勧めしません。

代わりに、AuthN モジュールと組み合わせてエンタープライズ グレードの外部 ID プロバイダーを構成して、アプリケーション層へのすべてのトラフィックを事前認証することをお勧めします。外部 IdP を使用して構成されている場合、ネイティブの Tableau Server ローカル認証プロセスは使用されません。Tableau Server は、IdP がユーザーを認証した後に、展開されているリソースへのアクセスを許可します。

AuthN モジュールによる事前認証

このガイドに記載されている例では、SAML SSO が構成されていますが、事前認証プロセスはほとんどの外部アイデンティティ プロバイダーおよび AuthN モジュールを使用して構成できます。

リファレンス アーキテクチャでは、リバース プロキシは、IdP を使用してクライアント認証セッションを作成してから、Tableau Server への要求をプロキシするように構成されています。このプロセスを事前認証フェーズと呼びます。リバース プロキシは、認証されたクライアント セッションのみを Tableau Server にリダイレクトします。Tableau Server はセッションを作成し、セッションの認証を IdP と確認してから、クライアント要求を返します。

次の図は、AuthN モジュールが構成された場合の事前認証と認証プロセスの詳細を示しています。リバース プロキシは、一般的なサードパーティ ソリューションでも、Tableau Server の独立したゲートウェイでもかまいません。

構成の概要

これは、Web 層を構成するプロセスの概要です。各ステップの後に接続を確認します。

1. 2 つのリバース プロキシを構成して、Tableau Server に HTTP アクセスを提供します。
2. プロキシ サーバー上でスティッキー セッションを使用して負荷分散ロジックを構成し、ゲートウェイ プロセスを実行している各 Tableau Server インスタンスに接続します。
3. インターネット ゲートウェイでスティッキーセッションを使用してアプリケーションの負荷分散を構成し、リーバス プロキシ サーバーに要求を転送します。
4. 外部 IdP を使用して認証を構成します。リバース プロキシ サーバーに認証ハンドラをインストールすることにより、SSO または SAML を構成できます。AuthN モジュールは、外部 IdP と Tableau 展開との間の認証ハンドシェイクを管理します。Tableau は IdP サービス プロバイダーとしても機能し、IdP を使用してユーザーを認証します。
5. この展開で、Tableau Desktop を使用して認証するには、クライアントで Tableau Desktop 2021.2.1 以降が実行されている必要があります。

Tableau Server の独立したゲートウェイを使用した Web 層構成の例

このトピックの残りの部分では、Tableau Server の独立したゲートウェイを使用して Web 層を実装するためのエンドツーエンドの手順を、AWS 参照アーキテクチャの例で説明します。リバース プロキシとして Apache を使用する設定例については、「付録 - Apache の展開例を使用した Web 層」を参照してください。

この構成例には、次のコンポーネントが含まれています。

• AWS アプリケーション ロード バランサー
• Tableau Server の独立したゲートウェイ
• Mellon 認証モジュール
• Okta IdP
• SAML 認証

注: このセクションに示されている Web 層の構成例には、サードパーティーのソフトウェアとサービスを展開するための詳細な手順が含まれています。Web 層のシナリオを有効にする手順や文書の検証には最善を尽くしていますが、サードパーティーのソフトウェアが変更される場合や、シナリオがここで説明されている参照アーキテクチャと異なっている場合があります。正式な構成の詳細情報とサポートについては、サードパーティーのドキュメントを参照してください。

このセクションの Linux の例では、RHEL のようなディストリビューションのコマンドを示します。具体的には、これらのコマンドは Amazon Linux 2 ディストリビューションで開発されたものです。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。

この例の Web 層の展開では、段階的な構成と検証の手順に従います。コア Web 層を構成するには、次のステップを実行して、Tableau とインターネット間の HTTP を有効にします。AWS アプリケーション ロード バランサーの背後でリバース プロキシと負荷分散を行うために、独立したゲートウェイを実行し、設定します。

1. 環境の準備
2. 独立したゲートウェイのインストール
3. 独立したゲートウェイ サーバーの構成
4. AWS アプリケーション ロード バランサーを構成します。

Web 層を設定して Tableau との接続を確認したら、外部プロバイダーを使用して認証を構成します。

環境の準備

独立したゲートウェイを展開する前に、次のタスクを完了してください。

1. AWS セキュリティ グループの変更。独立したゲートウェイのハウスキーピングを行う、Private セキュリティ グループからのインバウンド通信 (TCP 21319) を許可するように、Public セキュリティ グループを設定します。

2. 「パート 4 - Tableau Server のインストールと構成」で説明されているように、バージョン 22.1.1 (またはそれ以降) を 4 ノードの Tableau Server クラスタにインストールします。

3. 「ホスト コンピューターを構成する」で説明されているように、パブリック セキュリティ グループに 2 つのプロキシ EC2 インスタンスを構成します。

独立したゲートウェイのインストール

Tableau Server の独立したゲートウェイには、Advanced Management ライセンスが必要です。

Tableau Server の独立したゲートウェイは、.rpm パッケージをインストールして実行し、初期状態を設定することにより導入します。このガイドの手順は、参照アーキテクチャに導入するための規範的なガイダンスです。

導入環境が参照アーキテクチャと異なる場合は、Tableau Server のコア ドキュメントである「独立したゲートウェイを使用した Tableau Server のインストール (Linux(新しいウィンドウでリンクが開く))」を参照してください。

重要: 独立したゲートウェイを構成する作業は、エラーが発生しやすいプロセスです。独立したゲートウェイ サーバーの 2 つのインスタンス間で構成の問題をトラブルシューティングすることは非常に困難です。このため、独立したゲートウェイ サーバーは一度に 1 つ構成することをお勧めします。最初のサーバーを構成した後、機能を確認してから、2 つ目の独立したゲートウェイ サーバーを構成します。

独立したゲートウェイの各サーバーは別々に設定しますが、Public セキュリティ グループにインストールした両方の EC2 インスタンスで次のインストール手順を実行します。 

1. アップデートを実行して、Linux OS に最新の修正を適用します。

   sudo yum update

2. Apache がインストールされている場合は、Apache を削除します。

    sudo yum remove httpd

3. バージョン 2022.1.1 以降の独立したゲートウェイのインストール パッケージを Tableau ダウンロード ページ(新しいウィンドウでリンクが開く)から、Tableau Server を実行するホスト コンピューターにコピーします。

   たとえば、Linux RHEL のようなオペレーティング システムを実行しているコンピューターでは、次のコマンドを実行します。

   wget https://downloads.tableau.com/esdalt/2022<version>/tableau-server-tsig-<version>.x86_64.rpm

4. インストール プログラムを実行します。たとえば、Linux RHEL のようなオペレーティング システムでは、次のコマンドを実行します。

   sudo yum install <tableau-tsig-version>.x86_64.rpm

5. /opt/tableau/tableau_tsig/packages/scripts.<version_code>/ ディレクトリに変更し、そのディレクトリにあるスクリプト initialize-tsig を実行します。--accepteula フラグに加えて、Tableau Server デプロイメントを実行しているサブネットの IP 範囲を含める必要があります。-c オプションを使用して IP 範囲を指定します。AWS サブネット (例) を指定したコマンドの例を次に示します。

   sudo ./initialize-tsig --accepteula -c "ip 10.0.30.0/24 10.0.31.0/24"

6. 初期化が完了したら、tsighk-auth.conf ファイルを開き、認証シークレットをファイルにコピーします。バックエンドの Tableau Server を構成するときに、独立したゲートウェイのインスタンスごとに次のコードを送信する必要があります。

   sudo less /var/opt/tableau/tableau_tsig/config/tsighk-auth.conf

7. 独立したゲートウェイの両方のインスタンスで前の手順を実行した後、tsig.json 構成ファイルを準備します。構成ファイルは、「independentGateways」(独立したゲートウェイ) 配列で構成されています。配列では、独立したゲートウェイのインスタンスに対する各接続の詳細を定義する構成オブジェクトを保持します。

   次の JSON をコピーして、ご利用の導入環境に応じてカスタマイズします。この例は、サンプルの AWS 参照アーキテクチャ用のファイルを示しています。

   以下のサンプル JSON ファイルには、1 つの独立したゲートウェイの接続情報のみが含まれています。プロセスの後半で、2 つ目の独立したゲートウェイ サーバーの接続情報を含めます。

   この後の手順のために、ファイルを tsig.json という名前を付けて保存します。

   {
   "independentGateways": [
    {
    	"id": "ip-10-0-1-169.ec2.internal",
    	"host": "ip-10-0-1-169.ec2.internal",
    	"port": "21319",
    	"protocol" : "http",
    	"authsecret": "13660-27118-29070-25482-9518-22453"
    	}]
    }

   • "id" - 独立したゲートウェイを実行している AWS EC2 インスタンスのプライベート DNS の名前。
   • "host" - "id" と同じ。
   • "port" - ハウスキーピングポート。デフォルトでは "21319"。
   • "protocol" - クライアント トラフィックのプロトコル。初期設定ではこれを http のままにしておきます。
   • "authsecret" - 前の手順でコピーしたシークレット。

独立したゲートウェイ: 直接接続とリレー接続

先に進む前に、ご利用の導入環境で設定する接続方式 (直接接続またはリレー接続) を決定する必要があります。ここでは、各オプションについて、関連する意思決定のデータ ポイントとともに簡単に説明します。

リレー接続: クライアント通信を単一のポートで Tableau Server のゲートウェイ プロセスに中継するように独立したゲートウェイを構成することができます。この通信をリレー接続と呼びます。

• 中継プロセスにより、独立したゲートウェイからバックエンドの Tableau Server ゲートウェイ プロセスへの余分なホップが発生します。余分なホップのために、パフォーマンスは直接接続の構成と比較して低下します。
• TLS は、リレー モードでサポートされています。リレー モードでのすべての通信は単一のプロトコル (HTTP または HTTPS) に制限されているため、TLS で暗号化および認証できます。

直接接続: 独立したゲートウェイは、複数のポートを介してバックエンドの Tableau Server プロセスと直接通信できます。この通信を直接接続と呼びます。

• バックエンドの Tableau Server に直接接続されるため、クライアントのパフォーマンスはリレー接続オプションと比較して大幅に向上します。
• 独立したゲートウェイから Tableau Server コンピューターへの直接プロセス通信には、パブリック サブネットからプライベート サブネットに 16 個以上のポートを開く必要があります。
• TLS は、独立したゲートウェイから Tableau Server へのプロセスではまだサポートされていません。

検証: 基本トポロジ構成

http://<gateway-public-IP-address> をブラウザーに表示すると、Tableau Server の管理ページにアクセスできます。

Tableau Server サインイン ページが読み込まれない場合、または Tableau Server が起動しない場合は、次のトラブルシューティング ステップに従ってください。

ネットワーク: 

• Tableau Server ノード 1 から wget コマンド (wget http://<独立したゲートウェイの内部 IP アドレス>:21319) を実行して、Tableau の展開と独立したゲートウェイ インスタンスの間の接続を確認します。このコマンドの例は次のとおりです。

   wget http://ip-10-0-1-38:21319

  接続が拒否されるか、失敗する場合は、独立したゲートウェイのハウスキーピングを行う、プライベート セキュリティ グループからのトラフィック (TCP 21319) を許可するようにパブリック セキュリティ グループが構成されていることを確認します。

  セキュリティ グループが正しく構成されている場合は、独立したゲートウェイの初期化中に正しい IP アドレスまたは IP 範囲を指定したことを確認します。/etc/opt/tableau/tableau_tsig/environment.bash にある environment.bash ファイルの構成を表示して変更できます。このファイルに変更を加えた場合は、以下の説明に従って、tsig-http サービスを再起動します。

プロキシ ホスト 1 で次の手順を実行します。

1. httpd.conf ファイルを独立したゲートウェイのスタブ ファイルで上書きします。

   cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf

2. 最初のトラブルシューティング手順として、tsig-httpd を再起動します。

   sudo su - tableau-tsig
   systemctl --user restart tsig-httpd
   exit

Tableau ノード 1 で次の手順を実行します。

• tsig.json ファイルをもう一度チェックします。エラーを見つけた場合は、修正してから tsm topology external-services gateway update -c tsig.json を実行します。
• 直接接続を実行している場合は、proxy_targets.csv にリストされている TCP ポートが、パブリック セキュリティ グループからプライベート セキュリティ グループへの入力ポートとして構成されていることを確認してください。

AWS アプリケーション ロード バランサーの構成

パブリック Tableau URL で DNS を更新

AWS ロード バランサーの説明にあるドメイン DNS ゾーン名を使用して、DNS に CNAME 値を作成します。URL (tableau.example.com) へのトラフィックは、AWS パブリック DNS 名に送信する必要があります。

接続の確認

DNS の更新が完了すると、パブリック URL (たとえば、https://tableau.example.com) を入力して、Tableau Server のサインイン ページに移動できるようになります。

認証構成の例: 外部 IdP を使用した SAML

次の例では、AWS 参照アーキテクチャで実行されている Tableau の展開のために、Okta IdP と Mellon 認証モジュールを使用して SAML の設定と構成を行う方法について説明します。

この例は前のセクションからの抜粋であり、独立したゲートウェイを一度に 1 つ構成することを前提としています。

この例では、 HTTP を介した Tableau Server と Independent Gateway を設定する方法を説明します。Okta は HTTPS を介して AWS ロード バランサーに要求を送信しますが、すべての内部トラフィックは HTTP を介して伝送されます。このシナリオ用に構成する場合は、URL 文字列を設定するときに HTTP プロトコルと HTTPS プロトコルに注意してください。

この例では、独立したゲートウェイ サーバー上の事前認証サービス プロバイダー モジュールとして Mellon を使用しています。この構成により、認証されたトラフィックのみが Tableau Server に接続されます。Tableau Server は、Okta IdP を使用したサービス プロバイダーとしても機能します。したがって、2 つの IdP アプリケーションを構成する必要があります。1 つは Mellon サービス プロバイダー用で、もう 1 つは Tableau サービス プロバイダー用です。

Mellon を事前認証用にインストール

この例では、人気のあるオープン ソース モジュールである mod_auth_mellon を使用しています。一部の Linux ディストリビューションでは、廃止された mod_auth_mellon バージョンを古いリポジトリからパッケージ化しています。これらの廃止されたバージョンには、未知のセキュリティの脆弱性や機能上の問題が含まれている可能性があります。mod_auth_mellon を使用する場合は、現在のバージョンを使用していることを確認してください。

mod_auth_mellon モジュールはサードパーティ製ソフトウェアです。このシナリオを有効にする手順や文書の検証には最善を尽くしていますが、サードパーティー製ソフトウェアが変更される場合や、シナリオがここで説明されている参照アーキテクチャと異なっている場合があります。正式な構成の詳細情報とサポートについては、サードパーティーのドキュメントを参照してください。

1. 独立したゲートウェイを実行しているアクティブな EC2 インスタンスで、最新バージョンの Mellon 認証モジュールをインストールします。

2. /etc/mellon ディレクトリを作成します。

   sudo mkdir /etc/mellon

Mellon を事前認証モジュールとして構成

この手順を、独立したゲートウェイの最初のインスタンスで実行します。

Okta 構成から作成した pre-auth_idp_metadata.xml ファイルのコピーがある必要があります。

1. ディレクトリを変更します。

   cd /etc/mellon

2. サービス プロバイダーのメタデータを作成します。スクリプト mellon_create_metadata.sh を実行します。コマンドには、組織のエンティティ ID と戻り URL を含める必要があります。

   戻り URL は、Okta では シングル サインオン URL と呼ばれます。戻り URL のパスの最後の要素は、この手順の後半で説明する mellon.conf 構成ファイルの中で MellonEndpointPath と呼ばれます。この例では、エンドポイント パスとして sso を指定します。

   例:

   sudo /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh https://tableau.example.com "https://tableau.example.com/sso"

   スクリプトが、サービス プロバイダーの証明書、キー、およびメタデータ ファイルを返します。

3. 読みやすくするために、mellon ディレクトリ内のサービス プロバイダー ファイルの名前を変更します。今後このドキュメントでは、これらのファイルを次の名前で参照します。

   sudo mv *.key mellon.key
   sudo mv *.cert mellon.cert
   sudo mv *.xml sp_metadata.xml
   

4. pre-auth_idp_metadata.xml ファイルを同じディレクトリにコピーします。

5. /etc/mellon ディレクトリ内のすべてのファイルの所有権と権限を変更します。

   sudo chown tableau-tsig mellon.key
   sudo chown tableau-tsig mellon.cert
   sudo chown tableau-tsig sp_metadata.xml
   sudo chown tableau-tsig pre-auth_idp_metadata.xml 
   sudo chmod +r * mellon.key
   sudo chmod +r * mellon.cert
   sudo chmod +r * sp_metadata.xml
   sudo chmod +r * pre-auth_idp_metadata.xml 

6. /etc/mellon/conf.d ディレクトリを作成します。

   sudo mkdir /etc/mellon/conf.d

7. global.conf ファイルを /etc/mellon/conf.d ディレクトリに作成します。

   以下のようにファイルの内容をコピーしますが、MellonCookieDomain をルート ドメイン名で更新します。たとえば、Tableau のドメイン名が tableau.example.com の場合、ルート ドメインとして example.com を入力します。

   <Location "/">
   AuthType Mellon
   MellonEnable auth
   Require valid-user
   MellonCookieDomain <root domain>
   MellonSPPrivateKeyFile /etc/mellon/mellon.key
   MellonSPCertFile /etc/mellon/mellon.cert
   MellonSPMetadataFile /etc/mellon/sp_metadata.xml
   MellonIdPMetadataFile /etc/mellon/pre-auth_idp_metadata.xml
   MellonEndpointPath /sso
   </Location>
   
   <Location "/tsighk">
   MellonEnable Off
   </Location>

8. mellonmod.conf ファイルを /etc/mellon/conf.d ディレクトリに作成します。

   このファイルは、mod_auth_mellon.so ファイルの場所を指定する単一のディレクティブを保持します。この例の場所は、ファイルのデフォルトの場所です。ファイルがこの場所にあることを確認するか、このディレクティブのパスを変更して、mod_auth_mellon.so の実際の場所と一致させます。

   LoadModule auth_mellon_module /usr/lib64/httpd/modules/mod_auth_mellon.so

Okta で Tableau Server アプリケーションを作成

Tableau Server で認証モジュールを設定する

Tableau Server ノード 1 で以下のコマンドを実行します。これらのコマンドは、リモートの独立したゲートウェイ コンピューター上の Mellon 構成ファイルに対してファイルの場所を指定します。これらのコマンドで指定したファイル パスが、リモートの独立したゲートウェイ コンピューター上のパスとファイルの場所にマッピングされていることをもう一度チェックします。

tsm configuration set -k gateway.tsig.authn_module_block -v "/etc/mellon/conf.d/mellonmod.conf" --force-keys
tsm configuration set -k gateway.tsig.authn_global_block -v "/etc/mellon/conf.d/global.conf" --force-keys

ダウンタイムを減らすために、次のセクションで説明するように、SAML を有効にするまで変更を適用しないでください。

IdP 用の Tableau Server で SAML を有効化

tsig-httpd サービスを再起動する

Tableau Server の展開で変更を適用したら、Tableau Server の独立したゲートウェイ コンピューターに再度サインインし、次のコマンドを実行して、tsig-httpd サービスを再起動します。

sudo su - tableau-tsig
systemctl --user restart tsig-httpd
exit

SAML 機能の検証

エンドツーエンドの SAML 機能を検証するには、この手順の最初に作成した Tableau 管理者アカウントからパブリック URL (https://tableau.example.com など) を使用して Tableau Server にサインインします。

TSM が起動しない場合 (「ゲートウェイ エラー」)、または接続しようとしたときにブラウザ エラーが発生する場合は、「Tableau Server の独立したゲートウェイのトラブルシューティング」を参照してください。

独立したゲートウェイの 2 つ目のインスタンスで認証モジュールを構成

独立したゲートウェイの最初のインスタンスを正常に構成したら、2 つ目のインスタンスをデプロイします。この例は、本トピックで説明する AWS / Mellon / Okta シナリオをインストールするための最終プロセスです。この手順では、このトピック (独立したゲートウェイのインストール) で前述したように、独立したゲートウェイが 2 つ目のインスタンスにすでにインストールされていることを前提としています。

2 つ目の独立したゲートウェイをデプロイするプロセスでは、次の手順が必要です。

1. 独立したゲートウェイの 2 つ目のインスタンスで Mellon 認証モジュールをインストールします。

   このトピックで前述したように Mellon 認証モジュールを構成しないでください。その代わり、以降の手順で説明しているように、構成のクローンを作成します。

2. 独立したゲートウェイの構成済み (最初の) インスタンスで次の手順を実行します。

   既存の Mellon 構成の tar コピーを取得します。この tar バックアップでは、すべてのディレクトリ階層と権限を保持しています。次のコマンドを実行します。

   cd /etc

   sudo tar -cvf mellon.tar mellon

   mellon.tar を、独立したゲートウェイの 2 つ目のインスタンスにコピーします。

3. 独立したゲートウェイの 2 つ目のインスタンスで、次の手順を実行します。

   tar ファイルを /etc ディレクトリの 2 目のインスタンスに抽出 (「解凍」) します。次のコマンドを実行します。

   cd /etc

   sudo tar -xvf mellon.tar

4. Tableau Server 展開のノード 1: 接続ファイル (tsig.json) を 2 つ目の独立したゲートウェイの接続情報を使用して更新します。このトピックで前述したように (Independent Gatewayのインストール)、認証キーを取得する必要があります。

   接続ファイルの例 (tsig.json) は次のとおりです。

   {
   "independentGateways": [
    {
      "id": "ip-10-0-1-169.ec2.internal",
      "host": "ip-10-0-1-169.ec2.internal",
      "port": "21319",
      "protocol" : "http",
      "authsecret": "13660-27118-29070-25482-9518-22453"
    },
    {
      "id": "ip-10-0-2-230.ec2.internal",
      "host": "ip-10-0-2-230.ec2.internal",
      "port": "21319",
      "protocol" : "http",
      "authsecret": "9055-27834-16487-27455-30409-7292"
    }]
    }

5. Tableau Server 展開のノード 1: 次のコマンドを実行して構成を更新します。

   tsm stop

   tsm topology external-services gateway update -c tsig.json
   

   tsm start

6. 独立したゲートウェイの両方のインスタンスで Tableau Server が起動しているときに、tsig-httpd プロセスを再起動します。

   sudo su - tableau-tsig

   systemctl --user restart tsig-httpd

   exit

7. AWS EC2 > ターゲット グループ: ターゲット グループを更新して、2 つ目の独立したゲートウェイのインスタンスを実行している EC2 インスタンスを含めます。

   作成したターゲット グループを選択し、[ターゲット] タブをクリックします。 

   • [編集] をクリックします。
   • 2 つ目の独立したゲートウェイ コンピューターの EC2 インスタンスを選択して [登録済みに追加] をクリックし、[保存] をクリックします。