ECS + Fargate + gRPCを使ったマイクロサービス構成
バックエンドサーバは機能毎にマイクロサービスとして分割し、サーバ間通信には gRPC を使ってモダンな感じにしたい。
最初のインフラ構想
まず Node.js アプリケーションをコンテナベースにして、Code Pipeline + CodeBuild + ECR + ECS + Fargate で継続的デプロイ&オートスケールする仕組みを作った。
だがうまくいかなかった。バックエンドの gRPC でサーバ間通信を行う部分で Unavailable
, transport is closing
というエラーになってしまう。
この ALB を使って ECS タスクに対して負荷分散させる構成は gRPC を使わずに REST API でならうまくいった。
HTTP/2 の gRPC は ALB と相性が悪い
gRPC は HTTP/2 が必須となり、ALB も HTTP/2 に対応しているが、それはフロントエンドのみ。ALB によってバックエンドに転送する場合は強制的に HTTP/1.1 になってしまい、gRPC としての通信が失敗してしまう。
じゃあ ALB を諦めて CLB にするしかないか…と変更しようとしたが、ECS + Fargate を使う場合、ECS のネットワークモードが awsvpc
固定となり、ロードバランサーには ALB 以外を選ぶことができない。
つまり gRPC の負荷分散のために CLB を使うなら Fargate は諦めて ECS + EC2 で運用するということになり、インスタンス管理コストの低下という大きなメリットを享受できなくなってしまう。
それだったら gRPC は諦めて Swagger(OpenAPI) で REST API にするしかないかなぁという雰囲気になりつつあった。
ECS サービスディスカバリを使うことで解決
いろいろ検討した結果、ECS サービスディスカバリが使えるのではないかと教えてもらった。
ECS でクラスターとサービスを作ると、サービス名が Route53 で自動的に 複数値回答レコードとしてドメイン登録され、ECS タスクの数だけ IP アドレスが割り振られる。
例えば game-server
というサービス名にし、3 つのタスク(コンテナ)を起動した場合は 3 つの内部 IP アドレスそれぞれに game-server.local
というドメイン名が割り当てられ、同一 VPC 内であればアクセスできるようになる。
Route 53
Name | Type | Value |
---|---|---|
game-server.local. | A | 10.0.0.1 |
game-server.local. | A | 10.0.0.2 |
game-server.local. | A | 10.0.0.3 |
複数値回答レコードはドメイン game-service.local
にアクセスすると、最大 8 つの IP アドレスをクライアントに返す。上記の場合は 10.0.0.1
, 10.0.0.2
, 10.0.0.3
の 3 つのアドレスが返る。
試しに同じ VPC に AWS Cloud9 を立ち上げ、ターミナルから dig
コマンドを試してみると次のような結果となる。
$ dig +short game-service.local 10.0.0.1 10.0.0.2 10.0.0.3
なお、Route53 側で Hosted zones の local.
にチェックをいれ、Associated VPC に対象の VPC が含まれていないと参照できないので注意。
あとはクライアント実装次第となるが、通常はラウンドロビンされた値が使われることになる。curl
や wget
だと 1 番目の値しか使われなかったが HTTP Client ライブラリの axios はラウンドロビンされて使われていた。
ECS サービスディスカバリとヘルスチェック
ECS のタスク定義で Docker コンテナの HEALTHCHECK を指定できる。
ヘルスチェックが失敗するとタスクは異常と判定し、ECS はタスクを終了してから新しいタスクを自動起動してくれる。
これが ECS サービスディスカバリとも連携してくれるので、タスクが終了すると同時に、タスクの内部 IP アドレスに割り当てられた game-server.local
も削除され、ルーティングされなくなるのでとても便利。
Nest.jsでgRPCを使ったマイクロサービス
Nest.js ではアプリケーションサーバとして動かすだけでなく、同時に gRPC として動かし、別のマイクロサービスと通信ができる設計になっている。
main.ts
(async () => { const app = await NestFactory.create(AppModule); const protoDir = join(__dirname, '..', 'protos'); app.connectMicroservice({ transport: Transport.GRPC, options: { url: '0.0.0.0:5000', package: 'rpc', protoPath: '/rpc/rpc.proto', loader: { keepCase: true, longs: Number, defaults: false, arrays: true, objects: true, includeDirs: [protoDir], }, }, }); await app.startAllMicroservicesAsync(); await app.listen(3000); });
普通のアプリケーションサーバとして動かす必要がないなら await app.listen(3000);
をコメントアウトする。
マイクロサービスなので単一の .proto
ファイルを読み込むレベルのシンプルなもので事足りると思うが、複数 proto を読み込みたい場合は includeDirs
でディレクトリを指定すればよい。ここは Nest.js 公式のサンプルになく、Issue あげたら教えてもらえた。この部分は @grpc/proto-loader が使われている。
rpc.controller.ts
Controller はデコレーターで gRPC のサービス名とメソッド名を指定する方式。
リクエスト/レスポンスの型情報は公式の grpc-tools
を使うより protobuf.js
で生成した方が JavaScript オブジェクトをそのまま型変換できて便利。
@Controller() export class RpcController { constructor(private readonly championService: ChampionService, private readonly battleFieldService: BattleFieldService) {} @GrpcMethod('Rpc', 'GetChampion') async getChampion(req: GetChampionRequest): Promise<GetChampionResponse> { const obj = this.championService.getChampion(req.champion_id); return GetChampionResponse.create({champion: obj}); } @GrpcMethod('Rpc', 'ListChampions') async listChampions(req: IEmpty): Promise<ListChampionsResponse> { const champions = this.championService.listChampions(); return ListChampionsResponse.create({champions}); } @GrpcMethod('Rpc', 'GetBattleField') async getBattleField(req: IEmpty): Promise<rpc.GetBattleFieldResponse> { const battleField = this.battleFieldService.getBattleField(); return GetBattleFieldResponse.create({battle_field: battleField}); } }
ここで必要なのは単純な型情報だけなので、自分で get-champion-request.dto.ts
みたいな interface を定義して使ってもいい。リクエストに含まれるパラメータが Nest.js が自動で格納するので、req.champion_id
のように参照することができる(keepCase: false
にするとキャメルケースになる)。
rpc.proto
protobuf のサービス定義はこんな感じ。サンプルでしかないけど League of Legends のチャンピオン取得ができる API みたいなのを想定している。
service Rpc { rpc GetChampion (GetChampionRequest) returns (GetChampionResponse); rpc ListChampions (Empty) returns (ListChampionsResponse); rpc GetBattleField (Empty) returns (GetBattleFieldResponse); }
疎通テスト
疎通確認には golang の gRPCurl を使うと便利。
$ grpcurl -d '{"champion_id": 1}' -plaintext -proto ./rpc/rpc.proto -import-path ./protos 127.0.0.1:5000 rpc.Rpc/GetChampion { "champion": { "championId": 1, "type": "ASSASSIN", "name": "Akali", "message": "If you look dangerous, you better be dangerous." } }
フルソースコード
Node.js の gRPC サンプルはあまりないので参考になるとよいです。