Rekonsiliasi akun merupakan langkah penting untuk memastikan kelengkapan dan keakuratan laporan keuangan. Secara khusus, perusahaan harus melakukan rekonsiliasi neraca keuangan akun yang mungkin mengandung salah saji signifikan atau material. Akuntan memeriksa setiap akun di buku besar akun dan memverifikasi bahwa saldo yang tercantum lengkap dan akurat. Ketika ditemukan ketidaksesuaian, akuntan menyelidiki dan mengambil tindakan perbaikan yang tepat.

Sebagai bagian dari organisasi FinTech Amazon, kami menawarkan platform perangkat lunak yang memberdayakan tim akuntansi internal di Amazon untuk melakukan rekonsiliasi akun. Untuk mengoptimalkan proses rekonsiliasi, pengguna ini memerlukan transformasi kinerja tinggi dengan kemampuan untuk menskalakan sesuai permintaan, serta kemampuan untuk memproses ukuran file variabel mulai dari beberapa MB hingga lebih dari 100 GB. Tidak selalu mungkin untuk memasukkan data ke dalam satu mesin atau memprosesnya dengan satu program dalam jangka waktu yang wajar. Perhitungan ini harus dilakukan dengan cukup cepat untuk memberikan layanan praktis di mana logika pemrograman dan detail yang mendasarinya (distribusi data, toleransi kesalahan, dan penjadwalan) dapat dipisahkan.

Kita dapat mencapai komputasi simultan ini pada beberapa mesin atau thread dengan fungsi yang sama di seluruh kelompok elemen kumpulan data dengan menggunakan solusi pemrosesan data terdistribusi. Hal ini mendorong kami untuk menemukan kembali layanan rekonsiliasi yang didukung oleh layanan AWS, termasuk Amazon ESDM dan Apache Spark kerangka pemrosesan terdistribusi, yang menggunakan PySpark. Layanan ini memungkinkan pengguna memproses file di atas 100 GB yang berisi hingga 100 juta transaksi dalam waktu kurang dari 30 menit. Layanan rekonsiliasi telah menjadi pusat pemrosesan data, dan kini pengguna dapat dengan lancar melakukan berbagai operasi, seperti Poros, BERGABUNG (seperti operasi Excel VLOOKUP), hitung operasi, dan lebih, memberikan solusi serbaguna dan efisien untuk merekonsiliasi kumpulan data yang sangat besar. Peningkatan ini merupakan bukti skalabilitas dan kecepatan yang dicapai melalui penerapan solusi pemrosesan data terdistribusi.

Dalam postingan ini, kami menjelaskan cara kami mengintegrasikan Amazon EMR untuk membangun sistem dengan ketersediaan tinggi dan skalabel yang memungkinkan kami menjalankan proses rekonsiliasi keuangan bervolume tinggi.

Arsitektur sebelum migrasi

Diagram berikut menggambarkan arsitektur kami sebelumnya.

Layanan warisan kami dibangun dengan Layanan Kontainer Amazon Elastic (Amazon ECS) aktif Fargate AWS. Kami memproses data secara berurutan menggunakan Python. Namun, karena kurangnya kemampuan pemrosesan paralel, kami sering kali harus meningkatkan ukuran cluster secara vertikal untuk mendukung kumpulan data yang lebih besar. Sebagai contoh, data sebesar 5 GB dengan 50 operasi memerlukan waktu sekitar 3 jam untuk diproses. Layanan ini dikonfigurasikan untuk menskalakan secara horizontal ke lima instans ECS tempat pesan disurvei Layanan Antrian Sederhana Amazon (Amazon SQS), yang memenuhi permintaan transformasi. Setiap instance dikonfigurasi dengan 4 vCPU dan memori 30 GB untuk memungkinkan penskalaan horizontal. Namun, kami tidak dapat meningkatkan kapasitas kinerjanya karena prosesnya terjadi secara berurutan, mengambil sebagian data Layanan Penyimpanan Sederhana Amazon (Amazon S3) untuk diproses. Misalnya, operasi VLOOKUP di mana dua file akan digabungkan mengharuskan kedua file dibaca dalam memori potongan demi potongan untuk mendapatkan output. Hal ini menjadi kendala bagi pengguna karena harus menunggu lama untuk memproses datasetnya.

Sebagai bagian dari re-arsitektur dan modernisasi, kami ingin mencapai hal-hal berikut:

