안녕하세요. 이전 게시물에서 언급했듯이, 저는 기존 사이트를 내리고 약 200만 개의 게시물이 포함된 프로덕션 데이터를 이전하기 전에 모든 해결책을 갖추기 위해 Drupal → Discourse 마이그레이션 테스트를 진행 중입니다. 지금까지 배운 점은, 3개의 vCPU 코어를 가진 상당히 빠른 VPS에서도 가져오기(import) 과정이 거의 48시간 정도나 걸린다는 것입니다. 그리고 나서 아마도 rake 태스크와/또는 rails c를 사용하여 몇 가지 정리를 해야 할 것이며, rake posts:rebake가 필요한 작업의 경우 추가로 약 20시간이 더 소요될 것으로 보입니다.
저는 Ruby 도구 체인(toolchain)의 기본 원리를 잘 이해하지 못합니다. 하지만 이 작업에 더 많은 CPU 코어를 투입하면 이러한 프로세스 중 하나라도 완료되는 데 걸리는 시간을 크게 줄일 수 있을까요? 예를 들어 bundle 명령어나 rake 명령어가 사용 가능한 CPU 사이에 작업을 분배할 수 있는가, 아니면 추가 코어가 주로 여러 사용자가 웹사이트에 동시 접속할 때 여러 프로세스를 병렬로 실행하는 데에만 유용한 것인가?
@Canapin 사실 그걸 언급해 주셔서 정말 감사합니다. 어떻게 하셨는지 정말 궁금합니다. 저도 같은 일을 해보고 싶었는데, 부분 가져오기를 하면 데이터베이스 불일치 문제가 생길 것 같아서 그 생각을 포기했거든요. 그래서 테스트용으로 스켈레톤 Drupal 테스트 포럼을 만들어서 진행했습니다. 하지만 가능하면 프로덕션 DB의 복사본을 테스트에 사용하고 싶습니다.
주된 우려는 결국 최종 프로덕션 마이그레이션에 관한 것입니다. 기존 포럼을 오프라인으로 두거나 최소한 읽기 전용으로 만들어야 하는데, 아무리 빨라도 최소 48시간의 다운타임이 필요해 보입니다. CPU 코어를 두 배로 늘리면 시간이 절반으로 줄어든다고 볼 수 있을까요?
복구에 오랜 시간이 소요되는 작업들은 실제로 멀티스레드로 처리됩니다. 다만, CPU를 2배로 늘린다고 해서 성능이 2배로 향상되는 경우는 거의 없습니다.
또 다른 점은, rake posts:rebake 작업과 포럼 자체의 콘텐츠 복구 및 최적화라는 무거운 작업은 포럼이 라이브 상태일 때에도 수행될 수 있다는 것입니다. 이렇게 하면 포럼을 오프라인 또는 읽기 전용으로 두어야 하는 시간을 줄이고, 다소 열화된 경험을 제공하면서도 운영을 유지할 수 있습니다.
제 추천은 다음과 같습니다. 먼저 테스트를 해보세요. 마이그레이션을 수행하고, 소요되는 시간과 모든 리베이크(rebake)가 적용되지 않은 상태에서 포럼이 어떻게 보이는지 확인해 보세요. 만약 그 상태가 충분히 괜찮다면, 마이그레이션이 포럼의 트래픽이 낮은 시간대에 끝나도록 조정하면, 많은 사용자의 불만 없이 4~10시간 정도의 마이그레이션 시간을 확보할 수 있습니다.
불행히도 그걸 적어두지 않았고 잊어버렸어요… 하지만 코딩을 아신다면 그다지 어렵지 않을 거예요. BATCH_SIZE와 offset 값을 조정해서 루프를 변경하고, 게시글 배치(batch)를 건너뛰게 하거나 그런 식으로 했을 수도 있어요…
지금 바로 다시 시도할 수는 없어요. 현재 가져오기(import)할 포럼이 없어서요. 하지만 꽤 유용하다고 생각하니까 다음에는 간단한 튜토리얼을 만들어볼게요.
흥미롭네요. 이전에는 이런 권장 사항을 본 적이 없습니다. 이게 조각(fragmentation)을 줄이거나 그런 효과가 있는 건가요?
네, 처음에는 Postgres 콘솔에서 regexp_replace()를 사용하여 일부 [QUOTE] 문제와 Textile → Markdown 변환을 수정하고 모든 게시물을 다시 베이킹하려 했습니다. rake posts:remap 명령이 너무 느렸기 때문입니다. 하지만 Postgres가 사용하는 정규식 형식이 PCRE와 호환되지 않으며, 의도치 않은 이상 현상이 너무 많아 이를 신뢰하기 어렵다는 것을 발견했습니다. 그래서 수입 과정에서 Pandoc을 통해 게시물을 처리해 보려 합니다. 이렇게 하면 수입된 사이트를 보기 좋은 상태로 실행에 올려 놓고, 이모지 키워드 같은 작은 문제는 rake posts:remap으로 나중에 수정할 수 있을 것입니다.
혹시 가장 빠르게 가져오기(import) 스크립트를 다시 실행하여 데이터를 다시 가져오는 방법에 대한 팁을 공유해 주실 수 있나요? 가져오기 스크립트에서 텍스트 치환을 조정하고 있는데, 제대로 되지 않을 때마다 Discourse 데이터베이스를 삭제하고 ./launcher rebuild import를 실행해야 해서 꽤 시간이 걸립니다. 가져오기 스크립트를 수정한 후 처음부터 다시 시작하게 하고 싶습니다. (현재 사이트의 작은 골격 목업 데이터베이스를 사용 중이라 가져오기를 실행하는 데는 매우 빠릅니다.)
음. 이번에는 8개의 가상 코어와 16GB의 RAM을 갖춘 상당히 강력한 VPS에서 프로덕션 포럼 데이터를 다시 가져오는 것을 테스트하고 있습니다. 다음과 같이 설정했습니다: UNICORN_SIDEKIQS=4 DISCOURSE_SIDEKIQ_WORKERS=20 UNICORN_WORKERS=16
두 개의 가이드[1]와[2]를 조합하여, 소스 포럼 데이터베이스의 MySQL 사본을 실행하는 다른 Docker 컨테이너에 접근하여 가져오기를 수행했습니다. 하지만 별도의 import 컨테이너를 만들지 않고, 단일 app 컨테이너를 사용하고 mysql-dep.tempate를 추가하면 된다는 것을 깨달았습니다:
이렇게 하면 가져오기 스크립트가 실행되는 동안에도 작동하는 Discourse 인스턴스를 유지할 수 있습니다. 모든 사용자와 카테고리가 가져와진 직후에 포럼을 공개하고, 완전한 데이터 입력까지 며칠이 걸릴 것이라는 배너를 통해 사용자에게 알려주는 방식에는 어떤 단점이 있을까요? 적어도 모든 주제와 게시글은 가져왔지만 개인 메시지는 아직 가져오기 전 단계에서 공개할 수 있을 것 같다는 생각이 듭니다. 개인 메시지만 가져오는 데도 상당한 24시간이 소요될 테니까요.
