Amazon Web Services ブログ

【開催報告】Amazon Redshift事例祭り(ビジネス編)~Redshift Supports Our Business〜

こんにちは。アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクトの平間です。

2020年10月22日に、「Amazon Redshift事例祭り(ビジネス編)~Redshift Supports Our Business〜」を開催しました。Amazon Redshiftは、大量のデータを高速に分析できるクラウドDWHサービスです。Amazon Redshiftは、お客さまのビジネスをどのようにサポートしているのか、その裏側も含めて具体的で興味深い内容を、メディカル・データ・ビジョン株式会社の中村正樹様とシルバーエッグ・テクノロジー株式会社の柳内伸夫様からお話しいただきました。また、その他の海外事例や、ビジネスで活用する際に重要となってくるAmazon Redshiftのセキュリティについて、AWSよりご紹介させていただきました。

Amazon Redshift 最新事例集 [Slides]

甲谷 優
アマゾン ウェブ サービス ジャパン株式会社 事業開発マネージャー

Amazon Redshift 最新事例集

甲谷からは、Amazon Redshiftを活用してビジネスを効果的に進めているお客様について、海外と国内それぞれの最新事例をご紹介しました。

まずは海外から、レストラン予約サイトなどを運営するYelp様の事例を紹介しました。Yelp様ではビジネスオーナーが無料でYelp上にページを公開可能にするとともに、ビジネスオーナーがページのPV数をトラッキングすることを可能にしています。この行動ログデータ量は数ペタバイトにも上ります。さらに、Yelp様社内でも、データサイエンティストなどのデータ分析を行うユーザーが増加しています。これら大量のデータを多様な分析ニーズに合わせて処理するため、Yelp様ではAmazon RedshiftとAmazon S3との間でデータ連携を行うレイクハウスアーキテクチャを利用した基盤を構築しました。このAmazon Redshiftクラスターでは、多数のユーザーから同時に実行されるクエリを処理するために、同時実行スケーリングとクエリの優先順位付けを有効に活用しています。Yelp様では、更に最新のRA3インスタンスを導入することにより、同じコストで2倍程度のパフォーマンス向上も実現されました。

次に、Warner Bros.様の事例をご紹介しました。Warner Bros.様では、これまでゲームを運用している各チームがそれぞれ別々のツールを利用して分析を行ってきました。これをAWSのAnalyticsサービスで統合し、一貫性があってユーザーを獲得・維持するために有用な分析を行うことを目指しました。初めはオンプレミスのDWHを中心とした基盤を構築しましたが、データの反映が遅い、スケーリングに限界がある、アクセスがSQLに限定されるなどの課題がありました。これをAmazon Redshiftを用いたDWHとAmazon S3によるデータレイクとを連携させたレイクハウス構成とすることで、柔軟な運用を実現しつつ、ユーザーからの多様なアクセス要求も満たすことができました。

次に、海外の事例としてモデルナ様の事例をご紹介しました。モデルナ様では科学者のデータ分析と意思決定支援のためにAmazon RedshiftとBIツールを組み合わせたシステムを利用しています。ここではAmazon Redshiftを1つのソースとする一方で、Amazon S3をバックアップとして使うことで、バックアップ・リカバリが容易に行え、巨大なIT部門を社内に保つ必要がなくなりました。

ここからは国内の事例となります。まずはすかいらーく様の事例をご紹介しました。すかいらーく様では国内3000店舗、年間4億人が利用するレストランのPOSデータを分析するシステムを構築しました。それまでは数日かかっていた複雑な分析が、Amazon Redshiftを始めとするAWSサービスを利用したシステムを導入することで数秒に短縮され、仮説検証・施策投入のサイクルが飛躍的に向上しました。この結果、従来手法と比較して広告宣伝費の削減と売上高の成長を実現できました。システム構築そのものも、採用決定から1ヶ月という短期間で実現できています。

次に、良品計画様の事例をご紹介しました。良品計画様では実店舗の客数を増やしたり、デジタルマーケティングを効果的に行いたいという課題を解決するために、MUJI Passportという施策を導入しました。この施策を分析するための環境として、良品計画様では、伸縮可能で柔軟な分析ができる基盤の構築を目指しました。Amazon Redshiftを始めとした各ツールを利用したシステムを構築し、試行錯誤しながら徐々に高度化することによって、クーポン利用率の大幅な向上、実店舗客数の増加といった大きな導入効果を得ることができました。

