Spring Cloudシリーズの第4回です。
概要
今回は「Spring Cloud Gateway」を使ってAPI Gatewayを立てることにします。
Spring Cloundファミリーでは従来、「Zuul」が使われていましたが、Zuulはメンテナンスモードとなり、「WebFlux&Nettyベースの」「Spring Gloud Gateway」が代替プロダクトとなっています。
API GatewayはAPIの前段に建てるリバースプロキシとして働きます。
API Gatewayの役割としては、クライアントとAPIの間に入り、API側に持ち込みたくない関心事を前段でさばくことにあります。
下の図は、API Gateway向けの別プロダクト「KrakenD」のドキュメントから拝借しています。
フィルタリング、入出力の返還、APIの集約、ログや統計情報取得、認証回り(SSLを解いたり、トークンをチェックしたり付加したり)、Throtting(流量制御でいいのかな?)といったところが代表例です。
個人的には2つを重要視していて、SpirngベースのSpring Cloud Gatewayには期待しています。
- APIの前段に構えるので、パフォーマンスが良いこと。
- 並行してアクセス数を多くさばける必要あり。
- カスタマイズ性に富んでいること。
- API Gatewayに機能追加がしやすいこと。(やりたいことがシンプルにできる)
環境
以下が動く環境を前提とします。
- docker & docker-compose
- JDK11
前回までの投稿の続きですので、前回のゴール地点のソースを手元に用意し、それをベースとします。
作業ステップ
本記事では以下のステップで進めていきます。
- API Gatewayのひな型作成
- 実装(アノテーションの付加と設定ファイルの記述)
- Dockerイメージ化とdocker-componentへの追加
ステップ1:API Gatewayのひな型作成
Spring Initializr の出番です。
Artifact と Name だけgateway
に指定し、あとは
Dependencies にGateway
と Eureka Client
、Spring Cloud LoadBalancer
、SpringBoot Actuator
を追加しましょう。
ActuatorはGatewayに必須ではありませんが、何かと必要になるものなので追加しておきます。
Dependencies | 説明 |
---|---|
Gateway | Spring Cloud Gateway を導入するために追加 |
Eureka Discovery Client | Eurekaからサービスのリストを取得するために追加 |
Spring Cloud Loadbalancer | クライアントサイド・ロードバランスのライブラリを追加 |
Spring Boot Actuator | Spring Boot の内部情報を参照するために追加 |
あとはGENERATE
するとスケルトンのgateway.zipがダウンロードできます。
ステップ2:実装(アノテーションの付加と設定ファイルの記述)
今回もあまりやることがありません。2つだけ。
まず1つ目。
Applicationクラスにアノテーションを1つ付けます。
これでService Discoveryを参照できるようになります。
package com.example.gateway;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient; // ★追加する
@SpringBootApplication
@EnableDiscoveryClient // ★追加する
public class GatewayApplication {
public static void main(String[] args) {
SpringApplication.run(GatewayApplication.class, args);
}
}
やること2つ目。設定ファイル「application.yml」を書きます。
※src/main/resources/application.properties
は不要になるので、削除してください。
server:
port: ${PORT:5000}
spring:
main:
banner-mode: "off"
application:
name: gateway
cloud:
gateway:
routes:
- id: account
uri: lb://ACCOUNT-API
predicates:
- Path=/api/**
filters:
- RewritePath=/api(?<segment>/?.*), $\{segment}
loadbalancer:
ribbon:
enabled: false
management:
endpoints:
web:
exposure:
include: "*"
eureka:
instance:
prefer-ip-address: false
client:
registerWithEureka: false
serviceUrl:
defaultZone: ${DISCOVERY:http://localhost:8761/eureka}
Routes
の箇所がルーティングの定義です。
今回は1つだけRouteの定義をしており、以下を指定しています。
- ServiceDiscoveryから「ACCOUNT-API」サービスのインスタンスリストを取得し、負荷分散してリクエストする。(uri)
- リクエストされたパス「/api/xxx」 に対し、アクセス先パスを「/xxx」に書き換えてサービスへリクエストする。(predicates/filters)
また、eureka.client.serviceUrl.defaultZone
には、Service Discovery(Eurekaサーバ)のURLを指定します。
ステップ3:Dockerイメージ化とdocker-componentへの追加
Dockerイメージを作成してdocker-composeで操れるようにしましょう。
前回のディレクトリ構造に以下のようにgateway
ディレクトリを配置します。
その上で、Dockerfileを作成し、とdocker-compose.ymlに追記します。
spring-msa
├── account
│ └── ・・・
├── db
│ └── init
├── docker-compose.yml <-- ★追記する
├── gateyway <-- ★配置する
│ └── Dockerfile <-- ★作成する
└── sd
└── ・・・
FROM openjdk:11-jdk-slim
ADD target/gateway-*.jar /gateway.jar
ENV CONTAINER_NAME=localhost \
PORT=5000 \
OPTS_ARGS=''
ENTRYPOINT ["java", "-jar", "/gateway.jar", "${OPTS_ARGS}"]
version: '3'
・・・
services:
db:
・・・
adminer:
・・・
gateway:
image: spring-msa/gateway
container_name: gw
build:
context: ./gateway
dockerfile: Dockerfile
environment:
- CONTAINER_NAME=gw
- PORT=5000
- DISCOVERY=http://sd:3001/eureka/,http://sd2:3002/eureka/
ports:
- "5000:5000"
sd:
・・・
account:
・・・
これで準備OK.
mvn wrapperでJARを作ったあとに、Dockerイメージを作成します。
$ cd discovery
$ .mvnw clean package
$ cd ..
$ docker-compose build gw
これでdocker-composeでgwを起動・停止できるようになりました。
(全サービスを起動)
$ docker-compose up -d
(GWの停止)
$ docker-compose stop gw
(全サービスの停止と破棄)
$ docker-compose down
(全サービスの停止とVolumeを含めた破棄)
$ docker-compose down -v
コンテナの5000ポートをホストの5000ポートにbindしているので、
http://localhost:5000/api/info でアクセスできます。
下記のように繰り返し/api/infoを呼ぶと、Service Discoveryが返すサービスインスタンスのリストを使って
呼び先のACCOUNT-APIが負荷分散されているのがわかると思います。
組み込まれているロードバランサのデフォルトのアルゴリズムがRoundRobinなため、順番にリクエスト先が振られている状態です。
$ curl localhost:5000/api/info
{"containerName":"account","port":"9001","hostAddress":"172.18.0.9","hostName":"c1f0f98a3859"}
$ curl localhost:5000/api/info
{"containerName":"account2","port":"9002","hostAddress":"172.18.0.7","hostName":"27d40318d8bc"}
$ curl localhost:5000/api/info
{"containerName":"account3","port":"9003","hostAddress":"172.18.0.8","hostName":"7c2abf523dcf"}
$ curl localhost:5000/api/info
{"containerName":"account","port":"9001","hostAddress":"172.18.0.9","hostName":"c1f0f98a3859"}
$ curl localhost:5000/api/info
{"containerName":"account2","port":"9002","hostAddress":"172.18.0.7","hostName":"27d40318d8bc"}
$ curl localhost:5000/api/info
{"containerName":"account3","port":"9003","hostAddress":"172.18.0.8","hostName":"7c2abf523dcf"}
何かがおかしければdockerのログをみてください。
$ docker-compose logs -f gw
さいごに
ここまでのソースを以下に置いています。
ここまで来てようやく土台ができつつあります。
これからやってみたいこととしては、API Gatewayに機能追加を試すことです。
ロードバランスのアルゴリズムをカスタマイズしたり、APIに負荷をかけすぎないようにアクセス流量制御を追加してみたいところです。
と、なると、
その前にもう少し準備をしておく必要があります。
- どこのAPIサービスにリクエストが行って1リクエストの中でどこにどれだけ時間がかかっているのか。
- リクエスト数はそれぞれのサービスでどれだけさばけているのか。
- そもそも負荷をかけたときにサービスはどのくらい余裕があるのか。
などなど、アクセスのトレースや、コンテナ/サービスのモニタリングをができる状態で負荷テストツールで負荷をかけられるようにしておきたいところです。
次回からはその辺を進めていきたいと思います。
ではでは。