최신 리포트 다운로드 지금 바로 문의하기
최신 리포트 다운로드 지금 바로 문의하기
Author

Sangmi Park

자본감소에 따른 구주권 제출공고

by Sangmi Park

자본감소에 따른 구주권 제출공고

베스핀글로벌 주식회사(이하 “회사”)는 상법 제438조 제2항에 의거한 자본감소를 2023년 7월 31일 개최한 임시주주총회에서 아래와 같이 결의하였기에 공고하오니 주주 및 질권자께서는 소유주식을 제출하고 신주권을 수령하시기 바랍니다.

다음

1. 자본감소에 관한 사항
(1) 감자의 종류와 수: 보통주 4,765,805주 (1주당 액면가 10,000원)
(2) 감자방법: 액면가 10,000원의 보통주 100주를 동일한 액면주식 1주로 병합(무상균등감자)
(3) 감자비율: 100 대 1 (99%)
(4) 감자기준일: 2023년 9월 1일
(5) 감자사유: 결손금 보전을 통한 재무구조 개선
(6) 감자 전후 자본금
– 감자 전: 47,658,050,000원
– 감자 후: 476,570,000원
(7) 감자 전후 발행 주식수
– 감자 전: 4,765,805주
– 감자 후: 47,657주

2. 구주권 제출 및 신주권 수령에 관한 사항
(1) 구주권 제출 기간: 2023년 8월 1일 ~ 2023년 8월 31일
(2) 신주권 교부예정일: 2023년 9월 1일
(3) 구주권 제출 및 신주권 수령 장소: 서울특별시 서초구 강남대로 327, 13층, 14층, 15층, 16층(서초동, 대륭서초타워)

3. 기타사항
(1) 1주 미만 단주 처리방법: 액면가를 기준으로 계산하여 현금 지급함
(2) 자본감소 결의의 건과 관련한 기타 세부사항의 집행은 대표이사에게 위임함
(3) 상기 일정은 관계기관과 일정협의에 따라 변경될 수 있습니다.
(4) 상기 감자결정은 상법 제438조 제2항에 의거한 결손금 보전을 위한 것으로, 상법 제439조 2항에 따라‘채권자보호절차(채권자 이의제출)’를 생략합니다.

2023년   7월   31일

베스핀글로벌 주식회사
서울특별시 서초구 강남대로 327, 13층, 14층, 15층, 16층(서초동, 대륭서초타워)

대표이사 장인수

[MySQL] Partition add & drop 자동화 테스트

TECH
by Sangmi Park

1. Partition Drop

월 별 혹은 년도 별 Partition Table을 관리할 때, 과거 파티션을 삭제하는 과정을 크게 두 가지의 방법으로 테스트해 보았습니다. 

해당 테스트를 진행한 이유는 두 가지 방법에 대해 효용성을 체크하기 위함이며, 
alter drop partition 보다 exchange partition이 수행 속도가 빠르다면 Partition Table에 걸리는 Lock을 최소화하여 서비스를 원활하게 할 수 있지 않을까라는 기대를 예상했습니다.

첫 번째는 별도의 일반 테이블(0건)을 만들고, Drop할 파티션과 Exchange를 한 후 일반 테이블을 삭제하는 방법입니다. 
이 경우 일반 테이블에 과거 테이블을 이력으로도 남길 수 있다는 장점이 있습니다. 

두 번째는 대상 Partition Table에 ALTER DROP PARTITION 을 수행하여 바로 DDL을 날리는 과정이며, online DDL을 수행하는 과정에서 DML을 따로 받을 수 있습니다.

1-1. TEST 환경구성

항목설 명

Database

RDS MySQL 8.0.23

Sysbench

[ec2-user@ip-10-0-130-172 ~]$ sysbench –version

sysbench 1.0.20

Test Table

1. Description

mysql> CREATE TABLE `sbtest1` (

 `id` int(11) NOT NULL AUTO_INCREMENT,

 `k` int(11) NOT NULL DEFAULT ‘0’,

 `c` char(120) NOT NULL DEFAULT ”,

 `pad` char(60) NOT NULL DEFAULT ”,

 PRIMARY KEY (`id`),

 KEY `k_1` (`k`)

) ENGINE=InnoDB AUTO_INCREMENT=100000001 DEFAULT CHARSET=utf8

PARTITION BY RANGE (id)

(PARTITION p1 VALUES LESS THAN (30000000) ENGINE = InnoDB,

 PARTITION p2 VALUES LESS THAN (60000000) ENGINE = InnoDB,

 PARTITION p3 VALUES LESS THAN (90000000) ENGINE = InnoDB,

 PARTITION p4 VALUES LESS THAN (120000000) ENGINE = InnoDB);

2. Data 적재

Sysbench를 이용해 sbtest1 테이블에 1억건 적재

sysbench –db-driver=mysql –mysql-host=bjh-test-partition.cnaj6ucovzx2.ap-northeast-2.rds.amazonaws.com –mysql-user=admin –mysql-password=qkswlgus –mysql-db=sysbench –table-size=100000000 –tables=1 /usr/share/sysbench/oltp_read_only.lua prepare

1-2. Exchange Partition Test

시나리오

설 명

1) 파티션테이블 상태 조회

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

+————–+————+—————-+—————————-+——————+———————–+————+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | PARTITION_METHOD | PARTITION_DESCRIPTION | TABLE_ROWS |

+————–+————+—————-+—————————-+——————+———————–+————+

| sysbench     | sbtest1    | p2             |                          1 | RANGE            | 60000000              |   29592144 |

| sysbench     | sbtest1    | p3             |                          2 | RANGE            | 90000000              |   29592576 |

| sysbench     | sbtest1    | p4             |                          3 | RANGE            | 120000000             |    9863928 |

+————–+————+—————-+—————————-+——————+———————–+————+

2) 원본 테이블 Row확인

mysql> select table_schema, table_name, partition_name, table_rows from information_schema.PARTITIONS where TABLE_NAME=’sbtest1′;

+————–+————+—————-+————+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | TABLE_ROWS |

+————–+————+—————-+————+

| sysbench     | sbtest1    | p2             |   29592144 |

| sysbench     | sbtest1    | p3             |   29592576 |

| sysbench     | sbtest1    | p4             |    9863928 |

+————–+————+—————-+————+

4 rows in set (0.01 sec)

 

 

3) Drop Partition 수행

mysql> alter table sbtest1 drop partition p2;

MySQL [sysbench]> alter table sbtest1 drop partition p2;

Query OK, 0 rows affected (0.16 sec)

Records: 0  Duplicates: 0  Warnings: 0

1-3. ALTER DROP Partition

시나리오

설 명

1) 파티션테이블 상태 조회

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

+————–+————+—————-+—————————-+——————+———————–+————+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | PARTITION_METHOD | PARTITION_DESCRIPTION | TABLE_ROWS |

+————–+————+—————-+—————————-+——————+———————–+————+

| sysbench     | sbtest1    | p2             |                          1 | RANGE            | 60000000              |   29592144 |

| sysbench     | sbtest1    | p3             |                          2 | RANGE            | 90000000              |   29592576 |

| sysbench     | sbtest1    | p4             |                          3 | RANGE            | 120000000             |    9863928 |

+————–+————+—————-+—————————-+——————+———————–+————+

2) 원본 테이블 Row확인

mysql> select table_schema, table_name, partition_name, table_rows from information_schema.PARTITIONS where TABLE_NAME=’sbtest1′;

+————–+————+—————-+————+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | TABLE_ROWS |

+————–+————+—————-+————+

| sysbench     | sbtest1    | p2             |   29592144 |

| sysbench     | sbtest1    | p3             |   29592576 |

| sysbench     | sbtest1    | p4             |    9863928 |

+————–+————+—————-+————+

4 rows in set (0.01 sec)

 

 

3) Drop Partition 수행

mysql> alter table sbtest1 drop partition p2;

MySQL [sysbench]> alter table sbtest1 drop partition p2;

Query OK, 0 rows affected (0.16 sec)

Records: 0  Duplicates: 0  Warnings: 0

2. Partition Add

파티션 테이블에 maxvalue 파티션을 가지고 있을 경우와 없는 경우 add partition 을 할 수 있는 방법또한 달라집니다. maxvalue 파티션이 없을 경우에는 단순히 add partition이 가능하지만 있을 경우에는 add partition을 진행할 경우 Error Code : 1481이 발생하게 됩니다.

2-1. Maxvalue 파티션이 없을 경우

시나리오설 명

1) 파티션테이블 상태 조회

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

+————–+————+—————-+—————————-+———————–+————+————–+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | PARTITION_DESCRIPTION | TABLE_ROWS | INDEX_LENGTH |

+————–+————+—————-+—————————-+———————–+————+————–+

| sysbench     | sbtest1    | p3             |                          1 | 90000000              |   29592576 |    624902144 |

| sysbench     | sbtest1    | p4             |                          2 | 120000000             |    9863928 |    248266752 |

| sysbench     | sbtest1    | p5             |                          3 | 150000000             |          0 |        16384 |

+————–+————+—————-+—————————-+———————–+————+————–+

 

2) 파티션 추가

mysql> alter table sbtest1 add partition (partition p6 values less than (180000000));

MySQL [sysbench]> alter table sbtest1 add partition (partition p6 values less than (180000000));

Query OK, 0 rows affected (0.12 sec)

Records: 0  Duplicates: 0  Warnings: 0

3) 파티션테이블 상태 조회

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

+————–+————+—————-+—————————-+———————–+————+————–+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | PARTITION_DESCRIPTION | TABLE_ROWS | INDEX_LENGTH |

+————–+————+—————-+—————————-+———————–+————+————–+

| sysbench     | sbtest1    | p3             |                          1 | 90000000              |   29592576 |    624902144 |

| sysbench     | sbtest1    | p4             |                          2 | 120000000             |    9863928 |    248266752 |

| sysbench     | sbtest1    | p5             |                          3 | 150000000             |          0 |        16384 |

| sysbench     | sbtest1    | p6             |                          4 | 180000000             |          0 |        16384 |

+————–+————+—————-+—————————-+———————–+————+————–+

2-2. Maxvalue 파티션이 있을 경우

시나리오설 명

1) 파티션테이블 상태 조회

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

+————–+————+—————-+—————————-+———————–+————+————–+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | PARTITION_DESCRIPTION | TABLE_ROWS | INDEX_LENGTH |

+————–+————+—————-+—————————-+———————–+————+————–+

| sysbench     | sbtest1    | p3             |                          1 | 90000000              |   29592576 |    624902144 |

| sysbench     | sbtest1    | p4             |                          2 | 120000000             |    9863928 |    248266752 |

| sysbench     | sbtest1    | p5             |                          3 | 150000000             |          0 |        16384 |

| sysbench     | sbtest1    | p6             |                          4 | 180000000             |          0 |        16384 |

| sysbench     | sbtest1    | p7             |                          5 | MAXVALUE              |          0 |        16384 |

+————–+————+—————-+—————————-+———————–+————+————–+

 

2) 파티션 추가 (에러발생)

mysql> alter table sbtest1 add partition (partition p6 values less than (200000000));

MySQL [sysbench]> alter table sbtest1 add partition (partition p6 values less than (200000000));

ERROR 1481 (HY000): MAXVALUE can only be used in last partition definition

3) REORGANIZE 파티션

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

MySQL [sysbench]>  ALTER TABLE sbtest1

    -> REORGANIZE PARTITION p7 into (

    ->   partition p7 values less than (200000000) engine=innodb,

    ->   PARTITION p8 VALUES LESS THAN (MAXVALUE) ENGINE = InnoDB

    -> );

Query OK, 0 rows affected (0.12 sec)

Records: 0  Duplicates: 0  Warnings: 0

4) 파티션테이블 상태 조회

mysql> select * from information_schema.partitions where table_schema=’sysbench’;

+————–+————+—————-+—————————-+———————–+————+————-+

| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | PARTITION_DESCRIPTION | TABLE_ROWS | DATA_LENGTH |

+————–+————+—————-+—————————-+———————–+————+————-+

| sysbench     | sbtest1    | p3             |                          1 | 90000000              |   29592576 |  6740246528 |

| sysbench     | sbtest1    | p4             |                          2 | 120000000             |    9863928 |  2248146944 |

| sysbench     | sbtest1    | p5             |                          3 | 150000000             |          0 |       16384 |

| sysbench     | sbtest1    | p6             |                          4 | 180000000             |          0 |       16384 |

| sysbench     | sbtest1    | p7             |                          5 | 200000000             |          0 |       16384 |

| sysbench     | sbtest1    | p8             |                          6 | MAXVALUE              |          0 |       16384 |

3. Partition 관리 자동화

신규 파티션 추가와 삭제를 매번 수작업으로 진행할 수는 없으므로 이를 자동으로 관리하기 위한 프로시저 및 이벤트를 생성하는 과정을 진행하였습니다. 파티션 관리 요건 중 가장 중요한 것은 다음의 세가지입니다.

1. 어떠한 이유에서든지 프로시저가 동작하지 않은 경우라도 데이터 Insert 실패가 발생하지 않도록 할 것.

2. 프로시저가 일정기간 동작하지 않고, 다시 재기동 되는 경우에 프로시저가 주기적으로 동작했던 것과 동일한 파티션 구조를 생성할 것.

