DBRE (DataBase Reliability Engineering)チームの taka-h です。 2025年10月のTiDB User Dayにおいて、 オートスケールについて取組み中(P. 81)であることをご紹介 しました。この記事では、その後のオートスケールの取り組み状況についてお伝えします。 結論としては、2025年11月時点で、DBREが管理するTiDB移行済みの全クラスタでTiDBの水平方向オートスケール導入が完了し、その後も安定稼働しています。 次の画像は、メルカリ内のとあるCluster(l1-2)で、オートスケールがCPU利用率の平均値を60パーセント前後に保つように動作している様子を示したものです。 なお、TiDB Cloudにはいくつかの製品ラインアップがありますが、本記事での以後のTiDB Cloudという言葉は、いわゆるサーバーレスではない「TiDB Cloud Dedicated」を指すものとします。 背景：なぜTiDB Cloudでオートスケールが必要だったか メルカリでは、最初にTiDBのオートスケールの実装をすることを決め、初期の実装ターゲットをTiDBに絞ってオートスケールの導入を進めました。 まずはこの経緯を簡単に説明します。 実装決定に至った経緯 最初に既存のライブラリの実装状況を調査しました。 TiDBをKubernetes上でホスティングするためのライブラリとしては、 tidb-operator があります。このライブラリでオートスケールが実装されていれば、我々が利用しているTiDBのマネージドサービスであるTiDB Cloudでもオートスケールが近々実現されることが想定されます。 オートスケール導入を検討した当時は、次の状況でした。 当初実装されていたオートスケールの機能が削除されていた TiDB Cloudの開発ロードマップにオートスケールの機能が入っていない （最新の tidb-operator v2ではCRDのsub resourcesに対応 しています） また、TiDB Cloudは自動での水平/垂直のオートスケールの機能が提供されていない一方で、スケール変更についてAPIが提供されています。 https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster/operation/UpdateCluster APIがあれば、オートスケールは実現のための必要条件を満たすので、まずはオートスケールの実現のため実装を進めることとしました。 実装対象の選定 オートスケールの実装を決めた後、最初にオートスケール化の対象を決める必要があります。 メルカリにおけるTiDB Cloudのコストの構成としては、オートスケール導入前の時点で、大雑把にTiKVが6割程度、TiDBが2割程度でありました。TiKVが実データを持つのに対し、TiDBはステートレスでオートスケールに対する考慮事項が少なく、比較的容易に実現できますので、まずは実装対象をTiDBとし、要件を定義の上実装することにしました。 https://docs.pingcap.com/tidb/stable/tidb-architecture/ 方針1：Kubernetes HPA活用, しかしマネージドサービス特有の壁があった (オートスケール v1) 実装範囲を決めた後、最初はKubernetes HPA(Horizontal Pod Autoscaler)を活用して実装する方針としました。ここではその最初の方針決定の経緯、そして方針変更に至った経緯を順に説明します。 要件を定義の上LLMで実装する予定でしたので、フルカスタム実装でもよかったのですが、主に、社内で Elasticsearchのオートスケールが実現されていた ため、これと同様にKubernetesのNativeのオートスケールの機能の活用して実現することに決定しました。 具体的には、実績があり安心できるという理由の他には、Kubernetes Nativeのオートスケールを利用すると、次の利点がありました。 考慮すべき様々な一般的な考慮事項が既に満たされており、これを活用することでその実装が不要になり、開発すべき機能のスコープが絞られる 例) スラッシング回避、一度に増減できるノード数上限、など datadog経由のメトリクス連携を既存のオートスケールの機能でできる クレデンシャルのセットアップなども追加で不要 運用が他のKubenetesのものとそろう 既存のパターンとの違い: Podが管理するClusterに存在しない 既存のElasticsearchのオートスケールと今回のTiDB Cloudでは、前提条件が大きく異なります。既存のパターンは「自分たちが運用するKubernetesクラスタ上でPodが動いている」ことを前提に、HPAがPodのスケールを制御していました。 一方で、TiDB Cloudを利用する場合、実際のPodはTiDB Cloud上で動作しており、メルカリが管理するKubernetesクラスタ上には存在しません。このため、既存パターンと同様にHPAを適用しようとすると「スケール対象として参照できるPodがない」という問題に直面します。 そこで、TiDB Clusterを表すCustom Resourceを定義し、これをHPAのスケール対象として扱う方針で検討を進めました（次節で説明します）。 実際のPodがない対象へのHPA ここでやりたかったのは、TiDB CloudのTiDBノード数変更を、KubernetesのHPAの仕組みに乗せて自動化することです。そのために、TiDB Clusterを表すCustom Resourceを定義し、HPAがその replicas を増減できる構成を検討しました。 しかし、HPAがCustom Resourceをスケール対象として扱うには、 scale subresource （ /scale ）を提供する必要があり、あわせて labelSelectorPath の定義が求められます。 labelSelectorPath は、本来スケール対象に紐づくPod群を特定するための情報です。 https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource TiDB Cloudでは該当Podが自クラスタに存在しないため、この前提を満たせず、通常の形ではHPAが成立しませんでした。一方で、 External Metricsで AverageValue を使う場合に限り、結果的にselectorが評価に使われない挙動 があり、 labelSelectorPath をダミーにしても動作しました（ただし仕様保証がなく、運用上のリスクが残ります）。 https://docs.cloud.google.com/kubernetes-engine/docs/tutorials/autoscaling-metrics : autoscaling/v1beta1（旧形式） metrics: - type: External external: metricName: pubsub.googleapis.com|subscription|num_undelivered_messages metricSelector: matchLabels: resource.labels.subscription_id: my-subscription targetAverageValue: "2" : autoscaling/v2 (現行推奨) metrics: - type: External external: metric: name: pubsub.googleapis.com|subscription|num_undelivered_messages selector: matchLabels: resource.labels.subscription_id: my-subscription target: type: AverageValue averageValue: "2" 方針2: フルカスタムへ切り替え、運用可能な形へ収束 (オートスケール v2) ステージング環境までは、何とかこの実装で動作はしたのですが、External Metrics連携が想定通りに動作せず、次の理由からCustom Resourceを定義し、reconcileのループを回すところだけ残し、その他をフルカスタム実装に切り替えることにしました。 Native HPAの機能を活用している既存の実装は、現状利用している特定のパターンが将来的に利用できなくなる可能性が払拭できない デバッグが困難を極めた LLMでオートスケールのような「よくある」実装が非常に容易になっている フルカスタム実装に切替えてから、オートスケールで考慮すべき一般的な考慮事項についての学びを1つ1つ獲得しながら、下記の方針で、迅速にそして大きな問題なくオートスケールを導入完了できました。 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること 想定外であった場合に、それを検知する実装/設計になっていること つまり、当初は実装精度が十分ではなく、オートスケールの制御精度もやや低い状態でした。そこで初期は目標値を保守的に設定し、まずは一定のコスト削減を達成しました。あわせて、目標値との差分（猶予）を確保しつつ、想定外を検知できる仕組みを用意しました。そのうえで、運用しながら段階的に精度を高めていきました。精度が低い状態を許容するには、想定外の事態や異常の検知が十分に検討され、適切に実装されていることが前提になります。 最低限担保すべき範囲 オートスケールでは、ある指定されたメトリックが目標値になるようリソースを増減させます。 運用開始時に、この目標値に余裕を持たせる前提であれば、 最小ノード数を一定以下にしないこと 一度に可能な増減ノード数を制御できていること ノード増減操作の連続操作に制約を与えること が期待通りに動作していれば、提供するサービス品質に影響が発生するということはないと考えました。 想定外を検知する実装/設計 最低限担保する範囲を厳密に守りながら、実装速度を優先し、運用中に改善を重ねていく前提で開発を進める方針でしたので、運用中の改善を許容するためには「異常な状態」をうまく検知できる必要があり、そのために必要なメトリクス/アラートについて、事前に多くの検討を行いました。 ここでの検討事項には、次の3つのポイントがありました。 1. 制御するパラメータに対する適切なアラート設計/設定 現時点ではCPU利用率を一定範囲にコントロールすることを目標にオートスケールを運用しています。当たり前ですが、利用率が低すぎれば、それはリソースが有効に活用できておらず、利用率が高すぎれば、サービスの提供品質に問題がでる、こういったことが起きない範囲にコントロールすることを目指します。 オートスケールでの制御目標値 実際のアラートの閾値(Cluster/Node) 上記のような値を適切な上下関係に設定し、運用を行うこととしました。 2. 依存関係のモニタリング オートスケールが依存しているAPIの品質/問題に対して異常検知を行うことが重要であると考えました。今回は現状のメトリクスを把握するためのdatadogのAPI、そしてTiDB CloudのAPIが該当します。 例えば、APIレスポンスが遅くなったり、特定のエラーコードが一定以上発生したり、データ点が欠損したり、あるいは、変更操作を起こった際の所要時間をモニタリングし、これが期待値通りかを観測する、といったことです。 3. オートスケールの想定内・想定外の規定 オートスケールでは、ノードを追加したり、削除したり、変更操作を随時行っています。 一方で、あるノードの予期せぬ再起動、といったことも発生します。 外部から観測できるメトリクス(Clusterの状態や、NodeのUptimeなど)から、どのような状態/変化が想定通りか、あるいは想定外かを考え、規定しています。 これらを可能にした周辺改善 オートスケールは、当たり前のように実施しなければならない項目ではありますが、それを実現するために、メルカリ社そしてTiDB Cloudの提供元であるPingCAP社の様々な改善がありました。 一番大きなものは、TiDB CloudのTiDBのスケール操作(スケールアップ/スケールダウン/スケールイン)がgracefulではなかった点を、メルカリ/PingCAP社で改善したことです( TiDB User Day 2025 P.36~ )。 そして、TiDB CloudのdatadogのCPUメトリクスの値の信頼性が十分でなく、オートスケールなどに利用するのが難しい、といった問題への対処、また、オートスケールをAPIで実施する際の 権限制御の改善 、などがありました。 度重なる要望に対して、改善を積み重ねていただいたPingCAP社には改めて感謝します。 今後: TiKVへの展開の難しさと次の一手 現在、より大きなコスト割合を占めるTiKVのスケーリングに取り組んでいます。 TiKVはデータを保持するため、これを水平スケールする際には、データの偏りをなくすためのリバランス、が必要です。水平スケールの戦略を取るためには、スケールインの際には削除対象のノードのすべてのデータを他のノードに移動してからではないと、ノードを削除できません。 現在、「1日の中で負荷が上下し、TiKVで必要なリソースが変化するので、これに最適なリソースにし、コストを抑制しながら必要なリソースを必要なだけ確保したい」という要望があります。データのリバランスは、既存のノードの性能にも影響を与える可能性があり、そのため一般的にはその速度がある程度抑制されています。水平スケールに求めるスケール速度が、このような1日の中でノードを増減する必要がある、という場合においてスケールインは不向きであるといえるでしょう。また、逆にもう少し長いスパンでのスケールの自動追従であれば、コストに対するインパクトがそこまでないため実現の重要性は下がるでしょう。 これに対して、リバランスの速度を調整する、という選択肢も考えられます。しかし、現状ではTiDBではこのリバランスの設定を含む、TiKVの設定変更に対してAPIが提供されておらず、現状取りうる手段は、サポートチケット経由での設定の変更依頼が必要です。 そこで、まずは垂直スケールの機能の導入を目指しています。 TiKVの垂直スケールにおけるメモリ有効活用 今後も追加で様々な課題が見つかるかとは思いますが、現状、大きなインスタンスクラスでTiKVを運用した場合、メモリを有効活用できない課題がありましたので、それを解決しています。 MySQLやその他のデータストアや、システムでもよくある問題ですが、データベースをホストしているノードの安定稼働のために、データベース以外、あるいは主に利用するリソース以外で利用するリソースを一定割合確保するため、主に利用するメモリの利用率を保守的に設定することがあります。 TiDBにおいては、TiKVの block_cache.capacity , memory_usage_limit といった設定が主に積極的に活用したいリソースでありますが、現状のTiKVの実装状況で発生している拘束条件として、これらのパラメータについては、初期値は固定の割合で指定されるものの、初期値ではない値に変更する場合に、利用するメモリ利用量を数値で指定する必要がありました。 https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#memory-usage-limit https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#capacity 先述の通り、TiDB Cloudではこれらの設定を変更するAPIもありませんので、メモリを有効活用するためにメモリ利用量を、値を指定して変更する場合、現状サポートチケット経由で変更依頼が必要です。この状況では、負荷に合わせて自動で垂直スケールしたい、といった場合に、サポートチケット経由での変更が必要になり、結果として適切にメモリ利用量を追従させられません。 すなわち、TiKVを大きなインスタンスクラスで運用した場合、メモリが余剰しリソースを有効活用できない、という問題がありました。具体的にはblock-cache.capacityのデフォルト値の45%に近い、50%前後までしか、メモリを活用できませんでした。 そこで、TiKVのメモリを割合で指定し、大きなインスタンスタンスクラスで運用する場合に、これを大きな値に設定することができるように修正しました。この修正はmasterブランチにマージ済みで、次のマイナーバージョンである8.5.7で利用可能になる見込みです。 https://github.com/tikv/tikv/pull/19419 まとめ メルカリではTiDB Cloudを運用しており、負荷に合わせTiDBの水平方向のオートスケールを安定的に運用しています。これにより、TiDBの50%前後のコストが削減されました（トータルでは、全体の2割の約半分、の削減効果）。 既存のKubernetesのNativeの機能を活用する方針で初期の検討を始め、ステージング環境までも動作させたものの、LLMにて再実装を行ったこと、また、LLMでの実装については、 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること 想定外であった場合に、それを検知する実装/設計になっていること を基本方針として迅速に実装を完了させたこと、 一見当たり前のようにみえる、オートスケールの実現自体には、実はとても大変な基礎的な改善の数々があること、また、最後にTiKVの垂直スケールでメモリを有効活用するため、修正をコントリビュートしていること、をお伝えしました。 最後に、現在メルカリでは、この記事の発行者の所属する DBREチーム の EM(Engineering Manager) を募集しています。詳しくは こちら をご覧ください。

