no image
[AWS SAA] 33. AWS Log 서비스
로스 유형 인프라를 구축하면서 로깅을 계획해야 합니다. 다음은 서비스에서 로그를 지원하는 방식입니다. CloudWatch Logs EC2 인스턴스, CloudTrail, Route53 및 기타 소스에서 로그 파일을 모니터링 , 저장 및 액세스합니다. AWS CloudTrail 콘솔, AWS SDK, CLI 및 서비스를 통해 수행된 작업을 비롯하여 계정 활동의 이벤트 기록을 제공합니다. 이러한 이벤트 기록은 보안 분석, 리소스 변경 추적 및 문제 해결을 간소화합니다. CloudTrail은 거버넌스, 규정 준수, 운영 및 위험 감사를 촉진합니다. 이를 사용해 AWS 인프라 전반에서 수행하는 작업과 관련된 계정 활동을 로깅하고 지속적으로 모니터링하는 동시에 보존할 수 있습니다. VPC 흐름 로그 VPC 네트워..
2023.08.28
[AWS SAA] 32. CloudWatch
모니터링하는 이유 환경 모니터링은 아키텍처를 생성할 때 고려해야 할 가장 중요한 요소 중 하나입니다. 리소스 운영 및 작동을 추적할 수 있는 방법이 항상 필요합니다. 다음은 기억해야 할 몇 가지 핵심 사항입니다. 모니터링을 사용하면 리소스 사용률 및 애플리케이션 성능에 대한 정보를 수집합니다. 모니터링 시에는 인프라가 수요를 충족하는지 측정합니다. 그럼 수요 증가 시 확장되고 수요 감소 시 다시 축소되는 아키텍처를 구축하는 데 도움이 됩니다. 이 유형의 크기 조정은 고객에게 더 나은 사용자 경험을 제공하고 비용을 절감합니다. 모니터링은 보안상 중요한 작업입니다. 파라미터를 설정하면 사용자가 환경의 일부에 액세스하는지 여부를 알 수 있고 권한을 확인할 수 있습니다. 모니터링을 수행하는 이유는 다음과 같습니..
2023.08.27
[AWS SAA] 31. Database 마이그레이션
Database Migration Service(DMS) DMS는 원본에서 AWS 클라우드의 대상 DB로 데이터를 복제합니다. 원본 및 대상 연결을 생성하여 데이터를 추출할 원본 위치와 로드할 대상 위치를 AWS DMS에 제공합니다. 그런 다음 이 서버에서 실행되어 데이터를 이동하는 태스크를 예약합니다. 그러면 AWS DMS가 테이블 및 관련 기본 키를 생성합니다(대상이 아직 없는 경우에 해당하며, 이미 존재한다면 해당 대상을 선택할 수도 있습니다). DMS는 가장 광범위하게 사용되는 DB(Oracle, PostgreSQL, MS SQL Server, MariaDB, MySQL) 간 마이그레이션을 지원합니다. 또한 동일한 엔진 및 다른 엔진 간 마이그레이션을 지원합니다. 이 서비스를 사용하여 온프레미스 ..
2023.08.26
[AWS SAA] 30. 캐싱 서비스
ElastiCache ElastiCache는 클라우드에서 분산 인 메모리 데이터 스토어 또는 캐시 환경을 원활하게 설정, 관리 및 확장할 수 있는 웹 서비스 입니다. 이 서비스는 확장 가능하며 비용 효율적인 고성능 캐싱 솔루션을 제공합니다. 또한 분산 캐시 환경 배포 및 관리와 관련된 복잡한 작업도 수행할 필요가 없습니다. ElastiCache는 Redis와 Memcached 두 가지 오픈 소스 인 메모리 엔진을 지원합니다. ElastiCache 엔진 ElastiCache는 위 2가지 오픈 소스 호환 인 메모리 데이터 스토에 대해 완전 관리형 기능을 제공합니다. ElastiCache for Memcached를 사용하여 데이터 집약적 앱에 대한 확장 가능한 캐싱 티어를 구축할 수 있습니다. 1밀리초 미만의..
2023.08.25
no image
[AWS SAA] 29. DB Caching(캐싱)
캐시를 고려해야하는 항목 애플리케이션이 데이터베이스 캐싱을 사용해야 하는지 여부를 결정하기 위해서 다음과 같은 사항을 고려할 수 있습니다. 속도와 비용 기본적으로 속도는 더 느리고 비용은 더 많이 드는 데이터베이스 쿼리가 존재합니다. 예를 들어 여러 테이블에서 조인을 수행하는 쿼리는 단순한 단일 테이블 쿼리보다 훨씬 더 많은 시간과 비용이 듭니다. 요청하는 데이터를 수신하려면 속도가 느리고 비용이 많이 드는 쿼리를 실행해야 하는 경우 해당 데이터를 캐시할 수 있습니다. 데이터 및 액세스 패턴 캐싱할 항목을 결정할 때는 데이터 그 자체와 데이터의 액세스 패턴도 이해해야 합니다. 예를 들어 빠르게 변경되거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없습니다. 캐싱을 통해 유의미한 이점을 얻으려면 소셜 미..
2023.08.25
no image
[AWS SAA] 28. DynamoDB - 2
DynamoDB 테이블 DynamoDB는 데이터를 테이블에 저장합니다. 테이블을 생성할 때 테이블 이름과 파티션 키를 지정해야 합니다. 테이블 생성 시에 필요한 엔터티는 이 두 항목 뿐입니다. DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해 줍니다. 지원되는 기본 키의 2가지 유형은 다음과 같습니다. 단순 기본 키 파티션 키라는 속성 하나만으로 구성된 단순한 기본 키입니다. 파티션 키를 하나만 사용하는 경우 두 항목이 동일한 값을 가질 수 없습니다. 복합 기본 키 복합 기본 키는 파티션 키와 정렬 키로 구성됩니다. 이 경우 여러 항목의 파티션 키 값은 같을 수 있지만 정렬 키 값은 달라야 합니다. 핵심 구성 요소는 테이..
2023.08.24
반응형

로스 유형

인프라를 구축하면서 로깅을 계획해야 합니다. 다음은 서비스에서 로그를 지원하는 방식입니다.

 

  • CloudWatch Logs
    EC2 인스턴스, CloudTrail, Route53 및 기타 소스에서 로그 파일을 모니터링 , 저장 및 액세스합니다.
  • AWS CloudTrail
    콘솔, AWS SDK, CLI 및 서비스를 통해 수행된 작업을 비롯하여 계정 활동의 이벤트 기록을 제공합니다. 이러한 이벤트 기록은 보안 분석, 리소스 변경 추적 및 문제 해결을 간소화합니다. CloudTrail은 거버넌스, 규정 준수, 운영 및 위험 감사를 촉진합니다. 이를 사용해 AWS 인프라 전반에서 수행하는 작업과 관련된 계정 활동을 로깅하고 지속적으로 모니터링하는 동시에 보존할 수 있습니다.
  • VPC 흐름 로그
    VPC 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보가 캡처됩니다.
  • 로드 밸런싱
    로드 밸런서로 전송된 요청에 대한 상세 정보를 캡처하는 액세스 로그를 제공합니다. 애플리케이션에서 사용자 지정 로그를 사용할 수 있습니다.

로깅 및 이벤트 / CloudWatch를 통한 OS 및 APP 로그 파일 저장 및 모니터링

 

CloudWatch Logs 예제

위 예시와 같이 로그 파일 server.log에 데이터를 기록하는 동일한 웹 서버 두 개가 나와 있다고 가정하겠습니다. 서버 하나는 EC2에 있고 다른 하나는 온프레미스의 가상 머신에 있습니다.

 

두 서버는 모두 로그 파일의 이벤트를 로그 스트림에 게시할 수 있습니다. 로그 스트림은 동일한 소스를 공유하는 로그 이벤트 시퀀스입니다. CloudWatch Logs 로그 소스는 각각 별도의 로그 스트림을 구성합니다.

 

여러 로그 스트림을 단일 로그 그룹에 수집할 수 있습니다. 로그 그룹은 모든 스트림에서 동일한 보존 기간, 모니터링, 액세스 제어 설정을 공유합니다. 로그 그룹을 정의하고 각 그룹에 배치할 스트림을 지정할 수 있습니다. 하나의 로그 그룹에 속할 수 있는 로그 스트림의 수는 제한이 없습니다.

 

로그 그룹을 생성한 후에는 지표 필터를 사용하여 로그 이벤트에서 일치하는 단어, 구문 또는 값을 검색할 수 있습니다. 지표 필터가 로그 이벤트에서 단어, 구문 또는 값 중 하나를 찾으면 CloudWatch 지표의 값을 증분할 수 있습니다. 예를 들어 LogFile-ErrorConunt 지표에서 error라는 단어 등의 단일 용어가 나오는 횟수를 계산할 수 있습니다. 또한, 지표를 모니터링하여 경보를 호출할 수도 있습니다.

 

Logs 사용법 / CloudWatch 지표 및 로그 수집법

 

CloudTrail

CloudTrail은 사용자 활동 및 API 사용량을 추적하여 누가 무엇을 언제 헀는가에 대한 인사이트를 제공합니다. CloudTrail을 사용하면 계정의 AWS API 호출 기록을 가져올 수 있습니다. 콘솔, AWS SDK, CLI 및 고급 AWS 서비스를 통해 이러한 호출을 숳애할 수 있습니다. CloudTrail은 AWS API 호출을 기록하고 로그 파일을 제공합니다. 로그 파일에 포함되는 정보는 소스 IP, API 호출자의 ID, 호출 시간, 요청 파리미터, AWS 서비스에서 반환하는 응답 요소 등이 있습니다. 

 

CloudTrail에서 생성하는 AWS API 호출 기록을 활용하여 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다.

 

Cloud Trail은 리전 단위로 활성화됩니다. 여러 리전을 사용하는 경우, 리전별로 로그 파일이 전송될 장소를 선택할 수 있습니다. CloudTrail은 로그를 지정된 S3 버켓에 저장합니다. 리전별로 별도의 S3 버킷을 사용할 수도 있고, 모든 리전의 로그 파일을 S3 버켓 하나에 집계할 수도 있습니다.

 

또한, 자세히 분석해야 하는 사항을 파악하는데 사용할 수도 있습니다. CloudTrail API 사용 로그를 S3 버켓에 저장하면 나중에 이렇나 로그를 분석하여 다음과 같은 중요한 정보를 파악할 수 있습니다.

  • 장기 실행 인스턴스가 종료된 이유와 해당 인스턴스를 종료한 사람(조직의 추적 가능성 및 책임 소재 확인 지원)
  • 보안 그룹 구성을 변경한 사람(책임 소재 확인 및 보안 감사 지원)
  • 권한 부족으로 인해 거부된 활동(조직 안팎의 네트워크 대상 공격 가능성 파악)

상세

 

CloudTrail 로그 예시

