온프레미스와 온클라우드 설계 간의 장단점

플라톤에 의해 재발행

팔로워 : 0

전문가들이 참석: Semiconductor Engineering은 회사가 온프레미스 및 클라우드에서 작업을 분할하는 방법과 이유, 그리고 주의해야 할 사항에 대해 CAD 인프라 및 물리적 설계 펠로우인 Philip Steinke와 함께 논의했습니다. AMD; Mahesh Turaga, 클라우드 비즈니스 개발 담당 부사장 케이던스 디자인 시스템; Lightmatter의 하드웨어 엔지니어링 부사장 Richard Ho; Craig Johnson, 클라우드 솔루션 부사장 Siemens Digital Industries 소프트웨어; 그리고 Rob Aitken, 동료 Synopsys. 다음은 Design Automation Conference에서 실시간 청중 앞에서 진행된 대화의 일부입니다. 이 토론의 첫 번째 부분은 여기에서 지금 확인해 보세요..

SE: 오늘날 칩 설계에는 많은 위험이 따릅니다. 클라우드 리소스를 사용하여 최고의 ROI를 달성하려면 어떻게 해야 합니까?

스타인케: 클라우드 활성화를 위한 워크플로를 선택할 때 우리는 데이터를 살펴보는 것부터 시작했습니다. 캡슐화하고 클라우드 호스팅 데이터 센터로 이동하여 일종의 컴퓨팅을 수행한 다음 합리적인 양의 결과를 얻을 수 있는 관리 가능한 데이터 세트가 있는 것은 무엇입니까? 우리가 집중한 영역 중 하나는 프런트엔드 검증이었습니다. 제가 선호하는 흐름은 빌드를 온프레미스에 유지하고, 모델 자체를 테스트 자극과 함께 묶은 다음, 이를 클라우드 컴퓨팅에서 실제 시뮬레이션 활동을 수행하기 위해 보내는 것입니다. 우리가 클라우드를 구현한 다른 종류의 워크로드는 전체 칩 검증 워크로드, 정적 타이밍을 위한 전체 칩 사인오프 실행, 물리적 검증 및 전력입니다. 주로 장소 및 경로 유형 환경에서는 일상적인 ECO 또는 정기적인 ECO가 발생하고 변경되고 이미 데이터 관리 설정이 완료되어 설계 릴리스가 완료되었습니다. 따라서 우리는 해당 릴리스 메커니즘에 후크를 넣을 수 있습니다. 이를 자체 데이터 센터의 일종의 로컬 릴리스 볼륨에 넣는 것뿐만 아니라 해당 데이터를 실행하기 위해 선택된 클라우드 데이터 센터로 푸시할 수 있습니다. 직업. 이렇게 큰 워크로드에 대한 우려 사항 중 하나는 병합된 Oasis가 이미 있거나 정적 타이밍을 실행하려는 디자인에 대한 모든 사양을 수집한 경우 이동해야 할 상당한 양의 데이터가 있다는 것입니다. 한꺼번에. 그러나 블록 수준 릴리스 방법론을 업데이트하면 하루 동안 각 블록이 릴리스됨에 따라 조금씩 유입됩니다. 이렇게 하면 대기 시간을 단축하면서 클라우드에서 호스팅되는 전체 칩 분석 작업을 시작할 수 있습니다. 제가 본 주요 과제는 대규모 작업을 실행하기에 충분한 메모리를 갖춘 우수한 클라우드 VM에 액세스하는 것입니다. 이는 우리가 클라우드 파트너에게 계속해서 제공하도록 추진하는 또 다른 공간입니다. 즉, 칩 설계 회사가 사용할 수 있는 충분한 RAM을 갖춘 솔루션입니다.

SE: 워크로드가 언제 프레미스에서 수행되어야 하는지 클라우드에서 수행되어야 하는지 식별하는 데 대해 어떤 조언을 해주실 수 있나요?