3. 파티션 삭제시 Table Lock으로 인한 영향을 최소화할 것.

처음 이 파티션 테스트를 진행하기 전에는 파티션의 MAXVALUE가 테이블의 관리나 성능적인 측면에서 필요 없다고 생각하였으나, 1번의 내용과 같이 파티션 관리 프로시저가 며칠 동안 동작하지 않을 경우 서비스 자체가 운영되지 않을 수 있기 때문에 반드시 존재해야 한다고 제 개인적인 생각을 바꾸게 되었습니다. 또한, 앞서 테스트한 경우와 마찬가지로 파티션 drop은 단순한 alter문이 아닌 partition exchange로 진행하여 3번에 해당하는 Table Lock 최소화도 고려하였습니다.

3-1. Partition Create Procedure

Create Partition Procedure 문 (Terminal 수행을 위해 DELIMITER 변경 후 진행)

DELIMITER $$

CREATE PROCEDURE create_partition(p_dbname varchar(255), p_tbname varchar(255), p_future INT, p_interval INT)

SQL SECURITY INVOKER

BEGIN

   DECLARE x, max_pdesc, new_pdesc INT;

   DECLARE pname VARCHAR(64);

   DECLARE alter_cmd VARCHAR(1024);

  — 현재 테이블의 파티션의 가장 마지막 파티션의 HIGH VALUE 값을 구함

   SELECT MAX(PARTITION_DESCRIPTION) – TO_DAYS(current_date()) INTO x FROM information_schema.PARTITIONS

   WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION != ‘MAXVALUE’ ;

   — 파티션 미리 생성할 기한까지 지정한 interval에 맞도록 파티션 추가

   — 파티션 추가는 ADD PARTITION이 아닌 MAXVALUE 파티션의 REORGANIZE로 처리됨

   WHILE x <= p_future DO

      SELECT

         CONCAT(‘p’, DATE_FORMAT(current_date() + interval MAX(PARTITION_DESCRIPTION) – TO_DAYS(current_date()) day, ‘%Y%m%d’)),

         MAX(PARTITION_DESCRIPTION),

         MAX(PARTITION_DESCRIPTION) + p_interval

      INTO pname, max_pdesc, new_pdesc

      FROM information_schema.PARTITIONS

      WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION!=’MAXVALUE’;

      IF max_pdesc < new_pdesc THEN

         SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘.’, p_tbname, ‘ REORGANIZE PARTITION pMAXVALUE INTO (‘,

                          ‘PARTITION ‘, pname, ‘ VALUES LESS THAN (‘, new_pdesc, ‘), PARTITION pMAXVALUE VALUES LESS THAN MAXVALUE)’ );

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

      END IF;

      SET x = x + p_interval;

   END WHILE;

   — 파티션 정보 출력 (옵션)

   SELECT current_date() + interval MAX(PARTITION_DESCRIPTION) – TO_DAYS(current_date()) – 1 day AS Last_Date,

          COUNT(*) AS Partitions_For_Future

   FROM information_schema.PARTITIONS

   WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION != ‘MAXVALUE’

      AND PARTITION_DESCRIPTION > TO_DAYS(current_date()) + 1;

END $$

DELIMITER ;

3-1-1. Partition Create Procedure

시나리오설 명

1) 파티션테이블 생성

Range Partition Create 구문 (Maxvalue 파티션 필요)

CREATE TABLE partitiontest (

  id int NOT NULL AUTO_INCREMENT,

  some_data varchar(100),

  createdAt datetime(6) NOT NULL,

  modifiedAt datetime(6) DEFAULT NULL,

  PRIMARY KEY (id,createdAt)

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

partition by range (to_days(createdAt))

(

partition p20221201 values less than (to_days(‘2022-12-02’)) ENGINE = InnoDB,

partition p20221202 values less than (to_days(‘2022-12-03’)) ENGINE = InnoDB,

partition p20221203 values less than (to_days(‘2022-12-04’)) ENGINE = InnoDB,

partition p20221204 values less than (to_days(‘2022-12-05’)) ENGINE = InnoDB,

partition p20221205 values less than (to_days(‘2022-12-06’)) ENGINE = InnoDB,

partition p20221206 values less than (to_days(‘2022-12-07’)) ENGINE = InnoDB,

partition p20221207 values less than (to_days(‘2022-12-08’)) ENGINE = InnoDB,

partition p20221208 values less than (to_days(‘2022-12-09’)) ENGINE = InnoDB,

partition p20221209 values less than (to_days(‘2022-12-10’)) ENGINE = InnoDB,

partition p20221210 values less than (to_days(‘2022-12-11’)) ENGINE = InnoDB,

partition p20221211 values less than (to_days(‘2022-12-12’)) ENGINE = InnoDB,

partition p20221212 values less than (to_days(‘2022-12-13’)) ENGINE = InnoDB,

partition p20221213 values less than (to_days(‘2022-12-14’)) ENGINE = InnoDB,

partition p20221214 values less than (to_days(‘2022-12-15’)) ENGINE = InnoDB,

partition p20221215 values less than (to_days(‘2022-12-16’)) ENGINE = InnoDB,

partition p20221216 values less than (to_days(‘2022-12-17’)) ENGINE = InnoDB,

partition p20221217 values less than (to_days(‘2022-12-18’)) ENGINE = InnoDB,

partition p20221218 values less than (to_days(‘2022-12-19’)) ENGINE = InnoDB,

partition p20221219 values less than (to_days(‘2022-12-20’)) ENGINE = InnoDB,

partition pMAXVALUE values less than (maxvalue) ENGINE = InnoDB

);

2) 파티션 조회

MySQL [bjh]> select * from information_schema.partitions where table_schema=’bjh’ and table_name=’partitiontest’;

+————–+—————+—————-+—————–+———————-+———————–+———————+

| TABLE_SCHEMA | TABLE_NAME    | PARTITION_NAME |PARTITION_METHOD | PARTITION_EXPRESSION | PARTITION_DESCRIPTION | CREATE_TIME         |

+————–+—————+—————-+—————–+———————-+———————–+———————+

| bjh          | partitiontest | p20221201      |RANGE            | to_days(`createdAt`) | 738856                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221202      |RANGE            | to_days(`createdAt`) | 738857                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221203      |RANGE            | to_days(`createdAt`) | 738858                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221204      |RANGE            | to_days(`createdAt`) | 738859                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221205      |RANGE            | to_days(`createdAt`) | 738860                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221206      |RANGE            | to_days(`createdAt`) | 738861                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221207      |RANGE            | to_days(`createdAt`) | 738862                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221208      |RANGE            | to_days(`createdAt`) | 738863                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221209      |RANGE            | to_days(`createdAt`) | 738864                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221210      |RANGE            | to_days(`createdAt`) | 738865                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221211      |RANGE            | to_days(`createdAt`) | 738866                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221212      |RANGE            | to_days(`createdAt`) | 738867                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221213      |RANGE            | to_days(`createdAt`) | 738868                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221214      |RANGE            | to_days(`createdAt`) | 738869                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221215      |RANGE            | to_days(`createdAt`) | 738870                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221216      |RANGE            | to_days(`createdAt`) | 738871                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221217      |RANGE            | to_days(`createdAt`) | 738872                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221218      |RANGE            | to_days(`createdAt`) | 738873                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221219      |RANGE            | to_days(`createdAt`) | 738874                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | pMAXVALUE      |RANGE            | to_days(`createdAt`) | MAXVALUE              | 2022-12-19 04:47:35 |

+————–+—————+—————-+—————–+———————-+———————–+———————+

3) 프로시저 수행

MySQL [mysql]> call create_partition(‘bjh’, ‘partitiontest’, 1, 1);

프로시저 해석 : bjh.partitiontest 테이블을 금일 날짜(테스트 날짜 :2022-12-19) 기준으로 1일 후까지 1일 간격으로 파티션을 생성.

+————+———————–+

| Last_Date  | Partitions_For_Future |

+————+———————–+

| 2022-12-20 |                     1 |

+————+———————–+

1 row in set (0.25 sec)

Query OK, 0 rows affected (0.25 sec)

3-1) 파티션 결과 조회

MySQL [mysql]> select * from information_schema.partitions where table_schema=’bjh’ and table_name=’partitiontest’;

+————–+—————+—————-+—————–+———————+———————–+———————+

| TABLE_SCHEMA | TABLE_NAME    | PARTITION_NAME |PARTITION_METHOD |PARTITION_EXPRESSION | PARTITION_DESCRIPTION | CREATE_TIME         |

+————–+—————+—————-+—————–+———————+———————–+———————+

| bjh          | partitiontest | p20221201      |RANGE            |to_days(`createdAt`) | 738856                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221202      |RANGE            |to_days(`createdAt`) | 738857                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221203      |RANGE            |to_days(`createdAt`) | 738858                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221204      |RANGE            |to_days(`createdAt`) | 738859                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221205      |RANGE            |to_days(`createdAt`) | 738860                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221206      |RANGE            |to_days(`createdAt`) | 738861                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221207      |RANGE            |to_days(`createdAt`) | 738862                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221208      |RANGE            |to_days(`createdAt`) | 738863                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221209      |RANGE            |to_days(`createdAt`) | 738864                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221210      |RANGE            |to_days(`createdAt`) | 738865                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221211      |RANGE            |to_days(`createdAt`) | 738866                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221212      |RANGE            |to_days(`createdAt`) | 738867                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221213      |RANGE            |to_days(`createdAt`) | 738868                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221214      |RANGE            |to_days(`createdAt`) | 738869                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221215      |RANGE            |to_days(`createdAt`) | 738870                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221216      |RANGE            |to_days(`createdAt`) | 738871                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221217      |RANGE            |to_days(`createdAt`) | 738872                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221218      |RANGE            |to_days(`createdAt`) | 738873                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221219      |RANGE            |to_days(`createdAt`) | 738874                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | p20221220      |RANGE            |to_days(`createdAt`) | 738875                | 2022-12-19 05:09:59 |

| bjh          | partitiontest | pMAXVALUE      |RANGE            |to_days(`createdAt`) | MAXVALUE              | 2022-12-19 05:09:59 |

+————–+—————+—————-+—————–+———————+———————–+———————+

4) 프로시저 수행

MySQL [mysql]> call create_partition(‘bjh’, ‘partitiontest’, 7, 1);

프로시저 해석 : bjh.partitiontest 테이블을 금일 날짜(테스트 날짜 :2022-12-19) 기준으로 7일 후까지 1일 간격으로 파티션을 생성.

+————+———————–+

| Last_Date  | Partitions_For_Future |

+————+———————–+

| 2022-12-26 |                     7 |

+————+———————–+

1 row in set (1.52 sec)

Query OK, 0 rows affected (1.52 sec)

4-1) 파티션 결과 조회

MySQL [mysql]> select * from information_schema.partitions where table_schema=’bjh’ and table_name=’partitiontest’;

+————–+—————+—————-+—————–+———————-+———————–+———————+

| TABLE_SCHEMA | TABLE_NAME    | PARTITION_NAME |PARTITION_METHOD | PARTITION_EXPRESSION | PARTITION_DESCRIPTION | CREATE_TIME         |

+————–+—————+—————-+—————–+———————-+———————–+———————+

| bjh          | partitiontest | p20221201      |RANGE            | to_days(`createdAt`) | 738856                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221202      |RANGE            | to_days(`createdAt`) | 738857                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221203      |RANGE            | to_days(`createdAt`) | 738858                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221204      |RANGE            | to_days(`createdAt`) | 738859                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221205      |RANGE            | to_days(`createdAt`) | 738860                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221206      |RANGE            | to_days(`createdAt`) | 738861                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221207      |RANGE            | to_days(`createdAt`) | 738862                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221208      |RANGE            | to_days(`createdAt`) | 738863                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221209      |RANGE            | to_days(`createdAt`) | 738864                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221210      |RANGE            | to_days(`createdAt`) | 738865                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221211      |RANGE            | to_days(`createdAt`) | 738866                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221212      |RANGE            | to_days(`createdAt`) | 738867                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221213      |RANGE            | to_days(`createdAt`) | 738868                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221214      |RANGE            | to_days(`createdAt`) | 738869                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221215      |RANGE            | to_days(`createdAt`) | 738870                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221216      |RANGE            | to_days(`createdAt`) | 738871                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221217      |RANGE            | to_days(`createdAt`) | 738872                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221218      |RANGE            | to_days(`createdAt`) | 738873                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221219      |RANGE            | to_days(`createdAt`) | 738874                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221220      |RANGE            | to_days(`createdAt`) | 738875                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221221      |RANGE            | to_days(`createdAt`) | 738876                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221222      |RANGE            | to_days(`createdAt`) | 738877                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221223      |RANGE            | to_days(`createdAt`) | 738878                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221224      |RANGE            | to_days(`createdAt`) | 738879                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221225      |RANGE            | to_days(`createdAt`) | 738880                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | p20221226      |RANGE            | to_days(`createdAt`) | 738881                | 2022-12-19 05:11:32 |

| bjh          | partitiontest | pMAXVALUE      |RANGE            | to_days(`createdAt`) | MAXVALUE              | 2022-12-19 05:11:32 |

+————–+—————+—————-+—————–+———————-+———————–+———————+

3-1-2. 알게된 점

