Amazon Web Services ブログ
【開催報告】AWSで実践！Analytics Modernization ～事例祭り編 第三回～
2022年9月22日に「AWSで実践！Analytics Modernization ～事例祭り編 第三回～」を開催しました。今回の事例祭りではAWSのAnalyticsサービスをご利用いただいている The ROOM Door 株式会社様、IQVIA ソリューションズ ジャパン株式会社様、株式会社カヤック様、株式会社デンソー様、ディップ株式会社様にご登壇いただきました。本ブログでは当日の各発表内容を紹介いたします。
Serverlessで始めるAWSのAnalyticsサービス — Serverlessサービスのご紹介＆デモ
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト, アナリティクス 平間 大輔
まず、AWS の平間から、AWS が提供している Analytics サービスのうち、手軽に始められるサーバレスのサービスとして、代表的なものをいくつかピックアップして、デモを交えてご紹介しました。
各サービスを紹介する前に、現在におけるデータ活用の重要性とその課題についてお話ししました。日々生み出されるデータは年々増加し、データソースやデータの種類も増えています。一方でそのデータを活用するユーザーも増加しており、各ユーザーが求める分析も様々なものとなっています。これら多様なデータに対する多様なニーズに答えるための仕組みとして、AWS ではモダンデータ戦略という呼び方で、データソースからデータを収集し、データのガバナンスを効かせながら各種分析サービスで分析するまでの流れを有機的に結びつけています。
それら AWS の分析サービスの柱となっているものが、スケーラブルなデータレイク、パフォーマンスとコストを重視した専用設計、サーバレスで使いやすい、統合されたデータアクセス・セキュリティ・ガバナンス、組み込みの機械学習という５つです。このうち、今回はサーバレスで使いやすいサービスについて焦点を当て、データ加工からデータ分析のためのクエリ、最後はデータの可視化までを扱う 3 つのサービスについて紹介しました。
データ加工の処理をサーバレスで実施することができるのが AWS Glueです。AWS Glue は、データがどこにあるのかを管理するデータカタログとETL実行エンジンを主要コンポーネントとするサービスで、データレイクへのデータ収集から、ターゲットとなる他の分析サービスへのデータロードまでを一貫して作成・管理することができます。ETL 処理はソースコードを直接書くこともできますが、AWS Glue Studio を使えばプログラムを書かずに ETL ジョブを作成することができます。また実際のデータを確認しながらデータクレンジングなどの前処理を行うことのできる、データサイエンティスト向けのサービスとして、AWS Glue DataBrew も用意されています。
加工が終わったデータをSQLで高速でクエリするデータウェアハウス (DWH) のサービスとして、AWS では Amazon Redshift を提供しています。従来はデータ量や要求される処理速度などの要件に応じて、主に情報システム部門などのインフラを管理する担当者が適切なサイズの Amazon Redshift のクラスタを立ち上げて（プロビジョンして）運用していました。この Amazon Redshift を運用負荷なくより簡単に使うためのオプションとして、Amazon Redshift Serverless が登場しました。これによって、インフラ管理者がいない部門や、利用頻度は低いが高いパフォーマンスが必要となる分析環境などで、エンタープライズレベルの高度な DWH を手軽に使えるようになりました。
データをクエリできるようになったら、最後はSQLを書かない人でも手軽に可視化し、分析を行うことができるサービスがあると、より多くのユーザーが自分で分析できるようになります。これを実現するのが Amazon QuickSight です。Amazon QuickSight はクラウドに最適化されたサーバレスのBIサービスで、グラフィカルな分析ダッシュボードをPCやモバイルなどで利用することができ、またその画面を社内ポータルやSaaSアプリケーションに組み込むこともできます。また多くのユーザーは、過去を分析した後に未来を推測することを望みますが、そのための機能として、Amazon QuickSight では組み込みの機械学習機能を複数用意しています。Amazon SageMaker と連携して、より高度な機械学習の結果を可視化することもできます。
このあと、Amazon Redshift Serverless にデータをロードして、Amazon QuickSight で可視化を行うデモを行い、サーバーレスのサービスを組み合わせることで簡単に分析業務を始める例をお見せしました。
このように、AWS の分析サービスは、サーバレスでインフラ運用が不要となることで一般企業の業務部門でも無理なく利用可能な各種サービスを提供しています。ぜひお試しください。
10万円vs10億？DX基盤構築に必要なトランスフォーメーションのご紹介
The ROOM Door 株式会社 代表取締役 秋山 泉 氏
DX 推進を進めるにあたっては、ビジネスモデルそのものを変革することが重要になってきます。ただ単に決まった何かをやり直すというものではないという点が重要です。日本における課題として IT 人材が不足しているということが言われますが、これはビジネスを理解している IT 人材、そして IT を理解しているビジネス人材が不足しているということを意味しているかと思います。また委託先にノウハウが蓄積されてしまっているということも言われがちかとは思いますが、そういったことが本質的な問題ではなく、お互い IT とビジネスを理解しているという点が最も重要なポイントかと思います。一番重要なのは、まず変革が必要であるという点です。
DX の検討に際してゴール設定、つまり始まりがどこにある点について皆さん異口同音におっしゃることとして、データがサイロ化されて色々な部署にもたれているためにこれを統合したいという点です。多様なサイロ化したデータを集めたいという点が共通ポイインとになっているというようににご理解ください。これはひと昔前の DWH を作りたいという問題意識にニーズがよく似ているため、トランスフォームを忘れてしまった場合、DX をやろうとしたところがまず DWH を作ろうとしてしまうという失敗に陥ってしまいます。
収益を増やすための分析テーマ群という部分については詳しくはお話ししませんが、LTV の最大化について様々なテーマがあります。これを実現するためにCDPを作るというのが最近のトレンドになっているという印象をもっています。CDP を作るにしてもまずサイロ化したデータ群を統合するというDXの要素が必ず入ってくるため、まず SSoT（Single Source of Truth）を手に入れるところからスタートしがちであるという点が共通項になっているといえるかと思います。
ただ、ひとことにサイロ化しているとはいっても、今ここで見ていただいているように経理財務・コールセンター・セールス・社内業務・外部・マーケティングといったようにばらばらに存在していますし、一つの部門の中でも CDA を使いながら勘定奉行も使っています、というような場合があります。かつ、各部門が自部署のデータを外に見せたがらないケースもよくありますが、自分のデータを共有しない限りはよそのデータも見せてはもらえません。そこで、DX においてはまず部門の垣根などにこだわることなく SSoT 、つまり本来の真のデータを一箇所に集めた場所を作ることの必要性をご理解いただく必要があるかと思います。
これを実現しようとする際に、DX を進めます、CDP を作りますといったお題目で進んでしまうために結局は CDP で使えることを目指した設計がされてしまことがあります。本来源泉システムの中で閲覧範囲を絞る必要がありますが、その後でどこのデータについてどのデータを誰に・どこに見せる必要があるのかを管理する部分が重要です。
ELT 処理層についても、これまでは IT 部が全てやってくれていたものについて今後は ELT 層を実現したりデータの中身の調査を外注に出したり社内の人に調査してもらうといった必要があるため、彼らにデータを閲覧する権限を与える必要があります。
データを入れていく入れ箱の設定ですが、DX の時代に作る必要のある箱というのは昔の DWH ではないという点がポイントになります。DX 時代のあるべき設計手法としては、源泉データはなにも考えずにデータレイクにコピーしていきます。もしくはコピーでなくともレイクから覗きにいくことができる構成をとる必要があります。従来の DWH の設計思想で行けば複数のシステムから ETL でもってきて、そして DWH の中でデータの流れを考えますが、源泉から持ってきた段階でデータが破損しているケースも多いです。旧来の DWH の設計思想でやってしまうと、忘れたテーブルについてベンダーに依頼してしまうとその度お金がかかります。全てのデータがレイクに綺麗に入ってさえいれば、後から必要なデータを必要なタイミングで取り出すことが可能です。
なぜこのようなことばかりお話ししますかといいますと、まさにタイトルの 10 万円 vs 10 億円というところに関連するところで、設計思想を間違うとどうなるかということに帰結します。高い値段は出せないし早く実現したいのに 1 年 2 年かかるというような相談を弊社が受けて、いざ見積書提案書を見せてもらうと as-is tobe 調査を行い設計を行う……というような形で、DX でなく DWH を再度を作りなおすような実態になっていることがよくあります。
価格的にもひっくり返ってしまうような金額になっています。初期の設計で 1 千万円、作ってしまうのに 10 億円といいったような形です。そこで再度正しい設計思想のもとで再設計して見積もりを作ったところ、
ソース把握からレイクへのデータ投入までで 2 ヶ月で終わりました。これは去年のお話しです。圧倒的に期間が短縮されたことで費用も圧縮されています。ただし源泉からデータを持ってきたあとにデータの中身の調査は丁寧にやらせていただいており、ただ単に費用が安くなるというのではなく準備期間が短くなったことによってすぐ分析にとりかかることができるようになったこととしてご理解いただければと思います。
実際に金融期間様と一緒によくお仕事させていただいておりますが、福岡ファイナンシャル様の事例では初期の調査では 3 人が張り付き 4 ヶ月でドキュメントまで作成されたそうです。つまりそんなには大変なことではないということです。各ベンダーさんともナレッジノウハウともに貯めてらっしゃいますので、そう大きな調査なしで使い始めることをご理解いただければ、実はデータレイクの作り方・設計思想・実装というのは簡単にできるものです。
弊社のある事例では、AWS をデータレイク基盤に採用しています。なぜ AWS をデータレイク基盤に採用したかという点については、基本データが S3 に入っていたですとかシステムが AWS 上に乗っていたという点もあるのですが、大きいな 3 つの理由があります。①データ品質の管理。引っ張ってきたデータが壊れてしまうと困るため、源泉のデータを綺麗に入れることを担保するためのチェックツールである Deequ ②ビジネス部門や分析部門が好きな中間テーブルを作りアプリ側に渡すことができる ELT ツールが GUI で実装できる Glue Data Brew があるため、データ元からどういった処理をしてアウトプットを作ったのかを残せ、しかもボタンひとつでバッチ化できる点 ③ Salesforce との親和性が高い点。これらが主な理由です。
実際データレイクの作るための費用としては、パッと作るだけであれば 10 万円もあればできると思っています。ある程度ドキュメントを読めば、皆さんの会社側でレイクはさくっと作ることができまう。 AWS のセリングトークを信じるならば、数日から10日程度で作れるのではないかと思います。DX を得るための基盤は安い、そして実際のデータを見て運用の部分をきちんとする必要があるのであって、基盤を作ること自体に数億円もの費用をかけることは無駄です。
初期の検討では、Redshift の部分だけSnowflakeを採用することを前提に Amazon と会話を始めていました。そこで、ちょうどいいタイミングで Snowflake とまったくおなじ設計思想の Amazon Redshift Serverless というサービスがリリースされました。
Snowflake と全く同じ設計思想でしたので、データサイエンティストはその都度Amazon Redshiftのお腹の中に中間テーブルを作りたがるのですが、Snowflake であれば利用者の人数によってパフォーマンスを入れ替えられるのですが、Amazon Redshift Serrverless はもってこいの製品でしたためこちらにトランスフォームしました。また Pay for use すなわち使った分だけの課金になっているため、この部分も採用した理由になっております。
設計思想が Snowflake のほぼそのままになっているため、コンピュートノードとストレージノードのレイヤが切り分けられているためパフォーマンスが足りなくなった時には計算ノードを増やすことができるため非常に便利でした。ただ、設計思想が同じだからといってパフォーマンスが本当に同じかどうかのチェックは GA（一般公開）になるまで何度もテストを繰り返しました
料金の部分につきましては、同一コンセプトのクラウド DWH ではの一番高いバージョン（プライベートリンクがサポートされているなどで、これが必須の条件となる）と比較したところ、Amazon Redshift Serverless の料金はかなり安かったというような結果にもなりました。
Amazon Redshift Serverless は AWS を採用する理由のひとつにもなりました。
Redshift Serverless を活用した医療データ分析サービスの性能改善
IQVIAソリューションズ ジャパン株式会社 テクノロジーソリューションズ 清宮 忍 氏
IQVIAソリューションズ ジャパン株式会社（以下IQVIAと省略）では誰がいつどのような診療をうけどのような薬を処方されたかについての情報であるレセプトを健康保険組合から収集し、IQVIA Claimsデータとして所有しています。Claimsは請求という意味です。この主な利用者は製薬会社です。市場自体の把握、費用対効果の分析などに利用しています。データベースのみならず、IQVIAでは分析用のBIツールを備えたClaims Analyzerというツールも提供しています。
Claims Analyzer- は AWS 上に構築されたマルチテナントの SaaS の Web システムです。お客様はインターネットを経由してシステムにアクセスします。バックエンドのデータベースとして Amazon Redshift を利用しています。
全市場のデータ規模は 550 万人分となり、レコード件数は 17 億件にも上ります。データセットが大きいこと、また速いレスポンスが求められることからデータベースには Amazon Redshift を採用しています。その一方でユーザが十数名程度しかおらず、毎日使うシステムでもないためシステムのアイドリング時間が長いという特性を持っています。実際に 2022 年 1 月から 7 月の実績を確認したところ、データベースへのコネクション数が一件もないアイドリング時間となっていました。アイドリング時間が 81 時間というのは 1 ヶ月に換算すれば 24 日と 8 時間は誰も利用していないということを意味します。誰も利用していないにもかかわらず、Amazon Redshift の費用だけが発生しているという状態です。とてももったいない話です。ですので Amazon Redshift Serverless が登場した時、私たちのサービスにぴったりのソリューションだということですぐに Amazon Redshift Serverless を試してみることにしました。
まず最初に気になったのはプロビジョンドで実行しているクエリがそのまま実行できるのか、あるいは修正する必要があるのかという点です。開発環境を使いプロビジョンドのクラスタをサーバーレスに置き換えてアプリを動かしてみました。その結果既存のクエリを一切変更することなく動くことが確認できました。次に気になったのはパフォーマンスです。そこでプロビジョンド型とサーバーレス型のパフォーマンスを比較してみました。プロビジョンドのクラスタは本番環境と同じ dc2.large 4 ノードを使いました。サーバーレスは 96RPU としました。RPU が大きすぎるとコストが膨れ上がりますし、小さすぎるとパフォーマンスがでません。そこで過去 6 ヶ月の本番環境のクエリ処理回数と処理時間を調べ、コストシミュレーションを繰り返しました。その結果 96 RPU がコストとパフォーマンスのバランスがとれた私たちのシステムに最適のサイズだと判断しました。
テストケースですが、最初のテストケースではニキビ治療薬を処方された患者を抽出してデータマートを作ります。二つ目のテストケースでは老人性白内障と診断された患者を抽出してデータマートを作ります。このようにして 6 種類の抽出条件を用意しました。それぞれについて 3 回の抽出ずつ抽出処理を実行しその平均時間でパフォーマンスを比較しました。なお、検証は今年の 6 月 14 日と 16 日の 2 日間で実施しました。一般公開前のプレビュー期間であったことを付け加えておきます。
ちらがプロビジョンドとサーバーレスの処理時間を比較した結果です。全てのケースでサーバーレスの処理時間が短くなりました。最も改善したケースでは 455 秒が 56 秒に短縮されました。元の時間のわずか 0.12 倍です。中央値で見てももとの時間の 0.4 倍に短縮されています。アプリの行動を書き換えることも DB のパラメータを調整する面倒なチューニングを行うこともなくこれだけのパフォーマンスが得られたのは驚きでした。
今度はデータを増やしてパフォーマンスを検証しました。弊社では今年 8 月に IQVIA Claims data の拡大版データセットをローンチしました。拡大データセットの規模は患者 1400 万人分。患者台帳・請求・診断・処方・処置をあわせるとレコード件数は 40 億件です。基本データセットのおよそ 2.5 倍の規模です。私たちはデータセットが大きくなることでレスポンスが遅くなることを心配していました。そこで基本データセットの時と拡大版データセットの時で処理時間がどのように変化するかを調べました。時間の比較はさきほどと同じく 6 種類の抽出条件で 3 回ずつデータマートを作りその平均時間を比較しました。
こちらが患者数 550 万人の基本データセットと患者す 1400 万人の拡大版データセットの処理時間を比較した結果です。やはりデータサイズが増えたことでデータマート作成に要する時間は長くなりました。しかしデータサイズが 2.5 倍になったのに対して処理時間の伸びは中央値で 1.4 倍程度に収まりました。最大でも 1.8 倍でした。データサイズが増えた割には処理時間は長くはならなかったという印象です。
それでは、このセッションでお話ししたことを振り返りたいと思います。私たちの分析ツールの特性はデータセットが大きいこと、ユーザの利用頻度が少ないこと、その一方でリアルタイム性が求められることの 3 点でした。クエリが実行される間だけ課金される Amazon Redshift Serverless でコストを最適化できると期待しています。プロビジョンドとサーバーレスのパフォーマンスを比較して私たちのユースケースでは処理時間が半分あるいは半分以下になりました。データサイズを増やしてのパフォーマンス検証でも 2.5 倍のデータサイズの増加であれば処理時間の伸びは 1.4 倍程度に収まりました。
ここまではサーバーレスの優れた点ばかりをお話ししてきました。一方で気を付けるべき点もあります。それはコスト管理の難しさです。私たちのケースでは本番環境のクエリの実行回数と実行時間を調べサーバーレスに置き換えた場合の費用を試算しました。その結果プロビジョンドのクラスタに支払っている金額よりも少ない費用で収まるという見通しを持っています。とはいえあくまでもシミュレーションの結果にしかすぎません。いざ本番環境でサーバーレスを使ったら予想以上に費用がかかるおそれもあります。一ヶ月の費用がほとんど変化しないプロビジョンドと比べるとコストが変動するサーバーレスではコスト管理の難しさがあります。すでに本稼働中のシステムであればサーバーレスに置き換えた場合のコストをある程度信用できる制度で見積もろることができるかと思います。しかし新しいサービスの立ち上げ前など利用頻度の予測が難しい場合はプロビジョンドを使った方が無難かもしれません。
最後に、弊社の Amazon Redshift Serverless の利用予定ですが、開発環境はすでに Amazon Redshift Serverlessへ の移行が完了しています。今年の11月に本番環境も移行する予定です。私の発表は以上で終了です。Amazon Redshift Serverless を検討している皆さんの参考になれば幸いです。
小規模プロダクトにおけるRedshift Servelessの活用の検討
株式会社カヤック エンジニア 池田 将士 氏
資料ダウンロード
面白法人カヤックでは、鎌倉で主に Web 技術を用いて人の印象に深く残るような面白コンテンツを作成しています。
そんなカヤックでは、(1) 事業が多種多様であるため個々のプロダクトが小規模になりがちであり、(2) その中でも売却、撤退事業がよくあるため事業を跨いだ統合データ基盤を創りにくいことから、データ分析基盤に Amazon Redshift (特に RA3 ノードタイプ) を導入したくても予算に合わないということがよく起きていました。ここで、カヤックでは、Redshift を導入するにしても、 no upfront の dc2.large 1 年リザーブドインスタンスぐらいの値段で、ストレージとコンピュートが分離した最新の Redshift を運用したい、というニーズが出てきました。
そこで、Redshift Serverless の導入の検討を開始しました。Redshift Serverless では特にコストネックになるコンピュートの課金が、データウェアハウスがアクティブな時にだけ課金されるため、うまく運用すればコストが抑えられるためです。ここで、目標値を 150 USD/month と設定されました。
まずは、この 150 USD/month が、どの程度の Redshift Serverless 容量に相当するのか、どの程度まで使えるのか確認されたようです。Redshift Serverless のコンピュートは RPU という単位で課金されます。32 から 512 の間で、8 RPU 刻みでコンピュートのサイズが決まります。ここで最低の 32 RPU (ベース RPU 容量にて設定) を設定して1 分間課金された場合、0.263 USD の課金となります。したがって、150 USD/month までの場合、32 RPU で月当たり 9.488 時間まで使える、ということになります。
Redshift Serverless の管理単位の概念として、名前空間とワークグループがあります。今回のセッションのトピックはコストコントロールですが、コストコントロールについてはワークグループの設定が中心となります。
ここでコストコントロールの設定のために重要になるのが、ワークグループのベース RPU 容量の設定と使用制限の設定になります。使用制限の設定は、頻度と上限に達した時のアクションが決められ、柔軟な設定が可能であることを示していただきました。
CloudWatch Metrics による、Redshift Serverless の料金の監視方法も共有いただけました。Redshift Serverless のワークグループの、Compute Capacity と Compute Seconds を確認いただくことにより、その時点での課金の状況を確認いただけます。
ここで、カヤックさんのとあるプロダクトの Redshift の監査ログから、リソースの使用状況をご紹介いただきました。98.2% のワークロードがシステムによる ETL/ELT の実行で、ユーザのクエリ実行時間は 1.4%、1 週間で 70分ほどでした。1 ヶ月で 300分 (=5時間) ほどになる計算ですが、ここで余裕をみて 7 時間程度クエリする前提とします。このとき、150 USD/month にするためには、月の使用時間は 9.488 時間までだったので、ETL/ELT の時間は月当たり残りの 2.488 時間 (日当たり 5 分) に抑えなくてはならない、ということになります。
したがって、ETL/ELT の時間を削減する必要があります。ここで、現状のETL/ELT のリソースの使用状況の詳細を調べると、Load、Redshift へのデータの取込みに時間を使っていることがわかりました。
そこで、データを Redshift にロードせずにクエリするために、データレイククエリ (S3 に置いたデータを Redshift マネージドストレージに取り込まず、外部スキーマ内の外部テーブルとして直接クエリする機能) や、Aurora/RDS のデータを Redshift から直接クエリする Federated Query の活用を推奨されていました。
また、より多くのデータソースを外部テーブルとして扱うための OSS である psql-front の紹介もしていただきました。PostgreSQL のデータベースオブジェクト (外部テーブル) に見えるのですが、それに対してクエリを実行すると実態としては連携しているサーバー (コンテナ) 上の Data Fetcher が外部のデータソースからデータを取得する形で動くものだそうです。
ですので、今回のように予算からクエリの実行時間を制限したい場合は、ユーザクエリを優先した上で他のボトルネック (今回は Redshift マネージドストレージへのデータのロード)を見つけ、それに対する打ち手を打つ (データレイククエリや Federated Query、psql-front 等の Redshift マネージドストレージにデータをロードしなくてもデータが取ってこれるようにする) ことが重要であることを教訓としてシェアいただきました。
社内データ分析基盤の構築 ～使われる基盤として成長した７つのポイント～
株式会社デンソー ITデジタル本部 データ活用推進室 渡邉 崇志 氏
資料ダウンロード
デンソーでは幅広い自動車部品を製造しております。注力分野として、電動化・自動運転・コネクティッド・非車載事業としての FA や農業の工業化に取り組んでおり、これらを推進するためにもデータ活用の重要性が増してきています。
2019 年頃より社内でデータ利活用による業務改善やビジネス化の検討が活発化していましたが、プロジェクト毎に分析環境をイチから構築しており、データ活用の前段階で膨大な時間がかかっていました。そこで、構築済みの社内分析環境を提供することで、データ利活用までのリードタイムを短縮できると考え、基盤の開発に着手しました。
自ら環境環境を構築する場合、データ分析以外のITスキルが必要になるためビジネス部門にとっては難易度が高く、基盤の開発に1年かかってしまうこともありました。一方で、我々の構築した分析基盤を使用する場合、既に基盤がリリースされているので、簡単な利用申請だけで、最短当日から利用いただけます。このように、早く・安全に・便利に使える基盤の構築を目指しました。
データ分析基盤の構成としては、基盤は Web アプリとして構成してあり、各プロジェクトの環境ごとに AWS アカウントを用意しています。ユーザーはデータ分析・活用に必要な機能を、Web アプリからワンストップで利用することができます。
ここから、ユーザーがデータ分析に注力できるように、我々が基盤構築において工夫したポイントを紹介します。
１. UI操作1時間で構築完了
分析環境の構築には、AWS CloudFormation を活用しています。各 AWS リソースをコードとして扱い、管理の効率化やリソース作成または更新の自動化ができるようにしています。また、当基盤では、AWS 以外のサービスも活用していますが、AWS Lambda を用いて AWS とそれ以外のリソースの橋渡しを実現しています。CloudFormation と Lambda の活用により、基盤の環境構築はほぼ自動化されており、簡単なUI上のクリック操作のみで、最短申請当日から分析を開始できるスピーディーさを実現しています。
２. お支払いは一声かけるだけ
当基盤のように、様々なクラウドサービスやソフトウェアを利用する場合、個別にライセンス契約や支払い処理が必要となります。社内それぞれのプロジェクトごとに契約するのではなく、利用するサービスを予め一括で契約締結しておき、基盤側で費用を支払うようにしています。これにより、ユーザーはすくにサービスの利用を開始することができます。
３.セキュリティ、ワンストップで一元管理
当基盤では Web アプリが複数のクラウドリソース権限やユーザー管理、IP 制限などのセキュリティ対策を一元管理できるようになっています。データ分析をしたいユーザーの方は、必ずしも IT に詳しいとは限らず、むしろ IT とは関わりの薄い現場のリーダーが最もビジネス的に価値のある分析の着眼点を持っている場合もあります。分析を開始する際に必要となるセキュリティの枠組みや考え方を勉強する手間なく、簡単に基盤を使い、データ活用に注力できるようにしています。
４. リソース監視＆強制停止！防げ高額請求
従量課金制のクラウドサービスでは、ユーザー側が意図せず大量データ処理を続けてしまい、膨大な請求が発生してしまう場合があります。そういった事態を避けるために、当基盤ではサービスのリソースの稼働時間や消費量を監視し、異常な値となった場合は、通知を行うとともに強制的に利用を停止する機能を備えています。
５. インフラ・ミドル維持からの解放
当基盤は、クラウド・サーバレスの構成としています。この構成にすることで、OSやミドルウェアの維持業務は不要で、新機能の開発や検証、デプロイを高速化することができます。AWSで提供される多種多様なサービスを活用することで、一から開発することなく基盤の新機能を開発することができ、工数を削減することができています。これにより、開発・運用メンバは完全内製化を実現し、短期間でユーザ要望に寄り添った機能開発やセキュリティ対応に注力することができています。
６. 月に１回のアップデートで変化に追従できる。そう、Agileならね。
機能開発などのアップデートについても、内製メンバでのアジャイル開発により、ユーザーの要望やセキュリティ対応を即座に反映することができています。当社の基盤は、約1年半で20回ものアップデートを行ってきました。本発表でご紹介の機能も、リリース当時に全て揃っていたわけではなく、リリース後にユーザーの声を聞きながら少しずつ充実させていきました。まずは最低限の機能でリリースし、そこからアジャイルによる高頻度のアップデートで成長させていくことがポイントだと考えています。
７. 小さく産んで、大きく育てる
正式リリース前には、開発メンバから利用してもらえそうなプロジェクトへ声掛けし、現状の機能の問題点などを確かめていきました。こうした改善なく、問題点を抱えたまま大々的に宣伝をすると、早速利用しようと考えるユーザーからの評価が低くなってしまいます。このようなユーザーは社内のDXを先導している立場の方も多いため、今後の基盤拡大に大きな妨げとなってしまいます。まずはスモールスタートで改善を重ね、利用実績が出来てきたのちに、社内の発表会などで継続的に紹介し続けることで、着実に利用数が増加中しています。
データ分析基盤のリリースから1年半が経過した現在の利用実績は以下の通りとなっています。
データ分析基盤のベースとして AWS を選んだ理由としては、各種サービスが、基盤を利用いただけるユーザーにとって利便性が高く、我々開発運用チームにとっても高い対応力を実現できるからです。具体的には、充実したサポートや豊富なマニュアルにより困った際には確実に解決することができる点、また、頻繁なアップデートにより機能追加・改善される点が挙げられます。また、 AWS Lambda を活用したことで、利用プロジェクト毎の特別な要望を受け、新機能をすぐにデプロイすることが可能となっています。
データ分析基盤の利用イメージとして、２つご紹介させていただきます。１つ目は、基幹システムデータの集約・開放プロジェクトです。これは、社内の基盤に蓄積されているデータを当基盤に蓄積・加工・公開することで、社内の一般ユーザーにも広く利用できるようにするものです。基幹システムに蓄積されている各部品の生産情報は、生産や開発の現場からニーズが高い一方、レガシーなシステムからの閲覧が簡単にはできず、現状IT部門で個別に依頼に対応しています。そこで、このプロジェクトでは、基幹システムからデータを書き出すプログラムを作成し、データ分析基盤にアップロードすることで自動で整形・加工後データウェアハウスに格納され、すぐにユーザー側からのデータ利用が可能となります。
２つ目に、社内車両データ活用プロジェクトです。現在、車からセンサー等のデータを取得し、各部品の製品設計に活かす試みが行われています。しかし、実際にそのようなデータを活用する場合は、データ活用における課題に加え、車両データを扱う上での課題もあります。社有車のデータを当基盤に収集・開放することで、ユーザー側でそのような課題を気にする必要なく、すぐに分析を始めることができます。
基盤の今後の展望としては、まず、データ加工機能の強化をしていきたいと考えています。具体的には、AWS Glue DataBrew 活用によるデータ分析ミス防止です。基盤を利用いただいているプロジェクトの中でも、現状、データの分析・加工のレベル感にバラつきがあります。よくあるユースケースや加工処理についてはレシピとして登録し、データを自動でデータウェアハウスに格納できるようにすることで、ETL 処理のミスによる誤った分析を防止することができます。
また、シングルサインオンの導入も進めていきたいと考えています。現状分析基盤の利用者ごとにユーザをCognito上に作成して管理していますが、従業員１人１人に発行されている社内用アカウントと多重管理することになります。社内のID管理を担うサービスと Cognito 間で SSO を導入することで、よりセキュアで簡単にアクセスできる環境を構築したいと考えています。
数万規模データを QuickSight で可視化！SaaS ビジネスでの QuickSight 利用事例 〜ディップでイチから BI 導入してみた〜
ディップ株式会社 DX事業本部 プロダクト開発部データストラテジー課 課長 豊田 晋也 氏
資料ダウンロード
ディップでは人事労務にまつわる課題をワンストップで解決するコボットを運営しています。データストラテジー課では社内のデータ活用におけるニーズに対応していますが、課題がありました。まずコボットはサービスごとに環境が分かれているためサイロ化のリスクがありました。そしてカスタマーサポートや営業の担当者が各システムからデータを抽出したうえでデータ分析をしたりレポート作成をしたりするのに多大な時間がかかっていました。そこで BI ツールの検討を始めました。
以前はオープンソースの BI ツールを使っていましたが、パフォーマンスや可視化における課題がありました。かつ、依頼に応じてデータストラテジー課がデータ抽出する運用も非効率でした。そこで、データを依頼する側と請負う側双方の課題を解決できる BI ツールを検討した結果、Amazon QuickSight を採用しました。
BI ツールというと初期導入においても数百万円のコストがかかりがちですが、Amazon QuickSight であれば初期費用をかけずに始めることができます。AWS サービス間の連携も簡単で、Amazon Redshift 上のデータとすぐに接続できました。共有の機能も充実しているので、将来的には社内用途に加えて顧客向けのデータ提供も検討しています。パフォーマンスに関してはインメモリの SPICE を使うことで高速化を図れます。セキュリティ管理も重要です。SaaS 運営においては必ずユーザーの個人情報が発生するため、Amazon QuickSight の行/列レベルセキュリティで外部漏洩のリスクを防いでいます。分析・ダッシュボード単位でもアクセス権限を柔軟かつ簡単に設定できます。
下図が今回のアーキテクチャです。データの発生源であるコボットのシステムは複数あり、それぞれ特性が異なるため、データ連携のアプローチも変わってきます。従って、まずは各システムから Amazon S3 にデータを集約し、それを AWS Glue および Amazon Redshift で前処理および分析を行っています。
次は整備したデータ環境を社内に周知し活用を促すフェーズです。SQL や BI ツールの経験がない社員への訴求には悩みましたが、ハッカソン形式で実際に触れてもらう機会を設けることにしました。結果、見たいけど見れなかったデータをすぐに活用できて便利だった、可視化も簡単だった、という前向きなコメントをもらいました。日頃の業務に活かせる内容であったのもポイントでした。Amazon QuickSight を使えばやりたいことを実現できるという印象付けをすることで導入障壁を下げることができました。詳細はこちらのデジレバnoteも。
本格的な運用に向けて、既存 BI ツールからのレポート移行も行いました。4 サービスぶんで約 3000 テーブルありましたが、Amazon QuickSight にはカスタム SQL 機能も備わっているため、データセットの作成については SQL のコードをそのままコピー＆ペーストで完了しました。優先度が高いレポートから順次移行していきました。社員の利用を円滑に進めるという観点ではシングルサインオンも重要なため、社内の ID 管理基盤である Microsoft Azure Active Directory と SAML 連携する形で、社員の半数以上が Amazon QuickSight にアクセスできる状態になっています。
最後に実際のユースケースを紹介します。人事労務コボットは従業員の労務手続きを自動化するサービスなので、企業の契約書登録数や企業ごとのサービス設定状況から利用率の KPI を確認しています。他には在籍数に対する従業員の入社・退社手続き割合やログイン数を見ています。このような分析により、活用が進んでいないユーザーに対して利用案内やサポートをいち早く提示することができます。また、業種ごとの顧客傾向を把握することで各ユーザーに適したアプローチができます。
次が常連コボットでの活用です。店舗での常連顧客の獲得を目的とした LINE アプリを簡単に作成できるプラットフォームです。店舗ごとのアプリ登録数、ユーザーごとの訪問数、発行・利用ポイント数、などを分析することで、常連獲得における状況を確認できます。うまく使えていないユーザーには積極的にアドバイスするような体制を設けています。
まとめ
今年度第一回・第二回の事例祭りに続き、Analytics領域の先進的な事例が盛り沢山のセミナーとなりました。特に今年の7月に一般公開となりましたAmazon Redshift Serverlessについても、その直後の開催だったにもかかわらず詳細な検証を行っていただいた結果採用へ踏み切っていただいた貴重な事例を頂戴することができました。
AWSでは日本のお客様向けに AWS アナリティクスサービスの最新動向を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております（お申込みリンク）
アナリティクス事業本部 ソリューションアーキテクト 平間大輔
アナリティクス事業本部 事業開発 甲谷 優・伊東 大騎・藤沢 夏美・松山航平