Steven Austin Waruwu (Stevenwwruwu)

2025: Steven Austin Waruwu, B.Sc., S. Kom.
Cloud Solutions Architect | AWS Migration Specialist

Portofolio Proyek: Migrasi Infrastruktur On-Premise SIPSHOP.CO.ID ke AWS Cloud

Gambaran Umum Proyek:
Proyek ini berfokus pada migrasi komprehensif sistem produksi monolitik sipshop.co.id dari infrastruktur on-premise ke Amazon Web Services (AWS) Cloud. Tujuan utama adalah untuk memastikan kelangsungan bisnis dengan meminimalkan downtime, sekaligus membangun lingkungan cloud yang sangat scalable, highly available, lebih tangguh, dan optimal dari segi biaya serta performa.


Klien: PT SIPSHOP BANTU BERSAMA (sipshop.co.id)
Periode Implementasi: 3 Mei 2025 - 9 Mei 2025
Peran Saya: Project Lead | Cloud Infrastructure Architect
Tantangan Lingkungan Asal (On-Premise):
Sistem on-premise yang ada menggunakan arsitektur monolitik pada host MSIS366 dengan OS Ubuntu 22.04 dan konfigurasi RAID1 untuk penyimpanan. Tantangan utama meliputi keterbatasan skalabilitas, potensi single point of failure, dan beban operasional yang tinggi dalam pemeliharaan infrastruktur fisik.

Solusi AWS yang Diimplementasikan:

Strategi Migrasi:

Menggunakan pendekatan Lift-and-Shift (Rehost) dengan AWS Application Migration Service (MGN) untuk memigrasikan server produksi.

Replikasi data dilakukan menggunakan AWS MGN Agent.
Layanan Komputasi (EC2 & Skalabilitas):

Aplikasi dimigrasikan ke instance Amazon EC2.
Instance T3.Large pada awalnya menjadi target berdasarkan hasil monitoring CPU dan RAM. Namun, setelah analisis dan simulasi lebih lanjut (yang menunjukkan C5.2xLarge sebagai "Best Option" untuk pola beban), ini menunjukkan proses right-sizing yang berkelanjutan.

Auto Scaling Group (ASG) dikonfigurasi dengan instance sipshop.co.id sebagai anggota untuk skalabilitas otomatis berdasarkan beban.
Application Load Balancer (ALB) dibuat untuk mendistribusikan lalu lintas ke instance EC2.
Dilakukan pengujian ekstensif dengan berbagai tipe instance (t3.small, t3.large, c5.4xlarge, c5.9xlarge) untuk menentukan sumber daya yang optimal.
Layanan Jaringan & Keamanan:

Pengaturan jaringan AWS dikonfigurasi, termasuk VPC dan security group.
Akses remote dijaga ketat melalui IP terkontrol menggunakan RSA dan SSH.
Pemantauan keamanan dan kepatuhan dilakukan melalui pemantauan snapshot retention dan review AWS billing dashboard untuk optimasi biaya.
Layanan Data & Penyimpanan:

Konfigurasi volume EBS mencakup ukuran 895 GB untuk data dan 1 GB untuk boot, dengan penyesuaian IOPS dan Throughput.
Dilakukan 2 full snapshots dan 2 incremental snapshots untuk backup data.
Replikasi data MGN sempat dihentikan sementara untuk menghemat biaya traffic dan mencegah agen membuat backup inkremental yang tersimpan di bawah snapshot.

Monitoring & Validasi:

Pengaturan AWS CloudWatch dilakukan untuk pemantauan.
Semua fungsi aplikasi telah diuji di bawah subdomain sementara dan diverifikasi berjalan normal di infrastruktur AWS yang baru.


Pengujian staging dan UAT dilakukan untuk memverifikasi fungsionalitas dan integrasi.
Hasil & Manfaat yang Dicapai:

Kelangsungan Bisnis: Memastikan aplikasi dapat berjalan normal di infrastruktur AWS baru dengan meminimalkan downtime selama proses migrasi.

Skalabilitas & Ketersediaan: Implementasi ASG dan ALB meningkatkan kemampuan aplikasi untuk menyesuaikan diri dengan beban kerja yang bervariasi dan menjaga ketersediaan tinggi.
Efisiensi Sumber Daya: Melalui proses right-sizing dan pemantauan yang cermat, sumber daya cloud disesuaikan untuk mencapai kinerja optimal dan efisiensi biaya.

Manajemen Anggaran: Anggaran migrasi dikelola secara efektif.
Pembelajaran & Praktik Terbaik:

Pentingnya pengujian menyeluruh di lingkungan staging dan UAT dengan berbagai konfigurasi instance untuk validasi kinerja.
Fleksibilitas AWS memungkinkan penyesuaian tipe instance pasca-migrasi berdasarkan hasil monitoring riil untuk optimasi berkelanjutan.
Manajemen biaya dan pemantauan IOPS/Throughput EBS secara berkala adalah kunci setelah migrasi

2025: Sebagai mitra AWS, saya memimpin proyek migrasi ini mulai dari tahap perencanaan hingga pasca-migrasi. Tujuan utamanya adalah memindahkan aplikasi-aplikasi kritis RetailConnect ke AWS dengan downtime minimal, meningkatkan ketahanan sistem, menekan biaya, serta memodernisasi landscape database mereka.

Strategi Migrasi

Migrasi dilakukan bertahap agar tidak mengganggu operasional bisnis:

Platform E-commerce (Postgres 2 TB)

Aplikasi web di-containerize dan dijalankan di Amazon ECS dengan Fargate, dilengkapi Application Load Balancer untuk skala otomatis.

Database dipindahkan ke Amazon Aurora PostgreSQL menggunakan AWS Database Migration Service (DMS) dengan ongoing replication agar hampir tanpa downtime.

Konten statis dipindahkan ke Amazon S3 dan didistribusikan global dengan Amazon CloudFront.

Sistem Manajemen Inventori (Oracle 4 TB)

Karena RetailConnect ingin meninggalkan Oracle dan Windows, database direfaktor menjadi PostgreSQL.

AWS Schema Conversion Tool (SCT) digunakan untuk konversi skema, sedangkan migrasi data memakai AWS DMS.

Aplikasi Java dijalankan ulang di Amazon EC2 berbasis Linux dengan Application Load Balancer.

Platform Analitik Pelanggan (Postgres 3 TB + ETL)

Database analitik dipindahkan ke Amazon Redshift untuk performa query yang lebih baik.

Proses ETL Pentaho di-containerize di Amazon ECS dan diorkestrasi menggunakan AWS Step Functions.

Data mentah dan data bersih (total 2 TB) dimigrasikan ke Amazon S3 sebagai data lake utama.

Tantangan dan Solusi

Database Besar: Migrasi data dilakukan dengan kombinasi AWS Snowball Edge untuk transfer bulk dan AWS DMS untuk sinkronisasi berkelanjutan.

Downtime Minimal: Dengan DMS, sinkronisasi berjalan real-time sehingga cutover dilakukan hampir tanpa gangguan.

Refactoring Oracle: Perpindahan dari Oracle 12c ke Aurora PostgreSQL menghilangkan biaya lisensi dan menstandarkan database di PostgreSQL.

Keamanan: Seluruh data dienkripsi saat transit (TLS) maupun saat disimpan (KMS). Selama migrasi digunakan VPN Site-to-Site, dengan opsi peningkatan ke AWS Direct Connect.

Efisiensi Operasional: Mengandalkan layanan terkelola seperti Aurora, Redshift, ECS, dan S3, tim IT tidak lagi terbebani patching atau maintenance rutin.

Arsitektur AWS Setelah Migrasi

Web & Aplikasi: Amazon ECS + ALB

Database: Aurora PostgreSQL (e-commerce & inventori), Amazon Redshift (analitik)

Data Lake: Amazon S3 (raw + clean data)

ETL: Pentaho di ECS + Step Functions

Distribusi Konten: S3 + CloudFront

Backup & DR: AWS Backup + Cross-Region Replication

Monitoring & Security: CloudWatch, Config, GuardDuty, IAM

(Di portofolio, bagian ini bisa dilengkapi diagram arsitektur high-level untuk memperkuat cerita.)

Proses Migrasi & Alur Trafik

Transfer Awal: Data dalam skala terabyte diekspor menggunakan AWS Snowball Edge.

Sinkronisasi: DMS menjaga data on-prem dan AWS tetap sinkron sampai cutover.

Cutover: Begitu lag sinkronisasi mendekati nol, aplikasi dialihkan ke AWS.

Alur Trafik Pasca Migrasi:

Pengguna mengakses e-commerce melalui CloudFront → ALB → ECS.

Aplikasi berinteraksi dengan Aurora PostgreSQL.

Data analitik masuk ke S3, diproses ETL, lalu dimuat ke Redshift.

Hasil Bisnis

Penghematan Biaya: Dengan menghapus lisensi Oracle dan server Windows, serta memanfaatkan layanan terkelola, biaya infrastruktur turun sekitar 40%.

Skalabilitas: Platform e-commerce kini otomatis menyesuaikan kapasitas saat traffic melonjak.

Reliabilitas: Database utama berjalan di mode Multi-AZ, memastikan high availability.

Analitik Cepat: Redshift dan data lake di S3 memungkinkan analitik pelanggan lebih cepat dan mendekati real-time.

Efisiensi Tim IT: Waktu yang sebelumnya habis untuk maintenance kini bisa difokuskan ke inovasi produk.

Kesimpulan

Proyek ini berhasil mentransformasi infrastruktur inti RetailConnect. Dengan kombinasi rehost, refactor, dan modernisasi, seluruh workload utama berhasil dipindahkan ke AWS secara aman, hemat biaya, dan siap untuk tumbuh lebih cepat. RetailConnect kini memiliki fondasi cloud yang kuat untuk inovasi bisnis di masa depan, sekaligus meningkatkan pengalaman pelanggan mereka.

2025: Saat berencana meluncurkan game flagship multiplayer Gatcha battle dengan jutaan pemain aktif harian, mereka menghadapi tantangan serius: kebutuhan skalabilitas tinggi, latensi rendah, serta pengalaman pemain yang konsisten meskipun terjadi lonjakan traffic saat turnamen atau event khusus.


Strategi Migrasi & Modernisasi

Kami melakukan modernisasi total dari infrastruktur on-premises mereka, yang sebelumnya berbasis server fisik, SAN, dan monitoring manual. Pendekatan yang digunakan adalah cloud-native dari awal:

Game Servers (10x, high memory compute):

Dipindahkan ke Amazon EC2 C7g/M7g instances dengan Auto Scaling Group untuk elastisitas sesuai jumlah pemain.

Amazon Global Accelerator dipakai untuk mempercepat routing trafik pemain global ke region terdekat, dimulai dari ap-southeast-1 (Singapore).

Web Servers & Matchmaking:

Dialihkan ke Amazon ECS dengan Fargate agar mudah autoscale dan mengurangi beban operasi.

Dideploy bersama Amazon API Gateway untuk layanan matchmaking & player portal.

Amazon CloudFront mempercepat distribusi konten web dan statis.

Database (PostgreSQL):

Diimplementasikan menggunakan Amazon Aurora PostgreSQL dengan konfigurasi Multi-AZ dan Aurora Global Database untuk mempersiapkan ekspansi ke US di masa depan.

Replikasi otomatis memastikan failover cepat tanpa downtime panjang.

Storage & Backup:

Game updates, logs, dan backup disimpan di Amazon S3 dengan S3 Lifecycle Policies (file otomatis dihapus setelah 1 tahun tidak aktif).

Backup database dikelola oleh AWS Backup dan diarsipkan ke S3 Glacier untuk efisiensi biaya.

Networking & Security:

Menggunakan AWS WAF + AWS Shield Advanced untuk melindungi dari serangan DDoS.

Elastic Load Balancer menggantikan perangkat F5 lama untuk mendistribusikan traffic.

Semua komunikasi antar komponen diamankan dengan VPC Private Subnets, Security Groups, dan KMS Encryption.

Monitoring & Analytics:

Digantikan dengan stack observability cloud-native: Amazon CloudWatch + AWS X-Ray untuk tracing, serta integrasi dengan Grafana Cloud.