해당 프로시저를 수행할 때, 파티션에 중복 (시나리오3), 4)번 과정에서는2022-12-20의 파티션이 중복 수행됨.)이 있다고 하더라도 오류없이 파티션이 정상적으로 추가가 되었습니다. 또한, information_schema.partitions 테이블의 create_time 컬럼을 조회할 때 추가된 컬럼에 한해서만 갱신이 되는 것이 아니라, 파티션 전체에 대해 파티션을 추가한 시간으로 동일하게 갱신되어 있었습니다.

 

3-2. Partition Drop Procedure

Drop Partition Procedure 문 (Terminal 수행을 위해 DELIMITER 변경 후 진행)

DELIMITER $$

CREATE PROCEDURE delete_partition(p_dbname varchar(255), p_tbname varchar(255), p_del_date INT)

SQL SECURITY INVOKER

BEGIN

   DECLARE done INT;

   DECLARE pname VARCHAR(64);

   DECLARE alter_cmd VARCHAR(1024);

   DECLARE deleted_partition VARCHAR(1024);

  — 삭제할 파티션 목록 취합

   DECLARE cur CURSOR FOR

      SELECT PARTITION_NAME FROM information_schema.PARTITIONS

      WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION!=’MAXVALUE’

        AND PARTITION_DESCRIPTION<=TO_DAYS(current_date()) – p_del_date ;

   DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

   SET done = 0;

   — 삭제 대상 파티션 목록 확인 및 작업 완료 후 출력 (옵션)

   SELECT GROUP_CONCAT(PARTITION_NAME) INTO deleted_partition

   FROM information_schema.PARTITIONS

   WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION!=’MAXVALUE’

     AND PARTITION_DESCRIPTION<=TO_DAYS(current_date()) – p_del_date ;

   OPEN cur;

   FETCH cur INTO pname;

   WHILE done = 0 DO

     — MySQL 5.6 버전 이상인 경우 동일 스키마로 빈 테이블을 만들어서 PARTITION EXCHANGE 처리 후 DROP PARTITION

     — 파티션 삭제 처리 시간 지연으로 인한 Table Lock 영향을 최소화하기 위함

      IF left(version(),3) >= ‘5.6’ THEN

         — make empty table for exchange

         SET @alter_sql := CONCAT(‘CREATE TABLE ‘, p_dbname, ‘._exchange_’, p_tbname,’_’,pname, ‘ LIKE ‘, p_dbname, ‘.’ , p_tbname);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

         SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘._exchange_’, p_tbname,’_’,pname, ‘ REMOVE PARTITIONING’);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

         — exchange

         SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘.’, p_tbname, ‘ EXCHANGE PARTITION ‘, pname, ‘ WITH TABLE ‘, p_dbname, ‘._exchange_’, p_tbname, ‘_’, pname);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

         — drop tmp table

         — SET @alter_sql := CONCAT(‘DROP TABLE ‘, p_dbname, ‘._exchange_’, p_tbname);

         — PREPARE alter_cmd FROM @alter_sql;

         — EXECUTE alter_cmd;

         — DEALLOCATE PREPARE alter_cmd;

      END IF;

      — 파티션 삭제

      SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘.’, p_tbname, ‘ DROP PARTITION ‘, pname);

      PREPARE alter_cmd FROM @alter_sql;

      EXECUTE alter_cmd;

      DEALLOCATE PREPARE alter_cmd;

      FETCH cur INTO pname;

   END WHILE;

   CLOSE cur;

   — 삭제 처리한 파티션 목록 출력 (옵션)

   SELECT deleted_partition AS Deleted_Partitions ;

END $$

DELIMITER ;

▶ Switching한 Temp Table을Drop하는 부분은 현재 진행중인 프로젝트에서 History보관주기가 변경될 수 있어 일단 주석으로 처리한 후 테스트를 진행하였습니다.

 

3-2-1. Partition Drop Procedure (임시테이블 유지)

시나리오설 명

1) 파티션테이블 생성

Range Partition Create 구문

CREATE TABLE partitiontest (

  id int NOT NULL AUTO_INCREMENT,

  some_data varchar(100),

  createdAt datetime(6) NOT NULL,

  modifiedAt datetime(6) DEFAULT NULL,

  PRIMARY KEY (id,createdAt)

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

partition by range (to_days(createdAt))

(

partition p20221201 values less than (to_days(‘2022-12-02’)) ENGINE = InnoDB,

partition p20221202 values less than (to_days(‘2022-12-03’)) ENGINE = InnoDB,

partition p20221203 values less than (to_days(‘2022-12-04’)) ENGINE = InnoDB,

partition p20221204 values less than (to_days(‘2022-12-05’)) ENGINE = InnoDB,

partition p20221205 values less than (to_days(‘2022-12-06’)) ENGINE = InnoDB,

partition p20221206 values less than (to_days(‘2022-12-07’)) ENGINE = InnoDB,

partition p20221207 values less than (to_days(‘2022-12-08’)) ENGINE = InnoDB,

partition p20221208 values less than (to_days(‘2022-12-09’)) ENGINE = InnoDB,

partition p20221209 values less than (to_days(‘2022-12-10’)) ENGINE = InnoDB,

partition p20221210 values less than (to_days(‘2022-12-11’)) ENGINE = InnoDB,

partition p20221211 values less than (to_days(‘2022-12-12’)) ENGINE = InnoDB,

partition p20221212 values less than (to_days(‘2022-12-13’)) ENGINE = InnoDB,

partition p20221213 values less than (to_days(‘2022-12-14’)) ENGINE = InnoDB,

partition p20221214 values less than (to_days(‘2022-12-15’)) ENGINE = InnoDB,

partition p20221215 values less than (to_days(‘2022-12-16’)) ENGINE = InnoDB,

partition p20221216 values less than (to_days(‘2022-12-17’)) ENGINE = InnoDB,

partition p20221217 values less than (to_days(‘2022-12-18’)) ENGINE = InnoDB,

partition p20221218 values less than (to_days(‘2022-12-19’)) ENGINE = InnoDB,

partition p20221219 values less than (to_days(‘2022-12-20’)) ENGINE = InnoDB,

partition pMAXVALUE values less than (maxvalue) ENGINE = InnoDB

);

2) 파티션 조회

MySQL [bjh]> select * from information_schema.partitions where table_schema=’bjh’ and table_name=’partitiontest’;

+————–+—————+—————-+—————–+———————-+———————–+———————+

| TABLE_SCHEMA | TABLE_NAME    | PARTITION_NAME |PARTITION_METHOD | PARTITION_EXPRESSION | PARTITION_DESCRIPTION | CREATE_TIME         |

+————–+—————+—————-+—————–+———————-+———————–+———————+

| bjh          | partitiontest | p20221201      |RANGE            | to_days(`createdAt`) | 738856                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221202      |RANGE            | to_days(`createdAt`) | 738857                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221203      |RANGE            | to_days(`createdAt`) | 738858                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221204      |RANGE            | to_days(`createdAt`) | 738859                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221205      |RANGE            | to_days(`createdAt`) | 738860                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221206      |RANGE            | to_days(`createdAt`) | 738861                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221207      |RANGE            | to_days(`createdAt`) | 738862                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221208      |RANGE            | to_days(`createdAt`) | 738863                | 2022-12-19 04:47:35 |

         … 중략 …

| bjh          | partitiontest | p20221214      |RANGE            | to_days(`createdAt`) | 738869                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221215      |RANGE            | to_days(`createdAt`) | 738870                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221216      |RANGE            | to_days(`createdAt`) | 738871                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221217      |RANGE            | to_days(`createdAt`) | 738872                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221218      |RANGE            | to_days(`createdAt`) | 738873                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | p20221219      |RANGE            | to_days(`createdAt`) | 738874                | 2022-12-19 04:47:35 |

| bjh          | partitiontest | pMAXVALUE      |RANGE            | to_days(`createdAt`) | MAXVALUE              | 2022-12-19 04:47:35 |

+————–+—————+—————-+—————–+———————-+———————–+———————+

3) 프로시저 수행

MySQL [mysql]> call mysql.delete_partition(‘bjh’, ‘partitiontest’, 16);

프로시저 해석 : bjh.partitiontest 테이블을 금일 날짜(테스트 날짜 :2022-12-19) 기준으로 16일이 경과한 파티션을 삭제.

+———————+

| Deleted_Partitions  |

+———————+

| p20221201,p20221202 |

+———————+

1 row in set (5.46 sec)

Query OK, 0 rows affected (5.46 sec)

3-1) 파티션 결과 조회

MySQL [mysql]> select * from information_schema.partitions where table_schema=’bjh’ and table_name=’partitiontest’;

+————–+—————+—————-+——————+———————-+———————–+———————+

| TABLE_SCHEMA | TABLE_NAME    | PARTITION_NAME | PARTITION_METHOD | PARTITION_EXPRESSION | PARTITION_DESCRIPTION | CREATE_TIME         |

+————–+—————+—————-+——————+———————-+———————–+———————+

| bjh          | partitiontest | p20221203      | RANGE            | to_days(`createdAt`) | 738858                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221204      | RANGE            | to_days(`createdAt`) | 738859                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221205      | RANGE            | to_days(`createdAt`) | 738860                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221206      | RANGE            | to_days(`createdAt`) | 738861                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221207      | RANGE            | to_days(`createdAt`) | 738862                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221208      | RANGE            | to_days(`createdAt`) | 738863                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221209      | RANGE            | to_days(`createdAt`) | 738864                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221210      | RANGE            | to_days(`createdAt`) | 738865                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221211      | RANGE            | to_days(`createdAt`) | 738866                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221212      | RANGE            | to_days(`createdAt`) | 738867                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221213      | RANGE            | to_days(`createdAt`) | 738868                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221214      | RANGE            | to_days(`createdAt`) | 738869                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221215      | RANGE            | to_days(`createdAt`) | 738870                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221216      | RANGE            | to_days(`createdAt`) | 738871                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221217      | RANGE            | to_days(`createdAt`) | 738872                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221218      | RANGE            | to_days(`createdAt`) | 738873                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | p20221219      | RANGE            | to_days(`createdAt`) | 738874                | 2022-12-19 06:32:45 |

| bjh          | partitiontest | pMAXVALUE      | RANGE            | to_days(`createdAt`) | MAXVALUE              | 2022-12-19 06:32:45 |

+————–+—————+—————-+——————+———————-+———————–+———————+

4) 임시테이블 존재 확인

MySQL [bjh]> show tables;

+———————————–+

| Tables_in_bjh                     |

+———————————–+

| _exchange_partitiontest_p20221201 |

| _exchange_partitiontest_p20221202 |

| partitiontest                     |

+———————————–+

3 rows in set (0.00 sec)

4-1) 임시테이블 존재 확인

MySQL [bjh]> describe _exchange_partitiontest_p20221202;

MySQL [bjh]> describe _exchange_partitiontest_p20221202;

+————+————–+——+—–+———+—————-+

| Field      | Type         | Null | Key | Default | Extra          |

+————+————–+——+—–+———+—————-+

| id         | int          | NO   | PRI | NULL    | auto_increment |

| some_data  | varchar(100) | YES  |     | NULL    |                |

| createdAt  | datetime(6)  | NO   | PRI | NULL    |                |

| modifiedAt | datetime(6)  | YES  |     | NULL    |                |

+————+————–+——+—–+———+—————-+

4 rows in set (0.00 sec)

3-2-2. Partition Drop Procedure (임시테이블 삭제)

앞서 테스트 한 프로시저는Exchange된 일반 테이블을 drop하지 않고 그대로 남겨 이력을 가져가고자 할 때 사용할 수 있는 프로시저입니다.

일반 테이블이 필요 없을 때에는 아래의 프로시저를 사용하여 즉시 Drop 할 수 있습니다. (앞의 프로시저와 내용이 조금씩 다르므로 구문 전체 복사가 필요합니다.)

Drop Partition Procedure 문 (Terminal 수행을 위해 DELIMITER 변경 후 진행)

DELIMITER $$

CREATE PROCEDURE delete_partition(p_dbname varchar(255), p_tbname varchar(255), p_del_date INT)

SQL SECURITY INVOKER

