Panduan ini menyediakan pengantar lingkungan fleksibel bagi pengguna yang sudah terbiasa dengan lingkungan standar. Dokumen ini menjelaskan persamaan dan perbedaan utama antara lingkungan dan juga memberikan rekomendasi arsitektur umum untuk aplikasi yang menggunakan kedua lingkungan tersebut.
Untuk pemetaan layanan yang tersedia di lingkungan standar ke layanan analognya di lingkungan fleksibel, lihat Memigrasikan Layanan dari Lingkungan Standar ke Lingkungan Fleksibel.
Persamaan dan perbedaan utama
Kedua lingkungan menyediakan infrastruktur deployment, penayangan, dan penskalaan App Engine. Perbedaan utamanya adalah cara lingkungan mengeksekusi aplikasi Anda, cara aplikasi Anda mengakses layanan eksternal, cara Anda menjalankan aplikasi secara lokal, dan cara aplikasi diskalakan. Anda juga dapat merujuk ke memilih lingkungan untuk ringkasan mendetail tentang perbedaan ini.
Eksekusi aplikasi
Dalam lingkungan standar, aplikasi Anda berjalan pada instance ringan di dalam sandbox. Sandbox ini membatasi hal yang dapat dilakukan aplikasi Anda. Misalnya, sandbox hanya mengizinkan aplikasi Anda menggunakan kumpulan library biner yang terbatas, dan aplikasi Anda tidak dapat menulis ke disk. Lingkungan standar juga membatasi opsi CPU dan memori yang tersedia untuk aplikasi Anda. Karena pembatasan ini, sebagian besar aplikasi standar App Engine cenderung menjadi aplikasi web stateless yang merespons permintaan HTTP dengan cepat.
Sebaliknya, lingkungan fleksibel menjalankan aplikasi Anda dalam container Docker di mesin virtual (VM) Google Compute Engine, yang batasannya lebih sedikit. Misalnya, Anda dapat menggunakan bahasa pemrograman apa pun pilihan Anda, menulis ke disk, menggunakan library apa pun yang diinginkan, dan bahkan menjalankan beberapa proses. Dengan lingkungan fleksibel, Anda juga dapat memilih jenis mesin Compute Engine apa pun untuk instance, sehingga aplikasi Anda memiliki akses ke lebih banyak memori dan CPU.
Mengakses layanan eksternal
Dalam lingkungan standar, aplikasi Anda biasanya mengakses layanan seperti Datastore melalui API google.appengine bawaan. Namun, dalam lingkungan fleksibel, API ini tidak lagi tersedia. Sebagai gantinya, gunakan library klien Google Cloud. Library klien ini berfungsi di mana saja, sehingga aplikasi Anda menjadi lebih portabel. Jika diperlukan, aplikasi yang berjalan di lingkungan fleksibel biasanya dapat berjalan di Google Kubernetes Engine atau Compute Engine tanpa modifikasi besar-besaran.
Pengembangan lokal
Dalam lingkungan standar, Anda biasanya menjalankan aplikasi secara lokal menggunakan App Engine SDK. SDK menangani pengoperasian aplikasi Anda dan mengemulasi layanan App Engine. Dalam lingkungan fleksibel, SDK tidak lagi digunakan untuk
menjalankan aplikasi Anda. Sebaliknya, aplikasi yang ditulis untuk lingkungan fleksibel harus ditulis seperti aplikasi web standar yang dapat berjalan di mana saja. Seperti yang disebutkan, lingkungan fleksibel hanya menjalankan aplikasi Anda dalam container Docker. Artinya, untuk menguji aplikasi secara lokal, Anda cukup menjalankan
aplikasi secara langsung. Misalnya, untuk menjalankan aplikasi Python menggunakan Django, Anda
hanya akan menjalankan python manage.py runserver.
Perbedaan utama lainnya adalah aplikasi lingkungan fleksibel yang berjalan secara lokal menggunakan layanan Cloud Platform yang sebenarnya, seperti Datastore. Gunakan project terpisah untuk pengujian secara lokal, dan jika tersedia, gunakan emulator.
Karakteristik penskalaan
Meskipun kedua lingkungan menggunakan infrastruktur penskalaan otomatis App Engine, cara penskalaannya berbeda. Lingkungan standar dapat melakukan penskalaan dari nol instance hingga ribuan dengan sangat cepat. Sebaliknya, lingkungan fleksibel harus memiliki setidaknya satu instance yang berjalan untuk setiap versi aktif dan memerlukan waktu lebih lama untuk diskalakan sebagai respons terhadap traffic.
Lingkungan standar menggunakan algoritma penskalaan otomatis yang dirancang khusus. Lingkungan fleksibel menggunakan Autoscaler Compute Engine. Perlu diperhatikan bahwa lingkungan fleksibel tidak mendukung semua opsi penskalaan otomatis yang tersedia untuk Compute Engine. App Engine mematuhi pemesanan VM Compute Engine yang sudah Anda miliki di region yang cocok dengan konfigurasi Anda. Memiliki reservasi VM akan meningkatkan kemungkinan Anda menerima alokasi resource selama kekurangan resource sementara.
Developer harus menguji perilaku aplikasi mereka dalam berbagai kondisi. Misalnya, Anda harus memverifikasi cara penskalaan otomatis merespons saat aplikasi yang terikat CPU menjadi terikat I/O selama periode saat panggilan ke layanan jarak jauh memiliki latensi yang lebih tinggi.
Health check
Lingkungan standar tidak menggunakan health check untuk menentukan apakah traffic dikirim ke instance atau tidak. Lingkungan fleksibel memungkinkan developer aplikasi menulis pengendali health check mereka sendiri yang akan digunakan oleh load balancer untuk menentukan apakah traffic dikirim ke sebuah instance atau tidak, dan apakah traffic tersebut harus otomatis dipulihkan. Developer harus berhati-hati saat menambahkan logika ke health check. Misalnya, jika health check melakukan panggilan ke layanan eksternal, kegagalan sementara dalam layanan tersebut dapat menyebabkan semua instance menjadi tidak responsif, dan mungkin menyebabkan kegagalan beruntun.
Melepaskan permintaan saat kelebihan beban
Aplikasi dapat membatalkan permintaan saat kelebihan beban sebagai bagian dari strategi untuk menghindari kegagalan beruntun. Kemampuan ini dibangun ke dalam lapisan perutean traffic di lingkungan standar. Sebaiknya developer aplikasi dengan QPS yang sangat tinggi di lingkungan fleksibel mem-build kemampuan ini untuk menghapus traffic overload ke aplikasi mereka dengan membatasi jumlah permintaan serentak.
Anda dapat memverifikasi bahwa aplikasi lingkungan fleksibel Anda tidak rentan terhadap kegagalan semacam ini dengan membuat versi dengan batas jumlah maksimum instance. Kemudian tingkatkan traffic secara bertahap hingga permintaan turun. Anda harus memastikan bahwa aplikasi tidak gagal dalam health check selama overload.
Untuk Java, aplikasi Java yang menggunakan Jetty runtime dapat mengonfigurasi Kualitas Filter Layanan untuk menerapkan overload pelepasan. Anda dapat menetapkan jumlah maksimum permintaan serentak yang dilayani oleh aplikasi, dan durasi waktu permintaan tersebut akan dimasukkan ke dalam antrean menggunakan fitur ini.
Ukuran instance
Instance lingkungan fleksibel diizinkan memiliki batas CPU dan memori yang lebih tinggi daripada yang dimungkinkan dengan instance lingkungan standar. Hal ini memungkinkan instance fleksibel menjalankan aplikasi yang menggunakan lebih banyak memori dan CPU. Namun, hal ini dapat meningkatkan kemungkinan bug serentak karena peningkatan thread dalam satu instance.
Developer dapat melakukan SSH ke instance lingkungan fleksibel dan mendapatkan thread dump untuk memecahkan jenis masalah ini.
Misalnya, jika menggunakan runtime Java, Anda dapat menjalankan kode berikut:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Waktu tunggu permintaan maksimum
Meskipun waktu tunggu permintaan lingkungan standar bervariasi sesuai jenis penskalaan yang dipilih, lingkungan fleksibel selalu menerapkan waktu tunggu 60 menit. Agar tidak membiarkan permintaan terbuka selama 60 menit penuh dan berpotensi menggunakan semua thread di server web:
Saat melakukan panggilan ke layanan eksternal, tentukan waktu tunggu.
Terapkan filter servlet untuk menghentikan permintaan yang memerlukan waktu lama, seperti 60 detik. Pastikan aplikasi Anda dapat kembali ke status yang konsisten setelah filter menghentikan permintaan.
Pengelolaan thread
Runtime Java lingkungan standar sebelum Java 8 hanya dapat menggunakan thread yang dibuat menggunakan SDK lingkungan standar App Engine. Developer yang mem-porting aplikasi dari runtime lingkungan standar Java generasi pertama ke lingkungan fleksibel harus beralih menggunakan library thread natif. Aplikasi yang memerlukan thread dalam jumlah besar dapat berjalan lebih efisien dengan kumpulan thread daripada pembuatan thread eksplisit.
Migrasi traffic
Lingkungan standar menyediakan fitur migrasi traffic yang secara bertahap memindahkan traffic ke versi baru untuk meminimalkan lonjakan latensi. Baca dokumen Migrasi Traffic untuk mengetahui cara memastikan Anda menghindari lonjakan latensi saat mengalihkan traffic ke versi baru.
Kegagalan satu zona
Aplikasi lingkungan standar memiliki satu rumah, yang berarti semua instance aplikasi berada di satu zona ketersediaan. Jika terjadi kegagalan di zona tersebut, aplikasi akan memulai instance baru di zona berbeda di region yang sama dan load balancer akan mengarahkan traffic ke instance baru. Anda akan melihat lonjakan latensi karena permintaan pemuatan dan juga flush Memcache.
Aplikasi lingkungan fleksibel menggunakan Grup Instance Terkelola Regional, yang berarti bahwa instance didistribusikan di beberapa zona ketersediaan dalam satu region Jika terjadi kegagalan zona tunggal, load balancer akan menghentikan pemilihan rute traffic ke zona tersebut. Jika telah menyetel penskalaan otomatis untuk menjalankan instance sesigap mungkin, Anda akan mengalami periode kelebihan beban singkat sebelum penskalaan otomatis membuat lebih banyak instance.
Perbandingan biaya
Banyak faktor yang terlibat dalam perbandingan biaya antara workload yang berjalan di lingkungan standar dan fleksibel. Fitur tersebut meliputi:
- Harga yang dibayar per MCycle.
- Kemampuan platform CPU, yang memengaruhi pekerjaan yang dapat dilakukan per MCycle
- Seberapa cepat Anda dapat menjalankan instance di setiap platform.
- Biaya deployment, yang mungkin berbeda pada setiap platform dan bisa menjadi signifikan jika Anda menggunakan Deployment Berkelanjutan untuk aplikasi.
- Beban runtime.
Anda perlu menjalankan eksperimen untuk mengetahui biaya workload di setiap platform. Dalam lingkungan fleksibel, Anda dapat menggunakan QPS per inti sebagai proxy untuk efisiensi biaya aplikasi Anda saat menjalankan eksperimen guna menentukan apakah perubahan berdampak pada biaya. Lingkungan standar tidak menyediakan mekanisme seperti itu untuk mendapatkan metrik real-time tentang efisiensi biaya aplikasi Anda. Anda harus melakukan perubahan dan menunggu siklus penagihan harian selesai.
Arsitektur
Lingkungan standar memungkinkan autentikasi yang aman antar-aplikasi menggunakan header permintaan
X-Appengine-Inbound-Appid. Lingkungan fleksibel tidak memiliki fitur tersebut. Pendekatan
yang direkomendasikan untuk autentikasi aman antar-aplikasi adalah menggunakan
OAuth.
Deployment
Deployment di lingkungan standar umumnya lebih cepat daripada deployment di lingkungan fleksibel. Lebih cepat meningkatkan skala versi yang ada di lingkungan fleksibel daripada men-deploy versi baru, karena pemrograman jaringan untuk versi baru biasanya merupakan tiang panjang dalam deployment lingkungan fleksibel. Salah satu strategi untuk melakukan rollback cepat di lingkungan fleksibel adalah dengan mempertahankan versi baik yang diketahui dan diperkecil menjadi satu instance. Anda kemudian dapat meningkatkan versi tersebut dan mengarahkan semua traffic ke versi tersebut menggunakan Pemisahan Traffic.
Kapan harus menggunakan lingkungan fleksibel
Lingkungan fleksibel dimaksudkan untuk menjadi pelengkap lingkungan standar. Jika Anda sudah memiliki aplikasi yang berjalan di lingkungan standar, biasanya Anda tidak perlu memigrasikan seluruh aplikasi ke lingkungan fleksibel. Sebagai gantinya, identifikasi bagian aplikasi yang memerlukan lebih banyak CPU, RAM yang lebih besar, library atau program pihak ketiga khusus, atau yang perlu melakukan tindakan yang tidak mungkin dilakukan di lingkungan standar. Setelah mengidentifikasi bagian-bagian tersebut dari aplikasi Anda, buat layanan App Engine kecil yang menggunakan lingkungan fleksibel untuk menangani bagian-bagian tersebut saja. Layanan yang ada dan berjalan di lingkungan standar dapat memanggil layanan lain menggunakan HTTP, Cloud Tasks, atau Cloud Pub/Sub.
Misalnya, jika Anda sudah memiliki aplikasi web yang berjalan di lingkungan standar dan ingin menambahkan fitur baru untuk mengonversi file ke PDF, Anda dapat menulis microservice terpisah yang berjalan di lingkungan fleksibel yang hanya menangani konversi ke PDF. Microservice ini dapat berupa program sederhana yang terdiri dari satu atau dua pengendali permintaan saja. Microservice ini dapat menginstal dan menggunakan program Linux yang tersedia untuk membantu konversi, seperti unoconv.
Aplikasi utama Anda tetap berada di lingkungan standar dan dapat memanggil layanan mikro ini secara langsung melalui HTTP, atau jika Anda mengantisipasi konversi akan memakan waktu lama, aplikasi dapat menggunakanTugas Cloud atau Pub/Sub untuk membuat antrean permintaan.