“全部コピーしない”ファイルデータの活用 ： — FSx for ONTAP × S3 Tables × Icebergで作るメタデータカタログ

2026/07/04開催 の JAWS ミート 2026 の15分登壇した資料です。当日は、セッション枠の15分で収まらないので端折っています。フルでやるとしたら、30分程度掛け合いをしながら、紹介していきたい内容です。
* イベントページ： https://jaws-ug-tokaido.connpass.com/event/392910/

本セッションでは、「NAS上のRawデータをすべてS3へコピーする」のではなく、FSx for ONTAPをソース・オブ・トゥルースとして扱い、S3 Access Points経由で分析・ETL・AI連携のread pathを広げる。そのうえで、品質・lineage・PII・AI分類・エンジン互換性などのHot MetadataをS3 Tables / Icebergで管理する設計アイデアを紹介しています。

また、Delta / Iceberg / Hudi の transactional write path がそのまま適用しづらい理由を整理し、Rawデータは FSx for ONTAP に残しつつ、Bronze / Silver / Gold の curated layer やメタデータカタログを Amazon S3 Tables / Apache Iceberg 側で設計する “Hot Metadata × Cold Data” の考え方を解説しています。

「ゼロコピーで全部できる」ではなく、「向き不向きを理解し、品質・来歴・利用可否・curated table の置き場所を設計する」ための、FSx for ONTAP × S3 Access Points × Lakehouse の現時点での現実解です。

Transcript

