Sigit Nugroho

Q: Apakah dalam hal Stabilitas, PostgreSQL dapat mendukung ribuan koneksi bersamaan per detiknya? Bagaimana jika ada crash, Apakah bisakah auto recovery?

A: Bisa, karena Postgres compliance dengan ACID yaitu Atomicity, Consistency, Isolation and Durability. Mengenai kemampuan ribuan koneksi tergantung pada kemampuan hardware seperti memori yang cukup besar dan proses yang berjalan banyak. Data yang sudah commit akan tetap berada di memori, namun data yang belum commit akan hilang. PostgreSQL juga dapat auto recovery yang mana ketika terjadi crash dan dilakukan restart akan auto recovery semua yang sudah committed namun untuk data yang belum committed tentunya harus diulang kembali.

Aditya Prapanca

Q: Apakah beda antara mesin multiprosesor dan multikomputer? Manakah yang lebih handal?

A: Multiprosesor atau Scale Up yaitu teknologi yang terdiri dari satu motherboard dan memiliki beberapa proses didalamnya. Hampir seluruh komputer saat ini adalah multiprocessor atau multi core. Sedangkan Multikomputer atau yang kita kenal dengan Scale Out merupakan teknologi yang memiliki lebih dari satu server yang bekerja sama saling membentuk cluster.

Hero Yudo

Q: Bagaimana mempersiapkan aplikasi Enterprise agar benar-benar dikatakan memiliki fitur HA?

A: Hal tersebut tentunya tergantung seperti apa aplikasi tersebut. Salah satu yang penting yaitu HA harus muncul dari aplikasi itu sendiri dan bagaimana session atau data harus disinkronisasikan, hal tersebut tergantung pada pemilik atau pembuat aplikasi.

Hero Yudo

Q: Bagaimana sistem komunikasi yang seharusnya terjadi antar modul-modul aplikasi Enterprise?

A: Bilamana yang dimaksud adalah komunikasi antar server HA maka yang perlu disiapkan proses komunikasi lokal sehingga proses sinkronisasi berlangsung cepat dalam satuan kurang dari microsecond.

Budi Hertanto

Q: Ketika membahas availability, kelihatannya lebih banyak tergantung pada faktor luar dari aplikasi tersebut, seperti H/W dan fasilitas pendukung, bukankah kalau demikian hampir semua aplikasi akan bisa memenuhi faktor availability ini?

A: Hal tersebut karena HA merupakan mekanisme untuk memitigasi risiko yaitu menghilangkan Single Point of Failure (SPOF). SPOF disebabkan oleh 2 faktor yaitu Hardware dan Software. Faktor pertama yaitu hardware failure sehingga software tidak mampu melakukan failover atau memang tidak bisa dilakukan failover. Faktor yang lebih mendasar bahwa HA adalah Hardware Failure Mitigation dimana ketika kita sudah memiliki 2 hardware yang sama dan satu hardware tersebut down maka dapat kita memitigasi risiko yang mungkin terjadi.
Sedangkan faktor kedua: Software memastikan dapat melakukan replikasi data dan melakukan failover dengan otomatis atau dapat di failover secara otomatis tanpa kehilangan konteks operasionalnya: (Sessionnya tidak hilang, koneksinya tidak menyebabkan user harus relogin dari awal, datanya tidak ada yang hilang).

Budi Hertanto

Q: Kalau untuk scalability tentunya setiap aplikasi punya batasan maximum, berapa minimal value untuk scale up/scale out supaya bisa dikategorikan sebagai Enterprise Level?

A: Tidak ada batasan, karena kemampuan dari scale up/scale out sendiri merupakan kemampuan dari Enterprise Level. Ketika sebuah aplikasi mampu di Scale Up/Scale Out sesuai dengan statement dari developer atau penjual sistem maka dapat dikatakan compliance dengan Enterprise Level.

Sugianto

Q: Apa tantangan ketika membangun Database yang workload tinggi dengan teknologi in memory computing atau OLTP dengan database Postgres?

