NETWORK AKAMAI: SEBUAH PLATFORM UNTUK APLIKASI INTERNET HIGH-PERFORMANCE

NETWORK AKAMAI: SEBUAH PLATFORM UNTUK APLIKASI INTERNET HIGH-PERFORMANCE ABSTRAK

Akamai Platform memiliki lebih dari 61000 server di 1000 network di 70 negara di dunia. Akamai Platform memberikan ratusan milyar interaksi Internet setiap harinya, dan membantu ribuan perusahaan meningkatkan kinerja dan reliability aplikasi Internetnya. Di paper ini, kita akan mengulas komponen dan kapabilitas platform komputing distribusi skala-besar, dan menawarkan beberapa wawasan tentang arsitektur, prinsip desain, operasi dan manajemen.

Kategori dan Deskriptor Subyek

C.2.1. (Arsitektur dan Desain Network): Network Distributif

C.2.4. (Sistem Distributif): Aplikasi Distributif, Sistem Operasi Network

Istilah Umum

Algorithma, Manajemen, Kinerja, Desain, Reliabilitas, Keamanan, Toleransi Fault

Kata Kunci

Akamai, CDN, network overlay, akselerasi aplikasi, HTTP, DNS, deliveri konten, kualitas layanan, media streaming

1. PENDAHULUAN

Internet telah merubah setiap aspek masyarakat manusia dengan memudahkan berbagai aplikasi untuk bisnis, perdagangan, hiburan, berita dan social networking. Internet tidak pernah ditata untuk mendukung level kinerja, reliability, dan scalability yang dibutuhkan oleh aplikasi komersil jaman sekarang, dan karena itu, ini menciptakan hambatan teknis signifikan bagi pihak yang ingin bertransaksi bisnis di Web. Selain itu, hambatan yang ada menjadi menantang ketika aplikasi sekarang dan masa depan mulai berevolusi.

Akamai pertama kali merintis konsep Content Delivery Network (CDN) lebih dari satu dekade lalu untuk membantu bisnis mengatasi hambatan teknisnya. Sejak itu, Web dan Platform dari Akamai mengalami perkembangan pesat. Saat ini, Akamai telah mendeliveri 15-20 % semua traffic Web di dunia dan memberikan berbagai layanan komersil selain deliveri konten, seperti akselerasi aplikasi Web dan IP, EdgeComputing, deliveri dalam media live dan media on-demand high-definition (HD), high-availability storage, analisis, dan layanan DNS otoritatif.

Paper akan memberikan ulasan tentang Akamai Platform, termasuk diskusi banyak teknologi kunci dan pendekatan arsitektural yang digunakan untuk mencapai hasil. Dari situ, diharap bisa didapatkan wawasan tentang berbagai platform dan luas penelitian dan inovasi teknologi yang dibutuhkan untuk menghasilkan sistem dalam skala yang dimaksud.

Paper disusun seperti berikut. Pertama, kita akan menjelaskan ruang masalah dan mencermati motivasi penciptaan platform. Selanjutnya, ulasan Akamai Platform berisi penjelasan bagaimana cara mengatasi batasan Internet dalam deliveri konten web, media stream, dan aplikasi dinamis. Kita akan memberikan kasus dimana network distributif adalah arsitektur paling efektif untuk tujuan ini, khususnya ketika konten menjadi lebih interaktif dan lebih lapar bandwidth. Kita perlu melihat detail komponen Akamai Platform, dengan fokus ke prinsip desain dan arsitektur toleran fault. Terakhir, kita menawarkan cross-section dari hasil konsumen untuk memvalidasi efficacy dunia-riil dari platform.

2. KEBUTUHAN APLIKASI INTERNET

Aplikasi dan layanan usaha modern di Internet membutuhkan kualitas sistem end-to-end, karena degradasi kecil dalam kinerja dan reliability pun bisa memiliki dampak bisnis. Outage (gagal koneksi) satu-jam saja bisa memberikan biaya ratusan ribu sampai jutaan dolar dalam bentuk hilangnya pendapatan bagi sebuah situs e-commerce besar. Selain itu, outage bisa menimbulkan kerusakan pada reputasi brand. Biaya downtime aplikasi usaha juga besar, dan bisa diukur dalam hilangnya pendekatan dan pengurangan produktivitas.

Kinerja aplikasi berhubungan langsung dengan metrik bisnis seperti tingkat penggunaan aplikasi dan tingkat konversi situs. Survey Forrester Consulting 2009 menunjukkan bahwa mayoritas online shopper menyebut kinerja website sebagai faktor penting dalam loyalitas toko online, dan bahwa 40 % konsumen menunggu tidak lebih dari 3 detik untuk men-load satu page sebelum keluar dari situs tersebut. Kita bisa menemukan kuantifikasi lebih konkrit dari efek ini di sebuah studi Akamai dalam satu website e-commerce. Dalam studi ini, pengunjung situs dipecah. Separuh diarahkan ke situs lewat Akamai (memberikan pengalaman high-performance), sedangkan separuh lainnya dikirim langsung ke server asal situs. Analisis memperlihatkan bahwa 15 % user situs high-performance cenderung menyelesaikan pembelian, dan 9 % jarang mengabaikan situs setelah melihat satu page. Untuk aplikasi B2B, ceritanya sama. Di survey IDC tahun 2009, konsumen yang menggunakan layanan akselerasi aplikasi usaha Akamai melaporkan peningkatan pendapatan tahunan 200 ribu dolar menjadi 3 juta dolar, dan ini langsung dihubungkan dengan peningkatan kinerja dan reliability aplikasi.

Sayangnya, batasan dalam arsitektur Internet menyulitkan pencapaian level kinerja di Internet. Ketika didesain sebagai network usaha-terbaik, Internet tidak memberikan jaminan pada reliability atau kinerja end-to-end. Sebaliknya, komunikasi Internet area-luas dihadapkan dengan bottleneck yang berdampak buruk ke kinerja, termasuk latensi, loss paket, outage network, protokol yang tidak mencukupi, dan friksi lintas-network.

Selain itu, ada pertanyaan serius, yaitu apakah Internet bisa memiliki skala untuk mengakomodasi kebutuhan video online. Bahkan, proyeksi jangka pendek memperlihatkan level kapasitas yang dibutuhkan, yang kadarnya lebih besar dibanding yang dilihat di Internet sekarang ini. Distribusi programming kualitas-HD ke audiens global membutuhkan puluhan pentabit per detik kapasitas, dan ini diartikan sebagai peningkatan beberapa kadar ukuran.

Hubungan gap teknologi antara kapabilitas terbatas infrastruktur Internet dan kebutuhan kinerja dari aplikasi distribusi sekarang dan masa depan, karena itu, menjadi penting bagi pertumbuhan dan kesuksesan Internet yang kontinyu, dan viabilitasnya bagi bisnis. Kita perlu mengamati lebih dekat mengapa ini menantang.3. TANTANGAN DELIVERI INTERNET

Meski sering disebut sebagai sebuah entitas, Internet berisi ribuan network berbeda, yang masing-masing memberikan akses ke persentase kecil end user. Network terbesar hanya 5 % dari traffic akses Internet, dan persentase ini bisa turun tajam (Gambar 1). Faktanya, butuh 650 network untuk menghasilkan 90 % semua traffic akses. Gambar 1. Persentase traffic akses dari top network

Sayangnya, komunikasi data inter-network bukanlah operasi efisien atau reliabel, dan bisa dipengaruhi secara buruk oleh beberapa faktor. Yang paling signifikan adalah:

Kemacetan peering point. Kapasitas di peering point dimana beberapa network bertukar traffic bisa lambat karena struktur ekonomi dari Internet. Uang mengalir ke dalam di mil pertama (yaitu website hosting) dan di mil terakhir (yaitu end user), dan mendorong investasi di infrastruktur mil pertama dan terakhir. Meski begitu, ada sedikit insentif ekonomi untuk network untuk berinvestasi di mil tengah yaitu peering point yang high-cost dan zero-revenue dimana network dipaksa bekerjasama dengan entitas pesaing. Peering point seperti ini akan menjadi bottleneck yang nantinya menimbulkan packet loss dan meningkatkan latensi. Protokol routing yang tidak efisien. Meski dipuji karena bisa menjadi skala Internet dalam usaha terbaik, BGP memiliki beberapa batasan. Salahsatunya adalah bahwa ini tidak didesain untuk kinerja. BGP mendasarkan hitungan route-nya pada AS hop count, dan tidak menjelaskan apapun tentang topologi, latensi, atau kemacetan waktu-riil dari network. Dalam prakteknya, network kadang dipaksa melakukan agreement bisnis dengan satu sama lain, bukan memberikan kinerja end-to-end yang baik. Contoh, ada beberapa path antar lokasi di Asia yang di-route lewat peering point di US, yang pastinya meningkatkan latensi. Selain itu, ketika route berhenti kerja, atau konektivitasnya menurun, maka BGP bisa lambat dalam mengkonvergensi route baru. Terakhir, BGP rawan terhadap human error atau foul play. Route yang miskonfigurasi atau dibajak dengan cepat akan berpropagasi diine, yang menimbulkan route flapping, bloated path, dan outage konektivitas yang luas. Network yang tidak reliabel. Di Internet, outage terjadi di setiap waktu yang disebabkan oleh banyak alasan, seperti kabel putus, router miskonfigurasi, serangan DDoS, outage power, bahkan gempa bumi dan bencana alam lain. Meski failure-nya bisa berbeda dalam skop, okurensi skala besar jarang terjadi. Di bulan Januari 2008, contohnya, komponen Asia Tenggara dan Timur Tengah merasakan estimasi reduksi 75 % dalam konektivitas bandwidth ketika sejumlah kabel di bawah laut mengalami putus aksidental. Di bulan Desember di tahun yang sama, insiden putus kabel lainnya menimbulkan outage di sejumlah network di Mesir dan India. Di dua kasus tersebut, gangguan terjadi sampai beberapa hari.

Hubungan peering yang rapuh bisa menjadi batasan. Ketika dua network mengalami de-peering selama perselisihan bisnis, maka ini bisa menimbulkan partisi Internet, sehingga konsumen dari satu network tidak akan mampu menjangkau konsumen di network lain. Selama de-peering profil-tinggi antara Sprint dan Cogent di bulan Oktober 2008, konektivitas dari 3500 network mendapatkan efek buruk. Contoh profil tinggi dari outage Internet yang disebabkan pembajakan BGP juga ada, seperti blackout YouTube yang disebabkan oleh Pakistan di bulan Pebruari 2008, atau meluasnya outage Internet yang disebabkan bocornya China Telecom di bulan April 2010.

Protokol komunikasi yang tidak efisien. Meski ini didesain untuk reliability dan avoidansi-kongesi (kemacetan), TCP memiliki overhead signifikan dan mempunyai kinerja suboptimal yang menimbulkan latensi tinggi atau packet loss, yang umum terjadi di Internet area luas. Kongesi mil tengah memperburuk masalah, karena packet loss memicu retransmisi TCP, yang lebih jauh memperlambat komunikasi.

Selain itu, untuk aplikasi interaktif, ada multiple round trip yang dibutuhkan untuk permintaan HTTP, dan ini mempengaruhi kinerja aplikasi. Sebagian besar web browser juga membatasi jumlah koneksi paralel yang dibuat untuk nama host tertentu, dan ini membatasi kinerja jangka panjang bagi situs yang berisi banyak obyek.TCP juga menjadi bottleneck kinerja serius untuk file video dan file besar lainnya. Karena ini membutuhkan pemahaman receiver di setiap window paket data yang dikirim, maka throughput (ketika menggunakan TCP standar) berhubungan terbalik dengan latensi network atau round trip time (RTT). Karena itu, jarak antara server dan end user bisa menjadi bottleneck untuk kecepatan download dan kualitas pandang video. Tabel 1 menunjukkan hasil mengejutkan dari efek ini. HD Quality Stream baik, contohnya, sulit didapatkan jika server tidak relatif dekat. Tabel 1. Efek Jarak Terhadap Throughput dan Waktu Download

