19P by safethecode 4달전 | favorite | 댓글 3개
  • GitHub은 1200개 이상의 MySQL 호스트를 MySQL 8.0으로 업그레이드하는 작업을 진행했고, 이 진행 과정에서 업그레이드 진행 사유로는 MySQL 5.7의 수명이 다하고 최신 보안 패치와 새로운 기능을 활용하기 위해 이루어졌으며, 총 1년 이상의 과정을 거쳤습니다. 다양하고 복잡한 MySQL 인프라를 업그레이드하면서 발생한 기술적 도전과 배운 점은 자동화와 플릿 관리의 중요성을 강조하고 있습니다.

  • GitHub은 15년 전에 Ruby on Rails 애플리케이션과 단일 MySQL 데이터베이스로 시작되었습니다. 그 이후로 GitHub은 플랫폼의 스케일링 및 내구성 요구를 충족시키기 위해 MySQL 아키텍처를 개선해 왔습니다. 그리고 이번에는 1200개 이상의 MySQL 호스트를 MySQL 8.0으로 업그레이드하는 작업을 수행했습니다.

  • 업그레이드 동기는 MySQL 5.7이 수명이 다해가면서, 최신 보안 패치, 버그 수정 및 성능 향상을 얻기 위해 MySQL 8.0으로 업그레이드하고자 했습니다. 또한 8.0에는 Instant DDLs, invisible indexes, compressed bin logs 등의 새로운 기능이 포함되어 있습니다.

  • GitHub의 MySQL 인프라는 1200개 이상의 호스트로 이루어진 다양하고 복잡한 배포로 구성되어 있습니다. 이를 유지하면서 업그레이드를 수행하기 위해 GitHub은 세심한 계획, 테스트 자동화, 그리고 다양한 팀 간의 협업이 필요했습니다.

  • 업그레이드를 준비하는 단계에서는 인프라를 업그레이드하고, 애플리케이션 호환성을 확인하며, 커뮤니케이션과 투명성을 유지하고, 천천히 진행되는 업그레이드 전략을 수립하는 등의 작업을 수행했습니다. 업그레이드는 여러 단계로 진행되었고, 중요한 측면은 롤백 가능성을 유지하면서 업그레이드를 진행하는 것이었습니다.

  • 업그레이드 도중에는 MySQL 8.0에서 MySQL 5.7로의 롤백이 어려운 문제가 있었지만, GitHub은 롤백 기능을 유지하면서 업그레이드를 안전하게 수행했습니다. Vitess와 같은 다양한 기술적 도전에 부딪히기도 했지만, 이러한 문제들을 극복하며 전체 업그레이드 과정은 1년 이상 소요되었습니다.

  • 이 프로젝트를 통해 얻은 경험과 교훈은 GitHub에게 MySQL 업그레이드가 중요한 루틴 유지보수 중 하나임을 강조하며, 자동화와 안정적인 플릿 관리 툴 개발이 향후 업그레이드를 더 효율적으로 수행할 수 있게 할 것이라는 결론을 도출했습니다.

MS는 인수한 회사에서 자사 기술 stack으로 migration을 하는걸 굳이 강요안하는것 같습니다... 아직도 RoR / mysql이군요

깃헙 db 마이그리이션.. 상상만 해도 끔찍하네요

손되면 답 없는 거 알기에 가만있던거 아닐까요? ㅎ