Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Amazon EMR Service Quotas verwalten **Topics** + [Was sind Amazon EMR Service Quotas?](emr-service-limits-what-are.md) + [Amazon EMR Service Quotas verwalten](emr-service-limits-strategy.md) + [Wann sollten EMR-Ereignisse eingerichtet werden in CloudWatch](emr-service-limits-cloudwatch-events.md) In den Themen in diesem Abschnitt werden EMR-Dienstkontingente (früher als Service Limits bezeichnet) beschrieben, wie sie in der verwaltet werden und wann es von Vorteil ist AWS-Managementkonsole, CloudWatch Ereignisse anstelle von Servicekontingenten zu verwenden, um Cluster zu überwachen und Aktionen auszulösen. # Was sind Amazon EMR Service Quotas? Ihr AWS Konto verfügt über Standard-Servicekontingenten, auch Limits genannt, für jeden AWS Dienst. Für den EMR-Service gibt es zwei Arten von Grenzwerten: + *Ressourcenbeschränkungen* – Sie können EMR verwenden, um EC2-Ressourcen zu erstellen. Diese EC2-Ressourcen unterliegen jedoch Service Quotas. Die Ressourcenbeschränkungen in dieser Kategorie sind: + Die maximale Anzahl der aktiven Cluster, die gleichzeitig ausgeführt werden können. + Die maximale Anzahl aktiver Instances pro Instance-Gruppe. + *Einschränkungen bei APIs* — Bei der Verwendung von EMR APIs gibt es zwei Arten von Einschränkungen: + *Burst-Limit* – Dies ist die maximale Anzahl von API-Aufrufen, die Sie gleichzeitig tätigen können. Beispielsweise ist die maximale Anzahl von AddInstanceFleet API-Anfragen, die Sie pro Sekunde stellen können, standardmäßig auf 5 calls/second festgelegt. Dies bedeutet, dass das Burst-Limit der AddInstanceFleet API bei 5 Aufrufen/Sekunde liegt oder dass Sie zu einem bestimmten Zeitpunkt maximal 5 AddInstanceFleet API-Aufrufe tätigen können. Nachdem Sie das Burst-Limit verwendet haben, sind Ihre nachfolgenden Aufrufe jedoch durch das Ratenlimit begrenzt. + *Ratenlimit* – Dies ist die Wiederauffüllrate der Burst-Kapazität der API. Beispielsweise ist die Wiederauffüllrate von AddInstanceFleet Aufrufen standardmäßig auf 0,5 calls/second festgelegt. Das bedeutet, dass Sie, nachdem Sie das Burst-Limit erreicht haben, mindestens 2 Sekunden warten müssen (0,5 Aufrufe/Sekunde X 2 Sekunden = 1 Anruf), um den API-Aufruf zu tätigen. Wenn Sie vorher einen Aufruf tätigen, werden Sie vom EMR-Webservice gedrosselt. Zu jedem Zeitpunkt können Sie nur so viele Aufrufe tätigen, wie die Burst-Kapazität ausreicht, ohne dass dies gedrosselt wird. Mit jeder weiteren Sekunde, die Sie warten, erhöht sich Ihre Burst-Kapazität um 0,5 Aufrufe, bis sie das maximale Limit von 5, dem Burst-Limit, erreicht. # Amazon EMR Service Quotas verwalten Service Quotas ist eine AWS Funktion, mit der Sie Ihre Amazon EMR-Servicekontingente oder -Limits von einem zentralen Ort aus einsehen und verwalten können, indem Sie die AWS-Managementkonsole, die API oder die AWS CLI. Weitere Informationen zum Anzeigen von Quotas und zum Beantragen einer Erhöhung finden Sie unter [AWS -Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in der *Allgemeine Amazon Web Services-Referenz*. **Wichtig** Servicekontingente können unabhängig voneinander durchgesetzt werden, und manchmal können sich ihre Auswirkungen überschneiden. Einige sind auf bestimmte Kontingente beschränkt APIs, und andere Kontingente setzen Beschränkungen auf Kontoebene durch. Insbesondere werden die folgenden Kontingente auf Kontoebene angewendet: *Die maximale Rate, mit der Ihr Bucket für alle EMR-Operationen aufgefüllt wird.* *Die maximale Anzahl von API-Anfragen, die Sie pro Sekunde stellen können* Beachten Sie, dass es möglich ist, dass eines dieser Kontingente auf Kontoebene weiterhin die API-Aufrufraten begrenzt, wenn Sie erfolgreich eine bestimmte Kontingenterhöhung beantragen und weiterhin Drosselungen feststellen, z. B. für API-Anfragen. Zur Problembehebung können Sie die Konsole für Dienstkontingente verwenden, die zu [https://console.aws.amazon.com/servicequotas/Hause](https://console.aws.amazon.com/servicequotas/home) verfügbar ist, um die Kontingentlimits zu überprüfen und Erhöhungen zu beantragen. Wenn Sie Erhöhungen beantragen und weiterhin Drosselungen feststellen, wenden Sie sich an den Support. Standardlimits und Beschreibungen für EMR [Service-Kontingente](https://docs.aws.amazon.com/general/latest/gr/emr.html#limits_emr) finden Sie auch im ***Referenzhandbuch* mit AWS allgemeinen** Referenzen. Für einige APIs ist die Einrichtung einer CloudWatch Veranstaltung möglicherweise die bessere Option als die Erhöhung der Servicekontingenten. Sie können auch Zeit sparen, indem CloudWatch Sie proaktiv Alarme einrichten und Erhöhungsanforderungen auslösen, bevor Sie das Servicekontingent erreichen. Weitere Details finden Sie unter [Wann sollten EMR-Ereignisse eingerichtet werden in CloudWatch](emr-service-limits-cloudwatch-events.md). # Wann sollten EMR-Ereignisse eingerichtet werden in CloudWatch Bei einigen Abfrage-APIs, wie DescribeCluster, und DescribeStep ListClusters, kann die Einrichtung eines CloudWatch Ereignisses die Reaktionszeit auf Änderungen reduzieren und Ihre Servicekontingenten freisetzen. Wenn Sie beispielsweise eine Lambda-Funktion so eingerichtet haben, dass sie ausgeführt wird, wenn sich der Status eines Clusters ändert, z. B. wenn ein Schritt abgeschlossen oder ein Cluster beendet wird, können Sie diesen Auslöser verwenden, um die nächste Aktion in Ihrem Workflow zu starten, anstatt auf die nächste Abfrage zu warten. Andernfalls, wenn Sie über dedizierte Amazon-EC2-Instances oder Lambda-Funktionen verfügen, die ständig die EMR-API nach Änderungen abfragen, verschwenden Sie nicht nur Rechenressourcen, sondern könnten auch Ihr Service Quota erreichen. Im Folgenden sind einige Fälle aufgeführt, in denen Sie von einer Umstellung auf eine ereignisgesteuerte Architektur profitieren könnten. ## Fall 1: EMR-Abfrage mithilfe von DescribeCluster API-Aufrufen zur Schrittabwicklung **Example EMR mithilfe von DescribeCluster API-Aufrufen zur Schrittabwicklung abfragen** Ein gängiges Muster besteht darin, einen Schritt an einen laufenden Cluster zu senden und Amazon EMR nach dem Status des Schritts abzufragen, in der Regel mit dem DescribeCluster oder DescribeStep APIs. Diese Aufgabe kann auch mit minimaler Verzögerung erledigt werden, indem Sie sich in das Amazon-EMR-Schrittstatusänderungsereignis einklinken. Dieses Ereignis enthält die folgenden Informationen in seiner Nutzlast. ``` { "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Step Status Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:53:09Z", "region": "us-east-1", "resources": [], "detail": { "severity": "ERROR", "actionOnFailure": "CONTINUE", "stepId": "s-ZYXWVUTSRQPON", "name": "CustomJAR", "clusterId": "j-123456789ABCD", "state": "FAILED", "message": "Step s-ZYXWVUTSRQPON (CustomJAR) in Amazon EMR cluster j-123456789ABCD (Development Cluster) failed at 2016-12-16 20:53 UTC." } } ``` In der Detailmap könnte eine Lambda-Funktion nach „state“, „stepId“ oder „clusterId“ suchen, um relevante Informationen zu finden. ## Fall 2: EMR nach verfügbaren Clustern abfragen, um Workflows auszuführen **Example EMR nach verfügbaren Clustern abfragen, um Workflows auszuführen** Ein Muster für Kunden, die mehrere Cluster ausführen, besteht darin, Workflows auf Clustern auszuführen, sobald sie verfügbar sind. Wenn viele Cluster laufen und ein Workflow auf einem wartenden Cluster ausgeführt werden muss, könnte ein Muster darin bestehen, EMR mithilfe von API-Aufrufen DescribeCluster oder ListClusters API-Aufrufen nach verfügbaren Clustern abzufragen. Eine weitere Möglichkeit, die Verzögerung zu verringern, wenn Sie wissen, wann ein Cluster für einen Schritt bereit ist, besteht darin, das Amazon-EMR-Cluster-Statusänderungsereignis in zu verarbeiten. Dieses Ereignis enthält die folgenden Informationen in seiner Nutzlast. ``` { "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:43:05Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "WAITING", "message": "Amazon EMR cluster j-123456789ABCD ..." } } ``` Für dieses Ereignis könnte eine Lambda-Funktion eingerichtet werden, um einen wartenden Workflow sofort an einen Cluster zu senden, sobald sich sein Status in WAITING ändert. ## Fall 3: EMR nach Cluster-Terminierung abfragen **Example EMR nach Cluster-Terminierung abfragen** Kunden, die viele EMR-Cluster betreiben, fragen häufig bei Amazon EMR nach beendeten Clustern ab, sodass keine Arbeit mehr an Amazon EMR gesendet wird. Sie können dieses Muster mit den ListClusters API-Aufrufen DescribeCluster und oder mithilfe des Amazon EMR Cluster State Change-Events in implementieren. Nach der Clusterbeendigung sieht das ausgegebene Ereignis wie im folgenden Beispiel aus. ``` { "version": "0", "id": "1234abb0-f87e-1234-b7b6-000000123456", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T21:00:23Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"USER_REQUEST\",\"message\":\"Terminated by user request\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "TERMINATED", "message": "Amazon EMR Cluster jj-123456789ABCD (Development Cluster) has terminated at 2016-12-16 21:00 UTC with a reason of USER_REQUEST." } } ``` Der Abschnitt „Detail“ der Nutzlast enthält die ClusterID und den Status, auf den reagiert werden kann.