Ruby 2.7로 업그레이드된 GitHub!

 

GitHub가 Ruby2.7로 한층 더 업그레이드되었습니다!

Ruby 2.7은 키워드 인수의 작동 방식을 사용하지 않는 매우 독특한 업그레이드로, 이번 버전부터 Ruby는
메소드가 키워드 인수를 예상할 때 옵션 해시 전달을 허용하지 않습니다.

 

GitHub는 애플리케이션의 발전을 위해 주요 변경 사항을 확인하는 등 향후 업데이트에 뒤처지지 않고

Ruby와 Rails 모두를 지원 중단 없이 실행하기 위해 최선을 다하고 있습니다.

 

그럼 Ruby 2.7로 한층 더 업그레이드된 GitHub에 대해 자세히 알아볼까요?

---

업데이트 전략

전략 하나: 보다 편리한 작업

이번 업데이트는 과거 Rails를 업그레이드한 것처럼, 환경 변수를 사용하여 Ruby2.6과 Ruby 2.7를
듀얼 부팅이 되도록 GitHub 애플리케이션을 설정했습니다.  

이 작업으로 아래와 같은 작업들이 편리해졌습니다.

 

1. 이번 버전과 호환성을 위한 변경이 쉬워졌습니다.

2. 업그레이드를 위한 기존 브랜치를 유지할 필요가 없습니다.

3. 엔지니어팀이 새로운 버전의 Ruby를 실행하기 위해 변경해야 하는 운영하던 시스템을 쉽게 변경할 수 있습니다.

4. 400,000라인 이상의 애플리케이션 크기와 매일 100개의 PR로 업그레이드 프로세스가 대폭 간소화되었습니다.

  

 

전략 둘: Monkey patch를 사용한 Warning 수정 요청

이전에는 warning 수정 지원을 요청할 준비가 되지 않아 빌드를 실행한 후 Ruby Warning은 단순한 텍스트 출력의 문자열이기 때문에 수정해야 할 목록을 캡처해야 했습니다. 그래서 GitHub는 Ruby에 warning 모듈을 수용하기 위해 monkey patch를 사용했습니다.

 

 

아래는 monkey patch를 단순화한 버전입니다.

 

 

이 패치는 폐기된 warning과 WarningCollector에 warning을 발생시키는 테스트 경로를 저장합니다.

 

 

 

 

 

warningCollector#process 매서드는 warning.txt라 불리는 파일에 경고들을 저장합니다.

그리고 CODEOWNERS를 사용하여 경고들을 분석하고 각 팀이 사용하는 파일로 변환해 줍니다.

 

모든 경고를 처리하고 나면 새로운 Ruby 버전에서 애플리케이션을 부팅하기 위한 쉬운 가이드와 함께 이슈를
오픈합니다. GitHub의 경고 레포트는 아래와 같이 경고를 내는 파일, 경고 자체 그리고 경고를 트리거한 것들을
포함하고 있습니다.

 

 

 

 

 

이 작업은 팀 간에 중복 업무를 피하고 각 경고의 소유권한과 상태를 간단하게 결정할 수 있게 해 줍니다.

 

 

전략 3: 경고(warning) 수 추적

마지막 전략으로는 경고(warning) 수를 추적하는 것입니다. GitHub는 Ruby 2.7 CI 빌드의 경고 수를 추적해
새로운 코드가 또 다른 새로운 경고를 만들었는지 확인했습니다.

 

그리고 40여 개의 팀과 몇 달간의 협업으로 30개 이상의 gem이 업그레이드되었고 11K warning은 더 이상
CI 빌드에서 발견되지 않았습니다. 유지되지 않는 gem은 유지되고 있는 gem으로 대체되었습니다.

 

또한 Warning을 수정한 후 Ruby 2.7에서 오류를 일으키는 monkey 패치를 변경해 GitHub 코드 베이스로 가는
새 코드에 warning이 발생하지 않도록 했습니다.

 

 