最後に、あきんどスシロー様の事例をご紹介しました。スシロー様では、回転寿司レストランのオペレーションを改善するため、寿司皿にセンサーを付け、そのセンサーから送られてくるストリームデータを収集・分析をして、食材廃棄の削減やオペレーションの改善を実現しました。この分析基盤にAmazon Redshiftが使われています。Amazon Kinesisと組み合わせることで、ストリームデータの分析にもAmazon Redshiftを有効活用することができています。

最後に、これらデータ分析がビジネス課題を解決している事例に追いて、Amazon Redshiftが分析のコアのクエリエンジンとしてお客さまのビジネスをサポートしていること、更に最新事例では、Amazon Redshift SpectrumやRA3インスタンスなどのAmazon Redshiftの最新機能が、運用の柔軟性を高めるために活用されていることをお伝えして、このセッションを締めくくりました。

Redshiftを活用した医療ビッグデータビジネスの業務改善 [Slides]

中村 正樹 様
メディカル・データ・ビジョン株式会社 取締役

Redshiftを活用した医療ビッグデータビジネスの業務改善

中村様からは、メディカル・データ・ビジョン様の事業内容の紹介と、そこで用いられるビッグデータを扱う上での悩み、そしてその悩みを解決するためにAmazon Redshiftを導入した経緯についてお話していただきました。

メディカル・データ・ビジョン様は、「豊富な実証データに基づいた確かな医療の実現」という経営理念のもと、医療機関、製薬会社、保険会社などに、データ解析・調査のための医療データベースのサービスを提供しています。このデータベースは日本最大規模のものであり、その圧倒的なデータボリュームと、特に豊富な高齢者層データを持つこと、そしてデータ更新が毎月行われるというデータの新鮮さから、多くのお客様に選ばれています。サービスの利用は、インターネットからWebで手軽にアクセスして調査できるサービスから、お客様の要件に合わせてアドホックにデータを集計、もしくは元データを切り出して提供するといった、柔軟なサービス提供を行っています。

このような多様なサービスを実現する上で、ビッグデータの分析基盤は非常に重要なものでした。しかしながら、従来のデータ分析基盤はパフォーマンスに大きな課題を抱えていました。Webツールからのアクセスで検索結果の表示が非常に遅い、アナリストがSQLでデータを集計する際に、SQLの実行結果がなかなか出てこないなどです。このため、メディカル・データ・ビジョン様ではデータベースの切り替えプロジェクトを実施することとなりました。

まず2017年に、従来のDBから切り替えるためのPoCが行われました。ここではオンプレミス上の従来のDBと、Amazon Redshiftのds2.8xlarge 2ノードとで実行速度の比較を行いました。その結果、Amazon Redshiftを利用すると、従来のDBから5倍以上の速度改善をもたらすことがわかり、Amazon Redshiftを次期DBとして採用いただくこととなりました。

2020年には、さらなる高速化のために、Amazon Redshiftの新インスタンスであるRA3インスタンスを検証いただきました。クエリの単体実行と多重実行を、現行のds2.8xlargeとra3.16xlargeについて、ノード数を変えながら測定を実施いただきました。その結果、両者ともノード数を増やすスケールアウトを行うことで、単体実行、多重実行ともに処理速度が大幅に向上することを確かめていただきました。そのため現行インスタンスのds2.8xlargeのノード追加と最後まで迷われたそうですが、INSERT系の処理速度と価格、そしてAWSからの推薦もあり、ra3.16xlargeの採用に至ったとのことでした。

最後に、メディカル・データ・ビジョン様のシステムでの、Amazon Redshiftを含む各AWSの活用状況をご紹介いただき、セッションを締めくくられました。

Amazon Redshiftで稼ぐための基礎知識 – セキュリティ編 [Slides]

平間 大輔
アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト

Amazon Redshiftで稼ぐための基礎知識

平間からは、Amazon Redshiftを用いてビジネスを進めるにあたっては不可欠なセキュリティについて、主にユーザー認証とアクセスコントロールについてご紹介しました。

Amazon Redshiftでのユーザー認証は、まず大きくクラスター管理を行うユーザーの認証と、データベースにアクセスするユーザーの認証に分かれます。このうちデータベースアクセスのためのユーザー認証は、一般的なRDBMSと同様に、Amazon Redshift内でユーザーを作成し、認証を行うのが基本的な動作です。しかしこのデメリットとして、ユーザー管理を他のシステムと連携することができず、個別管理となってしまう点があります。そのため、Amazon Redshiftでは、SAML2.0準拠のIDフェデレーションを利用したシングルサインオンをサポートしており、Amazon Redshift ODBC/JDBCドライバーにおいて、ADFS、Okta、PingFederate、Azure ADとの連携をサポートしています。ここでは、実際にADFSを利用したIDフェデレーションについてデモを行いました。