{
    "Records": [{
        "eventVersion": "1.0",
        "userIdentity": {                                     /* ← 요청을 수행한 사용자 */
            "type": "IAMUser",
            "principalId": "EX_PRINCIPAL_ID",
            "arn": "arn:aws:iam::123123123123:user/Alice",
            "accountId": "123123123123",
            "accessKeyId": "EXAMPLE_KEY_ID",
            "userName": "Alice"                               /* ← 요청을 수행한 사용자 */
        },
        "requestParameters": {                                /* ← 요청의 주된 내용 */
            "instancesSet": {
                "item": [{
                    "instanceId": "i-abcdefg01234567890"      /* ← 요청의 주된 내용 */
                }]
            },
            "force": false
        },
        "eventTime": "2018-03-06T21:01:59Z",                  /* ← 요청이 수행된 시간 */
        "eventSource": "ec2.amazonaws.com",
        "eventName": "StopInstances",                         /* ← API 호출 내용 */
        "awsRegion": "us-west-2",                             /* ← 요청이 수행된 위치 */
        "sourceIPAddress": "123.123.123.123",
        "userAgent": "ec2-api-tools 1.6.12.2",
        "responseElements": {                                 /* ← 응답 내용 */
            "instancesSet": {
                "item": [{
                    "instanceId": "i-abcdefg01234567890",
                    "currentState": {
                        "code": 64,
                        "name": "stopping"                     /* ← 응답 내용 */
                    },
                    "previousState": {
                        "code": 16,
                        "name": "running"
                    }
                }]
            }
        }
    }]
}

 

VPC 흐름 로그

VPC 흐름 로그는 VPC 네트워크 인터페이스에서 송수신되는 IP 트래픽 정보를 캡처합니다. 다음은 몇가지 특징입니다.

  • 이 로그는 VPC, 서브넷, 네트워크 인터페이스를 기준으로 트래픽을 기록하도록  구성할 수 있습니다.
  • EC2 및 VPC 콘솔에서 특정 리소스의 흐름 로그 탭을 선택하여 흐름 로그에 대한 정보를 볼 수 있습니다.
  • 흐름 로그는 기본적으로 해제되어 있으므로, 흐름 로그 데이터를 수집하기 위해서는 옵트인해야 합니다.

흐름 로그는 S3 버켓 또는 CloudWatch 로그 그룹에 게시됩니다. 데이터는 네트워크 트래픽 경로 외부에서 수집되므로 네트워크 처리량이나 지연 시간에 영향을 미치지 않습니다. 흐름 로그는 다음과 같은 여러 작업을 수행하는 데 도움이 될 수 있습니다.

  • 지나치게 제한적인 보안 그룹 규칙을 진단
  • 인스턴스에 연결되고 있는 트래픽을 모니터링
  • 네트워크 인터페이스를 오가는 트래픽 방향 결정

IP 트래픽 로깅 / 흐름 로그 분석으로 보안 개선(AWS Blog)

 

흐름 로그 레코드 내용

각 레코드는 특정 캡처 기간에 대한 네트워크 IP 흐름을 캡처하며 5가지 값(5튜플)을 포함합니다. 레코드에는 소스, 대상, 프로토콜 같은 IP 흐름의 구성 요소가 포함됩니다. 특정 유형의 트래픽이 탐지되면 활성화되는 경보를 생성하고 경향 및 패턴을 식별하는 데 도움이 되는 지표를 생성할 수 있습니다.

 

정보에는 보안 그룹 및 네트워크 엑세스 제어 목록(NACL) 규칙에 따른 ACCEPT 또는 PEJECT 작업이 포함됩니다. 그리고 소스 및 대상 IP 주소와 포트 및 Internet Assigned Numbers Authority(IANA) 프로토콜 번호도 포함됩니다. 또한 패킷 및 바이트 수(흐름이 관찰되는 시간 간격)도 포함됩니다.

 

흐름 로그가 네트워크의 모든 것을 캡처할 수는 없습니다. DNS 트래픽이나 DHCP(Dynamic Host Configuration Protocol) 요청 및 응답은 VPC 로깅에 포함되지 않습니다. 자체 DNS 서버를 실행 중인 경우에는 요청 확인 트래픽을 로깅할 수 있습니다. 그러나 많은 사용자가 내부 AWS DNS 서버에 의존하며, 서버와 AWS DNS 서비스 간의 활동 및 DHCP 트래픽은 VPC 흐름 로그에 캡처되지 않습니다. 

반응형

'자격증 > AWS SAA' 카테고리의 다른 글

[AWS SAA] 35. Elastic Load Balancing(ELB)  (0) 2023.08.30
[AWS SAA] 34. 경보 및 이벤트  (0) 2023.08.29
[AWS SAA] 32. CloudWatch  (0) 2023.08.27
[AWS SAA] 31. Database 마이그레이션  (0) 2023.08.26
[AWS SAA] 30. 캐싱 서비스  (0) 2023.08.25
반응형

모니터링하는 이유

환경 모니터링은 아키텍처를 생성할 때 고려해야 할 가장 중요한 요소 중 하나입니다. 리소스 운영 및 작동을 추적할 수 있는 방법이 항상 필요합니다. 다음은 기억해야 할 몇 가지 핵심 사항입니다.

  • 모니터링을 사용하면 리소스 사용률 및 애플리케이션 성능에 대한 정보를 수집합니다. 모니터링 시에는 인프라가 수요를 충족하는지 측정합니다. 그럼 수요 증가 시 확장되고 수요 감소 시 다시 축소되는 아키텍처를 구축하는 데 도움이 됩니다.
  • 이 유형의 크기 조정은 고객에게 더 나은 사용자 경험을 제공하고 비용을 절감합니다.
  • 모니터링은 보안상 중요한 작업입니다. 파라미터를 설정하면 사용자가 환경의 일부에 액세스하는지 여부를 알 수 있고 권한을 확인할 수 있습니다.

 

모니터링을 수행하는 이유는 다음과 같습니다.

  • 운영 상태: 운영 가시성 및 인사이트를 확보합니다.
  • 애플리케이션 성능: 성능 스택의 모든 계층에서 데이터를 수집합니다.
  • 리소스 사용률: 리소스 최적화를 개선합니다.
  • 보안 감사: 증거 수집, 보안 및 무결성을 자동화 및 관리합니다.

CloudWatch

CloudWatch는 실시간에 가까운 시스템 이벤트 스트림을 제공하는 AWS 서비스입니다. 이러한 이벤트는 AWS 리소스에 대한 변경 사항을 설명합니다. CloudWatch를 사용하면 운영 변경 사항에 신속하게 대응하고 시정 조치를 취할 수 있습니다. CloudWatch 경보는 알림을 보내거나 정의한 규칙을 기준으로 모니터링하는 리소스를 자동으로 변경합니다.

 

예를 들어 EC2 인스턴스의 CPU 사용량과 디스크 읽기 및 쓰기를 모니터링할 수 있습니다. 이 데이터는 증가한 로드를 처리하기 위해 추가 인스턴스를 시작해야 하는지 여부를 판단하는 데 사용할 수 있습니다. 또한 이 데이터를 사용해 사용률이 낮은 인슽너스를 중지하고 비용을 절감할 수도 있습니다.

 

AWS에서 기본으로 제공하는 지표 이외에도 사용자 지정 지표를 생성하고 모니터링할 수 있습니다. CloudWatch를 사용하면 시스템 전체의 리소스 사용률, 애플리케이션 성능 및 운영 상태를 시각적으로 파악할 수 있습니다.

 

CloudWatch 한 곳에서 모든 AWS 리소스, 애플리케이션, 서비스에 걸쳐 이 데이터를 수집 및 액세스하고 상관 관계를 파악할 수 있습니다. CloudWatch는 온프레미스 서버에서도 데이터를 수집할 수 있습니다. 성능 및 리소스 사용을 최적화할 수 있도록 CloudWatch에서는 자동 대시보드를 제공하며, 1초 시간 단위로 데이터를 제공하고 최대 15개월 동안 지표를 저장 및 보존합니다.

 

상세

 

CloudWatch 지표

지표는 시스템 성능에 대한 데이터입니다. 대다수 서비스에서는 기본적으로 리소스 관련 지표를 제공합니다. 이러한 리소스의 예시는 EC2 인스턴스, EBS 볼륨, DB 인스턴스 등이 있습니다. CloudWatch에서는 지표에 대한 데이터를 일련의 데이터 요소로 저장합니다. 각 데이터 요소에는 연결된 타임스탬프가 있습니다.

 

CloudWatch에 지표를 직접 게시할 수 있습니다. AWS 관리 콘솔을 사용하여 게시한 지표의 통계 그래프를 확인합니다. 또한, EC2 인스턴스 같은 일부 리소스에 대한 세부 모니터링을 활성화하거나 자체 애플리케이션 지표를 게시할 수도 있습니다.

 

CloudWatch는 검색, 그래프 작성 및 경보를 위해 계정에 모든 지표(AWS 리소스 지표 + 사용자가 제공한 앱 지표)를 로드할 수 있습니다. 지표 데이터는 15개월 동안 보관되므로 최신 데이터와 이력 데이터를 모두 볼 수 있습니다.

 

CloudWatch의 구성 요소는 다음과 같습니다.

  • 네임스페이스
    CloudWatch 지표 중 컨테이너입니다. 서로 다른 네임스페이스의 지표는 서로 격리되어 있으므로 다른 애플리케이션의 지표가 실수로 동일한 통계로 집계될 일은 없습니다. 사용자는 지표를 생성할 때 네임스페이스 이름을 지정할 수 있습니다. (참고_AWS 네임스페이스는 AWS/service라는 명명 규칙을 사용합니다.)
  • 지표
    CloudWatch에 게시된 시간 순서별 데이터 요소 세트를 나타냅니다. 지표를 모니터링할 변수로 생각하면 데이터 요소는 시간에 따른 변수 값을 나타냅니다. 각 지표데이터 요소는 타임스탬프와 연결되어야 합니다. 타임스탬프를 제공하지 않으면 CloudWatch는 데이터 요소를 받은 시간을 기준으로 타임스탬프를 생성합니다.
  • 차원
    지표를 고유하게 식별할 수 있도록 도움을 주는 이름/값 페어를 말합니다. 각 지표에서는 차원을 10개까지 할당할 수 있습니다. 모든 지표에는 지표를 설명하는 특징이 있습니다. 이러한 특징의 범주를 차원이라 할 수 있습니다.

콘솔에서 지표 그래프를 생성하려는 경우 자체적으로 제공하는 정형 쿼리 언어(SQL) 엔진인 CloudWatch Metrics Insights를 사용할 수 있습니다. 이를 사용해 모든 지표 내의 실시간 추세와 패턴을 파악할 수 있습니다.

 

 

반응형

'자격증 > AWS SAA' 카테고리의 다른 글

[AWS SAA] 34. 경보 및 이벤트  (0) 2023.08.29
[AWS SAA] 33. AWS Log 서비스  (0) 2023.08.28
[AWS SAA] 31. Database 마이그레이션  (0) 2023.08.26
[AWS SAA] 30. 캐싱 서비스  (0) 2023.08.25
[AWS SAA] 29. DB Caching(캐싱)  (0) 2023.08.25
반응형

Database Migration Service(DMS)

