Studi Kasus: Mengapa Saya Menggunakan AWS Cloud Infrastructure untuk Produk Saya

Sebagai platform untuk menjalankan produk perangkat lunak yang kompleks dan menuntut, AWS menawarkan fleksibilitas dengan memanfaatkan sumber daya saat dibutuhkan, pada skala yang dibutuhkan. Ini sesuai permintaan dan instan, memungkinkan kontrol penuh atas lingkungan yang berjalan. Saat mengusulkan solusi arsitektur cloud seperti itu kepada klien, infrastruktur yang disediakan, dan harganya, sangat bergantung pada persyaratan yang perlu disiapkan di awal.

Artikel ini akan menyajikan salah satu arsitektur infrastruktur cloud AWS, diusulkan dan diimplementasikan untuk LEVELS, jaringan sosial dengan fungsi pembayaran wajah terintegrasi yang menemukan dan menerapkan semua manfaat yang mungkin diperoleh pengguna untuk program kartu yang mereka ikuti, barang yang mereka miliki, atau tempat mereka tinggal di.

Persyaratan

Klien memiliki dua persyaratan utama yang harus dipenuhi oleh solusi yang diusulkan:

1. Keamanan
2. Skalabilitas

Persyaratan keamanan adalah tentang melindungi data pengguna dari akses tidak sah dari luar, tetapi juga dari dalam. Persyaratan skalabilitas adalah tentang kemampuan infrastruktur untuk mendukung pertumbuhan produk, secara otomatis beradaptasi dengan peningkatan lalu lintas dan lonjakan sesekali, serta failover dan pemulihan otomatis jika terjadi kegagalan server, meminimalkan potensi waktu henti.

Ikhtisar Konsep Keamanan AWS

Salah satu manfaat utama menyiapkan infrastruktur AWS Cloud Anda sendiri adalah isolasi jaringan penuh dan kontrol penuh atas cloud Anda. Itulah alasan utama mengapa Anda memilih rute Infrastruktur sebagai Layanan (IaaS), daripada menjalankan lingkungan Platform sebagai Layanan (PaaS) yang lebih sederhana, yang menawarkan default keamanan yang solid tetapi tidak memiliki kontrol yang lengkap dan halus yang Anda dapatkan. menyiapkan cloud Anda sendiri dengan AWS.

Meskipun LEVELS adalah produk muda ketika mereka mendekati layanan konsultasi Toptal untuk AWS, mereka bersedia berkomitmen pada AWS dan tahu bahwa mereka menginginkan keamanan mutakhir dengan infrastruktur mereka, karena mereka sangat memperhatikan data pengguna dan privasi. Selain itu, mereka berencana untuk mendukung pemrosesan kartu kredit di masa mendatang, sehingga mereka tahu bahwa mereka perlu memastikan kepatuhan PCI-DSS di beberapa titik.

Virtual Private Cloud (VPC)

Keamanan di AWS dimulai dengan pembuatan Amazon Virtual Private Cloud (VPC) Anda sendiri - jaringan virtual khusus yang menghosting sumber daya AWS Anda dan secara logis diisolasi dari jaringan virtual lain di AWS Cloud. VPC mendapatkan rentang alamat IP sendiri, subnet yang dapat dikonfigurasi sepenuhnya, tabel perutean, daftar kontrol akses jaringan, dan grup keamanan (secara efektif, firewall).

Dengan LEVELS, kami memulai dengan mengisolasi lingkungan produksi kami dari lingkungan pengembangan, pengujian, dan QA. Ide pertama adalah menjalankan masing-masing dari mereka sebagai VPC mereka sendiri yang sepenuhnya terisolasi, masing-masing menjalankan semua layanan seperti yang diperlukan oleh aplikasi. Setelah beberapa pertimbangan, ternyata kami dapat mengizinkan beberapa berbagi sumber daya di tiga lingkungan non-produksi, yang mengurangi biaya sampai batas tertentu.

