はじめに こんにちは、クラウドエース 事業推進本部 のエウゲニです。 Google Cloud Next Tokyo 2026で参加したセッション内容の要点をまとめてみました。 社内へのAI導入やクラウドインフラの最適化など、実務に直結する知見が共有されていたため、本記事にて共有します。 グリーとカプコンが語る、開発を劇的に変える Gemini 活用とエンタメの未来 企業（登壇者）：株式会社グリー（大久保 将様）、株式会社カプコン（井上 真一様） 本セッションでは、ゲーム開発の現場におけるAI活用のリアルな課題と展望が語られました。 AI導入の真の目的 AIを導入する最大の理

本稿は、2026 年 8 月 18 日に公開された “ Amazon EVS with NSX Federation for Disaster Recovery and Multi-site Networking ” を翻訳したものです。 はじめに Amazon Elastic VMware Service (Amazon EVS) が NSX Federation をサポートしました。これにより、AWS 上で VMware ワークロードを実行する際のエンタープライズ規模のネットワーク、ディザスタリカバリ (DR)、マルチサイトネットワークのための強力な新しいオプションが利用可能になります。 NSX Federation は、複数の NSX 環境を単一の Global Manager コントロールプレーンの下で接続する VMware のネットワーク機能です。オーバーレイネットワーク、セキュリティポリシー、ゲートウェイサービスを複数のロケーションに拡張し、各サイトを個別に設定するのではなく、複数サイトのネットワークを統一されたファブリックとして管理できます。 VMware Cloud Foundation Operations HCX (HCX) は、マイグレーションおよびマイグレーション中のネットワーク拡張のための VMware のソリューションです。NSX Federation は、大規模な Layer 2 拡張、ロケーション間での統一されたセキュリティポリシー、マルチサイトメッシュ接続、および 1 分未満のフェイルオーバーによるネイティブ DR を必要とするシナリオに対応することで、HCX を補完します。 この記事では、これが重要である理由、NSX Federation が HCX 単体では提供できないネットワーク機能をどのように拡張するか、そしてワークロードの真のマルチサイトネットワークをどのように実現するかを説明します。 課題: エンタープライズネットワークが単一ソリューションの範囲を超える場合 VMware HCX Network Extension (NE) は、マイグレーション中にサイト間で Layer 2 セグメントを延伸するための実績のある専用技術です。マイグレーションワークフローや小規模な DR シナリオでは効果的かつ迅速にデプロイできます。しかし、企業がスケールするにつれて、HCX に加えて追加の機能が必要になることがあります。 大量の VLAN 数 – 数百の VLAN を持つ環境では、アプライアンスペアごとの拡張ではなく、ファブリックレベルのアプローチが有効です。 統一されたセキュリティポリシー – 単一サイト内だけでなく、すべてのロケーションで一貫して適用される Distributed Firewall (DFW) ルール。 マルチサイトメッシュネットワーク – 複雑なハブアンドスポークトポロジなしに 3 つ以上のロケーションをネイティブにサポート。Federation により、ネットワーク全体を再設計することなく、設定ステップとして新しいサイトを追加できます。 ステートフル DR フェイルオーバー – フェイルオーバー中にステートフルサービスが完全に保持された状態での 1 分未満のネットワーク接続復旧。 ここで NSX Federation が登場します。HCX の代替ではなく、これらのエンタープライズ規模の要件に対応する補完機能です。 ソリューション: Amazon EVS 上の NSX Federation NSX Federation は、参加するすべてのロケーションにまたがる 単一の Global Manager によって管理される 、統一されたオーバーレイネットワークファブリックを作成します。HCX と並行して動作し、それぞれの技術がその強みを発揮します。 NSX Federation が提供する機能 機能 メリット 数千のセグメント Global Segments はフェデレーションファブリック全体で 数千にスケール 統一された Distributed Firewall (DFW) DFW ルールは Global Manager 上で一度定義され、すべてのロケーションで一貫して適用 マルチサイトメッシュ Federation は複数のロケーションをネイティブにサポート。3 番目や 4 番目のサイトの追加は設定ステップであり、複雑なポイントツーポイントリンクを構築することなく真のマルチサイト接続を実現 ステートフルゲートウェイフェイルオーバー Active-Standby Tier-0 ゲートウェイがステートフルサービス (NAT、Gateway Firewall) を含む 1 分未満のフェイルオーバー を提供 シングルペインオブグラス Global Manager がすべてのフェデレーションロケーションの一元管理を提供 マルチサイトネットワークの実践 Federation の大きな利点の 1 つは、マルチサイト接続です。従来のアプローチでは、3 つ以上のサイトを接続するには、個別のポイントツーポイントリンクを構築し、各ペア間のルーティングを管理する必要がありました。Federation は、すべてのロケーションを単一ファブリックのメンバーとして扱うことで、この複雑さを排除します。 サイト A のワークロードは、追加の設定なしに同じ Global Segment 上でサイト B またはサイト C と通信できます。 DFW ポリシーは、ファブリック内のどのサイトで実行されているかに関係なく、ワークロードに追従します。 Global Manager に登録してローカル Edge ノードをデプロイすることで、新しいサイトの追加ができます。既存ネットワークのオブジェクト (セグメント、ファイアウォールルール、ゲートウェイ) は自動的に新しいロケーションに拡張されます。 これにより、Federation は複数の AWS リージョンやアベイラビリティーゾーンをまたいで運用する組織や、オンプレミスデータセンターとのハイブリッド接続を維持する組織にとって特に価値があります。 ビジネス価値: エンタープライズクラウド導入にとって重要な理由 1. 停滞しているマイグレーションの解消 複数の企業が、マルチサイト DR および数百のネットワークセグメントにまたがる IP 保持接続の要件が、マイグレーションツールで実現可能ではあるものの、大規模であれば非実用的なリソースコストでしか達成できないため、Amazon EVS の採用がブロックされていました。NSX Federation はこれらの組織のブロックを直接解消し、本番環境のデプロイメントを進めることを可能にします。 2. 運用複雑性の削減 Federation は大規模な L2 拡張を単一のマネージドファブリックに統合します。運用負荷は大幅に低下します。 1 つの Global Manager がすべてのロケーションにわたる一元的な制御を提供 1 つの DFW ポリシーセット がどこでも一貫して適用 1 つのフェイルオーバーメカニズム (Active-Standby T0) がネットワークフェイルオーバーをネイティブに処理 3. 真のビジネス継続性 Amazon EVS 上の NSX Federation は以下を実現します。 ネットワーク RTO: 1 分未満の Active-Standby Tier-0 ゲートウェイフェイルオーバー 。これを実現するには、NSX フェイルオーバーおよびルートテーブルの更新などの AWS 側のネットワーク変更のためのオートメーションが必要です。 RPO: Amazon FSx for NetApp ONTAP SnapMirror レプリケーションで 約 5 分 (またはマルチ AZ デプロイメントで RPO 0) フェイルオーバーの前、最中、後において、両サイトで DFW ルールがアクティブな状態での 一貫したセキュリティポスチャ HCX と NSX Federation: 組み合わせによる相乗効果 HCX と NSX Federation は補完的な目的を持ち、組み合わせて効果的に機能します。それぞれが適しているユースケースは以下の通りです。 ユースケース 推奨アプローチ マイグレーション (バルク vMotion/レプリケーション) HCX、マイグレーションワークフロー向けに専用設計 少数の VLAN での 2 サイト間 L2 拡張 HCX Network Extension、シンプルかつ迅速にデプロイ可能 大規模な L2 拡張 (大量の VLAN 数または 3 サイト以上) NSX Federation、アプライアンスごとの上限なしのファブリックレベルアプローチ ステートフルフェイルオーバーによるマルチサイト DR NSX Federation、Active-Standby T0 で 1 分未満の RTO サイト間で一貫した DFW ポリシー NSX Federation、Global Manager からの統一されたセキュリティ 3 サイト以上 NSX Federation、ネイティブマルチロケーションメッシュ マイグレーション + DR (組み合わせ) 両方: HCX でマイグレーション処理、Federation で恒久的なネットワークと DR エンタープライズ企業は HCX と NSX Federation の両方を使用できます。HCX がマイグレーションの過程を処理し、NSX Federation がワークロードの配置後に長期的なネットワークと DR の基盤を提供します。 まとめ この記事では、Amazon EVS 上の NSX Federation が AWS 上のエンタープライズ VMware ネットワークの可能性をどのように拡大するかを紹介しました。ファブリックレベルの L2 拡張、統一されたセキュリティポリシー、ネイティブマルチサイトメッシュ接続、1 分未満の DR フェイルオーバーにより、HCX を補完します。これらの機能を組み合わせることで、マイグレーションを超えたエンタープライズ規模の要件に対応するためのツールが提供されます。 大規模なマイグレーションを計画している場合でも、マルチサイト DR アーキテクチャを構築している場合でも、複数の AWS ロケーションとオンプレミスデータセンター間でワークロードを接続している場合でも、Amazon EVS 上の HCX と NSX Federation の組み合わせが、それを正しく実現するためのネットワーク基盤を提供します。 始める準備はできましたか？ お使いの環境での NSX Federation デプロイメントについては、AWS アカウントチームにお問い合わせいただくか、 Amazon EVS のドキュメント で詳細をご確認ください。 著者について Ron Wedel Ron Wedel は AWS のシニアソリューションアーキテクトです。20 年以上にわたり仮想化技術に携わっており、パートナーやお客様が AWS への次のステップを踏み出す支援を楽しんでいます。AWS ソリューションアーキテクトとして、VMware 環境、ネットワーク、コンピューティングインフラストラクチャの最適化を専門としています。これらの技術に関する包括的なバックグラウンドが、AWS のお客様が AWS 上でモダンインフラストラクチャを構築・成長させるためのアプローチの基盤となっています。 Jay Scheponik Jay Scheponik は AWS のシニアスペシャリストソリューションアーキテクトで、マイグレーションとモダナイゼーションを担当しています。エンタープライズ IT およびインフラストラクチャにおける長年の実践経験を活かし、お客様の VMware ワークロードの AWS への移行を支援しています。Jay は 12 の AWS 認定資格を保有し、VMware Certified Design Expert (VCDX) でもあります。仕事以外では、ゴルフ、レコードを回すこと、ゲーム、家族との時間を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