DMS는 원본에서 AWS 클라우드의 대상 DB로 데이터를 복제합니다. 원본 및 대상 연결을 생성하여 데이터를 추출할 원본 위치와 로드할 대상 위치를 AWS DMS에 제공합니다. 그런 다음 이 서버에서 실행되어 데이터를 이동하는 태스크를 예약합니다. 그러면 AWS DMS가 테이블 및 관련 기본 키를 생성합니다(대상이 아직 없는 경우에 해당하며, 이미 존재한다면 해당 대상을 선택할 수도 있습니다).

 

DMS는 가장 광범위하게 사용되는 DB(Oracle, PostgreSQL, MS SQL Server, MariaDB, MySQL) 간 마이그레이션을 지원합니다. 또한 동일한 엔진 및 다른 엔진  간 마이그레이션을 지원합니다. 이 서비스를 사용하여 온프레미스 데이터베이스, EC2 DB, RDS DB간 마이그레이션을 진행할 수 있습니다. 하지만 두 개의 온프레미스 DB 간에는 마이그레이션할 수 없습니다. 소스 또는 대상 DB(혹은 둘 다)가 RDS 또는 EC2에 있어야합니다.

 

DMS 사용 시에는  Snowball 엣지 디바이스를 마이그레이션 대상을 사용할 수도 있습니다. 작업 환경의 인터넷 연결 상태가 불량하거나 소스 DB가 너무 커서 인터넷을 통해 이동하기가 어려운 경우 이 방법을 사용할 수 있습니다. 조직에 개인정보 또는 보안 요구 사항이 적용되는 경우에도 이 방법을 사용합니다.

 

대상 DB에서 사용할 수 있도록 AWS DMS가 원본 데이터 형식을 자동으로 처리합니다. 스키마나 코드는 변환하지 않습니다.

 

상세

 

Schema Conversion Tool(SCT)

AWS SCT를 사용해 이기종(서로 다른 엔진) DB를 예측 가능한 방식으로 마이그레이션할 수 있습니다. 원본 DB 스키마와 대부분의 DB 코드 객체를 자동으로 변환합니다. 변환에는 뷰, 축적 절차(stored procedure) 및 함수가 포함됩니다. 이들 객체는 대상 DB와 호환되는 형식으로 변환됩니다. 자동으로 변환되지 않는 객체는 표시가 되기 때문에 수동 변환을 통해서 마이그레이션을 완료할 수 있습니다.

 

SCT 임베디드 SQL 문에 따라 애플리케이션 소스 코드를 확장하여 DB 스키마 변환 프로젝트의 구성 요소로 변환할 수 있습니다. AWS SCT는 이 프로세스 중에 클라우드용으로 작성된 코드를 최적화합니다. 즉, Oracle 및 SQL Server의 레거시 함수를 상응하는 AWS 서비스로 변환하여 DB 마이그레이션과 동시에 애플리케이션을 현대화합니다.

 

스키마 변환이 완료되고 나면 AWS SCT는 기본 제공 데이터 마이그레이션 에이전트를 사용하여 다양한 데이터 웨어하우스에서 Amazon Redshift로 데이터를 효과적으로 마이그레이션할 수 있습니다.

 

상세

 

 

 

반응형

'자격증 > AWS SAA' 카테고리의 다른 글

[AWS SAA] 33. AWS Log 서비스  (0) 2023.08.28
[AWS SAA] 32. CloudWatch  (0) 2023.08.27
[AWS SAA] 30. 캐싱 서비스  (0) 2023.08.25
[AWS SAA] 29. DB Caching(캐싱)  (0) 2023.08.25
[AWS SAA] 28. DynamoDB - 2  (0) 2023.08.24
반응형

ElastiCache

ElastiCache는 클라우드에서 분산 인 메모리 데이터 스토어 또는 캐시 환경을 원활하게 설정, 관리 및 확장할 수 있는 웹 서비스 입니다. 이 서비스는 확장 가능하며 비용 효율적인 고성능 캐싱 솔루션을 제공합니다. 또한 분산 캐시 환경 배포 및 관리와 관련된 복잡한 작업도 수행할 필요가 없습니다.

 

ElastiCache는 Redis와 Memcached 두 가지 오픈 소스 인 메모리 엔진을 지원합니다.

 

ElastiCache 엔진

ElastiCache는 위 2가지 오픈 소스 호환 인 메모리 데이터 스토에 대해 완전 관리형 기능을 제공합니다.

 

ElastiCache for Memcached를 사용하여 데이터 집약적 앱에 대한 확장 가능한 캐싱 티어를 구축할 수 있습니다. 1밀리초 미만의 응답 시간이 필요한 가장 까다로운 애플리케이션을 지원할 수 있도록 인 메모리 데이터 스토어 및 캐시의 역할을 합니다. 또한, 확장 가능하고 안전한 완전관리형 서비스로서 자주 액세스하는 데이터가 인 메모리에 상주해야 하는 사용 사례에 적합합니다. 이 엔진은 다중 스레딩을 사용하는 간단한 캐싱 모델을 제공합니다. 웹, 모바일 앱, 게임, 광고 기술 및 전자 상거래와 같은 사용 사례에 주로 사용됩니다. Memcached 호환 서비스는 자동 검색도 지원합니다.

 

ElastiCache for Redis는 인터넷 규모에서 1 밀리 초 미만의 지연 시간을 제공하는 인 메모리 데이터 스토어 입니다. Redis용 ElastiCache는 오픈 소스 Redis의 속도, 간편성, 및 다양성과 Amazon의 관리 용의성, 보안 및 확장성을 결합합니다. 게임, 광고 기술, 전자 상거래, 헬스케어, 금융 서비스 및 사물 인터넷(IoT) 분야에서 가장 까다로운 실시간 애플리케이션도 지원할 수 있습니다.

 

