PPL - TUGAS 5 - Low Level Design

Nama: Muhammad Razan Athallah
NRP: 5025211008
Kelas: PPL A
Tahun: 2023/2024 (Genap)

Tugas kelima (pertemuan 6) berupa latihan mengidentifikasi dan menganalisis High Level Design (HLD) dan Low Level Design (LLD) dari suatu sistem aplikasi. Referensi saya ambil dari link berikut ini: https://www.geeksforgeeks.org/design-dropbox-a-system-design-interview-question/

System Requirements

Functional Requirements

• Pengguna harus dapat mengunggah foto/berkas.
• Pengguna harus dapat membuat/menghapus direktori di drive.
• Pengguna harus dapat mengunduh berkas.
• Pengguna harus dapat membagikan berkas yang diunggah.
• Drive harus menyinkronkan data antara semua perangkat pengguna.

Non-Functional Requirements

• Ketersediaan: Ketersediaan berarti persentase waktu sistem tersedia untuk menerima permintaan pengguna. 
• Daya Tahan: Daya tahan berarti data yang diunggah oleh pengguna harus disimpan secara permanen di database bahkan jika terjadi kegagalan database. Sistem harus memastikan bahwa berkas yang diunggah oleh pengguna disimpan secara permanen di drive tanpa kehilangan data.
• Keandalan: Keandalan berarti seberapa sering sistem memberikan output yang diharapkan untuk input yang sama.
• Skalabilitas: Dengan bertambahnya jumlah pengguna, sistem kami harus cukup mampu menangani peningkatan lalu lintas.
• Properti ACID: Atomicity, Consistency, Integrity, dan Durability. Semua operasi berkas harus mengikuti properti ini.

Estimasi Kapasitas

Asumsikan jumlah pengguna total adalah 500 juta, sedangkan jumlah pengguna harian mencapai angka 100 juta. Asumsikan rata-rata banyaknya file yang disimpan seorang pengguna sebanyak 200 file dengan rata-rata ukuran tiap file 100 KB. Sehingga dengan total pengguna 500 juta, akan ada 100 miliar file yang disimpan, dengan total penyimpanan 10 PB.

High Level Design

Pengunggahan Pengguna

Pengguna berinteraksi dengan aplikasi klien atau antarmuka web untuk memulai pengunggahan berkas. Aplikasi klien berkomunikasi dengan Layanan Unggah di sisi server. Berkas besar dapat dipecah menjadi potongan-potongan lebih kecil untuk transfer yang efisien.

Layanan Unggah

Menerima permintaan pengunggahan berkas dari klien. Menghasilkan URL yang telah ditandatangani sebelumnya (Presigned URL) untuk S3 agar klien dapat mengunggah langsung. Mengkoordinasikan proses pengunggahan, memastikan integritas dan kelengkapan data. Setelah pengunggahan berhasil, memperbarui Database Metadata dengan rincian berkas. Mengkoordinasikan proses pengunggahan, memecah berkas besar menjadi potongan yang lebih mudah dikelola jika diperlukan.

Mendapatkan URL

Aplikasi klien meminta URL yang telah ditandatangani sebelumnya dari Layanan Unggah. Server menghasilkan URL yang telah ditandatangani sebelumnya dengan berinteraksi dengan layanan S3, menciptakan token unik untuk operasi pengunggahan tertentu. URL ini memberikan akses sementara dan aman untuk mengunggah berkas tertentu ke bucket S3 yang ditunjuk. Memungkinkan klien untuk melewati server dan berkomunikasi langsung dengan lapisan penyimpanan.

Bucket S3

S3 berfungsi sebagai penyimpanan backend yang skalabel dan tahan lama. URL yang telah ditandatangani sebelumnya memungkinkan klien untuk mengunggah langsung ke S3, meminimalkan keterlibatan server dalam transfer berkas yang sebenarnya. Struktur bucket dapat mengorganisir berkas berdasarkan akun pengguna dan metadata.