에이트켄: 이 패널의 대표자들에게서 볼 수 있는 흥미로운 역동성이 있습니다. Richard가 접근하는 방식과 Phil이 접근하는 방식이 다르기 때문입니다. 하나는 요구 측면에서 최고점과 최저점을 통과하는 디자인에 매우 중점을 둡니다. AMD에서는 아마도 항상 많은 디자인이 진행되고 있기 때문에 그들이 하려는 일이 무엇인지에 대한 초기 노력이 있을 것입니다. 클라우드에서 모든 설계를 수행하고 온프레미스 데이터 센터가 전혀 없는 세상을 만들고자 한다면 어떤 인프라가 의미가 있습니까? 이에 접근하는 방식은 이미 보유하고 있는 대규모 인프라에 대한 백업 및 확장 기능으로 클라우드를 사용하는 경우와 다를 것입니다.

SE: 실제로 어떻게 결정하시나요?

기침: 당신은 데이터를 봅니다. 얼마나 많은 데이터를 가지고 있나요? 얼마나 많은 데이터를 생성할 예정인가요? 그리고 당신은 무엇을 돌려받아야 합니까? 성공을 위한 핵심은 클라우드에서 원하는 정보를 다시 가져오는 것입니다. 온프레미스는 최소화되어야 하므로 표시되는 것은 보고서와 회귀 결과뿐입니다. 우리 빌드는 실제로 소규모 온프레미스에 있습니다. 우리는 이를 배송하고 시뮬레이션을 실행하며 자체적으로 적용 범위 분석을 수행합니다. 그런 다음 결과를 다시 보내는데 결과가 매우 작고 좋습니다. 백엔드가 다릅니다. 물리적 디자인 부분에서는 디자인을 외부로 내보내고 데이터베이스가 방대하기 때문에 가능한 한 오랫동안 클라우드에 머물기를 원하며 다시는 돌아오지 않기를 바랍니다. 그 시점에서는 서비스형 인프라(Infrastructure as a Service)가 됩니다. 사람들이 클라우드에 로그인하여 GDS를 얻을 때까지 거기에서 모든 물리적 설계를 수행하면 됩니다. 저기, 그것은 기계 내부의 것들입니다. 얼마나 많은 메모리를 얻을 수 있습니까? 그것은 제한 사항 중 하나입니다. 클라우드에 매우 큰 가상 머신을 보유하는 것은 실제로 매우 비용이 많이 듭니다. 직접 구입하는 것이 더 저렴한 경우가 많습니다. 우리는 비용에 대해 이야기하지 않았습니다. 클라우드의 비용은 사람들이 생각하는 것과 다릅니다. 꽤 높습니다. 온프레미스보다 더 많은 경우가 많기 때문에 유연성과 대용량 메모리 리소스에 대한 액세스 이점을 얻으려면 균형을 맞춰야 합니다. 그리고 그 모습은 각 고객마다 매우 개별적일 것입니다.

존슨 : 이 질문은 실제로 그렇게 하는 ROI와 관련이 있습니다. 이는 환경 사용자로서 달성하려는 목표에 따라 달라지며 이는 도전 과제의 일부입니다. 각 회사는 클라우드에서 무엇을 하고 싶은지, 그리고 그 이익을 얻기 위해 얼마나 공격적으로 지출할 의향이 있는지 파악하기 위해 전략에 따라 자체 계산을 수행합니다. 다른 요소는 측정한 수익이 소유 비용과 다르다는 것입니다. 우리는 ROI의 "R" 부분보다 총 소유 비용 분석을 더 잘 수행하는 경향이 있으며, 이는 더 많은 무형 요소를 처리 시간 및 출시 시간 이점으로 활용해야 합니다.

에이트켄: 대기 시간과 같은 간단한 경우에도 도구를 실행하고 '마우스를 움직였는데 잠시 후에 무슨 일이 발생합니다'라는 응답 시간이 오면 매우 실망스러울 수 있습니다.

투라가: 역사적으로 클라우드의 ROI를 살펴보면 클라우드를 매우 효과적으로 활용할 수 있는 세 가지 클래스의 도구가 있습니다. 첫 번째는 설계 조직, 설계 반복, 검증을 통한 회귀입니다. 두 번째는 컴퓨팅 로드가 많은 장기 실행 시뮬레이션이 있는 경우이며, 다양한 인스턴스에서 컴퓨팅 알고리즘을 활용하도록 매우 잘 확장할 수 있습니다. 세 번째는 대기 시간이 필요하고 많은 협업 성장이 필요한 도구와 같은 대화형 유형입니다. 이는 클라우드에서 최고의 ROI를 얻을 수 있는 세 가지 범주의 도구입니다. 그리고 다시 말하지만, 각 고객 상황에 따라 클라우드에서 어떤 도구를 시작하고 싶은지에 따라 다릅니다. 일부 고객은 검증으로 시작했지만 구체적인 고객 상황에 따라 다릅니다.