Jadi, kami menetapkan lingkungan produksi sebagai satu VPC, dengan lingkungan pengembangan, pengujian, dan QA sebagai VPC lainnya.

Akses Isolasi di Level VPC

Penyiapan dua VPC mengisolasi lingkungan produksi dari tiga lingkungan yang tersisa di tingkat jaringan, memastikan kesalahan konfigurasi aplikasi yang tidak disengaja tidak dapat melewati batas itu. Bahkan jika konfigurasi lingkungan non-produksi harus salah menunjuk ke sumber daya lingkungan produksi, seperti database atau antrian pesan, tidak ada cara untuk mendapatkan akses ke sana.

Dengan lingkungan pengembangan, pengujian, dan QA yang berbagi VPC yang sama, akses lintas batas dimungkinkan jika terjadi kesalahan konfigurasi, tetapi, karena lingkungan tersebut menggunakan data pengujian, tidak ada masalah keamanan yang nyata dengan kurangnya isolasi di sana.

Model Keamanan Toko Aset

Aset disimpan di penyimpanan objek Amazon Simple Storage Service (S3) . Infrastruktur penyimpanan S3 sepenuhnya independen dari VPC, dan model keamanannya berbeda. Penyimpanan diatur dalam bucket S3 terpisah untuk setiap lingkungan dan/atau kelas aset, melindungi setiap bucket dengan hak akses yang sesuai.

Dengan LEVELS, beberapa kelas aset diidentifikasi: unggahan pengguna, konten yang dihasilkan LEVELS (video promosi dan konten serupa), aplikasi web dan aset UI (kode JS, ikon, font), konfigurasi aplikasi dan infrastruktur, dan bundel penerapan sisi server.

Masing-masing mendapat ember S3 terpisah.

Manajemen Rahasia Aplikasi

Dengan AWS, ada AWS Systems Manager Parameter Store atau AWS Secrets Manager terenkripsi, yang merupakan layanan nilai kunci terkelola yang dirancang untuk menjaga kerahasiaan tetap aman (Anda dapat mempelajari lebih lanjut di Linux Academy dan 1Strategy).

AWS mengelola kunci enkripsi yang mendasarinya dan menangani enkripsi/dekripsi. Rahasia itu sendiri dapat menerapkan kebijakan izin baca dan tulis berdasarkan awalan kunci, baik untuk infrastruktur maupun pengguna (masing-masing server dan pengembang).

Akses SSH Server

Akses SSH ke server dalam lingkungan yang sepenuhnya otomatis dan tidak dapat diubah seharusnya tidak diperlukan sama sekali. Log dapat diekstraksi dan dikirim ke layanan logging khusus, pemantauan juga diturunkan ke layanan pemantauan khusus. Namun, mungkin ada kebutuhan untuk akses SSH sesekali untuk inspeksi konfigurasi dan debugging.

Untuk membatasi permukaan serangan server, port SSH tidak terpapar ke jaringan publik. Server dijangkau melalui bastion host, mesin khusus yang memungkinkan akses SSH eksternal, selain itu dilindungi dengan memasukkan daftar putih hanya rentang alamat IP yang diizinkan di firewall. Akses dikendalikan dengan menyebarkan kunci SSH publik pengguna ke kotak yang sesuai (login kata sandi dinonaktifkan). Pengaturan semacam itu menawarkan gerbang yang cukup tangguh bagi penyerang jahat untuk melewatinya.

Akses Basis Data

Prinsip yang sama yang diuraikan di atas berlaku untuk server database. Mungkin juga ada kebutuhan sesekali untuk menghubungkan dan memanipulasi data secara langsung dalam database, meskipun ini jelas bukan praktik yang disarankan, dan akses tersebut perlu dilindungi dengan cara yang sama seperti akses server SSH dilindungi.

Pendekatan serupa dapat digunakan, memanfaatkan infrastruktur bastion host yang sama dengan tunneling SSH. Terowongan SSH ganda diperlukan, satu ke bastion host, dan melalui terowongan itu, satu lagi ke server yang memiliki akses ke database (host bastion tidak memiliki akses server database). Melalui terowongan kedua itu, koneksi dari mesin klien pengguna ke server database sekarang tersedia.

