寄稿：SBI ネオバンキングシステムにおける Amazon EKS Auto Mode の導入事例 ― 移行で実現した運用負荷の軽減

本稿は、SBI ネオバンキングシステム株式会社による AWS EKS Auto Modeの活用について、主導されたSBI ネオバンキングシステム株式会社新藤様より寄稿いただきました。

はじめに

SBI ネオバンキングシステム株式会社（以下、弊社）は、地方銀行向けのインターネットバンキングサービスをマルチテナント型 SaaS として開発・運用しています。サービス基盤には Amazon Elastic Kubernetes Service（以下、Amazon EKS）を採用しており、従来は AWS Fargate（以下、Fargate）上でワークロードを実行していました。

本記事では、2024 年 12 月の AWS re:Invent で一般提供が開始された Amazon EKS Auto Mode（以下、EKS Auto Mode）を 2025 年 9 月に導入し、AWS Fargate からの移行によって実現した運用負荷の軽減効果についてご紹介します。

SBI ネオバンキングシステムについて

弊社は、地方銀行のお客様が残高照会や振込といった銀行取引をスマートフォンやブラウザから行えるインターネットバンキングサービスを開発・運用しています。マルチテナント型の SaaS として構築しており、2026 年 3 月時点で4行の地方銀行向けにサービスを提供しています。

提供先の銀行が増えるにつれ、リリース頻度や運用イベント（バージョンアップ、パッチ適用、監視対応など）も増加するため、少人数でも安定した運用を実現できるアーキテクチャが求められていました。

システムの規模としては、3 つのアベイラビリティゾーン（AZ）を活用し、東京リージョンをプライマリ、大阪リージョンを DR（災害対策）環境とするマルチリージョン構成を採用しています。本番環境に加えて 3 つの開発環境を運用しており、合計 8 クラスターを管理しています。本番環境のクラスターでは約 60 の Pod が稼働しています。

EKS Auto Mode 導入の背景

Fargate を中心とした従来の運用には、以下の 3 つの課題がありました。

課題 1: EKS バージョンアップの運用負荷

Amazon EKS のバージョンアップでは、コントロールプレーン、アドオン、データプレーンをそれぞれ更新する必要があります。弊社の環境では、東京リージョンでは Fargate、大阪リージョンでは当時の構成上マネージドノードグループを利用していたため、コントロールプレーンとアドオンに加えてマネージドノード側の更新も含めた複数箇所を手動で操作する必要がありました。アップデート中には他の本番適用作業を並行で進めますが、手動操作のために作業が中断されてしまうことがストレスに感じていました。また、金融サービスとして安全にアップデートを実施できる仕組みの確保も重要な要件でした。

課題 2: EKS アドオンの自前管理負荷

AWS Load Balancer Controller、CoreDNS、kube-proxy といったアドオンを自前で管理していました。Amazon EKS のバージョンアップのたびにアドオンの互換性を確認し、適切なバージョンを選定・更新する作業が発生していました。

課題 3: Fargate 固有の運用負荷

Fargate 環境では、以下の運用負荷が発生していました。

Datadog サイドカーコンテナの管理: Fargate では DaemonSet が利用できないため、各 Pod に Datadog Agent をサイドカーとして配置する必要があり、マニフェストの記述量が増加するだけでなく、サービスに直接関係しない Datadog Agent の記述が混在することでマニフェストの見通しが悪化
Fargate 組み込みログルーターの設定: Fargate の組み込みログルーター（Fluent Bit ベース）経由で Amazon CloudWatch Logs へ転送する構成のため、Pod ごとにロググループの管理が必要
イメージキャッシュが利用不可: Fargate ではコンテナイメージのキャッシュが効かず、Pod 起動のたびにイメージを Pull する必要があり、起動が遅延

これらの課題を踏まえ、AWS にインフラ管理をより広く委ねることで運用負荷を大幅に軽減することを目指し、EKS Auto Mode の導入を決定しました。

アーキテクチャ概要

本節では、EKS Auto Mode 導入に伴うアーキテクチャの変化を説明します。

図: 移行後のアーキテクチャ（EKS Auto Mode 構成）

EKS Auto Mode で変わったこと

コンピュート: Fargate から EC2（Auto Mode 管理）へ

EKS Auto Mode の導入により、データプレーンが Fargate から EKS Auto Mode が管理する Amazon EC2 インスタンスへ移行しました。ノードのプロビジョニング、スケーリング、パッチ適用は AWS が自動的に管理します。EKS Auto Mode はノードのプロビジョニングにオープンソースの Kubernetes ノードオートスケーラーである Karpenter を内部で利用しており、NodePool でインスタンスタイプや有効期限などのノード仕様を定義します。弊社の環境では、ビルトインの NodePool が提供するインスタンスタイプが要件に合わなかったため、カスタム NodePool を作成してインスタンスタイプを指定しています。ノードの更新サイクル（expireAfter）はデフォルトの 336h（14 日）です。また、EC2 ノードではコンテナイメージのキャッシュが有効になるため、Fargate で課題だった Pod 起動の遅延も改善します。

