Contents
KrakenD の概要と主要機能
KrakenD は Go 言語で実装された API ゲートウェイ です。マイクロサービス群を単一のエンドポイントに統合し、バックエンド側の複雑さをフロントエンドから隠蔽します。高速な非同期 I/O とプラグインベースの拡張性により、トラフィックが増大しても低レイテンシを維持できる点が最大の強みです。
ポイント
- バイナリサイズは約 10 MB（静的リンク）で、コンテナイメージの軽量化に寄与。
- 標準プラグインとして JWT・OAuth2・Prometheus などが提供されており、追加実装が不要。
マイクロサービス統合がもたらすメリット
このセクションでは、ゲートウェイを導入することで得られる具体的な効果と、その背景にある技術的根拠を解説します。
1. エンドポイントの一元化
フロントエンドは 単一の URL（例：https://api.example.com/v1/…）だけを意識すればよく、バックエンドサービスが増減してもクライアント側のコードは変更不要です。
2. データ集約と変換
KrakenD の backend 配列と JSONPath 設定により、複数マイクロサービスから取得したデータを 1 回のリクエストで統合 できます。これによりフロントエンドの通信回数が削減され、ネットワークコストと待ち時間が大幅に低減します。
3. 認証・認可の集中管理
トークン検証やスコープチェックをゲートウェイ側で実施することで、各マイクロサービスに認証ロジックを重複実装する必要がなくなります。結果として セキュリティポリシーの一貫性 が保たれます。
軽量・プラグインアーキテクチャの特徴
KrakenD 本体は最小構成で 10 MB 程度ですが、機能拡張は extra_config に JSON 形式でプラグイン設定を追加 するだけです。
| カテゴリ | 標準プラグイン例 | 主な利用シーン |
|---|---|---|
| 認証 | krakend-jose, krakend-oauth2 |
JWT・OAuth2 の検証 |
| ロギング | krakend-gologger |
JSON 形式ログ出力 |
| メトリクス | krakend-prometheus |
Prometheus 連携 |
| カスタムロジック | 任意の Go パッケージ | 独自変換・フィルタリング |
拡張手順（概要）
- プラグインを Go モジュールとして作成し、ビルド時に
-tagsオプションで組み込み。 - 設定ファイルの
extra_config.{plugin_path}に必要なパラメータを記述。 - 再起動または
reloadAPI で即座に有効化。
KrakenD のインストール手順
本節では 公式バイナリ、Homebrew（macOS）、Docker の３つの導入方法を紹介します。どの環境でも同一コマンドで動作確認が可能です。
注意点
バージョン情報はkrakend versionで取得できますが、表示例に日付が含まれる場合は「ビルド日時」ではなく「リリース日」を明示するようにしてください（例：KrakenD v2.5.0 (released on 2024-10-15)）。
公式バイナリの取得と配置
|
1 2 3 4 5 6 7 8 9 10 |
# 1. 公式サイトから対象プラットフォーム用 tar.gz をダウンロード curl -L https://github.com/devopsfaith/krakend/releases/download/v2.5.0/krakend_2.5.0_linux_amd64.tar.gz -o krakend.tar.gz # 2. 解凍し、実行バイナリを /usr/local/bin にコピー tar -xzf krakend.tar.gz sudo install -m 755 krakend /usr/local/bin/ # 3. バージョン確認 krakend version # => KrakenD v2.5.0 (released on 2024-10-15) |
Homebrew（macOS）でのインストール
|
1 2 3 4 |
brew tap devopsfaith/krakend brew install krakend krakend version # 正しく表示されれば完了 |
Homebrew は常に 最新安定版 を取得します。リリース日が必要な場合は brew info krakend で確認できます。
Docker イメージの利用
|
1 2 3 |
docker pull krakend/krakend:2.5.0 docker run --rm -p 8080:8080 krakend/krakend:2.5.0 version |
公式イメージは Alpine ベースでサイズが約 30 MB と軽量です。latest タグは自動更新のリスクがあるため、バージョンタグ（例：2.5.0）を使用することを推奨します。
基本設定ファイル（krakend.json）の構造
krakend.json はゲートウェイ全体の挙動を定義する中心的なファイルです。ここでは 最低限必要なキー とその意味を解説し、拡張時に参照すべきポイントを示します。
ファイル構造の概要
|
1 2 3 4 5 6 7 8 |
{ "version": 3, "timeout": "3000ms", "cache_ttl": "60s", "extra_config": {}, "endpoints": [] } |
| キー | 説明 |
|---|---|
version |
設定スキーマのバージョン（現在は 3 が推奨）。 |
timeout |
バックエンド呼び出し全体の最大待機時間。ミリ秒単位で記述。 |
cache_ttl |
レスポンスキャッシュの有効期間。省略するとキャッシュ無効化。 |
extra_config |
プラグイン設定を格納するオブジェクト。 |
endpoints |
公開エンドポイントとそのバックエンド構成の配列。 |
エンドポイント定義の基本形
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "endpoints": [ { "endpoint": "/api/v1/users", "method": "GET", "output_encoding": "json", "backend": [] } ] } |
endpoint：外部に公開するパス。method：許可する HTTP メソッド（大文字）。output_encoding：レスポンス形式（通常はjson）。backend：バックエンドサービスの設定配列。
ポイント
基本構造だけ把握すれば、後から認証やキャッシュ、ロギングなどを自由に追加できます。
エンドポイント定義とデータ集約例
以下では「シンプルなリバースプロキシ」から「複数バックエンドの結果を統合」まで、実務でよく使われるパターンを段階的に示します。
1. シンプルなリバースプロキシ
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "endpoint": "/api/v1/status", "method": "GET", "backend": [ { "url_pattern": "/status", "host": ["http://service-status:8080"] } ] } |
url_pattern：バックエンド側のパス。host：対象サービスの URL 配列（複数可）。
この設定だけで、外部から /api/v1/status にアクセスすると内部の service-status が返す JSON がそのまま転送されます。
2. 複数バックエンドからのデータ集約（Aggregation）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "endpoint": "/api/v1/profile", "method": "GET", "backend": [ { "url_pattern": "/users/{{.UserID}}", "host": ["http://user-service:8080"], "mapping": { "UserID": "query.id" } }, { "url_pattern": "/teams/{{.UserID}}", "host": ["http://team-service:8080"], "mapping": { "UserID": "query.id" } } ], "extra_config": { "github.com/devopsfaith/krakend-gologger": {} } } |
mapping：リクエストクエリ（例：?id=123）の値をバックエンド URL に埋め込む。- 複数バックエンドから取得した JSON は自動的に マージ され、最終的なレスポンスは
{ "user": {...}, "team": {...} }の形になる。
3. JSONPath を用いたデータ変換
|
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 |
{ "endpoint": "/api/v1/summary", "method": "GET", "backend": [ { "url_pattern": "/stats", "host": ["http://analytics:8080"] } ], "extra_config": { "github.com/devopsfaith/krakend-jsonschema": { "output_schema": { "$ref": "#/definitions/Summary" }, "definition": { "Summary": { "type": "object", "properties": { "totalUsers": { "type": "integer" }, "activeSessions": { "type": "integer" } } } } } } } |
krakend-jsonschema プラグインで出力スキーマを明示すると、不要なフィールドが除外され、フロントエンド側の型安全性が向上します。
認証・認可の実装例
ゲートウェイで認証を集中管理することで、マイクロサービスは ビジネスロジック に専念できます。ここでは JWT 検証 と OAuth2 トークンインスペクション の設定例を示します。
1. JWT トークン検証（基本構成）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "endpoint": "/api/v1/secure", "method": "GET", "backend": [ /* ... */ ], "extra_config": { "github.com/devopsfaith/krakend-jose/router": { "alg": "HS256", "secret_is_base64": false, "disable_jwt_cookies": true } } } |
alg：使用する署名アルゴリズム（ここでは HS256）。disable_jwt_cookies：クッキー経由の JWT を受け付けず、ヘッダーのみ許可。
2. OAuth2 アクセストークンのインスペクション
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "endpoint": "/api/v1/oauth", "method": "POST", "backend": [ /* ... */ ], "extra_config": { "github.com/devopsfaith/krakend-oauth2/introspection": { "introspection_url": "https://auth.example.com/introspect", "client_id": "my-client-id", "client_secret": "**********", "scopes_required": ["read:data"] } } } |
introspection_url：RFC 7662 に準拠したトークン検証エンドポイント。scopes_required：不足時は自動的に 403 Forbidden が返されます。
ベストプラクティス
- 秘密情報（シークレットやクライアントシークレット）は 環境変数 で注入し、設定ファイルにはプレースホルダーだけを書き込む。
ログ出力・モニタリング & Docker 環境構築
本節では JSON ログ, Prometheus メトリクス の有効化手順と、Docker でのローカル開発環境構築方法をまとめます。
1. 標準ロガーのカスタマイズ
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "extra_config": { "github.com/devopsfaith/krakend-gologger": { "level": "INFO", "output": "stdout", "format": "json", "prefix": "[KrakenD]" } } } |
level：本番は INFO、デバッグ時は DEBUG。format: jsonにすると ELK スタックや Loki との相性が良くなります。
2. Prometheus メトリクスの有効化
|
1 2 3 4 5 6 7 8 9 |
{ "extra_config": { "github.com/devopsfaith/krakend-prometheus": { "endpoint": "/metrics", "namespace": "krakend" } } } |
/metrics にアクセスすると、以下のような指標が取得可能です。
| 指標名 | 説明 |
|---|---|
krakend_request_total |
総リクエスト数 |
krakend_response_time_seconds |
レスポンスタイム（ヒストグラム） |
krakend_backend_upstream_latency_seconds |
バックエンド呼び出しの遅延 |
3. Dockerfile（最小構成）
|
1 2 3 4 5 6 7 8 9 |
# syntax=docker/dockerfile:1 FROM krakend/krakend:2.5.0 WORKDIR /etc/krakend COPY krakend.json . EXPOSE 8080 CMD ["run", "-c", "/etc/krakend/krakend.json"] |
krakend/krakend:2.5.0は公式の Alpine ベースイメージ。- 設定ファイルはビルド時にコピーし、コンテナ起動時に自動でロードされます。
4. docker‑compose.yml（ローカル開発向け）
|
1 2 3 4 5 6 7 8 9 10 |
version: "3.8" services: krakend: build: . ports: - "8080:8080" volumes: - ./krakend.json:/etc/krakend/krakend.json:ro restart: unless-stopped |
volumesによってローカルのkrakend.jsonをマウントすれば、設定変更が即座にコンテナへ反映されます。
5. 動作確認コマンド例
|
1 2 3 4 5 6 |
# エンドポイントの正常応答をチェック curl -i http://localhost:8080/api/v1/users?id=123 # Prometheus メトリクス取得（先頭数行だけ表示） curl http://localhost:8080/metrics | head |
Postman でも同様に Headers に Authorization: Bearer <token> を付与すれば、認証付きエンドポイントのテストが可能です。
参考文献・ベンチマーク情報
| 項目 | 内容 | 出典 |
|---|---|---|
| 同時接続 10,000 件での CPU 使用率 | 約 30 %（Intel Xeon Gold 6248R、64 GB RAM、Ubuntu 22.04） | 【1】KrakenD 公式ベンチマークレポート (2024‑09‑12) https://github.com/devopsfaith/krakend/blob/master/docs/benchmarks.md |
| バイナリサイズ（Linux x86_64） | 約 10 MB（静的リンク） | 【2】KrakenD Release Notes v2.5.0 (2024‑10‑15) https://github.com/devopsfaith/krakend/releases/tag/v2.5.0 |
| プラグイン一覧 | JWT, OAuth2, Prometheus, Gologger など | 【3】公式プラグインカタログ https://www.krakend.io/docs/plugins/ |
| Docker イメージサイズ | 約 30 MB（Alpine） | 【4】Docker Hub – krakend/krakend (tag:2.5.0) https://hub.docker.com/r/krakend/krakend/tags |
注記
ベンチマークは公式リポジトリのbenchmarks.mdに掲載されている数値を引用しています。実環境で同等の結果が得られるかは、CPU アーキテクチャ・ネットワーク条件・バックエンドサービスの応答時間などに依存します。導入前には 自社環境での負荷試験 を実施することを推奨します。
以上が KrakenD の基本的な概要からインストール、設定、運用までを網羅したガイドです。各セクションは独立して参照できるように構成していますので、プロジェクトのフェーズや目的に合わせて必要な部分だけでも活用してください。