Database Metadata

Menyimpan metadata yang terkait dengan setiap berkas, termasuk rincian seperti nama, ukuran, pemilik, izin akses, dan cap waktu. Memungkinkan pengambilan rincian berkas dengan cepat tanpa mengakses S3. Memastikan bahwa metadata berkas konsisten dengan konten yang sebenarnya di S3.

Mengunggah ke S3

Klien menggunakan URL yang telah ditandatangani sebelumnya untuk mengunggah berkas langsung ke bucket S3 yang ditunjuk. Metadata yang terkait dengan berkas, seperti nama berkas dan pemilik, disertakan dalam proses pengunggahan. Ini memastikan bahwa metadata berkas disinkronkan dengan data yang sesuai di S3.

Peran Task Runner

Setelah berkas berhasil diunggah ke S3, proses task runner dipicu. Task runner berkomunikasi dengan Database Metadata untuk memperbarui atau melakukan tugas tambahan yang terkait dengan berkas yang diunggah. Ini dapat mencakup memperbarui status berkas, memicu pengindeksan untuk fungsi pencarian, atau mengirim notifikasi.

Layanan Pengunduhan

Klien memulai permintaan pengunduhan berkas melalui aplikasi klien. Layanan Pengunduhan menanyakan Database Metadata untuk rincian berkas. Layanan Pengunduhan server mengambil metadata dari Database Metadata. Metadata mencakup informasi seperti nama berkas, ukuran, pemilik, dan izin akses.

Low Level Design

Berikut komponen-komponen dari aplikasi dropbox:

Misalkan kita memiliki klien yang terpasang di komputer kita (aplikasi yang terpasang di komputer Anda) dan klien ini memiliki 4 komponen dasar. Komponen dasar ini adalah Watcher, Chunker, Indexer, dan Internal DB. Kami hanya mempertimbangkan satu klien tetapi ada beberapa klien yang mungkin milik pengguna yang sama dengan komponen dasar yang sama.

• Klien bertanggung jawab untuk mengunggah/mengunduh berkas, mengidentifikasi perubahan berkas di folder sinkronisasi, dan menangani konflik akibat pembaruan offline atau bersamaan. 
• Klien secara aktif memantau folder untuk semua pembaruan atau perubahan yang terjadi pada berkas. 
• Untuk menangani pembaruan metadata berkas (misalnya nama berkas, ukuran, tanggal modifikasi, dll.) klien ini berinteraksi dengan layanan Pesan dan Layanan Sinkronisasi. 
• Klien juga berinteraksi dengan penyimpanan cloud jarak jauh (Amazon S3 atau layanan cloud lainnya) untuk menyimpan berkas yang sebenarnya dan menyediakan sinkronisasi folder.

Komponen Klien

• Watcher bertanggung jawab untuk memantau folder sinkronisasi untuk semua aktivitas yang dilakukan oleh pengguna seperti membuat, memperbarui, atau menghapus berkas/folder. Memberikan notifikasi kepada indexer dan chunker jika ada tindakan yang dilakukan pada berkas atau folder.
• Chunker membagi berkas menjadi beberapa bagian kecil yang disebut chunk dan mengunggahnya ke penyimpanan cloud dengan ID atau hash unik dari potongan-potongan ini. Untuk membuat ulang berkas, potongan-potongan ini dapat digabungkan kembali. Untuk setiap perubahan pada berkas, algoritma chunking mendeteksi potongan spesifik yang dimodifikasi dan hanya menyimpan bagian/potongan tersebut ke penyimpanan cloud. Ini mengurangi penggunaan bandwidth, waktu sinkronisasi, dan ruang penyimpanan di cloud.
• Indexer bertanggung jawab untuk memperbarui database internal ketika menerima notifikasi dari watcher (untuk setiap tindakan yang dilakukan pada folder/berkas). Menerima URL potongan dari chunker bersama dengan hash dan memperbarui berkas dengan potongan yang dimodifikasi. Indexer berkomunikasi dengan Layanan Sinkronisasi menggunakan Layanan Antrian Pesan, setelah potongan berhasil diserahkan ke penyimpanan cloud.
• Database Internal menyimpan semua informasi berkas dan potongan, versinya, dan lokasi mereka dalam sistem berkas.

Basis Data Metadata

Basis data metadata ini mempertahankan indeks dari berbagai potongan. Informasi tersebut mencakup nama berkas/potongan, serta versi-versi yang berbeda beserta informasi pengguna dan ruang kerja.

Anda dapat menggunakan RDBMS atau NoSQL tetapi pastikan untuk memenuhi sifat konsistensi data karena beberapa klien akan bekerja pada berkas yang sama. Dengan RDBMS, tidak ada masalah dengan konsistensi, tetapi dengan NoSQL, Anda akan mendapatkan konsistensi eventual.

Antrian Layanan Pesan

Antrian layanan pesan bertanggung jawab atas komunikasi asinkron antara klien-klien dan layanan sinkronisasi.

Di bawah ini adalah persyaratan utama dari Layanan Antrian Pesan.

• Kemampuan untuk menangani banyak permintaan baca dan tulis.
• Menyimpan banyak pesan dalam antrian yang sangat tersedia dan dapat diandalkan.
• Kinerja tinggi dan skalabilitas yang baik.
• Memberikan penyeimbangan beban dan elastisitas untuk beberapa instansi Layanan Sinkronisasi.

Akan ada dua jenis antrian pesan dalam layanan ini.

Antrian Permintaan:

• Ini akan menjadi antrian permintaan global yang dibagikan di antara semua klien.
• Setiap kali klien menerima pembaruan atau perubahan dalam berkas/folder, ia mengirimkan permintaan melalui antrian permintaan.
• Permintaan ini diterima oleh layanan sinkronisasi untuk memperbarui basis data metadata.

Antrian Tanggapan:

• Akan ada antrian tanggapan individu yang sesuai dengan masing-masing klien.
• Layanan sinkronisasi menyebarkan pembaruan melalui antrian tanggapan ini, dan antrian tanggapan ini akan mengirimkan pesan-pesan yang diperbarui kepada setiap klien. Kemudian klien-klien ini akan memperbarui berkas-berkas mereka sesuai dengan pesan yang diterima.
• Pesan tidak akan pernah hilang bahkan jika klien terputus dari internet (manfaat dari menggunakan layanan antrian pesan).
• Kami membuat n jumlah antrian tanggapan untuk n jumlah klien karena pesan akan dihapus dari antrian setelah diterima oleh klien, dan kami perlu berbagi pesan yang diperbarui dengan berbagai klien yang berlangganan.

Layanan Sinkronisasi

Klien berkomunikasi dengan layanan sinkronisasi untuk menerima pembaruan terbaru dari penyimpanan cloud atau untuk mengirim permintaan/pembaruan terbaru ke Penyimpanan Cloud.

• Layanan sinkronisasi menerima permintaan dari antrian permintaan dari layanan pesan dan memperbarui basis data metadata dengan perubahan terbaru.
• Selain itu, layanan sinkronisasi menyiarkan pembaruan terbaru kepada klien-klien lain (jika ada beberapa klien) melalui antrian tanggapan sehingga indexer klien lain dapat mengambil kembali potongan-potongan dari penyimpanan cloud dan membuat ulang berkas dengan pembaruan terbaru.
• Layanan ini juga memperbarui basis data lokal dengan informasi yang tersimpan dalam Basis Data Metadata. Jika klien tidak terhubung ke internet atau offline untuk sementara waktu, klien akan memeriksa sistem untuk pembaruan baru segera setelah terhubung kembali ke internet.

Penyimpanan Cloud

