みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 5月15日 (木) に「 GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 」というイベントが開催されます。このイベントでは、GenAIOps を実現するための重要な要素である生成 AI オブザーバビリティについて、評価 (evaluation) が中心となるという Eval-Centric AI の考え方の解説とともに、Langfuse と Amazon Bedrock を題材にしたハンズオンワークショップを提供します。昨今の生成 AI 切っても切り離せない GenAIOps に取り組まれる方、興味ある方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年5月5日週の主要なアップデート 5/5(月) Amazon ECS introduces 1-click rollbacks for service deployments Amazon Elastic Container Service（Amazon ECS）が、失敗したデプロイメントを簡単に元の安全な状態に戻せる新機能を発表しました。この機能では、 デプロイメントサーキットブレーカー と CloudWatch アラームを使用して、ECSサービスのローリングアップデートに対する自動障害検出と修復を構成できます。これまでは、特定の障害検出メカニズムで検出されないデプロイメント失敗の場合、手動でロールバックトリガーの操作が必要でした。新しい stopDeployment APIを使用することで、ECS が自動的に最後の安定状態にサービスをロールバックします。この機能はすべての AWS リージョンでAWS Management Console、API、SDK、CLIから利用可能です。 Amazon SES now supports IPv6 when calling SES outbound endpoints Amazon Simple Email Service（SES）が送信エンドポイントへの IPv6 接続をサポートし、AWS SDK や CLI を使用する際に IPv4 または IPv6 を選択できるようになりました。これまでは SES の送信エンドポイントへの接続は IPv4 アドレスのみでしたが、環境変数やコマンドライン引数を使ってデュアルスタック接続の設定が可能になり、IPv6 通信への移行が容易になります。 5/6(火) Amazon EBS announces Provisioned Rate for Volume Initialization Amazon Elastic Block Store（Amazon EBS）が、スナップショットからボリュームを作成する際の初期化速度を指定できる「プロビジョンドレート」機能の一般提供を開始しました。この機能により、多数の EC2 インスタンスを同時に起動する場合でも、ボリュームが予測可能な時間内に十分なパフォーマンスを発揮できるようになります。スナップショットからの新規ボリューム作成、AMI からのインスタンス起動、ルートボリューム交換などのシナリオで利用可能で、すべての商用 AWS リージョンで提供されています。なお、プロビジョンドレートを指定する場合は追加料金が発生します。詳細は こちら をご確認ください。 Amazon SageMaker adds support for three new data sources Amazon SageMaker は、Oracle、Amazon DocumentDB、および Microsoft SQL Server データベースへの直接接続をサポートするようになり、Amazon SageMaker Lakehouse で利用可能なデータ統合機能が拡張されました。この機能強化により、お客様はこれらのデータベースからシームレスにデータにアクセスして、ETL フローを構築することができます。 Amazon CloudWatch Network Monitoring adds multi-account support for flow monitors Amazon CloudWatch Network Monitoring で、Flow Monitor を使用して、複数のアカウントにまたがる AWS ワークロードのネットワークパフォーマンスを監視できるようになりました。マルチアカウントサポートにより、ネットワーク管理者は監視が必要なリソースを所有するすべてのアカウントで Flow Monitor を有効にすることができます。そうすることで、複数のアカウントにまたがるワークロードのネットワークパスの可視性が得られます。また、複数のアカウントにまたがる Flow のネットワークパフォーマンスメトリクスを統合的に表示することもできます。 5/7(水) Amazon EC2 R7g instances are now available in additional AWS regions Amazon Elastic Compute Cloud（Amazon EC2）R7g インスタンスが大阪リージョンを含む、６リージョンで新たに利用可能となりました。R7gインスタンス は AWS Graviton2 プロセッサと比較して最大 25% 優れたコンピューティング性能を提供する AWS Graviton3 プロセッサを搭載しています。同等のEC2インスタンスと比較して、同じ性能で最大 60% 少ないエネルギーを使用し、クラウド利用時の環境負荷をより抑えることができます。 Amazon MSK enables seamless certificate renewals on MSK Provisioned clusters Amazon Managed Streaming for Apache Kafka（Amazon MSK）は、MSK プロビジョンドクラスターのすべてにおいて、中断のない証明書の更新を提供するようになりました。Amazon MSK で使用される暗号化証明書は 13ヶ月ごとに更新が必要です。この機能のリリースにより、Amazon MSK プロビジョンドクラスターでの証明書更新は、クライアント接続を中断することなくシームレスに行われるようになりました。 5/8(木) Amazon SQS now supports FIPS 140-3 enabled interface VPC endpoint Amazon SQS は、連邦情報処理標準（FIPS）140-3 プログラムの下で検証された VPC エンドポイントをサポートするようになりました。FIPS 140-3 検証済みの暗号化モジュールを使用した安全な接続を必要とする規制対象のワークロードに対して、AWS PrivateLink と Amazon SQS を簡単に使用できるようになりました。 Amazon RDS for PostgreSQL supports minor versions 17.5, 16.9, 15.13, 14.18, and 13.21 Amazon Relational Database Service (RDS) for PostgreSQL で、最新のマイナーバージョン 17.5、16.9、15.13、14.18、13.21 がサポートされるようになりました。このリリースには、pg_repack 1.5.1、pg_logical 2.4.5などの PostgreSQL 拡張機能の更新も含まれています。 Amazon SageMaker AI enhances Amazon Q Developer with custom code suggestions and workspace context Amazon SageMaker AI Jupyter Lab における Amazon Q Developer の重要な機能強化を発表しました。この強化には、プライベートコードリポジトリに基づくコード提案のカスタマイズと、改善されたコード支援のためにワークスペース全体のコンテキストを含める機能が含まれています。これらの新機能により、組織は独自のコードを活用し、コード提案の関連性を向上させ、最終的に Jupyter Lab 環境内での開発者の生産性とコード品質を向上させることが可能になります。 Amazon Aurora PostgreSQL Limitless Database now supports PostgreSQL 16.8 Amazon Aurora PostgreSQL Limitless Database が PostgreSQL 互換性 バージョン 16.8 が利用可能になりました。このリリースには、 PostgreSQLコミュニティによる製品の改善とバグ修正 に加え、ltree 拡張機能、btree_gist 拡張機能のサポート、クエリパフォーマンスの向上などの Aurora Limitless 固有の追加機能が含まれています。 5/9(金) Amazon SageMaker HyperPod now integrates with Amazon EventBridge to deliver status change events Amazon SageMaker HyperPodがAmazon EventBridgeと統合され、クラスターのステータス変更についてほぼリアルタイムの通知を受け取ることが可能になりました。SageMaker HyperPodは、EventBridge を通じて2種類の通知を提供します。1つ目は、HyperPod クラスターが InService や Failed などの状態間で遷移する際に通知するクラスターステータス変更イベント、2つ目は、ノードの健全性ステータス（健全/不健全など）が変更された場合や、障害からの回復中に自動的に置き換えられた場合に通知するノード健全性イベントです。これらのイベントが発生した際に自動アクションをトリガーする簡単な EventBridge ルールを作成することもできます。 Amazon VPC Reachability Analyzer now supports resource exclusion Amazon VPC Reachability Analyzer が、送信元とあて先間の到達性分析時にネットワークリソースを除外する機能をサポートするようになり、到達性分析をより柔軟に実行できるようになりました。例えば、インターネットゲートウェイからElastic Network Interface（ENI）への、ネットワークファイアウォールによる検査を通過しないパスを特定したい場合、リソース除外でNetwork Firewallを指定して到達性分析を実行できます。分析の結果、到達可能なパスが見つかった場合、ネットワーク内に代替パスが存在することがわかり、必要な対策を講じることができます。 暑くなったり、寒くなったりと不安定な気候が続いていますので、体調管理に気をつけてお過ごしください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は、2025/5/9 に公開された Accelerate lightweight analytics using PyIceberg with AWS Lambda and an AWS Glue Iceberg REST endpoint を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 データインサイトに基づき決定を行う現代の組織にとって、効果的なデータ管理は、高度な分析と効率的な機械学習の利用を実現するための重要な要素です。データ利用のユースケースがより複雑になるにつれ、データエンジニアリングチームには、複数のデータソースやアプリケーション全体でのバージョン管理、増加するデータ量、スキーマ変更に対処するための高度なツールが必要になります。 Apache Iceberg は、データレイクで人気の選択肢となっています。ACID (原子性、一貫性、独立性、永続性) トランザクション、スキーマ進化、タイムトラベル機能を提供します。Iceberg テーブルは、Apache Spark や Trino などの様々な分散データ処理フレームワークからアクセスできるため、多様なデータ処理のニーズに対して柔軟なソリューションとなります。そのような Iceberg を扱うためのツールの中で、 PyIceberg は分散コンピューティングリソースを必要とせずに、Python スクリプト上でテーブルのアクセスと管理を可能にします。 この投稿では、 AWS Glue Data Catalog と AWS Lambda と統合された PyIceberg が、直感的な Python インターフェースを通じて Iceberg の強力な機能を活用するための軽量なアプローチを提供する方法を示します。この統合により、チームはほとんどセットアップやインフラストラクチャの依存関係の設定を行わずとも Iceberg テーブルの操作や利用を開始できることを説明します。 PyIceberg の主要機能と利点 PyIceberg の主な利点の 1 つは、軽量であることです。分散コンピューティングフレームワークを必要とせず、チームは Python アプリケーションから直接テーブル操作を実行できるため、学習曲線が小さく、小規模から中規模のデータ探索と分析に適しています。さらに、PyIceberg は Pandas や Polars などの Python データ分析ライブラリと統合されているため、データユーザーは既存のスキルとワークフローを活用できます。 PyIceberg を Data Catalog と Amazon Simple Storage Service (Amazon S3) で使用すると、データチームはテーブルを完全にサーバーレスな環境で利用および管理できます。つまり、データチームはインフラストラクチャの管理ではなく、分析と洞察に集中することができます。 さらに、PyIceberg を通じて管理される Iceberg テーブルは、AWS のデータ分析サービスと互換性があります。PyIceberg は単⼀ノードで動作するため、⼤量のデータを扱う場合は性能に制限がありますが、 Amazon Athena や AWS Glue などのサービスを使えば、同じテーブルをより大規模に効率的に処理できます。これにより、チームは PyIceberg を使って迅速な開発とテストを行い、その後、データ管理アプローチの一貫性を維持しながら、より大規模な処理エンジンを使った本番ワークロードにシームレスに移行できます。 代表的なユースケース 次のようなシナリオでは、PyIceberg が特に役立ちます: データサイエンスの実験と特徴量エンジニアリング – データサイエンスでは、信頼できる効率的な分析とモデルを維持するために、実験の再現性が重要です。しかし、組織のデータが継続的に更新されるため、重要なビジネスイベント、モデル学習、一貫した参照のためのデータスナップショットを管理することが難しくなります。データサイエンティストは、タイムトラベル機能を使ってデータの過去のスナップショットを照会し、 タグ付け機能 を使って重要なバージョンを記録できます。PyIceberg を使えば、Pandas などの馴染みのあるツールを使って Python 環境でこれらの利点を得られます。Iceberg の ACID 特性のおかげで、テーブルが積極的に更新されている場合でも整合性を担保したデータアクセスが可能になります。 AWS Lambda によるサーバーレスデータ処理 – 組織は多くの場合、複雑なインフラストラクチャを管理せずに、データを効率的に処理し、分析テーブルを維持する必要があります。PyIceberg と Lambda を使えば、チームはサーバーレスな Lamnba 関数を使ってイベント駆動のデータ処理やスケジュールされたテーブル更新を構築できます。PyIceberg の軽量な性質は、サーバーレス環境に適しており、データ検証、変換、取り込みなどのシンプルなデータ処理タスクを可能にします。これらのテーブルは、さまざまな AWS サービスを通じて更新と分析の両方にアクセスできるため、チームはサーバーやクラスターを管理せずに効率的なデータパイプラインを構築できます。 PyIceberg を使用したイベント駆動のデータ取り込みと分析 このセクションでは、 NYC yellow taxi trip data を使用して、PyIceberg によるデータ処理と分析の実践的な例を探ります。リアルタイムのタクシー走行記録の処理をシミュレートするために、Lambda を使用してサンプルデータを Iceberg テーブルに挿入します。この例では、効率的なデータ取り込みと柔軟な分析機能を組み合わせることで、ワークフローをより合理的なものにする方法を示します。 チームが次のような複数の要件対応する必要がある場面を想像してください: データ処理ソリューションは、中規模のデータセットを処理するケースで分散コンピューティングクラスターの管理の複雑さを避けるため、コストパフォーマンスが良く、メンテナンス性が高い必要があります。 アナリストは、Python のツールを使って柔軟なクエリと探索を行えるようにする必要があります。例えば、過去のスナップショットと現在のデータを比較して、時間の経過に伴うトレンドを分析する必要があるかもしれません。 ソリューションは、将来的により拡張性の高いものにする能力を持つ必要があります。 これらの要件に対処するため、PyIceberg で動作する Lambda によるデータ処理と Jupyter ノートブックによる分析を組み合わせたソリューションを実装します。このアプローチにより、データの整合性を維持しながら柔軟な分析ワークフローを可能にする、軽量でありながら堅牢なアーキテクチャが実現されます。ウォークスルーの最後では、Athena を使用してこのデータを照会し、複数の Iceberg 対応ツールとの互換性を示すとともに、このアーキテクチャのスケール性を示します。 大まかな手順は以下の通りです: Lambda を使用して、 AWS Glue Iceberg REST エンドポイント 経由で PyIceberg を利用し、サンプルの NYC yellow taxi trip data を Amazon S3 上の Iceberg テーブルに書き込みます。実際のシナリオでは、この Lambda 関数は Amazon Simple Queue Service (Amazon SQS) などのキューイングコンポーネントからのイベントによってトリガーされます。詳細は、 Lambda と Amazon SQS の併用 を参照してください。 Jupyter ノートブックで AWS Glue Iceberg REST エンドポイントを経由して PyIceberg を使用し、テーブルデータを分析します。 Athena を使用してデータをクエリし、Iceberg の柔軟性を実証します。 次の図はアーキテクチャを示しています。 このアーキテクチャを実装する際に重要になる点は、Lambda 関数がイベントによってトリガーされると、複数の同時実行が発生する可能性があることです。この同時実行により、Iceberg テーブルへの書き込み時にトランザクション競合が発生する可能性があります。これを処理するには、適切な再試行メカニズムを実装し、トランザクション分離レベルを慎重に管理する必要があります。Amazon SQS をイベントソースとして使用する場合は、 SQS イベントソースの最大同時実行設定 を使って同時実行を制御できます。 前提条件 このユースケースには、次の前提条件が必要です。 Lambda、AWS Glue、Amazon S3、Athena、および AWS CloudFormation へのアクセスを提供するアクティブな AWS アカウント。 CloudFormation スタックを作成およびデプロイする権限。詳細については、 自己管理権限を使用した CloudFormation StackSets の作成 を参照してください。 AWS CloudShell とその機能に対する完全なアクセス権を持つユーザー。詳細については、 AWS CloudShell の概要 を参照してください。 AWS CloudFormation によるリソースのセットアップ 次の CloudFormation テンプレートを使用して、以下のリソースをセットアップできます: Iceberg テーブルのメタデータとデータファイルを格納する S3 バケット Amazon Elastic Container Registry (Amazon ECR) のリポジトリ (Lambda 関数のコンテナイメージを格納) テーブルを格納するデータカタログデータベース Amazon SageMaker AI の ノートブックインスタンス (Jupyter ノートブック環境用) Lambda 関数と SageMaker AI ノートブックインスタンス用の AWS Identity and Access Management (IAM) ロール 次の手順に従ってリソースをデプロイしてください。 Launch stack を選択します。 スタックの パラメータ では、データベース名として　 pyiceberg_lambda_blog_database がデフォルトで設定されています。デフォルト値を変更することもできます。データベース名を変更した場合は、以降のすべてのステップで pyiceberg_lambda_blog_database を選択した名前に置き換えることを忘れないでください。次に、 次へ を選択します。 次へ を選択します。 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します を選択します。 送信 を選択します。 Lambda 関数の構築と実行 PyIceberg を使って着信レコードを処理する Lambda 関数を構築しましょう。この関数は、Data Catalog の pyiceberg_lambda_blog_database データベース内に nyc_yellow_table という Iceberg テーブルが存在しない場合に新規でテーブルを作成します。次に、サンプルの NYC yellow taxi trip data を生成して、レコードをシミュレートし、 nyc_yellow_table に挿入します。 この例では、この関数を手動で呼び出していますが、実際のシナリオでは、この Lambda 関数は Amazon SQS からのメッセージなどの実際のイベントによってトリガーされます。実際のユースケースを実装する際は、関数コードをイベントデータを受け取り、要件に基づいて処理するように変更する必要があります。 コンテナイメージをデプロイパッケージとして使用して、この関数をデプロイします。ここではコンテナイメージから Lambda 関数を作成するために、CloudShell でイメージをビルドし、ECR リポジトリにプッシュします。以下の手順を実行してください。 AWS マネジメントコンソール にサインインし、 CloudShell を起動 します。 作業ディレクトリを作成します。 mkdir pyiceberg_blog cd pyiceberg_blog Lambda スクリプト lambda_function.py をダウンロードします。 aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-5013/lambda_function.py . このスクリプトは以下のタスクを実行します: Data Catalog に NYC yellow taxi trip data のスキーマを持つ Iceberg テーブルを作成します ランダムな NYC yellow taxi trip data にもとづくデータセットを生成します このデータをテーブルに挿入します この Lambda 関数の重要な部分を掘り下げてみましょう: Iceberg カタログの構成 – 次のコードは、AWS Glue Iceberg REST エンドポイントに接続する Iceberg カタログを定義しています: # Configure the catalog catalog_properties = { "type": "rest", "uri": f"https://glue.{region}.amazonaws.com/iceberg", "s3.region": region, "rest.sigv4-enabled": "true", "rest.signing-name": "glue", "rest.signing-region": region } catalog = load_catalog(**catalog_properties) テーブルスキーマ定義 – 次のコードは、NYC taxi データセットの Iceberg テーブルスキーマを定義しています。このテーブルには以下が含まれています。 Schema で定義されたスキーマのカラム vendorid と tpep_pickup_datetime による パーティショニング (PartitionSpec を使用) tpep_pickup_datetime に適用された day 変換 tpep_pickup_datetime と tpep_dropoff_datetime による ソートオーダー タイムスタンプ列に day 変換を適用する際、Iceberg は階層的に日付ベースのパーティション分割を自動的に処理します。つまり、単一の day 変換で、年、月、日のレベルでパーティションプルーニングを可能にするため、各レベルに明示的な変換を必要としません。Iceberg のパーティション分割の詳細については、 パーティション分割 を参照してください。 # Table Definition schema = Schema( NestedField(field_id=1, name="vendorid", field_type=LongType(), required=False), NestedField(field_id=2, name="tpep_pickup_datetime", field_type=TimestampType(), required=False), NestedField(field_id=3, name="tpep_dropoff_datetime", field_type=TimestampType(), required=False), NestedField(field_id=4, name="passenger_count", field_type=LongType(), required=False), NestedField(field_id=5, name="trip_distance", field_type=DoubleType(), required=False), NestedField(field_id=6, name="ratecodeid", field_type=LongType(), required=False), NestedField(field_id=7, name="store_and_fwd_flag", field_type=StringType(), required=False), NestedField(field_id=8, name="pulocationid", field_type=LongType(), required=False), NestedField(field_id=9, name="dolocationid", field_type=LongType(), required=False), NestedField(field_id=10, name="payment_type", field_type=LongType(), required=False), NestedField(field_id=11, name="fare_amount", field_type=DoubleType(), required=False), NestedField(field_id=12, name="extra", field_type=DoubleType(), required=False), NestedField(field_id=13, name="mta_tax", field_type=DoubleType(), required=False), NestedField(field_id=14, name="tip_amount", field_type=DoubleType(), required=False), NestedField(field_id=15, name="tolls_amount", field_type=DoubleType(), required=False), NestedField(field_id=16, name="improvement_surcharge", field_type=DoubleType(), required=False), NestedField(field_id=17, name="total_amount", field_type=DoubleType(), required=False), NestedField(field_id=18, name="congestion_surcharge", field_type=DoubleType(), required=False), NestedField(field_id=19, name="airport_fee", field_type=DoubleType(), required=False), ) # Define partition spec partition_spec = PartitionSpec( PartitionField(source_id=1, field_id=1001, transform=IdentityTransform(), name="vendorid_idenitty"), PartitionField(source_id=2, field_id=1002, transform=DayTransform(), name="tpep_pickup_day"), ) # Define sort order sort_order = SortOrder( SortField(source_id=2, transform=DayTransform()), SortField(source_id=3, transform=DayTransform()) ) database_name = os.environ.get('GLUE_DATABASE_NAME') table_name = os.environ.get('ICEBERG_TABLE_NAME') identifier = f"{database_name}.{table_name}" # Create the table if it doesn't exist location = f"s3://pyiceberg-lambda-blog-{account_id}-{region}/{database_name}/{table_name}" if not catalog.table_exists(identifier): table = catalog.create_table( identifier=identifier, schema=schema, location=location, partition_spec=partition_spec, sort_order=sort_order ) else: table = catalog.load_table(identifier=identifier) データの生成と挿入 – 次のコードはランダムなデータを生成し、テーブルに挿入します。この例では、ビジネスイベントやトランザクションを追跡するために、新しいレコードが継続的に追加される append-only のパターンを想定しています。 # Generate random data records = generate_random_data() # Convert to Arrow Table df = pa.Table.from_pylist(records) # Write data using PyIceberg table.append(df) Dockerfile をダウンロードします。これは、Lambda 関数のコンテナイメージを定義します。 aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-5013/Dockerfile . requirements.txt をダウンロードします。これは、Lmbmda 関数に必要な Python パッケージを定義しています。 aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-5013/requirements.txt . この時点で、作業ディレクトリには次の 3 つのファイルが含まれているはずです。 Dockerfile lambda_function.py requirements.txt 環境変数を設定します。 を自分の AWS アカウント ID に置き換えてください: export AWS_ACCOUNT_ID= <account_id> Docker イメージをビルドします: docker build --provenance=false -t localhost/pyiceberg-lambda . # Confirm built image docker images | grep pyiceberg-lambda イメージにタグを設定します: docker tag localhost/pyiceberg-lambda:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/pyiceberg-lambda-repository:latest AWS CloudFormation によって作成された ECR リポジトリにログインします: aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com イメージを ECR リポジトリにプッシュします: docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/pyiceberg-lambda-repository:latest Amazon ECR にプッシュしたコンテナイメージを使用して、Lambda 関数を作成します: aws lambda create-function \ --function-name pyiceberg-lambda-function \ --package-type Image \ --code ImageUri=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/pyiceberg-lambda-repository:latest \ --role arn:aws:iam::${AWS_ACCOUNT_ID}:role/pyiceberg-lambda-function-role-${AWS_REGION} \ --environment "Variables={ICEBERG_TABLE_NAME=nyc_yellow_table, GLUE_DATABASE_NAME=pyiceberg_lambda_blog_database}" \ --region ${AWS_REGION} \ --timeout 60 \ --memory-size 1024 次のセクションで確認するため、少なくとも 5 回関数を呼び出して複数のスナップショットを作成してください。今回は手動で関数を呼び出してイベント駆動型のデータ取り込みをシミュレートしていますが、実際のシナリオでは Lambda 関数がイベント駆動型で自動的に呼び出されます。 aws lambda invoke \ --function-name arn:aws:lambda:${AWS_REGION}:${AWS_ACCOUNT_ID}:function:pyiceberg-lambda-function \ --log-type Tail \ outputfile.txt \ --query 'LogResult' | tr -d '"' | base64 -d ここまでで、Lambda 関数をデプロイして実行しました。この関数は、 pyiceberg_lambda_blog_database データベース内に nyc_yellow_table Iceberg テーブルを作成します。また、このテーブルにサンプルデータを生成して挿入します。後の手順で、このテーブルのレコードを確認します。 コンテナを使用した Lambda 関数の構築に関する詳細情報は、 コンテナイメージを使用した Lambda 関数の作成 をご覧ください。 Jupyter を使った PyIceberg によるデータ探索 このセクションでは、Data Catalog に登録された Iceberg テーブルのデータにアクセスし、分析する方法を示します。PyIceberg を使用した Jupyter ノートブックから、Lambda 関数によって作成されたタクシー運行データにアクセスし、新しいレコードが到着するたびに作成される異なるスナップショットを検査します。また、重要なスナップショットにタグを付けて保持し、さらなる分析のために新しいテーブルを作成します。 SageMaker AI ノートブックインスタンスで Jupyter を使ってノートブックを開くには、次の手順を実行してください。 SageMaker AI コンソールで、ナビゲーションペインから Notebooks を選択します。 CloudFormation テンプレートを使用して作成したノートブックインスタンスの横にある Open JupyterLab を選択します。 ノートブック をダウンロードし、SageMaker AI ノートブックの Jupyter 環境で開いてください。 アップロードした pyiceberg_notebook.ipynb を開きます。 カーネル選択のダイアログでは、デフォルトのオプションのままにして Select を選択します。 ここからは、セルを順番に実行してノートブックを進めていきます。 カタログへの接続とテーブルのスキャン PyIceberg を使用して Iceberg テーブルにアクセスできます。次のコードは、AWS Glue Iceberg REST エンドポイントに接続し、 pyiceberg_lambda_blog_database データベース上の nyc_yellow_table テーブルを読み込みます。 import pyarrow as pa from pyiceberg.catalog import load_catalog import boto3 # Set AWS region sts = boto3.client('sts') region = sts._client_config.region_name # Configure catalog connection properties catalog_properties = { "type": "rest", "uri": f"https://glue.{region}.amazonaws.com/iceberg", "s3.region": region, "rest.sigv4-enabled": "true", "rest.signing-name": "glue", "rest.signing-region": region } # Specify database and table names database_name = "pyiceberg_lambda_blog_database" table_name = "nyc_yellow_table" # Load catalog and get table catalog = load_catalog(**catalog_properties) table = catalog.load_table(f"{database_name}.{table_name}") Iceberg テーブルからフルデータを Apache Arrow テーブルとしてクエリし、 Pandas の DataFrame に変換できます。 スナップショットの操作 Iceberg の重要な機能の 1 つがスナップショットベースのバージョン管理です。スナップショットは、テーブルのデータに変更があるたびに自動的に作成されます。次の例のように、特定のスナップショットからデータを取得できます。 # Get data from a specific snapshot ID snapshot_id = snapshots.to_pandas()["snapshot_id"][3] snapshot_pa_table = table.scan(snapshot_id=snapshot_id).to_arrow() snapshot_df = snapshot_pa_table.to_pandas() スナップショットに基づいて、任意の時点の過去のデータと現在のデータを比較できます。この場合、最新のテーブルとスナップショットテーブルの間のデータ分布の違いを比較しています。 # Compare the distribution of total_amount in the specified snapshot and the latest data. import matplotlib.pyplot as plt plt.figure(figsize=(4, 3)) df['total_amount'].hist(bins=30, density=True, label="latest", alpha=0.5) snapshot_df['total_amount'].hist(bins=30, density=True, label="snapshot", alpha=0.5) plt.title('Distribution of total_amount') plt.xlabel('total_amount') plt.ylabel('relative Frequency') plt.legend() plt.show() スナップショットのタグ付け 特定のスナップショットに任意の名前を付けてタグ付けし、後でその名前で特定のスナップショットを取得できます。これは、重要なイベントのスナップショットを管理する際に便利です。 この例では、checkpointTag タグを指定してスナップショットへクエリをしています。ここでは polars を使用して、既存のカラム tpep_dropoff_datetime と tpep_pickup_datetime に基づいて trip_duration という新しいカラムを追加することで、新しい DataFrame を作成しています。 # retrive tagged snapshot table as polars data frame import polars as pl # Get snapshot id from tag name df = table.inspect.refs().to_pandas() filtered_df = df[df["name"] == tag_name] tag_snapshot_id = filtered_df["snapshot_id"].iloc[0] # Scan Table based on the snapshot id tag_pa_table = table.scan(snapshot_id=tag_snapshot_id).to_arrow() tag_df = pl.from_arrow(tag_pa_table) # Process the data adding a new column "trip_duration" from check point snapshot. def preprocess_data(df): df = df.select(["vendorid", "tpep_pickup_datetime", "tpep_dropoff_datetime", "passenger_count", "trip_distance", "fare_amount"]) df = df.with_columns( ((pl.col("tpep_dropoff_datetime") - pl.col("tpep_pickup_datetime")) .dt.total_seconds() // 60).alias("trip_duration")) return df processed_df = preprocess_data(tag_df) display(processed_df) print(processed_df["trip_duration"].describe()) 処理済みの DataFrame から trip_duration 列を使って新しいテーブルを作成します。このステップは、将来の分析のためにデータを準備する方法を示しています。基になるテーブルが変更されていても、タグを使うことで、処理済みデータが参照しているデータのスナップショットを明示的に指定できます。 # write processed data to new iceberg table account_id = sts.get_caller_identity()["Account"] new_table_name = "processed_" + table_name location = f"s3://pyiceberg-lambda-blog-{account_id}-{region}/{database_name}/{new_table_name}" pa_new_table = processed_df.to_arrow() schema = pa_new_table.schema identifier = f"{database_name}.{new_table_name}" new_table = catalog.create_table( identifier=identifier, schema=schema, location=location ) # show new table's schema print(new_table.schema()) # insert processed data to new table new_table.append(pa_new_table) 処理済みデータから作成した新しいテーブルを Athena でクエリし、Iceberg テーブルの相互運用性を実証しましょう。 Amazon Athena からのデータクエリ 前のセクションのノートブックから作成された pyiceberg_lambda_blog_database.processed_nyc_yellow_table テーブルを、 Athena クエリエディタ でクエリできます: SELECT * FROM "pyiceberg_lambda_blog_database"."processed_nyc_yellow_table" limit 10 ; これらのステップを通して、Lambda と AWS Glue Iceberg REST エンドポイントを使用したサーバーレスのデータ処理ソリューションを構築し実際に利用する流れを体験しました。また、PyIceberg を使用してスナップショット管理やテーブル操作を含む Python によるデータ管理と分析を行いました。さらに、別のエンジンである Athena を使用してクエリを実行し、Iceberg テーブルの互換性を示しました。 クリーンアップ この記事で使用したリソースをクリーンアップするには、次の手順を実行してください。 Amazon ECR コンソールで、リポジトリ pyiceberg-lambda-repository に移動し、リポジトリ内のすべてのイメージを削除します。 CloudShell で、作業ディレクトリ pyiceberg_blog を削除します。 Amazon S3 コンソールで、CloudFormation テンプレートを使用して作成した S3 バケット pyiceberg-lambda-blog- - に移動し、バケットを空にします。 リポジトリとバケットが空になったことを確認したら、CloudFormation スタック pyiceberg-lambda-blog-stack を削除します。 Docker イメージを使用して作成した Lambda 関数 pyiceberg-lambda-function を削除します。 結論 この記事では、AWS Glue Data Catalog と PyIceberg を使用することで、堅牢なデータ管理機能を維持しながら、効率的で軽量なデータワークフローを実現できることを示しました。チームがインフラストラクチャの依存関係を最小限に抑えながら、Iceberg の強力な機能を活用できることを紹介しました。このアプローチにより、組織は分散コンピューティングリソースのセットアップや管理の複雑さなしに、すぐに Iceberg テーブルの利用を開始できます。 Iceberg の機能を低いハードルで導入しようとしている組織にとって、これは特に価値があります。PyIceberg の軽量な性質により、チームはすぐに Iceberg テーブルを使い始めることができ、慣れ親しんだツールを使用し、追加の学習を最小限に抑えることができます。データニーズが高まれば、同じ Iceberg テーブルを Athena や AWS Glue などの AWS 分析サービスからシームレスにアクセスでき、将来的なスケーラビリティへの明確なパスが提供されます。 PyIceberg と AWS の分析サービスの詳細については、 PyIceberg のドキュメント と Apache Iceberg とは? を参照することをお勧めします。 著者について Sotaro Hikita は、AWS でアナリティクスに特化したスペシャリストソリューションアーキテクトで、ビッグデータ技術とオープンソースソフトウェアを扱っています。仕事以外では、いつも美味しい食べ物を探し求め、最近はピザに夢中になっています。 Shuhei Fukami は、AWS におけるアナリティクスに特化したスペシャリストソリューションアーキテクトです。趣味で料理をするのが好きで、最近はピザ作りにはまっています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 3 月のアップデートまとめ はお読みいただけましたでしょうか。今月も アップデート 情報を中心に以下の内容をお届けします。皆さまのお役に立つ内容がございましたら幸いです！ 注目のアップデートについて 2025 年 4 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートについて #1: ダッシュボードがエージェント階層を使用したアクセス制御をサポート Amazon Connect Contact Lens ダッシュボードが、特定のエージェント階層に基づいてきめ細かなアクセス制御を実施するコンタクトセンター管理者向けの機能をサポートするようになりました。ユーザーに階層を割り当てると、ユーザーが所属する組織グループを定義でき、きめ細かなアクセス制御を有効にすると、自身の階層内または特定の割り当てられた階層内のエージェントのメトリクスのみを表示できるようにすることができます。たとえば、チームの階層グループとレベルを設定すると、そのチーム内の階層グループに割り当てられたユーザーのみが、そのエージェントのメトリクスを表示できるようになるため、スーパーバイザーは、自チームのエージェントのメトリクスだけを表示できます。 セキュリティプロファイルのアクセスコントロールで“階層ベースのアクセスコントロール”を選択し、リソースに“ユーザー”、ターゲティングに“割り当てられたユーザー階層”(階層内のユーザーを表示) または “カスタムのユーザー階層”(特定の階層内のユーザーを表示)を指定することで、エージェント階層に基づいた、ダッシュボード、リアルタイムメトリクス、履歴メトリクスの表示を制御することが可能です。制御可能なリソースはユーザーのみサポートされています。詳細は管理者ガイドを参照してください。 関連リンク 管理者ガイド リリースノート 2. 2025年4月のアップデート一覧 Amazon Connect がエージェントスケジュールの管理者アクセスを開始 – 2025/04/30 Amazon Connect では、管理者にエージェントスケジュールへのアクセス権を付与できるようになりました。今回のローンチにより、スケジュール管理者をすべてのスタッフグループにスーパーバイザーとして追加することなく、特定のユーザーに対して公開済みのエージェントスケジュールへのアクセス権を付与できるようになりました。たとえば、一元管理されたスケジューラーや監査担当者など、組織全体のエージェントスケジュールを幅広く把握する必要があるユーザーに、数回クリックするだけでこのアクセス権を付与できるようになりました。これにより、アクセス管理に費やす時間が短縮され、業務効率が向上します。  関連リンク 管理者ガイド Amazon Connect でエージェントスケジュールを一括削除できるようになりました  – 2025/04/30 Amazon Connect では、エージェントスケジュールを一括削除できるようになり、エージェントスケジュールの日々の管理がより効率的になりました。今回のアップデートにより、1 日単位で最大 400 人のエージェント、1 人の場合は最大 30 日間のスケジュールを削除できるようになりました。たとえば、コンタクトセンターのクローズにあわせて翌週の月曜日のスケジュールをすべて削除したり、組織に所属しなくなったエージェントの今後のシフトを一括して削除することが可能になります。一括削除により、マネージャーはエージェントのシフトスケジュールを 1 日ずつ削除する必要がなくなり、エージェントスケジュールの管理に費やす時間が短縮されるため、マネージャーの生産性が向上します。  関連リンク 管理者ガイド お客様の AI 導入を加速するための MAP の強化  – 2025/04/30 モダナイゼーションの取り組みを加速し、お客様の AI の採用を促進するために、以下の2 つの主要機能によりAWS 移行アクセラレーションプログラム (MAP) が強化されました。 1つ目は、Amazon Bedrock と Amazon SageMaker を特徴とする新しい「AI への移行」モダナイゼーションパスウェイです。このパスウェイにより、測定可能なビジネス価値をもたらす実証済みの AI パターンを使用して、お客様が既存のアプリケーションやビジネスプロセスを変革できるよう支援できます。 2つ目として、Amazon Connect は MAP モダナイゼーション戦略的パートナーインセンティブ (SPI) の対象サービスになりました。これにより、エージェントの生産性を高め、カスタマーエクスペリエンスを向上させる AI を活用した機能により、顧客がコンタクトセンターを変革できるよう支援できます。 これらにより、顧客の AI 変革を主導し、コンタクトセンターの近代化を推進する能力が強化されます。 関連リンク AWS Partner Funding Benefits Program Guide MAP Modernization SPI Eligible Services Amazon Connect エージェントワークスペースが、問い合わせ関連のアクションを含むサードパーティアプリケーション向けの機能を拡張 – 2025/04/25 Amazon Connect エージェントワークスペースは、アウトバウンドコールの発信、コンタクトの応答、転送、クリア、エージェントステータスの更新など、サードパーティアプリケーションの追加機能をサポートするようになりました。これらの機能強化により、エージェントがより直感的なワークフローを実現するアプリケーションを統合できるようになりました。例えば、 createOutboundCall API を使用して、最新のコンタクト一覧を表示するカスタムメイドの通話履歴インターフェイスから、エージェントがワンクリックでアウトバウンドコールを行う Click to Call 機能を実装できるようになります。今回新たにサポートされた API の詳細情報は以下を参照してください。 関連リンク 管理者ガイド API リファレンス Amazon Connect Cases にケースに関するサービスレベル契約を管理するためのサポートが追加 – 2025/04/18 Amazon Connect Cases に、コンタクトセンターがケースのサービスレベル契約 (SLA) を追跡、管理する機能が追加されました。管理者は、Amazon Connect の管理コンソール上で、ケース属性に基づいて SLA ルールを設定し、目標とするケースの解決までの時間を設定できるようになりました。エージェントとマネージャーはケース一覧で各ケースの SLA 状況をリアルタイムで確認できるため、緊急性の高い作業から優先的に対応することができます。また、管理者は SLA が守られない場合にケースを自動的にエスカレーションしたり、別のチームにケースを転送するルールを作成できます。たとえば、「重要度の高いケースは4時間以内に確認し、24時間以内に解決する」といった目標を設定し、その達成状況を管理することができます。これにより、企業はサービス品質の維持・向上に取り組みやすくなりました。 ルール設定画面で、 ① ケース作成時にサービスレベルを割り当てるルールを作成 し、作成したルールをもとに ② サービルレベルに抵触した場合の検知、通知、エスカレーションを行うルールを作成 することが可能です。サービスレベルが割り当てられたケースは ③エージェントワークスペースの“Next SLA Branch”カラムで SLA の状況を確認することが可能 です。  関連リンク 管理者ガイド Amazon Connect Contact Lens ダッシュボードがエージェント階層を使用したアクセス制御をサポート開始 – 2025/04/18 注目アップデート #1 をご覧ください！ Amazon Connect がコンタクトフローで音声や言語を動的に設定する機能を提供開始 – 2025/04/10 Amazon Connect では、音声ボットと自動音声応答 (IVR) で使用されるテキスト読み上げ (TTS) の音声、言語、話し方を動的に設定できるようになりました。これらの新機能を利用することで、よりパーソナライズされたエクスペリエンスをエンドカスタマーごとに提供することが可能になります。例えば、 顧客プロファイル で設定した主な使用言語に基づいて、希望する音声を動的に設定できます。これらの新機能は、 Amazon Connect フロー の [ 音声の設定 ] ブロックで設定が可能であり、ドラッグアンドドロップのフローデザイナーまたはパブリック API で設定できます。 関連リンク 管理者ガイド Amazon Connect でスーパーバイザーが進行中のチャットで追加のアクションを実行可能に – 2025/04/03 Amazon Connect では、スーパーバイザーが進行中のチャットで Amazon Connect UI から直接追加のアクションを実行できるようになりました。これにより、問題解決が加速され、顧客満足度が向上します。例えば、スーパーバイザーは、非アクティブな顧客とのチャットを終了したり、特定のエージェントやキューにチャットを再割り当てしたりできるようになりました。  関連リンク 管理者ガイド Amazon Connect が追加の Dual-Tone Multi-Frequency (DTMF) 構成設定のサポートを開始 – 2025/04/02 Amazon Connect では、発信者がキーパッドボタンを押す間にシステムが待機する秒数をカスタマイズできるようになりました。これにより、自動音声応答 (IVR) システムでのユーザー入力を最適化できます。管理者は以前は5秒に固定されていたこの待機時間を 1 秒から 20 秒の間で調整できるようになりました。たとえば、銀行の IVR フローでは、口座番号入力の桁間タイムアウトを長く設定できます。これは、数字を押す間隔が長くなる場合がある顧客に役立ちます。さらに、既存の 2 つの設定である [最大桁数] と [最初の入力までのタイムアウト] を変数を使用して動的に設定できるようになったため、管理者は IVR フローをより柔軟に設計できます。この柔軟性の向上により、特定のユースケースに合わせて IVR システムを最適化し、ユーザーエクスペリエンスとシステム効率を向上させることができます。  関連リンク 管理者ガイド Amazon Connect でエージェントの作業スケジュールへの遵守状況がカレンダービューに表示されるように – 2025/04/02 Amazon Connect では、スーパーバイザーがエージェントのスケジュール遵守状況をカレンダービューで簡単に監視できるようになりました。今回のリリースにより、スーパーバイザーは、過去 90 日間までの遵守違反をエージェント別、日別にシフトと一緒に視覚化できるようになりました。これには、最小限の遵守違反を除外する機能も含まれます。この視覚化により、スーパーバイザーはチーム全体の遵守違反を即座に発見し、最も重要なインシデントに優先順位を付け、過去のエージェントの行動と比較し、該当エージェントの懸念に対処するための措置を講じることができます。たとえば、スーパーバイザーは、エージェントが休憩や昼食後に常に遅刻するパターンに気づいた場合、さらに調査して、ネットワークの問題、機器の問題、適時性への期待など、対処する必要のある根本的な問題があるかどうかを判断できます。  関連リンク 管理者ガイド Amazon Connect Contact Lens で感情分析の有効化および無効化をサポート – 2025/04/01 Amazon Connect Contact Lens で感情分析の有効・無効化を制御できるようになりました。これにより、コンプライアンス義務を果たす必要がある組織は、トランスクリプト、生成 AI の要約、その他の会話インサイトなど、Contact Lens の他の会話分析機能を引き続き利用しながら、感情分析を制御することができます。例えば、ブランドに対する顧客の認識の追跡では感情分析を有効にし、社内の苦情対応窓口では利用者の感情分析を無効にすることができます。  関連リンク 管理者ガイド Amazon Connect Contact Lens、新たに 34 言語で会話型分析のサポートを開始 – 2025/04/01 Amazon Connect Contact Lens では、新たに 34 言語で会話分析がサポートされるようになりました。 関連リンク 管理者ガイド(言語サポート) Amazon Connect Contact Lens が新たに 2 つのリージョンで AI を活用したセマンティックコンタクト分類の機能の提供を開始 – 2025/04/01 Amazon Connect Contact Lens では、新たに 2 つのリージョン (欧州 – フランクフルトとアジアパシフィック – ソウル) で生成 AI を活用したコンタクト分類の機能が提供されました。 関連リンク 管理者ガイド(言語サポート) Amazon Connect Contact Lens で新たに 2 つのリージョンで AI を活用したコンタクトの要約機能の提供を開始 – 2025/04/01 Amazon Connect Contact Lens では、新たに欧州 (フランクフルト) とアジアパシフィック (ソウル) の 2 つのリージョンで、コンタクト終了後に生成 AI を活用した概要が提供されるようになりました。 関連リンク 管理者ガイド(言語サポート) 3. AWS Contact Center Blog のご紹介 Salesforce Contact Center with Amazon Connect: オムニチャネルのカスタマーエンゲージメントを効率化 (日本語翻訳) Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect のデジタルチャネルおよび音声機能を Salesforce に統合した画期的なソリューションとして、一般提供されています。音声チャネル専用の Service Cloud Voice (SCV) を基盤として、SCC-AC は、Amazon Connect と Salesforce 間で音声チャネルとデジタルチャネルを統合することで、カスタマーエクスペリエンス、エージェントエクスペリエンス、および業務効率を向上させることを可能にします。 AWS recognized as a leader in 2025 Forrester Wave for Contact Center as a Service with Amazon Connect (英語記事) Amazon Connect は、AIアーキテクチャ、生成 AI と LLM のサポート、エージェントデスクトップとワークフローの自動化、イノベーション、ロードマップ、価格の柔軟性と透明性といった評価基準で最高スコアを獲得しました。本ブログ記事は、AWS 社のクラウドベースのコンタクトセンターソリューションである Amazon Connect が、Forrester 社による2025年第2四半期のコンタクトセンター・アズ・ア・サービス(CCaaS)プラットフォーム評価でリーダーとして認定されたことを説明しています。 Insights and learnings from Amazon Q in Connect at NatWest (英語記事) 大手金融機関のNatWestグループによる、コンタクトセンターでのAmazon Q in Connect導入事例を紹介する記事です。ユーザー受け入れテスト(UAT)での課題、知識管理システムの統合方法、パイロット評価の手法など、具体的な取り組みが紹介されています。特に、テスト用の適切なインテント選定、レガシーな知識システムとの統合、パイロットの成功評価という3つの主要な課題に焦点を当てています。 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は、2025/4/8 に公開された Manage concurrent write conflicts in Apache Iceberg on the AWS Glue Data Catalog を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 現代的なデータアーキテクチャにおいて、Apache Iceberg はデータレイクの人気のあるテーブルフォーマットとして台頭しており、ACID トランザクションと同時書き込みサポートなどの重要な機能を備えています。これらの機能は強力ですが、本番環境で効果的に実装するには、慎重な検討を要する独自の課題があります。 一般的なシナリオを考えてみましょう。ストリーミングパイプラインが継続的に Iceberg テーブルにデータを書き込み、スケジュールされたメンテナンスジョブがコンパクション操作を実行しています。Iceberg には同時書き込みを処理するための組み込みメカニズムがありますが、ストリーミング更新とコンパクション操作の間のような特定の競合シナリオでは、トランザクションが失敗し、特別な処理パターンが必要になる可能性があります。 この記事では、Iceberg テーブルで信頼性の高い同時書き込み処理メカニズムを実装する方法を示します。Iceberg の同時実行モデルを探り、一般的な競合シナリオを検討し、自動再試行メカニズムと、独自の競合解決ロジックが必要な状況の実用的な実装パターンを提供して、耐障害性の高いデータパイプラインを構築します。また、 AWS Glue Data Catalog テーブル最適化による自動コンパクションと併用した設計パターンについても説明します。 一般的な競合シナリオ 多くの組織がデータパイプラインで直面する、データ競合が最も頻繁に発生する具体的な運用シナリオについて、この節で説明します。 重複したパーティションへの UPDATE/DELETE の同時実行 複数のプロセスが同時に同じパーティションを変更しようとすると、データの競合が発生する可能性があります。例えば、ここで両方の操作が同じパーティションのcustomer_id を対象にした場合、重複するデータセットを変更することで競合が発生する可能性があります。両方の操作は customer_id に基づいて同じパーティションを対象としているため、重複するデータセットを変更しているので競合が発生する可能性があります。このような競合は、大規模なデータクリーンアップ操作で特に一般的です。 コンパクション vs ストリーミング書き込み テーブルのメンテナンス操作中に、典型的な競合シナリオが発生する可能性があります。リアルタイムのイベントデータを取り込むストリーミングパイプラインと、ファイルサイズを最適化するためにスケジュールされたコンパクションジョブが同時に実行されている場合を考えてみましょう。ストリーミングプロセスが新しいレコードをパーティションに書き込んでいる間に、コンパクションジョブが同じパーティション内の既存ファイルを結合しようとしているかもしれません。このシナリオは、特に Glue Data Catalog の自動最適化機能を利用している際に一般的に起こりうるシナリオです。自動コンパクションが継続的なデータ取り込みと同時に実行される可能性があるためです。 MERGE の同時実行操作 MERGE 操作は、データの読み取りと書き込みの両方を含むため、特に競合が発生しやすくなります。例えば、ある時間単位のジョブがソースシステムからの顧客プロファイル更新をマージしている一方で、別のジョブが別のシステムからの設定更新をマージしている場合、両方のジョブが同じ顧客レコードを変更しようとすると、それぞれの操作が異なる現在のデータ状態に基づいて変更を行うため、競合が発生する可能性があります。 一般的なテーブルの同時更新 複数のトランザクションが同時に発生すると、他のトランザクションの干渉により、一部のトランザクションがカタログにコミットできない可能性があります。Iceberg にはこのシナリオを処理するメカニズムがあり、多くの場合、同時トランザクションに対応できます。ただし、更新の基準となるメタデータバージョンが確立された後にメタデータが最新化されると、コミットが失敗する可能性があります。このシナリオは、Iceberg テーブルのあらゆる種類の更新に適用されます。 Iceberg の同時実行モデルと競合の種類 特定の実装パターンに入る前に、Iceberg がテーブルアーキテクチャとトランザクションモデルを通じて同時書き込みをどのように管理するかを理解することが不可欠です。Iceberg は、テーブルの状態とデータを管理するために階層アーキテクチャを使用しています。 カタログレイヤー – 現在のテーブルメタデータファイルへのポインターを維持し、テーブル状態の単一の情報源として機能します。Glue Data Catalog は Iceberg カタログと同様の機能を提供します。 メタデータレイヤー – テーブルの履歴、スキーマの進化、スナップショット情報を追跡するメタデータファイルが含まれています。これらのファイルは Amazon Simple Storage Service (Amazon S3) に格納されています。 データレイヤー – 実際のデータファイルと削除ファイル (Merge-on-Read 操作用) が格納されています。これらのファイルも Amazon S3 に格納されています。 次の図はこのアーキテクチャを示しています。 このアーキテクチャは Iceberg の楽観的同時実行制御の基本であり、複数のライターが同時に操作を進めることができ、競合はコミット時に検出されます。 書き込みトランザクションの流れ Iceberg での典型的な書き込みトランザクションは、次のキーステップに従います。 現在の状態を読み取ります。OVERWRITE、MERGE、DELETE などの多くの操作では、クエリエンジンがどのファイルまたは行が関連するかを知る必要があるため、現在のテーブルスナップショットを読み取ります。INSERT などの操作ではこの手順はオプションです。 トランザクションが行う変更を確定し、新しいデータファイルを書き込みます。 テーブルの最新のメタデータを読み込み、更新の基準となるメタデータバージョンを判断します。 ステップ 2 で準備した変更が、ステップ 3 の最新のテーブルデータと互換性があるかどうかを確認します。互換性がないことが検出された場合、トランザクションは停止する必要があります。 新しいメタデータファイルを生成します。 メタデータファイルをカタログにコミットします。コミットに失敗した場合は、ステップ 3 から再試行します。再試行回数は設定によって異なります。 次の図はこのワークフローを示しています。 競合が発生する可能性がある重要な 2 つのポイントは次のとおりです。 データ更新の競合 – データの競合をチェックする際の検証時 (ステップ 4) カタログコミットの競合 – カタログポインタを更新しようとするコミット時 (ステップ 6) Iceberg テーブルを扱う際、発生しうる競合の種類とその処理方法を理解することは、信頼性の高いデータパイプラインを構築する上で非常に重要です。主な 2 種類の競合とその特徴について説明しましょう。 カタログコミットの競合 カタログコミット競合は、複数のライターが同時にテーブルメタデータを更新しようとしたときに発生します。コミット競合が発生すると、Iceberg はテーブルの書き込みプロパティに基づいて自動的に操作を再試行します。再試行プロセスはメタデータのコミットのみを繰り返すため、安全で効率的です。再試行に失敗すると、トランザクションは CommitFailedException で失敗します。 次の図では、2 つのトランザクションが同時に実行されています。トランザクション 1 は、Iceberg カタログ内のテーブルの最新のスナップショットを 0 から 1 に正常に更新しました。一方、トランザクション 2 はスナップショット 0 から 1 への更新を試みましたが、カタログへの変更をコミットしようとしたときに、最新のスナップショットがすでにトランザクション 1 によって 1 に変更されていたことがわかりました。その結果、トランザクション 2 はステップ 3 から再試行する必要がありました。 これらの競合は一時的なものであり、再試行によって自動的に解決できます。オプションで、コミットの再試行動作を制御する書き込みプロパティを構成できます。より詳細な構成については、Iceberg ドキュメントの 書き込みプロパティ を参照してください。 現在の状態を読み取るときに使用されるメタデータ (ステップ 1) と、更新のベースメタデータとして使用されるスナップショット (ステップ 3) は異なる可能性があります。ステップ 1 とステップ 3 の間に別のトランザクションが最新のスナップショットを更新しても、現在のトランザクションはデータ競合チェック (ステップ 4) に合格すれば、カタログに変更をコミットできます。つまり、変更の計算とデータファイルの書き込み (ステップ 1 から 2) に長い時間がかかり、その間に他のトランザクションが変更を加えた場合でも、トランザクションはカタログへのコミットを試行できます。これは、Iceberg の賢明な同時実行制御メカニズムを示しています。 次の図はこのワークフローを示しています。 データ更新の競合 データ更新の競合は、より複雑で、同時実行されるトランザクションが重複するデータを変更しようとしたときに発生します。書き込みトランザクション中、クエリエンジンはトランザクション分離ルールに従って、書き込まれるスナップショットと最新のスナップショットの整合性をチェックします。不整合が検出された場合、トランザクションは ValidationException で失敗します。 次の図では、2 つのトランザクションが id 、 name 、 salary 列を含む従業員テーブルで同時に実行されています。トランザクション 1 は、スナップショット 0 に基づいてレコードを更新しようとし、この変更を正常にコミットしてスナップショットのバージョンを 1 に更新しました。一方、トランザクション 2 も同じレコードをスナップショット 0 に基づいて更新しようとしました。トランザクション 2 が最初にデータをスキャンした時点では、最新のスナップショットは 0 でしたが、その後トランザクション 1 によって 1 に更新されていました。データ競合チェック中に、トランザクション 2 はその変更がスナップショット 1 と競合していることを検出し、トランザクションが失敗しました。 この競合シナリオでは、更新の元となるテーブルの状態が変更されているため、トランザクションを再施行した場合に全体のデータ整合性が維持されるかどうかが不確かになるため、Iceberg のライブラリでは自動的に再試行できません。この種の競合は、個別のユースケースと要件に基づいて対処する必要があります。 次の表は、各書き込みパターン別に競合が発生する可能性の有無をまとめたものです。 書き込みパターン カタログコミット競合 (自動再試行可能) データ競合 (再試行なし) INSERT ( AppendFiles ) Yes Never UPDATE/DELETE with Copy-on-Write または Merge-on-Read ( OverwriteFiles ) Yes Yes Compaction ( RewriteFiles ) Yes Yes Iceberg テーブルの分離レベル Iceberg テーブルは、 Serializable 分離 と Snapshot 分離 の 2 つの分離レベルをサポートしています。どちらも、テーブルの一貫したビューを読み取り、リーダーがコミットされたデータのみを参照することを保証します。Serializable 分離は、同時実行操作が逐次的に実行されたかのように処理されることを保証します。Snapshot 分離は保証が弱くなりますが、同時に多数の書き込みクライアントが存在する環境でのパフォーマンスが向上します。Snapshot 分離では、同時実行トランザクションが条件に一致する可能性のあるレコードを含む新しいファイルを追加した場合でも、データ競合チェックが合格する可能性があります。 デフォルトでは、Iceberg テーブルはSerializable 分離を使用します。テーブルプロパティを使用して、特定の操作の分離レベルを構成できます。 tbl_properties = { 'write.delete.isolation-level' = 'serializable', 'write.update.isolation-level' = 'serializable', 'write.merge.isolation-level' = 'serializable' } ユースケースに基づいて適切な分離レベルを選択する必要があります。最も一般的な競合シナリオの一つであるストリーミングでの書き込みとコンパクション操作の同時実行では、スナップショット分離を選んだとしても、競合を緩和する観点でシリアライザブル分離に対する追加のメリットはない点に留意してください。より詳細な設定については、 IsolationLevel を参照してください。 実装パターン Iceberg で堅牢な同時書き込み処理を実装するには、競合の種類とユースケースに応じて異なる戦略が必要です。このセクションでは、一般的なシナリオを処理するための実証済みのパターンを共有します。 カタログコミット競合の管理 カタログコミットの競合は、テーブルプロパティを通じて比較的簡単に処理できます。以下の構成は、ワークロードのパターンと要件に応じて調整できる、初期のベースライン設定として機能します。 頻繁な同時書き込み (ストリーミングによる書き込みなど) の場合: tbl_properties = { 'commit.retry.num-retries': '10', 'commit.retry.min-wait-ms': '100', 'commit.retry.max-wait-ms': '10000', 'commit.retry.total-timeout-ms': '1800000' } メンテナンス操作 (コンパクション等) の場合: tbl_properties = { 'commit.retry.num-retries': '4', 'commit.retry.min-wait-ms': '1000', 'commit.retry.max-wait-ms': '60000', 'commit.retry.total-timeout-ms': '1800000' } データ更新の競合管理 データ更新の競合は自動的に再試行できないため、適切なエラー処理を伴うカスタムの再試行メカニズムを実装する必要があります。一般的なシナリオは、ストリームでの UPSERT 取り込みと同時実行のコンパクション操作が競合する場合です。このような場合、ストリーム取り込みジョブは通常、データを処理するために再試行を実装する必要があります。適切なエラー処理がないと、ジョブは ValidationException で失敗します。 Iceberg ストリーミングジョブでのデータ競合に対するエラー処理の実用的な実装を示す 2 つのサンプルスクリプトを紹介します。このコードは、適切な Java と Python を相互に利用する際に不可欠な Py4JJavaError 処理を通じて、 ValidationException を捕捉しています。また、 エクスポネンシャルバックオフとジッター戦略 を実装し、各再試行間隔に 0 〜 25% のランダムな遅延を追加しています。たとえば、指数関数的バックオフ時間の基準が 4 秒の場合、実際の再試行の遅延は 4 〜 5 秒の間になり、即座の再試行の嵐を防ぎながら、合理的な待ち時間を維持できます。 このサンプルでは、一意の識別子として 'value' を使用し、その範囲を人為的に制限することで、同じレコードに対する頻繁な MERGE 操作のシナリオを作成しています。モジュロ演算 ( value % 20 ) を適用することで、すべての値を 0 〜 19 の範囲に制限しています。これにより、複数の更新が同じレコードを対象とすることになります。たとえば、元のストリームに値 0、20、40、60 が含まれている場合、すべて 0 にマッピングされるため、同じレコードに対して複数の MERGE 操作が行われます。次に、 groupBy と max 集約を使用して、一般的な UPSERT パターンをシミュレートします。ここでは、各値の最新のレコードを保持します。変換されたデータは一時ビューに格納され、MERGE ステートメントのソーステーブルとして機能します。これにより、 'value' を一致条件として使用して UPDATE 操作を実行できます。このセットアップにより、同時実行トランザクションが同じレコードを変更しようとしたときに発生する ValidationExceptions に対するリトライメカニズムの動作を確認できます。 最初のサンプルでは、20 秒のトリガー間隔でデータを生成する レートソース を使用する Spark Structured Streaming を使用して、同時操作によるデータ競合が発生したときの再試行メカニズムの動作を示します。 <database_name> は実際のデータベース名、 <table_name> は実際のテーブル名、 amzn-s3-demo-bucket は 実際の S3 バケット名にそれぞれ置き換えてください。 import time import random from pyspark.sql import SparkSession from py4j.protocol import Py4JJavaError from pyspark.sql.functions import max as max_ CATALOG = "glue_catalog" DATABASE = "" TABLE = "<table>" BUCKET = "amzn-s3-demo-bucket" spark = SparkSession.builder \ .appName("IcebergUpsertExample") \ .config(f"spark.sql.catalog.{CATALOG}", "org.apache.iceberg.spark.SparkCatalog") \ .config("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \ .config(f"spark.sql.catalog.{CATALOG}.io-impl","org.apache.iceberg.aws.s3.S3FileIO") \ .config("spark.sql.defaultCatalog", CATALOG) \ .config(f"spark.sql.catalog.{CATALOG}.type", "glue") \ .getOrCreate() spark.sql(f""" CREATE TABLE IF NOT EXISTS {DATABASE}.{TABLE} ( timestamp TIMESTAMP, value LONG ) USING iceberg LOCATION 's3://{BUCKET}/warehouse' """) def backoff(attempt): """Exponential backoff with jitter""" exp_backoff = min(2 ** attempt, 60) jitter = random.uniform(0, 0.25 * exp_backoff) return exp_backoff + jitter def is_validation_exception(java_exception): """Check if exception is ValidationException""" cause = java_exception while cause is not None: if "org.apache.iceberg.exceptions.ValidationException" in str(cause.getClass().getName()): return True cause = cause.getCause() return False def upsert_with_retry(microBatchDF, batchId): max_retries = 5 attempt = 0 # Use a narrower key range to intentionally increase updates for the same value in MERGE transformedDF = microBatchDF \ .selectExpr("timestamp", "value % 20 AS value") \ .groupBy("value") \ .agg(max_("timestamp").alias("timestamp")) view_name = f"incoming_data_{batchId}" transformedDF.createOrReplaceGlobalTempView(view_name) while attempt < max_retries: try: spark.sql(f""" MERGE INTO {DATABASE}.{TABLE} AS t USING global_temp.{view_name} AS i ON t.value = i.value WHEN MATCHED THEN UPDATE SET t.timestamp = i.timestamp, t.value = i.value WHEN NOT MATCHED THEN INSERT (timestamp, value) VALUES (i.timestamp, i.value) """) print(f"[SUCCESS] Batch {batchId} processed successfully") return except Py4JJavaError as e: if is_validation_exception(e.java_exception): attempt += 1 if attempt < max_retries: delay = backoff(attempt) print(f"[RETRY] Batch {batchId} failed with ValidationException. " f"Retrying in {delay} seconds. Attempt {attempt}/{max_retries}") time.sleep(delay) else: print(f"[FAILED] Batch {batchId} failed after {max_retries} attempts") raise # Sample streaming query setup df = spark.readStream \ .format("rate") \ .option("rowsPerSecond", 10) \ .load() # Start streaming query query = df.writeStream \ .trigger(processingTime="20 seconds") \ .option("checkpointLocation", f"s3://{BUCKET}/checkpointLocation") \ .foreachBatch(upsert_with_retry) \ .start() query.awaitTermination() 2 つ目のサンプルは、AWS Glue Streaming ジョブで利用可能な GlueContext.forEachBatch を使用しています。リトライメカニズムの実装パターンは同じですが、主な違いは GlueContext を使った初期設定と、ストリーミング DataFrame を作成する方法です。このサンプルでは spark.readStream をレートソースと共に使用していますが、実際の AWS Glue Streaming ジョブでは、通常 glueContext.create_data_frame.from_catalog を使用して、 Amazon Kinesis や Kafka などのソースからストリーミング DataFrame を作成します。詳細については、 AWS Glue ストリーミング 接続 を参照してください。 <database_name> は実際のデータベース名、 <table_name> は実際のテーブル名、 amzn-s3-demo-bucket は 実際の S3 バケット名にそれぞれ置き換えてください。 import time import random from py4j.protocol import Py4JJavaError from pyspark.context import SparkContext from awsglue.context import GlueContext from pyspark.sql import SparkSession from pyspark.sql.functions import max as max_ CATALOG = "glue_catalog" DATABASE = "<database_name>" TABLE = "<table_name>" BUCKET = "amzn-s3-demo-bucket" spark = SparkSession.builder \ .appName("IcebergUpsertExample") \ .config(f"spark.sql.catalog.{CATALOG}", "org.apache.iceberg.spark.SparkCatalog") \ .config("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \ .config(f"spark.sql.catalog.{CATALOG}.io-impl","org.apache.iceberg.aws.s3.S3FileIO") \ .config("spark.sql.defaultCatalog", CATALOG) \ .config(f"spark.sql.catalog.{CATALOG}.type", "glue") \ .getOrCreate() sc = spark.sparkContext glueContext = GlueContext(sc) spark.sql(f""" CREATE TABLE IF NOT EXISTS {DATABASE}.{TABLE} ( timestamp TIMESTAMP, value LONG ) USING iceberg LOCATION 's3://{BUCKET}/warehouse' """) def backoff(attempt): exp_backoff = min(2 ** attempt, 60) jitter = random.uniform(0, 0.25 * exp_backoff) return exp_backoff + jitter def is_validation_exception(java_exception): cause = java_exception while cause is not None: if "org.apache.iceberg.exceptions.ValidationException" in str(cause.getClass().getName()): return True cause = cause.getCause() return False def upsert_with_retry(batch_df, batchId): max_retries = 5 attempt = 0 transformedDF = batch_df.selectExpr("timestamp", "value % 20 AS value") \ .groupBy("value") \ .agg(max_("timestamp").alias("timestamp")) view_name = f"incoming_data_{batchId}" transformedDF.createOrReplaceGlobalTempView(view_name) while attempt < max_retries: try: spark.sql(f""" MERGE INTO {DATABASE}.{TABLE} AS t USING global_temp.{view_name} AS i ON t.value = i.value WHEN MATCHED THEN UPDATE SET t.timestamp = i.timestamp, t.value = i.value WHEN NOT MATCHED THEN INSERT (timestamp, value) VALUES (i.timestamp, i.value) """) print(f"[SUCCESS] Batch {batchId} processed successfully") return except Py4JJavaError as e: if is_validation_exception(e.java_exception): attempt += 1 if attempt < max_retries: delay = backoff(attempt) print(f"[RETRY] Batch {batchId} failed with ValidationException. " f"Retrying in {delay} seconds. Attempt {attempt}/{max_retries}") time.sleep(delay) else: print(f"[FAILED] Batch {batchId} failed after {max_retries} attempts") raise # Sample streaming query setup streaming_df = spark.readStream \ .format("rate") \ .option("rowsPerSecond", 10) \ .load() # In actual Glue Streaming jobs, you would typically create a streaming DataFrame like this: """ streaming_df = glueContext.create_data_frame.from_catalog( database = "database", table_name = "table_name", transformation_ctx = "streaming_df", additional_options = { "startingPosition": "TRIM_HORIZON", "inferSchema": "false" } ) """ glueContext.forEachBatch( frame=streaming_df, batch_function=upsert_with_retry, options={ "windowSize": "20 seconds", "checkpointLocation": f"s3://{BUCKET}/checkpointLocation" } ) 操作のスコープを絞り、競合の可能性を最小化する メンテナンス操作 (コンパクションや更新など) を実行する際は、他の操作との重複を最小限に抑えるため、スコープを絞ることをお勧めします。たとえば、日付でパーティション分割されたテーブルで、ストリーミングジョブが最新の日付のデータを継続的に上書きする場合を考えてみましょう。以下は、テーブル全体をコンパクションするために rewrite_data_files プロシージャを実行するサンプルスクリプトです。 # Example of broad scope compaction spark.sql(""" CALL catalog_name.system.rewrite_data_files( table => 'db.table_name' ) """) where 句でデータ分割フィルターを使用してコンパクション範囲を狭めることで、ストリーミングデータ取り込みとコンパクション操作の競合を回避できます。ストリーミングジョブは最新のパーティションで動作を続けられる一方で、コンパクションは過去のデータを処理できます。 # Narrow down the scope by partition spark.sql(""" CALL catalog_name.system.rewrite_data_files( table => 'db.table_name', where => 'date_partition < current_date' ) """) 結論 Iceberg での同時書き込みを適切に管理するには、テーブルのアーキテクチャと様々な競合シナリオを理解する必要があります。この投稿では、本番環境で信頼できる競合処理メカニズムを実装する方法を探りました。 最も重要な概念は、カタログコミット競合とデータ競合の違いを覚えておくことです。カタログコミット競合は自動再試行とテーブルプロパティの設定で対処できますが、データ競合には独自の処理ロジックを慎重に実装する必要があります。これは、 rewrite_data_files で where 句を使用してスコープを絞ることで競合の可能性を大幅に低減できるため、コンパクション (compaction) などのメンテナンス操作を実装する際に特に重要になります。 ストリーミングパイプラインでの成功の鍵は、競合の種類を区別し、適切に対応するためのエラー処理を実装することにあります。これには、テーブルプロパティを通じて適切な再試行設定を構成し、ワークロードの特性に合わせたバックオフ戦略を実装することが含まれます。適切なタイミングでメンテナンス操作を組み合わせることで、同時書き込みを確実に処理できる、耐障害性の高いデータパイプラインを構築できます。 これらのパターンを適用し、Iceberg の同時実行モデルの基本的なメカニズムを理解することで、データの整合性と信頼性を維持しながら、同時書き込みシナリオを効果的に処理できるロバストなデータパイプラインを構築できます。 著者について 疋田 宗太郎 : アナリティクスソリューションアーキテクトです。幅広い業界の顧客に対し、アナリティクスプラットフォームの構築と運用をより効果的に行えるようサポートしています。特に、ビッグデータ技術とオープンソースソフトウェアに情熱を持っています。 関山 宜孝 : AWS Glue チームのプリンシパル ビッグデータ アーキテクトです。東京を拠点に活動しています。顧客を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇時間には、ロードバイクで走ることを楽しんでいます。