Jarak

(Server ke User)RTT NetworkPacket Loss TipikalThroughputWaktu Download DVD 4GB

Lokal:

< 100 mil1,6 mdet0,6 %44 Mbps (HDTV high-quality)12 menit

Regional:

500-1000 mil16 mdet0,7 %4 Mbps (HDTV dasar)2,2 jam

Lintas-kontinen:

- 3000 mil 48 mdet1,0 %1 Mbps (SDTV)8,2 jam

Multi-kontinen:

- 6000 mil96 mdet1,4 %0,4 Mbps (buruk)20 jam

Meski protokol alternate dan peningkatan kinerja TCP telah banyak diulas di literatur, prakteknya sangat lambat ke end user dunia riil, dan karena itu, implementasi di Internet menjadi tugas yang menantang. Scalability. Proses scaling aplikasi Internet berarti harus memiliki sumberdaya yang cukup untuk merespon kebutuhan instant, apakah selama kejadian yang direncanakan atau periode peak traffic yang tidak terduga. Proses scaling dan mirroring infrastruktur asal cenderung mahal dan memakan waktu, dan sulit memprediksi kebutuhan kapasitas secara advans. Sayangnya, situasi underprovisioning berarti hilang bisnis, sedangkan overprovisioning berarti membuang uang dalam infrastruktur yang tidak digunakan. Selain itu, kebutuhan website sering sangat tajam, yang berarti bahwa perusahaan perlu menyiapkan provisi untuk peak seperti promosi, event (acara/kejadian), dan serangan, dan karena itu, harus berinvestasi dalam infrastruktur signifikan yang sering tidak digunakan setiap waktu. Ini memiliki biaya lingkungan bila infrastruktur yang tidak digunakan ini memakan power yang besar dan signifikan. Terakhir, penting untuk dicatat bahwa scalability asal ini hanyalah bagian dari tantangan scalability. Scalability aplikasi end-to-end bukan hanya memastikan bahwa ada kapasitas server asal yang cukup, tapi juga memastikan ada bandwidth network yang cukup untuk semua point antara end user dan aplikasi yang ingin diakses. Ini adalah pertimbangan serius untuk jaman video Internet. Batasan aplikasi dan tingkat adopsi perubahan yang lambat. Meski beberapa tantangan yang dirasakan Internet telah sebagian bisa diatasi dengan merubah protokol dan/atau software klien, sejarah menunjukkan bahwa ini adalah perubahan yang lambat. Bila perusahaan ingin memberikan kinerja terbaik ke end usernya, mereka sering kurang atau tidak bisa mengontrol software end user. Selain itu, perubahan sulit dijalankan bila harus membutuhkan tingkat adopsi klien 100 %. Bila tingkat adopsi tersebut dijalankan, klien lama akan terbuang, meski keuntungan dari perubahan protokol bisa didapat secepat ketika klien dan server menggunakannya. Banyak perusahaan sering tidak suka menyetel kinerja infrastruktur web-nya dengan semua software klien yang cenderung heterogen. Microsofts Internet Explorer 6 (yang kinerjanya lebih rendah dibanding versi selanjutnya dan tidak cocok dijalankan optimisasi protokol seperti kompresi gzip) masih menjadi browser paling populer untuk penggunaan bulan Desember 2009, meski releasenya sudah lebih dari 8 tahun yang lalu.4. ULASAN NETWORK DELIVERI

Tantangan deliveri Internet di atas menggambarkan betapa sulitnya perusahaan meraih level kinerja, reliability, dan scalability efektif-biaya yang diharapkan di dalam operasi Web. Banyak bottleneck sulit dikontrol oleh entitas, dan selalu dipengaruhi oleh cara kerja Internet yaitu patchwork dari network otonom heterogen yang kurang terkoordinasi.

Di satu dekade lalu, Akamai memperkenalkan konsep Content Delivery Network (CDN) untuk mengatasi ini. Awalnya, CDN bisa memperbaiki kinerja website dengan men-caching konten situs statis di edge Internet, lebih dekat ke end user, agar bisa menghindari bottleneck mil tengah. Sejak itu, teknologi tersebut berkembang pesat menjauh dari deliveri konten web statis. Saat ini, Akamai memiliki network deliveri aplikasi yang bisa mempercepat aplikasi web keseluruhan atau basis-IP , network deliveri media yang memberikan deliveri kualitas-HD di media live dan media on-demand, dan network EdgeComputing yang memasang dan menjalankan aplikasi Java J2EE dalam cara distributif.

Selain itu, tawaran layanan juga dimaturekan agar bisa memenuhi kebutuhan perusahaan seperti kemampuan mempertahankan visibilitas dan mengontrol konten di network distributif. Ini berarti memberikan kepastian keamanan, logging, SLA, diagnostik, pelaporan dan analitik, dan alat manajemen. Terkait dengan deliveri konten itu sendiri, ada tantangan skala, reliability dan kinerja yang harus diatasi. 4.1. Network Deliveri sebagai Network Virtual

Secara konseptual, network deliveri adalah network virtual yang dibangun sebagai layer software di atas Internet aktual, yang dipasang pada hardware distributif, dan disesuaikan dengan kebutuhan sistem aplikasi dan layanan distributif (Gambar 2). Sebuah network deliveri memberikan aspek peningkatan reliability, kinerja, scalability dan keamanan yang jarang bisa diberikan saat menggunakan langsung Internet. Sebuah CDN, dalam hal deliveri konten web statis, adalah satu tipe dari network deliveri.Gambar 2. Sebuah network deliveri adalah sebuah network virtual yang dibangun sebagai layer software di atas Internet aktual, yang dipasang pada hardware distributif.

Sebuah pendekatan pendukung, tapi beda, ke tantangan aplikasi Internet adalah me-redesain Internet secara clean-slate. Meski proses re-arsitektur Internet selalu menguntungkan, penggunaannya di dunia riil tidak terjamin. Dengan ratusan milyar dolar di dalam investasi sink dan juga entrenched adoption oleh puluhan ribu entitas, maka arsitektur Internet yang sekarang berubah secara lambat. Contoh, perhatikan bahwa IPv6 perubahan inkremental yang dibutuhkan adalah perubahan yang pertama kali digagas di tahun 1996, tapi baru benar-benar dilaksanakan (deployment) hampir di 15 tahun kemudian.

Keindahan dari pendekatan network virtual adalah bahwa ini dijalankan di Internet, tidak membutuhkan software klien dan tidak ada perubahan dalam network dasarnya. Karena dibuat hampir sepenuhnya di dalam software, maka ini dengan mudah bisa disesuaikan dengan kebutuhan masa depan ketika Internet mulai berevolusi.

4.2. Anatomi Sebuah Network Deliveri

Network Akamai adalah sistem distribusi yang sangat besar yang berisi puluhan ribu server global yang menjalankan algorithma mutakhir untuk memudahkan deliveri aplikasi distributif dengan scalability tinggi. Kita bisa mengatakan bahwa ini berisi berbagai network deliveri, yang masing-masing disesuaikan dengan tipe konten berbeda, contohnya konten web statis, streaming media, atau aplikasi dinamis. Di level tinggi, network deliveri bisa memiliki aristektur sama, seperti yang ditunjukkan di Gambar 3, tapi teknologi dasar dan implementasi setiap komponen sistem bisa berbeda agar bisa cocok dengan tipe konten, streaming media, atau aplikasi yang di-deliverikan. Gambar 3. Komponens sistem sebuah network deliveri. Untuk memahami cara interaksi komponen ini, penting untuk memahami contoh user yang berusaha mendownload satu webpage lewat network Akamai Komponen utama dari network deliveri Akamai adalah sebagai berikut: Ketika user mengetik URL ke browser-nya, nama domain URL diterjemahkan oleh mapping system menjadi IP address untuk edge server untuk melayani kontennya (panah 1). Untuk memasukkan user ke sebuah server, sistem mapping mendasarkan jawabannya ke banyak data historis dan data current tentang kondisi network dan server global yang telah dikumpulkan dan diproses sebelumnya. Data ini digunakan untuk memilih edge server yang bertempat dekat dengan end user.

Setiap edge server adalah bagian dari edge server platform, yaitu sebuah penempatan (deployment) beberapa server global berskala besar di dalam ribuan situs di dunia. Server ini bertanggungjawab memproses permintaan prosesing dari user terdekat dan melayani konten yang diminta (panah 2).

Untuk merespon permintaan dari satu user, edge server harus meminta konten dari server origin. Contoh, konten dinamis pada sebuah webpage yang dikustomisasi untuk setiap user tidak bisa sepenuhnya di-cache (disediakan) oleh edge platform dan harus di-fetch (diambil) dari origin. Transport system digunakan untuk mendownload data yang dibutuhkan dalam cara yang reliabel dan efisien. Transport system inilah yang menggerakkan data dan konten pada Internet jarak jauh dengan reliability dan kinerja yang tinggi. Di banyak kasus, transport system juga meng-cache konten statis.

Sistem komunikasi dan kontrol digunakan untuk menyebarkan informasi status, pesan kontrol, dan update konfigurasi dalam cara yang toleran-fault dan tepat waktu. Sistem pengumpulan dan analisis data bertanggungjawab mengumpulkan dan memproses data dari berbagai source seperti server log, client log, dan informasi network dan server. Data yang terkumpul bisa digunakan untuk memonitor, memperingatkan, analitik, pelaporan dan billing.

Terakhir, management portal menjalankan dua fungsi. Pertama, ini memberikan platform manajemen konfigurasi yang membuat konsumen perusahaan bisa mengontrol cara konten dan aplikasi diberikan ke end user. Konfigurasi ini diupdate pada edge platform dari management portal lewat sistem komunikasi dan kontrol. Selain itu, management portal membantu perusahaan dalam melihat bagaimana user berinteraksi dengan aplikasi dan konten, termasuk memberikan laporan demografik audiens dan metrik traffic.

Meski semua network deliveri Akamai menggunakan sistem di atas, desain spesifik dari setiap sistem masih dipengaruhi oleh kebutuhan aplikasi. Contoh, transport system dari sebuah network deliveri aplikasi memiliki set kebutuhan berbeda dan arsitektur berbeda dibanding network deliveri konten. Kita akan melihat setiap komponen sistem ini secara detail.

4.3. Prinsip Desain Sistem

Kompleksitas network deliveri distributif global menciptakan set tantangan dalam arsitektur, operasi dan manajemen, khususnya dalam lingkungan yang heterogenus dan tidak terprediksi seperti di Internet. Contoh, manajemen network dan pengumpulan data harus bisa scalabel dan cepat di antara ribuan kluster server, yang banyak di antaranya berada di pusat data third-party yang tidak bernama, dan beberapa di antaranya bisa offline atau memiliki konektivitas buruk di waktu tertentu. Perubahan konfigurasi dan update software perlu dilakukan pada network dalam cara yang aman, cepat dan konsisten tanpa merusak layanan. Perusahaan harus mampu menjaga visibilitas dan kontrolnya atas konten di antara platform distributif.

Sebagai panduan pilihand esain, kita perlu berasumsi bahwa sejumlah failure (apakah pada mesin, rack, kluster, konektivitas, level network) bisa terjadi di setiap waktu di dalam network. Meski bukan standar dalam desain sistem, asumsi ini alami dalam konteks Internet. Ada beberapa faktor kenapa failure Internet bisa terjadi seperti yang dijelaskan sebelumnya, dan ini perlu dicermati.

