Category: Home Fifteen Blog

Seiring dengan berkembangnya infrastruktur cloud dan semakin banyaknya koneksi antar Amazon VPC (Virtual Private Cloud) di berbagai akun dan region, mengelola jaringan menjadi semakin kompleks. AWS Transit Gateway hadir sebagai solusi untuk menyederhanakan kompleksitas ini dengan menyediakan pusat komunikasi yang aman antara VPC, sistem on-premises, dan Transit Gateway lainnya. Apa itu Transit Gateway Flow Logs? Transit Gateway Flow Logs memberikan visibilitas terhadap lalu lintas jaringan yang melewati Transit Gateway. Log ini mencatat detail seperti IP sumber/tujuan, port, protokol, jumlah traffic, timestamp, dan metadata lainnya. Informasi ini sangat berguna untuk: Troubleshooting jaringan Perencanaan kapasitas jaringan Kepatuhan dan keamanan Kenapa Menggunakan Amazon Managed Grafana? Dengan Amazon Managed Grafana, Anda bisa memvisualisasikan data Flow Log secara real-time, sehingga Anda bisa: Menganalisis performa jaringan Mendeteksi aktivitas mencurigakan Merencanakan kapasitas dengan lebih baik Menyelesaikan masalah jaringan dengan cepat Ringkasan Arsitektur Lalu lintas dari berbagai VPC dikirim ke Transit Gateway. Transit Gateway mengirim Flow Log ke Amazon S3 bucket. AWS Glue membaca log dan membuat katalog data. Amazon Athena digunakan untuk menjalankan query terhadap data tersebut. Amazon Managed Grafana menampilkan hasilnya dalam bentuk dashboard yang interaktif. Langkah-langkah Implementasi Langkah 1: Deploy Template CloudFormation Template ini akan otomatis membuat: Amazon S3 bucket untuk menyimpan log Konfigurasi AWS Glue dan database Workgroup Amazon Athena Query Athena yang disimpan Catatan: Beberapa layanan mungkin menimbulkan biaya saat digunakan. Langkah 2: Konfigurasi Flow Logs di Transit Gateway Buka Amazon VPC Console. Pilih Transit Gateway atau Attachment. Klik Actions > Create flow log. Pilih S3 bucket sebagai tujuan log. Pilih format log (plain text atau Parquet – yang lebih cepat dan efisien). Tambahkan tag jika diperlukan. Klik Create flow log. Langkah 3: Buat View di Amazon Athena Buka Amazon Athena. Pergi ke Saved Queries dan jalankan query bernama aws_tgw_centralized_logging. Pastikan Database, Table, dan Workgroup sudah sesuai. Jalankan query untuk membuat View bernama tgwlogs. Langkah 4: Hubungkan Amazon Athena ke Amazon Managed Grafana Login ke Amazon Managed Grafana menggunakan URL workspace Anda. Buka Data sources, pilih Amazon Athena. Isi detail seperti region, database, workgroup, dan output S3 bucket. Klik Save & test. Langkah 5: Buat Dashboard di Amazon Managed Grafana Buat dashboard baru atau import dari file JSON yang tersedia. Dashboard ini akan menampilkan informasi seperti: Jumlah data (byte) yang dikirim antara IP sumber dan tujuan Top alamat IP yang paling banyak digunakan VPC atau subnet dengan traffic terbanyak Tren trafik masuk dan keluar secara real-time Deteksi anomali seperti packet drop karena routing error Dashboard akan refresh otomatis setiap 5 menit dan menjalankan query dari Athena View yang telah dibuat sebelumnya. Pembersihan Resource Setelah selesai, hapus resource untuk menghindari biaya tambahan: Hapus stack CloudFormation Hapus workspace Amazon Managed Grafana Hapus Athena workgroup Kosongkan dan hapus S3 bucket secara manual Kesimpulan Tutorial ini menunjukkan bagaimana cara memantau dan menganalisis AWS Transit Gateway Flow Logs secara visual menggunakan Amazon Managed Grafana. Dengan dashboard yang interaktif, Anda dapat: Menghemat waktu troubleshooting Mendeteksi masalah secara proaktif Merencanakan kapasitas jaringan dengan lebih akurat Untuk informasi lebih lanjut, kunjungi: AWS Transit Gateway Flow Logs Amazon Managed Grafana Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Ringkasan Salah satu keuntungan utama menggunakan Amazon Web Services (AWS) adalah model pembayaran sesuai penggunaan. Dengan fleksibilitas ini, Anda bisa menghemat biaya dibandingkan infrastruktur on-premise. Salah satu pilar utama dalam AWS Well-Architected Framework adalah Optimasi Biaya. Dulu, optimasi biaya hanya dilakukan di akhir bulan oleh tim keuangan. Namun, sekarang optimasi biaya menjadi tanggung jawab bersama. Untuk memaksimalkan nilai investasi Anda, optimasi biaya harus dilakukan secara strategis dan taktis. Pendekatan strategis mencakup praktik terbaik, penggunaan layanan cloud-native, serta pengambilan keputusan berbasis data. Sedangkan pendekatan taktis berfokus pada tindakan konkret yang bisa langsung menghemat biaya. Salah satu layanan AWS yang bisa membantu mengelola optimasi biaya adalah AWS Config. Layanan ini memonitor, mengaudit, dan mengevaluasi konfigurasi serta hubungan antar sumber daya AWS secara terus-menerus. Dalam artikel ini, kami akan menunjukkan cara memanfaatkan fitur Conformance Packs di AWS Config untuk mengotomatisasi optimasi biaya di seluruh organisasi Anda. Apa Itu Conformance Pack dan Manfaatnya? Conformance Pack adalah kumpulan aturan dan tindakan remediasi di AWS Config yang membantu Anda menerapkan standar kepatuhan secara otomatis dalam satu akun atau di seluruh organisasi AWS. Aturan ini akan secara otomatis memonitor dan mengevaluasi sumber daya terhadap standar optimasi biaya yang telah ditentukan. AWS Config menyediakan Managed Rules (aturan yang sudah disediakan AWS dan bisa dikustomisasi) serta Custom Rules (aturan yang bisa dibuat sendiri menggunakan AWS Lambda atau AWS CloudFormation Guard). Jika suatu sumber daya tidak sesuai dengan aturan, maka akan ditandai sebagai Noncompliant. Anda bisa melakukan remediasi secara manual atau otomatis dengan AWS Systems Manager Automation. Solusi yang Ditawarkan Solusi Cost Optimization Conformance Pack membantu pengguna AWS Config untuk mengelola optimasi biaya dengan lebih baik. Conformance Pack ini mencakup tiga aturan optimasi biaya, yaitu: Memeriksa volume EBS tipe gp2 → Remediasi: Mengubahnya ke gp3. Memeriksa volume EBS yang tidak terhubung ke instans EC2. Memeriksa bucket S3 yang tidak memiliki kebijakan siklus hidup. Jika suatu sumber daya tidak memenuhi kriteria, maka akan ditandai sebagai Noncompliant. Aturan pertama juga memiliki opsi remediasi otomatis yang bisa mengubah volume EBS dari gp2 ke gp3, yang bisa menghemat biaya hingga 20% per GB. Catatan: AWS Config adalah layanan berbayar. Pastikan Anda memahami struktur biaya sebelum mengaktifkannya. Solusi ini bisa diterapkan dalam AWS Organization dengan atau tanpa AWS Control Tower. AWS Control Tower membantu mengelola lingkungan multi-akun dengan lebih mudah. Arsitektur Solusi Dalam solusi ini, akun audit di dalam Security OU ditetapkan sebagai delegated administrator untuk AWS Config dan AWS CloudFormation. Akun ini akan mengelola deployment Conformance Pack ke semua akun dalam organisasi. Sumber daya utama dalam solusi ini meliputi: AWS Config Conformance Pack – Mengandung aturan optimasi biaya. AWS Lambda Function – Mengevaluasi kepatuhan sumber daya. IAM Roles – Memberikan izin ke Lambda dan AWS Systems Manager. AWS Systems Manager Automation Document – Digunakan untuk remediasi otomatis. AWS Config Aggregator akan mengumpulkan hasil evaluasi dari semua akun dalam organisasi dan menampilkannya dalam satu dashboard. Prasyarat Sebelum memulai, pastikan: AWS Organizations dan AWS Control Tower sudah diaktifkan. Anda memiliki izin untuk mengakses akun manajemen dan akun audit. Trusted Access untuk StackSets dengan AWS Organizations sudah diaktifkan. Anda memiliki akses ke AWS Console untuk AWS Config di akun-akun yang terlibat. Langkah-Langkah Implementasi 1. Menetapkan Hubungan Kepercayaan AWS Organizations dengan AWS Config dan CloudFormation Gunakan AWS CloudShell dalam akun manajemen organisasi untuk menjalankan perintah berikut: aws organizations enable-aws-service-access –service-principal=config-multiaccountsetup.amazonaws.com aws organizations enable-aws-service-access –service-principal=member.org.stacksets.cloudformation.amazonaws.com Verifikasi dengan: aws organizations list-aws-service-access-for-organization 2. Menetapkan Akun Audit sebagai Delegated Administrator untuk AWS Config aws organizations register-delegated-administrator –account-id 222222222222 –service-principal config.amazonaws.com Verifikasi dengan: aws organizations list-delegated-administrators –service-principal=config.amazonaws.com 3. Menetapkan Akun Audit sebagai Delegated Administrator untuk AWS CloudFormation aws organizations register-delegated-administrator –service-principal=member.org.stacksets.cloudformation.amazonaws.com –account-id=222222222222 4. Meng-deploy Cost Optimization Conformance Pack Unduh file CloudFormation YAML template dari AWS Samples GitHub Repository. Buka AWS CloudShell, unggah file YAML tersebut. Jalankan perintah berikut: aws cloudformation deploy –template-file template.yaml –stack-name CostOptimizationConfPack –parameter-overrides DeployingInDelegatedAdminAccount=True –capabilities CAPABILITY_IAM Verifikasi bahwa Stack telah berhasil dibuat di AWS CloudFormation. Pengujian dan Remediasi Buat volume EBS tipe gp2. Jalankan ulang evaluasi aturan di AWS Config. Lihat apakah volume ditandai sebagai Noncompliant. Jalankan remediasi otomatis untuk mengubah volume ke gp3. Verifikasi bahwa statusnya berubah menjadi Compliant. Pembersihan Sumber Daya Untuk menghapus solusi, jalankan perintah berikut di AWS CloudShell: aws cloudformation delete-stack –stack-name CostOptimizationConfPack Deregistrasi akun audit sebagai delegated administrator: aws organizations deregister-delegated-administrator –account-id 222222222222 –service-principal config.amazonaws.com Kesimpulan AWS Config Cost Optimization Conformance Pack adalah solusi otomatis yang membantu mengelola dan mengoptimalkan biaya AWS secara efektif. Dengan aturan dan remediasi yang telah disiapkan, organisasi dapat menerapkan standar kepatuhan biaya yang lebih baik. Solusi ini tersedia sebagai open source di AWS Samples GitHub Repository. Anda dapat menyesuaikan aturan sesuai kebutuhan untuk lebih meningkatkan efisiensi biaya cloud Anda.  