本記事は 2025 年 4 月 10 日に公開された “ Announcing inline chat in Eclipse with Amazon Q Developer ” を翻訳したものです。 本日 (原文公開日 : 2025/4/10)、 Amazon Q Developer は Eclipse IDE でのインラインチャット機能（プレビュー版）をリリースしました。この記事では、既存コードのリファクタリングからパフォーマンスが重要なメソッドの最適化まで、この強力な新機能を使って Java 開発作業を効率化する方法をご紹介します。Eclipse のベテランユーザーでも、これから始める方でも、 Amazon Q Developer の高度な AI を活用したツールがソフトウェア開発ライフサイクル全体を通じて生産性を向上させる方法をご覧いただけます。 背景 長年の Java 開発者として、昨年 Amazon Q Developer が Eclipse に統合された ときにとても興奮しました。私は Amazon Q Developer をしばらく使用していますが、これによって開発方法が完全に変わりました。 Amazon Q Developer が 2022 年にインライン提案機能を最初にリリースした とき、コーディング作業がどれだけ加速できるかに驚きました。しかし、 2023 年に完全なチャットインターフェイスが追加された ことで、さらに次のレベルへと進化しました。そして 2024 年には、 新しいインラインチャット機能によってコードをその場で編集・リファクタリングできるようになりました。 しかし、今日(原文公開日 : 2025/4/10)までインラインチャットは Eclipse では利用できませんでした！ Amazon Q Developer の チャットインターフェイス は、特定のタスクをどう進めればいいのかわからないときに頼りになります。解決しようとしている問題や理解しようとしている概念を説明すると、正しい方向へ導くための、詳細なコンテキストに基づいた回答が得られることが、とても気に入っています。AI が生成するコードスニペットと説明は、新しいことを学んだり複雑な課題に取り組んだりするときに、とても価値があります。しかし、タスクの実行方法がわかっているときは、説明は要らず、コードだけが欲しいのです。 一方で、よく理解しているタスクに取り組んでいるときは、 Amazon Q Developer の インライン提案 を使いたいと感じます。既存のコードやコメントを分析して関連性の高いカスタマイズされた補完を提供してくれるので、本当に素晴らしいです。コンテキストを切り替えたり、正しい構文を探したりすることなく、新しい機能をより速く開発できます。ただし、インライン提案は新しいコードの生成には優れていますが、既存のコードの編集には使用できません。 今回、 Eclipse での新しい インラインチャット 機能（プレビュー版）により、 Amazon Q Developer を使用してコードをその場で簡単に編集できるようになりました。別のチャットウィンドウからコードをコピー＆ペーストする必要はありません。エディター内で直接変更したい内容を説明するだけで、 Amazon Q Developer が Amazon Q Developer によって提案された更新がコードベースに差分としてシームレスに統合されます。この機能はリファクタリング、バグ修正、ドキュメントの整備、そしてコードの可読性の維持にといった作業にとても役立ちます。それでは、Eclipse でインラインチャットがどのように機能するか、いくつかの例を見てみましょう。 リファクタリング 開発チームの新メンバーとして、 OrderProcessor クラスにユニットテストを追加するタスクを任されたと想像してみましょう。しかし、コードベースを調べていくと、 OrderProcessor が OrderRepository の実装に密結合していることに気づきました。以下の画像の 2 行目で OrderRepository を直接インスタンス化しているのが確認できます。これにより、モックリポジトリを簡単に差し替えることができず、ユニットテストの作成が困難でした。依存性注入を使用するようにコードをリファクタリングする必要があることはわかっていましたが、その変更をすべて手動で行うことはとても大変でした。 幸いなことに、 Eclipse IDE の Amazon Q Developer のインラインチャットのおかげで、このリファクタリングに一人で立ち向かう必要はありませんでした。 OrderProcessor クラスを選択し、キーボードショートカット（macOS では CMD + SHIFT + I、Windows では CTRL + SHIFT + I）を使用してインラインチャットを呼び出しました。そして、「このクラスに依存性注入（Dependency Injection : DI）を使うようリファクタリングして。 OrderRepository をモック化してユニットテストしたい。」と変更内容を説明しました。特定の DI フレームワーク（Hibernate など）を活用するよう Amazon Q Developer に指示することもできましたが、このブログ記事ではシンプルに進めることにします。 Amazon Q Developer はコードをすばやく分析し、以下の画像のように変更を提案しました。変更は差分として表示され、 Amazon Q Developer が削除する部分（赤色）と追加する部分（緑色）を一目で確認できます。変更をレビューすると、 Amazon Q Developer が IOrderRepository インターフェイスを受け取るコンストラクタを導入し、具体的な実装またはテストダブルのいずれかを渡せるようにしていることがわかりました。これにより、 OrderProcessor の包括的なユニットテストを簡単に作成できるようになります。「Accept」をクリックするだけで、 Amazon Q Developer がコードを更新し、時間を大幅に節約し、かつ堅牢でテスト可能な設計の上に新しい機能が構築できるのです。。 今回の例では、クラス全体を選択しました。しかし、コードの特定の部分に対して Q Developer に作業を依頼することもできます。 最適化 Order クラスに取り組んでいるとき、 containsItem メソッドの実行が遅いことに気づきました。とくに多数の明細項目を持つ注文に対してその事象が発生していました。コードをプロファイリングしたところ、そのメソッドがホットスポットとなり、過剰な量の CPU サイクルを消費していることがわかりました。そこで、 containsItem メソッドを選択し、インラインチャットを表示して、 Amazon Q Developer に「このコードの実行が遅いので、最適化してください」と依頼しました。 Amazon Q Developer は、すぐに既存のコードを分析しました。このコードはリスト内の項目を反復処理するために、単純な for ループを使用しており、そこ対して改良された実装を提供しました。差分に示されているように、 Amazon Q Developer は for ループをより効率的なストリームベースのアプローチに置き換え、 anyMatch メソッドを使用して注文内に項目が存在するかどうかを判断する実装を提案しました。この変更により、とくに多数の明細項目を持つ注文のパフォーマンスが向上しました。私は変更を確認し、 Amazon Q Developer の提案を受け入れました。（※訳者注 : あくまで分かりやすい例としての記載であり、実際にパフォーマンスが上がるかどうかはデータの量などによって変わります。） Amazon Q Developer の最適化により、 containsItem メソッドのパフォーマンスが向上しただけでなく、コードの可読性と保守性も向上しました。 まとめ Amazon Q Developer の Eclipse IDE への統合（プレビュー版）により、私の Java 開発の作業が効率化し、改善されました。新しい概念の学習、ボイラープレートコードの生成、パフォーマンスのボトルネックの最適化など、 Amazon Q Developer の AI を活用したツール群は、私の開発プロセスに欠かせない存在となっています。とくにインラインチャットの追加により、アシスタントと直接やりとりし、集中力を途切れさせることなくコードベースを直接更新できるようになったのは大きな変化です。もし、あなたが Eclipse ユーザーで、生産性をさらに向上させたいと考えているなら、 Amazon Q Developer プラグインを今すぐインストール することを強くオススメします。 翻訳はApp Dev Consultantの宇賀神が担当しました。

