개발 피드 목록

네이버랩스의 인재상은 passionate self-motivated team player입니다. 어쩌면 '자기주도적 팀플레이어'라는 말은 형용모순(形容矛盾)일 지도 모릅니다. 하지만 우린 계속 시도했고, 문화는 계속 쌓여갑니다. 다양한 분야의 전문가들이 경계없이 협력하고 스스로 결정하며 함께 도전하는 곳의 이야기를 전합니다. How to work at NAVER LABSH2W@NL 시리즈 전체보기지난해 11월, 네이버랩스는 국내 기업 중 최초로 도로 HD맵 데이터셋을 무상 배포했습니다. 수많은 국내 자율주행 연구자들을 위해서입니다. 그렇다면, 왜 자율주행 연구에 HD맵은 중요할까요? 안전하고 효과적인 자율주행을 위해서입니다. 센서 데이터와 HD맵을 연동하면 고층 빌딩이 즐비한 도심에서도 현재 위치를 끊김없이 정확하게 인식할 수 있도록 해주고, 복잡하게 얽혀있는 도로 구조를 광범위하게 파악해 효과적인 경로 계획을 세울 수 있으며, 신호등/횡단보도 등의 위치를 HD맵을 통해 미리 확인해 실시간 인지 정확도를 높일 수도 있습니다. 그래서 네이버랩스는 자율주행 연구 시작 시점부터 HD맵 솔루션을 함께 연구해 왔습니다. 그 결과가 하이브리드 HD 매핑입니다. 항공사진과 MMS 데이터를 융합해 고정밀 지도를 만드는 기술입니다. 다른 어디에서도 시도하지 못했던, 가장 독창적인 방식의 매핑 솔루션은 어떻게 개발되었을까요? 그 주역들의 이야기를 들어보았습니다.Q. 왜 HD맵 기술을 개발하나요?HD맵은 도로 자율주행을 위한 시작(김형준|시스템 소프트웨어 개발) 자율주행 시대가 온다고 합니다. 그렇다면, 반드시 그보다 먼저 필요한 것은 HD맵입니다. 자율주행 차량이 도로를 안전하게 주행하려면, 차선 단위의 아주 정밀한 정보가 필요하기 때문입니다. 보통은 MMS (Mobile Mapping System) 차량이 일일이 돌아다니며 수집한 도로 데이터로 HD맵을 제작하는 것이 일반적이지만, 이 방식은 소요되는 시간과 비용이 많습니다. 지역이 광범위해지면 더 많은 리소스가 필요하고요. 우리는 그걸 획기적으로 줄일 수 있는 방법을 찾고 싶었습니다. 정확도는 유지하되, 도시 단위의 넓은 지역을 더 빠르고 효율적으로 제작하는 솔루션을 찾았습니다. 그 결과가 네이버랩스의 하이브리드 HD 매핑 기술입니다. 항공 사진을 통해 대규모 지역의 도로의 레이아웃과 건물 정보 등을 얻고, 이 위에 자체 MMS 차량인 R1으로 취득한 데이터를 정합해서 HD맵을 만듭니다. R1이 최소한만 주행해도 HD맵을 제작할 수 있기 때문에, 소요되는 시간과 비용을 획기적으로 줄일 수 있습니다.(전준호|비주얼 피처맵 개발) 이렇게 완성된 HD맵에는 도로 자율주행에 필수적인 고정밀 정보들이 담겨 있습니다. 도로의 구조 정보인 로드 레이아웃 맵(Road Layout Map), 기하 정보를 가진 포인트 클라우드 맵(Point Cloud Map), 시각 정보를 가진 비주얼 피처 맵(Visual Feature Map) 등이죠.(신용호|센서 캘리브레이션) 우리가 하이브리드 HD 매핑이란 새로운 방식을 고안하고 완성할 수 있었던 건, 그 동안 지속적으로 개발해 온 자율주행 기술과 항공 사진 기반의 지도 생성 기술을 모두 내재화하고 있었기 때문이죠.도시 규모의 HD맵을 효율적으로 제작할 수 있는 독자 솔루션(이진한|PM/소프트웨어 개발) 사실 자율주행 기술을 연구하는 회사들은 많습니다. 그런데 독자적인 HD 매핑 기술까지 보유한 회사는 의외로 많지 않아요. 네이버랩스도 처음엔 그랬어요. 자율주행 프로젝트가 시작된 2016년 무렵엔 자체 HD 매핑 기술이 없다는 점이 아쉬웠어요. 센서만으로는 얻기 힘든 정보들을 미리 담아둘 수 있는 그릇이 HD맵인데, 바로 그 정보들이 자율주행의 성능을 높이는데 큰 역할을 하거든요. 결국 이 그릇을 만드는 방법을 내재화했죠. 이제는 도시 규모의 HD맵을 효율적으로 제작할 수 있는 독자 솔루션을 갖췄습니다. 실제로 이 결과물을 Localization에 바로 활용하여 자율주행 기술도 함께 고도화하고 있습니다.Q. 어떤 협업을 통해 개발되었나요?아웃풋이 바로 새로운 인풋이 되는(이진한|PM/소프트웨어 개발) 하이브리드 HD 매핑은 여러 분야의 전문가들이 함께 했습니다. 한 프로젝트의 결과물이 다른 프로젝트의 입력으로 연결되는 구조라고 할 수 있겠네요. 예를 들어 R1 하드웨어 장비 개발 프로젝트는 Sensor Calibration 프로젝트로 이어지고, 항공 매핑을 통해 만들어진 로드 레이아웃 데이터에 MMS 데이터를 연결하고… 이렇게 유기적인 의존 관계로 진행되었습니다.(이웅희|센서 데이터 툴 개발) 자체 개발한 MMS 차량인 R1에는 다수의 카메라, 라이다, GPS, 자이로센서 등 많은 센서들이 탑재되어 있어요. 이러한 개별 센서들에 대한 드라이버 개발은 물론 전체 센서 데이터가 동시에 들어왔을 때 유실 없이 저장할 수 있는 시스템 개발, 그리고 운용 소프트웨어 개발이 필요했습니다.(신용호|센서 캘리브레이션) R1이 수집된 데이터를 융합하기 위해서 반드시 필요한 과정이 있습니다. 캘리브레이션입니다. 각 센서간에는 상대적인 위치와 방향 등의 차이가 발생하는데, 캘리브레이션을 통해 정확하게 매칭을 시켜야 하죠. 그렇지 않으면 수집한 데이터들을 제대로 사용할 수가 없습니다.하늘과 도로에서 획득한 데이터를 융합하여 도시 규모의 HD맵 생성(김진석|항공 매핑) R1이 지상을 담당한다면, 저희는 하늘에서 찍은 정보를 활용합니다. 항공 사진을 통해 정확도를 획기적으로 높이는 방식을 개발했습니다. 항공 사진에서 8cm 해상도로 왜곡이 제거된 연직 정사영상(TrueOrtho)을 생성한 후, 도로 영역의 2D/3D 로드 레이아웃을 생성합니다. 여기에 R1이 수집한 포인트 클라우드 데이터를 정합하면, 대규모 지역의 HD맵을 빠르고 효율적으로 만들 수 있게 됩니다.(임준택|라이다 피처맵 개발) 이처럼 R1이 도로의 포인트 클라우드를, 항공기가 대규모 지역의 로드 레이아웃을 스캔해 결합하는 방식은 아주 새로운 솔루션입니다. 물론 그냥 붙인다고 HD맵이 바로 나오는 것은 아닙니다. 스캔 데이터에서 자동차나 사람같이 불필요한 부분을 지우는 딥러닝 모델을 만들고, HD맵을 사용할 차량이나 로봇을 위한 특징점을 추출하는 과정도 필수적입니다.서로 다른 분야의 전문가, 하나의 팀(전준호|비주얼 피처맵 개발) HD맵을 이루는 요소들, 즉 Road Layout Map/Point Cloud Map/Visual Feature Map 등의 구축 알고리즘을 각기 개발해, 이 데이터들을 잘 포함하고 있는 HD맵을 제작하는 거죠. 이렇듯 많은 팀의 협력으로 완성한 매핑 솔루션입니다. 항공 사진의 정합과 인식, MMS 차량의 데이터 수집을 위한 장비와 센서 시스템 구축, GPS와 LiDAR 데이터를 이용한 위치 인식 기술, 시각 정보 추출을 위한 딥러닝 기술 등 서로 다른 전문가가 하나의 팀으로 모여있어요. 같은 목적을 갖고 밀접하게 협업하기에 더 높은 수준의 연구와 개발이 가능한 것 같습니다.“결과도 중요하죠. 하지만 문제를 같이 정의하고, 함께 해법을 찾아가는 과정은 더 중요한 것 같아요. 그래야 좋은 결과가 이어질 수 있으니까요.”(김형준|시스템 소프트웨어 개발) 다양한 분야의 전문가들이 모여 유기적인 협업이 언제든 가능하다는 것은 프로젝트에서 난항을 겪을 때 큰 힘을 발휘합니다. 예전에, 데이터 취득 시스템의 안정성에 문제가 생긴 적이 있어요. 그때 하드웨어 엔지니어와 소프트웨어 엔지니어들이 모두 모여 동시에 검토를 했습니다. 필드를 돌며 문제 발생 시점의 상황을 함께 체크하고, 그 중 기구 엔지니어 분들이 원인을 찾아 문제를 해결했습니다.(김상진|하드웨어 설계) 저도 그때가 기억나요. 차량 진동으로 인한 간헐적인 회로 단락이 원인이었죠. 짧은 시간에 가장 정확한 답을 찾기 위해 필요한 것은, 역시 유기적인 팀웍인 것 같아요.(신용호|센서 캘리브레이션) 팀이 없는 것처럼 협업이 잘 된다는 점도 자랑하고 싶어요. 함께 잘하기 위해서라는 목표만으로 일에 몰입할 수 있다는 건 정말 좋은 경험이죠.Q. 경과, 그리고 목표는?서울시 2,000km 로드 레이아웃 지도 구축(김진석|항공 매핑) 서울시 4차선 이상 도로 2,000km에 대한 로드 레이아웃 구축을 완료했습니다. 자율주행에 필요한 도로 구조 정보(차선, 중앙선, 정지선, 좌회전 등의 노면표시)를 정밀한 벡터 데이터 형식으로 변환했습니다. 서울시만큼 큰 대도시 규모의 매핑이란 관점에서 보자면, 국내에서 유일한 기술입니다.(김형준|시스템 소프트웨어 개발) 하이브리드 HD 매핑의 자체 프로세스가 정립되면서, 예전과 비교해 최소한의 작업으로 원하는 지역의 HD맵을 생성할 수 있게 되었습니다. 무상 공개한 판교 및 상암 지역 HD맵도 이 결과물 중 하나죠.(이진한|PM/소프트웨어 개발) 상암/판교 지역의 HD맵 무상 배포를 DEVIEW에서 발표했을 때가 정말 보람되었던 것 같아요. 국내에서 자율주행을 연구하고 있는 많은 기관에서 데이터셋 신청을 해주셨어요. 저희의 솔루션으로 만든 HD맵이 국내 자율주행 기술 고도화에 도움이 될 수 있었으면 좋겠습니다.(전준호|비주얼 피처맵 개발) 네이버랩스의 HD맵은 도로 위의 정밀 위치 인식을 최종 목표로 하고 있습니다. 예를 들어 Visual Feature Map의 경우 위치 인식에 필요한 최소한의 시각 정보와 기하 정보를 Descriptor 형태로 경량화 했기 때문에, 대규모 도심 지역의 데이터도 용량이 아주 작습니다. 이러한 최적화를 계속할 계획이고요.미래 모빌리티 세상으로 한 걸음 더(김상진|하드웨어 설계) 매핑 시스템 고도화의 목표는 결국 신뢰성 높은 지도를 만드는 것에 있습니다. 하드웨어 시스템의 신뢰성/유연성/운용성을 빠르게 개선하고, 이를 더욱 저비용으로 구현할 수 있도록 개발을 지속하고 있어요. 이런 연구들의 결과가 모이고, 이러한 고정밀 데이터가 쌓이면, 우리가 상상하고 있는 미래 모빌리티 세상을 더욱 앞당길 수 있다고 생각합니다.