• Ketersediaan tinggi – Cluster pemrosesan data harus memiliki ketersediaan tinggi, menyediakan tiga ketersediaan 9 (99.9%)
• Throughput – Layanan ini harus menangani 1,500 pengoperasian per hari
• Latensi – Seharusnya dapat memproses data 100 GB dalam waktu 30 menit
• Heterogenitas – Cluster harus mampu mendukung berbagai macam beban kerja, dengan file mulai dari beberapa MB hingga ratusan GB
• Konkurensi kueri – Implementasinya menuntut kemampuan untuk mendukung minimal 10 derajat konkurensi
• Keandalan pekerjaan dan konsistensi data – Pekerjaan harus dijalankan dengan andal dan konsisten untuk menghindari pelanggaran Perjanjian Tingkat Layanan (SLA)
• Hemat biaya dan skalabel – Ini harus dapat diskalakan berdasarkan beban kerja, sehingga hemat biaya
• Keamanan dan kepatuhan – Mengingat sensitivitas data, data harus mendukung kontrol akses yang menyeluruh dan penerapan keamanan yang tepat
• Pemantauan – Solusinya harus menawarkan pemantauan klaster dan pekerjaan secara end-to-end

Mengapa Amazon EMR

Amazon EMR adalah solusi big data cloud terdepan di industri untuk pemrosesan data berskala petabyte, analisis interaktif, dan pembelajaran mesin (ML) menggunakan kerangka kerja sumber terbuka seperti Apache Spark, Sarang Apache, dan Presto. Dengan kerangka kerja ini dan proyek sumber terbuka terkait, Anda dapat memproses data untuk tujuan analitik dan beban kerja BI. Amazon EMR memungkinkan Anda mengubah dan memindahkan sejumlah besar data masuk dan keluar dari penyimpanan data dan database AWS lainnya, seperti Amazon S3 dan Amazon DynamoDB.

Keuntungan penting Amazon EMR terletak pada penggunaan pemrosesan paralel yang efektif dengan PySpark, yang menandai peningkatan signifikan dibandingkan kode Python sekuensial tradisional. Pendekatan inovatif ini menyederhanakan penerapan dan penskalaan kluster Apache Spark, memungkinkan paralelisasi yang efisien pada kumpulan data besar. Infrastruktur komputasi terdistribusi tidak hanya meningkatkan kinerja, namun juga memungkinkan pemrosesan data dalam jumlah besar dengan kecepatan yang belum pernah terjadi sebelumnya. Dilengkapi dengan perpustakaan, PySpark memfasilitasi pengoperasian seperti Excel DataFrame, dan abstraksi DataFrames tingkat tinggi menyederhanakan manipulasi data yang rumit, sehingga mengurangi kompleksitas kode. Dikombinasikan dengan penyediaan klaster otomatis, alokasi sumber daya dinamis, dan integrasi dengan layanan AWS lainnya, Amazon EMR terbukti menjadi solusi serbaguna yang cocok untuk beragam beban kerja, mulai dari pemrosesan batch hingga ML. Toleransi kesalahan yang melekat pada PySpark dan Amazon EMR meningkatkan ketahanan, bahkan jika terjadi kegagalan node, menjadikannya pilihan yang dapat diskalakan, hemat biaya, dan berkinerja tinggi untuk pemrosesan data paralel di AWS.

Amazon EMR memperluas kemampuannya melampaui kemampuan dasar, menawarkan beragam opsi penerapan untuk memenuhi beragam kebutuhan. Entah itu Amazon EMR di EC2, Amazon EMR di EKS, Amazon EMR Tanpa Server, atau Amazon EMR di AWS Outposts, Anda dapat menyesuaikan pendekatan Anda dengan kebutuhan spesifik. Bagi mereka yang mencari lingkungan tanpa server untuk pekerjaan Spark, integrasi Lem AWS juga merupakan pilihan yang layak. Selain mendukung berbagai kerangka kerja sumber terbuka, termasuk Spark, Amazon EMR memberikan fleksibilitas dalam memilih mode penerapan, Cloud komputasi elastis Amazon (Amazon EC2) jenis instans, mekanisme penskalaan, dan berbagai teknik pengoptimalan penghematan biaya.

Amazon EMR berdiri sebagai kekuatan dinamis di cloud, memberikan kemampuan tak tertandingi bagi organisasi yang mencari solusi data besar yang tangguh. Integrasinya yang lancar, fitur-fitur canggih, dan kemampuan beradaptasi menjadikannya alat yang sangat diperlukan untuk menavigasi kompleksitas analisis data dan ML di AWS.

Arsitektur yang didesain ulang

Diagram berikut menggambarkan arsitektur kami yang didesain ulang.