A: Semua database yang benar menggunakan teknologi in memory karena RDBMS harus bekerja dengan sangat cepat sehingga semua data jika bisa akan diletakan di memori. Namun tentunya hal tersebut tidak bisa karena memori lebih kecil dari storage sehingga terjadi cache hit dan cache miss. Ketika seluruh data di load ke memori maka dapat dikatakan in memory, sama halnya dengan Postgres sehingga Postgres dapat dikatakan sama seperti in memory database. Database terkadang lambat disebabkan karena ketika transaksi akan dilakukan commit oleh aplikasi dan database Postgres akan melakukan penulisan ke disk yang mana disk ini bekerja lambat karena terus menerus melakukan proses commit sehingga menyebabkan kelambatan pada database. Kami menyarankan bilamana menggunakan Postgres, silahkan untuk memindahkan pg_wal nya kedalam sebuah storage yang sangat cepat seperti NVME sehingga dapat terasa seperti in memory. Cara lainnya juga dapat dilakukan dengan melakukan konfigurasi fsync dengan nilai off sehingga transaksi tidak melulu menulis ke disk sehingga penulisan dapat lebih cepat.

Sugianto

Q: High Availability cluster dengan DRC dengan RPO yang kecil, Bagaimana solusi Postgres hal ini?

A: Pertama yang harus kita pahami baik-baik adalah, High Availability tidak sama dengan DR, memiliki purpose dan mitigasi yang berbeda. HA disetup pada sebuah Data Center dan tidak terhubung melewati WAN. Setup sebuah sistem yang menghubungkan 2 Data Center yang berbeda domain jaringannya, tidak dapat disebut sebagai HA, setup tersebut lebih cocok disebut DR. Mengapa?

1. Melakukan establishment layanan dengan konfigurasi yang menggunakan domain jaringan yang berbeda tidak dapat dilaksanakan dengan mudah dan otomatis. Usaha melakukan otomatisasi pada sistem yang kompleks membutuhkan koordinasi yang ketat dan meningkatkan resiko ketersediaan layanan (Kontra produktif).
2. HA ditujukan untuk menjaga ketersediaan layanan, terhadap potensi SPOF (Single Point Of Failure) yang sudah disebutkan dalam presentasi, KECUALI Keadaan Kahar (Force Majeure)
3. Keadaan Kahar (Force Majeure) adalah sasaran mitigasi dari DR (Disaster Recovery) yang memiliki mekanisme dan teknologi jauh berbeda dengan HA, dan lebih penting lagi, DR adalah keputusan politis, bukan teknis.
4. Dalam suatu kondisi Keadaan Kahar (Force Majeure) secara umum ada lebih dari 1 fungsi atau fasilitas yang gagal operasi, bersifat sistemik dan melibatkan banyak department, tidak hanya IT saja (Bisnis, Operasional, Call Center, dan lainnya), hal ini berada diluar sasaran yang didisain untuk dimitigasi oleh HA (dengan pelaksanaan Failover yang otomatis)
5. RPO (Recovery Point Objective) adalah batasan data dapat dikembalikan bilamana terjadi crash. Dalam konteks HA maupun DR, tidak ada perbedaan yang berarti selama pelaksanaan dan implementasi dilakukan dengan cara yang benar sesuai dengan best practice. PostgreSQL memiliki kemampuan backup snapshot dan incremental. Backup and Recovery yang mumpuni juga disediakan oleh Equnix dalam melayani pelanggannya. Dengan kemampuan backup secara berlapis dari HA, Hot Standby/Report Replica, Snapshot dan Incremental backup dapat memastikan RPO yang sangat kecil sampai dengan ukuran mili detik. Lebih lanjut terkait RPO ini dapat menghubungi team Marketing kami untuk berdiskusi lebih jauh.

Fierta Cahaya

Q: Dulu APP Enterprise bersifat "Centralized" lalu menjadi "Modular", terakhir menjadi "Microservices" sehingga bisa "high-performance & auto-scale". Bagaimana dengan solution design dari sisi DB-level-nya (mis. PostgreSQL) supaya juga tidak jomplang secara DB-performance-nya dibanding APP level-nya? Apakah PostgreSQL sudah ready untuk support "Microservices" ?