BEGIN

   DECLARE done INT;

   DECLARE pname VARCHAR(64);

   DECLARE alter_cmd VARCHAR(1024);

   DECLARE deleted_partition VARCHAR(1024);

  — 삭제할 파티션 목록 취합

   DECLARE cur CURSOR FOR

      SELECT PARTITION_NAME FROM information_schema.PARTITIONS

      WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION!=’MAXVALUE’

        AND PARTITION_DESCRIPTION<=TO_DAYS(current_date()) – p_del_date ;

   DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

   SET done = 0;

   — 삭제 대상 파티션 목록 확인 및 작업 완료 후 출력 (옵션)

   SELECT GROUP_CONCAT(PARTITION_NAME) INTO deleted_partition

   FROM information_schema.PARTITIONS

   WHERE TABLE_SCHEMA = p_dbname AND TABLE_NAME = p_tbname AND PARTITION_DESCRIPTION!=’MAXVALUE’

     AND PARTITION_DESCRIPTION<=TO_DAYS(current_date()) – p_del_date ;

   OPEN cur;

   FETCH cur INTO pname;

   WHILE done = 0 DO

     — MySQL 5.6 버전 이상인 경우 동일 스키마로 빈 테이블을 만들어서 PARTITION EXCHANGE 처리 후 DROP PARTITION

     — 파티션 삭제 처리 시간 지연으로 인한 Table Lock 영향을 최소화하기 위함

      IF left(version(),3) >= ‘5.6’ THEN

         — make empty table for exchange

         SET @alter_sql := CONCAT(‘CREATE TABLE ‘, p_dbname, ‘._exchange_’, p_tbname, ‘ LIKE ‘, p_dbname, ‘.’ , p_tbname);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

         SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘._exchange_’, p_tbname, ‘ REMOVE PARTITIONING’);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

         — exchange

         SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘.’, p_tbname, ‘ EXCHANGE PARTITION ‘, pname, ‘ WITH TABLE ‘, p_dbname, ‘._exchange_’, p_tbname);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

         — drop tmp table

         SET @alter_sql := CONCAT(‘DROP TABLE ‘, p_dbname, ‘._exchange_’, p_tbname);

         PREPARE alter_cmd FROM @alter_sql;

         EXECUTE alter_cmd;

         DEALLOCATE PREPARE alter_cmd;

      END IF;

      — 파티션 삭제

      SET @alter_sql := CONCAT(‘ALTER TABLE ‘, p_dbname, ‘.’, p_tbname, ‘ DROP PARTITION ‘, pname);

      PREPARE alter_cmd FROM @alter_sql;

      EXECUTE alter_cmd;

      DEALLOCATE PREPARE alter_cmd;

      FETCH cur INTO pname;

   END WHILE;

   CLOSE cur;

   — 삭제 처리한 파티션 목록 출력 (옵션)

   SELECT deleted_partition AS Deleted_Partitions ;

END $$

DELIMITER ;

 

3-3. Procedure Event 등록

앞의 Drop & Add 파티션 프로시저를 가지고 이벤트 스케줄러러나 crontab(이벤트 스케줄러 미지원 버전의 경우)에 등록합니다.

이벤트 스케줄러 사용 시, event_scheduler 파라미터 ON 여부도 확인해야 합니다.

사전 준비사항

SET GLOBAL activate_all_roles_on_login=ON; — 해당 파라미터 ON 확인

— 이벤트 생성 및 실행에 필요한 권한 부여

MySQL [mysql]> grant event on *.* to `admin`@`%`;

MySQL [mysql]> grant execute on procedure  mysql.delete_partition to `admin`@`%`;

MySQL [mysql]> grant execute on procedure  mysql.create_partition to `admin`@`%`;

MySQL [mysql]> flush privileges;

Drop & Add Partition Event Scheduler (Terminal 수행을 위해 DELIMITER 변경 후 진행)

DELIMITER $$

drop event if exists evt_partition_management $$

CREATE DEFINER=`admin`@`%` EVENT evt_partition_management

ON SCHEDULE EVERY ‘1’ DAY STARTS ‘2022-12-20 01:00:00’    — 스케쥴러 시작 시점은 반드시 현재 날짜 기준으로 미래 시점이어야 함

DO

BEGIN

  call mysql.delete_partition(‘bjh’, ‘partitiontest’, 10);

  call mysql.create_partition(‘bjh’, ‘partitiontest’, 3, 1);

END $$

DELIMITER ;

Event 등록 확인

MySQL [mysql]> show events;

+——-+—————————+——————–+—————-+—————-+———————+——+———-+

| Db    | Name                      | Definer            | Interval value | Interval field | Starts              | Ends | Status   |

+——-+—————————+——————–+—————-+—————-+———————+——+———-+

| mysql | evt_partition_management  | admin@%            | 1              | DAY            | 2022-12-20 01:00:00 | NULL | ENABLED  |

| mysql | ev_rds_gsh_collector      | rdsadmin@localhost | 5              | MINUTE         | 2022-12-19 04:19:42 | NULL | DISABLED |

| mysql | ev_rds_gsh_table_rotation | rdsadmin@localhost | 7              | DAY            | 2022-12-26 04:19:42 | NULL | DISABLED |

+——-+—————————+——————–+—————-+—————-+———————+——+———-+

방금 읽은 인사이트를 실무에 직접 적용하고 싶으시다면?
지금 바로 베스핀글로벌에 문의하세요.

베스핀글로벌 문의하기

[Linux] Out Of Memory 발생 시 메모리 확인 방법

TECH
by Sangmi Park

리눅스 서버를 운영하면서 일반적으로 CPU / MEM / DISK 등의 상태에 대해 모니터링을 하게 됩니다.

모니터링을 하는 방법이야 유료/무료 툴을 사용하든 직접 명령어로 확인하든 다양한 방법이 있을 것이고, 본문에서는 다루지 않을 생각입니다.

서버를 모니터링할 때 가장 무서운 장애는 OOM(Out Of Memory)입니다.

특정 프로세스에서 메모리를 많이 사용하게 되어 OOM 이 발생하게 되면 해당 프로세스(App 등)가 멈출 뿐 아니라 서버의 메모리 자원이 부족하여 아예 동작을 하지 못하는 상황이 발생하게 됩니다.

따라서 OOM 상황을 방지하고자 프로세스들을 확인하고 메모리를 확보하는 작업을 하게 됩니다.

1. 메모리 확인

$ free -h

위 명령으로 전체 메모리 / 사용 메모리 / 캐시 메모리 / 스왑 메모리 등을 확인할 수 있습니다.

 

$ top

이 명령으로 CPU / MEM 를 동시에 확인할 수 있으며, 어떤 프로세스의 사용률이 높은지 확인할 수 있습니다.

일반적으로 top 명령으로 위처럼 확인할 수 있고, 만약 특정 앱의 프로세스가 메모리 사용률이 높다면, 그 앱을 사용하는 담당자에게 문의해 죽일 수 있습니다.

2. 캐시 메모리의 사용비율이 높은 상황

`$ free -h` 명령으로 확인했을 때 메모리 사용률은 낮은데 이상하게 캐시 메모리의 사용이 높은 경우가 있습니다.

이 경우에는 캐시 메모리를 비워주어 해결할 수 있습니다.

캐시 메모리를 사용한다면 자주 사용되고 있는 프로그램들의 값들을 캐시에 저장하여 사용하기에 메모리 접근 속도를 높일 수 있지만, 다른 프로그램에서 메모리 사용률을 확보하지 못하는 문제가 발생할 수 있습니다.

따라서 주기적으로 캐시 메모리를 비워 메모리를 확보해 주는 것이 좋을 것 같습니다.

$ sync && echo 3 > /proc/sys/vm/drop_caches

이 명령어를 사용하면 캐시 메모리를 비울 수 있고, 메모리 여유 공간을 확보할 수 있습니다.

 

위 명령에 대해 좀 더 자세히 확인해보자면, 아래와 같습니다.

pagecache 해제

$ echo 1 > /proc/sys/vm/drop_caches

 

dentries, inodes 해제

$ echo 2 > /proc/sys/vm/drop_caches

 

pagecache, dentries, inodes 모두 해제

$ echo 3 > /proc/sys/vm/drop_caches

 

플러싱하기

$ sync

3. 정리

메모리가 부족한 상황은 일반적으로 특정 프로세스에서 과도하게 사용하거나 캐시 메모리에서 많이 사용하고 있는 경우입니다.

이 외의 경우는 아직 경험해 보지 못하였으나, 시스템 로그 / 메모리 확인 / 앱의 상태 확인 등의 방법을 통해 차근차근 접근한다면 충분히 해결할 수 있을 것입니다.

방금 읽은 인사이트를 실무에 직접 적용하고 싶으시다면?
지금 바로 베스핀글로벌에 문의하세요.

베스핀글로벌 문의하기

사우디아라비아 vs. 아랍에미리트, 두 나라 사이 불꽃이 튀는 이유 ‘전격 공개’!

BESPICK
by Sangmi Park

안녕하세요, 베스픽 구독자 여러분. 오늘은 멀지만 몇 년 새 우리에게 친숙한 이름이 되어버린 ‘중동’, 그중에서도 지역을 대표하는 두 나라 ‘사우디아라비아’와 ‘아랍에미리트(UAE)’의 긴장 관계에 대해 뒷얘기를 풀어보고자 합니다.

사실 두 나라 사이의 긴장 관계는 하루 이틀 사이에 생겨난 것은 아닙니다. 우리나라만 봐도 국경을 맞대고 있는 나라의 사이가 아주 좋기란 쉽지 않죠. 사우디아라비아와 아랍에미리트도 ‘중동의 형제’라 불리며, 깊은 교류와 문화적 공통점을 바탕으로 긴밀한 동맹을 유지하고 있지만(!) 그 속내는 다르다는데요. 그게 클라우드 혹은 디지털 기술과 무슨 상관이냐고요? 끝까지 다 읽으시면 알게 됩니다!

‘아부다비’·‘두바이’ 알지만… 들어는 봤니, ‘리야드’?👂

혹시 사우디아라비아의 수도가 어디인지 알고 계셨나요? 아랍에미리트의 아부다비와 두바이가 세계적으로 유명한 것에 비해, 사우디아라비아는 알아도 그 수도 리야드는 모르는 사람들이 많습니다. 세계에서 두 번째로 많은 석유 생산량을 앞세워 경제와 국력의 덩치를 키운 사우디아라비아가 중동 지역의 맹주인 건 확실합니다. 아랍 국가 중 유일한 G20 국가이기도 하고요. 하지만 중동 지역에 출장을 간다면, 또는 관광을 하러 간다면 그 도착지는 리야드가 아닌 아랍에미리트의 두 도시, 아부다비와 두바이 중 하나일 확률이 매우 높습니다.

Abu Dhabi, Source: traveler.marriott.com/

아랍에미리트의 수도 아부다비는 현재 도시 내에 5개의 경제 자유 구역을 갖추고 있습니다. 아부다비 투자 진흥청(Abu Dhabi Investment Authority)은 세계 최대 펀드 중 하나고요. 잘 알려진 것처럼 두바이엔 세계에서 가장 고급스러운 호텔과 세계에서 가장 높은 건물이 있죠.  아부다비는 2022년 글로벌 도시 성장 전망(GCO) Top 10 중 9위에 뽑혔고요. 두바이는 같은 지수에서는 11위였습니다. 전 세계 150개 도시를 대상으로 분석한 이 보고서에서 아부다비와 두바이는 중동 지역의 도시 중 가장 높은 순위를 차지했으며, 리야드는 30위권 내에 없었습니다. 아랍에미리트가 가장 글로벌한 중동 국가임을 입증하는 것이죠.

2020년 기준 사우디아라비아의  국내총생산(GDP)은 약 7000억 달러로, 아랍에미리트의 2배나 되고 인구로 비교해도 사우디아라비아가 아랍에미리트의 3배가 넘습니다. 하지만 1인당 구매력 평가 지수(PPP) 기준으로 아랍에미리트는 세계에서 가장 부유한 국가 8위, 중동에서는 카타르에 이은 2위입니다. 그에 비해 사우디아라비아는 아랍에미리트는 물론, 쿠웨이트에도 밀려 중동 지역 내 4위를 기록하고 있죠.

아무리 사우디아라비아가 경제 규모나 영토가 더 크고 인구도 많다지만 글로벌에서 평가하는 국가와 도시의 브랜드, 또 실질적 삶의 질에 있어서는 아랍에미리트에 밀리고 있는 형국인데요. 아랍에미리트나 사우디아라비아나 자국의 석유 매장량이 언젠가는 고갈될지도 모른다는 불안감에 휩싸여 있는 것은 마찬가지입니다. 그 때문에 아랍에미리트나 사우디아라비아나 석유 이후의 경제, 즉 ‘포스트 오일(Post-Oil) 시대’를 준비할 수밖에 없는 것이죠.

석유 없는 미래를 대비해야 하는 중동 국가들에 대해 더 자세히 알고 싶다면, 저번주 베스픽을 확인해 주세요!

👉 최대 산유지 중동, 이제는 ‘클세권’ 노린다?

포스트 오일 시대를 대비하라, 자금·인력·파트너 쟁탈전💥

사우디아라비아와 아랍에미리트 두 나라 모두가 석유 다음의 자원으로 주목한 것이 바로 ‘디지털 경제’입니다. 디지털 경제란 모든 경제 활동을 디지털화시켜 그 발전 속도를 크게 증대시키는 것을 의미하는데요. 세계은행에 따르면 디지털 경제가 중동 및 북아프리카(MENA) 지역에서 많은 일자리를 창출할 수 있을 뿐 아니라, 각국의 국내총생산(GDP)을 총합 1조 6000억 달러까지 증가시킬 수 있다고 하는데요. MENA 지역의 디지털 경제 시장 규모는 현재 400억 달러가 안되지만 2030년까지 박차를 가하면 4000억 달러에 이를 수도 있다는(!) 분석이 나오기도 했습니다.

디지털 경제를 위해서는 무엇이 필요할까요? 자금과 함께 고급 인력, 그리고 전문성을 갖춘 파트너겠죠. 바로 이를 확보하기 위한 경쟁이 사우디아라비아와 아랍에미리트 사이에 벌어지기 시작했습니다. 기회와 자원은 한정적이고, 석유 고갈에 대한 두려움은 큰 만큼 그 경쟁이 더욱 치열한데요.