Solusi ini beroperasi berdasarkan kontrak API, di mana klien dapat mengirimkan konfigurasi transformasi, menentukan rangkaian operasi di samping lokasi kumpulan data S3 untuk diproses. Permintaan dimasukkan ke dalam antrean melalui Amazon SQS, lalu diarahkan ke Amazon EMR melalui fungsi Lambda. Proses ini memulai pembuatan langkah Amazon EMR untuk implementasi kerangka kerja Spark pada klaster EMR khusus. Meskipun Amazon EMR mengakomodasi jumlah langkah yang tidak terbatas selama masa pakai klaster yang berjalan lama, hanya 256 langkah yang dapat berjalan atau tertunda secara bersamaan. Untuk paralelisasi yang optimal, konkurensi langkah ditetapkan pada 10, sehingga memungkinkan 10 langkah dijalankan secara bersamaan. Jika terjadi kegagalan permintaan, Amazon SQS antrian surat mati (DLQ) mempertahankan acara tersebut. Spark memproses permintaan tersebut, menerjemahkan operasi seperti Excel ke dalam kode PySpark untuk rencana kueri yang efisien. DataFrames yang tangguh menyimpan input, output, dan data perantara dalam memori, mengoptimalkan kecepatan pemrosesan, mengurangi biaya I/O disk, meningkatkan kinerja beban kerja, dan mengirimkan output akhir ke lokasi Amazon S3 yang ditentukan.

Kami mendefinisikan SLA kami dalam dua dimensi: latensi dan throughput. Latensi didefinisikan sebagai jumlah waktu yang dibutuhkan untuk melakukan satu pekerjaan terhadap ukuran kumpulan data deterministik dan jumlah operasi yang dilakukan pada kumpulan data tersebut. Throughput didefinisikan sebagai jumlah maksimum pekerjaan simultan yang dapat dilakukan layanan tanpa melanggar SLA latensi suatu pekerjaan. SLA skalabilitas keseluruhan layanan bergantung pada keseimbangan penskalaan horizontal sumber daya komputasi elastis dan penskalaan vertikal masing-masing server.

Karena kami harus menjalankan 1,500 proses per hari dengan latensi minimal dan kinerja tinggi, kami memilih untuk mengintegrasikan Amazon EMR pada mode penerapan EC2 dengan penskalaan terkelola yang diaktifkan untuk mendukung pemrosesan ukuran file variabel.

Konfigurasi klaster EMR menyediakan banyak pilihan berbeda:

• Jenis simpul EMR – Node utama, inti, atau tugas
• Opsi pembelian instans – Instans Sesuai Permintaan, Instans Cadangan, atau Instans Spot
• Opsi konfigurasi – Armada instans EMR atau grup instans seragam
• Opsi penskalaan - Penskalaan Otomatis atau penskalaan terkelola Amazon EMR

Berdasarkan beban kerja variabel, kami mengonfigurasi armada instans EMR (untuk praktik terbaik, lihat Keandalan). Kami juga memutuskan untuk menggunakan penskalaan terkelola Amazon EMR untuk menskalakan inti dan simpul tugas (untuk skenario penskalaan, lihat Skenario alokasi node). Terakhir, kami memilih memori yang dioptimalkan Graviton AWS contoh, yang menyediakan hingga Biaya 30% lebih rendah dan peningkatan kinerja hingga 15% untuk beban kerja Spark.

Kode berikut memberikan gambaran konfigurasi cluster kami:

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Performance

Dengan migrasi kami ke Amazon EMR, kami dapat mencapai kinerja sistem yang mampu menangani berbagai set data, mulai dari 273 B hingga 88.5 GB dengan p99 dari 491 detik (sekitar 8 menit).

Gambar berikut menggambarkan variasi ukuran file yang diproses.

Gambar berikut menunjukkan latensi kami.

Untuk membandingkan dengan pemrosesan sekuensial, kami mengambil dua kumpulan data yang berisi 53 juta catatan dan menjalankan operasi VLOOKUP satu sama lain, bersama dengan 49 operasi serupa Excel lainnya. Proses ini memerlukan waktu 26 menit di layanan baru, dibandingkan dengan 5 hari untuk diproses di layanan lama. Peningkatan ini hampir 300 kali lebih besar dibandingkan arsitektur sebelumnya dalam hal kinerja.

Pertimbangan

Ingatlah hal berikut saat mempertimbangkan solusi ini:

• Cluster dengan ukuran yang tepat – Meskipun Amazon EMR dapat diubah ukurannya, penting untuk mengatur ukuran klaster dengan tepat. Penentuan ukuran yang tepat akan memitigasi klaster yang lambat, jika ukurannya terlalu kecil, atau biaya yang lebih tinggi, jika klasternya terlalu besar. Untuk mengantisipasi permasalahan tersebut, Anda dapat menghitung jumlah dan jenis node yang akan dibutuhkan untuk beban kerja tersebut.
• Langkah paralel – Menjalankan langkah-langkah secara paralel memungkinkan Anda menjalankan beban kerja tingkat lanjut, meningkatkan pemanfaatan sumber daya klaster, dan mengurangi jumlah waktu yang dibutuhkan untuk menyelesaikan beban kerja Anda. Jumlah langkah yang diizinkan untuk dijalankan pada satu waktu dapat dikonfigurasi dan diatur saat klaster diluncurkan dan kapan pun setelah klaster dimulai. Anda perlu mempertimbangkan dan mengoptimalkan penggunaan CPU/memori per pekerjaan ketika beberapa pekerjaan dijalankan dalam satu klaster bersama.
• Klaster EMR sementara berbasis pekerjaan – Jika memungkinkan, disarankan untuk menggunakan klaster EMR sementara berbasis pekerjaan, yang memberikan isolasi unggul, memverifikasi bahwa setiap tugas beroperasi dalam lingkungan khusus. Pendekatan ini mengoptimalkan pemanfaatan sumber daya, membantu mencegah gangguan antar pekerjaan, dan meningkatkan kinerja dan keandalan secara keseluruhan. Sifat sementara memungkinkan penskalaan yang efisien, memberikan solusi yang kuat dan terisolasi untuk beragam kebutuhan pemrosesan data.
• ESDM Tanpa Server – EMR Tanpa Server adalah pilihan ideal jika Anda memilih untuk tidak menangani pengelolaan dan pengoperasian cluster. Ini memungkinkan Anda menjalankan aplikasi dengan mudah menggunakan kerangka kerja sumber terbuka yang tersedia dalam EMR Serverless, menawarkan pengalaman yang mudah dan tidak merepotkan.
• Amazon EMR di EKS – Amazon EMR di EKS menawarkan keunggulan berbeda, seperti waktu startup yang lebih cepat dan peningkatan skalabilitas dalam mengatasi tantangan kapasitas komputasi—yang sangat bermanfaat bagi pengguna Graviton dan Spot Instance. Penyertaan jenis komputasi yang lebih luas akan meningkatkan efisiensi biaya, sehingga memungkinkan alokasi sumber daya yang disesuaikan. Selain itu, dukungan Multi-AZ memberikan peningkatan ketersediaan. Fitur-fitur menarik ini memberikan solusi tangguh untuk mengelola beban kerja big data dengan peningkatan kinerja, optimalisasi biaya, dan keandalan di berbagai skenario komputasi.

Kesimpulan

Dalam postingan ini, kami menjelaskan bagaimana Amazon mengoptimalkan proses rekonsiliasi keuangan bervolume tinggi dengan Amazon EMR untuk skalabilitas dan kinerja yang lebih tinggi. Jika Anda memiliki aplikasi monolitik yang bergantung pada penskalaan vertikal untuk memproses permintaan atau kumpulan data tambahan, maka memigrasikannya ke kerangka pemrosesan terdistribusi seperti Apache Spark dan memilih layanan terkelola seperti Amazon EMR untuk komputasi dapat membantu mengurangi waktu proses untuk menurunkan pengiriman Anda SLA, dan juga dapat membantu mengurangi Total Biaya Kepemilikan (TCO).

Saat kami memanfaatkan Amazon EMR untuk kasus penggunaan khusus ini, kami mendorong Anda untuk mengeksplorasi kemungkinan lebih lanjut dalam perjalanan inovasi data Anda. Pertimbangkan untuk mengevaluasi AWS Glue, bersama dengan opsi penerapan Amazon EMR dinamis lainnya seperti EMR Tanpa Server atau Amazon EMR di EKS, untuk menemukan layanan AWS terbaik yang disesuaikan dengan kasus penggunaan unik Anda. Masa depan perjalanan inovasi data memiliki kemungkinan dan kemajuan menarik untuk dieksplorasi lebih lanjut.

Tentang Penulis

Jeeshan Khetrapal adalah Insinyur Pengembangan Perangkat Lunak Senior di Amazon, tempat ia mengembangkan produk fintech berdasarkan arsitektur tanpa server komputasi awan yang bertanggung jawab atas kendali umum TI perusahaan, pelaporan keuangan, dan kendali atas tata kelola, risiko, dan kepatuhan.

Sakti Misra adalah Arsitek Solusi Utama di AWS, yang membantu pelanggan memodernisasi arsitektur data mereka dan menentukan strategi data menyeluruh, termasuk keamanan data, aksesibilitas, tata kelola, dan banyak lagi. Dia juga penulis buku tersebut Sederhanakan Analisis Big Data dengan Amazon EMR. Di luar pekerjaan, Sakti senang mempelajari teknologi baru, menonton film, dan mengunjungi tempat-tempat bersama keluarga.

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• PlatoData.Jaringan Vertikal Generatif Ai. Berdayakan Diri Anda. Akses Di Sini.
• PlatoAiStream. Intelijen Web3. Pengetahuan Diperkuat. Akses Di Sini.
• PlatoESG. Karbon, teknologi bersih, energi, Lingkungan Hidup, Tenaga surya, Penanganan limbah. Akses Di Sini.
• PlatoHealth. Kecerdasan Uji Coba Biotek dan Klinis. Akses Di Sini.
• Sumber: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/