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

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

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

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

同時に、生産性のプラトーが減少し始めるポイントがあり、そのイノベーションからの流出につながります。簡単な例の 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 に移行するという私の決定に影響を与えるほど重要ではありませんでした。

結論

Gartner の生産性のプラトーの最も重要な側面は、消費者が成功し、目標を達成できるようにする製品、フレームワーク、またはサービスを提供することです。生産性のプラトーは、比喩的な意味で、派手でファッショナブルであることを意図したものではありません。

Render の開発者アドボケイトである Ed にこの結論を伝えたところ、彼の反応は私が共有したかったものでした。

「Render は、『ファッショナブル』であることを目指していないことをかなり公言しています。私たちは、驚くべきことではなく、信頼できるものであるよう努めています。」

Ed の反応は私に深く共鳴し、以前の同僚が私のコードが「退屈」だと言ったときのことを思い出しました。彼のコメントは、私が受け取ることができた最大の賛辞であることが判明しました.詳しくはこちらをご覧ください。

テクノロジーのあらゆる側面において、どのプロバイダーを選択するかの決定は、常にテクノロジーの立場に一致する必要があります。よくわからない場合は、Gartner のハイプ サイクルが参考になります。こちらからサービスのサブスクリプションを開始できます。

私は次のミッション ステートメントに焦点を当ててきました。これは、あらゆる IT プロフェッショナルに適用できると思います。

「知的財産の価値を拡張する機能を提供することに時間を集中してください。他のすべてのフレームワーク、製品、およびサービスを活用してください。」

- J.ベスター

Render PaaS エコシステムを見ると、ハイプ サイクルの好みの範囲内にありながら、ミッション ステートメントに準拠しているソリューションが見つかります。

状況を改善するのは、個人の自己負担コストが 44% 削減されることを完全に期待していることです。サービスを垂直方向に拡張する必要があるため、さらに節約できます。

ホスティング ソリューションを検討している場合は、Render をプロバイダーのリストに追加して、レビューと分析を行うことをお勧めします。このリンクをたどることで、無料で始めることができます。

このシリーズの第 2 部はエキサイティングです。 Angular で記述された静的クライアントへの支払いを回避し、Vue または Svelte を使用して Render の無料の静的サイト サービスを利用する方法を示します。どのフレームワークを選択しますか? その理由は?

本当に素晴らしい一日を！