아랍에미리트는 오랫동안 외국계 자본을 유치하기 위한 전략을 적극적으로 추진해왔습니다. 팬데믹이 시작되면서 전 세계적으로 외국인 직접 투자(FDI)가 42% 감소했지만 아랍에미리트는 달랐습니다. 2020년에도 전년대비 20억 달러가 늘어 199억 달러를 기록했고 2021년에는 사상 최고치인 207억 달러를 달성했죠. 

배경에는 아랍에미리트 정부 차원의 노력이 있었습니다. 이미 예전부터 중동 지역에서 가장 개방적인 정책을 펴왔던 아랍에미리트는 2019년 자국에서 사업 혹은 투자를 하길 원하거나 AI·빅데이터·SW 등 전문 기술을 보유한 외국인에게 골든 비자를 주어 10년간 장기 체류를 가능하게 했고요. 2020년에는 허가된 장소에서의 음주와 결혼하지 않은 커플의 동거를 허락했습니다. 글로벌 스탠다드에 맞춰 토요일과 일요일을 휴일로 바꾸기도 했죠.

그런데 이 흐름에 사우디아라비아도 동참하면서 두 나라 사이 경쟁이 본격화됩니다. 아랍에미리트가 중동 지역의 비즈니스 허브이니, 글로벌 기업의 중동 본사들은 당연히 두바이나 아부다비에 위치해 있었는데요. 2021년 2월 사우디아라비아가 2024년까지 다국적 기업의 본사를 리야드로 옮기지 않으면 비즈니스를 금지하겠다며 엄포를 놓은 거죠. 글로벌 기업의 중동 지역 주요 비즈니스 파트너 자리를 놓고 아랍에미리트에 도전한 것입니다. 이 조치에 힘입어 리야드는 2021년 말 기준으로 44개나 되는 글로벌 기업의 지역 본사를 유치했습니다. 그해 1월에 20개뿐이었던 걸 감안하면 1년도 안되어서 2배 넘게 증가했죠.

아랍에미리트는 이에 맞불을 놓듯 최근 외국인의 기업 지분 100% 소유를 허용했습니다. 말하자면 사우디아라비아는 강경한 태도로 아랍에미리트에 도전하고 있고, 아랍에미리트는 당근을 주는 유화책을 어필하며 각자의 목표를 위해 열심히 뛰고 있는 셈입니다.

‘비전 2030’ vs ‘Projects of the 50’, 승자는 어부지리?🎣

사우디아라비아의 경제 다각화를 주도적으로 이끄는 사람이 바로 최근 한국을 방문했던 빈 살만 왕세자, ‘미스터 에브리씽’입니다. 국내에서도 화제가 됐던 네옴시티로 대표되는 ‘비전 2030’을 내세워 사우디아라비아의 디지털 전환을 강력하게 추진하고 있는데요. 사우디아라비아는 G20 국가들 중  ‘Top Digital Riser’로 선정될 만큼 디지털 전환을 위한 포괄적인 정부 지원을 발표했죠.

또한 사우디아라비아는 최근 의료, 제조 그리고 클라우드를 포함한 산업 분야에 투자할 경우 인센티브를 제공하는 특별 경제 구역을 만들겠다고 밝혔습니다. 사우디아라비아는 이런 특별 경제구역을 4~5개는 만들 계획이라고 하는데요. 자연스럽게 이미 여러 경제 구역을 갖추고 있는 아랍에미리트와의 경쟁은 피할 수 없겠죠.

아랍에미리트도 마찬가지입니다. 건국 50주년과 함께 ‘미래 50년을 위한 국가 전략(Projects of the 50)’이라는 이름으로 향후 50년간의 야심찬 성장 계획을 발표했는데요. 기술과 혁신을 성장의 핵심 동인으로 삼아 향후 10년 동안 국가의 경제 규모를 2배로 늘리는 것을 목표로 하고 있습니다. 이에 따라 핀테크, 블록체인, AI, 클라우드, 모빌리티 등 미래 핵심 기술 기업들의 설립과 운영을 지원하고 있죠. 잠재력이 높은 기술 기업들에 문을 열어 석유 자원이 아닌 미래 자원을 개발하기 위함입니다.

글로벌 빅테크들은 이를 틈타 중동에 활발하게 진출하고 있는데요. 특히 디지털 경제의 가장 기본적인 토대가 되는 주요 인프라, 클라우드를 공급하는 CSP 기업들의 기세가 무섭습니다. 실제로 해당 지역의 클라우드 컴퓨팅 시장은 2026년까지 314억 달러로 급증할 것으로 여겨지고 있는데요.  2020년 오라클은 사우디아라비아 제다(Jeddah)에 클라우드 리전을 설립하더니, 같은 해 두바이와 아부다비에 차례로 리전을 여는 공격적 행보를 보였습니다. 구글도 아람코와 합작 투자의 일환으로 담맘(Dammam)에 리전을 개설했고요. 아랍에미리트에도 이미 마이크로소프트를 선두로 알리바바, IBM 등 내로라하는 클라우드 기업들이 대거 진출해 있습니다. 양국 외에 바레인과 카타르에도 클라우드 리전이 설립되어 중동 지역의 클라우드 전환 기회를 호시탐탐 노리고 있습니다.

이렇게 치열한 경쟁 속에서 과연 승자는 누가 될까요? 사우디아라비아? 아랍에미리트? 그 틈새에서 두 나라로부터 가장 적극적이고 최적화된 지원을 얻어낼 기업이 바로 승자일 확률이 가장 높지 않을까 싶은데요.

중동 지역에서 디지털 경제 개발을 저해하는 가장 큰 요인으로 꼽히는 것이 바로 기술 격차입니다. 클라우드를 비롯한 전문 기술에 대한 현지 수요와 공급 사이에 어마어마한 격차가 자리 잡고 있기 때문에 기술을 서로 교류하고 전문성을 보유한 파트너가 절실한 것이죠. 바로 이 가려운 부분을 딱 긁어주면서, 신뢰를 바탕으로 비즈니스를 추진할 수 있는 기업이라면 이 치열한 싸움에서 피 흘리지 않고 승자가 될 수 있지 않을까요?

베스핀글로벌은 2019년 중동과 북아프리카 지역에 첫 진출한 이후, 해당 지역의 디지털 전환을 돕고 있습니다. 올해 아부다비 최초 클라우드 운영센터와 교육 아카데미를 설립하여 클라우드 인재를 한데 모아 교육하고 양성하고 채용함으로써 해당 지역의 클라우드 생태계를 조성했는데요. 향후 중동에서 펼쳐질 포스트 오일의 시대, 디지털 전환은 어디까지 펼쳐질까요? 그리고 베스핀글로벌은 어떠한 역할을 맡게 될까요? 베스핀글로벌이 앞장서고 있는 중동의 미래에 대해 주목해 주시기 바랍니다.

오늘은 이것으로 마무리하겠습니다. 다음주에 만나요🙂
👉 베스픽 질문&피드백 남기기

📰 안보면 클나우

“ICT 수출전략, 하드웨어에서 소프트웨어 중심으로 전환해야” 더보기
오늘(20일) ICT 수출 활성화를 위한 민·관 합동 간담회가 열렸습니다. 수출 현황과 전망, 중동 등 새로운 시장 진출과 그 성공 사례를 공유하는 시간이었는데요. 이 자리에서 베스핀글로벌의 이한주 대표는 수출 전략을 하드웨어 중심에서 소프트웨어, 특히 클라우드 형태의 디지털 전략으로 대전환해야 한다고 강조했습니다.

AI 챗봇 챗GPT ‘돌풍’…개발사 “2024년 매출 10억 달러 목표”  ​​ 더보기
공개 이후 일주일 이내에 100만 명 이상이 사용한 것으로 알려진 ‘챗GPT’에 관심이 집중되고 있습니다. 인간과 상당히 비슷한 대화는 물론, 프로그래밍도 가능하다고 하는데요. 개발사 측은 2024년 10억 달러 규모의 매출을 목표로 하고 있다고 합니다.

오라클, FYQ2(9~11월) 호실적 발표… 클라우드 서비스 매출 성장세 더보기
오라클이 전망을 웃도는 실적을 발표했습니다. 특히 매출의 65%를 차지하는 클라우드&온프레미스 서비스 매출 성장세가 두각을 나타냈는데요. 클라우드 관련 매출액이 전년 대비 40%나 증가했다고 합니다.

☁️ 안쓰면 클나우

2023 IT 키워드는 핀옵스(FinOps)?

2023 IT 트렌트를 보다보면 ‘핀옵스(FinOps)’라는 말을 자주 접하실 듯 합니다. 멀티 클라우드와 하이브리드 클라우드 사용이 증가하면서 클라우드 비용과 자원에 대한 전문적인 관리가 필요해진 것인데요. 핀옵스의 핵심은 다음 3가지입니다.

  • 클라우드 비용 관리 전담 조직(인력)
  • 가시화 도구 사용
  • 클라우드 거버넌스

우리 회사의 핀옵스 역량이 궁금하신가요? 어떻게 핀옵스를 시작하면 좋을지 고민이신가요? 그런 분들을 위해 옵스나우 핀옵스 컨설팅 서비스를 소개합니다. 클라우드 관리 솔루션 OpsNow CMP(옵스나우 CMP)를 활용해 클라우드 비용 최적화를 위한 다양한 방안을 제시해 드립니다.

👉 클라우드 비용 최적화를 위한 핀옵스 컨설팅 바로가기
👉 클라우드 관리 솔루션 ‘옵스나우’ 자세히 보기

클라우드 도입 사례, 관리와 비용 절감을 위한 팁은 물론 국내외 IT 업계 소식까지
당신의 클라우드 원픽 뉴스레터 베스픽에서 만나보세요.
뉴스레터를 구독하시면 매주 화요일, 가장 먼저 베스픽을 받아볼 수 있습니다 🙂

방금 읽은 이 콘텐츠가 마음에 드셨다면?
지금 바로 베스핀글로벌의 뉴스레터 ‘베스픽’을 구독하고, 매주 인사이트를 가장 빠르게 받아보세요.

베스핀글로벌 문의하기
뉴스레터 구독하기

Contract for AWS Resale

by Sangmi Park

Contract for AWS Resale

계약 일반 조건

2023년 06년 19일부터 체결하는 계약에 적용됩니다.

제1조 (목적)

본 계약은 고객과 베스핀 사이에 Amazon Web Services(AWS) 통합빌링 서비스에 대한 사용계약을 체결함에 있어 필요한 제반 사항을 명시하여 상호신뢰를 바탕으로 성실한 계약 이행과 공동의 이익 발전에 이바지함을 목적으로 합니다.

제2조 (용어의 정의)
  1. “서비스”란 본 계약을 통하여 베스핀이 제공하는 AWS 통합빌링 서비스 그 외의 추가 서비스 등을 의미합니다.
  2. “통합빌링 서비스”란 AWS의 과금 체계 및 청구를 통합빌링 기능을 이용하여 베스핀을 통한 AWS 사용료의 납부 서비스를 의미합니다.
제3조 (계약기간)
  1. 본 계약의 기간은 계약표지의 계약기간으로 합니다. 다만, 양 당사자의 서면 합의로 본 계약의 기간을 변경할 수 있습니다.
  2. 본 계약의 기간 만료일이 특정일로 지정되어 있는 경우에는 본 계약의 만료 1개월 전까지 당사자 일방 또는 쌍방이 계약 내용의 변경을 요구하거나 계약의 종료를 통보하지 아니한 경우에는 본 계약은 동일한 조건으로 기간 만료일 다음날부터 1년씩 자동 연장됩니다.
제4조 (계약상세조건)
  1. 고객은 본 계약 체결을 통해 서비스 사용과 관련하여 Amazon Web Services, Inc.(이하 “Amazon”)의 AWS 라이선스 계약조건을 포함한 관련 규정들을 준수할 것을 확약하며, 필요 시 고객은 인터넷 박스 클릭 등의 형태로 Amazon과 별도 약관, 라이선스 계약 등을 체결할 수 있습니다.
  2. 고객이 선택한 Amazon Support Plan에 따라 Amazon에서 고객에게 제공하는 기술지원 서비스가 제한될 수 있습니다. 계약 기간 내에 Support Plan 변경 혹은 계정 추가 시 AWS Plan 표준 요금을 청구시점 시 청구합니다. 이 경우 고객은 Support Plan 변경 혹은 계정 추가 시 베스핀에게 통지하여야 하며, 이를 하지 않아 베스핀이 요금을 과다 청구하는 등의 불이익에 대하여는 베스핀이 책임지지 않습니다.
  3. 고객은 베스핀의 원활한 고객지원을 위해 베스핀이 고객을 대신하여 AWS Support Center에 접속 및 관리할 수 있도록 다음 각 호 내용의 IAM계정을 생성하는 것에 동의합니다.
    1. IAM Identity Center (SSO) 서비스를 통한 지원역할 (Support Role) 생성
    2. 생성되는 역할명(Role name)은 “AWSReservedSSO_bespin-support_변수값”임
    3. 역할관련 권한은 (1) ReadOnlyAccess와 (2) SupportAccess에 국한함
  4. 고객이 본 조 제3항의 절차에 동의하지 않을 경우 서비스 중지를 포함하여 고객지원 서비스 이용에 제약이 있을 수 있습니다. 고객 계정의 기본 관리에 대한 책임은 고객에게 있습니다.
  5. 본 계약에 따라 제공되는 서비스가 본 계약에 명시된 바와 다르다고 고객이 판단할 경우, 고객은 베스핀에게 이러한 사실을 서면으로(지정된 이메일 포함) 통지할 수 있고, 베스핀은 이에 지체없이 대응합니다.
  6. 베스핀은 준거법에서 허용하는 최대 한도 내에서 본 계약에 따른 서비스를 있는 그대로, 유효한 범위에서 제공하며, 서비스가 아무런 장애나 에러가 없이 제공되거나, 본 계약서에 명시되지 않은 고객의 요구사항이나 기대치에 부합할 것을 보증하지 않습니다.
제5조 (서비스 사용료)
  1. 서비스 사용료는 고객의 AWS 사용료를 기준으로 매월 1일부터 말일까지 월별로 산정되어 청구됩니다.
  2. 계약표지의 청구 및 결제 조건에 따라 베스핀은 고객에게 서비스 사용료를 청구하며, 고객은 베스핀에게 서비스 사용료를 지급해야 합니다.
  3. 베스핀은 고객의 전월 사용금액에 대하여 사용월 마지막 영업일 기준 서울외국환중개소 환율을 적용하여 산정합니다.
  4. 고객이 지급기일 내에 서비스 사용료를 납부하지 않는 경우, 미납 서비스 사용료에 대하여 연 15%의 지연이자가 적용되며, 베스핀은 고객에게 미납 서비스 사용료에 대한 통지를 합니다.
제6조 (권리의무의 양도금지)
  1. 고객은 임의로 본 계약상의 권리와 의무를 타인에게 이전하거나 양도, 담보 설정 등으로 처분할 수 없습니다. 다만, 고객에게 합병, 분할의 사유가 발생하는 경우는 예외로 합니다.
  2. 고객에게 합병, 분할의 사유가 발생하여 고객이 아닌 제3자(이하 “양수인”이라 합니다)가 고객이 베스핀과 체결한 본 계약에 따른 법적 지위를 승계하는 경우에는, 서비스의 사용을 위하여 고객 및 양수인은 즉시 회사에 지위 승계를 입증할 수 있는 서류를 첨부하여 베스핀에게 통지하여야 합니다.
제7조 (비밀유지)
  1. 양 당사자는 본 계약의 체결 및 이행과 관련하여 알게 된 상대방의 업무상 비밀을 상대방의 사전 서면 동의 없이 제3자에게 공개, 유출, 제공하여서는 아니됩니다.
  2. 양 당사자의 상호, 로고는 영업비밀에 해당하지 않으며, 양 당사자는 상대방의 상호, 로고를 홍보 목적 등으로 사용할 수 있으나, 그 사용이 상대방의 명성을 저하시키거나 명예를 훼손하여서는 아니됩니다.
제8조 (계약의 해지)
  1. 양 당사자는 다음 각 호의 사유가 있는 경우 상대방에 대한 최고절차 없이 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
    1. 발행한 어음이나 수표가 부도 또는 거래 정지된 경우
    2. 감독관청의 영업정지 또는 영업면허, 영업등록 등의 취소처분을 받은 때
    3. 파산절차 또는 회생절차가 시작되거나 이러한 신청이 있는 경우
    4. 가압류, 가처분 등으로 본 계약의 목적달성이 곤란하다고 판단되는 경우
  2. 양 당사자 중 일방이 본 계약을 위반한 경우 상대방은 14일의 기간을 두고 이를 최고한 후, 시정되지 않을 경우 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
  3. 양 당사자는 희망 해지일로부터 30일 전에 상대방에 대한 해지 통지를 함으로써 본 계약을 해지할 수 있습니다.
제9조 (계약의 변경 및 해석)
  1. 본 계약의 효력기간 중에 본 계약의 내용을 변경할 필요가 있는 경우, 상호 합의에 의한 변경계약서로 변경이 가능하며, 변경계약서의 내용 중 본 계약과 상충되는 부분은 변경계약서의 내용이 우선하며, 변경계약서에서 정하지 아니한 사항에 대해서는 본 계약에 의합니다.
  2. 양 당사자는 본 계약에서 정하지 아니한 사항이나 추가 서비스에 관하여 부속합의서를 체결할 수 있습니다.
제10조 (손해 배상)

고객 또는 베스핀이 본 계약을 위반하여 상대방에게 손해를 입힌 경우 또는 본 계약이 해지되는 경우에는 그 책임이 있는 당사자가 상대방이 입은 손해를 배상하여야 합니다. 다만, 손해 배상 청구일 또는 본 계약 해지일 직전월에 고객이 베스핀에게 지급한 서비스 사용료 금액을 한도로 배상합니다.

제11조 (준법 경영)
  1. 고객과 베스핀은 본 계약 체결 및 이행 과정에서 상대방의 임직원에게 금품, 향응 등 일체의 경제적 이익 또는 과도한 식사/접대 등을 제공하거나 상대방 임직원과 도박, 금전 대차, 공동투자, 인사청탁, 고용보장 등 부적절한 행위(이하 “비위행위”)를 하여서는 아니됩니다.
  2. 고객 또는 베스핀이 본 조 제1항의 의무를 위반하는 경우, 위반 당사자는 민형사상 일체의 책임을 감수하여야 하며, 상대방은 별도의 최고 절차 없이 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
  3. 고객과 베스핀은 본 계약의 공정성 확보를 위해 다음 각 호의 사항을 협조하도록 합니다.
    1. 고객 또는 베스핀의 임직원을 상대로 이루어진 비위행위가 발견되거나 비위행위에 대한 의혹이 있는 경우 상대방에게 그와 관련된 자료의 제출 또는 열람을 요구할 수 있으며, 이 경우 당사자는 적극적으로 협조하여야 합니다.
    2. 고객은 베스핀의 임직원으로부터 본 조 제1항에서 열거한 행위를 제의받거나, 이러한 사실을 인지한 때에는 베스핀 홈페이지의 윤리경영 핫라인에 즉각 신고하도록 합니다.
제12조 (준거법 및 분쟁의 해결)
  1. 본 계약은 대한민국 법률에 의해 해석됩니다.
  2. 본 계약에 명시되지 아니한 사항은 양 당사자가 합의하여 정하고, 본 계약의 해석에 이견이 발생한 경우에는 관련 법령 및 일반 상관례에 의합니다.
  3. 본 조 제2항에 의한 해결이 불가능한 경우 양 당사자는 소송을 제기할 수 있으며, 이 경우 서울중앙지방법원을 제1심 관할법원으로 합니다.
제13조 (기타)
  1. 베스핀이 고객에게 통지해야 하는 경우, 본 계약에서 별도로 명시하지 않는 한 고객이 베스핀에게 제공한 이메일 주소를 이용하여 통지합니다.
  2. 고객은 베스핀의 통지 사항을 수신할 수 있도록 연락처 정보를 항상 최신 상태로 유지할 의무가 있습니다. 연락처 정보가 업데이트 되어 있지 않아 고객에게 발생하는 불이익에 대해 베스핀은 어떠한 책임도 지지 않습니다.
  3. 만약 어떤 조항이 법원에 의해 무효 또는 집행이 불가하다고 판단되더라도, 그 나머지 조항들의 집행가능성은 여전히 유효하며 강제력을 갖습니다.
  4. 고객의 본 계약 위반과 관련하여 베스핀이 권리 실행이나 조치를 취하지 않았다고 하더라도, 이후 결과적으로 또는 유사하게 발생하는 행위에 대해 베스핀은 본 계약상의 권리 실행을 포기하는 것으로 간주되지는 않습니다.

[My SQL] DB / Table 용량확인(data, index)

TECH
by Sangmi Park

아래의 쿼리를 참고하여 원하는 형태로 쿼리를 수정하여 사용량을 확인 할 수 있다.

1. 특정 DB 테이블별 용량을 확인할 때

SELECT
     table_schema AS ‘DatabaseName’,
     TABLE_NAME,
     ROUND(SUM(data_length + index_length)/ 1024 / 1024 , 2) AS ‘total_Size(MB)’,
     ROUND(SUM(data_length)/ 1024 / 1024, 2) AS ‘data_Size(MB)’,
     ROUND(SUM(index_length)/ 1024 / 1024, 2) AS ‘index_Size(MB)’
FROM
     information_schema.tables
WHERE table_schema = {DB명}
GROUP BY table_schema, TABLE_NAME;

용량이 커서 GB 기준으로 보고 싶다면 아래 같이 쿼리를 변경하면 된다.

ROUND(SUM(data_length + index_length)/ 1024 / 1024 , 2) AS ‘total_Size(MB)’,
=> ROUND(SUM(data_length + index_length)/ 1024 / 1024 /1024 , 2) AS ‘total_Size(GB)’,

2. 특정 DB 전체 용량을 확인할 때

SELECT
     table_schema AS ‘DatabaseName’,
     TABLE_NAME,
     ROUND(SUM(data_length + index_length)/ 1024 / 1024 , 2) AS ‘total_Size(MB)’,
     ROUND(SUM(data_length)/ 1024 / 1024, 2) AS ‘data_Size(MB)’,
     ROUND(SUM(index_length)/ 1024 / 1024, 2) AS ‘index_Size(MB)’
FROM
     information_schema.tables
WHERE table_schema = {DB명}
GROUP BY table_schema;

방금 읽은 인사이트를 실무에 직접 적용하고 싶으시다면?
지금 바로 베스핀글로벌에 문의하세요.

베스핀글로벌 문의하기

NCP 계약 일반 조건

by Sangmi Park

NCP 계약 일반 조건

NCP 계약 일반 조건

2023년 06년 01일부터 체결하는 계약에 적용됩니다.

제1조 (목적)

본 계약은 고객과 베스핀 사이에 Naver Cloud Platform (NCP) 통합빌링 서비스에 대한 사용계약을 체결함에 있어 필요한 제반 사항을 명시하여 상호신뢰를 바탕으로 성실한 계약 이행과 공동의 이익 발전에 이바지함을 목적으로 합니다.

제2조 (용어의 정의)
  1. “서비스”란 본 계약을 통하여 베스핀이 제공하는 NCP 통합빌링 서비스, 그 외의 추가 서비스 등을 의미합니다.
  2. NCP란 Naver Cloud Platform의 약자로서, 네이버클라우드 주식회사(이하 “네이버”)가 운영하는 클라우드 컴퓨팅 서비스를 의미합니다.
  3. “통합빌링 서비스”란 NCP의 과금 체계 및 청구를 통합빌링 기능을 이용하여 베스핀을 통한 NCP 사용료의 납부 서비스를 의미합니다.
제3조 (계약기간)
  1. 본 계약의 기간은 계약표지의 계약기간으로 합니다. 다만, 양 당사자의 서면 합의로 본 계약의 기간을 변경할 수 있습니다.
  2. 본 계약의 기간 만료일이 특정일로 지정되어 있는 경우에는 본 계약의 만료 1개월 전까지 당사자 일방 또는 쌍방이 계약 내용의 변경을 요구하거나 계약의 종료를 통보하지 아니한 경우에는 본 계약은 동일한 조건으로 기간 만료일 다음날부터 1년씩 자동 연장됩니다.
제4조 (계약상세조건)
  1. 고객은 본 계약 체결을 통해 서비스 사용과 관련하여 네이버의 서비스 이용 약관을 포함한 관련 규정들을 준수할 것을 확약하며, 필요 시 고객은 인터넷 박스 클릭 등의 형태로 네이버와 별도 약관, 라이선스 계약 등을 체결할 수 있습니다.
  2. 고객 계정의 관리에 대한 책임은 고객에게 있습니다.
  3. 계약표지의 할인 조건에 따라 NCP할인이 제공되는 경우에 네이버의 정책에 따라 할인 적용 대상에서 제외되는 상품이 있으며, 이를 첨부된 할인 제외 상품표에 명시합니다. 명시하는 할인 적용 대상 제외 상품은 본 계약 체결일을 기준으로 하며, 네이버의 정책에 따라 할인 적용 대상 제외 상품의 구성이 달라질 수 있습니다.
  4. 본 조 제3항에서 네이버의 정책에 따라 할인 적용 대상 제외 상품의 구성이 달라지는 경우 베스핀은 고객에게 통지합니다.
  5. 본 계약에 따라 제공되는 서비스가 본 계약에 명시된 바와 다르다고 고객이 판단할 경우, 고객은 베스핀에게 이러한 사실을 서면으로(지정된 이메일 포함) 통지할 수 있고, 베스핀은 이에 지체없이 대응합니다.
  6. 베스핀은 준거법에서 허용하는 최대 한도 내에서 본 계약에 따른 서비스를 있는 그대로, 유효한 범위에서 제공하며, 서비스가 아무런 장애나 에러가 없이 제공되거나, 본 계약서에 명시되지 않은 고객의 요구사항이나 기대치에 부합할 것을 보증하지 않습니다.
제5조 (서비스 사용료)
  1. 서비스 사용료는 고객의 NCP 사용료를 기준으로 매월 1일부터 말일까지 월별로 산정되어 청구됩니다.
  2. 계약표지의 청구 및 결제 조건에 따라 베스핀은 고객에게 서비스 사용료를 청구하며, 고객은 베스핀에게 서비스 사용료를 지급해야 합니다.
  3. 고객이 지급기일 내에 서비스 사용료를 납부하지 않는 경우, 미납 서비스 사용료에 대하여 연 15%의 지연이자가 적용되며, 베스핀은 고객에게 미납 서비스 사용료에 대한 통지를 합니다.