Maksud di balik ini adalah bahwa kita harus mendesain network deliveri berdasarkan filosofi bahwa failure adalah normal, dan network deliveri harus beroperasi tanpa terganggu oleh itu. Beberapa upaya telah dilakukan untuk mendesain rekoveri dari semua tipe fault, termasuk fault konkuren multipel.

Filosofi ini memandu setiap level keputusan desain bahkan sampai pilihan tipe server mana yang harus dibeli. Penggunaan server komoditas kuat lebih masuk akal di dalam konteks dibanding server lebih mahal dengan redundansi hardware signifikan. Meski penting untuk mengidentifikasi hardware yang gagal (lewat ECC memory check dan disk integrity check yang membuat server bisa menghentikan layanannya secara otomatis), ada hasil buruk bila ada redundansi di dalam hardware (misal, dua power supply) dibanding di dalam software. Implikasi dari filosofi akan dijelaskan lebih jauh.

Ada beberapa prinsip penting yang mempengaruhi desain sistem platform.

Desain untuk reliability. Karena sifat bisnis, goal-nya adalah menghasilkan ketersediaan end-to-end 100 %. Ini membutuhkan upaya signifikan berdasarkan asumsi bahwa komponen sering gagal dan bisa gagal dalam cara yang tidak terprediksi. Kita harus memastikan ada redundansi penuh dalam komponen (tidak ada single point untuk failure), membuat beberapa level toleransi fault, dan menggunakan protokol seperti PAXOS dan decentralized leader election untuk mengakomodasi berbagai kemungkinan failure komponen sistem.

Desain untuk scalability. Dengan lebih dari 60 ribu mesin di dunia, semua komponen platform harus bisa scalabel. Di level dasar, scaling berarti menangani lebih banyak traffic, konten dan konsumen. Ini juga diterjemahkan sebagai penanganan volume besar data yang harus dikumpulkan dan dianalisa, atau membangun sistem komunikasi, kontrol dan mapping yang harus mendukung banyak mesin distributif. Membatasi perlunya manajemen manusia. Seringkali, kita mendesain sistem agar otomatis. Ini mendukung filosofi bahwa failure sering terjadi dan bahwa sistem harus didesain untuk tetap beroperasi meski failure. Ini tetap perlu diskala karena pengeluaran operasi manusia menjadi terlalu tinggi. Karena itu, sistem harus mampu merespon fault, menangani shift di dalam load dan kapasitas, menyetel kinerja, dan melakukan update software dan konfigurasi dengan aman dalam intervensi manusia minimal. Contoh, untuk mengolah 60 ribu mesin, maka pusat operasi network Akamai menggunakan 60 orang, yang terdistribusi untuk bekerja dalam waktu 24x7x365.

Desain untuk kinerja. Ada upaya kontinyu untuk meningkatkan kinerja path kritis sistem, bukan hanya didasarkan dari perspektif perbaikan waktu respon, tapi juga untuk metrik berbeda antar platform, seperti tingkat cache hit dan penggunaan sumberdaya network. Manfaat lain dari upaya ini adalah efisiensi energi, contohnya, karena optimisasi kernel dan software lain menghasilkan kapasitas lebih besar dan lebih banyak traffic yang dilayani dengan mesin yang lebih sedikit. Kita perlu memahami prinsip ini lebih jauh dengan mempelajari setiap network deliveri Akamai secara detail. Di Section 5 dan 6, kita akan mengulas tantangan dan solusi dalam desain konten, streaming media, dan network deliveri aplikasi, dan mengamati karakteristik transport system, yang berbeda di setiap network deliveri. Di Section 7, kita perlu menjelaskan detail komponen sistem generik yang ada di network deliveri Akamai, seperti platform edge server, sistem mapping, sistem komunikasi dan kontrol, dan sistem pengumpulan dan analisis data.

5. NETWORK DELIVERI STREAMING DAN KONTEN YANG HIGH-PERFORMANCE Di bagian ini, kita akan menfokuskan diri ke pertimbangan arsitektural network deliveri untuk konten web dan streaming media. Prinsip dasar dari peningkatan kinerja, reliability dan scalability untuk deliveri konten dan stream adalah meminimkan komunikasi long-haul yang melewati bottleneck mil-tengah di Internet. Ini adalah sebuah goal yang hanya bisa diwujudkan dengan arsitektur distributif dimana server berada di dekat end user. Kedekatan ini didefinisikan sebagai ukuran geografik dan topologi network. Situasi ideal (dari perspektif kinerja user) bisa berupa server yang bertempat di dalam ISP dan geografi setiap user, yang karena itu, meminimkan ketergantungan ke komunikasi inter-network dan jarak-jauh.

Pertanyaan kuncinya adalah seberapa distributif sebuah arsitektur. Pendekatan Akamai mencoba meraih batas Internet, dengan bukan hanya mendeploy pusat data Tier 1 dan Tier 2 yang besar, tapi juga banyak ISP end user. Daripada melakukan pendekatan deployment server farm ke dalam beberapa lusin pusat data, Akamai mendeploy kluster server dengan beragam ukuran di ribuan lokasi. Ini adalah pendekatan yang menambah kompleksitas ke desain dan manajemen sistem. Meski begitu, ini adalah pilihan arsitektur karena kita merasa bahwa inilah yang memiliki efficacy tertinggi.

Traffic akses Internet cenderung terfragmen antar network. Gabungan top 45 network hanya terhitung dari separuh traffic akses user, dan jumlah ini bisa turun. Ini berarti bahwa bila CDN tidak dideploy di ribuan network, maka persentase besar dari traffic yang dilayani perlu melakukan perjalanan lewat beberapa network sebelum mencapai end user. Deployment di ISP lokal adalah proses penting dalam region di dunia yang memiliki konektivitas buruk. Seperti yang kita lihat di Section 3, Tabel 1, karena cara kerja TCP, jarak antara server dan end user menjadi bottleneck untuk throughput video. Jika CDN hanya memiliki lusinan lokasi server, mayoritas user di dunia tidak mampu menikmati video stream kualitas tinggi padahal akses broadband-nya sudah mencapai mil terakhir. Distribusi tinggi akan meningkatkan ketersediaan platform, dan outage antar pusat data (bahkan pusat data multipel) tidak akan mempengaruhi kinerja network deliveri.

Karena alasan inilah, pendekatan Akamai adalah mendeploy server sedekat mungkin dengan end user, sehingga meminimalkan efek kongesi peering point, latensi, dan outage network ketika harus melakukan deliveri konten. Sebagai imbasnya, konsumen menikmati level reliability dan kinerja yang tidak mungkin didapat di pendekatan yang lebih sentralis.

Terakhir, meski teknologi peer-to-peer bisa memberikan opsi untuk melayani konten web statis, kurangnya fitur manajemen dan kontrol di dalam implementasi membuatnya tidak cocok sebagai solusi stand-alone untuk deliveri kualitas-perusahaan. Konsumen perusahaan Akamai melihat network Akamai sebagai ekstensi, dalam aritan bahwa mereka berharap bisa menjaga kontrol dan visibilitas konten antar network. Ini meliputi manajemen pembaruan dan ketepatan konten, kontrol terhadap cara konten berbeda ditangani, kemampuan melihat analitik dan laporan traffic dalam waktu riil, dan menjamin keamanan (termasuk integritas, ketersediaan dan konfidensialitas). Kapabilitas ini penting bagi kebutuhan bisnis perusahaan karena mereka bisa diuntungkan dengan kinerja. Kurangnya kapabilitas ini akan membatasi aplikabilitas solusi deliveri konten peer-to-peer untuk konsumen perusahaan, meski Akamai bisa memberikan opsi hibrid bagi deliveri sisi-klien.Video-Grade Scalability

Selain kecepatan dan reliability, arsitektur network distributif memberikan keuntungan kritis lainnya, yaitu end-to-end scalability. Satu goal dari CDN, termasuk Akamai, adalah memberikan scalability bagi konsumen dengan memberikannya leverage untuk network besar yang dibutuhkan. Ini mengurangi tekanan yang dirasakan provider konten dalam memprediksi secara akurat kebutuhan kapasitas, dan memudahkannya menyerap spike dalam kebutuhan website. Ini juga menciptakan penghematan dalam beban kapital dan operasional, karena beberapa situs tidak lagi membangun infrastruktur origin besar yang jarang digunakan kecuali selama kejadian populer.

Dengan video throughput yang tinggi, meski begitu, kebutuhan scalability telah meningkat. Dari hampir tidak ada di kurang dari satu dekade lalu, sekarang, video menempati lebih dari sepertiga di semua traffic Internet, dan Cisco memprediksi bahwa di tahun 2014, persentasenya akan naik sampai 90 %. Dalam umur lima tahunnya, YouTube menyatakan bahwa pihaknya menerima 2 milyar view per hari. Selain peningkatan dalam jumlah viewer, bit rate dari stream juga meningkat untuk mendukung kualitas yang lebih tinggi. Video stream di masa lalu (sering ditampilkan dalam window kecil dan dilihat dalam periode waktu yang pendek) sering hanya beberapa ratus Kbps. Sekarang, stream kualitas SDTV dan HDTV bisa beragam antara 2 sampai 40 Mbps, dan viewer bisa melihat film penuh dalam layar penuh atau dari alat set-top.

Apa maksud kombinasi peningkatan viewer, peningkatan bit rate, dan peningkatan durasi-viewing dalam hal kebutuhan kapasitas? Pidato Presiden Obama di tahun 2009 menegaskan ini, ketika Akamai bisa melayani 7 juta stream simultan dan bisa menangani level traffic lebih dari 2 Tbps. Kebutuhan terus naik, yang dipicu oleh peningkatan kecepatan broadband dan tingkat penetrasi. Di bulan April 2010, Akamai mencapai puncak rekor baru 3,45 Tbps pada network. Di tingkat throughput ini, konten cetak keseluruhan dari US Library of Congress bisa didownload dalam waktu satu menit. Sebagai perbandingan, keynote 2001 Macworld Expo yang dibuat Steve Jobs, sebuah acara streaming pemecahan rekor, hanya mencapai peak 35500 user simultan dan 5,3 Gbps bandwidth, yang pastinya masih lebih rendah dibanding Akamai.

Dalam waktu dekat (dua sampai lima tahun), wajar bila dikatakan bahwa kebutuhan throughput di beberapa single video event bisa mencapai 5 sampai 100 Tbps (ekuivalen dengan stream kualtias TV distributif ke audiens prime time yang besar). Tingkatan ini masih lebih besar dibanding online event terbesar saat ini. Fungsionalitas video event juga meningkat sampai meliputi fitur seperti fungsionalitas mirip DVR (dimana klien bisa melakukan pause atau rewind), interaktivitas, insersi advertisement, dan dukungan alat mobile.

Di skala ini, tidak cukup hanya memiliki server dan sumberdaya bandwidth. Orang harus memperhatikan throughput dari path keseluruhan dari encoder sampai server hingga end user. Bottleneck tidak hanya ada di pusat data origin. Ini bisa terjadi di peering point, atau di kapasitas backhaul network, atau di konektivitas upstream ISP. Ini juga bisa disebabkan oleh latensi network antara server dan end user. Di skala video, kapasitas egress nominal dari pusat data kurang berhubungan dengan throughput riil ke end user.

Karena terbatasnya kapasitas di berbagai titik bottleneck Internet, bahkan pusat data yang terprovisi baik dan terkoneksi baik pun hanya bisa melayani tidak lebih dari ratusan Gbps throughput ke end user. Ini berarti bahwa CDN atau network lain dengan 50 pusat data yang terprovisi baik dan terkoneksi baik masih gagal dalam meraih 100 Tbps yang dibutuhkan untuk mendukung pertumbuhan jangka pendek dari video.

