날아갈 시간… 렌더링

아래에 설명된 Gartner의 과대광고 주기는 대부분의 기술 측면에 적용될 수 있습니다.

새로운 혁신이 해당 주기에 진입하면 결국 기대가 실현되어 일정 수준의 채택이 이루어집니다.

모든 혁신의 목표는 소비자가 혁신 채택에 따른 보상이 알려진 위험보다 훨씬 크다고 판단하는 생산성 수준에 도달하는 것입니다.

동시에, 생산성의 정체가 줄어들기 시작하여 혁신에서 벗어나게 되는 지점이 있습니다. 한 가지 간단한 예로는 휴대폰/장치가 생산성의 정점에 도달하기 전에 일반적이었던 호출기 (또는 호출기)를 들 수 있습니다.

기술자로서 우리는 생산성 수준을 높이는 기능, 프레임워크, 제품 또는 서비스를 제공하기 위해 노력합니다. 우리가 사용하는 제품도 마찬가지입니다.

최근에 저는 현재 호스팅 플랫폼이 생산성 수준에서 벗어나기 시작한 것 같은 느낌이 들었습니다. 사실 최근 발표를 통해 이제 다른 옵션을 고려해야 할 때가 되었는지 궁금해졌습니다.

Render PaaS를 사용하여 긍정적인 경험을 했기 때문에 Heroku 애플리케이션 중 하나를 얼마나 쉽게 변환하고, PostgreSQL을 채택하고, Render로 마이그레이션할 수 있는지 살펴보고 싶었습니다. 나는 이 두 부분으로 구성된 시리즈에서 그 여정을 설명하고 있습니다.

• 1부: 백엔드 서비스(Spring Boot 및 ClearDB MySQL) 마이그레이션에 중점을 둘 것입니다.
• 2부: 프런트엔드 Angular 클라이언트를 포팅하고 마이그레이션하는 데 중점을 둘 것입니다.

내가 렌더를 선택한 이유

이전에 Render에 대해 들어본 적이 없다면 제가 이전에 출판한 내용을 확인해 보세요.

• Render PaaS로 DevOps에 시간을 투자하지 마세요

• 완벽한 클라우드: AWS, GCP, Azure 올인원

• 목적 중심의 마이크로서비스 설계

• 하루 만에 스타트업 아이디어 실행

• 렌더를 사용하여 마이크로서비스 앱을 쉽게 확장하는 방법

제가 Render에 대해 흥미를 느끼는 점은 그들이 생산성의 정체를 인식하고 있는 채택자들에게 견고한 솔루션을 적극적으로 제공하면서 깨달음의 경사면을 계속해서 오르고 있다는 것입니다.

내 기사에서 언급했듯이 Render는 "Zero DevOps" 약속을 제공합니다. DevOps 작업에 집중할 시간이 없기 때문에 이는 내 요구 사항과 완벽하게 일치합니다.

Heroku 플랫폼에는 내가 그다지 좋아하지 않는 몇 가지 사항이 있습니다.

• 매일 다시 시작하면 내 서비스 중 하나가 예기치 않게 중단되었습니다.

• Heroku의 보급형(저에게 꼭 필요한 것) Postgres는 한 달에 4시간의 가동 중지 시간을 허용합니다.

• 소비자 관점에서 볼 때 가격 수준은 잘 확장되지 않습니다.

가격 측면에서 모든 애플리케이션과 서비스를 Heroku에서 Render로 마이그레이션한 후 상당한 비용 절감을 기대할 수 있습니다. 더 놀라운 점은 애플리케이션 설치 공간이 증가함에 따라 선형 확장을 통해 해당 가격에 더 나은 메모리와 CPU를 얻을 수 있다는 것입니다.

단일 서비스 변환

위에서 언급한 것처럼 이 기사는 2부로 구성된 시리즈 중 1부이며 이 기사에서는 서비스 계층에 중점을 두겠습니다. 변환하려는 서비스에는 다음과 같은 속성이 있습니다.

• 스프링 부트 RESTful API 서비스

• Heroku CloudAMQP(RabbitMQ) 메시지 브로커

• Heroku ClearDB(MySQL) 데이터베이스(단일 스키마)

• 옥타 통합

Render PaaS 측면에서 새로운 서비스 디자인은 다음과 같습니다.

• Spring Boot RESTful API 서비스를 호스팅하는 렌더링 웹 서비스(Docker를 통해)

• RabbitMQ 메시지 브로커를 호스팅하는 렌더 프라이빗 서비스(Docker를 통해)

• 여러 스키마가 존재할 수 있는 기능으로 Postgres 렌더링

• 옥타 통합

다음은 두 생태계를 나란히 비교한 것입니다.

전환을 위한 나의 높은 수준의 공격 계획은 다음과 같습니다.

변환을 위해 Heroku 준비

