Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mendukung penskalaan dinamis untuk aplikasi.NET Framework statis
## Ikhtisar
Salah satu manfaat utama menggunakan cloud untuk aplikasi adalah elastisitas, atau kemampuan untuk menskalakan komputasi masuk atau keluar berdasarkan permintaan. Ini memungkinkan Anda untuk hanya membayar kapasitas komputasi yang Anda butuhkan, daripada menyediakan untuk penggunaan puncak. Cyber Monday, di mana pengecer online dapat dengan cepat mendapatkan lalu lintas berkali-kali lebih banyak dari biasanya (misalnya, [ribuan persen dalam beberapa menit](https://aws.amazon.com/blogs/startups/how-clicktale-uses-aws-to-power-a-successful-cyber-monday/)), adalah contoh elastisitas yang baik.
Jika Anda membawa aplikasi web.NET lama ke cloud (misalnya, aplikasi ASP.NET Framework yang berjalan pada IIS), kemampuan untuk dengan cepat menskalakan beban peternakan server yang seimbang mungkin sulit atau tidak mungkin karena sifat aplikasi yang stateful. Data sesi pengguna disimpan dalam memori aplikasi, biasanya dengan [status sesi ASP.NET](https://learn.microsoft.com/en-us/previous-versions/aspnet/ms178581(v=vs.100)) atau variabel statis yang menyimpan data permintaan silang yang harus dipertahankan. Afinitas sesi pengguna biasanya dipertahankan melalui sesi lengket penyeimbang beban.
Ini terbukti menantang secara operasional. Ketika peningkatan kapasitas diperlukan, Anda harus dengan sengaja menyediakan dan menambahkan server. Ini bisa menjadi proses yang lambat. Mengambil node keluar dari layanan jika terjadi penambalan atau kegagalan yang tidak terduga dapat menjadi masalah bagi pengalaman pengguna akhir, kehilangan status untuk semua pengguna yang terkait dengan node yang terpengaruh. Paling-paling, ini akan mengharuskan pengguna untuk masuk lagi.
Dengan memusatkan status sesi untuk aplikasi ASP.NET dan menerapkan aturan penskalaan otomatis ke aplikasi ASP.NET lama, Anda dapat memanfaatkan elastisitas cloud dan berpotensi memanfaatkan penghematan biaya saat menjalankan aplikasi. Misalnya, Anda mendapatkan pengurangan biaya melalui skalabilitas komputasi, tetapi Anda juga dapat memilih dari berbagai model harga yang tersedia, seperti mengurangi [penggunaan instans cadangan](https://aws.amazon.com/ec2/pricing/reserved-instances/) dan menggunakan harga Instans [Spot Amazon](https://aws.amazon.com/ec2/spot/).
Dua teknik umum termasuk menggunakan [Amazon DynamoDB sebagai penyedia status sesi](https://github.com/aws/aws-dotnet-session-provider) dan menggunakan [ ElastiCache Amazon (Redis OSS)](https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/) sebagai penyimpanan sesi ASP.NET.
Diagram berikut menunjukkan arsitektur yang menggunakan DynamoDB sebagai penyedia status sesi.
Diagram berikut menunjukkan arsitektur yang menggunakan ElastiCache (Redis OSS) sebagai penyedia status sesi.
## Dampak biaya
Untuk menentukan manfaat penskalaan untuk aplikasi produksi, kami menyarankan Anda memodelkan permintaan Anda yang sebenarnya. Bagian ini membuat asumsi berikut untuk memodelkan aplikasi sampel:
+ Contoh yang ditambahkan dan dihapus dari rotasi identik dan tidak ada variasi ukuran instance yang diperkenalkan.
+ Pemanfaatan server tidak pernah turun di bawah dua server aktif untuk menjaga ketersediaan aplikasi yang tinggi.
+ Jumlah server berskala linier dengan lalu lintas (yaitu, lalu lintas dua kali lebih banyak akan membutuhkan komputasi dua kali lebih banyak).
+ Lalu lintas dimodelkan selama sebulan dalam peningkatan enam jam, dengan variasi intra-hari dan satu puncak lalu lintas abnormal (misalnya, penjualan promosi) untuk satu hari lalu lintas 10x. Lalu lintas akhir pekan dimodelkan pada pemanfaatan dasar.
+ Lalu lintas malam hari dimodelkan pada pemanfaatan dasar, sementara lalu lintas hari kerja dimodelkan pada pemanfaatan 4x.
+ Harga Instans Cadangan menggunakan harga satu tahun tanpa dimuka. Harga siang hari normal menggunakan harga sesuai permintaan sementara permintaan burst menggunakan harga Instans Spot.
Diagram berikut menggambarkan bagaimana model ini memanfaatkan elastisitas dalam aplikasi.NET daripada penyediaan untuk penggunaan puncak. Ini menghasilkan penghematan sekitar 68 persen.
Jika Anda menggunakan DynamoDB sebagai mekanisme penyimpanan status sesi, maka gunakan parameter berikut:
```
Storage: 20GB
Session Reads: 40 million
Session Writes: 20 million
Pricing Model: On demand
```
Perkiraan biaya bulanan untuk layanan ini adalah sekitar $35,00 per bulan.
Jika Anda menggunakan ElastiCache (Redis OSS) sebagai mekanisme penyimpanan status sesi, maka gunakan parameter berikut:
```
Number of Nodes: 3
Node size: cache.t4g.medium
Pricing Model: 1y reserved
```
Perkiraan biaya bulanan untuk layanan ini adalah sekitar $91,00 per bulan.
## Rekomendasi optimisasi biaya
Langkah pertama adalah mengimplementasikan status sesi dalam aplikasi.NET lama. Jika Anda menggunakan ElastiCache sebagai mekanisme penyimpanan status Anda, ikuti panduan dari [ElastiCache sebagai ASP.NET Session Store](https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/) di Blog Alat AWS Pengembang. Jika Anda menggunakan DynamoDB, ikuti panduan [dari Apa yang ada AWS SDK untuk .NET di dokumentasi](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/welcome.html). SDK untuk .NET
Jika aplikasi menggunakan **InProc**sesi untuk memulai, pastikan bahwa semua objek yang Anda rencanakan untuk disimpan dalam sesi dapat diserialkan. Untuk melakukan ini, gunakan `SerializableAttribute` atribut untuk menghias kelas yang instance akan disimpan dalam sesi. Contoh:
```
[Serializable()]
public class TestSimpleObject {
public string SessionProperty {get;set;}
}
```
Selain itu, .NET `MachineKey` harus sama antara semua server yang digunakan. Ini biasanya terjadi ketika instance dibuat dari Amazon Machine Image (AMI) yang umum. Contoh:
```
```
Namun, penting untuk memastikan bahwa jika gambar dasar diubah, itu dikonfigurasi dengan image mesin.NET yang sama (dapat dikonfigurasi pada tingkat IIS atau server). Untuk informasi lebih lanjut, lihat [SystemWebSectionGroup. MachineKey ](https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.systemwebsectiongroup.machinekey?view=netframework-4.8.1)Properti dalam dokumentasi Microsoft.
Terakhir, Anda harus menentukan mekanisme untuk menambahkan server ke grup Auto Scaling sebagai respons terhadap peristiwa penskalaan. Ada beberapa cara untuk mencapai ini. Kami merekomendasikan metode berikut untuk menerapkan aplikasi.NET Framework dengan mulus ke instans EC2 dalam grup Auto Scaling:
+ Gunakan [EC2 Image](https://aws.amazon.com/image-builder/) Builder untuk mengonfigurasi AMI yang berisi server dan aplikasi yang sepenuhnya dikonfigurasi. Anda kemudian dapat menggunakan AMI ini untuk mengonfigurasi [template peluncuran grup Auto Scaling Anda](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html).
+ Gunakan [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)untuk menyebarkan aplikasi Anda. CodeDeploy memungkinkan integrasi langsung dengan [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws-auto-scaling.html). Ini memberikan alternatif untuk membuat AMI baru untuk setiap rilis aplikasi.
## Sumber daya tambahan
+ [Membuat gambar dengan EC2 Image Builder (dokumentasi EC2 Image](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-images.html) Builder)
+ [Menyebarkan Aplikasi Web .NET Menggunakan AWS CodeDeploy Layanan Tim Visual Studio](https://aws.amazon.com/blogs/developer/deploying-net-web-applications-using-aws-codedeploy-with-visual-studio-team-services/) (Blog Alat AWS Pengembang)