Di lain pihak, platform berbasis-edge, dengan server di ribuan lokasi, bisa mencapai skala yang dibutuhkan di setiap lokasi yang mendukung puluhan Gbps output. Ini menguatkan efficacy dari arsitektur distributif dalam meraih kinerja, reliability dan scalability grade-perusahaan, khususnya di era mendatang dimana video akan mendominasi penggunaan bandwidth.

Perlu dicatat bahwa IP-layer multicast (yang awalnya dikemukakan sebagai solusi untuk menangani streaming event yang besar) cenderung tidak praktis dalam realitanya, karena tantangan perlunya dukungan di dalam backbone router tanpa memperkenalkan kerawanan keamanan, dan karena ada peningkatan set fitur seperti kontrol akses konten dan time-shifting. Ini bisa menghasilkan implementasi layanan multicast layer-aplikasi. Kinerja Streaming

Aplikasi web bisa berjalan baik jika page bisa didownload dengan cepat tanpa error. Meski begitu, kinerja streaming cenderung multidimensi dan kompleks. Penelitian Akamai tentang cara user menggunakan streaming media memunculkan definsi dan pengukuran beberapa metrik kunci. Metrik pertama adalah ketersediaan stream yang mengukur seberapa sering user memainkan stream tanpa failure. Selanjutnya, karena user ingin stream bergerak cepat, maka penting untuk meminimalkan waktu startup. Selain itu, user ingin melihat stream tanpa interupsi atau freeze. Karena itu, metrik ketiga mengukur frekuensi dan durasi interupsi selama playback. Terakhir, user ingin merasakan media pada bitrate yang tertinggi yang bisa dicapai pada konektivitas mil-terakhir, dan bisa dicapai oleh desktop atau alat yang ada. Karena itu, metrik terakhirnya adalah bandwidth efektif yang diberikan ke user. Goal desain dari network deliveri stream Akamai adalah mengoptimalkan metrik untuk memberikan pengalaman kualitas-tinggi bagi user. Selain metrik kunci di atas, sejumlah metrik lain seperti packet loss, jitter, frame loss, RTT dan delay end-to-end perlu dioptimalkan.

Akamai membangun dan mendeploy infrastruktur monitoring global yang mampu mengukur metrik kualitas stream dari sudut pandang user. Infrastruktur ini berisi pengukuran aktif yang dibuat oleh agent yang dideploy di seluruh dunia. Setiap agent mampu mensimulasikan user dengan memainkan stream dan menguji kualitasnya. 5.3 Sebuah Transport System Untuk Deliveri Konten Dan Deliveri Streaming Media

Dalam setiap network deliveri Akamai, transport system bertugas untuk memindah data dari origin server ke edge server dalam sebuah cara yang reliabel dan efisien. Teknik yang digunakan di sistem ini disesuaikan dengan kebutuhan data yang ditransport. Ada dua teknik yang akan dibicarakan di bawah ini. Yang pertama disesuaikan dengan konten yang jarang diakses dan yang kedua adalah yang sering digunakan untuk live streaming.

5.3.1. Distribusi Tiered

Dengan strategi caching efisien, arsitektur edge server Akamai memberikan kinerja yang baik dan cache hit rate yang tinggi. Meski begitu, bagi konsumen yang memiliki pustaka konten yang sangat besar, yang beberapa di antaranya bisa dingin atau jarang diakses, maka platform distribusi tiered dari Akamai bisa meningkatkan kinerja dengan mengurangi jumlah permintaan konten ke origin server. Dengan distribusi tiered, maka digunakan set parent cluster Akamai. Kluster ini adalah kluster dengan provisi baik, yang dipilih untuk menghasilkan kadar konektivitas tinggi dengan edge cluster. Ketika edge cluster tidak memiliki konten yang diminta di dalam cache, maka ini mengambil konten dari parent cluster, bukan dari origin server.

Dengan implementasi distribusi tiered yang pintar, maka kita bisa mengurangi load request pada origin server. Bahkan bagi konsumen dengan footprint konten yang sangat besar, kita bisa melihat persentase offload dalam 90 tinggi. Ini berguna dalam kasus obyek besar yang rawan flash crowd. Selain itu, distribusi tiered menawarkan penggunaan efektif koneksi persisten dengan origin, karena origin hanya perlu menangani koneksi dengan beberapa lusin parent cluster, bukan ratusan atau ribuan edge cluster. Selain itu, koneksi antara edge cluster dan parent cluster di Akamai mempermudah penggunaan transport system yang optimal kinerja. Perkembangan dari pendekatan ini, seperti adanya tier multipel, atau penggunaan set parent berbeda untuk konten berbeda bisa memberikan keuntungan tambahan untuk beberapa tipe konten.5.3.2. Network Overlay untuk Live Streaming

Karena kebutuhan unik ini, banyak live stream ditangani secara berbeda dibanding tipe konten lain di network Akamai. Ketika satu live stream ditangkap dan dienkode, maka stream dikirim ke kluster server Akamai yang disebut entrypoint. Untuk menghindari agar entrypoint tidak menjadi single point dari failure, maka kopian stream sering dikirim ke entrypoint lain, dengan mekanisme failover otomatis jika salahsatu entrypoint menjadi gagal. Dalam kluster entrypoint, distributed leader election digunakan untuk mentoleransi failure mesin.

Transport system untuk live stream bisa mentransport paket stream dari entrypoint ke subset edge server yang membutuhkan stream. Sistem ini berjalan dalam model publis-subscribe dimana setiap entrypoint menerbitkan stream yang telah ada, dan setiap edge server mensubcribe stream yang dibutuhkan. Perhatikan bahwa transport system harus mendistribusi ribuan live stream dari entrypoint ke subset edge server yang membutuhkan stream. Untuk melakukan tugas ini dalam cara yang scalabel, maka layer server yang disebut reflector harus digunakan. Reflector bertindak sebagai intermediary antara entrypoint dan edge server, dimana setiap reflector menerima satu atau beberapa stream dari entrypoint, dan bisa mengirim stream ke satu atau beberapa edge server. Perhatikan bahwa reflector mampu membuat kopian multipel dari setiap stream yang diterima, dimana setiap kopian bisa dikirim ke edge cluster yang berbeda. Fitur ini mempermudah replikasi sebuah stream ke beerapa edge cluster untuk melayani event yang sangat populer. Selain keuntungan scaling, reflector memberikan path alternate multipel antara setiap entrypoint dan edge cluster. Path alternate bisa digunakan untuk meningkatkan kualitas end-to-end lewat optimisasi jalur.

Goal dari transport system adalah mentransmisi setiap stream antar mil tengah Internet dengan failure, end-to-end packet loss dan cost yang minimal. Untuk mencapai goal ini, sistem mempertimbangkan beberapa path alternatif antara entrypoint dan edge server cluster dan memilih path yang kinerjanya terbaik untuk setiap stream. Jika tidak ada path kualitas-tinggi antara sebuah entrypoint dan sebuah edge server, maka sistem menggunakan path link-disjoint multipel yang menggunakan reflector berbeda sebagai intermediary. Kita stream dikirim di sepanjang path multipel, packet loss di berbagai satu path bisa direkoveri dari informasi yang dikirim di sepanjang path alternate. Rekoveri ini dilakukan pada edge server, dan menghasilkan versi stream lebih bersih yang diforward ke user. Transport system juga menggunakan teknik seperti prebursting, yang memberikan media player bagi user dengan quick burst untuk data sehingga stream play bisa start dengan cepat (mengurangi waktu startup).

Algorithma efisien dibutuhkan untuk membuat path overlay karena path optimal bisa berubah cepat seiring kondisi Internet. Masalah konstruksi path overlay bisa dianggap sebagai masalah optimisasi kompleks. Penelitian bisa dijalankan dengan menyelesaikan masalah ini dalam cara yang efisien dan mendekati optimal dengan menggunakan teknik algorithma advans seperti LP-rounding.6. NETWORK DELIVERI APLIKASI YANG HIGH-PERFORMANCE

Ketika website menjadi lebih dinamis, kemampuan meningkatkan kinerja aplikasi dan konten lain yang non-cacheabel menjadi sangat petning. Butuh dua pendekatan komplementer, dan dua pendekatan ini didasarkan pada koneksi pertama end user ke server Akamai terdekat. Pendekatan pertama ni adalah mempercepat komunikasi Internet long-haul dengan menggunakan Akamai Platform sebagai network overlay yang high-performance. Pendekatan kedua mendorong logika aplikasi dari origin server ke edge di Internet. Pendekatan ini bisa dijalankan bersama untuk meningkatkan kinerja aplikasi, reliability dan scalability. 6.1. Transport System Untuk Akselerasi Aplikasi

Transport system untuk network deliveri aplikasi Akamai menggunakan edge server distribusi tinggi Akamai sebagai network overlay high-performance yang membuat komunikasi Internet area-luas menjadi lebih cepat dan lebih reliabel. Komunikasi antara dua server Akamai bisa dioptimalkan untuk mengatasi ketidakefisiensian, lewat teknik seperti optimisasi path dan perluasan protokol.

Transport system semacam ini bisa diterapkan di banyak situasi, seperti akselerasi konten dan aplikasi konsumen non-cacheabel, pengambilan konten (atau proses check pembaruan) dari origin server, dan berbagai tipe komunikasi yang internal di network Akamai. Dalam skenario tipikal, end user pertama kali dipetakan ke server terdekat. Server tersebut menggunakan overlay high-performance untuk melewati Internet, dan mencapai mesin Akamai di dekat origin server perusahaan. Tipikalnya, server Akamai bisa berada dalam network sama, atau bahkan di pusat data sama seperti origin perusahaan, sehingga latensi antara keduanya bisa sangat rendah.

Overlay menggunakan beberapa teknik untuk meningkatkan kinerja dengan mengurangi beberapa jumlah round trip dan waktu round trop yang dibutuhkan untuk komunikasi tertentu. Teknik ini merepresentasikan area penting bagi penelitian kinerja.

Optimisasi path. Seperti yang dikatakan, ada beberapa batasan dalam BGP dan alasan mengapa route yang didefinisikan bisa kurang optimal. Di banyak kasus, kinerja yang lebih baik bisa dicapai dengan mengirim traffic lewat path alternate, yaitu mengarahkannya lewat server intermediate di network Akamai. Sama seperti pendekatan sebelumnya, Akamai meleverage network distributif sebagai sebuah overlay Internet. Topologi Internet dan data kinerja dari sistem mapping Akamai digunakan untuk memilih node intermediate untuk path tertentu. Kemudian, tergantung skenarionya, network Akamai bisa berebut untuk menentukan path mana yang harus digunakan, atau mengirim komunikasi ke berbagai path untuk menambah resiliensi.

Analisis terhadap data global yang diambil dari network Akamai memperlihatkan bahwa banyak path, khususnya di Asia, bisa merasakan peningkatan kinerja 30-50 % ketika menggunakan overlay. Penelitian tentang itu juga mencatat hasil sama, baik dalam setting non-komersil antar network dalam skala yang jauh lebih kecil. Perhatikan bahwa selain peningkatan kinerja, overlay juga meningkatkan reliability komunikasi dengan menawarkan path alternatif bila konektivitas menjadi turun di path langsung. Gambar 4 menunjukkan bagaimana Akamai mempertahankan konektivitas tinggi bagi konsumennya selama kasus putus kabel tahun 2008 yang menimbulkan outage Internet di Timur Tengah, Asia dan Afrika.

