re:Invent 2024: QuickSightへの移行でコスト74%削減 - AWS事例紹介
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Migrate to QuickSight: Reduce costs and increase productivity (BSI205)
この動画では、Amazon QuickSightへの移行に関するベストプラクティスと実例が紹介されています。Senior Worldwide QuickSight Go-to-Market SpecialistのSam Dabboussiが、QuickSightの概要と74%のコスト削減効果について説明し、Whole Foods MarketとItaú Unibancoの事例が共有されています。Whole Foods Marketは2万人以上のユーザーを6ヶ月以内に移行し、ダッシュボードの読み込み時間を1分から6秒未満に短縮。Itaú Unibancoは17,000のダッシュボードの移行を2年かけて実施し、34,000人のユーザーが利用する規模まで成長させました。Amazon Qの活用やSPICEエンジンによるパフォーマンス向上など、具体的な技術的メリットも詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon QuickSightの概要と本セッションの紹介
皆様、こんばんは。本日はお集まりいただき、ありがとうございます。私はSam Dabboussiと申します。Senior Worldwide QuickSight Go-to-Market Specialistとして、世界中のお客様のBIプラットフォーム modernization journeyをサポートしております。本日は何名かの方々と共同で発表させていただきます。AmazonからMaitri Shahが参加しており、彼女はAmazon QuickSightのSenior Technical Program Managerです。また、本日は2名のお客様にもご登壇いただけることを大変光栄に思います。Whole Foods MarketのData & Analytics ManagerであるRavi Reddy氏、そしてブラジルのサンパウロからItaú UnibancoのHead of D&A Platform EngineeringであるRoberto Figueira氏にもご参加いただいております。
お食事やお飲み物の前の最後のセッションとなりますが、 皆様を引き付けるような興味深いアジェンダをご用意しております。まず私からAmazon QuickSightの概要と、お客様にもたらすメリットについてお話しします。続いてMaitriが移行のベストプラクティスと、プロセスを通じてご利用いただけるリソースについてご説明します。その後、RaviがWhole Foods MarketのQuickSightへの移行の journey についてお話しし、RobertoがItaú UnibancoのQuickSightへの移行についてお話しします。
Amazon QuickSightの強みと移行のベストプラクティス
それでは、様々なプラットフォームや異なるBIベンダーからAmazon QuickSightへの移行を通じて、お客様が得られたメリットについてお話ししましょう。すでに数千のお客様が移行を完了しており、BIの利用率の向上、高いROI、そしてコスト削減により、この移行を決断した意思決定者は社内でヒーローとして見られることも多いのです。Enterprise Strategy Groupが最近実施した調査では、QuickSightへの移行による経済効果が実証されています。競合するBIベンダーからAmazon QuickSightへの移行を行った数千のお客様を対象とした調査では、3年間で最大74%のコスト削減を達成できたことが示されています。つまり、お客様は以前の支払額の4分の1程度で済むようになったということです。さらに、BIユーザー数とBI利用率が大幅に増加し、ユーザー数は157%から300%の増加を記録しています。これは、より多くの組織メンバーが意思決定時にAIやインサイトを活用するようになったことを意味し、275%のROIを達成しています。
QuickSightの強みと成長を示す証として、現在10万以上のお客様がいらっしゃり、さらに増加し続けています。これらのお客様は、あらゆる業界、あらゆるユースケースに広がっています。 QuickSightは、組織内部のユーザーと、お客様が分析機能を組み込みたい外部ユーザーの両方に対応する、完全で統合されたBIプラットフォームです。業界の調査によると、お客様は平均して2つ以上のベンダーをBIのユースケースで使用しているとされています。レポート用のベンダー、埋め込みダッシュボード用の別のベンダー、Natural Language Query用の第三のベンダーというように。これにより、BIのサイロ化、ガバナンスの欠如、単一の信頼できる情報源の欠如が生じています。また、お客様は異なるベンダーやツール、ライセンスのトレーニングに費用を支払う必要があります。さらに、これらのベンダーの多くは、最新のGenerative AIやML機能を実際には備えていません。
Amazon QuickSightでは、フルマネージドでハイパースケールな統合サービスを提供しています。単一のUIから、エンドツーエンドのBusiness Intelligenceプロセスをご利用いただけます。ユーザーはデータに接続し、データの準備を行い、ダッシュボードや分析などのアセットを作成し、ストーリー、埋め込みダッシュボード、またはPaginated Reportを通じて、どのようにユーザーに提供するかを決定できます。これらすべてが1つの統合プラットフォームで実現され、Generative BIによってユーザーをエンパワーしています。
お客様のもう一つの懸念は、スケーラビリティです。従来型のBIツールを使用しているお客様は、スケールの計画を立て、リソースを確保し、必要なリソース量を予測するための使用状況を把握する必要があります。これは常に課題となっており、お客様は過剰なキャパシティか過少なキャパシティのどちらかの状態に陥ります。過剰な場合は、使用量に対して多すぎるリソースを計画してしまい、必要以上の支払いが発生します。一方、過少な場合は、需要に対してリソースが不足し、パフォーマンスが低下します。ユーザー数が増えるほどパフォーマンスは悪化し、その改善も容易ではありません。面倒で、リアルタイム性に欠け、非常にコストがかかります。Amazon QuickSightを使用すれば、ユーザーの介入なしにリアルタイムで自動的にスケールするクラウドネイティブツールが手に入り、リソースとキャパシティの計画に関する負担が完全に解消されます。
最後に、QuickSightの管理のしやすさとコスト削減についてお話ししたいと思います。従来型のツールでは、お客様は複数年契約を求められ、サーバーの管理、アップグレードの管理、メンテナンス、ソフトウェアの管理、ソフトウェアのアップグレード、パッチ適用などを行う必要がありました。Amazon QuickSightは完全マネージド型のツールです。使用した分だけの月額課金制で、管理するサーバーは一切なく、常に最新の状態が保たれるため、お客様はリソース管理ではなく、インサイトの創出に真に注力できます。
Whole Foods MarketのQuickSight移行事例
ここからは、同僚のMariiaに引き継ぎ、移行のベストプラクティスについてご説明させていただきます。ありがとうございます、Sam。皆様、こんにちは。私はAWSのSenior Technical Program ManagerのMariiaです。QuickSightでチームの成功をサポートしています。始める前に、皆様の中で移行を経験された方はどのくらいいらっしゃいますか？手を挙げていただけますでしょうか。
多くの方がいらっしゃいますね。きっと共感していただけると思います。移行は高額で時間がかかり、日々のビジネス運営に影響を及ぼします。移行を実施するチームだけでなく、エンドユーザーにとっても混乱を招く可能性があります。しかし、適切に実施し、正しく計画すれば、長期的には大きなメリットがあります。その一部についてはSamが既に説明しました。QuickSightに移行することで、本質的にエンドユーザーがセルフサービスでAI機能を活用できるようになります。リソースやサーバーの管理を心配する必要はなく、ビジネスのためのビジュアライゼーションの作成に集中できます。つまり、QuickSightをワンストップショップソリューションとして、モダナイゼーションを実現できるのです。
それでは、移行のベストプラクティスについてお話ししましょう。計画フェーズで移行を開始する前に、移行がエンドユーザーにどのように役立つのか、お客様にどのようなメリットをもたらすのかを明確にすることが重要です。投資対効果を真に理解するために、既存のBIとAmazon QuickSightを比較することが大切です。
次に、チームとリーダーシップと共に目標を設定し、QuickSightへの移行が有益である理由について理解と支援を得ることが重要です。これにより、優先順位付けと計画立案がスムーズになります。3番目は、タイムラインの設定です。通常、チームがQuickSightへ移行する際には、既存のBIツールの更新時期に合わせた切り替え時期を想定します。QuickSightへの移行をそのタイムラインに合わせて逆算することで、並行テストが可能になり、ユーザーがQuickSightに慣れる時間を確保できます。
Tiger Teamを編成します。これは、既存のBIツールとQuickSightの両方にアクセスできる管理者で構成されるコアチームで、アクセス権限とセキュリティガイドラインの管理を担当します。さらに、レポート開発を担当するBIエンジニアやビジネスアナリストといったビルダーと、レポートの承認やユーザー受け入れテストを支援するエンドユーザーまたはアーリーアダプターであるテスターが必要です。
QuickSightは使い始めやすく操作も簡単ですが、それでも既存のBIツールとQuickSightの間でデータセット、データソース、ビジュアル、計算式などのエンティティやアセットを比較するマッピング作業は重要です。これらは異なる場合があるためです。 既存のBIツールとQuickSightの両方で使用状況と管理レポートを作成することが重要です。これにより、実際に使用されているアセットの数と、古くなった未使用または重複しているアセットの数を把握できます。アクティブなものだけを優先するか、古いものを移行しないという選択をすることで、時間、労力、コストを節約できます。このような分析を行うと、30%以上のアセットが古いか重複していることがわかります。
組織全体でリーダーシップが注目する週次ビジネスレビューや月次レポートなど、ビジネスクリティカルなレポートを特定し、それらを最初に移行することが重要です。さらにプロセスを簡素化し加速するために、QuickSight APIを使用してプログラムで移行できるアセットを優先することで、変更の範囲を縮小し、プロセスを加速できます。計画から実行までの各フェーズを進める中で、成功事例を積み重ね、それを広くチームに伝えることが重要です。これにより、より多くの自信を得て、シームレスな移行を目指すことができます。
移行に関して私たちが提供しているリソースについて簡単にご紹介します。 先ほど申し上げたように、QuickSight APIを通じて構築でき、Assets as Codeとして管理できるアセットは移行の助けとなります。これは、数千のレポート、複数のアカウント、数百のフォルダーを持つビジネスにとって特に重要です。なぜなら、そのような規模では手動での移行は現実的な選択肢ではないからです。 また、私たちには移行パートナーもいます。AWS Professional Servicesチームが、お客様の移行目標に関してエンドツーエンドで支援します。さらに、QuickSightへの移行を加速するメカニズムを持つAWS BIの移行パートナーもいます。AWS Professional ServicesやAWSパートナーの移行ツールについての詳細は、AWS Marketplaceでご確認いただけます。
最後に、さらなるインセンティブとして、大規模企業向けの資金提供プログラムをご用意しています。例えば、数千のアセットをQuickSightに移行することを検討している大規模デプロイメント向けに、カスタマイズ可能でスケーラブルな価格設定を提供しています。また、コストを削減できるMigration Acceleration Program (MAP)もご用意しています。
さらに、コストを一層抑えられる業界特有のプログラムもございます。これらの資金提供プログラムの詳細や、お客様の組織が対象となるかどうかについては、アカウントマネージャーまたはAWSアカウント管理チームにお問い合わせください。
Itaú UnibancoのQuickSight移行：背景とアーキテクチャ
それでは、Whole Foods MarketのRavi Reddyさんに、これらのベストプラクティスを活用したWhole Foods MarketのAmazon QuickSightへの移行の旅についてお話しいただきます。ありがとうございます。Maitriさん、ありがとうございます。本日は私たちの移行の旅についてお話しできることを嬉しく思います。意思決定から導入まで6ヶ月以内に完了し、2万人以上のユーザーを移行したという点で、これは革新的な取り組みでした。私はAmazonのデータ・アナリティクスリードのRavi Reddyです。Amazon Groceryのアナリティクス全般をサポートしています。
Amazon Groceryの簡単な紹介をさせていただきます： 私たちはAmazon.comと、Amazon Fresh、Whole Foods Market、Amazon Goという3つの実店舗フォーマットを通じて食料品を提供しています。また、20以上のサードパーティーのローカル食料品店を通じても食料品を提供しています。私たちのビジョンは、食料品と家庭用品をワンストップで購入できる場所を作ることです。
特にWhole Foods Marketに焦点を当てますと、米国、カナダ、英国に500店舗を展開しています。人々と地球を育むことを目的とした、ナチュラル＆オーガニック食品のリーダー的存在です。 従来のプラットフォームで直面していた課題についてお話しすると、ダッシュボードのパフォーマンスが極めて低かったのです。具体的な例を挙げますと、ダッシュボードユーザーとして5つのダッシュボードを閲覧する際、各ダッシュボードの読み込みに約1分かかるとすると、年間で約4.5時間を費やすことになります。これを2万人以上のユーザーに当てはめると、ダッシュボードの読み込みを待つだけで8万〜9万時間もの時間が費やされ、実際のアクションに移れていないことになります。そこで、ダッシュボードの読み込み時間を1分から5秒に短縮することを目標に掲げました。これは革新的な取り組みとなり、現在お客様にご満足いただいています。
新しいプラットフォームへの移行を検討したもう1つの理由はコストでした。レガシーのBIプラットフォームのパフォーマンス低下の問題に対処するため、様々なプラットフォームを評価した際、AWSが提供できる価格と比較して75%以上も高いコストを支払っていることが分かりました。レガシープラットフォームであったため、肥大化も進んでいました。多くの人々が様々なビジュアライゼーションを作成し、複数のデータソースが存在し、それら全てのデータパイプラインを簡単に管理できる状態ではありませんでした。同時に、ダッシュボードにも多くの重複がありました - 同じメトリクスが複数のダッシュボードに存在していたのです。そこで、この機会を活用して、ユーザーにとって本当に重要なダッシュボードだけを提供するよう、合理化を図ることにしました。
また、SharePointやExcel、レガシーデータソース、AWS基盤自体など、様々なソースからデータが来る複雑なデータソース管理にも対処する必要がありました。これらの管理は困難でした。また、複数年にわたるデータ移行計画を進めている最中だったため、このタイミングで新しいプラットフォームに移行することが適切かどうか検討する必要がありました。
私たちが懸念していたのは、レガシーからQuickSightへとレポーティングプラットフォームを移行し、データソースが移行された場合、全てのダッシュボードを再作成しなければならなくなることでした。そこで、中間的なステージングエリアを作成し、そこでデータを前処理して、将来の移行時にダッシュボードを修正することなく、単に基盤となるデータソースを変更するだけで済むような方法でダッシュボードにリンクさせることにしました。
QuickSightをソリューションとして選定した経緯についてですが、複数のレポーティングプラットフォームを評価し、レガシープラットフォームの既存レポートがAWS QuickSight上でどのようなパフォーマンスを示すかを確認するための実証実験を行いました。この実証実験の結果、ロード時間に関して90%のパフォーマンス向上が確認できました。また、大規模なユーザー数に対するスケーラビリティのメリットも認識しました。ピーク時の容量ニーズを計画したり、インフラのスケールダウンを心配したりする必要がありません。他のプラットフォームでは常に注意を払う必要があるこれらの考慮事項が、QuickSightでは効果的に対処されていました。また、AWS基盤との継ぎ目のない統合により、セキュリティやファイアウォールなどの心配をする必要もありませんでした。さらに、コストも確実に重要な要因の1つでした。
計画から立ち上げまでの私たちの journey について説明しますと、最初の懸念はBIプラットフォームの低いパフォーマンスでした。これは、リーダーシップによる店舗訪問時に最も頻繁に指摘される項目でした。リーダーシップチームから改善の指示を受けていましたが、複数の潜在的なソリューションがありました。新しいプラットフォームに移行するか、既存のものを修正するかを決定するために、多くの要因を考慮しながら、ステークホルダーの支持も得る必要がありました。既存のレポーティングプラットフォームはパフォーマンスが良くなかったものの、運用上は機能しており、チームは日々の意思決定にそれを使用していました。
新しいプラットフォームへの移行には、実行に移る前に顧客の同意を得るために多大な努力が必要でした。数多くのProof of Conceptを実施し、既存のBIプラットフォームと比較してどのようなパフォーマンスを発揮するかを実証し、検討したすべてのオプションを提示しました。また、組織外での活用事例も紹介しました。契約更新のタイミングを考慮して、更新時期までに大半のユーザーを移行することを目指したWork-backwardsプランを作成しました。
実装アプローチとしては、パレートの法則に従い、20%の努力で80%のROIを得ることを目指して、閲覧数とユーザー数が最も多いダッシュボードに焦点を当てました。移行開始から最初の3ヶ月間は、利用頻度の高いダッシュボードに集中し、2024年3月までに約20,000人のユーザーを移行することができました。その後、残りの約3,000人のユーザーと、注意が必要な複雑で重要なレポートの移行に、さらに3ヶ月を要しました。
アーキテクチャに関しては、設計を必要以上に複雑にすることは避けました。基本的に、ご覧の通り、レガシーデータの大部分をAmazon S3を通じてAWS環境に取り込もうとしていました。場合によっては、必要なデータ変換を行うためにAmazon Redshiftに移行し、その後QuickSightが利用できるように前処理されたデータセットを作成しました。
特に注意を払ったのはパフォーマンスでした。以前のプラットフォームでは、独自のデータ接続とデータソースを使用しており、ダッシュボードの読み込み時にリアルタイムでデータを処理していました。これは、20個のビジュアルがあれば20個のクエリが実行され、データベースからデータを抽出して計算列を作成することを意味し、レポートのパフォーマンスに影響を与えていました。そこで、レポーティングプラットフォームがリアルタイムの計算を行うのではなく、正確にデータを表示するように、データを前処理する方法を意識的に選択しました。QuickSightはSPICEエンジンを使用したリアルタイム計算が得意ですが、それでも前処理する方が効率的だと考えました。
このアーキテクチャでは、図に示されている前処理済みデータのボックスが、すべての変換済みデータを格納している領域です。将来的に、すべてのレガシーデータをAWSに移行する段階で、この前処理済みデータに流れ込むパイプラインを変更すれば、ダッシュボードを再構築することなく自動的に機能するようになります。このローンチによる効果としては、すでにコストが約75%削減され、パフォーマンスの面では、ダッシュボードの読み込み時間が1分以上から6秒未満に短縮されています。以前は、ユーザーがダッシュボードを読み込んでコーヒーを飲みに行き、運が良ければダッシュボードが正しく表示され、そうでなければタイムアウトエラーが表示されるような「コーヒーレポート」が多くありました。そのような悪い体験から、高性能なダッシュボードのパフォーマンスへと移行し、この改善により、開発中のAWSのGenerative AI機能をさらに活用できる道が見えてきています。これらのProof of Conceptについては、AWSチームと密接に協力して取り組んでいます。
教訓として、このような大規模な移行においてはリーダーシップの合意を得ることが非常に重要です。ビジネスには多くの競合する優先事項があるため、上級リーダーシップの支持がない場合、リソースが他のプロジェクトに優先順位をシフトしてしまい、全体的な移行プロセスが遅延する可能性があります。二つ目は段階的なアプローチと優先順位付けで、少ない労力で最大の価値を生み出すことに焦点を当てることです。私たちの場合、利用頻度の高いダッシュボードに注目し、少ない労力で多くのユーザーを自動的に移行することができました。この移行を開始した時、私のチームにはQuickSightの知識や経験がありませんでした。私たちは急速にスキルアップを図りましたが、皆さんもお気づきの通り、QuickSightは他のレポーティングプラットフォームと比べてそれほど複雑ではありません。開発を始めてみると、開発者それぞれが独自に作業を進め、独自に学んでいることに気づき、これはあまり効率的ではありませんでした。
そこで、この移行のための開発者コミュニティを作り、すべての学びをドキュメントにまとめてコミュニティ内で共有することにしました。開発者は一から始める必要はなく、以前のダッシュボード開発で同僚が得た知識を活用できるようになりました。これらが主な教訓でした。
次の計画として、現在これらのダッシュボードのモバイル利用の最適化に取り組んでいます。これらのダッシュボードはすでにモバイルで利用可能ですが、そのエクスペリエンスの向上を目指しています。例えば、20列あるテーブルグリッドは、PCでは見やすく表示されますが、モバイルでは2、3列しか表示できません。そこで、店舗のユーザーがバックオフィスのシステムに頼ることなく、外出先でもインサイトにアクセスできるよう、このモバイルエクスペリエンスの最適化を進めています。二つ目は、複数の画面をクリックしてグリッドにアクセスする代わりに、よりConversational BIに近づけるためにAmazon Qの機能を活用することを検討しています。
ここでRobertoに引き継ぎたいと思います。ありがとう、Ravi。皆さん、こんにちは。ここにいられることを大変嬉しく思います。 私はRoberto Figueiraで、Itaú Unibancoのデータプラットフォームとアナリティクスツール、そしてエンジニアリングを担当しています。オンプレミスのデータ可視化レガシープラットフォームから Amazon QuickSightへ、17,000のダッシュボードを移行した私たちの取り組みについてお話しさせていただきます。
Itaú Unibancoの移行プロセスと得られた教訓
Itaú Unibancoは、ラテンアメリカ最大の銀行です。当行のブランド価値は84億ドルで、18カ国に展開し、96,000人の従業員を擁し、そのうち17,000人がIT部門に所属しています。2014年から2015年にかけて、メインフレームからオンプレミスまで、銀行全体のプラットフォームを近代化する大規模なプログラムを開始し、システムをクラウドに移行しました。これは単なるリフト＆シフトではなく、レガシーシステムの一部を近代化して書き換えることも含まれています。データプラットフォームについては、銀行のデジタル化を進めるため、データドリブンであることを重視しています。過去3年間で、集中型アプローチからData Meshアーキテクチャパターンへの移行を決定し、データプラットフォーム上で本番ドメインと消費者ドメインをテナントとして分離しています。
これらを踏まえて、私たちはデータ可視化プラットフォームをオンプレミスからクラウドへ移行することを決定しました。移行の主な理由は、Raviがピーク時に経験したのと同じパフォーマンスの問題でした。私たちのオンプレミス環境は非常に低いパフォーマンスで、時折ビジネス面に大きな影響を及ぼしていました。ビジネス部門の人々から「ダッシュボードが開けない」という連絡が入ることもありました。もう一つの理由はコスト削減でした。そこで私たちはAmazon QuickSightへの移行を決めました。その理由の一つは、私たちのData Meshアプローチとの整合性であり、もう一つは製品のロードマップでした。
製品のロードマップと、ビジネス継続性に非常に重要なAWSとのパートナーシップやサポートが決め手となりました。 QuickSightを私たちのData Meshアーキテクチャにどのように統合したのか、その設計について理解していただくために、いくつかの数字をご紹介します。私たちには730のプロダクションData Lakeアカウントがあり、これらはプロダクトシステムがデータをData Lakeにロードするテナントです。そして、約1,300のコンシューマーアカウントがあります。コンシューマーアカウントは、ビジネスユーザーがダッシュボードを作成し、レポート用のデータセットを構築する場所です。
私たちには2万のテーブルがあり、これらは民主化されたテーブルと呼んでいます。これらのテーブルはプロデューサーまたはコンシューマーのアカウントに配置され、アカウント間でアクセスを共有することができます。アクセスのサブスクリプションと認可のためのプロセスがあります。民主化されたテーブルは2万と数えていますが、ローカルアカウントにはさらに多くのテーブルがあり、Data Mesh全体のテーブル数は数十万に及びます。データの探索とデータ準備を行うユーザーは9,000人おり、ユーザーデータを含めて16ペタバイト以上のデータがあります。
こちらが私たちのアーキテクチャです。左側には、ソースシステムとプロダクションのプロデューサーアカウントがあり、そこではソースシステムがData Lakeにデータを取り込んでいます。右側にはコンシューマーアカウントがあります。中央には、データガバナンス、データカタログ、データ品質のためのコントロールプレーンがあります。ここにはAWS Lake FormationとAWS Glue Data Catalogという2つのコンポーネントがあります。ユーザーがAthenaでクエリを実行したり、AWS GlueやAmazon EMRでジョブを実行したりする際、AWS Glueジョブは、Lake Formationでテーブルへのアクセス認可を取得し、AWS Glue Data Catalogでそのデータの物理アドレスを取得してから、ジョブを実行します。
このアーキテクチャを実装することで、プラットフォーム全体の分離とアクセス制御を保証することができます。ここでの考え方は、ビジネスユーザーとデータエンジニアにセルフサービスを提供するためにこのプラットフォームを構築することです。プラットフォームの運用コストを削減したいので、プラットフォームに実装するものはすべて、できる限りセルフサービスにしようとしています。ユーザーが自分のデータセットへのアクセス権を持つ人を決定します。しかし、QuickSightについて議論を始めたとき、 問題がありました：ダッシュボードを閲覧する人々と、データを探索・処理する人々が同じではないということです。
私たちはセルフサービスプロセスにおいて、独立したアクセス制御が必要でした。QuickSight用に別のアカウントを持っています。これがQuickSightのアカウントで、Restricted Folderと呼ばれる機能を使用しています。作成者は制限付きフォルダーに割り当てられ、そこでデータソースとデータセットを作成します。データセットは、コンシューマーアカウントで構築した結果データに基づいています。データをSPICEにロードし、作成者がダッシュボードと分析を保存できるサブフォルダーがあります。
作成者はビジネスユーザーグループを作成できます。これがダッシュボードへのアクセスを制御する方法です。これらのグループはフォルダーではなくサブフォルダーに割り当てられます。これにより、ユーザーは必要なアクセス制御がすべて整った状態で、ダッシュボードを通じてのみデータにアクセスできます。プラットフォーム上では、ビジネスケースやダッシュボードに応じて複数のフォルダーを用意しています。
私たちの移行には約2年かかりました。最初の6ヶ月は、決定、理解、そしてAWSサービスチームとのロードマップの確認のための協議に費やしました。その後、計画と準備に6ヶ月を費やしました。アクセス制御とセキュリティの扱い方を理解し、データプラットフォームと統合する必要がありました。銀行内のユーザー向けの接続を確立する必要がありました。というのも、オンプレミスに150の異なるデータソース（様々なデータベースインスタンスやファイルサーバーを含む）があるからです。ユーザーが自分のデスクトップからファイルデータセットをアップロードしたい場合もあるため、これらの異なるパターンすべてに対してネットワーク接続を作成する必要がありました。Amazon QuickSightの監視ログとアラートを開発し、セルフサービスアプローチを実装したかったため、接続プロセス、フォルダー作成、ビジネスユーザーを承認するための作成者向けオンボーディングプロセスを説明するドキュメントを作成しました。
また、課金とチャージバックの戦略も作成する必要がありました。Amazon QuickSightのインメモリデータベースであるSPICEは、ダッシュボードのパフォーマンスを大幅に向上させるため、作成者に特に好評です。急速に成長するため、ここでも戦略を立てる必要がありました。さらに、データセットとデータソースのバックアップと復元のプロセスも開発しました。Amazon QuickSightには分析を復元する機能が含まれていますが、私たちはこの機能をデータソースにも拡張し、より長期間維持したいと考えていました。
AWSのProfessional Servicesとアカウントチームからのサポートは、私たちの journey において非常に重要でした。また、プラットフォーム用のダッシュボードの書き換えとリデザインを担当したAWSパートナーのCompass UOLからもサポートを受けました。彼らのサポートは、特に移行時のビジネスユーザーの支援において重要でした。Compassが提供したツールを使用して、複雑さに基づいてダッシュボードを分類しました。その後、複雑さと利用状況に基づいてダッシュボードの優先順位を付け、デリバリースプリントごとにjourneyを整理しました。複雑なダッシュボードは移行に時間がかかるため、まずそれらに焦点を当て、閲覧数の多いものを優先して、サーバーの負荷を減らしオンプレミス環境のパフォーマンスを向上させました。スケジュールとの整合性を確保するため、週次のチェックポイントを維持しました。
移行したダッシュボードと削除・統合したダッシュボードの四半期ごとの測定を実施しました。当初17,000個あったダッシュボードのうち、最終的に7,600個を移行し、約10,000個のダッシュボードを削除または統合しました。
移行プロセスは、ブラジルのアカウンティングチームとAWS Professional Servicesチームのサポートを受けて、月次ワークショップから始まりました。ビジネスチームと作成者向けに、基本的なAmazon QuickSightのスキルトレーニングを提供しました。また、ビジネスユーザーとの時間外セッションを設け、プラットフォームの使用方法に関する質問や tips について話し合いました。移行の成功事例が蓄積されるにつれて、他のユーザーの移行意欲を高めるためのロードショーも実施しました。
今年の半ばに、計画と実際の移行状況との間にスケジュールの遅れが生じていることに気付きました。これは、ビジネス優先事項との競合が原因でした。また、作成者の技術スキルに関する課題もありました。そこで戦略を変更する必要があり、この時点で経営陣のスポンサーシップが非常に重要であることが判明しました。経営陣にビジネスユーザーと作成者に移行開始を促すよう依頼しました。作成者に直接連絡を取り、移行プロセスを加速させるためのヘルプとサポートを提供し始めました。最終的に編集アクセス権を取り消しました。そして、一部のダッシュボードは既に移行され、ビジネスユーザーによって承認され新しいダッシュボードに接続している一方で、レガシーダッシュボードにまだ残っているものもあることが分かりました。その結果、レガシープラットフォームの読み取りアクセス権を取り消すことになりました。
数字で見ると、昨年12月のレガシー環境では32,000人のユーザーがいましたが、現在Amazon QuickSightには34,000人のユーザーがいます。当初17,000個のダッシュボードがあり、そのうち約10,000個を統合または削除しましたが、QuickSightでは新たに15,000個のダッシュボードが作成されました。レガシープラットフォームでは120万回のビューまたはアクセスセッションがありましたが、現在は約90万回です。この差の理由は、最も頻繁に使用されるダッシュボードの一部が今月移行されたためで、来月にはこの数字が大幅に増加すると考えています。先ほど述べたように、SPICEは私たちにとって懸念事項であり、現在112テラバイトのデータがSPICEにあります。これを管理するためのガバナンスと教育に積極的に取り組んでいます。18,000のデータセットと1,700の制限付きフォルダーがあり、このアクセス分離のプロセスは非常にうまく機能しています。
ユーザーの評価は非常に好意的で、QuickSightは10倍速いと感じており、とても気に入っているようです。ピーク時の需要期間中でも一貫した応答時間を維持しています。プラットフォームのガバナンスと可観測性も向上しました。レガシープラットフォームではモバイルデバイス用とデスクトップ用の2つのバージョンのダッシュボードが必要でしたが、QuickSightでは1つのバージョンで済むというフィードバックを受けました。驚いたことに、SalesforceやMicrosoft Dynamicsなどの他のソリューションとの統合も容易でした。同様に、ダッシュボードの埋め込みにより、追加のポータルを作成し、銀行の一部のチームがQuickSightを埋め込むためのポータルを作成しています。
学んだ教訓として、経営陣のスポンサーシップが非常に重要です。経営陣のスポンサーシップがなければ、私たちはこのような形での移行を達成できなかったと思います。また、適切なトレーニング計画を持っていなかったことも、このプロセスから学んだ重要な教訓の一つです。
一部のユーザーは、ダッシュボードをより美しく見せたり、データソースを更新したりしようとしていました。それには時間がかかりすぎるため、私たちは「まずは移行を行い、その後でモダナイゼーションを行う」と伝えました。移行後には、ダッシュボードのモダナイゼーションに必要な時間を十分に確保できます。ビジネスユーザーの複雑さと創造性を過小評価してはいけません。彼らは非常に複雑で美しいダッシュボードを持っており、AWSにニーズを共有してロードマップを調整することが重要です。支援が必要な時はいつでも、Ramonがその場にいます。Ramonに問題があると相談する際、このようなAWSとの関係性を持つことは非常に重要です。
Amazon Qの活用と今後の展望
次のステップとして、QuickSightにおけるAmazon Qがあります。 私たちはすでにAmazon QでいくつかのPOCを実施しており、その経験を共有したいと思います。熟練したデザイナーの場合、ダッシュボード開発を支援するQuickSightのAmazon Q機能に価値を見出さないかもしれません。彼らは自分でダッシュボードを構築することを好みます。しかし、ビジネスユーザーにとっては価値があり、彼らからのフィードバックは非常に重要でした。QuickSightのAmazon QでPOCを試す場合は、ビジネスユーザーに向けて行ってください。技術者をPOCに参加させないでください。私自身でテストを行った際、最初にモデルを壊そうとしました。技術者を参加させると、彼らはモデルを壊そうとするでしょう。ビジネスパーソンを連れてきてください - 彼らはAmazon Qに対して適切なビジネス上の質問をするでしょう。
Amazon Qはポルトガル語ではまだ発展途上であり、より多くのメトリクス、定義、同義語を追加するために多くの作業が必要でした。現在、ビジネス用語集の定義を取得し、トピックをより自動的に構築するプロセスの作成と自動化に取り組んでいます。また、前述の通り、使用されていないダッシュボードとSPICEのガバナンスを改善する必要があります。全体的なデータ戦略として、銀行内のデータアセットの検索可能性向上に取り組んでいます。ユーザーが問題解決に適したダッシュボードを見つけられるよう、おそらくGenerative AIを使用して、より良い体験を提供したいと考えています。20,000のデータセット、20,000のテーブルから、解決したい問題に適したテーブルを見つけられるようにしたいのです。データプラットフォームの検索可能性を向上させ、Machine Learningプロセスなどについても同様の改善を目指しています。
これが私たちの journey です。ここに連絡先情報がありますので、プレゼンテーションにご参加いただき、ありがとうございました。ご質問がありましたら、お気軽にお問い合わせください。プレゼンテーション後もここにいますので、喜んでお話させていただきます。良いイベントウィークをお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion