分享到

簡介

Amazon Web Service 的 Relational Database Service (RDS) 由於其彈性和強大的功能集,是資料庫託管的熱門選擇。開發團隊可以佈建新的資料庫以供個人使用、暫存環境和生產工作負載,並將其與 AWS 其他產品套件無縫整合。

在本指南中,我們將討論如何使用 Amazon 的 RDS 設定適用於生產環境的 PostgreSQL 資料庫。我們將逐步介紹建立過程中的重要選項、討論權衡,並設定專為早期生產部署設計的可靠、穩健的資料庫設定。

為什麼選擇 Amazon Web Service 的 RDS?

在我們開始之前,讓我們先簡要討論一下為什麼 AWS 的 Relational Database Service 對許多團隊來說可能是一個不錯的選擇。

RDS 作為一項服務於 2009 年首次發布,作為 MySQL 資料庫的可設定、受管服務。PostgreSQL 支援於 2013 年新增,使該平台有充足的時間穩定和成熟,因為新功能不斷發布,並且考慮了額外的使用案例。

使 RDS 成為有吸引力選項的一些核心功能包括

  • 部署到不同的實體位置(多可用區域):在實體上不同的資料中心建立作用中或待命複本,以在發生基於位置的中斷時提高可用性和可靠性
  • 與 AWS IAM 安全模型整合:利用現有的存取控制和身份功能,在資料庫和用戶端應用程式之間設定身份驗證授權基於角色的存取策略
  • 可設定的備份、加密和監控:使用平台整合的備份、可觀察性工具和加密,以縮減和集中維護資料庫的營運成本。
  • 基於使用量的成本:成本與資料庫的功能和使用量直接相關,減輕了長期容量規劃的不確定性。

考慮到這些優勢,讓我們開始設定 PostgreSQL 資料庫執行個體,以逐步了解該過程。

開始資料庫建立程序

首先,使用您的 AWS 憑證登入您的 Amazon Web Services 主控台。如果您尚未註冊 AWS,您可以立即按照他們的註冊流程進行註冊。

在 AWS 主控台首頁中,在服務搜尋欄位中輸入rds以找到 RDS 服務

Search for AWS RDS

服務下按一下 RDS 以前往 Amazon RDS 主要頁面

Main RDS page

向下捲動直到您看到建立資料庫區段,然後按一下建立資料庫

Create database button

您將被帶到資料庫建立頁面,您可以在其中選取所需的設定。

Database creation page

在本指南的其餘部分,我們將介紹可用的不同選項,並為適用於生產環境的設定提供建議。

設定標準 PostgreSQL 部署選項

RDS 建立程序的第一部分決定了您想要如何設定資料庫,以及新資料庫的基本屬性,例如資料庫引擎、部署類型和基本設定。讓我們開始吧。

設定建立方法

在 RDS 上佈建新資料庫的第一步是選擇建立方法

Choose standard create

雖然簡易建立方法可以幫助您選擇一些合理的預設值,但它無法提供您在為您的環境設定重要資料庫時可能需要的彈性程度。標準建立選項提供額外的選項,而且過程仍然相對簡短。

選擇標準建立,以便您可以完全控制建立過程。

選取 PostgreSQL 引擎和版本

接下來,選擇資料庫引擎

Choose PostgreSQL engine

在本指南中,我們將設定 PostgreSQL 資料庫,因此我們將選擇 PostgreSQL 選項。Amazon Aurora 是另一個與 PostgreSQL 相容的選項,它提供 Amazon 自己的擴展和管理功能。但是,在本指南中,我們將重點介紹原生 PostgreSQL 部署。

選擇您希望使用的 PostgreSQL 版本。預設選取的版本通常是安全的選擇,但您也可能希望選擇最新版本以獲得更新的功能,或根據與您的應用程式函式庫的相容性選擇較舊的版本。

選擇生產範本

接下來,系統會要求您選擇範本

Choose production template

範本旨在提供與典型部署情境相符的預先選取選項。由於我們正在佈建生產資料庫,因此請選取生產範本。

設定資料庫可用性

下一節包含您需要針對部署做出的第一個主要決定:資料庫的可用性和持久性

Choose single DB instance