Gambar 4. Dengan optimisasi path real-time, Akamai membantu konsumen menghindari masalah konektivitas seperti yang digambarkan di sini, ketika kasus putus kabel Timur Tengah

Reduksi packet loss. Untuk aplikasi sensitif latensi, seperti teknologi yang menggunakan website interaktif seperti AJAX atau high-bitrate video streaming, TCP bisa menggunakan delay signifikan ketika meretransmisikan packet loss dan mengawali koneksi. Teknologi multipath yang digunakan untuk optimisasi path bisa digunakan untuk redundansi, dan ketika digabung dengan teknik koreksi error forward, ini bisa memberikan reduksi packet loss signifikan dengan overhead minimal dan tanpa peningkatan latensi, bahkan untuk path yang macet.

Optimisasi protokol transport. Gain kinerja bisa juga didapat dengan mengatasi ketidakefisiensian dalam TCP dan HTTP pada komunikasi server Akamai-to-Akamai jarak jauh. Karena tidak dibatasi oleh tingkat adopsi software klien di komunikasi internal, maka protokol layer-transport proprieter digunakan di antara server untuk menggunakan teknik seperti: Penggunaan pool koneksi persisten untuk menghapus setup koneksi dan overhead teardown.

Penggunaan window sizing TCP optimal yang didasarkan pada pengetahuan kondisi latensi network real-time. Contoh, dengan meningkatkan initial window ketika throughput-nya sudah bagus, maka komunikasi keseluruhan bisa sering dikirim dalam initial window, yang pastinya menghindari perlunya menunggu acknowledgement. Window yang lebih besar bisa meningkatkan throughput pada komunikasi jarak jauh.

Mendukung retransmisi setelah packet loss dengan meleverage informasi latensi network, bukan hanya mengandalkan protokol timeout dan retransmisi TCP standar. Contoh, timeout retransmisi bisa diset lebih pendek ketika throughput bisa menjadi baik.

Optimisasi protokol bisa dijalankan secara simbiotik dengan optimisasi path di transport system. Banyak overhead TCP disebabkan oleh fokusnya ke reliabilitas dalam kondisi network tidak pasti. Karena optimisasi path bisa memberikan path high-performance, maka protokol layer-transport bisa lebih agresif dan efisien.

Selain itu, beberapa optimisasi bisa digunakan bukan hanya untuk komunikasi server-to-server Akamai, tapi juga komunikasi langsung dengan end user berdasarkan pengetahuan platform di throughput mil terakhir dan kapabilitas kliennya. Jika end user menggunakan akses broadband, edge server Akamai bisa agresif dalam pilihan ukuran initial window-nya dan timeout retransmisi-nya.

Optimisasi aplikasi. Ada beberapa teknik layer-aplikasi yang juga digunakan untuk membantu meningkat responsivitas aplikasi Web bagi end user. Contoh, ketika memberikan deliveri HTML page ke user, edge server Akamai bisa juga mem-parse dan mem-prefetch konten embed (dari cache atau dari origin server) untuk memastikan bahwa ini sudah ada di memori ketika browser user memintanya. Karena itu, meski jika konten embed tidak bisa di-cacheabel atau long-tail (jarang di dalam cache), maka user merasakan responsivitas seperti jika situs memiliki host di edge server lokal. Edge server Akamai juga mengikuti link embed-nya dan mem-prefetch konten terkaitnya. Aturan bisnis konsumen sering mendikte kapan dan bagaimana ini harus dilakukan.Kompresi konten, bila tepat, adalah contoh lain dari optimisasi yang mengurangi jumlah roundtrip TCP dari origin server ke edge server, atau edge server ke end user (bila didukung oleh browser). Konten yang high-compressible, seperti HTML, Javascript, atau style sheet, yang ukurannya lebih dari beberapa KB, bisa diuntungkan dari kompresi. Keuntungan kinerja bisa diberikan ke end user dengan koneksi latensi lambat atau tinggi.

Logika aplikasi tambahan bisa juga diimplementasikan oleh edge server, seperti autentikasi atau melayani versi berbeda dari sebuah page yang didasarkan pada atribut klien. Perhatikan bahwa optimisasi path dan optimisasi protokol mempercepat komunikasi dalam dua arah, dan karena itu, ideal untuk upload atau download konten. Selain itu, ini tidak dibatasi hanya ke aplikasi basis Web. Akamai menggunakan teknologi sama untuk mempercepat aplikasi perusahaan basis-IP lainnya seperti interactive Web conferencing, aplikasi virtual (yaitu running dari protokol Citrix ICA atau protokol Microsoft RDP), transfer file besar untuk SFTP atau SSH, dan email, atau aplikasi perusahaan lain yang dikirim lewat SSL VPN.

Terakhir, penting untuk disadari bahwa sifat distributif tinggi dari network Akamai adalah kunci bagi efficacy network overlay karena end point dari tunnel long-haul yang optimal berada dekat dengan origin dan end user. Ini berarti bahwa komunikasi keseluruhan dari origin ke end user bisa optimal, dan brief hop di dua end ini memiliki latensi sangat rendah karena jaraknya pendek. Dalam prakteknya, ini cocok untuk membuat kinerja jarak-jauh yang baik. Untuk file besar, contohnya, download dari origin server dalam overlay high-performance bisa berkinerja seperti file yang dideliveri dari cache karena overlay mampu mendeliver file dari origin server ke edge server secepat mungkin sehingga edge server bisa mendeliveri ke end user. 6.2. Distribusi Aplikasi Ke Edge

Meski transport system dari aplikasi mampu mempercepat komunikasi di Internet area-luas, maka peningkatan kinerja, reliability, dan scalability bisa diwujudkan bila aplikasi bisa didistribusikan ke edge. Akamai memperkenalkan kapabilitas tersebut di platform-nya di satu dekade lalu dengan layanan EdgeComputing, yang berisi kapabilitas perusahaan untuk mendeploy dan mengeksekusi aplikasi Java J2EE atau komponen aplikasi pada edge server Akamai. EdgeComputing dari Akamai menggunakan cloud computing sampai sebuah level dimana sumberdaya aplikasi dialokasikan bukan hanya saat dibutuhkan, tapi juga dekat dengan end user. Kedekatan dengan end user ini adalah penting untuk kinerja, meski ini jarang diperhatikan dalam layanan cloud computing sekarang ini.

Untuk mengimplementasikan sebuah platform yang mampu memberikan layanan EdgeComputing, jelasnya dibutuhkan tindak lanjut terhadap persoalan teknis, seperti manajemen sessi (dan replikasi antar mesin), security sandboxing, manajemen fault, distributed load-balancing, dan monitoring dan manajemen sumberdaya, atau memberikan alat uji dan deployment yang tepat.

Tidak semua tipe aplikasi bisa dijalankan keseluruhan di edge. Aplikasi yang mengandalkan database transaksional besar sering membutuhkan komunikasi signifikan dengan infrastruktur origin. Meski begitu, banyak tipe aplikasi (atau beberapa porsi aplikasi) bisa diuntungkan dengan adanya EdgeComputing. Beberapa kategori penggunaannya adalah sebagai berikut:

Agregasi/transformasi konten. Ini adalah aplikasi dasar yang tidak membutuhkan database transaksional. Ini mengumpulkan konten dari layanan Web atau source lain dan mereformatnya untuk tujuan display (misal, menggunakan XSLT).

Database statis. Product catalog, store locator, site search, dan product configurator adalah contoh aplikasi yang menggunakan database yang cukup status, dan dijalankan di edge.

Pengumpulan data. Banyak aplikasi yang membutuhkan form atau input user lain bisa ditangani di edge, dengan data di-batch dan dikirim ke origin secara asinkron. Contoh, dengan aplikasi polling, edge server bisa menyimpan data secara lokal dan mengirim hasilnya ke origin server (atau ke sistem storage Akamai) dalam beberapa chunk besar, bukan dalam banyak berdasarkan permintaan individu. Validasi data dan tipe lain dari logika dasar bisa dieksekusi oleh edge server tanpa keterlibatan origin server. Pendekatan agregasi konten bisa mengurangi load origin server dalam beberapa tingkatan.

Aplikasi kompleks. Bahkan dengan aplikasi yang membutuhkan transaksi database real-time, proses running komponen layer presentasi dari aplikasi pada edge masih bisa memberikan keuntungan kinerja, karena komunikasi origin server bisa dirampingkan untuk memasukkan data mentah saja, bukan full HTML page. Contoh origin bisa menghasilkan dynamic page kecil yang dilengkapi referensi fragmen chaceabel yang besar, yang memudahkan full HTML page untuk dirakit dan dilayani di edge dengan menggunakan teknologi ESI (Edge Side Includes) Akamai. Dalam prakteknya, kita menemukan bahwa konsumen EdgeComputing bukan hanya diuntungkan dari level tinggi dalam kinerja, scalability dan toleransi fault dari model, tapi juga diuntungkan dari kemampuan mengembangkan dan mendeploy aplikasi yang lebih cepat, dengan sedikit kekhawatiran soal perencanaan kapasitas, pengadaan infrastruktur, dan aristektur scalability.

7. KOMPONEN PLATFORM

Ada cara berbeda ketika Akamai Platform bisa memudahkan deployment dan deliveri aplikasi web yang scalabel. Kita perlu mempelajari komponen sistem yang telah dijelaskan sebelumnya. Kita sebelumnya telah memeriksa salahsatu komponen, yaitu transport system, antar tipe network deliveri. Kita sekarang akan melihat komponen sistem lain. Gambar 5 memberikan ulasan arsitektur komponen besar meski singkat.

Gambar 5. Komponen sistem dari Akamai Platform

7.1. Edge Server Platform Edge server Akamai bertugas memproses permintaan end user dan melayani konten yang diminta, atau bertindak sebagai intermediary dalam network overlay. Platform ini menawarkan set fungsionalitas dan fitur penanganan konten yang dibuat berdasarkan satu dekade pengalaman dalam kerjasama dan mendukung banyak website dan aplikasi mutakhir di network. Kontrol ini bukan hanya menghasilkan perilaku aplikasi tepat seperti yang ingin dirasakan end user, tapi juga mengoptimalkan kinerja aplikasi dalam skenario berbeda.

Fitur penting dari edge server platform adalah configurability lewat metadata configuration, yang memudahkan perusahaan memiliki kontrol fine-grained dalam menerapkan beragam kapabilitas platform dalam penanganan konten.

Sebagai contoh, single virtual host (dengan single DNS hostname) sering berisi beragam konten dengan karakteristik berbeda. Beberapa path di host bisa dikonfigurasi sebagai konten non-cacheabel dinamis yang menggunakan tier-aplikasi konsumen sebagai origin. Di saat sama, path lain bisa cocok dengan obyek statis yang dilayani dari sistem storage Akamai. Kebijakan autentikasi dan kebijakan keamanan lain bisa dikonfigurasi di path terpilih, sedangkan path lain bisa dikonfigurasi untuk memodifikasi header request dan response HTTP.

Berikut ini adalah kategori kapabilitas edge server untuk memberikan ide tentang tipe fungsionalitas yang dikontrol metadata:

Lokasi origin server dan path konten (yang berbeda dari path URL yang diberikan ke end user). Kontrol cache, termasuk apakah dan berapa lama untuk meng-cache sebuah obyek atau bagian dari sebuah obyek. Beberapa kebijakan konsistensi dan invalidasi cache tersedia untuk kelas konten berbeda.

Indeksing cache. Konsumen memiliki kemampuan menjelaskan apa yang masuk dalam indeks cache untuk sebuah obyek, contohnya apakah perlu memasukkan deret query, mengabaikan bagian path URL, atau mengabaikan kasus, untuk memaksimalkan cacheability konten sekaligus menjaga ketepatannya.

