AWS 솔루션을 이용한 로드 테스트

안녕하세요.크리스마스 이브는요!다들 어떻게 지내?
마르크라는 회사의 SRE입니다.나칸입니다.
그래서 이 보도는 Makuake Advent Calendar 2020 23일째 보도다.
갑작스럽지만 여러분.부하 테스트 중인가!
고생 끝에 만든 서비스가 세상에 나왔으니 이제 시작이다!이런 상황에서
방문이 집중되어 사이트가 마비되다.슬프죠?
이러한 상황을 피하기 위해 공개되기 전에 실제적으로 어느 정도의 방문 집중 상태를 모의적으로 만들 것이다
실제로 제공되는 체험을 받을 수 있는지 확인하는 것은 매우 중요한 일이다.

실제로 부하 테스트를 하려면 힘들잖아요.


신뢰할 수 있는 부하 테스트를 실시할 때, 의외로 환경의 준비가 매우 고생스럽다.
  • 하중을 가하는 목적지는 연결 제한을 받는다
  • 생성된 실행 환경이 상상하는 부하가 없어 내부 핵 파라미터를 조정해야 한다
  • 원래 제작된 환경에서 부하 테스트 도구를 설치하는 것은 매우 번거롭다
  • 하나하나의 문제를 해결하는 것은 결코 어렵지 않지만, 조금씩 부하 테스트를 진행하기 전에 시간은 박탈당했다
    결국 무시할 수 없는 양의 시간은 박탈당한다.
    SaaS를 활용하는 것에 대해 논의할 수 있다고 생각합니다. 이번에는 AWS 솔루션이 제공한
    Serverless의 분산 하중 테스트 환경을 활용하고 싶습니다.

    AWS 솔루션


    AWS 솔루션은 AWS 아키텍처와 AWS 파트너가 구축하고 검증한 기술 참조로 구현되며 다음과 같은 특징이 있습니다.
  • 적절한 AWS 서비스를 활용하여 활용, 비용 면에서 고가의 설계
  • 교란 해제 지침
  • 첨부
    AWS에 익숙한 사람들이 구축·검증된 일반적인 문제의 해결책을 자신들의 AWS 환경에 마련하고 그 은혜를 맡겼다는 것이다.이용하지 않는 손은 없다.또 분산부하 테스트 외에도 다양한 솔루션이 공개돼 보기만 해도 즐겁다.

    AWS 솔루션 설치


    AWS 분산 하중 테스트 환경


    AWS 분산 하중 테스트


    위에서 링크된 대상의 AWS 솔루션을 실행하면 다음 리소스가 AWS 환경에서 만들어집니다.

    상세한 상황은 링크의 개요를 참조하여 아래와 같이 요약해 주십시오
  • AWS Amplify를 사용하여 로드 테스트를 수행하는 인터페이스의 프런트엔드를 작성하여 디버깅합니다.
  • 설계된 웹 사이트에서 부하 테스트 방안을 설정하고 Taurus라는 부하 테스트 자동화 프레임워크의 Docker 이미지를 바탕으로 ECS Task를 시작하여 방안에 따라 부하 테스트를 실시한다.
  • Taurus를 사용하기 때문에 JMeter와 Gatling 등 테스트 도구도 지원한다.
  • 단순히 디자인만 하면 가틀링이 실행 가능한 상태가 아니어서 조금 맞춤형으로 만들어야 한다.JMeter 시험은 문제 없이 실시된 것 같다.

    부하 테스트 환경의 구축


    환경 생성에 대한 개요 페이지에는 CloudFormation의 스택을 만드는 링크가 있습니다.
    어느 정도 익숙해진 사람은 정말 몇 번을 클릭해 환경을 완성할 수 있다는 얘기다.
    요약 페이지 오른쪽에 있는 AWS 콘솔에서 시작 버튼.

    필요한 항목을 설정하고 구축을 시작한 지 5분 정도 지나면 완성되며 곧 부하 테스트를 실시할 수 있는 상태입니다. 그러면 부하 테스트를 실시하는 데 문제가 있습니다.
    어쨌든 이번에 부하를 가하고 싶은 대상의 환경은 현재 절찬 개발 중이며 폐쇄된 환경에서 가동되고 있기 때문에 부하 테스트 환경의 방문은 거절당했다
    이 객체의 환경에 액세스하려면 연결 소스의 IP를 고정해야 합니다. 따라서 로드 테스트 환경에서 오는 통신의 송신 소스를 로드 테스트 환경에서 액세스하도록 수정합니다.

    고정 보낸 사람 IP


    부하 테스트 솔루션 중 VPC 내에 2개의 공개 네트워크를 만들어 그 네트워크에 컨테이너를 가동해 통신한다.
    따라서 VPC 내에 새 NAT 게이트웨이의 네트워크를 만들고 NAT 게이트웨이를 통해 통신할 수 있도록 공개된 네트워크의 로드맵을 변경합니다.NAT 게이트웨이 생성은 다음 템플릿을 사용합니다.
    AWSTemplateFormatVersion: "2010-09-09"
    Description:
      NAT Gateway Create
    
    Parameters:
      VpcId:
        Type: String
      InternetGatewayId:
        Type: String
      PublicSubnetCIDR:
        Type: String
        Default: 192.168.32.0/20
    
    Resources:
    
      Subnet:
        Type: "AWS::EC2::Subnet"
        Properties:
          CidrBlock: !Ref PublicSubnetCIDR
          AvailabilityZone:
            !Select
              - 0
              - !GetAZs
          VpcId: !Ref VpcId
    
      NatGwRouteTable:
        Type: AWS::EC2::RouteTable
        Properties:
          VpcId: !Ref VpcId
    
      RouteToInterne:
        Type: AWS::EC2::Route
        Properties:
          DestinationCidrBlock: 0.0.0.0/0
          RouteTableId: !Ref NatGwRouteTable
          GatewayId: !Ref InternetGatewayId
    
      RouteTableAssociation:
        Type: AWS::EC2::SubnetRouteTableAssociation
        Properties:
          RouteTableId: !Ref NatGwRouteTable
          SubnetId: !Ref Subnet
    
      NATGatewayEIP:
        Type: "AWS::EC2::EIP"
        Properties:
          Domain: vpc
    
      NATGateway:
        Type: "AWS::EC2::NatGateway"
        Properties:
          AllocationId: !GetAtt NATGatewayEIP.AllocationId
          SubnetId: !Ref Subnet
          Tags:
            - Key: Name
              Value: stress-test-natgw
    
    매개변수는 이전에 생성된 로드 테스트 환경 값을 참조하여 설정합니다.
  • VpcId
  • 로드 테스트 환경을 위한 VPC
  • 지정
  • InternetGatewayId
  • 부하 테스트 환경을 만들 때 설치된 인터넷 스위치를 지정
  • PublicSubnetCIDR
  • 부하 테스트 환경에서 제작된 서브넷 CIDR와 다른 내용을 지정합니다.분포식 부하 테스트 환경을 만들 때 기본 상태를 유지하면 이쪽도 변경하지 않을 수 있습니다.
  • 이러한 리소스를 제작한 후 로드 테스트 솔루션으로 작성된 공개망의 로드맵에서 인터넷 게이트웨이로 향하는 통신을 NAT 게이트웨이로 향하면 공개망에서 NAT 게이트웨이를 통한 내부 네트워크로 간단히 변경할 수 있다.
    예제
    수정 전

    수정 후

    지금은 비공개 환경에 대한 부하 테스트를 진행할 준비가 되어 있다.

    간단한 부하 테스트


    바로 브라우저에서 간단한 부하 테스트를 진행합니다.

    특정 URL의 경우 1분입니다.이것은 GET 요청을 수행하는 하중 테스트입니다.
    Test Type은 Single HTTP Endioponint 외에도 jmx 파일을 업로드할 수 있습니다.
    위의 그림은 새로운 테스트 화면으로 SUBMIT를 진행하면 자동으로 테스트를 시작합니다.
    지정된 시간 부하 테스트를 실시하면 합계 결과가 나타난다.

    구역별 표시와 연결 시간 등을 나누어 효과가 좋다.
    중간에 지나가는 걸 보고 싶으면 양도도 클라우드워치로 보내요.
    테스트의 화면 링크에서 CloudWatch 대시보드를 열 수 있습니다.

    실제로 사용해서 생각나는 일.Tips

  • 작업 수 100, 무게 200 이상의 하중을 가할 때
  • 여러 개의 분산 부하 해결 방안을 병행 제작하는 것이 좋을 것 같다
  • 하지만 Fargate ECS Task의 부팅 API는 제한적이며 동시에 테스트를 실시하는 경우 처음 실행된 테스트의 Task가 완전히 부팅되지 않으면 실패합니다.
  • 이 방면의 제약 때문에 정부는 1회 테스트의 시작만 지원할 수 있다.
  • 문서 제약 조건 하에서 연속 테스트 시간은 4시간으로 표시되지만 사실상 상한이 없을 수 있습니다
  • 1440분 정도 이동이 가능합니다.
  • Gatling은 기본적으로 사용할 수 없습니다.
  • 소개 영상에는 비교적 당당하게 사용된 발언이 나와 조금 실망했다.노력하면 할 수 있을 것 같아서요.
  • 시작된 Taurus 컨테이너의 리소스를 변경하려는 경우
  • 해당 Task definition을 업데이트하고 Lambda의 환경 변수를 변경하면 됩니다.
  • 총결산


    미리 준비한 클라우드 포메이션 템플릿에서 환경을 만들 수 있어 테스트의 구현 환경으로 만들기 쉽고 삭제 환경도 간단하기 때문에 필요할 때만 환경을 만들고 필요하지 않으면 쉽게 삭제할 수 있어 편리하다.
    JMeter 시나리오를 활용하려면 jmx 자산도 발휘 & 축적할 수 있기 때문에 사용법을 꼭 연구해 주세요.
    그럼 여러분.새해 복 많이 받으세요.

    좋은 웹페이지 즐겨찾기