제6조 (권리의무의 양도금지)
  1. 고객은 임의로 본 계약상의 권리와 의무를 타인에게 이전하거나 양도, 담보 설정 등으로 처분할 수 없습니다. 다만, 고객에게 합병, 분할의 사유가 발생하는 경우는 예외로 합니다.
  2. 고객에게 합병, 분할의 사유가 발생하여 고객이 아닌 제3자(이하 “양수인”이라 합니다)가 고객이 베스핀과 체결한 본 계약에 따른 법적 지위를 승계하는 경우에는, 서비스의 사용을 위하여 고객 및 양수인은 즉시 회사에 지위 승계를 입증할 수 있는 서류를 첨부하여 베스핀에게 통지하여야 합니다.
제7조 (비밀유지)
  1. 양 당사자는 본 계약의 체결 및 이행과 관련하여 알게 된 상대방의 업무상 비밀을 상대방의 사전 서면 동의 없이 제3자에게 공개, 유출, 제공하여서는 아니됩니다.
  2. 양 당사자의 상호, 로고는 영업비밀에 해당하지 않으며, 양 당사자는 상대방의 상호, 로고를 홍보 목적 등으로 사용할 수 있으나, 그 사용이 상대방의 명성을 저하시키거나 명예를 훼손하여서는 아니됩니다.
제8조 (계약의 해지)
  1. 양 당사자는 다음 각 호의 사유가 있는 경우 상대방에 대한 최고절차 없이 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
    1. 발행한 어음이나 수표가 부도 또는 거래 정지된 경우
    2. 감독관청의 영업정지 또는 영업면허, 영업등록 등의 취소처분을 받은 때
    3. 파산절차 또는 회생절차가 시작되거나 이러한 신청이 있는 경우
    4. 가압류, 가처분 등으로 본 계약의 목적달성이 곤란하다고 판단되는 경우
  2. 양 당사자 중 일방이 본 계약을 위반한 경우 상대방은 14일의 기간을 두고 이를 최고한 후, 시정되지 않을 경우 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
  3. 양 당사자는 희망 해지일로부터 1개월 전에 상대방에 대한 해지 통지를 함으로써 본 계약을 해지할 수 있습니다.
제9조 (계약의 변경 및 해석)
  1. 본 계약의 효력기간 중에 본 계약의 내용을 변경할 필요가 있는 경우, 상호 합의에 의한 변경계약서로 변경이 가능하며, 변경계약서의 내용 중 본 계약과 상충되는 부분은 변경계약서의 내용이 우선하며, 변경계약서에서 정하지 아니한 사항에 대해서는 본 계약에 의합니다.
  2. 양 당사자는 본 계약에서 정하지 아니한 사항이나 추가 서비스에 관하여 부속합의서를 체결할 수 있습니다.
제10조 (손해 배상)

고객 또는 베스핀이 본 계약을 위반하여 상대방에게 손해를 입힌 경우 또는 본 계약이 해지되는 경우에는 그 책임이 있는 당사자가 상대방이 입은 손해를 배상하여야 합니다. 다만, 손해 배상 청구일 또는 본 계약 해지일 직전월에 고객이 베스핀에게 지급한 서비스 사용료 금액을 한도로 배상합니다.

제11조 (준법 경영)
  1. 고객과 베스핀은 본 계약 체결 및 이행 과정에서 상대방의 임직원에게 금품, 향응 등 일체의 경제적 이익 또는 과도한 식사/접대 등을 제공하거나 상대방 임직원과 도박, 금전 대차, 공동투자, 인사청탁, 고용보장 등 부적절한 행위(이하 “비위행위”)를 하여서는 아니됩니다.
  2. 고객 또는 베스핀이 본 조 제1항의 의무를 위반하는 경우, 위반 당사자는 민형사상 일체의 책임을 감수하여야 하며, 상대방은 별도의 최고 절차 없이 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
  3. 고객과 베스핀은 본 계약의 공정성 확보를 위해 다음 각 호의 사항을 협조하도록 합니다.
    1. 고객 또는 베스핀의 임직원을 상대로 이루어진 비위행위가 발견되거나 비위행위에 대한 의혹이 있는 경우 상대방에게 그와 관련된 자료의 제출 또는 열람을 요구할 수 있으며, 이 경우 당사자는 적극적으로 협조하여야 합니다.
    2. 고객은 베스핀의 임직원으로부터 본 조 제1항에서 열거한 행위를 제의받거나, 이러한 사실을 인지한 때에는 베스핀 홈페이지의 윤리경영 핫라인에 즉각 신고하도록 합니다.
제12조 (준거법 및 분쟁의 해결)
  1. 본 계약은 대한민국 법률에 의해 해석됩니다.
  2. 본 계약에 명시되지 아니한 사항은 양 당사자가 합의하여 정하고, 본 계약의 해석에 이견이 발생한 경우에는 관련 법령 및 일반 상관례에 의합니다.
  3. 본 조 제2항에 의한 해결이 불가능한 경우 양 당사자는 소송을 제기할 수 있으며, 이 경우 서울중앙지방법원을 제1심 관할법원으로 합니다.
제13조 (기타)
  1. 베스핀이 고객에게 통지해야 하는 경우, 본 계약에서 별도로 명시하지 않는 한 고객이 베스핀에게 제공한 이메일 주소를 이용하여 통지합니다.
  2. 고객은 베스핀의 통지 사항을 수신할 수 있도록 연락처 정보를 항상 최신 상태로 유지할 의무가 있습니다. 연락처 정보가 업데이트 되어 있지 않아 고객에게 발생하는 불이익에 대해 베스핀은 어떠한 책임도 지지 않습니다.
  3. 만약 어떤 조항이 법원에 의해 무효 또는 집행이 불가하다고 판단되더라도, 그 나머지 조항들의 집행가능성은 여전히 유효하며 강제력을 갖습니다.
  4. 고객의 본 계약 위반과 관련하여 베스핀이 권리 실행이나 조치를 취하지 않았다고 하더라도, 이후 결과적으로 또는 유사하게 발생하는 행위에 대해 베스핀은 본 계약상의 권리 실행을 포기하는 것으로 간주되지는 않습니다.

Contract for GCP Resale

by Sangmi Park

Contract for GCP Resale

GCP 계약 일반 조건

2023년 04월 25일부터 체결하는 계약에 적용됩니다.

제1조(목적)

본 계약은 고객과 베스핀 사이에 Google Cloud Platform(GCP) 통합빌링 서비스, MSP Free-Tier 서비스에 대한 사용계약을 체결함에 있어 필요한 제반 사항을 명시하여 상호신뢰를 바탕으로 성실한 계약 이행과 공동의 이익 발전에 이바지함을 목적으로 합니다.

제2조(용어의 정의)
  1. “서비스”란 본 계약을 통하여 베스핀이 제공하는 GCP 통합빌링 서비스, MSP Free-Tier서비스, 그 외의 추가 서비스 등을 의미합니다.
  2. “통합빌링 서비스”란 GCP의 과금 체계 및 청구를 통합빌링 기능을 이용하여 베스핀을 통한 GCP 사용료의 납부 서비스를 의미합니다.
  3. “MSP Free-Tier 서비스”는 무상 제공 서비스로 헬프데스크, GCP Q&A, GCP FAQ를 고객에게 제공하는 서비스를 의미합니다.
제3조(계약기간)
  1. 본 계약의 기간은 계약표지의 계약기간으로 합니다. 다만, 양 당사자의 서면 합의로 본 계약의 기간을 변경할 수 있습니다.
  2. 본 계약의 기간 만료일이 특정일로 지정되어 있는 경우에는 본 계약의 만료 1개월 전까지 당사자 일방 또는 쌍방이 계약 내용의 변경을 요구하거나 계약의 종료를 통보하지 아니한 경우에는 본 계약은 동일한 조건으로 기간 만료일 다음날부터 1년씩 자동 연장됩니다.
제4조(계약상세조건)
  1. 고객은 본 계약 체결을 통해 서비스 사용과 관련하여 Google의 GCP 라이선스 계약조건을 포함한 관련 규정들을 준수할 것을 확약하며, 필요 시 고객은 인터넷 박스 클릭 등의 형태로 Google과 별도 약관, 라이선스 계약 등을 체결할 수 있습니다.
  2. 고객 계정의 관리에 대한 책임은 고객에게 있습니다.
  3. MSP Free-Tier서비스는 [첨부2] MSP Free-Tier 서비스 상세 내역에 따릅니다.
  4. 계약표지의 할인 조건에 따라 GCP할인이 제공되는 경우에 GCP 내의 3rd Party 및 Marketplace 제품들은 할인 적용 대상에서 제외됩니다.할인 적용 대상 제외 제품은 다음과 같습니다.- 3rd Party 제품 : https://cloud.google.com/skus/sku-groups/3rd-party-software– Marketplace 제품 : https://cloud.google.com/skus/sku-groups/google-cloud-marketplace
  5. 본 계약에 따라 제공되는 서비스가 본 계약에 명시된 바와 다르다고 고객이 판단할 경우, 고객은 베스핀에게 이러한 사실을 서면으로(지정된 이메일 포함) 통지할 수 있고, 베스핀은 이에 지체없이 대응합니다.
  6. 베스핀은 준거법에서 허용하는 최대 한도 내에서 본 계약에 따른 서비스를 있는 그대로, 유효한 범위에서 제공하며, 서비스가 아무런 장애나 에러가 없이 제공되거나, 본 계약서에 명시되지 않은 고객의 요구사항이나 기대치에 부합할 것을 보증하지 않습니다.
제5조(서비스 사용료)
  1. 서비스 사용료는 고객의 GCP 사용료를 기준으로 매월 1일부터 말일까지 월별로 산정되어 청구됩니다.
  2. 계약표지의 청구 및 결제 조건에 따라 베스핀은 고객에게 서비스 사용료를 청구하며, 고객은 베스핀에게 서비스 사용료를 지급해야 합니다.
  3. 고객이 지급기일 내에 서비스 사용료를 납부하지 않는 경우, 미납 서비스 사용료에 대하여 연 15%의 지연이자가 적용되며, 베스핀은 고객에게 미납 서비스 사용료에 대한 통지를 합니다.
제6조(권리의무의 양도금지)
  1. 고객은 임의로 본 계약상의 권리와 의무를 타인에게 이전하거나 양도, 담보 설정 등으로 처분할 수 없습니다. 다만, 고객에게 합병, 분할의 사유가 발생하는 경우는 예외로 합니다.
  2. 고객에게 합병, 분할의 사유가 발생하여 고객이 아닌 제3자(이하 “양수인”이라 합니다)가 고객이 베스핀과 체결한 본 계약에 따른 법적 지위를 승계하는 경우에는, 서비스의 사용을 위하여 고객 및 양수인은 즉시 회사에 지위 승계를 입증할 수 있는 서류를 첨부하여 베스핀에게 통지하여야 합니다.
제7조(비밀유지)
  1. 양 당사자는 본 계약의 체결 및 이행과 관련하여 알게 된 상대방의 업무상 비밀을 상대방의 사전 서면 동의 없이 제3자에게 공개, 유출, 제공하여서는 아니됩니다.
  2. 양 당사자의 상호, 로고는 영업비밀에 해당하지 않으며, 양 당사자는 상대방의 상호, 로고를 홍보 목적 등으로 사용할 수 있으나, 그 사용이 상대방의 명성을 저하시키거나 명예를 훼손하여서는 아니됩니다.
제8조(계약의 해지)
  1. 양 당사자는 다음 각 호의 사유가 있는 경우 상대방에 대한 최고절차 없이 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
    1. 발행한 어음이나 수표가 부도 또는 거래 정지된 경우
    2. 감독관청의 영업정지 또는 영업면허, 영업등록 등의 취소처분을 받은 때
    3. 파산절차 또는 회생절차가 시작되거나 이러한 신청이 있는 경우
    4. 가압류, 가처분 등으로 본 계약의 목적달성이 곤란하다고 판단되는 경우
  2. 양 당사자 중 일방이 본 계약을 위반한 경우 상대방은 14일의 기간을 두고 이를 최고한 후, 시정되지 않을 경우 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
  3. 양 당사자는 희망 해지일로부터 30일 전에 상대방에 대한 해지 통지를 함으로써 본 계약을 해지할 수 있습니다.
제9조(계약의 변경 및 해석)
  1. 본 계약의 효력기간 중에 본 계약의 내용을 변경할 필요가 있는 경우, 상호 합의에 의한 변경계약서로 변경이 가능하며, 변경계약서의 내용 중 본 계약과 상충되는 부분은 변경계약서의 내용이 우선하며, 변경계약서에서 정하지 아니한 사항에 대해서는 본 계약에 의합니다.
  2. 양 당사자는 본 계약에서 정하지 아니한 사항이나 추가 서비스에 관하여 부속합의서를 체결할 수 있습니다.
제10조(손해 배상)

고객 또는 베스핀이 본 계약을 위반하여 상대방에게 손해를 입힌 경우 또는 본 계약이 해지되는 경우에는 그 책임이 있는 당사자가 상대방이 입은 손해를 배상하여야 합니다. 다만, 손해 배상 청구일 또는 본 계약 해지일 직전월에 고객이 베스핀에게 지급한 서비스 사용료 금액을 한도로 배상합니다.