Kontrol akses. Sejumlah mekanisme autentikasi dan otorisasi tersedia untuk mengontrol akses ke konten atau meragamkan konten. Ini berisi mekanisme distributif (seperti memvalidasi cookies atau sertifikat klien di edge) atau mekanisme sentralis yang meng-query sebuah server autentikasi origin. Respon ke origin server failure. Dalam kejadian origin server failure, konsumen memastikan apakah bisa mendeliveri konten dari cache, menggunakan backup origin server, atau melayani konten statis dari sistem storage Akamai. Panjang timeout dan parameter backoff juga bisa dikonfigurasi.

Perubahan header. Edge server bisa menambah, mendelete atau merewrite header request dan response HTTP, seperti header yang berisi cookies. Ini bisa digunakan untuk memberikan informasi ke origin server dan klien kustom, berinteraksi dengan cookies, mengelola cache downstream, dan menindaklanjuti beragam perilaku browser.

EdgeComputing. Akamai Platform menawarkan fungsionalitas yang memudahkan perusahaan menjalankan logika aplikasi pada edge server. Dengan konfigurasi metadata, beberapa URL dikonfigurasikan untuk menyusun page secara dinamis dari fragmen dengan menggunakan Akamai ESI (Edge Side Includes), merubah respon dengan menggunakan XSLT, atau memberikan sebuah request ke server aplikasi Java di edge.

Optimisasi kinerja. Beberapa fitur dibuat untuk memaksimalkan kinerja dalam kondisi bebreda dan untuk kelas aplikasi atau konten bebreda. Ini berisi fitur besar seperti distribusi tiered dan optimisasi path overlay, penyetelan parameter TCP pada basis per-koneksi, dan proses prefectching dan refreshing konten secara asinkron. Banyak opsi konfigurasi lain digunakan untuk menyetel kinerja untuk aplikasi dan workload berbeda.

Sistem metadata memudahkan fitur dikonfigurasi secara terpisah berdasarkan pasangan atribut request dan response. Meski pasangan paling sederhana ditemukan di komponen path URL, ekstensi file, dan metode request, maka pasangan metadata yang lebih advans bisa merubah perilaku berdasarkan atribut termasuk lokasi geografik end user, kecepatan koneksi, header request dan response HTTP, nilai cookies dan banyak lainnya.

Meski platform mendukung beberapa fitur metadata yang harus dijelaskan lewat header response origin HTTP spesifik-Akamai, sarana primer dari spesifikasi metadata adalah lewat file konfigurasi XML yang didistribusikan ke seluruh network Akamai dengan menggunakan sistem komunikasi dan kontrol. Mekanisme out-of-band ini memberikan keamanan lebih besar dan kemudahan integrasi sekaligus memberikan derajat kontrol yang besar. Konfigurasi metadata bisa diset berads website keseluruhan, porsi situs, kategori spesifik konten, atau file individu.

Konfigurasi metadata mudah diupdate dan bisa disesuaikan dengan network dalam cara aman dan cepat. Lingkungan staging end-to-end diciptakan untuk memudahkan pengujian perubahan data sebelum mendorongnya ke produksi, dan perubahan ke lingkungan produksi bisa dilakukan secara inkremental lewat testing dan monitoring otomatis antar phase.

Arsitektur mudah diekstensi, sehingga mudah mengevolusi fungsionalitas platform agar memenuhi kebutuhan konsumen yang senantiasa berubah. Best practice dari metadata bisa diekspos lewat template agar bisa mengkonfigurasi perilaku yang diinginkan tanpa khawatir dengan detail.

Metadata dari edge server juga mendukung penggunaan variabel untuk memperluas fleksibilitas. Nilai variabel bisa diambil dari atribut request dan response, lalu dirubah dan digunakan kemudian. Sebagai satu contoh, variabel bisa diekstrak dari deret query untuk digunakan sebagai komponen cache key dari page, atau sebagai bagian dari dynamic page assembly dengan ESI.

Seperti semua komponen sistem Akamai Platform, selalu ada toleransi fault yang dmasukkan ke platform edge server agar bisa mencapai goal-nya yaitu menangani request dari end user secara berkelanjutan tanpa ada failure, apakah di mesin, pusat data, network, atau level inter-network. Kita akan mengulas lebih dalam, karena sistem mapping memainkan peran kunci dalam toleransi fault di platform edge server.

7.2. Sistem Mapping Sistem mapping Akamai adalah direktor traffic global dari platform. Sistem menggunakan data historis dan real-time tentang kesehatan dari network Akamai dan Internet agar bisa menciptakan peta yang digunakan untuk mengarahkan traffic pada network Akamai dalam cara reliabel, efisien dan high-performance.

Ada dua bagian penting dalam sistem ini, yaitu scoring dan real-time mapping. Sistem scoring menciptakan peta topologi yang menangkap kondisi konektivitas antar Internet. Lebih tepatnya, map akan membagi Internet menjadi beberapa kelas ekuivalensi adress IP dan merepresentasikan cara (dan seberapa baik) koneksinya satu sama lain. Ini membutuhkan pengumpulan dan prosesing sejumlah data historis dan real-time- termasuk ping, traceroute, data BGP, log dan data IP, yang dikumpulkan secara kumulatif selama beberapa tahun di-refresh dalam basis kontinyu. Latensi network, loss dan konektivitas dimonitor pada frekuensi tinggi, sehingga memudahkan respon cepat ke fault dan perubahan kinerja Internet.

Bagian real-time mapping dari sistem menciptakan map aktual yang digunakan Akamai Platform untuk mengarahkan end user (yang diidentifikasi lewat IP address dari end user dan nama server-nya) ke edge server Akamai untuk merespon request-nya. Bagian sistem ini juga memilih intermediate untuk distribusi tiered dan network overlay. Proses ini dijalankan dalam dua langkah:

Map to cluster. Pertama, top-level map memilih edge server cluster yang disukai untuk setiap kelas ekuivalensi end user yang memasukkan setiap fragmen kecil Internet ke salahsatu dari ribuan lokasi edge server Akamai. Mapping semacam ini didasarkan pada sejumlah faktor, termasuk informasi dari sistem scoring (termasuk informasi topologi seperti kedekatan geografik dan network/AS antara kluster dan end user), loss dan latensi real-time, kapasitas dan informasi kebutuhan yang real-time, kelas traffic (contohnya dalam memastikan bahwa kebutuhan traffic yang sensitif-latensi dan footprint-besar terpenuhi), dan informasi real-time tentang kesehatan kluster. Map tersebut diupdate setiap menit untuk menangkap kondisi sekarang. Jika masalah konektivitas antara kluster dan set end user diamati, contohnya, maka end user diarahkan ke kluster yang akan memberikan kinerja lebih baik. Sistem kontrol feedback akan melacak load, kapasitas dan kebutuhan di sepanjang dimensi multipel, dan memastikan bahwa kebutuhan yang dikirim ke kluster tertentu tidak akan memberikan load di kluster karena load bisa melebihi target kapasitas. Map to server. Ketika dimasukkan ke kluster spesifik, map level-rendah dalam kluster akan mengarahkan user ke mesin spesifik, yang didasarkan pada faktor termasuk kecenderungan mesin memiliki potongan konten yang diminta di dalam cache. Lokalitas perlu dilestarikan dalam kluster (proses mapping request untuk potongan konten sama di mesin sama), karena ini menig kinerja dan membuat penggunaan ruang cache menjadi efisien. Tantangannya adalah melakukan itu dalam lingkungan dinamis, yang sering rawan perbu load dan failure mesin. Penelitian pionir Akamai di area ini mulai mendapat dukungan konsisten di satu dekade lalu, dan berevolusi signifikan sampai point sekarang.

Ketika ada fault hardware dan network (seperti gagal hard drive di sebuah server), edge server yang gagal akan tersuspensi dan akan mengakhiri request yang in-progress tapi tidak akan dikirim ke end user sampai fault ini diselesaikan.

Sistem mapping itu sendiri adalah platform distributif yang toleran fault, yang mampu survive di tengah failure pusat data multipel tanpa ada interupsi. Porsi scoring dan porsi map-to-cluster dari sistem berjalan dalam beberapa situs independen multipel dan dalam situasi leader-elect yang didasarkan pada status kesehatan setiap situs. Porsi map-to-server dari sistem dijalankan di mesin multipel dalam setiap kluster target. Semua porsi sistem, termasuk monitoring agent dan DNS server, berkomunikasi lewat transport overlay multi-path yang mampu mentoleransi fault network.

Karena efficacy sistem mapping penting untuk kinerja keseluruhan sistem Akamai, maka ada penelitian dan pengembangan kontinyu untuk memajukan dan memperbaikinya. Ini berisi penelitian berkelanjutan untuk meningkatkan kualitas scoring input data, meningkatkan lokalitas konten footprint-besar, menindaklanjuti shift di arsitektur Internet, membuat metode baru untuk peningkatan isolasi-fault, dan mengoptimalkan kinerja komponen sistem untuk menghasilkan waktu respon yang lebih cepat.

Satu contoh dari perbaikan adalah proses yang dilakukan untuk meningkatkan kemampuan server untuk menyesuaikan input kapasitasnya ke sistem mapping berdasarkan self-monitoring terhadap penggunaan sumberdaya. Ini memudahkan hardware heterogenus, yang menjalankan tipe aplikasi berbeda, untuk digunakan secara lebih efisien di network.

Volume sheer (dan frekuensi) dari data yang diproses dalam sistem mapping juga memberikan sebuah tantangan. Selama redesain sistem di awal perkembangannya, analisis desain awal memperlihatkan bahwa jumlah data yang harus dikumpulkan dan dikomunikasikan bisa melebihi jumlah traffic end user yang dilayani. Banyak penelitian dilakukan sejak itu, dan terus dilakukan, untuk mengurangi beban komunikasi data, sekaligus menjaga semua informasi tetap penting bagi mapping kualitas-tinggi.7.3. Sistem Komunikasi Dan Kontrol

Akamai Platform menggunakan beberapa model berbeda untuk komunikasi internal, yang masing-masing memiliki tantangan sendiri dalam konteks platform Internet yang sangat distributif. Di sistem ini, ada tantangan skala (berkomunikasi dengan, sekaligus mengontrol, network yang berisi 60 ribu mesin) dan reliability (khususnya dalam komunikasi, karena kluster Akamai memiliki konektivitas dan kinerja tinggi ke end user mereka, tapi memiliki konektivitas buruk ke end user lain di Internet).

Sistem bisa dijabarkan sebagai berikut:

Distribusi informasi status dan kontrol yang real-time. Pesan kecil mungkin perlu dipropagasi lewat network di dalam real-time, seperti input dan output sistem mapping (load, kesehatan, konektivitas dan informasi kontrol). Kita menggunakan model publish/subscribe dengan arsitektur fan-out tiered multi-path. Publisher mengumumkan set node intermediate distributif global. Subscriber bisa subscribe ke satu atau beberapa intermediate. Arsitektur multi-path ini meminimkan latensi sekaligus memudahkan scaling dan toleransi ke fault network. Layanan RPC dan WEB Point-to-Point. Di banyak kasus dimana sistem membutuhkan komunikasi point-to-point latensi yang sangat reliabel dan rendah, kita bisa menggunakan overlay high-performance Akamai untuk meningkatkan reliability dan kinerja, bahkan saat menghadapi masalah network.

