深入探討 Amazon Aurora 及其創新 (DAT441)

場次筆記

Aurora 概觀

• Amazon Aurora 是雲端原生關聯式資料庫
• 結合高階商用資料庫的速度與可用性，以及開放原始碼的簡單易用與成本效益
• 完全受管，與 MySQL 及 PostgreSQL 相容
• 包含用於整合無伺服器及機器學習應用程式的工具
• 使用 Aurora 不需要變更應用程式
• 支援 PostgreSQL 的擴充功能
• 最近新增：Aurora DSQL (Distributed SQL)
• Aurora 架構：
• 使用 3 個可用區域
• Aurora 儲存體橫跨所有 3 個可用區域
• 儲存節點處理會轉換成資料庫頁面的日誌記錄

Aurora 儲存體的主要功能

• 不會有檢查點、完整頁面寫入、雙重寫入緩衝區或日誌封存等傳統資料庫問題
• 資料以 6 份副本的形式，跨 3 個可用區域中的 6 個儲存節點進行備援儲存
• 自動以點對點方式修復損壞或遺漏的日誌記錄，或故障的儲存節點
• 複本管理：
• 最多可新增 15 個唯讀複本，而不會產生一致性延遲
• 前端節點之間採用非同步失效及更新
• 複本可採用不同的大小和執行個體類型（例如 Graviton、Intel）
• 儲存體可自動擴充至 256 TB
• 自動容錯移轉：
• 發生故障時，將複本提升為讀寫節點
• 透過 DNS 型端點變更來重新路由應用程式
• 提供進階快速驅動程式，可實現更快（最多快 66%）的容錯移轉
• 多區域功能：
• 跨區域進行儲存體非同步複寫（Global Database）
• 複寫由 Aurora 處理，不需要變更應用程式
• 透過在次要區域執行應用程式，可進行低延遲的區域本機讀取
• 全球資料庫設定最多可使用 10 個區域
• 技術附註：
• 前端節點不參與複寫程序
• 次要區域中的唯讀複本可讓資料近乎即時可見，一般 RPO 延遲少於一秒

全域端點與容錯移轉

• 全域端點是一個指向目前寫入器區域的 DNS 名稱
• 主要區域發生問題時，會發出容錯移轉操作
• 容錯移轉會將另一個區域中的複本提升為寫入器節點
• 由於採用非同步複寫，可能會遺失資料
• 全域端點的 DNS 名稱會透過 Route 53 data plan API 更新 全球資料庫切換：
• 當兩個區域皆運作正常，且基於作業原因移動寫入器時，就會進行切換
• 最近的改善將切換時間從 5 分鐘縮短至 30 秒
• 運用日誌型架構，實現零資料遺失（RPO 為 0）及 30 秒的復原時間（RTO 為 30 秒）
• 本機寫入轉送：
• 允許將來自次要可用區域的寫入轉送至寫入器節點
• 不會將系統轉換成主動-主動組態
• 來自可用區域 2 的寫入會轉送至可用區域 1 的寫入器節點、執行，然後回傳結果
• 在不影響資料完整性或系統設計的情況下，提高作業彈性 Aurora 的一致性模式：
• 提供三種不同的一致性模式（亦稱可見性模式）
• 預設模式為工作階段可見性，會等待更新獲得確認後再繼續讀取
• 最終一致性模式不會等待更新，可能導致讀取結果未反映最新寫入
• 全域一致性模式會等待整個叢集的所有更新完成後再繼續，確保讀取結果反映所有寫入
• 本機寫入轉送：
• 允許將來自次要可用區域的寫入轉送至寫入器節點
• 維持與本機操作相同的一致性模式及考量
• 跨區域延遲差異是全域寫入轉送的一項因素 Aurora 儲存節點操作：
• 每個儲存節點都會執行一個「儲存惡魔」，以協助引擎與儲存體之間進行通訊
• 日誌記錄會寫入傳入佇列、排放至磁碟上的作用中日誌，然後獲得確認
• 遺漏的日誌記錄（例如因傳輸延遲造成）可透過點對點方式從其他儲存節點擷取
• 日誌記錄會合併至資料庫頁面，確保提供讀取要求時，延遲受到的影響降至最低
• 持續備份至 S3，可還原至過去 35 天內的任一時間點

