Praktik terbaik untuk menghubungkan layanan Amazon ECS di VPC

Dengan menggunakan tugas Amazon ECS di VPC, Anda dapat membagi aplikasi monolitik menjadi beberapa 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 dihentikan, 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 pada 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, penyebaran klien memperbarui konfigurasi dengan mengganti tugas klien. Anda dapat mengonfigurasi pemutus sirkuit penyebaran dan konfigurasi penerapan lainnya untuk memengaruhi perubahan Service Connect dengan cara yang sama seperti penerapan lainnya.

Menggunakan penemuan layanan

Pendekatan lain untuk service-to-service komunikasi 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 menyelesaikan 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-loacl, yang memiliki satu wadah. Setiap kontainer di ketiga layanan ini dapat menggunakan nama DNS internal AWS Cloud Map untuk menemukan alamat IP internal kontainer dari layanan hilir yang perlu dikomunikasikan.

Pendekatan service-to-service komunikasi ini memberikan latensi rendah. Pada pandangan pertama, 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 menyelesaikan 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 itu. 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 mengonfigurasi 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 service-to-service komunikasi langsung menggunakan penemuan layanan adalah Anda harus menerapkan logika tambahan untuk mencoba ulang dan menangani kegagalan koneksi. Catatan DNS memiliki periode time-to-live (TTL) yang mengontrol berapa lama mereka di-cache. Dibutuhkan beberapa waktu agar catatan DNS diperbarui dan cache kedaluwarsa sehingga aplikasi Anda dapat mengambil versi terbaru dari catatan DNS. Jadi, aplikasi Anda mungkin akan 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 service-to-service komunikasi 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 menyebarkan sumber daya yang berlebihan ke setiap subnet. Ketika sebuah wadah dari serviceA kebutuhan untuk berkomunikasi dengan wadah dariserviceB, itu membuka koneksi ke penyeimbang beban. Penyeimbang beban kemudian membuka koneksi ke wadah dariservice B. Load balancer berfungsi sebagai tempat terpusat untuk mengelola semua koneksi antara setiap layanan.

Jika wadah serviceB berhenti, maka penyeimbang beban dapat mengeluarkan wadah itu dari kolam. Load balancer juga melakukan pemeriksaan kesehatan terhadap setiap target hilir di kolam dan secara otomatis dapat menghapus target buruk dari kolam sampai mereka menjadi sehat kembali. Aplikasi tidak perlu lagi menyadari berapa banyak kontainer 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 instance 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 Availability Zone. Ini menambah biaya tambahan karena overhead membayar 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 kontainer 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.