はじめまして。SCSKのすぐろです。 プレビュー版として実装されていたAWS DevOps Agentが2026年3月にGA（一般提供）されましたね。 インシデント発生時に自動で原因調査を行ってくれるサービスですが、実際にどこまで調べてくれるのかが気になったので、Amazon EC2上のWebサーバーで障害を発生させ、DevOps Agentの調査精度と限界を検証してみました。 参照: AWS DevOps Agent is now generally available AWS DevOps Agentとは インシデント発生時に、複数のデータソースを横断的に分析し、根本原因の特定と緩和策の提案を自動で行うマネージドサービスです。AWSネイティブなCloudWatchメトリクス・CloudWatch Logs・CloudTrailに加え、Datadog、Dynatrace、New Relic、Splunk等のサードパーティ製監視ツールや、GitHub、GitLab等のCI/CDパイプライン、ServiceNow、PagerDuty等のチケットシステムとも連携できます。GA版ではAzureやGrafanaのサポートも追加されました。 参照: About AWS DevOps Agent 参照: AWS DevOps Agent GA発表ブログ 料金 従量課金制で、エージェントがタスクに費やした時間に対して秒単位で課金されます。アイドル状態や待機中は課金されません。 課金対象 単価 Investigations（インシデント対応） $0.0083 / agent-second Evaluations（インシデント予防） $0.0083 / agent-second On-demand SRE tasks（チャット） $0.0083 / agent-second 新規利用者には2ヶ月間の無料トライアルがあり、各月Investigation 20時間・Evaluation 15時間・チャット 20時間まで無料で利用できます。 参照: Pricing – AWS DevOps Agent 検証のきっかけ 本番稼働中のWebサーバー(EC2インスタンス)のインシデント調査に使用するにあたり、以下の4点がきになりました。 EC2インスタンスへの影響はあるか DevOps AgentのIAMマネージドポリシー（ AIDevOpsAgentAccessPolicy ）を確認すると、EC2に対しては ec2:Describe* 等の読み取り系APIのみが許可されています。セキュリティドキュメントにも「エージェントが利用可能なツールは、チケットやサポートケースのオープンを除き、リソースを変更することができない」と記載されています。つまり、DevOps Agentの導入・調査によってEC2インスタンスが変更・停止されることはありません。 参照: DevOps Agent IAM permissions 参照: AWS DevOps Agent Security サーバーの中まで見に行ってくれるのか DevOps AgentはAWSのAPIを通じて情報を収集します。OS内部に直接アクセスする機能はドキュメントに記載されていません。OS内部の情報を調査対象にするには、CloudWatch Agent等でCloudWatch Logsやカスタムメトリクスとして事前に送信しておく必要があります。 参照: About AWS DevOps Agent 参照: What is a DevOps Agent Topology? どうやって調査しているのか IAMポリシーにはSSMでコマンドを実行する ssm:SendCommand やSSH接続用の ec2-instance-connect:* は含まれていません。SSHやSSMでEC2に接続するのではなく、AWSのAPIを通じた読み取り専用アクセスのみで調査を行います。 参照: DevOps Agent IAM permissions サーバー内に何かインストールされるのか EC2インスタンス内部にエージェントソフトウェアがインストールされることはありません。導入時に作成されるのはAgent Space（論理コンテナ）やサービスリンクロール等、AWSコントロールプレーン側のリソースのみです。 参照: DevOps Agent IAM permissions 検証 検証環境 EC2: t3.micro（Amazon Linux 2023）、httpd（Apache）をUserDataで起動 CloudWatch Agent: 以下の設定でログ・メトリクスを送信 CloudWatch Agentの設定ファイル（ /opt/aws/amazon-cloudwatch-agent/etc/config.json ）: { "metrics": { "namespace": "DevOpsAgentTest", "metrics_collected": { "mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 }, "disk": { "measurement": ["used_percent"], "metrics_collection_interval": 60, "resources": ["*"] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "/devops-agent-test/messages" }, { "file_path": "/var/log/httpd/error_log", "log_group_name": "/devops-agent-test/httpd-error" }, { "file_path": "/var/log/httpd/access_log", "log_group_name": "/devops-agent-test/httpd-access" } ] } } } } /var/log/messages をCloudWatch Logsに送信することで、OOM KillerなどカーネルレベルのイベントがDevOps Agentの調査対象になります。メモリ・ディスク使用率のカスタムメトリクスも送信し、標準メトリクス（CPU、ネットワーク等）と合わせてDevOps Agentが参照できるようにしています。 検証1: CPU高負荷 SSMで接続し、 yes > /dev/null コマンドでCPUを100%に張り付かせた状態でDevOps Agentに調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: CPU使用率が100%に達していることを正しく検知 CloudTrailからタイムラインを構築し、同時刻のイベント（yum update、Inspector 2スキャン、SSMセッション開始）を列挙 「SSMセッション内でCPU集約的なコマンドを実行した可能性がある」と推測 → 実際に正しい方向の推測 調査した結果原因を断定できなかったので仮説を立てている 各仮説に「可能性がある」という表現を使い、断定を避けていた 「調査ギャップ」として確認できなかった事項を明確に報告 真の原因（yesコマンド）にはOS内部のプロセス情報がないため到達できませんでしたが、仮説と事実を区別した誠実な調査結果でした。 調査コスト: 約6分（360秒）→ $2.99（$1=¥150換算で約¥448） 追加検証: SSMセッションログを有効にして再検証 検証1ではDevOps Agentが実行コマンドを特定できなかった原因は、SSMセッション内で何を実行したかのログがCloudWatch Logsに送信されていなかったためです。そこで、SSM Session ManagerのCloudWatch Loggingを有効にし、セッション中のコマンド入出力をCloudWatch Logsに記録する設定を追加した上で、同じCPU高負荷を再現して調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: 根本原因を「IAMユーザーxxxxxによる意図的なCPUストレステストの実行」と正確に特定 実行コマンド（ for i in $(seq 1 $(nproc)); do (yes > /dev/null) & done ）を特定 実行ユーザー、セッションID、起動されたプロセスのPIDまで特定 「計画的な負荷テストであり、システム異常やマルウェアではない」と正しく判断 SSMセッションログという1つのデータソースを追加しただけで、検証1の「仮説止まり」が「正確な原因特定」に変わりました。DevOps Agentの調査精度がデータソースの充実度に直結することを改めて裏付ける結果となりました。 検証2: メモリ逼迫によるOOM Killer発動 stress-ng でメモリを枯渇させ、OOM Killerによってhttpdが強制終了される状況を作り、DevOps Agentに調査を依頼しました。検証1と異なり、OOM Killerのログが /var/log/messages → CloudWatch Logs経由でDevOps Agentの調査対象になります。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )上のWebサーバー（httpd、ポート80）が応答しなくなりました。原因を調査してください。 結果: 根本原因を「stress-ngツールによる意図的なメモリ枯渇テスト」と正確に特定 実行ユーザー（SSMセッションユーザー）を特定 実行コマンドとパラメータ（ stress-ng --vm 1 --vm-bytes 900M ）まで特定 OOM Killerが全httpdプロセス（PID含む）を強制終了したことをログから読み取り タイムラインを正確に構築（00:07:17 → 00:11:29 → 00:17:32） メモリ枯渇 → OOM Killer → httpd停止 という因果関係に正しく到達 検証1では仮説止まりだったのに対し、CloudWatch Logsにカーネルログという明確な根拠があったことで、正確な原因特定ができました。 また、調査完了後に「緩和計画」という機能を実行したところ、stress-ngプロセスの停止 → httpdサービスの再起動 → 事後検証（HTTP 200 OK確認）まで、具体的なコマンド付きの復旧手順を提示してくれました。手順通りに実行してWebサーバーの復旧を確認できました。 調査コスト: 約5分（304秒）→ $2.52（$1=¥150換算で約¥379） わかったこと 良かった点 AWSのAPI経由で取得できる情報を横断的に分析し、タイムラインを構築する能力は高い CloudWatch Logsに根拠となるログが存在する場合、実行コマンド・ユーザー・タイムラインまで正確に特定できる（検証2で確認） 調査ギャップ（確認できなかったこと）を報告する仕組みがある EC2インスタンスへの変更やエージェントのインストールは不要 従量課金制で、調査しなければ費用は発生しない 注意が必要な点 OS内部のプロセス状態やローカルログには直接アクセスできない CloudWatch Logsに送信されていない情報は調査対象外 データソースに根拠がない場合、仮説止まりになる（検証1で確認） 調査精度の比較 検証 データソースの根拠 原因特定 評価 検証1（CPU高負荷） △ メトリクスのみ × 仮説止まり 真の原因に到達できず 検証1 追加検証（SSMセッションログ有効） ○ メトリクス + SSMセッションログ ○ 正確に特定 コマンド・ユーザー・PIDまで特定 検証2（メモリ逼迫） ○ メトリクス + OOM Killerログ ○ 正確に特定 コマンド・ユーザーまで特定 まとめ DevOps Agentの調査精度は、データソースに残る根拠の有無に大きく依存します。検証1ではメトリクスだけでは仮説止まりでしたが、SSMセッションログを1つ追加しただけで正確な原因特定に変わりました。 導入を検討する場合は、DevOps AgentがAPIレベルで情報を取得できる環境を整備しておくことが重要だと感じました。CloudWatch Agentによるログ・メトリクスの送信はもちろん、CloudTrailの有効化やVPCフローログの設定など、DevOps Agentが参照できるデータソースを充実させて調査精度を向上させることで、インシデント調査はエージェントにお任せし、業務効率を向上させていきましょう！

本稿は、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 を中心としたマルチテナント基盤の信頼性と運用効率の向上に取り組んでいる。