MyCDN - Perancangan Kapasiti On-Premises

Pendekatan Sizing: Workload-Driven dengan 5-Year Growth

Sizing ini bukan berdasarkan andaian generik. Ia dikira daripada beban kerja sebenar: jumlah pengguna, transaksi sesaat (TPS), dan keperluan komponen.

Semua angka telah disahkan dengan matematik yang konsisten, bermula dari beban kerja dan berakhir dengan bilangan nodes fizikal.

Strategi Konsolidasi: InterSystems IRIS Platform menggantikan 4 komponen berasingan (ESB, API Gateway, Data Warehouse, ETL) menjadi satu platform bersepadu, mengurangkan kerumitan dan kos infrastruktur secara signifikan.

Mengapa Workload-Driven?

Comparison of Sizing Approaches

Generic Sizing:Menggunakan benchmark umum (contoh: "100 VMs untuk 50,000 users"). Tidak tepat, boleh over-provision atau under-provision.

Workload-Driven (Pendekatan Kami):Bermula dari beban kerja: bilangan pengguna, TPS, komponen spesifik, dan keperluan HA. Setiap komponen disaiz secara individu berdasarkan fungsinya.

Aliran Metodologi Kami

No	Langkah	Penerangan	Output
1	Profil Beban Kerja	Mengenal pasti jumlah pengguna (644,638), peak concurrency (5%), dan TPS (500) daripada keperluan JKDM.	User profile, TPS target
2	Pemetaan Komponen	Menentukan setiap komponen: iTAX COTS, IRIS Platform (ESB+DW+ETL+API), Payment Gateway, Kafka, Redis, Security, Monitoring, dan sebagainya. Setiap komponen disaiz secara berasingan.	Component inventory
3	Pengiraan vCPU per Komponen	Berdasarkan fungsi dan beban: iTAX memerlukan 8 VMs x 16 vCPU, IRIS Platform 4 VMs x 8 vCPU (32-core PROD + 4-core Non-PROD license), EDB Postgres memerlukan 4 VMs x 32 vCPU, dan seterusnya.	Per-component vCPU
4	Agregasi & HA	Jumlah semua komponen: DC PROD = 560 vCPU + Data Platform 16 vCPU = 576 vCPU. Dev 84 vCPU (15%). Total DC = 660. DRC = 256 vCPU (50% compute replica — merujuk kepada compute dan core transactional datasets, bukan keseluruhan storan).	Total allocated vCPU
5	5-Year Growth Model	Growth 10%/year x 5 = 1.61x. Year 5 DC PROD = 576 x 1.61 = 927 vCPU + Dev 84 = 1,011. At 1,536 physical = 66% utilisation.	5-Year node count
6	Pengesahan (Verification)	Semua angka disemak: Day 1 utilisation DC 43% (termasuk Dev), Year 5 ~66%. Headroom 876 vCPU untuk peak dan growth.	Verified sizing

Konsolidasi Platform: InterSystems IRIS

Komponen Digantikan: ESB/Integration Hub (6 VM), API Gateway (4 VM), Data Warehouse (4 VM), ETL Processing (3 VM) = 17 VM, 168 vCPU — semua digantikan oleh InterSystems IRIS Data Platform.

Komponen Baharu: InterSystems IRIS Platform = 4 VM, 32 vCPU (32-core PROD license + 4-core Non-PROD license)

Penjimatan Bersih: -13 VM, -136 vCPU dalam DC sahaja

Justifikasi: IRIS adalah platform bersepadu yang menyediakan Integration Engine, Columnar Data Warehouse, Native ETL/ELT, dan API Management dalam satu stack. Ini mengurangkan kerumitan operasi, titik kegagalan, dan kos pelesenan.

Headroom Philosophy

Sizing 5-Year Growth Ready (Dev pada Nodes PROD): Infrastruktur disaiz supaya pada tahun ke-5 dengan pertumbuhan 10%/tahun, utilisation DC mencapai ~66% (termasuk Dev/SIT/UAT). Dev workload (~84 vCPU, 15% daripada PROD) dijalankan pada nodes production yang sama, menjimatkan kos nodes berasingan. Buffer ~34% mencukupi untuk peak dan emergency.

Parameter	Nilai	Justifikasi
Annual Growth Rate	10%	Industry standard untuk sistem kerajaan
5-Year Growth Factor	1.61x	1.1^5 = 1.61
Target Year 5 Utilisation	66% (DC) / 64% (DRC)	Kedua-dua di bawah sasaran 70%
Day 1 Utilisation (DC)	43%	660 allocated (576 PROD+Data + 84 Dev) / 1,536 physical
Day 1 Utilisation (DRC)	40%	256 allocated / 640 physical

Sizing Termasuk Operational Headroom (5-Year Growth Ready)

Sizing ini 5-Year Growth Ready: DC 32 nodes (1,536 vCPU physical) dengan 660 allocated (termasuk Dev) = 43% Day 1 utilisation -> 66% Year 5.

Headroom 876 vCPU menyediakan operational buffer untuk peak loads dan pertumbuhan jangka pendek tanpa perlu penambahan nod.

Dev/SIT/UAT pada Nodes PROD: Persekitaran pembangunan dijalankan pada nodes production yang sama, menjimatkan nodes berasingan.

Konsolidasi IRIS: InterSystems IRIS menggantikan ESB, API Gateway, Data Warehouse, dan ETL sebagai satu platform bersepadu, mengurangkan bilangan VM secara signifikan.

VM-Based Architecture: Semua komponen aplikasi dan platform MyCDN di-deploy sebagai virtual machines (VMs) pada HPE ProLiant DL360 — termasuk iTAX, IRIS Platform, Kafka, Redis, dan semua services sokongan. Object Storage (StorageGRID) diimplementasi sebagai infrastruktur appliance berasingan dan tidak dikira dalam jumlah VM.

3-Component Architecture: iTAX COTS (teras cukai) + InterSystems IRIS (integrasi + analitik + API) + Payment Gateway (FPX/RPP/JomPAY). IRIS Platform membolehkan konsolidasi 4 komponen menjadi 1, mengurangkan bilangan VM dan kos operasi.

Nodes

32 DC (PDSA) + 20 DRC (KJ)

2,176

Physical vCPU

1,536 DC (PDSA) + 640 DRC (KJ)

916

Allocated vCPU

660 DC (PDSA) + 256 DRC (KJ)

101

Total VMs

68 DC (PDSA) + 33 DRC (KJ)

43%

Day 1 Utilisation

-> 66% Year 5

Definisi Terma Penting

DC (PDSA):Data Centre utama di Pusat Data PDSA — menjalankan semua workload production, dev, dan data platform.

DRC (Kelana Jaya):Disaster Recovery Centre di Kelana Jaya — warm standby, ~50% compute capacity, failover untuk transaksi teras sahaja.

Physical vCPU:Kapasiti fizikal nodes (1,536 DC + 640 DRC = 2,176). Kapasiti untuk 5 tahun pertumbuhan.

Allocated vCPU:vCPU diperuntuk kepada VM (660 DC + 256 DRC = 916). Dev/SIT/UAT dijalankan pada nodes production. Day 1 utilisation DC ~43%.

Core PROD:Beban kerja aplikasi teras = 560 vCPU (iTAX, EDB, IRIS, Kafka, Redis, Security, Monitoring, Management).

PROD + Data:Core PROD + Data Platform (Tableau BI) = 560 + 16 = 576 vCPU.

Total Workload:PROD + Data + Dev = 576 + 84 = 660 vCPU (Day 1 DC allocated).

IRIS Platform:InterSystems IRIS diklasifikasikan sebagai PROD workload kerana ia menyokong transaksi teras, integrasi, dan API runtime. IRIS bukan "Data Platform" — ia adalah komponen produksi aktif.

Data Platform:Merujuk khusus kepada BI visualisation (Tableau) sahaja — 2 VM, 16 vCPU, DC only. DW dan ETL telah diserap ke dalam IRIS (PROD workload).

Non-Production:Dev, SIT, UAT dijalankan pada nodes Production yang sama. Tiada nodes berasingan untuk pembangunan. Dev vCPU (84) dianggap statik dan tidak tertakluk kepada growth factor 10%/tahun.

Ringkasan Infrastruktur On-Premises (5-Year Growth Ready)

