결론부터 말하자면 RDS 의 cpu 가 예상과 다르게 100% 를 찍는다면 빨리 slow query 를 찾아보세요.

며칠 동안 불규칙 적으로 발생한 5분 정도 짜리의 cpu 과부하를 찾아내는 것은 쉽지 않았습니다.

RDS 에서 생성된 slow_query.log 파일에는 로그 flush 메시지 밖에 없었으니까요.

특별히 높지 않은 커넥션 수...

lock 이 걸렸는지, slow query 가 걸렸는지 5분 정도만에 cpu 점유율이 다시 안정을 되찾는...

밤이고 낮이고 심심할 때 가끔씩 찾아오는 과부하라...

그 시간대에 발생된 query 를 5 대가 넘는 서버에서 모두 뽑기엔, 아니 뽑는다 해도 이 중 무엇이 문제인지 알 수가 없다는...

람다에서 주기적으로 유입되는 데이터를 의심했지만, 시간대가 맞기도 하고 안맞기도 하고...

processlist query 를 1분마다 날리면서 lock 걸린 query 를 찾아야 하는 것인가...

일단 slow query 를 좀 봐야겠다는 생각에 20초 짜리 query 를 날렸지만, 이마저 slow_query.log 파일은 응답하지 않았습니다.

결국 고객센터에 징징거리기 시작했더니, 해결책을 알려줬습니다.

log_output 이 default 로 table 로 되어 있어서 slow query 가 테이블에 들어가 있다는...

EC~! 근데 왜 slow_query 파일이 생성되서 사람 민망하게 만드는 거냐고!!

화는 잠시 접어두고 결국 slow query 를 찾아 잘못된 인덱스를 수정하고 cpu 를 잠재웠습니다.

하필 중요한 검색 쪽이 ㅡㅡ;;

그럼 그렇지. 이 많은 query 들이 slow query 하나 없이 잘 돌아가고 있다고 생각한 나는 용자.

참고로 알아두면 좋을 Parameter Groups 를 적어 봅니다.

• slow_query_log : 1 (slow query 사용)
• long_query_time : 2 (slow query 제한, default 10 초)
• log_queries_not_using_indexes : 1 (인덱스 타지 않는 query 기록)
• log_output : table (로그 출력 table / file)

DynamoDB SDK 는 대부분의 프로그래밍 언어를 제공하며, 이를 사용하여 프로젝트에 필요한 작업을 할 수 있다.

SDK 가 다음 기능을 제공하여 개발자의 코드 양을 엄청나게 줄여준다.

• HTTP(S) 요청 서식 설정 및 요청 파라미터 직렬화.
• 각 요청의 암호화 서명 생성.
• 요청을 DynamoDB 엔드포인트에 전달하고 DynamoDB로부터 응답을 수신.
• 이러한 응답에서 결과 추출.
• 오류 발생 시 기본적 재시도 로직 구현.

AWS SDK는 DynamoDB 작업을 위한 3가지 프로그래밍 인터페이스를 제공한다.

사용 가능한 인터페이스는 사용하는 AWS SDK와 프로그래밍 언어에 따라 달라질 수 있다.

1. Low-Level Interfaces

SDK 는 Low-Level DynamoDB API 요청과 매우 비슷한 메서드를 사용하여, DynamoDB 용 Low-Level 인터페이스를 제공한다.

경우에 따라 문자열에 해당되는 S 또는 숫자에 해당되는 N 같은 Data Type Descriptors 를 사용하여 속성의 데이터 형식을 식별해야 한다.

DynamoDB Low-Level 인터페이스를 구현한 com.amazonaws.services.dynamodbv2.AmazonDynamoDB 클래스를 사용할 수 있다.

2. Document Interfaces

Java, .NET, Node.js, JavaScript 용 AWS SDK 는 Table 과 Index 에서 데이터 CRUD 를 수행할 수 있는 document 인터페이스를 제공한다.

document 인터페이스를 사용하면 Data Type Descriptors 를 사용할 필요가 없다.

이 document 인터페이스를 구현한 com.amazonaws.services.dynamodbv2.document.DynamoDB 클래스를 사용할 수 있다.

DynamoDB 는 Low-Level 클라이언트(AmazonDynamoDB) 의 래퍼 역할을 한다. (Low-Level 인터페이스를 사용하는 것보다 코드가 간결해진다.)

- Music Table 에서 특정 노래를 가져와 노래의 년도를 출력하는 예제)

3. Object Persistence Interfaces

DynamoDB Table 과 Index 의 Item 을 나타내는 객체를 생성해 이 객체들과만 상호 작용하여, 객체 중심 코드를 만들 수 있다.

이를 활용하면, DynamoDB 테이블로 클라이언트 측 클래스를 매핑할 수가 있다.

Object Persistence 인터페이스를 구현한 com.amazonaws.services.dynamodbv2.datamodeling.DynamoDBMapper 클래스를 사용할 수 있다.

DynamoDBMapper 도 Low-Level 클라이언트(AmazonDynamoDB) 의 래퍼 역할을 한다.

이 인터페이스는 Java, .NET 용 AWS SDK 만 제공한다.

DynamoDB Low-Level API 는 실제 DynamoDB 에 요청하는 마지막 단계 인터페이스로, 이 HTTP(S) 요청은 올바른 형식이어야 한다.

