金融システムをモダナイズするためのAmazon Elastic Kubernetes Service(EKS)ノウハウ大全

Transcript

1. 金融システムをモダナイズするための Amazon Elastic Kubernetes Service(EKS)ノウハウ大全 Fin-JAWS 第39回 最新AWS金融業界の話題あれこれ 2025年5月29日 株式会社 野村総合研究所 マルチクラウドインテグレーション事業本部 金融基盤サービス部 エキスパートアーキテクト 高棹 大樹
2. 1 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 高棹 大樹 – Daiki Takasao NRI 金融基盤サービス部 • Elastic Kubernetes Service(EKS)を用いた金融機関 様向けマイクロサービス共通基盤 のインフラ担当 主な仕事 趣味 最近の困り事 • キャンプ • 筋トレ • 子供と遊ぶ(相手をしてくれる内に。。) • 飼っている猫が懐いてくれない
3. 2 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 近年、金融システムのモダナイズ案件が増えています オンプレ→クラウドへのリフトは一巡 クラウドのポテンシャルを最大限享受するフェーズへ 従来アーキテクチャの課題を解消し、 よりアジリティの高いシステム開発を実現 問題が発生すると 由々しき事態なるのが金融システム
4. 3 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 金融システムで求められる高度な要求 ①高度なセキュリティ ②高度な信頼性 エンドユーザ様のお金を扱うシステムなので、 守れない場合深刻な問題に繋がる
5. 4 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 金融システムに求められる高度な要求をEKSで満たすためには？ 自身の経験から考える高度なセキュリティ、信頼性を担保する インフラ設計のベストプラクティスを一部紹介します！ KubernetesとAWS両方のサービス・機能を 有効活用する必要あり！ これまでEKSを運用する上で 実際に直面した問題と解決策についてもお話しします!!
6. 5 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼ 2025年3月17日に開催された エンタープライズでこそ発揮されるKubernetesの真価。 日本初Kubestronautが語る導入ノウハウと社内定着のステップ ー現場事例を交えて徹底解説【NRI Tech Talks#3】 の登壇内容から抜粋したものです 本日お話しする内容について アーカイブ動画 スライド
7. 6 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. アジェンダ 高度なセキュリティをどの様に実現するか？ 01 高度な信頼性をどの様に実現するか？ 02 EKS運用で直面した問題とその解決策 03
8. 7 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 7 1. 高度なセキュリティをどの様に実現するか？
9. 8 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. EKSクラスタ コントロールプレーン ⑤EKSクラスタのセキュリティ対策 ワーカーノード ④ワーカーノードのセキュリティ対策 Aシステム用 Namespace ③Namespace間のセキュリティ対策 Bシステム用 Namespace 各レイヤでのセキュリティ対策 1. 高度なセキュリティをどの様に実現するか？ ①コンテナのセキュリティ対策 コンテナ ②コンテナ間のセキュリティ対策 コンテナ
10. 9 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ①コンテナのセキュリティ対策 外部シークレットストアの利用 1. 高度なセキュリティをどの様に実現するか？ ◼ K8sのSecretオブジェクト内のシークレット情報はBase64エンコーディングで保存される ◼ そのため、SecretオブジェクトのマニフェストファイルをGithub等のリポジトリで管理してしまうと、そのマニフェストが漏 洩した際に致命的なセキュリティインシデントになる ⚫ マニフェストが漏洩してしまった場合、base64デコードで簡単にシークレット情報を見れてしまうため apiVersion: v1 kind: Secret metadata: name: sample-secret type: Opaque data: password: UEBzc3dvcmQK # "P@ssword" をbase64エンコード Secretのマニフェストファイル リポジトリ
11. 10 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ①コンテナのセキュリティ対策 外部シークレットストアの利用 1. 高度なセキュリティをどの様に実現するか？ ◼ Secrets Store CSI Driverを使ってシークレットをEKSクラスタ外部のシークレットストアで管理する ◼ AWS Secrets and Configuration Provider (ASCP)でAWS Secret Managerで管理可能 EKSクラスタ Aシステム用 Namespace SecretProviderClass ※Gitリポジトリ管理可能 シークレット1 シークレット2 ※自動生成 Key1 Key2 環境変数or Volume としてアクセス Secrets Store CSI Driver AWS Secrets Manager シークレットの値 シークレット1 シークレットの値 シークレット2 ASCP 紐付け設定 紐付け設定
12. 11 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ③Namespace間のセキュリティ対策 K8s/AWSリソースのアクセス制御 1. 高度なセキュリティをどの様に実現するか？ ◼ 単一クラスタ内で複数システムを稼動させる構成ではK8s/AWSリソースが混在 ◼ 情報漏洩等のリスクを考慮し、他システムのリソースにはアクセスを制限する必要がある EKSクラスタ Aシステム用 Namespace Bシステム用 Namespace Aシステム用 S3バケット Bシステム用 S3バケット Bシステム用 SQSキュー Aシステム用 SQSキュー Aシステム 管理者 Bシステム 管理者 K8sリソース AWSリソース 他システムリソースにアクセス可能だとセキュリティリスク
13. 12 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ③Namespace間のセキュリティ対策 管理者→K8sリソースのアクセス制御 1. 高度なセキュリティをどの様に実現するか？ ◼ K8sのRBACリソースでシステム間の権限分離 ◼ EKS access entryでRBACとIAMを紐付け。IAMロールで認証、RBACで認可制御を行う EKSクラスタ Aシステム用 Namespace Role RoleBinding EKS Access Entry Group Bシステム用 Namespace Role RoleBinding EKS Access Entry Group Aシステム用IAMロール Bシステム用IAMロール 紐付け 紐付け Aシステム 管理者 Bシステム 管理者
14. 13 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ③Namespace間のセキュリティ対策 K8sリソース→AWSリソースのアクセス制御 1. 高度なセキュリティをどの様に実現するか？ ◼ EKS Pod IdentityでServiceAccount とIAMロールを紐付け ◼ ServiceAccountで認証、IAMロールで認可制御を行う EKSクラスタ Aシステム用 Namespace Aシステム用 S3バケット Bシステム用 S3バケット Bシステム用 SQSキュー Aシステム用 SQSキュー EKS Pod Identity Aシステム用IAMロール Aシステム用ServiceAccount Bシステム用 Namespace EKS Pod Identity Bシステム用IAMロール Bシステム用ServiceAccount 紐付け 紐付け
15. 14 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 14 2. 高度な信頼性をどの様に実現するか？
16. 15 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 高度な信頼性を得るための考慮ポイント 2. 高度な信頼性をどの様に実現するか？ 複数リージョン、AZへのリソースの分散配置 その1 リリース時に問題があった際に 即座にリリース前の状態に戻せる様にする その2 アプリエラー件数ゼロのEKSクラスタメンテナンス その3 Blue/Green デプロイメントを活用
17. 16 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その1. リソースの分散配置 複数リージョンへの分散配置 2. 高度な信頼性をどの様に実現するか？ ◼ 各リージョンにEKSクラスタ、AWSリソースを配置 ◼ Route53のレコードを書き換える事でDR発動 ◼ AWSデータストアのリージョン間レプリケーションの機能を活用してサイト間のデータ同期を行う EKSクラスタ 正サイトリージョン EKSクラスタ DRサイトリージョン EFSファイルシステム EFSファイルシステム レプリケーション S3バケット S3バケット レプリケーション Auroraクラスタ Auroraクラスタ レプリケーション Amazon Route 53 通常時 エンドポイント エンドポイント
18. 17 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その1. リソースの分散配置 複数アベイラビリティーゾーン(AZ)への分散配置 2. 高度な信頼性をどの様に実現するか？ ◼ ワーカーノードをマルチAZ構成で配置(EKSノードグループにマルチAZなサブネットを複数指定) ◼ Podを複数台起動させるだけでは不十分。偏る可能性あり。podAntiAffinityを設定してワーカーノード、AZ間で分散配置する リージョン AZ 1 AZ 2 AZ 3 EKSノードグループ EKSワーカーノード EKSワーカーノード EKSワーカーノード spec: replicas: 3 template: spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: topologyKey: failure- domain.beta.kubernetes.io/zone weight: 100 - podAffinityTerm: topologyKey: kubernetes.io/hostname weight: 100 マニフェストファイル
19. 18 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その2. 即座にリリース前の状態に戻せる様にする 2つのレイヤでのBlue/Greenデロイメント 2. 高度な信頼性をどの様に実現するか？ 現Ver.EKSクラスタ 現Ver.アプリケーション 新Ver.アプリケーション 新Ver.アプリに切り替え 新Ver.EKSクラスタ 新Ver.クラスタに切り替え アプリケーション Blue/Greenデロイメントによるアプリリリース Blue/GreenデプロイメントによるEKSクラスタバージョンアップ
20. 19 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その2. 即座にリリース前の状態に戻せる様にする ALBの機能を活用した接続先EKSクラスタの切り替え 2. 高度な信頼性をどの様に実現するか？ ◼ EKSクラスタの切り替えに使用するため、Application Load Balancer(ALB)はK8Sリソースとしてでは無くスタンドアローンで構築 ⚫ Ingressリソースとして、EKSクラスタ内で稼動するNginx Ingress Controllerを導入 ◼ エンドユーザからの接続を待受けるリスナールールを現EKSクラスタのターゲットグループに紐付け ◼ 稼動確認用Cookie、ヘッダ付与で新EKSクラスタに振り分けるリスナールールも用意 ALB リスナー 現EKSクラスタ用 ターゲットグループ 新クラスタ用 ターゲットグループ リスナールール リクエストに稼動確認用Cookie or ヘッダが付与されていたら デフォルトルール 優先度:高 優先度:低 アプリ開発者 エンドユーザ 現EKSクラスタ Node Port NGINX Ingress Controller 新EKSクラスタ Node Port NGINX Ingress Controller
21. 20 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その2. 即座にリリース前の状態に戻せる様にする ALBの機能を活用した接続先EKSクラスタの切り替え 2. 高度な信頼性をどの様に実現するか？ ◼ デフォルトルールの振り分け先を新クラスタ用ターゲットグループに切り替える事で、エンドユーザからの通信を新EKSクラスタに向け る事ができる ◼ ターゲットグループ切替前からの仕掛かり中リクエスト、切替え中の新規リクエストは現EKSクラスタで引続き 処理されるのでサービス閉塞すること無く切替える事が可能(ALBの仕様) ALB リスナー 現EKSクラスタ用 ターゲットグループ 新クラスタ用 ターゲットグループ リスナールール リクエストに稼動確認用Cookie or ヘッダが付与されていたら デフォルトルール 優先度:高 優先度:低 アプリ開発者 エンドユーザ 現EKSクラスタ Node Port NGINX Ingress Controller 新EKSクラスタ Node Port NGINX Ingress Controller 新Ver.クラスタに切り替え
22. 21 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 21 3. EKS運用で直面した問題とその解決策
23. 22 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① IPアドレスが涸渇してPodが起動できなくなった！ どんな課題だった？ 3. EKS運用で直面した問題とその解決策 ◼ EKSのPodはVPCサブネットのIPアドレスを消費する(VPC CNIプラグインの仕様) ◼ マイクロサービス共通基盤の運用開始当初は障害時の影響分離のためEKSクラスタを複数構築する方針だったが、その後シス テム間共用クラスタとして複数システムを載せる方針に変ったため涸渇が発生した ◼ IPアドレスが涸渇する事で、EKSワーカーノードが追加できなくなる、Podが起動できなくなるという問題が発生 Virtual private cloud (VPC) Az-a サブネット(/24) EKSワーカーノード IPアドレス IPアドレス IPアドレス EKSワーカーノード IPアドレス EKSのVPC CNIプラグインは Pod毎にVPCサブネット内のIPアドレスを消費する Az-c サブネット(/24) EKSワー カーノード IPアドレス Az-d サブネット(/24) EKSワー カーノード IPアドレス IPが涸渇 専用クラスタ→システム間共用クラスタ Aシステム Aシステム Aシステム Bシステム Bシステム Bシステム IPアドレス Cシステム
24. 23 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① IPアドレスが涸渇してPodが起動できなくなった！ どうやって解決した？(暫定対応) 3. EKS運用で直面した問題とその解決策 ◼ 暫定対策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アドレスが涸渇した サブネット EKSワーカーノード IPアドレス IPアドレス EKSワーカーノードはPod起動より前 にIPアドレスを複数確保する VPC CNIプラグイン ・WARM_IP_TARGET ・MINIMUM_IP_TARGET Az-a サブネット(/24) Az-a サブネット(/21) NEW EKS ワーカーノード EKS ワーカーノード IPアドレス IPアドレス IPアドレス サブネットを追加しても ワーカーノードが偏って起動する事で IPアドレスの涸渇が発生 暫定対策1: VPC CNIプラグインのパラメータチューニング 暫定対策2: ワーカーノードに割り当てるサブネットの追加
25. 24 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① Podが想定以上稼動してIPアドレスが涸渇した! どうやって解決した？(恒久対応) 3. EKS運用で直面した問題とその解決策 ◼ EKSクラスタ専用の/16のCIDRブロックを複数作成し、その中に極力大きい単一のサブネットを作成した ◼ EKSバージョンアップ時の新バージョンのEKSクラスタをこのサブネット上で構築した ◼ これにより、Podに割り振る事ができるIPアドレス数を大幅に大きくする事ができた VPC CIDRブロック(/16)① Az-a サブネット(AZ1用) EKS ワーカーノード EKS ワーカーノード CIDRブロック(/16)② Az-c サブネット(AZ1用) EKS ワーカーノード EKS ワーカーノード CIDRブロック(/16)③ Az-d サブネット(AZ1用) EKS ワーカーノード EKS ワーカーノード
26. 25 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ② Prometheus Server Podがクラッシュした! どんな課題だった？ 3. EKS運用で直面した問題とその解決策 ◼ EKSクラスタ内で稼動する全Podのメトリクス収集とアラート通知にAmazon Managed Prometheus(AMP)を利用 ◼ AMPはサービス開始当初、メトリクス収集のためのPrometheus Server Podをセルフホストで稼動させる必要があった ◼ アプリPod数が増大する事でPrometheus Server Podのメモリ容量が徐々に逼迫し、最終的にクラッシュする事態に Amazon Managed Service for Prometheus(AMP) EKSワーカーノード メトリクス情報 保管 アラート設定 メトリクス収集 Prometheus Server Pod Aシステム Bシステム Cシステム Aシステム Bシステム Cシステム ・ ・ ・ メモリ逼迫で クラッシュ
27. 26 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ② Prometheus Server Podがクラッシュした! どうやって解決した？ 3. EKS運用で直面した問題とその解決策 ◼ Prometheus Server Podのメモリ容量をアプリPodが増える度に随時拡張していたが、運用負担になる ◼ AMPは2023年11月26日からマネージドスクレイパーが利用可能 ◼ マネージドスクレイパーはEKSクラスタ外からメトリクス収集を行うAWSマネージドサービス ◼ EKSバージョンアップのタイミングと合せてマネージドスクレイパーを導入した ◼ これにより、EKSクラスタ内で自前でPrometheus Server Podを運用する必要が無くなり、運用負荷を減らす事できた メトリクス取得のPrometheus Podが不要に！ Amazon Managed Service for Prometheus EKSワーカーノード メトリクス情報 保管 アラート設定 メトリクス収集 Aシステム Bシステム Cシステム Aシステム Bシステム Cシステム ・ ・ ・ マネージド スクレイパー
28. 27 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼金融システムには高度なセキュリティ、信頼性が必要 ◼高度な要求をEKS環境で満たすためには、、 まとめ クラスタ内の各層でセキュリティ対策を実施！ 高度なセキュリティ 分散配置、Blue/Greenデプロイメント、Podの安全停止設定 を活用！ 高度な信頼性
29. 28 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. まとめ EKS運用はIaaSベースのシステムとは 種類の異なる問題に直面する 新機能を活用して EKS構成を継続的に進化させる事が重要! EKS Auto Modeの導入を検討中