本節決定了您的資料庫將如何在 AWS 環境中部署。這會影響您的設定在多大程度上能夠抵抗故障和中斷,包括您的特定執行個體和 Amazon 基礎架構中的區域性中斷。

讓我們看看我們擁有的各種選項、它們提供的功能以及它們適用的情境。在本指南中,我們將推薦單一資料庫執行個體,如果您對其他選項不感興趣,可以隨時跳過。

多可用區域資料庫叢集

最安全、最穩健且最昂貴的選項是多可用區域資料庫叢集。

此選項設定一個 PostgreSQL 叢集,該叢集由一個主要資料庫執行個體以及兩個唯讀待命複本組成,每個複本都部署到不同的實體位置。此選項有助於防止在發生故障時資料庫中斷,同時透過複本增加可用的讀取輸送量。

話雖如此,此選項也非常昂貴,因為您必須為部署到不同可用區域的三個獨立資料庫執行個體付費。

如果您的資料庫停機時間直接等同於重大收入損失,這可能是一個不錯的選擇。如果您的典型資料庫使用模式是大量讀取,那麼讀取 IO 的增加也值得注意。如果這與您的使用案例相符,您可能還需要考慮評估 Amazon Aurora,以獲得類似的可用性,最終可能成本更低。

多可用區域資料庫執行個體

此選項將您的資料庫部署為作用中的主要執行個體,以及位於不同可用區域的待命複本。待命複本將保持最新狀態,以便在主要執行個體中斷時,可以觸發容錯移轉,並且待命複本可以承擔主要執行個體的責任。

與上面討論的多可用區域資料庫叢集相比,多可用區域資料庫執行個體只有一個待命複本。此外,待命複本只能用於其待命容量。它不支援唯讀工作負載。

如果您想要一些可用性保護,而不需要更高的讀取輸送量,則此選項可能是一個不錯的選擇。您必須考慮兩個資料庫執行個體的成本,因此價格將高於單一執行個體。如果停機時間對您的營運來說極其昂貴,那麼這可能是防止在發生中斷時可用性中斷的好選擇。

單一資料庫執行個體

單一資料庫執行個體是在一個可用區域內單一資料庫的標準部署。這不提供額外的可用性,這意味著您的資料庫的可用性直接與資料庫執行個體的運作時間相關。如果它出現問題,您的資料庫及其管理的所有資料將無法存取,直到服務恢復。

話雖如此,此選項也是最便宜的。部署由單一執行個體組成,因此不會部署您需要付費的額外資源。

此選項與某些程度的風險相關,但對於許多使用案例來說,風險是可以接受的,並且減輕風險的成本太高。Amazon RDS 在可靠性方面有良好的記錄,即使在單一可用區域內也是如此,因此對於許多使用案例來說,短暫的停機時間是可以接受的。

在本指南中,我們將選擇單一資料庫執行個體,因為它通常足以滿足對停機時間不極度敏感的生產部署。但是,如果您的收入和聲譽與資料庫的運作時間密切相關,那麼考慮其他選擇可能是明智之舉。

設定基本設定

下一節允許您設定部署的基本設定

Configure basic settings

首先,您有機會透過設定資料庫執行個體識別碼來命名您的資料庫執行個體。選擇一些獨特的名稱,以便在 AWS 主控台中顯示時幫助您了解資料庫的角色和用途。

接下來,設定資料庫執行個體的憑證。首先設定 PostgreSQL 資料庫的主要使用者名稱。預設情況下,大多數 PostgreSQL 用戶端工具都假定主要使用者名為 postgres,因此您可以保留該使用者名稱(如果適用)。

注意: 主要使用者名稱是 PostgreSQL 資料庫執行個體中的主要管理員帳戶。您應始終在佈建資料庫執行個體後,建立和設定具有有限權限的其他應用程式特定使用者名稱。設定您的資料庫用戶端和應用程式,以便日常運作使用這些權限較低的身份。僅將主要使用者名稱用於您的初始設定,以及建立更有限且範圍更窄的存取途徑。

然後,您可以選擇設定和確認主要使用者名稱的密碼。您可以為帳戶選擇一個強密碼(最好是機器產生的密碼),或者您可以選取自動產生密碼方塊,讓 AWS 自動為您產生安全密碼。