1. • プロローグ • ブログシリーズ「FSx for ONTAP S3 Access Points × Lakehouse — 動くもの、動かないもの、 その理由」 • エピローグ Disclaimer：本日の発表内容は所属する組織を代表する ものではありません。 ネットアップ合同会社 藤原 善基(ふじわら よしき) JAWS ミート 2026 “全部コピーしない”ファイルデータの活用 ： — FSx for ONTAP × S3 Tables × Icebergで作るメタデータカタログ
2. 藤原 善基(ふじわら よしき) ネットアップ合同会社 AWS SE Support / Sr. Cloud Solutions Architect – AWS AWS Community Builder 2023(Storage)、2024-2026(Cloud Operations) 2024-2026 Japan AWS Top Engineers(Software) AWS Ambassador ← New!! 最近やっていくること：生成AI、ランサムウェア対策、仮想化環境のAWS移行/拡張、 データ分析/活用プラットフォーム←New!! 経歴 • ・生後10ヶ月から7才までギリシャのアテネ(1986 - 1992) • 物流業の営業→コールセンターのオペレーター→SIer ヘルプデスク→ SIer インフラエンジニア→ネットアップ合同会社 ← 今ココ 趣味 • 技術イベントへの参加・旅行・外食・ロックフェスティバルに行くなど • Storage-JAWS運営メンバー 好きなAWSのサービス • Amazon Elastic Container Service • Amazon FSx for NetApp ONTAP • AWSサポート 自己紹介 Amazon FSx for NetApp ONTAP Amazon S3 Access points Amazon Elastic Container Service
3. Storage-JAWS 運営目的 • AWS上で「ストレージ」を活用するための議論や情 報発信をしていく場を作る • サービスやビジネスを加速するための活用方法も 参加対象者 • AWSストレージに興味がある方なら誰でもOK！ • 初心者から上級者までWelcome！！ • JAWS-UG Slack "#storage-jaws"で情報発 信中！ https://storage-jaws.connpass.com/
4. 個人的なコラボ：AWSのStorage観点で登壇。楽しく全国をまわりながら過ごしていますので、 気軽にお声がけください。 • 専門支部 • 地方支部 • 地方支部 x 専門支部
5. プロローグ：「Youは何しにここへ？」 開催概要から抜粋、 >JAWSミートの「ミート」は、「Meet（出会い）」と「Meat（お肉）」のダブルミーニング になっています。 勉強会で学びながら、お肉などを囲んで交流することを目的としたイベント です。 全国のAWSファンが集まるイベントですので、普段なかなか接点のない方同士が新たな つながりを持つきっかけになればと思っています。 つまり、→「勉強会で学び」ながら、「お肉などを囲んで交流すること」を目的に来ました！！ 5回目の開催で、初回からせっかく皆勤なので今回は最近の取り組みを共有しに来ました。 ちなみに、AWS Summit Japan 2026に参加した方、挙手お願いします！！ きっと、皆さん「データ基盤」に興味ありますよね？ AWS SummitコミュニティーブースでのAWS Community Hero / JAWS-UGビックデータ支部運営の織田さんのセッションが 資料公開されていますので、 当日見れなかった方も是非参考に。 藤原は参考に、今回の資料も磨き込み ました。 https://speakerdeck.com/sansantech/20260626
6. メダリオンアーキテクチャとは？ DatabricksのWebサイトから抜粋： >メダリオンアーキテクチャとは、レイクハウスのデータを論理的に整理するために用いられるデータ設 計を意味します。データがアーキテクチャの 3 つのレイヤー（ブロンズ → シルバー → ゴールドのテーブ ル）を流れる際に、データの構造と品質を増分的かつ漸次的に向上させることを目的としています。メダ リオンアーキテクチャは、「マルチホップ」アーキテクチャとも呼ばれます。 https://www.databricks.com/jp/blog/what-is-medallion-architecture
7. メダリオンアーキテクチャをAWSのサービスで考えると？ • 織田さんのセッションからアーキテクチャー図を以下に抜粋。 • データベースやS3などからデータを収集して、磨き込んで活用していく。今なら、Amazon Quickがオススメだと思います。 https://speakerdeck.com/sansantech/20260626
8. • データの格納サービス、高速キャッシュは「Amazon」、データの管理・エッジサービス・データの移動は「AWS」 。 • データ格納サービスは、プロトコル別に各サービスはObject/Block/NFS/SMBを1つずつサポート。FSx for ONTAPを除く。 AWSの主なストレージ関連サービスと、FSx for ONTAPの位置付け データの格納 (ストレージリソースの提供) AWS Backup AWS Storage Gateway AWS DataSync AWS Transfer Family Amazon S3 and Amazon S3 Glacier Object (API) Amazon EBS Block Amazon EFS NFS Amazon FSx for Windows File Server SMB Amazon FSx for NetApp ONTAP SMB / NFS / iSCSI + S3 Access Points Amazon FSx for Lustre Lustre データ管理 エッジサービス AWSサービス全体の バックアップと コンプライアンス オンプレミスからクラウド ストレージへの ゲートウェイ AWSストレージサービ スへのデータ転送 ファイル転送プロトコル (SFTP / FTPS / FTP) の提供 藤原の日常 Amazon FSx for openZFS NFS + S3 Access Points Amazon File Cache 保存場所に関わらずファイル データを簡単に処理できる AWS の高速キャッシュを提供 高速キャッシュ S3 AP仲間
9. #jawsug #jawsdays2026 #jawsdays2026_c AWSの主なストレージサービス <JAWS Days 2026楽しく学ぼう！ストレージ 入門>からの抜粋 データの格納 (ストレージリソースの提供) AWS Backup AWS Storage Gateway AWS DataSync AWS Transfer Family Amazon S3 and Amazon S3 Glacier Amazon EBS Amazon EFS Amazon FSx for Windows File Server Amazon FSx for NetApp ONTAP Amazon FSx for Lustre エッジサービス AWSサービス全体 のバックアップとコ ンプライアンス オンプレミスから クラウドストレージ への ゲートウェイ AWSストレージ サービスへの データ転送 ファイル転送 プロトコル (SFTP / FTPS / FTP) の提供 万能 Amazon FSx for openZFS Amazon File Cache 保存場所に関わらず ファイルデータを簡単に 処理できる AWS の高速 キャッシュを提供 高速キャッシュ 復旧 転送 原点 重力 忘却 並列 契約 分割 高速 同期 玄関 データの格納サービス、高速キャッシュはサービス名が「Amazon」で始まり、 データの管理・エッジサービスは「AWS」でサービス名が始まる。 ：「漢字2文字」でサービスの印象を表現してみた！ データ管理 Object (API) Block NFS SMB SMB / NFS / iSCSI + S3 Access Points Lustre NFS + S3 Access Points
10. • 優秀な担当者と個別最適な手順に支えられてきた一方で、クラウド時代の自動化・再利用には 「属人化」「サイロ化」「再利用できない自動化」の壁がある 課題：オンプレミスのファイルストレージ運用で起きてきた事 せっかくAWS使 うなら… データは FSx for ONTAPなど に置いたまま、AWS の他のフルマネ ージドサービスで「判断・分岐・並列化・監査」をAPI/コード化し て再利用する 。→運用知見を“人”から“再利用可能な設計資産”へ」 「あの人しか分からない」 ・暗黙知の運用判断 ・手順書より経験が優先 ・異動/休暇で止まる運用 部門・拠点・ボリューム 単位で運用が分断 • 権限/監査の粒度がバ ラバラ • データ活用が部門内 で閉じる スクリプト・手順・ワーク フローが 環境依存で横展開しづらい • エラー処理が属人的 • 監査/再実行の設計が後 付け 手 順 メ モ 秘 伝 部門 A 部門 B 部門 C script.sh # 手作業 runbook .xlsx 機 密 X 禁 X 止 ① 属人化 ② サイロ化 ③ 再利用できない自動化
11. • AWSサービス連携を再利用可能な形でNetApp藤原が設計、検証を行なったアイデアをGitHubリ ポジトリに公開: GitHub: github.com/Yoshiki0705/FSx-for-ONTAP-S3AccessPoints-Serverless-Patterns GitHub 公開リポジトリ：FSxN S3 Access Points Serverless Patterns Legal: 契約/証跡レビュー Financial: IDP / リスク分析 Manufacturing: テレメトリ分析 Media: VFX / メディア処理 Healthcare: DICOM / 医療データ処理 …… リポジトリの狙い • FSx for ONTAP 上のデータを S3 Access Point 経由でサーバーレス処理する業界別 パターン集 • 2026/07/04 時点で、42 の業界/ ワークロード別ユースケース • EventBridge Scheduler + Step Functions によるポーリングベース • 共通モジュール：OntapClient / FsxHelper / S3ApHelper • CloudFormation ネイティブでユース ケースごとに独立
12. • 12/2(火) AWS CEO Matt Garman氏のKeynoteの終盤、25の新しいサービスサポート の中で紹介。時間が限られていたため、概要の簡単な紹介のみ • 「ファイルストレージのデータをどう使えば良いのか？」という問いに対しての回答 • 「FSx for ONTAPにあるデータをS3にあるかのようにシームレスに扱うことができる」 • 「成長しているデータタイプとしては、大規模なデータのベクター埋め込み」 AWS CEO Matt Garman Keynoteでの発表！@AWS re:Invent 2025
13. • FSx for ONTAPが無い場合と、ある場合のファイルストレージ/ブロックストレージ/オブジェクトでのデータ連携方法の違い • IaaS上でプロトコルごとにセルフマネージド、フルマネージドサービスを設計するデータ連携・運用・コストの課題を解決 • FSx for ONTAPでより効率的かつ高速なデータ連携のハブ基盤を手に入れることができる→野良NAS統合、野良SAN統合 藤原は、こういう説明を日頃やっていて、AWS上のファイル/ブロックで眠っているデータの活用 推進しています。→S3 APIもFSx for ONTAPが使えるようになったので、無限大の可能性… SMB or NFS Without FSx for ONTAP With FSx for ONTAP ファイルサーバー on Amazon EC2 Amazon EFS Amazon FSx for Windows クライアント クライアント クライアント NFS SMB 用途やプロトコルに応じて使い分けが必要 サービス間のファイル共有方法の設計が必要 クライアント クライアント クライアント Amazon FSx for NetApp ONTAP マルチ/デュアルプロトコル対応のFSx for NetApp ONTAPで集約 重複排除等の効率化機能に加え、FlexCloneによるデータ複製や FlexCacheやSnapMirrorによるデータ共有も容易 SMB or NFS NFS SMB ＋ iSCSI マルチプロトコル対応 ONTAP独自の効率化機能 サ ー ビ ス 層 プ ロ ト コ ル 層 プ ロ ト コ ル 層 サ ー ビ ス 層 ＋ Amazon S3 Access Points アプリケーション on Amazon EC2 Amazon EBS Amazon FSx for openZFS アプリケーション on Amazon EC2 Access points Amazon S3 Object (API) Block デュアルプロトコル対応 Amazon EKS Amazon ECS Amazon EVS
14. • FSx for ONTAPに保存された ファイルは、まるでS3バケットに あたるかのようにAWSサービス からアクセス可能 • リファクタリングは不要 • 数十のS3ベースのAWSサービスと のシームレスな統合を可能。他の AWSサービス例： • Amazon Bedrock • Amazon SageMaker • Amazon Athena • Amazon Quick • Amazon Lambda / StepFunctionsなど… • FSx for ONTAPに格納されているデータをS3にあるかのように他のAWSサービ スから利用可能 FSx for ONTAPのS3 Access Pointsサポート
15. データ基盤のよくある課題：NASデータを全部S3へコピーする • 従来パターンは分かりやすいが、コスト・運用・鮮度でつらくなりがち • ストレージコストが二重化しやすい • 同期パイプラインのメンテナンスが増える • コピー先の鮮度が常に遅れる • ただし、ゼロコピーでもメタデータ・ログ・クエリ結果・派生データは別途作成され る点に注意 • 問い：S3 Access Points コピー不要の 読み込み は、どのエンジンでど こまで使えるのか？ Corporate data center Servers AWS Cloud Logs Documents Folders AWS DataSync Amazon S3 AWS Glue Amazon Athena
16. 公開シリーズ：8エンジン互換性マップ • 全9記事で “動くもの / 動かないもの / その理由” を整理：英語でまず 出して、日本語化しました。 Compatibility map 本番環境利用 OK 考慮点や代替案あり これじゃない • Amazon Athena • AWS Glue • Amazon EMR / Spark • Amazon Redshift Spectrum • DuckDB on AWS Lambda • Snowflake • Databricks Unity Catalog - External Locationは 一部動作 - サブディレクトリ一 覧 / CREATE TABLEで 制約 • OpenSharing - credential vending が代替パス • Delta transactional write • Iceberg transactional write • Hudi transactional write 理由: conditional write / atomic commit semantics が S3 AP path と合わない • それぞれの上手くいったパターン、上手くいかなかった理由と、 代替パスまで紹介しています。 シリーズ 概要
17. AWSネイティブサービスとの連携：安定動作したパス。 • Athena / Glue / EMR / Redshift Spectrum はゼロコピー分析の中核 AWSネイティブサービスを利用したクエリーとETLのPathを支える仲間達(一部) Amazon Athena 5M rows / 103MB 2.2s, 54.8 MB/s Security: 9/9 PASS Amazon EMR Serverless 10K rows ETL Read + transform + write 16s, Parquet append OK Redshift Spectrum + LF 5M rows COUNT 4.3s COUNT, 2.6s GROUP BY column/row/tag governance • 設計判断：Rawデータの検索 → Athena / ETL → EMR・Glue / ガバナン ス → Redshift Spectrum + Lake Formation AWS Glue Amazon Athena Amazon EMR Amazon Redshift AWS Lake Formation
18. サードパーティ / 軽量分析：Snowflake・DuckDB・Databricks・OpenSharing • “直接読める” だけでなく、AI連携・低コスト・共有パスまで検証 Snowflake ゼロコピーでの READがOK • AWS_ACCESS_POINT_ARN • External Stage / Table • Cortex AI: OCR・要約・翻訳 DuckDB on AWS Lambda Ultra low cost • warm 452ms / 5M rows 779ms • ~$0.00001/query • idle cost $0 Databricks UC 制約事項 • External Location partially works • subdirectory listing / CREATE TABLE blocked • Current workaround: DataSync → S3 OpenSharing 代替のパス • STS credential vending • prefix scope isolation • 11 formats verified • ポイント：Databricks UC(Unity Catalog)制約は “S3 Access Point ARNの 扱い” が焦点。OpenSharingはUCを迂回する代替パス(まだrecipienの仕様が 書かれていない)。
19. S3 APと一緒に動かないもの：Delta / Iceberg / Hudi の transactional write • 失敗も重要な設計判断。read path と table write path は分けて考える Transactional table write path Delta / Iceberg / Hudi commit write conditional commit metadata update × Why it fails • トランザクションログの atomic commit / conditional update が必要 • S3 AP read path とファイルシステ ムセマンティクスでは満たせないケー スがある • “S3に見える” ことと “テーブルウェ アハウスとして使える” ことは別 Alternative paths • Raw files: FSx for ONTAP に保持 • Curated Iceberg: Amazon S3 Tables / standard S3 bucket • Metadata catalog: S3 Tables + Iceberg REST • Parquet append: EMR / Glue / DuckDB path Data lake Amazon FSx for NetApp ONTAP Access points Database
20. JAWS-UG仲間のメダリオン登壇から取り入れたこと • 織田さんの AWS Summit Japan 2026 資料を「品質レイヤー設計」について 参考情報： SansanTech 公開資料「データレイクの『見えない問題』を可視化する」 / AWS Summit Japan 2026 からの学び Raw / NAS 正本 NFS/SMB Bronze 取り込み そのまま Silver 整形 品質付与 Gold 業務KPI 共有 Metadata 可視化 統制 メダリオンの考え方 • Raw/NAS を直接 “読める” だけでは不十分: 品質・来歴・利用可否をメタデータと して見える化する • Bronze/Silver/Gold の curated data は S3 Tables / S3標準バケット に置き、 FSx はソース・オブ・トゥルースとして扱う • メダリオンの議論を「コピー前提」から「コピーしない read path + 必要な curated layer」へ拡張する
21. メタデータカタログ設計：Hot Metadata × Cold Data • メダリオンとゼロコピーをつなぐ “見える化” レイヤー AWS Cloud Hot Metadata: Amazon S3 Tables / Apache Iceberg file_path / quality status / lineage / AI classification / PII flags / engine compatibility Cold Data: Amazon FSx for NetApp ONTAP 実ファイル / Snapshots / 重複排除 / NFS・SMB / S3 Access Point read path • AI enrichment + governance + medallion quality metadata をメタデータ層へ寄せる S3 Tables Amazon FSx for NetApp ONTAP AWS Lake Formation AWS Step Functions AWS Lambda Amazon Bedrock Amazon Quick
22. 更新パイプラインとガバナンス • ONTAP Fpolicy(ファイル操作を検知) サーバーon ECS Fargate / Lambda / SQS で更新し、Lake Formation + S3 AP Policyで制御 イベントドリブンなメタデータの更新 Metadata governance • AWS Lake Formation: table / column / row level を設計 • LF-Tags で権限管理をスケール • Data Filters と組み合わせて行レベル制御 Data access governance • Amazon S3 Access Point policy • AWS Identity and Access Management • ONTAP UNIX/NTFS ACL によるファイル システム権限 • 4層制御: IAM + S3 AP Policy + ONTAP ACL + Lake Formation Amazon FSx for NetApp ONTAP Amazon ECS AWS Fargate (Amazon SQS) AWS Lambda S3 Tables
23. サービス選定のアイデア：メダリオン段階ごとにエンジンを使い分ける • ひとつのエンジンに決めず、Raw / Bronze / Silver / Gold で役割分担する Stage Recommended path Why Raw discovery Amazon Athena / DuckDB on AWS Lambda NAS上の正本を低コストで探索、スキーマや 品質を把握 Bronze / ingestion AWS Glue / Amazon EMR Serverless Parquet 追記、初期キュレーション、フォー マット標準化 Silver / quality Amazon S3 Tables / Apache Iceberg 品質・lineage・PII・AI分類をメタデータ化 Gold / governed BI Redshift Spectrum / AWS Lake Formation 列・行・タグ制御、既存DWH・BIとの統合 AI / Share / ML Snowflake Cortex / OpenSharing / Databricks workaround AI抽出・要約・共有・MLワークロードへ接続 • 結論: FSxはRawデータの正本として利用できる。 Bronze/Silver/Goldは必要な分だけS3 Tables等にcurateし、メタ データで見える化する。
24. エピローグ：コピーしない活用の現実解 • “ゼロコピーで全部できる” ではなく “向き不向きと品質レイヤーを設計する” 1 Read path はOK Athena / Glue / EMR / Redshift Spectrum / DuckDB / Snowflake は実用 的な選択肢 2 メダリオンは “コピー前提” から拡張できる Rawデータは FSx に残し、Bronze/Silver/Goldは必要な分だけcurateする 3 Transactional table write は分離 Delta / Iceberg / Hudi の commit path は FSx S3 AP に直接乗せない Takeaway 「データは動かさないアイデアは可能」。だが、品質・来歴・利用可否・ curated table の置き場所は設計する。
25. 参考資料 • 日本語シリーズ / AWS Summit Japan 2026資料 / GitHub / コミュニティフィードバック シリーズ 概要 GitHub 織田さん資料： データレイクの 「見えない問題」 を可視化する 参考資料 • AWS Community Hero / JAWS-UG ビックデータ支部運 営織田さん：AWS Summit Japan 2026 / SansanTech SpeakerDeck: データレイクの「見えない問題」を可視化する 日本語ブログシリーズ: FSx for ONTAP S3 Access Points × Lakehouse — Part 0〜8 • GitHub: fsxn-lakehouse-integrations — evidence, CloudFormation, reproduction steps • Databricks Community: UC × Amazon S3 Access Points constraint discussion • OpenSharing Issue #6: S3 Access Point compatibility feedback メダリオンの品質レイヤー議論は、織田さんのAWS Summit資料を ご覧ください！藤原はこのセッションで、「NAS上のRawをコピーせず、ど こからcurateするか」を補完しました。
26. ご清聴ありがとうございました！！ (宣伝)Storage-JAWSで更に地域支部、専門支部 とのコラボをやっていきますので、よろしくお願いします！ Thank you!!