2가지 오픈 소스 비교 상세

 

스레드(Thread)
어떤 프로그램 내(특히 프로세스)에서 실행되는 흐름의 단위를 말합니다. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있디만, 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있는데, 이러한 실행 방식을 다중(멀티)스레드(Multithread)라고 합니다.

 

DynamoDB Accelerator(DAX)

DynamoDB는 확장성과 성능을 고려하여 설계되었습니다. 대부분의 경우 DynamoDB 응답 시간은 한 자릿수 밀리초 단위로 측정될 수 있습니다. 하지만 일부 용례는 마이크로초 단위의 응답 시간이 필요합니다. 이러한 사용 사례에서 DAX는 최종 일관성을 갖춘 데이터에 액세스하기 위한 빠른 응답 시간을 제공합니다.

 

DAX는 까다로운 애플리케이션에서 빠른 인 메모리 성능을 제공하는 DynamoDB와 호환되는 캐싱 서비스입니다.

 

VPC에 DAX 클러스터를 생성하여 캐시된 데이터를 애플리케이션에 더 가깝게 저장할 수 있습니다. 해당 VPC에서 애플리케이션을 실행하는 EC2 인스턴스에 DAX 클라이언트를 설치합니다. DAX 클라이언트는 런타임에 애플리케이션의 모든 DynamoDB 요청을 DAX 클러스터로 전송합니다. DAX는 요청을 직접 처리할 수 있으면 처리하고, 그 외의 경우에는 DynamoDB로 요청을 전달합니다.

 

DAX 개발자 안내서

반응형

'자격증 > AWS SAA' 카테고리의 다른 글

[AWS SAA] 32. CloudWatch  (0) 2023.08.27
[AWS SAA] 31. Database 마이그레이션  (0) 2023.08.26
[AWS SAA] 29. DB Caching(캐싱)  (0) 2023.08.25
[AWS SAA] 28. DynamoDB - 2  (0) 2023.08.24
[AWS SAA] 27.Dynamo DB - 1  (0) 2023.08.23
반응형

캐시를 고려해야하는 항목

애플리케이션이 데이터베이스 캐싱을 사용해야 하는지 여부를 결정하기 위해서 다음과 같은 사항을 고려할 수 있습니다.

 

  • 속도와 비용
    기본적으로 속도는 더 느리고 비용은 더 많이 드는 데이터베이스 쿼리가 존재합니다. 예를 들어 여러 테이블에서 조인을 수행하는 쿼리는 단순한 단일 테이블 쿼리보다 훨씬 더 많은 시간과 비용이 듭니다. 요청하는 데이터를 수신하려면 속도가 느리고 비용이 많이 드는 쿼리를 실행해야 하는 경우 해당 데이터를 캐시할 수 있습니다.
  • 데이터 및 액세스 패턴
    캐싱할 항목을 결정할 때는 데이터 그 자체와 데이터의 액세스 패턴도 이해해야 합니다. 예를 들어 빠르게 변경되거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없습니다. 캐싱을 통해 유의미한 이점을 얻으려면 소셜 미디어 사이트의 개인 프로필과 같이 비교적 정적이면서 액세스 빈도가 높은 데이터가 있어야 합니다.
  • 캐시 유효성
    데이터는 캐시에 저장되어 있는 동안 오래된 상태가 될 수 있습니다. 즉, 데이터베이스의 해당 데이터에 대해 수행되는 쓰기가 캐시하기에 적합한지를 결정할 때는 정확하지 않을 수도 있는 캐시 데이터에 대한 애플리케이션의 내결함성을 결정해야 합니다.

 

캐싱 아키텍처

캐싱을 사용하지 않는 경우 EC2 인스턴스가 데이터베이스에서 직접 읽고 씁니다. 반면 캐싱을 사용하는 경우 인스턴스는 먼저 캐시에서 읽기를 시도하는데, 이 읽기에는 고성능 메모리가 사용됩니다. 에를들어 ElasticCache 및 DynamoDB Accelerator(DAX)와 같은 AWS의 데이터베이스 캐시는 인 메모리 DB입니다. 이러한 데이터베이스가 사용하는 캐시 클러스터에는 서브넷 간에 분산된 캐시 노드 집합이 포함되어 있습니다. 해당 서브넷 내의 리소스는 이러한 노드에 고속으로 액세스합니다.

 

 

위 예에서는 VPC의 2개 가용 영역에 각각 앱 서브넷과 데이터 서브넷이 있습니다. 두 앱 서브넷의 애플리케이션 서버는 데이터 서브넷 하나의 프라이머리 DB가 연결됩니다. 다른 데이터 서브넷에는 복제본 DB가 포함되어 있습니다. 두 앱 서브넷에 걸쳐 캐시 클러스터가 표시되어 있으며, 각 서브넷의 클러스터에는 캐시 노드가 있습니다.

 

백엔드 데이터 스토어에 캐시를 사용할 경우 사이드 캐시가 일반적인 접근 방식입니다. 정식 예에는 Redis와 Memcached가 모두 포함됩니다. 이러한 캐시는 범용이며 기본 데이터 스토어와는 분리됩니다. 그러므로 워크로드 및 내구성 요구 사항에 따라 읽기 및 쓰기 처리량을 모두 높일 수 있습니다.

Redis? Memcached?
Redis는 키-값(Key-Value) 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 DBMS입니다. DB, 캐시, 메세지 브로커로 사용되며 인메모리 데이터 구조를 가진 저장소입니다.

