Go APIゲートウェイ構築で感じた実用的な改善ポイント

まずはこのステップを実行してみて - Go APIゲートウェイ構築で日常運用がグッと楽になる即効アクション

ルーティング設定はURLパス単位で10件以下に絞る
複雑化を防ぎ、変更やデバッグ時の混乱が減ります
JWT認証ロジックは1カ所に集約し一元管理へ切り替え
セキュリティ漏れや重複ミスを回避しやすくなる
APIゲートウェイ全体で毎週ログ出力内容を見直す
障害発生時の原因特定時間が半分以下に短縮されることも
(自作より)既存ライブラリやOSS導入比率を7割以上目指す
"車輪の再発明"から解放されて保守コスト激減

混乱なマイクロサービスに振り回されて疲弊

3年前だっけ？いや、もうちょっと前だったかも。とにかく、あの時私は自分たちのマイクロサービスアーキテクチャが妙に複雑化しすぎて、運用面でもう疲弊している現実を目の当たりにしていた。なんだろうなぁ…チームのみんなも、それぞれ担当するサービス群にはやけにこだわってて、それはそれで悪いことじゃないんだけど、統一されたエントリーポイントみたいなものが全然なくてさ。うーん…話が逸れるけど、この「エントリーポイント」って言葉、最近どうしてこんなに耳に残るんだろう……まあ、とりあえず戻るね。

APIリクエストっていうのは好き勝手な方向へ飛び交っていたし、そのせいで認証処理にも全く一貫性が見られなかった。不具合とかネットワークトラブルへの対応も、いつも想像以上に時間を取られてばかりで、「またこれかよ」みたいな溜息ばっかり出ちゃってた。本当に困った。そういう背景だったからこそ、私はあえて週末を使ってGoでAPIゲートウェイを開発することを決心した。まあ正直、「本当に必要なの？」と疑問抱きながら始めた部分もある。でも結局、その判断ひとつでシステム運用自体がガラッと変わったし、自分の堅牢なソフトウェア設計観にも影響した気がする。

そのAPIゲートウェイは短期間で組み上げただけなのだけれど、不思議なくらい今でも本番環境できちんと安定して動いてるんだよね。ま、いいか。この記事では、このGoベースのAPIゲートウェイ開発を決意した理由とか、その具体的なやり方、それから運用経験から感じた教訓なんかについて書いていこうと思う。「Go言語」とか「APIゲートウェイ」という単語を見るだけで少しでも興味湧く人や（いるかな？）、マイクロサービス環境下ならではの課題に直面した人にも何か参考になれば幸甚です。

## なぜAPIゲートウェイなのか？
私たちがぶつかった壁

状況として、一応説明すると、自社プラットフォーム上には約12個ほどマイクロサービスがそれぞれ独自のエンドポイント持ちながら存在していた。一部はユーザー認証担当、一部は決済管理専任、そのほか分析関連など機能ごと細分化されていて…。ああでも、ときどき「この数、本当に正確？」と不安になる瞬間もある。でもまぁ、大体そんな感じだったと思う。

フロントエンドチームとしては複数URLへのアクセスとかCORS対応とか、不統一すぎる認証フローへの適応……そういう厄介事ひとつひとつに個別対処せざるを得ない泥臭さというかなぁ、本当に大変だった。その結果として余計な工数や精神的負担まで積み重なる始末。でも、こう書いてみても実際現場で味わった混乱感までは伝わらない気がする。不思議だよね、人間って。本筋戻すね──まぁ、とにもかくにも課題は山積していたのでした。

Goを週末で選んだその時の空気感と決断

その間、バックエンドのチームはさ、トークンの検証とかリクエストのログ記録とか、あとレートリミットみたいな同じことを繰り返すコードにずっと頭を抱えてたんだよね。これが一番しんどい時って、やっぱりオンコールシフトで…ああ、そういえばこの前も深夜だったっけ？あるクライアントからAPIリクエストが途切れ途切れで失敗してるって連絡が来てさ。ま、それ自体は珍しくないけど、今回はなんか様子がおかしかった。えーと、それで数時間くらい調査した結果なんだけど、一つのサービス側で設定ミスがあったんだよね。有効なトークンなのに、不適切なシークレットキーで弾いちゃってて、「どうしてこんな単純なところ見落としてたんだろう」って正直自分でも呆れた。でもまあ、人間だから仕方ないか。