アドオン: 自前管理からビルトインへ

EKS Auto Mode では、CoreDNS、Amazon VPC CNI、Amazon EBS CSI driver が AMI に内蔵された systemd サービスとして提供され、AWS Load Balancer Controller や kube-proxy も AWS によって管理されます。これにより、アドオンのバージョン管理や Amazon EKS バージョンとの互換性確認から解放されました。

バージョンアップ: 複数箇所の手動操作からワンクリックへ

従来はコントロールプレーン、アドオン、マネージドノードの各箇所を個別に操作する必要がありました。安全なアップデートの実現手段として、ブルー/グリーンデプロイメントによるクラスター切り替えも検討しましたが、2 つのクラスターの並行運用やエンドポイント切り替えに伴う運用負荷の増加に対し、EKS Auto Mode が提供するコントロールプレーンの自動ロールバックとノードの自動更新により、インプレースでも十分な安全性を確保できると判断しました。コンソールでのワンクリックで開始した後は自動で進行し、おおむね 30 分で完了します。コントロールプレーンのアップデートに失敗した場合は自動でロールバックされ、ノードも自動で更新されます。失敗時は旧ノードが継続稼働するため、サービスへの影響を最小限に抑えられます。

監視: Datadog サイドカーから DaemonSet Agent へ

Fargate では各 Pod にサイドカーとして Datadog Agent を配置していましたが、EC2 ノード上では DaemonSet として Datadog Agent を配置し、ノードの IP アドレス（hostIP）経由で各 Pod と通信する構成に変更しました。これにより、Fargate の組み込みログルーターも不要になりました。

同時に行ったアーキテクチャ改善

EKS Auto Mode への移行にあたっては新規クラスターを作成し、旧クラスターからブルー/グリーン方式で切り替えました。日常のバージョンアップとは異なり、Fargate からの移行に加えて NLB から ALB への集約なども含む大規模な構成変更であったため、移行時に限りブルー/グリーン方式を採用しています。従来の構成には NLB ではゼロダウンタイムのローリングアップデートが実現できない点や、Amazon API Gateway に AWS Shield Advanced を適用できず DDoS 自動緩和機能が利用できない点といった課題があったため、クラスターを新規に構築するこのタイミングに合わせて、以下のアーキテクチャ改善も実施しました。

NLB から ALB への集約

従来は Amazon API Gateway と Network Load Balancer（NLB）をテナント数分用意する構成でしたが、Application Load Balancer（ALB）1 台に集約しました。Kubernetes の Ingress リソースと ALB のグルーピング機能を活用し、1 つの ALB に複数テナントを収容しています。これにより、AWS WAF の一元管理と AWS Shield Advanced による DDoS 自動緩和の適用も可能になりました。

IaC 管理の改善

ExternalDNS をマニフェスト管理から Terraform の Helm 管理へ移行し、Datadog Agent も同様に Terraform の Helm 管理に統合しました。変更内容の見通しと再現性が向上しています。

Before / After 比較

項目	Before(Fargate)	After(Auto Mode)
コンピュート	AWS Fargate(東京)/ マネージドノード(大阪)	EKS Auto Mode(EC2)
ノード管理	不要(Fargate)/ マネージドノード(大阪)	AWS 自動管理(パッチ適用・スケーリング)
アドオン管理	自前管理(AWS Load Balancer Controller、CoreDNS 等)	AWS 管理(AMI 内蔵 systemd)
バージョンアップ	複数箇所の手動操作	ワンクリックで開始 → 約 30 分で自動完了
監視エージェント	Datadog サイドカー(各 Pod)	Datadog Agent DaemonSet
ログ転送	Fargate 組み込みログルーター → CloudWatch	Datadog Agent 直接転送
LB 構成	API Gateway + NLB × テナント数	ALB × 1

導入時に直面した課題と解決策

EKS Auto Mode の導入にあたり、いくつかの課題に直面しました。以下に事象、原因、対処をまとめます。

1. セキュリティグループの追加設定

事象: Fargate から EC2 ノードへの移行に伴い、ネットワーク通信の設定変更が必要でした。

原因: Fargate では各 Pod に専用の ENI（Elastic Network Interface）が割り当てられるため、弊社の構成ではセキュリティグループの明示的な設定は不要でした。EC2 ノードでは複数の Pod が同一ノードの ENI を共有するため、ノードレベルでの通信許可が必要になります。

対処: EC2 ノードのセキュリティグループに以下の許可ルールを追加しました。

データベースへの接続許可
ノード間の Pod 通信の許可