IO 最佳化組態

• 調整組態選項，以提升 IO 密集型應用程式的輸送量。
• 修改儲存驅動程式，以進行更積極的批次處理，對 IO 密集型應用程式很有幫助。
• 使用現代引擎版本，以進一步最佳化。
• 將傳入佇列變更為耐久性佇列，以減少延遲與抖動，從而改善效能。
• Aurora PostgreSQL 相容性與更新：
• Aurora PostgreSQL 與 PostgreSQL 完全相容。
• 定期整合上游的 PostgreSQL 更新。
• 支援最高 PostgreSQL 17.6 版。
• 與具有本機磁碟的 RAG 執行個體類型相容。
• 包含相關子查詢快取、適應性聯結等多項來自上游的效能改善。
• 推出共用計畫快取，以提高記憶體效率。
• 強化大型執行個體及複本的讀取可用性。
• 實作 FIPS 140-3 安全加密。
• 更新各種擴充功能，特別是 PG vector。
• 支援最高 256 TB 的磁碟區。
• Aurora PostgreSQL 效能分析：
• 評估不同執行個體世代的輸送量。
• 測試範例：
• R52.4Xlarge（較舊的執行個體）與 R7i.48Xlarge（較新、較大的執行個體）的 CPU 密集型效能比較顯示，效能提升 2.1 倍。
• 推出的 R8G（下一代 Graviton 版本）比基準提升 2.7 倍，顯示其擴展幅度優於線性。
• 優於線性的擴展，是指當資源（例如資料大小或節點）增加時，系統或程序的效能或效率以不成比例的良好幅度提升，這通常見於對數成長或特殊架構；相較之下，線性成長是輸入加倍時輸出也加倍，而次線性擴展則會出現報酬遞減及 Amdahl 定律限制，其應用包括資料視覺化、資料庫效能及運算效率。

Aurora PostgreSQL 動態資料遮罩

• 用於保護 Aurora 中敏感資料的新功能。
• 敏感資料包括帳號、帳戶持有人姓名及個人身分識別資訊 (PII)。
• Aurora PostgreSQL 中的動態資料遮罩：
• 旨在透過提供經過捨入或遮罩的資料版本，保護敏感資料。
• 透過 Aurora 中新的 PG column mask 擴充功能實作。
• 可針對特定資料表及欄定義遮罩政策。
• 範例：
• 將客戶 ID 遮罩成 X's，並將帳戶餘額捨入。
• 政策會套用至指定角色（例如 'analyst'），並以定義的權重解決衝突。
• 在查詢重寫層中實作，可有效率地執行且不影響索引。
• 動態資料遮罩實作詳細資訊：
• 遮罩函數會在查詢重寫階段套用，而不是在擷取後才套用。
• 確保良好效能並維持索引功能。
• 可在查詢描述輸出中看到遮罩函數套用至目標欄。
• Aurora MySQL 更新：
• 最近發行的 3.11 版與 MySQL 8.0.43 相容。
• 推出功能經過強化的 3.10.0 長期支援版本。
• 記憶體內部轉送日誌快取可讓日誌複寫輸送量提升最多 40%。
• MySQL 的進階快速驅動程式支援 ODBC。ODBC (Open Database Connectivity) 是一種 API，可讓應用程式使用標準語言 SQL，存取各種資料庫管理系統中的資料。它扮演橋接器的角色，讓單一應用程式能連線至 SQL Server、MySQL 或 Oracle 等不同資料庫，而不需要針對每一種資料庫重寫。
• 提高磁碟區支援上限至 256 TB。
• 全球資料庫次要讀取器可在發生全域問題時提高讀取可用性。

Aurora Serverless