いやほんと、その時ちょっと考えごとしてしまった。「もし全部の入口が一つにまとまってて、一貫性保ててればこんなのもっと早く気づいたよな？」みたいな。うーん、自分でもわりと後悔というか反省…。そこで初めて本当に必要なのは**APIゲートウェイ**じゃないかなと思い至ったわけです。ルーティングも認証もログ記録もぜんぶまとめて面倒見る層――こういう集中管理できる場所。一瞬話逸れるけど、「玄関口」って言葉好きだな、とふと思った。でもまあ戻ろう。

APIゲートウェイはマイクロサービスへの出入り口となる役割でさ、全リクエストについてちゃんと検証・ルーティング・監視まで対応できる頼れる存在になる（理論上だけど）。ただし、この構造を素早く、それになおかつ軽量＆信頼性高く作らなくちゃならなくて…そこが最大の難題だった気がする。そしてそこで登場するのがGo言語だった。

## なぜGoなのか？この用途に適した理由
今回このプロジェクトでは主に3つ理由――いや、本当はもうちょっと複雑だけど大筋では「**速度**」「**シンプルさ**」「**信頼性**」を重視してGo言語を選択した、と言えるかな。まあ他にも細々思うことはいろいろあるにはある。ただ少なくとも、この三点については現場的にも納得感強かったように思うよ（実際どうだったか…今さら誰にも聞き返せないけど）。

最初の一歩、net/httpサーバーが静かに始動

1. **スピード**：Goって、高速なパフォーマンスで有名なんだよね。いや、ほんと、ちょっと面倒だけどコンパイル型で、しかもあの効率的な並行処理モデル（ゴルーチン）もあるし……あ、話が逸れた。でも高スループットのAPIリクエストをさばく場面にはやっぱり適しているらしい。ゲートウェイの現場では毎秒数千件ものリクエストを捌かなきゃいけなくて、「これ大丈夫なの？」って正直不安にもなるけど……まあ、とにかくGoの`net/http`パッケージはこの用途にはぴったりだったんだろうな。ふう。

2. **シンプルさ**：Goはそのミニマルな設計思想のおかげで、多くの場合は複雑怪奇なフレームワークとか多層ボイラープレートみたいなのを持ち出さなくても十分機能的なゲートウェイが構築できるって言われてる。うーん、それにしても少人数チーム＋タイトな締切（一つの週末！）。普通なら「絶対無理」と思っちゃう。でも短時間で全体像が掴みやすい言語が必要だったからこそGoに頼った、そんな感じかもしれない。ま、いいか。

3. **信頼性**：それからGoには強い型付けや組み込みテストツール、それにランタイム依存性が少ないという安心感もある。不意打ちみたいなクラッシュへの恐怖も若干和らぐ…と思いたい。標準ライブラリ自体にも多機能性があって、「外部パッケージなしでも堅牢サーバー作れる」という声を聞いたことがある。土曜日の朝になった時点でもう開発開始できてたんだから、その辺りにも理由が隠れてそうだよね。えっと、とりあえずそれだけ伝えておこうかな…。

URLプレフィックスだけで分岐するシンプルなルーティング表

## APIゲートウェイの構築：週末スプリント

何だったかな、目標。ああ、そうだ――APIゲートウェイを作ること、それだけは明白だった気がする。でも途中でコーヒーこぼしたりして、まぁ細かいことは後回し。うーん、とにかく以下を実現したかったんだよね：

- 受信リクエストのルーティングをマイクロサービスへ委ねる。

- JWTトークンで認証。これ絶対必要、セキュリティ的にも。

- あとね、ログ記録もやっとかないと…いや、ほんとは面倒なんだけど仕方ない。

- レートリミティングってやつ？アクセス集中とか防ぎたくてさ、まぁ念のため。

- 将来的にはメトリクス取得とかキャッシュ導入とか…できたらいいなと思ったりして。

