💡
이전의 trail - watch 관련 실습을 참고

1. Athena란?

💡
athena는 표준 s3를 사용하여 직접 데이터를 쉽게 분석할수 있는 대화형 쿼리 서비스입니다. 표준 SQL를 사용하여 임시 쿼리를 실행 → 몇초안의 결과를 얻을수 있습니다. ahtena는 서버리스 서비스이므로 설정하거나 관리할 인프라가 필요없다.또한, ETL(Extraction,Transformation,Loading)의 번거로움을 Athena가 내부에서 해결해줍니다.

 

2. 실습

    아키텍처

     

    trail 로그

    이전의 trail 에서 생성한 추적은 식별하기에 있어 불편함이 존재하여 특정 쿼리들을 이용해서 편리하게 보고자 하는 열을 나열할수도 있으며 해당 로그들을 분석해보자!

    1. Athena 테이블 생성

      → 해당 테이블생성시 trail 에 대한 정보를 나타내 준다.

      → 또한 이전의 추적으로 생성한 버킷을 지정한다 (해당 버킷에 존재하는 로그를 대상으로 쿼리를 진행하기때문이다.)

      CREATE EXTERNAL TABLE cloudtrail_logs_aws_cloudtrail_logs_186086016278_655f63bf (
          eventVersion STRING,
          userIdentity STRUCT<
              type: STRING,
              principalId: STRING,
              arn: STRING,
              accountId: STRING,
              invokedBy: STRING,
              accessKeyId: STRING,
              userName: STRING,
              sessionContext: STRUCT<
                  attributes: STRUCT<
                      mfaAuthenticated: STRING,
                      creationDate: STRING>,
                  sessionIssuer: STRUCT<
                      type: STRING,
                      principalId: STRING,
                      arn: STRING,
                      accountId: STRING,
                      userName: STRING>>>,
          eventTime STRING,
          eventSource STRING,
          eventName STRING,
          awsRegion STRING,
          sourceIpAddress STRING,
          userAgent STRING,
          errorCode STRING,
          errorMessage STRING,
          requestParameters STRING,
          responseElements STRING,
          additionalEventData STRING,
          requestId STRING,
          eventId STRING,
          resources ARRAY<STRUCT<
              arn: STRING,
              accountId: STRING,
              type: STRING>>,
          eventType STRING,
          apiVersion STRING,
          readOnly STRING,
          recipientAccountId STRING,
          serviceEventDetails STRING,
          sharedEventID STRING,
          vpcEndpointId STRING
      )
      COMMENT 'CloudTrail table for aws-cloudtrail-logs-186086016278-655f63bf bucket'
      ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
      STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
      OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
      LOCATION 's3://CloudTrail_bucket_name/AWSLogs/Account_ID/CloudTrail/';
      TBLPROPERTIES ('classification'='cloudtrail');

      → 다음처럼 쿼리형식을 확인 가능

    1. 테이블 생성 확인
    1. 간단하게 event name을 select 쿼리
    1. 서울 리전에서만 발생한 이벤트 확인
    1. 실행 중인 인스턴스 확인

       

     

     

     

    vpc Flow log
    1. S3 버킷에 flow log 전송(log를 받을 버킷 생성)
    1. 버킷 -> 속성 -> arn 리소스 이름 복사
    1. Flow log 생성
        생성 과정
        1. 생성 화면
        1. 대상 필터링 적용
        1. 복사한 s3 버킷의 arn 지정후 생성

          → Log 레코드 포멧은 default 값으로 진행 ( custom으로도 가능)

        1. 생성 확인

          → 해당 vpc 의 플로우 로그 창에서 확인 가능

          -	필터 : 로깅할 트래픽의 유형입니다. 
           총 3가지로 구성되며, 수락된 트래픽만 기록하려면 ‘적용’ 거부된 트래픽만 기록하려면
           ‘거부’ 수락 및 거부된 트래픽을 확인하려면 ‘모두’를 선택할 수 있습니다.
          -	최대 집계 간격 : 기본 10분 단위 수집 -> 테스트를 위해 (1분 단위로 진행)
          -	대상 : VPC flow log에 대한 로그 기록을 CloudWatch or s3 에 저장할 수 있습니다.
          -	IAM 역할 : CloudWatch 에 로그를 기록할 시 해당 역할을 부여해 주어야 합니다.
          -	레코드 형식: AWS에서 제공해주는 default 형식 or 
          							사용자 지정 형식을 선택할 수 있습니다.
          -	S3 버킷 ARN : 생성한 S3 버킷에 대한 ARN값을 지정 할 수 있습니다.

         

    1. Athena database 생성

      → DDL 문을 이용하여 DB 생성 또는 default DB에서 테이블 생성해도된다

    1. Athena table 생성

      참조 : https://docs.aws.amazon.com/ko_kr/athena/latest/ug/vpc-flow-logs.html

      CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
        version int,
        account string,
        interfaceid string,
        sourceaddress string,
        destinationaddress string,
        sourceport int,
        destinationport int,
        protocol int,
        numpackets int,
        numbytes bigint,
        starttime int,
        endtime int,
        action string,
        logstatus string
      )
      PARTITIONED BY (`date` date)
      ROW FORMAT DELIMITED
      FIELDS TERMINATED BY ' '
      LOCATION 's3://your_log_bucket/prefix/AWSLogs//vpcflowlogs//'
      TBLPROPERTIES ("skip.header.line.count"="1");
      -> 파티셔닝을 통하여 쿼리를 최적화 할수있다. 그렇지 않으면 모든 데이터를 불러와야한다.
    1. 동작 확인을 위한 ec2 생성
    1. 쿼리 테스트 진행

     

    ALB log
    1. 테스트 진행 할 ALB 생성
    1. 대상 그룹 인스턴스 아무거나 등록
    1. 버킷 정책 생성

      참조 : https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/classic/enable-access-logs.html

      ALB에 s3 버킷을 사용할 role을 부여 할수 없기에 정책을 이용하여 설정

      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "AWS": "arn:aws:iam::elb-account-id:root"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
          },
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*",
            "Condition": {
              "StringEquals": {
                "s3:x-amz-acl": "bucket-owner-full-control"
              }
            }
          },
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::bucket-name"
          }
        ]
      }
      버킷 경로 설정시 본인이 생성할 위치에 맞춰서 진행 해야함

      → 정책 생성기를 통하여 버킷 정책 생성

    1. alb 액세스 로그 활성화

      → ELB 는 5분마다 로그를 게시함

      주의사항!! : 버킷위치를 버킷 정책에서 지정한 버킷 위치와 동일해야함

      로그에 남는 기록

      • 트래픽 요청 받은 시간
      • 클라이언트 ip 주소
      • 지연 시간
      • 요청 경로 및 서버 응답등의 정보
    1. s3 버킷 테스트 파일 생성 확인

      → 다음과 같이 access log 활성화를 확인가능합니다.

    1. 로드밸런서 테스트
    1. athena -DB 생성

      테이블 생성시 참조

      https://docs.aws.amazon.com/ko_kr/athena/latest/ug/application-load-balancer-logs.html

    1. 쿼리 테스트
      1. 타겟 인스턴스로 트래픽이 전달 되는지 확인

      2. 요청 client ip 확인

      → 로컬에서 ping 테스트후 인터넷에서 내 ip 주소 확인후 검색 결과 해당 로컬 pc에서 도메인 접속한 이력 확인

       

       

     

    QuickSight
    1. 생성하기

      60일동안은 무료로 사용가능 standard 는 그이후 월 12달러

    1. 설정

      → Athena를 활용

    1. 데이터 세트

      → 여러가지 서비스 및 직접 데이터를 업로드도 가능

    1. athena 연결
    1. 테이블 선택
    1. 데이터 직접 쿼리로 생성

      만약 작업이 안될시에 보안 및 권한에서 s3를 추가해야함

       

    1. quicksight 확인

      필드에서 여러 값을 가져오면된다.

      → request당 client와 target ip 에 대한 통계값 확인

 

3. 결론

Athena를 통해서 aws 서비스중에 몇 가지만 추려서 log를 분석해 보며 특정값들을 불러올수 있었다.

추가적으로 athena의 테이블을 특정 파티셔닝을 지정하여 로그를 손쉽고 빠르게 불러오도록 설정하며 로그 데이터가 많을시 유용하게 사용된다.

또한, 적재된 s3 버킷에 존재하는 로그를 athena를 이용하여 필터링을 하며 최종으로 Quicksight를 이용해 시각화 하는 작업까지 해보았다. Quicksight에 대해서는 추가적으로 확인이 필요할듯하다.

'Management & Governance' 카테고리의 다른 글

CloudTrail 로그 확인  (0) 2021.02.26

1. CloudTrail이란?

💡
기본적으로 aws 계정 내에서 일어나는 모든 API를 통하여 계정 활동에 관련 작업을 기록하며 지속적으로 모니터링 하며 보관할수있습니다. Console , AWS SDK, 명령줄 기타 AWS서비스를 통해 수행된 작업을 비롯하여 이벤트 기록을 제공합니다. 또한, 이벤트 기록에서 여러가지 필터링을 이용하여 확인이 가능합니다.
!!!!기본적으로 Trail은 API 호출후 평균 약 15분 이내에 로그를 전송한다.

참고 문헌 : https://aws.amazon.com/ko/cloudtrail/features/
개념정리
  1. Cloud Trail은 모든 AWS 계정에서 계정 생성시 활동을 기록 수동으로 설정할 필요 없이 지원되는 서비스의 생성, 수정 및 삭제 작업을 위해 90일동안의 활동 기록
  1. 이벤트 필터링 가능 계정 활동을 보고 검색 및 다운로드 가능 → 리소스 변경에 대한 가시성 확보
  1. s3 서버측 암호화 SES를 사용하여 로그 암호화 가능 → KMS로도 가능하다.
  1. 이벤트 종류
    1. 관리 이벤트 aws 계정 리소스에서 수행되는 관리 작업등
      ex ) ec2 생성 , 삭제 , 수정등의 작업 기록 → aws 계정 ,iam역할,작업한 ip,시간,리소스등의 정보 확인 가능
    1. 데이터 이벤트 리소스 자체 or 리소스 내에서 수행되는 서비스 → 대량 활동
      • Amazon S3 객체 수준 API 활동(예: GetObject, DeleteObject 및 PutObject API 작업)
      • AWS Lambda 함수 실행 활동(Invoke API)
      !! 추적을 생성 할 때 데이터 이벤트는 기록되지 않음 → 설정 시 추가 요금
    1. Cloud Trail Insights
      • 리소스 프로비저닝 급증
      • IAM 작업의 급증 또는 주기적 유지 관리 활동 격차같은 aws계정의 비정상적 활동 식별
  1. 통합되는 서비스
    1. Lambda
      • s3 버킷 알림 기능을 활용하여 s3객체 생성 이벤트를 lambda에 게시가능
      • trail 에서 s3 버킷에 로그를 쓸때 lambda를 호출하여 처리
    1. cloudwatch logs
      • trail에서 기록 관리 및 데이터 이벤트를 cloudwatch logs로 보낼수있다.
      • 지표 필터 생성하여 이벤트,검색 이벤트를 모니터링가능
      • lambda 및 elastisearch 같은 다른 aws로 스트리밍가능
    1. cloudwatch 이벤트
      • 리소스 변경 사항에 자동 대응가능
      • trail 에서 특정 이벤트를 기록할시 실행 작업 정의 가능
      •   ex) cloudtrail 새 수신 규칙 추가와 같이 ec2 보안 그룹에 대한 변경 사항 기록시 lambda함수로 보내는 event 규칙을 생성가능

2. 실습

이벤트 로그 확인
  1. 콘솔을 통하여 trail 접속
  1. 이벤트 기록을 통하여 로그 확인
    → 기본적인 API활동에 의하여 활동 작업이 로그가 남는다.