• 建議的執行個體類型，可簡化機群管理。
• 根據工作負載需求自動調整 CPU 和記憶體。
• 在 V1 終止生命週期後，從 Aurora Serverless V2 重新命名為 Aurora Serverless。
• 提供彈性執行個體類型，以靈活配置資源。
• Aurora Serverless 功能及優點：
• 無須重新啟動引擎，即可自動擴展記憶體、CPU 及網路。
• 每秒進行擴展，並以 Aurora Capacity Units (ACU) 為衡量單位，每個單位代表 2 GB RAM 及相關資源。
• 回應 Lambda 函數或分析工作而進行擴展，根據需求調整 ACU。
• 採每秒計價，使用者只需為實際使用的資源付費。
• Aurora Serverless 的擴展機制：
• 使用會定期補充額度的擴展貯體運作，讓系統可擴展至設定的 ACU 上限。
• 需要擴展時會消耗額度，而貯體會隨時間重新補充。
• 最近的強化功能包括更快的觸發回應（低於 1 秒）、更大的初始貯體容量及更快的補充速率。
• 平台第 3 版的效能改善：
• 無須進行任何選取或額外設定，即可提供最高 30% 的效能改善。
• 適用於所有新叢集，可透過從備份還原、複製或建立新叢集來使用。
• 效能範例：
• 比較開啟與未開啟快速擴展之平台第 2 版的測試顯示，使用快速擴展時，尖峰效能維持時間延長 3.6 倍，且使用的 ACU 小時數減少 9%。
• 平台第 3 版（搭配快速擴展）的測試顯示，相較於平台第 2 版，執行時間和使用的 ACU 小時數減少 20%，使帳單費用降低 20%。
• 更快速的擴展及平台第 3 版都會自動套用至新叢集，使用者不需額外操作，便能獲得更好的效能及成本效益。

使用快速組態建立

• 在數秒內快速建立資料庫叢集。
• 目標使用者是經常建立叢集的人員，例如使用 CI/CD 管線或代理式 AI 應用程式的人員。
• 可為每次互動建立新資料庫，提高敏捷度及速度。
• 使用快速組態建立的功能：
• 提供靈活且可編輯的組態，起始為 16 ACU (Aurora Capacity Units)。
• 可在建立後修改大部分設定，包括變更 ACU 及其他組態。
• 預設即安全，已啟用加密和 IAM (Identity and Access Management)。
• 支援幾乎所有 Aurora 功能，包括全球資料庫及零 ETL。
• 不需要 VPC：
• 推出 Aurora Internet Access Gateway，這項新元件讓使用者無須 VPC (Virtual Private Cloud) 即可存取資料庫叢集。
• Internet Access Gateway 是與 PostgreSQL wire protocol 相容的高可用性端點，可將延遲降至最低。
• 可從任何位置存取 DB 叢集，減少使用 VPN 的需求，並簡化開發人員的程序。
• 與 Amazon IAM 和 AWS Shield 整合，提供詐騙防護及資料保護等強化安全功能。
• AWS Shield 是一項受管服務，可保護在 Amazon Web Services (AWS) 上執行的應用程式，防範分散式阻斷服務 (DDoS) 攻擊。它提供兩個層級：免費的 AWS Shield Standard 會自動緩解常見的網路層攻擊；付費的 AWS Shield Advanced 則提供更複雜攻擊的防護、進階功能及專家支援。

Aurora 與代理式 AI 的整合

• Aurora 可作為代理式 AI 系統的記憶體，這對代理式 AI 迴圈的運作至關重要。
• 使用「Letter」框架的範例：使用快速組態建立 DB 叢集、啟用用於向量嵌入的 PG vector 擴充功能，並將 Letter 框架指向 PostgreSQL 端點。
• Aurora PostgreSQL 可在 LangChain 等各種框架中用於遺傳式 AI 記憶體。
• 由 AWS 開放原始碼的 MCP (Model Context Protocol) 伺服器，可使用自然語言查詢來理解 Aurora 資料庫的結構描述，並將查詢轉換成 SQL 查詢。這對探索資料庫的新使用者及追求效率的進階使用者都有幫助。
• Aurora 中的修補與升級：
• Aurora 提供叢集修補及升級的受管體驗，主控台中可看見待處理的維護動作。
• OS 修補程式會以滾動方式套用至叢集中的多個節點，以提高可用性。
• 使用者可以設定更新的維護時段，並接收維護動作的通知。
• 維護動作可選擇是否自動化，讓使用者能透過 Terraform 等自己的系統控制升級。
• 對於叢集機群，依序升級開發、QA 及生產環境至關重要。
• Aurora 叢集循序升級：
• 必須依序升級不同環境（開發、QA、生產），才能保留測試及反應時間。
• 隨機發布維護公告可能會在開發環境之前升級 QA 環境，違反期望的順序，因而形成挑戰。

