はじめまして。SCSKのすぐろです。 プレビュー版として実装されていたAWS DevOps Agentが2026年3月にGA（一般提供）されましたね。 インシデント発生時に自動で原因調査を行ってくれるサービスですが、実際にどこまで調べてくれるのかが気になったので、Amazon EC2上のWebサーバーで障害を発生させ、DevOps Agentの調査精度と限界を検証してみました。 参照: AWS DevOps Agent is now generally available AWS DevOps Agentとは インシデント発生時に、複数のデータソースを横断的に分析し、根本原因の特定と緩和策の提案を自動で行うマネージドサービスです。AWSネイティブなCloudWatchメトリクス・CloudWatch Logs・CloudTrailに加え、Datadog、Dynatrace、New Relic、Splunk等のサードパーティ製監視ツールや、GitHub、GitLab等のCI/CDパイプライン、ServiceNow、PagerDuty等のチケットシステムとも連携できます。GA版ではAzureやGrafanaのサポートも追加されました。 参照: About AWS DevOps Agent 参照: AWS DevOps Agent GA発表ブログ 料金 従量課金制で、エージェントがタスクに費やした時間に対して秒単位で課金されます。アイドル状態や待機中は課金されません。 課金対象 単価 Investigations（インシデント対応） $0.0083 / agent-second Evaluations（インシデント予防） $0.0083 / agent-second On-demand SRE tasks（チャット） $0.0083 / agent-second 新規利用者には2ヶ月間の無料トライアルがあり、各月Investigation 20時間・Evaluation 15時間・チャット 20時間まで無料で利用できます。 参照: Pricing – AWS DevOps Agent 検証のきっかけ 本番稼働中のWebサーバー(EC2インスタンス)のインシデント調査に使用するにあたり、以下の4点がきになりました。 EC2インスタンスへの影響はあるか DevOps AgentのIAMマネージドポリシー（ AIDevOpsAgentAccessPolicy ）を確認すると、EC2に対しては ec2:Describe* 等の読み取り系APIのみが許可されています。セキュリティドキュメントにも「エージェントが利用可能なツールは、チケットやサポートケースのオープンを除き、リソースを変更することができない」と記載されています。つまり、DevOps Agentの導入・調査によってEC2インスタンスが変更・停止されることはありません。 参照: DevOps Agent IAM permissions 参照: AWS DevOps Agent Security サーバーの中まで見に行ってくれるのか DevOps AgentはAWSのAPIを通じて情報を収集します。OS内部に直接アクセスする機能はドキュメントに記載されていません。OS内部の情報を調査対象にするには、CloudWatch Agent等でCloudWatch Logsやカスタムメトリクスとして事前に送信しておく必要があります。 参照: About AWS DevOps Agent 参照: What is a DevOps Agent Topology? どうやって調査しているのか IAMポリシーにはSSMでコマンドを実行する ssm:SendCommand やSSH接続用の ec2-instance-connect:* は含まれていません。SSHやSSMでEC2に接続するのではなく、AWSのAPIを通じた読み取り専用アクセスのみで調査を行います。 参照: DevOps Agent IAM permissions サーバー内に何かインストールされるのか EC2インスタンス内部にエージェントソフトウェアがインストールされることはありません。導入時に作成されるのはAgent Space（論理コンテナ）やサービスリンクロール等、AWSコントロールプレーン側のリソースのみです。 参照: DevOps Agent IAM permissions 検証 検証環境 EC2: t3.micro（Amazon Linux 2023）、httpd（Apache）をUserDataで起動 CloudWatch Agent: 以下の設定でログ・メトリクスを送信 CloudWatch Agentの設定ファイル（ /opt/aws/amazon-cloudwatch-agent/etc/config.json ）: { "metrics": { "namespace": "DevOpsAgentTest", "metrics_collected": { "mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 }, "disk": { "measurement": ["used_percent"], "metrics_collection_interval": 60, "resources": ["*"] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "/devops-agent-test/messages" }, { "file_path": "/var/log/httpd/error_log", "log_group_name": "/devops-agent-test/httpd-error" }, { "file_path": "/var/log/httpd/access_log", "log_group_name": "/devops-agent-test/httpd-access" } ] } } } } /var/log/messages をCloudWatch Logsに送信することで、OOM KillerなどカーネルレベルのイベントがDevOps Agentの調査対象になります。メモリ・ディスク使用率のカスタムメトリクスも送信し、標準メトリクス（CPU、ネットワーク等）と合わせてDevOps Agentが参照できるようにしています。 検証1: CPU高負荷 SSMで接続し、 yes > /dev/null コマンドでCPUを100%に張り付かせた状態でDevOps Agentに調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: CPU使用率が100%に達していることを正しく検知 CloudTrailからタイムラインを構築し、同時刻のイベント（yum update、Inspector 2スキャン、SSMセッション開始）を列挙 「SSMセッション内でCPU集約的なコマンドを実行した可能性がある」と推測 → 実際に正しい方向の推測 調査した結果原因を断定できなかったので仮説を立てている 各仮説に「可能性がある」という表現を使い、断定を避けていた 「調査ギャップ」として確認できなかった事項を明確に報告 真の原因（yesコマンド）にはOS内部のプロセス情報がないため到達できませんでしたが、仮説と事実を区別した誠実な調査結果でした。 調査コスト: 約6分（360秒）→ $2.99（$1=¥150換算で約¥448） 追加検証: SSMセッションログを有効にして再検証 検証1ではDevOps Agentが実行コマンドを特定できなかった原因は、SSMセッション内で何を実行したかのログがCloudWatch Logsに送信されていなかったためです。そこで、SSM Session ManagerのCloudWatch Loggingを有効にし、セッション中のコマンド入出力をCloudWatch Logsに記録する設定を追加した上で、同じCPU高負荷を再現して調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: 根本原因を「IAMユーザーxxxxxによる意図的なCPUストレステストの実行」と正確に特定 実行コマンド（ for i in $(seq 1 $(nproc)); do (yes > /dev/null) & done ）を特定 実行ユーザー、セッションID、起動されたプロセスのPIDまで特定 「計画的な負荷テストであり、システム異常やマルウェアではない」と正しく判断 SSMセッションログという1つのデータソースを追加しただけで、検証1の「仮説止まり」が「正確な原因特定」に変わりました。DevOps Agentの調査精度がデータソースの充実度に直結することを改めて裏付ける結果となりました。 検証2: メモリ逼迫によるOOM Killer発動 stress-ng でメモリを枯渇させ、OOM Killerによってhttpdが強制終了される状況を作り、DevOps Agentに調査を依頼しました。検証1と異なり、OOM Killerのログが /var/log/messages → CloudWatch Logs経由でDevOps Agentの調査対象になります。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )上のWebサーバー（httpd、ポート80）が応答しなくなりました。原因を調査してください。 結果: 根本原因を「stress-ngツールによる意図的なメモリ枯渇テスト」と正確に特定 実行ユーザー（SSMセッションユーザー）を特定 実行コマンドとパラメータ（ stress-ng --vm 1 --vm-bytes 900M ）まで特定 OOM Killerが全httpdプロセス（PID含む）を強制終了したことをログから読み取り タイムラインを正確に構築（00:07:17 → 00:11:29 → 00:17:32） メモリ枯渇 → OOM Killer → httpd停止 という因果関係に正しく到達 検証1では仮説止まりだったのに対し、CloudWatch Logsにカーネルログという明確な根拠があったことで、正確な原因特定ができました。 また、調査完了後に「緩和計画」という機能を実行したところ、stress-ngプロセスの停止 → httpdサービスの再起動 → 事後検証（HTTP 200 OK確認）まで、具体的なコマンド付きの復旧手順を提示してくれました。手順通りに実行してWebサーバーの復旧を確認できました。 調査コスト: 約5分（304秒）→ $2.52（$1=¥150換算で約¥379） わかったこと 良かった点 AWSのAPI経由で取得できる情報を横断的に分析し、タイムラインを構築する能力は高い CloudWatch Logsに根拠となるログが存在する場合、実行コマンド・ユーザー・タイムラインまで正確に特定できる（検証2で確認） 調査ギャップ（確認できなかったこと）を報告する仕組みがある EC2インスタンスへの変更やエージェントのインストールは不要 従量課金制で、調査しなければ費用は発生しない 注意が必要な点 OS内部のプロセス状態やローカルログには直接アクセスできない CloudWatch Logsに送信されていない情報は調査対象外 データソースに根拠がない場合、仮説止まりになる（検証1で確認） 調査精度の比較 検証 データソースの根拠 原因特定 評価 検証1（CPU高負荷） △ メトリクスのみ × 仮説止まり 真の原因に到達できず 検証1 追加検証（SSMセッションログ有効） ○ メトリクス + SSMセッションログ ○ 正確に特定 コマンド・ユーザー・PIDまで特定 検証2（メモリ逼迫） ○ メトリクス + OOM Killerログ ○ 正確に特定 コマンド・ユーザーまで特定 まとめ DevOps Agentの調査精度は、データソースに残る根拠の有無に大きく依存します。検証1ではメトリクスだけでは仮説止まりでしたが、SSMセッションログを1つ追加しただけで正確な原因特定に変わりました。 導入を検討する場合は、DevOps AgentがAPIレベルで情報を取得できる環境を整備しておくことが重要だと感じました。CloudWatch Agentによるログ・メトリクスの送信はもちろん、CloudTrailの有効化やVPCフローログの設定など、DevOps Agentが参照できるデータソースを充実させて調査精度を向上させることで、インシデント調査はエージェントにお任せし、業務効率を向上させていきましょう！

本記事は 2026 年 1 月 12 日 に公開された「 Navigating architectural choices for a lakehouse using Amazon SageMaker 」を翻訳したものです。 組織がデータを活用して意思決定やイノベーションを推進する動きは加速しています。ペタバイト規模の情報を扱う中で、従来はデータレイクとデータウェアハウスという 2 つの異なるパラダイムに分かれてきました。それぞれ特定のユースケースに強みがある一方、データ資産間に意図しない障壁を生むことがあります。 データレイクは Amazon Simple Storage Service (Amazon S3) などのオブジェクトストレージ上に構築されることが多く、多様なデータ形式とスキーマ・オン・リード機能をサポートする柔軟性を提供します。そのため、 Apache Spark 、 Trino 、 Presto などの様々な処理フレームワークが同じデータにクエリできる マルチエンジンアクセス が可能になります。一方、データウェアハウス ( Amazon Redshift など) は、ACID (原子性、一貫性、分離性、耐久性) 準拠、パフォーマンス最適化、簡単なデプロイメントに優れており、構造化された複雑なクエリに適しています。データ量の増加と分析ニーズの複雑化に伴い、組織はデータレイクとデータウェアハウスのサイロを橋渡しし、両方のパラダイムの強みを活用しようとしています。レイクハウスアーキテクチャはデータ管理と分析を統合的に扱うアプローチとして注目されています。 時間の経過とともに、いくつかの異なるレイクハウスアプローチが登場しました。本記事では、ニーズに合った適切なレイクハウスパターンの評価と選択方法を紹介します。 データレイク中心のレイクハウス アプローチは、オブジェクトストレージ上に構築された従来のデータレイクのスケーラビリティ、コスト効率、柔軟性から始まります。目標は、主にオープンテーブルフォーマット ( Apache Hudi 、 Delta Lake 、 Apache Iceberg ) を通じて、従来データベースにあったトランザクション機能とデータ管理レイヤーを追加することです。オープンテーブルフォーマットはデータレイクの単一テーブル操作に ACID 保証を導入する点で大きく進歩しましたが、複雑な参照整合性制約やジョインを伴うマルチテーブルトランザクションの実装は依然として困難です。オブジェクトストレージ上のペタバイト規模のファイルに対するクエリは、分散クエリエンジンを介することが多く、高度に最適化・インデックス化・マテリアライズ化されたデータウェアハウスと比較すると、高い同時実行性でのインタラクティブクエリが遅くなる可能性があります。オープンテーブルフォーマットはコンパクションとインデックスを導入していますが、成熟した独自仕様のデータウェアハウスに見られる高度なストレージ最適化機能は、データレイク中心のアーキテクチャではまだ発展途上です。 データウェアハウス中心のレイクハウス アプローチは充実した分析機能を提供しますが、相互運用性に大きな課題があります。データウェアハウスは外部アクセス用に JDBC および ODBC ドライバーを提供していますが、基盤となるデータは独自仕様の形式のままであり、複雑な ETL や API レイヤーなしでは外部ツールやサービスが直接アクセスすることが困難です。データの重複とレイテンシーにつながる可能性があります。データウェアハウスアーキテクチャはオープンテーブルフォーマットの読み取りをサポートする場合がありますが、書き込みやトランザクションレイヤーへの参加能力は限定的です。真の相互運用性が制限され、意図しないデータサイロが生まれる可能性があります。 AWS では、データウェアハウスとデータレイクの両方への統合アクセスを実現する モダンでオープンなレイクハウスアーキテクチャ を構築できます。このアプローチにより、データの単一の信頼できるソースを維持しながら、高度な分析、機械学習 (ML)、生成 AI アプリケーションを構築できます。データレイクかデータウェアハウスかを選ぶ必要はありません。既存の投資を活用し、両方のパラダイムの強みを維持しつつ、それぞれの弱点を解消できます。AWS のレイクハウスアーキテクチャは、Apache Hudi、Delta Lake、Apache Iceberg などのオープンテーブルフォーマットを採用しています。 次世代の Amazon SageMaker でレイクハウスの導入を加速できます。SageMaker はデータへの統合アクセスを備えた分析と AI の統合エクスペリエンスを提供します。SageMaker は Apache Iceberg と完全互換のオープンレイクハウスアーキテクチャ上に構築されています。Apache Iceberg REST API のサポートを拡張することで、SageMaker は様々な Apache Iceberg 互換クエリエンジンやツール間の相互運用性とアクセシビリティを大幅に向上させています。このアーキテクチャの中核には、 AWS Glue Data Catalog と AWS Lake Formation 上に構築されたメタデータ管理レイヤーがあり、統合ガバナンスと一元的なアクセス制御を提供します。 Amazon SageMaker レイクハウスアーキテクチャの基盤 Amazon SageMaker のレイクハウスアーキテクチャには、統合データプラットフォームを構成する 4 つの主要コンポーネントがあります。 ワークロードパターンと要件に適応する柔軟なストレージ すべてのメタデータの単一の信頼できるソースとなるテクニカルカタログ すべてのデータ資産にわたるきめ細かなアクセス制御を備えた統合権限管理 Apache Iceberg REST API 上に構築された、ユニバーサル互換性のためのオープンアクセスフレームワーク カタログと権限 オープンレイクハウスを構築する際、メタデータの中央リポジトリであるカタログは、データ検出とガバナンスの重要なコンポーネントです。Amazon SageMaker のレイクハウスアーキテクチャには、マネージドカタログとフェデレーテッドカタログの 2 種類のカタログがあります。 マネージドカタログは、レイクハウスがメタデータを管理し、データを汎用 S3 バケットに保存する形態です。 フェデレーテッドカタログは、外部や既存のデータソースをマウント・接続し、データを移動せずに Amazon Redshift 、Snowflake、 Amazon DynamoDB などのデータソースに直接クエリできる形態です。詳細は「 Data connections in the lakehouse architecture of Amazon SageMaker 」を参照してください。 AWS Glue クローラー を使用して、 Data Catalog にメタデータを自動的に検出・登録できます。Data Catalog はデータ資産のスキーマとテーブルメタデータを保存し、ファイルを論理テーブルに変換します。データがカタログ化されたら、次の課題はアクセス制御です。フォルダごとに複雑な S3 バケットポリシーを使用することもできますが、管理とスケーリングが困難です。 Lake Formation は Data Catalog 上にデータベーススタイルの一元的な権限モデルを提供し、個々のユーザーやロールに対して行、列、セルレベルのきめ細かなアクセスを付与または取り消す柔軟性を備えています。 Apache Iceberg REST API によるオープンアクセス 前述のレイクハウスアーキテクチャ (以下の図の) は、サービスエンドポイントを通じて AWS Glue Iceberg REST カタログ も使用しています。OSS 互換性を提供し、Spark やその他のオープンソース分析エンジン間で Iceberg テーブルメタデータを管理するための相互運用性を向上させます。テーブルフォーマットとユースケースの要件に基づいて適切な API を選択できます。 本記事では、データレイクとデータウェアハウスを最適に活用してスケーラブルで高パフォーマンスなデータソリューションを構築する方法に焦点を当て、様々なレイクハウスアーキテクチャパターンを探ります。 AWS でレイクハウスにデータを取り込む レイクハウスアーキテクチャを構築する際、データのアクセスと統合には 3 つの異なるパターンから選択でき、それぞれ異なるユースケースに固有の利点を提供します。 従来の ETL は、データを抽出し、変換してレイクハウスにロードする従来の方法です。 使用すべきケース: 複雑な変換が必要で、パフォーマンス向上のためにダウンストリームアプリケーション向けに高度にキュレーションされ最適化されたデータセットが必要な場合 過去データの移行が必要な場合 大規模なデータ品質の適用と標準化が必要な場合 レイクハウスに高度にガバナンスされたキュレーション済みデータが必要な場合 Zero-ETL は、ソースシステムからレイクハウスへデータを最小限の手動介入やカスタムコードで自動的かつ継続的にレプリケートするモダンなアーキテクチャパターンです。内部的には、変更データキャプチャ (CDC) を使用して、ソースからターゲットへのすべての新規挿入、更新、削除を自動的にストリーミングします。このアーキテクチャパターンは、ソースシステムが高いデータクリーンネスと構造を維持しており、ロード前の重い変換の必要性が最小限の場合、またはデータの精製と集約がレイクハウス内のターゲット側で行える場合に効果的です。Zero-ETL は最小限の遅延でデータをレプリケートし、変換ロジックはインサイトが生成される場所に近いターゲット側で、より効率的なロード後フェーズとして実行されます。 使用すべきケース: 運用の複雑さを軽減し、準リアルタイムとバッチの両方のユースケースでデータレプリケーションを柔軟に制御する必要がある場合 カスタマイズが限定的で十分な場合。Zero-ETL は最小限の作業を意味しますが、レプリケートされたデータに軽い変換が必要な場合もあります 専門的な ETL の専門知識の必要性を最小限に抑えたい場合 処理遅延なしでデータの鮮度を維持し、データの不整合リスクを軽減する必要がある場合。Zero-ETL はインサイトまでの時間を短縮します データフェデレーション (データ移動なしのアプローチ) は、データを単一の集中場所に物理的に移動またはコピーせずに、複数の異なるソースからデータをクエリ・結合できる方法です。この クエリインプレース アプローチにより、クエリエンジンが外部ソースシステムに直接接続し、クエリを委任・実行し、結果をオンザフライで結合してユーザーに提示できます。このアーキテクチャパターンの効果は、システム間のネットワークレイテンシー、ソースシステムのパフォーマンス能力、クエリエンジンの述語のプッシュダウン能力の 3 つの要因に依存します。このデータ移動なしのアプローチにより、ソースデータへのリアルタイムアクセスを提供しながら、データの重複とストレージコストを大幅に削減できます。 使用すべきケース: オペレーショナル分析のためにソースシステムに直接クエリする必要がある場合 レイクハウス内のストレージスペースと関連コストを節約するためにデータを複製したくない場合 即時のデータ可用性とライブデータの一回限りの分析のために、クエリパフォーマンスとガバナンスの一部をトレードオフしてもよい場合 データを頻繁にクエリする必要がない場合 AWS でのレイクハウスのストレージレイヤーを理解する レイクハウスにデータを取り込む様々な方法を確認したところで、次の問題はデータの保存先です。以下の図のように、AWS ではデータレイク (Amazon S3 または Amazon S3 Tables ) またはデータウェアハウス ( Redshift Managed Storage ) にデータを保存してモダンなオープンレイクハウスを構築でき、ワークロード要件に基づいて柔軟性とパフォーマンスの両方を最適化できます。 モダンなレイクハウスは単一のストレージ技術ではなく、それらの戦略的な組み合わせです。データの保存場所と方法は、ダッシュボードの応答速度から ML モデルの効率まで幅広く影響します。ストレージの初期コストだけでなく、データ取得の長期コスト、ユーザーが求めるレイテンシー、単一の信頼できるソースを維持するためのガバナンスも考慮が必要です。このセクションでは、データレイクとデータウェアハウスのアーキテクチャパターンを掘り下げ、各ストレージパターンをいつ使用すべきかの明確なフレームワークを提供します。かつては競合するアーキテクチャと見なされていましたが、モダンでオープンなレイクハウスアプローチは両方を活用して単一の強力なデータプラットフォームを構築します。 汎用 S3 Amazon S3 の 汎用 S3 バケット は、オブジェクトの保存に使用される標準的な基本バケットタイプです。厳格な事前スキーマなしでネイティブ形式のデータを保存できる柔軟性を提供します。S3 バケットはストレージとコンピューティングを分離できるため、高度にスケーラブルな場所にデータを保存しながら、様々なクエリエンジンが独立してアクセス・処理できます。データの移動や複製なしに、ジョブに適したツールを選択できます。ストレージ容量のプロビジョニングや管理なしでペタバイト規模のデータを保存でき、 階層型ストレージクラス により、アクセス頻度の低いデータをより手頃なストレージに自動的に移動して大幅なコスト削減を実現します。 既存の Data Catalog はマネージドカタログとして機能します。AWS アカウント番号で識別されるため、既存の Data Catalog の移行は不要で、レイクハウスですでに利用可能であり、以下の図のように新しいデータのデフォルトカタログになります。 汎用 S3 上の基本的なデータレイクは、追記専用ワークロードに非常に効率的です。ただし、ファイルベースの性質上、従来のデータベースのトランザクション保証が欠けています。Apache Hudi、Delta Lake、Apache Iceberg などのオープンソースのトランザクショナルテーブルフォーマットを活用すると、この課題を解決できます。テーブルフォーマットによりマルチバージョン同時実行制御（MVCC）を実装でき、複数のリーダーとライターが競合なく同時に操作できます。スナップショット分離を提供するため、書き込み操作中でもリーダーはデータの一貫したビューを参照できます。以下の図は Apache Iceberg を使用した典型的なメダリオンアーキテクチャパターンを示しています。AWS で Apache Iceberg を使用してレイクハウスを構築する場合、Amazon S3 上のデータ保存には、セルフマネージド Iceberg を使用した汎用 S3 バケットと、フルマネージドの S3 Tables の 2 つの主要なアプローチから選択できます。それぞれに明確な利点があり、制御、パフォーマンス、運用負荷に対する具体的なニーズによって適切な選択が異なります。 セルフマネージド Iceberg を使用した汎用 S3 セルフマネージド Iceberg を使用した汎用 S3 バケットは、データと Iceberg メタデータファイルの両方を標準 S3 バケットに保存する従来のアプローチです。このオプションでは完全な制御を維持しますが、コンパクションやガベージコレクションなどの必須メンテナンスタスクを含む、Iceberg テーブルのライフサイクル全体を自分で管理する必要があります。 使用すべきケース: 最大限の制御: データライフサイクル全体を完全に制御できます。コンパクションのスケジュールや戦略の定義など、テーブルメンテナンスのあらゆる側面を微調整でき、特定の高パフォーマンスワークロードやコスト最適化に重要です。 柔軟性とカスタマイズ: 強力な社内データエンジニアリング専門知識を持ち、より幅広いオープンソースツールやカスタムスクリプトとの統合が必要な組織に最適です。 Amazon EMR や Apache Spark を使用してテーブル操作を管理できます。 初期コストの低さ: Amazon S3 ストレージ、API リクエスト、メンテナンス用コンピューティングリソースの料金のみ発生します。継続的な自動最適化が不要な小規模または低頻度のワークロードでは、よりコスト効率が高くなる可能性があります。 注意: クエリパフォーマンスは最適化戦略に完全に依存します。コンパクションの継続的なスケジュールジョブがないと、データの断片化に伴いパフォーマンスが低下する可能性があります。効率的なクエリを確保するために、コンパクションジョブを監視する必要があります。 S3 Tables S3 Tables は、分析ワークロードに最適化された S3 ストレージを提供し、大規模な表形式データを保存するための Apache Iceberg 互換性を備えています。S3 テーブルバケットとテーブルを Data Catalog と統合し、Lake Formation コンソールまたはサービス API で Lake Formation データロケーションとしてカタログを登録できます (以下の図の)。このカタログはフェデレーテッドレイクハウスカタログとして登録・マウントされます。 使用すべきケース: 運用の簡素化: S3 Tables はコンパクション、スナップショット管理、孤立ファイルのクリーンアップなどのテーブルメンテナンスタスクをバックグラウンドで自動的に処理します。カスタムメンテナンスジョブの構築・管理が不要になり、運用負荷を大幅に軽減できます。 自動最適化: S3 Tables はクエリパフォーマンスを向上させる組み込みの自動最適化を提供します。スモールファイル問題に対処するファイルコンパクションや、表形式データに特化したデータレイアウト最適化などのバックグラウンドプロセスが含まれます。ただし、自動化と柔軟性はトレードオフの関係にあります。コンパクション操作のタイミングや方法を制御できないため、特定のパフォーマンス要件を持つワークロードではクエリパフォーマンスにばらつきが生じる可能性があります。 データ活用への集中: S3 Tables はエンジニアリングの負荷を軽減し、データの消費、データガバナンス、価値創造に焦点を移します。 オープンテーブルフォーマットへの簡単な導入: Apache Iceberg の概念は初めてだが、データレイクでトランザクション機能を活用したいチームに適しています。 外部カタログ不要: 外部カタログを管理したくない小規模チームに適しています。 Redshift Managed Storage データレイクはすべてのデータの中央の信頼できるソースとして機能しますが、すべてのジョブに最適なデータストアではありません。最も要求の厳しいビジネスインテリジェンスとレポーティングワークロードでは、データレイクのオープンで柔軟な性質がパフォーマンスの予測不可能性をもたらす可能性があります。望ましいパフォーマンスを確保するために、以下の理由でデータレイクからデータウェアハウスへキュレーション済みデータのサブセットを移行することを検討してください: 高同時実行 BI とレポーティング: 数百のビジネスユーザーがライブダッシュボードで複雑なクエリを同時に実行する場合、データウェアハウスは予測可能なサブ秒のクエリレイテンシーで高同時実行ワークロードを処理するよう特別に最適化されています。 予測可能なパフォーマンス SLA: 財務レポートや日次売上分析など、保証された速度でデータを配信する必要がある重要なビジネスプロセスでは、データウェアハウスが一貫したパフォーマンスを提供します。 複雑な SQL ワークロード: データレイクは強力ですが、多数のジョインや大規模な集約を伴う非常に複雑なクエリでは苦戦する可能性があります。データウェアハウスは複雑なリレーショナルワークロードを効率的に実行するために構築されています。 AWS のレイクハウスアーキテクチャは Redshift Managed Storage (RMS) をサポートしています。RMS は、Amazon Redshift が提供するフルマネージドのストレージオプションです。RMS ストレージは、データウェアハウジングワークロード向けの組み込みクエリ最適化、 自動マテリアライズドビュー 、頻繁に実行されるワークロード向けの AI 駆動の最適化とスケーリング など、Amazon Redshift が提供する 自動テーブル最適化 をサポートしています。 フェデレーテッド RMS カタログ: 既存の Amazon Redshift データウェアハウスをレイクハウスにオンボード 既存の Amazon Redshift データウェアハウスでフェデレーテッドカタログを実装すると、データ移動を必要としないメタデータのみの統合が作成されます。このアプローチにより、既存のワークフローとの互換性を維持しながら、確立された Amazon Redshift への投資をモダンなオープンレイクハウスフレームワークに拡張できます。Amazon Redshift は階層的なデータ組織構造を使用しています: クラスターレベル : 名前空間から始まる データベースレベル : 複数のデータベースを含む スキーマレベル : データベース内のテーブルを整理する 既存の Amazon Redshift プロビジョンドまたはサーバーレスの名前空間を Data Catalog のフェデレーテッドカタログとして登録すると、この階層がレイクハウスのメタデータレイヤーに直接マッピングされます。AWS のレイクハウス実装は、基盤となるストレージメタデータを整理・マッピングする動的階層を使用して複数のカタログをサポートしています。 名前空間を登録すると、フェデレーテッドカタログは AWS リージョンとアカウント内のすべての Amazon Redshift データウェアハウスに自動的にマウントされます。登録プロセス中、Amazon Redshift はデータ共有に対応する外部データベースを内部的に作成します。エンドユーザーからはこの仕組みは完全に隠蔽されています。フェデレーテッドカタログを使用することで、データエコシステム全体にわたる即時の可視性とアクセシビリティを実現できます。 フェデレーテッドカタログの権限 は、同一アカウントとクロスアカウントアクセスの両方で Lake Formation によって管理できます。 フェデレーテッドカタログが特に効果を発揮するのは、 Amazon Athena 、 Amazon EMR 、オープンソース Spark などの外部 AWS エンジンから Amazon Redshift マネージドストレージにアクセスする場面です。Amazon Redshift は Amazon Redshift エンジンのみがネイティブに読み取れる独自仕様のブロックベースストレージを使用しているため、AWS はバックグラウンドでサービスマネージドの Amazon Redshift Serverless インスタンスを自動的にプロビジョニングします。このサービスマネージドインスタンスは、外部エンジンと Amazon Redshift マネージドストレージ間の変換レイヤーとして機能します。AWS は、登録されたフェデレーテッドカタログとサービスマネージドの Amazon Redshift Serverless インスタンス間に自動データ共有を確立し、安全で効率的なデータアクセスを実現します。AWS はデータ転送用のサービスマネージド Amazon S3 バケットもバックグラウンドで作成します。 Athena などの外部エンジンが Amazon Redshift フェデレーテッドカタログに対してクエリを送信すると、Lake Formation がリクエストサービスに一時的な認証情報を提供してクレデンシャルベンディングを処理します。クエリはサービスマネージドの Amazon Redshift Serverless を通じて実行され、自動的に確立されたデータ共有を通じてデータにアクセスし、結果を処理してサービスマネージドの Amazon S3 ステージングエリアにオフロードし、元のリクエストエンジンに結果を返します。 既存の Amazon Redshift ウェアハウスのフェデレーテッドカタログのコンピューティングコストを追跡するには、以下のタグを使用します。 aws:redshift-serverless:LakehouseManagedWorkgroup value: "True" 請求インサイトのために AWS 生成コスト配分タグを有効にするには、 有効化手順 に従ってください。 AWS Billing でリソースのコンピューティングコストも確認できます。 使用すべきケース: 既存の Amazon Redshift への投資: フェデレーテッドカタログは、既存の Amazon Redshift デプロイメントを持ち、移行なしで複数のサービス間でデータを活用したい組織向けに設計されています。 クロスサービスデータ共有: チームが既存の Amazon Redshift データウェアハウスのデータを異なるウェアハウス間で共有し、権限を一元管理できるように実装します。 エンタープライズ統合要件: 確立されたデータガバナンスとの統合が必要な組織に適しています。レイクハウス機能を追加しながら、現在のワークフローとの互換性を維持します。 インフラストラクチャの制御と料金: 予測可能なワークロードに対して既存のウェアハウスのコンピューティング容量を完全に制御できます。コンピューティング容量の最適化、オンデマンドとリザーブドキャパシティの料金の選択、パフォーマンスパラメータの微調整が可能です。一貫したワークロードに対してコストの予測可能性とパフォーマンス制御を提供します。 複数のカタログタイプを使用してレイクハウスアーキテクチャを実装する場合、パフォーマンスとコスト最適化の両方にとって適切なクエリエンジンの選択が重要です。本記事ではレイクハウスのストレージ基盤に焦点を当てていますが、Amazon Redshift データ操作を多用する重要なワークロードでは、可能な限り Amazon Redshift 内でクエリを実行するか、Spark を使用することを検討してください。複数の Amazon Redshift テーブルにまたがる複雑なジョインを外部エンジンで実行すると、エンジンが完全な述語のプッシュダウンをサポートしていない場合、コンピューティングコストが高くなる可能性があります。 その他のユースケース マルチウェアハウスアーキテクチャの構築 Amazon Redshift は データ共有 をサポートしており、ソースとターゲットの Amazon Redshift クラスター間でライブデータを共有できます。データ共有を使用すると、コピーの作成やデータの移動なしでライブデータを共有でき、ワークロード分離 (ハブアンドスポークアーキテクチャ) やクロスグループコラボレーション (データメッシュアーキテクチャ) などのユースケースが可能になります。レイクハウスアーキテクチャがない場合、ソースとターゲットの Amazon Redshift クラスター間に明示的なデータ共有を作成する必要があります。小規模なデプロイメントではデータ共有の管理は比較的簡単ですが、データメッシュアーキテクチャでは複雑になります。 レイクハウスアーキテクチャはこの課題に対応し、既存の Amazon Redshift ウェアハウスをフェデレーテッドカタログとして公開できます。フェデレーテッドカタログは、同一アカウントとリージョン内の他のコンシューマー Amazon Redshift ウェアハウスに外部データベースとして自動的にマウントされ、利用可能になります。データの単一コピーを維持しながら複数のデータウェアハウスからクエリでき、複数のデータ共有の作成と管理が不要になり、ワークロード分離でスケールできます。権限管理は Lake Formation を通じて一元化され、マルチウェアハウス環境全体のガバナンスが効率化されます。 パイプライン管理不要のペタバイト規模トランザクションデータの準リアルタイム分析: Zero-ETL 統合は、OLTP データソースから Amazon Redshift、汎用 S3 (セルフマネージド Iceberg)、または S3 Tables へトランザクションデータをシームレスにレプリケートします。ETL パイプラインの維持が不要になり、データアーキテクチャの可動部品と潜在的な障害ポイントが削減されます。ビジネスユーザーは、前回の ETL 実行からの古いデータではなく、新鮮な運用データをすぐに分析できます。 Amazon Redshift ウェアハウスにレプリケートできる OLTP データソースの一覧は「 Aurora zero-ETL integrations 」を参照してください。 既存の Amazon Redshift ウェアハウス、セルフマネージド Iceberg を使用した汎用 S3、S3 Tables にレプリケートできるその他のサポートされるデータソースについては「 Zero-ETL integrations 」を参照してください。 まとめ レイクハウスアーキテクチャは、データレイクとデータウェアハウスのどちらかを選ぶものではありません。両方のフレームワークが統合データアーキテクチャ内で共存し、異なる目的を果たす相互運用性のアプローチです。基本的なストレージパターンを理解し、効果的なカタログ戦略を実装し、ネイティブストレージ機能を活用することで、現在の分析ニーズと将来のイノベーションの両方をサポートする、スケーラブルで高パフォーマンスなデータアーキテクチャを構築できます。詳細は「 The lakehouse architecture of Amazon SageMaker 」を参照してください。 著者について Lakshmi Nair Lakshmi は、AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。業界横断で高度な分析システムの設計を専門としています。クラウドベースのデータプラットフォームの構築、リアルタイムストリーミング、ビッグデータ処理、堅牢なデータガバナンスの実現に注力しています。 Saman Irfan Saman は、ドイツのベルリンを拠点とする Amazon Web Services のシニアスペシャリストソリューションアーキテクトです。組織のデータアーキテクチャのモダナイゼーションとデータの潜在能力を最大限に引き出し、イノベーションとビジネス変革を推進することに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

本記事は 2026 年 1 月 26 日 に公開された「 Top 10 best practices for Amazon EMR Serverless 」を翻訳したものです。 Amazon EMR Serverless は Amazon EMR のデプロイオプションの 1 つで、 Apache Spark や Apache Hive などのオープンソースビッグデータ分析フレームワークを、クラスターやサーバーの設定・管理・スケーリングなしで実行できます。EMR Serverless は、データストレージ、ストリーミング、オーケストレーション、モニタリング、ガバナンスにわたる Amazon Web Services (AWS) サービスと統合し、サーバーレス分析ソリューションを実現します。 本記事では、EMR Serverless ワークロードのパフォーマンス、コスト、スケーラビリティを最適化するためのベストプラクティス 10 選を紹介します。EMR Serverless を使い始めたばかりの方も、既存の本番ワークロードを改善したい方も、効率的でコスト効率の高いデータ処理パイプラインの構築に役立つ内容です。以下の図は、EMR Serverless のエンドツーエンドアーキテクチャを示しており、分析パイプラインへの統合方法を表しています。 1. アプリケーションは一度定義して繰り返し使う EMR Serverless アプリケーション はクラスターテンプレートに相当し、ジョブ送信時にインスタンス化され、再作成せずに複数のジョブを処理できます。アプリケーションを再利用することで起動レイテンシーを削減し、運用管理を簡素化できます。 EMR on EC2 一時クラスターの一般的なワークフロー: EMR Serverless の一般的なワークフロー: アプリケーションは自己管理型のライフサイクルを備えており、必要なときに手動操作なしでリソースをプロビジョニングします。ジョブが送信されると自動的にキャパシティをプロビジョニングします。事前初期化キャパシティのないアプリケーションでは、ジョブ完了後すぐにリソースが解放されます。事前初期化キャパシティが設定されている場合、設定されたアイドルタイムアウト (デフォルト 15 分) を超えるとワーカーが停止します。このタイムアウトは、 CreateApplication または UpdateApplication API の AutoStopConfig でアプリケーションレベルで調整できます。たとえば、ジョブが 30 分ごとに実行される場合、アイドルタイムアウトを延長すると実行間の起動遅延を解消できます。 ほとんどのワークロードには、オンデマンドキャパシティが適しています。ジョブの要件に基づいてリソースを自動スケーリングし、アイドル時には課金されません。ETL ワークロード、バッチ処理ジョブ、最大限のジョブ回復力が必要なシナリオなど、一般的なユースケースに適したコスト効率の高いアプローチです。 即時起動が厳密に求められるワークロードには、オプションで 事前初期化キャパシティ を設定できます。事前初期化キャパシティは、数秒以内にジョブを実行できるドライバーとエグゼキューターのウォームプールを作成します。ただし、パフォーマンスが向上する分、コストは高くなります。事前初期化ワーカーはアプリケーションが停止状態になるまでアイドル中も継続的に課金されます。また、事前初期化キャパシティはジョブを単一のアベイラビリティゾーンに制限するため、回復力が低下します。 事前初期化キャパシティを検討すべきケース: 起動レイテンシーが許容できない、サブ秒の SLA 要件がある時間的制約の厳しいジョブ ユーザー体験が即時応答に依存するインタラクティブ分析 数分ごとに実行される高頻度の本番パイプライン それ以外のほとんどのケースでは、オンデマンドキャパシティがコスト、パフォーマンス、回復力のバランスに優れています。 リソースの最適化に加えて、ワークロード全体でのアプリケーションの整理方法も検討してください。本番ワークロードでは、ビジネスドメインやデータの機密レベルごとに別々のアプリケーションを使用しましょう。アプリケーションを分離することでガバナンスが向上し、重要なジョブと重要でないジョブ間のリソース競合を防げます。 2. AWS Graviton プロセッサ で価格性能比を向上 適切なプロセッサアーキテクチャの選択は、パフォーマンスとコストの両方に大きく影響します。 Graviton ARM ベースプロセッサは、x86_64 と比較して優れた価格性能比を実現します。 EMR Serverless は最新のインスタンス世代が利用可能になると自動的に更新されるため、追加設定なしで最新のハードウェア改善の恩恵を受けられます。 EMR Serverless で Graviton を使用するには、 CreateApplication でアプリケーション作成時に architecture パラメータで ARM64 を指定するか、既存のアプリケーションには UpdateApplication API を使用します: aws emr-serverless create-application \   --name my-spark-app \   -- SPARK \   --architecture ARM64 \   --release-label emr-7.12.0 Graviton 使用時の考慮事項: リソースの可用性 – 大規模ワークロードの場合、Graviton ワーカーのキャパシティプランニングについて AWS アカウントチームに相談することを検討してください。 互換性 – 一般的に使用される標準ライブラリの多くは Graviton (arm64) アーキテクチャと互換性がありますが、使用しているサードパーティパッケージやライブラリの互換性を検証する必要があります。 移行計画 – Graviton の導入には戦略的なアプローチを取りましょう。新しいアプリケーションはデフォルトで ARM64 アーキテクチャで構築し、既存のワークロードは中断を最小限に抑える段階的な移行計画で 移行 します。段階的に移行することで、信頼性を損なわずにコストとパフォーマンスを最適化できます。 ベンチマークの実施 – 正確な価格性能比はワークロードによって異なります。ワークロード固有の結果を把握するために、独自のベンチマークを実施することを推奨します。詳細は「 Achieve up to 27% better price-performance for Spark workloads with AWS Graviton2 on Amazon EMR Serverless 」を参照してください。 3. デフォルトを活用し、必要に応じてワーカーを適正化 ワーカー はワークロードのタスクを実行するために使用されます。EMR Serverless のデフォルト設定はほとんどのユースケースに最適化されていますが、処理時間の改善やコスト効率の最適化のためにワーカーのサイズを適正化する必要がある場合があります。EMR Serverless ジョブを送信する際は、メモリサイズ (GB) やコア数などのワーカー設定を Spark プロパティで定義することを推奨します。 EMR Serverless のデフォルトワーカーサイズは 4 vCPU、16 GB メモリ、20 GB ディスクです。一般的にほとんどのジョブにバランスの取れた構成ですが、パフォーマンス要件に応じてサイズを調整することもできます。事前初期化ワーカーに特定のサイズを設定している場合でも、ジョブ送信時に必ず Spark プロパティを設定してください。事前初期化キャパシティを超えてスケールする際に、デフォルトプロパティではなく指定したワーカーサイズが使用されます。Spark ワークロードの適正化では、ジョブの vCPU:メモリ比率が重要です。エグゼキューターの仮想 CPU コアあたりに割り当てるメモリ量は、この比率で決まります。Spark エグゼキューターはデータを効果的に処理するために CPU とメモリの両方が必要で、最適な比率はワークロードの特性によって異なります。 まずは以下のガイダンスを参考にし、ワークロード固有の要件に基づいて設定を調整してください。 エグゼキューター設定 以下の表は、一般的なワークロードパターンに基づく推奨エグゼキューター設定です: ワークロードタイプ 比率 CPU メモリ 設定 コンピューティング集約型 1:2 16 vCPU 32 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=32G 汎用 1:4 16 vCPU 64 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=64G メモリ集約型 1:8 16 vCPU 108 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=108G ドライバー設定 以下の表は、一般的なワークロードパターンに基づく推奨ドライバー設定です: ワークロードタイプ 比率 CPU メモリ 設定 汎用 1:4 4 vCPU 16 GB spark.emr-serverless.driver.cores=4spark.emr-serverless.driver.memory=16G Apache Iceberg ワークロード 1:8 (メタデータルックアップ用の大きなドライバー) 8 vCPU 60 GB spark.emr-serverless.driver.cores=8spark.emr-serverless.driver.memory=60G 設定をさらにモニタリングおよびチューニングするには、 Amazon CloudWatch ジョブワーカーレベルメトリクス でワークロードのリソース消費を監視し、ボトルネックを特定します。CPU 使用率、メモリ使用量、ディスク使用率のメトリクスを追跡し、以下の表を参考に設定を調整してください。 観測されたメトリクス ワークロードタイプ 推奨アクション 1 高メモリ (>90%)、低 CPU (<50%) メモリバウンドワークロード vCPU:メモリ比率を増加 2 高 CPU (>85%)、低メモリ (<60%) CPU バウンドワークロード vCPU 数を増加し、1:4 比率を維持 (例: 8 vCPU 使用時は 32 GB メモリ) 3 高ストレージ I/O、通常の CPU/メモリ、長いシャッフル操作 シャッフル集約型 サーバーレスストレージ または シャッフル最適化ディスク を有効化 4 全メトリクスで低使用率 過剰プロビジョニング ワーカーサイズまたは数を削減 5 一貫して高使用率 (>90%) 過少プロビジョニング ワーカー仕様をスケールアップ 6 頻繁な GC 一時停止** メモリ圧迫 メモリオーバーヘッドを増加 (10〜15%) **頻繁なガベージコレクション (GC) の一時停止は、Spark UI の Executors タブで確認できます。GC time 列があり、一般的にタスク時間の 10% 未満であるべきです。また、ドライバーログに GC (Allocation Failure)] メッセージが頻繁に含まれている場合もあります。 4. T シャツサイジングでスケーリング境界を制御 デフォルトでは、EMR Serverless は 動的リソース割り当て (DRA) を使用し、ワークロードの需要に基づいてリソースを自動スケーリングします。EMR Serverless はジョブのメトリクスを継続的に評価してコストと速度を最適化するため、必要なワーカー数を見積もる必要がありません。 コスト最適化と予測可能なパフォーマンスのために、以下のいずれかのアプローチでスケーリングの上限を設定できます: ジョブレベルで spark.dynamicAllocation.maxExecutors パラメータを設定 アプリケーションレベルの最大キャパシティ を設定 各ジョブの spark.dynamicAllocation.maxExecutors を個別に細かく調整するのではなく、ワークロードプロファイルを表す T シャツサイズとして設定を考えることができます: ワークロードサイズ ユースケース spark.dynamicAllocation.maxExecutors Small 探索的クエリ、開発 50 Medium 定期的な ETL ジョブ、レポート 200 Large 複雑な変換、大規模処理 500 この T シャツサイジングアプローチにより、キャパシティプランニングが簡素化され、個々のジョブを最適化するのではなく、ワークロードカテゴリに基づいてパフォーマンスとコスト効率のバランスを取れます。 EMR Serverless リリース 6.10 以降では、 spark.dynamicAllocation.maxExecutors のデフォルト値は無制限ですが、それ以前のリリースでは 100 です。 EMR Serverless はジョブの各ステージで必要なワークロードと並列性に基づいて、ワーカーを自動的にスケールアップまたはスケールダウンします。ジョブのメトリクスを継続的に評価してコストと速度を最適化するため、ワーカー数を見積もる必要がありません。 ただし、予測可能なワークロードの場合、エグゼキューター数を静的に設定したい場合があります。その場合は DRA を無効にしてエグゼキューター数を手動で指定します: spark.dynamicAllocation.enabled=false spark.executor.instances=10 5. EMR Serverless ジョブに適切なストレージをプロビジョニング ストレージオプションを理解し、適切にサイジングすることで、ジョブの失敗を防ぎ、実行時間を最適化できます。EMR Serverless は、ジョブ実行中の中間データを処理するストレージオプションが複数あります。選択するストレージオプションは EMR リリースとユースケースによって異なります。EMR Serverless で利用可能なストレージオプションは以下のとおりです: ストレージタイプ EMR リリース ディスクサイズ範囲 ユースケース メリット サーバーレスストレージ (推奨) 7.12+ N/A (自動スケーリング) ほとんどの Spark ワークロード、特にデータ集約型ワークロード ストレージコストなし 自動スケーリング ディスク障害の削減 最大 20% のコスト削減 標準ディスク 7.11 以前 ワーカーあたり 20〜200 GB 10 TB 未満のデータセットを処理する小〜中規模ワークロード シンプルな設定 デフォルト 20 GB でほとんどのワークロードに対応 最適なスループットには最大 200 GB シャッフル最適化ディスク 7.1.0+ ワーカーあたり 20〜2,000 GB マルチ TB を処理する大規模 ETL ワークロード 高 IOPS とスループット ワーカーあたり最大 2 TB のキャパシティ ストレージ設定をワークロードの特性に合わせることで、EMR Serverless ジョブを大規模でも効率的かつ安定的に実行できます。 6. マルチ AZ がデフォルトで組み込みの回復力を提供 EMR Serverless アプリケーションは、事前初期化キャパシティが有効でない場合、最初からマルチ AZ です。フェイルオーバーが組み込まれているため、手動操作なしで AZ 障害に対応できます。単一のジョブは単一のアベイラビリティゾーン内で動作し、クロス AZ データ転送コストを防ぎます。後続のジョブは複数の AZ に適切に分散されます。EMR Serverless が AZ の障害を検出すると、新しいジョブを正常な AZ に送信し、AZ 障害にもかかわらずワークロードの実行を継続できます。 EMR Serverless のマルチ AZ 機能を最大限に活用するには、以下を確認してください: 複数のアベイラビリティゾーンにまたがるサブネットを選択して VPC へのネットワーク接続 を設定 アプリケーションを単一の AZ に制限する事前初期化キャパシティを避ける ワーカーのスケーリングをサポートするために各サブネットに十分な IP アドレスがあることを確認 マルチ AZ に加えて、Amazon EMR 7.1 以降では ジョブの回復力 を有効にでき、エラーが発生した場合にジョブを自動的にリトライできます。複数のアベイラビリティゾーンが設定されている場合、別の AZ でもリトライされます。この機能は バッチ ジョブと ストリーミング ジョブの両方で有効にできますが、リトライ動作は両者で異なります。 最大リトライ回数を定義するリトライポリシーを指定してジョブの回復力を設定します。バッチジョブのデフォルトは自動リトライなし (maxAttempts=1) です。ストリーミングジョブでは、EMR Serverless は無制限にリトライし、1 時間以内に 5 回失敗するとリトライを停止するスラッシング防止機能が組み込まれています。このしきい値は 1〜10 回の間で設定できます。詳細は「 Job resiliency 」を参照してください。 ジョブをキャンセルする必要がある場合、デフォルトの即時終了ではなく、ジョブをクリーンにシャットダウンするための 猶予期間 を指定できます。カスタムクリーンアップアクションを実行する必要がある場合は、カスタムシャットダウンフックも含められます。 マルチ AZ サポート、自動ジョブリトライ、グレースフルシャットダウン期間を組み合わせることで、中断に耐え、手動操作なしでデータの整合性を維持できる EMR Serverless ワークロードを構築できます。 7. VPC 統合でセキュリティと接続性を拡張 デフォルトでは、EMR Serverless は Amazon Simple Storage Service (Amazon S3)、 AWS Glue 、 Amazon CloudWatch Logs 、 AWS Key Management Service (AWS KMS)、 AWS Security Token Service (AWS STS)、 Amazon DynamoDB 、 AWS Secrets Manager などの AWS サービスにアクセスできます。 Amazon Redshift や Amazon Relational Database Service (Amazon RDS) など VPC 内のデータストアに接続するには、EMR Serverless アプリケーションの VPC アクセスを設定する必要があります。 EMR Serverless アプリケーションの VPC アクセスを設定する際は、最適なパフォーマンスとコスト効率のために以下の考慮事項に留意してください: 十分な IP アドレスを計画 – 各ワーカーはサブネット内で 1 つの IP アドレスを使用します。ジョブのスケールアウト時に起動されるワーカーも含まれます。IP アドレスが不足すると、ジョブがスケールできず、ジョブの失敗につながる可能性があります。最適なパフォーマンスのために サブネットプランニングのベストプラクティス に従っていることを確認してください。 プライベートサブネットのアプリケーションには Amazon S3 用ゲートウェイエンドポイント を設定 – VPC エンドポイントなしでプライベートサブネットで EMR Serverless を実行すると、Amazon S3 トラフィックが NAT ゲートウェイ経由でルーティングされ、追加のデータ転送料金が発生します。S3 用 VPC エンドポイントにより、トラフィックを VPC 内に保持し、コストを削減して Amazon S3 操作のパフォーマンスを向上できます。 ネットワークインターフェースの AWS Config コストを管理 – EMR Serverless は各ワーカーに対して AWS Config にエラスティックネットワークインターフェースレコードを生成し、ワークロードのスケールに伴いコストが蓄積される可能性があります。EMR Serverless ネットワークインターフェースの AWS Config 追跡が不要な場合は、リソースベースの除外やタグ付け戦略を使用してフィルタリングし、他のリソースの AWS Config カバレッジは維持することを検討してください。 詳細は「 Configuring VPC access for EMR Serverless applications 」を参照してください。 8. ジョブ送信と依存関係管理を簡素化 EMR Serverless は StartJobRun API による柔軟なジョブ送信をサポートしており、完全な spark-submit 構文を受け付けます。ランタイム環境の設定には、 spark.emr-serverless.driverEnv と spark.executorEnv プレフィックスを使用して、ドライバーとエグゼキュータープロセスの環境変数を設定します。機密設定やランタイム固有の設定を渡す際に特に便利です。 Python アプリケーションの場合、venv を作成し、tar.gz アーカイブとしてパッケージ化するか、 spark.archives を使用して Amazon S3 にアップロードし、適切な PYSPARK_PYTHON 環境変数を設定して、仮想環境で依存関係をパッケージ化すると、ドライバーとエグゼキューターワーカー全体で Python の依存関係を利用できます。 高負荷時の制御を向上させるには、 ジョブの同時実行とキューイング (EMR 7.0.0+ で利用可能) を有効にして、同時に実行できるジョブ数を制限します。この機能により、同時実行制限を超えて送信されたジョブは、リソースが利用可能になるまでキューに入れられます。 ジョブの同時実行とキュー設定は、 CreateApplication または UpdateApplication API の SchedulerConfiguration プロパティで設定できます。 --scheduler-configuration '{"maxConcurrentRuns": 5, "queueTimeoutMinutes": 30}' 9. EMR Serverless の設定で制限を適用 EMR Serverless はワークロードの需要に基づいてリソースを自動スケーリングし、ほとんどのユースケースで Spark 設定のチューニングなしで機能する最適化されたデフォルトが用意されています。コスト管理のために、予算とパフォーマンス要件に合ったリソース制限を設定できます。高度なユースケースでは、リソース消費を細かく調整し、クラスターベースのデプロイメントと同等の効率を実現する設定オプションも提供しています。制限を適切に設定することで、パフォーマンスとコスト効率のバランスを取れます。 制限タイプ 目的 設定方法 ジョブレベル 個々のジョブのリソースを制御 spark.dynamicAllocation.maxExecutors または spark.executor.instances アプリケーションレベル アプリケーションまたはビジネスドメインごとのリソースを制限 アプリケーション作成時または更新時に最大キャパシティを設定 アカウントレベル 全アプリケーションにわたる異常なリソーススパイクを防止 自動調整可能なサービスクォータ「 Max concurrent vCPUs per account 」。 Service Quotas コンソール から引き上げをリクエスト これら 3 つのレイヤーの制限が連携して、異なるスコープで柔軟にリソースを管理できます。ほとんどのユースケースでは、T シャツサイジングアプローチによるジョブレベルの制限設定で十分であり、アプリケーションレベルとアカウントレベルの制限はコスト管理の追加的なガードレールになります。 10. CloudWatch、Prometheus、Grafana でモニタリング EMR Serverless ワークロードのモニタリングにより、デバッグ、コスト最適化、パフォーマンス追跡が容易になります。EMR Serverless は連携する 3 つのモニタリング階層があります: Amazon CloudWatch、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana です。 Amazon CloudWatch – CloudWatch 統合 はデフォルトで有効になっており、AWS/EMRServerless 名前空間にメトリクスを発行します。EMR Serverless はアプリケーションレベル、ジョブ、ワーカータイプ、キャパシティ割り当てタイプレベルで毎分 CloudWatch にメトリクスを送信します。CloudWatch を使用して、ワークロードの可観測性を高める ダッシュボード を設定したり、ジョブの失敗、スケーリングの異常、SLA 違反に対する アラーム を設定できます。CloudWatch と EMR Serverless を使用することで、ユーザーに影響が出る前に問題を検知できます。 Amazon Managed Service for Prometheus – EMR Serverless リリース 7.1+ では、Prometheus を有効にして詳細な Spark エンジンメトリクス を Amazon Managed Service for Prometheus にプッシュでき、メモリ使用量、シャッフルボリューム、GC 圧力などエグゼキューターレベルで可視化できます。メモリ制約のあるエグゼキューターの特定、シャッフルが多いステージの検出、データスキューの発見に活用できます。 Amazon Managed Grafana – Grafana は CloudWatch と Prometheus の両方のデータソースに接続し、可観測性と相関分析を統合した単一画面として利用できます。3 つの階層を組み合わせることで、インフラストラクチャの問題とアプリケーションレベルのパフォーマンス問題を関連付けられます。 追跡すべき主要メトリクス: ジョブの完了時間と成功率 ワーカーの使用率とスケーリングイベント シャッフルの読み取り/書き込みボリューム メモリ使用パターン 詳細は「 Monitor Amazon EMR Serverless workers in near real time using Amazon CloudWatch 」を参照してください。 まとめ 本記事では、パフォーマンスの最適化、コスト管理、大規模での安定した運用を実現するための Amazon EMR Serverless のベストプラクティス 10 選を紹介しました。アプリケーション設計、ワークロードの適正化、アーキテクチャの選択に注力することで、効率的で回復力のあるデータ処理パイプラインを構築できます。 詳細は「 Getting started with EMR Serverless 」ガイドを参照してください。 著者について Karthik Prabhakar Karthik は、Amazon Web Services (AWS) の Amazon EMR データ処理エンジンアーキテクトです。分散システムアーキテクチャとクエリ最適化を専門とし、大規模データ処理ワークロードにおける複雑なパフォーマンス課題の解決をお客様と共に取り組んでいます。エンジン内部、コスト最適化戦略、ペタバイト規模の分析を効率的に実行するためのアーキテクチャパターンに注力しています。 Neil Mukerje Neil は、Amazon Web Services のプリンシパルプロダクトマネージャーです。 Amber Runnels Amber は、Amazon Web Services (AWS) のシニアアナリティクススペシャリストソリューションアーキテクトで、ビッグデータと分散システムを専門としています。AWS のデータサービスでワークロードを最適化し、スケーラブルで高パフォーマンス、コスト効率の高いアーキテクチャの実現をお客様に支援しています。 Parul Saxena Parul は、Amazon Web Services (AWS) のシニアビッグデータスペシャリストソリューションアーキテクトです。高度に最適化されたスケーラブルでセキュアなソリューションの構築をお客様やパートナーに支援しています。Amazon EMR、Amazon Athena、AWS Lake Formation を専門とし、複雑なビッグデータワークロードのアーキテクチャガイダンスや、組織のアーキテクチャモダナイゼーションと分析ワークロードの AWS への移行を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。