本記事は 2025 年 5 月 6 日に公開された “ Accelerate development workflows to reduce release cycles using the Amazon Q Developer integration for GitHub (Preview) ” を翻訳したものです。 開発サイクルを短縮するためタスクを自動実行できる Amazon Q Developer for GitHub （プレビュー）は、AWS アカウントが不要で無料利用できます。 Amazon Q Developer は GitHub.com と GitHub Enterprise Cloud での機能開発を加速します。追加コストなしで Q Developer を支える高性能モデルを活用し、新機能の自動実装、バグの修正、テストカバレッジの向上、ドキュメント作成、すべての新しい Pull Request に対するコードレビューの実行、レガシー Java アプリケーションのモダナイズを行うことができます。これらは GitHub 上にある Issue と Pull Request を使用しながら実現できます。 背景 開発チームは、要件定義、開発、デプロイを協力して行う際に、複数のツールやコンテキストを行き来しながら、増え続ける課題に直面しています。バグ修正、コードレビュー、単体テストの作成、アップグレード管理といった定型作業に貴重な時間が費やされています。アプリケーションの規模が拡大するにつれ、これらの活動は開発者の生産性やセキュリティのベストプラクティスの維持にますます影響を与えています。 多くの開発者と同様に、皆様も DevOps ワークフローに GitHub を使用されていることでしょう。そのため、Amazon Q Developer の GitHub への統合を発表できることを大変嬉しく思います。AI 駆動の支援を、使い慣れた GitHub 環境に直接組み込むことで、コンテキスト切り替えを排除し、より迅速に作業を進め、セキュリティと運用の卓越性を維持しながらイノベーションに集中することができます。そのような開発の未来がここに到来しました！ はじめに Amazon Q Developer for GitHub の開始は簡単です。Organization の管理者は GitHub Marketplace を通じて Amazon Q Developer アプリケーションを迅速にデプロイし、リポジトリアクセスと AI エージェント設定を管理できます。個々の開発者は Organization のセットアップ後すぐにサービスの使用を開始できます。AWS アカウントの設定は必要ありません。 設定が完了すると、開発者は GitHub の Issue に “Amazon Q development agent” または “Amazon Q transform agent” ラベルを追加するだけで Amazon Q Developer のサポートを受けることができます。Pull Request が作成された後、開発者は Amazon Q Developer の Pull Request に自然言語でコメントすることで、生成されたコードを Amazon Q Developer と共に改善することができます。 Amazon Q Developer for GitHub の仕組み 1. 機能開発エージェント Amazon Q Developer は自然言語による説明から本番環境対応のコードを生成することで機能開発やバグ修正を簡素化します。開始するには GitHub の Issue に “Amazon Q development agent” ラベルを追加するだけです。ラベル付けされると Amazon Q Developer は要件と既存のコードベースを分析してコンテキストを理解します。その後新しいブランチを作成し、プロジェクトの確立されたパターンとベストプラクティスに従ったコードを生成します。 図 1 – “Amazon Q development agent“ ラベルを追加した Issue の作成 図 2 – Amazon Q Developer によって作成された Pull Request と変更内容の説明 図 1 に示すように、”Add an option to delete a task on the screen (画面上にタスクを削除するオプションを追加する)” というタイトルで Issue を作成し、”Amazon Q development agent” ラベルを適用すると、エージェントは処理を開始します。エージェントはリクエストを分析し、図 2 に示すように詳細な変更内容とセキュリティレビューを含む提案されたコード変更を含む Pull Request を作成します。 2. Transformation エージェント Amazon Q Developer は開発チームがアプリケーションをモダナイズし、自動化されたコードのアップグレードを通じて技術的負債を削減するのを支援します。このエージェントは現在、Java アプリケーションをバージョン 8 または 11 から Java 17 へアップグレードすることをサポートしており、API の変更や非推奨化を自動的に処理します。新しい言語機能を活用するためにコードを自動的に更新しながら、アプリケーションの既存機能を維持し、メジャーバージョンアップグレードに通常伴う時間とリスクの両方を削減します。 コード変換を開始する前に、 ドキュメント に記載されている前提条件とセットアップ手順を確認してください。 図 3 – “Amazon Q development agent” ラベルで作成された Issue 図 4 – コード変換のサマリが記載された Pull Request の作成 図 5 – Pull Request のファイル変更点 図 3 に示すように、“Migrate project from Java 8 to Java 17 (プロジェクトを Java 8 から Java 17 に移行する)” というタイトルの課題を作成し、”Amazon Q development agent” ラベルを適用すると、Amazon Q Developer はアップグレードプロセスを開始します。エージェントは図 4 と図 5 に示すように、すべての変更と実装手順を詳細に記録した Pull Request を作成します。 3. コードレビュー エージェント Amazon Q Developer は Pull Request レビューのプロセスを効率化し、自動コード分析を提供します。これによりチームはレビューサイクルを削減し、開発の早い段階で潜在的な問題を発見できます。Pull Request が作成されると、エージェントは自動的に以下の点についてコードを分析します: 品質の問題と潜在的なバグ セキュリティの脆弱性 公開された機密情報や重要情報 図 6 – Pull Request の自動コードレビュー 図 6 に示すように、エージェントは包括的なセキュリティレビューを実施し、詳細かつ実行可能なフィードバックを提供します。この例では、ハードコードされた SECRET_KEY を特定し、改善計画を提案しました。エージェントの推奨事項には以下が含まれています： 明確さのためのキーの名前変更 機密データを環境変数に移動 将来の改善のためのドキュメント追加 安全なキー管理のためのベストプラクティスの提案 エージェントは、ソースコードから機密情報を削除し、キーのローテーションを容易にし、コードの保守性を向上させることで、これらの変更がセキュリティをどのように改善するかを説明しました。また、安全な設定ファイルの使用や適切なエラー処理の実装など、本番環境のセキュリティを強化するための追加ステップも推奨しています。 このレベルの詳細なガイダンスを提供することで、コードレビューエージェントはチームがすばやくセキュリティ問題に対処し、開発者が AWS セキュリティのベストプラクティスを実装するのを支援するように設計されています。この自動化された詳細なレビュープロセスは、手動コードレビューに費やす時間を削減しながら、全体的なコード品質とセキュリティを向上させるのに役立ちます。 アンイストール GitHub Organization から Amazon Q Developer をアンインストールするには、 アプリのインストールページ に移動して “Configure“ を選択します。“Uninstall Amazon Q Developer” を選択すると、以前に選択したすべてのリポジトリから連携が完全に削除されます。 次のステップ この Amazon Q Developer for GitHub (プレビュー) は企業のソフトウェア開発を強化することを目的としています。Amazon Q Developer は AI を活用したエージェント機能を GitHub にもたらし、チームが高品質基準を維持しながら技術的負債を減らしつつ、より良いコードをより速く提供できるよう支援します。 この統合は GitHub の Issue、Pull Request、Commentなどの標準ワークフローを使用します。チームは確立された開発プラクティスを妨げることなく Amazon Q Developer のメリットを享受できます。 開発ワークフローを強化する準備はできていますか？ GitHub Marketplace にアクセスして、今すぐ GitHub での Amazon Q Developer の利用を開始しましょう。 翻訳はソリューションアーキテクトの小森谷が担当しました。 著者について Madhu Balaji Madhu is a Senior Specialist Solutions Architect at AWS who helps customers design and implement innovative cloud solutions. With 20+ years of experience in development and application architecture, he focuses on enabling customers to accelerate their time-to-market and solve complex business challenges using AWS services.

