Amazon Web Services ブログ

Category: Analytics

AWS Lake Formation の LF タグ管理の分散化

昨今のデータドリブンな世界では、組織は拡大し続けるデータエコシステムから貴重な洞察を管理し、抽出する上で、前例のない課題に直面しています。データ資産とユーザーの数が増えるにつれ、データ管理とガバナンスに対する従来のアプローチではもはや間に合いません。顧客は現在、権限管理を分散化するためのより高度なアーキテクチャを構築しています。これにより、中央のガバナンスチームに律速されることなく、個々のユーザーグループが独自のデータ製品を構築して管理できるようになります。 AWS Lake Formation のコア機能の1つは、 AWS Glue Data Catalog のデータベース、テーブル、カラムなどのリソースのサブセットに対する権限をデータスチュワードに委任することです。これにより、誰がリソースにアクセスできるかを決定できるようになり、データレイクの権限管理を分散化できます。 Lake Formation にはデータスチュワードが独自の Lake Formation タグを作成してアクセス権を管理できる機能が追加されました。 Lake Formation タグベースアクセス制御 (LF-TBAC) は、属性に基づいて権限を定義する認証戦略です。 Lake Formation ではこれらの属性を LF タグと呼びます。 LF-TBAC は、データカタログリソースが多数ある場合に Lake Formation の権限を付与する方法として推奨されます。 LF-TBAC は、名前付きリソース方式よりスケーラブルで、権限管理のオーバヘッドも少なくて済みます。この記事では、 LF タグの作成、管理、権限付与をデータスチュワードに委任するプロセスについて説明します。

データ転送を簡素化: Amazon AppFlow を利用した Google BigQuery から Amazon S3 への転送

昨今のデータドリブンな世界では、様々なプラットフォーム間でデータを簡単に移動して分析できることが不可欠です。フルマネージド型のデータ統合サービスである Amazon AppFlow は AWS サービスと SaaS アプリケーション間のデータ転送を効率化する最前線に立ってきており、現在は Google BigQuery にも対応しています。このブログ記事では、Amazon AppFlowの Google BigQuery コネクタがGoogle のデータウェアハウスから Amazon Simple Storage Service (Amazon S3) にデータを転送するプロセスを簡略化する手法と、マルチクラウドデータアクセスの民主化を含めたデータ専門家や組織にとっての大きなメリットについて解説します。

AWS Glue for Apache Spark のコストのモニタリングと最適化

AWS Glue for Spark についてお客様から最もよくいただくご質問のひとつに、ワークロードのコストを効果的にモニタリングし、最適化する方法があります。AWS Glue ワークロードのコストを最適化するには、ジョブ実行をモニタリングして、実際にかかったコストと使用状況を分析し、節約できるポイントを見つけ、コードや構成の改善に向けたアクションを取ります。この投稿では、AWS Glue ワークロードの上にモニタリングと最適化技術を用いることで、コストを管理および削減するためのアプローチを紹介します。

Data Driven

製造現場でデータドリブンとクラフトマンシップは交わるのか?

ものづくり白書2023では、日本の製造業について「我が国の生産現場は、高度なオペレーション・熟練技能者の存在によって、現場の最適化・高い生産性に強みを持つ」と分析しており、熟練技能者がクラフトマンシップを発揮して高い現場力を維持していることが強みという認識が示されています。一方で、「海外の先進企業は、データ連携や生産技術のデジタル化・ 標準化に強みを持ち、企業の枠を越えた最適化を実現」という表現で日本と海外先進企業の違いを分析しています。日本の製造業が今後さらに競争力を高めていくためには、高い現場力による部分最適と、データ連携によるデータドリブンなオペレーションと全体最適とを両立させることが鍵となりそうです。本ブログでは、部分最適と全体最適という一見すると相反したものを目指すデータドリブンとクラフトマンシップが交わるのか?について考察していきます。

Amazon OpenSearch Service Multi-AZ with Standby が有効化されたドメインによる高可用性の実現: フェイルオーバーの詳細

Amazon OpenSearch Service は最近、Multi-AZ with Standby を導入しました。これは重要なワークロードに対して、強化された可用性と一貫したパフォーマンスをビジネスに提供するために設計されたデプロイメントオプションです。この機能により、マネージドクラスターはゾーンのインフラストラクチャ障害に対する回復力を保ちながら、99.99% の可用性を実現できます。

Amazon OpenSearch Service は Multi-AZ with Standby を利用した 99.99% の可用性をサポート

AWS は OpenSearch Service の新しいデプロイメントオプションである Multi-AZ with Standby を発表しました。これにより、高頻度の監視、迅速な障害検出、障害からの迅速な回復などの重労働を軽減し、インフラ障害が発生した場合でもドメインの可用性とパフォーマンスを維持できるようになります。Multi-AZ with Standby を使用すると、ドメインは 99.99% の可用性と一貫したパフォーマンスを実現できます。

AWS Glue を使用した個人情報の検出・マスキング・編集および Amazon OpenSearch Service へのロード

大企業や中小企業を問わず、多くの組織がアマゾン ウェブ サービス(AWS)上で分析ワークロードの移行と近代化に取り組んでいます。AWS への移行にはさまざまな理由がありますが、主な理由の 1 つは、インフラストラクチャのメンテナンス、パッチ適用、モニタリング、バックアップなどに時間を費やす代わりに、フルマネージドサービスを利用できることです。リーダーシップと開発チームは、現在のインフラストラクチャのメンテナンスではなく、現在のソリューションの最適化や新しいユースケースの実験などにより多くの時間を費やすことができます。

AWS Step Functions の Distributed Map と再実行機能を使用した効率的な ETL パイプラインの構築

AWS Step Functions は、完全マネージドのビジュアルワークフローサービスで、AWS Glue、Amazon EMR、Amazon Redshift などのさまざまな抽出・変換・読み込み (Extract, Transform, Load; ETL) テクノロジーを含む複雑なデータ処理パイプラインを構築できます。Step Functions では、失敗、中止、タイムアウトしたステートからワークフローを再実行できるようになりました。この投稿では、Step Functions のDistributed Map ステートを使用して、Amazon Relational Database Service (Amazon RDS) のテーブルからデータをエクスポートする ETL パイプラインジョブをご紹介します。その後、障害をシミュレートし、新しい失敗したステートから再実行する機能を使用して、障害が発生したタスクを障害発生地点から再起動する方法をデモンストレーションします。