Halo semua! Pada kali ini saya akan berbagi tentang konsep arsitektur pada aplikasi kami. Dalam penjelasannya nanti, akan banyak sekali istilah yang mungkin kurang familiar ataupun belum pernah didengar. Oleh karena itu, pertama kali kita akan menjelaskan dahulu apa saja sih stack-stack yang ada pada aplikasi kami.
GitLab (Repository + Runner + Registry)
Kalian sudah tau dong apa itu GitLab? Ya, GitLab merupakan repositori tempat kami menyimpan dan mempublikasikan kode. Namun bukan hanya itu saja, kami juga memanfaatkan beberapa fitur dari GitLab yaitu runner dan registry. Runner merupakan fitur dimana GitLab memberikan virtual machine untuk kita melakukan pengujian/interaksi pada kode kita saat melakukan push ke dalam repositori. Kemudian registry merupakan tempat penyimpanan docker image. Apa itu docker image? Nanti akan dijelaskan di bawah ya!
Docker Container Image
Menurut website Docker sendiri:
A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.
Secara simpel, bayangkan saja docker container image sebagai sebuah virtual machine mini yang akan membuat aplikasi kita independen dan fleksibel terhadap infrastruktur dari mesin yang menjalankannya.
Kubernetes (Orchestrator)
Kubernetes merupakan orchestrator yang dapat menjadwalkan dan menjalankan kontainer aplikasi pada kelompok mesin fisik atau virtual. Namun, Kubernetes juga memungkinkan pengembang untuk ‘cut the cord’ ke mesin fisik dan virtual, bergerak dari infrastruktur host-sentris ke infrastruktur kontainer, yang memberikan keuntungan dan manfaat penuh yang melekat pada kontainer. Kubernetes menyediakan infrastruktur untuk membangun lingkungan pengembangan yang benar-benar kontainer-sentris. Disini Kubernetes digunakan untuk melakukan deployment pada docker container image yang kita miliki.
Flask (Framework Backend)
Flask merupakan framework mini yang cukup fleksibel dan berbahasa Python. Walaupun Flask dapat digunakan sebagai MVC dengan frontend menggunakan templating yang dimiliki Flask yaitu Jinja, namun konsep kontainer-sentris dan microarchitecture-oriented membuat kami memutuskan untuk menjadikan Flask hanya sebagai backend dengan konsep restfulAPI.
React-Js (Framework Frontend)
React-Js merupakan framework untuk frontend berbasis javascript yang cukup populer pada masa kini. Nah, React-Js sendiri kami gunakan sebagai frontend yang menampilkan aplikasi secara grafis kepada pengguna.
Celery (Worker)
Aplikasi kita memiliki tugas yang mengharuskan backend untuk dapat mengerjakan sebuah komputasi yang memakan waktu yang cukup lama. Dengan demikian dibutuhkannya bantuan dalam bentuk worker sehingga pekerjaan dapat dikerjakan secara paralel. Disini kami menggunakan Celery sebagai worker berbasis Python yang membantu backend dalam melakukan tugas yang berat.
Redis (Broker & Queue)
Redis dapat dibilang sebagai tempat penyimpanan layaknya database, namun uniknya dia menyimpan data di memori, bukan diska. Secara singkat disini kami menggunakan Redis untuk dua hal, yaitu sebagai broker yang menampung dan mengantrikan tugas-tugas yang diberikan oleh core backend untuk diberikan kepada worker, dan sebagai result backend yaitu tempat menampung hasil ataupun status dari kerja worker.
Postgresql (Database)
Singkat saja, postgresql merupakan database berbasis SQL tempat kami menyimpan data-data yang dibutuhkan.
Our Current Architecture Schema
Skema diatas merupakan gambaran dari aliran pengembangan aplikasi kami mulai dari kode yang dihasilkan oleh pemrogram hingga bagaimana aplikasi dapat disajikan kepada pengguna. Berikut merupakan penjelasannya:
- Ketika seorang pemrogram melakukan push kode menggunakan git, kode akan dikumpulkan dan digabungkan didalam sebuah repositori milik GitLab.
- Pada branch tertentu (master/sit-uat), push ke dalam branch tersebut akan memicu berjalannya runner yang akan melakukan proses tes, rilis, dan deployment.
- Kode yang akan dirilis akan dijadikan sebuah kontainer docker terlebih dahulu dan kemudian akan di push ke dalam penyimpanan kontainer milik GitLab yaitu GitLab Registry.
- Pada proses deployment, runner akan memicu kubernetes untuk melakukan proses pull pada kontainer/image docker yang baru di-push.
- Kubernetes kemudian melakukan deployment menggunakan konfigurasi yang diberikan pada repositori. Deployment yang dilakukan antara lain adalah: redis (broker & result backend), postgresql (database), mario (backend), luigi (worker), dan peach (frontend).
- Ketika suatu pengguna mengunjungi peach (frontend), maka peach (frontend) akan mengirimkan API untuk melakukan proses yang dikehendaki oleh pengguna kepada mario (backend).
- Untuk proses yang tergolong cepat, mario (backend) dapat langsung mengambil data dari postgresql, namun untuk proses yang lambat (kalkulasi, dll.), mario (backend) akan memberikan tugasnya kepada luigi (worker) melalui perantara redis.
- Redis merupakan broker yang menampung tugas-tugas yang diberikan oleh mario (backend), kemudian luigi (worker) akan melakukan pengecekan berkala pada redis, mengambil tugasnya, mengerjakannya, dan mengembalikannya kepada redis yang sekarang bekerja sebagai result backend.
- Dalam pengerjaannya luigi (worker) dapat menduplikasi dirinya menjadi banyak agar dapat menyelesaikan tugas secara paralel. Kapasitas penduplikasiannya sendiri dapat diatur dalam pengaturan dan menyesuaikan kapasitas dari mesin. Luigi (worker) juga memiliki akses kepada postgresql untuk melakukan transaksi pada database.
- Setelah mario (backend) selesai menyelesaikan tugasnya, hasilnya akan dikembalikan lagi kepada peach (frontend) untuk ditampilkan kepada pengguna.
Secara ringkas dapat digambarkan sebagai:
Simple Architecture
Pada dasarnya, konsep microarchitecture yang kami implementasikan menerapkan teknik dasar dari dependency injection.
Dependency injection memiliki fleksibilitas yang lebih tinggi dibandingkan dengan Layered Pattern yang juga merupakan teknik umum yang cukup populer.
Kekurangan dari dependency injection adalah dibagian management karena terdiri dari banyak servis kecil sehingga lebih sulit diurus.
Namun bagian terbaiknya adalah, arsitektur bersifat independen satu sama lain sehingga menjadi fleksibel.
Begitu deh secara singkat dapat dijelaskan arsitektur aplikasi kami. Tidak rumit bukan? Sampai jumpa lagi untuk penjelasan arsitektur yang lebih mendalam di seri Allocarchitecture berikutnya ya!
0 komentar:
Post a Comment