5 月 7 日、 Amazon Web Services (AWS) は、2026 年末までにチリに新しい AWS リージョン を開設する計画を発表しました。AWS 南米 (チリ) リージョンは、開設時に 3 つの アベイラビリティーゾーン で構成される予定です。これにより、チリのお客様には、 AWS インフラストラクチャ とサービスを、より近い場所でご利用いただけるようになります。この新しいリージョンは、 AWS 南米 (サンパウロ) リージョンと AWS メキシコ (中部) リージョン に続き、ラテンアメリカにおける 3 つ目の AWS リージョンとなります。各アベイラビリティーゾーンは、低レイテンシーを必要とするアプリケーションをサポートするために十分な距離を保って相互に離れており、単一のイベントが可用性に影響を及ぼすリスクを大幅に軽減します。 ラスコンデスの金融街にある近代的なオフィスビルが立ち並ぶ、チリのサンティアゴのスカイライン 新しい AWS リージョンにより、ラテンアメリカのお客様には、 AI や 機械学習 (ML) などの高度なクラウドテクノロジーを、より近い場所でご利用いただけるようになります。このリージョンは、完全に冗長化された専用ファイバー経由の高帯域幅かつ低レイテンシーのネットワーク接続を通じて、同期レプリケーションを必要とするアプリケーションをサポートすると同時に、データレジデンシー要件を満たせるよう、ワークロードの実行とデータのローカル保存における柔軟性を提供します。 チリにおける AWS 2017 年、AWS はチリのサンティアゴにオフィスを設立し、現地のお客様とパートナーをサポートしています。現在、サンティアゴのオフィスでは、ビジネス開発チーム、ソリューションアーキテクト、パートナーマネージャー、プロフェッショナルサービスコンサルタント、サポートスタッフ、および他のさまざまな役割を担うスタッフが勤務しています。 チリに対する継続的なコミットメントの一環として、AWS は、チリ全土で複数のインフラストラクチャオファリングに投資してきました。2019 年、AWS は チリに Amazon CloudFront エッジロケーション を開設しました。これにより、非常に安全でプログラム可能なコンテンツ配信ネットワークが提供され、低レイテンシーと高速転送により、世界中のユーザーに対する、データ、動画、アプリケーション、API の配信が高速化されます。 AWS は 2021 年に 2 つの重要な追加により、その存在感を強化しました。1 つ目は、 プンタアレーナスの AWS Ground Station アンテナ拠点 です。これは、衛星通信、データ処理、グローバルな衛星運用のスケーリングのためのフルマネージドサービスを提供します。2 つ目は、 チリの AWS Outposts です。これは、一貫したハイブリッドエクスペリエンスを実現するために、フルマネージド AWS インフラストラクチャおよびサービスを、事実上あらゆるオンプレミスまたはエッジロケーションで利用できるようにします。 2023 年、AWS は 2 つの重要な開発により、インフラストラクチャをさらに強化しました。1 つは、AWS と、お客様のデータセンター、オフィス、またはコロケーション環境の間でプライベート接続を確立できるようにする チリの AWS Direct Connect ロケーション であり、もう 1 つは、コンピューティング、ストレージ、データベース、および他の厳選されたサービスを、人口密集地や IT ハブの近くで利用できるようにする、 サンティアゴの AWS Local Zones です。サンティアゴの AWS Local Zone は、お客様が 1 桁ミリ秒のレイテンシーを必要とするアプリケーションをエンドユーザーに提供するのに役立ちます。 今後開設予定の AWS 南米 (チリ) リージョンは、チリにおけるイノベーションの推進に対する当社の継続的なコミットメントを表すものです。AWS は、インフラストラクチャの構築を超えて、包括的なクラウド教育イニシアティブを通じて、チリのデジタルワークフォースの育成においても重要な役割を果たしています。 AWS Academy 、 AWS Educate 、 AWS Skill Builder を通じて、AWS は、学生やデベロッパーから、ビジネスプロフェッショナルや新進の IT リーダーまで、必要不可欠なクラウドコンピューティングスキルを多様なグループに提供しています。2017 年以降、AWS は、ラテンアメリカ全域で 200 万を超える人々にクラウドスキルのトレーニングを提供してきました。これには、チリの 10 万人超も含まれています。 チリの AWS のお客様 チリの AWS のお客様はますます、アプリケーションを AWS に移行し、世界中の AWS リージョンでテクノロジーインフラストラクチャを運用するようになっています。この新しい AWS リージョンの追加により、お客様は、さらに低いレイテンシーをエンドユーザーに提供し、生成 AI、モノのインターネット (IoT)、モバイルサービス、銀行業界などの高度なテクノロジーを利用してイノベーションを推進できるようになります。このリージョンを利用することで、AWS のお客様は、チリでワークロードを実行したり、コンテンツを保存したりできます。 AWS を利用してイノベーションを推進しているチリのお客様の例をいくつかご紹介します: Digital Government Secretariat (SGD) は、デジタル政府戦略の提案と実施の調整を担当し、統合的な政府アプローチを提供するチリの政府機関です。SGD は、行政やサービスの提供を改善するために、デジタルテクノロジー、データ、公共情報の戦略的な利用において、調整および助言したり、セクター横断的なサポートを提供したりしています。このミッションを果たすため、SGD は AWS を利用して、 Clave Única (シングルサインオン) 、 FirmaGob (デジタル署名) 、 State Electronic Services Integration Platform (PISEE) 、 DocDigital 、 SIMPLE 、 Administrative Procedures and Services Catalog (CPAT) など、重要なデジタルプラットフォームを運用しています。 チリ最大の決済ソリューションエコシステムであり、国内取引の最も大きな割合を管理している Transbank は、AWS を利用して、新製品の市場投入までの時間を大幅に短縮しました。さらに、Transbank は AWS を利用した複数のソリューションを実装して、チームの生産性を高め、イノベーションを加速しました。これらの取り組みは、金融テクノロジー企業が AWS を利用してイノベーションと運用効率の向上を推進する方法を示しています。「チリの新しい AWS リージョンは、当社にとって非常に重要なものとなるでしょう」と Transbank の Chief Architecture and Technology Officer (CA&TO) である Jorge Rodríguez M. 氏は述べています。「このリージョンは、レイテンシーをさらに低減し、セキュリティを強化するとともに、イノベーションの可能性を拡大してくれるでしょう。これにより、当社は、より優れた新しいサービスと製品をお客様に提供できるようになります」。 チリの AWS のお客様の詳細については、 AWS のお客様の成功事例 にアクセスしてください。 チリにおける AWS のサステナビリティへの取り組み AWS は、革新的な保全プロジェクトを通じて、チリにおける水資源管理に取り組んでいます。サンティアゴ首都圏やバルパライソ地域に不可欠な水を供給するマイポ川流域において、AWS は、現地の農家や 気候テック企業である Kilimo と連携し、節水の取り組みを実施しています。このプロジェクトでは、67 ヘクタールの農地を湛水灌漑から点滴灌漑に転換します。これにより、年間約 2 億リットルの水が節約される予定です。 この節水活動は、2030 年までにウォーターポジティブとなることを目指す AWS のコミットメントを支えるものであり、AWS が事業を展開するコミュニティにおける環境の持続可能性への当社の取り組みを示すものです。このプロジェクトでは、専用の配管網を通して植物の根系に直接水を供給する効率的な点滴灌漑システムを採用し、農業用水効率を最大化しています。この取り組みの詳細については、ブログ記事「 AWS expands its water replenishment program to China and Chile—and adds projects in the US and Brazil 」をお読みください。 チリの AWS コミュニティ チリの AWS コミュニティは、この地域で最もアクティブなコミュニティの 1 つであり、 AWS Community Builders 、2 つの AWS User Group ( AWS User Group Chile と AWS Girls Chile )、 AWS Cloud Club で構成されています。これらのグループは毎月イベントを開催し、2 回の AWS Community Day を企画しました。2023 年に開催された最初の Community Day では、 Jeff Barr を基調講演のスピーカーとして迎えました。 Chile AWS Community Day 2023 引き続きご期待ください このリージョンや他のリージョンの開設については、今後のブログ記事でお知らせします。ご期待ください! 詳細については、 チリの AWS リージョンのページ にアクセスしてください。 – Eli Chile AWS Community Day 2023 の写真を提供してくださった Leonardo Vilacha 氏に感謝いたします。 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 6 日、 Amazon Elastic Block Store (Amazon EBS) のボリューム初期化のプロビジョンドレートの一般提供の開始を発表しました。これは、 Amazon Simple Storage Service (Amazon S3) に保存されたボリュームの耐久性の高いバックアップである EBS スナップショットから新しい EBS ボリュームへのデータ転送を高速化する機能です。 Amazon EBS のボリューム初期化のプロビジョンドレートを使用すると、予測可能な時間内に、完全にパフォーマンスを発揮できる状態になった EBS ボリュームを作成できます。この機能を使用すると、数百の同時ボリュームとインスタンスの初期化を高速化できます。また、既存の EBS スナップショットから復旧する必要があり、EBS ボリュームを可能な限り迅速に作成して初期化する必要がある場合にも、この機能を使用できます。この機能を使用すると、別のアベイラビリティーゾーン、AWS リージョン、または AWS アカウントで、EBS スナップショットを含む EBS ボリュームのコピーを迅速に作成できます。ボリュームごとのボリューム初期化のプロビジョンドレートは、スナップショット全体のサイズと、指定されたボリューム初期化レートに基づいて課金されます。 この新機能は、100 MiB/秒から 300 MiB/秒の間で指定した一定のレートで、EBS スナップショットから EBS ボリュームにデータを取得することで、ボリューム初期化プロセスを高速化します。このボリューム初期化レートは指定可能であり、スナップショットブロックはこのレートで Amazon S3 からボリュームにダウンロードされます。 ボリューム初期化レートを指定することで、予測可能な時間内に、完全にパフォーマンスを発揮できる状態になったボリュームを作成できるため、運用効率を高め、想定完了時刻を明確化できます。アプリケーションのリカバリやテストおよび開発用のボリュームコピーなどのワークフローで、 fio / dd などのユーティリティを実行してボリューム初期化を高速化することで、ワークフローの一貫性と予測可能性を維持しながら、そのようなスクリプトの管理に伴う運用上の負担を軽減できます。 ボリューム初期化レートの指定を開始する 開始するには、EC2 インスタンスを起動するとき、またはスナップショットからボリュームを作成するときに、ボリューム初期化レートを選択できます。 1.EC2 起動ウィザードでボリュームを作成する EC2 コンソール の起動ウィザードで新しい EC2 インスタンスを起動する際に、 [ストレージ (ボリューム)] セクションで希望する [ボリューム初期化レート] を入力できます。 また、 EC2 起動テンプレート を作成および変更する際にも、ボリューム初期化レートを設定できます。 AWS コマンドラインインターフェイス (AWS CLI) では、 run-instances コマンドを呼び出す際に、ブロックデバイスマッピングに VolumeInitializationRate パラメータを追加できます。 aws ec2 run-instances \ --image-id ami-0abcdef1234567890 \ --instance-type t2.micro \ --subnet-id subnet-08fc749671b2d077c \ --security-group-ids sg-0b0384b66d7d692f9 \ --key-name MyKeyPair \ --block-device-mappings file://mapping.json mapping.json の内容。この例では、サイズが 8 GiB の空の EBS ボリューム ( /dev/sdh ) を追加します。 [ { "DeviceName": "/dev/sdh", "Ebs": { "VolumeSize": 8 "VolumeType": "gp3", "VolumeInitializationRate": 300 } } ] 詳細については、 ブロックデバイスマッピングのオプション にアクセスしてください。これは、インスタンスの起動時にアタッチする EBS ボリュームとインスタンスストアボリュームを定義します。 2.スナップショットからボリュームを作成する スナップショットからボリュームを作成する場合は、 EC2 コンソール で [ボリュームを作成] を選択し、 [ボリューム初期化レート] を指定することもできます。 初期化レートで新しいボリュームを確認します。 AWS CLI では、 create-volume コマンドを呼び出す際に、 VolumeInitializationRate パラメータを使用できます。 aws ec2 create-volume --region us-east-1 --cli-input-json '{ "AvailabilityZone": "us-east-1a", "VolumeType": "gp3", "SnapshotId": "snap-07f411eed12ef613a", "VolumeInitializationRate": 300 }' コマンドが正常に実行されると、以下の結果が表示されます。 { "AvailabilityZone": "us-east-1a", "CreateTime": "2025-01-03T21:44:53.000Z", "Encrypted": false, "Size": 100, "SnapshotId": "snap-07f411eed12ef613a", "State": "creating", "VolumeId": "vol-0ba4ed2a280fab5f9", "Iops": 300, "Tags": [], "VolumeType": "gp2", "MultiAttachEnabled": false, "VolumeInitializationRate": 300 } EC2 インスタンスのルートボリュームを置き換えたり、 EBS コンテナストレージインターフェイス (CSI) ドライバー を使用して EBS ボリュームをプロビジョニングしたりする際に、ボリューム初期化レートを設定することもできます。 ボリュームの作成後、EBS はハイドレーションの進行状況を追跡し、ハイドレーションが完了するとアカウントに EBS についての Amazon EventBridge 通知 を発行します。これにより、ボリュームが完全にパフォーマンスを発揮できる状態になったことを確認できます。 詳細については、「Amazon EBS ユーザーガイド」の「 Create an Amazon EBS volume 」と「 Initialize Amazon EBS volumes 」にアクセスしてください。 今すぐご利用いただけます Amazon EBS のボリューム初期化のプロビジョンドレートが、本日からすべての EBS ボリュームタイプでご利用可能になり、サポートされるようになりました。スナップショット全体のサイズと、指定されたボリューム初期化レートに基づいて課金されます。 詳細については、「 Amazon EBS の料金 」のページにアクセスしてください。 この機能を含む Amazon EBS の詳細については、AWS Skill Builder ポータルで無料のデジタルコースを受講してください。コースには、ユースケース、アーキテクチャ図、デモが含まれています。 今すぐ Amazon EC2 コンソール でこの機能をお試しいただき、 AWS re:Post for Amazon EBS に、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