• HTTP(S) 요청은 POST 방식이어야 한다.
• Authorization 헤더에는 DynamoDB 가 요청을 인증하는 데 필요한 정보가 포함되어야 한다.
• X-Amz-Target 헤더에는 DynamoDB 작업의 이름(GetItem, PutItem 등...) 이 포함되어야 한다.
• 요청 본문은 JSON 형식이어야 한다.

응답도 JSON 형식으로 반환된다.

DynamoDB 가 요청을 처리할 수 없는 경우, HTTP 오류 코드와 메시지를 반환하므로 오류 처리를 해주면 된다.

이런 요청과 응답 모두 AWS SDK 가 구성하므로 개발자는 어플리케이션 로직에만 집중하면 된다.

Pets Table 에서 특정 키의 Item 을 GetItem 으로 읽어오는 요청 예)

Data Type Descriptors

요청/응답 JSON 데이터에는 각 Attribute 의 데이터 타입 서술자(Data Type Descriptors) 를 포함시켜야 한다.

String (S), Number (N), Binary (B), Boolean (BOOL), Null (NULL), Map (M), List (L), String Set (SS), Number Set (NS), Binary Set (BS)

특히, JSON 으로 요청할 때 int, long, double 같은 숫자 형식은 DynamoDB 의 데이터 타입에 정확히 매핑하기 위해 숫자값을 문자열로 변환해야 한다.

binary 데이터를 DynamoDB 로 보내려면 Base64 형식으로 인코딩해야 한다. (DynamoDB 는 요청을 받아 Base64 를 다시 binary 로 디코딩한다.)

데이터 쓰기

SQL 의 INSERT INTO 와 같은 역할이다.

Item 을 추가하려면 PutItem 작업에 위와 같은 파라미터를 전달한다.

복수의 데이터를 BatchWriteItem 작업으로 한번에 추가하는 것도 가능하다.

• TableName – 데이터를 추가할 Table 이름.
• Item - Primary Key 이외의 Attribute 는 데이터 타입과 함께 자동 생성된다.

데이터 읽기

단일 Item 을 읽기 위해 GetItem 작업에 Table 이름과 Primary Key 를 전달한다.

기본적으로 해당 Item 의 모든 Attributes 를 가져오지만 ProjectionExpression 파라미터로 특정 Attributes 만 반환할 수 있다.

Query 작업으로 조건을 지정하여 여러 Item 을 읽을 수도 있다.

KeyConditionExpression 에 Primary key 를 지정하고 (sort key 에 범위 지정 가능),

ExpressionAttributeValues 는 Expression 파라미터들에 바인드 변수를 사용하여 값을 전달한다.

FilterExpression 으로 조건을 지정하여 일부 Items 을 결과에서 제거할 수 있다.

Scan 작업으로 Table 의 전에 Item 을 읽거나 ProjectionExpression 에 Attribute 는 지정하여, 결과에서 제외시킬 수 있다.

Index 에 대하여 Query 나 Scan 을 할 경우에는 IndexName 파라미터만 추가하면 된다.

데이터 수정

위와 같이 UpdateItem 작업에 파라미터를 전달하여 단일 Attribute 를 수정할 수 있다.

UpdateItem 은 개별 Attribute 를 교체하는 것이 아니라 Item 전체를 교체한다.

해당하는 Primary key 가 존재하면 Attribute 를 업데이트 하고, 존재하지 않으면 이 Item 을 추가한다.

ConditionExpression 에 조건을 설정하여 true 일 때만 수정을 수행하도록 할 수도 있다.

또 Number 데이터 타입의 Attribute 에서 숫자 증감도 지원한다.

위 예에서 ReturnValues 파라미터의 UPDATED_NEW 는 업데이트된 Attribute 의 새 값을 반환한다.

데이터 삭제

DeleteItem 작업에 TableName 과 Primary key 를 지정하면 해당 데이터를 삭제한다.

ConditionExpression 에 조건을 설정하여 true 일 때만 삭제를 수행하도록 할 수도 있다.

복수의 Items 를 동시에 삭제하는 BatchWriteItem 작업을 지원한다.

Table 생성

SQL 의 CREATE TABLE 과 같은 역할이다.

Table 을 생성하려면 다음 파라미터를 CreateTable 작업에 전달해야 한다.

• TableName – Table 이름.
• KeySchema – Primary Key 에 사용되는 Attribute.
• AttributeDefinitions – Primary Key 의 데이터 형식.
• ProvisionedThroughput – RCU / WCU 설정.

Table 읽기/삭제

DescribeTable 작업에 TableName 을 전달하여 위처럼 Table 정보를 읽어올 수 있다.

DeleteTable 작업에 TableName 을 전달하여 Table 을 삭제할 수 있다.

Table 수정

UpdateTable 작업으로 Secondary Index 를 추가할 수도 있다.

• TableName – Index 가 연동될 Table 이름.
• AttributeDefinitions – Index 와 데이터 형식.
• GlobalSecondaryIndexUpdates – 생성하려는 Index 의 세부 사항.
• IndexName – Index 이름.
• KeySchema – Index Primary Key 에 사용되는 Attribute.
• Projection – Table 에서 Index 로 복사될 Attribute.
• ProvisionedThroughput – Index 의 RCU / WCU 설정