{"id":7969,"date":"2020-12-17T13:16:38","date_gmt":"2020-12-17T06:16:38","guid":{"rendered":"http:\/\/binus.ac.id\/knowledge\/?p=7969"},"modified":"2020-12-17T13:23:30","modified_gmt":"2020-12-17T06:23:30","slug":"membangun-sistem-pelaporan-pada-distributed-system","status":"publish","type":"post","link":"https:\/\/binus.ac.id\/knowledge\/2020\/12\/membangun-sistem-pelaporan-pada-distributed-system\/","title":{"rendered":"Membangun Sistem Pelaporan pada Distributed System"},"content":{"rendered":"

Distributed System<\/em> merupakan salah satu arsitektur aplikasi yang populer diterapkan saat ini karena mendukung skalabilitas (scalability)<\/em> dan ketersediaan (high availability<\/em>). Arsitektur microservices<\/em> merupakan salah satu bentuk implementasi dari distributed system<\/em>, dimana sebuah aplikasi enterprise<\/em> dibagi-bagi menjadi modul-modul yang independen yang memiliki fungsi spesifik. Setiap modul ini disebut dengan microservice,<\/em> di dalamnya memiliki database<\/em> yang khusus sesuai dengan tanggung jawab dari modul tersebut (single bounded context<\/em>).<\/p>\n

Microservice<\/em> A tidak dapat mengakses langsung data dari microservice<\/em> B tanpa melalui endpoint<\/em> yang telah disediakan oleh microservice<\/em> B, dan sebaliknya. Hal ini dapat akan menjadi tantangan ketika kita membutuhkan laporan yang datanya merupakan hasil penggabungan dari kedua microservice<\/em> tersebut atau lebih.<\/p>\n

Menurut Mark Richards, terdapat empat teknik dalam membuat laporan dalam arsitektur microservice,<\/em> yaitu database pull model, HTTP pull model, batch pull model,<\/em> dan event-based push model<\/em>. Ketiga teknik pertama melakukan pengambilan data dari database microservice<\/em> lain, ini merupakan sebuah ANTIPATTERN<\/strong><\/em> yang dinamakan “reach-in reporting”.<\/em><\/strong> Ketiga ini merupakan teknik yang harus dihindari dan akan dibahas lebih dalam sebelum mengakibatkan masalah lebih lanjut.<\/p>\n

Isu utama dalam pembuatan laporan pada microservice architecture<\/em><\/h3>\n

Terdapat dua masalah yaitu pertama, bagaimana mendapatkan laporan secara tepat waktu dan tetap mempertahankan bounded context<\/em> pada microservice<\/em> dan datanya?<\/p>\n

Antipattern 1: Database pull model<\/em><\/h4>\n

Terdapat sebuah microservice yang secara langsung mengakses database<\/em> dari microservice<\/em> lainnya (Gambar 1).<\/p>\n

<\/strong><\/p>\n

Gambar 1: Database pull model<\/em><\/strong><\/p>\n

Metode ini merupakan cara termudah dan tercepat untuk mendapatkan laporan dalam waktu yang tepat. Namun ini berdampak pada coupling<\/em> \/ ketergantungan yang sangat tinggi antara microservices<\/em> dan reporting service.<\/em> Metode ini biasanya diimplementasikan dengan mudah pada shared database<\/em>, dimana beberapa aplikasi berbagi database.<\/em> Namun ini berarti integritas data juga dapat diragukan karena setiap microservice<\/em> dapat berubah, dan terjadilah ketergantungan dalam melakukan modifikasi, serta ini juga merusak prinsip bounded context<\/em>\u00a0pada arsitektur microservices.<\/em><\/p>\n

Antipattern 2: HTTP pull model<\/em><\/h4>\n

Teknik HTTP pull model<\/em> ini dapat menghindari isu pada antipattern<\/em> 1 yaitu ketergantungan dan pelanggaran bounded context.<\/em> Teknik ini tidak mengakses database<\/em> dari microservice<\/em> secara langsung, tetapi reporting service<\/em> akan memanggil data menggunakan endpoint microservices<\/em> sumber (biasanya menggunakan RESTful HTTP call)<\/em> (Gambar 2).<\/p>\n

<\/p>\n

Gambar 2: HTTP pull model<\/em><\/strong><\/p>\n

Teknik ini terbilang lambat dan kompleks ketika kita memerlukan laporan dengan kebutuhan khusus. Sebagai contoh reporting service ini harus melakukan join data dari dua atau lebih sumber data dengan volume yang cukup besar. Selain itu volume data yang besar juga menjadi isu tersendiri ketika melakukan transfer melalui simple HTTP call.<\/p>\n

Antipattern 3: Batch pull model<\/em><\/h4>\n

Teknik ketiga ini merupakan workaround<\/em> dari antipattern<\/em> 1, yaitu dengan mengambil data secara bertahap (batch).<\/em> Umumnya batch job<\/em> ini dilakukan menggunakan agent<\/em> secara periodik di waktu tertentu yang telah ditentukan dan akan melakukan agregasi terkait perubahan data (tambah, hapus, rubah) dan dimasukkan ke reporting database<\/em> atau data warehouse.<\/em><\/p>\n

<\/p>\n

Gambar 3: Batch pull model<\/strong><\/p>\n

Teknik ini memiliki masalah yang sama dengan database pull model<\/em> yaitu terdapat batch data upload service<\/em> akan mengakses database microservices<\/em> lain secara langsung.<\/p>\n

Event-based model (Asynchronous event push)<\/em><\/h4>\n

Solusi dari antipattern reach-in<\/em> pada perancangan sistem laporan ini adalah dengan event-based push model<\/em>. Teknik ini disebut juga data pump<\/em>, yaitu data dipompa ke reporting service<\/em> yang membutuhkan. Pengiriman dilakukan dengan menggunakan event<\/em> yang berisi data (message)<\/em> secara asynchronous<\/em> yang nanti pada akhirnya (eventually)<\/em> akan diterima oleh reporting service<\/em> (Gambar 4).<\/p>\n

<\/p>\n

Gambar 4: Event based push model<\/strong><\/p>\n

Implementasi teknik ini cukup kompleks, namun ini akan mempertahankan prinsip bounded context<\/em> dari microservices<\/em> lain serta data akan terkirim dalam waktu yang relatif cepat. Terdapat kontrak antara data capture service<\/em> dengan microservices<\/em> yang harus disepakati yaitu topik event-nya.<\/em><\/p>\n

Komparasi kelebihan dan kekurangan dari keempat teknik<\/h4>\n

<\/p>\n

Gambar 4. Komparasi kelebihan dan kekurangan dari keempat teknik<\/strong><\/p>\n

Pada Gambar 4, database pull method<\/em> memiliki ketepatan waktu yang sangat tinggi (timeliness of data<\/em>), namun melanggar prinsip bounded context<\/em>. HTTP pull model<\/em> mempertahankan bounded context<\/em>, namun memiliki isu dengan waktu dan volume data. Batch pull model<\/em> merupakan pola yang paling kurang baik, karena ketepatan waktu yang rendah dan melanggar bounded context<\/em>. Sedangkan event-based push model<\/em> ini memaksimalkan ketepatan waktu dan juga mempertahankan bounded context<\/em>. Namun secara effort<\/em> dalam membangun dengan event-based push model<\/em> ini relatif lebih kompleks dibanding yang lain.<\/p>\n

Sumber Referensi:<\/strong>
\nhttps:\/\/www.oreilly.com\/library\/view\/microservices-antipatterns-and\/9781492042716\/ch04.html<\/a>
\nhttps:\/\/medium.com\/@muneeb.ahmed20\/building-a-reporting-service-in-microservice-architecture-8d5bf3b90fb7<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Distributed System merupakan salah satu arsitektur aplikasi yang populer diterapkan saat ini karena mendukung skalabilitas (scalability) dan ketersediaan (high availability). Arsitektur microservices merupakan salah satu bentuk implementasi dari distributed system, dimana sebuah aplikasi enterprise dibagi-bagi menjadi modul-modul yang independen yang memiliki fungsi spesifik. Setiap modul ini disebut dengan microservice, di dalamnya memiliki database yang khusus […]<\/p>\n","protected":false},"author":5,"featured_media":7973,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[83],"tags":[459,458,454,457],"class_list":["post-7969","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news","tag-distributed-system","tag-microservices","tag-reporting","tag-system-design"],"_links":{"self":[{"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/posts\/7969","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/comments?post=7969"}],"version-history":[{"count":5,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/posts\/7969\/revisions"}],"predecessor-version":[{"id":7975,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/posts\/7969\/revisions\/7975"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/media\/7973"}],"wp:attachment":[{"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/media?parent=7969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/categories?post=7969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/binus.ac.id\/knowledge\/wp-json\/wp\/v2\/tags?post=7969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}