この記事は A deep dive into Amazon EKS Hybrid Nodes (記事公開日: 2024 年 1 月 27 日) を翻訳したものです。 この記事は、AWS の Kubernetes Principal Product Manager である Chris Splinter、AWS の Sr. Container Specialist Solutions Architect である Elamaran Shanmugam、AWS の Containers Specialist Solutions Architect である Re Alvarez Parmar が執筆しました。 Amazon Elastic Kubernetes Service (Amazon EKS) の新機能である Amazon EKS Hybrid Nodes の一般提供を re:Invent 2024 で発表できることをうれしく思います。EKS Hybrid Nodes を使用すると、ユーザーはオンプレミスとエッジのインフラを Amazon EKS クラスターのノードとして使用できるため、クラウド・オンプレミス・エッジ環境にわたって統一された Kubernetes の管理体験を実現できます。これは、モダナイゼーション・機械学習(ML)・メディアストリーミング・製造ワークロードなど、さまざまなユースケースで使用できます。 AWS クラウドで、新規開発あるいはモダナイズされたアプリケーションのために Kubernetes を利用しているユーザーは、しばしばこれらの機能をオンプレミスおよびエッジ環境で実行されているアプリケーションの管理にまで拡張したいと考えています。これは、レイテンシーの低減、データ依存性、データ主権、規制、ポリシー上の理由からです。 これまで、オンプレミスのデータセンターやエッジ環境で Kubernetes を実行しようとするユーザーは、オープンソースの Kubernetes やそれに似たセルフマネージド Kubernetes ソリューションを実行および運用する必要がありました。 オンプレミスでの Kubernetes を自身で運用することは複雑で、運用上のオーバーヘッドを追加することになり、最終的にはイノベーションとモダナイゼーションの計画を遅らせることになります。 EKS Hybrid Nodes は、ユーザーがオンプレミスおよびエッジの既存のキャパシティをマネージドな Amazon EKS コントロールプレーンにノードとして接続できるようにすることで、その複雑さとオーバーヘッドを削減します。 これにより、オンプレミスでの Kubernetes の運用を効率化し、クラウドでワークロードを実行するためにユーザーが慣れ親しんだ EKS クラスター、機能、インテグレーション、ツールを使用して、オンプレミスでの一貫した運用体験が可能になります。 オーバービュー EKS Hybrid Nodes を使用するには、オンプレミスのネットワークと EKS クラスターのある Amazon Virtual Private Cloud (Amazon VPC) 間の接続が必要です。 AWS Direct Connect 、 AWS Site-to-Site VPN 、独自の VPN ソリューションを使用して、EKS クラスターとハイブリッドノード間のプライベート接続を作成できます。EKS Hybrid Nodes は、Amazon EKS のコントロールプレーンからワーカーノードへの通信に使用されている 既存の仕組み を再利用します。 したがって、 AWS リージョン 上の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとオンプレミス環境で実行されているハイブリッドノードの両方を、同じ EKS クラスター内で実行できます。 EKS Hybrid Nodes は「Bring Your Own Infrastructure」のアプローチを使用しており、ハイブリッドノードとして使用するインフラストラクチャとオペレーティングシステムのプロビジョニングと管理はお客様の責任となります。 既存のベアメタルサーバーまたは仮想化されたインフラストラクチャをハイブリッドノードのコンピューティングとして使用できます。現在、Amazon Linux 2023、Ubuntu、Red Hat Enterprise Linux (RHEL) が、ハイブリッドノードとの互換性のため AWS でサポートされているオペレーティングシステムです。 EKS Hybrid Nodes は、オンプレミスの各ホストで実行する EKS Hybrid Nodes CLI (nodeadm) を使用してインストールされ、EKS クラスターに接続できます。 あるいは、ハイブリッドノードのブートストラップの自動化のために、ゴールデン OS イメージに nodeadm とハイブリッドノードの依存関係を含めることができます。これは、クラウドの EC2 インスタンスの Amazon EKS 最適化 Amazon Machine Images (AMI) で使用される仕組みと同様です。 ハイブリッドノードが EKS クラスターへの接続を試みると、 AWS Systems Manager ハイブリッドアクティベーションまたは IAM Roles Anywhere によってプロビジョニングされた一時的な AWS Identity and Access Management (IAM) 認証情報を使用して、ハイブリッドノードを EKS コントロールプレーンに安全に接続します。 EKS Hybrid Nodes は、CoreDNS・kube-proxy・ Amazon Managed Service for Prometheus エージェントレススクレイパー・ AWS Distro for Open Telemetry ・CloudWatch Observability Agent・IAM Roles for Service Accounts (IRSA)・EKS Pod Identity など、クラスターネットワーキング、可観測性、Pod 認証のためのいくつかの Amazon EKS アドオンと機能もサポートしています。 Pod ネットワーキングの場合、ハイブリッドノードで使用するために Cilium と Calico Container Networking Interface (CNI) がサポートされています。 EKS Hybrid Nodes の仕組みの詳細については、 EKS Hybrid Nodes ユーザーガイド を参照してください。 アーキテクチャ EKS Hybrid Nodes を使用する前に、クラウドにホストされた Amazon EKS コントロールプレーンとお客様の環境で実行されているハイブリッドノード間のネットワークフローを理解する必要があります。ハイブリッドノードとそれらで実行されるリソースに使用するノードと Pod のネットワークは、IPv4 RFC-1918 Classless Inter-Domain Routing (CIDR) を使用する必要があります。 ハイブリッドノード対応の EKS クラスターを作成するときに、これらのオンプレミスのノードと Pod ネットワークの CIDR を渡します。VPC とオンプレミスのルーティングテーブルは、エンドツーエンドのハイブリッドノードのトラフィックフローのために、このようなネットワークで構成する必要があります。 ハイブリッドノードのネットワーキング要件の詳細については、Amazon EKS ユーザーガイドの「 ハイブリッドノード用のネットワークを準備する 」を参照してください。 図 1 : EKS Hybrid Nodes のハイブリッドネットワーキングアーキテクチャ 次の表は、ハイブリッドノードのネットワーキングアーキテクチャの主要な部分をまとめたものです。 環境 コンポーネント 説明 AWS リージョン EKS クラスター設定 ログ、kubectl exec、ポートフォワードなどの Kubernetes 操作のため、EKS コントロールプレーンと kubelet 間の通信に EKS クラスター RemoteNodeNetwork 設定が必要です。 AWS リージョン EKS クラスター設定 EKS コントロールプレーンと Webhook 間の通信には、 EKS クラスター設定 の RemotePodNetwork が必要です。 RemotePodNetwork は設定することをおすすめしますが、もしハイブリッドノードで Webhook を実行していない場合、厳密には必要ありません。 AWS リージョン EKS クラスター VPC VPC のルーティングテーブルには、VPC からのトラフィックの出口として使用しているゲートウェイをターゲットとして、 RemoteNodeNetwork および RemotePodNetwork を送信先とするルートが必要です。ゲートウェイは通常、 AWS Transit Gateway または Virtual Private Gateway (VGW) になります。 AWS リージョン EKS クラスター セキュリティグループ EKS コントロールプレーンへのインバウンドアクセスと、 RemoteNodeNetwork および RemotePodNetwork へのアウトバウンドアクセスを許可する必要があります。 オンプレミス オンプレミス ファイヤウォール EKS コントロールプレーンへのインバウンドアクセスと、 RemoteNodeNetwork および RemotePodNetwork へのアウトバウンドアクセスを許可する必要があります。 オンプレミス オンプレミス ルーター オンプレミスルーターは RemoteNodeNetwork および RemotePodNetwork へのトラフィックをルーティングできなければなりません。 オンプレミス Container Networking Interface (CNI) CNI で設定するオーバーレイネットワーク CIDR は、 RemotePodNetwork と同じでなければなりません。ホストネットワーキングを使用している場合は、ノード CIDR が RemoteNodeNetwork と同じである必要があります。 ウォークスルー このウォークスルーでは、Systems Manager ハイブリッドアクティベーションを使用してハイブリッドノードの IAM 認証情報を設定し、ハイブリッドノード対応の EKS クラスターを作成し、ハイブリッドノードを EKS クラスターに接続し、アプリケーションの実行準備が整うように Cilium CNI をインストールします。このウォークスルーでは、EKS クラスターの作成に AWS Command Line Interface (AWS CLI) と AWS CloudFormation を使用していますが、 AWS マネジメントコンソール 、eksctl CLI、 Terraform などの他のインターフェースを代わりに使用することもできます。 前提条件 このソリューションを完了するには、以下の前提条件が必要になります。 オンプレミス環境と AWS 間のハイブリッドネットワーク接続 物理マシンや仮想マシンなどのインフラストラクチャ ハイブリッドノードと互換性のあるオペレーティングシステム AWS CLI バージョン 2.22.8 以降、または適切な認証情報を持つ 1.36.13 以降 eksctl CLI このウォークスルーの手順を実行する IAM ユーザーは、次のアクションの IAM アクセス許可を持っている必要があります: iam:CreatePolicy 、 iam:CreateRole 、 iam:AttachRolePolicy 、 ssm:CreateActivation 、 eks:CreateCluster ハイブリッドノードのための認証情報の準備 クラウド上の EC2 インスタンスで動作している EKS ノードと同様に、ハイブリッドノードは EKS コントロールプレーンに接続するために IAM ロールを必要とします。次に、ハイブリッドノードの IAM ロールは、Systems Manager ハイブリッドアクティベーションまたは IAM Roles Anywhere とともに使用され、一時的な IAM 認証情報がプロビジョニングされます。一般的に、オンプレミス環境に既存の公開鍵基盤(PKI)と証明書がない場合は、Systems Manager ハイブリッドアクティベーションを推奨します。既存の PKI と証明書がある場合は、これらを IAM Roles Anywhere で使用できます。 ハイブリッドノードに使用する IAM ロールには、以下のアクセス許可が必要です。 ハイブリッドノードが EKS クラスターに接続する際に、EKS クラスターの情報を収集する必要があります。そのためには、ハイブリッドノード CLI ( nodeadm ) が eks:DescribeCluster アクションを実行するためのアクセス許可が必要です。 eks:DescribeCluster アクションを有効にしない場合は、 nodeadm init を実行するときに nodeadm に渡すノードの設定に、Kubernetes API エンドポイント、クラスター CA バンドル、サービス IPv4 CIDR を指定する必要があります。 AmazonEC2ContainerRegistryPullOnly ポリシーで定義されているような、 Amazon Elastic Container Registry (Amazon ECR) からコンテナイメージを取得する kubelet のためのアクセス許可が必要です。 Systems Manager を使用する場合は、 AmazonSSMManagedInstanceCore ポリシーで定義されているような nodeadm init が Systems Manager ハイブリッドアクティベーションを使用するためのアクセス許可と、 nodeadm uninstall でインスタンスの登録を解除するための ssm:DeregisterManagedInstance アクションと ssm:DescribeInstanceInformation アクションを使用するアクセス許可が必要です。 これらのステップでは、AWS CLI と CloudFormation を使用して、前述のアクセス許可を持つハイブリッドノードの IAM ロールを作成します。次に、AWS CLI を使用して、ハイブリッドノードの IAM ロールを使用して Systems Manager ハイブリッドアクティベーションを作成します。 まず最初に、CloudFormation テンプレートを AWS CLI を実行するマシンにダウンロードします。 curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ssm-cfn.yaml' Bash デフォルトでは、CloudFormation テンプレートは ssm:DeregisterManagedInstance のアクセス許可を、ハイブリッドノードの IAM ロールがクラスター用に作成したハイブリッドアクティベーションに関連付けられたインスタンスのみ登録解除できるよう制限しています。ハイブリッドノードの IAM ロールのアクセス許可で使用される SSMDeregisterConditionTagKey と SSMDeregisterConditionTagValue は、後のステップで示す Systems Manager ハイブリッドアクティベーションの作成時に適用するタグと対応している必要があります。 # Define environment variables EKS_CLUSTER_NAME = my-hybrid-cluster AWS_ACCOUNT_ID = $( aws sts get-caller-identity --query 'Account' --output text ) AWS_REGION = ${AWS_REGION := us-west-2} EKS_CLUSTER_ARN = arn:aws:eks: ${AWS_REGION} : ${AWS_ACCOUNT_ID} :cluster/ ${EKS_CLUSTER_NAME} ROLE_NAME = AmazonEKSHybridNodesRole # Create cfn-ssm-parameters.json cat << EOF > cfn-ssm-parameters.json { "Parameters": { "RoleName": " $ROLE_NAME ", "SSMDeregisterConditionTagKey": "EKSClusterARN", "SSMDeregisterConditionTagValue": " $EKS_CLUSTER_ARN " } } EOF Bash CloudFormation スタックをデプロイします。 AWS_REGION をハイブリッドアクティベーションを作成する希望の AWS リージョンに置き換えます。 ハイブリッドアクティベーションのリージョンは、EKS クラスターのリージョンと同じである必要があります。 aws cloudformation deploy \ --stack-name EKSHybridRoleSSM \ --region ${AWS_REGION} \ --template-file hybrid-ssm-cfn.yaml \ --parameter-overrides file://cfn-ssm-parameters.json \ --capabilities CAPABILITY_NAMED_IAM Bash ハイブリッドノードの IAM ロールを作成した後、次のステップはその IAM ロールを使用して Systems Manager ハイブリッドアクティベーションを作成することです。 デフォルトでは、Systems Manager ハイブリッドアクティベーションは 24 時間有効で、最大有効期限は 30 日です。 ハイブリッドアクティベーションを作成するときに、 2024-08-01T00:00:00 のようなタイムスタンプ形式で --expiration-date を指定できます。 Systems Manager を認証情報プロバイダーとして使用する場合、ハイブリッドノードのノード名は設定できず、 mi-012345678abcdefgh という形式で Systems Manager によって自動生成されます。Systems Manager コンソールのFleet Manager 下で、Systems Manager マネージドインスタンスを表示および管理できます。 次のコマンドを使用して、前のステップで作成した IAM ロールを --iam-role フラグで渡して、Systems Manager のハイブリッドアクティベーションを作成します。 前のステップで作成したハイブリッドノードの IAM ロールに設定された信頼ポリシーに対応するハイブリッドアクティベーションを作成するときに適用するタグに注意してください。Systems Manager の create-activation コマンドの出力は、後のステップで EKS クラスターにハイブリッドノードを接続するときに使用するアクティベーションコードとアクティベーション ID が含まれているので、必ず保存してください。 # Define environment variables EKS_CLUSTER_NAME = my-hybrid-cluster AWS_ACCOUNT_ID = $( aws sts get-caller-identity --query 'Account' --output text ) AWS_REGION = ${AWS_REGION := us-west-2} EKS_CLUSTER_ARN = arn:aws:eks: ${AWS_REGION} : ${AWS_ACCOUNT_ID} :cluster/ ${EKS_CLUSTER_NAME} ROLE_NAME = AmazonEKSHybridNodesRole # Create SSM hybrid activation aws ssm create-activation \ --region ${AWS_REGION} \ --default-instance-name eks-hybrid-nodes \ --description "Activation for EKS hybrid nodes" \ --iam-role ${ROLE_NAME} \ --tags Key = EKSClusterARN,Value = ${EKS_CLUSTER_ARN} \ --registration-limit 5 Bash ハイブリッドノードのための EKS クラスターを作成する これらのステップでは、AWS CLI と CloudFormation を使用して、EKS クラスターの IAM ロールとハイブリッドノード対応の EKS クラスターを作成します。 まず最初に、CloudFormation テンプレートを AWS CLI を実行するマシンにダウンロードします。 curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-eks-cfn.yaml' Bash デフォルトでは、CloudFormation テンプレートは EKS クラスターをプライベートエンドポイント接続で作成します。これは、Kubernetes API エンドポイントに VPC 内からのみアクセスできることを意味します。 パブリックエンドポイント接続が必要な場合は、CloudFormation パラメータファイルで ClusterEndpointConnectivity を Public に設定できます。 次の CloudFormation パラメータファイルの例では、ハイブリッドノードの要件を満たす既存のサブネットを使用しています。 これは、Direct Connect を介してオンプレミス環境に接続された Transit Gateway にアタッチされた VPC 内のサブネットです。 Amazon EKS は、EKS コントロールプレーンから VPC への接続性のために、提供されたサブネットに Elastic Network Interfaces (ENI) をアタッチします。 CloudFormation テンプレートは、 RemoteNodeCIDR 、 RemotePodCIDR 、EKS コントロールプレーンからのトラフィックを許可するセキュリティグループも作成します。 cfn-eks-parameters.json ファイル内の値を、ご自身の環境の値に置き換えてください。 cat << EOF > cfn-eks-parameters.json { "Parameters": { "ClusterName": "my-hybrid-cluster", "ClusterRoleName": "EKSHybridClusterRole", "SubnetId1": "subnet-0b65cdc4812345678", "SubnetId2": "subnet-02f526cd012345678", "VpcId": "vpc-0a5f3bee960d6ec71", "RemoteNodeCIDR": "10.80.150.0/24", "RemotePodCIDR": "10.80.2.0/23", "K8sVersion": "1.31" } } EOF Bash CloudFormation スタックをデプロイします。クラスターが作成される希望の AWS リージョンで AWS_REGION を置き換えます。 aws cloudformation deploy \ --stack-name EKSHybridCluster \ --region ${AWS_REGION} \ --template-file hybrid-eks-cfn.yaml \ --parameter-overrides file://cfn-eks-parameters.json \ --capabilities CAPABILITY_NAMED_IAM Bash クラスターのプロビジョニングには数分かかります。次のコマンドで CloudFormation スタックのステータスを確認できます。 aws cloudformation describe-stacks \ --stack-name EKSHybridCluster \ --region ${AWS_REGION} \ --query 'Stacks[].StackStatus' Bash EKS クラスターを作成したら、ハイブリッドノードの IAM ロールを使用して Amazon EKS アクセスエントリを作成します。これにより、ノードがクラスターに参加できるようになります。 詳細については、Amazon EKS ユーザーガイドの「 ハイブリッドノードのクラスターアクセスを準備する 」を参照してください。 # Define environment variables EKS_CLUSTER_NAME = my-hybrid-cluster ROLE_NAME = AmazonEKSHybridNodesRole # Create access entry with type HYBRID_LINUX aws eks create-access-entry \ --cluster-name ${EKS_CLUSTER_NAME} \ --principal-arn ${ROLE_NAME} \ --type HYBRID_LINUX Bash EKS クラスターへのハイブリッドノードのインストールと接続 ハイブリッドノードの IAM ロール、Systems Manager ハイブリッドアクティベーション、EKS Hybrid Nodes が有効化された EKS クラスターを作成した後に、EKS クラスターにハイブリッドノードを作成、アタッチする準備が整います。 x86_64 または ARM の物理マシンや仮想マシンで前提条件を満たしていれば、ハイブリッドノードとして使用できます。 インストール、設定、登録など、ハイブリッドノードのライフサイクル管理を簡略化するために設計された nodeadm と呼ばれる ハイブリッドノード CLI があります。AL2023 Amazon EKS 最適化 AMI に基づいて Amazon EKS 用のカスタム AMI を構築したことがある場合、 nodeadm にすでに慣れているかもしれません。 AL2023 Amazon EKS 最適化 AMI で使用されているクラウドバージョンの nodeadm は、ハイブリッドノードの nodeadm バージョンとは異なるため、デプロイしたい対象に基づいて適切なバージョンを使用する必要があることに注意してください。 ハイブリッドノード CLI はブートストラッププロセスで 2 つのステップを実行します。まず、ホスト上に必要な依存関係(kubelet、containerd、Systems Manager エージェント/IAM Roles Anywhere ツールなど) をインストールします。 次に、依存関係を構成し開始することで、ノードが EKS クラスターに参加できるようにします。Amazon EKS は Packer テンプレート を提供しており、これを使用して Ubuntu と RHEL のハイブリッドノード用のイメージを作成できます。ハイブリッドノードを繰り返し作成したり、ブートストラッププロセスを自動化したい場合は、事前構築済みのイメージを使用することで時間を節約し、個々のホストで依存関係の取得を個別のプロセスとして実行する必要がなくなります。 ハイブリッドノードの依存関係をインストールするには、 nodeadm install コマンドを実行します。 以下の例では、Kubernetes バージョン 1.31 と認証情報プロバイダーとして ssm を使用しています。 EKS Hybrid Nodes は、標準サポートと拡張サポートのもとにある Amazon EKS と同じ Kubernetes バージョンをサポートしています。 ホスト上で root/sudo 権限を持つユーザーで nodeadm を実行する必要があることに注意してください。 sudo nodeadm install 1.31 --credential-provider ssm 必要な依存関係がノードにあるときは、設定のため nodeConfig.yaml を作成します。ノードの設定ファイルには、クラスター情報と認証に使用されるメカニズム(Systems Manager ハイブリッドアクティベーションまたは IAM Roles Anywhere) の 2 つの主要な詳細の設定が含まれています。 以下は、Systems Manager ハイブリッドアクティベーションを使用するハイブリッドノードの nodeConfig.yaml ファイルの例です。 SSM_ACTIVATION_CODE と SSM_ACTIVATION_ID を、前の Systems Manager アクティベーションを作成するステップの出力値に置き換えてください。 apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-hybrid-cluster region: us-west-2 hybrid: ssm: activationCode: SSM_ACTIVATION_CODE activationId: SSM_ACTIVATION_ID Bash ハイブリッドノードを EKS クラスターに接続するには、 nodeConfig.yaml で nodeadm init コマンドを実行します。 sudo nodeadm init -c file://nodeConfig.yaml コマンドが正常に完了し、kubelet のログにエラーがない場合、ハイブリッドノードは EKS クラスターに参加したことになります。 これは、EKS クラスターの「 コンピュートタブ 」に移動 ( IAM プリンシパルが表示権限を持っていることを確認してください ) して EKS コンソールで確認するか、 kubectl get nodes で確認できます。 NAME STATUS ROLES AGE VERSION mi-036ecab1709d75ee1 Not Ready < none > 1h v1.31.2-eks-94953ac Bash クラスターに代替の CNI がまだインストールされていない場合、CNI がインストールされ実行されるまで、接続したノードは Not Ready 状態のままです。 ハイブリッドノードのために CNI をインストール ハイブリッドノードの CNI として Cilium と Calico がサポートされています。これらの CNI は、Helm などのツールを使って管理できます。 Amazon VPC CNI はハイブリッドノードと互換性がなく、VPC CNI はデフォルトで eks.amazonaws.com/compute-type: hybrid ラベルに対して Anti-Affinity が設定されています。 ハイブリッドノードで Cilium と Calico を運用する詳細については、Amazon EKSユーザーガイドの「 ハイブリッドノードの CNI を設定する 」を参照してください。 CNI の DaemonSets がハイブリッドノード上にのみスケジュールされることを保証するために、 nodeadm によってハイブリッドノードがクラスタに参加したときに自動的に適用される eks.amazonaws.com/compute-type=hybrid ラベルに対する Affinity を構成できます。このラベルにより、ワークロードの配置を制御できるようになり、CNI を含むコンポーネントをハイブリッドノード上で実行するかしないかを決定できます。 次の cilium-values.yaml は、Cilium をインストールするための Helm の Values を示しています。ハイブリッドノードのラベルに対するアフィニティと IP Address Management (IPAM) の設定に注意してください。この例では、Cluter Pool overlay IPAM モードを使用しています。ここで clusterPoolIPv4PodCIDRList を設定し、これは EKS クラスター作成時に指定した RemotePodNetwork の CIDR に対応する必要があります。以下の例の 10.80.2.0/23 を RemotePodNetwork の値に置き換えてください。この例では、 clusterPoolIPv4MaskSize が 25 に設定されているため、ノードごとに 128 個の IP アドレスが割り当てられます。 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ipam: mode: cluster-pool operator: clusterPoolIPv4MaskSize: 25 clusterPoolIPv4PodCIDRList: - 10.80 .2.0/23 operator: unmanagedPodWatcher: restart: false Bash cilium-values.yaml ファイルを設定して作成した後、Helm を使用して Cilium をインストールできます。 CILIUM_VERSION = 1.16 .4 helm repo add cilium https://helm.cilium.io/ helm install cilium cilium/cilium \ --version ${CILIUM_VERSION} \ --namespace kube-system \ --values cilium-values.yaml Bash CNI をデプロイした後、再度 kubectl get nodes を実行し、ノードが Ready 状態であることを確認してください。 NAME STATUS ROLES AGE VERSION mi-036ecab1709d75ee1 Ready < none > 1h v1.31.2-eks-94953ac Bash ハイブリッドノード上で実行されるワークロードの Ingress とロードバランシング 多くのユースケースでは、Kubernetes クラスターで実行されているワークロードは、外部リソースにアクセスできるようにクラスターの外部に公開する必要があります。通常 Kubernetes では Ingress とロードバランサーを介して Service を公開することで実現されます。ハイブリッドノードでは、アプリケーショントラフィックには 2 つの一般的な経路があります。1 つ目は、AWS リージョンからオンプレミスのハイブリッドノード上で実行されているワークロードに接続するアプリケーショントラフィックです。2 つ目は、オンプレミス環境内に留まるアプリケーショントラフィックです。 AWS リージョンから発信されるアプリケーショントラフィックでは、Direct Connect または AWS Site-to-Site VPN で接続されたハイブリッドノード上のワークロードに、ターゲットタイプ ip の Application Load Balancer (ALB) または Network Load Balancer (NLB) と合わせて、 AWS Load Balancer Controller を使用できます。 AWS Load Balancer Controller は webhook を利用するため、ハイブリッドノード上で AWS Load Balancer Controller を実行する場合は、EKS クラスターの作成時に RemotePodNetwork を設定する必要があります。 オンプレミス環境のローカルアプリケーショントラフィックついては、ハイブリッドノードで使用するためのさまざまなパートナーおよび Kubernetes コミュニティのオプションがあります。 オプションを選択する際には、オンプレミス環境の既存のテクノロジーとアプリケーション要件を考慮してください。 オンプレミス環境の一般的なオプションには、Cilium (BGP または L2-aware ロードバランシング)、Calico (BGP ロードバランシング)、MetalLB、NGINX、HAProxy、Apache APISIX、Emissary Ingress、Citrix Ingressが 含まれます。また、Istio などのサービスメッシュテクノロジーも、他のオプションと同様の機能を提供します。 一般的に、Amazon EKS とハイブリッドノードは 100% のアップストリーム Kubernetes と互換性があり、Ingress とロードバランシングのほとんどの Kubernetes オプションを、ハイブリッドノード上で実行されているアプリケーションに使用できます。 クリーンアップ 次のコマンドを使用すると、前のステップで作成したリソースを削除して、料金が発生しないようにすることができます。異なる CloudFormation スタック名を使用した場合は、次のコマンドで EKSHybridRoleSSM と EKSHybridCluster を自身が使用したスタック名に置き換えてください。 aws cloudformation delete-stack --stack-name EKSHybridCluster aws cloudformation delete-stack --stack-name EKSHybridRoleSSM # to remove hybrid nodes components from your hosts sudo nodeadm uninstall --skip node-validation,pod-validation Bash ローンチパートナー EKS Hybrid Nodes のローンチには、Independent Software Vendors(ISV)、Independent Hardware Vendors(IHV)、Operating System vendors(OSV) などの様々なパートナーが参加しました。彼らと協力し、Kubernetes コミュニティの中で活動していくことを楽しみにしています。このローンチに参加したパートナーのリストは以下の通りです。 リストされている ISV のいくつかは、Amazon EKS および EKS Anywhere でサードパーティソフトウェアを検証するためのフレームワークである Conformitron を通じて、ソフトウェアソリューションを検証しました。これにより、GitOps ドリブンなインテグレーションを EKS Hybrid Nodes に拡張しています。 ユーザーは、これらのパートナーが提供する検証済みソリューションをデプロイして、ハイブリッドノードを操作できます。これにより、シークレット管理、ストレージ、デバイスの分散したフリート全体でのサードパーティコンポーネントのメンテナンスなど、一般的な本番環境での準備の領域に対処できます。 AccuKnox (ISV) は、クラウドネイティブと Kubernetes 環境のためのゼロトラストセキュリティソリューションの提供に焦点を当てたサイバーセキュリティ企業です。同社のプラットフォームは、Kubernetes デプロイメントの高度なランタイムセキュリティ、ネットワークセグメンテーション、コンプライアンス自動化を提供します。 AMD (IHV)は、彼らの EPYC プロセッサーとデータセンターおよびクラウドコンピューティングの分野で大きな進歩を遂げている半導体企業です。これらの高性能 CPU は、コンピュート集中型ワークロードの優れた価格パフォーマンス比を実現するように設計されており、Kubernetes デプロイメントにとって魅力的なオプションです。 Aqua (ISV) は、コンテナおよびサーバーレス環境の包括的な保護を提供するクラウドネイティブセキュリティソリューションの主要プロバイダーです。同社のプラットフォームは、ランタイム保護、脆弱性スキャン、コンプライアンス実施を含む、Kubernetes デプロイメントへの高度なセキュリティ機能を提供します。 CIQ (OSV) は、Rocky Linux のハイパフォーマンスコンピューティング (HPC) ソリューションとエンタープライズサポートに特化した企業です。同社は、コンテナ化と Kubernetes オーケストレーションの専門知識を提供しており、特に科学技術コンピューティングワークロードに対応しています。CIQ のソリューションは、コンピュート集中型アプリケーションと HPC 環境向けの Kubernetes デプロイメントの最適化に役立ちます。 Continent 8 Technologies (IHV) は、セキュアホスティングと接続ソリューションに特化したグローバル IT マネージドサービスプロバイダーです。主要なハードウェアベンダーではありませんが、Kubernetes デプロイメントをサポートできるクラウドサービスとインフラを提供しています。Continent 8 の規制市場における専門知識は、グローバルネットワークと組み合わせることで、厳しい規制要件を持つ業界向けの堅牢でコンプライアンスに準拠した Kubernetes クラスターのホスティング環境を AWS サービスと組み合わせて提供できます。 Dell Technologies (IHV) は、サーバー、ストレージ、ネットワーキング機器を含む Kubernetes デプロイメントをサポートできる幅広いハードウェアソリューションを提供する主要グローバルテクノロジー企業です。PowerEdge サーバーと VxRail ハイパーコンバージドインフラストラクチャは、コンテナ化されたワークロードを実行するための堅牢なプラットフォームを提供します。Dell のハードウェアソリューションは、AWS サービスと統合してパワフルなハイブリッドクラウド環境を作成し、オンプレミスとクラウドインフラストラクチャ間でシームレスな Kubernetes デプロイメントを可能にします。 Dynatrace (ISV) は、Kubernetes を含むクラウド環境のアプリケーションパフォーマンスモニタリング(APM) および可観測性ソリューションを提供する主要なソフトウェアインテリジェンスプラットフォームです。この AI 搭載プラットフォームは、AWS 上で実行されているコンテナ化されたアプリケーション、マイクロサービス、Kubernetes クラスターの深い可視性を提供します。 HashiCorp (ISV) は、AWS 上の Kubernetes デプロイメントを強化する一連の強力なオープンソースツールを提供しています。Infrastructure as Code の Terraform、シークレット管理の Vault、サービスネットワーキングの Consul などの製品は、Amazon EKS やその他の AWS サービスとシームレスに統合されます。 Kong (ISV) は、Kubernetes 環境のための堅牢なソリューションを提供する主要な API ゲートウェイおよびサービス接続プラットフォームです。Kubernetes Ingress Controller と API 管理ツールは、Amazon EKS やその他の AWS サービスとシームレスに統合され、マイクロサービスアーキテクチャのトラフィック制御、セキュリティ、可観測性を高めます。 Kubecost (ISV) は、Kubernetes 環境のリアルタイムのコスト可視性と最適化を提供するソフトウェアソリューションです。このプラットフォームは、Amazon EKS やその他の Kubernetes クラスター上で実行されるコンテナ化されたワークロードの詳細なコスト割り当て、モニタリング、予測を提供します。 NetApp (ISV) は、クラウドデータサービスとストレージソリューションのリーダーであり、Kubernetes 環境での永続ストレージの管理に役立つ強力なツールを提供しています。Astra 製品ラインは、スナップショット、バックアップ、AWS で実行される Kubernetes ワークロードの移行機能など、コンテナ化されたアプリケーションのデータ管理機能を提供します。 New Relic (ISV) は、Kubernetes 環境の包括的なモニタリングとパフォーマンス管理ソリューションを提供する主要な可観測性プラットフォームです。このプラットフォームは、Amazon EKS やその他の AWS サービス上で実行されているコンテナ化されたアプリケーション、マイクロサービス、Kubernetes クラスターの深い可視性を提供します。 Nirmata (ISV) は、複数の環境にまたがる Kubernetes クラスターのデプロイ、運用、ガバナンスを簡素化する Kubernetes 管理プラットフォームです。このソリューションは、組織が Amazon EKS やその他のKubernetes デプロイメント全体で一貫してセキュリティとコンプライアンス基準を適用できるように、ポリシーベースの Kubernetes の自動化を提供します。 PerfectScale (ISV) は、Kubernetes 環境でのリソース使用量とコスト効率を強化するために設計された AI 搭載最適化プラットフォームです。このソリューションは、Amazon EKS やその他の Kubernetes デプロイメントにおけるコンテナの適切なサイズ調整とクラスターリソースの最適化のためのインテリジェントな推奨事項を提供します。 Pulumi (ISV) は、開発者がおなじみのプログラミング言語を使用してクラウドリソースを定義および管理できるようにする、最新の Infrastructure as Code プラットフォームです。このソリューションは、Amazon EKS やその他のマネージド Kubernetes サービスを含む、AWS 上での Kubernetes クラスターのデプロイと管理のための強力なツールを提供します。 Solo.io (ISV) は、クラウドネイティブ環境のサービスメッシュと API ゲートウェイテクノロジーに特化したAPI インフラストラクチャソリューションの主要プロバイダーです。Gloo プラットフォームは、Amazon EKS やその他の AWS サービス上の Kubernetes デプロイメントのための高度なトラフィック管理、セキュリティ、可観測性機能を提供します。 Spectro Cloud (ISV) は、AWS を含む多様な環境にまたがる Kubernetes クラスターをデプロイおよび運用できる革新的な Kubernetes 管理プラットフォームを提供しています。このソリューションは、チームがオープンソースの柔軟性とエンタープライズ製品の管理容易性を組み合わせたカスタマイズされた Kubernetes スタックを作成できるようにする、クラスター管理のユニークなアプローチを提供します。 Sysdig (ISV) は、DevOps チームがコンテナ化されたアプリケーションを簡単にモニタリング、トラブルシューティング、セキュリティ保護できるようにする、Kubernetes 環境のための強力なコンテナインテリジェンスプラットフォームです。 Tetrate (ISV) は、サービスメッシュソリューションの主要プロバイダーであり、マイクロサービスベースの最新アプリケーションのエンタープライズグレードなインフラストラクチャを提供しています。同社の主力製品である Tetrate Service Bridge は、Amazon EKS やマルチクラスター、マルチクラウドデプロイメント全体で、包括的なアプリケーション接続、セキュリティ、可観測性を提供するために Istio の機能を拡張します。 まとめ オンプレミスまたはエッジで Kubernetes 上のワークロードを実行するには、通常、オープンソースの Kubernetes とツールやプロセスを定義および統合するのに時間、労力、メンテナンスが必要です。これにより、チームの運用上の負担が増え、オンプレミスとクラウドの環境間にサイロが生まれます。EKS Hybrid Nodes を使用すると、このトイルを削減し、オンプレミスのデプロイをクラウドでワークロードを実行する方法に近づけることができます。 オンプレミスのアプリケーションをモダナイズしたい場合、既存のオンプレミスハードウェアを使用したい場合、データを特定の国に保持することでデータローカライゼーションの要件を満たしたい場合など、EKS Hybrid Nodes を使用することで、Kubernetes コントロールプレーンの運用オーバーヘッドに対処することなく、効率的にオンプレミスのワークロードを実行できます。 EKS Hybrid Nodes の詳細と使用方法については「 EKS Hybrid Nodes ユーザーガイド 」をご覧ください。 また、EKS Hybrid Nodes の仕組み、機能、ベストプラクティスについて解説している re:Invent 2024 のセッション (KUB205) もご確認ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

こんにちは！ソリューションアーキテクトの水野です。 2025 年 4 月 24 日に製造業向けオンラインセミナー「Hannover Messe 2025 から見る産業変革」を開催いたしました。ご参加頂いた皆様には、改めて御礼申し上げます。本ブログは、セミナーの開催報告としてご紹介した内容や、当日の資料・収録動画などを公開いたします。 はじめに 今回のセミナーは、2025 年 3 月 31 日から 4 月 4 日にドイツで行われた Hannover Messe を振り返り、製造業における産業変革の最前線をコンパクトにまとめてご紹介しました。Hannover Messe については既にブースレポートとして ブログ を出していますが、ブログでは伝えきれなかった AWS ブースの詳細やパートナーソリューションについてお届けしています。 オープニング 登壇者: アマゾン ウェブ サービス ジャパン 合同会社 製造事業開発 設計領域担当部長 舛重 国規 動画リンク 資料リンク オープニングセッションでは、Hannover Messe 2025 における AWS の展示内容と主要なトピックについて紹介しました。今年の AWS ブースは 1400 平米の規模で、プロダクトエンジニアリング、スマート製造、スマートプロダクト、サプライチェーン、サステナビリティの 5 つのソリューション領域に 39 の産業パートナーブースで構成されました。特に注目すべき点として、①ビジネスに貢献する生成 AI の実装、②すぐに使える Vertical SaaS の増加、③DataOps の加速の 3 つが挙げられました。 また、ブースの目玉展示として「Built for Industrial AI」コーナーでは 4 つの生成 AI ユースケースを紹介し、e-Bike Smart Factory のデモでは実際の工場ラインを再現し AWS のサービスやソリューションによる製造プロセスの最適化を展示。日本からも多くの来場者があり、AWS Japan メンバーによる日本語でのブースツアーも実施されたことが紹介されました。 Hannover Messe 2025 で見えた AWS の製造ソリューションが拓く生産性向上と競争力強化 登壇者: アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 野間 愛一郎 動画リンク 資料リンク このセッションでは、主に AWS の展示内容から「ビジネスに貢献する生成 AI の実装」と「DataOps の加速」という 2 つの大きなポイントに焦点を当てて紹介しています。 生成 AI 実装の面では、AWS ブース内で日本のお客様の注目度が高かった Amazon Nova を活用した外観検査、現場作業者の業務効率向上、エッジでの生成 AI 活用、技術伝承、開発効率化について、具体的な応用例を解説しています。DataOps の分野では、産業データファブリック(IDF)、e-Bike Smart Factory、サプライチェーン管理、サステナビリティ、デジタルスレッド、そしてサロゲートモデルを使用したシミュレーションなど、データを効果的に活用するソリューションが紹介されています。これらの技術やソリューションを通じて、製造業における生産性向上と競争力強化をどのように実現できるかを解説している内容となっています。 AWS パートナー展示からみえる製造業の DX を加速する最新テクノロジートレンド 登壇者: アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト　水野 貴博 動画リンク 資料リンク このセッションでは、製造業の DX を加速する最新テクノロジートレンドについて AWS パートナー展示を中心に紹介しました。まず、日本の製造業でデータ活用が進まない技術的な課題として、レガシーシステムとの統合問題、データ基盤の技術的課題、セキュリティとインフラの制約などテクノロジーの課題と組織の壁や経営の理解、スキル、人材の不足といった非テクノロジーの課題があることが述べられました。その内、テクノロジーの課題に対しては産業データファブリック (IDF) とパートナーソリューションを組み合わせることで解決できる可能性が示されました。IDF パートナーとしては、HighByte、Litmus、Siemens、Snowflake、Cognite が紹介され、各社の特徴や得意分野が解説されました。例えば HighByte は産業用データ管理に特化し、Litmus はエッジでのデータ収集から分析までをシームレスに実現するソリューションを提供しています。 その他の注目パートナーとして、マルチベンダーの AGV / AMR を制御する SYNAOS、クラウド MES のソリューションとして TULIP、42Q をご紹介しました。また OT セキュリティを提供する Claroty、Dragos、Nozomi Networks なども紹介され、製造業のDXを支援する多様なソリューションをご紹介しました。 製造革新への扉：AWS パートナーと実現する業務革新の民主化 登壇者: アマゾン ウェブ サービス ジャパン 合同会社 産業テクノロジーパートナーシップ　ジャパンリード　小澤 剛 動画リンク 資料リンク このセッションでは、製造業のDXを加速させる AWS パートナーソリューションの最新動向が紹介されました。特に注目されたのは、AWS Marketplace で提供される SaaS ソリューションです。また、Siemens と AWS の戦略的提携により、PLM や CAE などの基幹システムの SaaS 化が進展している点も強調されました。さらに、産業データファブリック (IDF) の分野では、日立の Intelligent Platform、Cognite Data Fusion、HighByte Intelligence Hub など、データの意味づけや連携を実現する様々なソリューションが改めて紹介されました。これらのパートナーソリューションを活用することで、製造業は生成 AI の実用化やデータ活用を迅速に進め、ビジネス価値の創出を加速できることをご紹介しました。 まとめ 本ブログでは、製造業向けオンラインセミナー「Hannover Messe 2025 から見る産業変革」の資料及び動画とその概要をご紹介しました。本セミナーをきっかけに製造業の皆様の業務革新が進むことを期待しております。今後については 6 月 25 日(水)、26 日(木)に幕張メッセで行われる AWS Summit Japan 2025 にて Hannover Messe の展示されたソリューションの一部をご紹介する予定です。皆様のご来場をお待ちしております。ご登録は こちら 。 本ブログは、ソリューションアーキテクトの水野貴博が執筆しました。 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。

