この記事はkintoneの生成AIチームで連載中のkintone AIリレーブログ2026の2本目の記事です。 リレーブログでは、生成AIチームのメンバーがAIトピックに限らずさまざまなことについて発信していきます。
こんにちは！ kintoneの生成AIチームでバックエンドの開発・運用を担当している 齋藤 ( K.Saito (@SightSeekerTw) / X ) です。
以前、kintone AI ラボ のバックエンドを OpenTelemetry と AWS CloudWatch Application Signals で可観測性を向上させた話 という記事で kintone の AI 機能を実現しているアーキテクチャについて簡単に紹介しました。
この記事の中ではアプリケーション部分は AWS の Lambda 関数としてデプロイして運用していたのですが、この度 Kubernetes (Amazon EKS) の基盤を構築し、こちらに移行する運びとなったことをご報告いたします。
ここでは、どういった経緯、モチベーションで Kubernetes に移行することになったのかを紹介したいと思います。
なぜ Lambda から EKS へ ?
Lambda 運用で感じていた課題
CloudFront + Lambda Function URL の構成管理の複雑さ
CloudFront + Lambda Function URL の構成を採用していましたが、AWS CDK での管理が煩雑でした。
CloudFront はグローバルリソースのため北部バージニアリージョン (us-east-1) に、Lambda 関数は東京リージョン (ap-northeast-1) にデプロイする必要があり、リージョンをまたいだ値の受け渡しで整合性が崩れると、デプロイや削除が失敗することがありました。
ペイロードサイズ制限によるワークアラウンド
Lambda には同期呼び出しで 6MB、非同期呼び出しで 256 KB というペイロード制限がありました (現在は 1 MB まで緩和)。 LLM のコンテキストサイズが拡大していく中で、この制限を回避するために Valkey を経由させるなどのワークアラウンドが必要でした。
OpenTelemetry との相性
前回の記事で紹介した OpenTelemetry ですが、 Lambda 環境では制約が多くありました。
Lambda 用の Layer を追加し、関数の実行中にスパンを完了させる必要があるため、同期的な送信によるレスポンスタイムの悪化が発生したりしていました。
最終的な対策としては非同期で送信させられるような仕組みを入れることでパフォーマンスの問題は解決させられたのですが、一方で、関数の実行中にしかスパンが送信されないという制約から、長い間スパンが送信されないといった事象もあり一つのトレースを構成するスパンが完成するのには大きな遅延がありました。
EKS 移行で期待すること
Kubernetes マニフェストによる宣言的な構成管理
Ingress を含むすべてのリソースを Kubernetes マニフェストで管理することで、 Desired State による構成管理が可能になります。クロスリージョンの煩雑さから解放され、デプロイ・変更・削除が容易になります。
制限からの解放とアーキテクチャの柔軟性
ペイロードサイズの制限がなくなり、ワークアラウンド無しで LLM の大きなコンテキストを扱えるようになります。
OpenTelemetry Collector についても独立して運用できるため、アプリケーションコンテナを軽量化することができ、スパンも非同期で、バッチ方式でいくつかのスパンをまとめて送信することができるようになります。何より、 Lambda で動作させるためのワークアラウンドが不要になります。
開発のアジリティ向上
kintoneのAI機能開発をスケールさせるためのチーム戦略 で紹介したように、私たちのチームは「AI機能開発をスケールアウトさせるプラットフォームチーム」として、他のチームが AI 機能を開発しやすい基盤を整える役割を担っています。
その中長期的な取り組みの一つが、今回の EKS への移行を含む「インフラの刷新」です。
今後は現行のアプリケーションだけでなく、 基盤として必要なツールの整備や AI Agent を小さく作ってデプロイしていくことも見据えています。
AI Agent を実装するためのフレームワークは変化が激しく、一つのフレームワーク、一つのモノリシックなアプリケーションとして構成するのではなく、小さな単位でその時々に最適なフレームワークを選択してデプロイできる環境が望ましいと考えました。
Lambda などのサーバーレス環境では制約が多く、構成管理にも AWS に精通した人材が必要となるため、こうした柔軟なデプロイを実現するにはアジリティが十分に出ないと判断しました。
Kubernetes であれば、弊社のコアプロダクトである kintone の国内・グローバル向け環境でも採用されており、社内にナレッジと人材が豊富にあります。
グローバル向けの kintone のバックエンドでは EKS を基盤として採用しており、私もその基盤の運用をしばらく行っていた経験もあります。
この強みを活かすことで、チームメンバーが素早くアプリケーションを開発・デプロイできる環境を整えられると考えました。
移行の決め手
EKS の採用には、当然以下のようなデメリットもあります。
| 観点 | Lambda | EKS |
|---|---|---|
| 稼働コスト | 使用分のみ | クラスタ常時稼働 |
| 運用工数 | ほぼ不要 | アップグレード・アドオン管理が発生 |
なぜ許容できると判断したか
EKS Auto Mode による運用負荷の軽減
2024年末に登場した EKS Auto Mode が判断を後押ししました。kube-proxy、CoreDNS といった基本コンポーネントに加え、Karpenter、AWS Load Balancer Controller、VPC CNI など、従来は自前で管理が必要だったアドオンが AWS マネージドで提供されます。これにより、EKS 運用の大きな負担だったアドオン管理の大部分が不要になりました。
稼働コストの最適化：今後の展望
稼働コストについても、将来的には HPA (Horizontal Pod Autoscaler) も Auto Mode にビルトインされている Karpenter と組み合わせることによって、ノード数やインスタンスサイズを利用状況に応じてダイナミックに調整することで、最適化を図る予定です。
得られる価値がコストを上回る
Lambda の制約によるワークアラウンドからの解放、社内に蓄積された Kubernetes ナレッジの活用、そして AI Agent 開発を見据えた柔軟性など、これらの価値は、コストや運用工数の増加を十分に上回ると判断しました。
おわりに
今回は kintone AI のバックエンドを Lambda から EKS へ移行した背景についてご紹介しました。
kintoneのAI機能開発をスケールさせるためのチーム戦略 でも紹介しているように、私たちのチームは AI 機能を直接開発するだけでなく、他のチームが AI 機能を開発しやすい基盤を整える役割も担っています。
今回構築した EKS 基盤は、まさにその取組の一つです。社内で広く使われている Kubernetes の知見を活かし、変化の激しい AI 技術に柔軟に対応しながら、チームを超えて AI 機能の開発をスケールさせていければと考えています。
We are hiring !!
kintone の AI 機能を支える基盤を一緒に作りませんか？
私たちのチームでは、 AWS CDK による Infrastructure as Code、 Kubernetes (EKS) 上でのアプリケーション運用、そして日々進化する AI 技術を組み合わせながら、 kintone に新しい価値を届ける挑戦をしています。
- クラウドインフラと Kubernetes で AI ワークロードを支える基盤づくりに興味がある方
- 変化の激しい AI 技術領域で、柔軟にアーキテクチャを設計・改善していきたい方
- チームの枠を超えて、プラットフォームとして他の開発者を支えることにやりがいを感じる方
そんな方のご応募をお待ちしています！
【変更履歴】 2022年2月9日 記事プレビューのURLが設定されていた箇所を、公開ページのURLに修正しました。