Update konfigurasi dinamis. Banyak komponen sistem Akamai perlu menerima update konfigurasi dengan latensi rendah, kadang sering setiap menit. Satu contoh dari ini adalah file konfigurasi metadata konsumen yang digunakan untuk mengkonfigurasi platform edge server. Goal desain kunci adalah menghasilkan konsistensi versi antar network (mempertimbangkan penanganan isu konektivitas dan penanganan mesin yang bisa gagal dan restart di setiap waktu), meningkatkan reliability dan scalability sistem, dan menciptakan mekanisme untuk memastikan bahwa perubahan yang propagatif tidak mempengaruhi network. Pendekatan yang diambil adalah mempublikasi data ke set server storage highly-available yang menggunakan replikasi basis-quorum untuk menerima sebuah update. Untuk meraih skala dan latensi rendah dalam distribusi, update dipropagasi di network dengan menggunakan layanan deliveri konten Akamai sendiri. Terakhir, rollout konfigurasi bisa dijalankan secara otomatis, dengan check kesehatan dilakukan di setiap step untuk melindungi network.

Infrastruktur Manajemen Kunci (Key). Selalu ada keinginan untuk menjaga agar kunci kriptografik yang sensitif, seperti kunci yang digunakan untuk SSL, tidak menyentuh disk mesin. Infrastruktur manajemen kunci Akamai melakukan audit keamanan ekstensif terhadpa mesin sebelum mendistribusikan kunci ke software di mesin. Server distribusi kunci multipel (yang menggunakan PAXOS untuk mengkoordinasi replikasi database) mempermudah mesin melakukan audit dan kunci bahkan saat ada masalah network. Mesin yang tidak menerima kunci akan secara otomatis di-suspend, dan tidak akan masuk dalam map di sistem mapping. Manajemen Konfigurasi Software dan Mesin. Sistem Akamai untuk distribusi konfigurasi software dan informasi konfigurasi sistem di seluruh network didesain untuk menangani sifat heterogen dan distributif dari platform. Sebuah kebutuhan kunci adalah bahwa mesin harus memiliki konfigurasi software dan sistem yang tepat, bahkan saat ada roollback dan missing update yang sering disebabkan oleh masalah konektivitas. Sebagai bagian dari update konfigurasi software dan sistem dari setiap mesin, kondisi mesin harus dipastikan sesuai harapan, dan kemudian dibandingkan dengan kondisi jalannya (saat running). Sistem bisa mengambil aksi yang dibutuhkan untuk membuat kondisi running cocok dengan kondisi yang diharapkan, seperti mengupdate komponen software. Karena prinsip design-for-reliability, update software bisa dibuat tanpa dampak eksternal yang visibel. Contoh, sebuah mesin yang membutuhkan update akan di-suspend sehingga request baru bisa diarahkan ke server lain, dan mesin akan me-restart layanan setelah request in-progress selesai. Sistem Pengumpulan dan Analisis Data

Akamai Platform juga menggunakan beberapa mekanisme pengumpulan dan analisis data, yang semuanya memiliki tantangan desain sama, yaitu dalam scalability dan toleransi fault. Mekanismenya meliputi:

Kumpulan log. Kebutuhan bisnis dari konsumen sering mendikte kebutuhan file log mentah, dan Akamai juga menggunakan file log untuk memberikan billing ke konsumen. Untuk memberikan layanan rutin pada 10 juta request HTTP per detik, maka dibutuhkan prosesing 100 TB log per hari. Log kompresi diagregat menjadi set kluster yang memiliki pipeline prosesing untuk memvalidasi dan memfilter log. Atribut log terpilih diberikan ke sejumlah sistem seperti prosesing untuk tujuan analitik, proses loading ke dalam database untuk pelaporan historis dan billing, dan/atau juga deliveri ke konsumen.

Pengumpulan dan monitoring data real-time. Sistem Query dari Akamai adalah database relasional real-time distributif yang memudahkan monitoring real-time pada informasi status di network distributif. Data status diberikan oleh setiap komponen software di dalam Akamai Platform dalam bentuk baris tabel, dan baris ini diagregasikan menjadi ribuan tabel di dalam sistem Query. Di sini, Query mendukung interface SQL standar untuk memudahkan proses query ad-hoc arbitrary atas data, bukan mendefinisikan pertanyaan yang ada. Akamai menggunakan Query untuk tujuan monitoring dan alerting. Contoh, invarian seluruh-network bisa diekspresikan sebagai statement SQL (misal, tidak ada selain mesin N yang bisa menunjukkan perilaku sistem dalam region geografik tertentu di saat sama ketika ada perilaku sistem lain) dengan baris return yang menghasilkan sikap alerting untuk investigasi lebih jauh di dalam pusat operasi. Statement SQL lain (misal, persentil ke-95 dari penggunaan sumberdaya untuk proses tertentu, yang dipecah menurut tipe versi hardware dan software) bisa digunakan untuk mengekstrak aspek kompleks dari sistem untuk proses trending dan analisis. Analitik dan Pelaporan. Sistem analitik dan pelaporan Akamai memudahkan konsumen untuk melihat informasi tentang traffic dan kinerja dari situs. Sistem ini mengkonsumsi output dari koleksi log, Query dan sistem lain, yang memprosesnya menjadi sebuah format yang memudahkan pelaporan multi-dimensi. Generasi terbaru dari sistem menggunakan framework MapReduce modifikasi untuk mengekstrak beragam atribut dan memberikan data ke dalam sistem database berorientasi-kolom yang toleran-fault. Konsumen menggunakan interface pelaporan untuk membuat dan menerbitkan query multi-dimensi terhadap database untuk mendapat wawasan tentang traffic situs, demografik user, dan kinerja network.7.5. Sistem Dan Layanan Tambahan

Akamai Platform berisi beberapa infrastruktur yang highly scalabel dan high availability, tapi ini jarang didiskusikan detail meski ini memainkan peran penting dalam layanan yang ditawarkan ke basis konsumen Akamai.

7.5.1. DNS

DNS adalah bagian penting dari aplikasi Internet, yang digunakan oleh end user untuk memetakan nama host berdasarkan IP address. DNS juga menjadi salahsatu mekanisme primer untuk interface dengan sistem mapping Akamai, yang mengkomunikasikan keputusan tentang end user mana yang dimasukkan ke kluster dan mesin Akamai. Karena itu, Akamai mendeploy sistem distribusi global server DNS otoritatif yang highly-available baik untuk memberikan jawaban dinamis berdasarkan keputusan mapping kai, atau memberikan jawaban otoritatif statis ke zona konsumen. Akamai mengambil tindakan untuk memastikan adanya toleransi fault kuat di sistem DNS dengan menggunakan beberapa mekanisme untuk membantu sistem dalam menskala di tingkat request yang tinggi dan memberikan kinerja ekselen di seluruh dunia.

Sistem dengan high-availability juga diberikan ke konsumen sebagai layanan DNS otoritatif. Dengan adanya layanan ini, konten zona DNS bisa dipindah dari master server DNS konsumen, yang tidak lagi perlu dipapar ke end user. Konten didistribusikan ke infrastruktur DNS global Akamai, yang kemudian bisa menangani query DNS konsumen.

7.5.2. Agent Monitoring

Untuk memonitor kinerja network dan website, Akamai memiliki sistem distributif global multipel yang berisi agent monitoring. Berbagai agent ini melakukan ping, traceroute, atau request lewat beberapa protokol Internet seperti HTTP. Tes dikonfigurasi berdasarkan sistem mapping (misal, memetakan Internet dan memonitor loss dan latensi dalam real-time), dan berdasarkan konsumen (misal mengukur ketersediaan dan kinerja website, dengan hasilnya di-fed ke dalam sistem analitik).

7.5.3. Global Traffic ManagerKetika konsumen ingin agar origin server dideploy dalam lokasi multipel untuk mendapatkan toleransi fault dan keseimbangan load, Akamai memberikan sebuah versi teknologi mapping ke konsumen sebagai bagian layanannya. Layanan Global Traffic Manager (GTM) berisi agent di lokasi origin konsumen yang memonitor kinerja Internet dan mengumpulkan informasi load untuk di-fed ke dalam sistem mapping. Jawaban didistribusikan ke end user (atau server Akamai yang menggunakan origin kustom) lewat DNS, yang didasarkan pada faktor seperti load, latensi network, kedekatan geografik dan network, dan aturan bisnis konsumen.

7.5.4. Storage

Akamai Platform berisi sistem storage high-availability. Sistem ini bisa digunakan sebagai origin server untuk banyak tipe konten, seperti obyek statis, pustaka media besar, dan backup site. Aplikasi EdgeComputing juga menggunakan sistem storage sebagai gudang beberapa tipe data. Arsitektur storage ini dibuat sedemikian rupa sehingga tidak ada single point failure. Server dideploy dalam kluster dalam beberapa lokasi geografik, dan disediakan replikasi in-cluster dan multi-cluster secara otomatis. Mekanisme multipel diberikan untuk upload sistem, yang beragam dari rsync-over-ssh sampai HTTPS POST.7.5.5. Client Side Delivery

Sebagai pendekatan tambahan untuk peningkatan kinerja end user dan mengurangi biaya konsumen, Akamai memberikan sistem client-side delivery yang bisa digunakan oleh konsumen. Ini berisi software client-side (yang harus diinstall pada mesin end user) yang bisa berkomunikasi dengan sistem Akamai distributif. Aplikasi client-side web (di-run dengan browser) bisa berkomunikasi secara lokal dengan software klien untuk meminta konten, seperti untuk distribusi paket software yang besar. Sistem client-side delivery bertindak mirip seperti sistem peer-to-peer, tapi memberikan fitur tambahan yang dibutuhkan konsumen perusahaan. Banyak konsumen perusahaan lebih peduli dengan jaminan kinerja dan ketersediaan konten, dan mereka tidak ingin kehilangan kontrol atau visibilitas terhadap deliveri konten. Sistem client-side delivery bisa mewujudkan goal berikut, yaitu meleverage Akamai Platform sebagai tempat konten bibit, dan mampu melakukan fallback permintaan konten dari server Akamai terdekat ketika peer tidak memberikan kinerja yang cukup. Dengan mengintegrasi dengan Akamai edge server platform, maka software klien mampu memberikan konsumen dengan kontrol dan visibilitas terhadap distribusi konten, atau menjamin integritas deliveri konten. Ketika software klien berkomunikasi dengan control-plane dari Akamai, keputusan tentang peer mana yang bisa diajak komunikasi bisa dilakukan berdasarkan pemahaman real-time topologi Internet dari sistem mapping Akamai. 7.5.6. Management Portal

Management portal basis-web dari Akamai memberikan konsmen dengan platform konfigurasi dan manajemen yang high-availability sehingga membuat mereka bisa menjaga kontrol dan visibilitas terhadap konten, aplikasi dan traffic. Konsumen karena itu bisa melihat informasi seperti laporan traffic, kinerja network dan packet loss, demografik end user, tingkat penyelesaian download, media playtime/buffer time, dan laporan yang didefinisikan kustom. Kapabilitas portal lain berisi self-provisioning, konfigurasi (seperti mengelola konfigurasi metadata situs atau menginvalidasi konten), diagnostik, manajemen, alert, dan pelaporan. Sistem portal bisa diakselerasi dengan menggunakan network deliveri aplikasi Akamai, yang meningkatkan kinerja dan reliability untuk konsumen di seluruh dunia.8. CONTOH: FAILOVER MULTI-LEVEL

Kita menggunakan pendekatan desain platform dalam cara yang sama seperti komputing yang berorientasi-rekoveri. Ini didasarkan pada asumsi bahwa failure adalah bagian dari operasi yang tidak bisa dihindari dan bahwa sistem harus mampu beroperasi meski ada failure.

Kita perlu melihat lebih dekat aplikasi pendekatan ini dengan memeriksa bagaimana layanan deliveri konten Akamai bisa menjaga ketersediaan (availability) dalam skenario failure komponen multipel, yang didasarkan pada versi tua dari sistem. Untuk memahami bagaimana ini bisa bekerja, kita harus melihat aliran dasar request HTTP ke network Akamai.

