本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 透過 Amazon Aurora 執行概念驗證
下列內容將說明如何設定並執行 Aurora 的概念驗證。*概念驗證*是一種調查，可用來確認 Aurora 是否適合您的應用程式。概念驗證可助您了解資料庫應用程式中的 Aurora 功能，以及 Aurora 與您目前資料庫環境的比較。此功能也會呈現您移動資料、轉換 SQL 程式碼、調整效能與目前的管理程序所需的心力。
此主題提供本功能的概觀，以及執行概念驗證牽涉的高階程序與決策的步驟概述 (詳列如下)。如需詳細說明，您可點選特定主題的連結，閱讀完整文件。
## Aurora 概念驗證概觀
執行 Amazon Aurora 概念驗證時，您將了解將現有資料和 SQL 應用程式轉換至 Aurora 所需耗費的心力。您會使用一定量的資料和活動來代表您的生產環境，大規模執行 Aurora 的重要面向。目標是要確認 Aurora 的優勢，能夠完美解決您不想再使用舊有資料庫基礎設施的問題。在概念驗證的結尾，您將取得堅實的計畫，能夠執行更大規模的效能基準與應用程式測試。此時，您會了解生產部署過程中最大的作業項目。
下列最佳實務的建議有助您避開基準測試期間造成問題的常見錯誤。不過，此主題並未涵蓋執行基準測試和調整效能的逐步流程。相關程序會取決於您的工作負載，以及您使用的 Aurora 功能。如需詳細資訊，請參考效能相關文件，例如 [管理 Aurora 資料庫叢集的效能和擴展](Aurora.Managing.Performance.md)、[Amazon Aurora MySQL 效能增強功能](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance)、[Amazon Aurora PostgreSQL 的效能和擴展](AuroraPostgreSQL.Managing.md) 及[在 Amazon Aurora 上使用績效詳情監控資料庫負載](USER_PerfInsights.md)。
此主題資訊主要適用的應用程式，必須由您的組織撰寫程式碼及設計結構描述，而且要支援 MySQL 和 PostgreSQL 開放原始碼資料庫引擎。若您測試的商用應用程式或程式碼係由應用程式架構所產生，您可能會無法靈活應用所有準則。此時，請諮詢您的 AWS 代表，確認是否有適用您應用程式類型的 Aurora 最佳實務或案例研究。
## 1. 確認您的目標
評估將 Aurora 用於概念驗證時，您會選擇要訂定何種衡量方式，以及如何評估執行是否成功。
您必須確認應用程式的所有功能均與 Aurora 相容。由於 Aurora 主要版本直接相容於對應的 MySQL 和 PostgreSQL 主要版本，因此針對這些引擎開發的大多數應用程式也相容於 Aurora。不過，您仍必須依據每個應用程式，確認其相容性。
例如，您設定 Aurora 叢集時所選擇的部分組態，會影響您是否能夠/應該採用特定資料庫功能。您可從最一般用途的 Aurora 叢集著手，也就是*佈建*。接著，您可能要判斷特定組態 (如無伺服器或平行查詢) 能否為您的工作負載帶來效益。
詢問下列問題有助您確認目標並加以量化：
+ Aurora 是否支援您工作負載使用案例的所有功能呢？
+ 您想要多大的資料集大小或負載程度？ 您能否擴展至該程度？
+ 您有何特定的查詢輸送量或延遲需求？ 您能否滿足這些需求？
+ 您工作負載可承受的意外或非意外停機時間下限為多少？ 您能否達成這個目標？
+ 操作效率的必要指標有哪些？ 您能否精準監控這些指標？
+ Aurora 是否支援您特定的業務目標，例如降低成本、增加部署或佈建速度？ 您是否有辦法將這些目標量化？
+ 您的工作負載能否滿足所有安全與合規要求？
請花些時間認識 Aurora 資料庫引擎和平台功能，同時檢閱服務文件，並記下所有能夠幫助您取得滿意結果的功能。其中一項實用功能或許為工作負載整合，請閱讀 AWS 資料庫部落格[針對整合工作負載，如何依據 MySQL 的相容性規劃 Amazon Aurora 並將之優化](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/)相關文章。另一個以需求為基礎的擴展功能或許也很實用，請參閱 *Amazon Aurora 使用者指南*中的[使用 Amazon Aurora 自動擴展搭配 Aurora 複本](Aurora.Integrating.AutoScaling.md)。其他功能則包括提升效能，或者簡化資料庫的操作。
## 2. 了解您的工作負載特性
依據您預期的使用案例來評估 Aurora。Aurora 是線上交易處理 (OLTP) 工作負載的理想選擇。您也可在留有即時 OLTP 資料的叢集上執行報告，無須佈建另一個資料倉儲叢集。您可檢視您使用案例是否具備下列特性，確認該案例是否屬於類似情境：
+ 高度並行需求，同時間用戶端數量可達數十、數百或數千。
+ 大量低延遲查詢 (數毫秒至數秒)。
+ 短而即時的交易。
+ 高選擇性的查詢模式，搭配索引式查閱。
+ 如為 HTAP，能夠善加運用 Aurora 平行查詢的分析查詢。
選擇資料庫的關鍵因素之一就是資料的速度。*高速*表示資料插入與更新的次數相當頻繁。此類系統可能有數千個連線及數十萬個同時查詢，都會針對資料庫進行讀取和寫入。高速系統的查詢通常會影響相對少數的資料列，而且會存取相同資料列內的多個欄。
Aurora 係針對處理高速資料而設計，搭配單一 r4.16xlarge 資料庫執行個體的 Aurora 叢集會視其工作負載，每秒可能要處理超過 60 萬筆 `SELECT` 陳述式。同樣地，取決於工作負載而定，這樣的叢集每秒可以處理 200,000 個 `INSERT`、`UPDATE`，以及`DELETE` 陳述式。Aurora 為列儲存區資料庫，非常適合用在大量、高輸送量及高度平行的 OLTP 工作負載。
Aurora 也可在處理 OLTP 工作負載的相同叢集上執行報告查詢。Aurora 支援多達 15 個[複本](Aurora.Replication.md#Aurora.Replication.Replicas)，每個複本平均會在主要執行個體的 10—20 毫秒內。分析師可即時查詢 OLTP 資料，無須將資料複製到另一個資料倉儲叢集。透過 Aurora 叢集使用平行查詢功能，您可將多數處理、篩選和彙總作業，卸載至廣泛分散的 Aurora 儲存子系統。
運用此規畫階段熟悉 Aurora、其他 AWS 服務、AWS 管理主控台 和 AWS CLI 的功能。此外，請確認如何在概念驗證中，將這些功能與您預計要使用的其他工具搭配使用。
## 3. 透過 AWS 管理主控台或 AWS CLI 來練習
在下一步中，請透過 AWS 管理主控台 或 AWS CLI 練習，熟悉這些工具及 Aurora。
### 透過 AWS 管理主控台來練習
以下主要為 Aurora 資料庫叢集的初始活動，讓您熟悉 AWS 管理主控台 環境，並練習設定與修改 Aurora 叢集。若您使用 MySQL 相容或 PostgreSQL 相容的資料庫引擎來搭配 Amazon RDS，則使用 Aurora 時須仰賴相關知識。
善用 Aurora 的共用儲存模型和功能 (如複寫和快照)，可將整個資料庫叢集視為另一種您可以自由掌控的物件。在概念驗證期間，您可頻繁設定、拆卸和變更 Aurora 叢集的容量，不用因為最初的容量、資料庫設定和實際資料配置選擇而綁手綁腳。
若要開始使用，請設置空的 Aurora 叢集。請為您的最初測試選擇 **provisioned (佈建的)** 容量類型，以及 **regional (區域性)** 位置。
使用用戶端程式 (如 SQL 命令列應用程式) 來連接至該叢集。首先，您使用叢集端點來連接。您要連接至該端點，才能執行寫入操作，例如資料定義語言 (DDL) 陳述式和擷取、轉換、載入 (ETL) 流程。稍後在概念驗證中，您會使用讀取器端點來連接至查詢密集的工作階段，此端點會將查詢工作負載分散至叢集內的多個資料庫執行個體。
新增更多 Aurora 複本來擴展叢集，相關程序請參閱[以 Amazon Aurora 進行複寫](Aurora.Replication.md)。擴展或縮減資料庫執行個體的方法，是改變 AWS 執行個體類別。請了解 Aurora 如何簡化這類操作，若您對系統容量的初估值不正確，即可知道如何調整，無須重新來過。
建立快照，並將其還原至不同的叢集。
檢查叢集指標來查看各個時間的活動，並確認指標如何套用至叢集內的資料庫執行個體。
若能在一開始就熟悉如何透過 AWS 管理主控台來執行這些操作，會非常有用。了解 Aurora 的功能後，即可進展至使用 AWS CLI，將這些操作自動化。下一節會進一步說明概念驗證期間，這些活動的程序和最佳實務詳細資訊。
### 透過 AWS CLI來練習
即使是在概念驗證設定中，我們也建議將部署和管理程序自動化，方法是透過您已經熟悉的 AWS CLI。若您使用 MySQL 相容或 PostgreSQL 相容的資料庫引擎來搭配 Amazon RDS，則使用 Aurora 時須仰賴相關知識。
Aurora 通常會牽涉到叢集內安排的資料庫執行個體群組。因此，許多操作會判斷與叢集相關聯的資料庫執行個體，然後重複在所有執行個體執行管理操作。
例如，您自動化的步驟可能包括建立 Aurora 叢集、透過更大的執行個體類別或額外的資料庫執行個體分別將之垂直、橫向擴展。如此一來，即可在概念驗證中的任何階段重複動作，並探索不同類或不同組態的 Aurora 叢集的模擬情境。
請認識基礎設施部署工具 (如 AWS CloudFormation) 的功能與限制。部分在概念驗證情境中的活動，可能並不適合用於生產。例如，CloudFormation 的修改行為會建立新的執行個體，並刪除現有執行個體與其中資料。如需此行為的詳細資訊，請參閱 *AWS CloudFormation 使用者指南*中的[更新堆疊資源的行為](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html)。
## 4. 建立 Aurora 叢集
透過 Aurora，您可將資料庫執行個體新增至叢集，或者將資料庫執行個體擴展為更為強大的執行個體類別，藉此探索模擬情境。您也可用不同的組態設定來建立叢集，同時執行相同的工作負載。有了 Aurora，您將享受更多彈性來設置、拆卸或重新設定資料庫叢集。有鑑於此，在概念驗證的早期階段練習這些技巧就十分實用。如需建立 Aurora 叢集的一般程序，請參閱[建立 Amazon Aurora 資料庫叢集](Aurora.CreateInstance.md)。
如可行，請使用下列設定來著手。若您心中有特定使用案例，請略過此步驟。例如，若您的使用案例需要特殊類別的 Aurora 叢集，則可略過此步驟；或者，若您需要特定資料庫引擎和版本的組合，也可略過此步驟。
+ 關閉 **Easy create** (輕鬆建立)。在概念驗證中，建議您注意所選擇的所有設定，之後即可建立相同或略為不同的叢集。
+ 使用最新的資料庫引擎版本。這些資料庫引擎和版本組合廣泛相容於其他 Aurora 功能，相當多客戶都選擇普遍用於生產應用程式中。
+ Aurora MySQL 第 3.x 版 (與 MySQL 8.0 相容)
+ Aurora PostgreSQL 15.x 或 16.x 版
+ 選擇 **Dev/Test (開發/測試)** 範本。此選項對於概念驗證活動並不重要。
+ 若為 **DB instance class** (資料庫執行個體類別)，請選擇 **Memory optimized classes** (記憶體最佳化類別)，及其中一種 **xlarge** 執行個體類別。您稍後可上調或縮減此執行個體類別。
+ 在 **Multi-AZ Deployment** (異地同步備份部署) 之下，請選擇 **Create an Aurora Replica or Reader node in a different AZ (在不同 AZ 中建立 Aurora 複本或讀取器節點)**。許多 Aurora 最實用的功能會牽涉多個資料庫執行個體的叢集，因此，新的叢集從至少兩個資料庫執行個體著手，都是合理做法。第二個資料庫執行個體請選擇不同可用區域，如此有助測試不同的高可用性情境。
+ 為資料庫執行個體命名時，請使用通用的命名慣例。不要將任何叢集資料庫執行個體稱為「寫入器」，因為不同資料庫執行個體會視需要擔任這些角色。建議您使用 `clustername-az-serialnumber` 這類名稱，如 `myprodappdb-a-01`，如此即可明確辨識資料庫執行個體及其配置。
+ 為 Aurora 叢集設定高備份保留期。保留期間長，您執行的時間點復原 (PITR) 期間最長可為 35 天。執行 DDL 和資料處理語言 (DML) 陳述式後，您可將資料庫重設回已知狀態。若您意外刪除或變更資料，也可加以還原。
+ 在建立叢集時，開啟其他還原、記錄和監控功能。請開啟**恢復**、**績效詳情**、**監控**及**日誌匯出**底下的所有可用選項。啟用這些功能後，即可測試恢復、增強型監控或績效詳情等功能是否適合用於您的工作負載。在概念驗證期間，您也可輕鬆調查效能並執行故障診斷。
## 5. 設定您的結構描述
在 Aurora 叢集上，為您的應用程式設定資料庫、資料表、索引、外部索引鍵和其他結構描述物件。若您正遷離 MySQL 相容或 PostgreSQL 相容的資料庫系統，這個階段將十分簡單而直接。您要使用相同 SQL 語法和命令列或其他熟悉的用戶端應用程式，來搭配您的資料庫引擎。
如要在叢集上發出 SQL 陳述式，請尋找其叢集端點，並提供該值做為連接至您的用戶端應用程式的連線參數。在叢集詳細資訊頁面的 **Connectivity (連線功能)** 索引標籤中，即可找到叢集端點。叢集端點會標記 **Writer (寫入器)**，另一個標記為 **Reader (讀取器)** 的端點就是您可提供給最終使用者的唯讀連線，讓他們執行報告或其他唯讀查詢。如需連接至叢集的問題協助，請參閱[連接至 Amazon Aurora 資料庫叢集](Aurora.Connecting.md)。
若您要從不同的資料庫系統轉換結構描述和資料，此時必須略為修改結構描述，這些變更是為了要符合 SQL 語法及 Aurora 內的功能。您可以保留部分欄、限制、觸發條件或其他結構描述物件不變，這樣做可能很有用，因為這些物件對您的概念驗證目標而言可能並不重要，而且未來或許需要搭配 Aurora 相容性重新處理。
若您要遷離的資料庫系統使用 Aurora 以外的基礎引擎，請考慮使用 AWS Schema Conversion Tool (AWS SCT) 來簡化流程。如需詳細資訊，請參閱 [AWS Schema Conversion Tool 使用者指南](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html)。如需遷移和移植活動的一般詳細資訊，請參閱 AWS 白皮書《[將資料庫遷移至 Amazon Aurora](https://d1.awsstatic.com/whitepapers/RDS/Migrating%20your%20databases%20to%20Amazon%20Aurora.pdf)》。
此時您可評估結構描述設定是否有效率不彰的問題，例如索引策略或其他資料表結構 (如分割資料表)。將應用程式部署在使用多個資料庫執行個體且工作負載繁重的叢集時，這類效率問題可能會放大。請考慮是否現在就微調這方面的效能層面，或者在稍後的活動 (如完整基準測試) 中再來微調。
## 6. 匯入資料
概念驗證期間，您會將資料或代表範本，遷離舊有的資料庫系統。如可行，請在每個資料表內至少設定一些資料，如此有助測試所有資料類型和結構描述功能的相容性。練習基本的 Aurora 功能後，請擴展資料量。完成概念驗證時，您應該要測試 ETL 工具、查詢和整體工作負載，其中的資料集要足以取得準確的結論。
您可使用數個技術，將實體資料或邏輯備份資料匯入 Aurora。如需詳細資訊，請參閱[將資料遷移至 Amazon Aurora MySQL 資料庫叢集](AuroraMySQL.Migrating.md)或[將資料遷移至與 PostgreSQL 相容的 Amazon Aurora](AuroraPostgreSQL.Migrating.md) (視您在概念驗證中使用的資料庫引擎而一)。
測試您考慮要使用的 ETL 工具和技術，並選出最能符合需求的。請同時考量輸送量和彈性，例如，部分 ETL 工具會執行一次性傳輸，其他則會持續從舊的系統複寫至 Aurora。
從 MySQL 相容的系統遷移至 Aurora MySQL 時，您可使用原生資料傳輸工具，從 PostgreSQL 相容的系統遷移至 Aurora PostgreSQL 也是如此。若您要遷離的資料庫系統使用的基礎引擎不同於 Aurora，您可透過 AWS Database Migration Service (AWS DMS) 進行測試。如需 AWS DMS 的詳細資訊，請參閱 [AWS Database Migration Service 使用者指南](https://docs.aws.amazon.com/dms/latest/userguide/)。
如需遷移和移植活動的詳細資訊，請參閱 AWS 白皮書 [Aurora 遷移手冊](https://d1.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf)。
## 7. 移植 SQL 程式碼
測試 SQL 及相關聯應用程式，在不同案例需要不同程度的心力，遷離 MySQL 或 PostgreSQL 相容的系統或其他類系統更是有差別。
+ 若您正遷離 RDS for MySQL 或 RDS for PostgreSQL，SQL 所需的變動不大，您甚至可在 Aurora 測試原始 SQL 程式碼，並手動帶入必要變更。
+ 同樣地，若您遷離的現場部署資料庫與 MySQL 或 PostgreSQL 相容，您也可測試原始 SQL 程式碼，並手動帶入變更。
+ 若您正從商用資料庫遷離，則 SQL 就需要大幅變動，此時請考慮使用 AWS SCT。
此時您可評估結構描述設定是否有效率不彰的問題，例如索引策略或其他資料表結構 (如分割資料表)。請考慮是否現在就微調這方面的效能層面，或者在稍後的活動 (如完整基準測試) 中再來微調。
您可在應用程式中驗證資料庫連線邏輯。為了善加運用 Aurora 的分散式處理能力，讀取和寫入操作可能需要不同的連線，而查詢操作則使用相對短的工作階段。如需連線的詳細資訊，請參閱 [9. 連線到 Aurora](#Aurora.PoC.Connections)。
請確認您的生產資料庫是否有所犧牲或權衡以應付問題，並在概念驗證期間排入多一點時間，以改善結構描述設計和查詢。如要判斷您是否成功兼顧效能、營運成本和擴充能力，請在不同 Aurora 叢集上同時測試原始和修改後的應用程式。
如需遷移和移植活動的詳細資訊，請參閱 AWS 白皮書 [Aurora 遷移手冊](https://d1.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf)。
## 8. 指定組態設定
在 Aurora 概念驗證練習中，您亦可檢閱資料庫組態參數。您的 MySQL 或 PostgreSQL 組態設定，可能已經針對目前環境的效能和擴充能力進行調整。Aurora 儲存子系統會針對分散式雲端環境和高速儲存子系統進行調整，因此許多舊有的資料庫引擎設定並不適用。建議您透過預設 Aurora 組態設定來進行初始測試。只有當效能和擴充能力出現瓶頸時，才重新套用目前環境的設定。如有興趣，您可前往 AWS 資料庫部落格，在[介紹 Aurora Storage Engine](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) 中深入了解此主題。
對於特定應用或使用案例，Aurora 可輕鬆重複使用最佳組態設定。您會管理指派至整個叢集或特定資料庫執行個體的參數組，無須針對每個資料庫執行個體個別編輯組態檔案。例如，時區設定會套用至叢集內的所有資料庫執行個體，而且您可針對每個資料庫執行個體調整頁面快取大小設定。
請從一組預設參數組著手，再將變更套用至您需要微調的參數。如需使用參數群組的詳細資訊，請參閱 [Amazon Aurora 資料庫叢集和資料庫執行個體參數](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups)。如需 Aurora 叢集適用或不適用的組態設定資訊，請參閱 [Aurora MySQL 組態參數](AuroraMySQL.Reference.ParameterGroups.md)或 [Amazon Aurora PostgreSQL 參數](AuroraPostgreSQL.Reference.ParameterGroups.md) (視您的資料庫引擎而異)。
## 9. 連線到 Aurora
初次設定結構描述與資料並執行範例查詢時，您會發現您可連線至 Aurora 叢集內的不同端點。所使用的端點取決於該操作為讀取 (如 `SELECT` 陳述式) 或者寫入 (如 `CREATE` 或 `INSERT` 陳述式)。在 Aurora 叢集上增加工作負載並測試 Aurora 功能時，您的應用程式務必將每個操作指派給適當的端點。
針對寫入操作使用叢集端點，您會一律連線至叢集內具有讀/寫能力的資料庫執行個體。根據預設，Aurora 叢集內只有一個資料庫執行個體具備讀/寫能力。這個執行個體稱為*主要執行個體*。若原始主要執行個體變得無法使用，Aurora 會啟動容錯移轉機制，另一個資料庫執行個體會成為主要執行個體。
同樣地，將 `SELECT` 陳述式指向讀取器端點，即可分散叢集內資料庫執行個體處理查詢的作業。系統會使用輪詢 DNS 解析，將每個讀取器連線指派給不同的資料庫執行個體。在唯讀資料庫 Aurora 複本上執行多數查詢作業，可減少主要執行個體上的負載，釋出資源來處理 DDL 和 DML 陳述式。
使用這些端點會減少對硬編碼主機名稱的依賴，有助應用程式更快速從資料庫執行個體的故障中恢復。
**注意**
Aurora 也可讓您自訂端點，不過概念驗證期間通常不需要這些端點。
Aurora 複本會產生複本延遲，不過通常僅 10 至 20 毫秒。您可監控複寫延遲，並判斷該延遲是否仍在您資料一致性所需的範圍內。在部分案例中，您的讀取查詢可能需要更強大的讀取一致性 (先寫後讀一致性)，此時可沿用叢集端點，不要改用讀取器端點。
如要善加運用 Aurora 的功能來達成分散式平行執行，您可能需要變更連線邏輯，目標是避免將所有讀取請求傳送至主要執行個體。唯讀 Aurora 複本及其中所有資料會準備好來處理 `SELECT` 陳述式。將應用程式的邏輯，撰寫成針對各種操作使用適當的端點。請遵守這些一般準則：
+ 所有資料庫工作階段避免使用單一硬編碼連線字串。
+ 如可行，請將寫入操作 (如 DDL 和 DML 陳述式) 納入用戶端應用程式碼的函數中。如此一來，不同操作就會使用各自的連線。
+ 為查詢操作制定不同函數。Aurora 會將新的讀取者端點連線指派給不同的 Aurora 複本，以平衡讀取密集型應用程式的負載。
+ 若是牽涉多組查詢的操作，請在每組相關查詢完成後，關閉並重新開啟讀取器端點的連線。若您的軟體堆疊具備此功能，請使用連接共用。將查詢導向不同的連線，有助 Aurora 分散叢集內資料庫執行個體的讀取工作負載。
如需 Aurora 連線管理和端點的一般資訊，請參閱[連接至 Amazon Aurora 資料庫叢集](Aurora.Connecting.md)。若要深入了解此主題，請參閱 [Aurora MySQL 資料庫管理員手冊 – 連線管理](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)。
## 10. 執行工作負載
結構描述、資料和組態設定就緒後，即可執行工作負載，開始演練叢集。在概念驗證中使用的工作負載，要能反映生產工作負載的主要面向。建議一律使用實際測試結果和工作負載來制定效能方面的決策，避免使用合成基準 (如 Sysbench 和 TPC-C)。如可行，請依據自己的結構描述、查詢模式和使用量來收集測量值。
並盡可能複製出應用程式執行所在的實際情況。例如，您在其上執行應用程式程式碼的 Amazon EC2 執行個體，通常要與 Aurora 叢集位於相同 AWS 區域和 Virtual Private Cloud (VPC)。若您的生產應用程式在多個橫跨不同可用區域的 EC2 執行個體上執行，請以相同方式設定您的概念驗證環境。如需 AWS 區域的詳細資訊，請參閱 *Amazon RDS 使用者指南*中的[區域與可用區域。]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html)如需進一步了解 Amazon VPC 服務，請參閱《Amazon VPC 使用者指南》**中的[什麼是 Amazon VPC？]( https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)。
確認應用程式運作的基本功能並能夠透過 Aurora 存取資料後，您可以演練 Aurora 叢集的各個面向。建議您試用的功能包括搭配負載平衡的並行連線，以及自動複寫。
此時您應已熟悉資料傳輸機制，因此可以運用大量範例資料來執行測試。
在這個階段，您就能看見組態設定變動的效果，例如記憶體限制和連線限制。請重複 [8. 指定組態設定](#Aurora.PoC.Config)中的程序。
您亦可演練其他機制，例如建立並還原快照。舉例而言，您建立的叢集，可搭配不同 AWS 執行個體類別、AWS 複本數量等等。然後在每個叢集上，還原內含您的結構描述和所有資料的相同快照。如需此階段的詳細資訊，請參閱[建立資料庫叢集快照](USER_CreateSnapshotCluster.md)及[從資料庫叢集快照還原](aurora-restore-snapshot.md)。
## 11. 測量效能
這部份的最佳實務能夠確保所有工具和流程均正確設定，可在工作負載操作期間快速隔離異常行為，也能讓您可靠辨識任何問題的合理原因。
您可在 **Monitoring (監控)** 索引標籤查看叢集的目前狀態，或者隨時間檢查趨勢。每個 Aurora 叢集或資料庫執行個體的主控台詳細資訊頁面，都會提供此索引標籤，其中會以圖表形式呈現 Amazon CloudWatch 監控服務的指標。您可依據名稱、資料庫執行個體和時間區間篩選指標。
如需 **Monitoring (監控)** 索引標籤的更多選項，請在叢集設定內啟用增強型監控及績效詳情。若設定叢集時未選擇啟用這些選項，您也可以稍後再進行設定。
如要測量效能，您主要會仰賴呈現整個 Aurora 叢集的活動的圖表。您可確認 Aurora 複本是否有類似負載和回應時間，並查看作業是如何分割到讀/寫主要執行個體及唯讀 Aurora 複本。若資料庫執行個體之間並不平衡，或者某個問題僅影響一個資料庫執行個體，您可在 **Monitoring (監控)** 索引標籤內檢查該特定執行個體的情形。
模擬生產應用程式的環境和實際工作負載設定完成後，您可測量 Aurora 的效能。最重要的問題如下：
+ Aurora 每秒處理幾個查詢？ 您可檢查 **Throughput (傳輸量)** 指標，查看不同類型作業的數據。
+ Aurora 處理一個查詢平均要花多少時間？ 您可檢查 **Latency (延遲)** 指標，查看不同類型作業的數據。
若要檢視輸送量和延遲指標，請在 [Amazon RDS 主控台](https://console.aws.amazon.com/rds/)中檢查指定 Aurora 叢集的**監控**索引標籤。下列螢幕擷取畫面顯示**監控**標籤上**選取延遲**、**DML 延遲**、**選取輸送量**和 **DML 輸送量**指標的範例。
![\[[監控] 索引標籤，顯示 [選取延遲]、[DML 延遲]、[選取輸送量] 和 [DML 輸送量] 指標。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/AuroraPoC01.png)
若可以，請在您目前環境為這些指標建立基準值。若無法，請執行等同於生產應用程式的工作負載，藉此在 Aurora 上建構基準。例如，執行您的 Aurora 工作負載，其中同時上線使用者和查詢數量採用類似數量。接著，觀察這些值如何依據您測試不同的執行個體類別、叢集大小、組態設定等而變化。
若輸送量數據低於預期，請進一步調查影響工作負載資料庫效能的因素。同樣地，若延遲數據高於預期，請進一步調查。方法是：監控資料庫伺服器的次要指標 (CPU、記憶體等)，檢查資料庫執行個體是否接近這些限制值。您也可看到資料庫執行個體有多少多餘的容量，可處理更多並行查詢、對更大資料表的查詢等等。
**提示**
如要偵測落出預期範圍的指標值，請設定 CloudWatch 警示。
評估理想 Aurora 叢集大小和容量時，您找到的組態須能夠處理應用程式的尖峰效能，而且不會過度佈建資源。其中一個重要的因素在於在 Aurora 叢集中，為資料庫執行個體找到適當大小。首先選取的執行個體大小，要與您目前生產環境的 CPU 與記憶體容量類似，然後收集工作負載在該執行個體大小中的輸送量和延遲數據。接著，將執行個體擴展至下一個更大的大小，檢查輸送量和延遲數據是否改善。同樣地，縮減執行個體大小，並檢查延遲和輸送量數據是否不變。您的目標是在最小的執行個體上，取得最高的輸送量及最低的延遲。
**提示**
請調整 Aurora 叢集與相關聯資料庫執行個體的大小，確保現有容量足以處理突發、無法預測的流量高峰。以關鍵任務資料庫而言，請保留至少 20% 的備用 CPU 和記憶體容量。
執行效能測試的時間要夠長，才能測量資料庫在穩定的預備狀態下的效能。您可能要執行工作負載數分鐘、甚至數小時，才能到達穩定狀態。執行初期出現些許變動十分正常，變動出現的原因在於每個 Aurora 複本，會依據其處理的 `SELECT` 查詢來讓快取準備就緒。
Aurora 在處理交易式工作負載的效能最佳，其中涉及多個同時使用者和查詢。如要確保您啟動的負載足以實現最佳效能，請執行多執行緒的基準，或在效能測試中同時執行多個執行個體。請運用數百甚至數千個同時用戶端執行緒來測量效能，並模擬生產環境預期會同時出現的執行緒數量。您可能也要以更多執行緒執行其他壓力測試，藉以測量 Aurora 的擴充能力。
## 12. 演練 Aurora 高可用性
Aurora 的許多主要功能均與高可用性有關。這些功能包括自動複寫、自動容錯移轉、自動時間點還原備份，而且能夠在叢集中新增資料庫執行個體。這類功能提供的安全與可靠性，對於關鍵任務應用程式十分重要。
評估這些功能需要特定思維。在早期活動 (如效能測量) 中，您會觀察到系統在一切運作順利下的效能如何，而測試高可用性必須全面考慮最差情況的行為。您必須考量各種故障類型，即使該情況非常少見也不能忽略。建議您故意引發一些問題，確認系統可正確而快速地回復。
**提示**
在概念驗證中，將 Aurora 叢集內的所有資料庫執行個體都以相同 AWS 執行個體類別來設定。如此一來，即可測試 Aurora 的可用性功能，將資料庫執行個體離線以模擬故障時，無須大幅變更效能和擴充能力。
我們建議在每個 Aurora 叢集內使用至少兩個執行個體，一個 Aurora 叢集內的資料庫執行個體可橫跨至多三個可用區域 (AZ)，請將前兩個或三個資料庫執行個體放入不同 AZ。開始使用更大的叢集時，請將資料庫執行個體分散至您 AWS 區域內的所有可用區域。如此可增加容錯能力。即使一個問題影響整個 AZ，Aurora 可容錯移轉至不同 AZ 的資料庫執行個體。若您執行的叢集有超過三個執行個體，請將資料庫執行個體盡可能平均分散至所有三個 AZ。
**提示**
Aurora 叢集的儲存體會獨立於資料庫執行個體，而每個 Aurora 叢集的儲存體都會橫跨三個 AZ。
測試高可用性功能時，您在測試叢集內使用的資料庫執行個體一律要具備相同的容量，在資料庫執行個體互相接管時，這樣就可避免效能、延遲等出現無法預測的變更。
如要進一步了解如何模擬故障情形來測試高可用性功能，請參閱[使用錯誤注入查詢測試 Amazon Aurora MySQL](AuroraMySQL.Managing.FaultInjectionQueries.md)。
在概念驗證演練中，一個目標是要找到資料庫執行個體的理想數量，以及最適合這些資料庫執行個體的執行個體類別。要達到這個目標，您必須兼顧高可用性及效能的各自需求。
以 Aurora 而言，叢集內有愈多資料庫執行個體，高可用性的效益就愈大。擁有的資料庫執行個體數較多，也會改善讀取密集型應用程式的可擴展性。Aurora 可以在唯讀 Aurora 複本中分佈多個連接，來進行 `SELECT` 查詢。
另一方面，限制資料庫執行個體的數量，會減少從主要節點的複寫流量。複寫流量會消耗網路頻寬，此為整體效能和擴充能力必須考量的另一面向。因此，對於寫入密集型 OLTP 應用程式而言，使用較少量的大型資料庫執行個體是更好的選擇，而非大量的小型資料庫執行個體。
在典型 Aurora 叢集中，一個資料庫執行個體 (主要執行個體) 會處理所有 DDL 和 DML 陳述式，其他資料庫執行個體 (Aurora 複本) 則僅處理 `SELECT` 陳述式。雖然資料庫執行個體的工作量不一定相同，我們建議叢集內的所有資料庫執行個體都採用相同的執行個體類別。如此一來，若故障發生使得 Aurora 將一個唯讀資料庫執行個體提升為新的主要執行個體，則主要執行個體就可保有相同容量。
若同一叢集內須使用不同容量的資料庫執行個體，請為這些資料庫執行個體設定容錯移轉方案。這些方案會決定容錯移轉機制提升 Aurora 複本的順序。將容量明顯較大或較小的資料庫執行個體放到更低的容錯移轉方案，如此才會最後才選擇它們進行提升。
演練 Aurora 的資料復原功能，例如自動時間點還原、手動快照及還原，以及叢集恢復。如適用，請將快照複製到其他 AWS 區域，並還原至其他 AWS 區域來模擬 DR 情境。
請調查您組織的復原時間目標 (RTO)、復原點目標 (RPO) 和地區備援的要求。多數組織將這些事項納入整體災難復原類別底下。請評估本節的 Aurora 高可用性功能在您災難復原流程情境中的運作情形，以確保符合您的 RTO 和 RPO 要求。
## 13. 後續作業
概念驗證流程成功後，您會確認 Aurora 解決方案是否適合您預期的工作負載。透過上述流程，您已檢查 Aurora 在實際操作環境中的運作情形，同時測量其是否符合您的成功條件。
透過 Aurora 設定完資料庫環境並開始運行後，接著您可開始執行更詳細的評估作業，最後才會遷移並進行生產部署。概念驗證流程或許會/不會納入這些其他步驟，而這取決於您的情況。如需遷移和移植活動的詳細資訊，請參閱 AWS 白皮書 [Aurora 遷移手冊](https://d1.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf)。
另一項後續作業則是，請考量工作負載相關的安全組態，並將其設計為滿足您生產環境的安全要求。請計劃要採取哪些控管措施，以保護 Aurora 叢集主要使用者登入資料的存取。請定義資料庫使用者的角色與責任，以控制對存放於 Aurora 叢集內資料的存取。請考量應用程式、指令碼和第三方工具或服務的資料庫存取要求。請探索 AWS 服務和功能，例如 AWS Secrets Manager 及 AWS Identity and Access Management (IAM) 身分驗證。
此時，您應已理解透過 Aurora 執行基準測試的程序和最佳實務，因此可能會需要其他效能調校。如需詳細資訊，請參閱[管理 Aurora 資料庫叢集的效能和擴展](Aurora.Managing.Performance.md)、[Amazon Aurora MySQL 效能增強功能](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance)、[Amazon Aurora PostgreSQL 的效能和擴展](AuroraPostgreSQL.Managing.md) 和[在 Amazon Aurora 上使用績效詳情監控資料庫負載](USER_PerfInsights.md)。若需要其他調校作業，請確認您已熟悉您在概念驗證期間收集的指標。在後續作業中，您建立的新叢集可能會選擇不同的組態設定、資料庫引擎和資料庫版本。或者，您可能會建立特殊類別的 Aurora 叢集，以滿足特定使用案例的需求。
例如，您可探索 Aurora 平行查詢叢集，供混合式交易/分析處理 (HTPA) 應用程式使用。為了災難復原或縮減延遲而需要分散的地理分布，您可探索 Aurora 全球資料庫。若您的工作負載為間歇性，或者您正在開發/測試情境中使用 Aurora，您可探索 Aurora Serverless 叢集。
您的生產叢集可能也需要處理大量傳入連線。若要了解這些技術，請參閱 AWS 白皮書 [Aurora MySQL 資料庫管理員手冊 – 連線管理](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)。
概念驗證之後，若您覺得 Aurora 不適合您的使用案例，請考慮其他 AWS 服務：
+ 對於純粹的分析使用案例，工作負載受益於單欄式儲存格式和其他更適合 OLAP 工作負載的功能。處理此類使用案例的 AWS 服務包括下列各項：
+ [Amazon Redshift](https://docs.aws.amazon.com/redshift/)
+ [Amazon EMR](https://docs.aws.amazon.com/emr/)
+ [Amazon Athena](https://docs.aws.amazon.com/athena/)
+ 許多工作負載會受益於 Aurora 及這些一個或多個服務的結合。您可使用這些服務，將資料在服務之間移動：
+ [AWS Glue](https://docs.aws.amazon.com/glue/)
+ [AWS DMS](https://docs.aws.amazon.com/dms/)
+ [從 Amazon S3 匯入](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html)，如 *Amazon Aurora 使用者指南*內所述
+ [匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.SaveIntoS3.html)，如 *Amazon Aurora 使用者指南*內所述
+ 許多其他熱門的 ETL 工具