1,654 測定値

私が飛ぶ時間…レンダリングする時間

に John Vester8m2023/02/14

長すぎる; 読むには

Heroku は無料プランを廃止したため、プロトタイプの製品とサービスを Render に移行しています。 Render PaaS への変換がいかに簡単か見てみましょう。

以下に示すガートナーのハイプサイクルは、テクノロジーのほとんどの側面に適用できます。

新しいイノベーションがそれぞれのサイクルに入ると、最終的に期待が実現し、ある程度の採用につながります。

すべてのイノベーションの目標は、イノベーションを採用することの見返りが既知のリスクをはるかに上回ると消費者が判断する生産性の停滞期に到達することです。

同時に、生産性のプラトーが減少し始めるポイントがあり、そのイノベーションからの流出につながります。簡単な例の 1 つは、携帯電話/デバイスが生産性の停滞期に達する前に一般的だったポケットベル(またはブザー) です。

テクノロジストとして、私たちは生産性のプラトーを向上させる機能、フレームワーク、製品、またはサービスを提供するよう努めています。同じことが私たちが使用するものにも当てはまります。

最近、現在のホスティングプラットフォームの生産性が頭打ちになっているように感じました。実際、最近の発表で、他のオプションを検討する時期が来たのではないかと思いました。

私はRender PaaS を使用して良い経験をしたので、Heroku アプリケーションの 1 つを変換し、PostgreSQL を採用し、Render に移行することがいかに簡単かを調べたいと思いました。この 2 部構成のシリーズでは、その旅について説明しています。

パート 1: バックエンドサービス (Spring Boot と ClearDB MySQL) の移行に焦点を当てます。
パート 2: フロントエンドの Angular クライアントの移植と移行に焦点を当てます。

私がレンダリングを選んだ理由

Render について聞いたことがない場合は、私の以前の出版物のいくつかをチェックしてください。

Render PaaS で DevOps に費やす時間をゼロに

完璧なクラウド: AWS、GCP、Azure のオールインワン

目的主導のマイクロサービス設計

スタートアップのアイデアを 1 日で立ち上げましょう

Render を使用してマイクロサービスアプリを簡単にスケーリングする方法

Render について私がワクワクするのは、生産性の停滞を認識している採用者に確実なソリューションを積極的に提供しながら、Render が啓蒙の坂道を上り続けていることです。

記事で述べたように、Render は「ゼロ DevOps」を約束します。 DevOps タスクに集中する時間がないため、これは私のニーズに完全に一致します。

Heroku プラットフォームには、私があまり好きではない点がいくつかあります。

毎日の再起動により、サービスの 1 つで予期しないダウンタイムが発生しました。

エントリーレベル (私が本当に必要としているもの) の Postgres on Heroku では、1 か月あたり 4 時間のダウンタイムが許容されます。

消費者の観点から見た価格レベルは、うまくスケーリングできません。

価格の観点からは、すべてのアプリケーションとサービスを Heroku から Render に移行した後、大幅なコスト削減が期待できます。さらに驚くべきことは、その価格でより優れたメモリと CPU を入手できることです。アプリケーションのフットプリントの拡大に合わせて線形にスケーリングできます。

単一のサービスの変換

上で述べたように、これは 2 部構成のシリーズの第 1 部であり、この記事ではサービス層に焦点を当てます。変換したいサービスには次の属性があります。

Spring Boot RESTful API サービス

Heroku CloudAMQP (RabbitMQ) メッセージブローカー

Heroku ClearDB (MySQL) データベース (単一スキーマ)

Okta の統合

Render PaaS 側では、新しいサービス設計は次のようになります。

Spring Boot RESTful API サービスをホストする Web サービスをレンダリングする (Docker 経由)

RabbitMQ Message Broker をホストするプライベートサービスをレンダリングする (Docker 経由)

複数のスキーマが存在できるように Postgres をレンダリングする

Okta の統合

以下は、2 つのエコシステムを並べて比較したものです。

