バックエンド開発におけるインフラ管理の課題
バックエンドアプリケーションを開発する際、データベースやメッセージキュー、オブジェクトストレージといったインフラをコードとは別に手動で構築し、ローカル環境とクラウド環境で設定を揃える作業は手間がかかります。環境ごとに設定がずれると、ローカルでは動いていた処理がクラウドで失敗するといった問題も起きやすくなります。AWSやGoogle Cloudを利用する場合、Terraformなどでインフラを定義する方法もありますが、アプリケーションコードとインフラ定義が別々のリポジトリや言語で管理されることが多く、両者の整合性を保つことが課題になりやすい状況です。
Encoreが提供する機能
EncoreはTypeScriptやGoのSDK内で、データベースやPub/Sub、オブジェクトストレージ、キャッシュなどのリソースをコードとして宣言できるフレームワークです。SQLDatabaseやTopic、Bucketといった形でアプリケーションコードの中にリソースを定義すると、それがアプリケーション全体のグラフのノードとして扱われます。encore runコマンドでローカル実行すると、宣言したリソースに対応するローカル環境のPostgresやNSQ、ローカルファイルシステムなどが自動的に立ち上がります。コードをリポジトリにプッシュすると、プラットフォームがアプリケーショングラフとクラウド環境の差分を検出し、AWSやGoogle Cloud上に対応するRDSやSNS+SQS、S3などのリソースを自動でプロビジョニングしてデプロイする仕組みです。プルリクエストごとのプレビュー環境作成や、Terraformプロバイダを使ったIaCでの設定管理にも対応しているとされています。
導入を検討すべき場面
新規のバックエンドサービスをAWSやGoogle Cloud上に構築する際、ローカル開発とクラウド環境でのインフラ構成の差異を減らしたい場合や、サービス単位でのプレビュー環境を使ったPRベースの検証フローを整えたい場合に検討対象になりそうです。README内では、既存システムの一部サービスだけをEncoreで書き直し、他のサービスとAPI経由で連携させる段階的な移行方法も紹介されており、全面的な書き換えを避けたいケースにも触れられています。対応言語は現時点でTypeScriptとGoで、Pythonは今後対応予定とされています。
READMEだけでは判断できない点
README内では対応するクラウドプロバイダーとしてAWSとGoogle Cloudが挙げられ、Azureは今後のロードマップに含まれると記載されていますが、具体的な対応時期は示されていません。また各マネージドリソースへの変換の詳細な挙動や、既存の大規模システムへ段階的に移行する際の実際の工数、運用プラットフォームの料金体系の詳細などは本文からは読み取れません。実際の動作や移行の難易度を確認する際は、公式ドキュメントや移行ガイドを別途参照する必要があります。
出典
本記事はEncoreの公式READMEに基づいています。
https://github.com/encoredev/encore/blob/main/README.md
公式READMEをもとに、AIを執筆・推敲支援に使用しています。実機検証の報告ではありません。