……ま、とにかくここでは手順っぽいものを書いてみる。

## ステップ1：`net/http` を使ったサーバーセットアップ

Go の `net/http` パッケージって意外と万能（という噂）、高パフォーマンスなHTTPサーバー構築にも使えるらしい。最初は8080番ポートで待ち受ける、ごくシンプルなサーバーを書いた。えっと、そのコードはこんな感じ：

package main

import (

    "log"

    "net/http"

)

func main() {

    mux := http.NewServeMux()

    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {

        w.Write([]byte("API Gateway is live!"))

    })

    log.Fatal(http.ListenAndServe(":8080", mux))

}

ここで一息ついた。「Hello World」ってこういう瞬間なのかなぁと思いつつも、本当にこれだけで動くから不思議だよね。うーん……ちょっと感心しちゃった。でも話が逸れた。この時点で `http.ServeMux` がルーティングの基盤になっていて、この上に色々積めそうだな～という感じ。

## ステップ2：リクエストのルーティング

さて本題戻ろう。ゲートウェイの本質的な役割、それはURLパスごとに適切なマイクロサービスへリクエストを転送すること――まあ当たり前と言えば当たり前。でも実際やるとなると地味に大変なんだよねぇ…。

JWT認証をまとめて握るゲートウェイの真価は？

たとえば…うーん、まあ想像してみてほしいんだけど、`/auth/*` ってリクエストが飛んできたとする。そりゃ普通は認証サービスに投げたいよね？でさ、`/payments/*` の場合は決済サービス行きになるし、ああ…そうだ、`/analytics/*` は当然ながら分析サービスへ。要するに…いや違った、ごめんついまとめたくなってしまうけど、それぞれのパスごとに別々のサービスへ転送する必要があるわけ。でも何か急にお腹すいてきたな…。さて、本筋戻ろう。自分はマップ構造体とカスタムハンドラをこちょこちょ作りながら、やや乱雑だけど素朴なルーティングテーブルを仕立て上げてみた。

go

type Route struct {

    TargetURL string

}

css

var routes = map[string]Route{

    "/auth/":     {TargetURL: "http://auth-service:8081"},

    "/payments/": {TargetURL: "http://payment-service:8082"},

    "/analytics/": {TargetURL: "http://analytics-service:8083"},

}

css

func routeHandler(w http.ResponseWriter, r *http.Request) {

    for prefix, route := range routes {

        if strings.HasPrefix(r.URL.Path, prefix) {

            proxyRequest(w, r, route.TargetURL)

            return

        }

    }

    http.Error(w, "Not Found", http.StatusNotFound)

}

それで、この `proxyRequest` 関数――これがまぁ地味なんだけど妙に頼れる奴でさ。Go の `httputil.ReverseProxy` を使ってるから、ターゲット側サービスへちゃんとリクエストを横流しできる仕組みになったというか…。えっと、ヘッダーとかレスポンスのストリーミングも、そのまま維持される。この辺、一度手作業で書いたことある人なら「ありがたい」としか言いようがない微妙な面倒臭さが解消されてる感覚……いやでも実際そこまで難しくない、とも思えてくる不思議。

func proxyRequest(w http.ResponseWriter, r *http.Request, targetURL string) {

    target, _ := url.Parse(targetURL)

    proxy := httputil.NewSingleHostReverseProxy(target)

    proxy.ServeHTTP(w, r)

}

土曜日の午後には、とりあえず動くルーティングレイヤーっぽいものが出来上がっていた。それなのにソファでダラダラしながら、「本当にこれ大丈夫かな」なんてぼんやり考えてばかりだったけど…。例えば `/auth/login` や `/payments/process` 宛のリクエストを適当に叩いてみたら（半分寝ぼけつつ）、ちゃんとそれぞれ然るべきサービスまで辿り着く様子を確認できたりした。一瞬「新鮮だし、これは意外と面白いかも？」などと思わなくもない——いやでも油断するとすぐ飽きそうだとも感じたり。

## ステップ3：認証機能の追加

認証……これについて語ろうとすると気持ち少し重くなるなぁ。重要なのはもう分かっているんだけど、多くの場合 `Authorization` ヘッダー内に有効なJWTトークンを保持している必要があり、この検証処理をゲートウェイ側ひとまとめに任せれば各マイクロサービス側では同じコードを書かずにも済む（と思いたい）。えっと話逸れるけれど、この手法自体完璧じゃないとは思いつつ、一応 JWT の解析・検証には `github.com/golang-jwt/jwt/v4` パッケージを使ったので、その点は抜かりなし……多分、大丈夫だと思いたいところ。

ログもレートリミットも追加してみた日曜午後の現場感

以下は簡略化したミドルウェアのバージョンなんだけど、まあ、本当はもっと複雑なコードを書くべき時もある。でも今日はこれでいいや。

go

func authMiddleware(next http.HandlerFunc) http.HandlerFunc {

    return func(w http.ResponseWriter, r *http.Request) {

        authHeader := r.Header.Get("Authorization")

        if authHeader == "" {

            http.Error(w, "Missing Authorization header", http.StatusUnauthorized)

            return

        }

css

tokenString := strings.TrimPrefix(authHeader, "Bearer ")

        token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {

            return []byte("your-secret-key"), nil // 本番用のシークレットに置き換えてください

        })

css

if err != nil || !token.Valid {

            http.Error(w, "Invalid token", http.StatusUnauthorized)

            return

        }

next(w, r)
}
}

このミドルウェアで保護されたルートに`routeHandler`をラップしました。ふと、どうでもいいことを思い出したけど…ああ、やっぱり続きを書くね。

mux.HandleFunc("/payments/", authMiddleware(routeHandler))

mux.HandleFunc("/analytics/", authMiddleware(routeHandler))

こうして、`/payments/*`や`/analytics/*`へのリクエストには有効なJWTが必須となった。認証なしでは401で弾かれるわけだ。土曜の夜までには、それなりに認証もスムーズに動いていた気がする…いや、ちょっと心配だったけど特に大問題は起きなかった。

## ステップ4：ロギングとレートリミット

ゲートウェイを本番運用仕様へ近づけるために、リクエストロギングとレートリミット機能も追加。実は途中でコーヒーこぼしたんだよね…。でも、とりあえず続行するしかない。

各リクエストについてメソッド・パス・レスポンスタイムを記録するための、ごく単純なロギング用ミドルウェアを書いた：

scss

func loggingMiddleware(next http.HandlerFunc) http.HandlerFunc {

    return func(w http.ResponseWriter, r *http.Request) {

        start := time.Now()

        next(w, r)

        log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))

    }

}

レート制限についてはと言えば、「golang.org/x/time/rate」パッケージを利用してみたんだけどさ――これ意外と便利だと思う。IPごとに回数制御できるし悪用対策にもなるし。ただ、この辺もう少し考えたほうが良かったかな…ま、とりあえず以下。

go

func rateLimitMiddleware(next http.HandlerFunc) http.HandlerFunc {

    limiter := rate.NewLimiter(10, 100) // 1秒あたり10回まで、バースト100件まで許可

    return func(w http.ResponseWriter, r *http.Request) {

        if !limiter.Allow() {

            http.Error(w, "Too Many Requests", http.StatusTooManyRequests)

            return

        }

        next(w, r)

    }

}

この二つのミドルウェア、一応こんな感じでチェーンして使っている：

mux.HandleFunc("/", loggingMiddleware(rateLimitMiddleware(routeHandler)))

日曜日夕方までには、このゲートウェイが一通り完成してて――そういえば、その日は雨だったっけ？いや別にどうでもいいか。本筋戻すと、小規模Kubernetesクラスタへデプロイ完了＆DNS切替済みという流れだった。

## なぜうまくいったか：安定稼働から得た教訓

3年後もその週末プロジェクトは現役なんだよ。不思議だね…。理由としてまず浮かぶのは下記かな（本当は他にも色々ありそうだけど）。

Go言語自体が簡素だから保守性高め。全体でも500行未満っていう小ぢんまり感なのが逆によかった気もするし、新しいチームメンバーでもサッと理解できる程度。それから後になってメトリクスとかキャッシュ足す時も特段詰まらなかった。ふーん、自分でもちょっと驚いたよ…。

