Qlik Cloud への移行の計画
Qlik Cloud への移行を計画する際、Qlik が推奨する注意事項、ベストプラクティス、アプローチ、およびプロセスで利用可能なリソースをレビューして、Qlik Sense Client-Managed 製品から Qlik Cloud へ確実に移行できるようにします。これらの推奨事項は、Qlik Cloud へ移行する際に Qlik 顧客から得られる知識と体験を考慮に入れています。
次の組織のアセスメントと評価から、移行を始めます。
-
戦略的方向—Qlik Cloud への移行を戦略的イニシアチブとしてアプローチします。プロジェクトを将来のビジネス ニーズと組織のクラウド、データ、分析戦略の長期的方向に合わせます。
-
準備と実装—必要な検討事項、準備すべき主なステップ、実施に向けたベストプラクティスのアプローチについて詳しく説明します。
-
最適化— 導入を促進するために、Qlik Cloud 展開を測定および管理するメカニズムを確立します。
これらの主なエリアをレビューすることにより、移行コストを最小化しながら成功を最大化できます。
戦略的方向
Qlik Cloud を移行する際に、組織の戦略計画を念頭に置きます。これにより、移行優先順位と廃止すべき既存のイニシアチブの両方を特定できます。次の質問を考慮します。
-
Qlik Cloud へ移行する際の戦略的目標は何か?
-
現在のクラウド データ アーキテクチャはどのようなものか?
-
当社の運用システムはどこでホストされているのか?
-
当社は、データおよび分析プラットフォームにどのようなイニシアチブを求めているか?
-
将来のビジネスニーズに対応しない過去の実装はあるか?
準備と実装
Qlik Cloud の新しい機能や能力は、Qlik Sense Client-Managed 製品で活用されているアプローチ、テクニック、機能が Qlik Cloud では異なる可能性があることを意味します。クラウドベースのソリューションは、クライアント管理とはアーキテクチャが異なるため、Qlik Cloud の利点を最適化するために、再考とリファクタリングを検討する必要があります。 そのため、Qlik を使った分析体験を最適化するためには、オンプレミスから Qlik Cloud への移行は、単なるリフト＆シフトだけにしないことが必要です。戦略的目標を特定したら、次のステップは基本的な移行活動に取り組むことです。
移行ワークフローとタイムラインを理解する
具体的な移行アプローチとプロセスは、現在の状況、リソース、要件に応じて異なります。このセクションでは、移行ワークフローの一般的な概要について説明します。並行して実行できるタスクの種類、ユーザーを移動してスペースを作成するタイミングなど、移行中のイベントのタイミングと順序を理解するためのガイドラインとして使用してください。移行の各ステップにかかる時間は、既存の Qlik Sense Client-Managed 展開の複雑さに応じて異なります。
次のワークフローの例では、タスクの種類 (プロセス、セットアップ、アセット) に応じて移行ステップを分類しています。タスクは、移行シーケンスのどこに位置するかに従って配置されます。
移行ワークフローとタイムラインの例
Qlik Sense Client-Managed の移行ドキュメントでは、主にセットアップとアセットのワークフローのタスクに焦点を当てています。これには、クラウド テナントと移行ツールのセットアップと、これらのツールを使用したユーザーとコンテンツ (ストリーム、アプリ、データ接続など) の Qlik Cloud への移行管理の支援が含まれます。
詳細については、次を参照してください
セキュリティとガバナンス
認証と承認
既定では、新しい Qlik Cloud テナントは Qlik Account、Qlik ID プロバイダーに対して構成されますが、このためにはユーザーがログインする前に Qlik でアカウントを登録する必要があります。ただし、ベストプラクティスは、Qlik 展開 (例: Active Directory) 内の外部 ID プロバイダーを使用することです。
独自の ID プロバイダーを使用する利点には次のようなものがあります。
-
Qlik Account を作成して管理しなくても、既存の企業資格情報を使ってプラットフォームにアクセスできる。
-
パスワードの長さ、パスワードの有効期限、多要素認証について、独自のポリシーを適用できる。
-
ITセキュリティおよびガバナンス要件に従ってアクセスを監査および監視する。
-
必要に応じて、複数のディレクトリをフェデレートする。
-
アイデンティティプロバイダーを通して、ユーザーのグループ割り当てを含める。
-
ユーザーの参加と退出を自動的に処理し、スペースセキュリティとセクションアクセスのためのユーザー ID の管理方法をコントロールする。
役割とルール
Qlik Sense Client-Managed では、ルールの概念はセキュリティの構成と実施、ライセンス割り当て、アプリ配布などのために使用されます。ルールエンジンの柔軟性は、カスタム プロパティによって拡張され、複雑な承認パターンを作成できます。Qlik Cloud プラットフォームは、このような方法でセキュリティ ルールを実施せず、カスタム プロパティを持ちません。代わりに、Qlik Cloud はより単純なアプローチを使用し、セキュリティを直接グループに、または ID プロバイダーを通じてグループが利用できない場合はユーザーに割り当てるように設計されています。
Qlik Cloud 権限は、スペース レベル (アプリケーションおよびデータ向け)、またはシステム レベル (管理者の役割向け)、およびサポート グループと割り当て両方で設定できます。このアプローチには、組織固有の計画が必要です。このアプローチは、移行前に実施できますが、移行アクティビティを開始する前に Qlik Cloud で新しい役割と機能に対してこの設計をレビューすることが推奨されます。
現在の Qlik 展開を正当化および合理化する
Qlik Sense Client-Managed の顧客は、多くのレガシー アプリケーションを所有していることがよくありますが、その一部はすでに不要となっています (開発およびテスト環境など)。 古く、重複した、または使用されていないアプリケーションをアーカイブすることにより現行環境を合理化すると、Qlik Cloud への移行の作業 (そしてコスト) を大幅に低減し、継続的メンテナンスとテスト間接費を最小化することができます。
次のアプローチは、Qlik 展開を正当化および合理化するためのベストプラクティス テクニックです。
-
Production アプリの場合: アプリケーション所有者がリソースを確認するか、またはアプリケーションを廃止 (オプトアウト) できることを述べるようリクエストします。
-
Development および Test アプリの場合: アプリケーション所有者が移行 (オプトイン) するのに必要なアプリのリストを提供するようリクエストします。
-
移行が必要ないすべてのアプリの場合: Qlik 展開の外の長期ストレージにエクスポートおよびアーカイブします。
あなたのアプリ
Qlik Cloud への移行を計画する際、アプリをレビューして、それがQlik Cloud 展開に対して適切かどうかを理解することが重要です。Qlik Cloud は、異なるニーズに基づいて複数の容量ティアをサポートしています。ほとんどのアプリは標準容量ティアに適していますが、必要に応じて Qlik は、より大きなアプリケーション およびニッチなユースケースのために拡張および専門容量オプションを提供しています。Qlik Cloud 容量使用に関する詳細は、Qlik Sense 仕様および容量を参照してください。
アプリをレビューする際に考慮すべき重要な要素:
-
アプリ サイズ
-
リロード期間と同時実行性
-
データ ソース
-
サードパーティー コンポーネント - 拡張、GeoAnalytics、Qlik NPrinting、およびその他の統合ソリューション
-
匿名または OEM ユースケース (Qlik に連絡)
-
マッシュアップ
Qlik クライアント管理の環境に対して準備アプリを実行することにより、このレビューを支援できます。SaaS Readiness アプリは、Qlik Cloud を検討しているクライアントに対して Qlik が Qlik Sense Client-Managed サイトまたは QlikView 環境で実行するための Qlik Sense および QlikView アプリです。これらのアプリは、Qlik Sense Client-Managed または QlikView 環境のプロファイルを作成し、適切な Qlik Cloud ティアに対して適格かどうかを決定します。また、アプリには、セッション使用状況、データ接続のメタデータ (QlikView の系列)、およびタスクとタスク ケイデンス (Qlik Sense Client-Managed のみ) も含まれますが、これらすべては、アセットの移行の優先順位と複雑さを量る上で重要な属性です。
より詳しいアセスメントは、Qlik のカスタマー サクセス組織によって実施されます。
データの評価
Qlik Cloud への移行においては、組織のデータの場所を考慮する必要があります。Qlik Cloud には、一般にアドレス指定可能な多くのデータ ソースにアクセスできるコネクタがいくつかあります。そのため、組織がサポートされているクラウドベースのシステム (Salesforce または Workday など)、クラウド データベース (Google Big Query の Snowflake など)、またはクラウド ストレージ (AWS S3 または Azure ブロック ストレージなど) に移行したら、アプリケーションを移行するのは簡単になります。多くの組織には、オンプレミスで、パブリック インターネットに接続できず、または顧客の独自構造のコネクタを使用しなければならないデータ ソースがあります。そういった場合、このデータを Qlik Cloud が使用できるようにするためのツールやアプローチがいくつかありあｍす。
これらは、データを Qlik Cloud が使用できるための現行オプションです:
-
Qlik データ ゲートウェイ - 直接アクセス – Qlik Cloud のプライベート データに直接アクセスします
-
データをサポートされちえるクラウド データベースまたはストレージに移動してから、Qlik Cloud にプルします
-
サポートされたソース システムに Qlik Cloud から直接接続してから、Qlik Cloud にプルします
これらのテクノロジーやテクニックは、顧客の戦略的クラウド データ アーキテクチャを実装または統合するために使用できます。クラウド データ アーキテクチャという戦略的長期目標に移行しながら、短期的な戦術的オプションを使用するのが一般的な慣習です。
Qlik データ ゲートウェイ - 直接アクセス
Qlik データ ゲートウェイは、オンプレミス、仮想プライベート クラウド、またはパブリック クラウドなどその場所に関係なく、Qlik データ サービス を顧客のデータに拡張します。ゲートウェイでは、顧客のファイアウォールでポートを開かずに、Qlik Cloud に直接、およびその他よく使用するクラウド ターゲット (Snowflake、Azure Synapse、Google Big Query、または Databricks) へのセキュリティ保護された専用のトンネルを使って、直接アクセスを実現します。
Qlik Cloud からのソース システムに直接接続します
このオプションは、Salesforce または Workday などのクラウドベース システムに移行した場合に最もよく使用されます。Qlik Cloud はこれらのシステムを Qlik コネクタ経由で接続できますが、Qlik アプリケーションの自動化 を使用してこれらのシステムとの統合を構築することもできます。この方法でオンプレミスのソースに接続することは、組織のファイアウォールを開く必要があるため、推奨されません。