SE: 클라우드 사용자의 경우 클라우드 사용 모델에 대한 결정을 어떻게 내리셨나요?

스타인케: 우리는 한동안 있었어요. 우리는 이미 꽤 큰 데이터 센터를 갖고 있었기 때문에 처음부터 올인할 필요는 없었습니다. 우리는 클라우드가 제공하는 기능을 통해 우리가 보유한 기능을 확장하려고 했습니다. 우리의 온프레미스 데이터 센터는 계속해서 엄청난 양의 컴퓨팅 용량을 제공합니다. 프로젝트는 왔다 갔다 하며 예상치 못한 일이 발생합니다. 이러한 유연성을 계층화할 수 있고 우리가 끌어낼 수 있는 여러 컴퓨팅 소스를 가질 수 있다는 점은 우리가 뛰어넘고 싶었던 장점입니다. 이것이 클라우드에 대한 동기 부여의 큰 부분이었으며 우리가 그렇게 한 이유입니다. 우리는 이미 초기 투자를 했기 때문에 이를 확대하고 구축하려고 했습니다.

기침: 나는 두 가지 관점에서 이에 답할 수 있다. 첫 번째 관점은 제가 Lightmatter에 합류하기 전에는 Google에서 TPU 및 인프라팀 업무를 맡았고 그곳에서도 클라우드를 사용했다는 것입니다. 거기에 대한 대답은 Lightmatter의 대답과 다릅니다. 스스로에게 물어봐야 할 질문 중 하나는 저장소(저장소)를 온프레미스에서 원하는지 아니면 클라우드에서 원하는지입니다. Google 및 아마도 AMD와 같은 회사에서는 온프레미스 저장소를 원합니다. 그들은 더 안전하다고 느끼고 자신이 더 잘 통제할 수 있다고 느낍니다. Lightmatter와 같은 소규모 회사에서는 반드시 신경 쓰지 않습니다. 클라우드의 보안이 편해서 클라우드에 저장소를 둘 수 있었습니다. 그리고 더 작은 맥락에서 클라우드에 저장소가 있다는 것은 클라우드를 거의 전체 인프라로 사용하고 있음을 의미합니다. 온프레미스랑 똑같네요. 그게 첫 번째 고민이에요. 두 번째 관심사는 유산입니다. 일부 회사에는 레거시가 있으므로 레거시에서 클라우드 기반 솔루션으로 전환하려고 할 때 실제로 얻을 수 있는 것이 무엇인지 이해해야 하며 이는 이 패널의 목표에 부합합니다. 우리는 유연성, 최신 시스템 보유 등의 측면에서 이점을 얻을 수 있는 부분을 지적하려고 합니다. 실제로 중요한 부분은 병렬 실행이 많은 일부 워크로드에 있습니다. 실행 중인 대규모 서버와 작업을 관리하고 싶다면 클라우드를 이용해야 합니다. 이를 활용하여 워크로드를 만들 수 있습니다. 그런 다음 제약이 있는 데이터 흐름으로 돌아가서 결정을 내려야 합니다. 우리는 클라우드에 물리적 설계를 위한 저장소를 두기로 결정했지만 다른 회사에서는 그렇지 않았습니다. 나는 회사가 더 많은 것을 알고 있습니다. 그들은 많은 스토리지가 필요하고 그다지 많은 시스템이 필요하지 않기 때문에 여전히 온프레미스에서 많은 물리적 설계를 수행했습니다. 따라서 각 사례를 살펴보고 상황에 따라 결정을 내려야 합니다.

투라가: 많은 중소 규모 고객 스타트업은 온프레미스 저장소를 원하지 않습니다. 기존 데이터 센터 문제가 없으므로 실제로 클라우드를 완전히 수용하고 있습니다. 이미 대규모 온프레미스 인프라를 보유한 일부 대기업은 하이브리드형 모델로 전환하고 있습니다.