4 月 28 日週、私は AWS Summit Bangkok に参加するためにタイに行きました。活気に満ちた刺激的なイベントでした。私たちはデベロッパーラウンジを開催しました。デベロッパーラウンジでは、デベロッパーが集い、アイデアについて議論したり、ライトニングトークを楽しんだりしたほか、 AWS ビルダー ID Prize Wheel で SWAG を獲得し、 Amazon Q Developer Coding Challenge に挑戦して、Learn Amazon Bedrock ブースで生成 AI について学びました。 以下で概要をご紹介します: AWS ヒーロー 、 AWS コミュニティビルダー 、 AWS ユーザーグループ のリーダーやデベロッパーの皆様のご協力に感謝申し上げます。 ASEAN で次に開催されるのは AWS Summit Singapore です。お見逃しのないよう、今すぐ ご登録 ください。 4 月 28 日週のリリース 4 月 28 日週のリリースのうち、私が注目したいくつかのリリースをご紹介します: Amazon Nova Premier の一般提供を開始 – 複雑なタスクを実行したり、モデル蒸留の教師として機能させたりするための、当社の最も優れたモデルである Amazon Nova Premier の一般提供が Amazon Bedrock で開始されました。100 万トークンのコンテキスト長で、テキスト、画像、動画を処理しながら、深いコンテキスト理解と複数ステップの計画を必要とする複雑なタスクで優れたパフォーマンスを発揮します。Nova Premier と Amazon Bedrock Model Distillation を利用すると、特定のニーズのために、Nova Pro、Lite、Micro の、高性能でコスト効率が高く、低レイテンシーのバージョンを作成できます。 Amazon Q Developer が新しいエージェントコーディングエクスペリエンスで IDE エクスペリエンスを改善 – Visual Studio Code のためのこの新しいインタラクティブなエージェントコーディングエクスペリエンスにより、Q Developer は、デベロッパーのためにインテリジェントにアクションを実行できます。Amazon Q Developer は、Visual Studio Code にインタラクティブなコーディングエクスペリエンスを導入し、コーディング、ドキュメント作成、テストのためのリアルタイムコラボレーションを提供します。透明性の高い推論を提供し、自動またはステップバイステップの変更を複数の言語でサポートします。 Amazon Bedrock での新しい基盤モデル – Amazon Bedrock は、次の 2 つの重要な追加により、モデルオファリングを拡張します: Writer の Palmyra X5 および X4 モデル は、広範なコンテキストウィンドウ (それぞれ 100 万トークンと 128K トークン) を特徴としており、エンタープライズアプリケーションの複雑な推論で優れたパフォーマンスを発揮します。高い信頼性の水準で、複数ステップのツール呼び出しと適応型思考をサポートします。 Meta の Llama 4 Scout 17B および Maverick 17B モデル は、Mixture of Experts アーキテクチャを使用したネイティブのマルチモーダル機能を提供し、推論と画像理解を強化します。これらのモデルは、複数の言語と拡張コンテキスト処理をサポートします。また、Bedrock Converse API を通じて、簡素化された統合を実現できます。 第 2 世代 AWS Outposts ラックのリリース – AWS は、最新の x86 EC2 インスタンス、簡素化されたネットワーキング、高速化されたネットワーキングオプションなど、大幅な機能強化を含む第 2 世代 Outposts ラックの一般提供の開始を発表しました。これらの改善により、vCPU、メモリ、ネットワーク帯域幅が 2 倍になり、パフォーマンスが 40% 改善され、超低レイテンシーのワークロードがサポートされるため、要求の厳しいオンプレミスデプロイに最適です。 Amazon CloudFront SaaS Manager のリリース – Amazon CloudFront SaaS Manager は、SaaS プロバイダーとウェブホスティングプラットフォームが複数の顧客ドメインにわたってコンテンツ配信を効率的に管理するのに役立ちます。このサービスは、あらゆるお客様ドメインのために、高パフォーマンスのコンテンツ配信とエンタープライズグレードのセキュリティを提供しながら、運用上の複雑さを大幅に軽減します。 より豊かなコンテキストのための Model Context Protocol (MCP) による Amazon Q Developer CLI の拡張 | Amazon Web Services – Amazon Q Developer CLI は、Model Context Protocol (MCP) をサポートするようになりました。これで、コンテキストに応じた応答を実現するために、外部データソースと統合できます。これにより、デベロッパーは、事前構築済みの統合や、 stdio をサポートする MCP サーバーに接続できるようになり、コードの精度、データの理解、クエリ実行が強化されます。この機能は開発タスクを効率化します。また、まもなく Amazon Q Developer IDE プラグインに拡張される予定です。 Amazon Aurora が PostgreSQL 17 のサポートを開始 – Amazon Aurora は PostgreSQL 17.4 のサポートを開始しました。これは、コミュニティの改善と、メモリ管理の最適化やより高速なフェイルオーバーなど、Aurora 固有の機能強化を提供します。このリリースには、Babelfish の新機能、セキュリティ修正、更新された拡張機能が含まれており、すべての AWS リージョンでご利用いただけます。 CloudWatch が Lambda ログの階層料金を導入 – Amazon CloudWatch は、AWS Lambda ログの階層料金と、新しい配信先をリリースしました。米国東部での料金は、0.50 USD/GB～ (CloudWatch)、0.25 USD/GB～ (S3 および Firehose) であり、両方とも 0.05 USD/GB までの階層料金が設定されています。このアップデートにより、サポート対象のすべてのリージョンでログ管理における柔軟性が高まります。 RDS for MySQL がマイナーバージョンをアップデート – Amazon RDS for MySQL は、マイナーバージョン 8.0.42 と 8.4.5 のサポートを開始しました。これは、セキュリティ修正、バグ修正、パフォーマンスの改善を提供します。ユーザーは、メンテナンスウィンドウ中に自動的にアップグレードすることも、ブルー/グリーンデプロイを使用してより安全にアップデートすることもできます。 Amazon Bedrock Model Distillation の一般提供を開始 – Amazon Bedrock Model Distillation の一般提供が開始され、Amazon Nova や Claude 3.5 などの新しいモデルがサポートされるようになりました。これにより、小さめのモデルでもエージェントのための関数呼び出しを正確に予測できるようになり、RAG のユースケースで精度の低下を最小限に抑えながら、応答を最大 500% 高速化し、コストを最大 75% 削減できます。このサービスには、データ合成と生徒モデルのトレーニングのための自動化されたワークフローが含まれています。 Amazon OpenSearch Service 向けの AI 検索フロービルダー – Amazon OpenSearch Service は、OpenSearch 2.19 以降のドメイン向けの AI 検索フロービルダーの提供を開始しました。このローコードデザイナーにより、AWS およびサードパーティーのサービスを利用して、AI を利用した高度な検索フローを作成し、RAG、クエリの書き換え、セマンティックエンコーディングなどのユースケースをサポートできます。 community.aws より community.aws から、私が個人的に気に入っている記事をご紹介します: How to Generate AWS Architecture Diagrams Using Amazon Q CLI and MCP – Omshree Butani 氏が、Amazon Q CLI と Model Context Protocol (MCP) を利用して AWS アーキテクチャ図を迅速に生成し、アーキテクチャ設計プロセスを効率化する方法をご紹介します。 Implementing Nova Act MCP Server on ECS Fargate – Vivek V が、ブラウザオートメーションのために ECS Fargate で Amazon Nova Act Model Context Protocol (MCP) サーバーを実装する方法について詳しく説明します。このソリューションには、アーキテクチャ設計、デプロイ戦略、サーバー/クライアントの実装、Streamlit UI、AWS CDK インフラストラクチャ、VS Code 統合が含まれています。 Leveraging Crossplane to build single-tenant SaaS control planes on top of Kubernetes – Yehuda Cohen が、Crossplane を活用して Kubernetes でシングルテナント SaaS コントロールプレーンを構築する方法について詳しく説明します。この記事では、Crossplane が Kubernetes の宣言型モデルを拡張して Kubernetes 以外のリソースを管理し、テナントの自動プロビジョニングとスケーラブルなクラウドリソース管理を実現する方法に焦点を当てます。 How to Securely Display Objects from an S3 Bucket in a Browser – Osabutey-Anikon Theeophilus Lloyd 氏が、Amazon S3 バケットのオブジェクトをウェブブラウザで安全に表示するためのテクニックをご紹介します。特に、ブラウザベースのアクセスにおける適切なセキュリティ対策に焦点を当てます。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。お近くの都市のイベントにご登録ください: ポーランド (5 月 6 日)、 ベンガルール (5 月 7～8 日)、 香港 (5 月 8 日)、 ソウル (5 月 14～15 日)、 シンガポール (5 月 29 日)、 シドニー (6 月 4～5 日)。 AWS re:Inforce – ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 16～18 日) の予定をカレンダーに書き込みましょう。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。サブスクライブして、今すぐイベントの最新情報を入手しましょう! AWS パートナーイベント – クラウドジャーニーを始めたばかりであるか、新たなビジネス上の課題を解決したいと考えているかにかかわらず、誰もがインスピレーションと学びを得られるさまざまな AWS パートナーイベントを見つけましょう。 AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボを特色とする、コミュニティ主導のカンファレンスにぜひご参加ください: エレバン (アルメニア) (5 月 24 日)、 チューリッヒ (スイス) (5 月 25 日)、 ベンガルール (インド) (5 月 25 日)。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 5 月 5 日週のニュースは以上です。5 月 12 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 5 日より、 Amazon Q Developer in GitHub のプレビュー版をご利用いただけるようになりました! これは、仕事でも、個人的なプロジェクトでも、GitHub を日常的に使用している何百万人ものデベロッパーにとってすばらしいニュースです。これらのデベロッパーは、Amazon Q Developer を利用して、GitHub インターフェイス内で直接、機能開発、コードレビュー、Java コードの移行を行うことができるようになりました。 デモンストレーションのために、StoryBook Teller というアプリケーションをゼロから作成するのを Amazon Q Developer に手伝ってもらいます。これは .NET 9 を使用する ASP.Core ウェブサイトで、ユーザーから 3 枚の画像を取得し、 Amazon Bedrock と Anthropic の Claude を利用して、それらの画像に基づいてストーリーを生成します。 その仕組みをご紹介します。 インストール まず、 GitHub で Amazon Q Developer アプリケーション をインストールする必要があります。これにより、AWS アカウントに接続することなく、直ちに使用を開始できます。 その後、そのアプリケーションをすべてのリポジトリに追加するか、特定のリポジトリを選択するかを選びます。今回は storybook-teller-demo リポジトリに追加するので、 [選択したリポジトリのみ] を選択し、名前を入力して検索します。 これで、選択したリポジトリ内で Amazon Q Developer アプリケーションを使用する準備が整います。アプリケーションがインストールされていることは、GitHub アカウントの [設定] に移動して確認できます。アプリケーションは [アプリケーション] ページに表示されます。 [設定] を選択して許可を表示し、いつでも Amazon Q Developer をリポジトリに追加したり、削除したりできます。 それでは、Amazon Q Developer を利用してアプリケーションを構築してみましょう。 機能開発 Amazon Q Developer をリポジトリにインストールすると、GitHub の Issue を Amazon Q 開発エージェントに割り当てて、機能を開発してもらうことができます。その後、リポジトリ内のコードベース全体をコンテキストとして使用し、Issue の説明も参照して、コードを生成します。そのため、GitHub の Issue には、要件を可能な限り正確かつ明確に記載することが重要です (これは、どのような場合であっても常に心がけるべきことです)。 StoryBook Teller リポジトリで、.NET 9 のスケルトンプロジェクトの作成からフロントエンドとバックエンドの実装まで、このアプリケーションのすべての要件をカバーする 5 つの Issue を作成しました。 Amazon Q Developer を利用して、アプリケーションをゼロから開発し、これらのすべての機能を実装してみましょう。 まず、.NET プロジェクトを作成するのを Amazon Q Developer に手伝ってもらいます。そのためには、最初の Issue を開き、 [ラベル] セクションで [Amazon Q 開発エージェント] を見つけて選択します。 これだけです! これで、Issue が Amazon Q Developer に割り当てられました。ラベルが追加されると、Amazon Q 開発エージェントが自動的にバックグラウンドで作業を開始し、コメントを通じて進捗状況の最新情報を提供します。最初のコメントは I'm working on it です。 ご想像のとおり、かかる時間は機能の複雑さによって異なります。完了すると、すべての変更を含むプルリクエストが自動的に作成されます。 次に、生成されたコードが機能することを確認したいので、コードの変更をダウンロードし、自分のコンピュータでローカルにアプリケーションを実行します。 ターミナルに移動し、 git fetch origin pull/6/head:pr-6 と入力して、作成されたプルリクエストのコードを取得します。内容をダブルチェックすると、想定どおり .NET 9 を使用して生成された ASP.Core プロジェクトが確かに存在していることがわかります。 その後、 dotnet run を実行し、出力に示された URL を使用してアプリケーションを開きます。 すばらしいです。適切に機能しています! Amazon Q Developer は、GitHub の Issue で私が提供した要件に基づいて、まさに私の希望どおりに実装してくれました。アプリケーションの動作テストが完了したので、変更を受け入れる前にコード自体をレビューしたいと思います。 コードレビュー GitHub に戻り、プルリクエストを開きます。Amazon Q Developer が生成されたコードに対していくつかの自動チェックを実行したことがすぐにわかります。 これはすばらしいです! 既にかなりの作業が完了しています。ただし、プルリクエストをマージする前にレビューしたいと思います。これを実行するために、 [変更されたファイル] タブに移動します。 コードをレビューし、問題ないことを確認しました! しかし、.gitignore の内容を確認すると、変更したい点が見つかりました。Amazon Q Developer が適切な想定を行い、Visual Studio (VS) Code ファイルについての除外ルールを追加していることがわかります。しかし、JetBrains Rider は .NET 開発のための私のお気に入りの統合開発環境 (IDE) なので、これについてのルールも追加したいと考えています。 GitHub インターフェイスで通常のコードレビューフローを使用することで、再度イテレーションするよう Amazon Q Developer に指示できます。この場合、.gitignore コードに add patterns to ignore Rider IDE files というコメントを追加します。その後、 [レビューを開始] を選択します。これにより、レビューにおける変更がキューに追加されます。 [レビューを完了] と [変更をリクエスト] を選択します。 レビューを送信するとすぐに、[会話] タブにリダイレクトされます。Amazon Q Developer が作業を開始し、同じフィードバックループを再開して、私が満足するまでレビュープロセスを続行するよう促します。 Q Developer が変更を加えるたびに、生成されたコードに対して自動チェックが実行されます。今回は、コードが比較的単純なので、自動コードレビューで問題は発生しないことが想定されました。しかし、より複雑なコードの場合はどうなるでしょうか? 別の例として、Amazon Q Developer を利用して、ウェブサイトでの画像アップロードを可能にする機能を実装してみましょう。前のセクションで説明したのと同じフローを使用します。しかし、プルリクエストに対する自動チェックで、今回は警告フラグが立てられました。この警告によると、バックエンドで画像アップロードをサポートするために生成された API に認可チェックが欠落しているため、事実上、直接パブリックアクセスが可能になっているということです。セキュリティリスクの詳細な説明と、役立つリンクが提供されています。 その後、コード修正の提案が自動的に生成されます。 完了したら、コードをレビューし、変更に問題がなければ [変更をコミット] を選択できます。 これを修正してテストした後、この Issue のコードに満足したので、同じプロセスを他の Issue にも適用していきます。残りの Issue それぞれに Amazon Q 開発エージェントを割り当てて、コードが生成されるのを待ち、反復的なレビュープロセスを実行して、その過程で問題があれば修正するよう指示します。その後、ソフトウェアサイクルの最後にアプリケーションをテストします。Amazon Q Developer がプロジェクトのセットアップから、ボイラープレートコード、より複雑なバックエンドやフロントエンドまで、すべての問題に対処してくれたことに、私は非常に満足です。まさに真のフルスタックデベロッパーです! 途中で、変更したい点がいくつかあること気づきました。例えば、アップロードされた画像を Amazon Bedrock に送信する際に、Converse API ではなく Invoke API がデフォルトで使用されるようになっていました。しかし、要件でこれについて触れていなかったため、Q Developer がそれを知る術はありませんでした。このことは、Q Developer に必要なコンテキストを提供し、開発プロセスを可能な限り効率的にするために、Issue のタイトルと説明を可能な限り正確に記述することの重要性を強調しています。 とはいえ、プルリクエストで生成されたコードをレビューし、コメントを追加して、最終結果に満足するまで Amazon Q Developer エージェントに変更作業をさせ続けるのは簡単です。あるいは、プルリクエストの変更を受け入れ、開発の準備ができたら Q Developer に割り当てることができる別の Issue を作成することもできます。 コード変換 Q Developer を利用すると、レガシー Java コードベースを最新バージョンに変換することもできます。現在、アプリケーションを Java 8 または Java 11 から Java 17 に更新できますが、今後のリリースではさらに多くのオプションが使用可能になる予定です。 このプロセスは、いくつかの点を除けば、この記事の前半でデモンストレーションしたものと非常に似ています。 まず、Java 8 または Java 11 アプリケーションを含む GitHub リポジトリ内に Issue を作成する必要があります。この場合、タイトルと説明はそれほど重要ではありません。「Migration」などの短いタイトルで、説明は空白のままでも構いません。その後、 [ラベル] で、Issue に [Amazon Q transform agent] ラベルを割り当てます。 以前と同様に、Amazon Q Developer は、レビュー可能なプルリクエストのコードを生成する前に、直ちにバックグラウンドで作業を開始します。ただし、今回は、コード移行に特化した Amazon Q 変換エージェントが作業を行い、コードの分析と、Java 8 から Java 17 への移行に必要なすべてのステップを実行します。 ドキュメントに従って、ワークフローも作成する必要があることに留意してください。まだ有効になっていない場合は、再試行する前にすべてをセットアップするのに役立つ明確な手順が表示されます。 想定したとおり、移行の実行に必要な時間は、アプリケーションのサイズと複雑さによって異なります。 まとめ Amazon Q Developer in GitHub を利用することは、新機能を開発し、コードレビュープロセスを加速して、セキュリティ体制を強化し、コードの質を改善するためにコラボレーションできるフルスタックデベロッパーと作業するようなものです。また、Java 8 および 11 のアプリケーションから Java 17 への移行を自動化するために使用できるため、しばらく延期していた移行プロジェクトであってもはるかに簡単に開始できます。何よりも、これらすべてをご自身の GitHub 環境から快適に実行できます。 今すぐご利用いただけます 今すぐ GitHub で Amazon Q Developer の利用を無料で 開始できます。AWS アカウントのセットアップは不要です。 Amazon Q Developer in GitHub は現在プレビュー中です。 – Matheus Guimaraes | codingmatheus 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 2 日、 Amazon Q Developer は、新しいインタラクティブなエージェントコーディングエクスペリエンスを導入しました。これは現在、 Visual Studio Code のために 統合開発環境 (IDE) でご利用いただけます。このエクスペリエンスにより、既存のプロンプトベースの機能に基づいて、インタラクティブなコーディング機能を使用できます。コードの記述、ドキュメントの作成、テストの実行、変更のレビューを行う際に、自然でリアルタイムの共同作業パートナーとともに作業できるようになります。 Amazon Q Developer は、提案についての透明性の高い理由を提供し、自動変更と変更のステップバイステップの確認を選択できるようにすることで、コードの記述とメンテナンスの方法を変革します。 Amazon Q Developer コマンドラインインターフェイス (CLI) エージェント を日常的に使用する私は、Amazon Q Developer チャットインターフェイスがソフトウェア開発をどのようにより効率的で直感的なプロセスにするのかを直接体験しました。CLI で q チャット するだけで AI を使用したアシスタントが利用できるようになったため、私の日々の開発ワークフローが合理化され、コーディングプロセスが強化されました。 IDE の Amazon Q Developer における新しいエージェントコーディングエクスペリエンスは、ローカル開発環境とシームレスにインタラクションします。ファイルを直接読み書きし、bash コマンドを実行して、コードに関する自然な会話を行うことができます。Amazon Q Developer はコードベースのコンテキストを理解し、自然な対話を通じて複雑なタスクの完了をサポートします。これにより、開発速度を上げつつ、ワークフローの勢いを維持できます。 実際の動作 Amazon Q Developer を初めてご利用の場合は、「 Getting Started with Amazon Q Developer 」ガイドのステップに従って Amazon Q Developer にアクセスしてください。Amazon Q Developer を利用する際には、有料サブスクリプションサービスである Amazon Q Developer Pro 、または AWS ビルダー ID ユーザー認証を使用する Amazon Q Developer 無料利用枠 のいずれかを選択できます。 既存のユーザーは、新しいバージョンに更新してください。アクティブ化に関する指示については、「 Using Amazon Q Developer in the IDE 」をご覧ください。 まず、IDE で Amazon Q アイコンを選択し、チャットインターフェイスを開きます。このデモでは、 Amazon Nova サンプルリポジトリ の Jupiter ノートブックをインタラクティブなアプリケーションに変換するウェブアプリケーションを作成します。 次のプロンプトを送信します: In a new folder, create a web application for video and image generation that uses the notebooks from multimodal-generation/workshop-sample as examples to create the applications.Adapt the code in the notebooks to interact with models.Use existing model IDs その後、Amazon Q Developer は、README ファイル、ノートブック、メモ、および会話が配置されているフォルダ内にあるあらゆるものを調べます。今回は、リポジトリのルートにあります。 リポジトリの分析が完了すると、Amazon Q Developer はアプリケーション作成プロセスを開始します。プロンプトの要件に従って、必要なフォルダとファイルを作成するための bash コマンドを実行する許可をリクエストします。 フォルダ構造が整うと、Amazon Q Developer は完全なウェブアプリケーションの構築に進みます。 数分でアプリケーションが完成します。Amazon Q Developer は、アプリケーションの構造とデプロイに関する指示を提供します。これは、チャットでリクエストすることで README ファイルに変換できます。 アプリケーションを最初に実行しようとしたときにエラーが発生しました。Amazon Q チャットを使用してスペイン語でそのエラーについて説明しました。 Amazon Q Developer はスペイン語で応答し、スペイン語で解決策とコードの変更方法を教えてくれました。 とても満足です! 提案された修正を実装すると、アプリケーションは正常に実行されました。これで、この新しく作成されたインターフェイスを通じて、 Amazon Nova を利用して画像と動画を作成、変更、分析できるようになりました。 上記の画像は、アプリケーションの出力機能を示しています。スペイン語で動画生成コードを変更するように依頼したため、スペイン語のメッセージが表示されました。 知っておくべきこと 自然言語でのチャット – Amazon Q Developer IDE は、英語、中国標準語、フランス語、ドイツ語、イタリア語、日本語、スペイン語、韓国語、ヒンディー語、ポルトガル語など、多くの言語をサポートしています。詳細については、 「Amazon Q Developer ユーザーガイド」のページ にアクセスしてください。 コラボレーションと理解 – システムは、自然な対話を通じてローカル開発環境とシームレスにインタラクションするための柔軟性を提供しながら、リポジトリの構造、ファイル、ドキュメントを検査します。この深い理解により、開発タスク中に、より正確でコンテキストを踏まえたサポートを提供できるようになります。 コントロールと透明性 – Amazon Q Developer は、タスクを通じて機能する中で継続的にステータスを更新し、自動コード変更またはステップバイステップのレビューを選択できるようにすることで、ユーザーが開発プロセスを完全に制御できるようにします。 提供状況 – Amazon Q Developer のインタラクティブなエージェントコーディングエクスペリエンスは、Visual Studio Code 向けの IDE でご利用いただけるようになりました。 料金 – Amazon Q Developer のエージェントチャットは、 Amazon Q Developer Pro 階層 および Amazon Q Developer 無料利用枠 の両方のユーザーに追加コストなしで IDE でご利用いただけます。料金の詳細については、 Amazon Q Developer の料金ページ にアクセスしてください。 開始方法の詳細については、 Amazon Q Developer の製品ウェブページ にアクセスしてください。 –  Eli 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

