https://yennj12.js.org/yennj12_blog_V4/tags/vpc/Recent content in VPC on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 05 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part30-constraint-driven-architecture-zh/Thu, 04 Jun 2026 21:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part30-constraint-driven-architecture-zh/大多數的架構設計課程從「最優解」出發。 但 FDE 的真實工作，是從「客戶的限制」出發。 「所有資料不能出 VPC」、「模型不能用 SaaS API」、「每個 API call 都要有審計日誌」—— 這些限制不是問題，是你設計的起點。 面試情境 面試官：「你的客戶是一家銀行。他們的 IT 安全政策規定：所有含有客戶 PII 的資料不能傳送到外部網路，所有 API 呼叫必須在私有網路內完成，並且每個 AI 模型的調用都要有審計日誌。他們想在這個條件下部署一個 RAG-based 合約審閱 Agent。你的架構是什麼？」 一、FDE 面對限制的第一步：分類 收到限制條件，先做分類，不要立刻開始設計架構： 限制分類框架： 類型 1：資料主權限制（Data Residency） 「資料不能離開特定地理區域」 → GCP Region 選擇問題 → 影響：model endpoint 必須在指定 Region 類型 2：網路隔離限制（Network Isolation） 「API 呼叫必須在私有網路內」 → VPC 架構問題 → 影響：需要 Private Service Connect / VPC-SC 類型 3：資料分類限制（Data Classification） 「PII 不能傳給外部服務」 → 資料流設計問題 → 影響：需要 PII detection + 資料遮罩 pipeline 類型 4：審計與合規限制（Audit & Compliance） 「所有 AI 調用要有 audit log」 → Observability 架構問題 → 影響：Cloud Audit Logs + SIEM 整合 本題的限制：類型 2 + 3 + 4，三個同時 二、核心技術：VPC Service Controls（VPC-SC） 這是 Google Cloud 上的金融/政府客戶必備知識：https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part37-legacy-integration-zh/Fri, 05 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part37-legacy-integration-zh/Demo 時 Agent 很漂亮。 到客戶現場才發現：資料在 SAP（文件很爛）、Oracle（只有 DB 直連）、 還有一個每天凌晨 2 點才匯出的 CSV 檔案。 「連接組織」，是 FDE 和 AI 工程師最核心的差距之一。 面試情境 面試官：「客戶是一家有 30 年歷史的製造業。資料在三個地方：SAP ERP（有 REST API 但文件很爛）、Oracle 資料庫（只有 DB 直連）、一個每天從 mainframe 匯出的 CSV。他們希望 AI 能回答：庫存狀況、哪個供應商交期有問題。你怎麼設計這個整合層？」 一、問題本質：Legacy 整合的三種挑戰 Demo 的 Tool： def get_inventory(item_id: str) -> dict: return requests.get(f"https://api.example.com/inventory/{item_id}") 客戶現場的現實： SAP API： ├── 認證：OAuth + Client Certificate（文件在某個 Confluence 頁面，過期了） ├── Rate Limit：10 req/sec per user（AI 可能觸發 100 并發） ├── 回傳格式：200 欄位的 XML（Agent 只需要 5 個） └── 錯誤碼：自定義的 SAP 錯誤碼（不是標準 HTTP） Oracle DB： ├── 沒有 API，只能 JDBC/ODBC 直連 ├── 沒有任何文件，Schema 要靠 DBA 解釋 └── 有 SQL Injection 和 full table scan 的風險 Mainframe CSV： ├── 每天凌晨 2 點才有新資料（不是即時） ├── 格式偶爾會改變（沒有版本控制） └── 直接讀大 CSV 到 context = token 爆炸 這三個資料來源，需要三種不同的整合模式。 二、整合模式選型框架 選型決策矩陣： 資料來源特性 → 建議整合模式 ────────────────────────────────────────────────────────────── 有 API，但設計複雜 → API 橋接層 （認證複雜、格式冗餘、Rate Limit） ────────────────────────────────────────────────────────────── 只有 DB 直連，沒有 API → 資料庫查詢層（Stored Procedure） ────────────────────────────────────────────────────────────── 批次檔案（CSV、Excel） → 批次攝取 Pipeline（GCS → BigQuery） ────────────────────────────────────────────────────────────── 即時串流資料 → Pub/Sub → BigQuery → Agent Query ────────────────────────────────────────────────────────────── 三種模式的系統特性對比： 模式 延遲 資料新鮮度 設計複雜度 適用場景 ────────────────────────────────────────────────────────────── API 橋接層 低（ms） 即時 高 SAP 庫存查詢 ────────────────────────────────────────────────────────────── DB 查詢層 中（ms） 即時 中 Oracle 訂單狀態 ────────────────────────────────────────────────────────────── 批次攝取 Pipeline 秒-分 T+1（次日） 低 Mainframe 月報 ────────────────────────────────────────────────────────────── 製造業客戶的對應： SAP → API 橋接層 Oracle → DB 查詢層 Mainframe CSV → 批次攝取 Pipeline 三、模式一：API 橋接層設計 設計目標：隱藏 SAP API 的所有複雜性， 讓 Agent Tool 看到的是簡單、穩定的介面。 架構： ┌──────────────────────────────────────────────────────────────┐ │ ADK Agent │ │ def get_inventory(item_id, warehouse) → dict │ │ （Agent 只看到這個簡單函數） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ SAP Adapter Service（你寫的橋接層） │ │ │ │ ├── 認證管理 │ │ │ Secret Manager 取 OAuth token + Client Certificate │ │ │ Token 自動更新（expiry 前 5 分鐘刷新） │ │ │ │ │ ├── Rate Limiting（Token Bucket，10 req/sec） │ │ │ 超過上限的請求排隊等待，設定 queue timeout = 5s │ │ │ │ │ ├── 格式轉換 │ │ │ 200 欄位 XML → 5 欄位 JSON │ │ │ {available_qty, unit, location, last_updated, status} │ │ │ │ │ ├── Response Cache（Redis，TTL 5 分鐘） │ │ │ 相同 item_id+warehouse 的查詢，5 分鐘內走 Cache │ │ │ │ │ └── 錯誤處理 │ │ HTTP 429 / SAP-specific 錯誤碼 → 統一轉換成 Retry 或 │ │ 結構化錯誤訊息（Agent 能理解的格式） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ SAP REST API（原始系統） │ │ 認證複雜、格式冗餘、Rate Limit 10 req/sec │ └──────────────────────────────────────────────────────────────┘ Cache 的效益： 假設有 80% 的查詢是重複的相同 item_id： SAP API 實際呼叫量降低 80%，Rate Limit 問題基本消失。 對 SAP 系統的壓力大幅降低，減少影響生產系統的風險。 四、模式二：資料庫查詢層（Stored Procedure） 核心安全問題：Agent 不能直接生成 SQL 並執行。 風險分析： ❌ 直接讓 Agent 生成 SQL： Agent: SELECT * FROM orders WHERE supplier = '{user_input}' 攻擊者輸入：' OR 1=1; DROP TABLE orders; -- → SQL Injection，資料庫損毀 ❌ 直接 SELECT *： 對大型 Oracle 表的 full table scan 可能讓生產資料庫效能崩潰 ✅ 正確設計：Stored Procedure 層 架構： ADK Agent Tool def get_supplier_delivery(supplier_id, date_from, date_to) │ │ 呼叫預定義的 Stored Procedure ▼ Oracle DB EXEC sp_GetSupplierDelivery(?https://yennj12.js.org/yennj12_blog_V4/posts/aws-vpc-complete-guide-enterprise-networking/Mon, 29 Sep 2025 08:35:54 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aws-vpc-complete-guide-enterprise-networking/Introduction Amazon Virtual Private Cloud (VPC) is the foundation of AWS networking, providing isolated virtual networks within the AWS cloud. This guide explores VPC types, enterprise network design patterns, VPC peering strategies, and practical Java implementations for production environments. AWS VPC Fundamentals What is AWS VPC? AWS VPC lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define.