이벤트 필터링
  1. 필터링은 시간 및 여러 이벤트 패턴에 따라서 사용자가 조회 가능  
  1. 이벤트 이름으로 필터링 api test를 위해 미리 인스턴스를 생성해둠
    → 인스턴스 생성된것을 확인하고자 검색 결과 나타나지않음 → 다른 이벤트 이름으로 검색해보자!
    → 이전의 auto-scaling 으로 생성된 인스턴스부터 시간및 리소스 유형등을 확인 가능 해당 이벤트에 대하여 자세히 알고자 이벤트 정보 확인
  1. 이벤트 상세 정보 확인
    → 해당 이벤트에 대한 자세한 정보들을 확인 가능하다. 또한, 참조 리소스 까지 같이 확인 가능
  1. 제공되는 cloudtrail 열 리스트
  1. 시간 필터링
    → 특정 시간대를 지정하거나 start-end 시간을 지정도 가능하다.  
S3 - Trail 추적 기존 방식처럼 Trail로만 로그를 보는 데는 90일이라는 기간이 정해져 있기 때문에 이전의 데이터도 확인을 하고 싶을 시 S3버킷을 이용하는 방법이 있다.
  1. 추적 생성
    → 로그 파일을 보호하기 위해서 KMS를 사용가능.(실습이기에 모든것을 비활성화) → 또 앞서 개념 정리를 하면서 연동 가능한 서비스 중 watch logs를 이용할수도있다.
  1. 이벤트 선택
    → kms 이벤트는 제외 모든 api활동 (이벤트는 관리 이벤트만 나머지는 추가비용)
  1. 생성 진행
    → 이전의 추적을 생성해뒀으므로 따로 생성을 하진 않았다.
  1. 버킷 생성 확인
    → 다중 리전 추적 기능을 제공하므로 모든 리전의 정보가 나타난다. 따라서, 본인이 해당하는 리전에 대해서 로그 정보를 확인하면 된다.
  1. 로그 확인
    → 해당 로그들이 생성됨을 확인했다. (해당 날짜에 대해서 나타나며 시간별로 확인가능 하지만, 다소 UI가 떨어져서 식별하기가 어렵다... 확인해야 하는 번거로움 존재
    → 해당 객체의 URL을 통하여 접속한 결과 아찔하다....  
athena를 이용한 s3 로그 분석 이전의 trail 에서 생성한 추적은 식별하기에 있어 불편함이 존재하여 특정 쿼리들을 이용해서 편리하게 보고자 하는 열을 나열할수도 있으며 해당 로그들을 분석해보자!
  1. Athena 테이블 생성
    → 해당 테이블생성시 trail 에 대한 정보를 나타내 준다. → 또한 이전의 추적으로 생성한 버킷을 지정한다 (해당 버킷에 존재하는 로그를 대상으로 쿼리를 진행하기때문이다.)
    CREATE EXTERNAL TABLE cloudtrail_logs_aws_cloudtrail_logs_186086016278_655f63bf ( eventVersion STRING, userIdentity STRUCT< type: STRING, principalId: STRING, arn: STRING, accountId: STRING, invokedBy: STRING, accessKeyId: STRING, userName: STRING, sessionContext: STRUCT< attributes: STRUCT< mfaAuthenticated: STRING, creationDate: STRING>, sessionIssuer: STRUCT< type: STRING, principalId: STRING, arn: STRING, accountId: STRING, userName: STRING>>>, eventTime STRING, eventSource STRING, eventName STRING, awsRegion STRING, sourceIpAddress STRING, userAgent STRING, errorCode STRING, errorMessage STRING, requestParameters STRING, responseElements STRING, additionalEventData STRING, requestId STRING, eventId STRING, resources ARRAY<STRUCT< arn: STRING, accountId: STRING, type: STRING>>, eventType STRING, apiVersion STRING, readOnly STRING, recipientAccountId STRING, serviceEventDetails STRING, sharedEventID STRING, vpcEndpointId STRING ) COMMENT 'CloudTrail table for aws-cloudtrail-logs-186086016278-655f63bf bucket' ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde' STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://CloudTrail_bucket_name/AWSLogs/Account_ID/CloudTrail/'; TBLPROPERTIES ('classification'='cloudtrail');
    → 다음처럼 쿼리형식을 확인 가능
  1. 테이블 생성 확인
  1. 간단하게 event name을 select 쿼리
  1. 서울 리전에서만 발생한 이벤트 확인
  1. 실행 중인 인스턴스 확인
AWS CLI를 통한 확인 CLI는 홈페이지에서 설치가능 https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/install-cliv2-windows.html
→ AWS Cli 설치
https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/view-cloudtrail-events-cli.html - 명령들 참조 가능
aws cloudtrail lookup-event help - > 이벤트에 대한 명령줄 도움받기 aws cloudtrail lookup-event --max-results 1 (default 10 1~50까지 가능) aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances -> 인스턴스 구동된 이벤트 기록 (이벤트 이름으로 조회) aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=ec2.amazonaws.com -> EventSource 조회 aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::S3::Bucket -> 리소스 유형
  • 최신 이벤트 기록 1개 조회
  • 구동한 인스턴스 이력
CloudWatch logs 및 insight 이용
    cloudwatch logs
    1. cloud trail 표적을 생성시 s3 버킷 이외에도 cloudwatch로 로그그룹 생성가능
    1. cloudwatch 로그그룹 - 로그 스트림
      → 세부 정보는 해당 스트림을 확인
    1. 로그 이벤트 필터링 패턴
      → 삭제된 인스턴스 조회시 나타남
    cloudwatch insight이용하여 query

    샘플쿼리 : https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html

    단일 요청은 최대 20개의 로그그룹 쿼리 가능 쿼리가 완료되지 않은 경우 15분 후에 쿼리가 시간 초과됩니다. 쿼리 결과는 7일 동안 사용할 수 있습니다.
    1. 로그 그룹 선택
    1. 필터링

      → 원하는 패턴으로 필터링이 가능하다.

    1. 쿼리 조합시
      stats count(*) by eventSource, eventName, awsRegion -> 서비스 ,이벤트 이름 ,리전등의 갯수 |filter eventName="TerminateInstances" -> 파이프라인으로 종료된 인스턴스 조회 

       

3.결론

Trail을 이용하여 AWS계정 내에서 일어나는 모든 이벤트에 대한 로그를 자동으로 남아 지기 때문에
90일간의 기록이 지난 데이터들도 S3 를 이용하여 장기간의 데이터를 보관 할 수 있어 상당히 유용하게 사용 할 수 있는 서비스인 것 같다.
또한, s3 버킷으로 지난 로그들을 분석하기에는 불편함이 존재하여 Athena를 이용한다면 특정 쿼리문을 이용하여 테이블에 나타난 colume 명을 이용하여 필터를 할수있다.

 

'Management & Governance' 카테고리의 다른 글

athena log query  (0) 2021.03.08

        이전 포스팅 : route53 도메인 연결

💡
위의 내용을 기반으로 해당 도메인을 통하여 ALB의 https 접속 테스트 진행

 

<목차>

  1. 네트워크 구성
    • 네트워크 구성

      → vpc는 기본 vpc를 이용하여 실습을 진행

      • dns 활성화

      → dns 활성화 확인

      • 사용할 서브넷의 퍼블릭 ip 활성화
      • 라우팅 연결

       

  1. 서버 생성
    • 인스턴스 생성

      기본 amazon-linux2 사용

      • 보안 그룹 생성
      • 사용자 데이터 추가
      • 서버 생성

        → pem키는 사용자가 임의대로 정해서 사용하면된다.

        #!/bin/bash sudo yum -y install httpd sudo systemctl enable httpd sudo systemctl restart httpd sudo echo "<html><body><font color=blue>ALB acm test-webserver1</font></body></html> > /var/www/html/index.html
  1. 웹서버 접속확인
    • 웹서버 접속 테스트

      또는 공인 ip로 접속을 한다.

      구매한 도메인으로의 접속

       

  1. LB생성
    • 로드밸런서 생성

      로드밸런서 → alb 생성 → https,http 보안그룹 생성 → 대상 그룹생성

      • 기존의 만들어진 인스턴스의 ami를 생성하여 하나더 인스턴스 생성
      • 생성 확인
      • 웹 접속
      • 대상그룹 등록
      • 상태 검사

        → 로드밸런싱 확인

  1. alb - acm생성
    💡
    acm 인증서를 cloudfront 배포에 연결할시 미국 버지니아 북부 리전에서만 인증서를 가져오거나 생성해야합니다. [참고 https://aws.amazon.com/ko/premiumsupport/knowledge-center/migrate-ssl-cert-us-east/]
    • 인증서 갱싱

      acm 발급은 도메인으로 인증 하는법과 메일로 인증하는법이 존재

      도메인이 있으니 , 보유한 도메인으로 인증하자

      DNS 네임서버에서 CNAME으로 설정해줘야함

      → 하나 이상의 호스트를 사용할경우 *를 사용하여 인증받는다.

       

      → 해당 검증파일을 다운받은후 route53에서 CNAME 을 등록

      💡
      위와 같이 *.hyup.shop으로 등록시 *로 인해 하위 도메인들이 모두 사용가능하다. 예를들어, (test.hyup.shop, aaa.hyup.shop 등등이 존재) 하지만, hyup.shop에서는 사용이 불가하기떄문에 (hyup.shop 과 *.hyup.shop을 동시사용)

       

      주의사항!! Record Name 사용시 뒤에 .hyup.shop부분을 제거 해야한다.

      → 각각 Name 과 value값을 기입해준다.

      → 정상 등록시 다음과 같이 발급이 완료된다.

  1. LB환경 → route53연동 접속 
    • 해당 로드밸런서를 Alias설정

      → 연동후 로드밸런싱 동작 하지만, https 인증이 안되어있으므로 이전의 생성한 acm을 이용하여 리스너 규칙을 추가해보자!

       

  1. https접속 확인
    • lb https 설정

      alb에 리스너 규칙 추가

      → https로 보안접속 확인이 되었다.

       

        이전 포스팅:alb 리스너 규칙이용 

💡
이전의 리스너 규칙 실습에서는 hosts파일로 임의로 변경했지만 현재 실제 도메인을 구입하여 실습을 진행하였으므로 이전 실습을 추가적으로 활용이 가능하다. 도메인을 구입한 분은 리스너 규칙을 이용하여 라우팅을 해보는것도 추천드린다.

 

 

 

'aws' 카테고리의 다른 글

Elastisearch 를 사용 VPC FLOWLOGS  (0) 2021.03.29
CloudWatch / SSM Agent  (0) 2021.03.29
route 53 도메인 연결  (0) 2021.02.09
RDS-multi AZ/RR 구성 실습  (0) 2021.02.03
site-to-site vpn구축(openswan)  (0) 2021.01.20

Route 53이란?

💡
Amazon route53은 가용성과 확장성이 우수한 도메인 이름 시스템(DNS), 도메인 이름 등록, 상태 확인 웹 서비스입니다. 이 서비스는 최종 사용자를 인터넷 애플리케이션으로 라우팅할 수 있는 매우 안정적이고 비용 효율적인 방법을 개발자와 기업에 제공하기 위해 설계되었습니다.예를 들어, www.example과 같이 사람이 읽을 수 있는 이름을 컴퓨터가 서로 연결하는데 사용하는 192.0.2.1과 같은 숫자 ip 주소로 변환하는 글로벌 배포 서비스입니다. [출처 https://aws.amazon.com/ko/route53/faqs/]

Route53 생성

  1. route 53 접속
    호스팅 영역 생성

    가비아에서 구매한 도메인 이름을 기입

    → ns 와 soa 레코드 생성 해당 정보를 가비아에 기입
  1. 도메인 연동
    가비아 ns 등록

     

  1. 생성후 간단한 연동 테스트
    인스턴스 생성

    퍼블릭 ip를 달고있는 인스턴스 한개를 생성해보기

    웹서버를 구현하기 위한 간단한 user-data를ㄹ 추가한 webserver 생성

    보안그룹 - 인바운드 80 22 허용

    → 웹 페이지 접속

    레코드 생성

    → 인스턴스의 EIP를 이용하여 mapping 한다.

  1. 연동후 테스트

     

'aws' 카테고리의 다른 글

Elastisearch 를 사용 VPC FLOWLOGS  (0) 2021.03.29
CloudWatch / SSM Agent  (0) 2021.03.29
lb -acm 인증서를 이용한 접속  (0) 2021.02.09
RDS-multi AZ/RR 구성 실습  (0) 2021.02.03
site-to-site vpn구축(openswan)  (0) 2021.01.20

사전구성

접속툴 : mysql workbench ,aws 계정

  1. 서브넷 그룹 생성

    Multi-AZ : 각 zone이 전용선으로 연결되어 있어 네트워크 성능의 신뢰가 보장되어 메인 인스턴스에 적용한 데이터가 바로 동기화된다.(RDS의 HA를 위한 방법) → active-standby가 한쌍인 사이클을 가짐

    • multi az 를 활성화 하기 앞서 서브넷 그룹의 해당 가용영역을 지정

      >> 이름 및 vpc선택후 본인의 DB가 생성될 환경의 서브넷을 지정

    • 생성 확인
  1. DB 생성
    • aws console → RDS → 생성

    • 엔진 선택

    • 버전 및 사용자의 요구사항의 맞도록

    • DB 사용자및 암호생성

    • db인스턴스 크기

    • multi az 활성화

      >> 실제 콘솔상에서는 나타나지 않지만 다른 가용영역에서 대기

    • 연결을 위한 설정진행

      >> 퍼블릭 액세스 기능을 활성화 함으로써 원격으로 db접속을 허용함

      >> 해당 파라미터 그룹에 맞게끔 설정(log를 확인하고 싶을시 파라미터생성후연동)

      >>암호화 및 Performance Insights를 활성화 (성능 개선 도우미 같은경우는 db를 운영하면

      생기는 부하등을 확인하기 위함)

      >> 기타 세부사항은 선택적으로 하면된다.

    • 추가적인 부분

      qurey문을 사용할시에 해당 query문을 확인하기 위해 general 로그를 파라미터 그룹에 생성

      >> db엔진에 맞게끔 설정

    • DB 생성

      multi -AZ 로 생성된 DB는 active db만 나타나며 실제 standby 인스턴스는 대기 상태로

      다른 가용영역에 나타나 있다.

      >> multi az 가 활성화가 되어있는지만 알수있다.

    • 접속 테스트

      >> 해당 DB의 엔드포인트를 사용하여 접속

    • 로그 확인을 위한 파라미터 편집

      long_query_time = 2 (2초 사용자 편의) - 안해도됨

      general_log = 1 ( true)

      slow_query_log =1 (true)

      log_output = file,table,none (선택)

      >> 쿼리시 해당 시점의 시간으로 로그생성

      >> 동일하게 실시간으로 해당 DB의 로그가 남는것을 확인할수있다.

  1. multi -AZ 테스트

    aurora와 달리 RDS는 인스턴스를 지우면 failover 되는 것 이 아니다.

    >> RDS multi-AZ failover

    >> failover테스트가 동작했을시 이벤트로그상에서 대략 30~40초가량이 소요됨을확인

    >> 계획 되거나 계획되지 않은 중단이 발생시 자동으로 가용영역에 있는 예비 복제본으로 전환된다.(시간은 일반적으로 60~120초소요 → 규모에 따라 상이함)

    >> 다음과 같은경우에 failover가 이뤄진다.

    >> 가용 영역이 변경됨을 확인했다(자동으로 동작 하는 것은 테스트 상 진행이 불가 하여 수동으

    로 확인 결과 정상 작동임을 확인)

    >> 데이터 동기화 확인

    >> 다만 master 에서 만 모든 작업을 처리하게 되므로 DB의 부하를 고려 해야 할 수 있다.

    >> aurora는 읽기 복제 본 을 가지고 failover 처리(이점 : 항상 active-active 로 동작하기에 분산

    이 가능하여 cluster DB구성으로 모든 DB가 cluster volume 가르키고 있어 지연 시간도 최소화 할 수 있습니다. 비용만 감안한다면 훨씬 좋다고 생각된다..)

  1. Read Replica테스트

    multi-AZ : 동기식 복제 active의 db의 정보의 일어난 작업 이후 뒷 단 slave쪽 까지

    동기화 작업이 이루어진 후 정합성 이 완료 되는 방식 → 고가 용 성

    read Replica : 비동기 식 복제 master의 정보 만 가지고 read db 정보까지는 작업을 처리 하지 않는 상태 → 분산 하여 master의 정보를 읽어 들이는 역할

    • 기본 master db 생성 → 읽기 복제 본 생성

      >> 복제 본 생성 소요 시간은 약 3 분 가량 소요된다. (복제본 생성과 동시에 원본 스냅샷을 가지고 동일한 스펙으로 생성)

      >> 완벽하게 완료되기까지는 10분 의 시간이 소요된다.(slave 에서 의 작업)

    • read replica 생성 과정
      1. 복제본 생성시 RDS의 원본 DB인스턴스의 스냅샷을 캡처하여 복제시작
      1. DB 스냅샷 캡처기간동안 원본 DB 인스턴스에서 짧은 I/O발생 → 1분정도
      1. 위의 경우를 방지하고자 원본 DB인스턴스를 다중 AZ로 한다→ 보조 인스턴스에서 스냅샷을 생성하기 때문.
      1. 다수의 복제본이 하나의 원본을 가지고 병렬 작업시 → 첫번째 생성시에만 스냅샷캡처
    • replica 생성시 고려 사항
      1. 백업 보존 기간을 0이 아닌 다른 값으로 설정하여 원본 DB 자동백업 활성화
      1. 자동 백업은 mysql 5.6이상을 실행하는 복제 본에서만 지원

    • slave로 wirte 작업 시
    • slave db엔진 변경

      데이터는 동기화가 이루어진 slave지만 db 엔진을 변경했을시는 독립적으로 움직인다.

      >> 여기서 master의 엔진을 변경할시 기존 slave엔진들이 변경하려는 버전보다 낮을시 변경

      이 되지 않으므로 해당 slave엔진은 항상 master보다 같거나 높은상태여야 변경이가능.

      >> slave 인스턴스의 버전 변경확인 나머지는 기존대로 .22를 운영

    • slave 승격

      재해 복구 구현 기본 DB 인스턴스가 실패할 경우 재해 복구 솔루션으로 읽기 전용 복제본을 독립형 인스턴스로 승격할수 있다. → 다만, multi-az나 aurora보단 자동으로 failover처리가 아닌 수동으로 해야하는 불편함이 존재....

      • 승격 이유
        1. DDL 작업실행 (mysql , mariad db 한정)
          • 인덱스 생성 및 리빌드 등의 DDL작업은 시간 및 성능 저하 초래
        1. 샤딩 - 무공유 아키텍처를 구현함으로써 기본적으로 대규모 db 에서 다수의 소규모 db로 분할하는 기술
        1. 장애 복구 실행 - 기본 db인스턴스가 장애가 발생할시 복제본을 데이터 복구 체계로 사용. → 동기식 복제, 장애 자동 감지 및 장애 조치 보완

      • 승격을 해주면된다.
      • 기존 읽기 유형의 인스턴스가 기본 master와 동일한 독립 인스턴스로 승격됌
      • 또한, 스냅샷도 독립적으로 한개가 생성이된다.
      • read에서 승격을 실행시킴과 동시에 약간의 재부팅시간이 존재함
      • 데이터 확인

        >혹시나 데이터가 날아갔나 하여 확인결과 정상적으로 남아있다.(master에서 작업시의 데이터가 지속적으로 업데이트 되기때문)

'aws' 카테고리의 다른 글

Elastisearch 를 사용 VPC FLOWLOGS  (0) 2021.03.29
CloudWatch / SSM Agent  (0) 2021.03.29
lb -acm 인증서를 이용한 접속  (0) 2021.02.09
route 53 도메인 연결  (0) 2021.02.09
site-to-site vpn구축(openswan)  (0) 2021.01.20

+ Recent posts