4 月 30 日より、 AWS re:Invent で発表された Amazon Nova 基盤モデルファミリーを拡張 し、 Amazon Nova Premier の一般提供を開始しました。これは、複雑なタスクに対応できる当社の最も有能なモデルであり、モデル蒸留の教師としても機能します。 Nova Premier は、 Amazon Bedrock で利用可能な既存の Amazon Nova 理解モデル の一員となります。Nova Lite や Pro と同様に、Premier は、入力テキスト、画像、動画 (音声を除く) を処理できます。高度な機能を備えた Nova Premier は、コンテキストの深い理解、複数ステップの計画、複数のツールとデータソースにわたる正確な実行を必要とする複雑なタスクで優れたパフォーマンスを発揮します。100 万トークンのコンテキスト長に対応する Nova Premier は、非常に長いドキュメントや大規模なコードベースを処理できます。 Nova Premier と Amazon Bedrock Model Distillation を利用すると、特定のニーズに合わせて、Nova Pro、Lite、Micro の、高性能でコスト効率が高く、低レイテンシーのバージョンを作成できます。例えば、当社は Nova Premier を利用して Nova Pro を蒸留し、複雑なツール選択と API コールを実行しました。蒸留された Nova Pro ではベースモデルと比較して API 呼び出しの精度が 20% 向上し、一貫して教師と同等のパフォーマンスを発揮するとともに、Nova Pro の速度とコストメリットを実現しました。 Amazon Nova Premier のベンチマーク評価 当社は、テキストインテリジェンス、ビジュアルインテリジェンス、エージェントワークフローといった幅広いベンチマークで Nova Premier を評価しました。Nova Premier は、以下の表に示すように、17 のベンチマークで測定された Nova ファミリーの中で最も高性能なモデルです。 また、Nova Premier は、業界最高クラスの非推論モデルにも匹敵し、同じインテリジェンス階層の他のモデルと比較した場合、これらのベンチマークの約半数で同等以上のパフォーマンスを発揮します。これらの評価の詳細は、 テクニカルレポート をご覧ください。 Nova Premier は、Amazon Bedrock のインテリジェンス階層において、最も高速でコスト効率の高いモデルでもあります。料金の詳細と比較については、 Bedrock の料金ページ をご覧ください。 Nova Premier は、蒸留の教師モデルとしても使用できます。これは、特定のユースケース向けの高度な機能を、本番デプロイのために、Nova Pro、Micro、Lite などのより小規模かつ高速で効率的なモデルに移行できることを意味します。 Amazon Nova Premier の利用 Nova Premier の利用を開始するには、まず Amazon Bedrock コンソール でモデルに対するアクセスをリクエストする必要があります。ナビゲーションペインで [モデルアクセス] に移動し、 [Nova Premier] を見つけてアクセスを切り替えます。 アクセスを取得したら、 user と assistant からのメッセージのリストを入力で提供することで、 Amazon Bedrock Converse API を通じて Nova Premier を利用できます。メッセージには、テキスト、画像、動画を含めることができます。 AWS SDK for Python (Boto3) を使用した簡単な呼び出しの例を次に示します: import boto3 import json AWS_REGION = "us-east-1" MODEL_ID = "us.amazon.nova-premier-v1:0" bedrock_runtime = boto3.client('bedrock-runtime', region_name=AWS_REGION) messages = [ { "role": "user", "content": [ { "text": "Explain the differences between vector databases and traditional relational databases for AI applications." } ] } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages ) response_text = response["output"]["message"]["content"][-1]["text"] print(response_text) この例は、技術に関する複雑な質問について、Nova Premier がどのように詳細な説明を提供できるのかを示しています。しかし、Premier の真の力は、高度なワークフローを処理できる能力にあります。 マルチエージェントコラボレーションのユースケース Nova Premier が投資に関する調査のためのマルチエージェントコラボレーションアーキテクチャでどのように動作するのかを示す、より複雑なシナリオを詳しく見てみましょう。 エクイティリサーチプロセスには通常、複数のステージがあります。すなわち、特定の投資に関連するデータソースの特定、それらのソースからの必要な情報の取得、データの統合を通じた実用的なインサイトの取得です。このプロセスは、株価指数、個別株式、通貨など、さまざまな種類の金融商品を扱う場合、ますます複雑になります。 この種のアプリケーションは、 Amazon Bedrock でマルチエージェントコラボレーション を利用して構築できます。Nova Premier は、ワークフロー全体をオーケストレートするスーパーバイザーエージェントを支えます。スーパーバイザーエージェントは、最初のクエリ (例:「再生可能エネルギー投資の新たなトレンドは何か?」) を分析し、論理的なステップに分解して、どの専門サブエージェントを関与させるかを決定し、最終的な回答を合成します。 このシナリオでは、次のコンポーネントを使用してシステムを構築しました: Nova Premier を利用するスーパーバイザーエージェント Nova Pro を利用する複数の専門サブエージェント (それぞれ異なる金融データソースに特化) 金融データベース、市場分析ツール、他の関連する情報源に接続するツール 再生可能エネルギーに関する投資の新たなトレンドに関するクエリを送信すると、Nova Premier を利用するスーパーバイザーエージェントが次を実行します: クエリを分析し、カバーすべき基盤となるトピックや情報源を特定する それらのトピックと情報源に固有の適切なサブエージェントを選択する 各サブエージェントが、関連する経済指標、テクニカル分析、市場センチメントデータを取得する スーパーバイザーエージェントが、これらの情報を統合し、金融分野のプロフェッショナルが確認できる包括的なレポートを作成する このようなマルチエージェントコラボレーションアーキテクチャで Nova Premier を利用することで、金融分野のプロフェッショナルの業務が効率化され、投資分析をより迅速にまとめることができるようになります。次の動画は、このシナリオの視覚的な説明を提供します。 スーパーバイザーロールのために Nova Premier を使用する主な利点は、複雑なワークフローを正確に調整できるということです。これにより、適切なデータソースが最適な順序で参照されるほか、各サブエージェントは作業のための正しい情報を入力で受け取ることができるため、より質の高いインサイトを得ることができます。 モデル蒸留を使用するマルチエージェントコラボレーション Nova Premier は、そのモデルファミリーの中で最高レベルの精度を提供しますが、本番環境ではレイテンシーとコストを最適化する必要がある場合があります。ここで、蒸留のための教師モデルとしての Nova Premier の強みが際立ちます。 Amazon Bedrock Model Distillation を利用すると、この特定の投資に関する調査のユースケースの Nova Premier の結果を踏まえて Nova Micro をカスタマイズできます。 人間によるフィードバックとラベル付きサンプルを必要とする従来のファインチューニングとは異なり、モデル蒸留では、教師モデルに目的の出力を生成させることで質の高いトレーニングデータを生成し、データ取得プロセスを合理化できます。 モデルを蒸留 するプロセスには、次が含まれます: 複数の金融商品にわたる Nova Premier 実行からの入力と出力をキャプチャして、合成トレーニングデータを生成する このデータを参照として利用し、カスタムファインチューニングツールを通じて Nova Micro のカスタマイズされたバージョンをトレーニングする カスタマイズされた Micro モデルのレイテンシーとパフォーマンスの差を評価する カスタマイズされた Micro モデルを本番でスーパーバイザーエージェントとしてデプロイする Amazon Bedrock を利用すると、プロセスをさらに効率化し、 データ準備のために呼び出しログを使用 できます。そのためには、モデル呼び出しログ記録をオンに設定し、ログの宛先として Amazon Simple Storage Service (Amazon S3) バケットを設定する必要があります。 お客様の声 一部のお客様には Nova Premier に対する早期アクセスが提供されていました。これらのお客様からは、次のような声をいただいています: 「Amazon Nova Premier は、インタラクティブな分析ワークフローを実行する能力に優れており、当社のテストにおける他の先駆的なモデルと比較して、より高速であり、コストはほぼ半分です」と、会話、アプリケーション、顧客を 1 か所にまとめる企業である Slack の Senior Staff Engineer である Curtis Allen 氏は述べています。 「Amazon Nova 上に構築された新しいソリューションの実装は、すべての人にとって金融を民主化するという当社のミッションの達成に役立っています」と、すべての人にとって金融を民主化することをミッションとする Robinhood Markets の Head of AI and Data である Dev Tagare 氏は述べています。「当社は、高性能であるだけでなく、コスト効率とスピードにも優れた複雑なマルチエージェントコラボレーションなどの新たな可能性を探求できることに特に高揚感を覚えています。Nova Premier のインテリジェンスと、それが Nova Micro、Nova Lite、Nova Pro などの他のモデルに移行できるものにより、マルチエージェントコラボレーションが、一般のお客様が利用しやすいパフォーマンス、料金、スピードで利用できるようになります」。 「プロトタイプだけでなく、現実世界での AI のデプロイを加速するには、現実世界のアプリケーション固有のニーズに特化したモデルを構築する能力が必要です」と、データサイエンティストやデベロッパーが、データから正確で適応性の高い AI アプリケーションを迅速に生み出せるように支援するテクノロジー企業の Snorkel AI の共同創業者である Henry Ehrenberg 氏は述べています。「AWS が Amazon Bedrock Model Distillation と Amazon Nova Premier によって効率的なモデルカスタマイズを推進していくことを大変喜ばしく思います。これらの新しいモデル機能は、エンタープライズのお客様による、マルチモーダルデータなどを活用した質疑応答アプリケーションを含む、本番 AI アプリケーションの構築を加速する可能性を秘めています」。 知っておくべきこと Nova Premier は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン) の AWS リージョン の Amazon Bedrock で、 クロスリージョン推論 を介して4 月 30 日よりご利用いただけます。Amazon Bedrock でお支払いいただくのは、使用した分の料金のみです。詳細については、「 Amazon Bedrock の料金 」にアクセスしてください。 また、米国のお客様は、FM を簡単に探索できるウェブサイトである https://nova.amazon.com で Amazon Nova モデルにアクセスできます。 Nova Premier は、Nova Pro、Micro、Lite のカスタムバリアントを蒸留するための最適な教師です。これは、Premier が提供する機能を、本番デプロイのために、より小型かつ高速なモデルで実現できることを意味します。 Nova Premier には、 責任ある AI の使用を促進するための安全コントロールが組み込まれており、幅広いアプリケーションで適切な出力を維持するのに役立つコンテンツモデレーションも備わっています。 Nova Premier の使用を開始するには、今すぐ Amazon Bedrock コンソール にアクセスしてください。詳細については、「 Amazon Nova ユーザーガイド 」をご覧ください。また、 AWS re:Post for Amazon Bedrock にフィードバックをぜひお送りください。 community.aws サイトの生成 AI セクションでは、ビルダーコミュニティがソリューションで Amazon Bedrock をどのように利用しているのかを詳しくご覧いただけます。 – Danilo 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