いつしか完璧に動き続けるものになっていた奇跡と分析

【並行処理がスケーラビリティに寄与】
Goのゴルーチンって、なんか気づいたら数千件もの同時リクエストを平然とさばいていた。まあ、別に魔法でもないはずだし…うん。トラフィックが急激に増えた瞬間も、ゲートウェイのCPUやメモリ使用量にはほぼ動きがなかった。あれ？ほんとに大丈夫なのか疑ったけど、実際変化は見受けられなくて、妙に拍子抜けしたくらい。

3. 【標準ライブラリによる機能実現】
`net/http`とか`httputil`だけ使っているおかげで、外部パッケージ由来のバグとか脆弱性の心配があまりなかったんだよね。これって意外と大事だったりする。標準ライブラリの堅牢さ――という表現も少し仰々しい気はするけど、今までゲートウェイで深刻な障害が起きていないことにも関係していると思う。まあ、不安ゼロではない…けど今のところ平和。

4. 【ミドルウェアによる拡張性確保】
Go独特のハンドラー連結から発想したミドルウェアパターンを導入したことで、本体となるルーティングロジックそのままにログ記録やレート制限みたいな追加機能を後から柔軟に組み込めた。この柔らかさ…ちょっと羨ましいぐらい。他方で、「本当にこれで良いんだっけ？」と途中で手が止まったことも正直何度かある。でも結局、本筋には戻れるから不思議。

5. 【テストによる信頼性向上】
本番投入前には必ずと言っていいほどGo の `testing` パッケージで認証やルーティングロジックについてユニットテストを書いた。不正形式JWTみたいなイレギュラーケースも、この一手間でちゃんと検知できた（いや、一度寝落ちしかけてテスト漏れて焦ったことある）。それでも一定以上はコードへの信頼感につながったと思う。ふう…。

## Goサービス構築時に役立つヒント

もし自分自身でGoベースAPIゲートウェイとかサービス構築やろうとしているなら――ああ、こういう話、自分語りっぽくなるからちょっと恥ずかしいけど――経験則からこんなポイントも参考になる気がする：

1. 【標準ライブラリ活用推奨】
Go の標準ライブラリ、多くの場合かなり高性能だし汎用性も十分あるので案外なんでも対応できたりするんですよね。ただ万能じゃない部分も無視できない、と言いつつ、それでも最初はここから始めるべきかな、と私は思う。えっと、要するに悩む時間より動かす時間優先って感じ？ま、そのへん人それぞれだけど。

Goなら標準ライブラリだけでも十分やれた話とかテスト話とか

1. えっと、サードパーティのパッケージって便利そうに見えるけど、実際には`net/http`やら`encoding/json`みたいな標準の道具だけでやれることもあるんだよね。うーん…なんとなく新しいものをすぐ入れたくなる気持ちも分かるけど、一度立ち止まって「それ、本当に必要？」って自問自答したほうがいいかもしれない。ま、つい勢いで追加して後悔することも多いし。でもまあ、標準機能でも結構何とかなるケースが意外と多かったりするんだ。

2. ミドルウェアはクロスカットな関心事に役立つ…ああ、「クロスカット」って言葉自体ちょっと曖昧に感じるときがあるけど、とにかく認証とかロギングとかレート制限ね、それらをミドルウェア化すると本来書きたかったロジックがちゃんと整理される場合、多いと思う。途中で「あれ？これもミドルウェアかな…」なんて迷ったりもしちゃうんだけど、少なくとも新しい機能の追加・修正時には柔軟性が出たりするから捨て難い選択肢だろうな、と今は考えている。不思議な話だけど、本筋戻すと使わない手はないかな、と。

3. 並行処理ならゴルーチン一択みたいな雰囲気あるけど、本当にそればっかりでいいのかな……とは思いつつ、Goの並行性モデルのお陰でログ記録だったりメトリクス収集だったりを本流のリクエスト処理から切り離せる場面、確かにあるよね。ただ全部非同期化すればいいという話じゃなくて（ここ何となく罠ぽさ）、ブロックしないよう工夫できる余地もまだ残されているという感じ。まあ、そのへん曖昧になることも多々…。

