Iqbal - PT KAI

Q: Dari sisi security apa saja proteksi yang perlu di implementasikan sebuah perusahaan baik dari EQUNIX dapat mencegah dan melindungi data dari Cyber Threat?

A: Tentunya sangat banyak faktor-faktor security yang bisa kita jaga. Contohnya database, kita bicara mengenai bagaimana cara melakukan hardening terhadap server. Hardening sendiri ada 3 sisi, yaitu dari sisi OS, server yang menjadi environment database tersebut, dimana kita dapat membatasi akses user
Lalu dengan Menerapkan AAA (Authentication, Authorization & Accountable)

1. Authentication: pastikan orang yang mengakses atau berusaha masuk merupakan orang tersebut (dengan menggunakan password, 2FE, HSM, dan lain-lain).
2. Authorization: apakah user tersebut berhak untuk mengakses data tersebut?
3. Accountable/accounting: semua yang dilakukan user harus tercatat (ketika melakukan query, insert, update, dan lain lain)

Metode apalagi untuk melakukan hardening? Hardening bukan dari sisi security aksesnya saja, tentunya dengan tidak menggunakan port-port default, jika dari level database kita terapkan di PostgreSQL ada HBA (host-based authentication). Dari Application seperti apa? Misalkan, menyimpan jika credential di aplikasi, ketika aplikasinya di load ke memori, memorinya dapat kita lihat, kemudian kita bisa sniff lalu dapatlah data. Oleh karena itu juga dari sisi aplikasi tidak boleh menyimpan credentials.
Communication protocol, contohnya di EDIM selain memanfaatkan compression kita juga melakukan encryption, walaupun di sniff di DAM sekalipun. Karena wajib menggunakan PKI (Public Key Infrastructure) sama hal nya pada HTTPS, kita menggunakan SSL certificate untuk meng-encrypt data yang mengalir.
Kira-kira seperti itu untuk mengantisipasi cyber threat, salah satunya enkripsi data. Encrypt data-at-rest, encrypt data-in-transit, encrypt data-in-use. Dan kita sudah tahu cukup banyak case yang terjadi karena penerapan hardening yang masih belum tepat. Jika kita bisa memanfaatkan dan menerapkan hardening dengan baik maka tidak perlu khawatir dengan cyber threat.

Iqbal- PT KAI

Q: Apakah ada fitur automation dari EQUNIX untuk menjaga data kita contohnya backup automation menjadi solusi perlindungan data baik dari database dan server yang berbeda?

A: Kita memiliki metode khusus multi-tier backup, yaitu

1. Full snapshot: Jika kita melakukan copy data menyeluruh, data directory nya copy 100% dilakukan secara weekly (contohnya). Supaya jika data directory corrupt, kita sudah punya backupnya.
2. Incremental backup
   Kita juga mengaktifkan WAL archiving, setiap kali WAL sudah committed, kemudian akan di archive.

Kenapa disebut multi-tier? Karena ada full backup, ada WAL archive nya. Dimana nanti ketika membutuhkan restoration, kita cukup replay dari full snapshot ini. Itu disebut PITR, dilakukan secara formatted. Kita terapkan tools tersebut dan bilamana dibutuhkan, bisa melaksanakan backup dan juga restore.

Iqbal- PT KAI

Q: Terkait lisensinya apakah sudah include dengan support yang ada dan monitoringnya seperti apa?

A: Equnix memiliki produk yang bernama 11DB/PostgreSQL™. Produk ini merupakan salah satu turunan dari PostgreSQL, dan ini adalah licensed product milik Equnix. Sudah include dengan support (24/7 support, preventive maintenance, monitoring, script alerting, dsb).
Di tengah maraknya private cloud di Indonesia, Equnix juga memiliki product Equnix Appliance, yang bukan hanya dari sisi database. Hardwarenya dapat diletakan di kita ataupun client, namun Equnix bisa selalu melakukan akses secara remote. Di dalamnya juga terdapat 11DB/PostgreSQL™ sebagai databasenya. Sebagai one stop solution, Equnix memberikan full set berupa hardware, 24/7 full managed support, monitoring, tools, dan masih banyak fitur lainnya.
EDIM juga termasuk licensed. Namun sifatnya kita akan lihat seberapa banyak database yang masuk, data source, dan lain lain. Untuk supportnya jelas sudah termasuk, hingga monitoring nya juga ada.

Yong Ong

Q: Untuk EDIM extractor apakah support tidak hanya RDBMS? mengingat saat ini ada banyak tipe database, seperti NoSQL DB, Distributed DB, Graph DB dl. Bila support, apakah optimal bila database targetnya hanya menggunakan RDBMS yaitu PostgreSQL? Dan apakah memerlukan tuning-tuning tertentu?

A: EDIM yang saat ini Equnix release baru mensupport RDBMS saja (SQL, MS-SQL, Oracle, PostgreSQL). Untuk diluar tersebut, Equnix memang belum support. Namun selain RDBMS EDIM juga dapat membaca CSV Files. Jika kita memiliki data yang di produce oleh sistem lain non RDBMS, kita akan berusaha untuk load dari CSV tersebut ke dalam database dengan cepat. Contohnya seperti tabel dibawah ini:

Dan apakah optimal? Jika dibilang optimal atau tidak, karena Equnix mendukung PostgreSQL pastinya optimal. Namun tidak menutup kemungkinan jika targetnya bukan PostgreSQL, tapi sourcenya adalah PostgreSQL. Mungkin jika ada kebutuhan juga client ingin push ke Oracle karena mungkin sistem legacynya masih harus menggunakan Oracle, Equnix tetap support. Sehingga jika secara tuning, mungkin saya bisa bagi antara proses EDIM. Ketika load itu tidak berhubungan dengan proses data ini dibaca dari targetnya. Jika misalkan dari aplikasi berusaha untuk membuat reporting dari PostgreSQL yang menjadi target dan tentunya itu konteks yang terpisah yaitu Generating data dan Consuming data. Untuk tuning sendiri jelas sesuai dengan querynya, resource nya seperti apa. Jika misalkan kita bagi transactional apakah sifatnya transactional. Tuningnya seperti apa? Tuning untuk transactional harus dengan secepat mungkin menuliskan WAL untuk menjamin performance. Jika ternyata database tersebut sifatnya OLAP, karena complex query misalnya, kita akan tuning dengan karakteristik OLAP.

Yong Ong

Q: Apakah yang terjadi bila ketika EDIM melakukan ETL dan ditengah jalan terdapat error? Bagaimana memastikan ACID dari data tsb?

A:

1. Jika bicara ACID, kita bicara dari sisi CDC nya dari PostgreSQL. PostgreSQL tidak akan menuliskan transaksi bilamana tidak dilakukan commit. Artinya ada 2 konteks pembicaraan, tentang ACID dan bagaimana caranya EDIM bisa recover. Kita bicara lagi ke dalam logical slot, replication slot yang ada di PostgreSQL. Replication Slot ini hanya akan terisi jika transaksinya sudah di commit. Karena hal ini berhubungan juga dengan WAL nya jadi sebetulnya transaksi yang di commit ini belum masuk ke dalam WAL, itulah kenapa dia tidak direplikasikan ke sebelah. Hal yang sama dalam logical Replication slot, karena logical Replication slot belum ada, maka juga tidak mendapatkan apa-apa sehingga tidak ada yang direplikasikan.
2. Bilamana terdapat crash di tengah. Kembali lagi ke logical Slot, ketika kita create log slot PostgreSQL akan selalu mengisi ke dalam logical slot dan logical slot tidak akan di clean up. Sehingga semua data changes masih ada di logical slot. Kapan akan di clean up? Ketika ada aplikasi yang membaca dari logical slot itu dan mengkonfirmasi bahwa data tersebut telah dibaca. Jika di PostgreSQL terdapat LSN (Logical Sequence Number). Dia bisa mendeteksi sudah dibaca hingga slot ke berapa, dan nanti akan di clean up. Sehingga tidak ada masalah jika EDIM nya crash ataupun di-restart. Jika berbicara di Logical Replication, masih dituliskan data transaksinya ke dalam WAL, WAL ini tidak akan di clean up hingga ada konfirmasi dari aplikasi.

Yong Ong

Q: EDIM ini menarik karena berjalan pada background. berapa besar resource yang diperlukan ketika menjalankan EDIM? Apabila server running 24x7, ketika melakukan ETL apakah tidak mengganggu performa transaksi yang berjalan. Bagaimana best practices?

A: Jadi untuk action-action yang dilakukan EDIM ada 3 macam, diantaranya:

1. Snapshot
2. CDC
3. Incremental patch

Behavior tentu masing-masing berbeda, resource juga. Kalau perlu sinkronisasi 24/7 dan EDIM nya dijalankan, EDIM ini akan dibuat model replikasi/CDC. Tentunya untuk CPU resource, untuk memory resource, kita meminimalisir terjadinya memory leak. Sehingga tidak dibutuhkan memori yang cukup besar. Artinya selama data ini langsung di extract kemudian di load, sudah direlease di EDIM.
Berbeda ketika kita membuat EDIM menjadi mode snapshot, karena bisa saja ketika snapshot ada data-data yang cukup besar, ketika ekstraktornya berjalan dan di push ke dalam di queue ini masih menunggu di consume oleh si transformer, maka akan ada data yang ditampung pada CDC tersebut. Memory footprint yang digunakan EDIM, kecil sekali.
Kemudian untuk transaksi yang bersifat OLTP dari data source nya, tidak akan mengganggu performance dari sisi CDC. Sedikit yang dapat memberikan impact kepada performance, hanya ketika kita menuliskan WAL. Karena WAL level, kita ubah menjadi logical. Untuk mode snapshot/incremental patch (dari database lain) tidak membaca logical slot sebetulnya.
Untuk implementasi table partition, dapat di-enable kan partition pruning sehingga dapat mengakses data hanya untuk child table itu saja. Jika dibandingkan 1 table dengan ukuran 1 milyar data dengan 1 table yang memiliki 10 partition data, akan lebih cepat melakukan select pada child table daripada select parent table-nya langsung. Dengan demikian dapat melakukan select secara paralel. Karena proses nya lebih cepat, maka performance nya pun tidak terlalu terganggu OLTP nya.