키-값 구조로 쿼리를 사용할 필요가 없고, 메모리에서 데이터를 처리하기 때문에 처리 속도가 빠르다는 특징이 있습니다. 하지만 서버 장애시 데이터 유실이 일어날 수 있으므로 장애 복구 플랜이 중요합니다.

Memcached는 고성능 분산 메모리 캐시 시스템입니다. 데이터베이스 부하를 완화하여 동적 웹 응용 프로그램의 속도를 높이는 데 사용하도록 만들어졌습니다. Redis와 마찬가지로 사용하기 쉽고, 높은 성능을 자랑합니다. Redis와 비슷한 원리로 동작해 특징 또한 거의 유사합니다.

 

일반적인 캐싱 전략

다양한 전략을 활용해 캐시의 정보를 DB와 동기화된 상태로 유지할 수 있습니다. 두 가지 일반적인 캐싱 전략은 지연 로딩과 라이트 스루입니다.

 

지연 로딩

 

지연 로딩에서는 캐시를 업데이트하지 않고 데이터베이스를 업데이트합니다. 캐시 미스의 경우 데이터베이스에서 검색된 정보가 나중에 캐시에 기록될 수 있습니다. 지연 로딩 시에는 애플리케이션에 필요한 데이터가 캐시에 로드됩니다. 하지만 일부 사용 사례에서는 캐시 미스 비율이 높아질 수 있습니다.

 

라이트 스루

 

DB에 액세스할 때마다 캐시에 라이트 스루를 수행하는 방법입니다. 이러한 접근 방식은 캐시 미스가 줄어든다는 특징이 있습니다. 그 결과 성능이 개선되지만 애플리케이션에 필요하지 않을 수 있는 데이터용 추가 스토리지가 필요합니다.

 

최상의 전략은 사용 사레에 따라 다릅니다. 부실 데이터가 사용 사례에 미치는 영향을 이해하는 것이 중요합니다. 영향이 높은 경우 라이트 스루를 사용하여 새로 고침 상태를 유지하는 것이 좋습니다. 영향이 낮은 경우 지연 로딩으로 충분할 수 있습니다. 또한 기본 데이터의 변경 빈도를 이해하는 데 도움이 됩니다. 캐싱 전략의 성능 및 비용 절충에 영향을 미치기 때문입니다.

 

캐싱 유지 관리 전략을 경정한 후에는 애플리케이션 내에서 이 접근 방식을 구현해야합니다.

 

캐시 미스
CPU가 데이터를 요청하여 캐시 메모리에 접근했을 때 캐시 메모리가 해당 데이터를 가지고 있다면 이를 "캐시 적중(Cache hit)", 해당 데이터가 없어서 DRAM에서 가져와야 한다면 "캐시 부적중(Cache miss)"라고 부릅니다.

 

ElastiCache for Redis / Memcached 상세

 

캐시 관리

캐시 유효성 관리

지연 로딩은 기한 경과 데이터를 제공할 수도 있지만 빈 노드로 인해 실패하지는 않습니다. 라이트 스루에서는 최신 데이터가 유지도비니다. 그러나 빈 노드로 인해 실패할 수 있으며 불필요한 데이터로 캐시를 채울 수 있습니다. 캐시에 대한 각 쓰기에 유지 시간(TTL) 값을 추가하면 데이터를 최신 상태로 유지할 수 있으며, 여분의 데이터로 인해 캐시가 가득 차는 현상을 방지할 수 있습니다.

 

TTL은 키가 만료할 때까지의 시간(초 or 밀리초)을 지정하는 정수 값입니다. 애플리케이션이 만료된 키를 읽으려고 하면 캐시에서 데이터를 찾지 못한 것으로 처리됩니다. 따라서 데이터베이스가 쿼리되고 캐시가 업데이트됩니다. 그럼 데이터 기한 경과를 방지할 수 있습니다. 단, 데이터베이스에서 가끔씩 캐시의 값을 새로 고쳐야 합니다.

 

메모리 관리

캐시 메모리가 가득 차면 캐시 엔진이 새 데이터용 공간을 확보하기 위해 메모리에서 데이터를 제거합니다. 엔진은 사용자가 설정한 제거 정책을 기준으로 이 데이터를 선택합니다. 제거 정책은 데이터의 다음  특성을 평가합니다.

  • 액세스한 지 가장 오래된 데이터
  • 액세스 빈도가 가장 낮은 데이터
  • TTL 세트와 TTL 값이 설정되어 있는 데이터

 

 

반응형

'자격증 > AWS SAA' 카테고리의 다른 글

[AWS SAA] 31. Database 마이그레이션  (0) 2023.08.26
[AWS SAA] 30. 캐싱 서비스  (0) 2023.08.25
[AWS SAA] 28. DynamoDB - 2  (0) 2023.08.24
[AWS SAA] 27.Dynamo DB - 1  (0) 2023.08.23
[AWS SAA] 26. RDS - Aurora DB  (0) 2023.08.22
반응형

DynamoDB 테이블

DynamoDB는 데이터를 테이블에 저장합니다. 테이블을 생성할 때 테이블 이름과 파티션 키를 지정해야 합니다. 테이블 생성 시에 필요한 엔터티는 이 두 항목 뿐입니다.

 

DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해 줍니다. 지원되는 기본 키의 2가지 유형은 다음과 같습니다.

  • 단순 기본 키
    파티션 키라는 속성 하나만으로 구성된 단순한 기본 키입니다. 파티션 키를 하나만 사용하는 경우 두 항목이 동일한 값을 가질 수 없습니다.
  • 복합 기본 키
    복합 기본 키는 파티션 키와 정렬 키로 구성됩니다. 이 경우 여러 항목의 파티션 키 값은 같을 수 있지만 정렬 키 값은 달라야 합니다.

 