시작하기 전에 기존의 모든 Heroku 서비스를 유지 관리 모드 로 전환하는 것이 좋습니다. 이렇게 하면 소비자가 애플리케이션이나 서비스에 액세스하는 것이 금지됩니다.

소스 코드는 이미 백업되어 Git 기반 저장소에 저장되어 있지만 데이터베이스 백업이 성공적으로 생성되었는지 확인하는 것이 좋습니다.

Heroku 서비스 전환

변환 관점에서 변환할 항목은 서비스 자체와 ClearDB(MySQL) 데이터베이스 두 가지였습니다.

Spring Boot RESTful 서비스의 변환에는 많은 작업이 필요하지 않았습니다. 실제로 이전 프로젝트 에서 사용한 접근 방식을 활용할 수 있었습니다.

데이터베이스의 경우 MySQL에서 PostgreSQL로 변환해야 했습니다. 내 목표는 Render의 Heroku Migrator를 사용하여 Heroku Postgres를 Render Postgres로 쉽게 마이그레이션하는 것이었지만 먼저 MySQL에서 PostgreSQL로 변환해야 했습니다.

처음에는 데이터베이스 변환을 위한 일반적인 접근 방식인 것처럼 보이는 pgloader 경로를 시작했습니다. 하지만 M1 칩 MacBook Pro를 사용하면서 예상치 못한 문제가 발생했습니다.

대신, 저는 NMIG를 사용하여 MySQL을 PostgreSQL로 변환하기로 결정했습니다. 자세한 내용은 아래 " 데이터베이스 변환의 주요 내용 " 섹션을 확인하세요.

렌더에서 서비스 생성

데이터베이스와 Docker 내에서 실행되는 Spring Boot RESTful 서비스를 변환한 후 다음 단계는 Spring Boot RESTful API 서비스를 위한 렌더 웹 서비스를 만드는 것이었습니다.

서비스를 생성하고, 이름을 지정하고, GitLab에서 내 코드에 적합한 저장소를 가리키는 것만큼 쉬웠습니다.

RabbitMQ 서비스도 필요했기 때문에 다음 지침에 따라 Render에서 실행되는 RabbitMQ Private Service를 만들었습니다. 여기에는 처리되지 않은 메시지를 유지하기 위해 소량의 디스크 저장소를 설정하는 것이 포함되었습니다.

마지막으로, Spring Boot RESTful API 서비스와 RabbitMQ 메시지 브로커 모두에 대해 Render Dashboard에서 필요한 환경 변수를 생성했습니다.

서비스 초기화 및 유효성 검사

다음 단계는 서비스를 시작하는 것이었습니다. API가 실행되고 내 Postman 컬렉션을 사용하여 API가 검증된 후 새 렌더 서비스 위치를 가리키도록 클라이언트 애플리케이션을 업데이트했습니다.

모든 것이 실행되고 나면 아래와 같이 Render Dashboard가 나타납니다.

다음 단계

이 시점에서 남은 것은 아직 Heroku에서 실행 중인 데이터베이스를 삭제하고 Heroku 생태계에서 마이그레이션된 서비스를 제거하는 것뿐이었습니다.

Heroku를 사용할 때 코드를 서비스 저장소의 마스터 브랜치에 병합할 때마다 GitLab CI/CD를 사용하여 소스 저장소의 Heroku에 배포한 경우 코드가 자동으로 배포되었습니다.

그러나 Render를 사용하여 소스 파일 저장소에 코드를 추가할 필요는 없습니다. 서비스에 대한 렌더 대시보드에서 Build & Deploy Branch를 지정하기만 하면 되었습니다.

저는 Zero DevOps 약속을 좋아합니다.

데이터베이스 변환의 주요 내용

위의 단계를 따르면 Heroku에서 Render로의 변환이 원활하고 성공적이었습니다. 저에게 가장 큰 과제는 데이터 변환이었습니다. 높은 수준에서 이것은 대부분 내 MacBook Pro 터미널에서 실행되는 일련의 명령으로 요약됩니다.

먼저 Docker를 통해 로컬 Postgres 인스턴스를 시작했습니다.

 docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres

다음으로 다음 명령(또는 pgAdmin)을 사용하여 "example"이라는 데이터베이스를 만들었습니다.

 createdb example

Heroku에서 실행되는 ClearDB(MYSQL) 인스턴스를 로컬에서 실행되는 Postgres 데이터베이스 예제로 변환하기 위해 Node.js 기반 데이터베이스 변환 유틸리티인 NMIG를 사용했습니다.

NMIG를 설치한 후 데이터베이스 엔드포인트 정보와 자격 증명으로 config.json 파일을 설정하고 다음을 실행했습니다.

 /path/to/nmig$ npm start

다음으로 다음 명령을 사용하여 데이터를 파일에 백업했습니다.

 pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump

AWS에서 서명된 URL을 생성하는 번거로움을 겪는 대신 pgAdmin 클라이언트를 사용하여 Heroku에서 새로 생성된 Postgres 인스턴스로 백업을 가져왔습니다.

Postgres 인스턴스가 실행되고 데이터가 검증된 후 Render PaaS에 새로운 Postgres 데이터베이스를 생성했습니다 . 그런 다음 내가 해야 할 일은 다음 명령을 실행하는 것뿐이었습니다.

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/example example.dump

그 과정에서 얻은 교훈

Heroku에서 Render로 전환하면서 배운 몇 가지 교훈은 다음과 같습니다.

• DST 오프셋을 포함하도록 날짜/시간 값을 업데이트하는 Postgres 데이터베이스에 사소한 문제가 있었습니다. 이는 내 원래 데이터베이스 디자인에 문제가 있었을 수도 있지만 이 문제를 전달하고 싶었습니다. 제 경우에는 영향을 받은 열이 날짜 값에만 사용되었으며 이는 변경되지 않았습니다.

• 내 테이블 중 하나에 END라는 데이터베이스 열을 포함했는데, 이로 인해 Postgres나 Hibernate가 기본 쿼리를 반환하려고 시도할 때 문제가 발생했습니다. 서비스는 END 컬럼 이름을 보고 이를 SQL 키워드로 삽입했습니다. 이 문제를 해결하기 위해 단순히 열 이름을 바꾸었는데, 처음부터 그렇게 하지 말아야 했습니다.

• Render를 사용하면 웹 서비스 옵션이 예상 포트를 노출하지 않기 때문에 RabbitMQ 서비스를 개인 서비스로 만들어야 했습니다. 그러나 이 접근 방식을 사용하면 Private Services가 외부에 노출되지 않기 때문에 RabbitMQ 관리 인터페이스에 액세스할 수 없습니다. 렌더는 이 기능 요청을 처리할 계획인 것 같습니다.

전체적으로 이러한 사소한 장애물은 Render로 마이그레이션하려는 결정에 영향을 미칠 만큼 중요하지 않았습니다.

결론

Gartner의 생산성 고원에서 가장 중요한 측면은 소비자가 성공하고 목표를 달성할 수 있도록 지원하는 제품, 프레임워크 또는 서비스를 제공하는 것입니다. 생산성의 정체는 은유적인 의미에서 화려하거나 패셔너블해지려는 것이 아닙니다.

제가 이 결론을 Render의 Developer Advocate인 Ed와 공유했을 때 그의 반응은 제가 공유하고 싶었던 것이었습니다:

“렌더는 확실히 '유행'하려고 노력하지 않습니다. 우리는 놀랍지 않고 신뢰할 수 있는 사람이 되려고 노력하고 있습니다.”

Ed의 반응은 나에게 깊은 울림을 주었고 이전 동료가 내 코드가 그에게 "지루하다"고 말했던 때를 생각나게 했습니다. 그의 말은 내가 받을 수 있는 최고의 칭찬이었음이 드러났다. 여기에서 자세한 내용을 읽을 수 있습니다.

기술의 모든 측면에서 선택할 공급자에 대한 결정은 항상 기술 위치와 일치해야 합니다. 확실하지 않은 경우 Gartner의 과대광고 주기가 훌륭한 참고점이 되며 여기에서 해당 서비스 구독을 시작할 수 있습니다.

저는 모든 IT 전문가에게 적용될 수 있다고 생각하는 다음 사명 선언문에 중점을 두었습니다.

“지적 재산의 가치를 확장하는 특징/기능을 제공하는 데 시간을 집중하십시오. 다른 모든 것에 프레임워크, 제품, 서비스를 활용하세요.”

- J. 베스터

Render PaaS 생태계를 살펴보면 내 사명 선언문을 준수하는 동시에 내 과대 광고 주기 선호 사항 내에 있는 솔루션을 볼 수 있습니다.

상황을 더 좋게 만드는 것은 서비스가 수직적으로 확장되어야 하기 때문에 개인 본인부담 비용이 44% 절감될 것으로 기대한다는 것입니다.

호스팅 솔루션을 고려 중인 경우 검토 및 분석을 위해 공급자 목록에 Render를 추가하는 것이 좋습니다. 이 링크를 따라가면 무료로 시작할 수 있습니다.

이 시리즈의 두 번째 부분은 흥미로울 것입니다. Angular로 작성된 정적 클라이언트 비용을 지불하지 않고 Vue 또는 Svelte를 사용하여 Render의 무료 정적 사이트 서비스를 활용하는 방법을 보여 드리겠습니다. 어떤 프레임워크를 선택해야 할까요? 그리고 그 이유는 무엇입니까?

정말 좋은 하루 보내세요!