Pengorbanan Antara Desain On-Premise dan On-Cloud

Diterbitkan Ulang Oleh Plato

Followers: 0

Pakar di Meja: Teknik Semikonduktor duduk membahas bagaimana dan mengapa perusahaan membagi pekerjaan di lokasi dan di cloud, dan apa yang harus diwaspadai, dengan Philip Steinke, rekan, infrastruktur CAD dan desain fisik di AMD; Mahesh Turaga, wakil presiden pengembangan bisnis untuk cloud di Sistem Desain irama; Richard Ho, wakil presiden teknik perangkat keras di Lightmatter; Craig Johnson, wakil presiden solusi cloud di Perangkat Lunak Siemens Digital Industries; dan Rob Aitken, rekan di Synopsys. Berikut ini adalah cuplikan percakapan tersebut, yang diadakan di depan audiensi langsung di Design Automation Conference. Bagian pertama dari diskusi ini adalah di sini.

SE: Dengan begitu banyak hal yang dipertaruhkan dalam desain chip saat ini, bagaimana Anda mencapai ROI terbaik dengan sumber daya cloud?

Steinke: Saat memilih alur kerja untuk pemberdayaan cloud, kami memulai dengan melihat data. Manakah yang memiliki kumpulan data yang dapat dikelola dan dapat dienkapsulasi, dipindahkan ke pusat data yang dihosting di cloud untuk melakukan semacam komputasi, dan kemudian mendapatkan hasil dalam jumlah yang wajar? Salah satu area yang kami fokuskan adalah verifikasi front-end. Alur pilihan saya di sana adalah menjaga build kami tetap di lokasi, menggabungkan model itu sendiri dengan stimulus pengujian, dan mengirimkannya untuk melakukan aktivitas simulasi sebenarnya di komputasi awan. Kelas beban kerja lain yang telah kami lakukan pengaktifan cloud adalah beban kerja verifikasi chip penuh, proses signoff chip penuh untuk pengaturan waktu statis, verifikasi fisik, dan daya — terutama karena dalam lingkungan tipe tempat dan rute, Anda masuk ke dalam irama reguler ECO harian atau ECO reguler yang terjadi dan membuat perubahan, dan sudah ada pengaturan manajemen data, dengan rilis desain sedang dilakukan. Jadi kami dapat mengaitkannya ke dalam mekanisme rilis tersebut, tidak hanya memasukkannya ke dalam semacam volume rilis lokal di pusat data kami sendiri, namun kemudian mengirimkan data tersebut ke pusat data cloud yang telah dipilih untuk mengeksekusi data tersebut. pekerjaan. Salah satu kekhawatiran tentang beban kerja sebesar itu adalah jika Anda sudah menggabungkan Oasis, atau jika Anda telah mengumpulkan semua spesifikasi untuk desain yang ingin Anda gunakan pengaturan waktu statisnya, itu adalah sejumlah besar data yang perlu diubah. semua sekaligus. Namun dengan memperbarui metodologi rilis tingkat blok, maka mereka mulai masuk seiring dengan rilisnya setiap blok sepanjang hari. Dengan begitu, Anda dapat memulai pekerjaan analisis chip lengkap yang dihosting di cloud dengan latensi lebih rendah. Tantangan utama yang saya lihat adalah akses ke VM cloud yang bagus dengan memori yang cukup untuk menjalankan pekerjaan besar tersebut. Ini adalah ruang lain yang terus kami dorong untuk ditawarkan oleh mitra cloud kami — solusi dengan banyak RAM untuk digunakan oleh perusahaan desain chip.

SE: Saran apa yang bisa Anda berikan untuk membedakan kapan beban kerja harus dilakukan di lokasi dan di cloud?

Aitken: Ada dinamika menarik yang kita lihat pada perwakilan panel ini, karena cara Richard mendekatinya, dan cara Phil mendekatinya akan berbeda. Yang satu sangat fokus pada desain yang bergerak melalui puncak dan lembah dalam hal kebutuhan. Di AMD, mungkin, ada banyak desain yang dibuat sepanjang waktu, jadi ada upaya awal dalam hal apa yang mereka coba lakukan. Infrastruktur apa yang masuk akal jika Anda mencoba memasuki dunia di mana Anda akan melakukan semua desain Anda di cloud, dan Anda lebih memilih tidak memiliki pusat data lokal sama sekali? Pendekatan Anda akan berbeda dibandingkan jika Anda menggunakan cloud sebagai kemampuan pencadangan dan perluasan untuk infrastruktur besar yang sudah Anda miliki.

SE: Secara praktis, bagaimana Anda memutuskannya?

Batuk: Anda melihat datanya. Berapa banyak data yang Anda miliki? Berapa banyak data yang akan Anda hasilkan? Dan apa yang kamu butuhkan kembali? Hal utama untuk membuatnya sukses adalah informasi yang Anda inginkan kembali dari cloud. Lokal harus minimal, jadi hanya laporan dan hasil regresi Anda yang akan muncul. Bangunan kami sebenarnya berada di lokasi kecil kami. Kami mengirimkannya dan menjalankan simulasi kami di luar sana, dan kami melakukan analisis cakupan kami sendiri. Lalu kami mengirimkan kembali hasilnya, dan itu sangat kecil, dan itu bagus. Bagian belakangnya berbeda. Pada bagian desain fisik, Anda mengirimkan desain tersebut ke luar sana, Anda ingin desain tersebut tetap berada di cloud selama mungkin karena database tersebut sangat besar, dan Anda benar-benar tidak ingin desain tersebut kembali sama sekali. Pada titik ini, infrastruktur adalah layanan. Anda cukup meminta orang-orang Anda masuk ke cloud dan melakukan semua desain fisik di sana hingga Anda mendapatkan GDS. Itu adalah hal-hal yang ada di dalam mesin — berapa banyak memori yang bisa Anda dapatkan? Itu salah satu pembatasnya. Sebenarnya sangat mahal untuk memiliki mesin virtual yang sangat besar di cloud. Seringkali lebih murah untuk membeli sendiri. Kami belum bicara soal biaya. Biaya cloud tidak seperti yang dipikirkan orang. Itu cukup tinggi. Ini lebih sering terjadi daripada di lokasi, jadi Anda harus menyeimbangkannya untuk mendapatkan keuntungan dari fleksibilitas dan akses ke sumber daya memori yang besar. Dan tampilannya akan sangat individual untuk setiap pelanggan.

Johnson: Pertanyaan ini sangat berkaitan dengan ROI dari melakukan hal itu. Hal ini bergantung pada apa yang ingin Anda capai sebagai pengguna lingkungan, dan itu adalah bagian dari tantangannya. Setiap perusahaan melakukan perhitungannya sendiri berdasarkan strategi mereka untuk mengetahui apa yang ingin mereka lakukan di cloud dan seberapa agresif mereka bersedia mengeluarkan uang untuk mendapatkan keuntungan tersebut. Elemen lainnya adalah keuntungan yang Anda ukur berbeda dengan biaya kepemilikan. Kami cenderung lebih baik dalam melakukan analisis total biaya kepemilikan dibandingkan bagian “R” dari ROI, yang kemudian harus memasukkan lebih banyak faktor tidak berwujud melalui waktu dan keunggulan waktu ke pasar.

Aitken: Bahkan dengan sesuatu yang sederhana seperti latensi, ketika Anda menjalankan suatu alat dan waktu responsnya adalah, 'Saya menggerakkan mouse dan beberapa saat kemudian sesuatu terjadi,' itu bisa sangat membuat frustrasi.

Turaga: Secara historis, jika kita melihat ROI untuk cloud, ada tiga kelas alat yang dapat memanfaatkan cloud dengan sangat efektif. Pertama adalah organisasi desain, iterasi desain, regresi dengan verifikasi. Kedua, terdapat simulasi yang berjalan lama dengan beban komputasi yang berat, dan simulasi tersebut dapat diskalakan dengan sangat baik untuk memanfaatkan algoritme komputasi dalam berbagai contoh. Ketiga adalah tipe interaktif, seperti alat yang memerlukan latensi dan juga memerlukan banyak pertumbuhan kolaborasi. Itulah tiga kategori alat yang mendapatkan ROI terbaik dari cloud. Dan sekali lagi, bergantung pada situasi masing-masing pelanggan, bergantung pada alat mana yang ingin mereka mulai di cloud. Beberapa pelanggan kami memulai dengan verifikasi, namun hal ini bergantung pada situasi spesifik pelanggan Anda.

