[AWS RDS MySQL] InnoDB cache warming

-          버퍼풀 정보를 저장하고 시작시 로드하여 워밍업 단계 생략하기

 

l  Version : AWS RDS MySQL 5.6 later

 

InnoDB cache warming(캐시워밍) DB 인스턴스가 종료될 버퍼 풀의 현재 상태를 저장한 다음 DB 인스턴스가 시작될 저장된 버퍼 정보를 다시 로드하여 MySQL DB 인스턴스에 대한 성능 향상을 제공할 있다. 뜻은 정상적인 데이터베이스 사용에서 버퍼풀의 워밍업 필요를 무시하고 대신 알려진 공통 쿼리에 대한 페이지로 버퍼풀을 미리 로드한다. 버퍼풀 정보를 저장하는 파일은 페이지 자체가 아니라 버퍼풀에 있는 페이지에 대한 메타데이터만 저장한다. 따라서 결과적으로 파일에 많은 저장공간이 필요하지 않다. 파일크기는 캐시 크기의 0.2% 정도이다. 예를들어 64GB캐시의 경우 캐시 워밍업 파일은 128MB이다. 캐시워밍에 대한 자세한 내용은 MySQL 공식 문서인 아래 링크에서 확인할 있다.

l  Saving and Restoring the Buffer Pool State : https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

 

AWS RDS에서는 MySQL 5.6 버전 이상에 대해서 InnoDB 캐시 워밍업을 지원한다. InnoDB 캐시 워밍업을 활성화 하려면 DB 인스턴스의 파라미터 그룹에서 innodb_buffer_pool_dump_at_shutdown,  innodb_buffer_pool_load_at_startup 파라미터를 1 설정해야 한다. 해당 파라미터 값을 변경하면 해당 파라미터 그룹을 사용하는 모든 MySQL DB 인스턴스에 영향이 있기 때문의 사용시 주의하도록 한다. 특정 MySQL 대해서만 InnoDB 캐시 워밍업을 활성화 하려면 해당 인스턴스에 대한 파라미터 그룹을 생성 하도록 한다.

 

InnoDB 캐시 워밍은 주로 표준 스토리지를 사용하는 DB 인스턴스에 대한 성능 이점을 제공한다. PIOPS 스토리지를 사용하는 경우 일반적으로 상당한 성능 이점이 나타나지 않는다. InnoDB 캐시 워밍을 활성화 하였더라도 장애 조치중과 같이 MySQL DB 인스턴스가 정상적으로 종료되지 않으면 버퍼풀 상태가 디스크에 저장되지 않는다. 경우 MySQL DB 인스턴스가 다시 시작될 사용 가능한 모든 버퍼 파일을 로드 한다. 이런 경우에도 데이터베이스에는 아무런 이상이 없지만 복원된 버퍼풀은 가장 최근의 상태를 반영하지 않을 수도 있다. 시작 InnoDB 캐시를 워밍업 하는데 사용할 있는 버퍼풀의 최신 상태를 사용하려면 주기적으로 버퍼풀을 덤프하는 것이 좋다.

버퍼풀의 현재 상태를 디스크에 저장하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_dump_now();

 

디스크에 저장된 버퍼풀의 상태를 로드하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_load_now();

 

진행중인 로드 작업을 취소하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_load_abort();

 

버퍼풀을 주기적으로 자동으로 덤프하는 이벤트를 생성하여 사용할 경우 수동으로 매번 호출할 필요가 없다. 아래 스크립트는 매시간 버퍼풀을 덤프하는 periodic_buffer_pool_dump라는 이벤트를 생성한다.

CREATE EVENT periodic_buffer_pool_dump
ON SCHEDULE EVERY 1 HOUR
DO CALL mysql.rds_innodb_buffer_pool_dump_now();

 

 

[참고자료]

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.VersionMgmt

l  https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_dump_now.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_load_now.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_load_abort.html

 

 

 

2022-03-17 / Sungwook Kang / http://sungwookkang.com

 

 

AWS RDS, MySQL, InnoDB Cache warming, 캐시워밍업, 버퍼풀, buffer pool

