最新技術に積極チャレンジ！EKS共通基盤のこれまでとこれから

Transcript

1. Netadashi Meetup #17 最新技術に積極チャレンジ！ EKS共通基盤のこれまでとこれから エキスパートアーキテクト 高棹 大樹 株式会社 野村総合研究所 マルチクラウドインテグレーション事業本部 金融基盤サービス部 2026年8月28日
2. 高棹 大樹 – Daiki Takasao NRI 金融基盤サービス部 主な仕事 • Amazon Elastic Kubernetes Service (EKS) を用いた金融機関様向けマイクロサービス共通基盤 のインフラ担当 趣味 • キャンプ • 筋トレ • 子供と遊ぶ(相手をしてくれる内に。。) 最近の困り事 • 飼っている猫が懐いてくれない Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 1
3. Kubernetes/EKSのアウトプット結構やっています ◼ 約2,000名が参加する日本最大級のイベントであるCloudNative Days Winterに2年連続で登壇 ⚫ 【2024/11/29登壇】CloudNative Days Winter 2024 レガシーな金融システムをKubernetesを使って クラウドネイティブ化するためのノウハウ大全 ⚫ 【2025/11/18登壇】 CloudNative Days Winter 2025 Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全 ◼ 技術発信メディアであるTechPlayでKubernetesのノウハウについての講演を実施 ⚫ 【2025/3/17登壇】エンタープライズでこそ発揮されるKubernetesの真価。 日本初Kubestronautが語る導入ノウハウと社内定着のステップ ー現場事例を交えて徹底解説【NRI Tech Talks#3】 ◼ 一般社団法人ソフトウェア協会主催のカンファレンスTech Challenge Party 2026 で Kubernetes初学者向けの登壇を実施 ⚫ 【2026/2/4登壇】インフラエンジニア必見! Kubernetesを用いたクラウドネイティブ設計ポイント大全 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 2
4. 「クラウドネイティブ教科書」プロジェクトに参画しました ◼LPI-Japanのクラウドネイティブ教科書が先日一般公開されました！ ⚫ https://linuc.org/textbooks/cloudnative/ ◼NRIから私とクラウドネイティブ勉強会の有志が開発協力者として参画しています ◼ 技術の内容は少なく、どなたでも読みやすいものになっていますので興味のある方はぜひご一読 くださいー （無料でダウンロードできます） Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 3
5. はじめに これまで約5年間 EKS共通基盤に取り組んできました そこでの取り組みや 発生した問題についてお話しします！ 今後のEKS基盤で 取り組んでいきたいこともお話しします！ Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 4
6. アジェンダ 01 Kubernetes/EKSとは？ 02 EKS共通基盤のこれまで 03 EKS共通基盤のこれから Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 5
7. 1. Kubernetes/EKSとは？ Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 6
8. 1. Kubernetes/EKSとは？ Kubernetesって何？ ◼コンテナ化されたアプリケーションを自動で配置・スケーリング・管理するためのオーケストレーション プラットフォーム ◼元々Google で開発され、現在は CNCF（Cloud Native Computing Foundation） が運 営している ◼略してK8s Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 7
9. 1. Kubernetes/EKSとは？ Kubernetesの特徴①: 様々な形態で導入可能 Kubernetes上で構築したコンテナのシステム構成は、 他のパブリッククラウドやオンプレミス環境へ比較的容易に移行・展開が可能 ※クラウド固有のサービスに依存する部分を除く オンプレミス Kubernetes パブリッククラウド Kubernetes 様々なパブリッククラウド、オンプレミスでKubernetesを導入可能 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 8
10. 1. Kubernetes/EKSとは？ Kubernetesの特徴②: マニフェストによるリソース定義 マニフェストをKubernetesに適用することで、K8sリソースが作成される NEW apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx-container image: nginx:1.25 適用 K8sリソース 望ましい状態 マニフェストで定義した望ましい状態と 実際の状態を継続的に比較し、 差分を検知した場合は自動的に修復する 比 較 実際の状態 修 復 Kubernetes マニフェスト Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 9
11. 1. Kubernetes/EKSとは？ Kubernetesの特徴②: マニフェストによるリソース定義 望ましい状態： コンテナ(Pod)が3つ Kubernetes利用者が誤って1つのPodを削除 Kubernetesは差分を検知し、 望ましい数に合せる形で自動でPodを1つ起動する 比 較 実際の状態： コンテナ(Pod)が2つ → 1つ追加 誤って 削除 NEW Kubernetes 起 動 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 10
12. 1. Kubernetes/EKSとは？ Kubernetesの特徴③: 高い拡張性 ◼Kubernetesには豊富な種類のリソースがビルトインで揃っている ◼それらに加えて、独自のリソース(カスタムリソース)を定義できる ◼多数のカスタムリソースが開発されており、Kubernetesを中心とした大きなエコシステムを形成し ている プロダクト名 Istio Linkerd Argo CD Prometheus Operator KEDA Argo Workflows MongoDB Community Operator MySQL Operator Postgres Operator 用途 サービスメッシュ サービスメッシュ GitOpsによる継続的デリバリー Kubernetesネイティブな監視 イベント駆動のオートスケーリング バッチ処理・データパイプライン MongoDBクラスタ運用 MySQLクラスタ運用 PostgreSQLクラスタ運用 主なカスタムリソース名 VirtualService, DestinationRule, Gateway ServiceProfile Application ServiceMonitor, PrometheusRule ScaledObject, TriggerAuthentication Workflow, CronWorkflow MongoDBCommunity MysqlCluster PostgresCluster Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 11
13. 1. Kubernetes/EKSとは？ Kubernetesクラスタの構成要素 Kubernetesクラスタ ワーカーノード(データプレーン) コントロールプレーン リソースを管理 ・・・ リソースを稼働させるサーバ群 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 12
14. 1. Kubernetes/EKSとは？ Elastic Kubernetes Service(EKS)とは？ ◼AWSのマネージドKubernetesサービス ◼コントロールプレーンの管理が不要、 IAMユーザ/ロールによる認証などが主なメリット IAMユーザ/ロールによる 認証 コントロールプレーンの 管理が不要 ワーカーノード(データプレーン) コントロールプレーン リソースを管理 ・・・ リソースを稼働させるサーバ群 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 13
15. 1. Kubernetes/EKSとは？ ECS or EKS ？ ◼運用コストと利用可能な機能の幅、相互運用性を考慮して選択する ECS EKS (Elastic Container Service) (Elastic Kubernetes Service) 利用可能な機能の幅 マルチクラウド、オンプレミス との相互運用性 △ AWSが提供しているサービスの機能のみ 利用可能 △ ECSはAWS独自サービス 運用コスト クラスタのバージョンアップは実施不要 AWS提供サービスに加えてKubernetesや その上で稼動するクラウドネイティブOSSを利用可能 Kubernetes APIリソースは マルチクラウド、オンプレミスで使用可能 △ Kubernetesのバージョンリリースに追従して定期的に クラスタのバージョンアップを行う必要がある Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 14
16. 2. EKS共通基盤のこれまで Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 15
17. 2. EKS共通基盤のこれまで ドコモSMTBネット銀行様(旧 住信SBIネット銀行様)の事例 ◼マイクロサービス共通基盤としてEKSを活用 ◼「WEBフロントシステム」「かんたん住宅ローン」など複数の重要システムが共通基盤上で稼動中 WEBフロントシステム かんたん住宅ローン Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 16
18. 2. EKS共通基盤のこれまで i. 初期構想/構築(2021年頃) ◼2020年に全面的なクラウド移行(AWS)を完了 ◼AWS移行の次のステップとしてクラウドネイティブ化を推進 狙い コラボレーション Fintech関連企業との効 果的なコラボレーション スピード 商品・サービスの迅速な 提供 デジタルトランス フォーメーション AI、BigData等を活用 システムコストの 削減 DBの運用費は8割以上 削減。3年で回収 ◼ ドコモSMTBネット銀行様資料より引用 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 17
19. 2. EKS共通基盤のこれまで i. 初期構想/構築(2021年頃) ◼クラウドネイティブ化を推進する共通基盤としてEKS共通基盤構築を計画 ◼この共通基盤には以下の要件があったが、全て満たした前例がNRIに無かった マイクロサービスに 対応する マルチベンダーの システムを稼働できる 運用時間が24時間365日の システムを稼働できる Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 18
20. 2. EKS共通基盤のこれまで i. 初期構想/構築(2021年頃) ◼要件に対するEKS共通基盤の設計ポイントは以下の通り 共通基盤の要件 インフラ設計のポイント マイクロサービスに 対応する ①サービスメッシュ(Linkerd)の導入 マルチベンダーの システムを稼働できる 運用時間が24時間365日の システムを稼働できる ②24/365・マルチベンダーレディな EKSバージョンアップ方式 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 19
21. 2. EKS共通基盤のこれまで ①サービスメッシュ(Linkerd)の導入 ◼マイクロサービスはコンテナ間通信をgRPCで行う事が一般的 ◼Kubernetesのロードバランス機能(ClusterIP)はTCPレベルの振り分けのみサポートするため、 コネクションを使い続けるgRPCだとリクエストが特定のコンテナに偏る ◼マイクロは、1つのコンテナで処理が完結するモノリスと比較して通信傍受のリスクが大きい ◼マルチベンダーでの運用を考慮すると、コンテナ間通信を暗号化する必要がある 共通基盤の要件 インフラ設計のポイント マイクロサービスに 対応する ①サービスメッシュ(Linkerd)の導入 マルチベンダーの システムを稼働できる 運用時間が24時間365日の システムを稼働できる ②24/365、マルチベンダーレディな EKSバージョンアップ方式の考案 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 20
22. 2. EKS共通基盤のこれまで ①サービスメッシュ(Linkerd)の導入 ◼ アプリケーション側でgRPC振り分け、暗号化を実装不要とするため、サービスメッシュを導入した ◼ サービスメッシュ製品の中から、通信の高速性・アプリケーション側の設定負荷を考慮してLinkerdを選択 ⚫ WEBフロントシステムの顧客体験を考慮すると、通信の高速性は最も重要 ⚫ LinkerdはCNCFの成熟(Graduated)プロジェクト ◼ LinkerdとBlue/GreenデプロイメントOSSであるArgo Rolloutsを組合せた、 複数コンテナを跨いだアプリケーションの稼働確認方式を考案 暗号化(TLS) Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 21
23. 2. EKS共通基盤のこれまで ②24/365・マルチベンダーレディなEKSバージョンアップ方式 ◼Kubernetesは頻繁なバージョンアップに追随する必要がある ◼運用時間が24時間365日のシステムに対応するため、 オンライン処理に影響無く、かつ即座にバージョンアップ/戻しを行う必要があった ◼マルチベンダーのシステムが複数稼働するため、 同期を取ったバージョンアップは日程調整が困難になる事が予想された 共通基盤の要件 インフラ設計のポイント マイクロサービスに 対応する ①サービスメッシュ(Linkerd)の導入 マルチベンダーの システムを稼働できる 運用時間が24時間365日の システムを稼働できる ②24/365、マルチベンダーレディな EKSバージョンアップ方式の考案 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 22
24. 2. EKS共通基盤のこれまで ②24/365・マルチベンダーレディなEKSバージョンアップ方式 ◼即時に切り戻しを行える様に、Blue/Green方式のEKSバージョンアップを採用した ◼AWS ALBの仕掛り中のリクエストを落さない仕様を利用し、ALBによる切り替えを採用した ◼システム単位で切り替えを行える様に、システム毎にALBを作成する構成を考案した ◼システム単位で切り替えられる様にするためには、クラスタ内でのシステム間通信を禁止する必 要があるため、Kubernetes機能のNetworkPolicyで制御を行う方式を考案した Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 23
25. 2. EKS共通基盤のこれまで ii. IPアドレスが涸渇してPodが起動できなくなった！(2023年) ◼ EKSのPodはVPCサブネットのIPアドレスを消費する(VPC CNIプラグインの仕様) ◼ マイクロサービス共通基盤の運用開始当初は障害時の影響分離のためEKSクラスタを複数構築する方針だったが、 その後システム間共用クラスタとして複数システムを載せる方針に変ったため涸渇が発生した ◼ IPアドレスが涸渇する事で、EKSワーカーノードが追加できなくなる、Podが起動できなくなるという問題が発生 EKSのVPC CNIプラグインは Pod毎にVPCサブネット内のIPアドレスを消費する Virtual private cloud (VPC) 専用クラスタ→システム間共用クラスタ Az-a サブネット(/24) IPが涸渇 Az-c サブネット(/24) Az-d サブネット(/24) EKSワーカーノード EKSワーカーノード EKSワー カーノード EKSワー カーノード IPアドレス IPアドレス IPアドレス IPアドレス IPアドレス IPアドレス IPアドレス Aシステム Bシステム Aシステム Bシステム Cシステム Bシステム Aシステム Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 24
26. 2. EKS共通基盤のこれまで IP枯渇に対する暫定対応 ◼ 暫定対策1: VPC CNIプラグインのパラメータチューニング ⚫ VPC CNIプラグインはPod起動より前にワーカーノード内にIPアドレスを前持って確保する仕様 ⚫ VPC CNIプラグインのパラメータを変更して、IPアドレスの事前確保の数を小さくする事で空きIPアドレスを増やしてしのぐ • WARM_IP_TARGET：warm pool として確保する IP アドレス数 • MINIMUM_IP_TARGET：Amazon VPC CNI のコンポーネントにより最低限確保する IP アドレス数 ◼ 暫定対策2: ワーカーノードに割り当てるサブネットの追加 ⚫ ワーカーノードの自動拡張機能は、新規ワーカーノードをどのサブネットで起動させるかの判断にIPアドレスの空き状況を見ない仕様 ⚫ その結果、小さいCIDRのサブネットにワーカーノードが偏って起動してしまい、再びIPアドレスが涸渇した 暫定対策1: VPC CNIプラグインのパラメータチューニング EKSワーカーノードはPod起動より前 にIPアドレスを複数確保する サブネット EKSワーカーノード ・WARM_IP_TARGET ・MINIMUM_IP_TARGET 暫定対策2: ワーカーノードに割り当てるサブネットの追加 Az-a サブネット(/24) EKS ワーカーノード Az-a サブネット(/21) EKS ワーカーノード NEW IPアドレス IPアドレス IPアドレス IPアドレス VPC CNIプラグイン IPアドレス サブネットを追加しても ワーカーノードが偏って起動する事で IPアドレスの涸渇が発生 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 25
27. 2. EKS共通基盤のこれまで IP枯渇に対する恒久対応 ◼ EKSクラスタ専用の/16のCIDRブロックを複数作成し、その中に極力大きい単一のサブネットを作成した ◼ EKSバージョンアップ時の新バージョンのEKSクラスタをこのサブネット上で構築した ◼ これにより、Podに割り振る事ができるIPアドレス数を大幅に大きくする事ができた VPC CIDRブロック(/16)① Az-a サブネット(AZ1用) CIDRブロック(/16)② Az-c サブネット(AZ1用) CIDRブロック(/16)③ Az-d サブネット(AZ1用) EKS ワーカーノード EKS ワーカーノード EKS ワーカーノード EKS ワーカーノード EKS ワーカーノード EKS ワーカーノード Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 26
28. 2. EKS共通基盤のこれまで iii. Prometheusマネージドコレクターの導入(2024年) ◼ AWSマネージドなPrometheus(Amazon Managed Service for Prometheus)はメトリクス格納ストレージやア ラート設定機能はマネージドなものの、メトリクス収集のPrometheusコンテナ(Pod)を起動させる必要があった ◼ Pod数の増加と合せて取得するメトリクスも増加 → Prometheusコンテナのリソース管理が大変に。。。 ◼ 2023/11リリースのPrometheusマネージドコレクターを導入する事で、Prometheusコンテナ管理が不要になり、管 理負荷を軽減することができた！ メトリクス取得のPrometheus Podが不要に！ EKSワーカーノード EKSワーカーノード メトリクス収集 メトリクス収集 メトリクス情報 保管 メトリクス情報 保管 アラート設定 アラート設定 Prometheus Amazon Managed Service Pod for Prometheus Amazon Managed Service for Prometheus Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 27
29. 2. EKS共通基盤のこれまで iv. EKS Automodeの導入(2025年) ◼ EKS Automodeとは、Kubernetes向けのノードオートスケーリングOSSであるKarpenterのマネージドサービス ⚫ Automodeは他にもALB Ingress ControllerやEBS CSI Driver等をマネージド化する。 ◼ 初期構築時から、ノードのオートスケリングとしてCluster Autoscalerを導入しているが、Automode(Karpenter)の 以下のメリットを考慮して導入 1. 高速なスケーリング • 従来のCluster Autoscaler（CA）より高速にノードをプロビジョニング • Podのスケジューリング要求に直接反応して、数秒でノードを起動 2. 柔軟なノード選択 • Auto Scaling Groupに依存せず、EC2インスタンスを直接起動 • Podの要求（CPU、メモリ、GPU等）に最適なインスタンスタイプを自動選択 • 複数のインスタンスタイプやアベイラビリティゾーンから最適なものを選択 3. コスト最適化 • Spot インスタンスの活用をサポート • ノードの統合（Consolidation）機能により、使用率の低いノードを自動的に最適化 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 28
30. 2. EKS共通基盤のこれまで iv. EKS Automodeの導入(2025年) ◼EKS Automodeは最大21日でワーカーノードが停止する仕様 ◼ワーカーノードの停止がアプリの処理に影響を与えない様にするためには、アプリPodのマニフェスト を適切に設定する必要がある ◼ポリシー管理OSSであるGatekeeperを用いて、リリース(Apply)時に自動で設定をチェック Podの安全な停止 (preStopフック) 冗長性を一時的にどの程度崩せるか (PodDisruptionBudget) Podの分散配置 (topologySpreadConstraints) Apply時に チェック Gatekeeper マニフェストファイル Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 29
31. 2. EKS共通基盤のこれまで ワーカーノードのハイブリット構成 ◼ 年次のEKSバージョンアップと合せてAutomode導入したため、対策が間にあわないコンテナもあった ◼ その様なコンテナ(Pod)を稼動させるために従来のワーカーノードも稼動させる様にした ◼ Podのマニフェスト設定(nodeSelector)でどちらのノードで稼動させるか選択できる様にした アプリ用ワーカーノード(Automode) アプリPod インフラ用ワーカーノード(従来のワーカーノード) kind: Deployment spec: template: spec: nodeSelector: node: automode ・・・ アプリPod アプリPod 管理系Pod NodePort ユーザー ALB アプリ用ワーカーノード(従来のワーカーノード) NGINX Service NGINX アプリPod kind: Deployment spec: template: spec: nodeSelector: node: normal ・・・ アプリPod アプリPod Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 30
32. 2. EKS共通基盤のこれまで Automodeの導入効果 ワーカーノード台数を約50％削減！! Automode移行を進める事で さらに削減可能な見込み！ Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 31
33. 3. EKS共通基盤のこれから Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 32
34. 3. EKS共通基盤のこれから Blue/Green方式のEKSバージョンアップの辛いところ 新Ver.EKSクラスタに移行するために、システム側に対応してもらう事がいろいろ発生する ⚫ 新Ver.クラスタにArgoCDで同期するため、Gitlabリポジトリを追加で作成し、マニフェストを移行 ⚫ 新Ver.クラスタにPodをデプロイ/稼動確認 etc... システム数が増加するごとに移行コストが増えてしまう EKSクラスタを跨いだリソースの引き継ぎに別途対応が必要 ⚫ Blue/Green方式は新Ver.クラスタを独立して構築するため ⚫ ステートフルワークロード（PV/PVC） は別途データバックアップ・移行が必要 EKSクラスタの利用用途が限られる(ステートレス) Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 33
35. 3. EKS共通基盤のこれから インプレース方式のEKSバージョンアップで迅速化・省力化を実現！ ◼2026/7/1のアップデートでEKSのバージョンロールバックが可能に！ ⚫ https://aws.amazon.com/jp/about-aws/whats-new/2026/07/amazon-eks-version-rollback/ ◼活用する事で、インプレース方式でのEKSバージョンアップが選択肢に ◼インプレース方式のバージョンアップには以下のメリットがある ⚫ AWS利用料/バージョンアップ工数の最適化(Blue/Green方式は一時的に2つのEKSクラスタを持つ必要あり) ⚫ フロンティアAIによる脆弱性攻撃に対抗した、迅速なアップグレードが可能 ◼ AWS公式サイトより引用 Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 34
36. 3. EKS共通基盤のこれから EKS Capabilitiesでリソース作成のセルフサービス化を加速！ ◼ 2025/12 リ リ ー ス の E K S C a p a b i l i t i e s は AWS Controllers for Kubernetes(ACK), Kube Resource Orchestrator(kro)をマネージドサービスとして利用可能に AWS Controllers for Kubernetes (ACK): AWS リソースをk8sリソース(マニフェスト)として定義・管理できる Kube Resource Orchestrator (kro): 複数のk8sリソースを束ねて抽象化されたk8sリソースを作成できる ACK kro --- --- Service S3バケット ユーザー --k8sマニフェスト ・ ・ ・ --ユーザー SQSキュー ・ ・ ・ 抽象化された k8sマニフェスト --Deployment --k8sマニフェスト SQSキュー リソースの統制を効かせつつセルフサービス化が可能に！プラットフォームがスケールする！ Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 35
37. まとめ インフラは作って終りではない！ 日々進化させていく事が重要！ 課題を常に頭に置きつつ、 最新技術にアンテナを張ることで、 課題解消のアイディアが生まれる Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 36