re:Invent 2024: BBVAのData MeshとLake Houseによる大規模データプラットフォーム構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - BBVA: Building a multi-region, multi-country data platform at scale (FSI310)
この動画では、BBVAがAWSと協力して構築したグローバルデータプラットフォーム「ADA」について解説しています。4ペタバイト以上のデータを管理し、毎日50,000以上のプロセスを実行する大規模なプラットフォームを、Data MeshアーキテクチャとData Lake Houseアーキテクチャを組み合わせて実現しました。AWS EMR、Amazon S3、AWS Lake Formationなどのサービスを活用し、250以上のSandboxを通じてエンドユーザーにセルフサービス機能を提供しています。また、FinDataOpsという部門を設立してコスト管理を行い、予防的・検知的ガードレールを実装することで、6,000人以上のData Scientistや4万人以上のデータ消費者による安全な利用を実現しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
BBVAのグローバルデータプラットフォーム構築：背景と課題
re:Invent 2024へようこそ。このセッションはFSI 310です。テーマは「BBVA：マルチリージョン、マルチカントリーのデータプラットフォームを大規模に構築する」についてです。私はIgnacio Fernándezです。皆さんにはNachoとして知られています。Amazon Web Servicesのグローバル金融サービス業界担当のPrincipal Solutions Architectとして働いています。そして、私の隣にはFedericoがいます。こんにちは、私はFederico Estebanです。BBVAのGlobal Head Data Architectureを務めており、本日は私たちのAWSにおける新しいデータプラットフォーム構築の journey をご紹介できることを大変嬉しく思います。
BBVAのグローバルデータプラットフォームについて、少し背景をご説明させていただきます。2023年6月、BBVAはデータとAIを活用した組織への変革の一環として、AWSとの戦略的パートナーシップを発表しました。BBVAは、AWSの幅広い分析およびAIサービスを活用して、グローバルに展開される新しいデータプラットフォームを構築し、BBVAの業務と顧客データの安全なリポジトリを実現することになりました。このプラットフォームは、社内のビジネス関係者に自動化されたビジネスおよびマーケティングインサイトを提供し、業務効率を向上させ、新規顧客を獲得することを目指しています。このグローバルデータプラットフォームは予定通りの時期と予算で提供され、現在稼働中であることをお伝えできます。ここでFederico Estebanが代表するBBVAに、心からお祝いを申し上げたいと思います。
私たちは、航空業界と金融業界の両方が規制された環境であることから、両者の類推を行いたいと思います。現在稼働中のこのグローバルデータプラットフォームは、飛行中の航空機に例えることができます。ここでの課題は、稼働中のグローバルデータプラットフォームのエンジンを交換することでした。これは、飛行中の航空機のエンジンを交換するようなものです。より効率的な航路で、より速く、よりコスト効率よく移動する必要があり、より多くのユースケースでより多くのデータという目的地をカバーする必要があります。また、エンドユーザーにより効果的なサービスを提供し、数百、数千人のデータ消費者、Data Scientist、ビジネスアナリストである乗客の働き方を変える必要があります。そして最後に、私たちの航空機クルーはより効率的である必要があるため、それらのチームに新しい働き方を提供する必要があります。
かつて組織がモノリシックからマイクロサービスへの移行によってメリットを見出したように、現在、データに関して組織はその責任をエッジに分散させています。単一のIT組織がデータのライフサイクル全体、つまりデータの取り込み、データ品質管理、さらにはインサイトの創出まで責任を持つのではなく、このモデルは組織とエッジに責任を押し出し、自律性、オーナーシップ、スピードを向上させています。ここにはいくつかの役割があります。まず、Producerです。Producerになることは簡単ではありません。データのカタログ化、データの機能的・技術的なメタデータ付与に責任を持ちます。特に、Consumerによるデータの発見をより迅速にしたいからです。また、ITチームはIT Enablerとなるべきです。私たちはオンボーディングを簡素化し、よりセキュアな環境を提供し、トレーニングやコミュニティ構築も行います。そして右側には、データを消費したい人々、データをより速く発見したいConsumerがいます。
これらのConsumerは、ビジネスからの要求に応じて、自身のビジネスの優先事項を実行したいと考えています。ここで重要なのは、このモダンなデータコミュニティにおける革新がConsumer側で起きているということです。なぜなら、ConsumerもまたProducerになりたいと考えているからです。これについては後ほど見ていきます。BBVAにおける重要な概念は、Sandboxという概念です。Sandboxとは、モダンデータプラットフォームを活用したい共通の優先事項や取り組みを持つビジネスアナリストやData Scientistなどのエンドユーザーのグループです。彼らはビジネス成果に向けた価値実現までの時間を短縮し、加速させたいと考えています。このSandboxの概念とConsumerがProducerになっていく様子については、後ほど詳しく見ていきます。
ADAプラットフォームの概要と移行プロジェクトの教訓
それでは、BBVAのユースケースについてFedericoさんからご紹介させていただき、その後でアーキテクチャなどのトピックについてお話しします。BBVAはグローバルな金融機関です。25カ国以上に拠点を持ち、7,000万人以上の顧客と12万人以上の従業員を抱えています。これらの従業員は、日々お客様との業務のためにデータを必要としており、そのためにグローバルなスケールのデータプラットフォームが不可欠なのです。データプラットフォームに関する私たちの歩みは、多くの企業と同様でした。最初はサイロ化されたデータベースから始まりましたが、すぐにデータの不整合や重複の問題に直面しました。その後、Enterprise Data Warehouseにすべてのデータを統合しました。この技術は素晴らしく、長年にわたって有効に機能しましたが、データが膨大になりすぎて維持が困難になり、コストも高騰してしまいました。
そのタイミングで、多くの企業と同様に私たちもBig Data技術の実験を開始しました。DATIOと呼ばれる最初のBig Dataプラットフォームを構築しましたが、2つの問題に直面しました。1つ目は、これらの技術をスケールで運用・保守することが非常に複雑だったことです。2つ目は、オンプレミスで運用していたため、増加し続けるデータ量とパフォーマンスの要求に近い将来対応できなくなることが分かったことです。そこで私たちはAWSへの移行を決断しました。制限なくスケールアップでき、AWSのマネージドサービスを活用してアーキテクチャをシンプルにしたかったのです。
私たちのプラットフォームはADAと呼ばれています。ADAはグローバルプラットフォームです。統一されたコンソールを持ち、6,000人以上のData ScientistやData Analystなどの上級ユーザー、そして4万人以上のデータ消費者がいます。コンソールは統一されていますが、プラットフォームは2つの場所にデプロイされています。1つはヨーロッパの国々をカバーするための新しいスペインリージョン、もう1つは現在North Virginiaにあるアメリカです。近々利用可能になる新しいメキシコリージョンへの移行も計画しています。2つの場所にデプロイしているのは、レイテンシーの問題を避け、プラットフォームにデータを供給する運用システムの近くに配置したいからです。
これがプラットフォームの数字です。4ペタバイト以上の情報を保持し、約3万のテーブルを管理し、毎日5万以上のプロセスを実行してプラットフォームにデータをロードしています。しかし最も重要な数字は、過去5年間で衰えを見せることなく支え続けてきた年間40%の成長率です。これこそが私たちをクラウドへと向かわせた本当の理由です。このプロジェクトは3年計画でした。2023年に新しいプラットフォームの開発を開始し、同時に他の2つの重要なフェーズも実行しました。1つは「プレマイグレーション」と呼ばれるもので、プラットフォームの整理整頓と不要なものの削減に焦点を当て、将来の移行の範囲を縮小できるようにしました。もう1つは規制対応で、銀行のデータをクラウドに移行する承認を得るため、すべての規制当局と協力しました。一部の国では非常に困難を極めました。なぜなら、私たちは情報の100%をクラウドに移行する最初の銀行の1つだったからです。2024年にはプラットフォームが構築され、移行を開始する準備が整いました。ヨーロッパの国々から始め、数週間前にヨーロッパの本番環境への移行を完了し、シャットダウンしました。
ヨーロッパにあるプラットフォームについて、現在はアルゼンチン、ペルー、コロンビア、メキシコを含むアメリカの国々との作業を進めています。2025年半ばまでに移行を完了する計画で、その時点でオンプレミスのプラットフォームを完全にシャットダウンする予定です。このプロジェクトで学んだ5つの教訓についてお話ししましょう。
最初の教訓は複雑性についてです。このプロジェクトの複雑さは、新しいプラットフォームを構築することではなく、古いプラットフォームをシャットダウンできるように、すべてをオンプレミスから新しいプラットフォームに移行することにあります。後ほど説明する並行フェーズは、このプロジェクトで最も重要な部分の1つです。5万以上のプロセスを同時に実行する2つのプラットフォームを並行して運用することは非常に困難なため、移行フェーズはできるだけ短期間で行うことが望ましいのです。
先ほど申し上げたように、プレ移行はプロジェクトの重要な鍵の1つでした。プレ移行フェーズのおかげで、移行の範囲を40%以上削減することができ、プロジェクトの成功に不可欠なフェーズとなりました。規制対応トラックでは、規制当局からの承認を得るために多大な労力が必要となるため、すべてのデータをクラウドに移行することについて、規制当局を説得するために必要な作業を過小評価してはいけません。最後に、シャットダウンフェーズは特筆すべき点です。これは銀行内で古いプラットフォームをシャットダウンする最初のプロジェクトの1つだからです。プラットフォームをシャットダウンできるようにするためには、プロジェクトの開始時点からそれを念頭に置いて設計する必要があります。
AWSを活用したデータアーキテクチャの設計と実装
では、BBVAで使用しているデータアーキテクチャについてお話ししましょう。 2022年末にプロジェクトを開始した時点で、いくつかの課題はありましたが、ゼロからのスタートではありませんでした。私たちは、AWSのモダンデータリファレンスアーキテクチャを採用し、いくつかの重要な前提条件を設定しました：最適なデータパフォーマンスと価格比の実現、あらゆる規模でのデータ利用、シームレスなデータアクセスの提供、セキュリティの確保、データ流出防止機能の提供、価値実現までの時間短縮、統一されたガバナンスによるエンドユーザーのオンボーディングの簡素化、新しい働き方の実現、そしてAmazon SageMakerのようなサービスを活用してビジネス課題を大規模に解決するMLソリューションの提供です。
AWSのモダンデータリファレンスアーキテクチャを異なるレイヤーで使用していますが、これは重要なポイントです。なぜなら、最初に考えなければならないのは、AWSのアカウントをどのように割り当てるかということだからです。 取り込みレイヤーでは、データベースからの取り込みにはAWS DMS、さまざまなデータソースからのファイル取り込みにはAWS DataSyncなど、様々なサービスを利用できます。BBVAの場合、独自のツールも持っており、これらの機能を実行するためにAmazon EMRを広範に活用しました。
まず、データレイク全体をAWSにコピーし、その後増分コピーを提供することを考える必要があります。 これは、データがストレージレイヤー（この場合はS3）に到達した時点で、オンプレミスのソースとAWSのターゲットの間でコピーが正しく実行されていることを検証する必要があるためです。 また、オンプレミスのエンジンとAWS上のエンジンの間でデータカタログを同期する必要があります。そのため、データの取り込み時にはデータカタログとともに、データ権限の移行も考慮する必要があります。これらのプロセスは、完全な実行と増分実行の両方を行う必要があります。
はい、私たちはオンプレミス環境でエンジン上でバッチ処理を実行していましたが、今回はAWS EMRを使用してAWS上で同様のバッチ処理を実行する必要がありました。
これをAWSで実現するために、AWS EMRを使用しています。というのも、オンプレミス環境では、ヨーロッパで2万件以上のデータプロセスを扱うSparkの大規模データ処理を行っているからです。IFRS9や流動性計算などの規制報告に関して、システムに求められるパフォーマンス要件を満たす必要があり、これは大きな課題となっています。 さらに、消費層でのSandboxを通じてエンドユーザーにセルフサービス機能を提供し、Amazon Athenaを使用した分析クエリの実行や、BIサービスとしてのAmazon QuickSightの利用を可能にしています。大規模な機械学習には、Amazon SageMakerを活用し、AWS上のリファレンスアーキテクチャにある他のサービスも活用しています。
大規模な移行を行う際には、データ関連の側面以外にも考慮すべき点があります。 重要な考慮事項の一つが、CI/CD統合です。エンドユーザーが大規模に使用しているコードのリポジトリがある一方で、AWS上で動作する別のプラットフォームと同期を取る必要があります。そのリポジトリを使用し、双方からの供給を確実にする必要があります。CloudFormationは非常に重要です。これは大規模に展開する必要があるからです。一つのリージョンだけでなく、複数のリージョンに展開する可能性があります。そのため、BBVAが事業を展開する様々なリージョンに対して、CloudFormationを使用してインフラストラクチャをサービスとして提供する必要があります。
データ領域のモニタリングには、Amazon CloudWatchとAWS CloudTrailを使用して、バッチプロセスや他の多くのソースからの情報を収集しています。データセキュリティについては、AWS CloudTrailのロギングを使用して、プラットフォーム上で誰が何をしているかを把握しています。 非常に重要なオーケストレーションに関して、BBVAはサードパーティのオーケストレーターであるBMC Control-Mを使用しています。オンプレミスでバッチを実行しながら、AWS上でもバッチを実行する必要があり、両方のバッチプロセスが完全に同期して動作することを確保しています。
人間は間違いを犯す可能性があるため、データ保護は極めて重要です。オブジェクトやデータサブセットを復元する必要があるかもしれません。例えば、災害復旧の比較などのためです。 BBVAは、コスト保護とコストの可視性を提供するための重要な教訓として、統合セキュリティコンソールを開発しました。ここでの焦点は、プラットフォームにおける外れ値となる可能性のあるエンドユーザーの活動から情報を収集することです。中央データプラットフォームはデータエンジニアリングによって運営され、通常はより制御されていますが、私たちはエンドユーザーのモニタリングとガードレールの提供を目指しています。
それでは、これまでの説明を踏まえて、アーキテクチャの全体像を見ていきましょう。私たちは、Data MeshアーキテクチャとData Lake Houseアーキテクチャという2つの優れた世界を組み合わせています。これがプラットフォームの中核部分です。この部分では、Data Lake Houseアーキテクチャを採用しています。ご覧のように、プラットフォームには様々なアカウントがあります。その中でも最も重要なのが、上部にあるDataアカウントです。このアカウントでは、様々な種類のストレージを使用してプラットフォームのすべての情報を保持・管理しています。S3を様々なユースケースで使用していますが、高性能な分析が必要な場合には、AWSの強力なデータウェアハウス技術であるRedshiftも使用しています。これらのデータはすべてAWS Glue Data Catalogで統合し、Lake Formationを使用してデータへのアクセス制御を一元化しています。その下には、Processingアカウントがあります。これは非常に重要で、毎日50,000のプロセスを実行する場所です。実行の主要技術はSparkであり、そのためEMRを使用しています。システムの負荷に応じて、EMRクラスターを動的に作成・破棄しています。何千ものEMRクラスターを運用しています。
これらのEMRクラスターは、複数のアカウントにまたがって毎日作成・破棄されています。例えば、プラットフォームのすべてのセキュリティツールを管理するSecurityアカウント、Control-Mを使用してこれらのプロセスをスケジューリングするSchedulingアカウント、そしてプラットフォームのすべてのログやAWS CloudTrail情報を一元化するLogging/Monitoringアカウントがあります。 右側には、Data Meshアーキテクチャを採用しているConsumption層があります。先ほど説明したように、私たちはSandboxというコンセプトを作り、各ビジネスエリアにSandboxを展開しています。現在、250以上のSandboxが展開されており、各ビジネスエリアのコストと予算をより適切に管理するため、それぞれが独立したアカウントに配置されています。
これらのSandboxには、最も頻繁に使用されるツールの1つであるAmazon Athenaや、分析やモデルトレーニングを行うためのAmazon SageMakerなど、様々なツールが配置されています。中央アカウントのAWS Glue Data Catalogを各Sandboxにフェデレーションすることで、中央アカウントの情報にアクセスできるようにしています。また、QuickSightのようなBIツールや、DomoやMicroStrategyなどのサードパーティツールも展開しています。真のData Meshとなるためには、これらのSandbox間のコラボレーションとデータ共有が必要です。そのため、ガバナンスとコントロールを備えたデータの共有とコラボレーションにAWS DataZoneを使用しています。
並行フェーズの実行とFinDataOpsの確立
では、この変革の旅で特に興味深いと考える機能について、詳しく見ていきましょう。 最初の機能は、Unified Consoleを通じてエンドユーザーの体験をサポートする方法です。私たちの戦略は、ユーザーがAWSサービスを直接利用できるようにすることですが、AWSコンソールは時としてユーザーにとって大きすぎて扱いにくいものです。そこで私たちは、Unified Consoleと呼ぶ独自のコンソールを構築しました。このコンソールでは、ユーザーは必要なサービスを探すことができ、役割に応じて異なるAWSサービスを提供しています。このアプローチにより、高コストな統合を避け、AWSサービスの機能を直接活用することができます。
BBVAに固有の機能もあり、これらもこのコンソールに実装しています。例えば、ユーザーのデータサブスクリプションを承認する必要がある場合、現在のAWSコンソールではできないため、私たちのコンソールで開発しました。他にも多くの機能を実装していますが、最も重要な側面の1つは、ユーザーに提供するダッシュボードです。これにより、ユーザーは支出、使用しているサービス、時間の経過に伴うコストの推移などのFinOps情報を確認できます。 データの民主化は私たちの戦略的優先事項の1つであり、ユーザーが必要な情報に簡単にアクセスできるよう努めています。私たちのコンソールでは、ガバナンスツールを使用して必要な情報に直接サブスクライブできます。機密性の低い情報であれば、即座にアクセスが可能です。機密情報の場合は、データオーナーの承認が必要です。オンプレミスでは、テーブルへのアクセス要求に1〜2週間かかっていましたが、現在では15秒で完了することもあり、大幅に高速化されています。
データの体系化に関して、これはプロジェクト開始時の基盤となったものですが、私たちは主にAmazon S3をメインストレージとして使用しています。S3の構成は、国、セキュリティレベル、そしてプラットフォームのデータ層に応じて整理しています。
この体系化のために、異なるバケットを作成しています。セキュリティレベルは3段階あり、パブリックデータ用のL1、機密データ用のL2、極秘データ用のL3があります。各バケットは異なる暗号化キーを使用してセキュリティを確保し、カタログが抽象化層として機能します。ユーザーはデータベースのようなビューを持っているため、ファイルの物理的な場所を知る必要はありません。すべての権限とアクセス制御はLake Formationタグによって管理され、情報とセキュリティの管理が大幅に簡素化されています。
プロジェクト開始時の重要な要件の1つは、ADAでのデータ漏洩を防ぐためのデータフィルタリングでした。先ほど述べたように、私たちは7,000万人の顧客データを扱っているため、セキュリティは私たちにとって極めて重要です。データ漏洩のリスクを防ぐ必要があり、そのためにAppStreamというAmazonのサービスを使用しています。ユーザーにとってほぼ見えない存在のAppStreamを使用することで、情報をローカルにダウンロードして銀行の外部に持ち出すことを防ぐことができます。各Sandbox用に独立したAppStream Fleetを展開し、ユーザーが情報をダウンロードする必要がある場合は、データ漏洩のリスクを排除するために、制御とガバナンスを備えた独自のコンソールでダウンロード機能を開発しています。
移行アプローチに関しては、エンジンを並行して稼働させ続けることが重要だったため、この部分に多くの時間を投資しました。プロジェクトの中で最も複雑で重要な部分の1つである並行フェーズをどのように実行するかの定義に大きな労力を費やしました。ここで目指しているのは、両方のプラットフォームが同じ結果を生み出すまで並行して稼働させることです。私たちはオンプレミスのプラットフォームから始めました。これには、毎日何千ものオペレーショナルシステムからプラットフォームにファイルが送信されています。データエンジニアは、異なる国からの伝送を含む、このデータをオンプレミスプラットフォームに取り込むための何千ものジョブを作成しました。毎日15,000以上の伝送があり、ユーザーは多くのツール、ノートブック、ジョブ、BIツールからこのデータを利用しています。
この並行フェーズで最初に行ったのは、AWSで開発した新しいシステムを展開し、オンプレミスからすべてのプロセスを移行することでした。また、伝送の複製も行いました。つまり、オペレーショナルシステムがファイルを送信すると、両方のプラットフォームに同時に到着するようになりました。並行フェーズを開始する前に、すべてのデータ（4ペタバイト）を移行する必要もありました。 非常に迅速に行う必要があったため、情報を転送するための独自のシステムを作成しました。コピーを行うためにバッチ処理を停止する必要がありましたが、バッチを長時間停止することはできませんでした。そこで、情報を転送するための独自のシステムを開発しました。まず、4ペタバイトすべての情報をコピーデータオンプレミスと呼ぶ新しいストレージに完全コピーし、その後、そのデータをクラウドと同期させました。
その時点で、オンプレミスとクラウドで同時に50,000のプロセスを実行し始めました。これを1週間続けた後、停止して結果の確認を開始しました。当初は、クラウドで実行されるプロセスに多くの問題があり、クラウドとオンプレミスで得られるデータの違いを修正する必要がありました。週末にはバッチを停止して比較し、問題があれば再度同期を行いました。クラウド上の情報がオンプレミスと完全に一致するまで、6ヶ月間にわたってこの作業を毎週続けました。ユーザーにもプラットフォームのテストが必要でしたが、最初は、コピーが完璧で情報に問題がないことが分かっていたため、コピーに対して新しいAWSツールでテストを開始しました。
クラウド上のデータの品質が十分に良くなったところで、シャットダウン直前に、ユーザーに最終プラットフォームのテストを開始してもらいました。すべてが正常に動作することを確認した後、コピーを削除してオンプレミスシステムをシャットダウンし、移行を完了しました。先ほど申し上げたように、これを実現するために、 EMRとDeltaCPをベースにした独自の転送システムを開発しました。このシステムにより、30時間で500テラバイト以上、あるいは週次オペレーションで6時間以内に約100テラバイトという非常に高速な転送速度を達成しました。これは非常に重要なフェーズであり、オンプレミスプラットフォームのシャットダウンを可能にする鍵となりました。移行を決定した時点での成功率は97%で、90-95%という完全なテーブルとクリティカルプロセスに関するゴール基準を超えることができました。
さて、ここからは非常に興味深い話題です。BBVAでデータ領域のFinOpsをどのように管理しているかについてお話しします。 私たちは、FinDataOpsという部門を設立しました。これはFinOpsの一部門で、データに特化した部門です。この部門には複数の機能があります。まず、従量課金制のモデルに慣れていない財務部門に対して、予算管理と請求の支援を行います。また、来年度の予算予測や請求戦略の策定をサポートします。
コスト管理とガードレールの導入、そして未来への展望
次に、FinOps戦略において、コストの可視化は非常に重要です。ユーザーに対して、自分たちの活動のコストに関する詳細な情報を提供するために多くの取り組みを行っています。ユーザーに適切に作業してもらうためには、自分たちの支出と活動を把握してもらうことが重要です。また、この従量課金制戦略は組織に新しい役割と働き方をもたらすため、ガバナンスモデルも不可欠です。これらの役割を定義し、どのように運用するかを確立する必要があります。しかし、最も重要な側面はコスト保護です。多くのユーザーがクラウドプラットフォームに不慣れで、コストに影響を与えるエラーを起こすことを私たちは知っているため、利用するサービスにガードレールを設けることで、ユーザーを保護する取り組みを広範に行っています。
ベストプラクティスとして、Sandboxに組み込まれる新しいサービスはすべて、ガードレール分析プロセスを経ます。アナリティクスとMLに対して、2種類のガードレールを設計しています。予防的ガードレールは、ユーザーがCloudFormation上のInfrastructure as Codeテンプレートに基づいてAWSサービスを設定する際のリクエスト時に展開されます。例としては、EMR実行制御やAmazon Athenaのクエリごとの制御制限などがあります。検知的ガードレールは、CloudWatchやCloudTrailによって監視されるログ、トレイル、タイムスタンプ、消費量を使用して展開されます。検知的ガードレールの例としては、しきい値に達した際のガードレール実行につながるアラート生成や、Amazon EMRジョブのメトリクスとログのリアルタイム分析とガードレール制限との比較などがあります。
このようなガードレールに基づいて、意図しない消費を防ぎ、コストの保護と可視性を提供しています。
プラットフォームの規模に応じて、ハイレベルなアーキテクチャを見ると、異なるリスクが存在することがわかります。左側は、AWSサービスとの直接的なやり取りがないため、リスクが低くなっています。コンソールはありますが、プラットフォームを構築するアーキテクチャチームのみが使用し、彼らは非常に高いスキルを持っています。中央部分では、日々インジェストプロセスを開発する数百から数千のData Engineerがいるため、リスクが高くなります。これらのユーザーは高いスキルを持っていますが、コストに影響を与えるエラーを防ぐために保護する必要があります。
最もリスクが高いのは右側で、ビジネス部門から技術的なスキルを持たない何千人ものユーザーがプラットフォームを使用し、コストに影響を与えるエラーを起こす可能性が高いです。私たちはゾーンに応じて異なるガードレールを作成しました。中央部分では、 Data Engineerが使用するサービスを保護する9つのガードレールを作成しました。EMRとAWS Glueについては、ジョブの実行時間をチェックし、長時間実行されている場合は停止するガードレールを設けています。右側では、ユーザーが日常的に使用するすべてのサービスを保護しています。例えば、Amazon Athenaでは、処理する情報量が多すぎるクエリを停止するガードレールを設けています。
これらのガードレールがあっても、財務部門はSandboxのコスト管理と、作業中にSandboxが予算を超過した場合の対応について懸念を持っていました。そこで、メインのガードレールを作成しました。 このメインガードレールは、常にSandboxの予算を監視し、予算の40%、50%、100%を消費した時点でユーザーにアラートを送信します。200%の時点でアクションが取られない場合、Sandboxは自動的にすべてのアクティビティを停止します。その時点で、ユーザーは何が起きているのかを確認する必要があります - 予想以上のプロジェクトがあるかもしれませんし、サービスを不適切に使用して予想以上の消費が発生しているかもしれません。問題を理解したら、予算を修正することができ、そうするとSandboxは自動的に再起動します。
AWS はCost ExplorerやBillingツールを通じて、コストに関する豊富な情報とツールを提供していますが、私たちはユーザーに自分たちのアクションを認識してもらうために、できるだけ多くの情報を提供する必要があると考えています。AWS CUR Databaseに基づいて、必要な情報をすべて含むカスタムダッシュボードを作成しました。これらのダッシュボードで、ユーザーはビジネスエリアレベルの情報にアクセスし、部門レベルや個々のユーザー、サービスまで掘り下げて確認することができます。私たちが提供する重要な機能の1つは、異なるビジネスエリアや個々のユーザーを比較できることです。これにより、誰が最も優れたユーザーなのかを確認し、他のユーザーがプラットフォーム上で適切に作業するためのモデルとして活用することができます。
Sandbox Ownerの役割は、プラットフォーム上で何が起きているかを監視し、最終的にコストに責任を持つことです。彼らは日々これらのダッシュボードを使用してプラットフォームの活動を監視し、ユーザーが何か間違ったことをしているのを見つけた場合、その問題を解決するために協力します。将来のロードマップについて、 現在のGenerative AIの時代において、私たちはこのテクノロジーを活用したいと考え、次のスライドで見られるように、エンドユーザー向けのヘルプチャットボットを提供するパイロットプロジェクトを開始しました。
プラットフォーム上の運用ドキュメントから得られるすべてのデータを取り込み、セマンティック検索を提供し、私たちが持つ情報を活用します。これにより、ADA内でプラットフォームの問題解決やユーザーサポートにかかる時間を大幅に短縮することができます。
要件の1つはスペイン語のサポートでした。私たちは今回一緒に参加しているAccentureと協力し、1ヶ月半という短期間でプロトタイプを完成させ、実証することができました。これにより、エンドユーザーは「Sandboxエンジンをどのようにモニタリングすればよいですか？」や「Fireglassとは何ですか？」といった質問をすることができます。Fireglassは以前オンプレミスで使用されていたアップストリームでした。これは、プラットフォーム自体で非常に迅速にプロトタイプを作成できることをエンドユーザーに示す良い例となりました。
プラットフォームが本番環境で稼働していることを大変嬉しく思いますが、2025年に向けて非常に興味深い課題があります。現在は構造化データのみを扱っていますが、Generative AIで想定されるすべてのユースケースに対応するためには、非構造化データの管理を始める必要があります。私たちはSandbox間のデータ共有とコラボレーションの改善に取り組んでおり、急速に進化しているDataZoneの新機能を継続的に統合していきます。また、Amazon SageMakerによるリアルタイム推論の統合も開始しました。現在はバッチ推論のみを行っていますが、これからリアルタイム推論の統合を始めており、さらにデータレイヤーに Feature Storeという新しいストレージを追加して、データサイエンティストがより速くモデルをトレーニングできるようにしています。
現在は一定の制限のあるParquetフォーマットのみを使用していますが、より興味深い機能を提供してくれるIcebergのような新しいトランザクショナルデータフォーマットの検討を始めています。現在見ていただいているものはすべてバッチ処理で、毎日実行される50,000のプロセスはすべてバッチ処理です。これからはリアルタイムのユースケースに対応するため、Amazon Kinesisを使用したリアルタイム処理の統合を開始しています。毎日50,000のプロセスを実行している多くのデータエンジニアがいますが、これらの機能開発をより迅速に行いたいと考えています。そのため、データエンジニアがより良いツールを持てるよう、Amazon EMR ServerlessやAWS Glueのデータ品質とETLといった新しいサービスを検討しています。
申し上げた通り、私たちはプラットフォームが本番環境で稼働していることを大変嬉しく思っています。現在、クラウドへの移行とAWSの活用による恩恵を実感していますが、最高の成果はこれからだと確信しています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion