MySQL 5.5: 성능과 확장성의 향상!

 

MySQL 5.5: 성능과 확장성의 향상!

By rob.young@oracle.com on November 9, 2010 10:19 PM

MySQL 5.5버전이 조만간 GA로 등장할 것이므로, 주목할만한 신기능들에 대한 블로그 글을 올려나갈 예정입니다. 우선 그동안 우리가 이룩한 성과를 먼저 말씀 드리고, 그 다음 자세한 발전 사항들에 대하여 이야기하겠습니다. MySQL 5.5에서는 MySQL의 테크니컬 아키텍쳐와 InnoDB 스토리지엔진의 기술이 병합되게 되었으므로, 이제 우리는 이 둘을 하나처럼 생각하면 되겠습니다. 이 둘은 앞으로도 많은 부분에서 협력 관계를 이어나갈 것입니다. (이렇게 할 수 있는 것은 오라클이 둘 모두를 소유하게 되었기 때문에...) MySQL 5.5와 새로 설계된 InnoDB 스토리지 엔진에 대해 꼭 알아야 할 내용들은: 

• 앞으로 오라클 InnoDB가 기본 스토리지 엔진으로 사용될 것입니다.
• 윈도우 환경에서의 성능과 확장성이 다른 플랫폼 이상을 낼 수 있게 되었습니다.
  
• 이제 MySQL도 멀티-코어 아키텍쳐를 채택한 최신 시스템들의 성능을 최대한 활욜할 수 있게 되었습니다. 이는 플랫폼에 관계없이 모두 적용 됩니다.
• 리플리케이션에 대한 모니터링, 관리, 사용등이 더욱 쉽고 좋아졌습니다.
• InnoDB 기능이 스토리지, 관리, 효율성등의 측면에서 더욱 향상되었습니다.
• 새로 추가된 SIGNAL/RESIGNAL구문과 파티셔닝 기능이 개발자분들에게 환호받을 것 입니다.
• 새로 추가된 Performance Schema가 도움이 될 것 입니다.

자 그럼 몇가지 주요 항목들을 살펴보며 시작하도록 합시다.

오라클의 InnoDB는 MySQL 스토리지 엔진 중 가장 널리 사용되고 있습니다. InnoDB 스토리지 엔진은 ACID적인 트랜잭션 기능을 제공하며, 높은 성능과 확장성을 보장해주는 독자적인 아키텍쳐를 가지고 있습니다. 또한 장애 복구 기능을 내장하고 있으며, 무결성, 높은 동시성, 빠른 응답 시간 등을 제공하고 있습니다. 대부분의 어플리케이션은 이러한 기능들을 필요로 하고 있으므로, InnoDB를 기본 스토리지 엔진으로 선택하게 됨으로써, 재설정 없이 어플리케이션 개발에 사용하는 것이 가능하게끔 되었습니다. MyISAM 및 다른 테이블 타입 또한 여전히 이용 가능합니다.

5.5버전에서의 InnoDB는 다시 설계되어 최신 하드웨어와 OS들의 장점을 모두 활용 가능합니다. 간결성을 위해 몇가지 주요 향상점과 MySQL 다큐멘테이션의 내용만 뽑아냈습니다. 

윈도우 환경에서의 성능과 확장성 향상 - 전통적으로 MySQL은 UNIX환경에서 더욱 나은 성능을 보였습니다. 요즘은 많은 개발자들이 윈도우 환경에서 개발을 하고 있으므로, MySQL 또한 윈도우 환경으로까지 발판을 넓혔습니다. 실제로 최근 MySQL 다운로드 경향은 윈도우용이 가장 높습니다. MySQL 5.5버전은 윈도우에 특화된 향상점들로 시스템 성능과 확장성이 증대하였습니다. 또한 어플리케은 높은 서비스 동시성과 유저 로드를 위해 디자인되었습니다. 윈도우 환경에 대한 주요 향상점은 아래와 같습니다. 

• MySQL에서는 이제 뮤텍스와 락킹 알고리즘을 윈도우 기본 동기화방식으로 대체합니다. 이를 통해 부차적으로, 너무 많은 수의 윈도우 이벤트가 발생하던 것과, InnoDB에서 소모하던 관련 이벤트 핸들들을 극적으로 절감시켰습니다.
• MySQL에서는 이제 POSIX쓰레드를 사용하는 대신 윈도우 작업 단위로 동작하며, 이를 통해 읽기/쓰기 전용 락 기능을 향상시켰습니다.
• MySQL에서는 이제 기본적으로 윈도우 OS가 제공하는 메모리 할당기능을 사용합니다.
• 다른 플랫폼에서만 이용되고 있었던 최적화 기법들이 윈도우 버전에도 적용되게 되었습니다.
• 윈도우에서만 발생해오고 있던 버그들 중 다수를 정리하였습니다.
  