Ikhtisar Konsep Skalabilitas AWS

Ketika kita berbicara murni tentang server, skalabilitas lebih mudah dicapai dengan platform yang lebih sederhana daripada AWS. Kelemahan utama adalah bahwa persyaratan tertentu mungkin perlu dicakup oleh layanan eksternal platform, yang berarti data berjalan melintasi jaringan publik dan melanggar batas keamanan. Berpegang pada AWS, semua data dijaga kerahasiaannya, sementara skalabilitas perlu direkayasa untuk mencapai infrastruktur yang skalabel, tangguh, dan toleran terhadap kesalahan.

Dengan AWS, pendekatan terbaik untuk skalabilitas adalah dengan memanfaatkan layanan AWS terkelola dengan pemantauan dan pengujian otomatisasi di ribuan klien yang menggunakan platform. Tambahkan cadangan data dan mekanisme pemulihan ke dalam campuran, dan Anda mendapatkan banyak masalah dengan hanya mengandalkan platform itu sendiri.

Memiliki semua yang diturunkan memungkinkan tim operasi yang lebih kecil, agak mengimbangi biaya layanan yang dikelola platform yang lebih tinggi. Tim LEVEL dengan senang hati memilih jalan itu jika memungkinkan.

Amazon Elastic Compute Cloud (EC2)

Mengandalkan lingkungan yang terbukti menjalankan instans EC2 masih merupakan pendekatan yang cukup masuk akal, dibandingkan dengan overhead tambahan dan kompleksitas menjalankan container atau konsep arsitektur komputasi tanpa server yang masih sangat muda dan berubah dengan cepat.

Penyediaan instans EC2 harus sepenuhnya otomatis. Otomatisasi dicapai melalui AMI kustom untuk kelas server yang berbeda, dan Grup Penskalaan Otomatis menangani menjalankan armada server dinamis dengan menjaga jumlah instans server yang berjalan dalam armada sesuai dengan lalu lintas saat ini.

Selain itu, fitur penskalaan otomatis memungkinkan pengaturan batas bawah dan batas atas dalam jumlah instans EC2 yang akan dijalankan. Batas bawah membantu toleransi kesalahan, berpotensi menghilangkan waktu henti jika terjadi kegagalan instans. Batas atas menjaga biaya tetap terkendali, memungkinkan beberapa risiko waktu henti jika terjadi kondisi ekstrem yang tidak terduga. Penskalaan otomatis kemudian secara dinamis menskalakan jumlah instans dalam batas tersebut.

Amazon Relational Database Service (RDS)

Tim telah menjalankan Amazon RDS untuk MySQL , tetapi cadangan yang sesuai, toleransi kesalahan, dan strategi keamanan belum dikembangkan. Pada iterasi pertama, instans database ditingkatkan ke kluster dua instans di setiap VPC, dikonfigurasi sebagai master dan replika baca, yang mendukung failover otomatis.

Pada iterasi berikutnya, dengan tersedianya engine MySQL versi 5.7, infrastruktur tersebut mendapatkan upgrade ke layanan MySQL Amazon Aurora . Meskipun dikelola sepenuhnya, Aurora bukanlah solusi yang diskalakan secara otomatis. Menawarkan penskalaan penyimpanan otomatis, menghindari masalah perencanaan kapasitas. Tetapi seorang arsitek solusi masih perlu memilih ukuran instans komputasi.

Waktu henti karena penskalaan tidak dapat dihindari tetapi dapat dikurangi seminimal mungkin dengan bantuan kemampuan penyembuhan otomatis. Berkat kemampuan replikasi yang lebih baik, Aurora menawarkan fungsionalitas failover yang mulus. Penskalaan dijalankan dengan membuat replika baca dengan daya komputasi yang diinginkan dan kemudian mengeksekusi failover ke instans tersebut. Semua replika baca lainnya kemudian juga dikeluarkan dari klaster, diubah ukurannya, dan dibawa kembali ke klaster. Ini membutuhkan beberapa juggling manual tetapi lebih dari bisa dilakukan.