편집자 주문맥에 따라 ‘Transaction’과 ‘트랜잭션’으로 영어와 한글을 혼용함.문맥에 따라 ‘LOCK’과 ‘lock’으로 대문자와 소문자를 혼용함.OverviewMySQL DB는 일반적인 운영환경에서 뛰어난 성능을 제공합니다. 특히 적은 양의 자료가 빈번하게 교류되는 환경에서는 더욱 빛을 발하죠. 국내에서는 주로 작은 규모의 웹사이트를 구축할 때 MySQL을 사용합니다. 그런데 문제는 사이트의 규모가 커지면서부터 생긴다는 것이죠. 조금씩 느려지는 Query가 생기면 원인도 파악하고, Query를 튜닝하고, 설계도 변경하지만 MySQL의 특징적인 문제를 곧 만나게 됩니다.테이블을 복제(CREATE SELECT)하거나 다른 테이블로 옮기면(INSERT SELECT) 작업을 하는 동안 SELECT 절에 있는 테이블들이 Lock이 걸립니다. 게다가 다른 Session에서 해당 테이블을 수정(UPDATE / DELETE)하면 복제와 이동을 마칠 때까지 대기 상태로 있어야 한다는 것입니다. 이러한 문제는 시스템을 구축하고 자료가 일정량 쌓이기 전까지는 알 수 없습니다. 또한 Oracle과 같은 DB를 사용하던 사용자가, MySQL을 사용하면 이와 같은 문제가 있을 것이라고 생각하기도 어렵습니다.이러한 특징을 가진 MySQL의 Transaction Isolation Level을 알아보고자 합니다. Transaction Isolation Level 은 Transaction의 경리 수준을 말합니다. 트랜잭션 처리 시 다른 트랜잭션에서 접근해 자료를 수정하거나 볼 수 있도록 하는 수준입니다.Transaction Isolation Level의 종류와 특성Transaction Isolation Level에는 READ UNCOMMITTED, READ COMMIITED, REPEATABLE READ, SERIALIZE 네 가지 종류가 있습니다. 1)READ UNCOMMITTED1) COMMIT 되지 않은 데이터에 다른 트랜잭션에서 접근할수 있다.2) INSERT, UPDATE, DELETE 후 COMMIT 이나 ROLLBACK에 상관없이 현재의 데이터를 읽어온다.3) ROLLBACK이 될 데이터도 읽어올 수 있으므로 주의가 필요하다.4) LOCK이 발생하지 않는다.READ COMMIITED1) COMMIT 된 데이터에 다른 트랜잭션에서 접근할 수 있다.2) 구현 방식이 차이 때문에 Query를 수행한 시점의 데이터와 정확하게 일치하지 않을 수 있다.3) LOCK이 발생하지 않는다.4) MySQL에서 많은 양의 데이터를 복제하거나 이동할 때 이 LEVEL을 추천한다.REPEATABLE READ1) Default LEVEL이다.2) SELECT시 현재 시점의 스냅샷을 만들고 스냅샷을 조회한다.3) 동일 트랜잭션 내에서 일관성을 보장한다.4) record lock과 gap lock이 발생한다.5) CREATE SELECT, INSERT SELECT시 lock이 발생한다.SERIALIZE1) 가장 강력한 LEVEL이다.2) SELECT 문에 사용하는 모든 테이블에 shared lock이 발생한다.LOCK과 테이블, 어떻게 해결할 수 있을까?지금부터는 관련된 내용을 확인해보겠습니다. 우선 현재의 경리 수준부터 알아보겠습니다.mysql> SHOW VARIABLES WHERE VARIABLE_NAME='tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.00 sec) 다음으로 TEST 테이블을 만듭니다. 이때 SELECT절의 테이블을 UPDATE할 경우, 대기 상태로 빠지는 것을 확인해보겠습니다. 테이블을 만들고 상태를 확인합니다.CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 ; -- 생성시 INFORMATION_SCHEMA.PROCESSLIST 로 상태를 확인합니다. mysql> SELECT -> * -> FROM INFORMATION_SCHEMA.PROCESSLIST -> WHERE USER = 'hansj' -> AND COMMAND <> 'Sleep' -> \G *************************** 1. row *************************** ID: 11004 USER: hansj HOST: 192.168.1.150:50711 DB: test COMMAND: Query TIME: 5 STATE: Sending data INFO: CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 1 row in set (0.00 sec) 다음으로 테이블 생성 시 UPDATE를 해 대기 상태로 빠지는지 확인해보겠습니다.UPDATE test.TB_PROD_BAS SET PROD_MEMO = 'TEST' WHERE PROD_ID = 1 ; mysql> SELECT -> * -> FROM INFORMATION_SCHEMA.PROCESSLIST -> WHERE USER = 'hansj' -> AND COMMAND <> 'Sleep' -> \G *************************** 1. row *************************** ID: 11004 USER: hansj HOST: 192.168.1.150:50711 DB: test COMMAND: Query TIME: 24 STATE: Sending data INFO: CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 *************************** 2. row *************************** ID: 11006 USER: hansj HOST: 192.168.1.150:50719 DB: test COMMAND: Query TIME: 22 *****이부분 중요합니다.****** STATE: updating *****이부분 중요합니다.****** INFO: UPDATE test.TB_PROD_BAS SET PROD_MEMO = 'TEST' WHERE PROD_ID = 1 2 rows in set (0.00 sec) 위의 TIME을 보면 테이블이 생성될 때까지 대기하고, UPDATE 문의 상태가 updating 으로 표시됩니다. 하지만 이렇게 나올 경우 건수가 많으면 실제 UPDATE 중인지 대기상태인지 확인하기가 어렵습니다. LOCK이 걸린 테이블을 확인하려면 INNODB LOCK 테이블로 정확하게 알 수 있습니다. 아래 세 가지 테이블로 확인해보겠습니다. 보다 자세한 설명은 MySQL 홈페이지를 확인합니다.information_schema.INNODB_TRXLOCK을 걸고 있는 프로세스 정보information_schema.INNODB_LOCK_WAITS현재 LOCK이 걸려 대기중인 정보information_schema.INNODB_LOCKSLOCK을 건 정보위의 각 항목마다 테이블 생성 및 UPDATE 시 정보가 어떻게 나타나는지 확인해보겠습니다.1.information_schema.INNODB_TRXmysql> SELECT -> T101.TRX_ID -> ,T101.TRX_STATE -> ,T101.TRX_STARTED -> ,T101.TRX_REQUESTED_LOCK_ID -> ,T101.TRX_WAIT_STARTED -> ,T101.TRX_WEIGHT -> ,T101.TRX_MYSQL_THREAD_ID -> ,T101.TRX_ISOLATION_LEVEL -> ,SUBSTR(T101.TRX_QUERY,1,10)AS TRX_QUERY -> FROM information_schema.INNODB_TRX T101 -> ; +---------+-----------+---------------------+-----------------------+---------------------+------------+---------------------+---------------------+------------+ | TRX_ID | TRX_STATE | TRX_STARTED | TRX_REQUESTED_LOCK_ID | TRX_WAIT_STARTED | TRX_WEIGHT | TRX_MYSQL_THREAD_ID | TRX_ISOLATION_LEVEL | TRX_QUERY | +---------+-----------+---------------------+-----------------------+---------------------+------------+---------------------+---------------------+------------+ | 8771591 | LOCK WAIT | 2019-05-27 16:15:53 | 8771591:70031:4:306 | 2019-05-27 16:15:53 | 2 | 11006 | REPEATABLE READ | UPDATE tes | | 8771586 | RUNNING | 2019-05-27 16:15:51 | NULL | NULL | 1538969 | 11004 | REPEATABLE READ | CREATE TAB | +---------+-----------+---------------------+-----------------------+---------------------+------------+---------------------+---------------------+------------+ 2 rows in set (0.00 sec) TRX_ID_STATE트랜잭션의 상태를 나타냅니다. 실행 중인지 LOCK WAIT 상태인지 알 수 있습니다.TRX_MYSQL_THREAD_IDPROCESSLIST 의 ID를 나타냅니다.TRX_ISOLATION_LEVELISOLATION LEVEL을 나타냅니다.따라서 위의 내용을 보면 CREATE TABLE이 실행 중인 것과, UPDATE가 LOCK WAIT인 것, 그리고 관련된 PROCESSLIST의 ID까지도 알 수 있습니다2.information_schema.INNODB_LOCK_WAITSmysql> SELECT -> * -> FROM information_schema.INNODB_LOCK_WAITS T101 -> ; +-------------------+---------------------+-----------------+---------------------+ | requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id | +-------------------+---------------------+-----------------+---------------------+ | 8771591 | 8771591:70031:4:306 | 8771586 | 8771586:70031:4:306 | +-------------------+---------------------+-----------------+---------------------+ 1 row in set (0.01 sec) requesting_trx_idLOCK WAIT 인 TRX_IDblocking_trx_idLOCK 을 건 TRX_ID현재 LOCK이 걸린 TRX_ID와 LOCK을 걸어둔 TRX_ID를 알 수 있습니다.3.information_schema.INNODB_LOCKSmysql> SELECT -> * -> FROM information_schema.INNODB_LOCKS -> ; +---------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ | lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data | +---------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ | 8771591:70031:4:306 | 8771591 | X | RECORD | `test`.`TB_PROD_BAS` | PRIMARY | 70031 | 4 | 306 | 1 | | 8771586:70031:4:306 | 8771586 | S | RECORD | `test`.`TB_PROD_BAS` | PRIMARY | 70031 | 4 | 306 | 1 | +---------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ 2 rows in set (0.01 sec) lock_trx_idLOCK 과 관련된 TRX_IDlock_modeX 쓰기, S 읽기 2)어떤 테이블이 LOCK을 걸고 있는지 알 수 있습니다.위의 내용들을 통해 REPEATABLE READ에서 CREATE SELECT시 SELECT 테이블에 LOCK이 걸려 UPDATE가 대기하게 되는 것을 알 수 있습니다. 이번에는 Transaction Isolation Level 을 READ COMMIITED로 변경하고 CREATE SELECT 및 UPDATE를 진행해보겠습니다.SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SHOW VARIABLES WHERE VARIABLE_NAME='tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | READ-COMMITTED | +---------------+-----------------+ 1 row in set (0.00 sec) UPDATE 문은 다음과 같이 수행됩니다. mysql> UPDATE test.TB_PROD_BAS -> SET PROD_MEMO = 'TEST' -> WHERE PROD_ID = 1 -> ; Query OK, 0 rows affected (0.04 sec) Rows matched: 1 Changed: 0 Warnings: 0 기존에 대기했던 것과 다르게 0.04초가 걸렸습니다.mysql> SELECT -> * -> FROM INFORMATION_SCHEMA.PROCESSLIST -> WHERE USER = 'hansj' -> AND COMMAND <> 'Sleep' -> \G *************************** 1. row *************************** ID: 11004 USER: hansj HOST: 192.168.1.150:50711 DB: test COMMAND: Query TIME: 9 STATE: Sending data INFO: CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 1 row in set (0.00 sec) -- 프로세스 정보도 CREATE TABLE 만 진행중임을 알수 있습니다. mysql> SELECT -> T101.TRX_ID -> ,T101.TRX_STATE -> ,T101.TRX_STARTED -> ,T101.TRX_REQUESTED_LOCK_ID -> ,T101.TRX_WAIT_STARTED -> ,T101.TRX_WEIGHT -> ,T101.TRX_MYSQL_THREAD_ID -> ,T101.TRX_ISOLATION_LEVEL -> ,T101.TRX_QUERY -> FROM information_schema.INNODB_TRX T101 -> ; +---------+-----------+---------------------+-----------------------+------------------+------------+---------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | TRX_ID | TRX_STATE | TRX_STARTED | TRX_REQUESTED_LOCK_ID | TRX_WAIT_STARTED | TRX_WEIGHT | TRX_MYSQL_THREAD_ID | TRX_ISOLATION_LEVEL | TRX_QUERY | +---------+-----------+---------------------+-----------------------+------------------+------------+---------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 8771856 | RUNNING | 2019-05-27 17:17:45 | NULL | NULL | 4594347 | 11004 | READ COMMITTED | CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 | +---------+-----------+---------------------+-----------------------+------------------+------------+---------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) READ COMMITTED LEVEL로 CREATE만 수행 중인 것을 알 수 있습니다.mysql> SELECT -> * -> FROM information_schema.INNODB_LOCK_WAITS T101 -> ; Empty set (0.00 sec) mysql> SELECT -> * -> FROM information_schema.INNODB_LOCKS -> ; Empty set (0.00 sec) LOCK을 걸고 걸린 것이 없어 내용도 없습니다.Conclusion지금까지 Transaction Isolation Level 을 기준으로 CREATE SELECT 시 SELECT 에 사용되는 테이블도 LOCK이 걸릴 수 있는 것을 확인했고, 그에 따른 해결 방법까지 알아봤습니다.INSERT INTO SELECT에서도 같은 현상이 나타납니다. 그렇기 때문에 운영 중인 테이블을 복제(CREATE SELECT)하거나 다른 테이블로 옮길 경우(INSERT SELECT) Transaction Isolation Level을 READ COMMITTED 변경하고 작업하기를 권장합니다.그렇지 않으면 관련된 TABLE은 LOCK이 걸리고, 관련 Query들이 대기 상태로 빠지면서 시스템 장애가 발생할지도 모릅니다.참고1)MySQL :: MySQL 5.6 Reference Manual :: 14.7.2.1 Transaction Isolation Levels2)MySQL :: MySQL 5.6 Reference Manual :: 14.7.1 InnoDB Locking글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만