윈도우 환경에서 동작하고있는 어플리케이션이나 웹 사이트들에 훨씬 더 비싼 SQL서버 제품을 사용하는것에 대한 훌륭한 대안이 될 것입니다.

쓰레드의 동시성 처리 성능 향상 - 이제 InnoDB를 통해 기본적으로 동시에 수행되는 쓰레드를 제한 없이 이용 가능하며, 멀티쓰레드와 멀티코어 시스템에서의 프로세싱 능력을 끌어 올렸습니다. innodb_thread_concurrency파라메터 값을 통하여 이러한 동장 방식에 대한 임계치를 정하여 줄 수 있습니다. 지난 오라클 오픈 월드 행사에서의 MySQL선데이 코너에서 이기능이 소개되었을때 박수를 받았었습니다.

OS에서 제공되는 메모리 할당기능 제어가능 - 이제 InnoDB의 메모리 할당기능과 OS에서 제공되는 메모리 할당 기능 중 더 효율이 높아보이는 기능을 사용하겠다고 사용자가 직접 지정해 줄 수 있습니다. 이는 새로이 제공되는 시스템 설정 파라메터인 innodb_use_sys_malloc를 통해 설정할 수 있습니다. 기본값은 1로, InnoDB에서 OS자원을 사용하겠다는 의미입니다.

더욱 빨라진 락킹 알고리즘을 통한 확장성 증가 - 이제 InnoDB는 대부분의 플랫폼에서(UNIX,Linux, Windows) POSIX쓰레드를 통해 향상된 뮤텍스와 읽기쓰기 락을 구현하는 대신, 독자적인 작동방식을 사용하게 되었습니다. 이는 InnoDB의 성능과 확장성을,특히 멀티 코어 시스템에서, 크게 증대시켜 주었습니다.

복구 성능 향상 - InnoDB는 자체적으로 장애 후 복구를 해주는 것으로 알려져있습니다. 기존 버전에서의 복구는 리두로그를 탐색하고 적용한 뒤에 스타트업이 일어났기에, 데이터의 양이나 서버 재기동에 소요된 시간등에 따라서 굉장히 긴 시간을 필요로 했었습니다. 장애 복구시간을 고려하여 극단적으로 낮은 사이즈의 리두로그를 사용하시던 분들도 이제 로그 파일 사이즈를 늘려도 괜찮겠습니다. 상황에 따라 다를 수는 있겠지만, 복구 시간이 10배 더 빨라졌다는 고객도 있었습니다.

다중 버퍼풀 사용 - 오늘날의 버퍼풀은 몇기가 크기의 사이즈를 갖고 있으며, 데이타 페이지들은 각기 다른 쓰레드를 통해 읽히며 변경되고 있습니다.  MySQL 5.5에서는 하나의 쓰레드가 버퍼풀을 업데이트 중일 때에 대기하며 일어나는 병목현상을 감소시켰습니다. 버퍼풀에 연결되어 작업하면 모든 구조들이 이제는 다중화 될 수 있게 되었습니다. 예를들면 뮤텍스 보호체계, LRU 정보, 플러쉬 리스트 같은 것들이 있습니다. 이제 몇개의 버퍼풀을 사용할 것인지를 사용자가 직접 제어하고 조절할 수 있습니다. 단, 호환성을 위하여 기본값은 여전히 1입니다. 이 기능은, 기존 수 기가 바이트에 달하는 버퍼풀 사이즈에서, 각각 1기가 정도의 버퍼풀 여러개로 나누어 쓰는 식으로 최적화가 가능합니다.

다중 롤백 세그먼트 사용 - 이제 InnoDB는 다중 롤백 세그먼트를 이용하여 성능, 확장성 그리고 동시에 서비스 될 수 있는 트랜잭션의 수를 매우 크게 증가시키게 되었습니다. 기존 버전의 InnODB에서는 최대 1023개의 트랜잭션만이 동시에 진행될 수 있었으나, MySQL 5.5에서는 128000개의 트랜잭션이 동시에 동작하며 언두 데이터를 생성해낼 수 있습니다. 이 기능을 통하여 처리량이 많을 때의 단일 롤백 뮤텍스에 대한 경합을 감소시킬 수 있게되었습니다. 

