# tableau Guides - Full Documentation [メイン コンテンツに進む](#main-content) # Tableau Cloud サイトの作成と設定 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 このガイドで説明している移行プロセスは、アカウント マネージャーと協力して Tableau ライセンスをサーバーからクラウドに移行することから始まります。移行前に Tableau Cloud をテストしたい場合は、いつでも[Tableau Cloud を試用](https://www.tableau.com/ja-jp/products/trial)できます。 ## ステップ 1: Tableau アカウント マネージャーと協力してライセンスを移行する 移行の最初のステップは、アカウント マネージャーと協力してライセンスをサーバーからクラウドに移行することです。これを実施すると、両方の製品に 60 日間アクセスできます。ユーザーが 100 人以下のお客様のほとんどは、この移行プロセスを 1 週間以内に実施するため、移行時に両方の製品にアクセスする十分な時間があるはずです。さらに時間が必要な場合は、アカウント マネージャーにご相談ください。 ## ステップ 2: 追加の Tableau Cloud サイトを作成する Tableau Server で複数のサイトを作成している場合は、[Tableau Coud Manager](https://help.tableau.com/current/online/ja-jp/cloud_manager_intro.htm) を使用して Tableau Cloud で同等のサイトを作成することもできます。クラウド管理者として[サイトを追加](https://help.tableau.com/current/online/ja-jp/cloud_manager_sites.htm)すると、コンテンツ環境を分離し、ユーザーとライセンスを管理し、パーミッションを制御することができます。作成できる Tableau Cloud サイトの数は、購入した Tableau エディションによって異なります。 追加のサイトを作成したら、サイトごとにこのトピックの残りの手順を続行します。 ## ステップ 3: 認証方法を指定する デフォルトの認証方法は、ユーザー名とパスワード (TableauID) です。TableauID ユーザーが Tableau Cloud へ安全にアクセスするには、多要素認証が必要です。また、多くの業界標準のシングル サインオン オプションもサポートしています。詳細については、「[認証](https://help.tableau.com/current/online/ja-jp/security_auth.htm)」を参照して、組織に最も適した認証方法を判断してください。 ## ステップ 4: サイトに慣れる [サイト設定](https://help.tableau.com/current/online/ja-jp/sites_add.htm)を確認し、組織のニーズに合わせて適切に設定されていることを確認します。 ## ステップ 5: データ接続を設定する Tableau Cloud がデータに接続する方法は、データが保存されている場所によって異なります。それぞれの方法には異なる準備が必要な場合があり、以下に説明します。適切なオプションがわからない場合は、アカウント マネージャーにご相談ください。 ### 一般に利用できるクラウド データ 一般に利用できるクラウド データには、Google ドライブ、Dropbox、OneDrive、Snowflake などがあります。 接続がデータベースの場合、Tableau Cloud でクエリを実行できるように有効化する必要がある場合があります。接続を有効化するには、「[Tableau Cloud にパブリッシュされたクラウド データへのアクセスの承認](https://help.tableau.com/current/pro/desktop/ja-jp/publish_tableau_online_ip_authorization.htm)」を参照してください。 Excel や .csv ファイルなどのフラット ファイルの場合は、Google ドライブ、Dropbox、OneDrive などのクラウド ストアにこれらのファイルを保存することをお勧めします。その後、Tableau Cloud からデータへの直接接続を有効にできます。それを選択できない場合は、ローカルに保存されたフラット ファイルへの接続を維持するように Tableau Bridge を設定する必要があります。 ### オンプレミス、ローカル ファイル、プライベート クラウド データ ローカル ファイル、プライベート クラウド データ、オンプレミス データは、たとえば、SQL Server、Oracle、ローカルの Excel ファイルなどです。 プライベート データの要件がある場合は、[Tableau Bridge](https://help.tableau.com/current/online/ja-jp/to_bridge_install.htm) をインストールして設定する必要があります。Tableau Bridge は、Tableau Cloud とファイアウォールの背後にあるデータとの間の安全な通信を提供します。データにアクセスできる別のコンピューターのファイアウォールの内側に Bridge をインストールします。「[Bridge クライアントについて](https://help.tableau.com/current/online/ja-jp/to_bridge_client.htm)」を参照してください。 オプション: ローカル ファイル (Excel、CSV など) の場合、Tableau Bridge を使用する代わりに、Google ドライブ、Dropbox、Onebox などのクラウド ストアに保存できます。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. **現在地:** Tableau Cloud サイト 00 を作成して設定する 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # Tableau Cloud の更新スケジュールの再作成 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 ## 抽出データ ソースの新しい更新スケジュールを確立する - 抽出データ ソースの場合、Tableau Cloud でパブリッシュ済みデータ ソースまたは埋め込みデータ ソースに移動します。\[抽出更新\]、\[新しい抽出更新\]、\[抽出スケジュールの選択\] の順に選択します。 Tableau Bridge を必要とするデータ ソースの場合、抽出更新を確立する前に、Bridge が接続用に設定されていることを確認します。「[プライベート クラウド データに Bridge を使用する](https://help.tableau.com/current/online/ja-jp/to_bridge_vpc.htm)」を参照してください。 ## Tableau Prep フローの新しい更新スケジュールの設定 スケジュール フローは、データ管理のお客様のみが利用できます。 - Tableau Prep フローの新しい更新スケジュールを設定するには、Tableau Cloud のフローに移動します。\[スケジュールされたタスク\]、\[新しいタスク\] の順に選択し、スケジュールを選択して設定します。リンクされたタスクに対しても同じことを行います。詳細については、[「フロー タスクのスケジュール設定」](https://help.tableau.com/current/online/ja-jp/prep_conductor_schedule_flow_task.htm)を参照してください。 Tableau Cloud では、フローのカスタム スケジュールはサポートされていません。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. **現在地**: Tableau Cloud の更新スケジュールの再作成 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # Tableau Cloud への残りのユーザーの追加 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 すべてのコンテンツを移行し、プロジェクト、グループ、パーミッションを設定したので、残りの (またはすべての) ユーザーを追加できます。 このトピックでは、サイト にユーザーを追加する方法について説明します。クラウド管理者は Tableau Cloud Manager を使用すると、複数のサイトにわたってユーザーを追加または削除し、サイト ロールを変更できます。詳細については、[「Tableau Cloud Manager でのユーザーの管理」](https://help.tableau.com/current/online/ja-jp/cloud_manager_users.htm)を参照してください。 ## ユーザーの追加 ユーザーを追加すると、すぐにコンテンツにアクセスできるようになります。ユーザーを追加する前に、「[移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm)」の手順に従ってください。 Tableau Cloud に移行する前に、ユーザー サイト ロールについて学習することもお勧めします。「[ユーザーのサイト ロールの設定](https://help.tableau.com/current/online/ja-jp/users_site_roles.htm)」を参照してください。 以下に示すように、ユーザーを手動で追加できます。多数のユーザーがいて、CSV ファイルを使用して一括インポートする場合は、「[ユーザーのインポート](https://help.tableau.com/current/online/ja-jp/users_import.htm)」を参照してください。 ### ユーザーを手動で追加する 1. Tableau Server サイトにサインインし、**\[ユーザー\]** を選択します。 2. \[ユーザー\] ページで \[ユーザーの追加\] をクリックしてから、\[Add Users by Username (ユーザー名ごとにユーザーを追加する)\] をクリックします。 ![](/tableau/next/ja-jp/guides/migration/ja-jp/Img/users_add_online.png) 3. インポートされたユーザーが Tableau Cloud にサインインするときに使用する認証方法を選択します。サイトで認証が設定されていない場合、インポートされたユーザーには MFA を使用した Tableau の認証方法が割り当てられます。 **注:** ユーザーの追加後、いつでも \[ユーザー\] ページに移動して認証タイプを変更できます。 4. **\[Enter usernames (ユーザー名の入力)\]** テキスト ボックスにユーザーのユーザー名 (メール アドレス形式の) を入力します。複数のユーザーを追加する場合は、各ユーザー名をセミコロンで区切ります。 たとえば、「_tdavis@example.com; jjohnson@example.com; hwilson@example.com_」のように入力します。 5. ドロップダウン リストからサイト ロールを選択して、追加するすべてのユーザーにサイト ロールを割り当てます。 サイト ロールの定義については、[「ユーザーのサイト ロールの設定」](https://help.tableau.com/current/online/ja-jp/users_site_roles.htm)を参照してください。 6. \[ユーザーの追加\] をクリックします。 新しいユーザーのユーザー名が既に tableau.com のアカウントに関連付けられている場合、ユーザーはこのアカウント用の既存のメール アドレスとパスワードを使用してサインインする必要があります。 新しいユーザーのユーザー名がまだ tableau.com のアカウントに関連付けられていない場合は、そのユーザーに姓名とパスワードの登録を求めるプロンプトが表示されます。 ユーザーがそれらの値を提供するまで、Tableau Server のユーザー リストのエントリには、ピリオドが前についた電子メール アドレスが表示されます。例: `.snguyen@example.com` ユーザーがサインインした後、エントリがフル ネームに更新されます。例: `Susan Nguyen` ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. **現在地**: Tableau Cloud へユーザーを追加する 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # Tableau Cloud 手動移行ガイド このガイドでは、Tableau Server 展開を Tableau Cloud に手動で移行する方法について説明します。一言で言えば、このガイドは、100 人未満のユーザーで Tableau Server を運用していて、完全に手動でのセルフサービス移行プロセスに抵抗がいない管理者に役立ちます。 ユーザー数が多く、データ要件がより複雑な場合は、[プロフェッショナル サービスや経験豊富な移行パートナー](https://www.tableau.com/ja-jp/solutions/tableau-migration)と連携して Tableau Cloud に移行するほうが利点があるかもしれません。さらに、このトピックには、移行を計画する方法についてのガイダンスも含まれています。 ただし、その前に、なぜ Tableau Cloud への移行が組織にとって賢明な動きであるかを確認しましょう。 ## 移行が理にかなっている理由 少人数のユーザー グループ向けに 1 台の Tableau Server を運用しているのであれば、Tableau Cloud に運用を移行すると時間と費用を確実に削減できます。Tableau Cloud へ移行することで簡単に得られるのは、私たちの多くにとって不足しがちな時間を節約することです。また、自分はデータ サイエンティストやデータ アナリストなのに、Tableau Server のインストールを予期せず実行していることに気付いたなら、移行して、データを扱うことに専念しましょう。 大きな組織ではどうなるでしょうか。組織のユーザー数が 100 人を超えている場合、コストと時間を大規模に節約することのメリットが間違いなく得られます。Tableau Cloud は大規模な組織に対応できるように構築されていますが、このガイドはそうではありません。大規模な組織の移行を検討している場合は、「[Tableau Cloud への移行](https://www.tableau.com/ja-jp/solutions/tableau-migration)」を確認してください。ここでは、プロフェッショナル サービスや経験豊富な移行パートナーとの連携について詳しく知ることができます。 多くの組織にとって、Tableau Cloud の方がより高速で信頼性が高く、Tableau Server の稼働を維持するために現在行っている煩わしさも少なくなります。サーバーのメジャー アップグレードはもちろんのこと、メンテナンス リリース アップデート (ご存知の通り、密かに行われる別の名のアップグレードのことです) さえも、もう対応する必要はありません。Tableau Cloud は、最新の機能を備えた最新リリースを常に実行しています。信頼性とパフォーマンスはサービスに組み込まれています。移行プロセスを終えると、Tableau Cloud で費やす時間は、ユーザーとデータの管理に向けることができます。それだけです。サービス エラーのトラブルシューティングを行ったり、ログを調べたり、再起動を繰り返したりすることはありません。 アカウント マネージャーと連携して、ユーザーをサポートするためのコストを把握してください。全体的なコストを評価するときは、ユーザーごとのライセンス費用という単一のメトリックだけでは、SAAS とサーバーのセルフホスティングを同一条件で比較することはできないことに注意してください。Tableau Server の管理に費やされる時間や、ハードウェアの更新やリースにかかる資本コストを含めない場合、この比較は特に不毛なものになります。クラウドで単一のサーバーを実行する年間コストは、年間 10,000 ドルを超える場合があります。もちろん、メンテナンス、定期的なアップデート、トラブルシューティングの人員コストも含めて分析する必要があります。 ### より深く掘り下げる - Tableau Cloud への移行に関する迅速で適切な評価については、ブログ投稿「[Should I Move My Analytics to Tableau Cloud?](https://www.tableau.com/ja-jp/blog/should-i-move-my-analytics-cloud)」 (分析を Tableau Clould に移行すべきか?) を参照してください。 - オンプレミスまたは独自のホスティングから Tableau Cloud に移行する利点の詳細については、GigaOm の調査記事「[CxO の意思決定の概要: SaaS ビジネス インテリジェンスのプラットフォーム](https://portal.gigaom.com/report/cxo-decision-brief-saas-business-intelligence-platforms)」(英語) を参照してください。 - 現実世界でのコスト削減とパフォーマンス向上を詳しく説明したケーススタディについては、[「Splunk の Tableau Cloud への移行により、サーバー管理者のオーバーヘッドが排除され、ダッシュボードのパフォーマンスが向上します」](https://www.tableau.com/solutions/customer/splunk-migrates-tableau-cloud-eliminates-server-admin-overhead)を参照してください。 ## 移行が理にかなわない場合 次のリストでは、移行する代わりに、Tableau Server の独自のインスタンスを管理し続けることが理にかなっているシナリオを説明します。Tableau Cloud では継続的な改善に取り組んでおり、これらのギャップに対処する新機能をリリースする際には、このリストを更新します。ただし、移行を決定する前に、Tableau Cloud が要件を満たしているかどうかを確認することが重要です。移行を進める前に、必ず要件を検証してください。 - **規制とデータの所在:** ビジネスは、規制 (FedRAMP、PCI など) やデータ所在の要件に準拠する必要がある領域で運営されているが、Tableau Cloud はまだ準拠していない場合。[現在のコンプライアンスのリストを確認](https://compliance.salesforce.com/ja/services/tableau-cloud)してください。新たな認証を取得した場合のために、随時再確認してください。 - **データ ソース:** 組織が依存しているデータ ソリューションが、Tableau Cloud と連携できない、Tableau Bridge でサポートされていない、または自分の責任範囲では互換性のある方法で抽出できない場合。このようなデータ ソースの例には、キューブ データ ソース、カスタム コネクタ、パッケージ化された Tableau コネクタ (.taco) ファイルなどがあります。次のトピック「[移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm)」では、サポートしているさまざまなデータ ソースと、Tableau Cloud で利用できるオプションについて説明します。無料の[「Tableau Cloud への移行に関する技術準備評価」](https://exchange.tableau.com/products/921)をダウンロードして、現在使用しているデータ ソースと、それらが Tableau Cloud でサポートされているかどうかを確認することもできます。 - **サイト容量:** 1 TB を超えるデータがある場合は、[「Tableau Cloud の Advanced Management」](https://help.tableau.com/current/online/ja-jp/itm_intro.htm)を参照してください。それ以外の場合は、[「Tableau Cloud サイトの容量」](https://help.tableau.com/current/online/ja-jp/to_site_capacity.htm)を確認して、必要な統合を最適化します。[「Tableau Cloud への移行に関する技術準備評価」](https://exchange.tableau.com/products/921)は、統合が必要なアセットを特定するのに役立ちます。 - **認証:** 外部 ID ストアの LDAP、Kerberos 認証、または Kerberos 委任認証が必要な場合。 - **データ管理:** Tableau Prep フローは Tableau Bridge ではサポートされていません。プライベート ネットワークの背後にあるデータに対して Tableau Prep フローを使用した自動データ更新が必要な場合は、「[Tableau Cloud でオンプレミス データを使用して Tableau Prep Conductor のフローを実行する方法](https://kb.tableau.com/articles/howto/how-to-run-tableau-prep-conductor-flows-with-on-premises-data-in-tableau-cloud?lang=ja-jp)」を参照してください。Python を使用する Tableau Prep フローも、Tableau Bridge ではサポートされていません。 ## 本ガイドの対象読者 このガイドは、Tableau Cloud への移行を実行する個人またはチームを対象としています。このガイドは、100 ユーザー以下の Tableau Server インストール用に設計されています。このガイドでは、組織を Tableau Server からフル機能の Tableau Cloud のサイトに 1 ～ 2 週間で移行するための段階的な手動プロセスについて説明します。 Tableau Cloud に移行して主要な管理機能 (ID/ユーザー、サイト設定、認証、データ接続など) を作成したら、コンテンツの移行の大部分は組織の作成者と分担できます。「作成者」とは、Creator ロールベースのライセンスを持つユーザーです。目的に応じて、あなた (管理者) または作成者がコンテンツを移行できます。そのために、作成者に紹介できる移行関連のコンテンツを用意しました。コンテンツを移行するユーザーは、Creators ライセンスと [Tableau Desktop](https://www.tableau.com/ja-jp/products/desktop) へのアクセス権を持っている必要があります。作成者が Tableau Prep のフローを移行する場合は、Tableau Prep Builder もインストールする必要があります。 ## 移行後 このガイドでは、Tableau Cloud プラットフォームをできる限りカバーするよう最善を尽くしますが、管理者がエンド ユーザーに代わって設定できない機能がいくつかあります。移行を完了した後、ユーザーはコンテンツを更新する必要があります。クラウド ネイティブの機能を使用する利点を活かして、Tableau Cloud で新たに再作成した方がよい機能もいくつかあります。 ### Tableau Cloud の機能の違い 前述したように、管理者の視点から見ると、Tableau Cloud の実行は、独自の Tableau Server を管理するよりもはるかに労力がかかりません。機能の違いをまとめたリストについては、Tableau Server ヘルプ トピック_「Tableau Server から Tableau Cloud への移行に関する技術的考慮事項_ ([Windows](https://help.tableau.com/current/server/ja-jp/migrate_server_to_cloud_overview.htm) | [Linux](https://help.tableau.com/current/server-linux/ja-jp/migrate_server_to_cloud_overview.htm))」を参照してください。以下に、最も一般的な項目をいくつか示します。 - Tableau Cloud では、管理者は _Tableau Server リポジトリ_ ([Windows](https://help.tableau.com/current/server/ja-jp/server_process_repository.htm) | [Linux](https://help.tableau.com/current/server-linux/ja-jp/server_process_repository.htm)) に直接アクセスできません。代わりに、[管理者インサイト](https://help.tableau.com/current/online/ja-jp/adminview_insights_manage.htm)を使用すると、現在のライセンスの状態やパフォーマンスなど、Tableau 環境で何が起こっているかを把握できます。 - ゲストでのアクセスは Tableau Cloud では使用できません。代わりに、[接続済みアプリケーション](https://help.tableau.com/current/online/ja-jp/connected_apps.htm)を使用してアクセスを拡大します。 - 完全なカスタム フォント機能はサポートされていませんが、公開コンテンツで使用できる Google Fonts のセットが用意されています。 - Tableau Cloud では、管理にテナントとサイトのモデルが使用されています。[Tableau Cloud Manager](https://help.tableau.com/current/online/ja-jp/cloud_manager_intro.htm) を使用すると、Tableau Server の場合と同様に、テナント上に複数のサイトを作成できます。既定では、最大 3 つの Tableau Cloud サイトを作成できます。この数量は、ご購入の Tableau エディションに応じて増加します。[Enterprise](https://help.tableau.com/current/online/ja-jp/to_tab_enterprise_features.htm) では最大 10 サイトまで、[Tableau+](https://help.tableau.com/current/online/ja-jp/to_tab_plus_features.htm) では最大 50 サイトまでです。 [「Tableau Cloud への移行に関する技術準備評価」](https://exchange.tableau.com/products/921)を実施して、Tableau Cloud に移行する前に対応が必要なユースケースがあるかどうかを確認します。 ### エンド ユーザーが実施する必要があるタスク 管理者がエンド ユーザーに代わって設定できない機能や、手動での再構成が必要な機能がいくつかあります。ユーザーに直接共有できるように、完全な一覧を「[エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm)」として別途用意しましたが、これらのタスクには次のものが含まれます。 - Webhook - ソリューションの更新の埋め込み - REST API スクリプトの更新 - 分析拡張機能の設定 ## バージョンの互換性  原則として、当社のドキュメントは Tableau Server の最近または現在のバージョンに基づいていますが、このガイドで説明されているプロセスはプログラム的または自動化された移行ではないため、古いバージョンの Tableau Server から Tableau Cloud に移行する場合の問題は想定していません。厳密に言えば、このガイドのプロセスは、管理上の設定に関しては「移行」というより「移植」に近いものです。 ## ライセンス発行 Tableau Cloud は、ロールベースのサブスクリプション ライセンスを使用します。Tableau Server は、ロールベースのサブスクリプション ライセンスと従来の価格モデルをサポートしています。別の (以前の) ライセンス モデルを使用している場合は、Tableau アカウント チームに連絡して、ライセンスをロールベースのサブスクリプションに変換してください。 ## 追加サポート この資料を読んだ後、自分で手動で移行するのではなく、専門家に任せたいと思うかもしれません。その場合は、[経験豊富な移行パートナー](https://www.tableau.com/ja-jp/solutions/tableau-migration#partners)に連絡して、Tableau Cloud への移行をどのように推進できるかご確認ください。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # エンドユーザーの移行チェックリスト これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 Tableau Cloud へようこそ。 Tableau 管理者が最近、Tableau Server 環境を、Tableau のフルマネージド型分析プラットフォームである [Tableau Cloud](https://online.tableau.com/) に移行しました。 移行作業の一環として、Tableau Cloud へのスムーズな移行を実現するために、以下の作業に数分の時間が必要です。以下の機能のいずれかを Tableau Server で使用していた場合は、それらを Tableau Cloud で再作成する必要があります。このリストで、再作成する必要がある機能を確認し、手順に従って再作成してください。 これらの事項を移行する間は、Tableau 管理者と協力して、Tableau Server と Tableau Cloud の両方にアクセスしてください。 - **URL アクション**: Tableau Server で発行した URL アクションは、Tableau Cloud の URL を指すように更新する必要があります。更新されたフィールド変数を使用することも可能です。「[URLアクション](https://help.tableau.com/current/pro/desktop/ja-jp/actions_url.htm)」を参照してください。 - **サブスクリプション**: Tableau Cloud サイトでビュー、ワークブック、フローをサブスクライブし直す必要があります。「[ビューまたはワークブックへのサブスクリプションの作成](https://help.tableau.com/current/online/ja-jp/subscribe_user.htm)」を参照してください。 - **カスタム ビュー**: カスタム ビューは、選択内容とフィルターが適用されたビューのコピーです。Tableau Cloud サイトでカスタム ビューを適用し直す必要があります。「[カスタム ビューの使用](https://help.tableau.com/current/pro/desktop/ja-jp/customview.htm)」を参照してください。 - **行レベルのセキュリティ**: ユーザー名とグループ名は移行中に変更される可能性があります。Tableau のデータ ポリシー、データ ソース、ワークブック内の行レベルのセキュリティ ソリューションでグループ名とユーザー名を使用していた場合は、移行後にそれらを更新する必要があります。 - **「データに聞く」レンズ**: Tableau Cloud で「データに聞く」レンズを設定し直す必要があります。「[特定の対象者に焦点を当てた「データに聞く」のレンズを作成する](https://help.tableau.com/current/pro/desktop/ja-jp/ask_data_lenses.htm)」を参照してください。 - **お気に入り**: お気に入りを作成し直す必要があります。埋め込みデータ ソースを除き、任意のタイプのコンテンツをお気に入りに追加できます。「[お気に入りとしてマークする](https://help.tableau.com/current/pro/desktop/ja-jp/favorites.htm)」を参照してください。 - **コレクション**: コレクションは、Tableau Cloud でユーザーが作成し直す必要があります。 - **ユーザー アカウント設定**: メール設定とユーザー インターフェース オプションを更新します。「[アカウント設定の管理](https://help.tableau.com/current/pro/desktop/ja-jp/useracct.htm)」を参照してください。 - **データ ソースの保存された認証資格情報**: 保存した認証資格情報を含むすべてのデータ ソースとフローを更新する必要があります。「[データ接続のために保存された認証資格情報の管理](https://help.tableau.com/current/pro/desktop/ja-jp/manage_stored_credentials.htm)」を参照してください。 - **Webhook** : Tableau Cloud で Webhook を作成し直す必要があります。「[Tableau Webhook](https://help.tableau.com/current/developer/webhooks/ja-jp/index.html)」を参照してください。 - **埋め込みソリューション**: Tableau Server のビューが他のアプリケーションに埋め込まれている場合、それらのソリューションは Tableau Cloud 構成を使用するように更新する必要があります。これには、コンテンツ アイテムの URL、web ページがアイテムと対話する方法、ビジュアライゼーションに対する認証が含まれますが、これらに限定されません。 - **ダッシュボードの拡張機能**: ユース ケースによっては、ダッシュボードの拡張機能を新しい Tableau Cloud 環境に適応させる必要がある場合があります。「[ダッシュボードの拡張機能](https://help.tableau.com/current/pro/desktop/ja-jp/dashboard_extensions.htm)」を参照してください。Tableau 管理者は、[Cloud サイトでダッシュボード拡張機能のサポートを設定する](https://help.tableau.com/current/online/ja-jp/dashboard_extensions_server.htm)必要がある場合があります。 - **データ管理**: 組織にデータ管理機能がある場合 (以前購入したデータ管理を使用するか、Tableau Enterprise を購入する)、データ品質に関する警告とフィールドの説明を更新する必要があります。「[仮想接続とデータ ポリシーについて](https://help.tableau.com/current/online/ja-jp/dm_vconn_overview.htm)」を参照してください。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. **現在位置**: ユーザー移行チェックリスト [メイン コンテンツに進む](#main-content) # ステップ 1: データへの接続 あなたは上司から会社の全体的な売上と収益性を調べ、改善が必要な重点エリアを特定するよう依頼されました。大量のデータがあっても、どこから手をつければよいかわからない場合があります。まず、Tableau Desktop Free Edition をダウンロードすることから始めます。 関連リソースとビデオについては、「[Tableau Desktop でのデータへの接続](https://www.tableau.com/ja-jp/learn/tutorials/on-demand/connecting-data-tableau-desktop?playlist=509089)」を参照してください。 ## Tableau Desktop を開いて開始する Tableau Desktop を開いて最初に目に入るのは、[スタート ページ](https://help.tableau.com/current/pro/desktop/ja-jp/environment_startpage.htm)です。ここでは、Tableau がデータにアクセスするために必要なコネクタを選択します。 ![Tableau スタート ページ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Connect1.png) スタート ページでは、さまざまなオプションが提供されており、そこから選択することができます。 **1.** **Tableau アイコン。**任意のページの左上隅にある ![Tableau ロゴのアイコン](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Connect2.png) をクリックすると、スタート ページと作成ワークスペースが切り替わります。 **2.** **\[接続**\] ペイン - Microsoft Excel、PDF、空間ファイルなどのファイル内のデータに接続します。 - Google Drive、Amazon Redshift、Oracle などのサーバーベースのプラットフォームにあるデータ、または Tableau Cloud や Tableau Server にパブリッシュされたデータ ソースに接続します。 - 以前に接続したことのあるデータ ソースに接続します。 Tableau は、さまざまな場所に保存された広範な種類のデータへの接続機能をサポートします。\[接続\] ペインには接続先として最も一般的な場所がリストされます。また、\[詳細\] リンクをクリックすると、その他のオプションが表示されます。データ ソースへの接続の詳細については、このチュートリアルの[「学習ライブラリ」](https://help.tableau.com/current/guides/get-started-tutorial/ja-jp/get-started-tutorial-next.htm)を参照してください。 **3.** クイック スタート **アクセラレーター**: 独自のデータに接続できる事前作成されたテンプレート。 **4.** クイック スタート **サンプル ワークブック**: Tableau Desktop に付属するサンプル ワークブック。 **5.** **オープン**: 最近開いたワークブック。 **6.** **ディスカバー**: その他のリソース。 \[接続\] ペインの \[保存されたデータ ソース\] で **\[サンプル - スーパーストア\]** をクリックして、サンプル データセットに接続します。「スーパーストア」には、架空の小売会社内で改善が必要な重点エリアの特定に使用できる、商品や顧客、売上などに関する情報が含まれています。 [\[Tableau Public のサンプル データ\]](https://public.tableau.com/app/learn/sample-data) ページにある「スーパーストア」のデータセットをダウンロードするには、Microsoft Excel コネクタを使用します。 ![サンプル - スーパーストア にリストされているスーパーストア](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Connect_Superstore.png) **\[サンプル - スーパーストア\]** を選択すると、画面は次のようになります。 ![空白のワークシート](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Connect4.png) 詳細: Tableau はデータにどのような処理を行うのでしょうか。 データに接続した後、Tableau は以下の処理を行います。 - 新しいワークシートを開きます。最初のビューを作成できる空白の状態です。 - 接続先のデータ ソースを表示します。複数のデータ ソースを使用している場合は、ここにそれらがすべてリストされます。 - データ ソースの列を左側の **\[データ\]** ペインに追加します。列はフィールドとして追加されます。 - データに対して、データ型 (日付、数値、文字列など) や役割 (ディメンションやメジャー) を自動的に割り当てます。(これらの用語については、後で詳しく説明します。) データの詳細を確認する場合は、左下隅の **\[データ ソース\]** ページを選択できます。ここでは、データの最初の 1,000 行を表示でき、一部の分析を好きなように実行できます。フィールドの並べ替えまたは非表示、フィールドを複数の列に分割する、列ヘッダーの名前変更などのすべての操作を、元のデータ ソースを変更せずに実行できます。Tableau 内の処理は Tableau 内に留まり、データは安全です。 詳細を確認するために **\[データ ソース\]** ページに移動したい場合は、**\[シート 1\]** のタブをクリックすると開始した場所に戻ります。 データ ソースページの詳細については、[「学習ライブラリ」](https://help.tableau.com/current/guides/get-started-tutorial/ja-jp/get-started-tutorial-next.htm)参照してください。 詳細: 自分のデータを準備します 自分のデータ ソースに接続すると、Tableau でデータ ソースに接続する前に、いくつかの準備作業を行う必要があります。これは、Tableau が操作するデータを正しく表示できるよう、データに関する推測を行うためです。 データの準備の詳細については、[「学習ライブラリ」](https://help.tableau.com/current/guides/get-started-tutorial/ja-jp/get-started-tutorial-next.htm)を参照してください。 [ステップ 2: ドラッグ アンド ドロップによる初期表示](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-drag.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 2: ドラッグ アンド ドロップによる初期表示 ## ビューの作成 あなたは改善のための重点エリアを特定することを決定しましたが、何から始めればよいのでしょうか。4 年分のデータを使用して、売上高データ全体を掘り下げ、何が見つかるかを確認してみましょう。最初に、シンプルなグラフを作成します。 関連リソースとビデオについては、「[Tableau Desktop での Workspace の操作](https://www.tableau.com/ja-jp/learn/tutorials/on-demand/navigating-workspace-tableau-desktop?playlist=509089)」を参照してください。 詳細: 本セクションの用語
用語 説明
集計と粒度

集計とは、行レベルの数量的なデータをより高いカテゴリにまとめたものです (売上の合計や利益の平均など)。Tableau はこれを自動で行うため、データを操作する詳細のレベルに分類できます。

粒度とは、データの詳しさを意味します。たとえば、日付には、日、月、年などの粒度があります。
ディメンションとメジャー

ディメンションは、名前や日付のように特性に関するデータです。既定では、Tableau は特性やカテゴリに関する情報が含まれているデータを、ディメンションとして自動的に分類します (例: テキスト値やブル値 (真/偽) が含まれるフィールド)。これらのフィールドは一般的に、"Customer Name (カスタマー名)" や "Order Date (注文日)" など、データの行の列見出しとして表示され、ビュー内で表示する詳細レベルも定義します。

メジャーは、数量に関する数値データです。既定では、Tableau はこの種類のフィールドをすべてメジャーとして処理します (売上トランザクション数や収益など)。メジャーとして分類されたデータは、指定したディメンションに基づいて集計できます。たとえば、地域別の売上合計などです。この場合、売上 はメジャー、合計 (または総計) は集計、地域 はディメンションです。
連続と不連続

連続フィールドには、有限の値を含めることができます。これには、特定の日付範囲や数量内の売上高などの値の範囲を使用できます。Tableau では、連続フィールドは緑色で表示されます。

不連続フィールドには国、週、カスタマー名などの有限の値を含めることができます。Tableau では、不連続フィールドは青色で表示されます。
**ディメンションとメジャーの詳細について**は、[学習ライブラリ](https://help.tableau.com/current/guides/get-started-tutorial/ja-jp/get-started-tutorial-next.htm)を参照してください。 詳細: Tableau ワークスペースのコントロールとエレメント このセクションでは、フィールドを \[列\] や \[行\] シェルフにドラッグし、\[マーク\] カードも操作します。以下の画像は、表示されるワークスペースのコントロールやエレメントをいくつか示しています。 ![ワークスペースの要素の概要](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Drag28.png)
要素 説明

A元に戻す

Tableau では、自由にデータを実験できます。[元に戻す] ボタンを押すと、いつでも最初の状態に戻ることができます。このボタンを使用すると、ワークブック内で実行した最後のアクションを元に戻すことができます。

元に戻す操作は何回でも使用でき、保存を行った後でも、ワークブックを最後に開いた時点まで戻ることができます。

B[データ] ペイン

ビューに含まれるデータ ソースの名前と、使用できるフィールドを表示します。フィールドは、ソースのテーブルに基づいて、またはフォルダーごとにグループ化できます。

ディメンションとメジャーの詳細については、「学習ライブラリ」を参照してください。

C and Dカードとシェルフ

カードは、Tableau で利用可能なさまざまなコントロールのコンテナーです。シェルフは、カード コントロールのタイプです。[データ] ペインから [列] または [行] シェルフにフィールドをドラッグすると、データはビューの軸に列や行として追加されます。

[データ] ペインから [マーク] カードにフィールドをドラッグすると、タイプ、色、サイズ、形状などのビジュアル プロパティをコントロールできます。このアクションの影響を受けるのはビューのマークのみです。軸は変更されません。

ディメンションとシェルフの詳細については、「学習ライブラリ」を参照してください。

Eカードの表示/非表示

必要なカードを誤って非表示にしてしまったことはありませんか? 大丈夫です。Tableau ワークスペースでは、ほとんどすべての構成要素をオンまたはオフにして、視覚化を作成する最大限の余地を提供します。

[ページ]、[フィルター] または [凡例] などのカードを表示または非表示にするには、ツール バーで [カードの表示/非表示]カード アイコンの表示/非表示 ボタンのドロップダウン矢印をクリックし、カードのチェック マークをオフまたはオンにします。

また、ペインの上右隅の [最小化][データ] および [アナリティクス] ペインの最小化 ボタンをクリックして [データ] および [アナリティクス] ペインをワークスペースの左下隅に折りたたむこともできます。もう一度ボタンをクリックし、ペインを以前の状態に戻します。
1. **\[データ\]** ペインから、**\[オーダー日\]** を **\[列\]** シェルフにドラッグします。 **注:** **\[列\]** シェルフに "Order Date (オーダー日)" をドラッグすると、データ セット内の各年に対して列が作成されます。各列の下には、Abc インジケーターがあります。これは、Excel スプレッドシートのように、テキスト データや数値データをここにドラッグできることを示します。"Sales (売上高)" をこのエリアにドラッグすると、Tableau によってクロス集計 (スプレッドシートのようなもの) が作成され、各年の合計売上高が表示されます。 2. **\[データ\]** ペインから、**\[売上\]** を **\[行\]** シェルフにドラッグします。 Tableau では、売上高を合計 (集計) でまとめ、次のグラフを生成します。各年の集計された合計売上高を注文日ごとに見ることができます。 ![\[列\] シェルフに "Order Date (オーダー日)" を使用し、\[行\] シェルフに "SUM(売上)" を使用する折れ線グラフ](Img/gs_Drag1.png) _時間 (この場合は "Order Date (オーダー日)") を含むビューを初めて作成すると、Tableau で折れ線グラフが自動的に生成されます。_ この線グラフでは、売上高が良く、長期間にわたって増加しているように見えることを示します。これはよい情報ですが、どの商品の売上高が最も多いか、および他の商品よりも売上高が多い商品があるかは不明確です。まだ始めたばかりですので、さらに探索し、他に何がわかるかを見ることにします。 詳細: オプションを探索します グラフのタイプをすばやく変更するには、**\[マーク\]** カードのドロップダウン メニューを選択します。 たとえば、面グラフの場合は、**\[面\]** を選択します。 ![\[マーク\] メニューにリストされるチャート タイプ](Img/gs_Drag2.png) Tableau では、さまざまなグラフ タイプ (マーク タイプ) がサポートされています。詳細については、[「学習ライブラリの」](https://help.tableau.com/current/guides/get-started-tutorial/ja-jp/get-started-tutorial-next.htm)**「マーク タイプの詳細」**を参照してください。 **注:** チュートリアルを続行する前に、グラフのタイプが **\[自動\]** に設定されていることを確認してください。 作業を確認します。動画「ビューの作成」をご覧ください _画像をクリックして再生する。_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## ビューの微調整 どの商品が売上高全体の原動力となっているかに対するインサイトを得るには、さらにデータを追加してみてください。最初に商品カテゴリーを追加して、売上高合計を異なる方向から調べます。 1. \[データ\] ペインから、**"Category (カテゴリー)"** を **\[列\]** シェルフにドラッグし、"YEAR(Order Date) (年 (発注日))" の右側にドロップします。\[カテゴリ\] フィールドを確認するには、\[製品\] の階層を展開する必要がある場合もあります。 ビューが棒グラフに更新されます。ビューに 2 つ目の不連続ディメンションを追加することで、データを長時間調べ続ける代わりに、データを不連続の塊に分類することができます。これにより棒グラフが作成され、商品カテゴリーごとの全売上高が年ごと表示されます。 ![\[行\] シェルフに "YEAR(Order Date) (年 (オーダー日))" とカテゴリーがあり、\[行\] シェルフに "SUM(売上)" がある棒グラフ](Img/gs_Drag4.png) 詳細: パースペクティブを変更します 棒グラフを縦ではなく横に表示するには、ツールバーで **\[Swap Rows and Columns (行と列の切り替え)\]** をクリックします。 **注:** 「はじめに」チュートリアルを続行する前に、このアクションを元に戻してください。 ![\[行と列の切り替え\] アイコンを強調表示する棒グラフ](Img/gs_Drag7.png) 詳細: 数値を表示します ビューにデータ ポイント情報を表示または追加できます。この例では、この情報はカテゴリー別の正確な合計売上高を示します。 ビュー内の各データ ポイント (マーク) に関する情報を表示するには、いずれかのバーをポイントし、ツールヒントを表示します。ツールヒントには、そのカテゴリーの合計売上高が表示されます。以下は、2025 年の「事務用品」カテゴリに関するツールヒントです。 ![2021 年の "Office Suplies (事務用品)" の売上を示すツールヒント](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Drag5.png) ビューにラベルなどのデータ ポイント情報を追加するには、ツール バーの **\[マーク ラベルの表示\]** をクリックします。以下に、各カテゴリーと年に対する合計売上高を示します。 **注:** 「はじめに」チュートリアルを続行する前に、このアクションを元に戻してください。 ![\[マーク ラベルの表示\] アイコンを強調表示する棒グラフ](Img/gs_Drag6.png) ビューはカテゴリー別 (家具、事務用品、テクノロジーなど) に売上高を表示します。興味深いインサイトが明らかになりました。 このビューからは、2025 年は事務用品の売上が非常に好調であったものの、"Furniture (家具)" の売上が "Office Supplies (事務用品)" の売上よりも急速に増加していることがわかります。事務用品の代わりに家具を重点的に販売するように会社に勧めることができるかもしれません。会社はこれらのカテゴリのさまざまな商品を販売しているため、会社に推薦する前に、より多くの情報が必要になります。 この質問に答えるために、商品をサブカテゴリ別に調べてどのアイテムがよく売れるかを見ることにします。たとえば、"Furniture (家具)" のカテゴリでは、本棚、椅子、調度品、テーブルなどの詳細を確認します。このデータを調べることは、売上高や、その後の全体的な収益性に対するインサイトを得るのに役立つ可能性があります。そのため、サブカテゴリーを棒グラフに追加します。 1. **"Sub-Category (サブカテゴリー)"** をダブルクリックするか、**\[列\]** シェルフにドラッグします。 **注:** フィールドはドラッグ アンド ドロップまたはダブルクリックでビューに追加できますが、注意が必要です。データは Tableau が推測する場所に追加されるため、期待した場所に配置されない場合があります。\[元に戻す\] をクリックすれば、いつでもフィールドを削除できます。または Tableau が配置したエリアの外にドラッグして、最初からやり直することができます。 サブカテゴリーは、もう 1 つの不連続フィールドです。ビューの一番下にもう 1 つのヘッダーが作成され、各カテゴリー (68 マーク) ごとの棒を、カテゴリーおよび年別に分類して表示します。 ![\[列\] シェルフに "Order Date (オーダー日)"、カテゴリー、サブカテゴリーを表示し、\[行\] シェルフに "SUM(売上)" を表示する棒グラフ](Img/gs_Drag9.png) ある程度のところまで進めましたが、視覚的に並べ替えるデータが多数あります。次のセクションでは、色やフィルターなど追加して特定の結果に焦点を当てる方法について学習します。 詳細: 異なるビューを使用して商品売上高を比較します 売上高全体に占める商品の割合をカテゴリー別に表示するため、Tableau では別のオプションを提供しています。 **"Sub-Category (サブカテゴリー)"** を \[マーク\] カードの **\[色\]** にドラッグすると、積み上げ棒グラフが作成され、各サブカテゴリーを一意の色で識別する追加のマークが付きます。Tableau では、サブカテゴリー値の右側に凡例カードが自動的に表示されます。 **注:** 「はじめに」チュートリアルを続行する前に、このアクションを元に戻してください。 ![\[列\] シェルフに "Order Date (オーダー日)" とカテゴリー、\[行\] シェルフに "SUM(売上)"、\[マーク\] カードの \[色\] にサブカテゴリーを示す棒グラフ](Img/gs_Drag8.png) これにより、合計売上高に占める各製品の売上がカテゴリーおよび年ごとにただちに表示され、売上高に占める割合が高いものと低いものが一目でわかります。 \[サブカテゴリー\] は "Sales (売上高)" 軸上の位置ではなく、凡例にリストされている順序で積み上げ棒グラフに表示されます。 例えば、上記のビューでは、「家具」の各バーの最上部に「本棚」が表示されています。これは、凡例において「本棚」が「いす」、「調度品」、「テーブル」よりも上にリストされているためです。サブカテゴリーは凡例に表示されているため、意味を成すように任意の場所に移動してデータを調べることができます。 実行する分析の種類によって、積み上げ棒グラフが適している場合も、そうでない場合もあります。 作業を確認します。動画「ビューの微調整」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## ステップのサマリー このステップでは、データを知るための方法と、インサイトを得るための質問の始め方について説明します。以下の操作方法を学びました。 - 自分の目的に合ったグラフをビューで作成する。 - フィールドを追加し、ビューの正しい詳細のレベルを取得する。 これで、結果に焦点を当てて、より具体的な対象エリアを特定する準備が整いました。次のセクションでは、データを視覚的に探索できるよう、フィルターや色を使用する方法について学習します。 [ステップ 3: 結果に焦点を当てる](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-focus.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 3: 結果に焦点を当てる ここまで、商品売上高のビューを作成し、カテゴリー別およびサブカテゴリー別に分類しました。ある程度のところまで進めましたが、まだ並べ替えるデータが多数あります。興味深いデータ ポイントを簡単に探し、特定の結果に焦点を当てる必要があります。Tableau には、そのための優れたオプションが多数あります。 フィルターと色を追加することで、興味深い詳細に焦点を当てることができます。データに焦点を追加した後、他の Tableau Desktop 機能の使用を開始してそのデータを操作できます。 ## フィルターをビューに適用する フィルターを使用して、さまざまな値をビューに含めたり、ビューから除外することができます。この例では、ワークシートに 2 つのシンプルなフィルターを追加し、商品売上高を、特定の年のサブカテゴリー別に見やすくします。 1. **\[データ\]** ペインで、**\[Order Date (注文日)\]** を右クリックし、**\[フィルターの表示\]** を選択します。 2. **サブカテゴリー** フィールドで上記の手順を繰り返します。 フィルターは、選択した順序でビューの右側に追加されます。フィルターは、カードのタイプです。フィルターをクリックし、ビューの別の場所までドラッグすることでキャンバス上を移動できます。フィルターをドラッグすると、線が表示され、フィルターを移動するためにドロップ可能な場所が示されます。 **注**: 「はじめに」チュートリアルでは、フィルター カードの既定の位置を使用します。 **フィルターリングの詳細について**は、ラーニング ライブラリ (トップ メニュー) を参照してください。 ![サブカテゴリーと "Order Date (オーダー日)" のフィルターを含む棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Drag10.png) 作業を確認します。動画「フィルターをビューに適用する」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## ビューに色を追加する フィルターを追加すると、このデータ全体で並べ替えることはできますが、青ばかりになってしまいます。これを何とかしなくてはいけません。 この時点では、さまざまな商品の合計売上高が表示されています。ある製品は一貫して売上が低くく、ある製品は製品ラインの販売努力を減らすための良い候補であることがわかります。しかし、さまざまな製品の全体的な収益性はどうでしょうか? **"Profit (利益)"** を \[色\] にドラッグして結果を確認します。 **\[データ\]** ペインから **\[収益\]** を \[マーク\] カードの **\[色\]** へドラッグします。 "Profit (利益)"を \[色\] にドラッグすると、"Tables (テーブル)"、"Bookcases (本箱)"、"Machines (機械類)" の利益がマイナスになったことがわかります。新たなインサイトが明らかになりました。 ![\[列\] シェルフに "Order Date (オーダー日)"、カテゴリー、およびサブカテゴリー、\[行\] シェルフに "SUM(売上)"、\[マーク\] カードの \[色\] に "SUM(利益)" を示す棒グラフ](Img/gs_Dragcolor1.png) **注:** Tableau では、データには正の値と負の値の両方が含まれているため、色の凡例が自動的に追加され、分岐カラー パレットが割り当てられます。 詳細: 色の操作 色を追加することでビューを視覚的に強調し、興味深いデータが目立つようにすることができます。Tableau のビューでは既定のカラー パレットを使用して製品に色を割り当てていますが、カラー パレット以外も使用できます。好きな方を選択してください。 表示されている色以外を使用する場合は、色またはカラー パレットをいつでも変更できます。単純に \[マーク\] カードで **\[色\]** をクリックし、**\[色の編集\]** を選択します。開いた \[色の編集\] ダイアログ ボックスから別のカラー パレットを選択できます。 **注:** 「はじめに」チュートリアルでは、既定のカラー パレットを使用します。 ビュー内のデータによって、\[色の編集\] ダイアログ ボックスに分岐カラー パレットが表示される場合と、カテゴリー別カラー パレットが表示される場合があります。 分岐カラー パレットは、次の画像のようになります。分岐カラー パレットは一般的に、連続フィールドに割り当てられます。 ![\[色の編集\] メニューにリストされている分岐カラー パレット](Img/gs_Dragcolor2.png) 凡例を使用している場合、次の画像のようになります。カテゴリー別カラー パレットは一般的に、不連続フィールドに割り当てられます。 ![\[色の編集\] メニューにリストされているカテゴリー カラー パレット](Img/gs_Drag12.png) 作業を確認します。動画「ビューに色を追加する」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 重要なインサイトを見つける これまで学習したように、Tableau Desktop ではビューを構築しながらデータを探索できます。フィルターや色を追加することで、データをより効果的に視覚化し、問題を直ちに識別するのに役立ちます。 次の手順では、結論を導き出せるようにビューを操作します。 ビューを見ると、明らかにいくつかの不採算商品があることがわかります。次に、これらの製品が不採算であったかどうかを前年比で確認します。 次に、フィルターを使用してさらに詳しく調べます。 1. ビューの **"Sub-Category (サブカテゴリー)"** フィルター カードで、**"Bookcases (本箱)"**、**"Machines (機械類)"**、および **"Tables (テーブル)"** 以外のすべてのチェック ボックスをオフにします。 ![サブカテゴリーの利益と損失を示す分岐カラー パレットを使用した棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_FocusFilter1.png) これで、"Bookcases (本箱)" と "Machines (機械類)" で実際に利益を上げた年もあったことがわかります。しかし、最近、機械類の採算性が悪くなりました。重要な発見があったとはいえ、上司にアクション項目を提案するには、さらに多くの情報を収集する必要があります。 あなたは勘を頼りに、地域別にビューを分割することを決めます。 2. \[データ\] ペインから **\[行\]** シェルフへ **\[Region (地域)\]** をドラッグして、\[合計(売上)\] の左に配置します。 Tableau によって、地域別に分類された複数の軸が作成されます。 これで、各地域の商品別の売上高と収益性がわかります。地域をビューに追加してサブカテゴリ―をフィルタリングすると、"South (南部)" では他の地域に比べて機械類の総利益がマイナスになっていると報告されていることがわかります。隠れていたインサイトが見つかりました。 ![各地域の機械サブカテゴリーの収益性を示す棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Focus_MachineSpike.png) このビューは、これまでの作業を効果的に要約しています。**"Sub-Category (サブカテゴリー)"** フィルター カード (フィルターを変更した場合) で **\[すべて\]** を選択し、すべてのサブカテゴリーを再度表示してワークシートに名前を付け、タイトルを追加します。 6. ワークスペースの左下で **\[シート 1\]** をダブルクリックしてから、「**Sales by Product/Region**」(商品/地域別売上高) と入力します。 あなたは南部の分析に焦点を当てることにしましたが、作成したビューを失うことは望んでいません。Tableau Desktop でワークシートを複製し、中止したところから続行します。 7. ワークブックで **"Sales by Product/Region (商品/地域別売上高)"** シートを右クリックし、**\[複製\]** を選択します。 8. 複製したシートの名前を「**Sales in the South (南部の売上高)**」に変更します。 9. 新しいワークシートで、\[データ\] ペインから **\[フィルター\]** シェルフへ **\[Region (地域)\]** をドラッグして、ビューにフィルターとして追加します。 10. **\[地域をフィルター\]** ダイアログ ボックスで、"South (南部)" 以外のすべてのチェック ボックスをオフにし、**\[OK\]** をクリックします。 11. **\[行\]** シェルフの **\[地域\]** ピルを右クリックし、**\[ヘッダーの表示\]** のチェックを外します。 ビューが更新されて、次の画像のようになります。 ![南部のサブカテゴリーの収益性を示す棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_FocusSouth1.png) これで、南部の売上高の収益に焦点を当てることができます。機械類の売上が 2022 年と 2025 年にマイナスになったことがすぐにわかります。これは間違いなく調査が必要です。 4. **\[ファイル\]** > **\[名前を付けて保存\]** を選択して作業を保存します。ワークブックに「Regional Sales and Profits (地域別売上高と収益)」などの名前を付けます。 詳細: Tableau で保存済みワークブックを整理する方法 Tableau をインストールすると、**\[ドキュメント\]** > **\[マイ ドキュメント\]** > **\[マイ Tableau リポジトリ\]** の下にフォルダー ディレクトリが自動的に作成されます。\[マイ Tableau リポジトリ\] にはデータ ソース用の複数のフォルダー、保存済みワークブック、地理的データなどが含まれます。 **ワークブックを別の Tableau ファイル タイプで保存する方法の詳細については**、ラーニング ライブラリ (トップ メニュー) を参照してください。 作業を確認します。動画「重要なインサイトを見つける」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## ステップのサマリー このステップでは、データを操作しやすくするよう、フィルターや色を使用しました。また、データに関する重要な質問に回答するため、Tableau が提供する多数の機能についても学習しました。以下の操作方法を学びました。 - フィルターや色を適用し、最も関心を持っているデータのエリアに焦点を当てやすくする。 - Tableau が提供するツールを使用してグラフを操作する。 - ワークシートを複製して変更内容を保存し、作業内容を失わず別の方法でデータの探索を続行する。 Tableau Desktop でデータを探索することで、懸念となるエリアを特定しました。南部の売上高と収益が問題であることはわかっていますが、解決策はまだありません。これらの結果の原因となっている他の要因を調べる必要があります。次に、Tableau の別の主要な機能を活用し、地理的データを操作します。 [ステップ 4: データを地理的に調査する](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-explore.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 4: データを地理的に調査する 商品別の売上高と収益を数年にわたって確認できる、優れたビューを作りました。さらに、南部の商品売上高と収益性を調べた後、その地域のトレンドやパターンを探すことを決定します。 地理的データ (地域フィールドなど) には、マップ ビューを構築するオプションを使用できます。マップ ビューは、このような情報の表示や分析に優れています。外観も優れています。 この例では、Tableau は既に \[国\]、\[都道府県/州\]、\[市区町村\] および \[郵便番号\] フィールドに適切な地理的役割を割り当てています。これらの各フィールドに地理的データが含まれていると認識したためです。今すぐマップ ビューを作成して、作業に取り掛かることができます。 詳細: 地理的役割について紹介します Tableau では、州や市区町村名などの一般的な地理的データを多く認識します。Tableau はこれらのデータ型を認識すると、自動的に適切な地理的役割を割り当てるため、それらは地理的フィールドになります。 **\[データ\]** ペインの地理的フィールドの隣には、地球儀アイコン ![地理データ フィールドを識別する地球儀アイコン](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore16_24x13.png) があります。フィールドに地理的役割が割り当てられている場合、\[マーク\] カードの **\[詳細\]** にフィールドを追加すると、Tableau が自動的にマップ ビューを作成するように検出します。詳細については、後で説明します。 Tableau がデータを地理的データとして認識しない場合、各関連フィールドに手動で地理的役割を割り当てることができます。 さまざまな地理的役割を選択できます。 - 空港 - 市外局番 (米国) - CBSA/MSA (米国) - 市区町村 - 下院議員選挙区 (米国) - 国/地域 - 郡 - NUTS ヨーロッパ - 都道府県/州 - 郵便番号 ![フィールドに地理的役割を手動で割り当てるイメージ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore1.png) ## マップ ビューの作成 新しいワークシートで最初から始めます。 1. ワークスペース下部の **\[新しいワークシート\]** アイコンをクリックします。 ![新しいワークシート アイコンの強調表示](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_explore17.png) Tableau では前のワークシートを保持し、新しいワークシートを作成します。そのため、作業内容を失わずにデータの探索を続けることができます。 4. **\[データ\]** ペインで **\[都道府県/州\]** をダブルクリックし、\[マーク\] カードの **\[詳細\]** に追加します。 マップ ビューが表示されました。 ![カナダと米国本土のシンボルマップ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_explore3.png) 詳細: ダブルクリックして地理的フィールドを追加します フィールドをダブルクリックすると、それらをビューにすばやく追加できます。地理的フィールドをダブルクリックすると、それらは \[マーク\] カードの \[詳細\] に自動的に追加され、フィールドにリストされている各場所に対してマークの付いたマップ ビューが作成されます。 Tableau は州名が地理的データであると既に認識しており、**\[都道府県/州\]** のディメンションには 都道府県/州の地理的役割が割り当てられているため、Tableau はマップ ビューを自動的に作成します。 データソースには、隣接した米国本土の 48 州とカナダの各州ごとに 1 つのマークがあります。(データ ソースにはアラスカとハワイは含まれていないため、マッピングされません。) ビューに **\[国\]** フィールドも追加されました。これは、サンプル - スーパーストア の地理的フィールドが階層の一部であるために発生します。階層の上位レベルは、詳細レベルとして自動的に追加されます。 さらに、緯度および経度のフィールドが生成され、\[列\] および \[行\] シェルフに追加されます。これらは X および Y フィールドのようなものです。データ内の場所にはそれぞれ緯度と経度の値が割り当てられているため、これらはマップ ビューを作成する際には常に重要です。これらのフィールドは、Tableau によってデータの地理的フィールドから生成される場合があります。または、データに緯度と経度の独自の値が含まれている場合もあります。これについての詳細を知るためのリソースは、ラーニング ライブラリで見つけることができます。 これで、外観の良いマップで隣接する米国とカナダに焦点を当てましたが、確認する必要があるのは南部で何が起こっているのか、ということです。 13. **"Region (地域)"** を **\[フィルター\]** シェルフにドラッグしてから、フィルターで **"South (南部)"** のみに絞り込みます。マップ ビューは "South (南部)" 地域にズームし、そこには各州 (合計 11) のマークがあります。 次に、この地域のデータの詳細を確認します。まず、他のフィールドを \[マーク\] カードにドラッグします。 15. \[マーク\] カードの **\[色\]** に **"Sales (売上高)"** メジャーをドラッグします。 ![さまざまな色合いの青で色分けされた米国南部の 11 州の地図](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_explore2.png) ビューが自動的に更新されて塗りつぶしマップに変わります。各州の色は、合計売上高に基づいています。製品の売上の調査をしているので、売上を米ドルで表示する必要があります。**\[マーク\]** カードの **\[合計 (売上)\]** フィールドをクリックし、**\[書式設定\]** を選択します。数値には、**\[通貨\]** を選択します。 正の値 ("Sales (売上高)" など) を含む連続メジャーを \[マーク\] カードの \[色\] に追加すると、塗りつぶしマップは緑色になります。負の値には、オレンジ色が割り当てられます。 マップを青色にすることが必要な場合もあります。緑を希望する場合や、データが青で表すべきでない場合 (山火事や交通渋滞など) もあります。非常にわかりにくくなります。 カラー パレットは以前行ったように変更できます。 20. \[マーク\] カードで **\[色\]** をクリックし、**\[色の編集\]** を選択します。 この例では、どの州の売上高が多く、どの州の売上高が少ないかを確認します。 22. \[パレット\] ドロップダウン リストで **\[オレンジ - 青の分化\]** を選択し、ダイアログを閉じます。これにより、パフォーマンスが高い項目と低い項目をすばやく確認できます。 ビューが更新されて、次のように表示されます。 ![州の総売上に基づいたオレンジ - 青の分化のマップ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore5.png) お待ちください。オレンジが多すぎます。何が起こりましたか? データは正確であり、業績の低いものと高いものを_技術的_に比較することは可能ですが、本当にそれだけで良いのでしょうか。 これらの州では売上がそれほど良くないのでしょうか、またはフロリダに商品を購入する人が多いだけでしょうか? オレンジ色の州では、店舗の規模が小さかったり、店舗の数が少ないのかもしれません。または、青色に表示されている州の人口密度が高く、購入する人が多い可能性もあります。 いずれにしても、データが有用なストーリーを伝えているという確信が持てないため、上司にこのビューを見せることはできません。 29. ツール バーで、**\[元に戻す\]** アイコン ![左向き矢印アイコン。](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore22.png) をクリックし、青のビューに戻します。 まだ色の問題が残っています。すべてが素晴らしく見えます。そこが問題です。 一見、"Florida (フロリダ)" の実績が最も良いようです。このマークをポイントすると売上高の合計が 89,474 ドルであることがわかります。一方、サウス カロライナでは売上高はたった 8,482 ドルです。ただし、南部のいずれかの州で_利益_を上げたところはありますか? 32. この質問の答えが出るか確認するには、\[マーク\] カードの **\[色\]** に **"Profit (収益)"** をドラッグします。 ![州の総利益に基づいた青/オレンジ分岐のマップ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore6.png) さらに良くなりました。利益には正の値と負の値の両方が含まれていることが多いため、Tableau はオレンジ/青分岐カラー パレットを自動的に選択して、利益が黒字の州と赤字の州をすばやく表示します。 "Tennessee (テネシー)"、"North Carolina (ノース カロライナ)"、"Florida (フロリダ)" の売上高は問題ないように見えますが、収益がマイナスであることは明らかです。でもなぜでしょうか? この回答は次のステップで得られます。 作業を確認します。動画「マップ ビューの作成」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 [ステップ 5: ドリルダウンによる詳細表示](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-drilldown.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 5: ドリルダウンによる詳細表示 最後の手順で、"Tennessee (テネシー)"、"North Carolina (ノース カロライナ)"、"Florida (フロリダ)" が赤字収益であることがわかりました。理由を見つけるため、さらに掘り下げ、これらの 3 つの州だけに何が起こったかに注目します。 ## マップ ビューを中止した時点に移動する 最後の手順でご覧いただいたように、データを広く視覚化するにはマップが最適です。棒グラフは、核心に到達するのに役立ちます。これを行うため、別のワークシートを作成します。 1. **\[シート 3\]** をダブルクリックし、ワークシートに「**Profit Map**」(収益マップ) と名前を付けます。 2. ワークスペースの一番下にある **"Profit Map (収益マップ)"** を右クリックし、**\[複製\]** を選択します。新しいシートに「**Negative Profit Bar Chart (赤字収益棒グラフ)**」という名前を付けます。 3. "Negative Profit Bar Chart (赤字収益棒グラフ)" ワークシートで **\[表示形式\]** をクリックしてから、**\[横棒\]** を選択します。 \[表示形式\] はビューに追加したデータに基づき、異なるグラフのタイプをハイライトします。 **注:** いつでも、**\[表示形式\]** をもう一度クリックして折りたたみます。 ![\[表示形式\] メニューの横棒グラフのハイライト](Img/gs_Explore8.png) もう一度棒グラフが表示されます。 ![南部地域の州の利益を示す横棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore9.png) 7. 左側の横棒を複数選択するには、**テネシー**、**ノース カロライナ**、**フロリダ**の横棒全体でカーソルをクリックしてドラッグします。表示されたツールヒントで、これらの 3 つの州に焦点を当てるには、**\[選択したデータのみを保持\]** を選択します。 ![同時に選択された 3 つのバーを示す青いボックス](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore_click_and_drag.png) **注:** ハイライトされているバーのいずれかを右クリックし、**\[選択したデータのみを保持\]** を選択します。 "State (州)" の _"Inclusions (含める)"_ フィールドが \[フィルター\] シェルフに追加され、ビューから特定の州がフィルターされたことを示します。フィールド上の 2 つの円のアイコンは、このフィールドがセットであることを示しています。\[フィルター\] シェルフのフィールドを右クリックし、**\[フィルターの編集\]** を選択してこれを編集できます。 次に、これらの州の都市のデータを調べます。 9. **\[行\]** シェルフで、**"State (州)"** フィールドの横にある**プラス**アイコンをクリックし、"City (都市)" 詳細のレベルにドリルダウンします。 表示されている情報が多すぎるため、収益が最も赤字の都市が表示されるように、上位 N フィルターでビューをフィルターします。 作業を確認します。ステップ 1 から 5 を動画でご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 上位 N フィルターの作成 Tableau Desktop の \[上位 N フィルター\] を使用すると、ビューに表示されるマークの数を制限できます。この場合、\[上位 N フィルター\] を使用してパフォーマンスが低いものを絞り込みます。 1. \[データ\] ペインから、**\[フィルター\]** シェルフに **"City (都市)"** をドラッグします。 2. \[フィルター\] ダイアログ ボックスで、**\[上位\]** タブを選択してから、次の手順を実行します。 1. **\[フィールド別\]** をクリックします。 2. 業績が最も低い項目を明らかにするには、**\[一番上\]** ドロップダウンをクリックし、**\[一番下\]** を選択します。 3. データ セットのパフォーマンス下位 5 件を表示するには、テキスト ボックスに「**5**」と入力します。 Tableau Desktop は既に、ビューのフィールドに基づき、\[上位 N フィルター\] にフィールド (収益) と集計 (合計) を選択しています。これらの設定により、パフォーマンスが悪い都市下位 5 件のみを集計の合計別に表示します。 ![\[別\] フィールドを \[下位\] 5 に設定した、\[都市\] フィルター ダイアログ ボックスの \[上位\] タブ](Img/gs_Explore12.png) 6. **\[OK\]** をクリックします。 これは良い例です。しかし、利益が黒字のノースカロライナ州ジャクソンビルを含む 6 つの都市がビューにあります。利益の高い都市を除外するフィルターを作成したはずなのに、利益が黒字の都市がビューに表示されるのはなぜでしょうか。 ノース カロライナ州ジャクソンビルが含まれているのは、ビューに表示される最低の詳細レベルが市区町村であるためです。Tableau Desktop がノース カロライナ州ジャクソンビルとフロリダ州ジャクソンビルの違いを認識できるよう、次の詳細レベル (この例では郵便番号) を場所の階層にドリルダウンする必要があります。郵便番号を追加すると、フロリダ州ジャクソンビルを除外することなく、ノース カロライナ州ジャクソンビルを除外することができます。 1. \[行\] シェルフで、**"City (市区町村)"** の横にあるプラス アイコンをクリックし、"Postal Code (郵便番号)" の詳細レベルにドリルダウンします。 2. ノースカロライナ州ジャクソンビルの郵便番号である **28540** を右クリックし、**\[除外\]** を選択します。 \[フィルター\] シェルフに "Postal Code (郵便番号)" が追加され、"Postal Code (郵便番号)" フィールドの特定のメンバーがビューからフィルターされたことを示します。ビューから \[郵便番号\] フィールドを削除しても、フィルターは残ります。 4. **"Postal Code (郵便番号)"** を \[行\] シェルフの外にドラッグします。 ビューが更新されて、次のように表示されます。 ![最も収益性の低い南部の 5 つの都市の棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore14.png) 作業を確認します。ステップ 1 から 8 を動画でご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 これで、ビューでは最も収益が低い都市がフォーカスされました。さらに調査を進め、原因となる商品を特定することができます。 ## トラブルメーカーを特定する 収益を下げている商品を特定するため、ビューを "Sub-Category (サブカテゴリー)" 別に分類することを決定しました。"Sub-Category (サブカテゴリー)" フィールドには場所別の販売済み商品に関する情報が含まれていることがわかっているため、そこから始めます。 1. **\[行\]** シェルフに **"Sub-Category (サブカテゴリー)"** にドラッグし、"City (都市)" の右に配置します。 2. 赤字収益の商品をわかりやすくするため、\[マーク\] カードの **\[色\]** に **"Profit (収益)"** をドラッグします。 3. \[データ\] ペインで、**\[Order Date (注文日)\]** を右クリックし、**\[フィルターの表示\]** を選択します。 必要な場合は、それぞれの年のマイナスの収益を探索し、損益を招いている商品をすばやく特定できます。 機械類、テーブル、およびバインダーの業績が良くないようです。"Jacksonville (ジャクソンビル)"、"Concord (コンコード)"、"Burlington (バーリントン)"、"Knoxville (ノックスビル)"、"Memphis (メンフィス)" でこれらの品目の販売を中止したらどうなるでしょうか。 ![パフォーマンスの最も低い都市のサブカテゴリの収益性を示す横棒グラフ](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Explore15.png) ## 結果を検証する バインダー、機械類、テーブルを除外することで、フロリダ州、サウス カロライナ州、テネシー州の収益は改善するでしょうか。これを調べるため、問題の商品をフィルターで除外し、結果を確認することができます。 1. **"Profit Map (収益マップ)"** シート タブをクリックしてマップ ビューに戻ります。 2. \[データ\] ペインで **\[サブカテゴリー\]** を右クリックし、**\[フィルターの表示\]** を選択します。 提供しているすべての商品のフィルター カードがマップ ビューの横に表示されます。このフィルターは後で使用します。 3. \[データ\] ペインから \[マーク\] カードの **\[ラベル\]** に、**\[Profit (収益)\]** と **\[Profit Ratio (収益率)\]** をドラッグします。 - 利益率をパーセントで書式設定するには、**\[利益率\]** を右クリックして **\[書式設定\]** を選択します。次に、**\[既定\]** セクションの **\[数値\]** として **\[パーセント\]** を選択し、マップに表示する小数点以下の桁数を設定します。このマップでは、小数点以下 0 桁を選択します。次に、書式設定ペインを閉じます。 これで、カーソルを重ねなくても各州の正確な収益が表示されるようになりました。 4. \[データ\] ペインで **\[Order Date (注文日)\]** を右クリックして **\[フィルターの表示\]** を選択し、ビューのコンテキストを提供します。 "YEAR(Order Date)" のフィルター カードがビューに表示されます。すべての年の収益または複数の年を組み合わせた収益を確認できるようになりました。これはプレゼンテーションに役立つ可能性があります。 5. ビューの "Sub-Category (サブカテゴリー)" フィルター カードのリストで、**"Binders (バインダー)"**、**"Machines (機械類)"**、および **"Tables (テーブル)"** をクリアします。 フィルターをビューに追加することで値を含め、または値を除外し、データの特定の部分を強調できることを思い出してください。 各メンバーをクリアすると、"Tennessee (テネシー)"、"North Carolina (ノース カロライナ)"、および "Florida (フロリダ)" の収益が改善し、最終的にはそれぞれが黒字収益となります。 ![\[サブカテゴリ\] フィルターから \[バインダー\]、\[機械\]、\[テーブル\] の選択を解除した結果](Img/gs_explore-deselect.png) ここで面白い発見をしました。 バインダー、機械類およびテーブルは、テネシー州、ノース カロライナ州、フロリダ州においては間違いなく損失の原因となっていますが、南部の残りの州ではそうではありません。フィルター カードからアイテムをクリアすると、他の州の一部で収益が実際に減少していることにお気づきですか? たとえば、"Sub-Category (サブカテゴリー)" フィルター カードで **"Binders (バインダー)"** を切り替えると、アーカンソー州の収益は 4% 低下します。アーカンソー州では、機械類は実際には収益を上げていると推定できます。 自分が行ったのと同じ手順を行ってもらい、この発見をチームと共有することができます。 11. "Sub-Category (サブカテゴリー)" フィルター カードで **\[すべて\]** を選択し、すべての商品を再度含めます。 詳細: さらに質問する テネシー州、ノース カロライナ州、フロリダ州においてバインダー、機械類およびテーブルが損失の原因となっていることがわかりました。次はどうすればよいでしょうか? 以下の質問に回答することで、データの探索を続けることができます。**注:** これらの質問を探索するためにビューを使用している場合は、「はじめに」チュートリアルを続行する前に変更を元に戻してください。 - "Tennessee (テネシー)"、"North Carolina (ノース カロライナ)"、および "Florida (フロリダ)" の機械類の売上高はどうでしょうか? 販売数量は多いでしょうか。その場合、収益はどのような影響を受けていますか? - これらの結果には、他にどのような要因があるでしょうか。南部の小売業者は商品を割引して販売していますか? - テーブルとバインダーの売上高についてはどうですか? - 機械類、テーブル、バインダーのいずれかを削除すると、"Jacksonville (ジャクソンビル)"、"Miami (マイアミ)"、"Burlington (バーリントン)"、"Knoxville (ノックスビル)"、"Memphis (メンフィス)" の売上高はどのように変化するでしょうか。 - では、本箱はどうでしょうか。ステップ 2 では、他の地域での本箱の収益性が非常に悪いことを確認しました。これらの地域をドリルダウンすることで、追加の解決策が判明する場合があります。 作業を確認します。動画「結果を検証する」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 これで社内で問題のある商品が機械類、テーブル、バインダーであることがわかりました。南部に焦点を当てると、これらの製品が利益にさまざまな影響を与えていることがわかります。これは上司に話す価値のある内容です。 次に、結果を明確にプレゼンテーションで示せるよう、ここまででダッシュボードに行った作業を組み合わせます。 **マップおよび地理的役割の詳細について**は、ラーニング ライブラリ (トップ メニュー) を参照してください。 [ステップ 6: インサイトを示すダッシュボードの構築](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-build.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 6: インサイトを示すダッシュボードの構築 ここまでで、上司が把握する必要がある重要な情報を伝える 4 つのワークシートを作成しました。ここで、テネシー、ノース カロライナ、フロリダのマイナスの利益を示し、利益が低い理由のいくつかを説明する方法が必要です。 これを行うために、ダッシュボードを使用して複数のワークシートを一度に表示できます。さらに、必要であれば、互いに情報をやり取りすることもできます。 関連リソースとビデオについては、「[Tableau Desktop でのダッシュボードの作成](https://www.tableau.com/ja-jp/node/106947?playlist=509089)」を参照してください。 ## ダッシュボードのセットアップ ある場所で、ある品目の販売実績が良くないことを強調する必要があります。収益の棒グラフ ビューとマップ ビューはこの点を明確に示します。 1. **\[新しいダッシュボード\]** をクリックします。 ![新しいダッシュボード アイコン](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Build1.png) 2. 左側の **\[ダッシュボード\]** ペインに、作成したシートが表示されます。**\[Sales in the South (南部の売上)\]** を空のダッシュボードにドラッグします。 3. **\[利益マップ\]** をダッシュボードにドラッグし、それを \[南部の売上\] ビューの上にドロップします。 ダッシュボードが更新されて、次のように表示されます。 !["Profit Map (利益マップ)" と "Sales in the South (南部の売上)" シートを含むダッシュボード](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Build2.png) これで、両方のビューを一度で見ることができます。 残念ながら、棒グラフが少し押しつぶされていますが、データを理解するには問題ありません。 ## ダッシュボードの配置 "Sales in the South (南部の売上)" の棒グラフから "**Sub-Category** (サブカテゴリー)" の各アイテムの詳細を確認することは簡単ではありません。 この問題を解決することで、必要な情報をより効果的に伝えることができます。 1. \[南部の売上\] で **\[カテゴリ\]** 列ヘッダーの値を右クリックし、**\[ヘッダーの表示\]** をクリアします。 ![\[ヘッダーの表示\] が選択されているメニュー](Img/gs_Build3.png) 2. \[南部の売上\] で \[オーダー日/サブカテゴリ\] ヘッダーを右クリックし、\[列のフィールド ラベルを非表示\] を選択します。 ![列フィールド ラベルのメニュー](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_build4.png) データの内訳を保持しながら、ダッシュボードから不要な情報を非表示にしました。余分なスペースがあれば、ダッシュボードでデータが見やすくなりますが、さらに見やすくする方法があります。 3. **"Profit Map (収益マップ)"** タイトルを右クリックして、**\[タイトルを非表示\]** を選択します。 タイトル "Profit Map (利益マップ)" がダッシュボードから非表示になり、より多くのスペースができました。 4. **"Sales in the South (南部の売上高)"** ビュー タイトルについてもこの手順を繰り返します。 5. シートを取り出すたびに、そのシートのフィルターも表示されます。つまり、フィルターが重複して表示されています。ビューの右側で最初の **\[サブカテゴリ\]** フィルター カードを選択し、カードの上部で **\[削除\]** アイコン ![ダッシュボードの \[削除\] アイコン](Img/gs_build5.png) をクリックします。 6. 2 番目の **"Sub-Category (サブカテゴリー)"** フィルター カードといずれかの **"Year of Order Date (注文日の年)"** フィルター カードについてもこの手順を繰り返します。 7. **"Profit (収益)" の色の凡例**をクリックし、右側にある "Sales in the South (南部の売上高)" の下までドラッグします。 8. 最後に、残りの **"Year of Order Date (注文日の年)"** フィルターを選択し、ドロップダウン矢印をクリックしてから、**\[浮動\]** を選択します。それをマップ ビューの白いスペースに移動します。この例では、"Atlantic Ocean (大西洋)" の "East Coast (東海岸)" に配置されます。 "Year of Order Date (発注日の年)" フィルターで別の年を選択してみてください。データがすばやくフィルターされ、州のパフォーマンスの変動が年ごとに表示されます。それも悪くありませんが、比較をさらに簡単にすることができます。 10. **"Year of Order Date (発注日の年)"** フィルターの一番上にあるドロップダウン矢印をクリックし、**\[単一値 (スライダー)\]** を選択します。 ビューが更新されて、次のように表示されます。 ![列ヘッダーとフィルターが少ない "Profit Map (利益マップ)" と "Sales in the South (南部の売上)" シートを含むダッシュボード](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_build6.png) 詳細: ダッシュボード上の浮動オブジェクトとタイル オブジェクトの区別 ダッシュボード上のオブジェクトは、**\[タイル\]** または **\[浮動\]** のいずれかに設定できます。 タイル アイテムは、ドロップした領域に合わせて自動的に拡大縮小されます。浮動アイテムは、ダッシュボードの他のオブジェクトから自由に移動およびサイズ調整できます。必要であれば、同じダッシュボードで浮動アイテムとタイル アイテムの両方を使用することもできます。 **ダッシュボードの配置の詳細については**、ラーニング ライブラリ (トップ メニュー) を参照してください。 これでダッシュボードが大変見やすくなりました。これで年ごとの収益と売上高を簡単に比較できます。プレゼンテーションで使用する画像とあまり違いはありません。Tableau を使用しています。ダッシュボードをより魅力的にしましょう。 作業を確認します。動画「ダッシュボードの配置」をご覧ください _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 双方向性の追加 特定の州でどのサブカテゴリーの収益が多いかを表示するにはどうすればよいでしょうか。 1. ダッシュボードで **\[利益マップ\]** を選択し、右上隅にある **\[フィルターとして使用\]** アイコン ![\[フィルターとして使用\] アイコン](Img/gs_build7.png) をクリックします。 2. マップの南部地域の州を選択します。 "Sales in the South (南部の売上高)" 棒グラフは自動的に更新され、選択した州のサブカテゴリーの売上高のみを表示します。どのサブカテゴリーで収益が多いかをすばやく確認できます。 3. 色が付いている南部の州以外のエリアをクリックして、選択をクリアします。 注文日に基づいた収益の変化をビューアーが確認できるようにする場合もあります。 5. **\[オーダー日の年\]** フィルターを選択してドロップダウン矢印をクリックし、**\[ワークシートに適用\]**、**\[このデータ ソースを使用するすべて\]** の順に選択します。 新しい、インタラクティブなダッシュボードで州のパフォーマンスを年別に探索します。 作業を確認します。動画「双方向性の追加」をご覧ください ここでは、"Sales in the South (南部の売上高)" をフィルターしてノース カロライナ州で販売されたアイテムのみを表示し、次に年ごとの収益を探索します。 _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 名前を変更して進める あなたは上司にダッシュボードを見せ、上司はそれを気に入りました。彼女はそれに「Regional Sales and Profit」(地域別売上高と収益) と名前を付けました。これに従い、**\[ダッシュボード 1\]** タブをダブルクリックし、"**Regional Profit** (地域別収益)" と名前を付けます。 調査中、上司も 2025 年にノースカロライナ州の市場に機械類を投入するという決断は_悪い考え_であったことに気づきました。 上司は探索できるダッシュボードを気に入っていますが、彼女はより大きなチームに対して明確なアクション計画を提示することも望んでいます。彼女からあなたの調査結果をもとにプレゼンテーションを作成するように頼まれました。 ここで、Tableau のストーリーに関する知識が役立ちます。 [ステップ 7: プレゼンテーション用ストーリーの構築](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-story.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 7: プレゼンテーション用ストーリーの構築 結果をより大きなチームと共有します。同時に、ノース カロライナ州での機械類の販売について再評価できるかもしれません。 チームが関心を持っている主要なインサイトを推し測ってプレゼンテーションに取り入れるのではなく、Tableau でストーリーを作成することにします。この方法では、ビューアーにデータ検出プロセスを実行してもらうことができます。また、プレゼンテーション中に発生した質問に回答するため、データをインタラクティブに探索できます。 ## 最初のストーリー ポイントの作成 Tableau のストーリーはスライドショーのようなものです。各ストーリー ポイントは、基本的にプレゼンテーション内の独立したスライドです。また、ダッシュボードとは異なり、各ストーリー ポイントには、独立した状態の同じ Viz またはダッシュボードを表示できます。それは何を意味するのでしょうか? 以下の指示に従うと、明確になるはずです。 プレゼンテーションについては、概要から開始します。 1. **\[新しいストーリー\]** をクリックします。 ![新しいストーリーのアイコン](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Story1.png) 空白のワークスペースが立ち上がり、「シートをここにドラッグ」と書かれています。ここで、最初のストーリー ポイントを作成します。 空白のストーリーは、空白のダッシュボードによく似ています。また、ダッシュボードの場合と同じように、ワークシートをドラッグして表示できます。ストーリーでは、プレゼンテーションにダッシュボードをドラッグすることもできます。 5. 左の \[ストーリー\] ペインから **"Sales in the South (南部の売上高)"** ワークシートをビューにドラッグします。 6. 「Sales and profit by year (年別の売上高と収益)」などのキャプションを追加します (ワークシート上の灰色のボックスでテキストを編集)。 ![ストーリーで表示する \[南部の売上\] シート](Img/gs_Story2.png) ストーリー ポイントは、ビューアーにデータを紹介するのに便利です。 今回は、ノースカロライナ州での機械類の販売についてのストーリーを伝えるため、そのデータに焦点を当てます。 ## 機械類の売上高をハイライトする 機械類を登場させるため、"南部 (South)" 棒グラフの "Sales (売上高)" に含まれるサブカテゴリー フィルターを活用します。 1. **\[ストーリー\]** ペインの \[新しいストーリー ポイント\] で **\[複製\]** をクリックし、1 番目のストーリー ポイントを複製します。 前回中止したところから作業を継続します。ただし、最初のストーリー ポイントは中止したもの全く同じとなることに注意してください。この新しいストーリー ポイントでは、最初のストーリー ポイントや参照元の Viz を変更することなく、フィルターやその他のインタラクティブ機能を変更できます。 2. ストーリーが機械類についてのものだとわかっているため、サブカテゴリー フィルターで **\[すべて\]** のセクションをオフにしてから、**"Machines (機械類)"** を選択します。 これで、ビューアーは機械類の売上高と収益を年ごとに素早く識別できるようになりました。 3. キャプションを追加して、ビューアーに強調します (例:「Machine sales and profit by year (機械類の年別の売上高と収益)」)。 ![\[南部の売上\] シートを含み、機械類にフィルターされたストーリー](Img/gs_Story4.png) 無事に焦点を機械類へと切り替えましたが、何かがおかしいことに気づきます。このビューでは、どの州が損失に関与しているか特定できません。 これについては、次のストーリー ポイントでマップを導入することで解決します。 詳細: ストーリー ポイントのキャプションの下にあるこのミニ ツールバーは何でしょうか。 ストーリー ツールバー ![ストーリーポイントのキャプションにカーソルを合わせると表示されるアイコン](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_story_toolbar.png) は、1 番目のストーリー ポイントのキャプションをキャンバスにドラッグしてナビゲーター エリアにカーソルを合せると、ストーリー ポイントのそばに表示されます。このツールバーを使用して変更を元に戻したり、ストーリーポイントへの更新の適用やストーリーポイントの削除を行ったり、現在のカスタマイズされたストーリーポイントから新しいストーリーポイントを作成したりすることができます。ストーリー ポイントに変更を加えた後は、すべてのオプションを使用できます。それ以外の場合は、削除オプションのみを使用できます。 作業を確認します。「最初のストーリー ポイントの作成」および "機械類の売上高をハイライトする」の実施を視聴してください。 _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 説得する 要するに、ノースカロライナでの機械類の販売は会社の損失につながるということです。作成したダッシュボード内でそのことがわかります。年別の全体的な売上高と収益だけを見てこのポイントを示すことはできませんが、地域の収益を見れば示すことができます。 1. **\[ストーリー\]** ペインで **\[空白\]** を選択し、新しい空白のストーリー ポイントを追加します。ダッシュボード **\[地域の売上と利益\]** をキャンバスにドラッグします。 これにより、ビューアーにデータの新しい観点を提供します。赤字収益は目を引きます。 ![\[地域の売上と利益\] のダッシュボードを使用するストーリー](Img/gs_Story6.png) 3. キャプションを追加します (例:「Underperforming items in the South (南部の非採算項目)」) 結果をノースカロライナ州のみに絞り込むため、まずストーリー ポイントを複製します。 1. **\[複製\]** をクリックし、"Regional Profit (地域の収益)" ダッシュボードで別のストーリー ポイントを作成します。 2. マップ上で **"North Carolina (ノース カロライナ州)"** を選択すると、棒グラフが自動的に更新されることがわかります。 3. "Year of Order Date (発注日の年)" フィルター カードで \[すべて\] を選択します。 4. 「ノース カロライナ州における損益 (2022 - 2025)」などのキャプションを追加します。 これで、ノースカロライナ州の収益の変化を、年ごとにビューアーで確認できるようになりました。これを行うため、4 つのストーリー ポイントを作成します。 1. **\[複製\]** をクリックし、"North Carolina (ノース カロライナ州)" に焦点を当てた "Regional Profit (地域別収益)" ダッシュボードを開始します。 2. \[オーダー日の年\] フィルターで右矢印ボタンをクリックすると、**2022** が表示されます。 3. 「ノース カロライナ州における損益 (2022)」などのキャプションを追加し、**\[複製\]** をクリックします。 4. 2023、2024、2025 の各年について、ステップ 2 と 3 を繰り返します。 これで、ビューアーに対し、ノースカロライナ市場にどの商品がいつ導入され、その業績がいかに低いかを伝えることができます。 作業を確認します。「説得する」の実施を視聴してください。 _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 仕上げ 2025 年のデータにフォーカスしたこのストーリー ポイントで、結果について説明します。キャプションだけでなく、詳細を追加します。 1. 左側のペインで **\[ドラッグしてテキストを追加\]** を選択し、ビューにドラッグします。 2. ノース カロライナ州における機械類の業績の低さを強調する説明をダッシュボードに入力します。たとえば、「2025 年度にノースカロライナ市場に再導入した機械類は、大きな損失となった」などです。 劇的な効果を出すには、プレゼンテーション中に \[南部の売上\] 棒グラフで機械類にカーソルを合わせ、損失が約 4,000 ドルであることを示すツールヒントを表示させます。 ![「2021 年度にノースカロライナ市場に機械類を導入した結果、かなりの金額が失われた」というテキスト キャプションが付いた地域の売上と利益のダッシュボード。](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Story9.png) さらに、最終スライドで、詳細にドリルダウンします。 4. \[ストーリー\] ペインで、**\[空白\]** をクリックします。 5. \[ストーリー\] ペインから **"Negative Profit Bar Chart (赤字収益棒グラフ)"** をビューにドラッグします。 6. **\[オーダー日の年\]** フィルター カードで、表示を **2025** のみに絞り込みます。 これで、機械類の損失がノース カロライナ州バーリントンのみから生じていることが容易にわかります。 7. ビューで **"Burlington (バーリントン)"** マーク (棒) を右クリックし、**\[注釈をつける\]** > **\[マーク\]** を選択します。 8. 表示された \[注釈の編集\] ダイアログ ボックスで、ダミー テキストを削除し、「2025 年のバーリントンにおける機械類の損失は約 $4,000」と入力します。 9. **\[OK\]** をクリックします。 10. ビューで、注釈をクリックしてドラッグし、表示場所を調整します。 11. このストーリー ポイントに「機械類の損失を招いているのはノース カロライナ州のどこか」というキャプションを付けます。 12. **"Story 1 (ストーリー 1)"** タブをダブルクリックして、ストーリーの名前を "Improve Profits in the South (南部の収益向上)" に変更します。 13. **\[ウィンドウ\]** > **\[プレゼンテーション モード\]** を選択してストーリーを確認します。 詳細:サイズを合わせる。 プレゼンテーション モードでは、ダッシュボードのストーリー ポイントの右側と下側にあるスクロール バーは何を行っているのでしょうか。 ![水平スクロールバーと垂直スクロールバーがあるストーリー](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Story7.png) ダッシュボードがプレゼンテーションにうまく適合していないようです。気になるものです。**\[Esc\]** キーを押してプレゼンテーションを終了し、ワークブックの下にある **\[地域の売上と利益\]** シートを選択します。 **\[ダッシュボード\]** にある左側のペインで、**\[サイズ\]** ドロップダウンの選択を \[デスクトップ\] から **\[南部の利益を改善に合わせる\]** に変更します。これで最適なストーリー閲覧のために、ダッシュボードのサイズが自動的に合わせられます。 ![ダッシュボードのサイズの変更に使用する \[ダッシュボード\] ペインのメニュー](Img/gs_Story10.png) **Fit to Improve Profits in the South (南の収益向上に合わせる)** を選択してから、再びプレゼンテーション モードに入ります。ダッシュボードがきれいに収まります。 作業を確認します。「仕上げ」の実施を視聴してください。 _画像をクリックして再生する_ **注**: この gif の詳細は、画面に表示される内容と正確には一致しない場合があります。 ## 発表後 プレゼンテーションはうまくいきました。チームはノースカロライナ州バーリントンで収益を改善するためにやるべきことがあると確信します。さらに、そもそもなぜ機械類の販売がうまくいかなかったのか、知りたいと考えます。あなたの上司は驚きます。損失に対処する道を示しただけでなく、自分たちの実績に疑問を投げかけるようチームを動かしたからです。 この教訓を記憶に鮮明に残すため、結果が書かれた文書をメールでチームに送るように上司から指示されました。Tableau Server や Tableau Public を使って自分のビジュアライゼーションを共有する方法を知っていてよかったです。 [ステップ 8: 結果の共有](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-share.htm)に続きます。 [メイン コンテンツに進む](#main-content) # ステップ 8: 結果の共有 ここまで多くの作業を行った結果、ノースカロライナ州バーリントンに対策が必要なことがわかりました。この情報をチームメートと共有しましょう。 **先へ進める前に**、次のオプションを選択してください。 - 会社で Tableau Cloud または Tableau Server を使用していない場合、または代替となる無料の共有オプションに関心がある場合は、[Tableau Public の使用](#Use_Tableau_Public) にジャンプします。 **注:** Tableau Desktop Free Edition を使用していて、所属する会社が Tableau Public へのコンテンツのパブリッシュを許可していない場合は、有料ライセンスで Tableau Desktop をアクティブ化してから、作業内容を共有またはパブリッシュする必要があります。 - 会社で Tableau Cloud または Tableau Server を使用しており、自分に割り当てられているパーミッションについて詳しく知っている場合は、[Tableau Cloud または Tableau Server の使用](#Use_Tableau_Server) に移動してください。 ## Tableau Public の使用 ストーリーは成功です。チームがオンラインで表示できるよう、Tableau Public にパブリッシュします。 **注:** Tableau Public にパブリッシュすると、名前からわかるように、これらのビューはパブリックにアクセスできます。つまり、ビューや参照元データを、インターネットにアクセスする他の誰とでも共有します。機密情報を共有する場合は、[Tableau Server](http://www.tableau.com/ja-jp/products/server) または [Tableau Cloud](http://www.tableau.com/ja-jp/products/cloud-bi) を検討してください。 1. **\[サーバー\]** > **\[Tableau Public\]** > **\[Tableau Public に保存\]** を選択します。 2. ダイアログ ボックスに Tableau Public 認証資格情報を入力します。 ![Tableau Public ログイン画面](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Share7.png) Tableau Public のプロファイルがない場合は、**\[今すぐ無料で作成\]** をクリックして、プロンプトに従います。 3. このダイアログ ボックスが表示されたら、\[データ ソース\] ページを開きます。右上隅で、**接続**タイプを **\[ライブ\]** から **\[抽出\]** に変更します。 ![「ワークブックの保存中にエラーが発生しました」というメッセージが表示されている \[データの抽出が必要です\] ダイアログボックス](Img/gs_Share10.png) 詳細: 抽出を作成する必要がある理由は?そもそも、抽出とは何でしょうか。Tableau Public ではライブ データ接続をサポートしていません。 このため、パブリッシュを行う前にデータの抽出を作成する必要があります。 データの抽出は、ワークブック内のデータのスナップショットを共有、パフォーマンスを改善、参照元データ ソースでは使用できない Tableau 機能を活用するために使用できる、データ ソースの保存済みサブセットです。 **抽出の操作の詳細について**は、ラーニング ライブラリ (トップ メニュー) を参照してください。 4. 2 回目 (最後) の場合は、**\[サーバー\]** > **\[Tableau Public\]** > **\[Tableau Public に保存\]** を選択します。 5. ブラウザーが開いたら、埋め込まれたストーリーを確認します。次のようになります。 ![Tableau Public にアップロードされた南部のパフォーマンスの低いアイテムの Viz](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Share8.png) 6. **\[詳細の編集\]** をクリックし、viz のタイトルを更新、説明を追加などを行います。 7. **\[保存\]** をクリックします。 これで、ストーリーが Web 上に掲載されました。 8. 同僚と共有するには、viz の一番下にある **\[共有\]** をクリックします。 ![Tableau Public の \[共有\] ダイアログ ボックス](Img/gs_Share9.png) 9. ストーリーの共有方法 1. 自分のウェブサイトに埋め込む: **\[埋め込みコード\]** をコピーして、Web ページの HTML に貼り付けます。 2. リンクを送る: **リンク**をコピーして同僚に送ります。 3. 既定のメール クライアントを使用してメールを送る: \[メール\] アイコンをクリックします。 4. Twitter や Facebook などで共有する: 適切なアイコンをクリックします。 これらの手順を完了した後、[ここをクリック](#Congrats,_you_did_it!)してチュートリアルの最後のセクションに移動してください。 ## Tableau Cloud または Tableau Server の使用 ストーリーは成功です。チームがオンラインで表示できるよう、これを Tableau Server にパブリッシュします。 ### Tableau Cloud または Tableau Server へのパブリッシュ 1. **\[サーバー\]** > **\[ワークブックのパブリッシュ\]** を選択するか、ツールバーで \[共有\] ![共有アイコン](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/Share_Icon.png) をクリックします。 2. **\[クイック接続\]** の **\[Tableau Cloud\]** をクリックして Tableau Cloud に接続するか、ダイアログ ボックスで接続先の Tableau Server の名前 (または、IP アドレス) を入力して \[接続\] をクリックします。 ![Tableau Server または Tableau Cloud ダイアログ ボックスを介した共有](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_share1.png) 3. \[名前\] フィールドに、「**Improve Profits in the South (南部の収益の向上)**」と入力します。 4. 必要であれば、参考用に説明を入力します (例: 「南部で利益を改善する提案」) 5. **\[シート\]** の **\[編集\]** をクリックしてから、**"Improve Profits in the South (南部の収益の向上)"** 以外のすべてのファイルをクリアします。 詳細:ストーリー以外も共有する。 必要であれば、Tableau Server でワークブックのすべてのシートを同僚と共有できます。ただし、どの同僚がどのシートを利用できるようにするかを悩む場合があります。 **注:** パーミッションは管理者によって異なる場合があります。 **Tableau Server パーミッションの詳細について**は、ラーニング ライブラリ (トップ メニュー) を参照してください。 6. **\[パブリッシュ\]** をクリックします。 Tableau Server がインターネット ブラウザーで開きます。要求されたら、サーバー認証資格情報を入力します。 \[パブリッシュの完了\] ダイアログ ボックスで、ストーリーの表示準備が整ったことがわかります。 ![\[パブリッシュの完了\] ダイアログ ボックス](Img/gs_share3.png) 無事完了しました。Tableau Server を使用して、ストーリーを正常にパブリッシュしました。 ### 作業内容へのリンクを送信 チームメイトがオンラインであなたのストーリーとやり取りができるように、自分の作業をチームメイトと共有しましょう。 1. Tableau Server で、パブリッシュした "Improve Profits in the South (南部の収益の向上)" に移動します。次のような画面が表示されます: ![Tableau Server にアップロードされた南部の利益改善のストーリー](/tableau/next/ja-jp/guides/get-started-tutorial/ja-jp/Img/gs_Share5.png) _ワークブックからその他にシートをパブリッシュしていた場合、それらは "Improve Profits in the South (南部の収益改善)" とともに表示されます。_ 2. **"Improve Profits in the South (南部の収益の向上)"** をクリックします。 3. メニューから、**\[共有\]** を選択します。 ![\[共有\] ダイアログ ボックス](Img/gs_Share4.png) 4. ストーリーの共有方法 1. 自分の Web サイトに埋め込む: **\[埋め込みコード\]** をコピーして、Web ページの HTML に貼り付けます。 2. リンクを送る: **リンク** をコピーして同僚に送ります。 3. 既定のメール クライアントを使用してメールを送る: \[メール\] アイコンをクリックします。 ## 無事に共有できました。 Tableau Desktop を使用して商品データのビューを作成、商品売上高と収益性を地域別にマップに示し、結果に関するダッシュボードを構築ました。さらにプレゼンテーションでストーリーを伝え、結果を Web で共有し、遠隔地にいるチーム メンバーが確認できるようにしました。 **あなたはデータの第一人者です。** よくできました。以下の Tableau の "データ ディスカバリ" メソッドをすべて実践できました。 - 質問する - データの収集 - データの構築 - データの探索 - インサイトの共有 Tableau で作業するときは、この基本的なワークフローに従う必要がありますが、ここで行った各段階よりもさらに修正が必要になる場合もあります。たとえば、最初の質問を一般的なもの (売上高に何が起こっているのか?) から具体的なもの (赤字収益の原因となっている南部の都市はどれか?) へと微調整するには、数回の修正が必要となる場合があります。 リビジョンは、予期しない方向に進む可能性があります。それは期待すべきことであり、最初にデータを見たときにはその存在すら知らなかった機会を発見することにつながります。 データの準備が整ったら、Tableau でデータの探索を開始してください。ただし、最初により多くの情報が必要な場合は、学習ライブラリをチェックしてください。 [学習ライブラリ](https://help.tableau.com/v0.0/guides/get-started-tutorial/ja-jp/get-started-tutorial-next.htm)に続きます。 [メイン コンテンツに進む](#main-content) # チュートリアル: Tableau Desktop を始める前に ##### データの接続、データ ビジュアライゼーションの作成、結果のプレゼンテーション、他のメンバーとのインサイトの共有の方法を学習します。 本チュートリアルでは、Tableau Desktop の特長と機能について順を追って説明します。このチュートリアルを進めていくことで、Tableau ワークブック内で複数の viz を作成します。これから取り組む手順とワークブックは、大手小売りチェーンの本社に勤務する従業員についてのストーリーに基づいています。ビジネスや業績に関する質問に回答することで、ストーリーが姿を現します。 Tableau Desktop のデータに接続する方法や、いくつかの有用なビューを作成したり、発表したり、共有する方法を学びます。その過程で、主要な機能を適用する方法を学びます。ステップを完了するために 1 時間から 3 時間取り分けてください。 ## このようなストーリーです... あなたが大手の小売チェーンの従業員であると仮定します。上司は四半期の売上高レポートを入手し、一部の商品の売上が他の商品より良いこと、および一部のエリアの収益が、期待したほど上がらなかったことに気づきました。上司は最終的な収益に興味があります:全体的な売り上げと収益性を見て、数字が何によって引き起こされたのかを探ることが仕事です。 上司から、改良点を特定し、結果をチームに発表するようにも言われました。チームは結果を探索し、会社の商品ラインの売上と収益性を改善する対策を講じることができます。 これから Tableau Desktop を使って商品データのシンプルなビューを作成し、商品の売上高と収益性を地域ごとにマッピングします。結果のダッシュボードを作成し、発表するストーリーを作ります。その後、リモート チーム メンバーが閲覧できるように結果を Web 上で共有します。 バックグラウンドや例については「**詳細**」セクションを展開してください。試してみてください。 詳細: データへの接続 最初は Superstore サンプル データ ソースを参照しながら進んでください。(方法は示されます。) Tableau Desktop のコア機能に慣れたら、これらのステップを自分のデータで試してください。 「スーパーストア」のデータ セットをダウンロードするには、[\[Tableau Public のサンプル データ\]](https://public.tableau.com/app/learn/sample-data) ページからアクセスします。

ステップ
ステップ 1: データへの接続
スタート ページの詳細およびデータへの接続方法について学習します。

ステップに進む

ステップ 2: ドラッグ アンド ドロップによる初期表示
Tableau ワークスペースについて知り、Tableau の用語を学習してデータの調査を開始します。
 ステップに進む
ステップ 3: 結果に焦点を当てる
より深い質問を尋ね、追加ツールを使用してビューを微調整し、データに関するインサイトを得ます。
 ステップに進む
ステップ 4: データを地理的に調査する
トレンドが見つかるかどうか確認するため、データをマップに示す方法について学習します。
 ステップに進む
ステップ 5: ドリルダウンによる詳細表示
データの詳細をドリルダウンし、[上位] フィルターを作成する方法を学習します。
 ステップに進む
ステップ 6: インサイトを示すダッシュボードの構築
作成したビジュアライゼーションを表示するようダッシュボードを構築し、フォーマットする方法について学習します。
 ステップに進む
ステップ 7: プレゼンテーション用ストーリーの構築
結果をプレゼンテーションで示すためのストーリーを構築し、フォーマットする方法について学習します。
 ステップに進む
ステップ 8: 結果の共有
Tableau Server や Tableau Cloud を使用して結果を組織と共有するか、Tableau Public を使用してそれらを世界中で共有します。
 ステップに進む
学習ライブラリ
これであなたはデータの第一人者です。これらの追加リソースについての学習を続けてください。

ライブラリに移動

[メイン コンテンツに進む](#main-content) # データ ソース、ワークブック、Prep フローの Tableau Cloud への移行 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 手動で移行を実行する多くの組織では、ユーザー (または一部のユーザー) が自分で、使い慣れたコンテンツを新しい Tableau Cloud サイトに移行することが理にかなっているかもしれません。このトピックで説明しているコンテンツの移行手順は、Creator ロールを持つ組織内のユーザーが実行できます。 ## はじめる前に コンテンツの移行に着手する前に、既存の Tableau Server 環境のたな卸しを完全に行い、クリーンアップを行うことをお勧めします。「[大掃除: お持ちのコンテンツは有益なものですか?](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm#Cleaning)」を参照してください。 **Tableau Server の作業は継続してください。**移行プロセス中、すべてのコンテンツとビジネス プロセスが Tableau Server システム内で動作し続けていることを確認してください。コンテンツと手順が Tableau Cloud に適切に移行されたことを確認および検証するまでは、Tableau Server 環境を廃止しないでください。 ## ステップ 1: 最小限のアクセス ポリシーでサイトのプロジェクトを作成する 新しい Tableau Cloud サイトは、最小限のアクセス ポリシーで設定することをお勧めします。ユーザーがプラットフォーム上のコンテンツへアクセスをできるようにするには、ユーザーを Tableau Cloud に追加する必要があります。 開始する前に、Tableau でパーミッションがどのように相互作用し継承するかについての復習コースとして、「[クイック スタート: パーミッション](https://help.tableau.com/current/online/ja-jp/qs_permissions.htm)」を確認することをお勧めします。Tableau Server の環境でこれらの概念に精通している場合は、開始して問題ありません。Tableau Cloud のパーミッションは、サーバーと同じロジックを使用します。 以下の手順に従って、最小限のアクセス ポリシーでプロジェクトを設定します。 1. さらに多くのプロジェクトを作成する前に、デフォルト プロジェクトで[テンプレートのパーミッション](https://help.tableau.com/current/online/ja-jp/permissions_capabilities.htm)を設定します。 2. すべてのユーザー グループのパーミッションを削除します。すべてのユーザーを削除すると、コンテンツにアクセスする必要があるユーザーに対して、プロジェクトが明示的なパーミッションで設定されます。 3. [グループを作成します](https://help.tableau.com/current/online/ja-jp/to_add_users_groups.htm)。グループを使用すると、組織やコンテンツの規模に応じてパーミッションの管理を簡素化できます。 プロジェクトのパーミッションに関する一般的なガイドについては、「[プロジェクトを使用したコンテンツへのアクセスの管理](https://help.tableau.com/current/online/ja-jp/projects.htm)」を参照してください。 ## ステップ 2: Creator ロールを持つユーザーを追加する 最小限のアクセス ポリシーを設定したら、コンテンツを移行するユーザーを追加します。コンテンツの移行をユーザーに依存していない場合は、プロセスの後半でユーザーを追加できます。「[移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm)」を参照してください。 Creator ユーザーを追加するには、次のガイドラインに従います。 - サイト ロールについては、「[ユーザーのサイト ロールの設定](https://help.tableau.com/current/online/ja-jp/users_site_roles.htm)」を参照してください。 - 「[ユーザーを手動で追加](https://help.tableau.com/current/online/ja-jp/sites_addusers.htm)」するか、「[ユーザーを CSV ファイルでインポート](https://help.tableau.com/current/online/ja-jp/users_import.htm)」できます。 - ユーザーを追加して役割を設定したら、前の手順で設定した適切なグループに追加します。 ## ステップ 3: パブリッシュ済みデータ ソースを移行する 複数のワークブックで 1 つのパブリッシュされたデータ ソースを使用している場合、パブリッシュされたデータ ソースを 1 回だけ移行する必要があります。 1. Tableau Desktop で Tableau Server 環境にサインインし、移行するワークブックに移動して \[ダウンロード\] をクリックします。 2. Tableau Desktop の \[データ\] メニューでデータ ソースを選択し、\[ローカル コピーの作成\] を選択して、データ ソースのローカル コピーを保存します。 3. \[シート\] から作業し、\[データ\]、\[データ ソースの置き換え\] の順に選択します。以下のオプションを入力します。 - 現在: 現在のローカル コピー の置き換え: 保存したローカル コピー - \[データ\] ペインで元のパブリッシュ済みデータ ソースを右クリックし、\[閉じる\] を選択します。 4. \[サーバー\] を選択し、\[サインアウト\] をクリックします。 5. \[データ\] メニューでデータ ソースを選択し、\[サーバーにパブリッシュ\] を選択します。 6. Tableau Desktop で Tableau Cloud にサインインし、データ ソースをパブリッシュします。 7. 必要に応じて、Tableau Cloud でそのデータ ソースの更新をスケジュールします。詳細については、「[Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm)」を参照してください。 新しくパブリッシュされたデータ ソースがワークブック内の唯一のデータ ソースである場合は、次の 2 つの手順に従ってワークブックもパブリッシュします。ワークブックにパブリッシュされたデータ ソースが複数ある場合は、スキップして次のステップに進みます。 1. データ ソースをパブリッシュするときに、\[ワークブックを更新して、パブリッシュされたデータ ソースを使用する\] が選択されていることを確認します。 2. \[サーバー\]、\[ワークブックのパブリッシュ\] の順に選択し、ワークブックを Tableau Cloud にパブリッシュします。 ## ステップ 4: 複数のパブリッシュ済みデータ ソースを含むワークブックを移行する Tableau Cloud に移行するすべてのパブリッシュ済みデータ ソースに対して、次のプロセスを繰り返します。 1. Tableau Desktop で Tableau Server 環境にサインインし、移行するパブリッシュ済みデータ ソースに移動して、\[ダウンロード\] をクリックします。 2. Tableau Desktop でファイルが開きます。Tableau Desktop の \[データ\] メニューでデータ ソースを選択し、\[ローカル コピーの作成\] を選択して、データ ソースのローカル コピーを保存します。 3. \[データ\] ペインで元のパブリッシュ済みデータ ソースを右クリックし、\[閉じる\] を選択します。 4. ワークブック内のすべてのパブリッシュ済みデータ ソースに対して、手順 2 ～ 3 を繰り返します。 5. \[サーバー\] を選択し、\[サインアウト\] をクリックします。 6. \[シート\] から作業し、\[データ\]、\[データ ソースの置き換え\] の順に選択します。以下のオプションを入力します。 - 現在: 現在のローカル コピー - 置換: 保存したローカル コピー 7. すべてのパブリッシュ済みデータ ソースを置き換えたら、\[選択\]、\[ワークブックのパブリッシュ\] の順に選択して、ワークブックを Tableau Cloud にパブリッシュします。 ワークブックに Tableau Bridge を必要とする埋め込みデータ ソースもある場合、それらのデータ ソースは移行中とは別にパブリッシュする必要があります。「[データ ソースのパブリッシュ](https://help.tableau.com/current/pro/desktop/ja-jp/publish_datasources.htm)」を参照してください。 ## ステップ 5: 埋め込みデータ ソースを含むワークブックを移行する 1. Tableau Desktop で Tableau Server 環境にサインインし、移行するワークブックに移動して **\[ダウンロード\]** をクリックします。 2. **\[サーバー\]** を選択し、**\[サインアウト\]** をクリックします。 3. **\[サーバー\]** を選択し、**\[サインイン\]** をクリックして Tableau Cloud にサインインします。 4. 埋め込みデータ ソースが自動更新に Tableau Bridge を必要としていて、**ファイル データ** (.cvs や .xlsx など) である場合は、「[オンプレミス データのパブリッシュ (Tableau Cloud のみ)](https://help.tableau.com/current/pro/desktop/ja-jp/publish_datasources.htm#publish-onpremises-data-tableau-cloud-only)」の手順に従ってください。 5. データ ソースが Tableau Bridge を必要としない場合、**または**ファイル データではない場合は、**\[サーバー\] > \[ワークブックのパブリッシュ\]** を選択します。 ## ステップ 6: Tableau Prep フローの移行 一般に公開されているクラウド データについては、Tableau Cloud でクエリを実行できるように有効化する必要がある場合があります。接続を有効化するには、「[Tableau Cloud にパブリッシュされたクラウド データへのアクセスの承認](https://www.google.com/url?q=https://help.tableau.com/current/pro/desktop/ja-jp/publish_tableau_online_ip_authorization.htm)」を参照してください。 Tableau Cloud に移行するすべての Tableau Prep フローに対して、次の手順を繰り返します。この手順は、[Tableau Prep Builder](https://www.tableau.com/ja-jp/products/prep/download) を実行しているコンピューターで実行します。 1. Tableau Server 環境にサインインし、移行するフローに移動して \[ダウンロード\] をクリックします。 2. Tableau Prep Builder でフローが開きます。 1. フローが少なくとも 1 つのパブリッシュされたデータ ソースに接続すると、サーバーにサインインするよう自動的に求められます。自動的に求められない場合は、トップ メニューから \[サーバー\]、\[サインイン\] の順に選択し、Tableau Server にサインインします。 2. トップ メニューから移動し、\[サーバー\] を選択します。\[サーバー URL にサインイン済み\] で、\[サインアウト\] をクリックします。 3. フローが少なくとも 1 つのパブリッシュされたデータ ソースに接続していると、次の警告が表示されます。 ![](/tableau/next/ja-jp/guides/migration/ja-jp/Img/prep-migrate_583x269.png) 4. \[サインアウト\] をクリックします。 3. トップ メニューに移動し、\[サーバー\]、\[サインイン\]、\[Tableau Cloud へのクイック接続\] の順に選択して Tableau Cloud にサインインします。 4. パブリッシュされたデータ ソースがフローに含まれていない場合は、次のステップに進みます。パブリッシュされたデータ ソースへの接続がフローに少なくとも 1 つある場合 1. \[接続\] ペインを開き、Tableau Cloud 上の新しいバージョンのパブリッシュされたデータ ソースに接続します。 2. 新しい接続をドラッグ アンド ドロップして、既存の Tableau Server のパブリッシュされたデータ ソースの入力ステップを置き換えます。 3. 接続の画面で既存の接続を右クリックし、Tableau Server のパブリッシュされたデータ ソースを削除します。 4. フロー内の他のすべてのパブリッシュされた接続データ ソースに対して手順を繰り返します。 5. パブリッシュされたデータ ソースにフローが出力している場合は、その出力ステップに移動し、Tableau Cloud 上の新しいパブリッシュされたデータ ソースを参照するように更新します。 - フロー内の他のすべてのパブリッシュされた出力データ ソースに対して手順を繰り返します。 6. パブリッシュされたデータ ソースがすべて置き換えられたら、\[サーバー\]、\[フローのパブリッシュ\] の順に選択するか、右上隅の \[パブリッシュ\] ボタンをクリックしてフローを Tableau Cloud にパブリッシュします。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. **現在地**: データ ソース、ワークブック、フローを Tableau Cloud に移行する 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # パート 1 - 企業環境への導入について **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 パート 1 では、「企業環境への Tableau Server 導入ガイド」で設計した、企業環境への導入における業界標準の特徴と要件について詳しく説明します。 次のネットワーク図は、Tableau Server 参照アーキテクチャを使用した、一般的なデータセンターにおける階層型の導入を表しています。 ## 業界標準と導入要件 業界標準の導入における特徴は以下のとおりです。これらを要件として参照アーキテクチャは設計されています。 - 多層ネットワーク設計: ネットワークは保護されたサブネットによって境界を区切り、Web 層、アプリケーション層、データ層の各層においてアクセスを制御します。すべての通信は隣接するサブネットで終端され、いかなる通信も複数のサブネットをまたがって通り抜けることはできません。 - ポートとプロトコルを既定でブロック: 各サブネットやセキュリティ グループは、すべてのインバウンドおよびアウトバウンドのポートとプロトコルを既定でブロックします。通信を部分的に可能にするためには、その通信のポートまたはプロトコルを例外的に開く設定が必要です。 - 保護区域の外での Web 認証: インターネットからのユーザー要求は、Web 層にあるリバース プロキシの認証モジュールで認証されます。そのため、アプリケーション層に対するすべての要求は、まず Web 層で認証されてから、保護されたアプリケーション層に渡されます。 - プラットフォーム非依存: オンプレミス サーバーのアプリケーションかクラウドのアプリケーションかに関わらず導入できるソリューションです。 - テクノロジー非依存: 仮想マシン環境にもコンテナにも導入できるソリューションです。Windows にも Linux にも導入できます。ただし、この初期バージョンの参照アーキテクチャとサポート ドキュメントは、AWS で実行する Linux を前提に策定されています。 - 高可用性: システム内のすべてのコンポーネントはクラスタとして展開され、アクティブ/アクティブ、またはアクティブ/パッシブの展開で動作するように設計されています。 - サイロ化されたロール: 各サーバーは個別のロールを実行します。この設計では、すべてのサーバーを分割することにより、アクセス権限がサービスごとの管理者に限られるようにします。たとえば、DBA は Tableau の Postgre SQL を管理し、ID 管理者は Web 層の認証モジュールを管理し、ネットワークとクラウドの管理者はトラフィックと接続を有効化します。 - 直線的に拡張可能: 負荷の状況に応じて、各層のサービスを個別のロールとして別々に拡張できます。 - クライアントのサポート: 参照アーキテクチャは、すべての Tableau クライアント (Tableau Desktop (バージョン 2021.2 以降)、Tableau Mobile、および Tableau Web 作成) をサポートします。 ## セキュリティ対策 前述のように、業界標準のデータセンター設計における第一の特徴はセキュリティです。 - アクセス: 各層は、サブネットで境界を区切ります。サブネットでは、ポートをフィルターすることにより、アクセス制御をネットワーク レイヤーで実施します。サブネット間の通信アクセス制御は、プロセス間の認証サービスを使用してアプリケーション レイヤーでも実施する場合があります。 - 統合: このアーキテクチャの設計では、Web 層のリバース プロキシで ID プロバイダー (IdP) にプラグインします。 - プライバシー: クライアントから Web 層への通信は、SSL で暗号化します。内部サブネットへの通信も、オプションで暗号化することができます。 ## Web 層 (プロキシ層) Web 層は DMZ (ペリメーター ゾーンとも呼ばれます) のサブネットであり、インターネットと、アプリケーションが展開される内部サブネットとの間のセキュリティ緩衝地帯として機能します。Web 層は、機密情報を保存しないリバース プロキシ サーバーをホストします。リバース プロキシ サーバーは、クライアント要求を Tableau Server にリダイレクトする前に、信頼できる IdP を使用してクライアント セッションを事前認証するように AuthN プラグインを使用して構成されます。詳細については、「[AuthN モジュールによる事前認証](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part5.htm#Pre-auth)」を参照してください。 ### ロードバランサー 導入の設計では、リバース プロキシ サーバーの手前に企業の負荷分散ソリューションを含めています。 ロードバランサーは、セキュリティとパフォーマンスを強化する上で、次のような重要な役割を果たします。 - アプリケーション層サービスのフロント エンド URL を仮想化 - SSL 暗号化を強制 - SSL をオフロード - クライアントと Web 層サービスの間で圧縮を実施 - DOS 攻撃から保護 - 高可用性を提供 **注**: Tableau Server バージョン 2022.1 には、Tableau Server の独立したゲートウェイが含まれています。独立したゲートウェイは、Tableau 対応のリバース プロキシとして機能する Tableau ゲートウェイ プロセスのスタンドアロン インスタンスです。リリースの時点で、独立したゲートウェイは検証されていますが、EDG リファレンス アーキテクチャでは完全にはテストされていません。完全なテストが完了したら、EDG は Tableau Server の独立したゲートウェイの規範的なガイダンスに従って更新されます。 ## アプリケーション層 アプリケーション層は、サーバー アプリケーションの核となるビジネス ロジックを実行するサブネットです。アプリケーション層には、クラスタ内の分散ノード群で構成されたサービスとプロセスが含まれます。アプリケーション層には Web 層からのみアクセスでき、ユーザーは直接アクセスできません。 パフォーマンスと信頼性を向上するために、使用するリソースの特徴が異なるプロセス (つまり、CPU 集中型プロセスとメモリ集約型プロセス) が同じ場所に配置されるようにアプリケーション プロセスを構成します。 ## データ層 データ層は、貴重なデータを保持するサブネットです。データ層へのすべてのトラフィックはアプリケーション層から送信されるため、すでに認証されています。データ層では、ポート構成を使用したネットワーク レイヤーでのアクセス要件に加えて、アプリケーション層で認証されたアクセスとオプションで暗号化されたトラフィックを含める必要があります。 [メイン コンテンツに進む](#main-content) # パート 2 - Tableau Server 導入の参照アーキテクチャ **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 次の画像は、関連する Tableau Server プロセスと、それらがリファレンス アーキテクチャーにどのように展開されているかを示しています。これは、企業環境での導入において求められる Tableau Server の最小構成です。 このトピックのプロセス図は、各ノードの特徴的で主要なプロセスを示すことを目的としています。ノードで実行されるサポートプロセスには、図に示されていないものも多くあります。すべてのプロセスの一覧については、このガイドの構成セクション[パート 4 - Tableau Server のインストールと構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm)を参照してください。 ## Tableau Server プロセス Tableau Server 参照アーキテクチャでは、PostgreSQL 上に外部リポジトリを備えた、4 つのノードからなる Tableau Server のクラスタを導入します。 - Tableau Server 初期ノード (ノード 1): TSM 管理サービスとライセンス サービスを実行します。これらは必須のサービスであり、クラスター内の単一ノードでのみ実行できます。エンタープライズ環境では、Tableau Server 初期ノードはクラスター内のプライマリ ノードです。このノードは、ノード 2 を使用して冗長アプリケーション サービスも実行します。 - Tableau Server アプリケーション ノード (ノード 1 およびノード 2): これらの 2 つのノードは、クライアント要求の処理、データ ソースへの接続とクエリ実行、データ ノードへの接続を行います。 - Tableau Server データ ノード (ノード 3 およびノード 4): これらの 2 つのノードはデータ管理専用です。 - 外部 PostgreSQL: このホストは Tableau Server リポジトリ プロセスを実行します。HA 構成では、アクティブ/パッシブ冗長性のために PostgreSQL ホストを追加で実行する必要があります。 PostgreSQL は Amazon RDS でを実行することもできます。RDS と EC2 インスタンスでのリポジトリの実行の違いについては、「_Tableau Server 外部リポジトリ_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_external_repo.htm)) を参照してください。 外部リポジトリを使用して Tableau Server を展開するには、Tableau Advanced Management ライセンスが必要です。 社内組織に DBA の専門知識がない場合は、オプションで、デフォルトの内部 PostgreSQL 構成を使用して Tableau Server リポジトリ プロセスを実行することもできます。デフォルトのシナリオでは、PostgreSQL が埋め込まれている Tableau ノードでリポジトリを実行します。その場合、リポジトリのフェイルオーバーに対応するために、専用の Tableau ノードでリポジトリを実行し、別の専用ノードでパッシブ リポジトリを実行することをお勧めします。_リポジトリ フェイルオーバー_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/distrib_ha_failover.htm)) を参照してください。 たとえば、このガイドに記載されている AWS の実装では、EC2 インスタンスで実行されている PostgreSQL に外部リポジトリを展開する方法を説明しています。 - オプション: 外部ストレージを使用している場合は、Tableau ファイル ストアを外部サービスとして導入できます。このガイドの主要な導入シナリオでは、外部ファイル ストアを扱っていません。「_外部ファイル ストアを使用して Tableau Server をインストールする_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_external_filestore_storage_new_install.htm))」を参照してください。 外部ファイル ストアを使用して Tableau Server を展開するには、Tableau Advanced Management ライセンスが必要です。 ### PostgresSQL リポジトリ Tableau Server リポジトリは PostgresSQL データベースであり、サーバー データを格納します。このデータには、Tableau Server のユーザー、グループとグループ割り当て、パーミッション、プロジェクト、データ ソース、抽出のメタデータと更新などに関する情報が含まれています。 ![それぞれ象徴的な象のロゴが付いた 2 つの PostgreSQL データベース間でデータ レプリケーションが行われています。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-ref-arch-repo.png) デフォルトの PostgresSQL の導入では、システム メモリ リソースのほぼ 50% を消費します。実稼働の導入の場合や、それが大規模である場合などの使用量に応じて、リソースの消費量が増える可能性があります。このため、リポジトリ プロセスを実行するコンピューターは、リソースを大量に消費する、VizQL、バックグラウンダー、データ エンジンなどのサーバー コンポーネントを実行していないコンピューターにすることをお勧めします。これらのコンポーネントのいずれかと一緒にリポジトリ プロセスを実行すると、IO の競合、リソースの制約などが発生し、導入の全体的なパフォーマンスが低下します。 ## ノード 1: 初期ノード 初期ノードは重要な少数のプロセスを実行し、アプリケーションの負荷をノード 2 と共有します。 Tableau を最初にインストールするコンピューターである「初期ノード」には、固有の特徴があります。初期ノード上で実行できるのは、ライセンス サービス (ライセンス マネージャー)、ライセンス認証サービス、TSM コントローラー (管理コントローラー) の 3 つのプロセスのみで、エラーが発生した場合を除き、これらのプロセスを他のノードに移動させることはできません。 ### ノード 1 のフェイルオーバーと自動復元 ライセンス、アクティブ化、および TSM コントローラー サービスは、Tableau Server を健全に展開するための重要なサービスです。参照アーキテクチャーが適切に構成されていれば、ノード 1 で障害が発生してもノード 2 に要求がルーティングされるため、ユーザーは引き続き Tableau Server 構成に接続できます。いっぽう、これらのコア サービスがなければ、Tableau Server 構成は障害が発生したままの重大な状態になります。「[初期ノードの自動リカバリ](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part7.htm#Initial)」を参照してください。 ## ノード 1 およびノード 2: アプリケーション サーバー ![Tableau アプリケーション ノードのプロセス](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-ref-arch-appnodes.png) ノード 1 とノード 2 は Tableau Server プロセスを実行し、クライアント要求の処理、データ ソースへのクエリ、ビジュアライゼーションの生成、コンテンツと管理の処理、その他の Tableau ビジネス ロジックを実施します。アプリケーション サーバーではユーザー データは保存されません。 **注**:「アプリケーション サーバー」は、TSM にリストされている Tableau Server プロセスを指すこともあります。"アプリケーション サーバー" の基盤となるプロセスは VizPortal です。 ノード 1 とノード 2 は、並行して実行すると拡張され、リバース プロキシ サーバーによる負荷分散ロジックからの要求を処理できます。冗長ノードとして、どれか 1 つのノードに障害が発生しても、クライアントの要求とサービスは残りのノードによって処理されます。 参照アーキテクチャは、補完的なアプリケーション プロセスが同一のコンピューターで実行されるように設計されています。つまり、このプロセスによって、コンピューティング リソースの競合が発生したり、誘発されたりすることはありません。 たとえば、アプリケーション サーバー上のコア処理サービスである VizQL は CPU とメモリに大きく依存しており、VizQL はコンピューターの CPU とメモリの約 60 ～ 70% を使用します。このため、リファレンス アーキテクチャは、他のメモリや CPU にバインドされたプロセスが VizQL と同じノード上に存在しないように設計されています。負荷の量やユーザー数が VizQL ノードのメモリや CPU の使用量に影響を与えないことはテストで確認済みです。たとえば、負荷テストで同時ユーザー数を減らしても、ダッシュボードやビジュアライゼーションの読み込みプロセスのパフォーマンスのみに効果があるものの、リソースの使用率は軽減されません。したがって、ピーク使用時に使用可能なメモリと CPU に基づいて、VizQL プロセスを追加することを検討できます。一般的なワークブックの開始方法として、まず VizQL プロセスごとに 4 つのコアを割り当てます。 ### アプリケーション サーバーの拡張 参照アーキテクチャは、使用量ベースのモデルに基づいて、拡張性を考慮して設計されています。最大 1000 人のユーザーをサポートするアプリケーション サーバーを少なくとも 2 台導入することを、一般的な出発点として推奨します。ユーザーの規模が拡大するのに合わせて、1000 ユーザーごとにアプリケーション サーバーを追加することを計画します。使用状況とパフォーマンスを監視して、自分の組織に適した、ホストあたりのユーザー規模を調整します。 ## ノード 3 およびノード 4: データ サーバー ![Tableau Server データ ノードのプロセス](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-ref-arch-data.png) ファイル ストア、データ エンジン (ハイパー)、バックグラウンダーなどのプロセスは、次の理由からノード 3 やノード 4 に配置します。 - 同一ノード上でバックグラウンダー、Hyper、およびファイル ストアを実行することで、パフォーマンスと信頼性が最適化されます。抽出プロセス中に、バックグラウンダーがターゲットのデータ ベースに対してクエリを実行し、Hyper ファイルを同じノードに作成してから、ファイル ストアにアップロードします。これらのプロセスを同じ場所に配置することにより、抽出作成ワークフローでは、ネットワークまたはノード間で大量のデータをコピーする必要がありません - リソースのバランシング: バックグラウンダーは主に CPU を集中的に使用します。データ エンジンはメモリを大量に消費するプロセスです。これらのプロセスを結合することによって、各ノードのリソース使用率を最大化できます。 - データ プロセスの統合: これらの各プロセスはバックエンドのデータ プロセスであるため、安全なデータ層の中で実行することは理にかなっています。参照アーキテクチャの今後のバージョンでは、アプリケーション サーバーとデータ サーバーは別々の層で実行されます。ただし、Tableau アーキテクチャにはアプリケーションの依存関係があるため、この時点では、アプリケーション サーバーとデータ サーバーを同じ層で実行する必要があります。 ### データ サーバーの拡張 アプリケーション サーバーと同様に、Tableau データ サーバーに必要なリソースを計画するには、使用量ベースのモデルが必要です。一般に、各データ サーバーが 1 日あたり最大 2000 の抽出更新ジョブをサポートできると想定します。抽出ジョブの増加に伴い、ファイル ストア サービスを使用せずにデータ サーバーを追加します。一般的に、2 ノードのデータ サーバー展開は、ファイル ストア サービスにローカル ファイル システムを使用する展開に適しています。アプリケーション サーバーを追加しても、データ サーバーのパフォーマンスや拡張性に直線的に影響を与えることはありません。実際のところ、ユーザー クエリの追加によるオーバーヘッドを除くと、アプリケーション ホストとユーザーの追加による影響は最小限です。 [メイン コンテンツに進む](#main-content) # パート 3 - Tableau Server を企業環境へ導入する準備 **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 パート 3 では、Tableau Server の参照アーキテクチャの導入に必要なインフラストラクチャ要件について説明します。始める前に、「[パート 2 - Tableau Server 導入の参照アーキテクチャ](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part2.htm)」を確認することをお勧めします。 このトピックでは、要件の説明に加えて、AWS 環境で参照アーキテクチャを実装する例についても説明します。本ガイドの残りの部分では、このトピックで説明する AWS 参照アーキテクチャの例を基にして説明を行います。 参照アーキテクチャで基本としている指針は、データセンターのセキュリティのベストプラクティスに基づく標準化です。具体的には、このアーキテクチャでは、保護されたネットワーク サブネットにサービスを分離するように設計されています。サブネット間のやりとりは、特定のプロトコルとポートの通信に制限されます。 次の図は、オンプレミス展開またはお客様が管理するクラウド展開におけるリファレンス アーキテクチャのサブネット設計を示しています。クラウドでの導入の例については、以下のセクション[例: AWS でサブネットとセキュリティ グループを構成する](#AWSexampe)を参照してください。 ## サブネット 3 つのサブネットを作成します。  - Web 層 - アプリケーション層 - データ サブネット ### ファイアウォール/セキュリティ グループのルール 以下のタブでは、データセンターの各層のファイアウォール ルールについて説明します。AWS 固有のセキュリティ グループのルールについては、このトピックの後半部分を参照してください。 Web 層は、インバウンドの HTTPS 要求を受け付け、その要求をアプリケーション層に代理転送する公開 DMZ サブネットです。この設計では、組織を狙う可能性のあるマルウェアからの防御層を設けます。Web 層は、アプリケーション層やデータ層へのアクセスをブロックします。
トラフィック タイプ プロトコル ポート範囲 接続元

インバウンド

 SSH TCP 22 要塞サブネット (クラウド展開用)
インバウンド HTTP TCP 80 インターネット (0.0.0.0/0)
インバウンド HTTPS TCP 443 インターネット (0.0.0.0/0)
アウトバウンド すべてのトラフィック すべて すべて  
アプリケーション サブネットは、Tableau Server を導入する場所です。アプリケーション サブネットには、Tableau アプリケーション サーバー (ノード 1 とノード 2) が含まれます。Tableau アプリケーション サーバーは、データ サーバーに対するユーザー要求を処理し、コア ビジネス ロジックを実行します。 アプリケーション サブネットには、Tableau データ サーバー (ノード 3 とノード 4) も含まれます。 アプリケーション層へのクライアントからのすべてのトラフィックは、Web 層で認証されます。アプリケーション サブネットへの管理アクセスは、要塞ホストを経由して認証され、ルーティングされます。
トラフィック タイプ プロトコル ポート範囲 接続元

インバウンド

 SSH TCP 22 要塞サブネット (クラウド展開用)
インバウンド HTTPS TCP 443 Web 層サブネット
アウトバウンド すべてのトラフィック すべて すべて  
データ サブネットは、外部 PostgreSQL データベース サーバーが存在する場所です。
トラフィック タイプ プロトコル ポート範囲 接続元

インバウンド

 SSH TCP 22 要塞サブネット (クラウド展開用)
インバウンド PostgreSQL TCP 5432 アプリケーション層サブネット
アウトバウンド すべてのトラフィック すべて すべて  
ほとんどのエンタープライズ セキュリティ チームでは、オンプレミスの管理システムからクラウド上に展開されたノードへの直接通信は許可されていません。代わりに、クラウド ノードへのすべての管理 SSH トラフィックは、要塞ホスト (「ジャンプ サーバー」とも呼ばれます) を介してプロキシされます。クラウドへの導入では、参照アーキテクチャのすべてのリソースへの接続に要塞ホスト プロキシを使用することをお勧めします。これは、オンプレミス環境向けのオプションの構成です。 要塞ホストでは管理アクセスの認証を行い、SSH プロトコルのトラフィックのみを許可します。
トラフィック タイプ プロトコル ポート範囲 接続元 接続先

インバウンド

 SSH TCP 22 管理コンピューターの IP アドレス  
アウトバウンド SSH TCP 22   Web 層サブネット
アウトバウンド SSH TCP 22   アプリケーション層サブネット
## 例: AWS でサブネットとセキュリティ グループを構成する このセクションでは、AWS で Tableau Server 参照アーキテクチャを展開するための VPC とネットワーク環境を作成および構成する方法を手順を追って説明します。 以下のスライドは、4 層の参照アーキテクチャを示しています。スライドを進めると、コンポーネント要素がトポロジ マップに階層化されます。 1. VPC サブネット トポロジと EC2 インスタンス (1 つの要塞ホスト、2 つのリバース プロキシ サーバー、4 つの Tableau サーバー、および少なくとも 1 つの PostgreSQL サーバー)。 2. プロトコルの流れとインターネット接続。すべてのインバウンド トラフィックは、AWS インターネット ゲートウェイ経由で管理されます。インターネットへのトラフィックは、NATを介してルーティングされます。 3. アベイラビリティー ゾーン。プロキシ、Tableau Server、PostgreSQL などのホストは、2 つのアベイラビリティー ゾーンに均等に展開されます。 4. セキュリティ グループ。4 つのセキュリティ グループ (パブリック、プライベート、データ、要塞) は、各層をプロトコル レベルで保護します。 ![サーバー、データベース、ユーザーを含む仮想プライベート クラウドのネットワーク図。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-vpc-sg-1.png) ![サーバー、データベース、ユーザーを含む仮想プライベート クラウドのネットワーク図。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-vpc-sg-2.png) ![サーバー、データベース、ユーザーを含む仮想プライベート クラウドのネットワーク図。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-vpc-sg-3.png) ![サーバー、データベース、ユーザーを含む仮想プライベート クラウドのネットワーク図。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-vpc-sg-4.png) ### AWS アベイラビリティーゾーンと高可用性 このガイドに記載されている参照アーキテクチャでは、単一のホストに障害が発生した場合に冗長性を通じて可用性を提供する展開を指定しています。ただし、リファレンス アーキテクチャが 2 つのアベイラビリティー ゾーンにまたがって展開されている AWS の場合、非常にまれなケースでアベイラビリティー ゾーンに障害が発生すると、可用性が低下します。 ### VPC を構成する このセクションでは、次の方法について説明します。 - VPC をインストールして構成する - インターネット接続を構成する - サブネットを構成する - セキュリティ グループを作成して構成する ### VPC を構成する このセクションの手順は、"クラシック" VPC エクスペリエンスの UI にマッピングされます。AWS VPC ダッシュボードの左上隅にある \[New VPC Experience (新しい VPC エクスペリエンス)\] をオフにすると、UI を切り替えてクラシック ビューを表示できます。 VPC ウィザードを実行して、既定のプライベート サブネットとパブリック サブネット、既定のルーティングとネットワーク ACL を作成します。 1. VPC を構成する前に、Elastic IP を作成する必要があります。すべての既定を使用して割り当てを作成します。 2. \[Run VPC wizard (VPC ウィザードの実行)\] > "パブリック サブネットとプライベート サブネットを使用した VPC" 3. ほとんどのデフォルト設定を受け入れます。ただし、以下を設定する必要があります。  - VPC 名を入力します。 - Elastic IP 割り当て ID を指定します。 - 次の CIDR マスクを指定します。 - パブリック サブネットの IPv4 CIDR は 10.0.1.0/24 です。このサブネットの名前を `Public-a` に変更します。 - プライベート サブネットの IPv4 CIDR は 10.0.30.0/24 です。このサブネットの名前を `Private-a` に変更します。 - アベイラビリティー ゾーン: どちらのサブネットにも、現在の地域の a オプションを選択します。 **注:** この例では、所定の AWS データセンター内でアベイラビリティ ゾーンを区別するために **a** と **b** を使用しています。AWS では、アベイラビリティー ゾーン名がここで示した例とは異なる場合があります。たとえば、データセンター内に **c** ゾーンと **d** ゾーンがアベイラビリティー ゾーンとして含まれる場合もあります。 4. \[Create VPC (VPC の作成)\] をクリックします。 5. VPC が作成されたら、 `Public-b`、`Private-b`、`Data`、および `Bastion` サブネットを作成します。サブネットを作成するには、\[サブネット\] > \[サブネットの作成\] をクリックします。 - `Public-b`: アベイラビリティー ゾーンには、現在の地域の b オプションを選択します。CIDR ブロックは 10.0.2.0/24 です。 - `Private-b`: アベイラビリティー ゾーンには、現在の地域の b オプションを選択します。CIDR ブロックは 10.0.31.0/24 です。 - `Data`: アベイラビリティー ゾーンには、現在の地域の a ゾーンを選択します。CIDR ブロックは 10.0.50.0/24 です。オプション: PostgreSQL クラスターで外部データベースを複製する場合は、CIDR ブロックが 10.0.51.0/24 のアベイラビリティ ゾーン B に Data-b サブネットを作成します。 - `Bastion`: アベイラビリティー ゾーンには、いずれかのゾーンを選択します。CIDR ブロックは 10.0.0.0/24 です。 6. サブネットが作成されたら、Public サブネットと Bastion サブネットのルート テーブルを編集して、関連付けられたインターネット ゲートウェイ (IGW) 用に構成されたルート テーブルを使用します。また、Private サブネットと Data サブネットを編集して、ネットワーク アドレス変換 (NAT) 用に構成されたルート テーブルを使用します。 - IGW または NATで 設定されているルート テーブルを確認するには、AWS ダッシュボードの \[ルート テーブル\] をクリックします。2 つのルート テーブル リンクのいずれかを選択して、\[プロパティ\] ページを開きます。\[ルート\] > \[Destination (宛先)\] > \[0.0.0.0/0\] でターゲット値を確認します。ターゲット値はルートのタイプを区別し、文字列 `igw-` または `nat-` のいずれかで始まります。 - ルート テーブルを更新するには、\[VPC\] > \[サブネット\] > \[サブネット名\] > \[ルート テーブル\] > \[ルート テーブルの関連付けの編集\] で更新します。 ### セキュリティ グループを構成する VPC ウィザードで作成する単一のセキュリティ グループは使用しません。以下のセキュリティ グループを作成します (\[セキュリティ グループ\] > \[セキュリティ グループの作成\])。EC2 ホストは、上のスライド図に示すように、2 つのアベイラビリティー ゾーンにまたがるこれらのグループにインストールされます。 - 新しいセキュリティ グループ **Private** を作成します。ここに Tableau Server の 4 つのノードをすべてインストールします。インストール プロセスの後の方で、Private のセキュリティ グループは、10.0.30.0/24 サブネットと 10.0.31.0/24 サブネットに関連付けられます。 - 新しいセキュリティ グループの **Public** を作成します。ここにプロキシ サーバーをインストールします。インストール プロセスの後の方で、Public のセキュリティ グループは、10.0.1.0/24 サブネットと 10.0.2.0/24 サブネットに関連付けられます。 - 新しいセキュリティ グループの **Data** を作成します。ここに Tableau 外部リポジトリである PostgreSQL をインストールします。インストール プロセスの後の方で、Data のセキュリティ グループは、10.0.50.0/24 (およびオプションで 10.0.51.0/24) サブネットに関連付けられます。 - 新しいセキュリティ グループ **Bastion** (要塞) を作成します。ここに要塞ホストをインストールします。インストール プロセスの後の方で、要塞セキュリティ グループは、10.0.0.0/24 サブネットに関連付けられます。 #### インバウンド ルールとアウトバウンド ルールの指定 AWS では、セキュリティ グループはオンプレミス環境のファイアウォールに類似しています。セキュリティ グループの出入りを許可するトラフィックのタイプ (https、http など)、プロトコル (TCP または UDP)、ポートまたはポート範囲 (80、443 など) を指定する必要があります。プロトコルごとに、送信先トラフィックまたは送信元トラフィックも指定する必要があります。 #### Public セキュリティ グループ ルール
インバウンド ルール
タイプ プロトコル ポート範囲 接続元
HTTP TCP 80 0.0.0.0/0
HTTPS TCP 443 0.0.0.0/0
SSH TCP 22 要塞セキュリティ グループ
アウトバウンド ルール
タイプ プロトコル ポート範囲 接続先
すべてのトラフィック すべて すべて 0.0.0.0/0
#### Private セキュリティ グループ ルール Private セキュリティグ ループには、Public セキュリティ グループからの HTTP トラフィックを許可するインバウンド ルールが含まれています。接続を検証するために、展開プロセス中に HTTP トラフィックのみが許可されます。リバース プロキシの展開と Tableau への SSL の構成が完了したら、HTTP インバウンド ルールを削除することをお勧めします。
インバウンド ルール
タイプ プロトコル ポート範囲 接続元
HTTP TCP 80 Public セキュリティ グループ
HTTPS TCP 443 Public セキュリティ グループ
PostgreSQL TCP 5432 Data セキュリティ グループ
SSH TCP 22 要塞セキュリティ グループ
すべてのトラフィック すべて すべて Private セキュリティ グループ
アウトバウンド ルール
タイプ プロトコル ポート範囲 接続先
すべてのトラフィック すべて すべて 0.0.0.0/0
PostgreSQL TCP 5432 Data セキュリティ グループ
SSH TCP 22 要塞セキュリティ グループ
#### Data セキュリティ グループ ルール
インバウンド ルール
タイプ プロトコル ポート範囲 接続元
PostgreSQL TCP 5432 Private セキュリティ グループ
SSH TCP 22 要塞セキュリティ グループ
アウトバウンド ルール
タイプ プロトコル ポート範囲 接続先
すべてのトラフィック すべて すべて 0.0.0.0/0
PostgreSQL TCP 5432 Private セキュリティ グループ
SSH TCP 22 要塞セキュリティ グループ
#### 要塞ホスト セキュリティ グループ ルール
インバウンド ルール
タイプ プロトコル ポート範囲 接続元
SSH TCP 22 AWS へのログインに使用するコンピューター (管理コンピューター) の IP アドレスとネットマスク。
SSH TCP 22 Private セキュリティ グループ
SSH TCP 22 Public セキュリティ グループ
アウトバウンド ルール
タイプ プロトコル ポート範囲 接続先
SSH TCP 22 AWS へのログインに使用するコンピューター (管理コンピューター) の IP アドレスとネットマスク。
SSH TCP 22 Private セキュリティ グループ
SSH TCP 22 Public セキュリティ グループ
SSH TCP 22 Data セキュリティ グループ
HTTPS TCP 443 0.0.0.0/0 (オプション: 要塞ホストにサポート ソフトウェアをダウンロードするためにインターネットにアクセスする必要がある場合は、このルールを作成します)
### パブリック IP の自動割り当てを有効にする これにより、プロキシ サーバーと要塞ホストに接続するための IP アドレスが割り当てられます。 パブリック サブネットと要塞サブネットの場合: 1. サブネットを選択します 2. \[アクション\] メニューで、\[Modify auto-assign IP settings (IP 設定の自動割り当てを変更する)\] を選択します。 3. \[Enable auto-assign public IPv4 addresses (パブリック IPv4 アドレスの自動割り当てを有効にする)\] をクリックします。 4. \[保存\] をクリックします。 ## ロード バランサー **注**: AWS にインストールし、このガイドの展開例に従う場合は、[パート 5 - Web 層の構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part5.htm)で説明されているように、展開プロセスの後の方で、AWS ロード バランサーをインストールして構成する必要があります。 オンプレミス展開では、ネットワーク管理者と協力してロードバランサーを展開し、参照アーキテクチャの Web 層をサポートします。 - Tableau クライアントから HTTPS 要求を受け入れ、リバース プロキシ サーバーと通信する Web 用アプリケーション ロード バランサー。 - リバース プロキシ:  - 冗長性とクライアント負荷の処理のために、少なくとも 2 台のプロキシ サーバーを使用することをお勧めします。 - ロード バランサーから HTTPS トラフィックを受け取ります。 - Tableau ホストへのスティッキー セッションをサポートします。 - ゲートウェイ プロセスを実行している各 Tableau Server へのラウンド ロビン負荷分散用のプロキシを構成します。 - 外部 IdP からの認証要求を処理します。 - フォワード プロキシ: Tableau Server は、ライセンス認証とマップ機能のためにインターネットへアクセスできる必要があります。フォワード プロキシ環境によっては、Tableau サービス URL のフォワード プロキシの許可リストを構成する必要がある場合があります。「_インターネットとの通信_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/plan_network.htm)) を参照してください。 ## ホスト コンピューターを構成する ### 推奨される最小ハードウェア 以下の推奨事項は、参照アーキテクチャでテストした実際のデータに基づいています。 アプリケーション サーバー: - CPU: 8 つの物理コア (16 vCPU) - RAM: 128 GB (物理コアあたり 16 GB) - 空きディスク領域: 100 GB データ サーバー - CPU: 8 つの物理コア (16 vCPU) - RAM: 128 GB (物理コアあたり 16 GB) - 空きディスク領域: 1 TB。Tableau ファイル ストアとして外部ストレージを使用する場合は、適切なディスク容量を計算する必要があります。「_外部ファイル ストアを使用して Tableau Server をインストールする_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_external_filestore_storage_new_install.htm))」を参照してください。 プロキシ サーバー - CPU: 2 つの物理コア (4 vCPU) - RAM: 8 GB (物理コアあたり 4 GB) - 空きディスク領域: 100 GB 外部リポジトリ データベース - CPU: 8 つの物理コア (16 vCPU) - RAM: 128 GB (物理コアあたり 16 GB) - ディスク容量の要件は、データ負荷とそれがバックアップに与える影響によって異なります。トピック「_ディスク容量の要件_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/requ_diskspace.htm#backup-and-restore-processes)) の「_バックアップと復元のプロセス_」セクションを参照してください。 ### ディレクトリ構造 リファレンス アーキテクチャでは、Tableau Server パッケージとデータを既定以外の場所にインストールすることをお勧めします。 - パッケージのインストール先: `/app/tableau_server`: Tableau Server パッケージをインストールする前にこのディレクトリ パスを作成し、インストール時にこのパスを指定します。 - Tableau データのインストール先: `/data/tableau_data`このディレクトリは、Tableau Server をインストールする前に作成しないでください。代わりに、インストール中にパスを指定する必要があります。これにより、Tableau Setup によってパスが適切に作成され、許可されます。 実装の詳細については、「[インストール パッケージの実行と TSM の初期化](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Run2)」を参照してください。 ## 例: AWS にホスト コンピューターをインストールして準備する このセクションでは、Tableau Server 参照アーキテクチャの各サーバー タイプに EC2 ホストをインストールする方法について説明します。 参照アーキテクチャには、次の 8 つのホストが必要です。 - Tableau Server 用の 4 つのインスタンス - プロキシ サーバー用の 2 つのインスタンス (Apache) - 要塞ホスト用の 1 つのインスタンス - 1 つまたは 2 つの EC2PostgreSQL データベース インスタンス ### ホスト インスタンスの詳細 以下の詳細に従って、ホスト コンピューターをインストールします。 #### Tableau Server - Amazon Linux 2 - インスタンス タイプ: m5a.8xlarge - セキュリティ グループ ID: Private - ストレージ: EBS、150 GiB、gp2 ボリューム タイプTableau ファイル ストアとして外部ストレージを使用する場合は、適切なディスク容量を計算する必要があります。「_外部ファイル ストアを使用して Tableau Server をインストールする_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_external_filestore_storage_new_install.htm))」を参照してください。 - ネットワーク: 各プライベート サブネット (10.0.30.0/24 および 10.0.31.0/24) に 2 つの EC2 ホストをインストールします。 - [Tableau ダウンロード ページ](https://www.tableau.com/ja-jp/support/releases/server)から、Tableau Server 2021.2 以降の rpm パッケージの最新メンテナンス リリースを各 Tableau ホストにコピーします。 #### 要塞ホスト - Amazon Linux 2 - インスタンス タイプ: t3.micro - セキュリティ グループ ID: Bastion - ストレージ: EBS、50 GiB、gp2 ボリューム タイプ - ネットワーク: 要塞サブネット 10.0.0.0/24 #### Tableau Server の独立したゲートウェイ - Amazon Linux 2 - インスタンス タイプ: t3.xlarge - セキュリティ グループ ID: Public - ストレージ: EBS、100 GiB、gp2 ボリューム タイプ - ネットワーク: 各パブリック サブネット (10.0.1.0/24 および 10.0.2.0/24) に 1 つの EC2 インスタンスをインストールします。 #### PostgreSQL EC2 ホスト - Amazon Linux 2 - インスタンス タイプ: r5.4xlarge - セキュリティ グループ ID: Data - ストレージ: ディスク容量の要件は、データ量とそれがバックアップに与える影響によって異なります。トピック「_ディスク容量の要件_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/requ_diskspace.htm#backup-and-restore-processes)) の「_バックアップと復元のプロセス_」セクションを参照してください。 - ネットワーク: Data サブネット 10.0.50.0/24(HA クラスターで PostgreSQL を複製する場合は、2 番目のホストを 10.0.51.0/24 サブネットにインストールします) ## 検証: VPC 接続 ホスト コンピューターをインストールしたら、ネットワーク構成を検証します。要塞セキュリティ グループのホストから各サブネットのホストに SSH で接続して、ホスト間の接続を検証します。 ### 例: AWS の要塞ホストに接続する 1. 管理コンピューターを ssh-agent 用に設定します。これにより、EC2 インスタンスに秘密キー ファイルを配置せずに AWS のホストに接続できます。 Mac で ssh-agent を設定するには、次のコマンドを実行します。 `ssh-add -K myPrivateKey.pem`、または最新の Mac OS の場合は `ssh-add --apple-use-keychain myPrivateKey.pem` Windows の場合は、[「プライベート Amazon VPC で実行されている Linux インスタンスに安全に接続する」](https://aws.amazon.com/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/)のトピックを参照してください。 2. 次のコマンドを実行して、要塞ホストに接続します。 `ssh -A ec2-user@` 3. VPC 内の他のホストへは、プライベート IP アドレスを使用して要塞ホストから接続できます。次に例を示します。 `ssh -A ec2-user@10.0.1.93` [メイン コンテンツに進む](#main-content) # パート 4 - Tableau Server のインストールと構成 **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 このトピックでは、Tableau Server 導入のベースラインをインストールして構成する方法について説明します。この手順では、引き続き AWS と Linux の参照アーキテクチャを例に進めていきます。 インストール手順では、Linux の例として RHEL のようなディストリビューションのコマンドを表示します。具体的には、これらのコマンドは Amazon Linux 2 ディストリビューションで開発されたものです。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。 ## はじめる前に 「[パート 3 - Tableau Server を企業環境へ導入する準備](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm)」の説明に従って、環境の準備と確認を行う必要があります。 ## PostgreSQL のインストール、構成、および tar バックアップ この PostgreSQL インスタンスは、Tableau Server 導入の外部リポジトリをホストします。Tableau をインストールする前に、PostgreSQL をインストールして構成する必要があります。 PostgreSQL は Amazon RDS または EC2 インスタンスで実行できます。RDS と EC2 インスタンスでのリポジトリの実行の違いについては、「_Tableau Server 外部リポジトリ_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_external_repo.htm)) を参照してください。 例として、以下の手順は、Amazon EC2 インスタンスに Postgres をインストールして構成する方法を示しています。ここに、リファレンス アーキテクチャにおける PostgreSQL の一般的なインストールと構成の例を示します。DBA は、データのサイズとパフォーマンスのニーズに基づいて PostgreSQL の配置を最適化する必要があります。 PostgreSQL 1.6 を実行していること、および uuid-ossp モジュールをインストールする必要があることに注意してください ### PostgreSQL のバージョン Tableau Server 外部リポジトリ用に互換性のある PostgreSQL のメジャー バージョンをインストールする必要があります。さらに、マイナー バージョンも最小要件を満たす必要があります。
Tableau Server のバージョン PostgreSQL の互換性のある最低バージョン

2022.3.0 ～ 2022.3.7

2023.1.0 ～ 2023.1.4

 13.7
2022.1.17 - 2022.1.19

2022.3.8 ～ 2022.3.19

2023.1.5 ～ 2023.1.15

2023.3.0 ～ 2023.3.8

 13.11
2022.3.20 ～ 2022.3.x

2023.1.16 ～ 2023.1.x

2023.3.9 ～ 2023.3.x

 13.14
2019.3 ～ 2019.3.8 15.6
2024.2.9 ～ 2024.2.13

2025.1.0 ～ 2025.1.6

 15.10
2024.2.14 ～ 2024.2.16

2025.1.7 ～ 2025.1.9

 15.13

2024.2.17

2025.1.10

2025.3 ～ 2025.3.5

 15.14
2025.3.6 15.16

2026.2.x

 17.7
### PostgreSQL をインストールする このインストール手順の例では、PostgreSQL バージョン 13.6 をインストールする方法について説明します。 前のパートで作成した EC2 ホストにサインインします。 1. アップデートを実行して、Linux OS に最新の修正を適用します。 `sudo yum update` 2. `/etc/yum.repos.d/` パスに pgdg repo. ファイルを作成して編集します。次の構成情報をファイルに入力します。 \[pgdg13\] name=PostgreSQL 13 for RHEL/CentOS 7 - x86\_64 baseurl=https://download.postgresql.org/pub/repos/yum/13/redhat/rhel-7-x86\_64 enabled=1 gpgcheck=0 3. Posgres 13.6 をインストールします。 sudo yum install postgresql13-server-13.6-1PGDG.rhel7.x86\_64 4. uuid-ossp モジュールをインストールします。 sudo yum install postgresql13-contrib-13.6-1PGDG.rhel7.x86\_64 5. Postgres を初期化します。 sudo /usr/pgsql-13/bin/postgresql-13-setup initdb ### Postgres SSL を構成する Postgres を設定して、ベース インストールを完了します。 1. 次の 2 つのエントリを使用して、pg\_hba 構成ファイル `/var/lib/pgsql/13/data/pg_hba.conf` を更新します。各エントリには、Tableau Server が実行されるサブネットのマスクを含める必要があります。  `host all all 10.0.30.0/24 password` `host all all 10.0.31.0/24 password` 2. 次の行を追加して、PostgreSQL ファイル `/var/lib/pgsql/13/data/postgresql.conf` を更新します。 `listen_addresses = '*'` 3. 再起動時に Postgres を開始するように構成します。 sudo systemctl enable --now postgresql-13 4. スーパーユーザーのパスワードを設定します。 sudo su - postgres psql -c "alter user postgres with password 'StrongPassword'" **注**: 強力なパスワードを設定してください。この例に示されている `'StrongPassword`’ は使用しないでください。 exit 5. Postgres を再起動します。 sudo systemctl restart postgresql-13 ## PostgreSQL ステップ 1 の tar バックアップを取得する PostgreSQL 構成の tar バックアップを作成します。現在の構成の tar スナップショットを作成すると、展開の続行中に障害が発生した場合の時間を節約できます。 これを "Step 1" バックアップと呼びます。 PostgreSQL ホストの場合: 1. Postgres データベース インスタンスを停止します。 sudo systemctl stop postgresql-13 2. 次のコマンドを実行して、tar バックアップを作成します。 sudo su cd /var/lib/pgsql tar -cvf step1.13.bkp.tar 13 exit 3. Postgres データベースを起動します。 sudo systemctl start postgresql-13 ステップ 1 の復元 インストール中に Tableau Server の初期ノードに障害が発生した場合は、ステップ 1 を復元します。 1. Tableau を実行しているコンピューターで消去スクリプトを実行して、Tableau Server をホストから完全に削除します。 sudo /app/tableau\_server/packages/scripts././tableau-server-obliterate -a -y -y -y -l 2. PostgreSQL ステージ 1 tar を復元します。Postgres を実行しているコンピューター上で、次のコマンドを実行します。 sudo su systemctl stop postgresql-13 cd /var/lib/pgsql tar -xvf step1.13.bkp.tar systemctl start postgresql-13 exit Tableau Server の初期ノードをインストールするインストール プロセスを再開します。 ## インストールの前に このガイドで説明されている AWS/Linux 実装の例に従って Tableau を展開すると、自動インストール スクリプト TabDeploy4EDG を実行できます。TabDeploy4EDG スクリプトによって、以下の手順で説明する 4 ノード Tableau 展開のインストール例が自動化されます。「[付録 - AWS Deployment Toolbox](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part_app-aws.htm)」を参照してください。 ## Tableau Server の初期ノードをインストールする この手順では、参照アーキテクチャで定義されている最初の Tableau Server ノードをインストールする方法について説明します。パッケージのインストールと TSM の初期化を除いて、この手順では、可能な限り TSM コマンド ラインを使用します。TSM CLI を使用すると、プラットフォームに依存しないことに加えて、仮想化されたヘッドレス環境へのよりシームレスなインストールが可能になります。 ### インストール パッケージの実行と TSM の初期化 ノード 1 のホスト サーバーにサインインします。 1. アップデートを実行して、Linux OS に最新の修正を適用します。 sudo yum update 2. インストール パッケージを [Tableau ダウンロード ページ](https://www.tableau.com/ja-jp/support/releases/server)から、Tableau Server を実行するホスト コンピューターにコピーします。 たとえば、Linux RHEL のようなオペレーティング システムを実行しているコンピューターでは、次のコマンドを実行します。 wget https://downloads.tableau.com/esdalt/2022/tableau-server-.rpm ここで、`` はリリース番号です。 3. 依存関係をダウンロードしてインストールします。 sudo yum deplist tableau-server-.rpm | awk '/provider:/ {print $2}' | sort -u | xargs sudo yum -y install 4. ルート ディレクトリにパス `/app/tableau_server` を作成します。 sudo mkdir -p /app/tableau\_server 5. インストール プログラムを実行し、インストール パスとして `/app/tableau_server` を指定します。たとえば、Linux RHEL のようなオペレーティング システムでは、次のコマンドを実行します。 sudo rpm -i --prefix /app/tableau\_server tableau-server-.x86\_64.rpm 6. `/app/tableau_server/packages/scripts./` ディレクトリに変更し、そのディレクトにあるスクリプト `initialize-tsm` を実行します。 sudo ./initialize-tsm -d /data/tableau\_data --accepteula 7. 初期化が完了したら、シェルを閉じます。 exit ### Tableau Server のライセンス認証と登録 1. ノード 1 のホスト サーバーにサインインします。 2. このステップでは、Tableau Server のプロダクト キー (複数可) を指定します。購入した各ライセンス キーに対して、次のコマンドを実行します。 tsm licenses activate -k 3. 次のような形式で json 登録ファイルを作成します。 { "zip" : "97403", "country" : "USA", "city" : "Springfield", "last\_name" : "Simpson", "industry" : "Energy", "eula" : "yes", "title" : "Safety Inspection Engineer", "company\_employees" : "100", "phone" : "5558675309", "company" : "Example", "state" : "OR", "opt\_in" : "true", "department" : "Engineering", "first\_name" : "Homer", "email" : "homer@example.com" } 4. ファイルの変更を保存したら、`--file` オプションでこのファイルを渡し、Tableau Server を登録します。 tsm register --file path\_to\_registration\_file.json ### アイデンティティ ストアの構成 **注**: 展開で Tableau ファイル ストアの外部ストレージを使用する場合は、アイデンティティ ストアを構成する前に外部ファイル ストアを有効にする必要があります。_「外部ファイル ストアを使用して Tableau Server をインストールする_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_external_filestore_storage_new_install.htm))」を参照してください。 デフォルトの参照アーキテクチャでは、ローカルの ID ストアを使用します。`tsm settings import` コマンドで `config.json` ファイルを渡すことにより、ローカル ID ストアで最初のホストを構成します。 オペレーティング システムに応じた `config.json` ファイルをインポートします。 `config.json` ファイルは、scripts. ディレクトリ パス (たとえば、`scripts.20204.21.0217.1203`) に含まれており、アイデンティティ ストアを構成するように書式設定されています。 次のコマンドを実行して、`config.json` ファイルをインポートします。 tsm settings import -f /app/tableau\_server/packages/scripts./config.json ### 外部 Postgres の構成 1. 以下の設定を使用して、外部データベースの json ファイルを作成します。 { "flavor":"generic", "masterUsername":"postgres", "host":"", "port":5432 } 2. ファイルへの変更を保存した後、次のコマンドを使用してこのファイルを渡します。 tsm topology external-services repository enable -f .json --no-ssl Postgres マスター ユーザー名パスワードを入力するように求めるプロンプトが表示されます。 オプション `--no-ssl` を使用すると、Postgres サーバーが SSL/TLS 用に構成されている場合にのみ SSL/TLS を使用するよう Tableau を構成できます。Postgres が SSL/TLS 用に構成されていない場合、接続は暗号化されません。[パート 6 - インストール後の設定](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part6.htm)では、展開の最初のフェーズが完了した後に、Postgres 接続の SSL/TLS を有効にする方法について説明します。 3. 変更を適用します。 次のコマンドを実行して変更を適用し、Tableau Server を再起動します。 tsm pending-changes apply 4. ステップ 1 で使用した構成ファイルを削除します。 ### ノード 1 のインストールを完了する 1. Tableau Server をインストールしたら、サーバーを初期化します。 次のコマンドを実行します。 tsm initialize --start-server --request-timeout 1800 2. 初期化が完了したら、Tableau Server 管理者アカウントを作成します。 TSM オペレーティング システム コンポーネントのインストールと管理に使用しているコンピューター アカウントとは異なり、Tableau Server 管理者アカウントは、Tableau Server のユーザー、プロジェクト、サイトなどの作成に使用するアプリケーション アカウントです。Tableau Server 管理者は、Tableau リソースに対してもパーミッションを適用します。次のコマンドを実行して、初期管理者アカウントを作成します。以下の例では、`tableau-admin` というユーザーです。 tabcmd initialuser --server http://localhost --username "tableau-admin" このユーザーのパスワードを設定するよう、tabcmd から要求されます。 ### 検証: ノード 1 の構成 1. 次のコマンドを実行して、TSM サービスが実行されていることを検証します。 tsm status -v Tableau は以下を返す必要があります。 external: Status: RUNNING 'Tableau Server Repository 0' is running (Active Repository). node1: localhost Status: RUNNING 'Tableau Server Gateway 0' is running. 'Tableau Server Application Server 0' is running. 'Tableau Server Interactive Microservice Container 0' is running. 'MessageBus Microservice 0' is running. 'Relationship Query Microservice 0' is running. 'Tableau Server VizQL Server 0' is running. ... すべてのサービスが一覧表示されます。 2. 次のコマンドを実行して、Tableau 管理サイトが実行されていることを検証します。 curl localhost 最初の数行には、次のような Vizportal html が表示されます。 /./start-administrative-services 8. ノード 1 で、`tsm status` コマンドを実行して、再起動の前に TSM の状態を監視します。 場合によっては、エラー "`Cannot connect to server...` (サーバーに接続できません...)" が発生します。このエラーは、tabadmincontroller サービスが再起動していないために発生します。`tsm status` を引き続き定期的に実行します。このエラーが 10 分経っても消えない場合は、`start-administrative-services` コマンドをもう一度実行します。 しばらくすると、`tsm status` コマンドが DEGRADED ステータスを返し、次に ERROR ステータスを返します。STOPPED ステータスが返されるまで、TSM を起動しないでください。その後、次のコマンドを実行します。 tsm start 残りのノードでインストール プロセスを再開して、Tableau Server をインストールします。 ## 残りのノードへの Tableau Server のインストール 展開を続行するには、Tableau インストーラーを各ノードにコピーします。 ノード構成の概要 このセクションでは、ノード 2 からノード 4 を構成するプロセスについて説明します。各ステップの詳細な構成と検証手順については、次のセクションで説明します。 Tableau Serverノード 2 からノード 4 のインストールでは、bootstrap ファイルを生成、コピー、および参照する必要があります。 bootstrap ファイルを生成するには、最初のノードで TSM コマンドを実行します。その bootstrap ファイルを対象のノードにコピーし、ノードを初期化する手順の中で実行します。 以下の json コンテンツは bootstrap ファイルの例です。(証明書と暗号関連の値は、サンプル ファイルを読みやすくするために切り詰めてあります) { "initialBootstrapSettings" : { "certificate" : "-----BEGIN CERTIFICATE-----\\r\\...=\\r\\n-----END CERTIFICATE-----", "port" : 8850, "configurationName" : "tabsvc", "clusterId" : "tabsvc-clusterid", "cryptoKeyStore" : "zs7OzgAAAAIAAAABAAAAA...w==", "toksCryptoKeystore" : "LS0tLS1CRUdJTiBUT00tLS0tCjM5MDBh...L", "sessionCookieMaxAge" : 7200, "nodeId" : "node1", "machineAddress" : "ip-10-0-1-93.us-west-1.compute.internal", "cryptoEnabled" : true, "sessionCookieUser" : "tsm-bootstrap-user", "sessionCookieValue" : "eyJjdHkiOiJKV1QiLCJlbmMiOiJBMTI4Q0JDLUhQ...", "sessionCookieName" : "AUTH\_COOKIE" } } bootstrap ファイルでは、ノード 1 を認証して接続の検証が行われ、bootstrap プロセス用に暗号化されたチャネルが作成されます。ノードの構成と検証には時間がかかる一方、bootstrap セッションには時間制限があります。ノードを構成する際は、新しい bootstrap の作成とコピーを計画的に実施してください。 bootstrap ファイルを実行した後、Tableau Server の初期ノードにサインインし、新しいノードのプロセスを構成します。ノードの構成が完了したら、変更を適用して初期ノードを再起動する必要があります。新しいノードが構成されて起動します。ノードの数を増やすにつれて、導入の構成と再起動が完了するまでの時間は徐々に長くなります。 インストール手順では、Linux の例として RHEL のようなディストリビューションのコマンドを表示します。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。 1. アップデートを実行して、Linux OS に最新の修正を適用します。 sudo yum update 2. 依存関係をダウンロードしてインストールします。 sudo yum deplist tableau-server-.rpm | awk '/provider:/ {print $2}' | sort -u | xargs sudo yum -y install 3. ルート ディレクトリにパス `/app/tableau_server` を作成します。 sudo mkdir -p /app/tableau\_server 4. インストール プログラムを実行し、インストール パスとして `/app/tableau_server` を指定します。たとえば、Linux RHEL のようなオペレーティング システムでは、次のコマンドを実行します。 sudo rpm -i --prefix /app/tableau\_server tableau-server-.x86\_64.rpm ## bootstrap ファイルを生成、コピー、使用して TSM を初期化する 次の手順は、別のノードで TSM を初期する際に、bootstrap ファイルを生成、コピー、使用する方法を示しています。この例では、bootstrap ファイルに `boot.json` という名前を付けています。 この例では、ホストコンピューターを AWS で実行しており、EC2 ホストで Amazon Linux 2 を実行しています。 1. 最初のノード (ノード 1) に接続し、次のコマンドを実行します。 tsm topology nodes get-bootstrap-file --file boot.json 2. bootstrap ファイルをノード 2 にコピーします。 scp boot.json ec2-user@10.0.31.83:/home/ec2-user/ 3. ノード 2 に接続し、Tableau Server のスクリプト ディレクトリに切り替えます。 cd /app/tableau\_server/packages/scripts. 4. `initialize-tsm` コマンドを実行し、bootstrap ファイルを参照します。 sudo ./initialize-tsm -d /data/tableau\_data -b /home/ec2-user/boot.json --accepteula 5. `initialize-tsm` が完了したら、`boot.json` を削除し、セッションを終了するか、セッションからログアウトします。 ## プロセスを構成する Tableau Server 管理コントローラー (TSM コントローラー) を実行しているノードで、Tableau Server クラスタを構成します。TSM コントローラーは初期ノードで実行します。 ![Tableau Server で実行されているプロセスのリアルタイム ステータスを表示するプロセス ステータス ウィンドウ。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-process-config.png) ### ノード 2 の構成 1. ノード 2 で bootstrap ファイルを使用して TSM を初期化した後、最初のノードにサインインします。 2. 最初のノード (`node1`) で次のコマンドを実行して、ノード 2 のプロセスを構成します。 tsm topology set-process -n node2 -pr clustercontroller -c 1 tsm topology set-process -n node2 -pr gateway -c 1 tsm topology set-process -n node2 -pr vizportal -c 1 tsm topology set-process -n node2 -pr vizqlserver -c 2 tsm topology set-process -n node2 -pr cacheserver -c 2 tsm topology set-process -n node2 -pr searchserver -c 1 tsm topology set-process -n node2 -pr dataserver -c 2 tsm topology set-process -n node2 -pr clientfileservice -c 1 tsm topology set-process -n node2 -pr tdsservice -c 1 tsm topology set-process -n node2 -pr collections -c 1 tsm topology set-process -n node2 -pr contentexploration -c 1 バージョン 2022.1 以降をインストールする場合は、インデックスおよび検索サービスも追加してください。 tsm topology set-process -n node2 -pr indexandsearchserver -c 1 バージョン 2023.3 以降をインストールする場合は、インデックスおよび検索サービスのみを追加してください。検索と参照 (searchserver) サービスは追加しないでください。 3. 変更を適用する前に、構成を確認してください。次のコマンドを実行します。 tsm pending-changes list 4. 変更が保留リストにあることを確認してから (保留リストには他のサービスもあります)、変更を適用します。 tsm pending-changes apply 変更を適用するには再起動が必要です。構成と再起動には時間がかかります。 5. ノード 2 構成を検証します。次のコマンドを実行します。 tsm status -v ### ノード 3 の構成 ノード 3 で bootstrap プロセスを使用して TSM を初期化してから、以下の `tsm topology set-process` コマンドを実行します。 プロセスを設定するたびに、調整サービスが警告を表示します。プロセスを設定するときは、この警告を無視してかまいません。 1. ノード 3 で bootstrap ファイルを使用して TSM を初期化した後、最初のノード (`node1`) にサインインして、次のコマンドを実行してプロセスを構成します。 tsm topology set-process -n node3 -pr clustercontroller -c 1 tsm topology set-process -n node3 -pr clientfileservice -c 1 tsm topology set-process -n node3 -pr backgrounder -c 4 tsm topology set-process -n node3 -pr filestore -c 1 バージョン 2022.1 以降をインストールする場合は、インデックスおよび検索サービスも追加してください。 tsm topology set-process -n node3 -pr indexandsearchserver -c 1 2. 変更を適用する前に、構成を確認してください。次のコマンドを実行します。 tsm pending-changes list 3. 変更が保留リストにあることを確認してから (リストには、自動的に構成された他のサービスも含まれます)、変更を適用します。 tsm pending-changes apply --ignore-warnings 変更を適用するには再起動が必要です。構成と再起動には時間がかかります。 4. 次のコマンドを実行して、構成を検証します。 tsm status -v ## 調整サービス アンサンブルをノード 1 ～ 3 に展開する 標準のリファレンス アーキテクチャの 4 ノード展開の場合は、次の手順を実行します。 1. ノード 1 で次のコマンドを実行します。 tsm stop tsm topology deploy-coordination-service -n node1,node2,node3 このプロセスには TSM の再始動が含まれ、時間がかかります。 2. 調整サービスが導入されたら、TSM を起動します。 tsm start ## ステップ 3 の tar バックアップを取得する インストールを確認したら、次の 4 つの tar バックアップを作成します。 - PostgreSQL - 最初の Tableau ノード (ノード 1) - Tableau ノード 2 - Tableau ノード 3 ステップ 3 tar ファイルの作成 1. 最初の Tableau ノードで、Tableau を停止します。 tsm stop 2. TSM が停止したら、各ノードで Tableau 管理サービスを停止します。各ノードで次のコマンドを順番に実行します (ノード 1、ノード 2、ノード 3)。 sudo /app/tableau\_server/packages/scripts././stop-administrative-services 3. PostgreSQL ホストで、Postgres データベース インスタンスを停止します。 sudo systemctl stop postgresql-12 4. 次のコマンドを実行して、tar バックアップを作成します。 sudo su cd /var/lib/pgsql tar -cvf step3.12.bkp.tar 12 exit 5. Postgres tar ファイルがルート権限で作成されていることを確認します。 sudo ls -al /var/lib/pgsql 6. Postgres ホストで、Postgres データベースを起動します。 sudo systemctl start postgresql-12 7. ノード 1、ノード 2、ノード 3 で tar バックアップを作成します。各ノードで次のコマンドを実行します。 - cd /data sudo tar -cvf step3.tableau\_data.bkp.tar tableau\_data - Tableau tar ファイルがルート権限で作成されていることを確認します。 ls -al 8. 各ノードで Tableau 管理サービスを順番に開始します (ノード 1、ノード 2、ノード 3)。 sudo /app/tableau\_server/packages/scripts././start-administrative-services 9. `tsm status` コマンドを実行して、再起動の前に TSM の状態を監視します。 ほとんどの場合、コマンドは、DEGRADED ステータスを返してから ERROR ステータスを返します。しばらく待ってから、コマンドを再実行してください。ERROR または DEGRADED ステータスが返された場合は、引き続き待機してください。STOPPED ステータスが返されるまで、TSM の起動を試行しないでください。その後、次のコマンドを実行します。 tsm start ステップ 3 の復元 このプロセスにより、Tableau ノード 1、ノード 2、ノード 3 を復元します。Postgres インスタンスもステップ 3 に復元します。このステップを復元したら、調整サービス、ノード 4、そして最終的なノード構成を導入できます。 1. 最初の Tableau ホスト (ノード 1) で tsm サービスを停止します。 tsm stop 2. TSM が停止したら、ノード 1、ノード 2、ノード 3 で Tableau 管理サービスを停止します。各ノードで次のコマンドを実行します。 sudo /app/tableau\_server/packages/scripts././stop-administrative-services 3. PostgreSQL のステップ 3 tar を復元します。Postgres を実行しているコンピューター上で、次のコマンドを実行します。 sudo su systemctl stop postgresql-12 cd /var/lib/pgsql tar -xvf step3.12.bkp.tar systemctl start postgresql-12 exit 4. ノード 1、ノード 2、ノード 3 で Tableau ステップ 3 tar を復元します。各 Tableau ノードで次のコマンドを実行します。 cd /data sudo rm -rf tableau\_data sudo tar -xvf step3.tableau\_data.bkp.tar 5. Tableau ノード 1 コンピューターで、次のファイルを削除します。 - sudo rm /data/tableau\_data/data/tabsvc/appzookeeper/1/version-2/currentEpoch - sudo rm /data/tableau\_data/data/tabsvc/appzookeeper/1/version-2/acceptedEpoch - sudo rm /data/tableau\_data/data/tabsvc/tabadminagent/0/servicestate.json シェルが "file not found (ファイルが見つかりません)" エラーを返した場合は、パス名を変更して、番号 `` (パスのセクション `.../appzookeeper//version-2/...` にある) を増分する必要がある場合があります。 6. ノード 1、ノード 2、ノード 3 で管理サービスを再起動します。各ノードで次のコマンドを実行します。 sudo /app/tableau\_server/packages/scripts././start-administrative-services sudo su -l tableau -c "systemctl --user daemon-reload" sudo /app/tableau\_server/packages/scripts././start-administrative-services 7. ノード 1 で、`tsm status` コマンドを実行して、再起動の前に TSM の状態を監視します。 場合によっては、エラー "`Cannot connect to server...` (サーバーに接続できません...)" が発生します。このエラーは、tabadmincontroller サービスが再起動していないために発生します。`tsm status` を引き続き定期的に実行します。このエラーが 10 分経っても消えない場合は、`start-administrative-services` コマンドをもう一度実行します。 しばらくすると、`tsm status` コマンドが DEGRADED ステータスを返し、次に ERROR ステータスを返します。STOPPED ステータスが返されるまで、TSM を起動しないでください。その後、次のコマンドを実行します。 `tsm start` ノード 1 〜 3 でインストール プロセスを再開して、調整サービスを展開します。 ## ノード 4 の構成 ノード 4 を構成するプロセスは、ノード 3 の場合と同じです。 上記と同様のコマンドを実行して、ノード 3 と同じプロセスを設定しますが、コマンド内で `node3` ではなく `node4` を指定します。 ノード 3 の検証と同様に、`tsm status -v` を実行してノード 4 の構成を検証します。 続行する前に、ノード 4 のファイル ストア プロセスが同期を完了するまで待ちます。ファイル ストア サービス ステータスは、同期が完了するまで `is synchronizing` を返します。ファイル ストアサ ービス ステータスが `is running` を返すと、続行できます。 ## 最終プロセスの構成と検証 プロセス構成の最後のステップは、ノード 1 から余計なプロセスを削除することです。 1. 初期ノード (`node1`) に接続します。 2. ノード 1 のファイル ストアの使用を停止します。停止すると、同じ場所にあるコントローラーからファイル ストアを削除することについて警告が表示されます。この警告は無視してかまいません。次のコマンドを実行します。 tsm topology filestore decommission -n node1 3. ファイル ストアの使用を停止したら、次のコマンドを実行して、ノード 1 からバックグラウンダー プロセスを削除します。 tsm topology set-process -n node1 -pr backgrounder -c 0 4. 変更を適用する前に、構成を確認してください。次のコマンドを実行します。 tsm pending-changes list 5. 実施する変更が保留リストにあることを確認し、変更を適用します。 tsm pending-changes apply 変更を適用するには再起動が必要です。構成と再起動には時間がかかります。 6. 構成を検証します。 `tsm status -v`。 続行する前に、ノード 4 のファイル ストア プロセスが同期を完了するまで待ちます。ファイル ストア サービス ステータスは、同期が完了するまで `is synchronizing` を返します。ファイル ストアサ ービス ステータスが `is running` を返すと、続行できます。 ## バックアップを実行する Tableau Server を完全にリカバリするには、次の 3 つのコンポーネントを含むバックアップ ポートフォリオが必要です。 - リポジトリのバックアップ ファイルとファイル ストア データ。このファイルは `tsm maintenance backup` コマンドで生成します。 - トポロジと構成のエクスポート ファイル。このファイルは `tsm settings export` コマンドで生成します。 - 認証用の証明書ファイル、キー ファイル、キータブ ファイル。 バックアップと復元のプロセスの詳細については、Tableau Server のトピック「_Tableau Server の完全なバックアップと復元を実行します_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/backup_restore.htm)) を参照してください。 導入のこの段階で、`tsm maintenance backup` コマンドと `tsm settings export` コマンドを実行することにより、完全な復元に必要なすべての関連ファイルとアセットを含めます。 1. 次のコマンドを実行して、構成とトポロジの設定を `ts_settings_backup.json` というファイルにエクスポートします。 tsm settings export -f ts\_settings\_backup.json 2. 次のコマンドを実行して、リポジトリとファイル ストア データのバックアップを `ts_backup-.tsbak` という名前のファイルに作成します。ファイル ストアがコントローラー ノードにないという警告は無視してかまいません。 tsm maintenance backup -f ts\_backup -d --skip-compression バックアップ ファイルの場所: `/data/tableau_data/data/tabsvc/files/backups/` 3. 両方のファイルをコピーして、Tableau Server の導入で共有していない別のストレージ アセットに保存します。 [メイン コンテンツに進む](#main-content) # パート 5 - Web 層の構成 **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 リファレンス アーキテクチャの Web 層には、次のコンポーネントが含まれている必要があります。 - Tableau クライアントから HTTPS 要求を受け入れ、リバース プロキシ サーバーと通信する Web 用アプリケーション ロード バランサー。 - リバース プロキシ:  - Tableau Server の独立したゲートウェイを導入することをお勧めします。 - 冗長性とクライアント負荷の処理のために、少なくとも 2 台のプロキシ サーバーを使用することをお勧めします。 - ロード バランサーから HTTPS トラフィックを受け取ります。 - Tableau ホストへのスティッキー セッションをサポートします。 - ゲートウェイ プロセスを実行している各 Tableau Server へのラウンド ロビン負荷分散用のプロキシを構成します。 - 外部 IdP からの認証要求を処理します。 - フォワード プロキシ: Tableau Server は、ライセンス認証とマップ機能のためにインターネットへアクセスできる必要があります。フォワード プロキシの許可リストに Tableau サービスの URL を設定する必要があります。「_インターネットとの通信_」 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/plan_network.htm)) を参照してください。 - クライアント関連のすべてのトラフィックは、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 の独立したゲートウェイでもかまいません。 ![上の図に示されている手順。ステップ 1: Tableau クライアントが、Tableau Server のリソースを要求します。ステップ 2: リバース プロキシが、ID プロバイダーへの URL リダイレクトを使用して認証要求を作成します。ステップ 3: ID プロバイダーが、ログイン フォームをユーザーに送信します。ステップ 4: ユーザーにプロンプトが表示され、ユーザーが認証資格情報を入力します。ステップ 5: ID プロバイダーが、ユーザーによって送信された認証資格情報を確認します。ステップ 6: ID プロバイダーが、リバース プロキシ サービス プロバイダーに渡される埋め込み SAML アサーションを使用してクライアントに応答します。ステップ 7: プロキシ上のサービス プロバイダーが、アサーションを検証し、セッションを作成してから、Tableau Server 上のサービス プロバイダーにリダイレクトします。ステップ 8: Tableau Server 上のサービス プロバイダーが、ID プロバイダーへの認証要求を作成します。ステップ 9: ID プロバイダーが、現在のセッションを検証します。ステップ 10: Tableau Server 上のサービス プロバイダーが、独自のセッションを検証および作成し、応答をユーザーに送信します。ステップ 11: ユーザーが、指定されたリソースへの承認のために Tableau Server に接続します。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/pixel-transparent.png) ## 構成の概要 これは、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 層](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part_app-apache.htm)」を参照してください。 この構成例には、次のコンポーネントが含まれています。 - 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 のインストールと構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm)」で説明されているように、バージョン 22.1.1 (またはそれ以降) を 4 ノードの Tableau Server クラスタにインストールします。 3. 「[ホスト コンピューターを構成する](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm#Install)」で説明されているように、パブリック セキュリティ グループに 2 つのプロキシ EC2 インスタンスを構成します。 ### 独立したゲートウェイのインストール Tableau Server の独立したゲートウェイには、Advanced Management ライセンスが必要です。 Tableau Server の独立したゲートウェイは、.rpm パッケージをインストールして実行し、初期状態を設定することにより導入します。このガイドの手順は、参照アーキテクチャに導入するための規範的なガイダンスです。 導入環境が参照アーキテクチャと異なる場合は、Tableau Server のコア ドキュメントである「_独立したゲートウェイを使用した Tableau Server のインストール_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_tsig_new_install.htm))」を参照してください。 **重要**: 独立したゲートウェイを構成する作業は、エラーが発生しやすいプロセスです。独立したゲートウェイ サーバーの 2 つのインスタンス間で構成の問題をトラブルシューティングすることは非常に困難です。このため、独立したゲートウェイ サーバーは一度に 1 つ構成することをお勧めします。最初のサーバーを構成した後、機能を確認してから、2 つ目の独立したゲートウェイ サーバーを構成します。 独立したゲートウェイの各サーバーは別々に設定しますが、Public セキュリティ グループにインストールした両方の EC2 インスタンスで次のインストール手順を実行します。  1. アップデートを実行して、Linux OS に最新の修正を適用します。 sudo yum update 2. Apache がインストールされている場合は、Apache を削除します。 sudo yum remove httpd 3. バージョン 2022.1.1 以降の独立したゲートウェイのインストール パッケージを [Tableau ダウンロード ページ](https://www.tableau.com/ja-jp/support/releases/server)から、Tableau Server を実行するホスト コンピューターにコピーします。 たとえば、Linux RHEL のようなオペレーティング システムを実行しているコンピューターでは、次のコマンドを実行します。 wget https://downloads.tableau.com/esdalt/2022/tableau-server-tsig-.x86\_64.rpm 4. インストール プログラムを実行します。たとえば、Linux RHEL のようなオペレーティング システムでは、次のコマンドを実行します。 sudo yum install .x86\_64.rpm 5. `/opt/tableau/tableau_tsig/packages/scripts./` ディレクトリに変更し、そのディレクトリにあるスクリプト `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 へのプロセスではまだサポートされていません。 Tableau Server と独立したゲートウェイの間で TLS を実行するには、リレー接続を使用して構成する必要があります。EDG のサンプル シナリオは、リレー接続を使用して構成されています。 1. `tsig.json` を Tableau Server 展開のノード 1 に移動します。 2. ノード 1 で次のコマンドを実行して、独立ゲートウェイを有効にします。 tsm stop tsm configuration set -k gateway.tsig.proxy\_tls\_optional -v none tsm pending-changes apply tsm topology external-services gateway enable -c tsig.json tsm start 直接接続は TLS をサポートしていないため、すべてのネットワーク トラフィックを他の手段で保護できる場合にのみ、直接接続を構成することをお勧めします。Tableau Server と独立したゲートウェイの間で TLS を実行するには、リレー接続を使用して構成する必要があります。EDG のサンプル シナリオは、リレー接続を使用して構成されています。 独立したゲートウェイを Tableau Server に直接接続するように構成している場合は、通信をトリガーするように構成を有効にする必要があります。Tableau Server が独立したゲートウェイと通信すると、プロトコルのターゲットが確立されます。次に、`proxy_targets.csv` を独立したゲートウェイのコンピューターから取得する必要があります。AWS のパブリック セキュリティ グループからプライベート セキュリティ グループへの対応するポートを開きます。 1. `tsig.json` を Tableau Server 展開のノード 1 に移動します。 2. ノード 1 で次のコマンドを実行して、独立ゲートウェイを有効にします。 tsm stop tsm topology external-services gateway enable -c tsig.json tsm start 3. 独立したゲートウェイのコンピューターで次のコマンドを実行して、Tableau Server クラスタが使用しているポートを表示します。 less /var/opt/tableau/tableau\_tsig/config/httpd/proxy\_targets.csv 4. AWS セキュリティ グループを構成します。`proxy_targets.csv` にリストされている TCP ポートを追加し、パブリック セキュリティ グループからプライベート セキュリティ グループへの通信を許可します。 Tableau Server 展開が変更されるとポートが変更される可能性があるため、ポート入力構成を自動化することをお勧めします。Tableau Server 展開にノードを追加したり、プロセスを再構成したりすると、Independent Gateway が必要とするポート アクセスが変更されます。 ### 検証: 基本トポロジ構成 `http://` をブラウザーに表示すると、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 アプリケーション ロード バランサーの構成 ロード バランサーを HTTP リスナーとして構成します。ここでの手順では、AWS にロード バランサーを追加する方法について説明します。 #### ステップ 1: ターゲット グループの作成 ターゲット グループは、プロキシ サーバーを実行する EC2 インスタンスを定義する AWS 構成です。これらは、LBS からの通信のターゲットになります。 1. \[EC2\] > \[ターゲット グループ\] > \[ターゲット グループの作成\] の順に選択 2. \[作成\] ページで次を実行 - ターゲット グループ名を入力 (例: `TG-internal-HTTP`) - ターゲット タイプ: インスタンス - プロトコル: HTTP - ポート: 80 - VPC: お使いの VPC を選択 - \[ヘルス チェック\] > \[ヘルス チェックの詳細設定\] > \[成功コード\] で、読み取るコードの一覧 `200,303` を追加します。 - \[作成\] をクリック 3. 作成したターゲット グループを選択し、\[ターゲット\] タブをクリックします。  - \[編集\] をクリックします。 - プロキシ アプリケーションを実行している EC2 インスタンス (または一度に 1 つずつ構成している場合は単一のインスタンス) を選択し、\[登録済みに追加\] をクリックします。 - \[保存\] をクリックします。 #### ステップ 2: ロード バランサー ウィザードの起動 1. \[EC2\] > \[ロード バランサー\] > \[ロード バランサーの作成\] を選択 2. \[ロード バランサーの種類の選択\] ページで、アプリケーション ロード バランサーを作成 **注**: ロードバランサーを構成するために表示される UI は、AWS データセンター全体で一貫性がありません。以下の「ウィザードの構成」の手順は、**ステップ 1 ロードバランサーの構成**から始まる AWS 構成ウィザードにマッピングされます。  データセンターですべての構成が単一のページに表示され、ページの下部に **\[ロード バランサーの作成\]** ボタンが含まれている場合は、以下の「単一ページの構成」の手順に従います。 1. \[ロード バランサーの構成\] ページで次を実行 - 名前を指定 - スキーム: インターネットへ接続 (デフォルト) - IP アドレス タイプ: ipv4 (デフォルト) - リスナー (リスナーとルーティング): 1. HTTP リスナーは既定のままにします 2. \[リスナーの追加\] をクリックして `HTTPS:443` を追加します - VPC: すべてをインストールした VPC を選択 - アベイラビリティー ゾーン: - データセンターのリージョンとして **a** と **b** を選択 - 対応する各ドロップダウンから、パブリック サブネット (プロキシ サーバーがある場所) を選択 - \[セキュリティ設定の構成\] をクリック 2. \[セキュリティ設定の構成\] ページで次を実行 - パブリック SSL 証明書をアップロード - \[次へ: セキュリティ グループの構成\] をクリック 3. \[セキュリティ グループの構成\] ページで次を実行 - パブリック セキュリティ グループを選択します。既定のセキュリティ グループが選択されている場合は、その選択をクリアする - \[次へ: ルーティングの構成\] をクリック 4. \[ルーティングの構成\] ページで次を実行 - ターゲット グループ: 既存のターゲット グループ - 名前: 以前に作成したターゲット グループを選択 - \[次へ: ターゲットの登録\] をクリック 5. \[ターゲットの登録\] ページで次を実行 - 以前に構成した 2 つのプロキシ サーバー インスタンスが表示される - \[次へ: レビュー\] をクリック 6. \[レビュー\] ページで次を実行 \[作成\] をクリックします。 基本構成 - 名前を指定 - スキーム: インターネットへ接続 (デフォルト) - IP アドレス タイプ: ipv4 (デフォルト) ネットワーク マッピング - VPC: すべてをインストールした VPC を選択 - マッピング: - データセンターのリージョンとして、**a** と **b** (または同等の) アベイラビリティー ゾーンを選択 - 対応する各ドロップダウンから、パブリック サブネット (プロキシ サーバーがある場所) を選択 セキュリティ グループ - パブリック セキュリティ グループを選択します。既定のセキュリティ グループが選択されている場合は、その選択をクリアする リスナーとルーティング - HTTP リスナーは既定のままにします。\[Default action (既定のアクション)\] で、以前設定したターゲット グループを指定します。 - \[リスナーの追加\] をクリックして `HTTPS:443` を追加します。\[Default action (既定のアクション)\] で、以前設定したターゲット グループを指定します。 セキュリティで保護されたリスナー設定 - パブリック SSL 証明書をアップロード \[ロード バランサーの作成\] をクリックします。 #### ステップ 3: スティッキネスの有効化 1. ロード バランサーを作成したら、ターゲット グループでスティッキネスを有効にする必要がある - AWS ターゲット グループ ページ (\[EC2\] > \[ロード バランス\] > \[ターゲット グループ\]) を開き、セットアップしたロード バランサーのインスタンスを選択します。\[アクション\] メニューで \[属性の編集\] を選択します。 - \[属性の編集\] ページで \[スティッキー\] を選択して、期間 "`1 day`" を指定し、\[変更を保存\] します。 2. ロード バランサーで、HTTP リスナーのスティッキネスを有効化。構成したロード バランサーを選択し、\[リスナー\] タブをクリックする - \[HTTP:80\] で、\[ルールの表示/編集\] をクリックします。表示される \[ルール\] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。既存の THEN ルールを削除し、\[アクションの追加\] > \[転送先...\] をクリックしてルールを置き換えます。結果の THEN 構成で、作成したものと同じターゲット グループを指定します。\[Group-level stickiness (グループ レベルのスティッキー)\] で、スティッキーを有効にし、期間を 1 日に設定します。設定を保存し、\[更新\] をクリックします。 #### ステップ 4: ロード バランサーでアイドル タイムアウトを設定する ロード バランサーで、アイドル タイムアウトを 400 秒に更新します。 この展開で構成したロード バランサーを選択し、\[アクション\] > \[属性の編集\] の順にクリックします。アイドル タイムアウトを `400` 秒に設定し、\[保存\] をクリックします。 #### ステップ 5: LBS 接続の検証 \[EC2\] > \[ロード バランサー\] から \[AWS ロード バランサー\] ページを開き、設定したロード バランサー インスタンスを選択します。 \[説明\] で DNS 名をコピーしてブラウザーに貼り付け、Tableau Server のサインイン ページにアクセスします。 500 レベルのエラーが発生した場合は、プロキシ サーバーを再起動する必要がある場合があります。 ### パブリック 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 サービス プロバイダー用です。 ### Tableau 管理者アカウントの作成 SAML を構成する際のよくある間違いは、SSO を有効にする前に、Tableau Server で管理者アカウントを作成するのを忘れることです。 最初のステップでは、サーバー管理者ロールを持つ Tableau Server でアカウントを作成します。Okta シナリオの例では、ユーザー名は、user@example.com などの有効なメール アドレスの形式である必要があります。このユーザーのパスワードを設定する必要がありますが、SAML を構成した後はパスワードは使用されません。 ### Okta 事前認証アプリケーションの構成 このセクションで説明するエンドツーエンドのシナリオには、2 つの Okta アプリケーションが必要です。 - Okta 事前認証アプリケーション - Okta Tableau Server アプリケーション これらの各アプリケーションは、リバース プロキシと Tableau Server でそれぞれ構成する必要がある異なるメタデータに関連付けられています。 この手順では、Okta 事前認証アプリケーションを作成および構成する方法について説明します。このトピックの後半で、Okta Tableau Server アプリケーションを作成します。ユーザー制限が設定されている無料のテスト Okta アカウントについては、[Okta Developer Web ページ](https://developer.okta.com/signup/)を参照してください。 Mellon 事前認証サービス プロバイダー用の SAML アプリ統合を作成します。 1. Okta 管理ダッシュボード > \[アプリケーション\] > \[アプリ統合の作成\] を開きます。 2. \[新しいアプリ統合の作成\] ページで \[SAML 2.0\] を選択し、\[次へ\] をクリックします。 3. \[一般設定\] タブでアプリ名 (たとえば、`Tableau Pre-Auth`) を入力し、\[次へ\] をクリックします。 4. \[SAML の構成\] タブで、次を設定します。 - シングル サインオン (SSO) URLシングル サインオン URL のパスの最後の要素は、この手順の後半で説明する `mellon.conf` 構成ファイルの中で `MellonEndpointPath` と呼ばれます。必要なエンドポイントを指定できます。この例では `sso` がエンドポイントです。`https://tableau.example.com/sso/postResponse` の最後の要素 `postResponse` は必須です。 - \[Use this for Recipient URL and Destination URL (受信者 URL と宛先 URL 用に使用する)\] チェックボックスをオフにします。 - 受信者 URL: SSO URL と同じですが、HTTP を使用します。たとえば、`http://tableau.example.com/sso/postResponse` のように使用します。 - 宛先 URL: SSO URL と同じですが、HTTP を使用します。たとえば、`http://tableau.example.com/sso/postResponse` のように使用します。 - オーディエンス URI (SP エンティティ ID): たとえば、`https://tableau.example.com` のように使用します。 - 名前 ID の形式: `EmailAddress`。 - アプリケーションのユーザー名: `Email`。 - 属性ステートメント: 名前 = `mail`。名前の形式 = `Unspecified`。値 = `user.email`。 \[次へ\] をクリックします。 5. \[フィードバック\] タブで、次を選択します。 - \[I'm an Okta customer adding an internal app (私は Okta の顧客であり、内部アプリを追加しています)\] - \[これは私たちが作成した内部アプリです\] - \[完了\] をクリックします。 6. 事前認証 IdP メタデータ ファイルを作成します。 - Okta で、\[アプリケーション\] > \[アプリケーション\] > 使用する新しいアプリケーション (例: `Tableau Pre-Auth`) > \[サインオン\] を選択します。 - \[SAML Signing Certificates (SAML 署名証明書)\] の横にある \[View SAML setup instructions (SAML セットアップ手順の表示)\] をクリックします。 - \[How to Configure SAML 2.0 for Application ( アプリケーションの SAML 2.0 を構成する方法)\] ページで、\[Optional (オプション)\] セクションの \[Provide the following IDP metadata to your SP provider (次の IDP メタデータを SP プロバイダーに指定する)\] まで下にスクロールします。 - XML フィールドのコンテンツをコピーして、`pre-auth_idp_metadata.xml` というファイルに保存します。 7. (オプション) 多要素認証を構成します。 - Okta で、\[アプリケーション\] > \[アプリケーション\] > 使用する新しいアプリケーション (例: `Tableau Pre-Auth`) > \[サインオン\] を選択します。 - \[サインオン ポリシー\] の下で、\[ルールの追加\] をクリックします。 - \[アプリのサインオン ルール\]で、名前とさまざまな MFA オプションを指定します。機能をテストするには、すべてのオプションを既定のままにします。ただし、\[アクション\] で、\[係数の確認\] を選択してから、ユーザーがサインインする必要がある頻度を指定する必要があります。\[保存\] をクリックします。 ### Okta ユーザーの作成と割り当て 1. Okta で、\[ディレクトリ\] > \[ユーザー\] > \[ユーザーの追加\] を選択し、Tableau で作成したのと同じユーザー名 (user@example.com) でユーザーを作成します。 2. ユーザーが作成されたら、新しい Okta アプリをそのユーザーに割り当てます。ユーザー名をクリックしてから、\[アプリケーションの割り当て\] でアプリケーションを割り当てます。 ### 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` を入力します。 AuthType Mellon MellonEnable auth Require valid-user MellonCookieDomain 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 MellonEnable Off 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 アプリケーションを作成 1. Okta ダッシュボードで、\[アプリケーション\] > \[アプリケーション\] > \[アプリ カタログの参照\] を選択します。 2. \[アプリ統合カタログの参照\] で、`Tableau` を検索して、Tableau Server タイルを選択し、\[追加\] をクリックします。 3. \[Tableau Server の追加\] > \[一般設定\] を選択して、ラベルを入力し、\[次へ\] をクリックします。 4. \[サインオン オプション\] で \[SAML 2.0\] を選択してから、\[サインオンの詳細設定\] まで下にスクロールします。 - \[SAML エンティティ ID\]: パブリック URL (たとえば、https://tableau.example.com) を入力します。 - \[アプリケーションのユーザー名の形式\] では、メールを指定します。 5. \[Identity Provider metadata (アイデンティティ プロバイダーのメタデータ)\] リンクをクリックして、ブラウザーを起動します。ブラウザーのリンクをコピーします。このリンクは、次の手順で Tableau を構成するときに使用します。 6. \[完了\] をクリックします。 7. 新しい Tableau Server Okta アプリをユーザー (user@example.com) に割り当てます。ユーザー名をクリックし、\[アプリケーションの割り当て\] でアプリケーションを割り当てます。 ### 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 を有効化 Tableau Server ノード 1 で次の手順を実行します。 1. Okta から Tableau Server アプリケーションのメタデータをダウンロードします。前の手順で保存したリンクを使用します。 wget https://dev-66144217.okta.com/app/exk1egxgt1fhjkSeS5d7/sso/saml/metadata -O idp\_metadata.xml 2. TLS 証明書および関連するキー ファイルを Tableau Server にコピーします。キー ファイルは RSA キーである必要があります。SAML 証明書と IdP 要件の詳細については、_「SAML 要件」_を参照してください ([Linux](https://help.tableau.com/current/server-linux/ja-jp/saml_requ.htm))。 証明書の管理と展開を簡素化するため、およびセキュリティのベスト プラクティスとして、信頼性の高い主要なサード パーティーの認証局 (CA) によって生成された証明書を使用することをお勧めします。または、自己署名証明書を生成するか、TLS 用の PKI からの証明書を使用することもできます。 TLS 証明書を持っていない場合は、以下の埋め込み手順に従って自己署名証明書を生成できます。 自己署名証明書の生成 Tableau Server ノード 1 でこの手順を実行します。 1. ルート認証局 (CA) の署名キーを生成します。 openssl genrsa -out rootCAKey-saml.pem 2048 2. ルート CA 証明書を作成します。 openssl req -x509 -sha256 -new -nodes -key rootCAKey-saml.pem -days 3650 -out rootCACert-saml.pem 証明書フィールドに値を入力するように求められます。例: Country Name (2 letter code) \[XX\]:US State or Province Name (full name) \[\]:Washington Locality Name (eg, city) \[Default City\]:Seattle Organization Name (eg, company) \[Default Company Ltd\]:Tableau Organizational Unit Name (eg, section) \[\]:Operations Common Name (eg, your name or your server's hostname) \[\]:tableau.example.com Email Address \[\]:example@tableau.com 3. 証明書と関連キー (この例では `server-saml.csr` と　`server-saml.key`) を作成します。証明書のサブジェクト名は、Tableau ホストのパブリック ホスト名と一致する必要があります。サブジェクト名は、`-subj` オプションと `"/CN="` の形式を使用して設定します。例: openssl req -new -nodes -text -out server-saml.csr -keyout server-saml.key -subj "/CN=tableau.example.com" 4. 上記で作成した CA 証明書を使用して、新しい証明書に署名します。次のコマンドも `crt` 形式で証明書を出力します。 openssl x509 -req -in server-saml.csr -days 3650 -CA rootCACert-saml.pem -CAkey rootCAKey-saml.pem -CAcreateserial -out server-saml.crt 5. キー ファイルを RSA に変換します。Tableau では、SAML 用の RSA キー ファイルが必要です。キーを変換するには、次のコマンドを実行します。 openssl rsa -in server-saml.key -out server-saml-rsa.key 3. SAML を構成します。次のコマンドを実行して、エンティティ ID とリターン URL を指定し、メタデータ ファイル、証明書ファイル、キー ファイルへのパスを指定します。 tsm authentication saml configure --idp-entity-id "https://tableau.example.com" --idp-return-url "https://tableau.example.com" --idp-metadata idp\_metadata.xml --cert-file "server-saml.crt" --key-file "server-saml-rsa.key" tsm authentication saml enable 4. 組織で 2021.4 以降の Tableau Desktop を利用している場合は、次のコマンドを実行して、リバース プロキシ サーバーを介した認証を有効にする必要があります。 バージョン 2021.2.1 ～ 2021.3 の Tableau Desktop は、事前認証モジュール (Mellon など) がトップレベル ドメインの Cookie を保持できるように構成されている場合、このコマンドを実行しなくても動作します。 tsm configuration set -k features.ExternalBrowserOAuth -v false 5. 構成の変更を適用します。 tsm pending-changes apply #### 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 の独立したゲートウェイのトラブルシューティング](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part7.htm#Troubles)」を参照してください。 ## 独立したゲートウェイの 2 つ目のインスタンスで認証モジュールを構成 独立したゲートウェイの最初のインスタンスを正常に構成したら、2 つ目のインスタンスをデプロイします。この例は、本トピックで説明する AWS / Mellon / Okta シナリオをインストールするための最終プロセスです。この手順では、このトピック ([独立したゲートウェイのインストール](#Install)) で前述したように、独立したゲートウェイが 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のインストール](#Install))、認証キーを取得する必要があります。 接続ファイルの例 (`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 インスタンスを選択して \[登録済みに追加\] をクリックし、\[保存\] をクリックします。 [メイン コンテンツに進む](#main-content) # パート 6 - インストール後の設定 **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 ## ロード バランサーから Tableau Server への SSL/TLS の構成 一部の組織では、クライアントからバック エンド サービスへのエンドツーエンドの暗号化チャネルが必要です。これまでに説明されている既定のリファレンス アーキテクチャでは、クライアントから組織の Web 層で実行されているロードバランサーへの SSL が指定されています。 このセクションでは、AWS リファレンス アーキテクチャの例を使用して、Tableau Server と独立したゲートウェイの SSL/TLS を設定する方法を説明します。AWS リファレンス アーキテクチャで Apache に SSL/TLS を設定する方法の例については、「[例: AWS リファレンス アーキテクチャで SSL/TLS を設定する](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part_app-apache.htm#Example:)」を参照してください。 現時点では、バックエンドの Tableau Server プロセスは 8000～9000 の範囲で実行され、TLS はサポートされていません。TLS を有効にするには、独立したゲートウェイを構成して、Tableau Server へのリレー接続を使用する必要があります。 この手順では、独立したゲートウェイから Tableau Server、および Tableau Server から独立したゲートウェイへの TLS を有効にして構成する方法を説明します。この手順では、リレー トラフィックを HTTPS/443 で暗号化し、ハウスキーピング トラフィックを HTTPS/21319 で暗号化します。 この例で示している Linux の手順は、RHEL 系ディストリビューションのコマンドです。具体的には、これらのコマンドは Amazon Linux 2 ディストリビューションで開発されたものです。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。 ここでの説明は、本ガイドで紹介している特定の AWS リファレンス アーキテクチャの例を対象とした規範的なものです。そのため、オプションの構成は含まれていません。完全なリファレンス ドキュメントについては、「_Independent Gateway での TLS の構成_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/server_tsig_configure_tls.htm))」を参照してください。 ### TLS を構成する前に TLS の設定は営業時間外に行います。設定するには、Tableau Server を少なくとも 1 回再起動する必要があります。完全な 4 ノードのリファレンス アーキテクチャを展開している場合、再起動には時間がかかることがあります。 - クライアントが HTTP 経由で Tableau Server に接続できることを確認します。独立したゲートウェイを使用した TLS の設定は、複数のステップからなるプロセスであり、トラブルシューティングが必要になる場合があります。そのため、TLS を設定する前に、完全に機能する Tableau Server をまず展開することをお勧めします。 - TLS/SSL 証明書、キー、関連するアセットを用意します。独立したゲートウェイと Tableau Server には SSL 証明書が必要です。証明書の管理と展開を簡素化するため、およびセキュリティのベスト プラクティスとして、信頼性の高い主要なサード パーティーの認証局 (CA) によって生成された証明書を使用することをお勧めします。または、自己署名証明書を生成するか、TLS 用の PKI からの証明書を使用することもできます。 このトピックのサンプル構成では、例として次のアセット名を使用しています。 - `tsig-ssl.crt`: 独立したゲートウェイの TLS/SSL 証明書。 - `tsig-ssl.key`: 独立したゲートウェイ上の `tsig-ssl.crt` のプライベート キー。 - `ts-ssl.crt`: Tableau Server の TLS/SSL 証明書。 - `ts-ssl.key`: Tableau Server 上の `tsig-ssl.crt` のプライベート キー。 - `tableau-server-CA.pem`: Tableau Server コンピューターの証明書を生成する CA のルート証明書。主要な信頼できるサード パーティーからの証明書を使用している場合は、通常、この証明書は不要です。 - `rootTSIG-CACert.pem`: 独立したゲートウェイ コンピューターの証明書を生成する CA のルート証明書。主要な信頼できるサード パーティーからの証明書を使用している場合は、通常、この証明書は不要です。 - SAML には他の証明書とキー ファイル アセットが必要であり、このガイドのパート 5 で詳しく説明しています。 - 実装で証明書チェーン ファイルを使用する必要がある場合は、ナレッジ ベースの記事「[証明書チェーンを持つ証明書を使用するときに、独立したゲートウェイで TLS を構成する](https://kb.tableau.com/articles/HowTo/configure-tls-on-independent-gateway-when-using-intermediate-certificate?lang=ja-jp)」を参照してください。 - IdP にアクセスできることを確認します。認証に IdP を使用している場合は、SSL/TLS を構成した後、IdP で受信者と宛先の URL を変更する必要がある可能性があります。 ### 独立したゲートウェイのコンピューターを TLS 用に構成する TLS を設定する作業は、エラーが発生しやすいプロセスです。独立したゲートウェイの 2 つのインスタンスにまたがるトラブルシューティングには時間がかかる可能性があるため、1 つの独立したゲートウェイのみを使用して EDG 展開で TLS を有効にして構成することをお勧めします。TLS が展開全体で機能することを検証したら、2 つ目の独立したゲートウェイ コンピューターを構成します。 #### ステップ 1: 証明書とキーを独立したゲートウェイのコンピューターに配布する tsig-httpd ユーザーがファイルへの読み取りアクセス権を持っている限り、アセットを任意のディレクトリに配布できます。これらのファイルへのパスは、他の手順で参照されます。このトピックでは、次のように、`/etc/ssl` 以下のパスの例を使用します。 1. 秘密鍵のディレクトリを作成します。 sudo mkdir -p /etc/ssl/private 2. 証明書ファイルとキー ファイルを `/etc/ssl` パスにコピーします。例は次のとおりです。 sudo cp tsig-ssl.crt /etc/ssl/certs/ sudo cp tsig-ssl.key /etc/ssl/private/ 3. (オプション) Tableau Server で SSL/TLS に自己署名証明書または PKI 証明書を使用している場合は、CA ルート証明書ファイルも独立したゲートウェイのコンピューターにコピーする必要があります。例は次のとおりです。 sudo cp tableau-server-CA.pem /etc/ssl/certs/ #### ステップ 2: TLS の環境変数を更新する 独立したゲートウェイ構成のポートとプロトコルの環境変数を更新する必要があります。 ファイル `/etc/opt/tableau/tableau_tsig/environment.bash` を更新して、それらの値を次のように変更します。 TSIG\_HK\_PROTOCOL="https" TSIG\_PORT="443" TSIG\_PROTOCOL="https" #### ステップ 3: HK プロトコルのスタブ構成ファイルを更新する スタブ構成ファイル (`/var/opt/tableau/tableau_tsig/config/httpd.conf.stub`) を手動で編集して、ハウスキーピング (HK) プロトコルの TLS 関連の Apache httpd ディレクティブを設定します。 スタブ構成ファイルには、`#TLS#` マーカーでコメントアウトされた TLS 関連のディレクティブのブロックが含まれています。次の例に示すように、ディレクティブからマーカーを削除します。この例では、`SSLCACertificateFile` オプションを用いて Tableau Server で使用する SSL 証明書にルート CA 証明書を使用しています。 #TLS# SSLPassPhraseDialog exec:/path/to/file SSLEngine on #TLS# SSLHonorCipherOrder on #TLS# SSLCompression off SSLCertificateFile /etc/ssl/certs/tsig-ssl.crt SSLCertificateKeyFile /etc/ssl/private/tsig-ssl.key SSLCACertificateFile /etc/ssl/certs/tableau-server-CA.pem #TLS# SSLCARevocationFile /path/to/file 独立したゲートウェイを再インストールすると、これらの変更は失われます。バックアップ コピーを作成することをお勧めします。 #### ステップ 4: スタブ ファイルをコピーしてサービスを再起動する 1. 最後の手順で更新したファイルをコピーして、httpd.conf を変更して更新します。 cp /var/opt/tableau/tableau\_tsig/config/httpd.conf.stub /var/opt/tableau/tableau\_tsig/config/httpd.conf 2. 独立したゲートウェイのサービスを再起動します。 sudo su - tableau-tsig systemctl --user restart tsig-httpd exit 再起動後、Tableau Server で次の一連の手順を実行するまで、独立したゲートウェイは動作しなくなります。Tableau Server での手順を完了すると、独立したゲートウェイが変更を反映してオンラインになります。 ### Tableau Server ノード 1 を TLS 用に構成する Tableau Server 展開のノード 1 で次の手順を実行します。 #### ステップ 1: 証明書と鍵をコピーして TSM を停止する 1. Tableau Server の「外部 SSL」証明書とキーがノード 1 にコピーされていることを確認します。 2. ダウンタイムを最小限に抑えるために、TSM を停止し、以下のステップを実行して、変更が適用された後に TSM を開始することをお勧めします。 `tsm stop` #### 手順 2: 証明書アセットを設定し、独立したゲートウェイ構成を有効にする 1. 独立したゲートウェイの証明書とキー ファイルの場所を指定します。これらのパスは、独立したゲートウェイのコンピューター上の場所を参照します。この例では、HTTPS とハウスキーピング通信を保護するために、同じ証明書とキーのペアを使用することを前提としています。 tsm configuration set -k gateway.tsig.ssl.cert.file\_name -v /etc/ssl/certs/tsig-ssl.crt --force-keys tsm configuration set -k gateway.tsig.ssl.key.file\_name -v /etc/ssl/private/tsig-ssl.key --force-keys 2. 独立したゲートウェイの HTTPS プロトコルと HK プロトコルで TLS を有効にします。 tsm configuration set -k gateway.tsig.ssl.enabled -v true --force-keys tsm configuration set -k gateway.tsig.hk.ssl.enabled -v true --force-keys 3. (オプション) 独立したゲートウェイで SSL/TLS に自己署名証明書または PKI 証明書を使用している場合は、CA ルート証明書ファイルをアップロードする必要があります。CA ルート証明書ファイルは、独立したゲートウェイ コンピューターの証明書を生成するときに使用されたルート証明書です。例は次のとおりです。 tsm security custom-cert add -c rootTSIG-CACert.pem 4. (オプション) Tableau Server で SSL/TLS に自己署名証明書または PKI 証明書を使用している場合は、CA ルート証明書ファイルも独立したゲートウェイの `/etc/ssl/certs` ディレクトリにコピーする必要があります。CA ルート証明書ファイルは、Tableau Server コンピューターの証明書を生成するときに使用されたルート証明書です。証明書を独立したゲートウェイにコピーした後、次の tsm コマンドを使用して、ノード 1 で証明書の場所を指定する必要があります。例は次のとおりです。 tsm configuration set -k gateway.tsig.ssl.proxy.gateway\_relay\_cluster.cacertificatefile -v /etc/ssl/certs/tableau-server-CA.pem --force-keys 5. (オプション: テスト目的のみ) コンピューター間で自己署名証明書または PKI 証明書を共有していて、証明書のサブジェクト名がコンピューター名と一致しない場合は、証明書の検証を無効にする必要があります。  tsm configuration set -k gateway.tsig.ssl.proxy.verify -v optional\_no\_ca --force-keys #### 手順 3: Tableau Server の「外部 SSL」を有効にして、変更を適用する 1. Tableau Server で「外部 SSL」を有効にして構成します。 tsm security external-ssl enable --cert-file ts-ssl.crt --key-file ts-ssl.key 2. 変更を適用します。 tsm pending-changes apply #### ステップ 4: ゲートウェイ構成の JSON ファイルを更新し、tsm を開始します 1. Tableau Server 側で独立したゲートウェイの構成ファイル (たとえば、`tsig.json`) を更新し、独立したゲートウェイのオブジェクトに `https` プロトコルを指定します。 "protocol" : "https", 2. 独立したゲートウェイの 2 つ目のインスタンスの接続情報を削除 (またはコメントアウト) します。保存する前に、必ず外部エディターで JSON を確認してください。 独立したゲートウェイの単一インスタンスに対して TLS を構成して検証した後、この JSON ファイルを独立したゲートウェイの 2 つ目のインスタンスの接続情報で更新します。 3. 次のコマンドを実行して、独立したゲートウェイの構成を更新します。 tsm topology external-services gateway update -c tsig.json 4. TSM の起動 tsm start 5. TSM の起動中に、独立したゲートウェイのインスタンスにサインインして、`tsig-httpd` サービスを再起動します。 sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### IdP 認証モジュールの URL を HTTPS に更新する 外部の ID プロバイダーを Tableau で設定している場合は、IdP の管理ダッシュボードでリターン URL を更新する必要があります。 たとえば、Okta 事前認証アプリケーションを使用している場合は、受信者 URL と宛先 URL に HTTPS プロトコルを使用するようにアプリケーションを更新する必要があります。 ### AWS ロード バランサーを HTTPS 用に構成する このガイドに記載されているように AWS ロード バランサーを導入する場合は、独立したゲートウェイを実行するコンピューターに HTTPS トラフィックが送信されるように AWS ロード バランサーを設定し直します。 1. 既存の HTTP ターゲット グループを削除します。 \[ターゲット グループ\] で、ロード バランサー用に設定されている HTTP ターゲットグ ループを選択し、\[アクション\] をクリックして \[削除\] をクリックします。 2. HTTPS ターゲット グループを作成します。 \[ターゲット グループ\] > \[ターゲット グループの作成\] - 「インスタンス」を選択 - ターゲット グループ名を入力 (例: `TG-internal-HTTPS`) - VPC を選択 - プロトコル: HTTPS 443 - \[ヘルス チェック\] > \[ヘルス チェックの詳細設定\] > \[成功コード\] で、読み取るコードの一覧 `200,303` を追加します。 - \[作成\] をクリックします。 3. 作成したターゲット グループを選択し、\[ターゲット\] タブをクリックします。  - \[編集\] をクリックします。 - 構成した Tableau Server の独立したゲートウェイを実行している EC2 インスタンスを選択し、\[登録済みに追加\] をクリックします。 - \[保存\] をクリックします。 4. ターゲット グループを作成したら、スティッキー設定を有効にします。 - AWS ターゲット グループ ページ (\[EC2\] > \[ロード バランス\] > \[ターゲット グループ\]) を開き、セットアップしたロード バランサーのインスタンスを選択します。\[アクション\] メニューで \[属性の編集\] を選択します。 - \[属性の編集\] ページで \[スティッキー\] を選択して、期間 "`1 day`" を指定し、\[変更を保存\] します。 5. ロード バランサーで、リスナー ルールを更新します。このデプロイメントで設定したロード バランサーを選択し、\[リスナー\] タブをクリックします。 - \[HTTP:80\] で、\[ルールの表示/編集\] をクリックします。表示される \[ルール\] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。既存の THEN ルールを削除し、\[アクションの追加\] > \[リダイレクト先...\] をクリックしてルールを置き換えます。表示される THEN 設定で、`HTTPS` とポート `443` を指定し、他のオプションはデフォルト設定のままにします。設定を保存し、\[更新\] をクリックします。 - \[HTTPS:443\] で、\[ルールの表示/編集\] をクリックします。表示される \[ルール\] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。既存の THEN ルールを削除し、\[アクションの追加\] > \[転送先...\] をクリックしてルールを置き換えます。作成した HTTPS グループにターゲット グループを指定します。\[Group-level stickiness (グループ レベルのスティッキー)\] で、スティッキーを有効にし、期間を 1 日に設定します。設定を保存し、\[更新\] をクリックします。 6. ロード バランサーで、アイドル タイムアウトを 400 秒に更新します。この展開で構成したロード バランサーを選択し、\[アクション\] > \[属性の編集\] の順にクリックします。アイドル タイムアウトを `400` 秒に設定し、\[保存\] をクリックします。 ## TLS を検証する TLS 機能を検証するには、この手順の最初に作成した Tableau 管理者アカウントからパブリック URL (https://tableau.example.com など) を使用して Tableau Server にサインインします。 TSM が起動しない場合、または他のエラーが表示される場合は、「[Tableau Server の独立したゲートウェイのトラブルシューティング](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part7.htm#Troubles)」を参照してください。 ## 独立したゲートウェイの 2 つ目のインスタンスを SSL 用に構成する 独立したゲートウェイの最初のインスタンスを正常に構成したら、2 つ目のインスタンスをデプロイします。 2 つ目の独立したゲートウェイをデプロイするプロセスでは、次の手順が必要です。 1. 独立したゲートウェイの構成済み (最初の) インスタンス: 次のファイルを、独立したゲートウェイの 2 目のインスタンス上の対応する場所にコピーします。 - `/etc/ssl/certs/tsig-ssl.crt` - `/etc/ssl/private/tsig-ssl.key` (2 つ目のインスタンスで `private` ディレクトリを作成する必要があります) - `/var/opt/tableau/tableau_tsig/config/httpd.conf.stub` - `/etc/opt/tableau/tableau_tsig/environment.bash` 2. Tableau Server 展開のノード 1: 接続ファイル (`tsig.json`) を 2 つ目の独立したゲートウェイの接続情報を使用して更新します。 接続ファイルの例 (`tsig.json`) は次のとおりです。 { "independentGateways": \[ { "id": "ip-10-0-1-169.ec2.internal", "host": "ip-10-0-1-169.ec2.internal", "port": "21319", "protocol" : "https", "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" : "https", "authsecret": "9055-27834-16487-27455-30409-7292" }\] } 3. Tableau Server 展開のノード 1: 次のコマンドを実行して構成を更新します。 tsm stop tsm topology external-services gateway update -c tsig.json tsm start 4. 独立したゲートウェイの両方のインスタンス: Tableau Server が起動しているときに、独立したゲートウェイの両方のインスタンスで `tsig-httpd` プロセスを再起動します。 sudo su - tableau-tsig systemctl --user restart tsig-httpd exit 5. AWS EC2 > ターゲット グループ: ターゲット グループを更新して、2 つ目の独立したゲートウェイのインスタンスを実行している EC2 インスタンスを含めます。 作成したターゲット グループを選択し、\[ターゲット\] タブをクリックします。  - \[編集\] をクリックします。 - 2 つ目の独立したゲートウェイ コンピューターの EC2 インスタンスを選択して \[登録済みに追加\] をクリックし、\[保存\] をクリックします。 ## Postgres の SSL 設定 オプションで、Tableau Server の外部リポジトリ接続に使用する Postgres 接続の SSL (TLS) を設定できます。 証明書の管理と展開を簡素化するため、およびセキュリティのベスト プラクティスとして、信頼性の高い主要なサード パーティーの認証局 (CA) によって生成された証明書を使用することをお勧めします。または、自己署名証明書を生成するか、TLS 用の PKI からの証明書を使用することもできます。 この手順では、AWS リファレンス アーキテクチャの例に挙げ、RHEL 系 Linux ディストリビューションの Postgres ホストで、OpenSSL を使用して自己署名証明書を生成する方法について説明します。 SSL 証明書を生成して署名したら、CA 証明書を Tableau ホストにコピーする必要があります。 **Postgress を実行しているホストの設定** 1. ルート認証局 (CA) の署名キーを生成します。 openssl genrsa -out pgsql-rootCAKey.pem 2048 2. ルート CA 証明書を作成します。 openssl req -x509 -sha256 -new -nodes -key pgsql-rootCAKey.pem -days 3650 -out pgsql-rootCACert.pem 証明書フィールドに値を入力するように求められます。例: Country Name (2 letter code) \[XX\]:US State or Province Name (full name) \[\]:Washington Locality Name (eg, city) \[Default City\]:Seattle Organization Name (eg, company) \[Default Company Ltd\]:Tableau Organizational Unit Name (eg, section) \[\]:Operations Common Name (eg, Postgres server's hostname) \[\]:ip-10-0-1-189.us-west-1.compute.internal Email Address \[\]:example@tableau.com 3. Postgres コンピューターの証明書と関連キー (以下の例の `server.csr` と　`server.key`) を作成します。証明書のサブジェクト名は、Postgres ホストの EC2 プライベート DNS 名と一致する必要があります。サブジェクト名は、`-subj` オプションと `"/CN="` の形式を使用して設定します。例: openssl req -new -nodes -text -out server.csr -keyout server.key -subj "/CN=ip-10-0-1-189.us-west-1.compute.internal" 4. 手順 2 で作成した CA 証明書を使用して新しい証明書に署名します。次のコマンドも `crt` 形式で証明書を出力します。 openssl x509 -req -in server.csr -days 3650 -CA pgsql-rootCACert.pem -CAkey pgsql-rootCAKey.pem -CAcreateserial -out server.crt 5. Crt ファイルとキー ファイルを Postgres `/var/lib/pgsql/13/data/` パスにコピーします。 sudo cp server.crt /var/lib/pgsql/13/data/ sudo cp server.key /var/lib/pgsql/13/data/ 6. root ユーザーに切り替えます。 sudo su 7. cer ファイルとキー ファイルにパーミッションを設定します。次のコマンドを実行します。 cd /var/lib/pgsql/13/data chown postgres.postgres server.crt chown postgres.postgres server.key chmod 0600 server.crt chmod 0600 server.key 8. Pg\_haba 構成ファイル `/var/lib/pgsql/13/data/pg_hba.conf` を更新して md5 の信頼を指定します。 既存の接続ステートメントを `host all all 10.0.30.0/24 password`、 `host all all 10.0.31.0/24 password` から `host all all 10.0.30.0/24 md5`、 `host all all 10.0.31.0/24 md5` に変更します。 9. 次の行を追加して、Postgresql ファイル `/var/lib/pgsql/13/data/postgresql.conf` を更新します。 ssl = on 10. root ユーザー モードを終了します。 exit 11. Postgres を再起動します。 sudo systemctl restart postgresql-13 ### オプション: Tableau Server で Postgres SSL の証明書の信頼性検証を有効にする 「[パート 4 - Tableau Server のインストールと構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm)」のインストール手順を実行した場合、Tableau Server は、Postgres 接続用のオプションの SSL で構成されています。つまり、Postgres SSL を構成すると (上記の説明に従って)、接続が暗号化されます。 接続に対して証明書の信頼性検証が必要な場合は、Tableau Server で次のコマンドを実行して、Postgres ホスト接続を構成する必要があります。 tsm topology external-services repository replace-host -f .json -c CACert.pem ここで、`.json` は、「[外部 Postgres の構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Configur3)」で説明した接続ファイルです。`CACert.pem` は、Postgres が使用する SSL/TLS 証明書の CA 証明書ファイルです。 オプション: SSL 接続を検証します。 SSL 接続を検証するには、次の操作を実行する必要があります。 - Tableau Server ノード 1 に Postgres クライアントをインストールします。 - 前の手順で作成したルート証明書を Tableau ホストにコピーします。 - ノード 1 から Postgres サーバーに接続します。 ### ノード 1 に Postgres クライアントをインストールする この例では、Postgres バージョン 13.4 をインストールする方法を示しています。外部リポジトリ用に実行しているバージョンと同じバージョンをインストールします。 1. ノード 1 で、`/etc/yum.repos.d` パスに pgdg repo. ファイルを作成して編集します。次の構成情報をファイルに入力します。 \[pgdg13\] name=PostgreSQL 13 for RHEL/CentOS 7 - x86\_64 baseurl=https://download.postgresql.org/pub/repos/yum/13/redhat/rhel-7-x86\_64 enabled=1 gpgcheck=0 2. Postgres クライアントをインストールします。 sudo yum install postgresql13-13.4-1PGDG.rhel7.x86\_64 ### ルート証明書をノード 1 にコピーする CA 証明書 (`pgsql-rootCACert.pem`) を Tableau ホストにコピーします。 scp ec2-user@:/home/ec2-user/pgsql-rootCACert.pem /home/ec2-user ### ノード 1 から SSL 経由で Postgres ホストに接続する ノード 1 から次のコマンドを実行して、Postgres サーバーのホスト IP アドレスとルート CA 証明書を指定します。 psql "postgresql://postgres@:5432/postgres?sslmode=verify-ca&sslrootcert=pgsql-rootCACert.pem" 例: psql "postgresql://postgres@10.0.1.189:5432/postgres?sslmode=verify-ca&sslrootcert=pgsql-rootCACert.pem" Postgres からパスワードの入力を求められます。サインインに成功すると、シェルは次を返します。 psql (13.4) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help. postgres=# ## SMTP およびイベント通知の設定 Tableau Server は、管理者とユーザーにメール通知を送信します。この設定を有効にするには、利用しているメール サーバーにメールを送信するように Tableau Server を設定する必要があります。イベント タイプ、しきい値、送信するサブスクリプション情報も指定する必要があります。 SMTP と通知の初期設定では、次の設定ファイル テンプレートを使用して json ファイルを作成することをお勧めします。_tsm configuration set_ で説明されている構文を使用して、以下に記載の単一の構成キーを設定することもできます (([Linux](https://help.tableau.com/current/server-linux/ja-jp/cli_configuration_tsm.htm#TSMSet))。 Tableau Server デプロイメントのノード 1 で次の手順を実行します。 1. 以下の json テンプレートをファイルにコピーします。SMTP 構成オプションと、組織のサブスクリプションおよびアラート通知を使用して、ファイルをカスタマイズします。 - すべての SMTP オプションの一覧と説明を表示するには、「_SMTP CLI 設定リファレンス_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/config_smtp.htm#config_reference))」を参照してください。 - すべての通知イベント オプションの一覧と説明を表示するには、「_サーバー イベント通知_の設定 ([Linux](https://help.tableau.com/current/server-linux/ja-jp/email.htm))」の CLI セクションを参照してください。 { "configKeys": { "svcmonitor.notification.smtp.server": "_SMTP server host name_", "svcmonitor.notification.smtp.send\_account": "_SMTP user name_", "svcmonitor.notification.smtp.port": 443, "svcmonitor.notification.smtp.password": "_SMTP user account password_", "svcmonitor.notification.smtp.ssl\_enabled": true, "svcmonitor.notification.smtp.from\_address": "_From email address_", "svcmonitor.notification.smtp.target\_addresses": "_To email address1,address2_", "svcmonitor.notification.smtp.canonical\_url": "_Tableau Server URL_", "backgrounder.notifications\_enabled": true, "subscriptions.enabled": true, "subscriptions.attachments\_enabled": true, "subscriptions.max\_attachment\_size\_megabytes": 150, "svcmonitor.notification.smtp.enabled": true, "features.DesktopReporting": true, "storage.monitoring.email\_enabled": true, "storage.monitoring.warning\_percent": 20, "storage.monitoring.critical\_percent": 15, "storage.monitoring.email\_interval\_min": 25, "storage.monitoring.record\_history\_enabled": true } } 2. `tsm settings import -f file.json` を実行し、json ファイルを Tableau サービス マネージャーに渡します。 3. `tsm pending-changes apply` コマンドを実行して変更を適用します。 4. `tsm email test-smtp-connection` を実行し、接続構成を表示して検証します。 ## PostgreSQL ドライバーのインストール Tableau Server で管理ビューを表示するには、PostgreSQL ドライバーを Tableau Server 展開のノード 1 にインストールする必要があります。 1. 「[Tableau ドライバーのダウンロード](https://www.tableau.com/ja-jp/support/drivers)」ページに移動し、PostgreSQL jar ファイルの URL をコピーします。 2. Tableau デプロイメントの各ノードで次の手順を実行します。 - 次のファイル パスを作成します。 `sudo mkdir -p /opt/tableau/tableau_driver/jdbc` - 作成したパスへ、PostgreSQL jar ファイルの最新バージョンをダウンロードします。例: `sudo wget https://downloads.tableau.com/drivers/linux/postgresql/postgresql-42.2.22.jar` 4. 初期ノードで、Tableau Server を再起動します。 `tsm restart` ## 強力なパスワード ポリシーの構成 IdP 認証ソリューションを使用して Tableau Server を展開しない場合は、既定の Tableau パスワード ポリシーのセキュリティを強化することをお勧めします。 IdP を使用して Tableau Server を展開する場合は、IdP を使用したパスワード ポリシーの管理が必要になります。 次の手順には、Tableau Server でパスワード ポリシーを構成するための JSON 構成が含まれています。以下のオプションの詳細については、「_ローカル認証_ ([Linux](https://help.tableau.com/current/server-linux/ja-jp/local_auth.htm))」を参照してください。 1. 以下の json テンプレートをファイルにコピーします。ユーザーのパスワードポリシー構成でキー値を埋めます。 { "configKeys": { "wgserver.localauth.policies.mustcontainletters.enabled": true, "wgserver.localauth.policies.mustcontainuppercase.enabled": true, "wgserver.localauth.policies.mustcontainnumbers.enabled": true, "wgserver.localauth.policies.mustcontainsymbols.enabled": true, "wgserver.localauth.policies.minimumpasswordlength.enabled": true, "wgserver.localauth.policies.minimumpasswordlength.value": 12, "wgserver.localauth.policies.maximumpasswordlength.enabled": false, "wgserver.localauth.policies.maximumpasswordlength.value": 255, "wgserver.localauth.passwordexpiration.enabled": true, "wgserver.localauth.passwordexpiration.days": 90, "wgserver.localauth.ratelimiting.maxbackoff.minutes": 60, "wgserver.localauth.ratelimiting.maxattempts.enabled": false, "wgserver.localauth.ratelimiting.maxattempts.value": 5, "vizportal.password\_reset": true } } 2. `tsm settings import -f file.json` を実行し、JSON ファイルを Tableau サービス マネージャーに渡して Tableau Server を構成します。 3. `tsm pending-changes apply` コマンドを実行して変更を適用します。 [メイン コンテンツに進む](#main-content) # パート 7 - 検証、ツール、トラブルシューティング **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 このトピックには、インストール後の検証手順とトラブルシューティング ガイダンスが含まれています。 ## フェールオーバー システムの検証 展開を構成した後、シンプルなフェールオーバー テストを実行して、システムの冗長性を検証することをお勧めします。 フェールオーバー機能を検証するには、次の手順を実行するとよいでしょう。 1. 独立したゲートウェイの最初のインスタンス (TSIG1) をシャットダウンします。すべてのインバウンド トラフィックは、独立したゲートウェイの 2 つ目のインスタンス (TSIG2) を介してルーティングされます。 2. TSIG1 を再起動してから、TSIG2 をシャットダウンします。すべてのインバウンド トラフィックは TSIG1 を介してルーティングされます。 3. TSIG2 を再起動します。 4. Tableau Server ノード 1 をシャットダウンします。すべての Vizportal/アプリケーション サービス トラフィックがノード 2 にフェールオーバーします。 **注:** 2022 年 9 月現在、Tableau Server 2021.4 以降の特定のバージョンで、ノード 1 の高可用性が低下しています。ノード 1 がダウンしている場合、クライアント接続が失敗します。この問題は、以下のメンテナンス リリースで修正済みです。 \- 2021.4.15 以降 \- 2022.1.11 以降 \- 2023.1.3 以降 ATR アクティブ化を使用する Tableau Server インストールで、初期ノードの障害発生後に 72 時間の猶予期間を確保するには、これらのバージョンのいずれかをインストールまたはアップグレードしてください。詳細については、Tableau ナレッジ ベースの「[ATR を使用する Tableau Server HA で初期ノードの障害後の猶予期間が存在しない](https://kb.tableau.com/articles/issue/tableau-server-ha-using-atr-does-not-have-a-grace-period-after-the-initial-node-failure?lang=ja-jp "高可用性の障害に関する Tableau KB の記事")」を参照してください。 5. ノード 1 を再起動し、ノード 2 をシャットダウンします。すべての Vizportal/アプリケーション サービス トラフィックがノード 1 にフェールオーバーします。 6. ノード 2 を再起動します。 このコンテキストでは、事前にアプリケーションの正常なシャットダウンを試みることなく、オペレーティング システムまたは仮想マシンをオフにすることにより、「シャットダウン」または「再起動」を行います。その目的は、ハードウェアや仮想マシンの障害をシミュレーションすることです。 各フェールオーバー テストの最小限の検証手順では、ユーザーで認証し、基本的なビュー操作を実行します。 障害をシミュレーションした後、サインインを試みたときに、「無効な要求」ブラウザ エラーが返される場合があります。ブラウザーのキャッシュをクリアしても、このエラーが表示されることがあります。多くの場合、この問題は、ブラウザーが前の IdP セッションからのデータをキャッシュしているときに発生します。ローカル ブラウザーのキャッシュをクリアした後でもこのエラーが続く場合は、別のブラウザーに接続して Tableau シナリオを検証してください。 ## 初期ノードの自動リカバリ Tableau Server バージョン 2021.2.4 以降には、初期ノードを自動的に回復できるスクリプト `auto-node-recovery` が、スクリプトのディレクトリ (`/app/tableau_server/packages/scripts.`) に含まれています。 初期ノードに問題があり、ノード 2 に冗長プロセスがある場合、Tableau Server が引き続き実行できるという保証はありません。Tableau Server は、初期ノードに障害が発生した後、ライセンス発行サービスの欠如が他のプロセスに影響を与え始めるまで、最大 72 時間実行し続ける可能性があります。初期ノードでエラーが発生しても、ユーザーは引き続きサインインしてコンテンツを表示および使用することはできますが、管理コントローラーへのアクセス権がなくなるため、Tableau Server の再構成ができなくなります。 冗長プロセスで構成されている場合でも、初期ノードに障害が発生すると、Tableau Server が機能し続けることができなくなる可能性があります。 初期ノード (ノード 1) のリカバリ手順は次のとおりです。 1. Tableau Server ノード 2 にサインインします。 2. スクリプトのディレクトリに変更します。 cd /app/tableau\_server/packages/scripts. 3. 次のコマンドを実行してスクリプトを起動します。 sudo ./auto-node-recovery -p node1 -n node2 -k `` は、ご利用の展開のライセンス キーをコンマで区切ったリスト (スペースなし) です。ライセンス キーがわからない場合は、[Tableau カスタマー ポータル](http://customer.tableausoftware.com/?_fsi=v45oWMAM)にアクセスして検索してください。例: sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN auto-node-recovery スクリプトは、約 20 のステップを実行して、サービスをノード 2 に回復します。スクリプトが進むにつれて、各ステップがターミナルに表示されます。より詳細なステータスは `/data/tableau_data/logs/app-controller-move.log` に記録されます。ほとんどの環境では、スクリプトが完了するまでに 35 ～ 45 分かかります。 ### 初期ノード リカバリのトラブルシューティング ノードの回復に失敗した場合は、スクリプトをインタラクティブに実行して、プロセス内の個別のステップを許可または禁止すると便利な場合があります。たとえば、スクリプトがプロセスの途中で失敗した場合は、ログ ファイルを確認し、設定を変更してからスクリプトを再実行できます。インタラクティブ モードで実行することにより、失敗したステップに到達するまですべてのステップをスキップできます。 インタラクティブ モードで実行するには、スクリプトの引数に `-i` スイッチを追加します。 ### 障害が発生したノードを再構築します。 スクリプトを実行すると、ノード 2 では、以前は障害が発生したノード 1 ホスト上にあったすべてのサービスが実行されます。4 ノードを追加するには、bootstrap ファイルを使用して新しい Tableau Server ホストを展開し、パート 4 で指定した元のノード 2 と同じように構成する必要があります。「[ノード 2 の構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Configur2)」を参照してください。 ## switchto switchto は、ウィンドウ間の切り替えを容易にする Tim のスクリプトです。 1. 要塞ホストのホーム ディレクトリにある `switchto` というファイルに、次のコードをコピーします。 #!/bin/bash #------------------------------------------------------------------- # switchto # # Helper function to simplify SSH into the various AWS hosts when # following the Tableau Server Enterprise Deployment Guide (EDG). # # Place this file on your bastion host and provide your AWS hosts' # internal ip addresses or machine names here. # Example: readonly NODE1="10.0.3.187" # readonly NODE1="" readonly NODE2="" readonly NODE3="" readonly NODE4="" readonly PGSQL="" readonly PROXY1="" readonly PROXY2="" usage() { echo "Usage: switchto.sh \[ node1 | node2 | node3 | node4 | pgsql | proxy1 | proxy2 \]" } ip="" case $1 in node1) ip="$NODE1" ;; node2) ip="$NODE2" ;; node3) ip="$NODE3" ;; node4) ip="$NODE4" ;; pgsql) ip="$PGSQL" ;; proxy1) ip="$PROXY1" ;; proxy2) ip="$PROXY2" ;; ?) usage exit 0 ;; \*) echo "Unkown option $1." usage exit 1 ;; esac if \[\[ -z $ip \]\]; then echo "You must first edit this file to provide the ip addresses of your AWS hosts." exit 1 fi ssh -A ec2-user@$ip 3. スクリプトの IP アドレスを更新して EC2 インスタンスにマッピングし、ファイルを保存します。 4. スクリプト ファイルにパーミッションを適用します。 sudo chmod +x switchto 使用方法: ホストを切り換えるには、次のコマンドを実行します。 `./switchto ` たとえば、ノード 1 に切り換えるには、以下のコマンドを実行します。 `./switchto node1` ## Tableau Server の独立したゲートウェイのトラブルシューティング 独立したゲートウェイ、Okta、Mellon、Tableau Server の SAML を構成する作業は、エラーが発生しやすいプロセスです。失敗の最も一般的な根本原因は文字列エラーです。たとえば、構成中に指定した Okta URL に末尾のスラッシュ (`/`) があることにより、SAML アサーション関連の不一致エラーが発生する可能性があります。これはほんの一例です。構成中に、誤った文字列を任意のアプリケーションで入力する機会がたくさんあります。 ### tableau-tsig サービスの再起動 トラブルシューティングを開始 (および終了) するには、独立したゲートウェイ コンピューターで tableau-tsig サービスを常に再起動します。このサービスの再起動は迅速であり、多くの場合、更新された構成がこれをトリガーにして Tableau Server からロードされます。 独立したゲートウェイ コンピューターで次のコマンドを実行します。 sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### 間違った文字列を見つける 文字列エラー (コピー/貼り付けの間違い、文字列の切り捨てなど) が発生した場合は、構成した各設定を時間をかけて一通り確認してください。 - Okta の事前認証の設定。設定した URL を注意深く確認してください。末尾のスラッシュを探します。HTTP か HTTPS かを確認します。 - ノード 1 での SAML 構成のシェル履歴。実行した `tsm authentication saml configure` コマンドを確認します。すべての URL が Okta で設定したものと一致することを確認します。ノード 1 のシェル履歴を確認する際に、`tsm configuration set` コマンドで指定した Mellon 構成ファイル パスが、独立したゲートウェイ上の、ファイルのコピー元のファイル パスに厳密にマッピングされていることを検証します。 - 独立したゲートウェイでの Mellon 構成。シェル履歴を確認して、Okta および Tableau SAML で設定したものと同じ URL 文字列でメタデータを作成していることを確認します。`/etc/mellon/conf.d/global.conf` で指定されているすべてのパスが正しく、`MellonCookieDomain` が Tableau サブドメインではなく、ルート ドメインに設定されていることを確認します。 ### 関連するログの検索 すべての文字列が正しく設定されているようであれば、ログにエラーがないか調べます。 Tableau Server は、エラーとイベントを数十の異なるログ ファイルに記録します。独立したゲートウェイも、一連のローカル ファイルにログを記録します。これらのログは、次の順序で検査することをお勧めします。 #### 独立したゲートウェイのログ ファイル 独立したゲートウェイのログ ファイルは、デフォルトでは `/var/opt/tableau/tableau_tsig/logs` にあります。 - `access.log`: このログは、Tableau Server ノードからの接続を示すエントリがあるので役立ちます。TSM を開始しようとしたときに、ゲートウェイ エラーが発生して開始できず、`access.log` ファイルにはエントリがない場合、コア接続に問題があります。最初のステップとして、AWS セキュリティ グループの設定を常に確認してください。もう 1 つの一般的な問題は、`tsig.json` のタイプミスです。tsig.json を更新する場合は、 `tsm topology external-services gateway update -c tsig.json` を実行する前に `tsm stop` を実行します。tsig.json が更新されたら、`tsm start` を実行します。 - `error.log`: このログには SAML および Mellon に関するエラーが含まれています。 #### Tableau Server の tabadminagent ログ ファイル 一連の `tabadminagent` (`tabadmincontroller` ではない) ファイルは、独立したゲートウェイ関連のエラーのトラブルシューティングに利用できる唯一のログ ファイルです。 独立したゲートウェイのエラーが `tabdminagent` に記録されている場所を見つける必要があります。これらのエラーはどのノードでも発生する可能性がありますが、発生するノードは 1 つのみです。「independent」の文字列が見つかるまで、Tableau Server クラスタの各ノードで次の手順を実行します。 1. EDG セットアップの Tableau Server ノード 1 ～ 4 で tabadminagent ログ ファイルの場所を見つけます。 cd /data/tableau\_data/data/tabsvc/logs/tabadminagent 2. 最新のログを開いて読み取ります。 less tabadminagent\_nodeN.log (N をノード番号に置き換えます) 3. 次の検索文字列を使用して、「Independent」と「independent」のすべてのインスタンスを検索します。 /ndependent 一致するものがない場合は、次のノードに移動して、手順 1 ～ 3 を繰り返します。 4. 一致した場合: 最後のエラー メッセージを取得するために `Shift + G` で一番下に移動します。 ### httpd スタブ ファイルの再読み込み 独立したゲートウェイは、Apache の httpd 構成を管理します。多くの場合、一時的な問題を解決する一般的な操作は、基になる Apache 構成をシードする httpd スタブ ファイルを再読み込みすることです。独立したゲートウェイの両方のインスタンスで以下のコマンドを実行します。 1. スタブ ファイルを httpd.conf にコピーします。 cp /var/opt/tableau/tableau\_tsig/config/httpd.conf.stub /var/opt/tableau/tableau\_tsig/config/httpd.conf 2. 独立したゲートウェイのサービスを再起動します。 sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### ログ ファイルの削除または移動 独立したゲートウェイは、すべてのアクセス イベントをログに記録します。ディスク空き容量が一杯になることを防ぐには、ログ ファイル ストレージを管理する必要があります。ディスクが一杯になると、独立したゲートウェイはアクセス イベントを書き込めなくなり、サービスが失敗します。独立したゲートウェイの error.log に次のメッセージが記録されます。 (28)No space left on device: \[client 10.0.2.209:54332\] AH00646: Error writing to /var/opt/tableau/tableau\_tsig/logs/access.%Y\_%m\_%d\_%H\_%M\_%S.log この障害が発生すると、Tableau ノード 1 で `tsm status -v` を実行した際に `external` ノードが `DEGRADED` ステータスになります。ステータス出力の `external` ノードは、独立したゲートウェイを指します。 この問題を解決するには、ディスクから access.log ファイルを削除するか、移動します。access.log ファイルは `/var/opt/tableau/tableau_tsig/logs` に保存されます。ディスクをクリアした後、tableau-tsig サービスを再起動します。 ### ブラウザ エラー **無効な要求**: このシナリオの一般的なエラーは、Okta から送信される「無効な要求」というエラーです。多くの場合、この問題は、ブラウザーが前の Okta セッションからのデータをキャッシュしているときに発生します。たとえば、あなたが Okta 管理者として Okta アプリケーションを管理しており、別の Okta 対応アカウントを使用して Tableau にアクセスしようとすると、管理者データからのセッション データが「無効な要求」エラーの原因となる場合があります。ローカル ブラウザーのキャッシュをクリアしてもこのエラーが続く場合は、別のブラウザーに接続して Tableau シナリオを検証してみてください。 「無効な要求」エラーのもう 1 つの原因は、Okta、Mellon、および SAML の設定作業中に入力する多くの URL でタイプミスがあることです。これらすべてをエラーなしで入力したことを確認してください。 多くの場合、独立したゲートウェイ サーバー上の `error.log` ファイルでは、エラーの原因となっている URL を指定しています。 **見つかりません - 要求された URL がこのサーバーで見つかりませんでした**: このエラーは、多くの構成エラーの 1 つです。 Okta を使用して認証されたユーザーがこのエラーを受け取った場合は、SAML を構成したときに Okta 事前認証アプリケーションを Tableau Server にアップロードした可能性があります。Okta 事前認証アプリケーション メタデータではなく、Okta Tableau Server アプリケーション メタデータが Tableau Server で構成されていることを確認します その他のトラブルシューティング ステップ - Okta 事前認証アプリケーションの設定を確認します。HTTP プロトコルまたは HTTPS プロトコルがこのトピックで指定されているとおりに設定されていることを確認してください。 - 両方の独立したゲートウェイ サーバーで tsig-httpd を再起動します。 - 両方の独立したゲートウェイで `sudo apachectl configtest` が「構文 OK」を返すことを確認します。 - テスト ユーザーが Okta の両方のアプリケーションに割り当てられていることを確認します。 - ロード バランサーおよび関連するターゲット グループにスティッキネスが設定されていることを確認します。 ### 独立したゲートウェイへの Tableau Server からの TLS 接続の検証 `wget` コマンドを使用して、独立したゲートウェイへの Tableau Server からの接続とアクセスを確認します。このコマンドのバリエーションを使用すると、証明書の問題が接続の問題を引き起こしているかどうかを理解するのに役立ちます。 たとえば、次の `wget` コマンドを実行して、Tableau Server からのハウスキーピング (HK) プロトコルを検証します。 `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319` tsig.json ファイルのホスト オプションに含めたのと同じホスト アドレスで URL を作成します。`https` プロトコルを指定し、URL に HK ポート`21319` を追加します。 接続を確認し、証明書の検証を無視します。 `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate` TSIG のルート CA 証明書が有効であることを確認します。 `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem` Tableau が通信できる場合、コンテンツ関連のエラーが発生する可能性はありますが、接続関連のエラーは発生しません。Tableau がまったく接続できない場合は、ファイアウォールやセキュリティ グループのプロトコル構成を確認することから始めます。たとえば、独立したゲートウェイが存在するセキュリティ グループのインバウンド ルールでは、TCP 21319 を許可する必要があります。 [メイン コンテンツに進む](#main-content) # 付録 - Apache の展開例を使用した Web 層 **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 このトピックでは、AWS リファレンス アーキテクチャの例で Web 層を実装するためのエンドツーエンドの手順を説明します。この構成例には、次のコンポーネントが含まれています。 - AWS アプリケーション ロード バランサー - Apache プロキシ サーバー - Mellon 認証モジュール - Okta IdP - SAML 認証 **注**: このセクションに示されている Web 層の構成例には、サードパーティーのソフトウェアとサービスを展開するための詳細な手順が含まれています。Web 層のシナリオを有効にする手順や文書の検証には最善を尽くしていますが、サードパーティーのソフトウェアが変更される場合や、シナリオがここで説明されている参照アーキテクチャと異なっている場合があります。正式な構成の詳細情報とサポートについては、サードパーティーのドキュメントを参照してください。 このセクションの Linux の例では、RHEL のようなディストリビューションのコマンドを示します。具体的には、これらのコマンドは Amazon Linux 2 ディストリビューションで開発されたものです。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。 この例の Web 層の展開では、段階的な構成と検証の手順に従います。コア Web 層を構成するには、次のステップを実行して、Tableau とインターネット間の HTTP を有効にします。Apache は、AWS アプリケーション ロード バランサーの背後でリバース プロキシ/負荷分散用に実行および構成されます。 1. Apache のインストール 2. リバース プロキシを構成して、Tableau Server への接続をテストします。 3. プロキシ上で負荷分散を構成 4. AWS アプリケーション ロード バランサーの構成 Web 層を設定して Tableau との接続を確認したら、外部プロバイダーを使用して認証を構成します。 ## Apache のインストール 両方の EC2 ホスト (プロキシ 1 とプロキシ 2) で次の手順を実行します。参照アーキテクチャの例に従って AWS に展開する場合は、2 つのアベイラビリティー ゾーンを持ち、各ゾーンで単一のプロキシ サーバーを実行する必要があります。 1. Apache をインストールします。 sudo yum update -y sudo yum install -y httpd 2. 再起動時に Apache を開始するように構成します。 sudo systemctl enable --now httpd 3. インストールした httpd のバージョンに `proxy_hcheck_module` が含まれていることを確認します: sudo httpd -M `proxy_hcheck_module` が必要です。このモジュールがお使いの httpd バージョンに含まれていない場合は、それが含まれているバージョンの httpd に更新してください。 ## プロキシを構成して Tableau Server への接続をテスト 次の手順をプロキシ ホストの 1 つ (プロキシ 1) で実行します。この手順の目的は、インターネット、プロキシ サーバー、およびプライベート セキュリティ グループの Tableau Server 間の接続を確認することです。 1. `tableau.conf` というファイルを作成して、それを `/etc/httpd/conf.d` ディレクトリに追加します。 次のコードをコピーして、Tableau Server ノード 1 のプライベート IP アドレスを持つ `ProxyPass` および `ProxyPassReverse` キーを指定します。 **重要**: 以下に示す構成は安全ではないため、本番環境では使用しないでください。この構成は、エンドツーエンドの接続を確認するために、インストール プロセス中にのみ使用する必要があります。 たとえば、ノード 1 のプライベート IP アドレスが `10.0.30.32` である場合、`tableau.conf` ファイルの内容は次のようになります。 ProxyPreserveHost On ProxyPass "/" "http://10.0.30.32:80/" ProxyPassReverse "/" "http://10.0.30.32:80/" 2. httpd を再起動します。 sudo systemctl restart httpd ### 検証: 基本トポロジ構成 `http://` をブラウザーに表示すると、Tableau Server の管理ページにアクセスできます。 Tableau Server のサインイン ページがブラウザーに読み込まれない場合は、次の手順に従ってプロキシ 1 のホスト上でトラブルシューティングを実施してください。 - トラブルシューティングの最初の手順として、httpd の停止と開始を行います。 - `tableau.conf` ファイルをもう一度チェックします。ノード 1 のプライベート IP が正しいことを確認します。二重引用符を確認し、構文を注意深く確認します。 - ノード 1 のプライベート IP アドレスを使用してリバース プロキシ サーバーで `curl` コマンドを実行します (例: `curl 10.0.1.90`)。シェルから html が返らない場合や、Apache テスト Web ページの html が返る場合は、パブリック セキュリティ グループとプライベート セキュリティ グループの間のプロトコルとポートの構成を確認します。 - プロキシ 1 のプライベート IP アドレスを使用して `curl` コマンドを実行します (例: `curl 10.0.0.163`)。シェルから Apache テスト Web ページの html コードが返る場合、プロキシ ファイルは正しく構成されていません。 - プロキシ ファイルやセキュリティ グループの設定を変更した後は、必ず httpd (`sudo systemctl restart httpd`) を再起動してください。 - TSM がノード 1 で実行されていることを確認してください。 ## プロキシ上で負荷分散を構成 1. `tableau.conf` ファイルを作成したのと同じプロキシ ホスト (プロキシ 1) 上で既存の仮想ホスト構成を削除し、そのファイルを編集して負荷分散ロジックを含めます。 例: ServerAdmin admin@example.com #Load balancing logic. ProxyHCExpr ok234 {%{REQUEST\_STATUS} =~ /^\[234\]/} Header add Set-Cookie "ROUTEID=.%{BALANCER\_WORKER\_ROUTE}e; path=/" env=BALANCER\_ROUTE\_CHANGED #Replace IP addresses below with the IP addresses to the Tableau Servers running the Gateway service. BalancerMember http://10.0.3.40/ route=1 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico BalancerMember http://10.0.4.151/ route=2 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico ProxySet stickysession=ROUTEID ProxyPreserveHost On ProxyPass / balancer://tableau/ ProxyPassReverse / balancer://tableau/ 2. httpd の停止と開始を実行します。 sudo systemctl stop httpd sudo systemctl start httpd 3. プロキシ 1 のパブリック IP アドレスを参照して、構成を確認します。 ## 構成を 2 番目のプロキシサーバーにコピー 1. プロキシ 1 から `tableau.conf` ファイルをコピーして、プロキシ 2 ホスト上の `/etc/httpd/conf.d` ディレクトリに保存します。 2. httpd の停止と開始を実行します。 sudo systemctl stop httpd sudo systemctl start httpd 3. プロキシ 2 のパブリック IP アドレスを参照して、構成を確認します。 ## AWS アプリケーション ロード バランサーの構成 ロード バランサーを HTTP リスナーとして構成します。ここでの手順では、AWS にロード バランサーを追加する方法について説明します。 #### ステップ 1: ターゲット グループの作成 ターゲット グループは、プロキシ サーバーを実行する EC2 インスタンスを定義する AWS 構成です。これらは、LBS からの通信のターゲットになります。 1. \[EC2\] > \[ターゲット グループ\] > \[ターゲット グループの作成\] の順に選択 2. \[作成\] ページで次を実行 - ターゲット グループ名を入力 (例: `TG-internal-HTTP`) - ターゲット タイプ: インスタンス - プロトコル: HTTP - ポート: 80 - VPC: お使いの VPC を選択 - \[ヘルス チェック\] > \[ヘルス チェックの詳細設定\] > \[成功コード\] で、読み取るコードの一覧 `200,303` を追加します。 - \[作成\] をクリック 3. 作成したターゲット グループを選択し、\[ターゲット\] タブをクリックします。  - \[編集\] をクリックします。 - プロキシ アプリケーションを実行している EC2 インスタンス (または一度に 1 つずつ構成している場合は単一のインスタンス) を選択し、\[登録済みに追加\] をクリックします。 - \[保存\] をクリックします。 #### ステップ 2: ロード バランサー ウィザードの起動 1. \[EC2\] > \[ロード バランサー\] > \[ロード バランサーの作成\] を選択 2. \[ロード バランサーの種類の選択\] ページで、アプリケーション ロード バランサーを作成 **注**: ロードバランサーを構成するために表示される UI は、AWS データセンター全体で一貫性がありません。以下の「ウィザードの構成」の手順は、**ステップ 1 ロードバランサーの構成**から始まる AWS 構成ウィザードにマッピングされます。  データセンターですべての構成が単一のページに表示され、ページの下部に **\[ロード バランサーの作成\]** ボタンが含まれている場合は、以下の「単一ページの構成」の手順に従います。 1. \[ロード バランサーの構成\] ページで次を実行 - 名前を指定 - スキーム: インターネットへ接続 (デフォルト) - IP アドレス タイプ: ipv4 (デフォルト) - リスナー (リスナーとルーティング): 1. HTTP リスナーは既定のままにします 2. \[リスナーの追加\] をクリックして `HTTPS:443` を追加します - VPC: すべてをインストールした VPC を選択 - アベイラビリティー ゾーン: - データセンターのリージョンとして **a** と **b** を選択 - 対応する各ドロップダウンから、パブリック サブネット (プロキシ サーバーがある場所) を選択 - \[セキュリティ設定の構成\] をクリック 2. \[セキュリティ設定の構成\] ページで次を実行 - パブリック SSL 証明書をアップロード - \[次へ: セキュリティ グループの構成\] をクリック 3. \[セキュリティ グループの構成\] ページで次を実行 - パブリック セキュリティ グループを選択します。既定のセキュリティ グループが選択されている場合は、その選択をクリアする - \[次へ: ルーティングの構成\] をクリック 4. \[ルーティングの構成\] ページで次を実行 - ターゲット グループ: 既存のターゲット グループ - 名前: 以前に作成したターゲット グループを選択 - \[次へ: ターゲットの登録\] をクリック 5. \[ターゲットの登録\] ページで次を実行 - 以前に構成した 2 つのプロキシ サーバー インスタンスが表示される - \[次へ: レビュー\] をクリック 6. \[レビュー\] ページで次を実行 \[作成\] をクリックします。 基本構成 - 名前を指定 - スキーム: インターネットへ接続 (デフォルト) - IP アドレス タイプ: ipv4 (デフォルト) ネットワーク マッピング - VPC: すべてをインストールした VPC を選択 - マッピング: - データセンターのリージョンとして、**a** と **b** (または同等の) アベイラビリティー ゾーンを選択 - 対応する各ドロップダウンから、パブリック サブネット (プロキシ サーバーがある場所) を選択 セキュリティ グループ - パブリック セキュリティ グループを選択します。既定のセキュリティ グループが選択されている場合は、その選択をクリアする リスナーとルーティング - HTTP リスナーは既定のままにします。\[Default action (既定のアクション)\] で、以前設定したターゲット グループを指定します。 - \[リスナーの追加\] をクリックして `HTTPS:443` を追加します。\[Default action (既定のアクション)\] で、以前設定したターゲット グループを指定します。 セキュリティで保護されたリスナー設定 - パブリック SSL 証明書をアップロード \[ロード バランサーの作成\] をクリックします。 #### ステップ 3: スティッキネスの有効化 1. ロード バランサーを作成したら、ターゲット グループでスティッキネスを有効にする必要がある - AWS ターゲット グループ ページ (\[EC2\] > \[ロード バランス\] > \[ターゲット グループ\]) を開き、セットアップしたロード バランサーのインスタンスを選択します。\[アクション\] メニューで \[属性の編集\] を選択します。 - \[属性の編集\] ページで \[スティッキー\] を選択して、期間 "`1 day`" を指定し、\[変更を保存\] します。 2. ロード バランサーで、HTTP リスナーのスティッキネスを有効化。構成したロード バランサーを選択し、\[リスナー\] タブをクリックする - \[HTTP:80\] で、\[ルールの表示/編集\] をクリックします。表示される \[ルール\] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。既存の THEN ルールを削除し、\[アクションの追加\] > \[転送先...\] をクリックしてルールを置き換えます。結果の THEN 構成で、作成したものと同じターゲット グループを指定します。\[Group-level stickiness (グループ レベルのスティッキー)\] で、スティッキーを有効にし、期間を 1 日に設定します。設定を保存し、\[更新\] をクリックします。 #### ステップ 4: ロード バランサーでアイドル タイムアウトを設定する ロード バランサーで、アイドル タイムアウトを 400 秒に更新します。 この展開で構成したロード バランサーを選択し、\[アクション\] > \[属性の編集\] の順にクリックします。アイドル タイムアウトを `400` 秒に設定し、\[保存\] をクリックします。 #### ステップ 5: LBS 接続の検証 \[EC2\] > \[ロード バランサー\] から \[AWS ロード バランサー\] ページを開き、設定したロード バランサー インスタンスを選択します。 \[説明\] で DNS 名をコピーしてブラウザーに貼り付け、Tableau Server のサインイン ページにアクセスします。 500 レベルのエラーが発生した場合は、プロキシ サーバーを再起動する必要がある場合があります。 ## パブリック 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 の設定と構成を行う方法について説明します。また、HTTP を使用するように Tableau Server と Apache プロキシ サーバーを構成する方法についても説明します。Okta は HTTPS を介して AWS ロード バランサーに要求を送信しますが、すべての内部トラフィックは HTTP を介して伝送されます。このシナリオ用に構成する場合は、URL 文字列を設定するときに HTTP プロトコルと HTTPS プロトコルに注意してください。 この例では、リバース プロキシ サーバー上の事前認証サービス プロバイダー モジュールとして Mellon を使用しています。この構成により、認証されたトラフィックのみが Tableau Server に接続されます。Tableau Server は、Okta IdP を使用したサービス プロバイダーとしても機能します。したがって、2 つの IdP アプリケーションを構成する必要があります。1 つは Mellon サービス プロバイダー用で、もう 1 つは Tableau サービス プロバイダー用です。 ### Tableau 管理者アカウントの作成 SAML を構成する際のよくある間違いは、SSO を有効にする前に、Tableau Server で管理者アカウントを作成するのを忘れることです。 最初のステップでは、サーバー管理者ロールを持つ Tableau Server でアカウントを作成します。Okta シナリオの例では、ユーザー名は、user@example.com などの有効なメール アドレスの形式である必要があります。このユーザーのパスワードを設定する必要がありますが、SAML を構成した後はパスワードは使用されません。 ### Okta 事前認証アプリケーションの構成 このセクションで説明するエンドツーエンドのシナリオには、2 つの Okta アプリケーションが必要です。 - Okta 事前認証アプリケーション - Okta Tableau Server アプリケーション これらの各アプリケーションは、リバース プロキシと Tableau Server でそれぞれ構成する必要がある異なるメタデータに関連付けられています。 この手順では、Okta 事前認証アプリケーションを作成および構成する方法について説明します。このトピックの後半で、Okta Tableau Server アプリケーションを作成します。ユーザー制限が設定されている無料のテスト Okta アカウントについては、[Okta Developer Web ページ](https://developer.okta.com/signup/)を参照してください。 Mellon 事前認証サービス プロバイダー用の SAML アプリ統合を作成します。 1. Okta 管理ダッシュボード > \[アプリケーション\] > \[アプリ統合の作成\] を開きます。 2. \[新しいアプリ統合の作成\] ページで \[SAML 2.0\] を選択し、\[次へ\] をクリックします。 3. \[一般設定\] タブでアプリ名 (たとえば、`Tableau Pre-Auth`) を入力し、\[次へ\] をクリックします。 4. \[SAML の構成\] タブで、次を設定します。 - シングル サインオン (SSO) URLシングル サインオン URL のパスの最後の要素は、この手順の後半で説明する `mellon.conf` 構成ファイルの中で `MellonEndpointPath` と呼ばれます。必要なエンドポイントを指定できます。この例では `sso` がエンドポイントです。`https://tableau.example.com/sso/postResponse` の最後の要素 `postResponse` は必須です。 - \[Use this for Recipient URL and Destination URL (受信者 URL と宛先 URL 用に使用する)\] チェックボックスをオフにします。 - 受信者 URL: SSO URL と同じですが、HTTP を使用します。たとえば、`http://tableau.example.com/sso/postResponse` のように使用します。 - 宛先 URL: SSO URL と同じですが、HTTP を使用します。たとえば、`http://tableau.example.com/sso/postResponse` のように使用します。 - オーディエンス URI (SP エンティティ ID): たとえば、`https://tableau.example.com` のように使用します。 - 名前 ID の形式: `EmailAddress`。 - アプリケーションのユーザー名: `Email`。 - 属性ステートメント: 名前 = `mail`。名前の形式 = `Unspecified`。値 = `user.email`。 \[次へ\] をクリックします。 5. \[フィードバック\] タブで、次を選択します。 - \[I'm an Okta customer adding an internal app (私は Okta の顧客であり、内部アプリを追加しています)\] - \[これは私たちが作成した内部アプリです\] - \[完了\] をクリックします。 6. 事前認証 IdP メタデータ ファイルを作成します。 - Okta で、\[アプリケーション\] > \[アプリケーション\] > 使用する新しいアプリケーション (例: `Tableau Pre-Auth`) > \[サインオン\] を選択します。 - \[SAML Signing Certificates (SAML 署名証明書)\] の横にある \[View SAML setup instructions (SAML セットアップ手順の表示)\] をクリックします。 - \[How to Configure SAML 2.0 for Application ( アプリケーションの SAML 2.0 を構成する方法)\] ページで、\[Optional (オプション)\] セクションの \[Provide the following IDP metadata to your SP provider (次の IDP メタデータを SP プロバイダーに指定する)\] まで下にスクロールします。 - XML フィールドのコンテンツをコピーして、`pre-auth_idp_metadata.xml` というファイルに保存します。 7. (オプション) 多要素認証を構成します。 - Okta で、\[アプリケーション\] > \[アプリケーション\] > 使用する新しいアプリケーション (例: `Tableau Pre-Auth`) > \[サインオン\] を選択します。 - \[サインオン ポリシー\] の下で、\[ルールの追加\] をクリックします。 - \[アプリのサインオン ルール\]で、名前とさまざまな MFA オプションを指定します。機能をテストするには、すべてのオプションを既定のままにします。ただし、\[アクション\] で、\[係数の確認\] を選択してから、ユーザーがサインインする必要がある頻度を指定する必要があります。\[保存\] をクリックします。 ### Okta ユーザーの作成と割り当て 1. Okta で、\[ディレクトリ\] > \[ユーザー\] > \[ユーザーの追加\] を選択し、Tableau で作成したのと同じユーザー名 (user@example.com) でユーザーを作成します。 2. ユーザーが作成されたら、新しい Okta アプリをそのユーザーに割り当てます。ユーザー名をクリックしてから、\[アプリケーションの割り当て\] でアプリケーションを割り当てます。 ## Mellon を事前認証用にインストール 1. Apache プロキシ サーバーを実行している EC2 インスタンスで次のコマンドを実行し、PHP モジュールと Mellon モジュールをインストールします。 sudo yum install httpd php mod\_auth\_mellon 2. `/etc/httpd/mellon` ディレクトリを作成します。 ## Mellon を事前認証モジュールとして構成 両方のプロキシ サーバーでこの手順を実行します。 Okta 構成から作成した `pre-auth_idp_metadata.xml` ファイルのコピーがある必要があります。 1. ディレクトリを変更します。 cd /etc/httpd/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. `mellon.conf` ファイルを `/etc/httpd/conf.d` ディレクトリに作成します。 sudo nano /etc/httpd/conf.d/mellon.conf 6. 次の内容を `mellon.conf` にコピーします。 MellonSPPrivateKeyFile /etc/httpd/mellon/mellon.key MellonSPCertFile /etc/httpd/mellon/mellon.cert MellonSPMetadataFile /etc/httpd/mellon/sp\_metadata.xml MellonIdPMetadataFile /etc/httpd/mellon/pre-auth\_idp\_metadata.xml MellonEndpointPath /sso MellonEnable "info" 7. 既存の `tableau.conf` ファイルに以下の内容を追加します。 `` ブロック内に次の内容を追加します。エンティティ ID のパブリック ホスト名で `ServerName` を更新します。 DocumentRoot /var/www/html ServerName tableau.example.com ServerSignature Off ErrorLog logs/error\_sp.log CustomLog logs/access\_sp.log combined LogLevel info `` ブロックの外部に Location ブロックを追加します。トップレベル ドメインで `MellonCookieDomain` を更新し、次のように Cookie 情報を保持します。 AuthType Mellon MellonEnable auth Require valid-user MellonCookieDomain example.com 設定が完了した `tableau.conf` ファイルは、次の例のようになります。 ServerAdmin admin@example.com ProxyHCExpr ok234 {%{REQUEST\_STATUS} =~ /^\[234\]/} Header add Set-Cookie "ROUTEID=.%{BALANCER\_WORKER\_ROUTE}e; path=/" env=BALANCER\_ROUTE\_CHANGED BalancerMember http://10.0.3.36/ route=1 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico BalancerMember http://10.0.4.15/ route=2 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico ProxySet stickysession=ROUTEID ProxyPreserveHost On ProxyPass / balancer://tableau/ ProxyPassReverse / balancer://tableau/ DocumentRoot /var/www/html ServerName tableau.example.com ServerSignature Off ErrorLog logs/error\_sp.log CustomLog logs/access\_sp.log combined LogLevel info AuthType Mellon MellonEnable auth Require valid-user MellonCookieDomain example.com 8. 構成を確認します。次のコマンドを実行します。 sudo apachectl configtest 構成のテストでエラーが返された場合は、エラーを修正して configtest を再実行してください。正常に構成されている場合は、`Syntax OK` が返ります。 9. httpd を再起動します。 sudo systemctl restart httpd ## Okta で Tableau Server アプリケーションを作成 1. Okta ダッシュボードで、\[アプリケーション\] > \[アプリケーション\] > \[アプリ カタログの参照\] を選択します。 2. \[アプリ統合カタログの参照\] で、`Tableau` を検索して、Tableau Server タイルを選択し、\[追加\] をクリックします。 3. \[Tableau Server の追加\] > \[一般設定\] を選択して、ラベルを入力し、\[次へ\] をクリックします。 4. \[サインオン オプション\] で \[SAML 2.0\] を選択してから、\[サインオンの詳細設定\] まで下にスクロールします。 - \[SAML エンティティ ID\]: パブリック URL (たとえば、https://tableau.example.com) を入力します。 - \[アプリケーションのユーザー名の形式\] では、メールを指定します。 5. \[Identity Provider metadata (アイデンティティ プロバイダーのメタデータ)\] リンクをクリックして、ブラウザーを起動します。ブラウザーのリンクをコピーします。このリンクは、次の手順で Tableau を構成するときに使用します。 6. \[完了\] をクリックします。 7. 新しい Tableau Server Okta アプリをユーザー (user@example.com) に割り当てます。ユーザー名をクリックし、\[アプリケーションの割り当て\] でアプリケーションを割り当てます。 ### IdP 用の Tableau Server で SAML を有効化 Tableau Server ノード 1 で次の手順を実行します。 1. Okta から Tableau Server アプリケーションのメタデータをダウンロードします。前の手順で保存したリンクを使用します。 wget https://dev-66144217.okta.com/app/exk1egxgt1fhjkSeS5d7/sso/saml/metadata -O idp\_metadata.xml 2. TLS 証明書および関連するキー ファイルを Tableau Server にコピーします。キー ファイルは RSA キーである必要があります。SAML 証明書と IdP 要件の詳細については、_「SAML 要件」_を参照してください ([Linux](https://help.tableau.com/current/server-linux/ja-jp/saml_requ.htm))。 証明書の管理と展開を簡素化するため、およびセキュリティのベスト プラクティスとして、信頼性の高い主要なサード パーティーの認証局 (CA) によって生成された証明書を使用することをお勧めします。または、自己署名証明書を生成するか、TLS 用の PKI からの証明書を使用することもできます。 TLS 証明書を持っていない場合は、以下の埋め込み手順に従って自己署名証明書を生成できます。 自己署名証明書の生成 Tableau Server ノード 1 でこの手順を実行します。 1. ルート認証局 (CA) の署名キーを生成します。 openssl genrsa -out rootCAKey-saml.pem 2048 2. ルート CA 証明書を作成します。 openssl req -x509 -sha256 -new -nodes -key rootCAKey-saml.pem -days 3650 -out rootCACert-saml.pem 証明書フィールドに値を入力するように求められます。例: Country Name (2 letter code) \[XX\]:US State or Province Name (full name) \[\]:Washington Locality Name (eg, city) \[Default City\]:Seattle Organization Name (eg, company) \[Default Company Ltd\]:Tableau Organizational Unit Name (eg, section) \[\]:Operations Common Name (eg, your name or your server's hostname) \[\]:tableau.example.com Email Address \[\]:example@tableau.com 3. 証明書と関連キー (この例では `server-saml.csr` と　`server-saml.key`) を作成します。証明書のサブジェクト名は、Tableau ホストのパブリック ホスト名と一致する必要があります。サブジェクト名は、`-subj` オプションと `"/CN="` の形式を使用して設定します。例: openssl req -new -nodes -text -out server-saml.csr -keyout server-saml.key -subj "/CN=tableau.example.com" 4. 上記で作成した CA 証明書を使用して、新しい証明書に署名します。次のコマンドも `crt` 形式で証明書を出力します。 openssl x509 -req -in server-saml.csr -days 3650 -CA rootCACert-saml.pem -CAkey rootCAKey-saml.pem -CAcreateserial -out server-saml.crt 5. キー ファイルを RSA に変換します。Tableau では、SAML 用の RSA キー ファイルが必要です。キーを変換するには、次のコマンドを実行します。 openssl rsa -in server-saml.key -out server-saml-rsa.key 3. SAML を構成します。次のコマンドを実行して、エンティティ ID とリターン URL を指定し、メタデータ ファイル、証明書ファイル、キー ファイルへのパスを指定します。 tsm authentication saml configure --idp-entity-id "https://tableau.example.com" --idp-return-url "https://tableau.example.com" --idp-metadata idp\_metadata.xml --cert-file "server-saml.crt" --key-file "server-saml-rsa.key" tsm authentication saml enable 4. 組織で 2021.4 以降の Tableau Desktop を利用している場合は、次のコマンドを実行して、リバース プロキシ サーバーを介した認証を有効にする必要があります。 バージョン 2021.2.1 ～ 2021.3 の Tableau Desktop は、事前認証モジュール (Mellon など) がトップレベル ドメインの Cookie を保持できるように構成されている場合、このコマンドを実行しなくても動作します。 tsm configuration set -k features.ExternalBrowserOAuth -v false 5. 構成の変更を適用します。 tsm pending-changes apply ## SAML 機能の検証 エンドツーエンドの SAML 機能を検証するには、この手順の最初に作成した Tableau 管理者アカウントからパブリック URL (https://tableau.example.com など) を使用して Tableau Server にサインインします。 ## 検証のトラブルシューティング **無効な要求**: このシナリオの一般的なエラーは、Okta から送信される「無効な要求」というエラーです。多くの場合、この問題は、ブラウザーが前の Okta セッションからのデータをキャッシュしているときに発生します。たとえば、あなたが Okta 管理者として Okta アプリケーションを管理しており、別の Okta 対応アカウントを使用して Tableau にアクセスしようとすると、管理者データからのセッション データが「無効な要求」エラーの原因となる場合があります。ローカル ブラウザーのキャッシュをクリアしてもこのエラーが続く場合は、別のブラウザーに接続して Tableau シナリオを検証してみてください。 「無効な要求」エラーのもう 1 つの原因は、Okta、Mellon、および SAML の設定作業中に入力する多くの URL でタイプミスがあることです。これらの URL すべてを注意深く確認してください。 多くの場合、Apache サーバー上の httpd `error.log` ファイルにより、エラーの原因となっている URL が特定されます。 **見つかりません - 要求された URL がこのサーバーで見つかりませんでした**: このエラーは、多くの構成エラーの 1 つです。 Okta を使用して認証されたユーザーがこのエラーを受け取った場合は、SAML を構成したときに Okta 事前認証アプリケーションを Tableau Server にアップロードした可能性があります。Okta 事前認証アプリケーション メタデータではなく、Okta Tableau Server アプリケーション メタデータが Tableau Server で構成されていることを確認します その他のトラブルシューティング ステップ - `tableau.conf` をチェックして、タイプミスや構成エラーがないことを確認します。 - Okta 事前認証アプリケーションの設定を確認します。HTTP プロトコルまたは HTTPS プロトコルがこのトピックで指定されているとおりに設定されていることを確認してください。 - 両方のプロキシ サーバーで httpd を再起動します。 - 両方のプロキシ サーバーで `sudo apachectl configtest` が “構文 OK” を返していることを検証します。 - テスト ユーザーが Okta の両方のアプリケーションに割り当てられていることを確認します。 - ロードバランサーおよび関連するターゲット グループにスティックレスが設定されていることを確認します ## ロード バランサーから Tableau Server への SSL/TLS を構成します 一部の組織では、クライアントからバック エンド サービスへのエンドツーエンドの暗号化チャネルが必要です。これまでに説明されている既定のリファレンス アーキテクチャでは、クライアントから組織の Web 層で実行されているロードバランサーへの SSL が指定されています。 ロードバランサーから Tableau Server への SSL を構成するには、次の手順を実行する必要があります。 - Tableau Server とプロキシ サーバーの両方に有効な SSL 証明書をインストールします。 - ロードバランサーからリバース プロキシ サーバーへの SSL を構成します。 - プロキシ サーバーから Tableau Server への SSL を構成します。 - Tableau Server から PostgreSQL インスタンスへの SSL を構成することもできます。 このトピックの残りの部分では、AWS リファレンス アーキテクチャのコンテキストを例に挙げ、この実装について説明します。 ## 例: AWS リファレンス アーキテクチャで SSL/TLS を設定する このセクションでは、Tableau で SSL を構成する方法、Apache プロキシ サーバーで SSL を構成する方法について説明します。これらはすべて AWS リファレンス アーキテクチャの例で実行します。 この例で示している Linux の手順は、RHEL 系ディストリビューションのコマンドです。具体的には、これらのコマンドは Amazon Linux 2 ディストリビューションで開発されたものです。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。 ### ステップ1: 証明書と関連キーを収集する 証明書の管理と展開を簡素化するため、およびセキュリティのベスト プラクティスとして、信頼性の高い主要なサード パーティーの認証局 (CA) によって生成された証明書を使用することをお勧めします。 または、自己署名証明書を生成するか、TLS 用の PKI からの証明書を使用することもできます。 次の手順では、自己署名証明書を生成します。推奨に従いサードパーティーの証明書を使用している場合は、この手順を省略できます。 この手順をプロキシ ホストの 1 つで実行します。証明書と関連キーを生成したら、それらを他のプロキシ ホストおよび Tableau Server ノード 1 と共有します。 1. ルート認証局 (CA) の署名キーを生成します。 `openssl genrsa -out rootCAKey.pem 2048` 2. ルート CA 証明書を作成します。 `openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem` 証明書フィールドに値を入力するように求められます。例: Country Name (2 letter code) \[XX\]:US State or Province Name (full name) \[\]:Washington Locality Name (eg, city) \[Default City\]:Seattle Organization Name (eg, company) \[Default Company Ltd\]:Tableau Organizational Unit Name (eg, section) \[\]:Operations Common Name (eg, your name or your server's hostname) \[\]:tableau.example.com Email Address \[\]:example@tableau.com 3. 証明書と関連キー (この例では `serverssl.csr` と　`serverssl.key`) を作成します。証明書のサブジェクト名は、Tableau ホストのパブリック ホスト名と一致する必要があります。サブジェクト名は、`-subj` オプションと `"/CN="` の形式を使用して設定します。例: `openssl req -new -nodes -text -out serverssl.csr -keyout serverssl.key -subj "/CN=tableau.example.com"` 4. 手順 2 で作成した CA 証明書を使用して新しい証明書に署名します。次のコマンドも `crt` 形式で証明書を出力します。 `openssl x509 -req -in serverssl.csr -days 3650 -CA rootCACert.pem -CAkey rootCAKey.pem -CAcreateserial -out serverssl.crt` ### 手順 2: プロキシサーバーの SSL 設定 両方のプロキシ サーバーでこの手順を実行します。 1. Apache SSL モジュールをインストールします。 `sudo yum install mod_ssl` 2. `/etc/ssl/private` ディレクトリを作成します。 `sudo mkdir -p /etc/ssl/private` 3. 証明書ファイルとキー ファイルを以下の `/etc/ssl/` パスにコピーします。 `sudo cp serverssl.crt /etc/ssl/certs/` `sudo cp serverssl.key /etc/ssl/private/` 4. 既存の `tableau.conf` を以下の更新でアップデートします。 - SSL リライト ブロックを追加します。 RewriteEngine on RewriteCond %{SERVER\_NAME} =tableau.example.com RewriteRule ^ https://%{SERVER\_NAME}%{REQUEST\_URI} \[END,NE,R=permanent\] - SSL リライト ブロックで、`RewriteCond` のサーバー名を編集してパブリック ホスト名を追加します。たとえば、`tableau.example.com` です。 - `` を `` に変更します。 - `` ブロックと `` ブロックを `` ...``。 - `BalancerMember`: プロトコルを `http` から `https` に変更します。 - `SSL*` 要素を `` ブロック内に追加します。 SSLEngine on SSLCertificateFile /etc/ssl/certs/serverssl.crt SSLCertificateKeyFile /etc/ssl/private/serverssl.key SSLProxyEngine on SSLProxyVerify none SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off - `LogLevel` 要素の中に `ssl:warn` を追加します。 - オプション: 認証モジュールをインストールして設定している場合は、tableau.conf ファイルに追加の要素がある可能性があります。たとえば、 ` ` ブロックに要素があります。 SSL を設定した tableau.conf ファイルの例を次に示します。 RewriteEngine on RewriteCond %{SERVER\_NAME} =tableau.example.com RewriteRule ^ https://%{SERVER\_NAME}%{REQUEST\_URI} \[END,NE,R=permanent\] ServerAdmin admin@example.com ProxyHCExpr ok234 {%{REQUEST\_STATUS} =~ /^\[234\]/} Header add Set-Cookie "ROUTEID=.%{BALANCER\_WORKER\_ROUTE}e; path=/" env=BALANCER\_ROUTE\_CHANGED BalancerMember https://10.0.3.36/ route=1 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico BalancerMember https://10.0.4.15/ route=2 hcmethod=GET hcexpr=ok234 hcuri=/favicon.ico ProxySet stickysession=ROUTEID ProxyPreserveHost On ProxyPass / balancer://tableau/ ProxyPassReverse / balancer://tableau/ DocumentRoot /var/www/html ServerName tableau.example.com ServerSignature Off ErrorLog logs/error\_sp.log CustomLog logs/access\_sp.log combined LogLevel info ssl:warn SSLEngine on SSLCertificateFile /etc/ssl/certs/serverssl.crt SSLCertificateKeyFile /etc/ssl/private/serverssl.key SSLProxyEngine on SSLProxyVerify none SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off #If you have configured a pre-auth module (e.g. Mellon) include those elements here. 5. index.html ファイルを追加して 403 エラーを抑制します。 sudo touch /var/www/html/index.html 6. httpd を再起動します。 sudo systemctl restart httpd ### ステップ 3: Tableau Server の外部 SSL 設定 serversl.crt ファイルと serverssl.key ファイルを Proxy 1 ホストから最初の Tableau Server (ノード 1) にコピーします。 ノード 1 で次のコマンドを実行します。 tsm security external-ssl enable --cert-file serverssl.crt --key-file serverssl.key tsm pending-changes apply ### ステップ 4 - 認証の設定 (オプション) 外部の ID プロバイダーを Tableau で設定している場合は、IdP の管理ダッシュボードでリターン URL を更新する必要があります。 たとえば、Okta 事前認証アプリケーションを使用している場合は、受信者 URL と宛先 URL に HTTPS プロトコルを使用するようにアプリケーションを更新する必要があります。 ### ステップ 5: AWS ロード バランサーの HTTPS 設定 このガイドに記載されているように AWS ロード バランサーを導入する場合は、HTTPS トラフィックがプロキシ サーバーに送信されるように AWS ロード バランサーを設定し直します。 1. 既存の HTTP ターゲット グループの登録を解除します。 \[ターゲット グループ\] で、ロード バランサー用に設定されている HTTP ターゲットグ ループを選択し、\[アクション\] をクリックして \[インスタンスの登録と登録解除\] をクリックします。 \[ターゲットの登録と登録解除\] ページで、現在構成されているインスタンスを選択し、\[Deregister (登録解除)\] をクリックして \[保存\] をクリックします。 2. HTTPS ターゲット グループを作成します。 \[ターゲット グループ\] > \[ターゲット グループの作成\] - 「インスタンス」を選択 - ターゲット グループ名を入力 (例: `TG-internal-HTTPS`) - VPC を選択 - プロトコル: HTTPS 443 - \[ヘルス チェック\] > \[ヘルス チェックの詳細設定\] > \[成功コード\] で、読み取るコードの一覧 `200,303` を追加します。 - \[作成\] をクリックします。 3. 作成したターゲット グループを選択し、\[ターゲット\] タブをクリックします。  - \[編集\] をクリックします。 - プロキシ アプリケーションを実行している EC2 インスタンスを選択し、\[登録済みに追加\] をクリックします。 - \[保存\] をクリックします。 4. ターゲット グループを作成したら、スティッキー設定を有効にします。 - AWS ターゲット グループ ページ (\[EC2\] > \[ロード バランス\] > \[ターゲット グループ\]) を開き、セットアップしたロード バランサーのインスタンスを選択します。\[アクション\] メニューで、\[属性の編集\] を選択します。 - \[属性の編集\] ページで \[スティッキー\] を選択して、期間 "`1 day`" を指定し、\[変更を保存\] します。 5. ロード バランサーで、リスナー ルールを更新します。このデプロイメントで設定したロード バランサーを選択し、\[リスナー\] タブをクリックします。 - \[HTTP:80\] で、\[ルールの表示/編集\] をクリックします。表示される \[ルール\] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。既存の THEN ルールを削除し、\[アクションの追加\] > \[リダイレクト先...\] をクリックしてルールを置き換えます。表示される THEN 設定で、`HTTPS` とポート `443` を指定し、他のオプションはデフォルト設定のままにします。設定を保存し、\[更新\] をクリックします。 - \[HTTP 443\] で、\[ルールの表示/編集\] をクリックします。表示される \[ルール\] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。THEN 構成で、\[Forward to...(転送先...)\] で、ターゲット グループを先ほど作成した HTTPS グループに変更します。\[Group-level stickiness (グループ レベルのスティッキー)\] で、スティッキーを有効にし、期間を 1 日に設定します。設定を保存し、\[更新\] をクリックします。 #### ステップ 6: SSL の確認 Https://tableau.example.com にアクセスして、設定を確認します。 [メイン コンテンツに進む](#main-content) # 付録 - AWS Deployment Toolbox **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 このトピックには、AWS に展開したときのリファレンス アーキテクチャのツールと代替デプロイ オプションが含まれています。具体的には、このトピックでは、EDG 全体で説明されている AWS 展開の例を自動化する方法について説明します。 ## TabDeploy4EDG 自動インストール スクリプト [TabDeploy4EDG スクリプト](https://help.tableau.com/samples/en-us/edg/tabdeploy4edg.txt)は、「[パート 4 - Tableau Server のインストールと構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm)」で説明されている 4 ノードの Tableau 展開の実装を自動化します。このガイドで説明されている AWS の実装例に従うと、TabDeploy4EDG を実行できます。 **要件:** スクリプトを実行するには、「[パート 3 - Tableau Server を企業環境へ導入する準備](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm)」の実装例に従って、AWS 環境を準備して設定する必要があります。 - VPC、サブネット、およびセキュリティグループが、記載通りに設定されている。IP アドレスは、実装例の記載と同じである必要はありません。 - 4 つの EC2 インスタンスで、AWS Linux2 の最新の更新ビルドを実行している。 - PostgreSQL がインストールされ、[PostgreSQL のインストール、構成、および tar バックアップ](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Install,)の記載通りに構成されている。 - ステップ 1 の tar バックアップ ファイルは、PostgreSQL がインストールされている EC2 インスタンスにあります。詳しくは、[PostgreSQL ステップ 1 の tar バックアップを取得する](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Take)を参照してください。 - Tableau Server 展開のノード 1 を実行する EC2 インスタンスが、PostgreSQL と通信できるように[パート 4 - Tableau Server のインストールと構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Configur)の記載通りに構成されている。 - 要塞ホストから SSH セッションを使用して各 EC2 インスタンスにログインしました。 スクリプトは、おおよそ 1 時間半から 2 時間かけて、4 つの Tableau サーバーをインストールして構成します。Tableau は、参照アーキテクチャに規定された設定に従って構成されます。スクリプトが実行するアクションは次のとおりです。 - PostgreSQL ホストの tar ファイルへのパスを指定すると、PostgreSQL ホストのステージ 1 バックアップが復元されます。 - すべてのノードで既存の Tableau インストールを消去します。 - すべてのノードで `sudo yum update` を実行します。 - 各ノードに Tableau rpm パッケージをダウンロードしてコピーします。 - 各ノードに依存関係をダウンロードしてインストールします。 - `/app/tableau_server` を作成して、すべてのノードにパッケージをインストールします。 - ローカル ID ストアを使用してノード 1 をインストールし、PostgreSQL を使用して外部リポジトリを構成します。 - ノード 2 ～ノード 4 の bootstrap のインストールと初期設定を行います。 - TabDeploy4EDG の bootstrap ファイルと構成ファイルを削除します。 - リファレンス アーキテクチャの仕様に従って、Tableau クラスター全体でサービスを構成します。 - インストールを検証し、各ノードのステータスを返します。 **スクリプトのダウンロードと要塞ホストへのコピー** 1. [TabDeploy4EDG サンプル ページ](https://help.tableau.com/samples/en-us/edg/tabdeploy4edg.txt)からスクリプトをコピーし、`TabDeploy4EDG` というファイルにコードを貼り付けます。 2. 要塞ホストとして稼働している EC2 ホストのホーム ディレクトリにファイルを保存します。 3. 次のコマンドを実行して、ファイルのモードを実行可能に変更します。 sudo chmod +x TabDeploy4EDG **TabDeploy4EDG の実行** TabDeploy4EDG は、要塞ホストで実行する必要があります。スクリプトは、[例: AWS の要塞ホストに接続する](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm#Example:)に記載のとおり、ssh フォワード エージェントのコンテキストで実行していることを前提に記述されています。ssh フォワード エージェントのコンテキストで実行していない場合は、インストール プロセスの間ずっとパスワードの入力を求められます。 1. 登録ファイル (`registration.json`) を作成、編集、保存します。ファイルは適切にフォーマットされた JSON ファイルである必要があります。次のテンプレートをコピーしてカスタマイズします。 { "zip" : "97403", "country" : "USA", "city" : "Springfield", "last\_name" : "Simpson", "industry" : "Energy", "eula" : "yes", "title" : "Safety Inspection Engineer", "phone" : "5558675309", "company" : "Example", "state" : "OR", "department" : "Engineering", "first\_name" : "Homer", "email" : "homer@example.com" } 2. 次のコマンドを実行して、テンプレート構成ファイルを生成します。 ./TabDeploy4EDG -g edg.config 3. 編集する構成ファイルを開きます。 sudo nano edg.config 少なくとも、各 EC2 ホストの IP アドレス、登録ファイルへのファイル パス、および有効なライセンス キーを追加する必要があります。 4. 構成ファイルの編集が完了したら、保存して閉じます。 5. TabDeploy4EDG を実行するには、次のコマンドを実行します。 ./TabDeploy4EDG -f edg.config ## 例: Terraform を使用して AWS インフラストラクチャの展開を自動化する このセクションでは、Terraform を構成して実行し、AWS に EDG リファレンス アーキテクチャをデプロイする方法について説明します。ここに示す Terraform 構成の例では、「[パート 3 - Tableau Server を企業環境へ導入する準備](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm)」で説明されているサブネット、セキュリティ グループ、EC2 インスタンスを使用して AWS VPC をデプロイしています。 Terraform のサンプル テンプレートは、Tableau サンプル Web サイト ([https://help.tableau.com/samples/en-us/edg/edg-terraform.zip](https://help.tableau.com/samples/en-us/edg/edg-terraform.zip)) で入手できます。これらのテンプレートは、組織に合わせて構成およびカスタマイズする必要があります。このセクションで提供する構成コンテンツでは、デプロイするためにカスタマイズする必要がある最小限のテンプレート変更について説明します。 ### 目標 ここで提供される Terraform テンプレートとコンテンツは、開発テスト環境で EDG を迅速にデプロイできるようにする作業サンプルとして使用することを意図しています。 Terraform 展開の例をテストして文書化することには最善を尽くしていますが、Terraform を使用して本番環境で EDG をデプロイおよび維持するには、この例の範囲を超える Terraform の専門知識が必要です。Tableau は、ここに記載されている Terraform ソリューションの例をサポートしていません。 ### 目的とする状態 このセクションの手順に従って、「[パート 3 - Tableau Server を企業環境へ導入する準備](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm)」で指定されている VPC と機能的に同等の VPC を AWS に設定します。 ![Tableau Server の AWS アーキテクチャ図。](/tableau/next/ja-jp/guides/enterprise-deployment/ja-jp/Img/edg-vpc-terraform.png) このセクションの Terraform サンプル テンプレートとサポート コンテンツ: - 上記のように、Elastic IP アドレス、2 つのアベイラビリティー ゾーン、サブネット組織を使って VPC を作成します (IP アドレスは異なります)。 - Bastion、Public、Private、および Data セキュリティ グループを作成します。 - セキュリティ グループに大部分の入力ルールと出力ルールを設定します。Terraform の実行後に、セキュリティ グループを編集する必要があります。 - 次の EC2 ホスト (各ホストが AWS Linux2 を実行) を作成します: bastion、proxy 1、proxy 2、Tableau node 1、Tableau node 2、Tableau node 3、Tableau node 4 - PostgreSQL の EC2 ホストは作成されません。Data セキュリティ グループに EC2 を手動で作成してから、「[PostgreSQL のインストール、構成、および tar バックアップ](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm#Install,)」の説明に従って PostgreSQL をインストールして構成する必要があります。 ### 要件 - AWS アカウント - VPC を作成できる AWS アカウントにアクセスできる必要があります。 - Windows コンピューターから Terraform を実行している場合は、AWS CLI をインストールする必要があります。 - AWS アカウントで使用可能な Elastic IP アドレス。 - AWS Route 53 に登録されているドメイン。Terraform は、Route 53 に DNS ゾーンと、関連する SSL 証明書を作成します。したがって、Terraform が実行されるプロファイルには、Route 53 の適切なパーミッションも必要です。 ### はじめる前に - この手順のコマンド ラインの例は、Apple OS を実行するターミナル用です。Windows で Terraform を実行している場合は、必要に応じて、ファイル パスを使用してコマンドを調整する必要がある場合があります。 - Terraform プロジェクトは、多くのテキスト構成ファイル (.tf ファイル拡張子) で構成されています。これらのファイルをカスタマイズして Terraform を構成します。堅牢なテキスト エディターがない場合は、Atom または Text++ をインストールしてください。 - Terraform プロジェクトを他のユーザーと共有する場合は、変更管理のためにプロジェクトを Git に保存することをお勧めします。 ### ステップ 1 - 環境の準備 #### A. Terraform をダウンロードしてインストールする [https://www.terraform.io/downloads](https://www.terraform.io/downloads) #### B. 秘密キーと公開キーのペアを生成する これは、AWS とその結果の VPC 環境にアクセスするために使用するキーです。Terraform を実行するときに、公開キーを含めます。 Terminal を開き、次のコマンドを実行します。 1. Create a private key. For example, `my-key.pem`: openssl genrsa -out my-key.pem 1024 2. 公開キーを作成します。Terraform では、このキー形式は使用されません。この手順の後半で、このキーを ssh キーに変換します。 openssl rsa -in my-key.pem -pubout > my-key.pub 3. 秘密キーにパーミッションを設定します。 sudo chmod 0600 my-key.pem Windows でパーミッションを設定するには、次の手順を実行します。 - Windows エクスプローラーでファイルを見つけて右クリックし、\[プロパティ\] を選択します。\[セキュリティ\] タブに移動し、\[詳細\] をクリックします。 - 所有者を自分に変更し、継承を無効にして、すべてのパーミッションを削除します。自分自身に \[Full control (フル コントロール)\] を付与し、\[保存\] をクリックします。ファイルを読み取り専用としてマークします。 4. ssh 公開キーを作成します。これは、プロセスの後半で Terraform にコピーするキーです。 ssh-keygen -y -f my-key.pem >my-key-ssh.pub #### C. プロジェクトをダウンロードして state ディレクトリを追加する 1. [EDG Terraform プロジェクト](https://help.tableau.com/samples/en-us/edg/edg-terraform.zip)をダウンロードして解凍し、ローカル コンピューターに保存します。ダウンロードを解凍すると、最上位のディレクトリである edg-terraform と一連のサブディレクトリが作成されます。 2. 最上位の `edg-terraform` ディレクトリのピアとして `state` というディレクトリを作成します。 ### ステップ 2 - Terraform テンプレートのカスタマイズ AWS および EDG 環境に合わせて Terraform テンプレートをカスタマイズする必要があります。ここでの例は、ほとんどの組織が行う必要がある最小限のテンプレート カスタマイズを提供します。特定の環境では、他のカスタマイズが必要になる可能性があります。 このセクションはテンプレート名別に構成されています。 「_ステップ 3 - Terraform の実行_」に進む前に、すべての変更を保存してください。 #### versions.tf There are three instances of `versions.tf` files where the `required_version` field must match the version of terraform.exe you're using. Check the version of terraform (`terraform.exe -version`) and update each of the following instances: - `edg-terraform\versions.tf` - `edg-terraform\modules\proxy\versions.tf` - `edg-terraform\modules\tableau_instance\versions.tf` #### key-pair.tf 1. ステップ 1.B で生成した公開キーを開き、キーをコピーします。 less my-key-ssh.pub Windows: 公開キーのコンテンツをコピーします。 2. 公開キーの文字列を public\_key 引数にコピーします。例は次のとおりです。 resource "aws\_key\_pair" "tableau" { key\_name = "my-key" public\_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQ (truncated example) dZVHambOCw==" Ensure that the `key_name` value is unique in the datacenter or `terraform apply` will fail. #### locals.tf Update `user.owner` to your name or alias. The value you enter here will be used for the "Name" tag in AWS on the resources that Terraform creates. #### providers.tf 1. 組織の要件に従ってタグを追加します。例は次のとおりです。 default\_tags { tags = { "Application" = "tableau", "Creator" = "alias@example.com", "DeptCode" = "8675309", "Description" = "EDG", "Environment" = "test", "Group" = "itcloud@example.com" } } 2. If using `provider`, comment out the `assume_role` lines: /\* assume\_role { role\_arn = "arn:aws:iam::310946706895:role/terraform-backend" session\_name = "terraform" }\*/ #### elb.tf Under `'resource "aws_lb" "tableau" {'` choose a unique value to use for `name` and `tags.Name`. If another AWS load balancer has the same name in the datacenter, then `terraform apply` will fail. Add `idle_timeout`: resource "aws\_lb" "tableau" { name = "edg-again-alb" load\_balancer\_type = "application" subnets = \[for subnet in aws\_subnet.public : subnet.id\] security\_groups = \[aws\_security\_group.public.id\] drop\_invalid\_header\_fields = true idle\_timeout = 400 tags = { Name = "edg-again-alb" } } #### variables.tf ルート ドメイン名を更新します。この名前は、Route 53 に登録したドメインと一致する必要があります。 variable "root\_domain\_name" { default = "example.com" } デフォルトでは、サブドメイン `tableau` が VPC DNS ドメイン名に指定されています。これを変更するには、`subdomain` を更新します。 variable "subdomain" { default = "tableau" } #### modules/tableau\_instance/ec2.tf There are two ec2.tf files in the project. This customization is for the Tableau instance of the ec2.tf in the directory: `modules/tableau_instance/ec2.tf`. - 必要に応じて、blob タグを追加します。 tags = { "Name" : var.ec2\_name, "user.owner" = "ALIAS", "Application" = "tableau", "Creator" = "ALIAS@example.com", "DeptCode" = "8675309", "Description" = "EDG", "Environment" = "test", "Group" = "itcloud@example.com" } } - 必要に応じて、オプションで、ストレージを更新して、データ要件を処理します。 ルート ボリューム: root\_block\_device { volume\_size = 100 volume\_type = "gp3" } アプリケーション ボリューム: resource "aws\_ebs\_volume" "tableau" { availability\_zone = data.aws\_subnet.tableau.availability\_zone size = 500 type = "gp3" } ### ステップ 3 - Terraform の実行 #### A. Terraform を初期化する Terminal で、`edg-terraform` ディレクトリに変更し、次のコマンドを実行します。 terraform init 初期化が成功した場合は、次のステップに進みます。初期化が失敗した場合は、Terraform 出力の指示に従います。 #### B. Terraform を計画する 同じディレクトリから、次の plan コマンドを実行します。 terraform plan このコマンドは複数回実行できます。必要に応じて何度でも実行して、エラーを修正します。このコマンドがエラーなしで実行されたら、次のステップに進みます。 #### C. Terraform を適用する 同じディレクトリから、次の apply コマンドを実行します。 terraform apply Terraform will prompt you to verify deployment, type `Yes`. #### オプション: Terraform を破棄する destroy コマンドを実行すると、VPC 全体を破棄できます。 terraform destroy destroy コマンドは、作成した VPC のみを破棄します。AWS の一部のオブジェクト (セキュリティ グループやサブネットなど) を手動で変更した場合、`destroy` コマンドは失敗します。失敗/ハングしている destroy の操作を終了するには、「`Control + C`」と入力します。次に、VPC を手動でクリーンアップして、Terraform が最初に VPC を作成したときの状態にする必要があります。その後、`destroy` コマンドを実行することができます。 ### ステップ 4 - bastion に接続する すべてのコマンド ライン接続は、TCP 22 (SSH プロトコル) の bastion ホストを介して行われます。 1. AWS で、Bastion セキュリティ グループ (**\[AWS\]** > **\[セキュリティ グループ\]** > **\[Bastion SG\]** > **\[Edit inbound rules (インバウンド ルールの編集)\]**) に移動してインバウンド ルールを作成し、ターミナル コマンドを実行する IP アドレスまたはサブネット マスクからの SSH (TCP 22) 接続を許可するルールを作成します。 オプション: 展開中に Private グループと Public グループの EC2 インスタンス間でファイルのコピーを許可すると役立つ場合があります。インバウンド SSH ルールを作成します。 - Private: Public からの SSH を許可するインバウンド ルールを作成します - Public: Private と Public からの SSH を許可するインバウンド ルールを作成します。 2. ステップ 1.B で作成した pem キーを使用して、bastion ホストに接続します。 **Mac ターミナルの場合:** pem キーが保存されているディレクトリから次のコマンドを実行します。 ssh-add —apple-use-keychain .pem If you get a warning about private key being accessible by others, then run this command: `chmod 600 ` and then run the `ssh-add` command again. Connect to the bastion host with this command: `ssh -A ec2-user@IPaddress` たとえば、`ssh -A ec2-user@3.15.12.112`。 **PuTTY と Pageant を使用する Windows の場合:** 1. pem キーから ppk を作成するには、PuTTY Key Generator を使用します。ステップ 1.B で作成した pem キーを読み込みます。キーがインポートされたら、**\[Save private key (秘密キーを保存)\]** をクリックします。これにより、ppk ファイルが作成されます。 2. PuTTY で構成を開き、次の変更を加えます。 - \[セッション\] > \[ホスト名\]: bastion ホストの IP アドレスを追加します。 - \[セッション\] > \[ポート\]: 22 - \[接続\] > \[データ\] > \[Auto-login username (自動ログイン ユーザー名)\]: ec2-user - \[接続\] > \[SSH\] > \[認証\] > \[エージェントの転送を許可する\] - \[接続\] > \[SSH\] > \[認証\] > \[For private key (秘密キー用)\] で、\[参照\] をクリックして、作成した .ppk ファイルを選択します。 3. Pageant をインストールし、アプリケーションに ppk を読み込みます。 ### ステップ 5 - PostgreSQL のインストール Terraform テンプレートは、外部リポジトリとして使用するために PostgreSQL をインストールしません。ただし、関連するセキュリティ グループとサブネットは作成されます。PostgreSQL を実行している EC2 インスタンスに外部リポジトリをインストールする場合は、「[パート 3 - Tableau Server を企業環境へ導入する準備](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part3.htm)」説明に従って、EC2 インスタンスをデプロイする必要があります。 次に、「[パート 4 - Tableau Server のインストールと構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part4.htm)」説明に従って、PostgreSQL をインストールして構成し、tar バックアップを作成します。 ### ステップ 6 - (オプション) DeployTab4EDG の実行 TabDeploy4EDG スクリプトによって、パート 4 で説明されている 4 ノード Tableau 展開の実装が自動化されます。「[TabDeploy4EDG 自動インストール スクリプト](#EDGSetup)」を参照してください。 [メイン コンテンツに進む](#main-content) # 仮想接続の移行 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 組織が Tableau Server の仮想接続を利用している場合は、続ける前に仮想接続を移行する必要があります。Tableau Server で仮想接続を設定していない場合は、この手順をスキップしてください。 Tableau Server から Tableau Cloud への仮想接続の移行は手動で行います。Tableau Cloud サイトで仮想接続 (またはパブリッシュされたデータ ソースと仮想接続) を作成し直し、各ワークブックのデータ ソースを新しい仮想接続に置き換えてから、元のワークブックのデータ ソースから新たなデータ ソースに計算式をコピーして貼り付ける必要があります。 **ステップ 1: Tableau Cloud で仮想接続を再作成してテストする** [「仮想接続の作成」](https://help.tableau.com/current/online/ja-jp/dm_vconn_create_conn.htm)を参照してください。 **ステップ 2: 仮想接続を使用して構築されたパブリッシュ済みのデータ ソースを再作成する** 仮想接続を使用するパブリッシュされたデータ ソースをすべて作成し直す必要があります。 1. [「仮想接続の使用」](https://help.tableau.com/current/online/ja-jp/dm_vconn_use.htm)の手順に従ってください。 2. Tableau Cloud で[パブリッシュされたデータ ソースを作成](https://help.tableau.com/current/pro/desktop/ja-jp/publish_datasources.htm)し、Tableau Server の元のデータ ソースを正確にミラーリングします。次の詳細が一致する必要があります。 - 元のデータ ソースのすべてのフィールドが新しいデータ ソースに存在する必要があります - フィールド名は大文字と小文字も一致する必要があります - メジャーとディメンションは元のフィールドから新しいフィールドにマッピングする必要があります - デフォルトのフィールド設定。[「フィールドの既定の設定の編集」](https://help.tableau.com/current/pro/desktop/ja-jp/datafields_fieldproperties.htm)を参照してください。 3. データ ソースに Tableau Bridge が必要かどうかをメモします。 **ステップ 3: ワークブックを更新して以前のデータ ソースを置き換える** Tableau Cloud に移行するワークブックごとに、Tableau Desktop から次の手順を実行します。 1. Tableau Server にサインインして、移行するワークブックに移動し、ワークブックをダウンロードします。 2. ワークブック内で **\[ファイル\]、\[閉じる\]** の順に選択します。Tableau Desktop を閉じないでください。 3. **\[サーバー\]、\[http://example にサインイン\]、\[サインアウト\]** の順に選択して、Tableau Server からサインアウトします。Tableau Server 接続中のサインアウトに関する警告が表示されます。**\[OK\]** をクリックします。 4. **\[サーバー\]、\[サインイン\]、\[Tableau Cloud\]** の順に選択して、Tableau Could にサインインします。 5. デスクトップのホーム画面から、ワークブック ファイルを選択してもう一度開きます。 「_アクションを完了できません」という_エラー メッセージが 2 回表示されます。エラー メッセージを閉じます。ワークシートを開くと、_「ワークシートを使用できません」_というメッセージが表示されます。メイン ウィンドウから接続を編集しないでください。 6. パブリッシュされた新しいデータ ソースをすでに作成している場合は、ステップ 8 に進みます。それ以外の場合は、**\[データ\]、\[新しいデータ ソース\]** の順に選択してデータ ソースを更新します。 - このワークブック用に作成した新しい仮想接続に移動し、**\[接続\]** をクリックします。 - Tableau Server の元のワークブックを開いて、式をコピーします。更新された Tableau Cloud のワークブックに式を貼り付けます。 7. 以前のデータ ソースと完全に一致する新しいデータ ソースを作成します。フィールド名は正確に一致する必要があります。 8. データ ソースを置換します。\[データ\] タブで、作成したデータ ソースを右クリックし、**\[データ ソースを置換\]** をクリックします。**\[データ ソースの置換\]**で、**置換**セレクターで正しいソースを指定し、**\[OK\]** をクリックします。 9. 古いデータ ソースを右クリックして **\[閉じる\]** を選択します。 10. 次の手順でデータ ソースをパブリッシュします。 - Tableau Cloud とは別に、**\[パブリッシュ\]、\[データ ソース\]、\[データ ソース名\]** の順に選択します。 - ワークブックに埋め込み、**\[パブリッシュ\]、\[ワークブック\]** の順に選択します。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. **現在位置**: 仮想接続の移行 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm#clou) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # 企業環境への Tableau Server 導入ガイド **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 企業環境への Tableau Server 導入ガイド (EDG) は、Tableau Server をオンプレミスまたはクラウドで導入する際に手引きとなるガイドです。このガイドでは、参照アーキテクチャを引用しながら、企業環境へ導入する場合のガイダンスを提供します。参照アーキテクチャは、業界標準のベスト プラクティスに準拠したものであり、セキュリティ、拡張性、パフォーマンスなどのベンチマークに適合していることを検証済みです。 大まかに見ると、業界標準の企業環境への導入における基本機能は、階層型トポロジで構成されています。サーバー アプリケーション機能の各層 (Web ゲートウェイ層、アプリケーション層、データ層) は、アクセス制御されたサブネットで区切られ保護されています。インターネットからサーバー アプリケーションにアクセスするユーザーは、Web 層で認証されます。認証されると、ユーザーの要求は保護されたサブネットにプロキシされます。このサブネットでは、アプリケーション層がビジネス ロジックを処理します。価値の高いデータは、第 3 のサブネットであるデータ層で保護されます。アプリケーション層のサービスは、保護されたネットワークを介してデータ層と通信し、バックエンドにあるデータ ソースへのデータ要求を処理します。 この導入では、設計上のすべての決定と実装において、セキュリティを最も重要視しています。ただし、信頼性、パフォーマンス、スケーラビリティも重要な要件です。参照アーキテクチャは分散型かつモジュール式に設計されているため、直線的に予測可能な方法で信頼性とパフォーマンスを拡張することができます。互換性のある複数のサービスを同じノードに戦略的に配置したり、負荷が高いポイントにサービスを追加したりすることができます。 ## 本ガイドの対象読者 EDG は、以下を必要とするエンタープライズ IT 管理者向けに策定されました。 - IT 部門の管理による Tableau の導入 - 業界コンプライアンスの徹底 - 業界におけるベスト プラクティスの導入 - デフォルトでのセキュアな導入 EDG は、エンタープライズ参照アーキテクチャを導入するための実装ガイドです。本バージョンの EDG には、AWS と Linux の実装例が含まれています。このガイドをリソースとして活用すると、経験を積んだエンタープライズ IT 管理者であれば、所定の参照アーキテクチャを業界標準のデータ センター環境に導入できます。 ## バージョン 本バージョンの EDG は、Tableau Server バージョン 2021.2.3 以降用に策定されました。この EDG は、古いバージョンの Tableau Server を導入する際に一般的なリファレンスとして使用することもできますが、Tableau Server 2021.2.3 以降で参照アーキテクチャを導入することをお勧めします。一部の機能とオプションは、古いバージョンの Tableau Server では使用できません。 最新の機能と改善点を適用するには、Tableau Server 2022.1.7 以降を使用して EDG を展開することをお勧めします。 このガイドで説明しているリファレンス アーキテクチャは、Tableau クライアント (互換性のあるブラウザーを使用した Web 作成、Tableau Mobile、および Tableau Desktop バージョン 2021.2.1 以降) をサポートしています。他の Tableau クライアント (Tableau Prep、Bridge など) は、リファレンス アーキテクチャでまだ検証されていません。 ## 主要な機能 Tableau Server 参照アーキテクチャの最初のバージョンでは、次のシナリオと機能が導入されています。 - クライアントの事前認証: Tableau クライアント (Desktop、Mobile、Web 作成) は、内部の Tableau Server にアクセスする前に、Web 層で企業の認証プロバイダーにより認証されます。このプロセスは、リバース プロキシ サーバーとして機能する Tableau Server の独立したゲートウェイ上に authN プラグインを構成することで管理されます。[パート 5 - Web 層の構成](https://help.tableau.com/v0.0/guides/enterprise-deployment/ja-jp/edg_part5.htm)。 - ゼロ トラスト展開: Tableau Server へのすべてのトラフィックは事前に認証されているため、Tableau の展開全体は、信頼できる接続を必要としないプライベート サブネットで動作します。 - 外部リポジトリ: 参照アーキテクチャでは、外部の PostgreSQL データベースに Tableau リポジトリをインストールするように指定してあり、DBA はリポジトリを汎用データベースとして管理、最適化、スケーリング、およびバックアップすることができます。 - 初期ノード回復: EDG には、障害が発生した場合に初期ノードを自動的に回復するスクリプトが導入されています。 - tar ベースのバックアップと復元: Tableau 展開の戦略的マイルストーンで使い慣れた tar バックアップを使用します。障害または展開構成のミスが発生した場合、関連する tar バックアップを復元することにより、前の展開段階にすばやく復元できます。 - パフォーマンスの向上: お客様とラボの検証では、EDG を実行すると、標準の導入と比較して 15 ～ 20% のパフォーマンスの向上が見られます。 ## ライセンス発行 このガイドで規定されている Tableau Server リファレンス アーキテクチャでは、Tableau Server 外部リポジトリを有効にするための Tableau Advanced Management ライセンスが必要です。オプションで、Tableau Server 外部ファイル ストアを展開することもできますが、これにも Tableau Advanced Management ライセンスが必要です。「_Tableau Server の Tableau Advanced Management について_」([Linux](https://help.tableau.com/current/server-linux/ja-jp/itm_intro.htm)) を参照してください。 [メイン コンテンツに進む](#main-content) # 学習ライブラリ ラーニング ライブラリへようこそ。調査対象のプロセスを含むステップの名前を検索します。追加の学習チュートリアル、ビデオ、ホワイトペーパーについては、次の表まで下にスクロールしてください。[Tableau のヘルプ](https://help.tableau.com/current/pro/desktop/ja-jp/default.htm)も情報源としてご利用いただけます。
「はじめに」チュートリアルのステップ 詳しく調べるトピック

サンプル データ ソースへの接続

ドラッグ アンド ドロップによる初期表示

結果に焦点を当てる

データを地理的に調査する

ドリルダウンによる詳細表示

インサイトを示すダッシュボードの構築

結果を他のユーザーと共有する
追加の学習チュートリアル、ビデオ、ホワイトペーパーです。これらのリソースを使用して、Tableau Desktop の理解を深めてください。
目標 参照先 このタイプのコンテンツの場合

Tableau インターフェースについて学習する

Tableau ワークスペース

Tableau ユーザー インターフェース (UI) のラベル付き画像。

さらにチュートリアルを確認し、サンプル データを使用しながら理解する

自分で構築するための演習

短いハウツー タイプでは、人気のあるグラフのタイプを作成する方法を示し、次のようなそれぞれのタイプを使用する状況について説明します。

  • 棒グラフ
  • テキスト テーブル
  • 線グラフ
  • 散布図
  • ヒート マップ
  • ヒストグラム
  • ガント チャート
  • 円グラフ
  • ツリーマップ
  • ボックス プロット
  • パック バブル チャート
  • マップ

データ ビジュアライゼーションのベスト プラクティスの例を見る。

視覚的なベスト プラクティス

効果的なダッシュボードのベスト プラクティス

優れたストーリーのためのベスト プラクティス

アクセシブルなビューを設計するためのベスト プラクティス

パブリッシュされたデータ ソースのベスト プラクティス

  • 見栄えのするビジュアライゼーションの作成方法。

  • 主要な洞察を得て意思決定を迅速化するために役立つ効果的なダッシュボードの設計方法。

  • Tableau ストーリー ポイントを使用した優れたストーリーの作成方法。

  • 視覚または身体に障害のあるユーザーがアクセスできるビジュアライゼーションの作成方法。

  • パブリッシュされたデータ ソースを使用して分析に使用可能なデータを作成する方法。

作業を始める前に Tableau 商品についてのコンテキストをさらに取得する

ホワイトペーパー

ベスト プラクティス、業界トレンド、データ分析の今後について詳細に説明します。

オンラインまたは対面でのトレーニングを検索する

学習とトレーニング

 オンライン、オンデマンドの無料トレーニングコースを受講するか、トレーニングに登録して専門知識を深めてください。

システム構成のコンテキストで、または他社のその他の商品と組み合わせた Tableau の操作方法に関する情報を探す

ナレッジ ベース

特定の環境やシナリオで Tableau の使用をサポートするよう設計され、サポート コールに対応して作成されたコンテンツ。
[メイン コンテンツに進む](#main-content) # 移行済みユーザーのパーミッションとコンテンツ アクセスの設定 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 データ ソース、ワークブック、Prep フローを Tableau Cloud に追加したので、ユーザーを追加する準備ができました。そのためには、誰がどのデータにアクセスできるかを Tableau がどのように判定しているか理解することが重要です。Tableau Cloud を使用すると、コンテンツにアクセスできるユーザーを指定したり、データ ソース内のデータへのアクセスを制限したりできます。 コンテンツ アイテムにアクセスできるユーザーは、コンテンツ アクセス ツールを使用して制限します。ユーザーがデータ ソース内で表示できるデータは、行レベル セキュリティ ツールを使用して制限します。 ## コンテンツ アクセス プロジェクト、ネストされたプロジェクト、個々のコンテンツ アイテムはすべて、パーミッション ルールの対象となります。これらのルールは、Tableau Server 環境でどのように使用されているかを確認することができ、Tableau Cloud で再作成できます。「[パーミッション](https://help.tableau.com/current/online/ja-jp/permissions.htm)」を参照してください。 ## 行レベル セキュリティ 行レベルのセキュリティを備えたデータ ソースまたはワークブックがある場合、行レベル セキュリティのパーミッションと計算を Tableau Cloud 用に更新する必要があります。これは、変換中にユーザー名とグループ名が変更される可能性があるためです。「[データ行レベルでのアクセスの制限](https://help.tableau.com/current/pro/desktop/ja-jp/publish_userfilters.htm)」および「[行レベルのセキュリティに使用するデータ ポリシーの作成](https://help.tableau.com/current/online/ja-jp/dm_vconn_create_rlspolicy.htm)」を参照してください。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. [移行計画](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part1.htm) 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. **現在地**: 移行済みユーザーのパーミッションとコンテンツ アクセス権の設定 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm) [メイン コンテンツに進む](#main-content) # 移行計画 これは、[Tableau Cloud 手動移行ガイド](https://help.tableau.com/current/guides/migration/ja-jp/emg_intro.htm)です。このガイドでは、ユーザーが 100 人未満の Tableau Server 展開を、手動で Tableau Cloud に移行する方法について説明します。 このトピックでは、移行前に実施すべき 2 つの重要な計画タスク (データ接続戦略と認証メカニズムの確立) について説明します。機能の違いをまとめたリストについては、Tableau Server ヘルプ トピック_「Tableau Server から Tableau Cloud への移行に関する技術的考慮事項_ ([Windows](https://help.tableau.com/current/server/ja-jp/migrate_server_to_cloud_overview.htm) | [Linux](https://help.tableau.com/current/server-linux/ja-jp/migrate_server_to_cloud_overview.htm))」を参照してください。[「Tableau Cloud への移行に関する技術準備評価」](https://exchange.tableau.com/products/921)を実施して、Tableau Cloud に移行する前に対応が必要なユースケースがあるかどうかを確認します。 ## Tableau Cloud について Tableau Cloud を初めて利用する場合は、オンラインの[セルフガイド コース](https://www.tableau.com/ja-jp/learn/training/elearning)にサインアップして、プラットフォームについての詳細を学習することをお勧めします。これらのコースは、Tableau Cloud の入門編として役立ち、移行を計画する際に必要なコンテキストを提供します。 現在、Tableau Server の管理に慣れている場合は、Tableau Cloud でも多くのタスクがほぼ同じであることがわかるでしょう。ただし、Tableau Cloud への移行に伴い、ソフトウェアの展開と管理に関連するタスクは、マネージド サービスとして Tableau が担当します。アップグレードは私たちにお任せください。詳細については、ブログ記事「[分析を Tableau Cloud に移行するべきか?](https://www.tableau.com/ja-jp/blog/should-i-move-my-analytics-cloud)」を参照してください。Tableau Cloud を使用すれば、スムーズなデータ接続やユーザーへのベスト プラクティスの提供、分析コミュニティの育成に、よりいっそう力を入れて取り組むことができます。Tableau Cloud サイトの管理に関する詳細、および管理者として開始するための一連のリソースについては、「[Tableau Cloud サイト管理](https://www.tableau.com/ja-jp/learn/get-started/online-admin)」のページを参照してください。 ## Tableau Cloud のためのデータ戦略計画 Tableau Cloud は多数のデータ ソースに接続できますが、移行を開始する前にデータ接続計画を作成することが不可欠です。このセクションでは、それを行うための最良の方法を順を追って説明し、Tableau Cloud がデータに接続する 2 つの方法について説明します。 この時点での目標は、Tableau Cloud へ移行しても、現在のデータ要件をサポートできるかどうかを検証することです。 ### 大掃除: お持ちのコンテンツは有益なものですか? さまざまなデータ タイプを評価したり、データ ソース、ワークブック、プロジェクトのすべてを Tableau Cloud に移行する方法を評価したりする前に、この移行を大掃除のチャンスとして活用することをお勧めします。Tableau Server を 1 年または 2 年以上稼動しているほとんどの組織では、ワークブック、データ ソース、プロジェクト、フローなどの古いコンテンツがある程度たまっています。移行する前に、次の手順を実行することをお勧めします。 - Tableau Server の_古いコンテンツ_の管理ビュー ([Windows](https://help.tableau.com/current/server/ja-jp/adminview-stale-content.htm) | [Linux](https://help.tableau.com/current/server-linux/ja-jp/adminview-stale-content.htm)) で、使用されなくなったコンテンツを特定できます。通常、アーカイブされた古いコンテンツを Tableau Cloud に移動することに意味はありません。手放しましょう。 - Tableau Server をしばらく運用していると、ほとんどの組織では、コンテンツ階層とパーミッション構造はおそらく有機的に「進化」し、少し乱雑になっているでしょう。移行を計画するときは、Tableau Cloud サイトでプロジェクト、グループ、パーミッションの構造を新しく最適化する戦略を立ててください。 - Tableau Data Management のお客様であれば、ツールを使用して、移行の保留中にデータのクリーニング、結合、処理を管理できます。 ### ダッシュボードのパフォーマンスの最適化 パフォーマンスに関しては、Tableau Server 上でダッシュボードが遅い場合は、Tableau Cloud でも同様に遅くなる可能性が高いというのが経験則です。移行する前に、ダッシュボードのパフォーマンスの問題を[「ワークブックのパフォーマンスを最適化する」](https://help.tableau.com/current/pro/desktop/ja-jp/performance_tips.htm)の手順で解決してください。移行する前に調整を行うことで、Tableau Cloud でも同様に向上したパフォーマンスを享受できます。 ### リストを作成し、データ ソース戦略を作成する 既存のコンテンツをクリーンアップしたら、データ ソースのインベントリを作成します。この作業の目標は、組織内のユーザーが現在使用しているデータ ソースをどのようにサポートするかを決定することです。 各データ ソースについて、以下を実行します。 - 次のセクションで、Tableau Cloud コネクタの表と照合します。サポートされている場合は、直接進める道があります。表にない場合は、以下を実行します。 - 「[ブリッジを使用した接続](https://help.tableau.com/current/online/ja-jp/to_sync_local_data.htm)」を確認して、データ型が Tableau Bridge でサポートされているかどうかを判断します。 - データ ソースが静的ファイルの場合、Tableau Cloud はブラウザーまたは Tableau Desktop からの Excel またはテキスト ベースのデータ ソース (.xlsx、.csv、.tsv) の直接アップロードをサポートしています。アップロードできるファイルの最大サイズは 1 GB です。多くの場合、ユーザーは一般的な共有ディレクトリにあるこれらの種類のファイルに接続しています。その場合、これらのファイルを、たとえば Google ドライブ、Dropbox、OneDrive などのパブリック クラウドのスペースにアップロードできます。または、Bridge を使用できます。その後、管理者 (またはユーザー) は、Tableau Cloud を設定して、ライブ データ接続でこれらのスペースに接続することができます。 - [「Tableau Cloud への移行に関する技術準備評価」](https://exchange.tableau.com/products/921)を実施して、Tableau Cloud に移行する前に対応が必要なユースケースがあるかどうかを確認します。 #### サポート済み Tableau Cloud コネクタ Tableau Cloud では、次のコネクタがサポートされています。

Alibaba AnalyticsDB for MySQL‡

Alibaba Data Lake Analytics‡

Amazon Athena‡

Amazon Aurora for MySQL‡

Amazon EMR Hadoop Hive‡

Amazon Redshift‡

Apache Drill‡

Azure Data Lake Storage Gen2‡

Azure Synapse Analytics (SQL Server 互換)

Box‡

Cloudera Hadoop‡

Databricks‡

Datorama by Salesforce‡

Denodo‡

Dremio by Dremio‡

Dropbox*‡

Esri コネクタ‡

Exasol‡

Google BigQuery*‡

Google Cloud SQL (MySQL 互換)‡§

Google ドライブ‡

Hortonworks Hadoop Hive

Impala‡

Kyvos‡

MariaDB‡

Microsoft Azure SQL データベース‡

Microsoft Azure Synapse Analytics‡

Microsoft SQL Server‡

MongoDB BI Connector‡

MySQL‡

OData‡

OneDrive*‡

Oracle‡

Pivotal Greenplum Database‡

PostgreSQL‡

Presto‡

Qubole Presto‡

Salesforce‡

SAP HANA (仮想接続のみ)‡

SharePoint Lists‡

SingleStore (旧 MemSQL)‡

Snowflake‡

Spark SQL‡

Teradata**‡

Vertica‡
\*Tableau Cloud で Google BigQuery、OneDrive、Dropbox 接続に OAuth 2.0 標準を使用する方法の詳細については、[「OAuth 接続」](https://help.tableau.com/current/online/ja-jp/protected_auth.htm)を参照してください。 \*\* Teradata Web 作成では、現在クエリ バンディング機能はサポートされていません。詳細については、「[Teradata](https://help.tableau.com/current/pro/desktop/ja-jp/examples_teradata.htm)」を参照してください。 ‡データ管理 をお持ちの場合は仮想接続をサポートします。詳細については、Tableau Cloud ヘルプの「[仮想接続とデータ ポリシーについて](https://help.tableau.com/current/online/ja-jp/dm_vconn_overview.htm)」を参照してください。 §Tableau Cloud は、Google Cloud SQL を使用した SSL をサポートしていません。 ## ユーザー アカウントと認証 2 つ目の重要な計画ステップは、Tableau Cloud ユーザーに使用する認証メカニズムを特定することです。 Tableau Cloud の既定のユーザー アカウントは TableauID と呼ばれます。TableauID では、Tableau Cloud への安全なアクセスを確保するために多要素認証 (MFA) が必要です。Tableau Cloud ドキュメントの「[多要素認証と Tableau Cloud について](https://help.tableau.com/current/online/ja-jp/security_auth.htm#mfa_requirement)」を参照してください。 組織が ID プロバイダー (IdP) を使用して認証を有効にしている場合は、Tableau Cloud でその認証を使用することも可能です。Salesforce 認証と Google OpenID をネイティブでサポートしています。Azure、Okta、OneLogin、AD FS、PingOne、または標準の SAML 2.0 認証をサポートする任意の IdP に対して SAML を構成することもできます。 続行する前に、Tableau Cloud の[認証](https://help.tableau.com/current/online/ja-jp/security_auth.htm)オプションを確認して、計画を立てます。 組織が Azure AD、Okta、または OneLogin を使用して ID を管理している場合、Tableau Cloud でユーザーとグループを自動的にプロビジョニングすることもできます。「[外部 ID プロバイダーを介したユーザー プロビジョニングおよびグループ同期の自動化](https://help.tableau.com/current/online/ja-jp/scim_config_online.htm)」を参照してください。 ## 移行ワークフロー このガイドは、Tableau Cloud に移行するための段階的なプロセスに従って構成されています。 1. **現在位置**: 移行を計画する 2. [Tableau Cloud サイトの作成と設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2.htm) 3. [仮想接続の移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part2-5.htm) 4. [データ ソース、ワークブック、Prep フローの Tableau Cloud への移行](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part3.htm) 5. [Tableau Cloud の更新スケジュールの再作成](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part4.htm) 6. [移行済みユーザーのパーミッションとコンテンツ アクセスの設定](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part5.htm) 7. [Tableau Cloud への残りのユーザーの追加](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part6.htm) 8. [エンドユーザーの移行チェックリスト](https://help.tableau.com/v0.0/guides/migration/ja-jp/cloud_migration_part7.htm)