SE: Untuk pengguna cloud, bagaimana Anda mengambil keputusan untuk model penggunaan cloud Anda?

Steinke: Kami sudah ada cukup lama. Kami sudah memiliki pusat data yang cukup besar, jadi kami tidak perlu melakukan semuanya di awal. Kami ingin menambah apa yang kami miliki dengan apa yang ditawarkan cloud. Pusat data lokal kami terus memberikan kapasitas komputasi dalam jumlah besar. Proyek datang dan pergi, dan hal-hal tak terduga terjadi; dapat memanfaatkan fleksibilitas tersebut dan memiliki banyak sumber komputasi yang dapat kami manfaatkan adalah keuntungan yang ingin kami manfaatkan. Hal ini menjadi bagian besar dari motivasi kami terhadap cloud, dan alasan kami melakukan hal tersebut. Kami sudah memiliki investasi awal, jadi ini adalah sesuatu yang ingin kami tingkatkan dan kembangkan.

Batuk: Saya bisa menjawabnya dari dua sudut pandang. Perspektif pertama adalah sebelum saya berada di Lightmatter, saya berada di Google bekerja di TPU dan tim infrastruktur, dan kami juga menggunakan cloud di sana. Jawabannya berbeda dengan jawaban di Lightmatter. Salah satu pertanyaan yang harus Anda tanyakan pada diri sendiri adalah apakah Anda ingin repo (repositori) Anda berada di lokasi atau di cloud. Di perusahaan seperti Google, dan mungkin AMD, mereka menginginkan repo mereka di lokasi. Mereka merasa lebih aman, mereka merasa hal-hal lebih berada dalam kendali mereka. Di perusahaan kecil seperti Lightmatter, saya tidak terlalu peduli. Saya merasa nyaman dengan keamanan cloud, sehingga saya dapat memiliki repo di cloud. Dan dalam konteks yang lebih kecil, memiliki repo di cloud berarti kami menggunakan cloud hampir sebagai infrastruktur penuh. Ini sama dengan di tempat saya. Itu kekhawatiran pertama. Kekhawatiran kedua adalah warisan. Beberapa perusahaan memiliki warisan, dan ketika Anda mencoba beralih dari solusi lama ke solusi berbasis cloud, Anda benar-benar harus memahami apa yang Anda peroleh, yang sesuai dengan tujuan panel ini. Kami mencoba untuk menunjukkan di mana Anda mendapatkan keuntungan dalam hal fleksibilitas, dalam hal kemampuan untuk memiliki mesin yang lebih baru, dll. Hal yang paling penting adalah pada beberapa beban kerja tersebut, di mana Anda memiliki banyak proses paralel. Anda ingin mengelola sejumlah besar server dan pekerjaan yang berjalan, dan di situlah Anda harus menggunakan cloud. Anda dapat memanfaatkan beban kerja Anda. Kemudian, kembali ke aliran data, di mana Anda mempunyai kendala, maka Anda harus membuat keputusan. Kami membuat keputusan untuk memiliki repo untuk desain fisik di cloud, namun perusahaan lain belum. Saya tahu bahwa perusahaan memiliki lebih banyak. Mereka telah melakukan banyak desain fisik masih di lokasi karena memerlukan banyak penyimpanan dan tidak memerlukan banyak mesin. Jadi, Anda harus melihat setiap kasus tersebut dan membuat keputusan berdasarkan situasi Anda.

Turaga: Banyak pelanggan startup kecil dan menengah kami yang tidak menginginkan repo on-prem. Mereka tidak memiliki masalah pusat data lama, jadi mereka benar-benar memanfaatkan cloud sepenuhnya. Beberapa perusahaan besar yang sudah memiliki infrastruktur lokal yang besar telah beralih ke model tipe hybrid.