Hive 데이터 입력시 노드당 처리 파티션 개수 초과 오류

 

·       Version : Hive

 

파티셔닝된Hive 테이블에 데이터 입력시 아래와 같은 오류가 발생하였다. 오류 메시지를 살펴보면 노드당 최대 동적 파티션 개수보다 많은 수의 동적 파티션이 생성되어 발생한 오류이다.

Error: java.lang.RuntimeException: org.apache.hadoop.hive.ql.metadata.HiveException: Hive Runtime Error while processing row {“col_1”:25513237,“col_2”:8104666,“col_3”:3808,“col_4”:6705,“col_4”:“2016-01-21 08:31:33",“col_6”:42,“col_7”:“471.00”,“col_8”:null} at org.apache.hadoop.hive.ql.exec.mr.ExecMapper.map(ExecMapper.java:157) at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54) at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:465) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:349) at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:174) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875) at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:168) Caused by: org.apache.hadoop.hive.ql.metadata.HiveException: Hive Runtime Error while processing row {“col_1”:25513237,“col_2”:8104666,“col_3”:3808,“col_4”:6705,“col_5”:“2016-01-21 08:31:33",“col_6”:42,“col_7”:“471.00”,“col_8”:null} at org.apache.hadoop.hive.ql.exec.MapOperator.process(MapOperator.java:494) at org.apache.hadoop.hive.ql.exec.mr.ExecMapper.map(ExecMapper.java:148) ... 8 more Caused by: org.apache.hadoop.hive.ql.metadata.HiveFatalException: [Error 20004]: Fatal error occurred when node tried to create too many dynamic partitions. The maximum number of dynamic partitions is controlled by hive.exec.max.dynamic.partitions and hive.exec.max.dynamic.partitions.pernode. Maximum was set to 100 partitions per node, number of dynamic partitions on this node: 101 at org.apache.hadoop.hive.ql.exec.FileSinkOperator.getDynOutPaths(FileSinkOperator.java:951) at org.apache.hadoop.hive.ql.exec.FileSinkOperator.process(FileSinkOperator.java:722) at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:882) at org.apache.hadoop.hive.ql.exec.SelectOperator.process(SelectOperator.java:95) at org.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:882) at org.apache.hadoop.hive.ql.exec.TableScanOperator.process(TableScanOperator.java:130) at org.apache.hadoop.hive.ql.exec.MapOperator$MapOpCtx.forward(MapOperator.java:146) at org.apache.hadoop.hive.ql.exec.MapOperator.process(MapOperator.java:484) ... 9 more

 

Hive 노드당 최대 동적 파티션 기본값은 100으로 설정되어 있다. 문제를 해결하기 위해서는 아래와 같은 명령을 사용하여 노드당 최대 동적 파티션 갯수 설정을 변경할 있다.

set hive.exec.max.dynamic.partitions=100000;
set hive.exec.max.dynamic.partitions.pernode=100000;

 

노드당 파일 갯수 초과할 경우에도 비슷한 오류가 발생한다. 아래 같은 오류 구문이 발생 때에는 파일 갯수의 설정을 오류가 발생한 최대 값보다 크게 설정할 있도록 한다.

[Fatal Error] total number of created files now is 100028, which exceeds 100000. Killing the job.

 

set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;
set hive.exec.max.dynamic.partitions.pernode=100000;
set hive.exec.max.dynamic.partitions=100000;
set hive.exec.max.created.files=900000;

 

 

위와 같이 설정값을 변경하기에 앞서 Hive에서 이렇게 많은 파티션 또는 파일을 생성하는지 생각해보아야 한다. 대부분의 경우 사용자 설정값 범위 내에서 파티션이 이루어진다는 가정하에 사용하는데,  이렇게 한계를 벗어난 다는 것은 파티션 키를 잘못 배치했거나 파티션 처리에 적절하지 않는 데이터셋을 사용했을 가능성이 크다. 그럼에도 불구하고 파티션을 늘려야한다고 생각되면 옵션을 사용하여 적절할 임계치를 조절할 있도록 한다.

 