Penawaran Aurora Tanpa Server yang baru juga memungkinkan beberapa tingkat penskalaan otomatis dari sumber daya komputasi, sebuah fitur yang pasti layak untuk dilihat di masa depan.

Layanan AWS Terkelola

Selain kedua komponen tersebut, sistem lainnya mendapat manfaat dari mekanisme penskalaan otomatis layanan AWS yang terkelola sepenuhnya. Itu adalah Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), penyimpanan objek Amazon S3, fungsi AWS Lambda, dan Amazon Simple Notification Service (SNS), di mana tidak diperlukan upaya penskalaan khusus dari arsitek.

Infrastruktur yang Dapat Diubah vs. yang Tidak Dapat Diubah

Kami mengenali dua pendekatan untuk menangani infrastruktur server - infrastruktur yang dapat berubah di mana server diinstal dan terus diperbarui dan dimodifikasi di tempat; dan infrastruktur yang tidak dapat diubah di mana server tidak pernah dimodifikasi setelah disediakan, dan setiap modifikasi konfigurasi atau pembaruan server ditangani dengan menyediakan server baru dari gambar umum atau skrip instalasi, menggantikan yang lama.

Dengan LEVELS, pilihannya adalah menjalankan infrastruktur yang tidak dapat diubah tanpa peningkatan di tempat, perubahan konfigurasi, atau tindakan manajemen. Satu-satunya pengecualian adalah penerapan aplikasi, yang memang terjadi di tempat.

Lebih lanjut tentang infrastruktur yang dapat berubah vs. yang tidak dapat diubah dapat ditemukan di blog HashiCorp.

Ikhtisar Arsitektur

Secara teknis, LEVELS adalah aplikasi seluler dan aplikasi web dengan backend API REST dan beberapa layanan latar belakang - aplikasi yang agak umum saat ini. Sehubungan dengan itu, infrastruktur berikut diusulkan dan dikonfigurasi:

Isolasi Jaringan Virtual - Amazon VPC

Diagram memvisualisasikan struktur satu lingkungan di VPC-nya. Lingkungan lain mengikuti struktur yang sama (memiliki Application Load Balancer (ALB) dan klaster Amazon Aurora yang dibagikan di antara lingkungan non-produksi di VPC mereka, tetapi pengaturan jaringannya persis sama).

VPC dikonfigurasi di empat zona ketersediaan dalam wilayah AWS untuk toleransi kesalahan. Subnet dan Grup Keamanan dengan Daftar Kontrol Akses Jaringan memungkinkan untuk memenuhi persyaratan keamanan dan kontrol akses.

Mencakup infrastruktur di beberapa Wilayah AWS untuk toleransi kesalahan tambahan akan terlalu rumit dan tidak perlu pada tahap awal bisnis dan produknya, tetapi merupakan opsi di masa mendatang.

Komputasi

LEVELS menjalankan REST API tradisional dengan beberapa pekerja latar belakang untuk logika aplikasi yang terjadi di latar belakang. Keduanya berjalan sebagai armada dinamis instans EC2 biasa, sepenuhnya otomatis melalui Grup Penskalaan Otomatis. Layanan terkelola Amazon SQS digunakan untuk distribusi tugas latar belakang (pekerjaan), menghindari kebutuhan menjalankan, memelihara, dan menskalakan server MQ Anda sendiri.

Ada juga beberapa tugas utilitas yang tidak memiliki logika bisnis yang dibagikan dengan aplikasi lainnya, seperti pemrosesan gambar. Jenis tugas seperti itu berjalan dengan sangat baik di AWS Lambda , karena Lambdas dapat diskalakan secara horizontal tanpa batas dan menawarkan pemrosesan paralel yang tak tertandingi dibandingkan dengan pekerja server.

