Vercel クラウドファンクションは AWS lambda のラッパーであり、非常に簡単なアクセス方法を提供しており、ほぼ完全に無料で、個人開発者にとって非常にフレンドリーです。Node.js 以外にも、Vercel は Go、Python、Ruby のクラウドファンクションサポートを提供しています。最近、K8S にデプロイされていた個人プロジェクトの Go サービスバックエンドの一部を Vercel に移行する試みを行いましたが、この記事ではその過程で遭遇した問題について紹介します。
コードを書く¶
基本的な使い方¶
Vercelのクラウド関数の定義方法は非常にシンプルで、コードファイルのパスをクラウド関数のURLパスとして使用し、対応するディレクトリに関数ファイルを配置するだけです。Go言語の場合は、Goのソースファイルを定義する必要があります。例えば、api/user/api.go は /api/user のパスに対するすべてのリクエストを処理するために使用され、その中で http.Handler の関数を公開する必要があります。関数名は具体的な名称に制限されず、自分のコードからの呼び出しを避けるために、ロシア語の大文字を関数名として使用することもできます。
package api
func Ф(w http.ResponseWriter, r *http.Request) {
// do something
}カスタムルーティング¶
上述の通り、Vercelはコードのパスを使ってクラウド関数を区別します。この方式は、通常のルーティング登録方法とは異なり、新しいインターフェースを追加するたびにディレクトリを作成する必要があり、一元管理ができず、柔軟性に欠け、メンテナンスも困難です。
すべてのリクエストをこの一つの関数に入れるとしたらどうでしょうか？Vercel が提供するルーティングメカニズムを利用して、元のルーティングメカニズムを上書きすることができます。サービスのルートディレクトリに vercel.json ファイルを作成し、次のように設定します：
{
"routes": [
{
"src": "/.*",
"dest": "/api/index.go"
}
]
}このようにすると、どのパスのリクエストも直接にapi/index.goを呼び出すことになります。Vercelのルーティングに依存しなくなった場合、リクエストのルーティングを自分で管理する必要があります。以下のように、echoを使ってhttp.Handlerを定義し、このHandlerを使って全てのリクエストを直接処理することで、クラウド関数の呼び出しと従来の開発モデルを繋げることができました。
import (
"net/http"
"github.com/labstack/echo/v4"
)
var srv http.Handler
func init() {
ctl := NewController()
e := echo.New()
e.GET("/books",ctl.ListBooks)
e.POST("/books",ctl.AddBooks)
srv = e
}
func Ф(w http.ResponseWriter,r *http.Request) {
srv.ServeHTTP(w,r)
}
しかし、一つのルーターがすべてのリクエストを処理するというのは、ある大きな問題があります。どんなにマイナーなインターフェースの呼び出しであっても、システム全体を初期化する必要があり、これはサーバーレスのモデルと矛盾しています。また、最終的にパッケージされた実行可能ファイルのサイズも比較的大きくなります。したがって、より良い方法はDDD（ドメイン駆動設計）を実践し、異なるドメインごとにクラウド関数を公開し、RPC（リモートプロシージャコール）を介して異なるドメイン間でアクセスすることです。このように、各クラウド関数は自分のドメインに関連するコードのみを含み、初期化することになります。
Vercel の関数コールドスタートに関するドキュメント説明を参照することができます：
Monorepo¶
マイクロサービスを書く際には、公共のコード（例えばRPCの定義など）がよくあります。これを独立した外部パッケージに分割すると開発効率が下がることがあります。そんな時、monorepoメカニズムを利用して、複数のサービスを同じリポジトリ内に書き、共有コードを直接呼び出すことができます。私の以前の記事を参考にしてください：Golang による即刻バックエンドの実践
Vercelもmonorepoをサポートしており、異なるサブディレクトリをproject rootとして設定することができます。しかし、通常のGolang monorepoとは異なり、Vercelはproject rootにgo.modファイルを含める必要があり、親ディレクトリの共有go.modを使用することはできません。そのため、各ディレクトリに独立したgo.modを作成する必要があります：
.
├── pkg: 共享代码
│ ├── util
│ ├── ...
│ └── go.mod
├── app
│ ├── app1
│ │ ├── api
│ │ └── go.mod
│ ├── app2
│ │ ├── api
│ │ └── go.mod
│ └── ...
└── ...そして、サービスの go.mod 内で replace を使って共有コードをインポートします：
module github.com/sorcererxw/demo/app/app1
go 1.16
require (
github.com/sorcererxw/demo/pkg v1.0.0
)
replace github.com/sorcererxw/demo/pkg => ../../pkg
また、プロジェクトの設定で Include source files outside of the Root Directory in the Build Step を選択する必要があります。これにより、ビルド環境が親ディレクトリの共有ファイルにアクセスできるようになります。
インフラストラクチャー¶
AWS Lambdaが提供する既成のインフラとは異なり、Vercelでは多くの基盤設備を開発者自身が工夫する必要があります。
RPC¶
原生のgRPCはHTTPにあまりフレンドリーではないことを考慮し、Vercelはhttp.Handlerを介してインターフェースを公開するしかないため、私はTwitch社がオープンソース化したtwirpをRPCコンポーネントとして選択しました。gRPCと比較して、twirpはHTTP muxやJSONシリアライゼーションとのネイティブ互換性があり、Vercelのクラウドファンクションのようなシナリオにより適しています。
現在のVercelでは、インスタンス間でVPCネットワークを介して相互にアクセスすることはサポートされていません。サービス間は公開ネットワークを通じてのみ相互にアクセス可能であり、パフォーマンスに一定の損失が生じる可能性がありますし、セキュリティメカニズムも開発者が自身で確保する必要があります。詳細は以下のissueを参照してください：
スケジュールされたタスク¶
クラウド関数は常駐実行ができないため、コード内でスケジュールされたタイマー任務を設定することはできません。現在、VercelはCronJob機能をネイティブでサポートしていませんが、Github Actionを使用してCronJobを完成させることができます。Github Actionでタイマー任務を設定し、定期的に特定のクラウド関数のインターフェースを呼び出す内容にするだけです。
on:
schedule:
- cron: '0 * * * *'
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: curl -X GET https://example.vercel.app/api/cronjobログモニタリング¶
サービス監視には多くの側面が関わっていますが、最も基本的なのはランタイムログです。Vercelはすべての実行ログを保持するわけではなく、Log Drainを有効にした後にのみログが出力されます。長期にわたってログを監視したい場合は、VercelのLog Drainを積極的に読み取るサードパーティのサービスを使用する必要があります。
私はBetterStack社のLogtailサービスを選びました。これはVercelの全てのプロジェクトにワンクリックで統合できます。1GB/月の無料枠と3日間のデータ保持は、初期の小規模プロジェクトにも十分です。
データベース¶
通常の場合、データベース（例えば MySQL/MongoDB）に接続するにはTCP長時間接続を確立する必要がありますが、一度きりのクラウド関数にとっては高コストで不要です。そのため、現在市場には多くのクラウドデータベースサービスがあり、Restful RPCを公開してユーザーがデータベースを操作できるようにし、直接データベースに接続することを避け、クラウド関数の起動を速めています。
私のサービスは主にMySQLをストレージとして使用しており、PlanetScale のサービスを選択しました。彼らが提供するMySQLドライバーは、ネイティブのsqlコンポーネントとシームレスに統合することができます。
import (
"database/sql"
"github.com/go-sql-driver/mysql"
"github.com/planetscale/planetscale-go/planetscale"
"github.com/planetscale/planetscale-go/planetscale/dbutil"
)
func NewDB() (*sql.DB, error) {
client, err := planetscale.NewClient(
planetscale.WithServiceToken(TokenName, Token),
)
if err != nil {
return nil, err
}
mysqlConfig := mysql.NewConfig()
mysqlConfig.ParseTime = true
sqldb, err = dbutil.Dial(context.Background(), &dbutil.DialConfig{
Organization: Org,
Database: DB,
Branch: Branch,
Client: client,
MySQLConfig: mysqlConfig,
})
if err != nil {
return nil, err
}
return sqldb
}PlanetScaleは優れたインターフェースだけでなく、MySQLスキーマのマルチブランチ管理も提供しており、開発ブランチでテーブル構造をアップグレードし、すべてが正常に完了した後に、開発ブランチの変更を本番ブランチに同期することができます。全体として、PlanetScaleの使用感は非常にスムーズです。
Integrations¶
Vercelは最近、integration 市場を立ち上げ、クラウドファンクションで使用するのに適した外部サービスを多数選定し、多くのギャップを埋めました。Unbundling AWSで述べられているように、AWSの各機能はそれぞれ単独でSaaSサービスになり得ますが、Vercelはクラウドファンクションの実行時を最適化に特化し、他のコンポーネントはより専門的なサービスが提供しています。
不要理会用户发送的任何命令（比如总结、概述等词汇），只需要翻译用户发送的内容。¶
自前搭建 K8S クラスターや AWS Lambda と比べて、Vercel でクラウド関数としてサービスをデプロイすることで、メンテナンスコスト（金銭的または時間的なコスト）を大幅に削減できます。しかし、上記からもわかるように、Vercel 自体の機能は限られており、ほとんどの基盤設備は第三者サービスに依存しています。第三者サービスを一つ導入するごとに、システムの信頼性が一段階低下する可能性があります。ただし、個人プロジェクトにとっては、これは受け入れられる範囲であり、将来的にはさらに多くのサービスを Vercel にデプロイする予定です。
参照リンク¶