如果您選擇自己的密碼,請將密碼儲存在安全的地方,因為您稍後將無法檢索它。同樣地,如果您自動產生密碼,您將只能在建立後第一次在 AWS 主控台中存取憑證時存取密碼。請務必安全地記錄密碼,因為您稍後將無法再次檢索它。

選擇資料庫執行個體類別

您需要做出的下一個主要決定是您的資料庫執行個體類別

Choose instance class

基本上,資料庫的執行個體類別決定了您的資料庫將部署到的虛擬機器的大小以及可用的資源。您可以選擇幾種不同類型的執行個體,以及每種類型中資源的組合。

執行個體類別的三個主要類別是

  • 標準:這些包括您可能從 AWS 的 EC2(彈性運算雲)執行個體中熟悉的「m」類別。基本上,這些是均衡的通用執行個體,旨在具有合理的 CPU 與記憶體比率。
  • 記憶體最佳化:這些包括 EC2「r」和「x」執行個體類別。此類別中的執行個體具有更高的記憶體與 CPU 比率,這對於涉及一次將大型資料集載入記憶體的資料庫運算非常有用。
  • 可叢發:這些執行個體通常比其他執行個體效能稍低,但對於許多應用程式來說,仍然可以佔據最佳位置。它們提供較低的基準 CPU 效能,但允許更高的效能叢發以適應尖峰。這讓您可以為較低的平均使用量付費,同時仍然能夠處理不時的額外工作負載。

您選擇的執行個體類別以及您需要的特定資源配置高度依賴於應用程式的使用模式。但是,我們可以提供一些一般指導,以幫助您做出選擇。請記住,如果您的需求發生變化,您可以隨時擴展您的資料庫。

選擇資料庫執行個體類別的一般建議

一般來說,對於大多數關聯式資料庫工作負載來說,RAM 往往比 CPU 更重要。因此,您不應因為擔心效能低下而必然忽略可叢發類別。它們提供了一些最佳價值,同時仍然能夠提供合理的效能。

具體來說,像 db.t3.medium 這樣的執行個體(提供 2 個 vCPU 和 4 GiB RAM)對於許多剛開始的使用案例來說是一個不錯的基準選擇。CPU 應該能夠處理中等程度的活動,同時適應請求尖峰。假設硬體效能適合您的專案,您可能遇到的第一個限制之一是 2,086 Mbps 的網路上限,因此在您做出決定時請記住這一點。

如果您想要更高的 CPU 效能來處理具有大量流量的標準資料庫,您可能需要考慮具有 2-4 個 vCPU 和 8-16 GiB RAM 的標準類別執行個體。m6g 執行個體的廣告宣傳比舊的 m5 執行個體具有高達 40% 的價格效能比,因此在查看標準執行個體時,它們通常是更好的選擇。考慮到這一點,db.m6g.largedb.m6g.xlarge 執行個體是此執行個體類別類型的不錯的入門選擇。

如果您知道您必須將大型資料集載入記憶體,那麼記憶體最佳化資料庫執行個體主要很有用。這可能是因為您的表格包含許多記錄,或者因為您經常查詢大量欄位。如果您大量使用 PostgreSQL 的 JSON 欄位,這可能是需要考慮的事情。話雖如此,最好從更標準的設定開始,如果發現這些資源不足,則變更執行個體類別。

設定儲存選項

接下來,您需要為資料庫執行個體設定儲存

Choose storage options

選擇儲存類型

RDS 提供三種不同類型的儲存,適用於不同的情境

  • 通用 SSD (gp2):這是標準的固態硬碟選擇。您的儲存裝置可用的 IOPS(每秒輸入/輸出操作次數)直接與您配置的空間大小相關。基準 IOPS 設定為每配置 1 GiB 3 IOPS,並能夠在短時間內叢發到 3,000 IOPS。
  • 佈建 IOPS SSD (io1):此選項允許您將儲存空間量與分配給資料庫的 IOPS 分離。
  • 磁性:磁性儲存使用傳統的旋轉磁碟而不是 SSD。

一般來說,幾乎總是最好從通用 SSD 選項開始。這允許您設定所需的空間量,並在 SSD 上部署資料庫。磁性選項很少是一個好的選擇,因為它的速度較慢,並且限制為 1000 IOPS。