Penyeimbangan Beban, Penskalaan Otomatis, dan Toleransi Kesalahan

Penyeimbangan beban dapat dicapai secara manual melalui Nginx atau HAProxy, tetapi memilih Amazon Elastic Load Balancing (ELB) menambahkan manfaat memiliki infrastruktur penyeimbangan beban yang secara intrinsik dapat diskalakan, sangat tersedia, dan toleran terhadap kesalahan.

Rasa Application Load Balancer (ALB) dari ELB digunakan, memanfaatkan perutean lapisan HTTP yang tersedia di penyeimbang beban. Instans baru yang ditambahkan ke armada didaftarkan secara otomatis ke ALB melalui mekanisme platform AWS. ALB juga memantau ketersediaan instans setiap saat. Ini memiliki kekuatan untuk membatalkan pendaftaran dan menghentikan instans yang tidak sehat, memicu Penskalaan Otomatis untuk menggantinya dengan yang baru. Melalui interaksi antara keduanya, penyembuhan otomatis armada EC2 tercapai.

Penyimpanan Data Aplikasi

Penyimpanan data aplikasi adalah klaster MySQL Amazon Aurora , yang terdiri dari instans master dan sejumlah instans replika baca. Dalam kasus kegagalan instans master, salah satu replika baca secara otomatis dipromosikan menjadi instans master baru. Dikonfigurasi seperti itu, memenuhi persyaratan toleransi kesalahan yang diminta.

Replika baca, seperti namanya, juga dapat digunakan untuk mendistribusikan beban cluster database untuk operasi pembacaan data.

Penyimpanan basis data secara otomatis diskalakan dalam peningkatan 10 GB dengan Aurora, dan pencadangan juga sepenuhnya dikelola oleh AWS, menawarkan pemulihan tepat waktu secara default. Semua itu mengurangi beban administrasi basis data hingga hampir tidak ada, kecuali untuk meningkatkan daya komputasi basis data saat dibutuhkan - layanan yang layak dibayar untuk berjalan tanpa rasa khawatir.

Menyimpan dan Melayani Aset

LEVELS menerima konten yang diunggah pengguna yang perlu disimpan. Penyimpanan objek Amazon S3 , cukup dapat diprediksi, adalah layanan yang akan menangani tugas itu. Ada juga aset aplikasi (elemen UI - gambar, ikon, font) yang perlu disediakan untuk aplikasi klien, sehingga dapat disimpan ke dalam S3 juga. Menawarkan pencadangan otomatis dari data yang diunggah melalui replikasi penyimpanan internalnya, S3 menyediakan ketahanan data secara default.

Gambar yang diunggah pengguna memiliki berbagai ukuran dan berat, seringkali terlalu besar untuk disajikan secara langsung dan kelebihan berat badan, membebani koneksi seluler. Memproduksi beberapa variasi dalam ukuran yang berbeda akan memungkinkan penyajian konten yang lebih optimal untuk setiap kasus penggunaan. AWS Lambda dimanfaatkan untuk tugas itu, serta untuk membuat salinan gambar asli yang diunggah ke dalam keranjang cadangan terpisah, untuk berjaga-jaga.

Terakhir, aplikasi web yang menjalankan browser juga merupakan kumpulan aset statis - infrastruktur pembangunan Continuous Integration mengkompilasi kode JavaScript dan menyimpan setiap build ke dalam S3 juga.

Setelah semua aset ini disimpan dengan aman di S3, mereka dapat disajikan secara langsung, karena S3 menyediakan antarmuka HTTP publik, atau melalui Amazon CloudFront CDN. CloudFront membuat aset terdistribusi secara geografis, mengurangi latensi ke pengguna akhir, dan juga memungkinkan dukungan HTTPS untuk melayani aset statis.

Penyediaan dan Pengelolaan Infrastruktur

