MIGRERING TILL GRAVITON FÖR CONTAINERBASERAD ARBETSBELASTNING

AWS Graviton-processorer, utvecklade av Amazon Web Services, erbjuder ett kostnadseffektivt och effektivt alternativ för att köra applikationer i molnet. Genom att använda ARM-arkitektur och 64-bitars Neoverse-kärnor är dessa processorer optimerade för hög prestanda, skalbarhet och låg latens. Amazon Web Services har skräddarsytt designen på Graviton-processorerna för att erbjuda optimal prisprestanda och utbyggningsmöjligheter.

VARFÖR MIGRERA TILL GRAVITON

Kostnadsbesparingar

AWS Graviton-instanser bygger på ARM-arkitektur och erbjuder ett kostnadseffektivt alternativ till traditionella x86-instanser. De ger en mycket bra balans mellan kostnad och prestanda, vilket gör det möjligt att minska infrastrukturkostnader.

Förbättrad prestanda

ARM-baserad processorteknik ger förbättrad effektivitet och prestanda, vilket resulterar i snabbare svarstider och lägre latens.

MyMoney är byggt med en Java-baserad mikrotjänstarkitektur som körs i Amazon Elastic Container Service (ECS) med Amazon Aurora MySQL som databas. Lösningen består av cirka 25 mikrotjänster med varierande belastning, inklusive långa perioder av låg trafik och plötsliga toppar. Tjänsterna i ECS körs i Fargate-läge. Tidigare migrerades lösningen från EC2-baserad ECS till Fargate med hjälp av Sigma Technology Cloud, vilket minskade behovet av serverhantering och gjorde det möjligt för utvecklingsteamet att fokusera på affärsfunktionalitet.

CI/CD-översikt

CI/CD-flödet bygger på GitHub och GitHub Actions, där containerbilder byggs och pushas till Amazon ECR. Vid uppdatering av en bildversion i ECS TaskDefinition triggas en uppdatering av tjänster i respektive miljö: Dev, Test och Prod.

Eftersom MySQL-databasen kördes som en hanterad tjänst på Amazon Aurora är migreringsprocessen till Graviton-baserade instanser inte så komplicerad, men kräver fortfarande en strikt process och testning. En process och runbook för migreringen skapades, vilken kunde följas för varje miljö. Efter varje miljömigrering testades och övervakades applikationen för att säkerställa att inga problem hittades.

Att migrera Amazon Aurora till Graviton är lika enkelt som att byta databasinstansfamilj. För att säkerställa kvaliteten bör dock flera steg tas.

Detaljerade uppgraderingsinstruktioner

• Skapa en databas-ögonblicksbild: Det här steget är avgörande eftersom det låter dig återställa eventuella ändringar som gjorts under processen. Se till att inte missa denna åtgärd.
• Verifiera databasversionens kompatibilitet med Graviton.
• Se till att din nuvarande databasversion stöds av Graviton2. Om inte, måste du uppgradera. Kompatibla versioner inkluderar Aurora MySQL version 2.09.2 eller senare.
• Ändra instanstyperna därefter.
• För konfigurationer med läsrepliker. Börja med att uppgradera en läsreplik till Graviton och befordra den sedan till den primära instansen.
• Utan läsrepliker: överväg att lägga till en läsreplik tillfälligt för att undvika driftstopp under instansuppgraderingen.
• Utför en grundlig validering. Se till att din applikation fungerar som förväntat. Om du använder prestandainsikter kan det hjälpa dig att analysera frågeprestanda och väntetider.
• Fortsätt med migreringen. Om allt fungerar som det ska kan du migrera dina återstående repliker en i taget, vilket säkerställer en smidig övergång.

Dessa steg bör följas för varje miljö och om några problem uppstår bör de noteras och lärdomar bör tillämpas vid migrering av nästa miljö.

MIGRERING AV ECS

Migrering av containrar i Fargate, särskilt Java-baserade containrar, är också en ganska enkel process. Byggprocessen behöver anpassas till ARM-arkitekturen tillsammans med en uppdatering av Fargate-runtime. På MyMoney definieras all infrastruktur som Infrastruktur som kod med hjälp av CloudFormation. För att uppdatera Fargate-runtime till att vara baserad på Graviton måste CPU-arkitekturen vara inställd på ARM64 i avsnittet RuntimePlatform i TaskDefinition.

CloudFormation-fragment

---
  ServiceTaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      TaskRoleArn: !Ref TaskRole
      ExecutionRoleArn: !Ref TaskExecutionRole
      RequiresCompatibilities:
        - FARGATE
      NetworkMode: awsvpc
      Cpu: !Ref TaskCpuUnits
      Memory: !Ref TaskMemory
      RuntimePlatform:
        CpuArchitecture: ARM64
      ContainerDefinitions:
        - Image: '....'
          Name: !Ref ServiceName
          PortMappings:
            - ContainerPort: 8080
              Protocol: tcp
---

MyMoney använder Gradle för att bygga applikationen, ett steg som inte ändras när man går till Graviton. När containeravbildningen är byggd måste den byggas för en ARM-baserad arkitektur och eftersom bygget görs från en x86-baserad runner i GitHub Actions måste en korskompilering göras. För att göra det använder MyMoney buildx-kommandot i Docker och ställer in målplattformen till linux/arm64. Att ställa in proveniensflaggan till falsk säkerställer att det bara skapas en enda avbildning. Utan denna flagga skulle en tom x86-baserad avbildning skapas och skickas till ECR.

GitHub Actions-fragment 

- name: Build and push Docker image
        env:
          REGISTRY: ...
          REPOSITORY: ...
          IMAGE_TAG: ...
        run: |
          docker buildx build \
            --platform linux/arm64 \
            --build-arg JAR_FILE=.... \
            --tag $REGISTRY/$REPOSITORY:$IMAGE_TAG \
            --push \
            --provenance false \
            .

Med de två kombinerade ändringarna skapas containeravbildningar för Graviton och kan köras på en Graviton-baserad Fargate-uppgift.

De första mätningarna visar att MyMoney minskat sina kostnader för beräkning och databaser med cirka 25 %. Samtidigt har den övergripande prestandan förbättrats och CPU-användningen minskat. Detta möjliggör ytterligare optimering genom att skala ner resurser, vilket skulle leda till mer besparingar. Dessutom bidrar Graviton till lägre energiförbrukning och därmed minskat klimatavtryck.