Player engagement dan monetisasi dianalisis menggunakan Amazon Redshift dengan Amazon Kinesis Data Streams untuk event ingestion real-time.

Tim produk bisa memanfaatkan Amazon QuickSight untuk dashboard interaktif mengenai perilaku pemain.

Alur Trafik Pemain (Setelah Migrasi)

Pemain dari berbagai wilayah terhubung ke server melalui Amazon Global Accelerator, yang secara otomatis memilih jalur jaringan terdekat dan tercepat.

Permintaan mereka diarahkan ke CloudFront ? API Gateway ? ECS (matchmaking/web services).

Session game didistribusikan ke EC2 Auto Scaling group (game servers).

Semua data pemain dan status game disimpan di Aurora PostgreSQL.

Event log game streaming ke Kinesis ? Redshift ? QuickSight, memberikan insight real-time ke tim produk.

Hasil Bisnis

Scalability: Infrastruktur mampu menangani jutaan pemain aktif secara otomatis tanpa perlu menambah server manual.

Low Latency: Global Accelerator menurunkan latensi rata-rata hingga 40% dibandingkan infrastruktur lama.

Cost Optimization: Dengan Auto Scaling, biaya server hanya dikeluarkan saat ada pemain. Ditambah S3 Glacier untuk arsip, storage cost bisa ditekan lebih dari 60%.

Player Experience: Pemain mendapatkan pengalaman stabil bahkan saat traffic melonjak selama turnamen.

Data-Driven Growth: Tim produk kini bisa mengidentifikasi pola belanja pemain dengan Redshift + QuickSight, sehingga strategi event dan monetisasi lebih efektif.

Future Ready: Aurora Global Database membuat ekspansi ke region baru (misalnya US) lebih cepat karena hanya perlu menambah read replica regional.

Kesimpulan

Proyek ini membawa GameNovas ke level baru. Dengan mengadopsi AWS sejak awal, mereka memiliki fondasi cloud gaming yang aman, elastis, hemat biaya, dan siap mendukung jutaan pemain. Selain itu, arsitektur ini membuka jalan untuk ekspansi global sambil tetap menjaga fokus pada yang terpenting: pengalaman bermain yang mulus dan engagement pemain yang berkelanjutan.

2025: Logging & Observability System with OpenSearch

Saya membangun sebuah sistem logging dan observability menggunakan OpenSearch, OpenSearch Dashboards, Logstash, Nginx, dan backend Python (Flask). Seluruh deployment dikelola secara otomatis dengan Ansible dan Docker Compose, sehingga mudah direplikasi dan dikelola di berbagai environment (dev/prod).

Tujuan Proyek

Menyediakan solusi terpusat untuk menyimpan, mengelola, dan menganalisis log.

Mengintegrasikan log dari Nginx ke OpenSearch agar dapat ditampilkan secara real-time di OpenSearch Dashboards.

Membuat deployment yang fleksibel dan dinamis dengan konfigurasi yang dihasilkan langsung dari file inventory Ansible.

Pencapaian Teknis

Membuat playbook Ansible untuk mendeploy container OpenSearch, Dashboards, Nginx, Logstash, dan backend Python.

Menggunakan template Jinja2 untuk menghasilkan docker-compose.yml dan .env secara dinamis.

Mengamankan sistem dengan SSL self-signed certificate dan menyimpan credential di Ansible Vault.

Menyediakan mekanisme terminate & redeploy untuk mempermudah troubleshooting.

Hasil

Log dari Nginx berhasil ditangkap, diproses, dan disimpan di OpenSearch.

Data dapat divisualisasikan melalui OpenSearch Dashboards dengan user akses yang dikonfigurasi otomatis lewat playbook.

Proyek terdokumentasi dengan baik, termasuk diagram arsitektur, instruksi deployment, serta rencana pengembangan fitur tambahan (alerting, Filebeat, monitoring dengan Grafana).

Nilai Tambah

Proyek ini memperlihatkan kemampuan saya dalam:

Automasi infrastruktur menggunakan Ansible.

Container orchestration dengan Docker Compose.

Security by design, melalui SSL dan Ansible Vault.

Observability dengan log centralization dan visualisasi.