A: Konsep microservice yaitu memecah proses menjadi sub proses yang lebih kecil. Database digunakan untuk menyimpan data transaksi yang sangat penting dan yang memiliki state machine. Tidak seluruh state perlu disimpan dalam satu database, yang mana kita dapat menyimpan state machine lainnya ke dalam database lain atau ke dalam memcached sehingga mengurangi beban di database utama. Dengan kita membangun satu sistem yang microservices maka kita dapat mengurangi beban database dan membangun clustering database.
(Bisa melihat rekaman Youtube, agar dapat memahami lebih jelas tentang penjelasan ini, intinya akses database seharusnya dapat dibuat lebih ringan dengan perubahan arsitektur dari monolitik menuju Micro Services. Arsitektur microservices tidak hanya memecah proses bisnis saja, tetapi juga memecah transaction cycle sesuai dengan skala prioritasnya)
(Bisa melihat rekaman Youtube, agar dapat memahami lebih jelas tentang penjelasan ini, intinya akses database seharusnya dapat dibuat lebih ringan dengan perubahan arsitektur dari monolitik menuju Micro Services. Arsitektur microservices tidak hanya memecah proses bisnis saja, tetapi juga memecah transaction cycle sesuai dengan skala prioritasnya).

Denny Rizky - PT. Wisma Kartika

Q: Bagaimana tips untuk menentukan bahwa hardware dan fasilitas yang kita gunakan masuk kedalam skala HA. Apakah itu artinya sebelum adanya implementasi di dalam sistem yang sebenarnya kita wajib melakukan trial test terlebih dulu untuk menentukan ketahanan dari 2 faktor tersebut atau bagaimana ya? Boleh dijelaskan.

A: Dalam konteks HA faktor yang harus diperhatikan adalah Hardware, yang mana tidak terdapat HA yang compliance terhadap hardware. HA merupakan satu cara untuk menghindarkan dari risiko hilangnya layanan dari masalah yang muncul dari hardware, fasilitas maupun sistem pendukung lainnya. Hal tersebut bukan berarti bilamana kita membeli sebuah hardware maka kita tidak akan kehilangan layanan dan memperoleh HA, namun dengan membangun sistem dan memilih hardware yang baik kita dapat memperkecil potensi kerusakan pada hardware sehingga mendapatkan keuntungan yang baik dari kemampuan hardware tersebut. Berbicara mengenai hardware maka terdapat redudansi hardware yang merupakan fitur dari hardware untuk menghindari Single Point of Failure, namun redudansi tersebut tidak relate ke HA dan tanpa redudansi pun kita tetap bisa membangun HA. Melalui HA kita dapat membuat sistem redundant dan available tanpa memiliki hardware yang memiliki kemampuan redudansi. Tentunya yang lebih baik bilamana menggunakan hardware nya redundant dan dilakukan instalasi HA.

Leo Willyanto Santoso

Q: Apakah pendapat Bapak, bahwa sebuah aplikasi yang berskala Enterprise haruslah bersifat agile (menyesuaikan dengan kebutuhan) juga?

A: Konteks pembahasan saat ini kita batasi terkait delivery application, sedangkan agile ini lebih kepada pembahasan proses bisnis yang dapat dijadikan nilai tambahan. Pembahasan kali ini mengenai bagaimana aplikasi bisa catch up dengan tantangan yang muncul di dunia Enterprise seperti force majeure, hardware failure dan peningkatan beban dimasa mendatang, hal tersebut yang menjadi challange yang kita definisikan di RAS.
Bisa saja sih kita masukkan Agile sebagai tambahan kategori, tetapi ini diluar pembahasan dalam diskusi ini.

Leo Willyanto Santoso

Q: Memiliki terlalu banyak solusi keamanan terkadang sama buruknya dengan memiliki terlalu sedikit. Bagaimana pendapat Pak Made?

A: Sebenarnya namanya solusi keamanan bukan banyak atau buruk, tetapi cocok atau tidak karena terkadang kita lupa menilai terlebih dahulu ditingkat mana keamanan dari sistem kita. Artinya di dalam memilih solusi keamanan penting dilakukan asesmen sistem dan manajemen risiko. Penting juga dilakukan pertimbangan kerugian dan effort yang dibutuhkan bilamana terjadi masalah di masa mendatang.

