本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Silo 模型多租用戶
由於合規和法規要求,某些多租戶 SaaS 環境可能需要將租戶的資料部署在完全分開的資源上。在某些情況下,大型客戶需要專用叢集,以減少雜訊鄰近環境的影響。在這些情況下,您可以套用孤立模型。
在孤島模型中,租用戶資料的儲存與任何其他租用戶資料完全隔離。用於代表租用戶資料的所有建構都被視為該用戶端的實際唯一,這表示每個租用戶通常都有不同的儲存、監控和管理。每個租用戶也會有用於加密的個別 AWS Key Management Service (AWS KMS) 金鑰。在 Amazon Neptune 中,孤立是每個租用戶一個叢集。
每個租用戶的叢集
您可以使用 Neptune 實作孤立模型,方法是每個叢集有一個租用戶。下圖顯示三個租用戶在虛擬私有雲端 (VPC) 中存取應用程式微服務,每個租用戶各有一個叢集。

每個叢集都有其個別端點,以協助確保不同的存取點,以進行有效率的資料互動和管理。透過將每個租用戶放在自己的叢集中,您可以在租用戶之間建立明確定義的界限,以確保客戶的資料與其他租用戶的資料成功隔離。此隔離對於具有嚴格法規和安全限制的 SaaS 解決方案也很有吸引力。此外,當每個租用戶都有自己的叢集時,您不必擔心雜訊鄰近,其中一個租用戶施加的負載可能會對其他租用戶的體驗產生負面影響。
雖然cluster-per-tenant孤島模型具有優勢,但它也會帶來管理和敏捷性挑戰。此模型的分散式性質使彙整和評估租戶活動以及所有租戶的操作運作狀態變得更加困難。部署也會變得更具挑戰性,因為設定新租用戶現在需要佈建個別的叢集。當用戶端升級和版本與資料庫升級緊密結合時,在具有共用用戶端層的環境中升級變得更具挑戰性。
Neptune 同時支援無伺服器和佈建叢集。評估無伺服器或佈建執行個體是否更能處理您的應用程式工作負載。一般而言,如果您的工作負載具有持續的需求層級,則佈建的執行個體將更具成本效益。Serverless 已針對高需求、高度可變的工作負載進行最佳化,其資料庫使用量很短,接著是長時間的輕度活動或沒有活動。
每個租用戶使用 Neptune 佈建叢集時,您必須選取近似租用戶需求最大負載的執行個體大小。這種對伺服器的依賴也會對 SaaS 環境的擴展效率和成本產生層疊影響。雖然 SaaS 的目標是根據實際租用戶負載動態調整大小,但 Neptune 佈建叢集需要您過度佈建,以考慮負載中的大量用量和尖峰期間。過度佈建會增加每個租用戶的成本。此外,隨著租用戶用量隨時間的變化,必須針對每個租用戶個別套用擴展或縮減叢集。
Neptune 團隊通常會針對孤立模型提供建議,因為閒置資源所產生的成本較高,且具有額外的操作複雜性。不過,對於受到高度管制或敏感的工作負載,客戶可能會願意支付額外的成本。
孤立模型的實作指引
若要實作cluster-per-tenant孤立隔離模型,請建立 AWS Identity and Access Management (IAM) 資料存取政策。這些政策透過確保租用戶只能存取包含自己的資料的 Neptune 叢集,來控制對租用戶 Neptune 叢集的存取。將每個租用戶的 IAM 政策連接至 IAM 角色。然後,應用程式微服務會使用 IAM 角色,使用 AWS Security Token Service () AssumeRole
方法產生精細的臨時登入資料AWS STS。這些登入資料只能存取該租用戶的 Neptune 叢集,用於連線至租用戶的 Neptune 叢集。
下列程式碼片段顯示以資料為基礎的 IAM 政策範例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "neptune-db:ReadDataViaQuery", "neptune-db:WriteDataViaQuery" ], "Resource": "arn:aws:neptune-db:us-east-1:123456789012:tenant-1-cluster/*", "Condition": { "ArnEquals": { "aws:PrincipalArn": "arn:aws:iam::123456789012:role/tenant-role-1" } } } ] }
此程式碼提供範例租用戶 tenant-1
,具有各自 Neptune 叢集的讀取和寫入查詢存取權。Condition
元素可確保只有擔任 IAM tentant-1
角色 () 的呼叫實體 (委託人tenant-role-1
) 才能存取 tenant-1
的 Neptune 叢集。