Rangkaian layanan web Amazon yang luas terus berkembang, memperluas penawarannya yang sudah komprehensif untuk semua jenis solusi web. Sementara pangsa pasarnya melanjutkan dominasinya (hampir tiga kali lipat dari Microsoft, Google, atau IBM) karena semua jenis solusi web memanfaatkan Layanan Web Amazon untuk sukses besar. Para pemimpin di bidang teknologi, mulai dari Netflix dan Airbnb, hingga NASA, Intuit, dan Spotify semuanya menggunakan platform cloud Amazon. Ketika ditugaskan untuk membangun solusi web baru, keuntungan dan kerugian harus selalu dievaluasi berdasarkan kasus per kasus, namun semakin sulit untuk menyangkal manfaat luar biasa dari penggunaan Layanan Web Amazon.
Menggunakan layanan Amazon untuk beberapa waktu sekarang, saya merasa sudah waktunya untuk menguji pengetahuan saya dengan Sertifikasi Arsitek Solusi Layanan Web Amazon. Hal ini memerlukan peningkatan pada sejumlah layanan AWS, mulai dari kontainer pribadi virtual, grup keamanan, tabel perutean dan subnetting, hingga kebijakan pemodelan dan partisi data Dynamo. Untuk menyimpulkan studi ini dan paling baik memvalidasi pemahaman saya tentang semua Layanan Web Amazon ini, saya mengumpulkan solusi web tumpukan cepat dan kotor yang menggabungkan sebanyak mungkin penawaran Amazon yang dapat saya sesuaikan.
Di sini, saya ingin membahas teknologi dan langkah-langkah untuk membangun solusi web Anda berikutnya di AWS. Dalam upaya untuk tetap fokus, ini akan diarahkan untuk membangun aplikasi klien React/Redux, Node/Express REST API, dan kemudian arsitektur AWS untuk hosting dan menyambungkan semuanya dengan cara yang aman dan dapat diskalakan, otomatis dengan Terraform HashiCorp (lihat juga CloudFormation). Dengan banyaknya sumber daya di luar sana yang merinci bagian-bagian tertentu, di sini kami akan mencoba menjembatani celah untuk menyatukan semuanya!
Membangun Front-End
Lapisan tampilan deklaratif, berbasis komponen, dan berperforma tinggi di React, bersama dengan Redux untuk manajemen negara dan mengelola kompleksitas asinkron, akan memungkinkan kami membuat pengalaman cepat bagi pengguna akhir kami. Kombo satu-dua ini telah menjadi salah satu kemajuan favorit saya di dunia front-end yang bergerak cepat baru-baru ini.
Aplikasi klien terdiri dari JavaScript statis, HTML, dan CSS yang dibundel bersama dengan Webpack dan dirender dalam browser web klien. Menggunakan React dan Redux, aplikasi klien menangani perutean, pembaruan optimis dengan backend kami, dan merender pembaruan konten di DOM secara efisien.
Kami menggunakan middleware Redux Thunk untuk mengelola permintaan HTTP asinkron ke API backend kami dengan cara yang dapat disusun. (Dalam posting mendatang saya akan menulis mengapa saya semakin menikmati penggunaan Redux Saga dan Redux Loop daripada thunks).
Membangun Back-End
Back-end adalah REST API yang bertanggung jawab untuk menangani permintaan HTTP dari front-end kami dan berkomunikasi dengan layanan Amazon terkelola kami (mis. SQS, Dynamo, RDS). Itu dapat diperluas untuk mengautentikasi dan mengintegrasikan dengan aplikasi seluler yang dibuat khusus atau juga layanan pihak ketiga lainnya.
Node.js dipilih untuk back-end karena kecepatan pengembangan dan kinerjanya luar biasa. Ini semakin menjadi tujuan industri untuk membangun REST API, dan meskipun Anda mungkin menemukan tolok ukur yang menceritakan cerita mana pun yang Anda suka (bergantung pada perpustakaan, bagaimana perangkat lunak dibuat, dll), saya terus terkesan dengan kinerja yang dicapai oleh Node dengan waktu pengembangan dan perangkat keras yang relatif minimal. Dasar-dasar I/O non-pemblokiran Node yang digerakkan oleh peristiwa, dan ekosistem perpustakaan sumber terbuka NPM yang luas, bersama dengan kemajuan merajalela Google dengan mesin V8 mereka, menjadikannya pilihan teknologi yang hebat.
Express adalah framework server standar de facto untuk Node.js, meskipun ada sejumlah pemain lain yang perlu dipertimbangkan. Express akan menangani perutean, penguraian, dan negosiasi permintaan kami.
Pengaturan dan Keamanan Lingkungan AWS
Dengan aplikasi kami yang dibuat, inilah saatnya untuk mulai mendalami AWS. Beberapa prinsip yang harus kita ingat: ketersediaan tinggi, skalabilitas/kinerja, dan keamanan. Untungnya Amazon akan menangani banyak hal ini untuk kami jika arsitektur kami disiapkan dengan benar!
Pertama dan terpenting kita perlu mengatur Virtual Private Cloud kita. Jika Anda telah menggunakan AWS sejak 2013, kemungkinan besar Anda telah menggunakan AWS VPC. VPC menyediakan lingkungan terisolasi yang aman untuk aplikasi kami dengan kontrol penuh atas rentang alamat IP internal, subnet, dan akses jaringan, serupa dengan jaringan lokal tradisional.
Di dalam VPC kami membuat subnet, atau rentang alamat IP yang dilambangkan dengan blok CIDR. Meskipun VPC mencakup beberapa zona ketersediaan, setiap subnet berada dalam satu zona ketersediaan, jadi kami ingin memastikan bahwa kami menyiapkan beberapa subnet untuk mempertahankan ketersediaan tinggi jika terjadi bencana.
Kami juga memerlukan banyak subnet, publik dan pribadi, agar sesuai dengan praktik keamanan terbaik. Subnet publik kami akan dapat diakses dari internet publik melalui AWS Network Gateway, sedangkan subnet pribadi kami akan dikunci tanpa akses dari internet, meskipun kami masih dapat mengizinkan akses internet keluar melalui NAT untuk pembaruan perangkat lunak, dll. NAT tersedia baik melalui AMI yang dihosting melalui instans EC2 atau melalui layanan gateway AWS NAT. Gateway NAT yang dikelola akan memberi Anda ketersediaan tinggi dan redundansi gratis sedangkan AMI akan memberi Anda kendali penuh atas NAT.
Daftar Kontrol Akses Jaringan kemudian dikonfigurasi untuk subnet kami. Ini bertindak sebagai firewall, mengontrol lalu lintas masuk dan keluar dari subnet kami. Setiap subnet dikaitkan dengan ACL jaringan, default ke ACL jaringan VPC. ACL jaringan berisi daftar aturan bernomor yang dievaluasi dalam urutan menaik untuk menentukan apakah lalu lintas diizinkan masuk atau keluar. Semua lalu lintas masuk dan keluar ditolak kecuali aturan secara eksplisit menyatakan sebaliknya.
Selain ACL jaringan, kami dapat menyiapkan grup keamanan untuk layanan Amazon yang akan kami bangun. Grup keamanan bertindak sebagai firewall virtual pada level instance, bukan pada level subnet (lihat perbandingannya di sini). Grup keamanan berisi daftar aturan ‘izinkan’ masuk dan keluar, dengan apa pun yang tidak terdaftar akan ditolak. Tidak seperti ACL jaringan, grup keamanan bersifat stateful, artinya apa pun aturan masuknya, permintaan dari layanan kami yang diizinkan keluar akan selalu memiliki tanggapan yang diizinkan masuk. Misalnya, grup keamanan untuk lapisan basis data kami dapat mengizinkan semua lalu lintas keluar, tetapi hanya lalu lintas TCP masuk melalui port 3306 dari alamat IP dalam VPC kami. Ini berarti tidak ada lalu lintas eksternal yang dapat memasuki lapisan DB kecuali dimulai dari dalam, sambil mengizinkan instans back-end kami melakukan panggilan DB.
Instans EC2, AMI, dan Load Balancing
Selanjutnya kami menyiapkan server tempat kami akan menggunakan AWS EC2 atau Elastic Compute Cloud. Instans EC2 adalah instans virtual yang dapat diubah ukurannya untuk aplikasi kami tempat kami akan menghosting API back-end kami (lihat juga AWS ECS). Instans EC2 bersifat sementara sehingga informasi yang disimpan di dalamnya bersifat sementara. Oleh karena itu, penyimpanan persisten seperti EFS (Elastic File System) atau EBS (Elastic Block Store) harus digunakan sesuai kebutuhan, meskipun kami bertujuan untuk menjaga backend kami tanpa status sehingga ini tidak diperlukan.
Di pos lain saya berharap untuk mempelajari pola arsitektur tanpa server baru yang memanfaatkan Lambdas dan AWS API Gateway.
AMI atau Gambar Mesin Amazon adalah apa yang akan di-boot dalam setiap instans kami. AMI khusus dibuat dari AMI berbasis Amazon, dengan alat seperti Packer, Puppet, Ansible, Chef, Salt, dll. sangat bagus di sini untuk menyediakan gambar. Alternatifnya, dengan pengaturan dasar Anda dapat tetap menggunakan AMI dasar dan membuat skrip startup melakukan apa yang Anda butuhkan. Saat Anda meluncurkan instans AWS EC2, Anda dapat meneruskan data cloud init yang dijalankan di sisi server saat booting.
Berfokus pada ketersediaan dan skalabilitas tinggi, kami ingin memanfaatkan penskalaan horizontal aplikasi kami. Auto Scaling Groups Amazon mengelola instans EC2 kami, meningkatkan jumlah instans dan dengan demikian kapasitas keseluruhan kami sesuai kebutuhan. Saat lalu lintas menurun, mereka juga akan secara elastis mengurangi jumlah instans untuk menghemat sumber daya. Dengan menggunakan detak jantung pemeriksaan kesehatan, grup penskalaan otomatis akan menutup secara cerdas dan memunculkan instance baru saat muncul kesalahan kritis. Health check dapat dikonfigurasi untuk menggunakan protokol yang berbeda, termasuk lapisan transport (mis. TCP) dan lapisan jaringan (mis. HTTP), dengan menggunakan satu atau beberapa pendengar.
Dalam grup penskalaan otomatis, Elastic Load Balancer akan mendistribusikan lalu lintas di antara instans yang berjalan untuk mempertahankan kinerja tinggi (lihat juga AWS ALB baru). Kami akan menggunakan penyeimbang muatan multi-AZ dengan instans di berbagai zona ketersediaan untuk ketersediaan tinggi jika terjadi bencana. Saat lalu lintas diterima, ELB akan merutekan lalu lintas ke instans yang sesuai di seluruh zona ketersediaan yang memastikan permintaan ditangani dengan cepat dan efisien saat aplikasi kami diskalakan.
Database Layer (Relasional atau NoSQL)
Untuk menyimpan dan menanyakan data yang terkait dengan aplikasi kita, kita memerlukan database. Teknologi database yang Anda pilih akan bergantung pada sejumlah faktor: pola akses yang Anda antisipasi, jumlah data, dan memprioritaskan ketersediaan versus konsistensi. Bagian dari keputusan ini akan mencakup apakah Anda menginginkan database relasional tradisional atau database NoSQL. Ini adalah area dengan kompleksitas khusus, di mana jawaban satu ukuran untuk semua tidak akan memadai.
Pada tingkat tinggi, Anda akan ingin mempertimbangkan database relasional seperti yang ada di AWS RDS jika integritas data (pengetikan/skema yang kuat, atomisitas data, konsistensi data) sangat diinginkan atau data secara inheren bersifat relasional dan kueri akan memerlukan banyak penggabungan. Database NoSQL seperti AWS DynamoDB harus dipertimbangkan jika diperlukan throughput tulis yang besar, skema fleksibel diinginkan, atau data Anda bersifat hierarkis/grafis. Redis atau AWS ElastiCache juga harus diperiksa untuk caching dan mengurangi beban dari database Anda.
Hosting Klien S3 dan CDN CloudFront
Sekarang kami siap untuk menerbitkan aplikasi klien kami ke AWS S3 atau Simple Storage Service. Bersama dengan EC2, S3 adalah salah satu layanan andalan AWS. S3 akan mengelola kebutuhan ketersediaan tinggi dan daya tahan data kami untuk menghosting aplikasi klien; faktanya S3 menawarkan daya tahan 99,999999999% dan metrik ketersediaan 99,99%. Itu sangat mengesankan! Cukup mengunggah bundel Webpack dengan klien React/Redux kami ke S3 dan menyetel ACL-nya ke publik-baca akan berhasil.
Untuk mengurangi latensi dan membuat aplikasi klien kami benar-benar tajam, kami dapat memanfaatkan jaringan pengiriman konten Amazon, CloudFront. CloudFront adalah jaringan lokasi edge global untuk meng-cache konten statis kami dan membawanya lebih dekat ke pengguna akhir. CloudFront akan mengoptimalkan kinerja aplikasi kami dengan mengurangi latensi. Sekarang pengguna di Jerman atau China tidak perlu menunggu aset statis kami dari seberang lautan. CDN juga dapat digunakan untuk memerangi DDOS atau serangan denial of service terdistribusi dengan memfilter permintaan yang salah bentuk dan memblokir geos asal.
IAM Roles dan Securing Cloud Credentials
Layanan Manajemen Identitas dan Akses Amazon memberi kami kontrol akses terperinci atas sumber daya kami. Di sini kami mendaftarkan akun pengguna untuk pengembang dan administrator, membuat dan menetapkan pengguna ke grup, dan membuat peran untuk memberikan akses ke layanan kami. Amazon menekankan filosofi hak istimewa terkecil yang akan kami patuhi, hanya memberikan izin minimal yang diperlukan untuk pengguna dan layanan kami.
Kami harus membuat pengguna untuk diri kami sendiri, karena sebaiknya jangan pernah menggunakan kredensial root akun Anda. Kami juga perlu membuat pasangan kunci publik/pribadi melalui pengguna untuk perkakas otomasi kami (mis. Terraform).
Untuk memberikan akses backend instance kami ke database dan layanan AWS lainnya, kami akan memberikan peran padanya. Bersamaan dengan data cloud init, kami dapat menetapkan peran ke instans EC2 kami saat memulai. Peran ini memerlukan akses ke database kami, serta layanan lain yang mungkin kami gunakan. Pemberian kredensial melalui peran IAM sangat bagus karena menghilangkan kerumitan pendistribusian kredensial secara aman ke setiap instans saat mulai dan kebutuhan untuk merotasi kredensial tersebut. Ini juga berarti kami tidak perlu menyimpan kredensial rahasia kami di EC2.
Metode alternatif untuk meneruskan kredensial ke instans EC2 kami adalah melalui bucket S3 yang aman. Untuk melakukannya, kami akan mengunci bucket S3 agar hanya dapat diakses dari kotak EC2 kami melalui ACL S3 khusus dan titik akhir VPC. Sebelum berkomunikasi dengan layanan lain, instans kami perlu mengambil kredensial ini dari S3 dan menyimpannya di variabel lingkungan atau untuk sementara di dalam variabel aplikasi.
Route53 DNS
Dengan aplikasi klien dan backend kami, saatnya menyiapkan konfigurasi DNS kami di AWS Route53. Route53 akan menghubungkan permintaan masuk ke layanan web Amazon yang telah kami siapkan serta memberikan failover DNS. Setelah kami mendaftarkan domain aplikasi kami baik melalui Route53 atau penyedia lain, kami harus mengonfigurasi entri DNS Route53 kami.
Pertama, kita membuat Hosted Zone untuk aplikasi kita. Ini adalah pengelompokan logis dari entri DNS untuk dikaitkan dengan aplikasi kami. Ada sejumlah jenis entri DNS, tetapi kami akan fokus pada jenis entri NS, SOA, dan A di sini. Secara default, untuk zona yang dihosting publik, Amazon akan membuat entri nameserver (NS) dan start of authority (SOA) untuk kita. Kumpulan record server nama mengaitkan empat server nama Route53 untuk digunakan dengan aplikasi kita, sementara kumpulan record otoritas awal menyimpan informasi meta tentang domain kita.
Dari keempat server nama ini, kami perlu menginstruksikan Route53 untuk menyelesaikan nama domain terdaftar kami dengan alamat IP aplikasi klien kami. Untuk melakukan ini, kami menggunakan kumpulan rekaman tipe A. Kumpulan catatan tipe adalah untuk memetakan domain ke alamat IPv4 dan dilengkapi dengan berbagai kebijakan perutean – sederhana, berbobot, latensi, failover, dan geo. Mereka masing-masing memberikan tujuan yang unik dan harus dicatat dengan hati-hati; kebijakan perutean sederhana merutekan lalu lintas langsung dari domain ke alamat IPv4, bobot mengarahkan lalu lintas secara proporsional ke beberapa alamat, latensi mengarahkan lalu lintas berdasarkan latensi terendah, failover mengarahkan lalu lintas ke sumber daya cadangan jika terjadi bencana, dan geo mengarahkan lalu lintas berdasarkan meminta geolokasi.
Untuk contoh ini, pertama-tama kita akan membuat dua kumpulan catatan A dengan perutean sederhana ke distribusi CloudFront yang menghosting aplikasi klien kita. Salah satu entri ini akan memiliki domain kami dengan awalan ‘www’ yang lain tanpa. Kami juga akan membuat kumpulan data A ketiga dengan kebijakan perutean kegagalan sehingga kami dapat mengarahkan pengguna ke halaman kesalahan kustom yang menyenangkan jika terjadi kegagalan. Kebijakan perutean failover hadir dengan sejumlah konfigurasinya sendiri, tetapi untuk kesederhanaan, kami akan menggunakan konfigurasi aktif-pasif. Kemudian kita hanya perlu mengaitkan health check dengan aplikasi kita. Sekarang ketika aplikasi kami gagal, kami akan memiliki failover DNS ke halaman kesalahan khusus.
Rangkuman
Ini adalah kunci untuk menggunakan otomatisasi dalam pembuatan banyak bagian pengaturan arsitektur yang dapat diskalakan, aman, dan sangat tersedia ini. AWS menawarkan CloudFormation kepada kami karena alasan ini atau Anda dapat menggunakan preferensi ini – Terraform HashiCorp. Dengan menggunakan Terraform, kami dapat menulis seluruh arsitektur kami secara deklaratif, mulai dari grup keamanan, hingga tabel Dynamo, hingga peran IAM. Ini tidak hanya menyediakan otomatisasi tetapi memungkinkan kita untuk mengontrol versi arsitektur kita.
Ada banyak lagi layanan yang dapat kitya diskusikan juga – Layanan Antrean Sederhana untuk memisahkan layanan aws, Layanan Notifikasi Sederhana untuk perpesanan SMS, Layanan Email Sederhana untuk email otomatis, ElastiCache untuk caching back-end, Cloud Trail untuk mencatat semua perubahan AWS.
Ini seharusnya memberikan panduan tingkat tinggi untuk membangun server tangguh dari ujung ke ujung, solusi web di AWS. Saya berharap penawaran pandangan komprehensif tentang bagaimana teknologi ini bekerja sama dan langkah-langkah yang terlibat dalam membangun aplikasi Anda selanjutnya di AWS.
