EC2 사용시 인스턴스와 코어

종종 "중간 데이터"프로젝트라고 할 수있는 작업을 수행하면서 4 개에서 32 개 코어에 이르는 단일 시스템에서 코드 (대부분 Python에서 모델링 및 예측 용)를 병렬화 할 수있었습니다. 이제는 EC2에서 클러스터로 확장하는 것을보고 있는데 (아마도 StarCluster / IPython을 사용하지만 다른 제안에도 열려 있음) 클러스터의 인스턴스와 인스턴스의 코어간에 작업을 분산시키는 방법에 의문이 생겼습니다.

각 인스턴스의 코어와 각 인스턴스에서 병렬 처리하는 것이 실용적입니까? 그렇다면 누구나 코어가 거의없는 많은 인스턴스를 실행하는 것과 비교하여 코어가 많은 인스턴스를 실행하는 장단점을 빠르게 정리할 수 있습니까? 인스턴스 당 코어 대 인스턴스의 비율을 올바르게 선택하는 데 필요한 경험이 있습니까?

내 프로젝트에서 대역폭과 RAM은 사소한 문제이지만 병목 현상과 재조정이 발생했을 때 쉽게 파악할 수 있습니다. 반복적 인 테스트없이 인스턴스에 적합한 코어 조합을 벤치마킹하는 것이 훨씬 더 어려우며 내 프로젝트는 단일 테스트가 모든 상황에 적용하기에는 너무 다양합니다. 미리 감사드립니다.이 구글을 제대로 검색하지 못하면 다른 곳에서 올바른 답변을 알려주십시오.

IPython을 사용할 때 효율성에 대한 약간의 손실 / 더 큰 통신 오버 헤드로 인해 걱정할 필요가 거의 없습니다. StarCluster의 병렬 IPython 플러그인은 기본적으로 각 노드에서 물리적 코어 당 하나의 엔진을 시작합니다 (이것은 구성 가능하지만 확실하지는 않습니다). DirectView api (map_sync, apply_sync, ...) 또는 % px 매직 명령을 사용하여 모든 엔진에서 원하는 것을 실행하면됩니다. 한 시스템에서 이미 IPython을 병렬로 사용하는 경우 클러스터에서 IPython을 사용하는 것도 다르지 않습니다.

특정 질문 중 일부를 해결 :

"인스턴스의 코어와 클러스터의 인스턴스간에 작업 분산을 조정하는 방법"-코어 당 하나 이상의 엔진을 얻습니다 (적어도). 작업은 모든 코어와 모든 인스턴스에 자동으로 배포됩니다.

"인스턴스와 각 인스턴스의 코어를 병렬화하는 것이 실용적입니까?" -예 :) 실행중인 코드가 당황스럽게 평행 한 경우 (여러 데이터 세트에서 정확히 동일한 알고리즘) 특정 엔진이 실행되는 위치를 대부분 무시할 수 있습니다. 코어가 엔진간에 많은 통신을 요구하는 경우 물론 엔진이 기본적으로 동일한 물리적 시스템의 다른 엔진과 통신하도록이를 구성해야합니다. 그러나 이런 종류의 문제는 IPython에 이상적으로 적합하지 않습니다.

"만약 그렇다면 누구든지 각각 코어가 적은 많은 인스턴스를 실행하는 것보다 많은 코어를 가진 인스턴스를 실행하는 장단점을 신속하게 정리할 수 있습니까? 인스턴스 당 코어 대 인스턴스의 비율을 적절하게 선택하는 규칙이 있습니까? " -컴퓨팅 바운드에는 가장 큰 c3 인스턴스를 사용하고 메모리 대역폭 바운드에는 가장 작은 인스턴스를 사용하십시오. 메시지 전달 바운드 문제의 경우 가장 큰 인스턴스도 사용하지만 각 파티션이 하나의 실제 머신에서 실행되고 대부분의 메시지 전달이 동일한 파티션 내에 있도록 문제점을 분할하십시오. 2N double c3보다 N quadruple c3 인스턴스에서 크게 느리게 발생하는 문제는 드물다 (인공적인 예는 많은 수의 이미지에 대해 여러 개의 간단한 필터를 실행하는 경우가있을 수 있음). 동일한 이미지).

일반적으로 경험할 때까지 배포하지 않는 것이 좋습니다. 일반적으로 용량의 절반 인 2N 서버보다 특정 용량의 N 서버를 사용하는 것이 더 효율적입니다. 더 많은 데이터 액세스는 로컬로 이루어 지므로 네트워크 전체에서 메모리가 빠르거나 느려집니다.

특정 시점에서 추가 리소스 비용이 선형 적으로 증가하기 때문에 한 시스템의 확장은 비 경제적입니다. 그러나이 점은 여전히 ​​놀랍습니다.

특히 Amazon에서는 스팟 마켓 인스턴스를 사용하는 경우 각 인스턴스 유형의 경제성이 크게 다를 수 있습니다. 기본 요금은 더 많거나 적다는 것은 인스턴스 유형에 관계없이 동일한 양의 리소스 비용이 거의 동일하다는 것을 의미합니다. 큰 인스턴스는 작은 인스턴스보다 저렴하거나 N 개의 작은 인스턴스는 동일한 리소스를 가진 하나의 큰 컴퓨터보다 훨씬 저렴할 수 있습니다.

여기서 한 가지 큰 고려 사항은 한 시스템에서 여러 시스템으로 이동할 때 계산 패러다임이 상당히 많이 변경 될 수 있다는 것입니다. 통신 오버 헤드로 인한 트레이드 오프는 예를 들어 데이터 병렬 패러다임을 채택하도록 강요 할 수 있습니다. 그것은 다른 도구와 알고리즘의 선택을 의미합니다. 예를 들어 SGD는 MapReduce와는 다른 인 메모리 및 Python에서 매우 다르게 보입니다. 따라서 병렬화하기 전에이를 고려해야합니다.

안정성을 위해 단일 노드 및 비 분산 패러다임이 작동하더라도 클러스터에 작업을 분산하도록 선택할 수 있습니다. 단일 노드가 실패하면 모든 계산이 손실됩니다. 분산 계산은 손실 된 계산의 일부만 복구하고 완료 할 수 있습니다.

동등한 것으로 간주되는 모든 것 (비용, CPU 성능 등) 내 데이터 세트를 모두 메모리에 보관하고 확장 할 수있는 가장 작은 인스턴스를 선택할 수 있습니다. 그런 식으로

• 네트워크 통신으로 인해 불필요한 대기 시간이 발생하지 않도록해야합니다.
• 프로세스에 사용 가능한 전체 메모리 대역폭을 최대화하는 경향이 있습니다.

모델의 일부 메타 매개 변수 를 최적화하기 위해 일종의 교차 유효성 검사 체계 를 실행한다고 가정하면 각 코어에 테스트 할 값을 할당하고 필요한만큼 적은 수의 라운드로 모든 매개 변수 공간을 포함하는 데 필요한 많은 인스턴스를 선택하십시오.

데이터가 한 시스템의 메모리에 맞지 않으면 인스턴스간에 분산해야합니다. 그런 다음 메모리 대기 시간 (더 많은 인스턴스가있는)과 네트워크 대기 시간 (더 적은 인스턴스가있는)의 균형을 맞추는 문제이지만 EC2의 특성을 고려할 때 몇 가지 뚱뚱한 인스턴스로 작업하는 것이 더 좋습니다.