리눅스상에서의 네이티브 비동기 I/O - MySQL 5.5에서는 리눅스 시스템에서의 I/O요청 동시성을 증대시켰습니다. 기존 버전의 InnoDB에서는 시뮬레이티드 비동기 I/O방식을 사용하여 내부적으로 I/O콜을 정렬하여 비동기 I/O로 보이게끔 사용되었습니다. 보이지 않는 곳에서는 I/O요청 경합시에, 경합이 발생한 쓰레드는 먼저 발생한 I/O작업이 완료될때까지 기다려야했습니다. MySQL5.5에서는 리눅스와 윈도우 플랫폼에 한해 네이티브 비동기 I/O 방식을 제공하고 있습니다. 이 기능을 사용하려면 libaio 라이브러리가 설치되어 있어야하며, innodb_use_native_aio옵션을 설정해주어야 합니다. 이 기능은 기본값으로 사용하게끔 설정되어있는데, 사용자 시스템과의 호환성이 맞지 않는다면 사용하지 않게끔 재설정해주어야 합니다.

로그에 사용되는 뮤텍스의 기능 향상, 그리고 별도로 분리 관리하게 된 플러쉬 리스트 뮤텍스 - 기존의 버퍼풀과 플러쉬리스트를 포함하는 작업은,  단 하나의 버퍼풀 뮤텍스를 통해 보호받았으므로, 이에 대한 경합이 발생하여 불필요하게 시간을 잡아먹었습니다. MySQL 5.5에서는 플러쉬 리스트를 관리하는 뮤텍스가 별로도 존재하며, 다른 버퍼풀 사용 작업과의 경합을 감소시키게 되었습니다. 이는 기본값으로 설정되어 있으며, 별도의 세팅이 필요하지는 않습니다. 다중 버퍼풀을 사용하면 더욱 향상된 성능을 보장받을 수 있는데, 각각의 버퍼풀이 각각의 플러쉬 리스트 뮤텍스를 갖게되어 경합으로부터 훨씬 더 자유로울 수 있기 때문입니다.

발전된 퍼지 스케쥴링 - InnoDB에서의 퍼지 작업은 주기적으로 수행되는 가비지 컬렉션 작업의 한 종류였습니다. 기존 버전에서는 퍼지 작업이 마스터 쓰레드에 의해 동작하였으며, 그동안 다른 데이터베이스 작업들은 대기해야 했었습니다. MySQL 5.5에서는 이 작업이 개별의 쓰래드에서 직접 수행되며, 더 높은 동시성을 보장해줍니다. innodb_purge_threads옵션을 통하여 이 기능을 제어할 수 있으며, 기본값은 0으로 되어있고, 1을 넣어 주면 기존대로 동작합니다.

트랜잭션 중의 메타데이터 락킹 성능 향상 - 기존 버전의 MySQL에서는 하나의 트랜잭션이 테이블에 대한 메타데이타 락을 획득하면, 해당 락은 트랜잭션이 아닌 구문에서 보유하게 되어, 해당 구문이 종료될 때에 락이 반납되었습니다. 만약 구문중에 DDL명령이 들어있을 때에, 다른 세션에서 해당 테이블을 이미 사용중이라면, 잘못된 순서로 바이너리 로그가 기록될 수 있는 문제가 있었습니다. MySQL 5.5에서는 다른 세션에 의해 사용중인 상태의 테이블에 대해서는 DDL문장을 허가하지 않음으로써 개별 트랜잭션의 순차를 더욱 확실히 잡아주었습니다. 이 기능의 구현을 위해 테이블 메타데이터에 대한 락은 구문이 종료 되었을 때가 아닌, 트랜잭션이 종료되었을 때에야 반납되게끔 조정되었습니다. 이 메타데이타 락킹 기능으로 인해, 하나의 트랜잭션에 의해 이용되고 있는 테이블은, 그 트랜잭션이 완료되기 전에는 다른 세션에 의해 DDL구문이 사용될 수 없게끔 되었습니다. 예를 들면, 테이블 t1이 하나의 트랜잭션에 의해 사용 중일 때에, 다른 세션에서 DROP TABLE t1명령을 날린다면, 이 명령문은 더 앞의 트랜잭션이 완료된 이후에 실제 실행이 되게 됩니다.

이러한 변경으로 인해 MySQL이 내부적으로 테이블 락을 더욱 잘 관리하게 되었으며, OLTP성 환경에서의 성능도 개선되게 되었습니다.  DDL이 자주 발생하는 구조에서도 성능이 좋아졌습니다.

MySQL5.5와 InnoDB에 대한 다큐멘테이션에서는 성능과 확장성의 모든 신기능들과 이를 어떻게 적용시켜야 하는지에 대하여 제공하고 있습니다.

다음 글에서는 MySQL 5.5의 리플리케이션과 가용성의 향상에 대하여 다룰 예정입니다. 읽어주셔서 감사합니다.