제11조(준법 경영)
  1. 고객과 베스핀은 본 계약 체결 및 이행 과정에서 상대방의 임직원에게 금품, 향응 등 일체의 경제적 이익 또는 과도한 식사/접대 등을 제공하거나 상대방 임직원과 도박, 금전 대차, 공동투자, 인사청탁, 고용보장 등 부적절한 행위(이하 “비위행위”)를 하여서는 아니됩니다.
  2. 고객 또는 베스핀이 본 조 제1항의 의무를 위반하는 경우, 위반 당사자는 민형사상 일체의 책임을 감수하여야 하며, 상대방은 별도의 최고 절차 없이 통지로써 통지일 즉시 본 계약을 해지할 수 있습니다.
  3. 고객과 베스핀은 본 계약의 공정성 확보를 위해 다음 각 호의 사항을 협조하도록 합니다.
    1. 고객 또는 베스핀의 임직원을 상대로 이루어진 비위행위가 발견되거나 비위행위에 대한 의혹이 있는 경우 상대방에게 그와 관련된 자료의 제출 또는 열람을 요구할 수 있으며, 이 경우 당사자는 적극적으로 협조하여야 합니다.
    2. 고객은 베스핀의 임직원으로부터 본 조 제1항에서 열거한 행위를 제의받거나, 이러한 사실을 인지한 때에는 베스핀 홈페이지의 윤리경영 핫라인에 즉각 신고하도록 합니다.
제12조(준거법 및 분쟁의 해결)
  1. 본 계약은 대한민국 법률에 의해 해석됩니다.
  2. 본 계약에 명시되지 아니한 사항은 양 당사자가 합의하여 정하고, 본 계약의 해석에 이견이 발생한 경우에는 관련 법령 및 일반 상관례에 의합니다.
  3. 본 조 제2항에 의한 해결이 불가능한 경우 양 당사자는 소송을 제기할 수 있으며, 이 경우 서울중앙지방법원을 제1심 관할법원으로 합니다.
제13조(기타)
  1. 베스핀이 고객에게 통지해야 하는 경우, 본 계약에서 별도로 명시하지 않는 한 고객이 베스핀에게 제공한 이메일 주소를 이용하여 통지합니다.
  2. 고객은 베스핀의 통지 사항을 수신할 수 있도록 연락처 정보를 항상 최신 상태로 유지할 의무가 있습니다. 연락처 정보가 업데이트 되어 있지 않아 고객에게 발생하는 불이익에 대해 베스핀은 어떠한 책임도 지지 않습니다.
  3. 만약 어떤 조항이 법원에 의해 무효 또는 집행이 불가하다고 판단되더라도, 그 나머지 조항들의 집행가능성은 여전히 유효하며 강제력을 갖습니다.
  4. 고객의 본 계약 위반과 관련하여 베스핀이 권리 실행이나 조치를 취하지 않았다고 하더라도, 이후 결과적으로 또는 유사하게 발생하는 행위에 대해 베스핀은 본 계약상의 권리 실행을 포기하는 것으로 간주되지는 않습니다.

베스핀글로벌, ‘e& 엔터프라이즈’로부터 투자 유치

by Sangmi Park

매일경제 / 2022-12-12 / 오대석 기자 / [기사 전문 보기]

  • e& 엔터프라이즈, UAE 아부다비 위치한 디지털 트랜스포메이션 선도 기업… 베스핀글로벌에 1,400억 원 규모 투자
  • 투자 유치 일환으로 베스핀글로벌과 e& 엔터프라이즈, 합작 법인 설립… 중동· 북아프리카·파키스탄 등에 클라우드 전문 서비스 제공 계획
  • 베스핀글로벌, e&의 지분 투자를 바탕으로 한국과 미국·동남아·일본·중국 등 해외 거점 중심 글로벌 확장 가속화 추진
  • 베스핀글로벌의 투자자들과도 약 2,000억 원 추가 투자 조건 합의

클라우드 딜리버리 플랫폼 기업 베스핀글로벌(https://bespinglobal.com, 대표 이한주)이 최근 아랍에미리트의 디지털 서비스 선도 기업 ‘e& 엔터프라이즈’(e& Enterprise, 구 에티살랏 디지털(Etisalat Digital))로부터 약 1,400억 원 규모의 투자를 유치했다고 12일 밝혔다.

이번 투자 유치의 일환으로, 베스핀글로벌과 e& 엔터프라이즈는 중동과 아프리카, 파키스탄 등을 주요 거점으로 활동하는 합작 법인을 설립한다. 해당 합작 법인은 역내 고객에게 클라우드 관리와 운영을 비롯한 클라우드 전문 서비스를 제공할 예정이다. 베스핀글로벌은 이번 e& 엔터프라이즈의 대규모 지분 투자를 기반 삼아 한국과 미국·동남아·일본·중국 등 각 해외 거점을 중심으로 한 글로벌 확장에 더욱 박차를 가할 계획이다.

이 외에도 베스핀글로벌은 투자자들과 전략적 인수 등을 목적으로 약 2,000억 원의 추가 투자에 대한 조건에도 합의했다고 밝혔다.

이번 투자 유치에는 베스핀글로벌이 보유한 클라우드 전문성과 기술력의 글로벌 시장 확장 가능성이 높게 평가 되었다. 특히 창립 이후 7년간 보여준 지속적인 성장세와 함께 미국과 중동, 동남아 등 최근 설립 및 확장된 해외 법인의 괄목할 만한 성과가 주요하게 작용했으며, 베스핀글로벌의 역량이 집약된 멀티 클라우드 관리 자동화 플랫폼 ‘옵스나우(OpsNow)’가 큰 역할을 했다는 후문이다.

베스핀글로벌은 클라우드 환경으로의 이전과 구축, 운영 및 관리, 데브옵스, 빅데이터, 보안 등 종합적인 클라우드 서비스를 제공하는 클라우드 딜리버리 플랫폼 기업이다. 현재 미국, 중동, 동남아, 중국과 일본 등 9개국 14개 오피스에 거점을 두고 유기적 협업 체계를 통해 글로벌 비즈니스에 박차를 가하고 있다. 전 세계 약 20여 기업이 등재되는 가트너 매직 쿼드런트에 ‘퍼블릭 클라우드 IT 트랜스포메이션 서비스 부문(Gartner Magic Quadrant for Public Cloud IT Transformation Services)’ 포함 6년 연속 이름을 올리며 이미 글로벌 경쟁력을 입증받은 바 있다.

e& 엔터프라이즈의 살바도르 앙글라다(Salvador Anglada) 대표는 “e& 엔터프라이즈는 고객의 디지털 잠재력을 극대화하는 것을 목표로 효과적이고 지능적이면서도 안전한 엔드 투 엔드(end-to-end) 디지털 솔루션을 설계, 제공 및 운영하며 고객과 긴밀히 협력하고 있다”고 소개하면서, “아랍에미리트 정부 및 기업의 파트너로서 베스핀글로벌에 대한 깊은 신뢰를 바탕으로, 클라우드 서비스 확장을 위해 베스핀글로벌과의 합작 법인 설립 및 투자를 결정하게 됐다”고 전했다.

베스핀글로벌의 이한주 대표는 “베스핀글로벌은 e& 엔터프라이즈와 협력하여, 클라우드 수요가 폭발적으로 증가하고 있는 중동 및 북아프리카, 파키스탄 지역을 대상으로 꼭 필요한 클라우드 관리 서비스를 제공할 예정이다. e& 엔터프라이즈가 고객과 맺고 있는 유대 관계와 베스핀글로벌이 보유한 클라우드 전문성을 토대로, 해당 지역에서의 클라우드 도입을 가속화할 수 있도록 최선을 다할 것”이라고 말했다. 또한 이한주 대표는 이번 투자 유치에 대해 “당사에 투자사로 합류하게 된 e&을 환영하며, 이번 투자 유치를 통해 글로벌 무대에서 신뢰할 수 있는 클라우드 서비스 제공 기업으로서 베스핀글로벌의 역량이 또 한 번 입증됐다”고 평가했다.

문의하기

베스핀글로벌, ‘AWS 컨트롤 타워’ 서비스 파트너 인증 획득

by Sangmi Park

ETNEWS / 2022-11-24 / 권혜미 기자 / [기사 전문 보기]

  • ‘AWS 컨트롤 타워’, 보안·운영 및 거버넌스에 맞도록 다중 계정의 AWS 환경 설정·관리를 손쉽게 지원
  • AWS 컨트롤 타워 서비스 파트너 인증 획득 위해 다수의 AWS 경험 및 성공사례 입증 필요
  • 베스핀글로벌, AWS 컨트롤 타워 기술에 대한 솔루션 개발 및 구축

<이미지: 베스핀글로벌, ‘AWS 컨트롤타워’ 서비스 파트너 인증 획득>

클라우드 딜리버리 플랫폼 기업 베스핀글로벌(https://bespinglobal.com, 대표 이한주)이 아마존 웹 서비스(Amazon Web Services, 이하 AWS)의 ‘AWS 컨트롤 타워’(AWS Control Tower)’ 서비스 파트너 인증을 획득했다고 24일 밝혔다.

‘AWS 컨트롤 타워’는 보안, 운영 및 거버넌스 모범 사례(Best Practice)를 기반으로 자동화된 랜딩 존(Landing Zone)을 제공하여, 다중 계정 환경을 손쉽게 설정하고 관리할 수 있도록 지원하는 서비스이다. 기업의 경우, 프로젝트나 팀 단위로 업무를 추진하면서 다양한 서비스를 각각 이용하기 때문에 AWS 계정을 여러 개 생성하여 이용하는 경우가 대다수이다. 이에 클라우드 설정이나 거버넌스가 복잡해지고 시간이 많이 소요되는 등 비즈니스 확장에 어려움이 발생할 수 있다. AWS 컨트롤 타워 서비스를 활용하면 각 계정을 자유롭게 활용하여 민첩성을 높일 수 있을 뿐 아니라 조직의 거버넌스에 맞춰 계정을 중앙에서 관리하는 것이 가능해진다.

이번 파트너 인증 획득으로 베스핀글로벌은 AWS 컨트롤 타워 서비스에 대해 상호 운용 가능한 솔루션을 개발 및 구축할 수 있음을 인정받았다. AWS 컨트롤 타워는 ‘커스터마이징을 위한 AWS 컨트롤 타워(Customizations for AWS Control Tower, CfCT)’와 ‘테라폼(Terraform)을 위한 AWS 컨트롤 타워 어카운트 팩토리(Account Factory)’의 두 가지 기술적인 프레임워크로 정의된다. AWS 고객과 파트너 기업은 이를 바탕으로 AWS 호환 솔루션을 구축할 수 있다.

AWS 컨트롤 타워 서비스 파트너로 선정되기 위해서는 AWS 모범사례와 더불어, AWS 관리 및 거버넌스 클라우드 환경 가이드에 따라, △제어 △네트워크 △신원 △보안 △모니터링 및 관찰 △클라우드 비용 관리 △소싱 △배포 등 8가지 기능 요소를 구축했음을 인정받아야 가능하다. AWS 관리 및 거버넌스 클라우드 환경 가이드는 AWS 서비스 및 타사 소프트웨어 솔루션에 대한 권장 사항을 포함하여 모범 사례 구현을 위한 지침을 제공한다. 베스핀글로벌은 이와 더불어, 풍부한 경험과 함께 AWS 솔루션을 원활하게 제공해왔음을 입증하여 AWS 컨트롤 타워 서비스 파트너 인증을 획득하였다.

베스핀글로벌은 AWS 컨트롤 타워 서비스를 활용하여 AWS가 권장하는 모범 사례에 기반한 랜딩존 환경을 제공한다. 특히 AWS 계정 사용자가 ISMS 및 전자금융 감독기준 등 국내 규범을 준수할 수 있도록 사전 구성된 정책·가드레일·보안·액세스 제어를 바탕으로, 고객에게 안정적인 다중 계정 환경과 함께 클라우드 도입 단계에 관계없이 고객의 비즈니스에 맞는 AWS 환경을 구축할 수 있도록 지원한다. 한편, 베스핀글로벌은 AWS의 프리미어 컨설팅 파트너이자 공인 MSP(Managed Service Provider)이며 AWS 마이그레이션 컴피턴시를 획득한 바 있다. AWS 웰-아키텍티드 (Well-Architected) 프로그램 파트너이기도 하다.

베스핀글로벌의 박종훈 클라우드 엔지니어링 부문장은 “베스핀글로벌은 이번 AWS 컨트롤 타워 제공 프로그램 파트너 인증 획득을 비롯, 클라우드 환경으로의 이전과 구축 및 운영 관리 등 종합적인 클라우드 서비스에 관해 다양한 역량을 인정받아왔다. 앞으로도 AWS가 제공하는 광범위한 서비스를 활용해 고객들이 기술 목표를 달성할 수 있도록 최선을 다할 것”이라고 설명했다.

(베스핀글로벌 웹사이트 내 ‘AWS 컨트롤 타워’ 서비스 소개 페이지 참고: https://www.bespinglobal.com/aws-built-on-control-tower)

문의하기
Load More Posts
문의하기 베스픽 구독하기
궁금한 점이 있다면 클릭해주세요.