金融システムで挑む！EKS Auto Mode導入ポイント大全

金融システムで挑む！ EKS Auto Mode導入ポイント大全 JAWS-UG Fin-JAWS × コンテナ支部金融コンテナ大全〜ビジネスから技術まで〜
2026年5月20日株式会社野村総合研究所マルチクラウドインテグレーション事業本部金融基盤サービス部エキスパートアーキテクト高棹大樹

1 Copyright （C） Nomura Research Institute, Ltd. All rights reserved.
高棹大樹 – Daiki Takasao NRI 金融基盤サービス部 • Elastic Kubernetes Service(EKS)を用いた金融機関様向けマイクロサービス共通基盤のインフラ担当主な仕事趣味最近の困り事 • キャンプ • 筋トレ • 子供と遊ぶ(相手をしてくれる内に。。) • 飼っている猫が懐いてくれない

NRIの会社紹介使命創発する社会私たちの価値観企業理念社会に対して新しい社会のパラダイムを洞察し、その実現を担うお客様に対してお客様の信頼を得て、お客様とともに栄える夢と可能性に満ち、豊かさを実感する、活力ある社会人々の英知がつながり、環境にやさしい持続可能な社会強くてしなやかな、安全で安心に満ちた社会先見性と緻密さで、期待を超える多彩な個が互いに尊重し、志をひとつにする情熱と誇りを胸に、あくなき挑戦を続けるコーポレート・ステートメント

NRIグループ４つの事業 NRIの会社紹介コンサルティング CONSULTING 創業以来、シンクタンクとしての深い知見と先見性を活かし、官民の様々な分野で戦略策定・政策立案を支援してきました。また、政策・産業・事業・技術への深い理解とお客様との対話を通じ、課題解決に向けた施策を提案し、伴走しています。 AIをはじめとする技術革新が加速し、社会や市場の変化が予測困難となる今、ビジネスを次のステージへと導くには、先見性に裏付けられたマネジメントコンサルティング、先進技術で事業・業務革新を加速するシステムコンサルティング、それらを統合する実行力が不可欠です。未来を見据え、今を変えることで、お客様の最良のパートナーであり続けることを目指します。 NRIグループはコンサルティングやさまざまなITソリューションの提供を通じて、社会や産業を確かな明日へ導くとともに、世界中のお客様と新しい価値を共創しています。金融ITソリューション FINANCIAL IT SOLUTIONS NRIグループは、金融ビジネスを取り巻く環境変化を高い洞察力で捉える研究員やコンサルタント、ITソリューションサービスを提供するビジネスアナリストやデジタル人材の連携によって次世代ソリューションを提供し続け、金融機関の事業継続を多方面から支えています。近年は、金融機関や政策当局、異業種プレーヤーなどとの価値共創により、金融機能の変革に取り組んでいます。金融は、社会の重要インフラです。進化し続けるデジタル技術との相性を常に考えながら、安定かつ先進的な社会インフラを実現し、社会課題に果敢にチャレンジしていきます。産業ITソリューション INDUSTRIAL IT SOLUTIONS 産業分野の業界トップ企業のビジネスパートナーとして、コンサルティングからシステム開発や運用まで、一貫したサービスを提供しています。コンサルタントとエンジニアが共同でお客様のビジネス環境やデータを分析しながら、最適なIT ソリューションを提供しています。また、コンサルティング部門から運用部門まで、NRIグループのリソースをインテグレーションし、お客様のデジタル戦略を柔軟かつスピーディーに実現します。長年にわたってミッションクリティカルなシステムを構築・運用してきた経験と実績で、これからもお客様の事業インフラとしてのシステム基盤を支えていきます。 IT基盤サービス IT PLATFORM SERVICES IT技術の革新が加速する中、巨大化・複雑化が進むITシステム基盤の重要性が増しています。 NRIグループは先進的な技術を見通し、戦略的にサービスやソリューションに取り入れ、お客様の成長や変革の実現をサポートします。先進技術の調査・研究やAI技術の活用も積極的に実施しています。また、マルチクラウドを含むシステム全体を運営するマネージドサービスやお客様の働く環境を創り出すデジタルワークプレイス事業などを展開しています。さらに、高度化するサイバー脅威に対応するデジタルトラスト事業やお客様が直面するセキュリティ課題の解決、総合的なセキュリティレベルの向上を支援しています。

今日話すことをざっくり EKSワーカーノードの管理から開放される Automodeはとっても魅力的！！特性を知った上で適切に運用しないと、システムエラーが頻発してしまう！ Automodeのメリットを活かしつつ、安定稼動させるための工夫をお話しします！