SE: 아직 클라우드에 최적화되지 않은 라이센스 비용 외에도 다양한 공급업체의 클라우드에서 사용할 수 있는 인스턴스 유형이 거의 당황스러울 정도로 많습니다. 사용자가 작업을 실행하는 데 적합한 유형의 인스턴스를 선택하는 방식을 어떻게 개선할 수 있습니까?

존슨 : 이것이 우리가 해결하려는 근본적인 문제 중 하나입니다. 우리의 아이디어는 자체 인프라를 관리하고 특정 방식으로 최적화하기를 원하는 AMD와 같은 회사를 위한 것이었습니다. 그들이 우리의 도움을 원하는 것은 어떤 유형의 인스턴스와 어떤 양의 메모리가 가장 잘 작동하는지에 대한 애플리케이션별 결정입니다. 워크로드 자체의 구성일 수도 있습니다. 최적의 성능을 위해 작업 실행을 어떻게 관리할 수 있습니까? 우리는 이 모든 것을 비행 계획이라고 부르는 것으로 패키지화하려고 노력합니다. 우리는 기본 제안과 함께 흐름의 다양한 부분에 대해 이러한 비행 계획을 사용할 수 있습니다. 고객이 그것을 사용하고 싶어한다면 좋습니다. 그들이 그것에 대해 비난하고 그것으로부터 개선하기를 원한다면 우리에게도 괜찮습니다.

에이트켄: Synopsys 보기는 동일하지만 수행 중인 특정 디자인에 대한 종속성도 있습니다. 일부 디자인에는 다른 디자인보다 더 크거나 더 높은 인스턴스가 필요합니다. 그리고 특정 워크플로가 무엇인지에 따라 일부 인스턴스는 다른 인스턴스보다 다소 의미가 있을 수 있습니다. 또한 라이센스 비용뿐만이 아닙니다. 클라우드의 기계 비용도 절충해야 합니다. 머신이 클수록 비용이 더 많이 들지만, 더 적은 인스턴스에서 더 오랫동안 워크로드를 실행하고 라이선스 요금은 더 많이 지불하지만 컴퓨팅 요금보다는 적게 지불할 수 있습니다.

기침: 우리의 초점은 실제 실행이 무엇인지 살펴보는 것이었습니다. 사전 체크인 진행인가요? 사전 체크인을 사용하면 짧은 대기 시간으로 더 빠른 실행을 원하므로 이를 위한 매우 고성능 인스턴스를 얻을 수 있습니다. 하룻밤의 회귀인가? 그런 경우에는 그것이 얼마나 빨리 끝나는지는 반드시 상관하지 않습니다. 밤새 완료하면 되므로 밤새 회귀에 대해 더 저렴한 인스턴스 비용을 지불할 수 있습니다. 우리는 클라우드 제공업체와 협력하여 이러한 유형의 작업을 실행하는 데 가장 적합한 인스턴스가 무엇인지 파악합니다. 그렇다면 비용 최적화의 문제입니다. 내가 말했듯이 비용이 꽤 빨리 합산되기 때문에 비용을 최대한 낮게 유지하고 싶습니다. 우리는 각각의 특정 워크로드를 살펴보고 "그것에 필요한 인스턴스 유형은 무엇입니까?"라고 말합니다. 동시에 각 작업에 대한 인스턴스 풀을 관리해야 하고 해당 작업이 실제로 시작될 때 합리적인 수준으로 실행되도록 사용 가능한 인스턴스 풀이 충분한지 확인해야 하기 때문에 어렵습니다. 기간. 배포를 진행하면서 이러한 질문을 해결해야 합니다.

투라가: 수년에 걸쳐 우리는 몇 가지 모범 사례를 개발해 왔습니다. 처음에 어떤 인스턴스 유형을 사용할지 확실하지 않은 경우 컴퓨팅과 메모리 사이의 균형을 맞추거나 일반적인 인스턴스 유형을 선택합니다. 하지만 다양한 유형의 워크로드와 검증을 살펴보면 약간 더 많은 메모리가 필요합니다. 타이밍도 마찬가지다. 더 많은 메모리가 필요합니다. CFD 분석을 위해서는 GPU가 필요할 수 있습니다. 이는 우리가 고객과 공유하기 위해 개발한 모범 사례의 일부입니다.