SE: Dengan banyaknya jenis instans yang tersedia di cloud dari berbagai vendor, ditambah biaya lisensi yang belum dioptimalkan untuk cloud, bagaimana pengguna dapat meningkatkan cara mereka memilih jenis instans yang tepat untuk menjalankan pekerjaan mereka?

Johnson: Ini adalah salah satu hal mendasar yang kami coba atasi. Ide kami adalah untuk perusahaan seperti AMD yang sebagian besar ingin mengelola infrastruktur mereka sendiri, dan mengoptimalkannya dengan cara khusus mereka, yang mereka perlukan bantuan dari kami adalah keputusan khusus aplikasi mengenai jenis instance dengan jumlah memori yang bekerja paling baik, dan mungkin konfigurasi beban kerja itu sendiri. Bagaimana mereka dapat mengelola pekerjaan yang dijalankan untuk mendapatkan kinerja optimal? Kami mencoba mengemas semuanya menjadi sesuatu yang kami sebut rencana penerbangan. Kami memiliki rencana penerbangan ini yang tersedia untuk berbagai bagian aliran kami dengan saran dasar. Jika pelanggan ingin menggunakannya, bagus. Jika mereka ingin memanfaatkannya dan memperbaikinya, itu juga tidak masalah bagi kami.

Aitken: Tampilan Synopsys sama, tetapi ada juga ketergantungan pada desain spesifik yang Anda lakukan. Beberapa desain hanya memerlukan instance yang lebih besar atau lebih tinggi dibandingkan yang lain. Dan bergantung pada alur kerja khusus Anda, beberapa contoh akan lebih atau kurang masuk akal dibandingkan yang lain. Selain itu, ini bukan hanya biaya perizinan. Biaya mesin di cloud juga harus Anda tukarkan. Mesin yang lebih besar lebih mahal, tetapi mungkin Anda dapat menjalankan beban kerja Anda pada mesin virtual yang lebih kecil untuk waktu yang lebih lama dan membayar lebih banyak biaya lisensi tetapi lebih murah daripada biaya komputasi.

Batuk: Fokus kami adalah melihatnya dalam kaitannya dengan proses sebenarnya. Apakah ini merupakan proses pra-check-in? Dengan pra-check-in, Anda ingin berjalan lebih cepat dengan latensi rendah, sehingga Anda mendapatkan instance berperforma tinggi untuk itu. Apakah ini regresi dalam semalam? Dalam hal ini, saya tidak terlalu peduli seberapa cepat penyelesaiannya. Ini hanya perlu diselesaikan dalam semalam, jadi itu berarti saya dapat membayar instance yang lebih murah untuk regresi semalam saya. Kami bekerja sama dengan penyedia cloud kami untuk mencari tahu contoh terbaik untuk menjalankan jenis pekerjaan ini. Lalu masalahnya adalah mengoptimalkan biaya. Anda tentu ingin menekan biaya serendah mungkin karena seperti yang saya katakan, biayanya bertambah cukup cepat. Kami melihat setiap beban kerja tertentu dan bertanya, “Jenis instans apa yang diperlukan untuk itu?” Pada saat yang sama, hal ini menjadi sulit karena Anda kemudian harus mengelola kumpulan instance untuk setiap pekerjaan, dan kemudian memastikan Anda memiliki cukup kumpulan instance yang tersedia sehingga ketika pekerjaan tersebut benar-benar dimulai, pekerjaan tersebut berjalan dengan wajar. jangka waktu. Saat Anda mulai menerapkan, Anda harus menjawab pertanyaan-pertanyaan ini.

Turaga: Selama bertahun-tahun kami telah mengembangkan beberapa praktik terbaik. Awalnya, ketika Anda tidak yakin tipe instans mana yang akan digunakan, Anda memilih sesuatu dengan keseimbangan antara komputasi dan memori atau tipe instans umum tersebut. Namun saat Anda melihat berbagai jenis beban kerja dan verifikasi, Anda memerlukan lebih banyak memori. Hal yang sama terjadi pada waktu. Anda membutuhkan lebih banyak memori. Untuk analisis CFD, Anda mungkin memerlukan GPU. Ini adalah bagian dari praktik terbaik yang kami kembangkan yang kami bagikan kepada pelanggan.