Komponen	DC	DRC	Jumlah	Nota
Virtualization Nodes	32	20	52	HPE ProLiant DL360
Physical vCPU	1,536	640	2,176	Kapasiti fizikal nodes (5-year ready)
Allocated vCPU (PROD)	560	256	816	Application workloads
Allocated vCPU (Data Platform)	16	-	16	Tableau BI (DC sahaja)
Total Allocated vCPU (PROD + Data)	576	256	832	PROD + Data Platform
Dev/SIT/UAT (pada Nodes PROD)	+84	-	+84	~15% daripada PROD vCPU (termasuk IRIS 4-core Non-PROD)
Jumlah Termasuk Dev	660	256	916	Keseluruhan beban kerja pada infrastruktur
Day 1 Utilisation	43%	40%	-	DC: 660/1,536, DRC: 256/640
Year 5 Utilisation	66%	64%	-	@ 10%/year growth (PROD grows, Dev static)
RAM	12,288 GB	7,680 GB	19,968 GB	~19TB total (384GB/node)
Aggregate Storage	320 TB	140 TB	460 TB	Usable capacity (5-year ready)
VMs (PROD)	66	33	99	DRC = ~50% VM count
VMs (Data Platform)	2	-	2	Tableau sahaja (DW/ETL consolidated into IRIS)
Total VMs	68	33	101	68 DC = 66 PROD + 2 Data Platform

Sizing 5-Year Ready (Dev pada PROD): DC 32 nodes menyediakan 1,536 vCPU physical dengan 660 allocated (termasuk Dev ~84 vCPU) = 43% Day 1 utilisation. DRC 20 nodes menyediakan 640 vCPU physical dengan 256 allocated = 40% Day 1 utilisation. DC mencapai ~66% utilisation pada Year 5, DRC ~64% (@ 10%/year growth, Dev static).

RAM Sizing Calculation (5-Year Growth Ready)

Growth Factor: 10%/year x 5 years = 1.61x (61% increase)

DC: 32 nodes x 384GB = 12,288 GB

DRC: 20 nodes x 384GB = 7,680 GB

Total RAM: 12,288 + 7,680 = 19,968 GB (~19TB)

5-Year Growth Projection: Memory & Storage (Dev pada PROD)

Resource	Capacity	Year 1	Year 3	Year 5	Status
DC (Primary Data Centre) — termasuk Dev/SIT/UAT
vCPU (PROD + Dev)	1,536	660 (43%)	781 (51%)	1,011 (66%)	OK (<70%)
↳ Dev/SIT/UAT (statik)	—	84	84	84	Tidak berkembang
Storage	320 TB	141 TB (44%)	170 TB (53%)	205 TB (64%)	OK (<70%)
DRC (Disaster Recovery Centre)
vCPU	640	256 (40%)	310 (48%)	412 (64%)	OK (<70%)
Storage	140 TB	62 TB (44%)	74 TB (53%)	90 TB (64%)	OK (<70%)

Nota: DC Year 5 utilisation 66% berada di bawah sasaran 70%. Buffer ~34% mencukupi untuk peak dan emergency. Dev vCPU (84) kekal statik manakala PROD berkembang 10%/tahun.

Penjelasan 320TB vs 205TB: 205TB merupakan unjuran penggunaan sebenar pada Tahun ke-5, manakala 320TB ialah usable capacity envelope — merangkumi retensi data undang-undang, workspace reindexing, dan operational headroom (~35%). Kedua-dua angka adalah betul dan konsisten: 205TB / 320TB = 64% utilisasi Year 5. Semua angka storan dalam dokumen ini adalah usable capacity (bukan raw), selepas overhead protection scheme (RAID/erasure coding) yang digunakan oleh platform storage.

Gambarajah Arsitektur: Bahagian ini menunjukkan rekabentuk infrastruktur on-premises MyCDN termasuk topologi DC (PDSA)-DRC (Kelana Jaya), komponen keselamatan DMZ, aplikasi iTAX/MyCDN, Data Platform, dan aliran data. 100% on-premises. Semua komponen aplikasi dan platform (iTAX, IRIS, Kafka, Redis, Tableau) di-deploy sebagai VM. Object Storage (StorageGRID) adalah infrastruktur appliance berasingan. IRIS menggantikan ESB, Data Warehouse, dan ETL sebagai satu platform bersepadu. Diagram adalah logical representation dan tidak menunjukkan bilangan VM secara literal.

Seni Bina Infrastruktur MyCDN (On-Premises)

Nota Seni Bina: Diagram menunjukkan topologi lengkap DC (PDSA) dan DRC (Kelana Jaya) dengan komponen keselamatan DMZ, aplikasi iTAX/MyCDN, Data Platform (Tableau BI), IRIS Platform (integrasi + analitik), dan pangkalan data PostgreSQL HA. Tiada komponen cloud - 100% on-premises. Semua angka storan dalam rajah adalah usable capacity selepas RAID dan formatting overhead (bukan replikasi DR). Backup storage adalah peruntukan berasingan. Nota Storan: Blok storan individu dalam rajah (70TB SAN, 50TB SAN, 50TB Object Storage) merupakan pengelompokan logikal yang digabungkan menjadi jumlah agregat 320TB DC capacity dalam jadual sizing. Object Storage (StorageGRID) adalah perkhidmatan infrastruktur — bukan VM dalam kiraan Data Platform.

3. VM Distribution Summary

DC VMs by Layer68 VMs

iTAX COTS8 VMs (128 vCPU)

EDB Postgres4 VMs (128 vCPU)

IRIS Integration Platform4 VMs (32 vCPU)

Corrad FPX2 VMs (8 vCPU)

Kafka + Redis10 VMs (64 vCPU)

BMC Helix + Dynatrace6 VMs (24 vCPU)

Bitdefender/Saviynt/Veeam14 VMs (56 vCPU)

HPE Morpheus/GitLab/LB18 VMs (104 vCPU)

Tableau BI (Data Platform)2 VMs (16 vCPU) — DC only

Total DC68 VMs (660 vCPU)

DRC VMs (Core Workloads Only)Kelana Jaya — 33 VMs

iTAX COTS4 VMs (64 vCPU)

EDB Postgres2 VMs (64 vCPU)

IRIS + Corrad FPX3 VMs (20 vCPU)

Kafka + Redis5 VMs (32 vCPU)

BMC Helix + Dynatrace3 VMs (12 vCPU)

Bitdefender/Saviynt/Veeam7 VMs (28 vCPU)

HPE Morpheus/GitLab/LB9 VMs (36 vCPU)

Tableau BI (Data Platform)DC-Only (Not Replicated by Design)

Total DRC33 VMs (256 vCPU)

DC Sizing - 3-Component Architecture dengan IRIS Consolidation

DC 5-Year Ready: 1,536 physical vCPU (32 nodes) dengan 660 allocated (560 PROD + 16 Data + 84 Dev) = 43% Day 1 utilisation -> 66% Year 5.

InterSystems IRIS menggantikan ESB, API Gateway, Data Warehouse, dan ETL - mengurangkan bilangan VM dengan ketara.

Dev/SIT/UAT pada Nodes PROD: Persekitaran pembangunan (~15% daripada PROD = 84 vCPU) dijalankan pada nodes production yang sama. Tiada nodes Dev berasingan.

Dev/Non-PROD Component	vCPU	Nota
InterSystems IRIS Non-PROD	4	4-core Non-Production license (Dev/SIT/UAT)
iTAX Dev + Other Components	80	Baki Dev allocation (iTAX, DB, Kafka, Redis, dll)
Total Dev/SIT/UAT	84	15% x 560 PROD vCPU

1,536

Physical vCPU

32 nodes x 48

660

Allocated vCPU

560 PROD + 16 Data + 84 Dev

43%

Day 1 Utilisation

876 vCPU headroom

Total VMs

66 PROD + 2 Data

DC - Production Components (66 VMs, 560 vCPU) — Klik nombor untuk justifikasi

Component	Perisian (BOM Ref)	VM	vCPU/VM	Total vCPU	RAM/VM	Total RAM
iTAX Core Application	iTAX COTS (.NET/Angular) — 3.1.3	8	16	128	64GB	512GB
Database	EDB Postgres — 3.1.6	4	32	128	128GB	512GB
Integration & Data Platform	InterSystems IRIS Data Platform (Imagelink) — 3.1.4 / 3.1.16 Lesen: 32-core PROD + 4-core Non-PROD	4	8	32	64GB	256GB
Payment Gateway	Corrad FPX Engine — 3.1.15	2	4	8	16GB	32GB
Message Broker	Apache Kafka	6	8	48	32GB	192GB
Cache Layer	Redis	4	4	16	32GB	128GB
Infrastructure & App Monitoring	BMC Helix AIOps & ITSM (600 RU) + Dynatrace APM — 3.1.11 / 3.1.12	6	4	24	16GB	96GB
Load Balancer	HAProxy / F5	4	4	16	8GB	32GB
MDR & PAM	Bitdefender MDR + Pulseway/Delinea PAM — 3.1.17 / 3.1.14	6	4	24	16GB	96GB
Identity & Access Management	Saviynt IAM (16,000 users) — 3.1.18	4	4	16	16GB	64GB
Backup & DR Replication	Veeam Backup & Replication — 3.1.8 / 3.1.13	4	4	16	16GB	64GB
Management & DevOps	HPE Morpheus Enterprise + GitLab Ultimate + RHEL/Win Mgmt — 3.1.9 / 3.1.10 / 3.1.7	14	6	84	16GB	224GB
PROD SUBTOTAL		66	-	560	-	1,984GB

vCPU Reconciliation: 560 = Sum of All Components

Category	Components (Perisian BOM)	vCPU
Core Application	iTAX COTS (128) + EDB Postgres (128)	256
IRIS Integration Platform	InterSystems IRIS — Integration + DW + ETL + API (32-core PROD + 4-core Non-PROD)	32
Payment Gateway	Corrad FPX Engine	8
Messaging & Cache	Apache Kafka (48) + Redis (16)	64
Monitoring & Management	BMC Helix/Dynatrace (24) + LB (16) + HPE Morpheus/GitLab (84)	124
Security & Identity	Bitdefender/Pulseway/Delinea (24) + Saviynt IAM (16) + Veeam (16)	56
Core MyCDN Total		560
PROD TOTAL		560

DC - Data Platform Components (2 VMs, 16 vCPU)

Component	VM	vCPU/VM	Total vCPU	RAM/VM	Total RAM
BI/Reporting (Tableau)	2	8	16	32GB	64GB
DATA PLATFORM SUBTOTAL	2	-	16	-	64GB

Nota: Data Warehouse dan ETL telah dikonsolidasikan ke dalam InterSystems IRIS Platform (dalam seksyen PROD). Tableau kekal sebagai lapisan visualisasi, kini bersambung ke IRIS melalui ODBC/JDBC.

Pengesahan Matematik: DC Physical = 1,536 (32 nodes x 48). DC Allocated = 560 (PROD) + 16 (Data Platform) + 84 (Dev/SIT/UAT @15%) = 660. Day 1 Utilisation = 660/1,536 = 43%. Year 5 (PROD grows @10%/yr, Dev static) = ~66%.

DRC Sizing - Penjelasan Utilisation

DRC mengandaikan partial workload activation semasa failover, bukan full concurrent peak.

Apabila failover berlaku, bukan semua workload diaktifkan serentak pada peak capacity. Pengguna dialihkan secara berperingkat (graceful degradation).

DRC 5-Year Ready: 640 physical vCPU (20 nodes) dengan 256 allocated = 40% Day 1 utilisation -> ~64% Year 5.

640

Physical vCPU

20 nodes x 32

7,680

Physical RAM (GB)

20 nodes x 384GB

256

Allocated vCPU

PROD replicas

40%

Day 1 Utilisation

256/640

Total VMs

~50% of DC PROD

DRC Component Breakdown — Kelana Jaya (33 VMs, 256 vCPU, 1,104 GB RAM)

Component	Perisian (BOM Ref)	DC VM	DRC VM	vCPU/VM	DRC vCPU	RAM/VM	DRC RAM	Notes
iTAX Core Application	iTAX COTS	8	4	16	64	64GB	256GB	50% replica
Database	EDB Postgres — 3.2.3	4	2	32	64	128GB	256GB	Standby only
Integration & Data Platform	InterSystems IRIS (Imagelink)	4	2	8	16	64GB	128GB	DR mirror (within 32-core PROD license)
Payment Gateway	Corrad FPX Engine	2	1	4	4	16GB	16GB	Minimal DR
Message Broker	Apache Kafka	6	3	8	24	32GB	96GB	Minimum quorum
Cache Layer	Redis	4	2	4	8	32GB	64GB	Warm standby
Infrastructure & App Monitoring	BMC Helix + Dynatrace — 3.1.11/3.1.12	6	3	4	12	16GB	48GB	Basic monitoring
Load Balancer	HAProxy / F5	4	2	4	8	8GB	16GB	Active-passive
MDR & PAM	Bitdefender MDR + Pulseway/Delinea — 3.2.8	6	3	4	12	16GB	48GB	Essential security
Identity & Access Management	Saviynt IAM	4	2	4	8	16GB	32GB	Replicated
Backup & DR Replication	Veeam — 3.2.4	4	2	4	8	16GB	32GB	DR backup
Management & DevOps	HPE Morpheus + GitLab — 3.2.5/3.2.6	14	7	4	28	16GB	112GB	Basic management
DRC TOTAL		66	33	-	256	-	1,104GB	~50% of DC (compute)

Nota "50% Replica": Nisbah 50% merujuk kepada compute (vCPU dan VM count) serta core transactional datasets sahaja — bukan keseluruhan storan. DRC storage = 140TB (44% daripada DC 320TB) kerana Data Lake (~50TB Object Storage) dan BI tidak direplikasi ke DRC.

DRC Failover Strategy: Hot-warm standby. Database replicas sentiasa synchronised. Application VMs dalam warm state. Graceful degradation: non-critical workloads dikurangkan. DRC mereplikasi beban kerja transaksional dan integrasi teras sahaja. Tableau BI adalah DC-Only kerana BI/reporting tidak diperlukan semasa failover DR.

DRC RAM Sizing

VM Allocated RAM: 1,104 GB (from table above)

Physical RAM: 20 nodes x 384 GB = 7,680 GB

RAM Utilisation: 1,104 / 7,680 = 14%

Data Platform Consolidation - IRIS + Tableau

InterSystems IRIS Data Platform telah mengambil alih peranan Data Warehouse dan ETL. Data Platform kini hanya mengandungi Tableau sebagai lapisan visualisasi BI.

IRIS Platform (dalam seksyen PROD) menyediakan: Columnar Data Warehouse (258x lebih pantas), Native ETL/ELT, Embedded Python, dan sambungan ODBC/JDBC ke Tableau.

Implikasi: Data Platform berkurang daripada 9 VM (104 vCPU) ke 2 VM (16 vCPU). Penjimatan 7 VM dan 88 vCPU.

Data Platform Components (DC Only)

Component	Location	vCPU	RAM	Status	Notes
Data Warehouse	IRIS Platform	-	-	Consolidated into IRIS	Columnar storage, 258x faster analytical queries
ETL/ELT Processing	IRIS Platform	-	-	Consolidated into IRIS	Native ETL with Embedded Python
BI/Reporting (Tableau)	DC Only	16	64GB	Active	Connects to IRIS via ODBC/JDBC
Data Lake / Object Storage	DC Only	-	-	Retained	Raw files, PDFs, unstructured data (~50TB)
DATA PLATFORM VM TOTAL	DC Only	16	64GB		IRIS handles DW+ETL within PROD allocation

Storage Comparison: DC vs DRC — Klik nombor untuk justifikasi

DC Storage (5-Year)320TB

Server Storage (VMs)123TB

SAN Storage (Database)115TB

Object Storage (Data Lake)50TB

Backup/Overhead32TB

Total DC320TB

DRC Storage (5-Year)Kelana Jaya — 140TB

Server Storage (VMs)57TB

SAN Storage (Database)81TB

Object Storage0TB (DC-Only by Design)

Total DRC140TB

Nota Rekonsiliasi Storan: Blok storan dalam rajah arsitektur (70TB, 50TB, 50TB) merupakan pengelompokan logikal yang digabungkan menjadi 320TB DC aggregate di atas. Angka dalam rajah = usable capacity selepas RAID dan formatting overhead (bukan replikasi DR). Object Storage (StorageGRID) adalah perkhidmatan infrastruktur appliance-based — bukan VM dalam kiraan Data Platform (2 VM / 16 vCPU).

Jawapan "Kenapa DR storage rendah?": DRC (140TB) = ~44% DC (320TB) kerana Data Lake (~50TB) tidak replicated ke DRC. DRC hanya mereplikasi core transactional & integration data — minimum recovery footprint untuk failover. RTO semasa DR memberi keutamaan kepada pemulihan transaksi teras (iTAX, EDB, IRIS); dokumen (Object Storage) dan BI (Tableau) dipulihkan selepas fasa stabilisasi DR.

Capacity Verification - Matematik Pengesahan

Check	DC Allocated	DC Physical	DRC Allocated	DRC Physical	Status
vCPU (PROD)	560	1,536	256	640	OK
vCPU (Data Platform)	16	-	-	-	OK (DC only, Tableau)
vCPU (Dev/SIT/UAT @15%)	84	-	-	-	Pada nodes PROD (incl. IRIS 4-core Non-PROD)
vCPU Total	660	-	256	-	DC 43%, DRC 40% Day 1
Day 1 Utilisation	660 / 1,536 = 43%	-	256 / 640 = 40%	-	5-Year Ready (~66% DC, ~64% DRC at Year 5)
DC Headroom	876 vCPU	-	-	-	Operational buffer
VM Count (PROD)	66	-	33	-	DRC = 50% DC (33/66)
VM Count (Data Platform)	2	-	0	-	Tableau DC only
Total VMs	68	-	33	-	DC: 66 PROD + 2 Data = 68
IRIS License Check	4 VM x 8 = 32 cores	-	2 VM x 8 = 16 cores	-	32-core PROD + 4-core Non-PROD; DRC within PROD license

Formula Verification

DC Calculation

Physical vCPU32 nodes x 48 = 1,536

PROD Allocated560 vCPU

Data Platform16 vCPU (Tableau)

Dev/SIT/UAT84 vCPU (15% of PROD, incl. IRIS 4-core)

Total Allocated560 + 16 + 84 = 660

Day 1 Utilisation660 / 1,536 = 43%

Headroom876 vCPU

DRC Calculation

Physical vCPU20 nodes x 32 = 640

PROD Allocated256 vCPU

Data Platform0 (not replicated)

Total Allocated256

Day 1 Utilisation256 / 640 = 40%

StatusOK (5-Year Ready)

Verification Complete: Semua nombor konsisten. DC = 43% Day 1 utilisation (termasuk Dev). DRC = 40% Day 1 utilisation. DC ~66% at Year 5, DRC ~64% at Year 5. Kedua-dua di bawah sasaran 70%.

Pernyataan Arsitektur Utama: iTAX merupakan aplikasi monolitik berasaskan .NET (runtime lintas-platform) dengan frontend Angular, dideploy pada Linux VM (RHEL 8/9). InterSystems IRIS Data Platform (32-core PROD + 4-core Non-PROD license) menggantikan ESB, Data Warehouse, ETL, dan API Gateway sebagai satu platform bersepadu.

Component Architecture (Mapped to BOM Perisian)

1. iTAX COTS (3.1.3): Aplikasi monolitik berasaskan .NET dengan Angular frontend, di-host pada Linux VMs (RHEL — 3.1.5). Database: EDB Postgres (3.1.6).

2. InterSystems IRIS Data Platform (3.1.4 / 3.1.16): Platform bersepadu yang menyediakan Integration Engine (ESB), Columnar Data Warehouse, Native ETL/ELT, dan API Management. Berjalan pada 4 VM DC. Lesen: 32-core Production + 4-core Non-Production.

3. Corrad FPX Engine (3.1.15): Modul pembayaran FPX/RPP/JomPAY yang berjalan pada 2 VM DC. Komponen ringan untuk integrasi bank dan pembayaran elektronik.

4. Supporting Services: Apache Kafka (async messaging), Redis (caching), BMC Helix AIOps & ITSM + Dynatrace APM (3.1.11/3.1.12), Bitdefender MDR (3.1.17), Saviynt IAM (3.1.18), Pulseway/Delinea PAM (3.1.14), Veeam Backup (3.1.8), HPE Morpheus Enterprise (3.1.9/3.1.10), GitLab Ultimate (3.1.7).

Core Application Architecture

Aspect	Specification	Implication
Runtime	.NET (lintas-platform / cross-platform)	Linux (RHEL 8/9), tiada kebergantungan Windows
Architecture Pattern	Monolithic with modular components	Not microservices, not independently scalable
Integration Platform	InterSystems IRIS	Unified ESB + DW + ETL + API in single stack
Scaling Model	Vertical + horizontal VM cloning	Not elastic auto-scaling
Deployment Unit	Linux VM (RHEL 8/9)	Full application per VM, not container pods
IRIS License	32-core PROD + 4-core Non-PROD	4 VM DC (PROD) + 2 VM DRC (DR mirror within PROD license)

Application Components — Mapped to BOM Perisian

Component	Perisian (BOM Ref)	Type	Role	DC VMs
iTAX Core	iTAX COTS .NET (3.1.3) on RHEL (3.1.5)	Core Engine	Tax processing	8
Database	EDB Postgres (3.1.6)	Core Engine	Transaction store	4
Integration & Data Platform	InterSystems IRIS Data Platform (3.1.4 / 3.1.16) 32-core PROD + 4-core Non-PROD	Integration	ESB + DW + ETL + API	4
Payment Gateway	Corrad FPX Engine (3.1.15)	Integration	FPX/RPP/JomPAY	2
Message Broker	Apache Kafka	Supporting	Async decoupling	6
Cache	Redis	Supporting	Session & reference data	4
BI / Reporting	Tableau Server	Analytics	Dashboard & visualisation	2
Monitoring (Infra + App)	BMC Helix AIOps & ITSM (3.1.11) + Dynatrace APM (3.1.12)	Operations	Infra & app performance	6
MDR & PAM	Bitdefender MDR (3.1.17) + Pulseway/Delinea PAM (3.1.14)	Security	Endpoint & privileged access	6
IAM	Saviynt IAM — 16,000 users (3.1.18)	Security	Identity & access management	4
Backup & DR	Veeam Backup & Replication (3.1.8 / 3.1.13)	Operations	Backup & DRC replication	4
Hypervisor & Management	HPE Morpheus Enterprise (3.1.9 / 3.1.10)	Infrastructure	Virtualisation management	—
Developer Tools	GitLab Ultimate + Essentials (3.1.7)	DevOps	CI/CD, source control	14*
Load Balancer	HAProxy / F5	Network	Traffic distribution	4
SSL Certificate	DV SSL — 30 units (3.1.19)	Security	HTTPS encryption	—
TOTAL DC PROD				66

* Management & DevOps — 14 VMs shared across HPE Morpheus, GitLab, OS management (RHEL/Windows), Active Directory, and operational tooling. HPE Morpheus runs on bare metal but management VMs are included. SSL certificates do not require dedicated VMs.

Komponen yang Dikonsolidasikan oleh IRIS

Komponen Lama	Teknologi Lama	VM Lama	Status Baharu
API Gateway	Standalone API GW	4 VM (32 vCPU)	Digantikan oleh IRIS API Management
ESB / Integration Hub	Standalone ESB	6 VM (48 vCPU)	Digantikan oleh IRIS Integration Engine
Data Warehouse	Standalone MPP	4 VM (64 vCPU)	Digantikan oleh IRIS Columnar Storage
ETL Processing	Standalone ETL	3 VM (24 vCPU)	Digantikan oleh IRIS Native ETL/ELT
MyCDN Custom Modules	Java	12 VM (96 vCPU)	Diserap ke iTAX/IRIS
Jumlah Dibuang		29 VM (264 vCPU)

User Concurrency Model

Parameter	Value	Derivation
Total Registered Users	644,638	From JKDM requirements (5 tax systems)
Peak Concurrent User %	5%	Industry standard for tax systems
Peak Concurrent Users	~32,200	644,638 x 5%
Peak TPS	500	Based on concurrent users and transaction patterns

Anggaran Pelayan & Pengguna Mengikut Aplikasi

MyCDN adalah platform bersepadu (consolidated). Semua 5 sistem cukai berkongsi infrastruktur yang sama — pelayan, rangkaian, keselamatan, dan pangkalan data digunakan secara bersama.

Jadual ini menunjukkan anggaran pecahan sumber mengikut aplikasi berdasarkan nisbah pengguna berdaftar.

Anggaran Pelayan Mengikut Aplikasi

Aplikasi	Pengguna Berdaftar	% Nisbah	Production (11 Pelayan Dikongsi)	DRC (7 Pelayan Dikongsi)	Utilisation (Day 1 → Year 5)	Concurrent User (5% Peak)
MyGST	460,000	71.4%	11 Pelayan 8 App + 3 DB (Shared Platform)	7 Pelayan 4 App + 3 DB (Shared Platform)	43% → 66%	23,000
MySST	180,000	27.9%				9,000
MyTTx	4,000	0.6%				200
MySToDS	500	0.1%				25
MyLVG	138	0.02%				7
JUMLAH	644,638	100%	11 Pelayan	7 Pelayan	43% → 66%	~32,232

Nota Penting: Nodes Production dan DRC adalah shared/consolidated platform. Semua 5 aplikasi berjalan pada set nodes yang sama. Pecahan nisbah adalah berdasarkan jumlah pengguna berdaftar dan digunakan sebagai anggaran sahaja. Pada infrastruktur fizikal, workload diagihkan secara dinamik oleh hypervisor.

Pecahan Terperinci Pelayan Fizikal

DC Production (11 Pelayan) PDSA

App Cluster8 × HPE ProLiant DL360

DB Cluster3 × HPE ProLiant DL360

Dev/SIT/UATPada nodes App Cluster

Jumlah11 Pelayan

Utilisation43% Day 1 → 66% Year 5

DRC (7 Pelayan) Kelana Jaya

App Cluster4 × HPE ProLiant DL360

DB Cluster3 × HPE ProLiant DL360

Jumlah7 Pelayan

Utilisation40% Day 1 → 64% Year 5

Derivasi Concurrent Users

Parameter	Nilai	Penerangan
Jumlah Pengguna Berdaftar	644,638	Gabungan 5 sistem cukai (MyGST + MySST + MyTTx + MySToDS + MyLVG)
Peak Concurrent %	5%	Industry standard untuk sistem percukaian
Peak Concurrent Users	~32,232	644,638 × 5%
Peak TPS (Backend)	500	Berdasarkan concurrent users dan corak transaksi
Peak Frontend RPS	~5,000	500 TPS × 10 (frontend:backend ratio)

Kenapa Shared Platform?

Kelebihan Konsolidasi: Daripada membina 5 set infrastruktur berasingan untuk setiap aplikasi cukai, MyCDN menggabungkan semuanya dalam satu platform bersepadu. Ini mengurangkan kos, memudahkan pengurusan, dan membolehkan perkongsian sumber secara optimum.

Dynamic Resource Allocation: Hypervisor mengagihkan sumber secara automatik berdasarkan beban kerja semasa. Apabila MyGST sibuk (musim penyata cukai), sumber diperuntuk lebih kepada MyGST. Apabila kurang sibuk, sumber dikembalikan untuk aplikasi lain.

Dev/SIT/UAT: Persekitaran pembangunan (~84 vCPU, 15% daripada PROD — termasuk IRIS 4-core Non-PROD) turut dijalankan pada nodes production yang sama, menjimatkan nodes berasingan.

Jadual Perisian & Pelesenan — Pemetaan BOM ke Infrastruktur

Bahagian ini menjawab soalan: "VM ini untuk apa?", "Lesen ini untuk apa?", "Kenapa 4 DB?", "Kenapa perlu perisian ini?"

Setiap perisian dalam BOM Lampiran 3.1 dipetakan kepada VM spesifik, kuantiti, dan justifikasi teknikal. Klik nombor untuk penjelasan lanjut.

BOM Perisian DC (3.1.x): 19 item perisian untuk Data Centre utama. Setiap item dipetakan kepada VM, kuantiti lesen, dan fungsi dalam seni bina MyCDN. Klik nombor berwarna biru untuk justifikasi terperinci.

Pemetaan BOM Perisian DC ke VM & Justifikasi

BOM	Kategori Perisian	Jenama / Produk	VM	vCPU	Jenis Lesen	Untuk Apa? (Justifikasi)
Sistem Pengoperasian (OS)
3.1.1	OS VM	RHEL Virtual Datacenter + Windows Server 2025	—	—	Per-Socket	OS asas untuk semua 66 VM Production. RHEL = 63 VM Linux (iTAX, IRIS, Kafka, Redis, dll). Windows = 3 VM (AD, Backup, WSUS). Tanpa OS, tiada VM boleh berjalan.
3.1.2	OS Standalone Backup	Windows Server 2025	1	4	Std License	Backup server berdiri sendiri (standalone) — menjalankan Veeam console. Windows diperlukan kerana Veeam management console native Windows.
Aplikasi Teras & Integrasi
3.1.3	COTS Sistem Utama	iTAX (.NET/Angular)	8	128	Dalam Sistem	Enjin cukai utama. Memproses semua transaksi 5 sistem cukai (MyGST, MySST, MyTTx, MySToDS, MyLVG) — filing, penilaian cukai, pembayaran, notis. 644,638 pengguna berdaftar, 500 TPS peak.
3.1.4	Integrasi Luaran	InterSystems IRIS Data Platform (Imagelink)	4	32	32-core PROD + 4-core Non-PROD	Integrasi dengan agensi LUAR — SSM, JPN, DOSM, MOF, IGFMAS, JIM, Paynet-FPX, Data Pos, iPathu/SMK, dan 15+ lagi. IRIS sebagai ESB menggantikan 75+ sambungan point-to-point.
3.1.5	Integrasi Dalaman	InterSystems IRIS Data Platform (Imagelink)	4	32	32-core PROD + 4-core Non-PROD	Integrasi antara 5 sistem cukai DALAMAN + OLAP consolidation point — MyGST↔MySST data tie hanya berlaku di DW (bukan di OLTP). Cross-tax operations seperti Seksyen 27A, bayar multiple tax sekaligus, dashboard MOF — semuanya melalui IRIS DW.
Pangkalan Data
3.1.6	Pangkalan Data	EDB PostgreSQL	4	128	320 Units	Pangkalan data transaksi (OLTP). Setiap sistem cukai mempunyai schema/instance berasingan — MyGST, MySST, MyTTx, MySToDS, MyLVG masing-masing diasingkan. DB tidak digabung supaya migrasi boleh dilakukan system-by-system tanpa risiko data tie. Konsolidasi cross-tax hanya berlaku di IRIS DW (OLAP), bukan di sini.
DevOps & Pembangunan
3.1.7	Developer Tools	GitLab Ultimate + Essentials	3	18	50 Users, 3-Yr	CI/CD dan source control. Setiap perubahan kod iTAX/IRIS mesti melalui pipeline automatik — unit test, security scan, staging deploy, approval. Tanpa GitLab, deployment manual = berisiko tinggi untuk sistem cukai negara.
Backup, Recovery & Virtualisation
3.1.8	Backup & Recovery	Veeam Backup & Replication	2	8	Per-VM	Backup harian semua VM. Recovery Point Objective (RPO) < 24 jam. Keupayaan instant VM recovery — jika VM corrupt, restore dalam minit. Mandatory untuk sistem kewangan kerajaan.
3.1.9	Hypervisor	HPE Morpheus Enterprise	3*	12	Platform	Virtualisation dan orchestration. Mengurus semua 68 VM pada 32 nodes — provisioning, migration, resource allocation, monitoring. Tanpa hypervisor, tiada VM boleh wujud.
3.1.10	Virtualization Manager	(Termasuk dalam HPE Morpheus)	—	—	Inkl.	Termasuk dalam 3.1.9. Morpheus Enterprise menyediakan kedua-dua hypervisor dan management console dalam satu platform.
3.1.13	DRC Replication	Veeam	2	8	Replication	Replikasi berterusan DC→DRC. Berbeza dari backup (3.1.8) — replication berjalan secara continuous, bukan scheduled. Memastikan DRC sentiasa synchronised untuk failover pantas.
Pemantauan & Pengurusan
3.1.11	Infrastructure Monitoring	BMC Helix AIOps & ITSM	3	12	600 RU	Pemantauan infrastruktur + ITSM. (1) Memantau kesihatan semua 52 nodes, 101 VMs, switches, firewalls. (2) ITSM — incident ticketing, change management, SLA tracking. (3) AIOps — AI mengesan anomali sebelum ia menjadi outage.
3.1.12	App Performance Monitoring	Dynatrace	3	12	Per-Host	Pemantauan prestasi aplikasi (APM). Berbeza dari BMC (infra) — Dynatrace memantau dalam aplikasi: response time setiap API call, database query lambat, memory leak, error rate. Jika iTAX lambat, Dynatrace tunjuk WHERE dan WHY.
3.1.14	Remote Monitoring & Management	Pulseway + Delinea PAM	3	12	45 Users	Remote monitoring + kawalan akses istimewa. Pulseway: pegawai JKDM pantau infra dari mana-mana. Delinea PAM: SETIAP akses admin ke server direkod — siapa, bila, buat apa. Mandatory untuk audit kerajaan.
Pembayaran
3.1.15	Payment Gateway	Corrad Software (FPX Engine)	2	8	Dalam Sistem	Gerbang pembayaran elektronik. Menyambung iTAX ke rangkaian bank — FPX (online banking), RPP (real-time payment), JomPAY. Setiap pembayaran cukai mesti melalui gateway ini.
Analitik & Data
3.1.16	Data Analytics & DW	InterSystems IRIS Data Platform (PQC Ready)	—	—	Inkl. 3.1.4	Data warehouse (OLAP) + analitik — satu-satunya titik konsolidasi data merentas 5 sistem cukai. Di peringkat OLTP (EDB), setiap sistem DB asing-asing. Di sini baru data "ditie" — Seksyen 27A (pelarasan hutang cukai merentas pelbagai jenis), bayar multiple tax sekaligus, dashboard MOF, trend kutipan. PQC Ready.
Keselamatan & Identiti
3.1.17	Managed Detection & Response	Bitdefender MDR	3	12	200 Agents	Perlindungan endpoint + MDR 24/7. Ejen pada setiap VM mengesan malware, ransomware, dan APT. MDR = Bitdefender SOC memantau dan bertindak balas terhadap ancaman secara proaktif — bukan sekadar antivirus pasif.
3.1.18	Identity & Access Management	Saviynt IAM	4	16	16,000 Users	Pengurusan identiti & akses. Satu titik SSO untuk semua pengguna — pembayar cukai, pegawai JKDM, admin, vendor. Kawalan siapa boleh akses apa, MFA, audit trail setiap login. Mandatory untuk sistem kerajaan.
3.1.19	SSL Certificate	DV SSL	—	—	30 Units	Sijil HTTPS untuk semua domain. Menyulitkan semua trafik antara pembayar cukai dan portal cukai. Tanpa SSL, data cukai terdedah kepada penyadapan. 30 sijil = semua domain, subdomain, API endpoint.

Ringkasan: BOM Perisian → VM Mapping

Kategori	BOM Ref	DC VM	vCPU
Aplikasi Teras (iTAX)	3.1.3	8	128
Integrasi & Analitik (IRIS)	3.1.4 / 3.1.5 / 3.1.16	4	32
Pangkalan Data (EDB)	3.1.6	4	128
Payment Gateway	3.1.15	2	8
Messaging & Cache	(Kafka + Redis)	10	64
Monitoring (BMC + Dynatrace)	3.1.11 / 3.1.12	6	24
Security (MDR + PAM + IAM)	3.1.14 / 3.1.17 / 3.1.18	10	40
Backup & Replication	3.1.8 / 3.1.13	4	16
Management & DevOps	3.1.7 / 3.1.9 / 3.1.10	18	120
JUMLAH DC (termasuk Data Platform)		68*	576*

* Termasuk 2 VM Tableau (16 vCPU) dalam Data Platform. Kafka dan Redis tidak disenaraikan dalam BOM Perisian kerana ia adalah komponen open-source tanpa lesen komersial — tetapi memerlukan VM dedicated. LB (HAProxy) juga open-source. Total termasuk Dev = 660 vCPU.

BOM Perisian DRC (3.2.x): DRC hanya memerlukan subset perisian DC — fokus kepada komponen kritikal untuk failover sahaja.

Pemetaan BOM Perisian DRC ke VM & Justifikasi

BOM	Kategori	Jenama / Produk	DRC VM	vCPU	Untuk Apa? (Justifikasi)
3.2.1	OS Standalone Backup	Windows Server 2025	1	4	DRC backup server — menerima replicated data dari DC dan menguruskan backup lokal DRC.
3.2.2	OS Standalone AD	Windows Server 2025	1	4	Active Directory replica di DRC — memastikan authentication berfungsi walaupun DC gagal. Tanpa AD, tiada pengguna boleh login semasa failover.
3.2.3	Pangkalan Data	EDB PostgreSQL	2	64	Standby replica pangkalan data utama. Streaming replication dari DC memastikan data sentiasa synchronised. Semasa failover, promote ke Primary.
3.2.4	Backup & Recovery	Veeam	2	8	DRC backup — menguruskan backup lokal DRC VMs dan menerima replicated backups dari DC.
3.2.5	Hypervisor	HPE Morpheus Enterprise	2*	8	Hypervisor dan management untuk 20 DRC nodes. Mengurus semua 33 DRC VMs.
3.2.6	Virtualization Manager	(Termasuk dalam Morpheus)	—	—	Termasuk dalam 3.2.5.
3.2.7	Windows Server User CAL	Windows Server 2025	—	—	Client Access License untuk Active Directory DRC — membenarkan pengguna authenticate melalui AD DRC semasa failover.
3.2.8	MDR	Bitdefender	1	4	Endpoint protection pada DRC. Walaupun DRC warm standby, ia mesti dilindungi kerana semasa failover ia menjadi production environment.

Kenapa DRC kurang perisian? DRC hanya memerlukan komponen untuk operasi failover — database replica, backup, security, dan management. Perisian seperti GitLab (DevOps), Dynatrace (APM terperinci), dan Saviynt IAM full-stack tidak diperlukan di DRC kerana pembangunan dan analitik mendalam tidak berlaku semasa DR mode. BMC Helix dikurangkan kepada basic monitoring sahaja.

BOM Perisian CPC (3.3.x): Perisian untuk Customs Processing Centre — workstation dan document management. Bukan bahagian infrastruktur pelayan.

Perisian CPC (Workstation & DMS)

BOM	Kategori	Jenama / Produk	Untuk Apa?
3.3.1	Document Management System	iTax DMS	Sistem pengurusan dokumen kastam — scanning, indexing, archival dokumen fizikal (manifes, invois, deklarasi). Termasuk dalam sebut harga sistem.
3.3.2	Pangkalan Data DMS	PostgreSQL	Pangkalan data untuk DMS — menyimpan metadata dan indeks dokumen yang diimbas.
3.3.3	OS Komputer Riba / PC	Red Hat Enterprise Linux	OS untuk workstation CPC — memastikan keserasian dengan portal MyCDN dan keselamatan endpoint.
3.3.4	Perisian Pejabat	Microsoft O365	Suite pejabat — Word, Excel, PowerPoint, Outlook untuk pegawai CPC. Email dan collaboration tools.

Soalan Lazim Penilaian: Bahagian ini menjawab soalan yang sering ditanya oleh panel penilai mengenai pemilihan perisian, kuantiti, dan justifikasi.

Soalan & Jawapan Justifikasi Perisian

S1: Kenapa 4 VM Database (EDB Postgres) — dan kenapa DB asing-asing?

Jawapan (Seni Bina OLTP vs OLAP):

MyCDN mengasingkan OLTP (transaksi) daripada OLAP (analitik) secara sengaja:

• EDB PostgreSQL (OLTP) — 4 VM: Setiap sistem cukai (MyGST, MySST, MyTTx, MySToDS, MyLVG) mempunyai schema/instance database berasingan. DB tidak digabung di peringkat transaksi.

• IRIS Data Warehouse (OLAP): Konsolidasi cross-tax hanya berlaku di sini — contohnya pembayaran Seksyen 27A (pelarasan hutang cukai merentas pelbagai jenis cukai), bayar multiple tax sekaligus, dashboard MOF, dan BI reporting.

Kenapa DB asing-asing (tidak digabung)?

• Strategi migrasi: Migrasi dilakukan system-by-system, modul-by-modul. Kalau combine, risiko satu migrasi gagal akan menjejaskan sistem lain — projek jadi lambat.

• Isolation risiko: Jika ada isu data tie pada satu sistem (contoh: MyGST), sistem lain (MySST, MyTTx) tidak terjejas. Di peringkat apps, DB masing-masing. Hanya di DW baru data dikaitkan.

• Prestasi: Setiap sistem ada corak query yang sangat berbeza. Gabung = contention. Asing = setiap sistem optimum.

Kenapa 4 VM (bukan 2)?

• 2 Primary (active) + 2 Replica (streaming replication) = zero-downtime failover + read scaling + patching tanpa downtime.

S1b: Kenapa DB asing-asing di OLTP tapi consolidated di DW (OLAP)?

Ini keputusan reka bentuk utama MyCDN:

Kalau tengok dari sisi apps & pelaksanaan — setiap sistem cukai (MyGST, MySST, MyTTx, MySToDS, MyLVG) mempunyai terlalu banyak perbezaan di peringkat database (schema, business rules, data model). Kalau combine semua dalam satu DB, risiko besar:

• Data tie issues: Satu perubahan pada MyGST boleh break MySST queries. Cross-system dependencies = fragile.

• Migrasi jadi sukar: Tidak boleh migrate system-by-system. Satu gagal = semua stuck. Projek jadi lambat.

• Prestasi terjejas: 5 sistem competing untuk resources yang sama = contention, slow queries.

Penyelesaian:
① OLTP (EDB Postgres): DB asing-asing. Setiap sistem manage data sendiri. Migrate modul by modul, system by system. Isu satu sistem tidak menjejaskan yang lain.
② OLAP (IRIS DW): Data dari semua 5 sistem dikumpul dan "ditie" di sini sahaja. Cross-tax operations berlaku di DW — Seksyen 27A (pelarasan hutang cukai merentas pelbagai jenis, payment boleh bayar multiple tax sekaligus atau multiple TP sekaligus), dashboard MOF, BI reporting.

Ringkasan: Apps side → DB lelain. DW je baru masukkan tie. Ini dari perspektif apps & pelaksanaan.

S2: Kenapa IRIS sahaja menggantikan ESB + DW + ETL + API Gateway?

Jawapan: InterSystems IRIS adalah platform bersepadu, bukan sekadar database:

• Integration Engine (ESB): Routing, transformation, orchestration — menggantikan standalone ESB (6 VM lama)

• Columnar Data Warehouse (OLAP): 258× lebih pantas untuk analytical queries — menggantikan standalone DW (4 VM lama). Ini adalah satu-satunya titik di mana data semua 5 sistem cukai dikaitkan (consolidated). Contoh: Seksyen 27A (pelarasan hutang cukai merentas MyGST+MySST), pembayaran pelbagai cukai sekaligus, dashboard MOF.

• Native ETL/ELT: Data transformation dengan Embedded Python — menggantikan standalone ETL (3 VM lama)

• API Management: Service routing — menggantikan standalone API GW (4 VM lama)

Mengapa consolidation di IRIS DW dan bukan di EDB PostgreSQL?

• Di peringkat OLTP (EDB), setiap sistem cukai DB asing-asing — ini sengaja supaya migrasi boleh system-by-system, dan isu satu sistem tidak menjejaskan yang lain.

• Di peringkat OLAP (IRIS DW), baru semua data "ditie" — kerana analytical queries, cross-tax reporting, dan compliance (27A) memerlukan pandangan menyeluruh merentas semua 5 sistem.

Penjimatan: Dari 17 VM (168 vCPU) → 4 VM (32 vCPU). Penjimatan bersih: 13 VM, 136 vCPU.

S3: Kenapa perlu DUA sistem monitoring (BMC Helix + Dynatrace)?

Jawapan: Mereka memantau perkara BERBEZA:

• BMC Helix AIOps & ITSM (3.1.11): Memantau infrastruktur — CPU nodes, RAM usage, storage health, network latency, switch status. Plus ITSM: incident ticketing, change management, SLA tracking.

• Dynatrace (3.1.12): Memantau dalam aplikasi — response time setiap API call, SQL query lambat, memory leak .NET, error rate per endpoint. Memberitahu "iTAX lambat kerana query X di database Y mengambil 3 saat".

Analogi: BMC = doktor umum (periksa badan keseluruhan). Dynatrace = pakar khusus (periksa organ spesifik yang sakit).

S4: Kenapa perlu Veeam berasingan untuk Backup (3.1.8) dan Replication (3.1.13)?

Jawapan: Backup dan replication adalah fungsi yang berbeza sepenuhnya:

• Backup (3.1.8): Salinan berkala (scheduled) — setiap malam. Untuk recovery jika data rosak, virus, atau kesilapan manusia. Retention: 30 hari harian + 12 bulan bulanan.

• Replication (3.1.13): Salinan berterusan (continuous) DC→DRC. Untuk failover pantas jika keseluruhan DC gagal. RPO < 15 minit.

Kenapa bukan satu sahaja? Replication tanpa backup = jika data corrupt di DC, corruption replicate ke DRC juga. Backup tanpa replication = RPO 24 jam (kehilangan 1 hari data jika DC gagal).

S5: Kenapa Saviynt IAM 16,000 users — bukan 644,638?

Jawapan: 16,000 users adalah untuk pengguna dalaman dan pentadbiran:

• 17,450 pegawai JKDM (bukan semua serentak — IAM handle provisioning/deprovisioning)

• Admin, vendor, dan external auditors

• 644,638 pembayar cukai authenticate melalui MyKastam portal SSO — bukan melalui Saviynt secara langsung. Saviynt mengurus role-based access untuk pegawai, bukan untuk public user login.

S6: Kenapa 8 VM iTAX — bukan 4 sahaja?

Jawapan: 8 VM = 4 active + 4 warm standby (HA pair):

• 4 VM aktif: Setiap VM disaiz pada ~125 TPS (initial sizing baseline). 4 × 125 = 500 TPS peak capacity. Angka 125 TPS/VM adalah bounded assumption yang akan disahkan melalui performance test (UAT perf) untuk 5–7 transaksi kritikal sebelum go-live.

• 4 VM warm standby: Disediakan dalam load balancer pool (disabled by default) dan diaktifkan secara automatik bila health check gagal atau ketika rolling maintenance. Bukan cold standby — VM sudah up dan pre-loaded, hanya belum menerima traffic.

• 16 vCPU/VM: Target steady-state CPU 60–70% pada peak. 16 vCPU dipilih (vs 12 atau 8) untuk mengelakkan GC pressure + thread contention di .NET ketika traffic spike. 12 cores untuk tax processing + 4 cores buffer (GC, background tasks, health check endpoints).

• Session management: Session state disimpan di Redis (bukan in-process) supaya failover antara active dan standby tidak menjejaskan sesi pengguna. Load balancer menggunakan least-connection routing, bukan sticky session.

Kenapa bukan 4 sahaja? iTAX adalah monolithic .NET — bukan microservice. Tanpa standby, satu kegagalan = 133% load pada baki 3 VM = cascading failure. Dengan 4 standby, rolling update dan patching boleh dilakukan tanpa sebarang downtime.

S7: Kenapa IRIS hanya 4 VM (32 vCPU) tetapi menggantikan 17 VM (168 vCPU)?

Jawapan: IRIS direka untuk high-throughput pada bilangan core rendah disebabkan seni bina bersepadu:

• Seni bina proprietari InterSystems: shared-nothing, multi-model engine dalam satu proses

• Tiada overhead komunikasi antara ESB↔DW↔ETL↔API — semua dalam satu memory space

• Columnar storage + in-memory caching = analytical queries tanpa ETL batch tradisional

• Lesen 32-core direka untuk mengendalikan workload konsolidasi yang jauh melebihi nisbah core-to-core berbanding platform berasingan, berdasarkan pengalaman implementasi InterSystems di sektor serupa (revenue authority, healthcare). Sizing ini akan disahkan melalui PoC/UAT performance validation sebelum go-live.

Kriteria Penerimaan Sizing (Measurable)

Sizing infrastruktur MyCDN tertakluk kepada kriteria penerimaan berikut yang boleh diukur semasa PoC/UAT dan selepas go-live:

Kriteria	Sasaran	Kaedah Pengesahan
TPS Sustained (Peak)	≥ 500 TPS	Load test 5–7 transaksi kritikal (filing, payment, assessment, enforcement, inquiry) selama 30 min sustained
Response Latency (P95)	≤ 2 saat	P95 end-to-end response time untuk transaksi standard (bukan bulk/batch)
CPU Utilisation (Steady Peak)	60–70%	Purata CPU utilisasi iTAX VMs semasa sustained peak load. Melebihi 80% = trigger scale review.
Failover RTO (iTAX)	≤ 60 saat	Masa dari health check fail hingga warm standby menerima traffic (LB auto-failover)
DR Failover RTO	≤ 4 jam	Masa dari keputusan failover hingga DRC (Kelana Jaya) beroperasi penuh untuk transaksi teras
Replication RPO (DC→DRC)	≤ 15 minit	Maximum data loss window — Veeam Replication continuous + DB streaming replication
RAM Utilisation (Steady)	≤ 75%	Purata RAM committed pada semua PROD VMs semasa peak. Melebihi 85% = trigger review.
Storage Year 5 Utilisation	≤ 70%	Unjuran DC (205TB / 320TB = 64%) di bawah threshold 70%
IRIS Throughput	Validated via PoC	Integration throughput (ESB + DW query + API) disahkan semasa PoC dengan dataset representatif
iTAX TPS/VM Baseline	~125 TPS/VM	Bounded assumption — disahkan UAT perf test. Jika actual < 100 TPS/VM, horizontal scaling.

Nota: Kriteria di atas adalah sizing acceptance criteria — bukan SLA operasi. SLA operasi (uptime, incident response) ditakrifkan dalam dokumen SLA berasingan.

S8: Kenapa Kafka dan Redis tiada dalam BOM Perisian?

Jawapan: Kafka dan Redis adalah perisian open-source (Apache License 2.0):

• Tiada lesen komersial diperlukan — percuma untuk kegunaan produksi

• Oleh itu, ia tidak muncul sebagai item dalam BOM Perisian (yang menyenaraikan lesen komersial sahaja)

• Namun, ia memerlukan VM dedicated: Kafka = 6 VM (48 vCPU) untuk message broker, Redis = 4 VM (16 vCPU) untuk caching

• VM ini dikira dalam jumlah infrastruktur (66 PROD VM) walaupun tidak disenaraikan sebagai item perisian berlesen

• Skop operasi: Kafka dan Redis termasuk dalam skop konfigurasi, hardening, patching, monitoring, dan sokongan operasi oleh pasukan implementasi — tanpa kos lesen. Operasional disokong melalui BMC Helix (infra monitoring) dan Dynatrace (APM).

Sizing Calculator: Kalkulator ini membolehkan panel penilai mengubah parameter input dan melihat kesan kepada sizing secara automatik. Semua konstanta sizing dinyatakan untuk ketelusan. Baseline telah dikemas kini untuk arsitektur 3-komponen (IRIS Consolidation).

Nota Baseline Pinning: Apabila parameter input sepadan dengan nilai asal (500 TPS, 70% headroom, 0.5 DR factor), kalkulator mengekalkan sizing baseline yang telah diluluskan (32 DC + 20 DRC nodes). Ini bagi memastikan keselarasan dengan sizing rasmi. Perubahan mana-mana parameter akan mengira semula secara dinamik dan mungkin menyimpang daripada baseline.

A. Input Parameters (Editable)

User & Traffic

1. Total Registered Users

2. Peak Concurrent User %

3. Peak TPS (Transactions/sec)

5-Year Growth & DR Policy

4. Year 5 Max Utilisation (%)

5. DR Capacity Factor

6. DRC Capacity Ratio

Non-Production pada Nodes PROD

Dev/SIT/UAT dijalankan pada nodes Production. Tiada nodes berasingan.

7. Dev (% of PROD) — pada nodes PROD

8. SIT (% of PROD)

9. UAT (% of PROD)

10. Staging (% of PROD)

B. Production Outputs (Auto-Updated) — Termasuk Dev pada PROD

32,232

Peak Concurrent Users

660

DC vCPU (PROD+Dev)

DC Nodes

12.3 TB

DC RAM (384GB/node)

256

DRC vCPU Allocated

DRC Nodes

7.7 TB

DRC RAM (384GB/node)

PROD Nodes

20.0 TB

PROD Total RAM

876

5-Year Buffer vCPU

43%

Day 1 Utilisation

C. Non-Production pada Nodes PROD (Auto-Updated)

Dev/SIT/UAT dijalankan pada nodes Production yang sama. vCPU berikut ditambah kepada DC Allocated (tiada nodes berasingan).

Dev vCPU (15%)

Pada Nodes PROD

SIT vCPU (0%)

Pada Nodes PROD

UAT vCPU (0%)

Pada Nodes PROD

Staging vCPU (0%)

Pada Nodes PROD

Additional Nodes

GRAND TOTAL Nodes

20.0 TB

GRAND TOTAL RAM

D. Sizing Constants & Assumptions (IRIS Consolidated)

Constant	Value	Description
Baseline TPS	500 TPS	Reference point for sizing calculations
Baseline PROD vCPU	560 vCPU	PROD vCPU at 500 TPS (Core MyCDN)
Data Platform vCPU	16 vCPU	Tableau BI only (DW+ETL consolidated into IRIS)
DC vCPU per Node	48 vCPU	Usable vCPU per DC node (dual-socket)
DRC vCPU per Node	32 vCPU	Usable vCPU per DRC node
RAM per Node	384 GB	Physical RAM per node
IRIS License	32 cores PROD + 4 cores Non-PROD	InterSystems IRIS (32-core PROD, 4-core Dev/SIT/UAT)
Scaling Formula	Linear	PROD vCPU = 560 x (TPS / 500)

E. What-If Scenarios (Pre-Calculated for 5-Year @ 70% Max)

Scenario	TPS	PROD vCPU	DC vCPU	DC Nodes	DRC vCPU	DRC Nodes	Total
Baseline (IRIS)	500	560	660	32	256	20	52
+20% TPS	600	773	789	39	386	29	68
+40% TPS	700	902	918	45	451	33	78

Untuk Panel Penilai: Tab ini menyediakan ringkasan mudah dan analogi untuk membantu memahami sizing infrastruktur.

Analogi Mudah

Bayangkan MyCDN seperti Hospital Besar

DC (Data Centre):Hospital utama beroperasi 24/7 dengan semua kemudahan lengkap.

DRC (DR Centre):Hospital sandaran - beroperasi penuh jika hospital utama ditutup.

IRIS Platform:Seperti makmal berpusat hospital yang menggabungkan pelbagai makmal berasingan (ESB, Data Warehouse, ETL, API) menjadi satu makmal canggih.

5-Year Buffer:Seperti membina hospital yang cukup besar untuk 5 tahun pertumbuhan. Hari ini 43% penuh (termasuk Dev), tahun ke-5 baru ~66% penuh.

Soalan Lazim (FAQ)

Soalan	Jawapan
Adakah termasuk headroom?	Ya - 5 Year Growth Ready. DC 32 nodes = 1,536 vCPU physical, 660 allocated (termasuk Dev) = 43% Day 1 -> ~66% Year 5. Dev/SIT/UAT dijalankan pada nodes yang sama.
Apa itu IRIS Platform?	InterSystems IRIS menggabungkan ESB, Data Warehouse, ETL, dan API Management dalam satu platform. Menggantikan 4 komponen berasingan (17 VM -> 4 VM), menjimatkan kos dan mengurangkan kerumitan.
Kenapa DRC storage rendah?	Data Lake (~50TB) tidak replicate ke DRC. DRC hanya untuk PROD data.
Dev/SIT/UAT di mana?	Dijalankan pada nodes Production yang sama. Dev workload ~84 vCPU (15% daripada PROD) berkongsi infrastruktur production — termasuk IRIS 4-core Non-Production license. Tiada nodes berasingan untuk pembangunan.
Adakah gunakan Kubernetes?	Tidak. Semua komponen (termasuk IRIS, Kafka, Redis, Tableau) adalah VM-based.

Ringkasan Nombor Utama

Nodes

916

Allocated vCPU

101

Total VMs

460TB

Total Storage