Amazon Web Services ブログ
【開催報告】AWSで実践！Analytics Modernization ～事例祭り編 第二回～
2022年6月23日に「AWSで実践！Analytics Modernization ～事例祭り編 第二回～」を開催しました。今回の事例祭りではAWSの Analytics サービスをご活用いただいている 株式会社ソニー・ミュージックエンタテインメント、株式会社ワールドホールディングス 、株式会社コスモスイニシア、株式会社ディーバ、株式会社ミスミ、全日本空輸株式会社にご登壇いただきました。また、最後にAWSよりサーバレスの Analytics サービスについてご紹介いたしました。本ブログでは各発表内容を紹介します。
ソニーミュージックグループのデータ連携基盤の取り組み – データ連携基盤でLift&Shiftを加速する –
株式会社ソニー・ミュージックエンタテインメント デジタルイノベーショングループ エンタプライズシステム本部 ビジネスプロセス企画部 プロデューサー 山本 俊之 氏
ソニー・ミュージックエンタテインメント(以下、SMEJと略称)は、複数のグループ会社を統括する総合エンタテインメント企業です。今回は、分析の機能はあえて持たせず、データ連携にフォーカスした基盤である「XrosLoads（クロスロード）」のご紹介をいたします。本基盤は、様々なシステムからデータを収集、ストレージに蓄積、そして提供・配布を行う基盤であり、データ連携ポータルからコントロールできるようになっています。
本基盤検討の経緯としては、ビジネスが拡大している中で、システム自体の数もクラウド利用も増加をしており、扱うデータについては、音源・画像・動画といったものから再生履歴・行動履歴データなど多様化、データベースについても、システムの特性に合わせて様々なものが扱われるようになってきたという点が背景にあります。我々は、業務アプリケーションは全て AWS に移行していく方針を掲げており、オンプレにあるアプリケーションはクラウドへ Lift を進めており、クラウドネイティブなアプリケーションもいくつか既に稼働している状況です。その中で、データ連携基盤が必要だと考え、本取り組みを進めました。 
次に、本基盤の構想についてご紹介します。最初は、既存のDBの丸ごと同期＆コピーという選択肢も挙がりましたが、”自動で同期されること”よりも、ビジネスの根幹となるデータの連携が”きちんとカタログ化されること”にポイントを定め、除外しました。また、パッケージやSaaSの選択肢もデータを自分たちのコントロール下で蓄積しホワイトボックス化したい、AWSと他クラウドサービス間での通信をしたい、なにより自分たちで構想し実装したものを育てていきたいという思いがあり、除外しました。最終的には、Amazon.comのデータレイクである「Andes」のアーキテクチャにならい、冒頭ご紹介した構想を固めました。
この基盤には、社内で募集・投票し、新しいネーミングを付けました。データが行き交う交差点をイメージした「XrosLoads（クロスロード）」です。
構想が固まり、ネーミングも決まり、開発に進みます。短サイクルな開発の中で徐々に機能を追加していくというアジャイルな進め方を採用しました。体制としては、SMEJ３名と、開発ベンダーとしてアイレット株式会社様にご参画いただき、AWSのProfessional Serviceにコンサルティングを依頼しました。
続いて、どういったアーキテクチャを組んだかについて具体的にお話いたします。
今回構築した基盤は、ポータルの画面から、データの定義を登録することができるようになっています。セキュリティ設定と定義をすれば、データの配布がなされる形です。
具体的なアーキテクチャとしては、収集部分でユーザが定義を登録、AWS Lambda をキックとして AWS Glue が収集を実行する流れです。蓄積部分は、ローデータと配布データは別で保持するような構成にしています。配布部分は収集部分とは別れており、こちらもユーザーがポータル画面から定義を登録することができるようになっています。
本基盤を構築して得られるものとしては、開発コストの削減です。データ連携の選択肢をあえて限定することで仕様調整の時間短縮や、再度のテスト検証が不要になることから人的負荷の撲滅に繋がると考えています。また、XrosLoads が社内の共通言語となり、今まで散らばっていた情報が集まるという良い循環も生まれてきています。もちろん、データを集約することによる社内での苦労もありますが、それも ”システム立案・DXの醍醐味” だと考えています。
今後も継続的に本基盤の機能開発をし、日本のエンタメ業界を支えるプラットフォームとして展開させていきたいと考えています。
Amazon Athenaを利用した情報分析基盤構築と活用について
株式会社ワールドホールディングス 情報監視室 藤田 阿悠夢 氏
ワールドホールディングスは、人材・教育、不動産、情報通信、農業公園の 4 事業を有しています。弊社は積極的な M&A を行う事により、事業規模を拡大してまいりました。それにより全社的に利用するシステムが増加しデータがサイロ化しており、資料作成にかかる人的コストが増加していました。これらを解消し、全社横断で情報分析ができる環境準備として、「DWH」と「BI」を用いた基盤の構築を行う事になりました。
データを収集する為の基盤としては、本プロジェクトの前段となる取組みに参画していたベンダーが提供されていた GCP ベースのサービスを利用することになりました。そして DWH としては「BigQuery」、BI としては同じくベンダーの知見がある「Tableau」を採用することになりました。
基盤の構築もある程度形になり、自社でのみ構築・運用を行っていくことになりました。すると、いくつかの課題が見えてきました。
これら課題を解決する為、一から基盤の見直しを行いました。基盤の見直しにあたってのポイントは以下3点です。
１．パフォーマンスとコスト：当時テーブルは数十件程度だったものの、データ数は1億件を超えており、定期的にデータを取得する必要がありました。また、数十社のデータを収集するため、大量のデータを保管した際のコストパフォーマンスに優れたもの選定する必要がありました。
２. 不測の事態に社内での対応可能か：構築・運用を自社で行うのでなるべく社内に知見があり、またテクニカルサポートを受ける為の直接相談できる窓口がある事が必要でした。
３. サーバーレスでの構築：既に多くの Amazon EC2 が稼働しており、さらにサーバーを立てた場合の管理・保守リソースを削減したいという思いと、折角一から基盤を見直すのであればサーバーレスに挑戦してみたいという思いもありました。
これらのポイントを踏まえ検討を重ねた結果、コストパフォーマンスに優れ、手厚いサポートが受けられるチャレンジがしやすいAWSへの移行を行う事に決まりました。
AWS環境への引越しにあたって、Tableauを Amazon QuickSight へ移行することとなりました。また、BigQuery 部分はAmazon Athena へ移行することにしました。Amazon Athena を採用した理由としては、時間的な制約もある中で、ある程度のSQLスキルがあれば操作ができ、Amazon S3 にファイルを入れておけばすぐに分析が始められるという点です。また、実行したクエリ毎・スキャンデータ量に応じた課金体系の為、定常的なコストが発生せずコストが抑えられる点や、Amazon S3 に格納する際にファイルを圧縮しておけば圧縮後のデータに対する課金の為、さらにコストが節約できる点も魅力的でした。
AWS 移行後の構成としては、これまで人の手で収集していたデータは一部を除き自動的に収集、一部の Excel ファイルはチームで取込み用フォーマットへ転記の後、取込する形をとりました。そうしてAmazon S3 へ格納されたデータを、AWS Glue でデータカタログ化、Amazon Athena でテーブルとして利用し、最終的にAmazon QuickSight で可視化を行う構成としました。
AWS へ移行の際、検討に時間がかかった点としては、Amazon Athena で利用するファイル形式の選定でした。取り扱うデータの性質から「列指向ストレージ形式」がよいかと思い、最終的には圧縮率やパフォーマンス等を考慮した結果 parquet を採用しました。また、csv ファイルから parquet ファイルを作成するフレームワーク情報はなかなか日本語のページが見つからず、試行錯誤しました。
AWS へ移行した事によって得られた効果は様々なのですが、大きく2点です。
１. 数値情報の可視化と自動化及びデータ活用環境の充実 : 一部フローを除き、ほとんどの作業は収集から可視化までを自動化できました。また、必要な情報をいつでも提供できる環境が充実したことにより、社内のデータ活用の場が整ってきたという事も大きな効果だと考えています。
２. コストの最適化 : 元々スモールスタートであり、利用規模に対するコスト負担が大きかったのですが、Amazon Athena＋Amazon QuickSight へ移行したことで、利用規模の変動に応じたコストの最適化を実現することができました。現在、トータルコストが移行前の約10%程度までに抑えられており、現試算だと、利用範囲が拡大したとしても約25％程度に収まるだろうとみています。
現在は会計系のデータを利用した業務報告系の可視化がメインの為、限定的な範囲での利用にとどまっている状況ですが、今後はデータの種類と範囲を広げるとともに、可視化する情報を増やすことでAmazon QuickSight の利用範囲を拡大していきたいと考えています。また、業務数値以外のインフラやセキュリティシステムのログの活用に関してセキュリティチームが動いているのでそちらの可視化も行いたいと考えています。
今後、取り扱うデータの種類や量は増えていくと思いますので状況に応じて Amazon Redshift への切り替えや、AWS Lake Formation 等の便利な機能の利用も検討し、基盤を拡充させていきたいと考えています。
スモールスタートで始める、不動産 DX におけるデータ活用 ～めざせ！脱 KKD ～
株式会社コスモスイニシア R&D部門 R&D戦略部 市場戦略課 飯島 慶悟 氏・福上 瑛豊 氏
コスモスイニシアは都市環境のプロデュースを行う大和ハウスグループの不動産デベロッパーです。R&D 戦略部の市場戦略課は事業部門から独立した組織で、経営への戦略提案やデータに基づいた不動産市況の予測を担っています。なぜデータ活用の取り組みを始めたかと言うと、不動産は数値化しにくい価値を高い専門性で見定めることから、経験や知識に基づく勘に頼る傾向があるため、データを使ってノウハウを汎用化できれば業務の効率化と意思決定の精度向上に繋がると考えました。
まずは今回の取り組みを通じて実現したことを紹介します。1 つ目の事例として、Amazon QuickSight を使って査定業務を半自動化しました。従来は複数のファイルを抽出し Excel 上で加工のうえレポートを作成していたため、1 つのレポート作成に 5 時間を要していました。そこで Amazon QuickSight を使い複数データを 1 つのダッシュボードにまとめた結果、1 つのレポート作成に要する時間を 2 時間に短縮できました。
実際のダッシュボード（ダミーデータを利用）と分析内容も紹介します。下記の査定用ダッシュボードでは物件条件を入力すると自動的に物件の適正金額を計算するようになっています。従来は複数ファイルを別のファイルで加工および集計するという手間がありましたが、Amazon QuickSight で簡単に結果を得られるようになりました。
また、事例物件データの検索から地図へのプロットを自動化できるようになりました。Amazon QuickSight のダッシュボードには外部 Web サイトを組み込むことができるため、地図プロットに使う Web サイトを組み込むことで一連の作業をスムーズに行えるようになりました。
2 つ目の事例は経営状況の可視化です。従来はデータのフォーマットが決まっていたため、人によって見たい条件が異なると分析がしずらいという課題がありましたが、Amazon QuickSight でダッシュボード化することで個人が自由に条件を指定できるようになると考えました。結果、個別にデータを準備する手間なくオーダーメイドの可視化を実現しました。
次に、これらの実現において直面した課題と対策を紹介します。そもそも開始当初はどういった効果が得られるか分からず、何から始めるべきかも分かりませんでした。なのでとりあえずスモールスタートしようと考え、下記 4 つのステップを明確にすることから始めました。まず STEP 1 に関しては日頃の悩みや楽にしたいことを一覧化し、悩みに大小を付け、かつ簡単に解決できそうな悩みから着手することにしました。
STEP 2 ではしっかりお金をかけてデータを綺麗にし分析しやすい形にしました。不動産データには駅名や住所など地理情報が多いことから全角・半角や表記のズレが発生しやすく、そうすると検索における利便性が下がり間違った集計にも繋がるため、データを正規化する仕組みを構築しました。これはデータ分析の精度を左右するため、パートナーにも入ってもらいながら費用と労力を投下しました。
STEP 3 のアウトプット作成では、安価で簡単に扱える Amazon QuickSight を採用しました。スモールスタートというのもあり、安く速く簡単に実現できる方法が必要だったので、サーバー管理や初期構築も不要な Amazon QuickSight は最適なソリューションでした。Amazon S3 にデータを蓄積し、Amazon Athena で正規化のうえ、Amazon QuickSight で可視化というシンプルな構成で実現しました。
最後の STEP 4 では、より多くの人たちにデータを活用してもらえるよう勉強会やマニュアル作成を通じて地道な普及活動をしました。ダッシュボードを準備しただけでは活用されず、新しいツールへの抵抗感があったため、社内の勉強会を 3 カ月間、隔週で行うことで利便性を理解してもらい、マニュアルも周知して草の根活動を継続しました。結果、ダッシュボードの利用頻度が倍になりました。
まとめとして、まずは小さく始めてみるのが大切と考えています。この活動を1年継続した結果、課内での良いサイクルが回り始め、自然と他の事業部も巻き込んだサイクルに発展しました。
QuickSight を活用したグループ経営ダッシュボードの組み込み
株式会社ディーバ 開発統括本部 プロダクト事業部 テクノロジー統括部長 鈴木 亮 氏
連結会計の業界シェア 1 位を誇るディーバでは、大規模かつ複雑化した連結会計データから迅速かつ有用な経営判断を行うための経営ダッシュボードを Amazon QuickSight で実現し、自社の SaaS に組み込んでいます。従来は全ての可視化を内製していたため簡易的な実装でも数人月かかり、ユーザーからの細かい要望にタイムリーに応えるのが難しい状況でした。そこで BI ツールの採用に踏み切りました。
採用基準として、まずは既に利用している AWS サービスとの親和性が高いクラウドサービスであることとしました。当初はサーバー型の BI ツールも検討しましたが、メインの製品をクラウド上に配備していることから BI ツールもクラウドの方が利便性が高いと判断しました。一部サービスは別のクラウド上に構築していますが、データは AWS 上に溜まっていき、新規製品は AWS 上での展開を考えていたため、AWS の採用を決定しました。
マルチテナント対応もポイントでした。ユーザー数が増えるにつれ運営側での管理リソースが増えるため、ユーザー数増加の妨げにならないよう、なるべく管理コストは抑えたいと考えました。Amazon QuickSight の場合は 1 つのアカウント上で複数顧客を名前空間で分離のうえ管理できるため、ネットワーク設定など共通化できる部分が増え管理コストの増加を抑えられました。また、Amazon QuickSight を使えばユーザーが分析しやすい形に準備したデータソースをユーザーに配布することも容易でした。
Amazon QuickSight の組み込みは簡単で、開発は 1 人月で完了しました。ユーザー管理における認証認可や運用側との決め事により多くの時間を費やしました。
今回の取り組みを通じて、ユーザーが欲しいと考えている分析をすぐ提供できるようになりました。簡易な分析は Amazon QuickSight の機能に任せることで、連結会計特有のデータをいかに経営判断に役立つよう提供するかという点に集中できるようになりました。
Amazon Redshift モダナイズとしての向き合い方
株式会社ミスミ グループ本社 データマネジメント推進室 吉田 哲史 氏
株式会社ミスミグループ本社、データマネジメント推進室吉田様より、Amazon Redshift を中心としたデータ分析環境を以下にモダナイズ化するかについてお話しいただきました。
ミスミ社は、金型部品、工具、消耗品を提供されており、生産財では世界最大級の品揃えを誇る MISUMI EC サイトも運営しておられます。
そんなミスミ社でも、データ分析環境を構築しており、ユーザが必要なデータを必要なときに、必要な分だけ分析できる環境を構築しています。また、基盤にはグローバルのデータを収集、加工し蓄積してあり、そこからデータマートを作成するような形となっております。また、あわせて分析アプリを集中管理されています。
分析基盤を運営する中で、データ量やワークロードが増加していったようです。そのために、データ分析環境のモダナイズが必要となりました。
たとえば、2019年時点では、当時の Redshift ではデータ領域が不足したため、データレイクを導入した上でデータの配置を工夫し、データレイク内のデータについては Redshift Spectrum にてアクセスする、という方式を取られました。
さらに、翌年 2020 年には、アクセス頻度に応じてデータウェアハウス内のデータとデータレイクに出すデータの配置を見直しつつ、データレイクのデータを Parquet 化する手間を削減するために、Redshift の Data Lake Export 機能を活用されたお話をいただきました。
また 2021 年には、ミスミ社のワークロードに適切なサイズの RA3 ノードタイプが出てきたことから、継続して増え続けるデータ容量に対して、ノード追加ではなく、RA3 に移行して抜本的に問題を解決いただいたお話をいただきました。
また BI ツールからのアクセス等、ワークロードも継続して増加しており、特にデータウェアハウス間でのデータ連携については余分なワークロードと開発工数が発生していたため、RA3 の特徴的な機能であるデータ共有機能を使ってそもそもデータの複製が不要な形にすることで、そのようなワークロードや開発工数を削減いただいたお話もいただきました。
この RA3 移行のタイミングで、他の DWH サービスを検討されたお話もいただきました。「課金体系」「クラウド ecosystem」「移行コスト」「特徴的な機能」の観点から比較された結果、いずれの観点でも Amazon Redshift が有利であったことから、継続して Redshift を使っていただくことを決断された、とのことでした。
最後に、Amazon Redshift を中心としたデータ分析環境をモダナイゼーションするにあたり、Redshift の機能改善スピードは速いこと、それらの新機能を素早く活用するためには小さく始めることが重要であること、最新リリースを確認し機能改善をキャッチアップしていくことが重要である、とお話しいただきました。また、ここでは情報収集→POC→本番適用のサイクルを回していくことになりますが、そのサイクルを回す背景には内製力が重要であるとして、本セッションを締めくくっていただきました。
さらに RA3 ノードタイプではクラスタ間のデータ共有が可能であることから、RA3 に移行いただいた、とのことでした。
これらの課題を解決すべく、データレイクを導入したり、Redshift を RA3 に移行する等で対応してきました。
ANAにおけるデータの民主化に向けた取り組み
全日本空輸株式会社 デジタル変革室データデザインチーム マネージャ 井岡 大 氏
全日本空輸株式会社 （以下、ANA と略）では、エアラインビジネスの変革やグループ事業におけるビジネスモデルの変革といった内部環境と、個人情報やプライバシー要件の厳格化やデジタルテクノロジーの拡大といった外部環境の変化から、データマネジメントをより強化していく必要があると考え、ANA のデータマネジメント構想を立ち上げ、人財育成およびプロセス整備と合わせてデータ基盤の進化を目指して取り組んでいます。
ANA データ基盤の仕組み自体は持っていましたが、構造化データの取り扱いのみを対象にしていたり、開発生産性の低下によるコスト増の課題がありました。また仕様のブラックボックス化といったことが起こっており、結果としてデータがサイロ化されてしまい、結合したくてもできないといった状況になっていました。
データ活用環境についても、手動で CSV データの抽出によるエクセル業務が非常に多かったです。IT 部門が作った固定のダッシュボードによるデータ可視化が主軸となっており、セルフ BI ができておりませんでした。また PC スペックに依存したデータ分析になっており、高度な分析など負荷のかかる作業は難しいという課題がありました。
これらの課題を解決するために、新データ基盤の方に順次移行しています。新しいデータ基盤はモダンなアーキテクチャでクラウドネイティブによる拡張性を踏まえたアーキテクチャになっています。多種多様なデータ蓄積を実現したり、プライバシー保護やセキュリティの強化も施しております。サイロ化を脱却するためのデータ統合と開発生産性の向上によるコスト削減を目指しています。さらにデータカタログを提供することでデータガバナンスにもデータ活用にも貢献しています。
データ活用環境も、従来のエクセル業務だけではなく高度分析や機械学習による予測もできるようになっています。セルフ BI や自分たちで作ったダッシュボードを部門間で共有できる機能の実装も予定しています。結果として負荷の高いデータ加工ができるようになり、データ分析の高度化ができるようになってきています。いろいろな分析を自らできることになったため、人財育成の大切さを感じています。現状は既存と新規のデータ基盤は併用しておりデータは常に同期していますが、今後は人財育成や基幹システムの更改を踏まえながら順次移行していくことを計画しています。
ANA では、当初はデータ基盤の整備だけでは費用対効果の説明が難しかったため、まずデータ活用のところで短期的に効果が出せる施策から取り組みました。その中でデータ基盤の必要性をアピールしながら、施策効果を投資の原資にしながらデータ基盤の整備に漕ぎつけました。データ基盤の整備では、堅牢性の担保（情報管理の徹底）・柔軟性の確保（データのオープン化）・経済性の維持（コストの適正化）の３点を掲げて推進しています。データ基盤を整備することによって、データ活用でも中長期的な効果創出施策ができるようになりました。こうしてデータ基盤の整備とデータ活用が親和性を持ちながら推進していくことで費用対効果を出していきました。
データ基盤の進化として柔軟性を確保するために、既存データ基盤では取り扱えなかったデータを新データ基盤ではオープンに扱えるようになったのが特長です。機密情報に応じてアカウントは分けており、Amazon S3 のデータレイクと Amazon Redshift の DWH があります。生データを S3 に取り込み、その中で機密情報のハッシュ化と、文字コードや日付型を合わせたりする共通処理を AWS Glue で実装しています。それを Cleansing Data という形で管理し、Amazon Redshift に転送してデータを公開しています。機密情報を取り除いた形のデータを、Amazon WorkSpaces を経由して分析者に展開することで、セキュアな環境から直接分析データを取り扱うことができるようになっています。データの持ち方を効率的にするために、クラスター間で Amazon Redshift の Data Sharing を活用しています。また最近では、もっと手早く試していくために Amazon Athena の整備もしております。そこでパフォーマンスが欲しい時には Amazon Redshift を活用するなど、日々データ戦略の実現と課題解決に向けた活動を継続的に実施しております。
ANA では、スキルに合わせてデータの民主化を展開していく必要があると考えています。データ活用の流れの中で、データレイク・DWH の領域については、一元管理方針を掲げながら DX 室主導で統制を図っています。一方、データマートから分析の領域においては、スキルに応じた展開の仕方があると考えています。データエンジニアリングのスキルがある部門については、データマートの整備からビジネス部門側で主導していただくことでスピード感を持った展開ができます。ただし、これは情報連携やコミュニケーションが非常に大事になるので、同じ方向性を持った取り組みにしていくように日々連携しています。
データマートや可視化の領域まで DX 室や IT 部門が提供していき、データ分析からビジネス部門主導型でやっているところがあったり、場合によっては、IT 部門の方で完全支援型の仕組みもございます。このように組織のスキルに合わせて展開していくことが、スピードの面でもコストの面でも有意義だと考えています。
このように ANA としては、DX 室・IT 部門が全ての価値創造を主導するのではなく、ビジネス部門との協創／共創を重視しながら、デジタル部門とビジネス部門がタッグを組みながら価値創造に向けた業務を推進しています。
運用いらずで手軽に分析！サーバレスで始めるAWSのAnalyticsサービス
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト, アナリティクス 平間 大輔
AWS の平間からは、AWS が提供している Analytics サービスのうち、手軽に始められるサーバレスのサービスとして、代表的なものをいくつかピックアップしてご紹介しました。
まず、各サービスを紹介する前に、現在におけるデータ活用の重要性とその課題についてお話ししました。日々生み出されるデータは年々増加し、データソースやデータの種類も増えています。一方でそのデータを活用するユーザーも増加しており、各ユーザーが求める分析も様々なものとなっています。これら多様なデータに対する多様なニーズに答えるための仕組みとして、AWS ではモダンデータ戦略という呼び方で、データソースからデータを収集し、データのガバナンスを効かせながら各種分析サービスで分析するまでの流れを有機的に結びつけています。
それら AWS の分析サービスの柱となっているものが、スケーラブルなデータレイク、パフォーマンスとコストを重視した専用設計、サーバレスで使いやすい、統合されたデータアクセス・セキュリティ・ガバナンス、組み込みの機械学習という５つです。このうち、今回はサーバレスで使いやすいサービスの中から、データ加工からデータ分析のためのクエリ、最後はデータの可視化までを扱う 4 つのサービスについて紹介しました。
データ加工の処理をサーバレスで実施することができるのがAWS Glueです。AWS Glueは、データがどこにあるのかを管理するデータカタログと ETL 実行エンジンを主要コンポーネントとするサービスで、データレイクへのデータ収集から、ターゲットとなる他の分析サービスへのデータロードまでを一貫して作成・管理することができます。ETL 処理はソースコードを直接書くこともできますが、AWS Glue Studio を使えばプログラムを書かずに ETL ジョブを作成することができます。また実際のデータを確認しながらデータクレンジングなどの前処理を行うことのできる、データサイエンティスト向けのサービスとして、AWS Glue DataBrew も用意されています。
加工が終わったデータをSQLでクエリすることのできるサービスとして、AWS では Amazon Athena とAmazon Redshif tの2つが用意されています。従来は Amazon Athena のサーバレスクエリエンジンで手軽に分析を始め、より複雑な分析を行うようになったり、データ分析を行うユーザーが増えてきてパフォーマンスが課題となったときには Amazon Redshift のクラスタを立ち上げて（プロビジョンして）利用を続けていました。この Amazon Redshift を運用負荷なくより簡単に使うためのオプションとして、Amazon Redshift Serverless がプレビュー公開されました。これによって、インフラ管理者がいない部門や、利用頻度は低いが高いパフォーマンスが必要となる分析環境などで、エンタープライズレベルの高度な DWH を手軽に使えるようになりました。
データをクエリできるようになったら、最後はSQLを書かない人でも手軽に可視化し、分析を行うことができるサービスがあると、より多くのユーザーが自分で分析できるようになります。これを実現するのが Amazon QuickSight です。Amazon QuickSight はクラウドに最適化されたサーバレスの BI サービスで、グラフィカルな分析ダッシュボードをPCやモバイルなどで利用することができ、またその画面を社内ポータルやSaaSアプリケーションに組み込むこともできます。また多くのユーザーは、過去を分析した後に未来を推測することを望みますが、そのための機能として、Amazon QuickSight では組み込みの機械学習機能を複数用意しています。Amazon SageMaker と連携して、より高度な機械学習の結果を可視化することもできます。
このように、AWS の分析サービスは、サーバレスでインフラ運用が不要となることで一般企業の業務部門でも無理なく利用可能な各種サービスを提供しています。ぜひお試しください。
まとめ
今年度第一回目の事例祭りに続き、アナリティクスの各トピックに関する事例が盛り沢山なセミナーでした。日本のお客様向けに AWS アナリティクスサービスの最新動向を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております。お申込みリンク。
アナリティクス事業本部 事業開発 甲谷 優・伊東 大騎・藤沢 夏美