Ringkasan Fitur Internet Monitor dalam Amazon CloudWatch Network Monitoring kini dilengkapi dengan panduan rekomendasi optimasi lalu lintas yang lebih canggih. Anda bisa menggunakannya untuk meningkatkan performa aplikasi dengan mengurangi latensi menggunakan AWS Regions, AWS Local Zones, atau Amazon CloudFront. Selain itu, Anda juga bisa mengoptimalkan routing IP tertentu ke endpoint yang lebih cepat. Fitur ini menawarkan beberapa saran peningkatan latensi, antara lain: Optimasi konfigurasi routing di Amazon Route 53 Internet Monitor memberikan rekomendasi untuk mengoptimalkan konfigurasi Amazon Route 53 DNS routing, dengan membandingkan hubungan antara prefix IP klien dan resolver DNS. Ini membantu Anda mengarahkan lalu lintas langsung ke endpoint aplikasi untuk mengurangi latensi. Pemilihan AWS Region/Local Zone yang optimal Berdasarkan analisis data latensi dari AWS, Anda akan mendapatkan rekomendasi terkait AWS Regions, Local Zones, atau Amazon CloudFront yang bisa membantu mengurangi latensi akses aplikasi oleh pengguna. Optimasi latensi berdasarkan lokasi pengguna Internet Monitor menyediakan rekomendasi berdasarkan lokasi pengguna (negara, kota, dan jaringan), sehingga Anda bisa melihat area dengan volume lalu lintas yang signifikan dan mengoptimalkan latensi di lokasi-lokasi tersebut. Anda dapat mengakses strategi optimasi ini melalui AWS Management Console, dengan masuk ke CloudWatch > Network Monitoring > Internet monitors, lalu pilih tab Optimize. Rekomendasi Konfigurasi Routing di Route 53 Amazon Route 53 memiliki fitur IP-based routing, yang memungkinkan pengaturan lalu lintas berdasarkan alamat IP pengguna untuk meningkatkan performa. Namun, mengonfigurasi fitur ini cukup rumit karena: Sulit memvisualisasikan dampak sebelum dan sesudah perubahan Tidak mudah menentukan IP mana yang harus dimasukkan ke dalam konfigurasi routing Hal ini terjadi karena permintaan DNS melewati resolver DNS milik ISP pengguna sebelum mencapai Amazon Route 53. Route 53 tidak melihat IP pengguna secara langsung, melainkan hanya melihat dua hal: Jika resolver mendukung EDNS-Client-Subnet (ECS), maka Route 53 dapat menggunakan subnet pengguna untuk mengarahkan lalu lintas. Jika ECS tidak didukung, Route 53 akan menggunakan alamat IP resolver ISP sebagai dasar pengambilan keputusan routing. Sebagai contoh: Pengguna memiliki alamat IP 203.0.113.10 Pengguna menggunakan resolver DNS ISP dengan alamat 198.51.100.50 Jika resolver mendukung ECS, maka Route 53 akan melihat 203.0.113.0/24 sebagai subnet pengguna dan bisa mengarahkannya dengan tepat. Jika resolver tidak mendukung ECS, maka Route 53 hanya akan melihat 198.51.100.50 dan mengambil keputusan berdasarkan IP resolver ini, bukan IP asli pengguna. Karena banyak resolver tidak mendukung ECS, Anda perlu mengetahui alamat IP dari semua resolver ISP yang digunakan pelanggan untuk bisa mengoptimalkan routing. Solusi dari Internet Monitor Fitur routing configuration recommendations yang baru ini mempermudah proses tersebut dengan memberikan visualisasi hubungan antara IP klien dan resolver ISP. Dengan begitu, Anda tidak perlu menganalisis detail resolver ISP secara manual. Langkah-langkahnya: Buka tab Optimize di Internet Monitor Lihat bagian “Reduce latency: Suggested updates to Route 53 routing” Anda akan menemukan data lengkap tentang resolver DNS yang digunakan pelanggan, ISP terkait, dan prefix IP pelanggan yang berhubungan dengan resolver tersebut. Lihat saran perbaikan dan estimasi pengurangan latensi (RTT – Round Trip Time) Buat atau perbarui CIDR collection untuk routing IP-based dengan cara: Pilih resolver IP yang ingin dioptimalkan Klik Add to CIDR collection Masukkan nama koleksi dan lokasi Klik Submit Setelah dibuat, CIDR collection ini bisa digunakan untuk mengatur routing dalam Amazon Route 53, guna mengarahkan lalu lintas klien ke Region tertentu. Keuntungan dari fitur ini: ✔ Meningkatkan visibilitas terhadap performa pengguna nyata ✔ Memberikan rekomendasi optimasi routing yang dapat langsung diterapkan ✔ Membantu pengambilan keputusan berdasarkan data yang akurat Rekomendasi AWS Regions dan Local Zones Berdasarkan Latensi Internet Monitor juga membantu Anda menemukan AWS Regions atau Local Zones terbaik untuk mengurangi latensi. Pada tab Optimize, Anda akan menemukan rekomendasi konfigurasi terbaik berdasarkan: AWS Region yang paling optimal berdasarkan volume lalu lintas Saran perubahan konfigurasi untuk meningkatkan kecepatan akses pelanggan Perbandingan latensi untuk semua Region, Local Zones, dan CloudFront Anda bisa membandingkan berbagai opsi berdasarkan Time to First Byte (TTFB), yang menunjukkan waktu respons awal server ke klien. Langkah-langkah untuk mengeksplorasi rekomendasi ini: Buka tab Optimize Lihat tabel “Suggested options for top Regions” untuk melihat rekomendasi utama Pilih “Optimization suggestions for all Regions” untuk melihat perbandingan mendetail Pilih Region atau layanan seperti CloudFront dan Local Zones untuk melihat dampak perubahannya terhadap latensi Keuntungan fitur ini: ✔ Memberikan wawasan tentang lokasi terbaik untuk men-deploy aplikasi ✔ Memungkinkan Anda membandingkan berbagai opsi konfigurasi ✔ Membantu mengurangi latensi berdasarkan data real-time dari AWS Rekomendasi Optimasi Latensi Berdasarkan Lokasi Pengguna Selain memilih Region yang optimal, Anda juga bisa melihat rekomendasi konfigurasi berdasarkan lokasi pengguna. Ini mencakup: Negara dan kota dengan lalu lintas tertinggi ke aplikasi Anda Estimasi perbaikan latensi rata-rata (TTFB) untuk setiap lokasi Detail ISP dan ASN yang melayani pengguna di lokasi tersebut Grafik historis untuk memantau tren latensi seiring waktu Keuntungan fitur ini: ✔ Menampilkan detail granular hingga tingkat kota dan ISP ✔ Membantu Anda membuat keputusan yang lebih akurat berdasarkan lalu lintas pengguna ✔ Menampilkan tren historis untuk melihat efektivitas optimasi Kesimpulan Dengan adanya fitur optimasi baru di Internet Monitor, Anda dapat: ✅ Mengoptimalkan performa aplikasi dengan lebih efisien ✅ Mengurangi latensi berdasarkan analisis real-time ✅ Membuat keputusan berbasis data untuk mengarahkan lalu lintas pengguna ✅ Meningkatkan pengalaman pengguna tanpa perlu konfigurasi manual yang rumit Fitur ini sangat bermanfaat bagi bisnis yang mengandalkan AWS untuk aplikasi berbasis cloud, terutama bagi mereka yang ingin memastikan respon cepat dan koneksi stabil untuk pengguna global. Manfaatkan fitur ini sekarang melalui AWS CloudWatch Network Monitoring dan tingkatkan performa jaringan global Anda! Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut !

Dalam perkembangan sistem SAP, akses berbasis web melalui SAP FIORI semakin banyak digunakan. Sebelumnya, pengguna SAP umumnya mengakses sistem melalui SAP GUI yang terinstal di PC atau laptop mereka. Namun, kini banyak transaksi penting yang dijalankan melalui browser, termasuk transaksi di SAP NetWeaver Portal, seperti input waktu kerja di SAP HR. Untuk memastikan kelancaran akses ini, load balancer menjadi komponen yang sangat penting. AWS menyediakan Amazon Application Load Balancer (ALB) yang dapat mendistribusikan lalu lintas aplikasi SAP ke berbagai target, seperti SAP Web Dispatcher atau SAP Application Server yang berjalan di Amazon EC2 di berbagai Availability Zones (AZ). Dulu, SAP Web Dispatcher (WD) sering digunakan sebagai load balancer utama. Namun, banyak perusahaan kini lebih memilih Amazon ALB karena fitur-fiturnya yang lebih unggul, kemudahan pengelolaan, efisiensi biaya, serta integrasi yang erat dengan ekosistem AWS. Apa itu Amazon Application Load Balancer (ALB)? Amazon ALB bekerja pada Layer 7 (application layer) OSI model, yang berarti dapat membaca konten lalu lintas jaringan untuk menentukan aturan pemrosesan. ALB menggunakan algoritma round robin secara default, tetapi dapat dikonfigurasi dengan metode least outstanding requests agar lebih optimal. Apa itu SAP Web Dispatcher (WD)? Menurut dokumentasi SAP, SAP Web Dispatcher berfungsi sebagai gateway utama untuk permintaan HTTP/HTTPS ke sistem SAP, bertindak sebagai reverse proxy yang menyeimbangkan beban ke server backend. Web Dispatcher umumnya ditempatkan di antara browser klien, load balancer lain, dan sistem SAP. Memilih SAP Web Dispatcher atau Amazon ALB? Banyak pelanggan bertanya apakah mereka sebaiknya menggunakan SAP Web Dispatcher, Amazon ALB, atau kombinasi keduanya. Untuk menentukan solusi terbaik, kita harus memahami fitur masing-masing. Fitur yang Dimiliki oleh SAP Web Dispatcher dan Amazon ALB Fitur Amazon ALB SAP Web Dispatcher HTTPS Termination ✅ Ya ✅ Ya Session Persistence (Stickiness) ✅ Ya ✅ Ya Dukungan HTTP/2 ✅ Ya ✅ Ya Server Name Indication (SNI) ✅ Ya ✅ Ya Multiple Systems Routing ✅ Ya ✅ Ya HTTP Header-based Routing ✅ Ya ✅ Ya HTTP Method-based Routing ✅ Ya ✅ Ya Mutual TLS (mTLS) ✅ Ya ✅ Ya Tabel di atas menunjukkan bahwa kedua solusi ini memiliki banyak fitur yang sama. Fitur Eksklusif SAP Web Dispatcher dan Amazon ALB Fitur Amazon ALB SAP Web Dispatcher Algoritma Load Balancing Round-robin, Least-outstanding-Request Simple round-robin, Adaptive Web Caching ❌ (Bisa dengan CloudFront) ✅ Ya Custom HTTP Headers ❌ (Bisa dengan CloudFront) ✅ Ya Request Manipulation ❌ Tidak ✅ Ya URL Filtering ❌ (Bisa dengan AWS WAF) ✅ Ya Dukungan WebSockets untuk RFC ✅ Ya (terbatas) ✅ Ya High Availability (HA) Bawaan ✅ Ya ❌ Tidak Skalabilitas ✅ Otomatis ✅ Dapat dikonfigurasi Integrasi dengan AWS Services ✅ Ya ❌ Tidak Maintenance dan Operasi ✅ Dikelola oleh AWS ❌ Dikelola oleh pengguna Tabel ini menunjukkan bahwa SAP Web Dispatcher memiliki fleksibilitas lebih besar dalam manipulasi request dan caching, sedangkan Amazon ALB lebih unggul dalam skalabilitas, keamanan, dan manajemen otomatis. Bagaimana Memilih Solusi yang Tepat? Berdasarkan fitur di atas, berikut keputusan yang bisa diambil: ✅ Gunakan Amazon ALB jika: Anda hanya membutuhkan fitur load balancing standar seperti yang ada di Tabel 1.1. Ingin skalabilitas otomatis dan minim perawatan. Menginginkan integrasi dengan layanan AWS seperti AWS WAF, CloudFront, ACM, CloudWatch. Mengutamakan keamanan dan ingin mengurangi risiko serangan karena ALB dikelola langsung oleh AWS. ✅ Gunakan SAP Web Dispatcher jika: Membutuhkan fitur tambahan seperti caching, request manipulation, dan URL filtering. Memerlukan kontrol lebih besar atas load balancing dengan konfigurasi yang lebih fleksibel. ✅ Gunakan Kombinasi Amazon ALB + SAP Web Dispatcher jika: Anda ingin memanfaatkan fitur eksklusif dari SAP WD dan integrasi cloud-native dari Amazon ALB. SAP Web Dispatcher digunakan sebagai reverse proxy, sementara ALB menangani distribusi trafik di belakangnya. Kesimpulan Amazon ALB adalah solusi cloud-native yang menawarkan integrasi erat dengan AWS, otomatisasi, dan keamanan tingkat tinggi. Dengan AWS Web Application Firewall (WAF) dan CloudWatch, ALB bisa memantau dan menangani ancaman keamanan secara otomatis. Sebaliknya, SAP Web Dispatcher memberikan kontrol lebih besar dalam pengaturan trafik dan caching, tetapi memerlukan pemeliharaan manual. Dalam banyak kasus, Amazon ALB lebih direkomendasikan, terutama untuk perusahaan yang ingin mengurangi beban operasional dan meningkatkan skalabilitas serta ketahanan sistem SAP mereka di AWS. Namun, jika fitur eksklusif SAP Web Dispatcher dibutuhkan, kombinasi keduanya bisa menjadi solusi terbaik. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan AWS Cloud, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut

Mainframe terus mendukung beban kerja kritis dan aplikasi transaksi inti bagi banyak perusahaan dengan database Adabas dan bahasa pemrograman Natural. Perusahaan yang masih mengandalkan Natural dan Adabas menghadapi dua kesulitan yang semakin besar: biaya lisensi produk dan semakin berkurangnya sumber daya yang mampu memelihara dan mengembangkan 4GL (Bahasa Generasi Keempat) serta database daftar terbalik (inverted list). Akibatnya, banyak yang mempertimbangkan modernisasi untuk mengurangi ketergantungan pada teknologi ini. Perusahaan-perusahaan ini juga berusaha untuk memungkinkan evolusi yang gesit dalam pengalaman pelanggan melalui transformasi digital. Upaya ini memerlukan lingkungan yang skalabel dan berbiaya rendah yang terintegrasi dengan teknologi berbasis cloud modern serta praktik pengembangan terkini. Selain itu, pelanggan ingin meningkatkan waktu pemasaran dengan pengembangan yang gesit sambil mengadopsi kemampuan cloud, pelaporan yang lebih baik, dan integrasi yang lebih mudah dengan aplikasi mobile, sosial, dan analitik. Kombinasi faktor-faktor ini sering mendorong modernisasi Natural dan Adabas ke Amazon Web Services (AWS). Artikel ini menyoroti jalur modernisasi yang tersedia untuk Natural dan Adabas dengan IBM ModernSystems dan AWS. Divisi ini menawarkan fungsionalitas refactor dan replatform, serta opsi migrasi mandiri. IBM Consulting adalah AWS Premier Tier Services Partner dan Managed Service Provider (MSP) yang menawarkan kemampuan layanan komprehensif untuk mengatasi tantangan bisnis dan teknologi yang dihadapi klien saat ini.   Ringkasan Solusi Kunci untuk meminimalkan risiko saat memodernisasi Natural dan Adabas adalah kematangan pilihan yang ditawarkan oleh perangkat lunak dan layanan unik dari Advanced. Akselerator IBM ModernSystems menjadi dasar dari solusi-solusi ini. Setiap solusi memberikan jalur strategis menyeluruh untuk menurunkan biaya dengan menghilangkan biaya lisensi pemasok untuk Natural dan Adabas, sambil mempertahankan aset warisan dan aturan bisnis. Ilustrasi di bawah ini menggambarkan pemetaan dari sumber ke target dengan akselerator IBM ModernSystems. Modernisasi Adabas – Natural ke AWS – Pemetaan Pola & Teknologi Gambar 1 – Gambaran umum modernisasi Natural Adabas.   Refactoring Otomatis dari Natural ke Java atau C# Solusi akselerator IBM ModernSystems dapat merubah kode sumber Natural menjadi aplikasi modern yang setara fungsionalnya, baik dalam Java atau C#. Kode yang telah di-refactor dapat dipelihara atau dikembangkan lebih lanjut menggunakan lingkungan pengembangan terintegrasi (IDE) modern apa pun. Akselerator IBM ModernSystems juga menyediakan opsi untuk menyematkan bahasa Natural dalam komentar untuk membantu pengembang Natural menemukan logika bisnis dalam struktur aplikasi baru. Kemampuan teknis dari refactoring Natural/Adabas adalah: Secara otomatis merubah semua objek Natural, termasuk program, subprogram, modul definisi data (DDM), peta, dan jenis area data. Memelihara dan menjalankan kode yang telah di-refactor sebagai Java atau C# .NET asli di AWS. Mengubah mode laporan Natural menjadi mode struktur. Konversi JCL ke PowerShell atau Spring Batch XML (standar Java JSR352). Mendukung pelanggan yang memilih untuk mempertahankan JCL dan PROCS mereka di lingkungan target dan menjalankannya menggunakan solusi IBM ModernSystems eavJES. Menjamin kode yang telah di-refactor memenuhi standar kualitas yang ditetapkan oleh SonarQube. Memelihara dan meningkatkan aplikasi yang telah di-refactor sebagai aplikasi web (Angular untuk antarmuka pengguna). Modernisasi Natural – Adabas : Zona Pendaratan AWS untuk Refactoring Otomatis Gambar 2 – Modernisasi beban kerja Natural Adabas – Zona Pendaratan Refactor di AWS.   Setelah aplikasi warisan dan database di-refactor dan diterapkan di AWS, pengembang dapat memperluas fungsionalitas aplikasi menggunakan alat DevOps standar dan CI/CD dengan layanan seperti AWS Code Pipeline dan AWS Code Build. Logika bisnis dari kode Natural yang lama dipertahankan tanpa perubahan. Tingkat optimasi tambahan dapat diterapkan dalam akselerator IBM ModernSystems untuk pengiriman yang efisien dan untuk memanfaatkan layanan AWS.   Replatforming Natural Perusahaan yang ingin mempertahankan basis kode warisan mereka dapat menjalankan sintaks Natural di Windows menggunakan akselerator IBM ModernSystems. Aplikasi yang dihasilkan identik dengan aplikasi di mainframe, meminimalkan perubahan yang terjadi saat bermigrasi dari mainframe ke AWS. Replatforming menyediakan cara yang relatif berbiaya rendah dan berisiko rendah untuk mengurangi pengeluaran operasional mainframe dan mempertahankan nilai bisnis yang diberikan oleh aplikasi asli. Karena sintaks Natural tetap seperti aslinya, organisasi dapat terus memanfaatkan talenta pengembang Natural mereka yang sudah ada sambil memberikan fitur baru dalam akselerator IBM ModernSystems. Akselerator IBM ModernSystems mencakup alat pengembangan UX lengkap untuk pengembang Natural, yang mencakup analisis kode Natural, diagram alur, analisis dampak, pencocokan pola, perbandingan versi, dan kemampuan debugging interaktif. Dengan kata lain, tim pengembang Natural dapat terus mengembangkan dan memelihara aplikasi dengan dukungan alat pengembangan yang modern dan efisien. Untuk menjalankan program Natural Online, akselerator IBM ModernSystems menafsirkan dan menjalankan setiap perintah Natural pada tingkat byte, memungkinkan aplikasi Natural yang ada untuk dijalankan tanpa perubahan terhadap database relasional baru. Mesin pemrosesan akselerator IBM ModernSystems menafsirkan perintah I/O seperti READ, WRITE, dan lainnya. Ini menghasilkan sintaks SQL yang setara untuk melakukan akses/pembaruan data terhadap database baru. Akselerator IBM ModernSystems memungkinkan alat business intelligence (BI) modern untuk terintegrasi dengan database relasional dengan cara yang tidak dapat dilakukan oleh sistem lama. Di lingkungan replatformed di AWS, JCL dijalankan di lingkungan eksekusi batch IBM ModernSystems eavJES, sebuah add-on untuk suite akselerator IBM ModernSystems dengan serangkaian alat lengkap. Pengembang dapat mempertahankan JCL dan PROCS, menghasilkan eksekusi yang mulus dengan sedikit perubahan. Eksekusi menghasilkan tindakan, katalog, restart, dan pemulihan yang sama seperti di lingkungan mainframe. Katalog terus dipantau dan dipelihara selama eksekusi pekerjaan dan bahkan memungkinkan manipulasi baris perintah pada dataset.   Jalur Menuju Modernisasi Lanjutan Setelah Replatforming Jalur Replatforming Natural membantu pelanggan yang memilih pendekatan bertahap untuk beralih ke bahasa modern. Akselerator IBM ModernSystems memberikan kemampuan untuk secara otomatis merubah basis kode ke Java atau C# melalui transformasi sederhana menggunakan fungsi “Save As”. Kode Java/C# yang baru di-refactor fungsinya setara dengan aplikasi Natural lama. Kode baru ini beroperasi menggunakan UI web dan Angular. Fitur ini memungkinkan modernisasi lanjutan untuk mendukung penggunaan kembali keterampilan pengembang yang ada dalam Natural dan pengetahuan mendalam mereka tentang aplikasi, sambil diterapkan sebagai Java atau C#. Modernisasi Natural – Adabas : Zona Pendaratan AWS untuk Replatforming Gambar 3 – Modernisasi beban kerja Natural Adabas – Zona Pendaratan Replatform di AWS.   Migrasi Adabas Otomatis Seiring dengan Refactoring Otomatis atau Replatforming Natural, semua database Adabas akan dimigrasikan ke padanan relasional (Amazon RDS untuk SQL Server, Oracle, Db2, Amazon Aurora). Setiap database relasional yang dihasilkan akan memiliki fungsionalitas dan kemampuan traversing yang sama seperti Adabas asli. Program unload Natural dihasilkan secara otomatis untuk memungkinkan…