アジェンダ Kubernetes/EKSのおさらい 01 EKS Automodeとは？ 02 Automodeでも安定稼動させるためのポイント 03 Automodeの導入効果 04

Kubernetesって何？ 1. Kubernetes/EKSのおさらい ◼コンテナ化されたアプリケーションを自動で配置・スケーリング・管理するためのオーケストレーションプラットフォーム ◼元々Google で開発され、現在は CNCF（Cloud Native Computing Foundation）が運営している ◼略してK8s

Kubernetesの役割①: コンテナの配置管理 1. Kubernetes/EKSのおさらいサーバコンテナA サーバサーバコンテナB コンテナA コンテナをどのサーバ上で稼働させるのかを判断・管理するコンテナC 障害が発生してもコンテナの機能提供を継続するために、同一種類のコンテナを複数稼働させる Kubernetes

Kubernetesの役割②: 障害発生時の退避・自動復旧 1. Kubernetes/EKSのおさらいコンテナA コンテナB コンテナA コンテナC 障害が発生したコンテナを復旧するコンテナB コンテナA サーバに障害が発生した際、そのサーバ上で稼働していたコンテナを他のサーバに退避する Kubernetes サーバサーバサーバ

Kubernetesの役割③: コンテナのリソース拡張・アップデート管理 1. Kubernetes/EKSのおさらいコンテナA コンテナB コンテナA 問合せ量の増加等を契機として、コンテナのリソースを自動拡張するコンテナC コンテナのローリングアップデートのために、一連のコンテナの停止とデプロイの作業を、順序を守って実施するコンテナB NEW Kubernetes サーバサーバサーバ

Kubernetesの役割③: コンテナのリソース拡張・アップデート管理 1. Kubernetes/EKSのおさらいコンテナA コンテナB コンテナA 問合せ量の増加等を契機として、コンテナのリソースを自動拡張するコンテナC コンテナのローリングアップデートのために、一連のコンテナの停止とデプロイの作業を、順序を守って実施するコンテナB NEW Kubernetes サーバサーバサーバコンテナ数が少なければ手動作業できるが、増えると困難。。 Kubernetesは自動で実施してくれる!

Kubernetesの特徴①: 様々な形態で導入可能 1. Kubernetes/EKSのおさらい Kubernetes オンプレミス Kubernetes パブリッククラウド様々なパブリッククラウド、オンプレミスでKubernetesを導入可能 Kubernetes上で構築したコンテナのシステム構成は、他のパブリッククラウドやオンプレミス環境へ比較的容易に移行・展開が可能 ※クラウド固有のサービスに依存する部分を除く

Kubernetesの特徴②: マニフェストによるリソース定義 1. Kubernetes/EKSのおさらい apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx-container image: nginx:1.25 マニフェスト Kubernetes 適用 K8sリソース望ましい状態実際の状態修復比較マニフェストをKubernetesに適用することで、K8sリソースが作成される NEW マニフェストで定義した望ましい状態と実際の状態を継続的に比較し、差分を検知した場合は自動的に修復する

Kubernetesの特徴②: マニフェストによるリソース定義 1. Kubernetes/EKSのおさらい Kubernetes 比較望ましい状態：コンテナ(Pod)が3つ実際の状態：コンテナ(Pod)が2つ → 1つ追加誤って削除 NEW 起動 Kubernetes利用者が誤って1つのPodを削除 Kubernetesは差分を検知し、望ましい数に合せる形で自動でPodを1つ起動する

Kubernetesの特徴③: 高い拡張性 1. Kubernetes/EKSのおさらいプロダクト名用途主なカスタムリソース名 Istio サービスメッシュ VirtualService, DestinationRule, Gateway Linkerd サービスメッシュ ServiceProfile Argo CD GitOpsによる継続的デリバリー Application Prometheus Operator Kubernetesネイティブな監視 ServiceMonitor, PrometheusRule KEDA イベント駆動のオートスケーリング ScaledObject, TriggerAuthentication Argo Workflows バッチ処理・データパイプライン Workflow, CronWorkflow MongoDB Community Operator MongoDBクラスタ運用 MongoDBCommunity MySQL Operator MySQLクラスタ運用 MysqlCluster Postgres Operator PostgreSQLクラスタ運用 PostgresCluster ◼Kubernetesには豊富な種類のリソースがビルトインで揃っている ◼それらに加えて、独自のリソース(カスタムリソース)を定義できる ◼多数のカスタムリソースが開発されており、Kubernetesを中心とした大きなエコシステムを形成している

