Best practices voor app-ontwikkeling overwegen
In deze les verkent u enkele aanbevolen procedures die u kunt toepassen bij het ontwikkelen van apps met Azure Database for MySQL - Flexible Server die kunnen helpen om betere prestaties, tolerantie en beveiliging te garanderen. Deze aanbevolen procedures zijn onder andere:
- Resources toewijzen.
- Het implementeren van groepsgewijze verbindingen.
- De juiste app-containergrootte kiezen.
- Netwerkisolatie en SSL-connectiviteit implementeren.
- Het implementeren van logica voor opnieuw proberen om tijdelijke fouten te beheren.
- De juiste reken- en opslaggrootte voor de database kiezen.
Deze aanbevolen procedures worden op verschillende punten in het ontwikkelingsproces van apps besproken met Azure Database for MySQL - Flexible Server, zoals wordt weergegeven in het volgende diagram.
Notitie
Deze lijst met aanbevolen procedures is niet volledig. Raadpleeg de documentatie van Azure Database for MySQL voor gedetailleerde handleidingen over het implementeren van best practices met betrekking tot netwerken, beveiliging, bewaking, prestatieoptimalisatie, bedrijfscontinuïteit en herstel na noodgevallen, enzovoort.
Resources colocate
Zorg er bij het implementeren van uw app in Azure voor dat al uw resourceafhankelijkheden in dezelfde regio worden gehost. Het spreiden van resource-exemplaren tussen regio's of beschikbaarheidszones kan netwerklatentie veroorzaken, wat de algehele prestaties van uw app kan beïnvloeden.
Groepsgewijze verbindingen implementeren
Het beheren van databaseverbindingen binnen een app kan aanzienlijk van invloed zijn op de algehele app-prestaties. Als u de prestaties en tolerantie van apps wilt verbeteren, kunt u verbindingspooling implementeren om verbinding te maken met een flexibele MySQL-server. Een verbindingspooler (zoals ProxySQL) kan het aantal niet-actieve verbindingen verminderen en bestaande verbindingen opnieuw gebruiken.
Tip
Om de prestaties te optimaliseren, vermindert u in sleutelcodepaden het aantal keren dat verbindingen tot stand zijn gebracht en de tijd die nodig is om deze verbindingen tot stand te brengen.
De juiste app-containergrootte kiezen
Omdat het selecteren van de juiste grootte voor uw app-container essentieel is, moet u ervoor zorgen dat de app voldoende reken- en geheugenresources heeft om verwachte belastingen te verwerken. U kunt hulpprogramma's zoals JMeter gebruiken om te helpen bij het testen van belasting, zodat u de grootte van uw resources op de juiste manier kunt aanpassen op basis van de resultaten.
Netwerkisolatie en SSL-connectiviteit implementeren
Azure Database for MySQL - Flexible Server met VNet-integratie (de connectiviteitsmethode voor privétoegang) biedt netwerkbeveiliging en isolatie. U kunt VNet-integratie gebruiken om servertoegang tot uw virtuele netwerkinfrastructuur (VNet) alleen te vergrendelen. Privé-eindpunten verbeteren deze beveiliging doordat u veilig verbinding kunt maken met uw flexibele server via een particulier netwerk, waardoor blootstelling aan het openbare internet wordt vermeden. U kunt uw app- en databasebronnen beveiligen in één VNet of in verschillende VNets in dezelfde of verschillende regio's (en naadloos zijn verbonden met peering van virtuele netwerken).
Het wordt ook aanbevolen om gegevens tijdens overdracht te beveiligen door ervoor te zorgen dat uw app verbinding maakt met een flexibele MySQL-server met behulp van Ssl (Secure Sockets Layer).
Logica voor opnieuw proberen implementeren om tijdelijke fouten te beheren
Omdat cloudomgevingen waarschijnlijk tijdelijke fouten ondervinden, zoals onderbrekingen van de netwerkverbinding of servicetime-outs, moet u ervoor zorgen dat uw apps logica implementeren om deze problemen op te lossen, meestal door aanvragen na een vertraging opnieuw uit te voeren.
Het is een goed idee om vijf seconden te wachten voordat u het eerst opnieuw probeert. Verhoog vervolgens bij elke volgende nieuwe poging de wachttijd geleidelijk, tot 60 seconden. Na een vast aantal nieuwe pogingen kan de app overwegen dat de bewerking is mislukt en u op de hoogte stellen zodat u de permanente fout verder kunt onderzoeken.
De juiste reken- en opslaggrootte kiezen voor uw database
Het is belangrijk om uw workload te analyseren en de grootte van uw flexibele MySQL-serverexemplaren correct te analyseren om een acceptabele balans te bereiken tussen de prestaties en kosten van apps.
Compute
U kunt een flexibele MySQL-server maken in een van de drie rekenlagen: Burstable, General Purpose en Bedrijfskritiek. Als uitgangspunt voor het kiezen van de rekenlaag kunt u de details in de volgende tabel bekijken.
| Compute-laag | Beoogde workloads |
|---|---|
| Met burstfunctie | Het meest geschikt voor workloads die niet continu de volledige CPU nodig hebben. Rendabel voor kleinere web-apps en ontwikkelworkloads. |
| Algemeen gebruik | Het meest geschikt voor de meeste zakelijke workloads die een evenwichtige rekenkracht en geheugen vereisen met schaalbare I/O-doorvoer. Voorbeelden hiervan zijn servers voor het hosten van web- en mobiele apps en andere zakelijke apps. |
| Bedrijfskritiek | Het beste voor databaseworkloads met hoge prestaties die prestaties in het geheugen vereisen voor snellere transactieverwerking en hogere gelijktijdigheid. Voorbeelden zijn onder meer servers voor het verwerken van realtime gegevens en transactionele of analytische toepassingen met hoge prestaties. |
Hoewel u na het maken ook de grootte van Flexibele MySQL-servers kunt wijzigen, kunt u alleen omhoog of omlaag schalen tussen de lagen Algemeen gebruik of Bedrijfskritiek.
Storage
In termen van opslag kunt u omhoog schalen wanneer u de limieten voor opslagcapaciteit nadert. U kunt de functie voor automatisch vergroten van opslag ook inschakelen om ervoor te zorgen dat de service de opslag automatisch schaalt wanneer deze de opslaglimieten nadert.
Als u weloverwogen beslissingen wilt nemen over berekeningen en opslag tijdig, controleert u belangrijke metrische gegevens van Azure Monitor, zoals host-CPU-percentage, hostgeheugenpercentage, opslagpercentage, IO-percentage, actieve verbindingen, enzovoort, voortdurend of stelt u waarschuwingen in om u te waarschuwen wanneer de oplossing de limieten van uw implementatie nadert.
IOPS aanpassen voor optimale prestaties
Een aanzienlijke verbetering die beschikbaar is in Azure Database for MySQL - Flexible Server is de functie IOPS voor automatisch schalen (Input/Output Operations Per Second), die een aanvulling vormt op de bestaande vooraf ingerichte IOPS-functie. In deze sectie wordt beschreven hoe u vooraf ingerichte IOPS en opties voor automatische schaalaanpassing van IOPS kunt gebruiken om de databaseprestaties te optimaliseren op basis van verschillende workloadvereisten.
Vooraf ingerichte IOPS
U kunt een specifiek aantal IOPS toewijzen aan uw database-exemplaar met behulp van vooraf ingerichte IOPS. Deze functie is van cruciaal belang voor workloads die consistente en voorspelbare prestaties vereisen. Door een gedefinieerde IOPS-limiet in te stellen, kunt u ervoor zorgen dat uw database een vast aantal aanvragen per seconde kan verwerken, waardoor stabiele en betrouwbare prestaties behouden blijven. U hebt ook de flexibiliteit om het aantal IOPS aan te passen dat is ingericht als uw workload verandert, waardoor schaalbaarheid en nauwkeurige controle over de prestaties van uw database mogelijk zijn.
IOPS automatisch schalen
IOPS voor automatische schaalaanpassing biedt dynamische schaalaanpassing van prestaties, een essentiële functie voor het effectief beheren van fluctuerende workloads. Als deze functie is ingeschakeld, past de databaseserver IOPS automatisch aan op basis van realtime vraag zonder dat vooraf inrichten nodig is. Deze flexibiliteit is met name nuttig voor laag-1, bedrijfskritieke apps die mogelijk te maken hebben met variabele prestatiebehoeften.
De belangrijkste voordelen van het gebruik van IOPS-functionaliteit voor automatische schaalaanpassing zijn:
Dynamisch schalen: Met de functie IOPS voor automatische schaalaanpassing worden de IOPS-limieten automatisch aangepast op basis van de werkelijke vraag naar werkbelasting. Deze dynamische aanpassing zorgt ervoor dat uw database consistent werkt op optimale prestatieniveaus zonder handmatige tussenkomst.
Workloadpieken verwerken: met deze functie kan uw database naadloos plotselinge toenames in belasting verwerken, zodat de prestaties van apps consistent blijven tijdens piekperioden. Deze mogelijkheid is van cruciaal belang voor het behouden van de beschikbaarheid van de service en de tevredenheid van gebruikers.
Kostenefficiëntie: In tegenstelling tot vooraf ingerichte IOPS, waarbij u betaalt voor een opgegeven limiet, ongeacht het werkelijke gebruik, zorgt Autoscale IOPS ervoor dat u alleen betaalt voor de I/O-bewerkingen die daadwerkelijk worden gebruikt. Dit kan leiden tot aanzienlijke kostenbesparingen, met name voor databases met variabele I/O-behoeften.
Vereenvoudigd beheer: Door de noodzaak voor handmatig schalen en capaciteitsplanning te verminderen, maakt IOPS voor automatische schaalaanpassing beheerresources vrij, zodat uw team zich kan richten op meer strategische initiatieven in plaats van routineonderhoud.