Awalnya, sebuah lookup DNS dibuat untuk menyelesaikan hostname Akamai. Resolusi DNS ini membutuhkan beberapa langkah:

Request pertama masuk ke server TLD generik, yang akan mengembalikan Akamai Top Level Name Servers (TLNS) sebagai otoritas, yang umumnya dengan DNS TTL panjang. Akamai TLNS terdistribusi secara global, dengan menggunakan campuran IP Anycast dan kluster besar. Query selanjutnya, ke TLNS Akamai, mengembalikan delegasi dengan TTL DNS lebih pendek ke sejumlah Akamai Low Level Name Servers (LLNS). Akamai LLNS bertempat di network dekat yang dekat dengan nama server yang diresolve.

Query akhir, ke Akamai LLNS, mengembalikan edge server IP address yang didasarkan pada penetapan kluster and map level rendah. Jawaban memiliki TTL yang sangat pendek sehingga perubahan di penetapan mapping (saat merespon failure atau shift dalam kebutuhan) bisa didistribusikan cepat ke end user.

Browser end user membuat request HTTP ke edge server IP address untuk menerima konten. Jika konten tidak ada di cache, edge server mengambilnya dari origin server dan mendeliverinya ke end user.

Perhatikan tipe failure berikut:

Failure mesin. Dalam sebuah edge cluster, Akamai mengimplementasikan teknik high-availability yang prinsipnya sama seperti di TCPHA. Ini menciptakan respon tak terputus ke failure mesin, khususnya ketika mesin lain mulai mengawali respon ke IP address dari mesin yang failure. Selain itu, map level rendah diupdate setiap beberapa detik, yang mengarahkan request baru agar mengakomodasi failure.

Failure kluster. Ketika kluster menjadi failure atau merasakan konektivitas yang tidak reliabel, maka penetapan kluster dari mapping diupdate dengan cepat menjadi kluster yang tidak lagi handout atau yang tidak rawan failure atau merasakan masalah konektivitas. Failure konektivitas. Jika konektivitas antara origin server dan edge server menurun, platform mendeteksi ini dengan cepat dan menggunakan teknologi optimisasi path untuk menemukan path alternate yang baik lewat node intermediate di Akamai Platform.

Perhatikan bahwa meski jika semua fault di atas terjadi bersamaan, platform masih bisa merekoverinya dengan cepat.

Selain goal langsung seperti ketersediaan platform yang kuat, ada juga byproduct dari filosofi desain yang berorientasi rekoveri. Byproduct pertama adalah reduksi staff operasi yang dibutuhkan untuk menjalankan network. Karena network didesain dengan asumsi bahwa komponen bisa failure di setiap waktu, maka staff tidak perlu khawatir tentang failure atau tidak perlu tergesa-gesa menindaklanjutinya. Staff bisa agresif dalam proaktif untuk mensuspend komponen yang kurang begitu penting karena melakukan itu pun tidak akan mempengaruhi kinerja sistem keseluruhan. Meski staff operasi tersebar di berbagai situs, staff manusia bukan di dalam path kritis di operasi network.

Keuntungan kedua adalah kemampuan rollout update software dalam cara cepat dan non-disruptif. Karena failure sejumlah mesin atau kluster tidak mempengaruhi sistem keseluruhan, maka rollout software bsia dilakukan dengan cepat dan sering tanpa merusak layanan ke konsumen Akamai.

9. KEUNTUNGAN DAN HASIL BAGI KONSUMEN Konsumen Akamai bisa dengan mudah menggunakan berbagai network deliveri Akamai dalam satu website, yang menyesuaikan metode deliveri untuk memenuhi kebutuhan aplikasi. Kita akan memberikan sampel kasus penggunaan yang menunjukkan cara berbeda dari konsumen dalam mengimplementasikan aplikasi di Akamai Platform dan keuntungan yang diterima sebagai hasilnya. 9.1. Contoh Untuk Deliveri Konten Dan Streaming

Keuntungan yang didapat konsumen dari deliveri konten dan streaming bukan hanya berupa pendapatan dan perluasan brand dari peningkatan kinerja dan reliability, tapi juga dari penghematan biaya infrastruktur, proteksi dari serangan DDoS, dan kemampuan menangani flashcrowd yang besar. New York Post: Peningkatan kinerja 20 kali lipat. New York Post datang ke Akamai setelah menerbitkan berita eksklusif yang memunculkan traffic yang membebani infrastruktur. Akamai mampu menyelesaikan provisi dan memadukan situs dalam bilangan jam, dan membuat New York Post bisa menangani flash crowd-nya, sekaligus membuat waktu download home page-nya 20 kali lebih cepat.

Pemerintah US: Proteksi terhadap DDoS. Di bulan Juli 2009, pemerintah US merasakan serangan DDoS terbesar di dalam sejarah, dengan situs top-target menerima traffic besr dalam satu hari selama 8 tahun. Meski skala serangan ini tidak terduga, semua situs pemerintah US yang dideliveri lewat Akamai termasuk situs untuk White House dan 13 dari 15 lembaga level Kabinet Federal tetap online, dengan Akamai menyerap lebih dari 200 Gbps serangan traffic yang ditargetkan ke situs pemerintah. Di saat sama, Akamai juga tetap memberikan layanan traffic ke user legitimate dan mempertahankan level availability-nya yang tinggi ke konsumen, sekaligus mendeliveri traffic sebesar 1 Tbps untuk basis konsumennya. MySpace: Peningkatan kecepatan 6 kali lipat, offload 98 %. Perusahaan networking populer meminta Akamai untuk membantu menangani laju pertumbuhan virtual yang tidak terduga. Meski ada footprint besar dalam konten personal dan basis-user, MySpace mampu mengoffload 98 % traffic-nya ke Akamai (dengan menggunakan distribusi tiered). Cara ini berhasil meningkatkan kinerja 2,6 kali ke end user di US dan peningkatan 6 kali ke user internasional. Sophos: Mengeliminasi infrastruktur yang mahal. Perusahaan keamanan global Sophos mendeliveri software antivirus dan mengupdatenya untuk 100 juta user di 150 negara. Perusahaan mulai menggunakan Akamai ketika server basis-London menjadi terbebani oleh release baru. Sophos mendeliveri 20 kali traffic, dan mencapai 99,9 % tingkat sukses download tanpa infrastruktur tambahan. Diestimasikan bahwa ini menghemat ratusan ribu dolar per tahun dan menghindari deployment 25 pusat data yang jelasnya mahal. MTV Hope for Haiti Concert: melayani 5,8 juta stream , pendapatan 61 juta dolar. MTV Network datang ke Akamai dengan rencana untuk membuat konser amal untuk korban gempa di Haiti selama satu minggu. Mereka ingin menyiarkannya secara online atau di televisi, dan goalnya adalah mendeliveri pengalaman streaming terbaik sekaligus menangani audiens dari berbagai ukuran. Akamai membantu membuat konser menjad sukses, dan mendeliveri 100 ribu stream konkuren selama acara, dan mendeliveri lebih dari 5,8 juta stream selama sepekan.

9.2. Contoh Deliveri Aplikasi

Layanan deliveri aplikasi Akamai menggabungkan optimisasi kinerja Akamai, network overlay, EdgeComputing, dan kapabilitas deliveri konten untuk mengakselerasi range keseluruhan dari aplikasi Web dan basis-IP. Perhatikan sampel kasus penggunaan berikut: Aplikasi Perusahaan. Beberapa provider bisnis dan provider SaaS menggunakan Akamai untuk membantu mereka mengatasi tantangan kinerja dan reliability dalam aplikasi perusahaan misi-penting. Mereka kemudian melaporkan peningkatan kinerja global dalam range 100 % sampai 700 %. Laporan dari Tolly Enterprise, contohnya, menunjukkan bahwa pihaknya menguji waktu respon dari user live saat menyelesaikan tugas dengan menggunakan aplikasi yang dijalankan di solusi virtual desktop Citrix XenDesktop. Tolly menemukan bahwa Akamai berhasil meningkatkan kinerja dari 170 % ke 700 % di beberapa lokasi di Asia. Bagi beberapa perusahaan, peningkatan ini bisa berarti dolar yang didapat dari peningkatan pendapatan dan efisiensi operasional. Laporan penelitian IDC menyebut bahwa organisasi yang menggunakan layanan akselerasi aplikasi Akamai untuk aplikasi perusahaan berhasil mendapat keuntungan tahunan rata-rata 7 jtua dolar di dalam investasi rata-rata 174 ribu dolar. Amazon EC2: Meningkatkan kinerja cloud computing. Ketika perusahaan seperti EC2 dan Google App Engine mencari layanan yang bisa mengurangi biaya kapital dan operasional, infrastruktur cloud masih kuarng bisa memberikan kinerja dan reliability karena kontennya masih harus berjalan di Internet mil tengah untuk mencapai end user. Aplikasi dan layanan yang mereka gunakan (seperti storage) bisa juga bertempat di pusat data berbeda. Akamai Platform bekerja dengan infrastruktur origin yang cloud-hosted, dan malah sama seperti kliennya, tapi berhasil meningkatkan pengalaman end user. Beberapa hasil dari aplikasi EC2-hosted adalah: Perusahaan kolaborasi proyek (SaaS): peningkatan kinerja 110 %.

Perusahaan foto dan video sharing: peningkatan kinerja 290 %.

Organisasi olahraga profesional: peningkatan kinerja 300-400 %. Transfer file besar. Perusahaan yang membutuhkan transfer file besar ke konsumen, partner dan pegawai antar dunia memperlihatkan gain kinerja yang signifikan ketika meleverage network overlay Akamai. Hasil tipikal ini meliputi:

Peningkatan 5 kali lipat dalam throughput transfer file besar (2 GB) dari Eropa ke US untuk perusahaan backup dan rekoveri data.

Peningkatan 4 kali sampai 5 kali dalam kinerja perusahaan semikonduktor global ketika menggunakan SFTP untuk mentransfer file desain skematik besar.

Peningkatan kecepatan 2,3 kali untuk transfer file pada VPN antara INDia dan US untuk publisher global. Selain itu, porsi signifikan dari enkripsi SSL intensif-sumberdaya bisa dioffload ke Akamai.

Perhatikan bahwa gain kinerja didapat karena optimisasi path dan protokol, bukan edge caching. Cara edge caching tidak efektif dalam transfer point-to-point dan untuk kasus dengan jumlah konten download kecil di region tertentu. eCommerce. Akamai mempermudah penanganan milyaran dolar pendapatan eCommerce di retailer online, yang meliputi 90 dari 100 situs retail Internet teratas. Konsumen melaporkan adanya penghematan biaya infrastruktur signifikan, dan juga merasakan peningkatan kinerja yang membantu pertumbuhan situs, meningkatkan reputasi brand, dan mengurangi pembuangan kereta belanja. EdgeComputing. Sony Ericsson menggunakan EdgeComputing dari Akamai untuk menghindari pembuatan pusat data regional yang mahal. Mereka mendeploy sejumlah komponen aplikasi, termasuk konfigurator telepon, kereta belanja, dan aplikasi lokator dealer, ke dalam edge, sedangkan komponen lain dijalankan di pusat data sentarlis. Strategi hybrid cloud mengurangi waktu respon aplikasi sampai faktor empat, sekaligus meningkatkan ketersediaan aplikasi dari 92 % sampai 100 %, dan mengurangi kebutuhan infrastruktur sebesar 65 %. 10. UCAPAN TERIMA KASIH

11. DAFTAR PUSTAKAPAGE 2