Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Multi-penyewaan model silo
Beberapa lingkungan SaaS multi-penyewa mungkin memerlukan data penyewa untuk digunakan pada sumber daya yang sepenuhnya terpisah karena kepatuhan dan persyaratan peraturan. Dalam beberapa kasus, pelanggan besar memerlukan cluster khusus untuk mengurangi dampak tetangga yang bising. Dalam situasi tersebut, Anda dapat menerapkan model silo.
Dalam model silo, penyimpanan data penyewa sepenuhnya terisolasi dari data penyewa lainnya. Semua konstruksi yang digunakan untuk mewakili data penyewa dianggap unik secara fisik untuk klien tersebut, yang berarti bahwa setiap penyewa umumnya akan memiliki penyimpanan, pemantauan, dan manajemen yang berbeda. Setiap penyewa juga akan memiliki kunci AWS Key Management Service (AWS KMS) terpisah untuk enkripsi. Di Amazon Neptunus, silo adalah satu cluster per penyewa.
Cluster per penyewa
Anda dapat menerapkan model silo dengan Neptunus dengan memiliki satu penyewa per cluster. Diagram berikut menunjukkan tiga penyewa mengakses layanan mikro aplikasi di cloud pribadi virtual (VPC), dengan cluster terpisah untuk setiap penyewa.

Setiap cluster memiliki titik akhir masing-masing untuk membantu memastikan titik akses yang berbeda untuk interaksi dan manajemen data yang efisien. Dengan menempatkan setiap penyewa di klaster sendiri, Anda membuat batas yang terdefinisi dengan baik antara penyewa yang memastikan pelanggan bahwa data mereka berhasil diisolasi dari data penyewa lain. Isolasi ini juga menarik bagi solusi SaaS yang memiliki batasan peraturan dan keamanan yang ketat. Selain itu, ketika setiap penyewa memiliki cluster sendiri Anda tidak perlu khawatir tentang tetangga yang berisik, di mana satu penyewa memaksakan beban yang dapat mempengaruhi pengalaman penyewa lainnya.
Sementara model cluster-per-tenant silo memiliki kelebihan, ia juga memperkenalkan tantangan manajemen dan kelincahan. Sifat terdistribusi dari model ini membuat lebih sulit untuk mengumpulkan dan menilai aktivitas penyewa dan kesehatan operasional di semua penyewa. Penerapan juga menjadi lebih menantang karena menyiapkan penyewa baru sekarang memerlukan penyediaan cluster terpisah. Upgrade menjadi lebih menantang di lingkungan dengan lapisan klien bersama ketika upgrade klien dan versi digabungkan erat ke upgrade database.
Neptunus mendukung cluster tanpa server dan yang disediakan. Menilai apakah beban kerja aplikasi Anda ditangani dengan lebih baik oleh instans tanpa server atau yang disediakan. Secara umum, jika beban kerja Anda memiliki tingkat permintaan yang konstan, instance yang disediakan akan lebih hemat biaya. Tanpa server dioptimalkan untuk beban kerja yang sangat bervariasi dan menuntut dengan penggunaan database yang berat untuk waktu yang singkat diikuti oleh periode aktivitas ringan yang lama atau tidak ada aktivitas.
Saat menggunakan cluster yang disediakan Neptunus per penyewa, Anda harus memilih ukuran instans yang mendekati beban maksimum permintaan penyewa Anda. Ketergantungan pada server ini juga memiliki dampak cascading pada efisiensi penskalaan dan biaya lingkungan SaaS Anda. Sementara tujuan SaaS adalah untuk mengukur secara dinamis berdasarkan beban penyewa yang sebenarnya, kluster yang disediakan Neptunus mengharuskan Anda melakukan penyediaan berlebihan untuk memperhitungkan periode penggunaan yang lebih berat dan lonjakan beban. Penyediaan berlebih meningkatkan biaya per penyewa. Selain itu, karena penggunaan penyewa berubah seiring waktu, penskalaan atau penskalaan cluster harus diterapkan secara terpisah untuk setiap penyewa.
Tim Neptunus umumnya menyarankan untuk tidak menggunakan model silo karena biaya yang lebih tinggi yang dikeluarkan oleh sumber daya yang menganggur dan kompleksitas operasional tambahan. Namun, untuk beban kerja yang sangat diatur atau sensitif memerlukan isolasi tambahan ini, pelanggan mungkin bersedia membayar biaya tambahan.
Panduan implementasi untuk model silo
Untuk menerapkan model cluster-per-tenant isolasi silo, buat kebijakan akses data AWS Identity and Access Management (IAM). Kebijakan ini mengontrol akses ke cluster Neptunus penyewa dengan memastikan bahwa penyewa hanya dapat mengakses cluster Neptunus yang berisi data mereka sendiri. Lampirkan kebijakan IAM untuk setiap penyewa ke peran IAM. Layanan mikro aplikasi kemudian menggunakan peran IAM untuk menghasilkan kredensil sementara berbutir halus menggunakan metode (). AssumeRole
AWS Security Token Service AWS STS Kredensil ini, yang hanya memiliki akses ke cluster Neptunus untuk penyewa itu, digunakan untuk terhubung ke cluster Neptunus penyewa.
Cuplikan kode berikut menunjukkan contoh kebijakan IAM berbasis data:
{ "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" } } } ] }
Kode ini menyediakan penyewa sampel,tenant-1
, dengan akses kueri baca dan tulis ke cluster Neptunus masing-masing. Condition
Elemen memastikan bahwa hanya entitas pemanggil (prinsipal), yang telah mengambil peran tentant-1
IAM (tenant-role-1
), diizinkan untuk mengakses cluster tenant-1
Neptunus.