Anda dapat menggunakan layanan penyimpanan cloud seperti Amazon S3 untuk menyimpan potongan-potongan berkas yang diunggah oleh pengguna. Klien berkomunikasi dengan penyimpanan cloud untuk setiap tindakan yang dilakukan pada berkas/folder menggunakan API yang disediakan oleh penyedia cloud.

Database Design

Berikut tabel-tabel untuk menyimpan data:

Users

{

  user_id(PK)

  name

  email

  password

  last_login_at

  created_at

  updated_at

}

Devices

{

  device_id(PK)

  user_id(FK)

  created_at

  updated_at

}

Objects

{

    object_id(PK)

    device_id(PK,FK)

    object_type

    parent_object_id

    name

    created_at

    updated_at

}

Chunks

{

    chunks_id(PK)

    object_id(PK,FK)

    url

    created_at

    updated_at

}

AcessControlList

{

    user_id(PK,FK1)

    object_id(PK,FK2)

    created_at

    update_at

}

Dengan syarat-syarat berikut:

• Setiap user harus memiliki setidaknya satu device. 
• Setiap device akan memiliki setidaknya satu object (file atau folder). 
• Setelah user mendaftar, kami membuat folder root untuk memastikan dia memiliki setidaknya satu object. 
• Setiap object mungkin memiliki chunk. Hanya file yang dapat memiliki chunk, folder tidak dapat memiliki chunk. 
• Setiap object mungkin dibagikan dengan satu atau beberapa user. 
• Pemetaan ini dikelola dalam AccessControlList.

API Design

Download Chunk

Digunakan untuk mendownload chunk dari file.

Request:

GET /api/v1/chunks/:chunk_id

X-API-Key: api_key

Authorization: auth_token

Response

Response:

200 OK

Content-Disposition: attachment; filename="<chunk_id>"

Content-Length: 4096000

The response will contain Content-Disposition header as attachment which will instruct the client to download the chunk. Note that Content-Length is set as 4096000 as each chunk is of 4 MB.

Upload Chunk

Digunakan untuk mengunggah chunk

Request

POST /api/v1/chunks/:chunk_id

X-API-Key: api_key

Authorization: auth_token

Content-Type: application/octet-stream

/path/to/chunk

Response

201 Created

Get Objects

Digunakan oleh klien untuk menanyakan Layanan Meta (Meta Service) tentang berkas/folder baru ketika mereka online. Klien akan mengirimkan id objek maksimum yang ada secara lokal dan id perangkat unik.

Request

GET /api/v1/objects?local_object_id=<Max object_id present locally>&device_id=<Unique Device Id>

X-API-Key: api_key

Authorization: auth_token

Response

200 OK

{

  new_objects: [

    {

      object_id:

      object_type:

      name:

      chunk_ids: [

        chunk1,

        chunk2,

        chunk3

      ]

    }

  ]

}

Skalabilitas

Skalabilitas Horizontal

Kita dapat menambahkan lebih banyak server di belakang load balancer untuk meningkatkan kapasitas setiap layanan. Ini dikenal sebagai Skalabilitas Horizontal dan setiap layanan dapat diskalakan secara horizontal secara independen dalam desain kita.

Sharding Database

Database Metadata di-shard berdasarkan object_id. Fungsi hash kita akan memetakan setiap object_id ke server acak tempat kita dapat menyimpan metadata berkas/folder. Untuk menanyakan object_id tertentu, layanan dapat menentukan server database menggunakan fungsi hash yang sama dan menanyakan data. Pendekatan ini akan mendistribusikan beban database kita ke beberapa server sehingga menjadi skalabel.

Sharding Cache

Mirip dengan Sharding Database Metadata, kita mendistribusikan cache ke beberapa server. Bahkan, Redis memiliki dukungan bawaan untuk pembagian data di beberapa instance Redis. Penggunaan Hash Konsisten untuk mendistribusikan data di seluruh instance memastikan bahwa beban didistribusikan secara merata jika satu instance tidak berfungsi.