如果您執行了相當穩健的應用程式分析,並且對您的環境在各種工作負載下產生的 IOPS 量有很好的了解,那麼佈建 IOPS SSD 是一個不錯的選擇。由於快取和其他可以降低實際點擊磁碟機的操作量的機制,這個數字也往往低於預期。一般來說,將其視為一種進階選擇,一旦您有長時間執行確切設定的經驗,它可能會變得適用。

選取初始儲存空間

選取儲存類型後,選擇要配置的儲存量。這也高度依賴於您的應用程式。然而,一般來說,人們往往高估了他們在開始時需要的空間量。從低開始,並記住您可以隨時擴展。

設定自動擴展

接下來,選擇是否啟用自動擴展。此選項讓您的儲存空間能夠隨著使用量自動調整規模。這通常是個好主意,因為它讓您能以較小的初始配置開始,以獲得更實惠的價格,然後隨著資料增加自動擴增儲存空間。您可以設定最大擴展量,以確保最終擴展的幅度不會超出您的預期。

一般來說,通常從 20 到 100 GiB 的初始配置開始就已足夠(通常取決於何者能為您提供足夠的 IOPS),然後將您的最大儲存空間閾值設定為您願意支付的最大容量。

決定連線策略

設定好儲存空間後,您需要做出的下一個重要決定是關於資料庫的連線能力

Choose connectivity strategy

本節包含許多不同的選項,如果您不熟悉 AWS 的安全性與網路模型,可能會感到困惑。

我們在此建議的通用策略是,對於適合生產環境的部署,應建立每個可用選項的新執行個體,而不是重複使用現有選項。如果您要將資料庫部署到應用程式已在執行的現有環境中,您可能需要調整此策略,但一般規則為新部署提供了最隔離且安全的方法。

設定 VPC

當要求您選擇要部署資料庫的 Virtual Private Cloud (VPC) 時,通常最好將其部署到新的 VPC 或包含將存取它的應用程式的 VPC。通常不建議部署到預設 VPC,因為這表示您的資料庫將受到您對預設網路環境所做的任何調整的影響。

選擇子網路群組

接下來,您需要選擇子網路群組。這定義了 VPC 內可以部署資料庫的 IP 範圍。一般來說,在這裡也建立一個新的群組是個好主意。

決定是否允許公開存取

您需要做出的最重要的選擇之一是是否允許公開存取您的資料庫執行個體。這主要取決於您的安全性需求以及您設定資料庫特殊存取的能力。

最安全的方法是關閉公開存取。這將只允許部署在與您的資料庫相同網路環境中的執行個體(或透過這些執行個體)存取您的資料庫。若要從外部存取您的資料庫,您需要設定一個 跳板主機 或一個具有外部存取的 網際網路閘道,以驗證外部連線並將其路由到您的資料庫。如果您不熟悉設定基礎架構或管理網路規則,這可能是一項重大的任務。

另一種方法是允許公開存取。這將使您的資料庫執行個體可從公共網際網路存取。這安全性較低,因為任何人都可以嘗試連線到您的資料庫,但它確實允許從外部連線進行更簡單的存取模型。如果您選擇此選項,請確保您的所有資料庫密碼都非常強壯且經常輪換。您可能會在日誌中看到外部嘗試存取您服務的行為,因此密碼強度至關重要。

是否啟用公開存取的選擇比最初看起來更複雜。如果您啟用公開存取,您仍然可以將存取權限鎖定到一組特定的外部 IP 位址,並提供其他配置點來篩選掉非法的連線嘗試。一般來說,最好選擇您長期以來最有可能支援的最安全配置。

選擇 VPC 安全群組

VPC 安全群組控制用於連線到內部部署執行個體的存取規則。這些基本上是類似防火牆的存取控制策略,有助於限制可以與您的資料庫執行個體建立的連線類型。

除非您已經為生產資料庫用途設定了一個 VPC 安全群組,否則請建立一個新的 VPC 安全群組。選擇一個名稱,以便在 AWS 主控台中顯示時,幫助您記住安全群組的重點和角色。

選擇可用區域和埠號

您可以選擇要在目前區域中部署資料庫執行個體的可用區域。如果您沒有偏好,請隨意保留選取「無偏好」。