変換のための私の高レベルの攻撃計画は次のとおりです。

変換のための Heroku の準備

開始する前に、既存のすべての Heroku サービスをMaintenance Modeにすることをお勧めします。これにより、消費者はアプリケーションやサービスにアクセスできなくなります。

ソースコードは既にバックアップされ、git ベースのリポジトリに保存されている必要がありますが、データベースのバックアップが正常に作成されていることを確認することをお勧めします。

Heroku サービスの変換

変換の観点からは、サービス自体と ClearDB (MySQL) データベースという 2 つの項目を変換する必要がありました。

私の Spring Boot RESTful サービスの変換には、多くの作業は必要ありませんでした。実際、以前のプロジェクトで使用したアプローチを活用することができました。

データベースについては、MySQL から PostgreSQL に変換する必要がありました。私の目標は、Render のHeroku Migrator を使用して Heroku Postgres を Render Postgres に簡単に移行することでしたが、最初に MySQL から PostgreSQL に変換する必要がありました。

最初に、データベース変換の一般的なアプローチと思われるpgloaderパスから始めました。しかし、M1 チップの MacBook Pro を使用すると、予期しない問題が発生しました。

代わりに、 NMIGを使用して MySQL を PostgreSQL に変換することにしました。詳細については、以下の「データベース変換のハイライト」セクションをご覧ください。

Render でサービスを作成する

データベースと、Docker 内で実行される Spring Boot RESTful サービスを変換した後、次のステップは、Spring Boot RESTful API サービス用の Render Web Service を作成することでした。

これは、サービスを作成し、名前を付けて、GitLab 内のコードの適切なリポジトリをポイントするのと同じくらい簡単でした。

RabbitMQ サービスも必要だったので、こちらの手順に従って、Render で実行される RabbitMQ プライベートサービスを作成しました。これには、処理されていないメッセージを永続化するための少量のディスクストレージの確立が含まれていました。

最後に、Render Dashboard で、Spring Boot RESTful API サービスと RabbitMQ メッセージブローカーの両方に必要な環境変数を作成しました。

サービスの初期化と検証

次のステップは、私のサービスを開始することでした。 API が実行され、Postman コレクションを使用して API が検証されたら、新しい Render サービスの場所を指すようにクライアントアプリケーションを更新しました。

すべてが起動して実行されると、レンダリングダッシュボードが次のように表示されます。

次のステップ

この時点で残っていたのは、まだ Heroku で実行されているデータベースを削除し、移行されたサービスを Heroku エコシステムから削除することだけでした。

Heroku を使用している場合、サービスリポジトリのマスターブランチにコードをマージするたびに、 GitLab CI/CD を使用してソースリポジトリの Heroku にデプロイした場合、コードは自動的にデプロイされました。

ただし、Render を使用してソースファイルリポジトリにコードを追加する必要はありません。サービスのレンダリングダッシュボードで Build & Deploy ブランチを指定するだけで済みました。

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 への移行を振り返ってみると、途中で学んだ教訓がいくつかあります。

Postgres データベースが日付/時刻の値を更新して DST オフセットを含めることに小さな問題がありました。これは、元のデータベース設計の問題だった可能性がありますが、これを伝えたいと思いました。私の場合、影響を受けた列は日付値にのみ使用され、変更されませんでした。

テーブルの 1 つに END という名前のデータベースカラムを含めましたが、Postgres または Hibernate がネイティブクエリを返そうとしたときに問題が発生しました。サービスは END 列名を認識し、それを SQL キーワードとして挿入しました。この問題を修正するために列の名前を変更しただけです。

Render では、RabbitMQ サービスをプライベートサービスにする必要がありました。これは、Web サービスオプションが予期したポートを公開しないためです。ただし、このアプローチでは、Private Services が外部に公開されていないため、RabbitMQ 管理インターフェイスにアクセスできなくなりました。 Render はこの機能要求に対応する予定のようです。

全体として、これらの小さなハードルは、Render に移行するという私の決定に影響を与えるほど重要ではありませんでした。