핵심 구성 요소는 테이블, 항목, 및 속성입니다. 테이블은 항목의 모음이고 각 항목은 속성의 모음입니다. 위 예시에서 나와 있는 테이블에는 2개 항목이 포함되어 있고, Hammer57과 FluffyDuffy가 단순 기본 키입니다. 기본 키가 Hammer57인 항목에는 3개의 속성 (게임 ID, 최고점, 장르)이 있습니다. FluffyDuffy의 기본 키에는 구독 여부 속성이 포함되며 장르 속성은 포함되지 않았습니다.

 

상세

 

DynamoDB 용량 및 크기 조정

DynamoDB에서 용량을 계획할 때는 초당 읽기/쓰기 요청의 예상 수와 해당 요청의 크기를 고려해야 합니다. 이 정보를 고려하면 테이블용 용량 모드를 쉽게 선택할 수 있습니다. 또한 메시지 크기를 관리할 수 있도록 테이블을 설계할 수 있습니다.

 

온디맨드 용량 모드는 요청 단위로 요금이 부과되는 모델입니다. 다음과 같은 상황에서는 온디맨드 용량 모드가 유용합니다.

  • 워크로드를 알 수 없는 경우
  • 트래픽을 예측할 수 없는 경우
  • 사용한 만큼만 지불하는 요금제를 사용하려는 경우

프로비저닝된 용량 모드 사용 시에는 RCU와 WCU의 최대 수를 설정합니다. 트래픽이 해당 한도를 초과하면 DynamoDB는 비용 제어를 위해 요청을 스로틀합니다. 자동 크기 조정을 사용해 프로비저닝된 용량을 조정할 수 있습니다. 다음과 같은 상황에서는 프로비저닝된 용량 모드가 유용합니다.

  • 애플리케이션 트래픽이 예측 간으한 경우
  • 트래픽의 양이 일정하거나 점진적으로 변경되는 경우
  • 비용 관리를 위해 용량 요구 사항을 예측할 수 있는 경우

상세

 

DynamoDB 일관성 옵션

애플리케이션이 DynamoDB 테이블에 데이터를 쓰고 HTTP 200 응답(OK)을 수신하면 쓰기가 발생하며 내구성을 갖습니다. 데이터는 일반적으로 1초 이내에 모든 스토리지 위치에서 최종적으로 일관성을 갖습니다. DynamoDB는 최종적으로 일관된 읽기와 강력한 일관된 읽기를 지원합니다

 

  • 최종적으로 일관된 읽기
    DynamoDB 테이블의 데이터를 읽을 때, 응답은 최근 완료된 쓰기 작업의 결과를 반영하지 않을 수 있습니다. 응답에는 부실 데이터가 일부 포함될 수 있습니다. 잠시 후 읽기 요청을 반복하면 응답이 최신 데이터를 반환합니다.
    (Ex_ YouTube 댓글, 쇼핑 장바구니 등 실시간 동기화가 굳이 필요하지 않은 경우)

  • 강력한 읽기 일관성
    강력한 읽기 일관성을 요청하면 DynamoDB는 성공한 모든 이전 쓰기 작업의 업데이트를 반영하여 가장 최신 데이터로 응답을 반환합니다. 강력한 읽기 일관성은 네트워크 지연 또는 중단이 발생하는 경우에 사용이 어려울 수 있습니다.
    (Ex_ 항공권 구매, 티켓팅 등 실시간 동기화가 필요한 경우)

옵션을 지정하지 않을 경우 DynamoDB는 최종적으로 일관된 읽기를 사용합니다. 읽기 작업(GetItem, Query,Scan)은 CnsistentRead 파라미터를 제공합니다. 이 파라미터를 true로 설정하면 DynamoDB는 작업 중에 강력한 읽기 일관성을 사용합니다.

 

DynamoDB 글로벌 테이블

글로벌 테이블은 단일 AWS 계정이 소유하고 복제 테이블로 식별되는 한 개 이상의 DynamoDB 테이블의 모음입니다. 복제 테이블(이하 복제본)은 글로벌 테이블의 일부로 기능하는 단일 DynamoDB 테이블입니다. 각 복제본에는 동일한 데이터 항목 집합이 저장됩니다. 글로벌 테이블은 리전당 한 개의 복제 테이블을 가질 수 있습니다. 모든 복제본은 동일한 테이블 이름과 동일한 기본 키 스키마를 갖습니다.

 

DynamoDB 글로벌 테이블은 복제 솔루션을 직접 구축하여 관리하지 않고도 다중 리전, 다중 활성 마스터 DB를 배포할 수 있는 완전관리형 솔루션을 제공합니다. 글로벌 테이블을 생성할 때 테이블을 사용할 수 있게 할 리전을 지정해야 합니다. DynamoDB는 이러한 리전에 동일한 테이블을 만들고 이들 모든 테이블에 대한 데이터 변경을 지속적으로 전파하기 위해 필요한 모든 태스크를 수행해야 합니다. DynamoDB는 AWS 네트워크 백본을 통해 이러한 변경 사항을 전달합니다.

 

상세

반응형

'자격증 > AWS SAA' 카테고리의 다른 글

[AWS SAA] 30. 캐싱 서비스  (0) 2023.08.25
[AWS SAA] 29. DB Caching(캐싱)  (0) 2023.08.25
[AWS SAA] 27.Dynamo DB - 1  (0) 2023.08.23
[AWS SAA] 26. RDS - Aurora DB  (0) 2023.08.22
[AWS SAA] 25. RDS(Amazon Relational Database Service)  (0) 2023.08.21