Bagit Airlangga

Q: Kami memiliki Data Center dan DRC sendiri, namun karena tuntutan bisnis kami harus berkembang lagi, nah apa kira-kira yang harus diambil keputusannya? Menggunakan Cloud atau Collocation atau membangun Data Center baru lagi ?

A: Hal tersebut tergantung pada kondisi Data Center. Bilamana memiliki Data Center yang cukup besar dan memiliki bisnis serta tim yang bagus maka itu cukup baik dan tidak ada masalah, sedangkan bilamana tidak terlalu besar akan lebih baik menggunakan Enterprise Cloud atau yang kita sebut Managed Service Collocation sehingga pemilik bisnis bisa fokus menjalankan bisnis.

Bagit Airlangga

Q: Pertanyaan tambahan, untuk database apakah harus direplikasi di semua site atau cukup di satu saja?

A: Secara umum, database kita butuh di main data center, bilamana memiliki site lainnya, maka bila hal tersebut merupakan DC, sebuah database yang diletakan di DC memiliki faktor alam, dengan membangun DRC maka bila terjadi disaster di Data Center kita memiliki data yang realtime dan aman. DRC juga dapat berupa backup offline sesuai dengan kebutuhan.

Yong Ong

Q: Dari sisi keamanan akses dan data, menurut bapak manakah yang lebih baik melakukan keamanan data dari database atau aplikasi atau keduanya? Manakah dari hal tersebut yang tidak berpengaruh pada performa?

A: Dalam keamanan kita mengenai state data yaitu data at rest (data di database), data in transit (data di antara aplikasi dan database) dan data in use (data di aplikasi dan database). Setiap state tersebut perlu diamankan. Hal tersebut tergantung dari ceklis compliance yang ditentukan dan seluruhnya perlu diterapkan sehingga dapat dikatakan compliance dengan Enterprise Level. Keamanan perlu diterapkan dari sisi yang paling besar yaitu database karena jika sudah compliance dari sisi akses dan state maka aplikasi akan lebih mudah. Aplikasi akan mengurusi key management dan membuat privilege untuk mengakses aplikasi sama dengan privilege pada database sehingga aplikasi mengakses data dengan satu user tertentu yang sudah diatur sehingga sesuai dengan peruntukannya. Singkatnya bilamana menginginkan keamanan yang ketat maka perlu diimplementasikan di sisi database dan aplikasi, namun bilamana tidak, bisa diserahkan seluruhnya ke database dan aplikasi dapat menggunakan yang sudah dienkripsi ataupun dekripsi oleh database. Tentunya hal tersebut berpengaruh pada performance bilamana menggunakan enkripsi yang matematikal, namun penurunan tersebut tidak signifikan sekitar 5-10%.

Yong Ong

Q: Dari sisi scalability scale out, untuk implementasi Load Balancing apakah dilakukan pada front end atau back end? Bagaimana best practice-nya?

A: Berbicara mengenai Load Balancing, terdapat 2 konstelasi, pertama dengan menggunakan Load Balancing pada level Database dan kedua pada level Aplikasi. Dalam implementasinya, Loadbalancer perlu dilengkapi dengan mekanisme HA sehingga memiliki mitigasi terhadap hardware failure dari loadbalancer itu sendiri. Saat ini teknologi PostgreSQL belum dapat di-load balancing karena perlu sinkronisasi data satu dengan yang lain dan memiliki potensial deadlock sehingga kami tidak menyarankan menggunakan Postgres untuk Load Balancing. (Catatan: PostgreSQL saat ini belum memiliki kemampuan replikasi 2 arah secara native, padahal fitur ini sangat dibutuhkan bilamana ingin melakukan load balancing 2 database PostgreSQL secara active-active).
Konstelasi kedua adalah yang dapat dijadikan pilihan dengan penerapan Load Balancing pada aplikasi dan aplikasi mengakses langsung ke database sehingga kita dapat memastikan koneksi selalu ke aplikasi yang sama dan database memiliki domain user yang berbeda, dengan demikian sinkronisasi antar database tidak menimbulkan deadlock karena setiap tier memiliki data yang berbeda.
Khususnya metode Load Balancing pada level Aplikasi, dapat juga menerapkan metode sticky session, sehingga pembagian beban lebih fleksibel terhadap akses yang memerlukan session. Hal ini dapat diterapkan dengan membuat client dari 1 sumber, tetap dilayani oleh aplikasi yang sama, sementara client lain dilayani oleh aplikasi peer-nya. Dengan demikian, tidak perlu terjadi session juggling antara Aplikasi yang tergabung dalam satu konstelasi, dan transaksi yang masuk ke database pun dapat menggunakan connection yang sama.