本記事は 2025 年 3 月 18 日 に公開された「 Streamlining access to tabular datasets stored in Amazon S3 Tables with DuckDB 」を翻訳したものです。 データドリブンな意思決定への依存が高まるなか、データ分析のプロセスを効率化・高速化するツールへの需要が増しています。重要な意思決定を進める場面では、アプリケーションアーキテクチャの効率性とシンプルさが競争優位につながります。開発者は、既存のアプリケーションスタックとスムーズに統合できる軽量で柔軟なツールを求めています。特に、データレイクに保存されたデータセットを素早く効率的にクエリするための手段が重視されています。 こうした状況において、 DuckDB は複雑なインストールなしにデータを素早く分析できる実用的な選択肢として注目されています。DuckDB はホストプロセスに完全に組み込まれ、別プロセスとして動作しないため、インストール・更新・保守が必要な別サーバーやソフトウェアを用意する必要がありません。軽量な設計により、Python、Java、その他の環境に容易に統合でき、対話型のデータ分析に適しています。DuckDB には最近、 Apache Iceberg REST API を利用して Amazon S3 Tables に格納されたテーブルを読み取る プレビューサポート が追加されました。S3 Tables は表形式ストレージ専用に設計されており、Apache Iceberg 形式のデータを直接、高性能かつ低コストで保存・クエリできます。S3 Tables はストレージを継続的に最適化してクエリ性能を最大化し、コストを最小化するため、追加のインフラ構築なしにデータレイク運用を効率化したい企業に適しています。DuckDB と S3 Tables の統合により、開発者は Amazon S3 に格納されたデータをクエリでき、複雑なデータ移動や追加のインフラなしにテーブルへアクセスしながら、企業はデータレイクを効率化・集約できます。 本記事では、 Amazon SageMaker Lakehouse Iceberg REST エンドポイント と AWS Lake Formation のアクセス許可を利用して、ローカルマシンから DuckDB で S3 テーブルバケット内の Iceberg テーブルを読み取る方法を紹介します。同じデータ利用ワークフローは、リソースが限られた小型のエッジデバイスから、100 コア超の CPU を搭載する数テラバイトメモリの大型サーバーまで、幅広い環境で適用できます。DuckDB と S3 Tables の組み合わせは、AWS 上でスケーラブルなデータレイク構築を始めるための、直接的で堅牢な基盤になります。 ソリューションの概要 本記事では、 AWS CloudShell の CLI で DuckDB を使い、ローカルシステムから S3 バケットのテーブルを読み取る方法を紹介します。ここではコマンドラインインターフェイスを使いますが、DuckDB は複数のプログラミング言語とクライアント API をサポートしています。対応言語と統合オプションの一覧は、 DuckDB 公式ドキュメント を参照してください。また、本記事では、開発者やデータサイエンティストがローカル環境でクエリをテスト・反復してから本番規模でデプロイするという、一般的なパターンを扱います。まずクライアントに DuckDB をインストールし、次の図のように S3 テーブルバケットに格納されたテーブルへアクセスするための Lake Formation のアクセス許可を接続します。その後、クライアント上の DuckDB インスタンスにカタログをアタッチし、テーブルに対するクエリを試します。 前提条件 本記事の手順を実行するには、次の AWS サービスにアクセスできる AWS アカウントが必要です。 Amazon S3 Tables AWS Identity and Access Management (IAM) Amazon SageMaker Lakehouse Amazon Athena AWS Lake Formation ウォークスルー 本ソリューションを実装するには、S3 テーブルバケットにテーブルを用意し、テーブルを読み取るためのアクセス許可を設定し、ローカルクライアントに DuckDB インスタンスを構成する必要があります。以降のセクションで各ステップを説明します。 Part A: S3 Tables のセットアップ Part B: アクセス許可のセットアップ (オプション) Part C: DuckDB のセットアップ Part A: S3 Tables のセットアップ DuckDB は現時点で S3 Tables を読み取り専用モードでサポートしています。アカウントにテーブルがない、または AWS 分析サービスとの統合が未設定の場合は、以下の手順に従ってください。すでに設定済みであれば、本セクションはスキップできます。本セクションでは、テーブルバケットの作成、テーブルのセットアップ、データ追加を通じて、DuckDB で分析するためのデータを準備する手順を説明します。すでにデータが入ったテーブルがある場合は、本セクションをスキップして次のセクションに進んでください。 1. S3 テーブルバケットを作成し、AWS 分析サービスとの統合をセットアップする 1.1. AWS マネジメントコンソール で S3 に移動します。左のナビゲーションメニューから Table buckets を選択し、 Create table bucket を選びます。テーブルバケット名を指定し、次の図のように AWS 分析サービスとの統合が未有効の場合は Enable integration を選択します。この統合により、この AWS リージョン とこのアカウントで作成されたすべてのテーブルを SageMaker Lakehouse と Lake Formation で検出でき、 Amazon Data Firehose 、Athena、 Amazon Redshift 、 Amazon EMR などの AWS 分析サービスからアクセスできるようになります。統合の詳細は、 Using Amazon S3 with analytics services を参照してください。 1.2. テーブルバケット mytraveldata が作成されました。DuckDB のセットアップで後ほど使うため、コピーアイコンでテーブルバケットの Amazon リソースネーム (ARN) をコピーしておきます。 2. テーブルバケットに新しいテーブルを作成する 2.1. S3 コンソールで対象のバケットに移動し、 Create table with Athena を選択します。 2.2. テーブルバケット内に名前空間とテーブルを作成する Create table ワークフローで Namespace name を追加します。 続けて Create table with Athena に進みます。 SageMaker Lakehouse に nyc という名前のデータベースが作成されます。 2.3. Athena クエリエディタで、次の SQL コマンドを使ってテーブルを作成します。 CREATE TABLE nyc.nyc_trips (trip_id INT, pickup_datetime TIMESTAMP, dropoff_datetime TIMESTAMP, passenger_count INT, trip_distance DOUBLE, fare_amount DOUBLE, payment_type STRING, pickup_zone STRING) TBLPROPERTIES ( 'table_type'='ICEBERG' ); 3. S3 Tables にデータを挿入する ここでは、次の SQL コマンドを使い、ニューヨーク市のタクシー走行に関するサンプルデータを、作成済みのテーブルに挿入します。 INSERT INTO nyc.nyc_trips (trip_id, pickup_datetime, dropoff_datetime, passenger_count, trip_distance, fare_amount, payment_type, pickup_zone) VALUES (1, TIMESTAMP '2023-03-01 08:30:00', TIMESTAMP '2023-03-01 09:15:00', 2, 5.8, 22.50, 'Credit Card', 'Midtown'), (2, TIMESTAMP '2023-03-01 12:15:00', TIMESTAMP '2023-03-01 12:45:00', 1, 3.2, 15.00, 'Cash', 'Upper East Side'), (3, TIMESTAMP '2023-03-01 17:00:00', TIMESTAMP '2023-03-01 17:45:00', 3, 7.1, 28.75, 'Credit Card', 'Financial District'), (4, TIMESTAMP '2023-03-02 09:45:00', TIMESTAMP '2023-03-02 10:30:00', 1, 4.5, 18.25, 'Credit Card', 'Chelsea'), (5, TIMESTAMP '2023-03-02 14:30:00', TIMESTAMP '2023-03-02 15:15:00', 2, 6.3, 24.50, 'Cash', 'Greenwich Village'), (6, TIMESTAMP '2023-03-02 20:00:00', TIMESTAMP '2023-03-02 20:30:00', 4, 2.8, 14.75, 'Credit Card', 'Times Square'), (7, TIMESTAMP '2023-03-03 07:15:00', TIMESTAMP '2023-03-03 08:00:00', 1, 8.2, 32.00, 'Credit Card', 'Brooklyn Heights'), (8, TIMESTAMP '2023-03-03 11:30:00', TIMESTAMP '2023-03-03 12:15:00', 2, 5.5, 21.75, 'Cash', 'East Village'), (9, TIMESTAMP '2023-03-03 16:45:00', TIMESTAMP '2023-03-03 17:30:00', 3, 6.7, 26.25, 'Credit Card', 'SoHo'), (10, TIMESTAMP '2023-03-03 22:00:00', TIMESTAMP '2023-03-03 22:45:00', 1, 4.9, 19.50, 'Cash', 'Upper West Side'); この SQL コマンドを実行すると、データが nyc_trips テーブルに取り込まれます。 Part B: アクセス許可のセットアップ (オプション) 当該アカウントで AWS 分析サービスとテーブルバケットの統合を行ったユーザーとは別のユーザーの場合、テーブルに対する Lake Formation のアクセス許可を付与してもらう必要があります。詳細は Grant permission on a table or database を参照してください。本記事では、コンソール上で AWS 分析サービスとの統合を行った同じユーザーが、DuckDB インスタンス経由でテーブルにアクセスすることを前提とします。 Part C: DuckDB のセットアップ 1. DuckDB をインストールする DuckDB のインストールページ にアクセスし、最新の DuckDB Command line (執筆時点は v1.2.1) を入手します。 Installation セクションの curl コマンドをコピーします。 AWS マネジメントコンソールで CloudShell 環境に移動します。 次の curl コマンドを実行します。 curl https://install.duckdb.org | sh 次の図は curl コマンドの実行例です。 2. CloudShell インスタンスで DuckDB インスタンスを実行する DuckDB インスタンスを起動するには、AWS Command Line Interface (AWS CLI) で次のコマンドを入力します。 /home/cloudshell-user/.duckdb/cli/latest/duckdb 3. Iceberg 拡張機能をロードする S3 Tables の DuckDB サポートは、現時点では nightly 拡張ビルドの一部として提供されています。最新の Iceberg 拡張機能をインストールするには、次のコマンドを実行します。 FORCE INSTALL iceberg FROM core_nightly; ここまでで DuckDB インスタンスのセットアップは完了です。 4. AWS 認証情報を登録する AWS 認証情報を含むシークレットを作成します。CloudShell を使用している場合、これは AWS コンソールの認証情報にあたります。DuckDB はこのシークレットを使ってテーブルデータにアクセスします。設定オプションの詳細は DuckDB のドキュメント を参照してください。 CREATE SECRET (   TYPE S3,   PROVIDER credential_chain ); 5. カタログをデータベースとしてアタッチする ここでは、テーブルバケットをデータベースインスタンスとして DuckDB にアタッチします。 ATTACH '<account-id>:s3tablescatalog/mytraveldata' AS duck_db (TYPE ICEBERG, ENDPOINT_TYPE 'GLUE'); 6. テーブルバケットに格納されたデータにアクセスする 次のコマンドを使い、DuckDB がテーブルバケット内のテーブルを検出できることを確認します。 SHOW ALL TABLES; 結果から、 mytraveldata には nyc という名前空間が 1 つあり、その中に nyc_trips というテーブルが 1 つ存在することがわかります。以下はテーブルに格納されたデータを分析するサンプルクエリの例です。 6.1. テーブルに格納されたすべてのデータを表示します。 SELECT * from duck_db.nyc.nyc_trips 6.2. 支払い方法別の運賃合計を取得します。 SELECT payment_type, SUM(fare_amount) AS total_fare FROM duck_db.nyc.nyc_trips GROUP BY payment_type; 6.3. 2023 年 3 月 1 日の走行に対する運賃合計を取得します。 SELECT SUM(fare_amount) AS total_fare FROM duck_db.nyc.nyc_trips WHERE pickup_datetime BETWEEN '2023-03-01 00:00:00' AND '2023-03-01 23:59:59'; 本記事では、DuckDB インスタンスへの接続に Amazon SageMaker Lakehouse Iceberg REST エンドポイント を利用しました。もう 1 つの選択肢として、 S3 Tables Iceberg REST Catalog API で DuckDB に接続することもできます。この場合は、次の ATTACH コマンドを使用します。 ATTACH '<table-bucket-arn>' AS duck_db (TYPE ICEBERG, ENDPOINT_TYPE 'S3_Tables'); 1 つの S3 テーブルバケット内の表形式データに基本的な読み取りアクセスが必要な場合は S3 Tables Iceberg REST Catalog API を使い、すべての表形式データを対象とした統一的なデータ管理、データガバナンス、きめ細かなアクセス制御が必要な場合は S3 Tables を SageMaker Lakehouse と組み合わせて利用できます。 クリーンアップ リソースをクリーンアップするには、次の手順を実行してください。 S3 テーブルを 削除 する。 テーブルバケット内の名前空間を 削除 する。 S3 テーブルバケットを 削除 する。 まとめ 本記事では、Amazon SageMaker Lakehouse と AWS Lake Formation のアクセス許可を活用し、DuckDB で Amazon S3 上の Iceberg テーブルを読み取る方法を紹介しました。S3 テーブルバケットにテーブルを作成し、データを投入し、DuckDB クライアントからテーブルにアクセスする流れをウォークスルーしました。DuckDB と Amazon S3 Tables を組み合わせることで、小規模から大規模までのあらゆる環境で、追加のインフラなしにデータレイク内のテーブルを扱えます。 著者について Anupriti Warade Anupriti Warade は AWS の Amazon S3 チームで Senior Technical Product Manager を務めています。お客様のイノベーションと課題解決につながるソリューションの構築に情熱を注いでいます。ワシントン州シアトルを拠点に、家族や友人との時間、料理、DIY クラフトを楽しんでいます。 Yuri Zarubin Yuri Zarubin は AWS の Amazon S3 チームで Principal Engineer を務めています。データ保護を専門とし、S3 Replication のエキスパートです。現在は S3 Tables を Apache Iceberg テーブル向けにもっとも高性能なストレージソリューションとするための開発に取り組んでいます。余暇は旅行と、子どもと一緒に遊ぶ次の PC ゲーム探しを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。