如果您開啟「其他組態」選項,您可以選擇性地變更 PostgreSQL 將監聽的埠號。變更此設定有助於減輕開放執行個體連線日誌中的某些雜訊,但它不會提供任何顯著的安全性改進,並且可能會使連線更加繁瑣。

設定資料庫驗證

接下來,您需要選擇要用於資料庫執行個體的驗證類型

Choose database authentication

選擇如下

  • 密碼驗證:使用 PostgreSQL 原生功能的標準密碼驗證。
  • 密碼和 IAM 資料庫驗證:同時使用 PostgreSQL 的原生密碼功能以及 AWS IAM 角色進行驗證。作為使用資料庫密碼的替代方案,您可以選擇使用 IAM 驗證令牌來驗證您的資料庫執行個體。
  • 密碼和 Kerberos 驗證:同時使用 PostgreSQL 的原生密碼功能以及使用 AWS Directory Service 建立的 AWS Managed Microsoft Active Directory 執行個體。如果您的組織已在使用 AWS 受管 AD 執行個體,這允許您透過票證使用 Kerberos 樣式的驗證。

一般來說,除非您需要更複雜的配置,否則僅使用密碼驗證是合理的。如果您大量投資於 AWS 生態系統以及基礎架構許多其他部分的基於 IAM 的驗證,則 IAM 資料庫選項可能很有吸引力。除非您已經將該服務用於其他目的,否則不值得選擇 Kerberos 選項。

設定備份、加密、監控及更多

如果您展開「其他組態」區段,您將有機會設定一些其他選項。我們將在本節中介紹這些選項。

資料庫選項

第一個其他區段允許您為 PostgreSQL 設定一些其他選項

Configure database options

如果您願意,您可以選擇讓 RDS 為您的部署自動建立初始資料庫。這通常是不必要的,因為您執行的任何遷移或其他設定腳本通常會在執行個體內建立必要的資料庫結構。

您有時也可以為您的執行個體選擇資料庫參數群組。此處的多個選項可能不可用,具體取決於您先前所做的選擇以及您是否在建立過程之外設定了參數群組。如果存在,它們允許您變更應用於此執行個體的 PostgreSQL 參數。

PostgreSQL 不支援選項群組,因此該下拉式選單將不會啟用。

備份

接下來,您可以設定與自動資料庫備份相關聯的選項

Configure backups

如果您想啟用自動備份,請選取「啟用自動備份」方塊。這將指示 AWS 自動為您的資料庫執行個體拍攝每日時間點快照,您可以使用這些快照進行還原。值得注意的是,雖然此頁面上未提及,但備份將儲存在 AWS 的 Simple Storage Service (S3) 中,並且您將需要為它們消耗的空間付費。

預設情況下,備份設定的保留期限為 7 天,這表示您將能夠還原在過去 7 天內拍攝的資料庫快照。如果您正在使用此功能,您可能需要將保留期限增加到 14 天,以便讓自己有更多時間來發現不想要的變更。但是請記住,增加保留期限將導致額外儲存空間的更高成本。

如果您對備份發生的時間有任何偏好,您可以選擇適當的時間範圍,否則,保持「無偏好」是安全的。

保持選取「將標籤複製到快照」,以便更輕鬆地在 S3 中找到適當的快照。

如果您想要額外的保護,您也可以選取「備份複寫」以自動將您的變更複寫到不同的 AWS 區域。這將允許您從不同的區域快速還原,但會增加您的 S3 儲存成本和資料傳輸成本。

加密

接下來,您可以為您的資料庫執行個體設定磁碟上的加密

Configure encryption

幾乎總是建議為您的執行個體啟用加密以獲得額外的安全性。

一般來說,您可以為此使用預設的 AWS KMS 金鑰,除非您有其他需求,例如加密到由不同 AWS 帳戶使用的金鑰。

效能分析

接下來,為您的執行個體設定效能分析

Configure performance insights

效能分析是一項功能,可協助您偵錯 RDS 執行個體中的效能問題。預設情況下,分析資料將免費保留 7 天。或者,您可以選擇 2 年的長期儲存,需額外付費,具體取決於您的 CPU 執行個體類型。