4 月 29 日、AWS のエッジコンピューティングにおける最新のイノベーションとなる第 2 世代の AWS Outposts ラック の一般提供の開始をお知らせします。この新世代には、最新の x86 ベースの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのサポート、簡素化された新しいネットワークスケーリングと設定、超低レイテンシーかつ高スループットのワークロード向けに特別に設計されたアクセラレーテッドネットワーキングインスタンスが含まれています。これらの機能強化により、金融サービスのコア取引システムや通信分野の 5G Core ワークロードなど、幅広いオンプレミスワークロードのパフォーマンスが改善します。 athenahealth、FanDuel、First Abu Dhabi Bank、Mercado Libre、Liberty Latin America、Riot Games、Vector Limited、Wiwynn などのお客様は、オンプレミスで維持する必要があるワークロードのために既に Outposts ラックを使用しています。第 2 世代の Outposts ラックは、マルチプレイヤーオンラインゲーム用のゲームサーバー、顧客トランザクションデータ、医療記録、産業および製造管理システム、通信分野のビジネスサポートシステム (BSS)、さまざまな機械学習 (ML) モデルのエッジ推論など、低レイテンシー、ローカルデータ処理、またはデータレジデンシーのニーズに対応できます。お客様は、最新世代のプロセッサとより高度な設定の Outposts ラックを活用して、より高速な処理、より高いメモリ容量、より広いネットワーク帯域幅をサポートできるようになりました。 最新世代の EC2 インスタンス AWS Outposts ラックで、C7i コンピューティング最適化インスタンス、M7i 汎用インスタンス、R7i メモリ最適化インスタンスをはじめとする、最新世代 (第 7 世代) の x86 ベースの Amazon EC2 インスタンスのローカルサポートを開始することをお知らせします。これらの新しいインスタンスは、前世代の Outposts ラックの C5、M5、R5 インスタンスと比較して最大 40% 優れたパフォーマンスを提供しつつ、2 倍の vCPU、メモリ、ネットワーク帯域幅を提供します。第 4 世代インテル Xeon スケーラブルプロセッサを搭載し、大規模なデータベース、より多くのメモリを使用するアプリケーション、高度なリアルタイムビッグデータ分析、高パフォーマンスの動画エンコーディングとストリーミング、より高度な ML モデルを使用した CPU ベースのエッジ推論など、より高度なパフォーマンスを必要とする幅広いオンプレミスワークロードに最適です。GPU 対応インスタンスを含む、より多くの最新世代の EC2 インスタンスのサポートの提供を近日中に開始する予定です。 簡素化されたネットワークのスケーリングと設定 最新世代の Outposts ではネットワーキングを徹底的に見直しました。これにより、これまで以上にシンプルかつスケーラブルになりました。このアップグレードの中核となるのは、すべてのコンピューティングおよびストレージトラフィックの中心的なハブとして機能する新しい Outposts ネットワークラックです。 この新しい設計には、3 つの大きな利点があります。1 つ目の利点は、コンピューティングリソースをネットワークインフラストラクチャから独立してスケールできるようになったことです。これにより、ワークロードが増加する中で、より大きな柔軟性とコスト効率を活用できます。2 つ目の利点は、ネットワークの回復力を最初から組み込んだことです。ネットワークラックがデバイスの障害を自動的に処理し、システムのスムーズな稼働を維持します。3 つ目の利点は、オンプレミス環境や AWS リージョンへの接続が簡単になったことです。わかりやすい API または更新されたコンソールインターフェイスを通じて、IP アドレスから VLAN や BGP 設定まで、あらゆるものを設定できます。 アクセラレーテッドネットワークを備えた専用 Amazon EC2 インスタンス アクセラレーテッドネットワーキングを備えた Outposts ラックに、新しいカテゴリの専用 Amazon EC2 インスタンスを導入します。これらのインスタンスは、レイテンシーの影響を極めて受けやすく、コンピューティング負荷が高く、大量のスループットが発生する、オンプレミスのミッションクリティカルなワークロード向けに特別に設計されています。可能な限り最高のパフォーマンスを提供するために、これらのインスタンスには、Outpost 論理ネットワークに加えて、Top of Rack (TOR) スイッチに接続されたネットワークアクセラレーターカードを備えたセカンダリ物理ネットワークが備わっています。 このカテゴリの第一弾は、超低レイテンシーで決定論的なパフォーマンスを実現するよう設計された bmn-sf2e インスタンスです。これらの新しいインスタンスは、インテルの最新の Sapphire Rapids プロセッサ (第 4 世代 Xeon スケーラブル) 上で動作し、すべてのコアで 3.9 GHz の持続的なパフォーマンスと、CPU コアごとに 8 GB の RAM という十分なメモリ割り当てを実現します。 bmn-sf2e インスタンスには、Top of Rack スイッチに直接接続する AMD Solarflare X2522 ネットワークカードが搭載されています。 金融サービスのお客様、特に資本市場企業の企業向けに、これらのインスタンスは、ネイティブのレイヤー 2 (L2) マルチキャスト、Precision Time Protocol (PTP)、等長ケーブルを通じた決定論的なネットワークを提供します。これにより、お客様は、既存の取引インフラストラクチャに簡単に接続しながら、公正な取引と平等なアクセスに関する規制要件を満たすことができます。 インスタンス名 vCPU メモリ (DDR5) ネットワーク帯域幅 NVMe SSD ストレージ アクセラレーテッドネットワークカード アクセラレーテッド帯域幅 (Gbps) bmn-sf2e.metal-16xl 64 512 GiB 25 Gbps 2 x 8 TB (16 TB) 2 100 bmn-sf2e.metal-32xl 128 1,024 GiB 50 Gbps 4 x 8 TB (32 TB) 4 200 2 つ目のインスタンスタイプである bmn-cx2 は、高スループットと低レイテンシーを実現するように最適化されています。このインスタンスは、高速 Top of Rack スイッチに物理的に接続された NVIDIA ConnectX-7 400G NIC を搭載し、ほぼラインレートで動作する最大 800 Gbps のベアメタルネットワーク帯域幅を提供します。ネイティブのレイヤー 2 (L2) マルチキャストとハードウェア PTP サポートを備えたこのインスタンスは、リアルタイムの市場データ配信、リスク分析、通信分野の 5G コアネットワークアプリケーションなどの高スループットワークロードに最適です。 インスタンス名 vCPU メモリ (DDR5) ネットワーク帯域幅 NVMe SSD ストレージ アクセラレーテッドネットワークカード アクセラレーテッド帯域幅 (Gbps) bmn-cx2.metal-48xl 192 1,536 GiB 50 Gbps 4 x 4 TB (16 TB) 2 800 つまり、新世代の Outposts ラックは、幅広いオンプレミスワークロード、さらには極めて厳しいレイテンシーとスループット要件を満たす必要があるミッションクリティカルなワークロードのためにも、強化されたパフォーマンス、スケーラビリティ、回復力を提供します。 AWS マネジメントコンソール から選択して注文を開始できます。新しいインスタンスは、クラウドとオンプレミスで同じ API、AWS マネジメントコンソール、オートメーション、ガバナンスポリシー、セキュリティコントロールをサポートすることで、リージョンレベルのデプロイとの一貫性を維持し、デベロッパーの生産性と IT 効率を高めます。 知っておくべきこと リリース時点では、第 2 世代の Outposts ラックは、米国とカナダに出荷でき、米国東部 (バージニア北部およびオハイオ)、米国西部 (オレゴン)、欧州西部 (ロンドンおよびフランス)、アジアパシフィック (シンガポール) を含む 6 つの AWS リージョンに紐づけて運用できます。さらに多くの国および地域、ならびに AWS リージョンのサポートの提供が近日中に開始される予定です。リリース時点では、第 2 世代の Outposts ラックは、前世代の Outposts ラックで提供されていた AWS サービスのサブセットをローカルでサポートします。さらに多くの EC2 インスタンスタイプと AWS サービスのサポートの提供が近日中に開始される予定です。 詳細については、 AWS Outposts ラック の製品ページと ユーザーガイド にアクセスしてください。オンプレミスのニーズについて相談する準備が整っている場合は、 Outposts のエキスパート にご相談いただくこともできます。 – Micah 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2025 年 4 月 17 日に「 AWS オンラインセミナー: 進化した Amazon EKS で Kubernetes の運用をシンプルに 」をオンラインで開催しました。 本イベントは、初期セットアップや Kubernetes クラスターに関連する機能の更新にかかる手間を減らす Amazon EKS の新機能である Amazon EKS Auto Mode のリアルな活用方法と、適材適所なマネージド Kubernetes 環境を実現する Amazon EKS Hybrid Nodes によるハイブリッドアーキテクチャを紹介しました。また Amazon EKS を含む AWS 環境におけるプラットフォームエンジニアリングの実践例を通じて開発者体験を向上するアプローチについても解説しました。 セッションの紹介 AWS メンバーから、Amazon EKS に関する 4 つのセッションを 2 時間でお届けしました。本記事の中に資料のリンクを記載しておりますので、ぜひご活用ください！ Kubernetes の運用をシンプルにする Amazon EKS のアプローチ AWS 事業開発マネージャ 中村 健太郎 資料ダウンロード AWS 事業開発マネージャ 中村より、Amazon EKS を活用した Kubernetes の運用をシンプルにするアプローチについて解説しました。Kubernetes の利用が広がる中で、Amazon EKS も進化しており有効活用していただけるシーンが増えてきています。この進化により Kubernetes をより扱いやすいものにし、クラウドでもオンプレミスでも今までより幅広いお客様に活用していただけるようになっています。Kubernetes 環境の運用を効率化し、開発者体験を向上するための時間を確保することで、更にシステムが改良されビジネスへの貢献に繋げられるのではないかと考えています。最新の Amazon EKS を活用することで、どのような課題解決を解決し、どのような成果に繋げることができるのかについてお伝えしているので、AWS コンテナサービスの現在地と解決できる課題について理解したい方は、ぜひ資料をご確認ください。 運用効率を上げる Amazon EKS Auto Mode のリアルな活用方法 AWS ソリューションアーキテクト 祖父江 宏祐 資料ダウンロード AWS ソリューションアーキテクト 祖父江より、Amazon EKS Auto Mode の活用方法についてデモを交えてご紹介しました。Amazon EKS の運用オーバーヘッドを削減することを目的として、2024 年に Amazon EKS Auto Mode がリリースされています。Auto Mode では、最適なインスタンスの選択、リソースの動的なスケール、コストの継続的な最適化、コアアドオンの管理、AWS セキュリティサービスとの統合が行われるため、Kubernetes の深い専門知識がなくてもクラスター管理を自動化できます。現在 Amazon EKS を活用いただいている方、あるいはこれから Amazon EKS を活用していく予定の方は、ぜひ資料をご確認いただき、Auto Mode についての理解を深めて頂けると幸いです。 EKS Hybrid Nodes によるハイブリッドクラウド環境における Kubernetes 運用体験の統一 AWS ソリューションアーキテクト 鈴木 祥太 資料ダウンロード AWS ソリューションアーキテクト 鈴木より、Amazon EKS Hybrid Nodes の活用方法についてご紹介しました。近年、Kubernetes はコンテナオーケストレーターのデファクトスタンダードとして重要な存在になっています。そのため、クラウドやオンプレ、エッジなど様々な環境で Kubernetes クラスターを構築および運用することも増えてきています。しかし、その際に課題になるのが各環境に点在する Kubernetes クラスターの運用管理の負荷になります。2024 年にリリースされた Amazon EKS Hybrid Nodes を活用することで、Amazon EKS のメリットを活かしつつ、ハイブリッド環境での Kubernetes 運用体験を統一できます。ハイブリッド環境における Kubernetes クラスターの運用に課題を感じている方は、ぜひ資料をご確認ください。 Amazon EKS におけるプラットフォームエンジニアリングの実践 AWS ソリューションアーキテクト 後藤 健汰 資料ダウンロード AWS ソリューションアーキテクト 後藤より、Amazon EKS におけるプラットフォームエンジニアリングの実践手法についてご紹介しました。ビジネスの拡大やサービスの増加に伴う開発組織の急速な規模拡大により、組織には様々な課題が生じます。そのような状況下で、開発者体験や生産性を向上させ、ビジネス価値の創出を加速することを目的とした「プラットフォームエンジニアリング」というアプローチが、近年注目を集めています。また多くの企業が Amazon EKS で内部開発者プラットフォームを構築・運用しており、開発生産性の向上に寄与しています。全ての組織の要件に合致するプラットフォームというものは存在しませんが、Amazon EKS や AWS を活用することで、さまざまなプラットフォームアーキテクチャを実現できます。本セッションでは、Amazon EKS を活用したプラットフォームアーキテクチャパターンについて解説しています。プラットフォームエンジニアリングに興味のある方は、ぜひ資料をご確認ください。 おわりに 本セミナーにご参加いただいた皆様、改めてありがとうございました。今後も様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 最近、SNS で流行っていた生成 AI による手相占いをやって自己肯定感を上げています。 さて、今週・来週は、生成 AI のイベントが盛りだくさんです。 5 月 8 日 (木）： AI Agent の効果・リスク・実装方法・組織展開を 1 日で学ぶ 5 月 13 日 (火)： Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ 5 月 14 日 (水)：JAWS-UG Expert Online: Amazon Q Developer 特集 (リンクは下記イベントガイド記事を参照) 5 月 15 日 (木)： GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 「 5月開催の AWS 生成 AI イベントガイド 」というブログで開催予定のイベントをまとめていますのでぜひご覧ください！ また、6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 の 事前登録 ができるようになっています。今年も多くの生成 AI セッションを用意しています。登録をお忘れなく！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、4 月 28 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「より豊かなコンテキストのための Model Context Protocol (MCP) による Amazon Q Developer CLI の拡張」を公開 4 月 29 日に Amazon Q Developer CLI にて MCP (Model Context Protocol) のサポートが開始 されました。本ブログでは、Amazon Q Developer に PostgreSQL の MCP サーバーの設定を行い、テーブル構造が反映された SQL クエリ文を生成したり、ER 図を生成したりする手順が紹介されています。大変注目のアップデートですので是非お試しください！ ブログ記事「Writer の Palmyra X5 および X4 の基盤モデルが Amazon Bedrock で利用可能に」を公開 4 月 28 日に Writer の Palmyra X5 および X4 モデルが Amazon Bedrock で提供開始 しました。特に大きなコンテキストウィンドウをサポートしているのが特徴で、Palmyra X5 は 100 万トークン、Palmyra X4 は 12.8万 (128K) トークンをサポートしています。本ブログでは、Palmyra X5 および X4 の特徴や使い方例を紹介しています。 ブログ記事「Meta の Llama 4 モデルが Amazon Bedrock サーバーレスで使用可能に」を公開 以前から Amazon SageMaker JumpStart で使用可能となっていた、 Meta社の Llama 4 Scout 17B と Llama 4 Maverick 17B が、4 月 29 日に Amazon Bedrock で利用いただけるようになりました。Amazon Bedrock を通じて利用することで、サーバーレスのメリットや Converse API を利用することによるアプリケーション統合のしやすさのメリットを享受いただけるようになっています。 サービスアップデート サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション Amazon Q Developer CLI が Model Context Protocol （MCP）をサポート開始 Amazon Q Developer CLI で Model Context Protocol (MCP) のサポートを開始しました。MCP とは、LLM が外部ツールや API などにアクセスする方法を標準化したオープンプロトコルです。今回のサポートにより、外部情報を参照した応答を開発者は得ることができるようになります。 上記のブログ をぜひ参照ください。 Amazon Q Developer in chat applications が AWS Systems Manager のノードアクセス承認をサポート 先日 AWS Systems Manager にて、 ノード (EC2 インスタンス) へのログイン権限を一時的に付与するジャストインタイムノードアクセス機能が発表 されました。従来はマネジメントコンソールを通じてログインの承認を行う必要がありましたが、今回の Amazon Q Developer in chat のサポートにより、ノードアクセスの承認作業を Microsoft Teams と Slack 経由で行えるようになりました。 Amazon Q Developerが、IDE内の新しいエージェント型コーディング体験を発表 エージェント型コーディングとは、ユーザーが与えた自然言語の指示を AI エージェントが理解し自ら解決策を考えコード生成やファイル修正などを行う技術です。この機能は、すでに Amazon Q Developer CLI で利用可能でしたが、今回 IDE で利用可能となりました。本機能は Claude Sonnet 3.7 モデルが搭載されており、日本語含む多言語を対応しています。IDE は現在 Visual Studio Code に対応しており JetBrains と Eclipse のサポートも間もなく開始される予定です。 Amazon Q Business が匿名ユーザーアクセスをサポート Amazon Q Business の匿名ユーザーアクセスの一般提供を開始しました。この機能により、お客様は公開されているコンテンツを使用して、匿名ユーザー向けの Q Business アプリケーションを作成できるようになります。例えばウェブサイトの Q&A ページで本機能を提供することで、訪問者のサポート体験を向上させることが可能です。この匿名モードで作成された Q Business アプリケーションは、API 消費量に基づいて課金されます。本機能は、米国東部（バージニア北部）、米国西部（オレゴン）、ヨーロッパ（アイルランド）、およびアジアパシフィック（シドニー）リージョンで利用可能です。 サービスアップデート – アプリケーション開発のためのツール WriterのPalmyra X5およびX4モデルがAmazon Bedrockで利用可能に 上記のブログ紹介 で触れたように、Writer の Palmyra X5 および X4 モデルが Amazon Bedrock で利用可能になりました。大きなコンテキストウィンドウをサポートするのに加え、高度な推論、マルチステップのツール呼び出し、RAG（検索拡張生成）などの複雑なタスクに優れています。日本語での動作が確認できており 対応言語ごとのベンチマークも公開 されています。現在は米国西部 (オレゴン) からクロスリージョン推論で呼び出すことが可能です。 Meta の Llama 4 が Amazon Bedrock で完全マネージド型として利用可能に こちらも ブログ紹介 で触れたように、Llama 4 Scout 17B と Llama 4 Maverick 17B が Amazon Bedrock で利用可能になりました。Llama 4 Scout 17B は、最大1,000万トークンのコンテキストウィンドウをサポートし、包括的な分析や推論を必要とするアプリケーションに対応可能です。Llama 4 Maverick 17B は画像とテキストの理解に優れた汎用モデルとなっています。本機能は、米国東部（バージニア北部）および米国西部（オレゴン）リージョンの Amazon Bedrock で利用可能です。また、クロスリージョン推論を通じて米国東部（オハイオ）からもアクセス可能です。 Amazon Bedrock Model Distillation (モデル蒸留) が一般提供開始 モデル蒸留とは、高性能なモデル（教師）から小規模なモデル（生徒）に知識を転送することで、特定のユースケースにおいて高精度でありながら処理速度が速くコスト効率の高いモデルの構築を目指す技術を指します。もともとプレビューでしたが今回一般提供開始となりました。一般提供開始に伴って対応モデルが拡大し、Amazon Nova Premier（教師）、Nova Pro（生徒）、Claude 3.5 Sonnet v2（教師）、Llama 3.3 70B（教師）、Llama 3.2 1B/3B（生徒）が追加されています。詳細は ドキュメント や ブログ を確認ください。 複雑なタスクに対応する最高性能とモデル蒸留機能を持つ Amazon Nova Premier の一般提供を開始 最高性能のマルチモーダル基盤モデル「Amazon Nova Premier」の一般提供を発表しました。Nova Premier は、これまでに発表されている Nova ファミリーモデルの中で最も高性能で、優れたインテリジェンス、高いエージェント性能、100 万トークンのコンテキストウィンドウを提供します。また、Amazon Bedrock Model Distillation (モデル蒸留) を使用することで、特定のニーズに合わせた高性能・高費用対効果・低レイテンシーの Nova Pro、Lite、Micro バージョンを作成可能です。現在、クロスリージョン推論を通じて、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）リージョンの Amazon Bedrock で利用可能です。 ブログ や ユーザーガイド もぜひご覧ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

本稿は、アプリケーション開発支援を担当された株式会社アイスリーデザイン様と Amazon Web Services Japan の共同執筆によるものです。 はじめに 引越しの際には見積もりの取得が不可欠ですが、予定調整や家財の確認など様々な課題が存在します。本稿では、アート引越センター株式会社様が提供する「ぐるっと AI 見積り」アプリケーションの事例をご紹介します。本アプリケーションは、顧客自身がスマートフォンで室内を撮影するだけで AI が自動的に引越しの見積もりを行い、プロセスを大幅に効率化します。 背景 物流業界における 2024 年問題や働き方改革、労働力不足といった社会的課題への対応、そして多様化する顧客ニーズに応えるため、引越業界においても AI などの最先端テクノロジーを活用したデジタルトランスフォーメーションが求められています。従来の引越し見積りでは、営業担当者による現地訪問または遠隔確認が必要であり、属人的要素が強く、見積もりにばらつきが生じるという課題がありました。これらの背景から、アート引越センター様の DX 推進施策の一環として、AI 技術を活用した自動見積りサービス「ぐるっと AI 見積りアプリ」が開発されました。 アイスリーデザイン様は今まで 14 年にわたり AWS のサービスを活用してきた実績があり、AWS の高い信頼性と、JAWS-UG などの AWS コミュニティとのつながりによる豊富な情報資源に魅力を感じ、AWS を採用することにしました。 アプリケーションの概要 本アプリケーションでは、ユーザー自身が室内を撮影し、デバイス上で 3D モデルを生成します。アプリ内に再現された室内をユーザーが確認し、見積り依頼を行うと、AI が 3D モデル内のソファーやベッドなどの家具、洗濯機・冷蔵庫といった家電、食器棚・タンスなどの収納などを検出し、自動的に見積りを行います。 （出展: 株式会社アイスリーデザイン） ソリューション/構成内容 推論には、PointNeXt をベースとした学習済みモデルを使用し、Amazon SageMaker Serverless Inference によるサーバーレス環境で非同期推論を実行しています。アプリケーション内で生成された 3D モデルはポイントクラウド（点群データ）に変換され、Amazon S3 にアップロードされます。API を介して見積りリクエストを受け付け、AWS Step Functions を通じて非同期推論リクエストを行う構成となっています。 （出展: 株式会社アイスリーデザイン） アプリケーションはコンテナベースで開発され、運用負荷の軽減を目的として、API と管理画面には Amazon ECS と AWS Fargate が採用されています。また、引越特有の季節性や時間帯による需要の偏りに対しても、オートスケーリングの容易な設定により対応しています。 導入効果 本アプリケーションの導入により、以下の効果が得られました： 営業担当者による見積り作業の無人化 利用者の見積り待ち時間の 15 分から 5 分への短縮 単身引越しにおける完全無人対応の実現 アート引越センター様は、「ぐるっと AI 見積り」の導入により、従来の人による見積りの誤差を解消し、正確な積算が可能になったと評価しています。特に喜ばしかったのは、引越しサービスそのものではなく AI アプリに対する顧客からの高評価で、技術に精通したエンジニアからも称賛の声が寄せられたそうです。また、3D モデルによる視覚的な情報共有が社内業務を効率化し、作業スタッフの準備をスムーズにした点も大きな成果でした。アプリのダウンロード後の実際の利用率や申し込み率も高く、この革新的な取り組みが顧客体験と業務効率の両面で成功を収めていることを実感されています。 アプリ利用者からもアプリに対するフィードバックを得られ、高い評価をいただいています。 結論 アート引越センター様における本 AI アプリケーションの導入は、引越し見積りプロセスの自動化と標準化を実現し、業務効率の向上と顧客満足度の改善に大きく寄与しています。サーバーレス環境の活用により、インフラ構築と運用の負荷を軽減し、アプリケーション開発に注力することで、優れたユーザー体験の提供が可能となりました。 現在、単身の引越しについては予約までシステムで完結できるようになっており、今後はさらなる適用範囲の拡大に向けて改善が続けられています。 本事例が、物流業界における AI 活用とデジタルトランスフォーメーションのさらなる推進の一助となれば幸いです。 著者について 大松 宏之 (Hiroyuki Omatsu) @_daimatsu_ テクニカルソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。好きなサービスは、AWS Direct Connect と AWS Client VPN です。 石岡 陸 (Riku Ishioka) LinkedIn AWS Japan のソリューションアーキテクトとして、Web 業界のお客様を中心にアーキテクチャの設計・構築を支援しています。ゲームと開発が趣味です。

組織が成長するにつれて、クラウドインフラの管理はますます複雑になり、コストを最適化するための高度な財務戦略が必要になります。 AWS Savings Plans は、1 年または 3 年の期間にわたって 1 時間あたりの米ドル (USD) で測定される一定の使用量をコミットしていただく代わりに、AWS サービスの使用料金を大幅に節約できる柔軟な価格モデルを提供します。多くの場合、個々のチームが直接購入したり、FinOps チームが特定のアカウントで購入したりすることで、複数の Savings Plans が採用されています。これらの戦略は大幅なコスト削減につながる可能性がある一方で、公平かつ効果的なチャージバック (※) プロセスを確保する上では複雑さも増すことにもなります。 ※訳注：チャージバックとは、組織の内部会計プロセスを通じて、発生した費用を実際にそのサービスやリソースを使用した部門等に請求する仕組みのことを指します。詳細は こちら のドキュメントをご覧ください。 本記事では、管理アカウント、連結アカウント、またはその両方で購入した Savings Plans のコストを、その割引を受けたアカウントに適切に配分するチャージバックの仕組みを定義する方法について説明します。それを理解していただくことで、Savings Plans 割引の恩恵を受けたアカウントを特定し、その具体的な使用状況に基づいてチャージバックする適切な金額を算出できるようになります。 Savings Plans の割引共有について AWS では、同じ AWS Organizations の organization (組織) に属する アカウント間で Savings Plans の割引を共有 することが可能です。Savings Plans の時間単位のコミットメント料金はそれを購入したアカウントに請求されますが、共有が有効になっている場合、割引は organization 内の複数のアカウントに適用される可能性があります。Savings Plans の割引は、まず Savings Plans を購入したアカウント内のすべての対象となるリソースに適用されます。割引を適用できるオンデマンド使用量がそれ以上なく “未使用のコミットメント” が生じる場合には、使い切れていないコミットメントは organization 内の他の連結アカウント (メンバーアカウント) で使用されます。 共有によって節約効果を最大化 できますが、その一方で共有による恩恵を organization 全体に適切に配分するには追加の労力が必要になる場合があります。Savings Plans の割引の恩恵を受けるすべてのアカウントに、Savings Plans のコミットメント料金を (AWS に対して直接) 支払う責任があるわけではありません。コミットメントのコストを負担しているアカウント (つまりコミットメントを購入しているアカウント) 以外が Savings Plans の恩恵を受けることもあります。そのため、恩恵 (つまり割引) が共有された場合には、慎重にコスト配分を行い各アカウントに対して公平に請求が行われるようにする必要があります。 Savings Plans の仕組みと、共有が Savings Plans に与える影響について理解できたので、次は コストと使用状況レポート (CUR) 2.0 のデータを使用したチャージバック戦略を見てみましょう。 前提条件 AWS Data Export により CUR 2.0 でエクスポート (※) を作成し、データをカタログ化するように AWS Glue を設定します。これにより、 Amazon Athena を使用してクエリを実行し、CUR 2.0 のデータを分析することができます。これを実現するには、次のことを行う必要があります。 ※訳注：AWS Data Export においてエクスポートされるデータのことを「エクスポート」と呼びます。 1. AWS Data Export による CUR 2.0 の設定 AWS マネジメントコンソール にサインインします。 AWS 請求とコスト管理 に移動します。[ データエクスポート (Data Export) ] を選択し、[ 作成 (Create) ] をクリックしてエクスポートの設定を開始します。 図 1. データエクスポートの作成 [ 標準データエクスポート (Standard data export) ] を選択し、エクスポート名を指定し、データテーブルタイプとして [ CUR 2.0 ] を選択します。 図 2. エクスポートの設定 [ リソース ID を含める (Include resource IDs) ] と [ コスト配分データを分割 (Split cost allocation data) ] の有効化はオプションです。 時間粒度として [ 時間単位 (Hourly) ] を選択します。 圧縮形式として [ Parquet ] を設定し、ファイルのバージョニングのために [ 既存のデータエクスポートファイルを上書き (Overwrite existing data export file) ] を選択します。 図 3. エクスポート配信オプションの設定 CUR 2.0 データを保存する宛先の Amazon S3 バケットとパスプレフィックスを指定します。 [ 作成 (Create) ] を選択して設定を完了します。(※) ※訳注：設定後、S3 バケットに CUR 2.0 のエクスポートが配信されるまで最大 24 時間かかります。 2. CUR データをクエリするための AWS Glue の設定 AWS Glue コンソールに移動し、[ Data Catalog ] > [ Crawlers ] を選択して CUR 2.0 データのカタログ化プロセスを開始します。 [ Create crawler ] をクリックして、一意のクローラー名を割り当てます。[ Next ] をクリックします。 図 4. AWS Glue Crawler の作成 [ Is your data already mapped to Glue tables? ] の質問については、[ Not yet ] を選択します。 [ Add a data source ] をクリックし、[ S3 ] を選択して、(AWS Data Export 内で設定した) CUR 2.0 データがエクスポートされる Amazon S3 の場所を以下の形式で指定します。 s3://<bucket-name>/<prefix>/<export-name>/data/ 図 5. CUR データをクローリングする S3 データソースの作成 [ Add an S3 data source ] をクリックし、[ Next ] をクリックします。 [ Create new IAM role ] をクリックすると、新しい AWS Glue ロールが作成されます。このロールにより、Glue は CUR 2.0 ファイルが保存されている S3 バケットにアクセスできるようになります。[ Next ] をクリックします。 [ Add database ] をクリックしてターゲットデータベースを作成します。データベース名を入力し、[ Create database ] をクリックします AWS Glue コンソールに戻り、前のステップで作成したデータベースを選択します。クローラーのスケジュールを [ On demand ] に設定して、必要な場合にのみ実行するようにします。[ Next ] をクリックします。 設定を確認し、[ Create crawler ] を選択します。 クローラーの準備ができたら、クローラーを選択して [ Run ] をクリックします。これにより、データが処理されてカタログ化され、Amazon Athena からアクセス可能なテーブルが作成されます。(※) ※訳注：データエクスポートの設定後、S3 バケットに CUR 2.0 のエクスポートが配信されるまで最大 24 時間かかります。まだ配信されていない状態でクローラーを実行してもカタログ化およびテーブルの作成はされないため、クローラーの実行はエクスポートが配信されるまでお待ちください。 CUR 2.0 を使って Savings Plans のチャージバックを行う 上記の前提条件を設定したら、以下のクエリを使用して、Savings Plans の割引を受け取った連結アカウントを特定します。[ Effective Cost ] 列には、連結アカウントで使用された Savings Plans のコミットメントの金額に対応するコストが表示されます。これが個々の連結アカウントへのチャージバックに使用する金額になります。 Amazon Athena コンソールに移動してクエリを実行します。Athena での SQL クエリの実行に関する 詳細についてはこちら をご覧ください。 以下のクエリをクエリエディタにコピーします。クエリのテーブル名を更新してください (※)。 ※訳注：具体的には、クエリ内の 59 行目の「<Table Name>」を Glue テーブルのデータベース名 (data) で置き換えてください。 ※訳注：以下のクエリは、実行日の前月の 請求期間 (1 か月) を対象に分析を行うことを想定しています。先述の設定で CUR 2.0 のエクスポートを初めて S3 バケットに出力した場合、その前月のエクスポートは存在しないため、クエリ自体は成功するもののクエリ結果は空になります。その場合は 62 行目の「 INTERVAL '1' month 」の「 1 」を「 0 」に修正して、クエリ実行当月 (その時点まで) の CUR 2.0 エクスポートを分析対象にするようにしてみてください。 select DATE_FORMAT(bill_billing_period_start_date,'%Y-%m-%d') as "Date" , line_item_usage_account_id as "Account Id" , savings_plan_offering_type as "Savings Plan Type" , split_part(savings_plan_savings_plan_a_r_n, '/', 2) AS "Saving Plan ID" , savings_plan_payment_option as "Savings Plan Payment Option" , line_item_line_item_type as "Item Type" , sum( case when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0 else savings_plan_recurring_commitment_for_billing_period end ) + sum( case when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0 else savings_plan_amortized_upfront_commitment_for_billing_period end ) as "Savings Plan Fee" , sum( case when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0 else savings_plan_recurring_commitment_for_billing_period end ) + sum( case when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0 else savings_plan_amortized_upfront_commitment_for_billing_period end ) - sum(savings_plan_used_commitment) as "Unused commitment" , sum( case when line_item_line_item_type = 'SavingsPlanRecurringFee' then 0 else savings_plan_savings_plan_effective_cost end ) as "Effective Cost" , sum( case when line_item_line_item_type = 'SavingsPlanRecurringFee' then 0 else line_item_unblended_cost end ) - sum( case when line_item_line_item_type = 'SavingsPlanRecurringFee' then 0 else savings_plan_savings_plan_effective_cost end ) - ( sum( case when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0 else savings_plan_recurring_commitment_for_billing_period end ) + sum( case when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0 else savings_plan_amortized_upfront_commitment_for_billing_period end ) - sum(savings_plan_used_commitment) ) as "Savings" from <Table Name> where line_item_line_item_type in ('SavingsPlanCoveredUsage', 'SavingsPlanRecurringFee') and bill_billing_period_start_date = DATE_TRUNC('month', CURRENT_DATE) - INTERVAL '1' month group by bill_billing_period_start_date , line_item_usage_account_id , savings_plan_offering_type , savings_plan_savings_plan_a_r_n , savings_plan_payment_option , line_item_line_item_type order by sum(savings_plan_savings_plan_effective_cost) desc これをよりよく理解するために、AWS CUR 2.0 にある 2 つの重要なコンポーネントを詳しく見てみましょう。 SavingsPlanRecurringFee :これは出力内で「 Item Type = 'SavingsPlanRecurringFee' 」であるフィールドです。これは、Savings Plans の購入アカウントがそのコミットメントに対して支払う義務があるコストを表します。これはコミットメントの全額が使用されたかどうかにかかわらず固定費です。Savings Plans の種類に応じて、この金額は非ブレンドコストまたは償却コストとして表示されます。 SavingsPlanCoveredUsage : これは出力内で「 Item Type = 'SavingsPlanCoveredUsage' 」であるフィールドです。これは Savings Plans の実際の使用量を表しており、コミットされた Savings Plans のうち、organization 全体での使用量にどの程度適用されたかを示します。organization の構造とワークロードの分散状況によっては、この使用量が複数のアカウントに分散される可能性があります。 Savings Plans のチャージバックを行うには、連結アカウントごとの「 Effective Cost 」列を使用する必要があります。この列には、各連結アカウントで使用された Savings Plans のコミットメントの割合に相当するコストが表示されています。これにより、各連結アカウントが Savings Plans から受けた恩恵に応じて Savings Plans の料金を確実に負担することができるようになります。 SavingsPlanRecurringFee のある行の「 Unused Commitment 」列を確認することも重要です。この列の値が $0 より大きい場合は、Savings Plans が十分に活用されていないことを示しています。これは一見すると節約機会の損失のように見えるかもしれませんが、実際にそうであるかどうかの検証が重要です。組織は意図的に想定使用量をやや上回る Savings Plans のコミットメントをあえて購入することがあります。これは、未使用分のコストを考慮しても、割引による全体的な節約効果の方が大きく、organization 全体としては正味の節約効果が見込める可能性があるからです。 例 以下の表では、Savings Plans のタイプは「 No Upfront 」です。関連する「SavingsPlanRecurringFee」フィールドを確認すると、毎月の定期料金 (“Savings Plan Fee” 列) はアカウント ID Aに請求されています。Savings Plans を購入したアカウントはアカウント ID A であるため、アカウント ID A の対象となる使用量に対して最初に割引が適用されます。月額コミットメント $12,410.68 のうち、$8,363.12 がアカウント ID A にチャージバックされる実効コスト (“Effective Cost” 列) です。アカウント B は、定期 (月額) コミットメントのうち $1,361.26 を使用しており、これがアカウント B に請求されるチャージバック額になります。また、未使用のコミットメント (“Unused Commitment” 列) が $0 で、実効コスト (“Effective Cost” 列) の合計が定期料金 (“Savings Plan Fee” 列) と一致していることも確認できます。これは、Savings Plans が十分に活用されていることを示しています。 図 6. アカウント間の Savings Plans による恩恵の配分を示すレポートの例 別の例を見てみましょう。 以下の表では、Savings Plans のタイプが「 All Upfront 」であることがわかります。これは、請求期間における前払い金額の償却部分に相当します。データによると、「未使用のコミットメント (“Unused Commitment” 列)」は $0 であるため、Savings Plans はアカウント ID A で購入されており、かつアカウント ID A で完全に使い切られていることがわかります。この場合、Savings Plans の恩恵を受けているアカウントは (アカウント ID A の) 1 つだけであるため、定期料金 (“Savings Plan Fee” 列) が実効コスト (“Effective Cost” 列) と一致しています。 図 7. 購入アカウントによる Savings Plans の恩恵の使用状況を示すレポートの例 まとめ この記事では、Savings Plans の共有がその使用量に与える影響について説明しました。共有を有効にすると、Savings Plans の料金を支払うことなく Savings Plans の割引の恩恵を受けられるアカウントが存在する可能性があります。Savings Plans の料金を (AWS に対して直接) 支払う義務は、それを購入したアカウントのみにあります。 AWS Cost and Usage Report (CUR) 2.0 で “対象を絞ったクエリ” を実行することで、Savings Plans の割引を受けているすべての対象アカウントと、それぞれに請求すべき定期料金の割合を特定できるチャージバックの仕組みを設計しました。この戦略により、Savings Plans を保有しているアカウントにのみ請求するのではなく、社内固有のチャージバックの仕組みを使用して、使用量とそれによって得られた節約額に基づいて正確にアカウントにチャージバックできるようになります。この方法により、Savings Plans のコストと恩恵の両方を公正かつ透明に分配することができ、財務責任を実際の使用状況に合わせて調整するのに役立ちます。 この戦略により、透明性と説明責任が高まり、チーム全体での思慮深いクラウド利用を促進します。Savings Plans のメリットを享受した分に応じて各アカウントに適切に請求することで、組織全体でのコスト意識の向上につながります。 Alonso de Cosio Alonso de Cosio は AWS のプリンシパルテクニカルアカウントマネージャーです。彼の役割は、AWS のベストプラクティスを活用したソリューションの計画と構築をサポートするため、お客様に対して技術的な提言と戦略的なガイダンスを提供することです。 彼は、サーバーレス技術を使用して AWS 上でモジュール化可能でスケーラブルなエンタープライズシステムを構築することに情熱を注いでいます。プライベートでは、妻や愛犬との時間を大切にし、ビーチに行ったり旅行したりすることを楽しんでいます。 Ketan Kumar Ketan は、アイルランドのダブリンを拠点とする AWS のシニアテクニカルアカウントマネージャーです。彼の役割は、 AWS のベストプラクティスを活用してソリューションを計画・構築できるよう、お客様に戦略的な技術指導を提供することです。 彼は、お客様がスケーラブルで回復力が高く、費用対効果の高いアーキテクチャを構築できるようにすることに力を注いでいます。プライベートでは、妻や家族との時間を大切にし、旅行やビデオゲーム、映画鑑賞を楽しんでいます。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 GW が明けましたね。私は趣味のパデルに没頭していました。連休中にもAWSアップデートが続いていて、この週は Amazon Q Developer まわりのアップデートが多かった印象です。AI 関連のイベントが5月は多く開催される予定で、 こちらの Blog にまとまっています。ぜひ、ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年4月28日週の主要なアップデート 4/28(月) AWS Client VPN でクライアントルートの強制適用がサポートされました AWS Client VPN に新機能が追加され、デバイスのネットワークルートを監視と、VPN トラフィックの漏洩を防止によるリモートアクセスのセキュリティを強化が可能となりました。この機能は、設定された内容に従って VPN トンネルを介してトラフィックが確実に流れるように、ユーザーのデバイスのルーティングテーブルを継続的に追跡します。 Writer の Palmyra X5 および X4 モデルが Amazon Bedrock で利用可能に Writer 社の高性能な基盤モデルである Palmyra X5 と X4 が、Amazon Bedrock で利用可能になりました。これは、Writer 社のモデルを完全マネージド型のサーバーレスモデルとして提供する初めてのクラウドプロバイダーとなります。これらのモデルは Stanford の HELM ベンチマークでトップランクを獲得しており、高度な推論や複数ステップのツール呼び出し、組み込みの RAG (検索拡張生成) などの複雑なタスクを得意としています。現在、Writer 社の Palmyra モデルは US West (オレゴン) で利用可能です。詳細は、こちらの ブログ もご参照ください。 Amazon CloudFront での HTTP 検証による公開証明書の自動化 AWS Certificate Manager (ACM) と Amazon CloudFront において、HTTP の検証済みパブリック証明書の自動化機能が発表されました。この新機能により、CloudFront をご利用のお客様は、新しい CloudFront のコンテンツ配信アプリケーションを作成する際に、チェックボックスを選択するだけで TLS 通信に必要なパブリック証明書を取得できるようになりました。ACM と CloudFront が連携して、必要な公開証明書の要求、発行、CloudFront との関連付けを自動的に行います。 4/29(火) AWS Amplify がデータシーディングを導入 AWS Amplify にデータシーディング機能が追加されました。この機能により、Amazon Cognito、AWS AppSync、Amazon DynamoDB、Amazon S3 といった複数のサービスにまたがるテストデータの作成が容易になります。シーディングとは、アプリケーションの開発やテストに必要なサンプルデータを自動的に作成することを指します。これまで開発者は、認証が必要なリソースをテストする際に、テストユーザーの作成や認証の設定を手動で行う必要がありました。新機能では、API やコマンドラインインターフェース (CLI) を使用して、テストユーザーの作成から関連リソースの設定まで、プログラムで自動的に行えるようになります。 Amazon Q Developer CLI が Model Context Protocol (MCP) をサポート Amazon Q Developer CLI が Model Context Protocol (MCP) に対応しました。Amazon Q Developer CLI は、開発者向けの AWS が提供するコマンドラインツールです。今回の対応により、開発者はより豊かなコンテキストを活用した開発作業が可能になりました。MCP は AI モデルが外部ツールやデータソース、API に安全かつ構造化された方法でアクセスする方法を標準化するオープンプロトコルです。これまでは Amazon Q Developer CLI でネイティブに利用可能なツールのみを使用して、コード生成や開発作業の実行を支援していました。MCP ツールのサポートにより、AWS が事前に用意した多数の統合機能や、標準入出力 (stdio) トランスポート層をサポートする MCP サーバーをツールとして Q Developer CLI に統合できるようになりました。これにより、ネイティブツールと MCP サーバーベースのツールを組み合わせたタスクを実行することで、より状況に応じたカスタマイズされた応答が可能になります。詳しくはこちらの Blog もご参照ください。 AWS Budgets が追加のコスト指標とフィルタリング機能をサポート AWS Budgets (予算管理サービス) に、コスト管理をより柔軟に行える新機能が追加されました。この更新により、クラウドコストの追跡と管理方法が大幅に改善されます。新しく追加された機能では、割引後のコストを監視できる「net unblended costs (正味未調整コスト)」や「net amortized costs (正味償却コスト)」といった新しいコスト指標での予算作成が可能になりました。また、予算作成時に特定の項目を除外することができ、Cost Explorer で使用される「reservation applied usage (予約インスタンス適用使用量)」「Savings Plan Upfront Fee (Savings Plan 前払い料金)」「Savings Plan Covered Usage (Savings Plan 対象使用量)」などのチャージタイプにも対応しています。これらの新機能により、自動適用される割引や高度なフィルタリング機能を活用して、アプリケーション、チーム、またはコストセンターの実際のコストに対する予算管理が可能になります。 4/30(水) AWS Clean Rooms で複数の結果受信者をコラボレーションでサポート AWS Clean Rooms の新機能として、複数のコラボレーションメンバーが分析結果を受け取れるようになりました。この機能強化により、Spark SQL を使用したクエリの分析結果を、複数のメンバーが直接受け取ることが可能になります。これまでは追加の監査メカニズムが必要でしたが、その必要性がなくなり、使いやすさと透明性が向上しました。具体的な使用例として、メディアパブリッシャーと広告主のコラボレーションでは、パブリッシャーが共有データセットに対してクエリを実行し、その結果を両者の指定した Amazon S3 ロケーションに自動的に送信して検証することができます。 Amazon SageMaker の Visual ETL とクエリエディタのスケジューリング機能が統合 Amazon SageMaker の Visual ETL とクエリエディタに対して、スケジューリング機能が統合されました。この新機能により、データ処理やクエリの実行を簡単にスケジュール設定できるようになりました。Amazon SageMaker の次世代バージョンは、データ、分析、AI を一元管理する中心的なプラットフォームとなっており、SageMaker Unified Studio という単一の開発環境を提供しています。Visual ETL は、ドラッグアンドドロップのインターフェースを使用して ETL フローを構築し、Amazon Q を活用してフローを作成できる機能です。また、クエリエディタツールでは、クエリの作成、実行、結果の確認、チームとの共有が可能です。 複雑なタスクとモデル蒸留の教師に最適な最高性能モデル Amazon Nova Premier を発表 Amazon が新しい大規模言語モデル「Nova Premier」を発表しました。これは Amazon の中で最も高性能なマルチモーダル基盤モデルとなります。Nova Premier は、長文ドキュメント、動画、大規模なコードベースの処理、そして複数のステップを必要とする作業の実行などの複雑なタスクを処理できます。また、Amazon Bedrock Model Distillation と組み合わせることで、特定のニーズに合わせたカスタムモデルを作成することもできます。Nova Premier はUS East (バージニア)、US East (オハイオ)、クロスリージョン推論の US West (オレゴン)で、Amazon Bedrock から利用可能です。 5/1(木) Amazon Q Developer が IDE 内で新しいエージェント型のコーディング体験を発表 Amazon Q Developer の IDE 内での新しいエージェント型コーディング体験が発表されました。この新機能は、ソフトウェア開発の方法を大きく変革するものです。自然言語を理解し、複雑なワークフローをスムーズに実行できる新しいコーディング体験を提供します。この新機能の特徴として、Q Developer はコードの提案だけでなく、ファイルの修正、コード差分の生成、コマンドの実行などを自然言語による指示で行うことができます。また、透明性のある推論プロセスにより、Q Developer があなたの要件をどのように解釈し、コードを変更しているかの思考プロセスを確認することができます。さらに、マルチターンの会話機能により、コードベース全体と開発セッション全体でコンテキストを維持しながら、双方向の対話が可能です。そして、細かな制御機能により、コードの自動修正を選択するか、ステップバイステップでのレビューと確認を行うかを選択できます。 Amazon Bedrock モデルディスティレーションが一般提供開始 Amazon Bedrock の Model Distillation が一般提供開始となりました。Model Distillation とは、より高性能なモデル (教師モデル) から、より軽量なモデル (生徒モデル) へ知識を転移させる技術です。この技術により、特定のユースケースにおいて、高速で費用対効果の高い生徒モデルを教師モデルと同等の性能で実現できます。今回の一般提供では、新しいモデルとして Amazon Nova Premier (教師モデル) と Nova Pro (生徒モデル)、Claude 3.5 Sonnet v2 (教師モデル)、Llama 3.3 70B (教師モデル) と Llama 3.2 1B/3B (生徒モデル) がサポートされました。Amazon Bedrock Model Distillation を使用することで、エージェントのユースケースにおける関数呼び出しの予測を、より小規模なモデルで正確に実行できるようになり、応答時間の大幅な短縮とコストの削減が可能になります。詳細は、こちらの Blog と 製品ページ をご参照ください。 AWS がエネルギーデータインサイトのマネージド型サポートを発表 AWS Managed Service (AMS) を通じて Energy Data Insights (EDI) のマネージド型サポートを発表しました。これは、エネルギー業界のお客様が OSDU 標準に準拠した形で、地下データ管理プラットフォームを AWS 上で簡単に展開、管理、運用できるようにするサービスです。この発表により、AWS 上で EDI を自動的にデプロイでき、データ取り込みの所要時間を数週間から数時間に短縮し、最小限の手作業で地下データをインテリジェントに処理・整理することが可能になりました。EDI on AWS は従量課金制で、US East (バージニア北部)、US West (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、ヨーロッパ (アイルランド)、ヨーロッパ (パリ)、南アメリカ (サンパウロ) で利用可能です。詳細は 製品ページ をご参照ください。 5/2(金) Amazon Aurora と RDS 向けの新しいオープンソース AWS Advanced PostgreSQL ODBC ドライバーが利用可能に AWS から、PostgreSQL データベース向けの新しい ODBC ドライバーが一般提供開始されました。このドライバーは Amazon RDS と Amazon Aurora PostgreSQL 互換エディションのデータベースクラスターで利用できます。このアップデートの重要なポイントは、フェイルオーバーやスイッチオーバーの時間が大幅に短縮され、従来のオープンソースドライバーと比べて数十秒かかっていた切り替え時間が一桁秒数まで改善されたことです。また、 Aurora Limitless のサポートや、AWS Secrets Manager、AWS IAM、フェデレーテッドアイデンティティによる認証もサポートしています。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。