Penyediaan infrastruktur AWS adalah kombinasi dari jaringan, sumber daya dan layanan yang dikelola AWS, dan sumber daya komputasi EC2. Layanan AWS terkelola, dikelola dengan baik. Tidak banyak yang bisa dilakukan dengan mereka kecuali menyediakan dan menerapkan keamanan yang sesuai, sementara dengan sumber daya komputasi EC2, kita perlu mengurus konfigurasi dan otomatisasi kita sendiri.

Perkakas

Konsol AWS berbasis web membuat pengelolaan infrastruktur AWS “seperti batu bata lego” menjadi hal yang sepele, dan, seperti pekerjaan manual lainnya, cenderung rawan kesalahan. Itu sebabnya menggunakan alat khusus untuk mengotomatisasi pekerjaan itu sangat diinginkan.

Salah satu alat tersebut adalah AWS CloudFormation , yang dikembangkan dan dikelola oleh AWS. Satu lagi adalah Terraform HashiCorp - pilihan yang sedikit lebih fleksibel dengan menawarkan beberapa penyedia platform, tetapi menarik di sini terutama karena filosofi pendekatan infrastruktur Terraform yang tidak dapat diubah. Selaras dengan cara infrastruktur LEVELS dijalankan, Terraform, bersama dengan Packer untuk menyediakan gambar AMI dasar, ternyata sangat cocok.

Dokumentasi Infrastruktur

Manfaat tambahan dengan alat otomatisasi adalah tidak memerlukan dokumentasi infrastruktur terperinci, yang cepat atau lambat akan usang. Paradigma “Infrastructure as Code” (IaC) dari alat penyedia disebut sebagai dokumentasi, dengan manfaat selalu up to date dengan infrastruktur yang sebenarnya. Memiliki ikhtisar tingkat tinggi, kecil kemungkinannya untuk diubah dan relatif mudah dipelihara dengan perubahan akhirnya, didokumentasikan di samping sudah cukup.

Pikiran Akhir

Infrastruktur AWS Cloud yang diusulkan adalah solusi skalabel yang mampu mengakomodasi pertumbuhan produk di masa depan sebagian besar secara otomatis. Setelah hampir dua tahun, ia berhasil menjaga biaya operasi tetap rendah, mengandalkan otomatisasi cloud tanpa memiliki tim operasi sistem khusus yang bertugas 24/7.

Berkenaan dengan keamanan, AWS Cloud menyimpan semua data dan semua sumber daya dalam jaringan pribadi di dalam cloud yang sama. Tidak ada data rahasia yang diperlukan untuk melakukan perjalanan melintasi jaringan publik. Akses eksternal diberikan dengan izin granular yang bagus ke sistem pendukung tepercaya (CI/CD, pemantauan eksternal, atau peringatan), membatasi cakupan akses hanya ke sumber daya yang diperlukan untuk peran mereka dalam keseluruhan sistem.

Diarsitektur dan diatur dengan benar, sistem seperti itu fleksibel, tangguh, aman, dan siap untuk menjawab semua persyaratan di masa mendatang terkait penskalaan untuk pertumbuhan produk atau menerapkan keamanan tingkat lanjut seperti kepatuhan PCI-DSS.

Itu tidak selalu lebih murah daripada penawaran yang diproduksi dari orang-orang seperti Heroku atau platform serupa, yang berfungsi dengan baik selama Anda cocok dengan pola penggunaan umum yang dicakup oleh penawaran mereka. Dengan memilih AWS, Anda mendapatkan kontrol lebih besar atas infrastruktur Anda, tingkat fleksibilitas tambahan dengan berbagai layanan AWS yang ditawarkan, dan konfigurasi yang disesuaikan dengan kemampuan menyempurnakan seluruh infrastruktur.

Bacaan Lebih Lanjut di Blog Teknik Toptal:

• Kerjakan Pekerjaan Rumah Anda: 7 Tips Ujian Arsitek Solusi Bersertifikat AWS
• Terraform vs. CloudFormation: Panduan Definitif
• Logging SSH dan Manajemen Sesi Menggunakan AWS SSM
• Bekerja Dengan TypeScript dan Dukungan Jest: Tutorial AWS SAM