Kubernetesクラスタの構成要素 1. Kubernetes/EKSのおさらい Kubernetesクラスタワーカーノード(データプレーン) ・・・リソースを稼働させるサーバ群コントロールプレーンリソースを管理

Elastic Kubernetes Service(EKS)とは？ 1. Kubernetes/EKSのおさらい ◼AWSのマネージドKubernetesサービス ◼コントロールプレーンの管理が不要、 IAMユーザ/ロールによる認証などが主なメリットワーカーノード(データプレーン) リソースを稼働させるサーバ群コントロールプレーンリソースを管理・・・コントロールプレーンの管理が不要 IAMユーザ/ロールによる認証

EKS Automodeとは？ 2. EKS Automodeとは？ ◼Kubernetes向けのノードオートスケーリングOSSであるKarpenterのマネージドサービス ⚫ 他にもAutomodeの機能はあるが、今日は説明を割愛( ◼Karpenterの主な特徴 1. 高速なスケーリング • 従来のCluster Autoscaler（CA）より高速にノードをプロビジョニング • Podのスケジューリング要求に直接反応して、数秒でノードを起動 2. 柔軟なノード選択 • Auto Scaling Groupに依存せず、EC2インスタンスを直接起動 • Podの要求（CPU、メモリ、GPU等）に最適なインスタンスタイプを自動選択 • 複数のインスタンスタイプやアベイラビリティゾーンから最適なものを選択 3. コスト最適化 • Spot インスタンスの活用をサポート • ノードの統合（Consolidation）機能により、使用率の低いノードを自動的に最適化

Karpenter/Automodeの機能 2. EKS Automodeとは？ No 項目概要 1 Drift ノードの設定とマニフェストとの間で乖離を検出した際に、マニフェストの内容で自動でノードを再作成する 2 Expiration ノードに有効期限を設定し、指定した期間が経過すると自動的にノードの削除・再作成を行う (EKS AutoModeの場合は、21日が最長期間として設定可能) 3 Consolidation ノードのリソース使用状況を監視し、AWS利用料が最適になる様に自動でノードの統合や削除を行う 4 Interruption EC2スポットインスタンスの中断通知やメンテナンスイベントを検知し、事前にPodを他のノードに退避する 5 Node Auto Repair ノードの健全性を監視し、異常を検出した場合に自動的にノードを削除・再作成する Consolidationのイメージワーカーノードの構成を最適化 ※Karpenter公式ページより抜粋絶えず増減するコンテナに追従して人手で実施するのは困難

Consolidationのイメージワーカーノードの構成を最適化 ※Karpenter公式ページより抜粋絶えず増減するコンテナに追従して人手で実施するのは困難 Karpenter/Automodeの機能 2. EKS Automodeとは？ No 項目概要 1 Drift ノードの設定とマニフェストとの間で乖離を検出した際に、マニフェストの内容で自動でノードを再作成する 2 Expiration ノードに有効期限を設定し、指定した期間が経過すると自動的にノードの削除・再作成を行う (EKS AutoModeの場合は、21日が最長期間として設定可能) 3 Consolidation ノードのリソース使用状況を監視し、AWS利用料が最適になる様に自動でノードの統合や削除を行う 4 Interruption EC2スポットインスタンスの中断通知やメンテナンスイベントを検知し、事前にコンテナを他のノードに退避する 5 Node Auto Repair ノードの健全性を監視し、異常を検出した場合に自動的にノードを削除・再作成する便利な反面、ノードが勝手に削除される！そんな中でも金融システムのコンテナはエラーを発生させる訳にはいかない！安定稼動のための工夫をお話しします！

住信SBIネット銀行様の事例 3. Automodeでも安定稼動させるためのポイント ◼ マイクロサービス共通基盤としてEKSを活用 ◼ 「WEBフロントシステム」「かんたん住宅ローン」をはじめとした複数の重要システムが共通基盤上で稼動中 ◼ マイクロサービス共通基盤でEKS Automode導入した際のポイント・工夫についてお話ししますかんたん住宅ローン WEBフロントシステム

ポイント①: Podの安全な停止設定 3. Automodeでも安定稼動させるためのポイント ◼ワーカーノードが削除される際、Podは別のノードに退避される ◼Podの退避は実際にはPodが停止し、その後別ノードでPodが起動する事で実現される ◼Podの停止時にシステムエラーは許容できないが、リクエストの振り分け対象から手動で切離す事はできない EKSワーカーノード EKSワーカーノード ①Pod停止 ②別ワーカーノードでPod起動 Pod停止前にリクエストの振り分け対象から該当Podを手動で切離す事はできない削除

ポイント①: Podの安全な停止設定 3. Automodeでも安定稼動させるためのポイント ◼ 受入れたリクエストの処理が完了する時間分、Podが停止を待つ設定を入れる ◼ 具体的には、アプリケーションのマニフェストファイルに、一律でPreStopフックでsleepコマンド実行、terminationGracePeriodSecondを明示的に指定する ⚫ PreStopフックは、コンテナが停止する前に任意のコマンドを実行できる機能この機能を利用して、アプリPodがkubernetesのServiceから切り離され、受け取ったリクエストの処理が終了するまでの時間コンテナ停止を待つ様にsleepコマンドを実行 ⚫ terminationGracePeriodSecondsは、Podが強制終了されるまでの時間を設定するもの Pod停止の前にリクエストの処理が完了する時間分待つ設定を入れる PreStopフックでsleepコマンド実行 terminationGracePeriodSeconds

ポイント①: Podの安全な停止設定 3. Automodeでも安定稼動させるためのポイント ◼ PreStopフックのSleepコマンド実行とterminationGracePeriodSecondsの関係を図にしたものが以下 Service Pod停止開始コンテナ強制終了 (SIGKILL) 新規リクエスト受け入れ終了コンテナ停止 (SIGTERM) ServiceからPodの切離し新規リクエストの受け入れコンテナ処理してレスポンスを返す新規リクエストの受け入れ PreStopフックでsleepコマンド実行余裕値 Pod terminationGracePeriodSeconds 余裕値 apiVersion: apps/v1 kind: Deployment spec: template: spec: terminationGracePeriodSeconds: "180s" containers: - image: <コンテナイメージ名> lifecycle: preStop: exec: command: - sh - -c - "sleep 160“ Deploymentマニフェスト

ポイント②: Podの冗長性を尊重したノード削除 3. Automodeでも安定稼動させるためのポイント ◼ワーカーノードの削除で複数稼動していたPodが同時に停止してしまうと、システムの稼動に影響を与えてしまう可能性あり Podを3つで冗長化ワーカーノード Pod停止削除ワーカーノード Pod停止削除 Podを冗長化していても、それらが稼動するノードが同時に削除されてしまうと問題 Pod停止ワーカーノードワーカーノード

ポイント②: Podの冗長性を尊重したノード削除 3. Automodeでも安定稼動させるためのポイント ◼ PodDisruptionBudget(PDB)は、Podの冗長性を一時的にどの程度崩せるのかを定義するリソース ◼ AutomodeはPDBの設定を尊重した上でノード削除を行う ◼ 冗長性を崩せない設定をすると、Pod退避→ノード削除の動作が行われず、ノードの強制削除が発生してしまうノード apiVersion: policy/v1 kind: PodDisruptionBudget metadata: ～～ spec: minAvailable: 2 ～～ PDBマニフェスト良いPDBの設定例ノードノード Podを3つで冗長化最少2つPodが起動している必要あり削除 Pod1つが停止してもPDBを守れるのでノード削除可能ノード apiVersion: policy/v1 kind: PodDisruptionBudget metadata: ～～ spec: minAvailable: 3 ～～ PDBマニフェスト悪いPDBの設定例ノードノード Podを3つで冗長化最少3つPodが起動している必要あり Pod1つが停止したらPDBを守れないので安全なノード削除不可削除できない

ポイント②: Podの冗長性を尊重したノード削除 3. Automodeでも安定稼動させるためのポイント ◼ PodDisruptionBudget(PDB)は、Podの冗長性を一時的にどの程度崩せるのかを定義するリソース ◼ AutomodeはPDBの設定を尊重した上でノード削除を行う ◼ 冗長性を崩せない設定をすると、Pod退避→ノード削除の動作が行われず、ノードの強制削除が発生してしまう。ノード apiVersion: policy/v1 kind: PodDisruptionBudget metadata: ～～ spec: minAvailable: 2 ～～ PDBマニフェスト良いPDBの設定例ノードノード Podを3台で冗長化最少2つPodが起動している必要あり削除 Pod1つが停止してもPDBを守れるのでノード削除可能ノード apiVersion: policy/v1 kind: PodDisruptionBudget metadata: ～～ spec: minAvailable: 3 ～～ PDBマニフェスト悪いPDBの設定例ノードノード Podを3台で冗長化最少3つPodが起動している必要あり Pod1つが停止したらPDBを守れないので安全なノード削除不可削除できない Podの冗長性とノードのメンテナンス性のバランスを取ったPDB設定が必要！

ポイント③: Podの分散配置 3. Automodeでも安定稼動させるためのポイント ◼ PDBを適切に設定しても、Podがノードで偏って起動してしまうと、ワーカーノードを削除できなくなる可能性がある ◼ Podをワーカーノード間で分散配置させるために、 topologySpreadConstraintsを設定する ◼ topologySpreadConstraintsの設定は、ワーカーノード障害時にも有効ノード apiVersion: policy/v1 kind: PodDisruptionBudget metadata: ～～ spec: minAvailable: 2 ～～ PDBマニフェストノードノード Podを3つで冗長化最少2つPodが起動している必要あり Pod2つが停止したらPDB を守れないので安全なノード削除不可削除できないノード apiVersion: apps/v1 kind: Deployment spec: template: spec: topologySpreadConstraints: - topologyKey: kubernetes.io/hostname ～～ Deploymentマニフェストノードノードノード間でPodを分散配置

ポイント④: ポリシー制御の仕組みでマニフェストチェック 3. Automodeでも安定稼動させるためのポイント ◼ここまでで説明したマニフェスト設定がしっかり設定されている事を、人手でチェックするのは大変 ◼システム数、コンテナの種類が増えてくると、人手でのチェックは現実的でなくなる ◼Kubernetesリソースのポリシー管理OSSであるGatekeeperを用いて、リリース(Apply)時に自動で設定をチェックする様にした

ポイント④: ポリシー制御の仕組みでマニフェストチェック 3. Automodeでも安定稼動させるためのポイント ◼Gatekeeperによるポリシー制御内容(抜粋) 目的監査対象リソース対象パラメータ制限内容 ①Podの安全な停止設定 Deployment, StatefulSet, DaemonSet, Rollout spec.containers[].lifecycle.prestop 設定値が存在していること Deployment, StatefulSet, DaemonSet, Rollout spec.terminationGracePeriodSeconds 設定値が存在していること、preStopよりも値が大きいこと ②Podの冗長性を尊重したノード削除 Deployment, StatefulSet, Rollout spec.selector.matchLabels （Kind:Deployment/StatefulSet） spec.template.metadata.labels （Kind:Deployment/StatefulSet） spec.selector.matchLabels （Kind:PodDisruptionBudget）設定されたラベルに対して一致するPDBが存在すること（PDBが設定されていること） ③Podの分散配置 Deployment, StatefulSet, Rollout spec.topologySpreadConstraints 設定値が存在していること

ポイント⑤: ワーカーノードのハイブリット構成 3. Automodeでも安定稼動させるためのポイント ◼ 年次のEKSバージョンアップと合せてAutomode導入したため、対策が間にあわないコンテナもあった ◼ その様なコンテナ(Pod)を稼動させるために従来のワーカーノードも稼動させる様にした ◼ Podのマニフェスト設定(nodeSelector)でどちらのノードで稼動させるか選択できる様にしたインフラ用ワーカーノード(従来のワーカーノード) NGINX ALB NodePort NGINX Service アプリ用ワーカーノード(Automode) アプリ用ワーカーノード(従来のワーカーノード) 管理系Pod ユーザー・・・アプリPod アプリPod アプリPod kind: Deployment spec: template: spec: nodeSelector: node: automode ・・・アプリPod アプリPod アプリPod kind: Deployment spec: template: spec: nodeSelector: node: normal

Automodeの導入効果 4. Automodeの導入効果ワーカーノード台数を約50％削減！! Automode移行を進める事でさらに削減可能な見込み！

Automodeによるノード削減の要因分析 4. Automodeの導入効果非常にスペックの大きいバッチPodが稼動しているそれが従来のワーカーノードのスケールアウトを引き起していたそのバッチPodをAutomodeで稼動させる事で、稼動後に自動でノードが削除される様になったアプリPodのリリースをBlue/Greenしている際、Podの量が一時的に2倍になるそれを賄うだけのワーカーノードが起動していた Automodeにより、リリース前のPodが停止することに追従してノードが自動削除される様になった

まとめポリシー制御の仕組みでアプリPodの設定を漏れなくチェック！ノード削除でもエラーを発生させないためにはアプリPodの適切な設定が重要！ Automodeは便利な反面、ノードが勝手に削除される！

まとめポリシー制御の仕組みでアプリPodの設定を漏れなくチェック！ノード削除でもエラーを発生させないためにはアプリPodの適切な設定が重要！ Automodeは便利な反面、ノードが勝手に削除される！今後はAutomodeをさらに活用し、 Spotインスタンスを導入することでさらにAWS利用料を最適化！！

金融システムで挑む！EKS Auto Mode導入ポイント大全

金融システムで挑む！EKS Auto Mode導入ポイント大全

More Decks by 高棹大樹

Other Decks in Technology

Featured

Transcript