こんにちは、cocone connectでサーバーサイドを担当している大友です。
cocone connectでは新サービスを絶賛開発中です。
今回は新プロジェクト開発の中でハマった点と、どのように解決に至ったのかについてご紹介できればと思います。
インフラ構成
開発中のプロジェクトでは、インフラ環境としてAWSを利用しVPC内に複数アベイラビリティゾーンを用意、Application Load Balancer(ALB)でEC2 Auto Scalingするというよくある構成をとっています。
唯一gRPCでUnityアプリケーションとアプリケーションサーバーとが通信するというのが挑戦部分でした。UnityアプリケーションからはgRPC with TLSで来てもらってALBでTLSターミネーション。ターゲットグループにはTLS無しのgRPCで来てもらう想定です。 現時点、ALBでHTTP2 / gRPCはリスナー側へはTLS必須ですが、ターゲット側は任意とのことです。
図で表すとこんな感じ。
サーバーアプリケーションを作る
Spring BootはgRPCを公式サポートしていないので、今回は「LogNet/grpc-spring-boot-starter」をgRPC実装として使用しました。
なんやかんやでjarで固めときます。
粛々と作りましょう。
ターゲットグループの設定をしていく
ALB構成を作成する中で、ターゲットグループを作る場面に出くわします。
- ターゲットタイプ : EC2 Auto Scalingを想定しているので、「インスタンス」を選択
- ターゲットグループ名 : 適宜命名(命名規約って大事)
- プロトコル – ポート : EC2で動く予定のアプリケーションにおいて、gRPCは6565で受け付けてます
- VPC : 適宜選択
- プロトコルバージョン : gRPC アプリケーションなのでgRPC選択
ヘルスチェック(ここがハマりポイントだった)
- ヘルスチェックプロトコル : HTTP (HTTPSも選べるが、任意)
- ヘルスチェックパス : デフォルトこのまま
- 成功コード : 12(このまま)
- その他項目 : 任意の値
実際に動かしてみた結果
jarをEC2にデプロイして動かしてみようとしましたが、ヘルスチェックがずっとunhealthyのまま変わらない。
なんでや。 アプリケーションの方のログにもなんにも出ていないうんともすんとも言わない。
ちなみにローカル環境でgRPC通信できることは確認済み。
ヘルスチェックがうまいこと行かない。
いろいろ試したりしていて2日ほど時間が溶けました。
インフラのメンバーともいろいろ話している中で、「tcpdumpとってみたら?」ってことでとってみることに。
とってみた結果がこちら。
HTTP2!!!!!!!1111
ヘルスチェックプロトコルでHTTPを選択していたので、てっきりHTTPで来てるものと思ってました。
gRPCでヘルスチェック来るんだからHTTP2でしょうけど、まったくもって勘違いから見事に考えが至らなかった。
2行の設定で解決した
Spring BootでHTTP2を受け付ける設定にしていなかったので、その設定を入れます。
application.ymlにhttp2を追加。おれの2日間は。。。。。
無事ヘルスチェックも通りました。
cocone connectでは一緒に働く仲間を募集中です。
ご興味のある方は、こちらのリンクからぜひご応募ください。
cocone connect株式会社 採用情報
https://recruit.jobcan.jp/coconeconnect
cocone connect株式会社 公式サイト
また、ココネでも一緒に働く仲間を募集中です。
ご興味のある方は、ぜひこちらの採用特設サイトをご覧ください。