Juicebox adalah mesin pencari sumber daya talent yang didukung oleh AI, yang menggunakan model bahasa alami canggih untuk membantu perekrut menemukan kandidat terbaik dari lebih dari 800 juta profil. Di inti fungsionalitas ini adalah Amazon OpenSearch Service, yang menyediakan dasar untuk infrastruktur pencarian Juicebox yang kuat, memungkinkan penggabungan metode pencarian teks penuh tradisional dengan kemampuan pencarian semantik canggih. Dalam postingan ini, kami akan membagikan bagaimana Juicebox menggunakan OpenSearch Service untuk meningkatkan pencarian.   Tantangan dalam Pencarian Rekrutmen Mesin pencari rekrutmen tradisional biasanya hanya mengandalkan pencarian berbasis Boolean atau kata kunci sederhana. Metode ini tidak efektif untuk menangkap nuansa dan maksud di balik kueri yang kompleks, sering kali menghasilkan banyak hasil yang tidak relevan. Perekrut pun menghabiskan waktu yang tidak perlu untuk menyaring hasil tersebut, yang merupakan proses yang memakan waktu dan tidak efisien. Selain itu, mesin pencari rekrutmen sering kali kesulitan untuk menangani dataset besar, menyebabkan masalah latensi dan hambatan kinerja saat lebih banyak data diindeks. Di Juicebox, dengan database yang tumbuh menjadi lebih dari 1 miliar dokumen dan jutaan profil yang dicari per menit, kami membutuhkan solusi yang tidak hanya dapat menangani ingest data dan pencarian dalam skala besar, tetapi juga mendukung pemahaman kontekstual dari kueri yang kompleks.   Gambaran Solusi Berikut adalah diagram yang menggambarkan arsitektur solusi. OpenSearch Service dengan aman membuka pencarian waktu nyata, pemantauan, dan analisis data bisnis dan operasional untuk kasus penggunaan seperti pemantauan aplikasi, analisis log, observabilitas, dan pencarian situs web. Anda mengirimkan dokumen pencarian ke OpenSearch Service dan mengambilnya dengan kueri pencarian yang mencocokkan teks dan vektor embedding untuk hasil yang cepat dan relevan. Di Juicebox, kami mengatasi lima tantangan dengan Amazon OpenSearch Service, yang kami bahas dalam bagian berikut.   Masalah 1: Latensi tinggi dalam pencarian kandidat Awalnya, kami menghadapi keterlambatan yang signifikan dalam mengembalikan hasil pencarian karena skala dataset kami, terutama untuk kueri semantik yang kompleks yang membutuhkan pemahaman kontekstual yang mendalam. Mesin pencari teks penuh lainnya tidak dapat memenuhi persyaratan kami untuk kecepatan atau relevansi dalam memahami niat perekrut di balik setiap pencarian. Solusi: BM25 untuk pencarian teks penuh yang cepat dan akurat Algoritma BM25 dari OpenSearch Service terbukti sangat berharga karena memungkinkan Juicebox untuk mengoptimalkan kinerja pencarian teks penuh sambil menjaga akurasi. Melalui penilaian relevansi kata kunci, BM25 membantu memberi peringkat profil berdasarkan kemungkinan kecocokannya dengan kueri perekrut. Pengoptimalan ini mengurangi latensi kueri rata-rata kami dari sekitar 700 milidetik menjadi 250 milidetik, memungkinkan perekrut untuk mengambil profil yang relevan jauh lebih cepat daripada implementasi pencarian kami sebelumnya. Dengan BM25, kami melihat pengurangan latensi hampir tiga kali lipat untuk pencarian berbasis kata kunci, yang meningkatkan pengalaman pencarian secara keseluruhan bagi pengguna kami.   Masalah 2: Menyesuaikan niat, bukan hanya kata kunci Dalam rekrutmen, pencocokan kata kunci yang tepat sering kali dapat menyebabkan terlewatnya kandidat yang memenuhi syarat. Seorang perekrut yang mencari “data scientist dengan pengalaman NLP” mungkin melewatkan kandidat dengan “machine learning” di profil mereka, meskipun mereka memiliki keahlian yang tepat. Solusi: Pencarian vektor dengan k-NN untuk pemahaman semantik Untuk mengatasi ini, Juicebox menggunakan pencarian vektor k-nearest neighbor (k-NN). Vektor embedding memungkinkan sistem untuk memahami konteks di balik kueri perekrut dan mencocokkan kandidat berdasarkan makna semantik, bukan hanya pencocokan kata kunci. Kami memelihara indeks pencarian vektor skala miliaran yang mampu melakukan pencarian k-NN latensi rendah, berkat optimasi OpenSearch Service seperti kemampuan kuantisasi produk. Kemampuan pencarian neural ini memungkinkan kami untuk membangun pipeline Retrieval Augmented Generation (RAG) untuk embedding kueri bahasa alami sebelum melakukan pencarian. OpenSearch Service memungkinkan kami mengoptimalkan parameter algoritma untuk Hidden Navigable Small Worlds (HNSW) seperti m, ef_search, dan ef_construction. Ini memungkinkan kami mencapai target latensi, recall, dan biaya. Pencarian semantik, yang didukung oleh k-NN, memungkinkan kami untuk menampilkan 35% lebih banyak kandidat relevan dibandingkan dengan pencarian hanya menggunakan kata kunci untuk kueri yang kompleks. Kecepatan pencarian ini tetap cepat dan akurat, dengan kueri ter-vektorisasi mencapai recall lebih dari 0,9.   Masalah 3: Kesulitan dalam benchmarking model machine learning Ada beberapa indikator kinerja utama (KPI) yang mengukur keberhasilan pencarian Anda. Ketika menggunakan vektor embedding, Anda memiliki beberapa pilihan untuk memilih model, menyesuaikan model, dan memilih hyperparameter yang digunakan. Anda perlu melakukan benchmarking solusi Anda untuk memastikan bahwa Anda mendapatkan latensi, biaya, dan terutama akurasi yang tepat. Benchmarking model machine learning (ML) untuk recall dan kinerja sangat menantang karena banyaknya model yang berkembang pesat (seperti papan peringkat MTEB di Hugging Face). Kami menghadapi kesulitan dalam memilih dan mengukur model secara akurat sambil memastikan kinerja yang baik di dataset berskala besar. Solusi: k-NN tepat dengan skrip penilaian di OpenSearch Service Juicebox menggunakan k-NN tepat dengan fitur skrip penilaian untuk mengatasi tantangan ini. Fitur ini memungkinkan benchmarking yang tepat dengan melakukan pencarian tetangga terdekat secara brute-force dan menerapkan filter pada subset vektor, memastikan bahwa metrik recall akurat. Pengujian model dipermudah menggunakan berbagai model terlatih dan konektor ML (terintegrasi dengan Amazon Bedrock dan Amazon SageMaker) yang disediakan oleh OpenSearch Service. Fleksibilitas dalam menerapkan penyaringan dan skrip penilaian kustom membantu kami mengevaluasi berbagai model di dataset berdimensi tinggi dengan percaya diri. Juicebox dapat mengukur kinerja model dengan kontrol yang sangat rinci, mencapai recall lebih dari 0,9. Penggunaan k-NN tepat memungkinkan Juicebox untuk melakukan benchmarking lebih cepat dan andal, bahkan di data skala miliaran, memberikan kepercayaan yang dibutuhkan untuk pemilihan model.   Masalah 4: Kurangnya wawasan berbasis data Perekrut tidak hanya perlu menemukan kandidat, tetapi juga memperoleh wawasan tentang tren industri talent yang lebih luas. Menganalisis ratusan juta profil untuk mengidentifikasi tren keterampilan, geografi, dan industri sangat memakan biaya komputasi. Kebanyakan mesin pencari lain yang mendukung pencarian teks penuh atau pencarian k-NN tidak mendukung agregasi. Solusi: Agregasi lanjutan dengan OpenSearch Service Fitur agregasi kuat dari OpenSearch Service memungkinkan kami membangun Talent Insights, fitur yang memberikan perekrut wawasan yang dapat ditindaklanjuti dari data yang teragregasi. Dengan melakukan agregasi skala besar di ratusan juta profil, kami mengidentifikasi keterampilan kunci dan tren perekrutan, serta membantu klien menyesuaikan strategi pencarian mereka. Kueri agregasi sekarang dijalankan di lebih dari 100 juta profil dan menghasilkan hasil dalam waktu kurang dari 800 milidetik, memungkinkan perekrut untuk menghasilkan wawasan dengan segera. Masalah 5: Menyederhanakan ingest dan pengindeksan data Juicebox mengimpor data…