AIにコードを直させたのに、体感速度は変わらなかった
「チェックアウトが遅い」というクレームを受けて、開発者がAIコーディング支援に最適化を依頼する。数秒でコードは書き換わり、レビューも通り、本番にデプロイされる。ところが、ユーザーの体感速度はほとんど変わらない。
こうした事象は、Kubernetesでマイクロサービスを運用している現場で珍しくない。原因はコードの書き方ではなく、Kubernetesマイクロサービスのレイテンシを生む構造そのものにあることが多いからだ。Kubernetesの公式ドキュメントが説明するように、Serviceは複数のPodをネットワーク越しに束ねる抽象化であり、1つのユーザー操作の裏側で複数のServiceへ処理が連鎖していく構成そのものは、K8sの標準的な設計パターンだ。だからこそ、AIがどれだけコードを速く書けても、サービス間の呼び出し構造というアーキテクチャ上の問題までは解決してくれない。
犯人は「1リクエスト5回のサービス呼び出し」だった
典型的なEC注文処理を分解すると、フロントエンドからのリクエスト1つに対して、バックエンドでは決済の検証、ユーザー情報の照会、在庫の確認、配送情報の照会、注文レコードの更新という具合に、複数のサービスへの呼び出しが連鎖することがある。1回の注文につき5回前後の個別サービス呼び出しが発生するケースも珍しくない。
これは、データベースのクエリ設計における「N+1問題」と本質的に同じ構造だ。N+1問題では1件のリストを取得するたびに関連データを1件ずつ追加で問い合わせてしまい、リクエスト数が線形に増えていく。Kubernetes上のマイクロサービスでも同様に、1つのユーザー操作が複数のマイクロサービスへの同期呼び出しへと連鎖していく「分散版のN+1問題」が起こりうる。Atlassianのマイクロサービス解説でも述べられている通り、マイクロサービスは本質的に分散システムであり、サービスを細かく分割するほど、サービス間通信の設計そのものが性能上のボトルネックになりやすい。
日経クロステックの解説記事でも指摘されているように、マイクロサービスは分散システムであるがゆえに設計・開発・運用のいずれもが難易度が高く、サービスごとにデータベースが分かれることでデータ整合性の担保も複雑になる。「まずマイクロサービスに分割する」ことが目的化してしまうと、こうしたチャッティな呼び出し構造を生みやすい。
Kubernetesクラスタの構成そのものはPodやServiceの単位で見えていても、リクエスト1件がどのサービスをどの順番で経由しているかは、ダッシュボード上では意外と見えにくい。Kubo の Captain UI のように、クラスタの状態を可視化する管理画面があると、こうした呼び出しの連鎖に気づくきっかけを作りやすくなる。
サービスメッシュのサイドカーが「かくれ税金」を取っている
サービス間通信を安全かつ可観測にするために導入されるサービスメッシュも、レイテンシの観点では見落とされがちなコストを持つ。Istio や Linkerd のようなサービスメッシュでは、各Podに Envoy のようなプロキシがサイドカーとして配置され、すべての通信がこのサイドカーを経由する。Envoy はアプリケーションサーバーの隣で動作し、透過的な通信メッシュを形成することでネットワークトポロジーをアプリケーション側から隠蔽する設計になっている。
Istio公式ドキュメントのパフォーマンスガイドでも、サイドカープロキシがデータパス上に追加される以上、レイテンシは重要な検討事項だと明記されている。1ホップあたりの遅延は小さくても、5つのサービスを連鎖的に呼び出す構成では、その遅延が積み重なって無視できない規模になる。
CNCFのブログが指摘するように、マイクロサービスの数が増えるほどサービス間通信の複雑さは増し、トラフィック管理・セキュリティ・可観測性を全サービスに一貫して適用すること自体が難しくなる。サービスメッシュはこの複雑さを解決する一方で、運用そのものに新たな学習コストという「税金」を課す。K3sベースで軽量に構成できるKuboであれば、モニタリングが標準搭載されているため、サービスメッシュを導入する前段階でもレイテンシの内訳を可視化しやすい。
コードを直す前に、呼び出しを「集約・キャッシュ・非同期化」する
チャッティな呼び出しに対しては、コードの書き方を変えるよりも先に、呼び出し構造そのものを見直すアプローチが効果的だ。代表的な手法は次の3つに整理できる。
1. BFF(Backends for Frontends)パターンで呼び出しを集約する
Sam Newmanが提唱するBFFパターンは、UIごとに専用のバックエンドを用意し、複数のマイクロサービスへの呼び出しをBFF側で集約する設計だ。サービスの数が少ないうちは効果が見えにくいが、呼び出すべき下流サービスの数が増えるほど、クライアント側での個別呼び出しをBFFに肩代わりさせるメリットは大きくなる。フロントエンドは1回のリクエストで済み、サービス間の連鎖はBFFの内部に閉じ込められる。
2. キャッシュ層で重複した呼び出しを減らす
在庫情報やユーザープロフィールのように更新頻度が低いデータは、リクエストのたびにDBへ問い合わせる必要はない。Redisをサービスメッシュのキャッシュ層として使う設計では、キャッシュにヒットする限り下流サービスへの呼び出し自体を発生させず、レイテンシとバックエンドの負荷を同時に減らせる。ダウンストリームのサービスが一時的に不調でも、キャッシュされたデータへのフォールバックによって全体の可用性を保てる点も利点だ。
3. 非同期化とサーキットブレーカーで連鎖を断ち切る
注文更新のように即時応答が必須ではない処理は、同期呼び出しからメッセージキュー経由の非同期処理に切り替えることで、リクエストの待ち時間から切り離せる。また、Resilience4jのサーキットブレーカー実装のように、一定割合の呼び出しが失敗・遅延した時点で回路を開き、下流サービスへの負荷そのものを遮断する仕組みを組み合わせると、1つのサービスの遅延が連鎖全体に波及するのを防げる。
こうした設計変更を実装する際、Kubo Cloud はGitOps対応でArgoCD/Fluxとの統合が標準化されているため、BFFやキャッシュ層の追加をHelmチャートとして宣言的に管理し、段階的にロールアウトしやすい。
まとめ ― AIが速くできるのは「コード」まで、「呼び出し設計」は人間の仕事
AIコーディング支援は今後さらに進化し、関数やクエリ単位の最適化は数秒でこなせるようになっていくだろう。しかし、いくつのサービスに分割するか、どの呼び出しを同期にし、どこをキャッシュや非同期に切り出すかというアーキテクチャ上の意思決定は、依然としてエンジニア自身が下す仕事だ。
Kubernetesマイクロサービスのレイテンシ問題の多くは、コードのバグではなく、こうした呼び出し構造の設計に起因する。まずは自分たちのシステムで「1つのリクエストが裏側で何回サービスを叩いているか」を可視化するところから始めたい。Kubo はPrometheus + Grafanaが標準搭載されたK3sベースのマネージドKubernetesとして、こうした呼び出し構造の可視化とHelm/GitOpsによる段階的な改善の両方を、EKSやAKSより低コストで実践できる基盤になる。アーキテクチャ設計そのものに集中したいなら、お問い合わせから相談してみてほしい。