Yong Ong

Q: Apakah Load Balancing cocok untuk data transaksi atau hanya untuk report saja?

A: Bisa untuk transaksi karena teknik penerapan Load Balancing bermacam-macam, ada Load Balancing dengan berdasarkan sesi (session based) yang mana bila user connect ke aplikasi A dan masih memiliki session, maka user akan terus mengakses aplikasi yang sama. Teknik lainnya yaitu non session based seperti Sticky IP dan teknik lainnya. Untuk database transaksional, teknik tersebut bisa diimplementasikan sehingga memperoleh keuntungan seperti menggunakan clustering database, sehingga Load Balancing sangat disarankan bila ingin membagi beban aplikasi untuk transaksional dengan memecah aplikasi ke beberapa cluster.

Yudi Fhirmanto

Q: Ingin bertanya pendapat bapak. Apa saja yang dikategorikan dalam Enterprise System?

A: Kategori tersebut kita bagi menjadi 3 yaitu Reliability, Availability dan Scalability seperti yang sudah kami jelaskan sebelumnya. Silahkan kunjungi youtube kami di @Equnix Business Solutions untuk penjelasan lebih lanjut.

Ardie

Q: Dear Pak Julyanto. Tadi disebutkan Reliability ada 2 aspek yaitu Kestabilan dan Keamanan Akses serta Data cmiiw. Bila iya maka analoginya harus dengan security dan kestabilannya harus dengan latensi mendekati 100 % kah?

A: Hal tersebut tidak ada hubungannya dengan latency, yang kita bahas adalah bagaimana sebuah sistem diamankan secara konteks Reliability. Reliability dibagi menjadi 2 yaitu Stabilitas dan Keamanan. Stabilitas mencakup bagaimana proses deployment (redeployment dan reinstallation) termasuk bilamana ada bug seperti apa mekanisme untuk bug fix nya. Kemudian dari sisi operasional seperti support system, eskalasi bilamana terjadi masalah, level principle yang menangani dan lain sebagainya. Hal tersebut yang perlu kita pahami ketika mengadopsi sebuah sistem dalam konteks Reliability.

Ardie

Q: Terkait keamanan data ini, apakah sebaiknya kita taruh database tetap di On Premise atau migrasi ke Cloud atau Hybrid? pertimbangannya baiknya seperti apa ya pak.

A: Hal tersebut tergantung pada kondisi Data Center. Bilamana memiliki Data Center yang cukup besar dan membutuhkan keamanan yang cukup tinggi maka akan lebih baik memiliki Data Center sendiri. Baik Cloud ataupun Enterprise Cloud (Managed Service Collocation) memiliki tingkat keamanan yang tinggi, hanya saja masalah kepercayaan kepada vendor tersebut.

Ardie

Q: Bilamana memiliki beberapa server dengan 3 database application, Apa saja yang harus dipersiapkan untuk pemindahan dari On-premise ke Cloud? Apakah harus migrasi 100%? Dan manakah yang lebih baik dari segi keamanan data?

A: Nantinya kami akan mendeliver sebuah dokumen yang akan kami share ke publik dan kita memiliki dokumen ceklis yang tentunya spesifik sebagai bahan acuan dalam menentukan Enterprise Level Application. Kami menyarankan pemindahan tersebut mempertimbangkan tiga aspek yaitu Reliability, Availability dan Scalability yang sudah kita bahas sebelumnya.