AWS Organization 的升級推出政策

• 為解決順序問題而推出，可將升級分成不同波次（第 1 波、第 2 波、最後一波）。
• 此程序包括通知使用者、等待第一波的維護時段、升級這些執行個體、烘焙（測試期間），接著再進行下一波。
• 提供使用者充分的時間，以便在發生問題時做出反應或選擇退出。
• 無論更新在星期幾發布，升級都會依序進行。
• 升級推出政策的實作：
• 需要啟用 AWS Organizations，並將帳戶置於組織內。
• 一般設定包括啟用自動次要版本升級及設定維護時段。
• 政策透過將標籤與資源建立關聯來設定；例如，為資源標記 "env=prod"，將其安排在最後一波。
• 沒有可辨識標籤的資源會預設歸入指定波次（例如第二波）。
• 使用者可以選擇不使用標籤並接受預設值，一次升級所有資源。
• 套用升級推出政策：
• 建立政策後，可將其連結至整個組織（根）或個別帳戶，以選擇性地套用。
• 升級期間，使用者會在待處理的維護動作及 AWS Health 中看到通知，指明升級將在哪個波次進行。

用於主要版本升級的藍綠部署

• 對於與目前版本不相容，且若就地執行便需要停機的主要版本升級，藍綠部署至關重要。
• 此程序涉及建立完整的生產環境副本（「綠色」環境）、使用邏輯複寫同步資料，並在藍綠部署的整個執行期間保持同步。
• 可在切換前徹底測試升級後的環境。
• 透過 CLI 或主控台進行的切換，會重新命名 AWS 資源並將端點切換至綠色環境，確保不會遺失資料且停機時間極短（通常不到一分鐘）。
• 若切換逾時，會提供後援選項，自動還原至原始（藍色）環境。
• 不僅適用於版本升級，也適用於結構描述變更、靜態參數變更，以及被認為不適合就地變更、風險過高的維護更新。
• 全球資料庫的藍綠部署：
• 最近新增對全球資料庫的支援，可使用藍綠部署跨區域進行主要版本升級。
• 此程序與單一區域部署相同，使用邏輯複寫確保資料同步及極短的停機時間（切換約需 1 分鐘）。
• 可在零資料遺失（RPO 為 0）及約 1 分鐘的復原時間目標（RTO）下，升級整個全球叢集的主要版本。

Aurora 的零 ETL 功能

• 無須管理 ETL 管線，即可將資料從 Aurora PostgreSQL 低延遲地傳輸至 Redshift。
• 透過 CLI 命令建立 Aurora 與 Redshift 叢集之間的管線來實現。
• 複寫延遲為 5 至 12 秒，確保資料可在 Redshift 中快速使用。
• 管理資料植入、維護及異動資料擷取 (CDC) 串流，讓使用者免於處理這些複雜工作。
• 支援將多個 Aurora 叢集（包括 MySQL 及 PostgreSQL）整合至單一 Redshift 叢集或資料湖。
• 也可使用相同技術，讓資料從 Aurora MySQL 流向 SageMaker。
• 零 ETL 的基礎技術：
• 在儲存層使用平行直接匯出，將資料快速植入 Redshift，且不影響效能。
• 使用內嵌於儲存體中的增強型 bin log（用於 MySQL）或 PostgreSQL 對等機制，以擷取邏輯複寫日誌。
• CDC 串流伺服器直接從儲存體讀取日誌，套用篩選及修改後再將資料推送至 Redshift，確保不會影響前端節點效能。
• Aurora 儲存體類型：
• Aurora Standard：提供基本效能及成本特性的預設儲存體類型。

