1,2회에 거쳐서, DB가 무엇인지, 그리고 어떤 역할을 하는지에 대해서 알아보았습니다.
이번 3회에서는 모든 온라인 게임이 하지 않을 수 없는, 많은 게이머들의 가슴을 태우는 정기점검과 일어나면 엄청난 소요가 일어나는 백섭의 문제에 대해서 알아보고자 합니다.
| 정기점검 |
보통 온라인 게임들은 주 1회 1~4시간 정도의 정기점검을 수행하고 있습니다. 사실, 게이머들은 정기점검 시간이 왜 필요한지, 그리고 그 시간에 게임 회사에서 어떤 일이 일어나는지 공지사항에 적혀 있는 문구외에는 전혀 알 길이 없습니다.
다음 어느 온라인 게임의 정기점검 공지 사항입니다.
|
안녕하세요. ****입니다.
****에서는 보다 안정적인 서비스를 제공해드리기 위하여
해당 시간동안 게임서비스와 홈페이지의 이용이 중단되오니
일시 : 10월 4일 목요일 오전 8시 ~ 10시까지 (2시간)
고객 여러분께서는 8시 정기점검이 시작되기 이전에 캐릭터를 안전한 곳으로
안정적인 서비스를 제공하기 위하여 항상 최선을 다하는 ****가 되겠습니다.
감사합니다. |
위 공지사항에서 볼 수 있는 것처럼, 정기점검의 내용은 주로 네트워크 작업과 서버작업, DB작업 이정도로 크게 나눌수 있습니다.
보통 게임서버들은 IDC(Internet Data Center)라는 곳에 입주해 있습니다. 그러다 보니, 서버 관리작업을 위해서는 IDC까지 가서 엄청난 기계들의 아파트 사이에서 소음과 추위(정말 IDC는 항온항습기와 각종 장비들 덕분에 너무 시끄럽고, 언제나 춥습니다 ㅠ.ㅠ)에 시달리며 작업을 해야 합니다.
(삽화: onesound)
각설하고, 보통, 잘 짜여진 운영시스템을 가진 회사라면, 서버군을 아우르는 라우터와 부하 분산을 위한 L4 Switch장비 밑에 최소 2대이상의 웹서버와, 게임서버군, DBMS서버, 그리고 RAID로 구성된 Storage나 SAN 혹은 NAS같은 저장장치로 구성되어 있습니다.
이와 비슷한 구조의 테스트 서버 군을 가지고 있으면 최상이겠지만, 비용의 문제상 그렇게 구성하긴 힘든것이 현실입니다.
| 정기점검 수행 절차 |
대체로, 정기점검 시간이 되면, 라우터에서 해당 서버로의 접속을 차단하고, 웹페이지는 정기점검 페이지로 변경하는 스크립트를 실행하게 됩니다. 그리고 나서, 이제부터 서버관리자들의 시간을 다투는 전투가 시작됩니다.
정기점검 전에 알려졌던 문제점과 해당 문제점을 고치기 위한 작업의 리스트를 가지고, 순차적으로 작업을 수행합니다.
|
1. 서버의 백업 작업을 수행합니다. 2. DBA(Database Administrator : 데이터베이스 관리자)는 데이터베이스의 Full backup을 수행합니다. 3. 데이터베이스 스키마의 변경,추가등의 작업을 수행합니다. 4. 인덱스 재생성, Chain row fix, vaccum 작업등 Database 성능을 향상 시킬 수 있는 작업들을 수행합니다. 5. Log data를 이전하거나, 관리작업을 수행합니다. 6. Game server관리자는 업데이트나 버그 픽스를 한 Game server로 교체작업을 하거나, Game server를 재가동 합니다. 7. 홈페이지 관리자는 그동안 준비했던 컨덴츠 업데이트나 여러가지 서비스중에 할 수 없었던 점검 작업을 합니다. 8. 일련의 모든 작업이 끝나면, 내부적으로 테스트를 수행합니다. 9. 테스트가 정상적으로 완료되면 정기정검을 완료합니다. 만약, 테스트에서 오류가 발생한다면, 시간이 충분하다면, 다시한번 문제점을 해결하기 위한 작업을 수행하고, 시간이 충분하지 않다면, 원상태로 되돌린뒤 정기정검을 완료합니다. 10. 점검시간이 종료되면 라우터에서 차단된 접속을 해제하고, 서비스를 재개합니다. |
여기서 가장 중요한 작업은 백업이라고 할 수 있습니다. 나머지 작업들은 매번 일어나는 작업이 아니라, 특별히 업데이트가 준비되어 있거나, 네트웍 망작업 혹은 문제가 발생했을 경우에 한해서 일어나는 작업입니다.
하지만, 서버의 Backup작업과, DB의 Full backup 그리고 DB의 성능을 높이기 위한 작업들은 매 정기점검마다 이루어 지는 작업들로, 관리작업의 핵심이라고 할 수 있습니다.
그럼, 왜 이런 백업 작업들과 Database 관리 작업이 중요한지에 대해 알아보겠습니다.
| 벡업의 종류 및 수행 절차 |
1. 온라인 백업과 오프라인 백업
백업은 크게 몇가지로 나뉘게 되는데, 수행 방식에 따라서 물리적 백업과 논리적 백업으로 나뉘고 논리적 백업은 다시 온라인 백업과 오프라인 백업으로 나뉘게 됩니다.
물리적 백업이란, 보통의 파일을 복사하듯이 데이터베이스의 핵심 파일들을 OS에서 제공하는 복사 명령어를 통하여 다른 저장매체로 복사하는 것을 뜻합니다. 언뜻 보면 가장 간단해 보이지만, 이 방식은 복구 하는데 필요한 시간이 길고, 저장 공간의 낭비가 심하기 때문에 권장하는 방식은 아니지만, 만약의 사태를 위해 실시하는 경우도 많습니다.
반면, 논리적 백업이란 DBMS에서 제공하는 백업용 프로그램(TOOL)을 사용하여 DBMS에 저장된 데이터를 백업하는 방식을 말합니다. 이때, 온라인 백업이란 DBMS를 정지시키지 않은 상태, 즉 DBMS가 가동중인 상태에서 백업을 수행하는 것을 말하고, 제품에 따라서는 온라인 풀백업을 지원하지 않는 경우도 있고, 지원한다고 하더라도, 백업 수행시점 이후의 변경점은 반영되지 않는 다는 단점이 있습니다.
오프라인 백업은 온라인 백업과 반대로 DBMS의 가동을 중지 시킨 상태에서 수행하는 백업을 말합니다. 대게 정지정검 시간에는 오프라인 풀 백업을 수행하는 것이 일반적이고, 가장 믿을 수 있는 백업본을 만들어 냅니다.
2. 논리적 백업의 단계
보통 DBMS는 전체백업(풀백업 - Full Backup)과 증분백업(Incremental Backup)의 단계를 제공합니다. 풀백업은 말 그대로 DBMS에 저장된 모든 데이터를 기준으로 백업을 수행하는 것을 의미합니다. 증분백업은, 최종적으로 백업이 수행되었던 시점 이후로 CRUD 연산에 의해 변경된 데이터만을 대상으로 백업을 수행하는 것을 말합니다. 경우에 따라 증분 백업은 1차 2차등의 단계를 나누어서 수행 할 수 있는 DBMS도 있습니다.(큐브리드도 이중 한가지 입니다.)
증분백업의 특성상, 최소한 한번 이상의 풀백업을 수행한 이후부터 가능하고, 2차 증분 백업의 경우 1차 증분 백업이 수행된 이후에 가능합니다.
보통, 데이터량에 따라 차이가 있겠지만, 풀백업은 시간이 많이 걸리고, DBMS에 부하가 걸리는 작업이라 매일 수행하기가 무척이나 힘든 작업입니다. 그래서, 일반적으로 DB를 관리하는 사람들은 다음과 같은 방법으로 풀백업과 증분백업을 주기적으로 수행하는 하도록 자동화하는것을 선호합니다.
* 한달에 한번 풀백업->일주일에 한번 1차증분백업->매일 2차증분 백업
* 일주일에 한번 풀백업->매일 증분백업
이런식으로 준비를 하게 되면, 시간이 오래 걸리는 풀백업 작업은 정기점검 시간을 통해 소화해 내고, 매일 매일 시간과 부하가 적은 증분 백업으로 변동분 만큼의 백업 데이터를 가지고 있게 되면, 유사시에 최대한 효율적으로 복구를 할 수 있게 됩니다.
(삽화: onesound)
| 복구의 한계 |
보통, DBMS는 데이터베이스에 기록하기 전에 해당 연산의 로그부터 작성을 하고, 로그가 정상적으로 기록되어야지만, 실제로 데이터에 반영합니다.
정확하게 말하자면, DBMS에 따라 기록방식에는 차이가 있지만, 로그 기능을 담당하는 부분과 데이터 기록을 담당하는 부분이 분리되어 독립적으로 존재하고, 적어도 데이터 기록을 담당하는 부분은 로그를 보고 데이터를 기록 한다는 것은 대체적으로 비슷하고 볼 수 있습니다.
이런 로그기록을 수행하기 위해 DBMS는 로그 버퍼라는것을 유지하게 되는데, 그 크기가 제한적으로 정해져 있다보니, 많은 데이터베이스 연산이 일어나는 경우 금새 이 로그 버퍼는 꽉 차버리게 됩니다.
그럴경우 DBMS는 꽉찬 해당 로그를 다름이름으로 전환하고(이렇게 생성되는 로그들을 아카이브로그라고 부릅니다) 로그버퍼를 비우게 되는데, 만약, DBMS가 아카이브로그를 지원하지 않는다면, 꽉 찬 로그는 버려지게 됩니다.
대체적으로, DBMS서버가 일시적으로 죽는 현상이 발생하였다고 하여도, DBMS에 저장된 데이터는 비교적 별도의 복구 절차 없이도 안전하게 복구가 됩니다. 하지만, 사고는 항상 예고 없이 닥치는 법이고, 갑작스런 서버 다운으로 데이터베이스 이미지에 손상이 가서 정상적으로 복구가 되지 않는 상황이 발생하면 이때 부터는, 얼마만큼 백업을 잘 수행해 왔는가와, DBMS가 얼마만큼 복구를 잘 지원하는지에 따라 관리자의 희비가 교차하게 됩니다.
장애의 원인 파악 부분도 중요하지만, 실 서비스가 이루어지고 있는 게임이라면 서비스 복구가 우선일 것입니다. 따라서, 원인 분석을 위한 로그 확보 및 파악은 별도의 팀이 수행하도록 하고, 복구 전담을 위한 인력은 최단 시간내에 가장 손실없는 데이터를 살려내야만 합니다.
다행스럽게도, 풀백업한 데이터가 있고, 오늘 새벽 4시에 수행한 증분 백업분이 있다면, 최대한 오늘 새벽 4시까지의 모든 데이터는 100% 복구 할 수 있습니다. 이 때 문제는, 새벽 4시 이후 부터 변경된 데이터에 대한 복구인데, 만약, 로그파일과 아카이브로그파일들이 건재하다면, 서버가 죽은 시점까지 반영된 모든 데이터는 100% 복구가 가능합니다.
하지만, 아카이브로그를 지원하지 않는 DBMS라면, 현재 있는 로그파일과 최종 증분백업을 받은 사이에 비는 데이터가 발생할 확률이 무척 높고, 이 부분은 사실상, 복구가 불가능합니다.
때에 따라선, 중간에 복구가 불가능한 부분으로 인해 현재 로그파일의 내용마저 버려야 할 경우도 생기며, 이땐 새벽4시 기준으로의 백섭은 불가피해 집니다. 데이터베이스의 최종 기록 시점이 새벽 4시이므로, 그 이후에 발생한 모든 상황에 대한 기록은 없어진게 되고, 결과적으로 새벽 4시 기준으로 백섭이 이루어지게 되는 것이죠.
반면, 아카이브로그를 지원하여 로그파일과 아카이브로그가 모두 건재하다고 해서 100% 백섭이 일어나지 않는다는 보장도 할 수는 없습니다.
이 부분은 게임서버 프로그램이 어떤 방식으로 데이터베이스에 데이터 조작 연산을 반영하는가에 따라 달라지겠지만, 일단, 게임서버 프로그램에서 DBMS로 보내지 않고 가지고 있던 만큼의 데이터는 복구가 불가능하고, 게임서버의 구성방식에 따라 최소 5초에서 최대 5분 정도의 백섭은 불가피한것이 현실입니다.
| 백섭의 원인 |
백섭의 원인은 앞서 복구의 한계에서 지적한 바와 같이 DBMS에 완전히 반영되지 못한 데이터 조작 연산이 남아 있는 채로 발생한 갑작스런 서버 다운과, 완벽하게 복구하지 못한 DBMS의 데이터에 의해 발생하게 됩니다.
완전히 복구하지 못하는 DBMS의 데이터에 대한 설명은 복구의 한계에서 자세히 설명하였으므로 생략하고, DBMS의 데이터를 완전히 복구하였음에도 불구하고 왜 5초에서 5분까지의 백섭이 일어날 수 밖에 없는지에 대한 조금 더 살펴보겠습니다.
일반적은 게임서버 프로그램은 실시간으로 모든 데이터 조작 연산을 DBMS로 보내지 않습니다. 이는, DBMS의 부하를 줄여 게임서버의 성능을 높이기 위한 방법으로 적당한 수의 데이터 조작 연산이 모이거나, 적당한 시간이 흐른 후에 DMBS에 반영하는 것이 일반적입니다.
예를 들어, 5ms이 경과될때 마다, 혹은 5ms가 경과되지 않았지만, 100건의 데이터 조작 연산 작업이 모였을 때 이를 한번에 처리하게 되는데, 이렇게 모아서 한번에 처리하는것을 '그룹커밋'이라고 부르고, 일반적으로 이런 그룹커밋은 그룹커밋을 사용하지 않을 때 보다 최대 5배정도의 성능 향상 효과를 볼 수 있습니다.
하지만, 문제는 이렇게 그룹커밋을 하기위해 데이터 조작 연산을 대기시키고 있는 사이에 서버가 다운된다면, 비록 대기 시간은 5ms에 불과 할지라도, 그 연산이 DBMS에서 실제 데이터로 반영되는 시간까지의 오차를 생각하면, 최소 5초정도의 데이터 누락은 생길 수 밖에 없고, 여기에서 프로그램의 갑작스런 중지가 아닌 서버 컴퓨터 자체의 갑작스런 다운이라면 DBMS의 처리중이었던 데이터(아직, 로그에도 기록되지 못한)까지도 손실될 수 밖에 없고, 이는 최종적으로 복구 가능한 데이터의 범위를 축소하게 됨으로 백섭의 범위는 넓어질 수 밖에 없습니다.
하지만, 백섭을 없애기 위해 실시간 데이터베이스 반영을 한다고 하면, 현저하게 저하된 서버 성능으로 원할한 게임을 방해하는 각종 렉을 유발하게 되므로 게이머들은 더 큰 불편을 겪을 수도 있고, 최대 접속 제한 인원이 낮아져서 온라인 게임의 재미를 떨어지게 할 수도 있기 때문에, 지금도, 서버 개발자들은 백섭을 최소화 하면서도 최대한의 성능향상을 할 수 있는 최선의 방법을 개발하기 위해 항상 노력을 하고 있습니다.
이상으로, 정기점검과 백섭이라는 내용으로, 데이터베이스 백업의 중요성과, 복구의 한계, 백섭의 원인등에 대해 알아보았습니다. 연재를 진행하면 할 수록 부족한 능력을 뼈저리게 통감하고 있습니다. 앞으로 남은 연재는 더더욱 알찬 내용으로 찾아 뵐 수 있도록 더 열심히 하겠습니다.
다음에는 온라인게임DB 관리의 중요성과 보안이라는 이슈로 찾아 뵙도록 하겠습니다.