Amazon Web Services ブログ
【開催報告】AWSで実践！Analytics Modernization ～事例祭り編～
2023 年 5 月 18 日に「AWS で実践！ Analytics Modernization ～事例祭り編～」を開催しました。今回の事例祭りでは AWS の Analytics サービスをご利用いただいている ミーク株式会社様、ニッセイ情報テクノロジー株式会社様、 ビットバンク株式会社 様、株式会社 Gunosy Gunosy Tech Lab DR&MLOps 様、にご登壇いただきました。本ブログでは当日の各発表内容を紹介いたします。
Amazon OpenSearch Serverless のご紹介
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 深見 修平
AWS の深見からは 2023 年 2 月に GA した Amazon OpenSearch Serverless をご紹介しました。
従来の Amazon OpenSearch Service ではマスターノード、ホットノード、Ultra Warm ノード、コールドストレージと複数のノードタイプから柔軟な設計が可能です。これらの要素を組み合わせたクラスター環境を簡単に構築することができる一方で、実際に構築する際にはデータサイズなどの情報をもとにユースケースごとに適したサイジングをユーザーが行う必要があります。
このような従来の構築と運用に関わる課題への新しいソリューションが Amazon OpenSearch Serverless です。Amazon OpenSearch Serverless を利用することでユーザーはインフラのプロビジョニング、設定、スケーリングを行う必要がなくなります。基礎となるリソースを継続的に調整することが可能なため、必要なリソースの予測が難しいワークロードに対しても自動的にスケールを行い対応することができます。
セッションでは Amazon OpenSearch Serverless のアーキテクチャについて解説をしました。Amazon OpenSearch Serverless ではインデクシングと検索、ストレージといったそれぞれのワークロードを分離したアーキテクチャになっています。そのため、それぞれが独立してスケールすることができる形になっています。また、各ノードは複数のアベイラビリティーゾーン（AZ）に分散され配置されるため、可用性も考慮した設計になっています。
本セッションでは、実際に Amazon OpenSearch Serverless がどのように使うことができるか、デモをお見せしながら説明しました。デモでは Amazon OpenSearch Serverless のコレクションを作成するところから Amazon Kinesis Data Firehorse を利用してデータを投入するといった内容について説明しました。
Amazon OpenSearch Serverless は、負荷に応じて自動でリソースのスケールイン・スケールアウトに対応しており、クラスター構成の管理が必要ありません。アップデートや運用タスクについてもユーザーの負担が削減されています。注意点として、一部の API をサポートしていない点などが挙げられますが、クラスターの構築・運用管理が必要なく非常にはじめやすいサービスとなっているため、是非お試しください。
Amazon QuickSight によるデータ統合と活用で経営・サービス改善のスピードアップを実現！
ミーク株式会社 技術・運用本部 加藤 敦基 氏
ソニーグループのミークでは IoT 向けモバイル回線を Web コンソールから簡単に追加できるサービスを展開しており、AWS 上に顧客情報や回線情報を蓄積しています。社内では各本部が定期的に経営陣へ営業、経営、サービス利用など様々な観点について報告していますが、従来はそれらデータ抽出に関する問い合わせが開発側に集中し、データ抽出後も本部ごとで異なるツールを使って分析していたため非効率な状況でした。例を挙げると、作業の重複、分析業務の属人化、データの信憑性、開発コストの増大、などの課題がありました。
課題に対して改善策を検討した結果、Amazon QuickSight を採用することにしました。採用理由はいくつかありますが、データ連携の容易さがあります。既にミークの環境では AWS を使っていたため、Amazon QuickSight とのデータ連携が容易なだけでなく、Salesforce のような AWS 外への接続が可能であったのも大きなポイントでした。他には、Amazon QuickSight はダッシュボードの作成など一連の操作が簡単であるため学習コストが低く、さらには閲覧ユーザーが安価な従量課金制であることから利用コストも抑えられるため、経営陣への導入説明し易かった点もポイントでした。
Amazon QuickSight 導入後は、Amazon OpenSearch Service、Amazon Simple Storage Service（Amazon S3）、Amazon Relational Database Service（Amazon RDS）のデータを Amazon QuickSight から一元的に活用できるようになりました。これを機に経営陣は報告を待たずしてタイムリーに最新データを確認できるようになりました。
Amazon DynamoDB のデータも Amazon Athena のフェデレーテッドクエリを介して連携しています。また、外部データとして Salesforce のデータを直接連携しています。Salesfore 上でも可視化はできますが、既に多くの情報を Amazon QuickSight で一元化していたのと、Salesforce は営業での利用が中心となりアクセス権限を持っているのは一部の社員であるため、Amazon QuickSight 上で可視化することにしました。Salesforce のデータと他 Amazon QuickSight のデータはともにミークの顧客 ID 単位で管理されているため、クロスでの分析も容易でした。
Amazon QuickSight で特に気に入っている点が 2 つあります。1 点目はインメモリエンジンの SPICE です。SPICE を使うことでデータソースでの参照負荷を軽減できます。特に Amazon RDS への接続に関してはサービス運用への影響も注意が必要なところですが、SPICE にデータを取り込むことで Amazon RDS に負荷を与えることなく分析を行えます。2 点目はデータの結合です。異なるデータソースのテーブルを Amazon QuickSight 上で結合できます。特に Salesforce の営業データを Amazon RDS が持つ顧客情報と顧客 ID で結合するのに良く使います。
次に Amazon QuickSight で作成しているダッシュボードと分析内容について紹介します（下記は架空データを利用）。まずはサービス全体の月次売上推移を確認のうえ、法人顧客ごと、営業担当ごと、提供サービス・プランごと、で売上を細かく分析します。
次が回線解約と異常値の確認です。異常検知と前月比で変化が大きかった項目の検知に関しては ML Insight を活用しており、異常値をトリガーにメール配信もしています。
予測機能も使って SIM 回線数の伸びを予測しています。
以下は回線速度のモニタリングです。キャリアごとに性能が設計通りかを分析しています。Amazon OpenSearch Service で分析した結果を Amazon QuickSight で可視化しています。
Amazon QuickSight を導入することでデータの分断を解決し、鮮度の高いデータをタイムリーに活用できるようになりました。経営陣は定例の報告を待たずしてダッシュボードから経営情報を確認するようになりました。これを機に別のグラフやデータのニーズも高まり、可視化の開発工数も短縮したことから、社内的には新しいデータの依頼もしやすくなりました。
社内向けに活用していたモバイル回線のデータをサービス利用者に社外提供する仕組みも開始しました。ミークのコンソール画面に Amazon QuickSight のダッシュボードを組み込んでシステム化し、可視化サービスを提供をしています。
Amazon QuickSightを活用した医療機関向け分析サービス提供事例のご紹介
ニッセイ情報テクノロジー株式会社 ヘルスケアソリューション事業部 医療ソリューションブロック 上席スペシャリスト 淵上 武暁 氏
ニッセイ情報テクノロジーでは日本生命グループにおけるシステム構築のノウハウを土台とした IT サービスやコンサルティングを展開しています。今回の事例は病院向けサービスにおける Amazon QuickSight の活用です。病院の経営状況は年々厳しさを増しており、赤字の割合は 7 割を超えます。そこで、病院向けの経営分析システムを通じて経営状況の分析と改善を行えるようにしています。分析にはその病院で行われた医療行為などのデータを用いており、例として患者数、患者の病名、入院状況、診療内容、使用薬剤があります。このような分析を通じて、病院の強みを活かせているか、効率的な医療行為が行われているか、などを判断します。
病院側はデータ分析に時間と人手を割くことが難しいため経営課題と取り組むべきアクションをパッと把握できることを期待しています。現在は病院経営におけるノウハウと方法論は確立されているため、それを効率的に活かせるシステムが求められています。
定型的な分析コンテンツも提供していますが、不十分な側面もあります。例えば法改定の情報が出た際に、病院としては影響範囲をすぐに確認したいところですが、定型分析コンテンツの開発が追い付かず、タイムリーな分析ができません。また、定型コンテンツにない独自の経営指標を使って分析したいという要望もありますが、個別の要望に対応していくのは困難です。このような要望に応えるために Amazon QuickSight の採用を決めました。病院個別にダッシュボードサービスを提供しています。
ユーザー管理の仕組みについては、定型コンテンツを使う既存ユーザーから Amazon QuickSight にアクセスできるよう、Amazon Cognito 上の定型コンテンツユーザーからシングルサインオンで Amazon QuickSight へアクセスできるようにしています。
当システムでは医療行為に関する機密情報を扱うため、情報漏洩の防止は重要なポイントでした。まず当システムは同一アカウント上で異なる病院ユーザーが存在するマルチテナント環境であり、絶対に別病院のデータが見えない構成にする必要があります。そのために、データベースを病院ごとに分けて作成し、ログイン情報から適切なデータベースに接続するようにしています。他には、病院ごとで名前空間に分離することで、他病院のユーザーを見れなくする、他病院に共有をできないようにする、アクセスできるデータを自病院のものに限定する、など実現しています。ユーザーによるデータソースの作成も禁止しています。
サービス提供に向けては運用上の課題もありました。1 点目はダッシュボードの効率的な作成についてです。ダッシュボードの作成は日々お客様と対面している保守サポートチームが担うことになりましたが、ノーコードでダッシュボードを作れるとはいえ BI ツールの経験がない保守サポートチームにとって簡単ではありませんでした。データセットやダッシュボード共有など、馴染みのない概念を理解することから始める必要がありました。そこで、ダッシュボードの作成ルールを定義し、「この通りにすれば作れる」といった内容を準備しました。あとは実践あるのみで、実際に手を動かすことで経験を積み、徐々に使いこなすメンバーが増えてきました。
2 点目の運用課題は、保守チームが作成したダッシュボードをどうお客様に配布するかです。数百の病院が存在するマルチテナント環境にダッシュボードを配布するのは容易ではありません。Amazon QuickSight の分析アセットを各病院に展開する方法では時間がかかりすぎます。
そこで以下のようなダッシュボードを配布する仕組みを構築しました。まずはダッシュボード作成専用の名前空間を作成し、そこで保守チームはデータセットとダッシュボードを作成します。次にそれらを全病院あるいは一部病院の名前空間に対してコピーし適切な権限を設定します。このコピーする部分をダッシュボード配布機能という運用ツールで簡単に実行できるようにしました。
更には、通常のシステム開発フローと同様に開発・ステージング・本番環境を Amazon QuickSight に関しても用意して、環境間でコピーするツールを作成しました。
お客様からは Amazon QuickSight のダッシュボードサービスが分析に役立っているという声をいただいており、分析が得意なお客様からは自分でもダッシュボードを作成したいという要望があります。また、ダッシュボード作成を担う保守サポートチームからは、従来はお客様の声を開発チームに届けることしかできなかったのが要望を直接かなえることができるようになったと声がありました。今後の展望としては、今回構築した仕組みを企画段階の実証実験に使えると考えています。更には、お客様が作ったダッシュボードを他病院にも配布できるようにすることで、お客様の分析事例が共有できるような仕組みにしたいと考えています。
ビットバンクにおける Amazon Redshift の活用事例 ~Amazon SageMaker と Redshift Data API を添えて~
ビットバンク株式会社 Platform部 データチームマネージャー 谷津 香氏
ビットバンク株式会社 Platform部 データチームエンジニア 加藤 雅行氏
ビットバンク株式会社 Platform部 インフラチームエンジニア 長尾 康志氏
ビットバンク株式会社は日本でTop3に入る暗号試算取引所を運営している暗号資産交換業者です。暗号資産取引所、暗号資産販売所、レンディングサービスの3サービスを展開しています。今回は Amazon Redshift を用いたデータの活用戦略、Amazon SageMaker 環境構築および Amazon Redshift Data API を用いた顧客へのデータ提供の 3 つをご紹介します。
まず Amazon Redshift を用いたデータの活用戦略です。この 1 年間、Amazon Redshift を活用して良かった点、微妙だった点があります。良かった点として、クエリ速度が劇的に改善、チューニングが今の所不要、DataSharing が利用しやすい、Amazon Redshift の新機能が継続的に登場する部分です。微妙だった点はAmazon Aurora MySQL との互換性や仕様の問題に引っかかる、また高頻度にメンテナンスがある点です。
良かった点のクエリ速度が劇的に改善した部分は、今までは数時間から数十時間要していた処理が約2分で終わるようになりました。
微妙だった点の 1 つ目として、Amazon Aurora MySQL との互換性や仕様の問題があります。特に HLL（History List Lenght）が発生する点で、レコード数が巨大なテーブルを全件スキャンするような操作が走ると CPU 負荷が少しずつ上昇する現象です。例えばフェデレーテッドクエリや AWS Data Migration Service（AWSDMS）にてAmazon Auroraに対し大規模 Select を行うと発生する可能性があるため、別途対策が必要です。Amazon Aurora MySQLのRollbackSegmentHistoryListLength（undo ログレコード）の上昇により検知ができます。
微妙な点の 2 つ目として、割と頻繁にメンテナンスがあります。ただし、事前のイベント通知やメンテナンスタイミングの調整で予期しないダウンタイムの回避が可能です。今後はサーバーレス化についても検討の余地があります。
bitbank における Amazon Redshift の活用事例として、データ共有機能をデータマート用途で活用しています。必要なデータのみ共有ができる点、元データを書き換えられる心配がない点により、社内外で活発なデータの利用が可能になります。
bitbank における Amazon Redshift を中心としたデータ活用の軸です。大きく 3 つあり、財務領域目的では暗号資産の財務処理におけるシステム整備や業務効率化、データ分析/マーケティング領域目的ではデータサイエンティストやマーケターなどのビジネス部門が利用するデータ基盤やデータの整備、プロダクト領域目的ではデータ基盤を用いた顧客への機能開発を行っています。中心に Amazon Redshift を置くことでデータ活用を推進しています。本日はその中でも、Amazon Redshift を用いた Amazon SageMaker 環境構築と Amazon Redshift Data API を利用した顧客へのデータ提供について説明します。
従前の分析環境にある課題として、分析環境はローカル端末 or Amazon Elastic Compute Cloud（Amazon EC2） で Jupyter Notebook を起動していた、人によって自由にライブラリをカスタマイズしていた、大量データを扱うのに Redash からデータを取得していたなどがあります。まず 1 点目では、Amazon SageMaker に統一することで管理負担を下げることにしました。2点目は、Amazon SageMaker に分析者共通で利用するカスタムイメージを用意し解決しました。3 点目は、データの取得先を Redash から Amazon Redshift に変えることで解決しました。
Amazon Redshift を利用した Amazon SageMaker 環境の構成図です。分析処理に必要な Python パッケージやスクリプトなどを管理している GitLab へ push することで CI/CD が起動し Amazon SageMaker カスタムイメージを Amazon Elastic Container Registry（Amazon ECR）へ格納します。次に、定期的に Amazon EventBridge をトリガーに Amazon SageMaker を定期的に起動します。その際に Amazon ECR からカスタムイメージを取得します。分析に必要なデータは Amazon Redshift Python コネクタを利用して Amazon SageMaker から Amazon Redshift Consumer クラスターにアクセスします。その際、Amazon Redshift Producer クラスターから必要なデータのみデータ共有で参照しています。エラー処理については、AWS Chatbotを利用し Slack 通知をしています。
課題解決の結果、Amazon SageMaker カスタムイメージの利用による属人化の解消と分析環境構築を IaC 化することで異なる分析用途の環境構築も横展開することが可能となりました。
また、データ参照先を Redash から Amazon Redshift に変更することで Redash の制約から解放されたこと、クエリ速度を改善することが出来ました。
まとめとして、必要なデータのみを分析環境の Amazon Redshift にデータ共有することでサイロ化を防ぐことができました。また、分析環境が統一されたことでデータサイエンティストが分析業務に注力することが出来るようになりました。
この図は Amazon Redshift と Amazon SageMaker 環境を横展開していく際に簡略化と汎用化を反映した図です。分析環境に必要な内容を AWS CloudFormation でテンプレート化しておき、GitLab Runner のデプロイ機能を利用し環境構築します。
ここからの内容は Amazon Redshift Data API を利用した顧客へのデータ提供です。ビットバンクが顧客に提供するデータとして、取引所の注文履歴、取引所の約定履歴、販売所の売買履歴があります。本日は上から 2 点についてお話します。
取引所の注文履歴は期間や通貨ペアを指定して暗号資産の注文履歴を表示できる機能です。取引所の約定履歴は期間や通貨ペアを指定して売買が成立した履歴を取得できる機能です。
従来は Amazon Aurora からデータを抽出し顧客にデータを提供していました。
従来の構成では ① データ抽出の負荷がサービスに影響しうるという点です。これはサービスと分離したデータ基盤として Amazon Redshift を利用することで解決しました。② Amazon Aurora への負荷を軽減するため、抽出上限を 1 リクエスト当たり 500 件の制限をしていましたが、サービスへの影響がないため抽出条件を解除しました。③ Amazon Aurora のデータが増え続け、クエリ性能が劣化していく点は、提供するデータが Amazon Redshift にあるため、Amazon Aurora からデータをパージできます。
Amazon Redshift を利用した顧客へのデータ提供の全体構成図はこのようになっています。
現在の課題として、月１程度の Amazon Redshift のパッチ提供への対応が必要ですが、サーバーレス化により解決ができるかもしれません。定期同期されるデータを利用しているため、最新データの提供ができていません。これはフェデレーテッドクエリの利用を検討しています。
まとめとして、Amazon Redshift Data APIと AWS Step Function は相性が抜群である点、非同期的に大きなデータを容易に扱える点が魅力、クエリ結果が大きくなる場合は Unload が便利です。
Gunosy におけるデータの民主化を促進するデータ基盤
株式会社 Gunosy 楠湧夢 氏
本日お話しする内容は Gunosy の社内データ基盤 Baikal についてです。Baikal はデータレイクというデータ基盤の形式をとっておりますので、まずはそもそもデータレイクとはなんなのか、AWS でどのように構築できるかについてご紹介いたします。
まずデータレイクの技術的な側面についてご説明します。すごくざっくり言ってしまえば、これは Amazon S3 に全てのデータを集約してあるということです。例えば Amazon Redshift のような DWH では、そのデータの倉庫として特別な空間を必要とします。しかし少なくとも AWS 上のデータレイクでは Amazon S3 上にデータを置いておけばそれでデータレイクとしては完結することになります。もちろんただ Amazon S3 にデータをおいても何か魔法がかかってデータレイクとして使えるようになるわけではありませんが、とにかくカジュアルにデータが使えるようになるのだということだけ理解しておいてください。
ひとつめのデータレイクの利点は反抗増加データを扱いやすいということです。つまり json や XML のような柔らかい構造を持ったドキュメントデータです。データレイクは Amazon S3 にデータを置いておくだけでよいという特性からドキュメントデータの解釈を最初に行わずすみます。つまり最初は適当に好きなようにおいておいて、後から活用したくなったデータからスキーマを考えてオンデマンドに読み出すということができます。またあるデーあを利用者の用途に応じて呼び出し解釈することができます。これを難しい言葉でスキーマオンリードと呼びます。DWH はその逆であるスキーマオンライトです、なぜならば DWH にデータを取り込む際には適切なスキーマを先に決定しておいて、それに合うデータを取り込む必要があるためです。これをひとことで捉えているのが「寿司原則」とこの書籍で呼ばれているものです。これは非常に重要なアイデアです。
第二の利点はデータ変換の負荷が最適化されるという点です。寿司原則によるスキーマオンリードという思想によってデータパイプラインを開発する人の負荷が減ります。例えば DWH の場合を考えるとまず DWH にデータを投入するデータ変換を考える必要があるのに対しデータレイクではこれが必要ありません。分析者の要望などに応じて、そこから逆算して必要なデータ変換を実装すればよいことになります。これにより繋ぎ込みを行う負荷がへり色々な部署との連携をしやすくなります。また機械学習の文脈でも変換前のデータの方が好ましいという話もあるようです。
以上の利点を整理して、例えばここで挙げたようなケースのお悩みに関してデータレイクの採用が推奨されるのではないでしょうか。つまりコストをかけず基盤を開始するようなケースです
これが 弊社のデータ基盤の概略図です。少しディテールは違いますすが、今までお話してきたデータレイクが図の中央の紫の枠で囲まれた部分に相当します。左から弊社プロダクトのデータが Amazon S3 に溜まって流れてたまっていきます。右にはデータを利用する社内にユーザーがいて、Redash や Amazon Quiksight を介して中央のデータで行くにアクセスします。これらの分析ツールは裏側で Amazon Athena に動いてもらってその結果を使って様々な分析をしていきます。これがデータ基盤のアーキテクチャになります。
アーキテクチャで現在の技術的な断面を理解すると同時に、その前提となっているデータ基盤をどのようにしていきたいか、何を目指しているのかというのが重要だと思っています。ここでは Gunosy のデータ基盤が目指している 4 つの指標を示しています。1 つずつ見ていきます。
まず 1 つ目は データの一元管理による車輪の再発明の防止です。全てのデータをデータ基盤に集約し全ての部門にそのデータ基盤を使っていただきます。共有の促進により部門間で重複した作業や開発をすることを避けることができます。2 つ目は誤操作を防ぐデータガバナンスです。広くデータを使ってもらいたいとは言いつつも守るべきものを守る必要があります。粒度の細かい権限管理を可能にすることで誰がどのデータにアクセスできるのか、更新できるのかをポリシーとして明確に管理できます。
3 つ目は組織横断なデータ基盤開発の民主化です。基盤チームだけでなく他の開発チームも変更が行えるような仕組みを整備することを目指します。4 つ目は幅広いユーザに向けた分析の民主化です。SQL がかけるユーザだけでなく経営層に至るまでデータが活用できる環境を整備しつつ、SQL がかけるユーザ向けにも専用の環境を整備します。
これら 4 つの目指す姿に近づくための具体的な取り組みを 6 つ紹介します。スライドでは対応関係がわかるようにアイコンを付与しています。
1 つ目は AWS Lake Formation を用いた横断管理です。これはテーブルデータとしての権限管理をもとにしたアクセス管理を意味します。だれがデータにアクセスするかを簡単かつ明確に管理でき、粒度の細かい権限管理を提供できます。ユーザ側も触るとまずいデータを気にすることなく安心して分析ができます。
2 つ目は Amazon Athena での SQL によるデータ変換です。我はデータ変換として Amazon EMR による Spark などは使わず Amazon Athena での SQL を用いたデータ変換を行なっています。これによって開発参入への敷居を避けることができます。基盤管理の負担を減らすこともできます。ただ従量課金の怖いところとして知らず知らずのうちに費用がかかってしまうクエリを発行してしまうことがあります。こちらは Slack での通知機能によって費用感覚を導入しております。
3 つ目は Amazon Athena の View による IaC の管理です。これは View をテーブルのように扱いデータソースとして利用することを指します。選択できるデータソースを Amazon Athena の VIew、つまり事前に定義したクエリの結果に制限しています。これによりユーザがどういったデータに対して分析を行うかを開発者側の想定内に制約することができます。
4 つ目は他チームのデータ開発基盤支援です。我々のチームは 3 人のチームで基盤の面倒を見ており、常にデータ基盤のみにフォーカスできるわけではりません。専門知識化を防ぐため、開発を民主化させることを意識しています。具体的にはドキュメントを整備し、エンジニアが独立してデータ繋ぎ込みや補填をできるようにしたり、ペアプロ等で知見を共有することです。
5 つ目は Amazon QuickSight による開かれた分析基盤です。基本的に定期ミーティングで各チームが確認するような指標は Amazon QuickSight のダッシュボードへ移行するようにしています、これにより、データを少し深ぼるような分析であればダッシュボードの GUI 操作によって完結するようになります。
6 つ目は Redash による詳細な分析基盤です。Amazon QuickSight で SQL のいらない分析基盤を作ったとはいえ、SQL ベースの可視化ツールである Redash は常に利用しています。現在は OSS 版の Redash サーバを社内でホスティングしています。分析はアナリスト主導で行われます。
4 つの柱と 6 つの施策についてお話ししてきました。まとめると、分析環境開発環境双方において利用者の体験を向上させることをおこなってきました。
発表の終わりに、現状どのようなことが起きたのか・これからの基盤はどのようになっていくかについて完結にお話しします。まず、開発の民主化で得られたことです。それは弊社の多くなエンジニアにアクティブなデータ基盤開発者がいるということです。これによって事前の連絡・連携などのコストがかかりません。また、より発展した形として別チームがデータ基盤の一部を切り出して管理するケースもあります。次に分析の民主化として得られたものとしては、Salesforce の連携プロジェクトがあります。これまで一部に閉じていた Salesforce データを Amazon QuickSight の全社共通ダッシュボードに連携して利用することで、セールスのチームに閉じず経営層までとどくようなスケールするダッシュボードを作成することができました。また副次的な効果として、Salesforce 側の機能をアクティベートすることを回避し数百万オーダーでのコスト削減にもつながりました。
最後に、これからのデータ基盤がどうなっていくかについて私見を述べます。まず更なるデータ民主化のためのモダンデータスタックの活用があります。データ変換は SQL による開発が主力になる傾向があるようにみえます、これはデータレイクの流行による ETL から ELT への移行と dbt による協力なテンプレート化の力が大きいと思います。また大量のデータから必要なある程度のデータが処理できればよいという現実的な経験則が共有されてきたこともあると思います。またマイクロサービス時代のデータ基盤としてデータメッシュという言葉がよく取り沙汰されます。これは中央集権的なサービス責任者がパンクしてしまうことを防ぐため、マイクロサービスの開発者側が各自のデータにも責任をもつ設計に流れるトレンドとして理解しています。この設計が必ず正解というものではないでしょうが、しかし比較できるパターンが多くなっていくということはアーキテクトにとってはよいことではないかと思います。
本日はこちらの内容についてお話ししました。皆様のお役に立てましたら幸いです。
ガバナンスを適用しながら組織の枠を超えたデータ活用を実現するAmazon DataZone
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 平井 健治
AWS の平井から、データ活用を進めていくにあたってのスピードと利便性に関する課題と、課題を解決するソリューションとして発表された Amazon DataZone の紹介をしました。
各ビジネスチームは組織の境界を超えてビジネスの成長に役立つデータを素早く発見して分析することを期待しますが、サイロ化されたデータにより欲しいデータが見つからなかったり、データ基盤を整備したもののビジネス部門の利便性が損なわれてしまうという事態は避けなければなりません。
このようなデータ活用に対するニーズに対して、Amazon DataZone が発表されました。
データは、データプロデューサーにより、適切なビジネスコンテキストでデータが公開され、データコンシューマーはパーソナライズされたウェブポータルから必要なデータを見つけてデータにアクセスできます。
一連のデータ共有にあたっては、データスチュワードの承認を入れることもできます。
次に、Amazon DataZone のコアコンポーネントである、ビジネスデータカタログ、プロジェクト、ガバナンスとアクセス制御、データポータル、がどういったものかを解説しました。
ビジネスデータカタログによって、ビジネスコンテキストを追加してデータを整理することができるので、企業全体のデータアセットを見つけることができます。データをアクセスするにあたってはコラボレーションスペースであるプロジェクトを用意しています。ビジネスユースケース単位でユーザーを招待するだけでなく、ツールやデータをプロジェクトとしてグループ化することにより、データアクセスが簡素化できます。プロジェクトの間でのデータの交換は、自動化されたパブリッシュとサブスクライブのワークフローによって、ガバナンスとアクセス制御を実現します。これらのオペレーションは、ユーザーのためにパーソナライズされたデータポータルを通して実施できます。
このあと、セールス部門の製品販売情報をマーケティング部門が活用するシナリオのデモを紹介しました。
最後にまとめとして、データの活用を進めるにあたっての必要とされるアジリティとガバナンスについて、どちらかではなく両方を実現するのが Amazon DataZone の特徴であることを説明しました。ぜひお試しください。
AWS Glue for Ray 入門
アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 奥野 友哉
AWS の奥野より、イベント時にはプレビュー、2023 年 6 月に一般公開された AWS Glue for Ray のユースケースや使い方についてデモを交えてご紹介しました。AWS Glue for Ray はデータエンジニアや開発者の Python ジョブをスケールさせるために利用できる新たな AWS Glue の実行エンジンです。従来では Python を利用して大規模なデータ加工を実施しようと考えた場合に、Python shell を利用するか、Apache Spark を利用するのかの選択肢しかありませんでしたが、これらにはいくつか課題があったことに触れています。 Python shell でのジョブ実行はシングルノードしかサポートされていなく、処理の高速化のためには自分たちでジョブ分割の仕組みを作成することが必要で、これにより運用の複雑性があがりエラーの原因となる要素が増えるという課題がありました。Apache Spark の Python API を利用すると、分散処理の仕組みはすでに組み込まれているのですが、Python でデータ分析をする際によく用いられる Pandas とは構文が異なっていて、新たな学習コストがかかっていました。
そこで、Ray というオープンソースのライブラリを AWS Glue のサーバレス環境で実行でき、純粋な Python のコードや、Pandas の構文で記述されたコードを、数百ノードへ簡単にスケールできる AWS Glue for Ray が発表しています。AWS Glue for Ray を利用すれば、Spark の Python API の学習コストをかけることなく、既存のコードをほぼ改変なしに Pandas API に似た構文で分散処理が実行できるようになっています。
デモでは下記の 2 つのユースケースについて触れています。
- Ray で Pure な Python コードを並列化する方法
- Pandas での ETL 処理を Ray で並列化する方法
1 つ目のデモでは、よく知られている並列化可能な計算である円周率の計算コードを並列化する方法をご紹介し、関数に対してデコレータを指定することで、こちらを並列化することができることを示しました。
2 つ目のデモでは、Amazon S3 上にあるファイルからデータを取得し、簡単な加工した上で、再度 Amazon S3 へと結果を出力する方法をご紹介しました。この際、Amazon S3 とのデータのやり取りに関しては AWS Glue for Ray で簡単に利用できる AWS SDK for Pandas を利用しています。これにより、AWS サービスとのデータのやりとりが Pandas 構文で簡単に実施できることをご紹介しました。また、Pandas の構文で書かれた ETL 処理の並列化に関しては、Ray の上で動く Modin (旧PandasOnRay) を利用して、構文の変更なく分散処理を実施する様子をご紹介しました。Pandas ユーザであるデータサイエンティストや開発者の方々にとってインフラの心配なしに、大きいデータを加工できる使いやすいサービスのため、ぜひお試しください。
まとめ
これまでの事例祭りに続き、Analytics 領域の先進的な事例が盛り沢山のセミナーとなりました。日本のお客様向けに AWS アナリティクスサービスの最新動向を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております。お申込みリンク。
井形 健太郎・平井 健治