Aurora 儲存成本與效能的詳細說明

• 讀取操作：若資料已快取，成本極低（數毫秒的執行個體執行時間）。若快取未命中，則會從儲存體讀取資料；依資料庫引擎而定，每個 8K 或 16K 資料庫頁面的成本不到一美分。
• 寫入操作：最多 4 KB 的成本不到一美分。較大的寫入可能會批次處理成最多 4 次 I/O，每個批次的成本會依其大小而定，皆不到一美分。
• Aurora I/O 最佳化儲存體：
• 提供更可預測的定價，效能也可能更好。
• 這是叢集層級的組態，可在建立叢集時選擇，也可在線上切換。
• 同時變更系統效能和架構，包括儲存體端的變更。
• 建議 Aurora 帳單中 I/O 占比超過 25% 的使用者採用，因為它可能會節省成本並提供更好的效能。
• 適用於過去 18 個月內推出的所有現代引擎版本，並與資料庫 Savings Plans 相容。
• I/O 最佳化儲存體的成本模型：
• 使用者需為運算和儲存體支付略高的費用，但 I/O 完全免費，讓帳單更簡單且更可預測。
• 適合具有大量 I/O 操作的工作負載，因為免除 I/O 成本可抵銷運算和儲存體的額外費用。
• I/O 最佳化的效能改善：
• 在 16X large 執行個體上進行的測試顯示，執行第 14 版的 R6I 16X large 執行個體啟用 I/O 最佳化後，輸送量提升 1.9 倍。
• 升級至搭載 PostgreSQL 16 版的 R7I 執行個體後，觀察到進一步改善（額外 10%）。

I/O 最佳化帶來的延遲與輸送量改善

• 延遲測試：搭載 PostgreSQL 17 版的 R8G 48X large 執行個體使用 I/O 最佳化時，延遲顯著改善，在低端改善 3 倍，高端則改善 6.4 倍。
• 輸送量測試：在相同條件下，輸送量改善 5 倍，突顯 I/O 最佳化對延遲與輸送量的雙重效益。
• 暫存物件與本機 NVMe 儲存體：
• 本機 NVMe 儲存體是指伺服器或雲端執行個體內速度極快、以實體方式連接的固態硬碟 (SSD)，可提供極低延遲及高輸送量，非常適合需要暫時、高效能暫存空間的高需求應用程式（AI/ML、資料庫）。
• 速度：使用 PCIe 匯流排，避開網路與控制器瓶頸，實現低於一毫秒的延遲及龐大的 IOPS。
• 直接連接：實體安裝於伺服器或執行個體機箱內（例如 AWS EC2 或 Azure VM）。
• 暫時性：資料是暫時的；執行個體終止、故障，有時甚至重新啟動或維護後，資料便不會保留。
• 在 PostgreSQL 中使用暫存物件執行索引重建或大型排序等操作，這些操作可能超出記憶體容量而需要磁碟儲存體。
• 在一般系統中，此磁碟是 EBS 磁碟，因而需要考量效能。
• 使用 RAGD 等 D 執行個體時，會改用本機 NVMe 執行個體儲存體，讓溢出最多可配置記憶體大小的 6 倍，大幅降低延遲，並改善使用這些暫存物件之工作負載的效能。
• I/O 最佳化對暫存物件儲存體的影響：
• I/O 最佳化會將暫存物件的配置量從記憶體的 6 倍降至 2 倍，仍可提升效能，但使用較少的儲存空間。
• 節省下來的儲存空間會用於名為分層快取的功能，此功能旨在提供額外的快取層，以進一步提升效能。

分層快取