2.7 업그레이드의 장점

왜 이렇게 복잡한 작업을 하고 많은 투자를 하며 Ruby를 업그레이드해야 할까요?

Ruby를 사용하시는 분들이라면 알고 있겠지만 Ruby를 업그레이드하는 것은 어려운 작업입니다.
하지만 얼마나 어려운 작업이든 이 업그레이드로 Ruby의 성능이 매우 향상되었습니다.

그럼 Ruby 2.7 업그레이드의 장점을 알아볼까요??

 

 

장점 하나: 줄어든 부팅시간

애플리케이션이 운영 모드에서 부팅하는데 걸리는 시간이 현저하게 줄었습니다.

아래 그래프에서 알 수 있듯이 전체 애플리케이션이 eager load 될 때 걸리는 평균 부팅시간은 90초였지만
70초까지 줄어들었습니다.

 

 

 

 

부팅시간이 빠르면 빠를수록 기능, 버그 수정 및 성능 향상도 빨리할 수 있습니다.

 

 

장점 둘: 감소된 오브젝트 할당(object allocations)

오브젝트 할당(object allocations)도 780k에서 668K로 감소했습니다.
오브젝트 할당(object allocations)은 사용 가능한 메모리에 영향을 미치기 때문에 낮은 수치가 중요합니다.

 

 

 

 

 

장점 셋: 애플리케이션 관리의 용이

가장 최근 버전의 언어 및 프레임워크를 유지하는 것은 애플리케이션을 관리하는 데 큰 도움이 됩니다. 이번 업데이트로 더 이상 애플리케이션에서 사용하지 않거나 소유자를 알 수 없는 수많은 코드를 발견해 제거했습니다.

 

또한 애플리케이션에 유지되지 않는 gem도 제거하거나 교체했습니다. 유지된 gem의 경우 Rails, rails-controller-testing, capybara, factory_bot, view_component, posix-spawn, github-ds, ruby-kafka를 포함하여 애플리케이션에서 경고를 표시하는 모든 gem에 대한 패치를 보내 커뮤니티에 반환했습니다.

 

안전한 업그레이드 배포

주요 업그레이드를 배포하는 것은 위험성을 수반합니다.

 

하지만 Ruby와 Rails의 경우 모든 테스트가 통과되고 코드가 안정될 때까지 dual-build를 실행해 위험을 대폭 줄일 수 있는 프로세스를 설계했습니다. 또한 새로운 버전이 문제가 없는지 확인하기 위해 주요 제품을 작업하는 팀에게 스테이징 환경에서 코드베이스 영역을 테스트하도록 했습니다.

 

새로운 업그레이드 제품을 배포하는 것은 매우 큰 작업이기 때문에 새로운 버전의 트래픽 비율도 높이고 Sentry와 Datadog에서 모니터링을 하는 등 신중에 신중을 기합니다. 이번 배포에서 GitHub는 트래픽을 2%까지 롤아웃했고 새로운 고정 문자열 예외를 빠르게 확인했습니다.  그리고 쿠버네티스의 partition에 순차적으로 배포하여 총 2시간의 시간을 투입해 업그레이드를 병합해 배포하였습니다.

 

GitHub는 Ruby와 Rails 업그레이드를 배포하기 위한 과정을 구축하고자 많은 투자를 했고 가장 위험성이 낮은 배포 방법으로 배포했습니다. Ruby를 배포하는 동안 다운타임은 없었고 사용자에게 미치는 영향도 제로였습니다.

 

---

 

Ruby 업그레이드가 뒤처지면 코드베이스의 안정성에 부정적인 영향을 미치기 때문에 GitHub는 항상 최신 버전의 Ruby로 작업할 수 있게 최선을 다하고 있습니다.

 

Ruby 2.7, Ruby 3.0뿐만 아니라 그 이상 버전의 Ruby를 기대합니다!

긴 글 읽어 주셔서 감사합니다.