2021-09-13 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, 파티션 테이블, 동적 파티션 개수 초과,

Kubernetes 장점

 

·       Version :

 

 쿠버네티스(Kubernetes) 환경에서는 컨테이너에 애플리케이션에 필요한 모든 항목이 포함되어 있기 때문에 시스템 관리자가 애플리케이션을 실행하기 위해 아무것도 설치할 필요가 없다.

·       애플리케이션 배포 단순화 : 쿠버네티스는 모든 워커 노드를 단일 플랫폼으로 제공하므로 애플리케이션 개발자는 자체적으로 배포할 있으며 클러스터를 구성하는 서버에 대해서 필요가 없다. 특히 특정 컨테이너가  SSD에서만 실행되거나 또는 HDD에서만 실행되어야 하는  경우처럼 특정 리소스가 필요한 경우 쿠버네티스 노드에서 필요한 리소스가 있는 노드를 선택해서 배포할 있다.

·       효율적인 하드웨어 활용 : 쿠버네티스환경에서 애플리케이션을 배포,실행하면 애플리케이션 리소스 요구사항에 따라 사용 가능한 가장 적합한 노드가 선택되어 할당된다. 또한 특정 노드에 애플리케이션을 종속시키지 않는다면 클러스터를 자유럽게 이동할 있어 리소스 가용 상태에 따라 자동으로 이동하거나 매치하여 사용할 있다.

·       자동 복구 모니터링 : 특정 클러스터에 종속되지 않으면 자유롭게 클러스터를 이동할 있기 때문에 이러한 장점으로 인해 모니터링 중에 특정 노드에 장애가 발생하면 자동으로 다른 노드에 애플리케이션이 재배치 되어 실행되기 때문에 야간이나 장애 발생시 즉시 대응할 필요가 없다.

·     오토스케일링 : 쿠버네티스는 애플리케이션에서 사용하는 리소스를 모니터링 하고 애플리케이션에서 실행되는 인스턴스 수를 조정하도록 지시할 있다.

·       개발 환경 단순화 : 애플리케이션이 개발 운영 환경이 동일하기 때문에 개발자는 본인 컴퓨터에서 개발하고 버그를 수정하고, 테스트한 완성된 애플리케이션 환경 그대로 운영 환경에서 실행할수 있다.

 

 

2021-07-30 / Sungwook Kang / https://sungwookkang.com

 

 

Kubernetes, 쿠버네티스

Kubernetes 마스터 노드, 워커 노드

 

·       Version :

 

 쿠버네티스(Kubernetes) 클러스터에서 마스터 노드는 전체 쿠버네티스 시스템을 관리하고 통제하는 쿠버네티스 컨트롤 플레인을 관장한다. 워커 노드는 실제 배포하고자 하는 애플리케이션 실행을 담당한다.

마스터 노드(컨트롤 플레인)에서는 클러스터를 관리하고 클러스터의 기능을 실행한다. 단일 마스터 노드에서 실행하거나 여러 노드로 분할 복제되어 고가용성을 보장할 있는 여러 구성요소로 구성 있다.

·       API Server : 사용자와 컨트롤 플레인과 통신하는 쿠버네티스 API

·       Scheduler : 애플리케이션을 예약하는 스케줄러로, 배포 가능한 구성 요서에 워커 노드 할당을 담당

·       Control Manager : 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 클러스터 기능을 실행

·       etcd : 클러스터 구성을 저장하는 분산 데이터 스토리지  

 

워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템으로 서비스 실행, 모니터링을 제공한다.

·       Kubelet : API 서버와 통신하고 노드에서 컨테이너를 관리

·       Kube-proxy : 애플리케이션 구성 요소 간에 네트워크 트래픽을 분산하는 쿠버네티스 서비스 프록시

 

 

2021-07-28 / Sungwook Kang / https://sungwookkang.com

 

 

Kubernetes, 쿠버네티스, 마스터 노드, 워커 노드, 컨트롤 플레인, Control Plane

+ Recent posts