同樣地,您可以為此加密保留選取預設的 AWS KMS 金鑰,除非您有特殊需求。

監控和日誌

接下來,您可以為資料庫設定監控日誌

Configure monitoring

一般來說,啟用監控有助於您更好地了解資料庫執行個體及其效能。

至於匯出日誌,除非您需要,否則預設情況下停用它是安全的。您的應用程式日誌通常會在需要時浮現資料庫特定的資訊,但如果您覺得有幫助,您可以隨時啟用 PostgreSQL 日誌匯出。日誌將匯出到 AWS CloudWatch Logs

維護和刪除保護

維護」和「刪除保護」區段完成了其他組態

Configure maintenance

通常認為自動升級 PostgreSQL 的次要版本是安全的。次要版本不應有重大變更,並且升級應相對順暢地執行。如果您有偏好,請選取升級時段。

始終建議為您的生產資料庫啟用刪除保護。這可以防止您意外刪除資料庫執行個體,因為它要求您先還原此選項,然後才能成功處理刪除。對於大多數用例,沒有合理的理由選擇退出此選項。

完成設定

我們終於到達設定過程的尾聲。在頁面底部,您可以看到您設定的資料庫執行個體的每月費用估算值

Estimated cost

請特別注意估算值下方的文字,其中重申顯示的成本計算不包括備份儲存、IO 或資料傳輸的成本。如果沒有考慮和限制這些額外成本,它們可能會非常可觀,因此請確保您在繼續之前對額外費用的概念感到放心。

當您準備好時,按一下頁面底部的「建立資料庫

Create the database

您的資料庫執行個體將根據您的設定進行佈建。這可能需要幾分鐘才能完成,具體取決於您選擇的執行個體大小和您啟用的選項。

當您的執行個體準備就緒時,它將顯示在 RDS 儀表板的「資料庫」區段中

New database instance

檢視自動產生的密碼

如果您將 AWS 設定為自動產生密碼,您會在螢幕頂端看到類似這樣的通知

Auto generate notice

按一下檢視憑證詳細資訊以查看密碼

View password

請注意,這是您唯一一次可以存取此密碼,如果您遺失了密碼,則必須重新產生。

檢視其他連線資訊

如需其餘的連線資訊,請按一下執行個體名稱。

在「連線能力與安全性」標籤中,您可以在左側找到資料庫的端點和埠號

Endpoint and port

在此範例中,我們的端點名稱(主機的 URL)是 production-db1.cddm7tgh3j5j.us-east-1.rds.amazonaws.com,而我們的資料庫正在 PostgreSQL 的標準埠號 5432 上監聽。

若要尋找您設定的主使用者名稱(如果您沒有修改,則為 postgres),請造訪「組態」標籤,並在「可用性」標題下尋找「主使用者名稱」欄位

Master username

如果您設定了初始資料庫,您也可以在此相同標籤的左側找到其名稱。

有了這些資訊,您就可以連線到您的 PostgreSQL 執行個體。舉例來說,若要連線到此處顯示的執行個體,您可以使用以下連線 URI

postgresql://postgres:Pa38iSJWm8qtq90LnmZ8@production-db1.cddm7tgh3j5j.us-east-1.rds.amazonaws.com:5432/postgres

您可以在我們的 PostgreSQL 連線 URI 指南中,進一步了解如何從連線詳細資訊建構連線 URI。

結論

在本指南中,我們介紹了如何使用 Amazon 的 RDS 受管資料庫服務建立適用於生產環境的 PostgreSQL 資料庫執行個體。雖然有很多選項可供探索,而且您的選擇會因專案和環境的需求而異,但我們嘗試在此提供一個合理的起點,以及足夠的資訊讓您做出明智的決策。

隨著您的需求變化,請記住您可以擴展您的資料庫執行個體以適應您新的使用模式。使用您從監控資訊和擴展日誌中收集的資料,以決定您的資料庫需求如何演變。

關於作者
Justin Ellingwood

Justin Ellingwood

Justin 自 2013 年以來一直撰寫關於資料庫、Linux、基礎架構和開發人員工具的文章。他目前與妻子和兩隻兔子住在柏林。他通常不必以第三人稱寫作,這對所有相關方來說都是一種解脫。