• 使用在 I/O 最佳化下減少暫存物件儲存配置所節省的空間。
• 旨在透過新增額外快取層來改善效能，但摘錄中並未提供分層快取具體運作方式的詳細資訊。
• 一般讀取程序：
• 先在共用緩衝區中檢查；若找到資料，便直接讀回，不需要採取進一步動作。
• 若資料不在共用緩衝區中，會從儲存體讀取至共用緩衝區，再提供給引擎。
• 使用 D 執行個體的最佳化讀取：
• 在磁碟上配置記憶體的 4 倍空間作為分層快取，其使用方式與共用緩衝區相似。
• 使用中繼資料判斷要求的資料是否位於磁碟快取中。
• 從儲存體讀取的資料會放入共用緩衝區；緩衝區已滿時，資料會被逐出至分層快取，並由中繼資料追蹤。
• 使用分層快取處理更新：
• 更新會翻轉中繼資料位元，使分層快取中的資料失效，避免頻繁寫入分層快取。
• 彈性與動態分層快取：
• 可根據工作負載需求，調整分層快取與暫存物件的大小比例。
• 對大量磁碟溢出的工作負載增加暫存空間，並在工作負載結束後縮減暫存空間，以擴大分層快取。

R8GD 執行個體效能

• 新的執行個體類型，價格與 R6GD 相同，但效能提升 165%。
• 鼓勵分層快取使用者及考慮採用分層快取的人員使用。
• 分層快取的效能改善：
• 降低讀取操作的延遲，尤其是資料超出記憶體容量時。
• 在 340 GB 測試中，分層快取的延遲比記憶體增加 1.5%，相較於未使用分層快取時增加 8 倍，則僅落後 3 倍。
• Pareto 隨機分佈測試顯示效能甚至更好，大型測試的延遲僅降低 1.4 倍。
• 真實世界使用案例：
• PG vector 基準測試顯示，使用最佳化讀取（R7GD 與 R8G 相比），每秒查詢數改善超過 3.5 倍。
• 比較 R6GD 與 8GD（價格相同），向量效能提升 1.6 倍。
• R：表示記憶體最佳化執行個體系列。
• 7：代表目前的世代（第 7 代）。
• g：表示執行個體使用 AWS Graviton 處理器（Arm 架構）。
• d：表示包含本機 NVMe 型 SSD 儲存體。
• Amazon EC2 R8g 執行個體由 AWS Graviton 4 處理器提供支援，代表 AWS 最新一代的記憶體最佳化執行個體，適用於大型資料庫、即時分析等高需求記憶體內部工作負載。
• Aurora PostgreSQL 與 Aurora MySQL 概觀：
• Aurora PostgreSQL：與 PostgreSQL 完全相容，使用單一寫入器架構，並以隱含或明確鎖定處理並行寫入。
• Aurora MySQL：使用主動-主動查詢處理器進行多次寫入，並採用開放式並行控制來管理衝突。
• Aurora PostgreSQL 的水平擴展涉及新增採用非同步複寫的複本，因而引發一致性問題，並運用快取提升效能。
• 主要差異：
• 並行處理：PostgreSQL 使用鎖定；MySQL 使用開放式並行控制。
• 寫入架構：PostgreSQL 有單一寫入器；MySQL 支援多個作用中的寫入器。
• 擴展機制：PostgreSQL 透過複本擴展；MySQL 透過額外的查詢處理器擴展。

Aurora PostgreSQL 與 Aurora MySQL 的詳細比較

• Aurora PostgreSQL：使用具有單一寫入器的主動-被動架構，並採用明確鎖定進行並行控制。支援透過新增複本來擴展，並使用非同步複寫。
• Aurora MySQL (DSQL)：採用具有多個寫入查詢處理器的主動-主動架構，並使用開放式並行控制。使用分散式區塊儲存區獨立擴展讀取。
• Aurora 的讀取與寫入程序：
• 讀取：由選定的查詢處理器，從各可用區域 (AZ) 的儲存伺服器擷取資料。
• 寫入：查詢處理器會將寫入操作排入多工緩衝處理，直到交易提交為止。提交時，寫入會傳送至裁決器（用於解決衝突），再傳送至日誌（用於跨 AZ 儲存日誌），並由其更新受影響的儲存分片。
• 多區域操作：
• Aurora PostgreSQL：跨區域資料使用非同步複寫，因此提交延遲發生在區域內。
• Aurora MySQL：提交內容會同步複寫至各區域，因此跨區域提交延遲成為根本差異。