2. ASCP の Pod Identity タイムアウト

事象: AWS Secrets Manager のシークレットを Kubernetes の Secret として Pod に注入する ASCP（AWS Secrets and Configuration Provider）で、EKS Pod Identity を使用した際に認証がタイムアウトする問題が発生しました。

原因: EKS Pod Identity のタイムアウト値（100ms）が短すぎるという既知の問題でした。

対処: Pod に AWS IAM の権限を付与するもう 1 つの方式である IAM Roles for Service Accounts（IRSA）に切り替えることで回避しました。

3. ALB サブネットの自動検出

事象: EKS Auto Mode の AWS Load Balancer Controller がサブネットを自動検出できず、ALB の作成に失敗しました。

原因: VPC サブネットに EKS クラスター識別用のタグが設定されていませんでした。

対処: サブネットに必要なタグを追加することで、自動検出が正常に動作するようになりました。

導入効果

運用負荷の大幅な軽減

EKS Auto Mode 導入による最大の効果は、運用負荷の大幅な軽減です。構成のシンプル化と合わせ、体感としては 50 ％程度の負荷軽減を実現できたと感じています。

EKS バージョンアップの簡素化: 以前はクラスター、アドオン、マネージドノードを含む複数箇所の操作が必要でしたが、ワンクリックで開始した後は約 30 分で自動完了するようになりました。本記事の執筆にあたり実際にバージョンアップを実施しましたが、アップデート中に何度も戻る必要がないので他の本番適用作業を中断されることなく、集中して進められました。

EKS アドオンの管理不要: AWS Load Balancer Controller、CoreDNS、kube-proxy 等が AWS 管理となり、バージョン管理や互換性確認の作業から解放されました。

ノード管理不要: マネージドノードを運用していた大阪リージョンについては、パッチ適用やスケーリングが自動化され、ノードの運用管理が不要になりました。これは弊社固有の事情ですが、東京リージョンと大阪リージョンの構成が同じ EKS Auto Mode 構成になったことで、リージョンを問わず同一の運用手順で対応できるようになった点も嬉しいです。

構成のシンプル化

Datadog サイドカーの廃止: 各 Pod からサイドカーコンテナを削除し、DaemonSet に集約したことで、マニフェストの記述量が削減され、Pod 構成がシンプルになりました。

Fargate ログルーターの廃止: Fargate の組み込みログルーターと Pod ごとの CloudWatch ロググループが不要になり、ログ転送設定が簡略化されました。

Pod 起動の高速化

EC2 ノードのコンテナイメージのキャッシュを活用できるようになり、Pod の起動時間が短縮し、スケールアウト時の応答性向上にも寄与しています。

Pod 更新・ノードパッチ適用におけるゼロダウンタイムの実現

NLB から ALB への集約と合わせてローリングアップデート時のパラメータ調整（PreStop フック、登録解除遅延など）を実施し、ゼロダウンタイムでの Pod 更新を実現しました。また、ノードへの自動パッチ適用にあたってもエラーやレスポンスの遅延が発生することなく、安定して運用できています。

コスト削減（副次的な効果）

本取り組みの主目的は運用負荷の軽減でしたが、副次的な効果としてコスト最適化にも寄与しました。

課金単位が Pod 単位（Fargate）から EC2 インスタンス単位に変化し、ノードに複数 Pod を集約できるためリソース利用効率が向上
CloudWatch Logs への転送が不要になり、ログ関連コストが削減
NLB をテナント数分用意する構成から ALB 1 台への集約により、ロードバランサーのコストが削減

今後の展望

提供先の銀行が増加していく中で、マルチテナント基盤のさらなる拡充を進めていきます。EKS Auto Mode の機能拡張にも期待しており、AWS が提供するマネージドな領域が広がることで、弊社はアプリケーション開発とサービス品質の向上により集中できると考えています。

また、ローリングアップデートの安全性向上や、ノード・スケールの最適化（状況に応じたスポットインスタンスの活用検討を含む）にも継続して取り組んでいきます。

まとめ

AWS Fargate から EKS Auto Mode への移行により、少人数の体制でも、金融 SaaS としての厳格な要件を満たしながら運用負荷を大幅に軽減できました。

EKS Auto Mode は、Kubernetes のメリットを活かしつつ、クラスター運用に伴う作業負荷を AWS に委ねたい場合に有力な選択肢となります。同様の課題を抱える方々にとって、本記事が参考になれば幸いです。

著者について

新藤泰斗

SBI ネオバンキングシステム株式会社プラットフォーム・エンジニアリング部 SREグループ長

地方銀行向けインターネットバンキングサービスのインフラ基盤の設計・運用を担当し、Amazon EKS を中心としたマルチテナント基盤の信頼性と運用効率の向上に取り組んでいる。

Amazon Web Services ブログ