次に、Amazon Redshiftにおけるアクセスコントロールの仕組みについてご紹介しました。認証を得たユーザーが、実際にどのデータにアクセスができるのかを決めるのが、アクセスコントロール(認可)です。Amazon Redshiftでは、SQLのGRANT文とREVOKE文を用いて各オブジェクトのアクセス権を細かく管理することができます。テーブルやビューでは、列レベルでの権限付与も可能となっています。また、DWHでユーザーがアドホック分析を行う場合によくあるトラブルが、作業用のテーブルを作りすぎてストレージ容量が逼迫してしまうことです。これを防ぐため、Amazon Redshiftでは、スキーマ単位で使用量の上限(QUOTA)を設定することが可能になっています。これらを組み合わせることで、Amazon Redshiftでは、アプリケーションからのアクセスや、データサイエンティストからのアドホッククエリなどが混在する環境においても、適切な権限管理を行うことができるようになっています。

また、Amazon Redshift Spectrumを利用したときの権限管理についてもご紹介しました。Amazon Redshiftの中で管理する場合は、Amazon S3バケットに紐づく外部スキーマを分けて、必要とするユーザーのみにそれぞれのスキーマ利用権限を付与することで管理します。また、AWS Lake Formationと連携することにより、Amazon S3上のデータに対する権限管理を、他のAWSサービスも含めて一元化することができ、かつ、Amazon S3上のファイルにおいても列レベルでの権限付与が可能になります。

最後に、ここまでの内容を振り返ってセッションを締めくくりました。

「サマリ結果と請求のための集計」から、「データ活用にも使える集計」に [Slides]

柳内 伸夫 様
シルバーエッグ・テクノロジー 株式会社 エンジニアリング部 副部長

「サマリ結果と請求のための集計」から「データ活用にも使える集計」に

柳内様からは、お客様への請求のための集計しか行うことができなかった従来の集計システムを、Amazon Redshift SpectrumとAWS Lambdaを用いたシステムに移行することによって、より詳細な分析が可能になるとともに、今後の事業拡大にも耐えられるスケーラブルな仕組みとする事ができるようになったことについてお話していただきました。

シルバーエッグ・テクノロジー様は、創業以来一貫してパーソナライゼーション技術の開発・提供を行う、デジタルマーケティング企業です。国内No.1シェアのリアルタイム・レコメンドサービス「アイジェント・レコメンダー」では、AIエンジンによる高精度のレコメンドを実現し、多くのお客様にご利用されています。集計システムでは、これらのサービスで日々発生する数億件のリクエストを集計し、顧客・レコメンド表示エリアごとに表示数・クリック数・受注数を計算しています。その結果をもとに異常検知・改善検討・請求などの業務を行うため、集計値は重要な数値であるそうです。

従来の集計システムでは、S3上のデータをEC2経由でDWHにロードしてクエリし、その結果をさらにプログラムで加工して最終結果のみをAmazon RDSのPostgreSQLにロードして提供する形となっていました。このため、集計処理に時間がかかる、最終処理結果のみを保存しているため分析に必要な集計の内訳がわからない、性能向上の手段がEC2のスケールアップとなるため、コスト高な上にそれでもリソース不足である、といった悩みを抱えていました。

この課題を解決するため、新集計システムではAWS LambdaとAmazon Redshift Spectrumを組み合わせたスケーラブルな構成を採用しました。データ加工にはAmazon Redshift Spectrumを利用して高速な処理を行います。フロントエンドのDBはPostgreSQLを引き続き採用し、Amazon Redshiftとdblinkで接続することで後続業務はそのまま実行できるようにし、中間明細データに対してはAmazon AthenaやBIツールでのアクセスを実現しています。これにより、集計間隔が日次から毎時となることで、対応から1〜2時間で迅速に対応結果が確認できるようになりました。また中間明細データの活用も可能となり、さらに性能が必要なときは顧客数に応じてAmazon Redshiftをスケールさせるというように、これまでの課題を解決することができたとのことでした。

最後に、新システム構築・運用の際に苦労した点についてお話していただきました。これはAmazon Redshiftの特徴がまだ把握できる前に、Amazon Redshiftが得意としない処理を行わせていたということと、運用後にデータ量が増えてくるに従って顕在化した課題があり、どちらもその解決策についてご紹介いただきました。

まとめ

今回は、Amazon Redshiftを利用してビジネスを改善し続けているお客様より、貴重な生の体験談をお話しいただきました。Amazon Redshiftのご利用に興味を持っていただいたお客様、またAmazon Redshiftに限らず、AWSのサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、こちらのリンクからぜひお申し込みください。