사일로 모델 다중 테넌시

일부 다중 테넌트 SaaS 환경에서는 규정 준수 및 규제 요구 사항으로 인해 테넌트의 데이터를 완전히 분리된 리소스에 배포해야 할 수 있습니다. 경우에 따라 대규모 고객에게는 시끄러운 이웃 영향을 줄이기 위한 전용 클러스터가 필요합니다. 이러한 상황에서는 사일로 모델을 적용할 수 있습니다.

사일로 모델에서 테넌트 데이터의 스토리지는 다른 테넌트 데이터와 완전히 격리됩니다. 테넌트의 데이터를 나타내는 데 사용되는 모든 구문은 해당 클라이언트에 대해 물리적으로 고유한 것으로 간주됩니다. 즉, 각 테넌트는 일반적으로 고유한 스토리지, 모니터링 및 관리를 갖게 됩니다. 또한 각 테넌트에는 암호화를 위한 별도의 AWS Key Management Service (AWS KMS) 키가 있습니다. Amazon Neptune에서 사일로는 테넌트당 하나의 클러스터입니다.

테넌트당 클러스터

클러스터당 하나의 테넌트를 보유하여 Neptune으로 사일로 모델을 구현할 수 있습니다. 다음 다이어그램은 각 테넌트에 대해 별도의 클러스터가 있는 Virtual Private Cloud(VPC)에서 애플리케이션 마이크로서비스에 액세스하는 세 개의 테넌트를 보여줍니다.

각 클러스터에는 효율적인 데이터 상호 작용 및 관리를 위해 고유한 액세스 포인트를 보장하는 데 도움이 되는 개별 엔드포인트가 있습니다. 각 테넌트를 자체 클러스터에 배치하면 테넌트 간에 잘 정의된 경계를 생성하여 고객이 다른 테넌트의 데이터와 데이터를 성공적으로 격리할 수 있도록 합니다. 이 격리는 엄격한 규제 및 보안 제약이 있는 SaaS 솔루션에도 유용합니다. 또한 각 테넌트에 자체 클러스터가 있는 경우 한 테넌트가 다른 테넌트의 경험에 부정적인 영향을 미칠 수 있는 부하를 부과하는 시끄러운 이웃에 대해 걱정할 필요가 없습니다.

cluster-per-tenant 사일로 모델에는 장점이 있지만 관리 및 민첩성 문제도 발생합니다. 이 모델의 분산 특성으로 인해 테넌트 활동 및 모든 테넌트의 운영 상태를 집계하고 평가하기가 더 어렵습니다. 이제 새 테넌트를 설정하려면 별도의 클러스터를 프로비저닝해야 하므로 배포도 더 어려워집니다. 클라이언트 업그레이드 및 버전이 데이터베이스 업그레이드와 긴밀하게 결합되면 공유 클라이언트 계층이 있는 환경에서 업그레이드가 더 어려워집니다.

Neptune은 서버리스 클러스터와 프로비저닝된 클러스터를 모두 지원합니다. 서버리스 또는 프로비저닝된 인스턴스에서 애플리케이션 워크로드를 더 잘 처리할 수 있는지 평가합니다. 일반적으로 워크로드의 수요 수준이 일정하면 프로비저닝된 인스턴스가 더 비용 효율적입니다. 서버리스는 짧은 기간 동안 데이터베이스 사용량이 많고 장시간 가벼운 활동이 있거나 활동이 없는 까다롭고 가변적인 워크로드에 최적화되어 있습니다.

테넌트당 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 요소는 tentant-1 IAM 역할()을 수임한 호출 엔터티(보안 주체tenant-role-1)만 tenant-1의 Neptune 클러스터에 액세스할 수 있도록 합니다.