Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Praktik terbaik untuk menghubungkan layanan Amazon ECS di VPC
Menggunakan tugas Amazon ECS di VPC, Anda dapat membagi aplikasi monolitik menjadi bagian-bagian terpisah yang dapat digunakan dan diskalakan secara independen di lingkungan yang aman. Arsitektur ini disebut arsitektur berorientasi layanan (SOA) atau layanan mikro. Namun, mungkin sulit untuk memastikan bahwa semua bagian ini, baik di dalam maupun di luar VPC, dapat berkomunikasi satu sama lain. Ada beberapa pendekatan untuk memfasilitasi komunikasi, semuanya dengan kelebihan dan kekurangan yang berbeda.
Menggunakan Service Connect
Kami merekomendasikan Service Connect, yang menyediakan konfigurasi Amazon ECS untuk penemuan layanan, konektivitas, dan pemantauan lalu lintas. Dengan Service Connect, aplikasi Anda dapat menggunakan nama pendek dan port standar untuk terhubung ke layanan di cluster yang sama, cluster lain, termasuk di seluruh VPC di Wilayah yang sama. Untuk informasi selengkapnya, lihat Amazon ECS Service Connect.
Saat Anda menggunakan Service Connect, Amazon ECS mengelola semua bagian penemuan layanan: membuat nama yang dapat ditemukan, mengelola entri secara dinamis untuk setiap tugas saat tugas dimulai dan berhenti, menjalankan agen di setiap tugas yang dikonfigurasi untuk menemukan nama. Aplikasi Anda dapat mencari nama dengan menggunakan fungsionalitas standar untuk nama DNS dan membuat koneksi. Jika aplikasi Anda sudah melakukan ini, Anda tidak perlu memodifikasi aplikasi Anda untuk menggunakan Service Connect.
Perubahan hanya terjadi selama penerapan
Anda menyediakan konfigurasi lengkap di dalam setiap layanan dan definisi tugas. Amazon ECS mengelola perubahan konfigurasi ini di setiap penyebaran layanan, untuk memastikan bahwa semua tugas dalam penerapan berperilaku dengan cara yang sama. Misalnya, masalah umum dengan DNS sebagai penemuan layanan adalah mengendalikan migrasi. Jika Anda mengubah nama DNS untuk menunjuk ke alamat IP pengganti baru, mungkin diperlukan waktu TTL maksimum sebelum semua klien mulai menggunakan layanan baru. Dengan Service Connect, penerapan klien memperbarui konfigurasi dengan mengganti tugas klien. Anda dapat mengonfigurasi pemutus sirkuit penerapan dan konfigurasi penerapan lainnya untuk memengaruhi perubahan Service Connect dengan cara yang sama seperti penerapan lainnya.
Menggunakan penemuan layanan
Pendekatan lain untuk komunikasi layanan-ke-layanan adalah komunikasi langsung menggunakan penemuan layanan. Dalam pendekatan ini, Anda dapat menggunakan integrasi penemuan AWS Cloud Map layanan dengan Amazon ECS. Menggunakan penemuan layanan, Amazon ECS menyinkronkan daftar tugas yang diluncurkan ke AWS Cloud Map, yang mempertahankan nama host DNS yang diselesaikan ke alamat IP internal dari satu atau lebih tugas dari layanan tertentu. Layanan lain di Amazon VPC dapat menggunakan nama host DNS ini untuk mengirim lalu lintas langsung ke wadah lain menggunakan alamat IP internalnya. Untuk informasi selengkapnya, lihat Penemuan Layanan.
Dalam diagram sebelumnya, ada tiga layanan. service-a-localmemiliki satu wadah dan berkomunikasi denganservice-b-local, yang memiliki dua wadah. service-b-localjuga harus berkomunikasi denganservice-c-local, yang memiliki satu wadah. Setiap wadah di ketiga layanan ini dapat menggunakan nama DNS internal dari AWS Cloud Map untuk menemukan alamat IP internal wadah dari layanan hilir yang perlu dikomunikasikan.
Pendekatan komunikasi layanan-ke-layanan ini memberikan latensi rendah. Sekilas, ini juga sederhana karena tidak ada komponen tambahan di antara wadah. Lalu lintas bergerak langsung dari satu kontainer ke kontainer lainnya.
Pendekatan ini cocok saat menggunakan mode awsvpc jaringan, di mana setiap tugas memiliki alamat IP uniknya sendiri. Sebagian besar perangkat lunak hanya mendukung penggunaan A catatan DNS, yang diselesaikan langsung ke alamat IP. Saat menggunakan mode awsvpc jaringan, alamat IP untuk setiap tugas adalah A catatan. Namun, jika Anda menggunakan mode bridge jaringan, beberapa kontainer dapat berbagi alamat IP yang sama. Selain itu, pemetaan port dinamis menyebabkan kontainer diberi nomor port secara acak pada alamat IP tunggal tersebut. Pada titik ini, A catatan tidak lagi cukup untuk penemuan layanan. Anda juga harus menggunakan SRV catatan. Jenis catatan ini dapat melacak alamat IP dan nomor port tetapi mengharuskan Anda mengkonfigurasi aplikasi dengan tepat. Beberapa aplikasi bawaan yang Anda gunakan mungkin tidak mendukung SRV catatan.
Keuntungan lain dari mode awsvpc jaringan adalah Anda memiliki grup keamanan unik untuk setiap layanan. Anda dapat mengonfigurasi grup keamanan ini untuk mengizinkan koneksi masuk hanya dari layanan hulu tertentu yang perlu berbicara dengan layanan tersebut.
Kerugian utama dari komunikasi layanan-ke-layanan langsung menggunakan penemuan layanan adalah bahwa Anda harus menerapkan logika tambahan untuk mencoba ulang dan menangani kegagalan koneksi. Catatan DNS memiliki periode time-to-live (TTL) yang mengontrol berapa lama data tersebut di-cache. Diperlukan beberapa waktu agar catatan DNS diperbarui dan cache kedaluwarsa sehingga aplikasi Anda dapat mengambil versi terbaru dari catatan DNS. Jadi, aplikasi Anda mungkin akhirnya menyelesaikan catatan DNS untuk menunjuk ke wadah lain yang sudah tidak ada lagi. Aplikasi Anda perlu menangani percobaan ulang dan memiliki logika untuk mengabaikan backend yang buruk.
Menggunakan penyeimbang beban internal
Pendekatan lain untuk komunikasi layanan-ke-layanan adalah dengan menggunakan penyeimbang beban internal. Penyeimbang beban internal ada sepenuhnya di dalam VPC Anda dan hanya dapat diakses oleh layanan di dalam VPC Anda.
Penyeimbang beban mempertahankan ketersediaan tinggi dengan menerapkan sumber daya redundan ke setiap subnet. Ketika sebuah wadah dari serviceA perlu berkomunikasi dengan wadah dariserviceB, itu membuka koneksi ke penyeimbang beban. Penyeimbang beban kemudian membuka koneksi ke wadah dariservice B. Penyeimbang beban berfungsi sebagai tempat terpusat untuk mengelola semua koneksi antara setiap layanan.
Jika wadah serviceB berhenti, maka penyeimbang beban dapat mengeluarkan wadah itu dari kolam. Penyeimbang beban juga melakukan pemeriksaan kesehatan terhadap setiap target hilir di kumpulannya dan secara otomatis dapat menghapus target buruk dari kolam sampai mereka menjadi sehat kembali. Aplikasi tidak perlu lagi menyadari berapa banyak wadah hilir yang ada. Mereka hanya membuka koneksi mereka ke penyeimbang beban.
Pendekatan ini menguntungkan untuk semua mode jaringan. Penyeimbang beban dapat melacak alamat IP tugas saat menggunakan mode awsvpc jaringan, serta kombinasi alamat IP dan port yang lebih canggih saat menggunakan mode bridge jaringan. Ini mendistribusikan lalu lintas secara merata di semua alamat IP dan kombinasi port, bahkan jika beberapa kontainer benar-benar di-host pada instans Amazon EC2 yang sama, hanya pada port yang berbeda.
Salah satu kelemahan dari pendekatan ini adalah biaya. Agar sangat tersedia, penyeimbang beban harus memiliki sumber daya di setiap Zona Ketersediaan. Ini menambah biaya tambahan karena biaya overhead untuk penyeimbang beban dan untuk jumlah lalu lintas yang melewati penyeimbang beban.
Namun, Anda dapat mengurangi biaya overhead dengan memiliki beberapa layanan berbagi penyeimbang beban. Ini sangat cocok untuk layanan REST yang menggunakan Application Load Balancer. Anda dapat membuat aturan perutean berbasis jalur yang merutekan lalu lintas ke layanan yang berbeda. Misalnya, /api/user/* mungkin merutekan ke wadah yang merupakan bagian dari user layanan, sedangkan /api/order/* mungkin merutekan ke order layanan terkait. Dengan pendekatan ini, Anda hanya membayar satu Application Load Balancer, dan memiliki satu URL yang konsisten untuk API Anda. Namun, Anda dapat membagi lalu lintas ke berbagai layanan mikro di backend.
