KotlinでgRPC。実運用にも活かせるWEBアプリケーション構成で試してみた。

April 13, 2017
gRPC
kotlin
Spring Boot

KotlinでgRPCを試していきます。protocol buffersがkotlinに対応していないのでjavaに生成したものを使います。次のようなアプリケーション構成でKotlinを使ったgRPC通信を試してみました。

アプリケーション構成

エンドクライアントからのアクセスはGateway Serverが窓口となりHTTP/1.1で通信を行います。
Gateway ServerのバックエンドにいるgRPC ServerとはgRPC（HTTP/2）で通信を行います。
monitoring toolはGateway ServerとgRPC Serverの監視を行いHTTP/1.1で通信を行います。

モチベーション

何度かgRPCについてのエントリをまとめてきました。kotlinでgRPCを試してみたいと感じていたのとSpring Framework 5.0のリリースを控えた状況でSpring Framework 5 on Kotlinを試してみたい欲求がありました。そのためアプリケーション構成図にあるとおりGateway ServerにはRouter機能を試したいので spring-webfluxでアプリケーションを作りました。

次のエントリではSpring Framework 5.0でReactive Programmingを活用しながらkotlinらしいコードの紹介がされています。

Introducing Kotlin support in Spring Framework 5.0

またgRPC ServerではHTTP/1.1とgRPC(HTTP2)の２つの通信方式を有効にしたいです。Spring Bootでどのように実現するのか？この課題についても理解を深める必要がありました。

そして実戦に向けて実運用をイメージしたアプリケーション構成を構築する必要がありました。

ここからは構築にいたるまでの勘所や課題などについてまとめていきます。

gRPC Server

まずはgRPC Serverからです。
ここでの課題はHTTP/1.1とgRPC(HTTP2)の２つの通信方式を有効にすることです。

monitoring toolからはヘルスチェックなどの監視リクエストに応えるためにHTTP/1.1で通信を行いたい
Gateway Serverとの通信にはgRPC(HTTP2)で通信を行いたい

この課題を解決するために次のspring-boot-starterを使いました。

こちらを使えばgRPC Serverを実装したクラスに@GRpcServiceをつけるだけでgRPC SeverをSpring Boot上に起動できます。またSpring Boot（spring-boot-starter-web）で起動していますのでHTTP/1.1の通信も有効です。

1
2
3
4
5
6
7
8
9


@GRpcService
class EchoServer : EchoServiceGrpc.EchoServiceImplBase() {

    override fun echoService(request: EchoMessage?, responseObserver: StreamObserver&lt;EchoMessage>?) {
        val msg = EchoMessage.newBuilder().setMessage("echo \\${request?.message}/").build()
        responseObserver?.onNext(msg)
        responseObserver?.onCompleted()
    }
}

レポジトリのREADMEにあるとおりinterceptorの提供（ログ差し込んだり）やServerビルド定義もカスタマイズできます。

1
2
3
4
5
6
7
8


$ ./gradlew clean generateProto bootRun
・・・
2017-04-13 14:48:45.479  INFO 30602 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)
2017-04-13 14:48:45.482  INFO 30602 --- [           main] o.l.springboot.grpc.GRpcServerRunner     : Starting gRPC Server ...
2017-04-13 14:48:45.528  INFO 30602 --- [           main] o.l.springboot.grpc.GRpcServerRunner     : 'app.grpc.server.EchoServer' service has been registered.
2017-04-13 14:48:45.531  INFO 30602 --- [           main] o.l.springboot.grpc.GRpcServerRunner     : 'app.grpc.server.GreetServer' service has been registered.
2017-04-13 14:48:45.765  INFO 30602 --- [           main] o.l.springboot.grpc.GRpcServerRunner     : gRPC Server started, listening on port 50051.
・・・

8080ポート（HTTP/1.1）と50051ポート（gRPC／HTTP2）の両方が起動ログで確認できます。これでgRPC Serverの課題は解決です。

Gateway Server

次にGateway Serverです。
ここではspring-web-fluxを使いreactor coreベースでアプリケーションが動いています。そしてエンドクライアントからリクエストをgRPC Serverへ渡すgatewayの役割を担います（gRPCクライアントの役割）。
spring-web-fluxを使うとnon-blockingなservletが起動するためgRPCクライントには okhttpを使います。gRPCのクライアントは標準でnettyが使われるためokhttpを指定します。これをしないとreactor coreのアプリケーションとgRPC Serverのnon-blokingなところがバッティングしてしまうようです。

1
2
3
4


private fun getChannel() = OkHttpChannelBuilder.forAddress(appProperties.grpc.server.hostname, appProperties.grpc.server.port!!)
            // for testing
            .usePlaintext(true)
            .build()

もしGateway Serverとエンドクライアントとの通信にgRPCを使いたい場合はGateway ServerにgRPC Serverを置く必要がありバッティング問題を解消しなくてはなりません。これに関してはSpring Framework5.0の正式リリースやマイルストーンの動きを見て試していく必要があり課題として残りました。

protobuf-gradle-plugin

protoclo bufferの生成には次のgradleプラグインを使っています。

起動時に.protoからprotocol bufferを生成するようにgradleに次ような設定をしています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


protobuf {
    protoc {
        artifact = 'com.google.protobuf:protoc:3.2.0'
    }
    plugins {
        grpc {
            artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}"
        }
    }
    generateProtoTasks {
        ofSourceSet('main').each { task ->
            task.builtins {
                java {
                    outputSubDir = 'protoGen'
                }
            }
            task.plugins {
                grpc {
                    outputSubDir = 'protoGen'
                }
            }
        }
    }
    generatedFilesBaseDir = "$projectDir/src/"
}

task cleanProtoGen {
    doFirst{
        delete("$projectDir/src/main/protoGen")
    }
}
clean.dependsOn cleanProtoGen

上記の定義により./gradlew clean generateProtoを実行することでprotocol bufferを再生成できます。起動時に最新の.protoからprotocol bufferを使われるように起動コマンドは./gradlew clean generateProto bootRunを使っています。

まとめ

現バージョンのSpring Boot 1.5.2ではLogNet/grpc-spring-boot-starterを使うことでHTTP/1.1とgRPC(HTTP2)の共存課題は解決できました。
Spring Framework 5ではreactor coreの採用からgRPC Serverとの共存には課題が残りました。今後のjavaのエコシステムなどを使いながら課題解決に取り組みます。

コードを公開しています

今回のKotlinでgRPCを試したコードのすべてはgithubに公開しています。起動して確認するにはgithubのコードからできますのでREADMEを参照してください。