4. テストは早め＆頻繁になんて言われてもピンとこない日もある。でもGo の `testing` パッケージさえあればユニットテストを書く環境自体はもう十分整っていて、ハンドラやミドルウェアのみならず予想外のシナリオにも対応できる仕組み作れるっぽいので、不具合を起こす前段階で検知できる可能性、高まると言いたいところ。本当によく忘れてしまうので、自分への戒めとして書いておこう…。

5. シンプルさ――いや本当に大事だと思う。不必要なのに複雑化してしまった例、今まで何度見たことか。「この設計要る？」と疑問符しか浮かばない夜、更け方まで頭抱えてた記憶あるし。まあ、人によって感覚違うとは思いつつ、大抵の場合シンプル路線を保ったほうがあとあと楽になる場面、多いらしいよ。ま、いいか。また複雑になりそうになったらこの一文思い出しておきたい。

難しいことしない方がいい、冗長防止Tipsバラバラと並べてみる

シンプルで特化したサービスって、まあ正直なところ保守が楽だし障害も起きにくいんだよね。そうは言いつつ、うーん…油断すると何か見落とす気がして不安になる。6. **すべてを監視すること**：初日からロギングとメトリクスを導入するのが肝要らしい。PrometheusやGrafanaみたいなツールは、たしかに障害になる前に問題を察知できる可能性があるけど、本当にそれだけで十分なのか…ああ、でも現実的にはそれくらいしか手段ないよな、と自分に言い聞かせてまた本題へ。

## 影響：チームの満足度向上と製品の改善

APIゲートウェイという存在は、技術面の課題だけじゃなく作業方法にも静かな波紋を広げた。フロントエンドチームは単一エンドポイントとの対話になったことで複雑さもバグも減ったという話。でも、それって本当に「減った」と言い切れるほど明確なんだろうか、とつい思ってしまう自分がいる。バックエンド側では繰り返し認証コードを書く煩わしさから解放されたので、新機能開発へより多く時間を割けるようになったらしい。そしてオンコール担当エンジニアも、「ちゃんと休める日が増えた」と呟いていたっけ。ただクライアントサイドでも変化あり——API応答時間は20%短縮され（中央集約型キャッシュのおかげ）、稼働率も99.99%に到達したとか。不意に数字を見ると夢でも見てるのかなと思う瞬間があるけれど、とりあえず良かったんじゃないかな…。

APIゲートウェイがくれた眠れる夜と新しい風景

ゲートウェイは、新しいサービスの展開を迅速化する役割も果たしていた。あ、でもちょっと話が逸れるけど、最近やたらとAPIまわりで疲れててね。でも戻るよ。本筋に。クライアント向けAPIには全く手を加えずに済んだから、ルーティングテーブルへ新サービスを滑り込ませることができた。それだけでだいぶ楽だった気がする。うーん、ま、いいか。

## 結論: Go を選択肢として検討する

週末にGoでAPIゲートウェイを構築した経験は──これ正直、思ったより濃い時間になったなあという印象しかない。眠かったしコーヒー切れて焦った瞬間もあったけど、それでもやっぱり有意義だった、と言えるかな。このプロセスで自分なりに感じたのは、「シンプルさ」って案外バカにできない強みなんじゃないかってこと。そして素早く繰り返す作業の妙な楽しさとか、結局どんな道具を選ぶかって大事なのでは？みたいな。まあ、そういう感想。

Go は処理速度とか信頼性、それから何となく漂う禁欲的な設計思想によって──厳しい納期のプロジェクトや求められる要件が高い場面にも実用性ある気がしてきた（あくまで自分調べ）。同じような問題……マイクロサービス間の複雑さだとか、新しいバックエンドサービス組み立てたりするとき……そういうときにはGoも候補になるんじゃないかと思う、いや本当に。事前準備と充分すぎるくらい集中できる時間、それだけ揃えば、多分長期間安定稼働してくれるものが作れる可能性だってあるよね。

> ところで、次回あなたが週末に挑戦してみたいプロジェクトって何？もしよかったらコメント欄で教えてほしいな、なんて思う今日この頃。