Modelo silo multiinquilino

Algunos entornos SaaS multiusuario pueden requerir que los datos de los inquilinos se desplieguen en recursos completamente separados debido a los requisitos normativos y de cumplimiento. En algunos casos, los grandes clientes necesitan clústeres dedicados para reducir el impacto del ruido en los vecinos. En esas situaciones, puede aplicar el modelo de silo.

En el modelo de silo, el almacenamiento de los datos de los inquilinos está completamente aislado de cualquier otro dato de los inquilinos. Todas las estructuras que se utilizan para representar los datos del arrendatario se consideran exclusivas de ese cliente desde el punto de vista físico, lo que significa que cada arrendatario, por lo general, dispondrá de un almacenamiento, una supervisión y una gestión diferenciados. Cada inquilino también tendrá una clave AWS Key Management Service (AWS KMS) independiente para el cifrado. En Amazon Neptune, un silo es un clúster por inquilino.

Clúster por inquilino

Puede implementar un modelo de silo con Neptune si tiene un inquilino por clúster. El siguiente diagrama muestra a tres inquilinos que acceden a un microservicio de aplicaciones en una nube privada virtual (VPC), con un clúster independiente para cada inquilino.

Cada clúster tiene su punto final individual para ayudar a garantizar puntos de acceso distintos para una gestión e interacción de datos eficientes. Al colocar a cada inquilino en su propio clúster, se crea un límite bien definido entre los inquilinos, lo que garantiza a los clientes que sus datos se aíslan correctamente de los datos de otros inquilinos. Este aislamiento también es atractivo para las soluciones SaaS que tienen estrictas restricciones regulatorias y de seguridad. Además, cuando cada inquilino tiene su propio clúster, no tiene que preocuparse por el ruido de un vecino, ya que uno de los inquilinos impone una carga que podría afectar negativamente a la experiencia de los demás inquilinos.

Si bien el modelo de cluster-per-tenant silos tiene ventajas, también presenta desafíos de gestión y agilidad. La naturaleza distribuida de este modelo hace que sea más difícil agregar y evaluar la actividad de los inquilinos y el estado operativo de todos los inquilinos. La implementación también se vuelve más difícil porque la configuración de un nuevo inquilino ahora requiere el aprovisionamiento de un clúster independiente. La actualización se hace más difícil en entornos con una capa de clientes compartida cuando las actualizaciones y versiones de los clientes están estrechamente vinculadas a la actualización de la base de datos.

Neptune admite clústeres aprovisionados y sin servidor. Evalúe si la carga de trabajo de su aplicación se gestiona mejor con instancias aprovisionadas o sin servidor. En general, si su carga de trabajo tiene un nivel de demanda constante, las instancias aprovisionadas serán más rentables. La tecnología Serverless está optimizada para cargas de trabajo exigentes y muy variables, con un uso intensivo de las bases de datos durante períodos cortos, seguidos de períodos prolongados de actividad ligera o nula.

Cuando utilices un clúster aprovisionado por Neptune por inquilino, debes seleccionar un tamaño de instancia que se aproxime a la carga máxima de la demanda de tu inquilino. Esta dependencia de un servidor también tiene un impacto en cascada en la eficiencia de escalado y el costo de su entorno SaaS. Si bien el objetivo del SaaS es dimensionar el tamaño de forma dinámica en función de la carga real de los inquilinos, un clúster aprovisionado por Neptune requiere un aprovisionamiento excesivo para tener en cuenta los períodos de uso más intensos y los picos de carga. El aprovisionamiento excesivo aumenta el coste por inquilino. Además, dado que el uso de los inquilinos cambia con el tiempo, la ampliación o reducción del clúster debe aplicarse por separado para cada inquilino.

El equipo de Neptune generalmente desaconseja un modelo de silo debido al mayor costo que representan los recursos inactivos y a las complejidades operativas adicionales. Sin embargo, en el caso de cargas de trabajo delicadas o muy reguladas que requieran este aislamiento adicional, los clientes podrían estar dispuestos a pagar el coste adicional.

Guía de implementación del modelo de silo

Para implementar un modelo de cluster-per-tenant aislamiento de silos, cree políticas de acceso a los datos AWS Identity and Access Management (IAM). Estas políticas controlan el acceso a los clústeres de Neptuno de los inquilinos al garantizar que los inquilinos solo puedan acceder al clúster de Neptuno que contiene sus propios datos. Adjunte la política de IAM de cada inquilino a una función de IAM. A continuación, el microservicio de la aplicación utiliza la función de IAM para generar credenciales temporales detalladas mediante el método de (). AssumeRole AWS Security Token Service AWS STS Estas credenciales, que solo tienen acceso al clúster de Neptuno de ese inquilino, se utilizan para conectarse al clúster de Neptuno del inquilino.

El siguiente fragmento de código muestra un ejemplo de política de IAM basada en datos:

{
  "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"
        }      
      }
    }
  ]
}

El código proporciona un ejemplo de inquilinotenant-1, con acceso de consulta de lectura y escritura a su respectivo clúster de Neptune. El Condition elemento garantiza que solo la entidad que realiza la llamada (la principal), que ha asumido la función de tentant-1 IAM (tenant-role-1), pueda acceder al clúster tenant-1 de Neptune.