Amazon Web Services ブログ
【開催報告】AWSで実践！Analytics Modernization ～事例祭り編～
2022 年 3 月 24 日に「 AWS で実践！Analytics Modernization ～事例祭り編～」を開催しました。今回の事例祭りでは AWS のアナリティクスサービスをご活用いただいている日産自動車株式会社、レバレジーズ株式会社、株式会社シャノン、株式会社カヤック、ビットバンク株式会社、ヤフー株式会社、株式会社 NTT ドコモにご登壇いただきました。本ブログでは各発表内容を紹介します。
自動車開発をサポートする積極的な QuickSight 活用事例紹介
日産自動車株式会社 R&Dデータサイエンス部門 課長 俵道 大輔 氏
日産自動車ではあらゆるデータを一元管理しており、AWS サービスで環境を構築しています。データの活用においては Amazon QuickSight を使用しています。ダッシュボード単位でデータマートを設けることで集計の効率化を図っています。Amazon QuickSight を選定した理由として、直感的な操作性、大量データの処理が得意、別AWSサービスとの親和性、安価な従量課金とサーバーレスでスモールスタートできる、などがありました。
次にユースケースを紹介します。1 つ目は販売データの分析で、社内および社外のデータを結合して Amazon QuickSight に取り込んでいます。データの前処理後にインメモリの SPICE に取り込んで分析しています。2 つ目は AWS DeepRacer トーナメントでの利用です。機械学習モデルの実装における CPU・GPU リソースを管理するのに使いました。3 つ目は車両データの分析です。車両から得られるデータはデータパイプラインを経由して Amazon QuickSight で分析できるようになっており、自動車開発のサイクルをまわすのに役立っています。大量の車両からミリセック単位の高頻度でデータを収集し分析しているため、ローカルPC上での処理には限界があり、クラウドの処理パワーが必要でした。また、Amazon QuickSight の様々な可視化機能を活用することでダッシュボードの使い勝手を向上しています。
日本一の IT フリーランス DB を世間に大公開してみた
レバレジーズ株式会社 マーケティング部 データ戦略室 データアナリスト 井上 智貴 氏
レバレジーズは IT 専門の就職支援サービスであるレバテックを運営しています。なかでもレバテックの IT フリーランス部門は業界ナンバーワンの登録者数と評価を得ており、本セッションでは蓄積された IT フリーランスに関するデータを Amazon QuickSight 通じて大公開したお話について紹介します。企業には技術者のスキルや希望条件を、技術者には IT 職の傾向を公開しています。
まずはデータ公開に至った背景を説明します。IT 技術者の不足数は増加傾向にあるため、需給ギャップを埋めるのにフリーランスの活躍が欠かせません。一方、企業側と技術者側の両方でフリーランスに対する不安要素は絶えません。そこでレバテックでは IT フリーランスのデータを公開することでリアルな情報を発信し、IT フリーランスの活用推進を目指しています。
データを公開するにあたり BI ツールの組み込みを検討しました。BI ツールを使えば簡単にデータを可視化できるため開発の手間を省くことができます。データ接続や可視化の細かい調整など、内製だと沢山の工数をかけて作りこむ必要があります。最初は別サービスを検討しましたが、サーバー構築および運用保守、ユーザーアカウントの管理、利用時のログイン手続き、など課題がありました。比較検討の結果、Amazon QuickSight を採用することにしました。まず Amazon QuickSight は実装の容易さで圧倒しました。サーバーレスのためサーバー構築や運用保守は一切いりません。ユーザー認証が不要な匿名アクセスの組み込みを使うことで開発も簡単で、レバテック利用者もログイン不要となり理想の UX を提供できます。また、別サービスの場合は利用有無に関係なくユーザーアカウント単位で課金が発生するのに対し、Amazon QuickSight の場合はセッション（アクセス頻度）に応じた従量課金という点も魅力的でした。総じて Amazon QuickSight のほうが今回のような大規模用途に適していると判断しました。
BigQuery とのデータ接続に関しては工夫が必要でしたが、やってみると案外簡単で、1週間で接続は完了しました（詳しくはレバレジーズのデータ戦略ブログを参考）。また、実際に Amazon QuickSight を使ってみて感じたのが、可視化も充実しているという点です。別サービスと同等の表現を実現できるかが懸念でしたが、細かい調整もできるようになっており、かつ直感的な操作性でとても簡単に良い感じのダッシュボードを作れます。
次にダッシュボードの活用についてです。技術者むけダッシュボードでは募集中案件数、新規案件数、倍率、単価の分布、作業日数、リモート可否、などが見れるようになっており、例えばプログラミング言語のようなスキルごとの案件傾向を見ていくことでニーズが多いスキルを把握できます。レバテック利用者むけの価値向上に加えて、レバレジーズの営業やマーケティング施策にも活用しています。ダッシュボードのフィルタ操作内容をログとして蓄積することで、利用者の興味に直結するような形で施策を打てるようになります。
まとめますと、Amazon QuickSight は数千人規模の利用に適した BI ツールで、データをレバテック利用者に公開することでフリーランスの活用促進という大きな価値を生み出すことができました。詳しくはレバレジーズのデータ戦略ブログでも紹介しています。
Amazon QuickSight を活用した、B2B マーケティングデータ分析ツールの実現
株式会社シャノン 技術統括部 エンジニア 駒田 直樹 氏
シャノンは SaaS 型マーケティングオートメーションツールの SHANON MARKETING PLATFORM（ SMP ）を運営しています。マーケティング活動における見込み客（リード）の獲得と育成を自動化するツールであり、「 Marketing is Science 」というコンセプトを掲げるシャノンは再現性があるマーケティングの実現を目指しています。そのためには施策の結果やリードの行動履歴に関する分析が重要となり、データ可視化のニーズも高いです。
しかし SMP でのデータ可視化には課題がありました。運営側のシャノンとしては定型ダッシュボード（決まったデータと可視化）のほうが提供しやすいですが、SMP 利用者はそれぞれ異なる分析ニーズをもっています。そのため定型ダッシュボードを準備しつつ利用者がカスタマイズできる仕組みを構築する必要がありました。そこで豊富な API を持っていてコンソール画面も組み込める Amazon QuickSight に注目しました。
次に具体的な実現方法を説明します。まずはデータソースの作成についてです。様々なマーケティングデータを、最終的にCSV形式で Amazon S3 に保存する仕組みを作りました。SMP はマイクロサービス化しているため、各サービスのデータを集約する ETL サービスも作成しました。次に Amazon QuickSight の Web 画面でデータ接続とダッシュボード作成を行い、SMP 上の画面操作から表示したいダッシュボードを選択のうえ API を通じて表示しています。頻繁に使われる数十パターンのグラフをテンプレートとして準備しておき、SMP 画面から自由に選択できるようになっています。API を上手く活用することであたかも自由にグラフ化できるような体験を実現しました。
SaaS 製品の場合は複数の顧客企業が同一の Amazon QuickSight 環境を共有することになります。このようなマルチテナント対応で最も重要なのが各顧客データの分離であり、高いセキュリティレベルで管理する必要があります。まずユーザーに関してはグループにまとめたうえで名前空間に分離しています。名前空間は企業単位で分け、各企業のユーザーをグループに分けて管理しています。各リソースの権限設定はグループに紐づけています。
次は開発サイクルについてです。通常の SMP 製品開発のフローに合わせて Amazon QuickSight も開発・テスト・本番環境（それぞれ別 AWS アカウント）を用意しました。そこで全ての Amazon QuickSight 環境に対して同じ設定を適用できる必要があります。まずは API での共通設定から共通のリソースを作れるようにしました。分析及びダッシュボードの作成とクロスアカウントでのコピーに関してはテンプレート API を利用しました。
SMP 利用者がシームレスに Amazon QuickSight を使えるよう Single Sign-On を構築しました。SMP 側のログイン情報をもとに Amazon QuickSight の認証を行っています。結果、各お客様に関連したリソースのみを扱えるようにしています。SMP サービスの一環で、SMP 利用者が Amazon QuickSight に登録された Amazon S3 のデータソースから自由にデータセットを作れるようにしています。そうすることで各マーケターが自由にデータの準備と分析を行うことができます。Amazon QuickSight の柔軟な権限設定を使ってデータソースは参照のみとしています。さらにはプリセットの分析テンプレートを自由に編集できるようにもしています。データセットの作成やゼロからの分析作成は難易度が高いこともあるため、より楽に可視化のみ編集できるようにしました。
今後は段階的に顧客向けリリースを進め、最終的には数千テナントでの利用を予定しています。SaaS への BI 組み込みにおいて Amazon QuickSight が特に優れている点は3つありました。まずはマネージドサービスのため運用負荷が低いことです。前に使っていたサービスはオンプレミス上で運用が大変でした。次に従量課金かつ初期構築費がかからないため SaaS の一部として提供しやすいです。最後に AWS サポートが充実しているため API ・ SDK を使った開発作業も滞ることがありませんでした。Amazon QuickSight の導入により運営側と SMP 利用者側の両ニーズを高いセキュリティレベルで満たすことができました。
Amazon Redshift を 1 年運用して感じた教訓とその対策方針
株式会社カヤック エンジニア 池田 将士 氏
面白法人カヤックは、鎌倉の地にて、主に Web 技術を用いて人の印象に深く残るような面白コンテンツを作る会社です。今回は、カヤック社が手掛けるいくつかの事業の中でも、大会プラットフォームサービス Tonamel に関するお話をいただきました。Tonamel で Amazon Redshift (Redshift) を導入したのは、2021 年 2 月のことだそうです。
Tonamel の分析バックエンドでは、当初 Amazon Aurora (Aurora) MySQL が使われていたそうです。そこでは、Window 関数や WITH 句が使用できず、複雑化する分析要件に対応できなくなっていました。加えて、マイクロサービスサイドの分析に Amazon DynamoDB (DynamoDB) も導入され、それぞれでデータサイロができてしまったこともペインになっておりました。
そこで、本格的にデータを集約するための基盤を選定することになりました。
候補としては上図のとおり 3 つの案があったようですが、カヤック社では Redshift を採用されました。採用理由には、以下の 3 つがあったようです。
1 つ目は、SUPER 型の対応により、DynamoDB からスムーズにデータを取り込む仕組みが構築できたことです。DynamoDB Streams により、Amazon Kinesis Data Streams で取り込んだ DynamoDB 上の変更情報を Amazon Kinesis Data Firehose 経由で Redshift に渡します。このとき、DynamoDB に含まれるメインの情報は基本的に JSON 形式で表される、半構造データとなります。このとき、Redshift に SUPER 型で受けるようにすれば、スムーズに連携可能となります。
2 つ目は、Federated Query により、Redshift から Aurora MySQL へのダイレクトクエリがサポートされていた点です。Aurora MySQL からデータを取り込む際の ETL パイプラインの簡略化が期待できました。
3 つ目は、「ぼくらの甲子園！ポケット」「Lobi」でも Redshift を既に導入していおり社内に知見があったこと、またアプリケーションが AWS にあるため、他の AWS サービスとの親和性の高さも、選定理由となりました。
現在は、運用を開始して約 1 年経ち、発生した事象を踏まえ、様々な教訓が得られたようです。今回のセッションでは、これらの教訓を、3 つのエピソードに対する 5 つの教訓にまとめあげ、シェアいただけました。
1 つ目のエピソードは、開発環境の準備方法です。当初、dc2.large 2 ノードでスモールし、開発環境が必要になったタイミングでは、コスト上の制約から、本番環境のクラスタに開発環境用のデータベースを切り出すことで運用されていました。ただ、開発環境に十分なデータを投入できず、本番環境相当のデータで試すことができない、という問題が生じました。この点に関しては、RA3 のノードタイプであれば、クロスデータベースクエリを使って解決できたため、「ra3.xlplus を選択しておくべきだった」という教訓 (1) が得られました。他にも、RA3 でのみ利用可能な、データ共有や AQUA といった新機能についても言及いただきました。
2 つ目は、Redshift の最新機能を試すため、プレビューに参加したい、というエピソードです。たとえば、選定理由に Aurora MySQL への Federated Query を挙げていただきましたが、こちらは採用したタイミングの 2021 年 2 月時点ではプレビューでした。ですので、お客様で本番環境のメンテナンストラックをプレビューにし、早速試用されたそうです。ただし、これは弊社 AWS としては本番環境でプレビューするのは推奨していないアンチパターンであり、結果、お客様のメンテナンストラックを最新に戻せなくなった、プレビューが終了してクラスタの停止と削除が必要になった、という事象が発生してしました。結局本番環境の作り直しが必要になってしまったのですが、このときスナップショットを経由しての復元ができず、S3 を経由してのデータの移行が必要になってしまったようです。ここで得られた重要な教訓 (2) として、「本番環境でプレビューにするべきではない」点を挙げていただきました。一方、本番環境でスムーズにプレビューする方法として、データ共有を活用する方法を挙げていただきました。データ共有に関しては RA3 のみで提供されている機能のため、教訓 (1) も同様に重要なポイントだと再度挙げていただきました。
3 つ目のエピソードとして、クラスタのお引越しについて、挙げていただきました。このクラスタのお引越しが、実質作り直しという形になったのですが、その際、以下 3 点の見直すべきポイントが見つかったようです。
カヤック社では、「誰が」「いつ」「どのテーブルに」アクセスしたかを、BI のクエリログ、Redshift のシステムテーブル STL_EXPLAIN および STL_QUERY を集計し、記録されておりました。結果、テーブルの使用頻度が以下のとおり偏りがある状況となり、使用頻度が低いテーブルについては引越しの対象から外すことで、データのスリム化に成功しました。このように、「テーブルの使用状況の把握が大事である」教訓 (3) が得られたとのことです。
また、Amazon Managed Workflows for Apache Airflow (MWAA) にて、DynamoDB の最新状態を復元するためだけに、5 分に 1 回起動させているワークフローがあったそうです。ただ、最新状態を復元するだけなら、何もワークフローを起動させなくとも最新行を特定するための、Auto Refresh を有効にした Materialized View と、参照用のビューを定義すれば簡単に実現できることが後ほどわかりました。ここから「Materialized View を積極的に使おう」という教訓 (4) が得られました。
Federated Query で Aurora MySQL にダイレクトにアクセスした際、Aurora MySQL 内の無加工データを Amazon Redshift にコピーせずとも加工データのみ移せてしまうため、Aurora MySQL から無加工データが消失している、という事象もあったようです。ここで「無加工データが S3 にあるのは大事である」という教訓 (5) が得られました。この無加工データを残すために、Federated Query を使うとしても CTAS で無加工データのコピーのテーブルを定義し、そのデータを S3 に書き出しておく方式を取るよう、修正されたそうです。
一方で、これら教訓を踏まえても、引き続き簡単に本番環境と同じものを復元できる仕組みを構築しておくのは重要だというのがカヤック社の見解です。そこでキーになるのが、Terraform や AWS CloudFormation による Infrastructure as Code、およびソフトウェア・エンジニアリングのベストプラクティスを分析に適用した、Analytics Engineering の考え方になると話していただきました。
ここで結論として、「良いデータウェアハウスの運用とは、再構築が容易であることだ」と締めくくっていただいております。再構築により、やり直しが容易となる、とのことでした。
なぜビットバンクは Amazon Redshift を選んだのか？
ビットバンク株式会社 システム部門 プラットフォーム部 インフラチーム 谷津 香 氏
ビットバンク株式会社は、日本では預り資産ベースで Top 3 に入る、暗号資産取引所を運営されている会社です。 ビットコインの技術で、世界中にあらゆる価値を流通させることをミッションとされております。
まずは、Redshift を導入する以前の、過去のデータ分析基盤についてお話しいただきました。データは Aurora, Amazon S3 (S3) に格納されており、そのデータを AWS Glue にて加工し S3 に配置、Amazon Athena (Athena) から AWS Fargate 上の BI ツール Redash からアクセスされる構成でした。
次に、ユースケースをご紹介いただきました。事業計画の推進上の意思決定、Web マーケティング施策およびその効果検証、市場動向の予測と分析、会計利用の際の入力となる帳票データ、取引モニタリング等、とのことでした。
この基盤で発生していた課題をご紹介いただきました。
最初にあげていただいた課題は仮想通貨事業を営まれているビットバンク社ならではのもので、個人情報を含む、秘匿性の高いデータに対するアクセスコントロール、セキュリティ、統制といった課題や、ユーザ部門からのデータ抽出依頼によりかかる運用部門の負荷、といったところだったそうです。また、他にも性能面の課題であったり、実質 S3 を必ず経由する必要があるといった点も、ペインになっていました。
基盤の見直しにあたって、改めて基盤の要件を整理されました。データソースは Aurora, S3 であり、Aurora からは必要なデータを取り出して連携し、BI ツール Redash での分析、といったこれまでの要件に加えて、より高度な機能と統制、具体的には、高いパフォーマンス、多様なデータソースのサポート、柔軟なデータアクセス、個人情報取扱いのためのアクセスコントロール、IT-GC/IT-AC といった業界ならではのセキュリティ、統制要件対応が必要となりました。
ビットバンク社では、これらの要件に対応するためには DWH が必要になってくるというところで、Redshift の他に、Snowflake、BigQuery も候補に加え検討されました。
DWH 導入後の利用イメージとしては、社内のユーザを BI ツールからのみの参照を想定する一般ユーザと自身で SQL を書く高度利用者、メンテナンスやユーザ管理を行う管理者に分類し、それぞれに応じて適切なアクセス権限を付与するというものでした。
その上で、選定のための比較項目を整備されたそうです。具体的には、以下の 12 個の項目を想定されたそうで、このうち「データソース」「アプリケーションからの操作」「アクセスコントロール」「セキュリティ」「レスポンス」「スケーラビリティ」「コスト」についてお話しいただきました。
まずは「データソース」の観点からです。データソースとしては、DynamoDB、Aurora、S3 の3 つのデータソースからのバルクロード、継続的ロードを想定し、そのロードの容易さの観点から比較検討を行われました。これらの観点では、Redshift および Snowflake であれば良さそう、という結果になりました。加えて、データの投入に際しノーコードでの連携が可能かの観点でも比較しましたが、この観点ではいずれの DWH も ETL のコーディングは必要、という結論になりました。
次に、「アプリケーションからの操作」という観点では、API と認証方法の観点で評価を行われました。この観点では、認証方法の観点で差があり、Redshift もしくは BigQuery の評価が高い、という結論になりました。
他にも、AWS Lambda (Lambda), AWS Glue といった ETL を実行するためのサービスからのテーブル、レコードの操作の観点から比較を行いましたが、この観点では大きく差がつかないという結果になったそうです。
次に、「アクセスコントロール」の観点です。この観点については、イベント時点 (2022 年 3 月) において Snowflake だけレコード単位でのマスキングが可能であり良さそう、という評価になりました。
次に、「セキュリティ」の観点です。評価の指標としては、取得済みの第三者認証、IP 制限の可否、Amazon Workspaces からの持ち出し制限の可否、という観点で比較しました。これらの ３ つの観点では特に大きな差がつかなかったものの、Amazon Workspaces を前提とした際に AWS と GCP 間のデータのやり取りでインターネットを出ないようにするために工夫が必要である点で、BigQuery の扱いが難しく感じられたそうです。
次に、「レスポンス」の観点です。現在、Athena で時間がかかっている 3 つのクエリについて、3 つの DWH サービスで性能を測定したところ、いずれも得意不得意はあるものの、総じて現行の Athena より改善が見込めるという結果になりました。
最後に、「コスト」の観点です。ここではサポートまで含めた TCO 観点での比較を行っており、マルチクラウド化に伴うサポート費用の増大が大きく影響する結果となりました。また、残る Snowflake との比較でいえば、リザーブドインスタンスによる割引は魅力的に映ったとおっしゃっていただけました。
ここまでの比較結果を、以下のように Pros/Cons でまとめていただけました。
また、改めて Redshift 採用の決め手となった 4 点についても、以下のようにご共有いただいております。
ここで Redshift 採用後の、現在のアーキテクチャについて解説いただきました。
まずは、初回データロードの仕組みについてです。こちらについては、Aurora に初回データ専用のカスタムエンドポイントを作成し、そこに対して AWS Database Migration Service (DMS) 経由でデータを持ってくるという構成です。
継続的に Aurora からデータを持ってくる箇所については、Amazon EventBridge (EventBridge) をトリガーとして Redshift のクエリをスケジューリングし、Federated Query にてデータを持ってくるという構成を取られました。エラー発生時は、EventBridge、Lambda を経由して Slack にメッセージを投入する仕組みを構築されたそうです。この構成の理由としては、今後 Aurora のデータをなくす計画もある中で、データの消失を防ぎたかったこと、運用を最小限にするために、余分なサービスを入れない形にしたこと、DB の負荷を独立させる方式を取られたこと、を挙げられていました。
ここで、今回 3 つの DWH サービスを比較して、機能面では大差ないと実感されたそうです。その中で感じられたこととしては、重要なのはサービスの有名度ではなく要件や既存アーキテクチャとの親和性が重要であること、また、将来的なヘビーユースの際にチューニングの余地は必要であること、各サービスともに進化を続けいているため、時間とともにベストプラクティスが変わりうること、を挙げていただきました。
最後に、Amazon SageMaker と Redshift との統合、BI ツールのさらなる活用、通知基盤と Redshift との統合等、データ活用の観点でさらにこのデータ分析基盤を進化させたいとのことで、締めくくっていただきました。
AWS Lake Formation を利用した企業ネットワーク間のデータインジェスト
ヤフー株式会社 COO 事業推進室 事業推進統括部 データディレクター 石川 貴大 氏
ZHD グループは、ヤフージャパンが提供する検索やニュース、ショッピングやオークション、コミュニケーションツールである LINE 、ロイヤリティの高い宿泊や予約事業を展開している一休など、多岐にわたってサービスを提供しています。それらサービスの連携を深めることでお客様により良いサービスを提供することを目指しており、利用許諾をいただいたお客様データに基づいた会員プログラムの充実やお客様のアクションに紐づいた情報提供の最適化を推進しています。その中でグループ全体での送客効果やキャンペーン効果を正しく計測するために取り組んだ、経由流通額の可視化と株式会社一休様とのデータ連携について共有させていただきます。
送客実績は、セッションデータを元に可視化します。セッションデータは、各サービスのドメイン別に作成し、お客様ごとにアクセスログを並び替えた後、あるアクセスから次のアクセスまでの時間がアブセンスタイム以上になった場合を区切りとしてまとめます。計測の都合上、最大セッション時間で一区切りにする処理を行ったり、デバイスを跨ぐアクセスや、セッション内におけるログイン前後のアクセス等も、セッションとしてつながるように計測しています。
そのセッションデータを元に、購買金額を 14 日間に存在する全ての送客元に均等に割り付ける 14 日イーブンモデルで経由流通額を可視化しています。このモデルを採用するにあたっては、他モデルと比較検証を実施し、送客実績の購買に対する直接的または間接的な貢献を、近似的にではありますが、確からしく計測できていることを確認しました。また、14 日イーブンモデルはシンプルなロジックのため、コミュニケーションを簡素にすることが可能となっています。
AWS Lake Formation を利用することで、少工数かつデータガバナンスを担保したデータパイプラインを実現することができました。私たちは、ヤフーネットワーク内に構築したコンテナベースの Airflow 環境を中心に経由流通額の可視化におけるデータ処理を行っており、この処理に必要なお客様の行動データの連携を株式会社一休様と行っています。
経由流通額の可視化に必要な一次データは、一休様の AWS アカウント領域の Amazon S3 に配置されています。このデータに対し、一休様側でAWS Lake Formationを利用してヤフーの AWS アカウントに対して参照権限を付与いただいています。この連携データをヤフーの AWS アカウントから Amazon Athenaで参照し、セッションデータに加工・ヤフーのHadoop Clusterに配置しています。アーキテクチャのポイントとしては 2 点あり、1 点目はデータガバナンスのコントロールポイントは株式会社一休様側にある点です。AWS Lake Formation を活用することで、アカウントに対する操作権限に加え、データカラム粒度での詳細なアクセスコントロールを実現しています。2 点目は連携データの一次データをヤフー側に保存していないことです。Amazon Athena で参照する際に必要な加工処理を実施し、二次データとして、ヤフーの Hadoop Cluster に配置しています。
AWS Lake Formation を利用したデータ連携方式と、従来手法であるSFTP方式を比較しました。SFTP 方式は既存の仕組みであったため学習コストが低いことがメリットである一方、連携元のETL開発工数が大きいことや連携先のストレージに一次データのコピーが取られること・連携データに対して詳細なアクセスコントロール設定ができないことがデメリットとしてあげられます。対して AWS Lake Formation 方式では、連携元が既にAWSを利用していたため、ETL の開発工数が小さいこと (約 5 人日で開発を完了) ・オープンソースの Airflow に AWS と接続するためのプラグインが存在していること・連携先にデータのコピーが取られないこと・連携データに対して詳細なアクセスコントロール設定ができることがメリットでした。デメリットとしては、初期の学習コストが高いことがあげられますが、私たちは設定方法をテンプレート化することで対応しています。
昨今、お客様のデータのプライバシー保護の観点に注目が集まっており、改正個人情報保護法も施行されました。今回 AWS Lake Formation を活用したアーキテクチャは、お客様の個人情報保護を実現する上でも大きなメリットとなっています。今後、ZHD のサービス統合の推進に伴い、ご紹介させていただいたアーキテクチャを横展開する形で、グループ企業間のデータ連携を拡大していく予定です。
大規模商用システムに特化型マネージドサービス AWS Glue を使ってみた！
株式会社 NTT ドコモ サービスデザイン部 名知 数馬 氏
NTT ドコモ サービスデザイン部では、通信事業以外のバラエティーに富んだ各種事業のシステムの開発・運用をしており、準内製スクラム開発で約 40 システムの開発を実施しています。今回お話する端末ログ収集基盤はドコモのスマートフォンから送信されてくるログを受信する基盤で、受信したログは、ドコモの各サービスの改善のために分析・利用されます。端末ログ収集基盤は 2020 年 9 月にオンプレミスから AWS へ移行しました。その際、大規模なレコードや JSON 形式のログを1時間ごとにレコードごとに分割・CSV 形式に変換する「ログ集計処理」の実現方法として、マネージドサービスである AWS Glue の導入にトライしました。
AWS 移行時の AWS Glue の導入は、期待した速度が出ないという課題がありました。AWS サポート提示された改善案であるDPU 追加はコストも比例して増加するため採用せず、TGG (とりあえずググれ！)を合言葉に、ネットの情報から試行錯誤の末、コストの増加無く速度の大幅改善を実現しました。解決に向けた自チームでの試行錯誤をやめてはいけないと強く感じています。
AWS へ移行したメリットとして、大きく 3 点あります。1 点目はマネージドサービスの活用により開発・運用におけるコスト・人的リソースが削減できた点、2点目はオブザーバビリティの向上・人的稼働の低減ができた点です。エラー発生時に Slack 通知を実施し、問題発生時に該当のボタン一つで Amazon CloudWatch Logs に飛べるようにすることで簡単に調査を開始できるようになりました。また、システムリソースの拡張が自在にできることも稼働減に繋がっています。2 点目は、処理時間が短縮したことです。オンプレ時代には 2 時間かかっていた処理が 30 分程度になりました。
続いて、AWSへの移行後に実施した AWS Glue 2.0 の導入についてです。基盤の AWS 移行後、新たに、起動時間がばらつく・最大 14 分程度かかってしまうという課題にぶつかりました。対策として、起動時間の短縮が謳われている AWS Glue 2.0 の導入を実施しました。導入当初は期待した性能が出ませんでしたが、AWS サポートの助言を受けながら解決し、最終的にはコスト 12 % 削減・起動時間を最大 14 分から 1 分程度まで短縮するという素晴らしい効果を得ることができました。この経験から、サービスの最新バージョンは迅速に検証の上、結果次第では積極的に導入すべきだと考えています。
その後、2021 年 8 月に登場した AWS Glue 3.0 の導入も実施することで、大幅な処理速度向上・伴う DPU 数の見直しにより、AWS Glue 1.0 比では 47%、AWS Glue 2.0 比では 37%のコスト削減を達成することができました。
まとめ
アナリティクスの各トピックに関する事例が盛り沢山なセミナーでした。日本のお客様向けに AWS アナリティクスサービスの最新動向を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております。お申込みリンク。
アナリティクス事業本部 事業開発 甲谷 優・藤沢 夏美・伊東 大騎