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

金融システムをモダナイズするための Amazon Elastic Kubernetes Service(EKS)ノウハウ大全 TECH PLAY NRI Tech Talks#3
2025年3月17日株式会社野村総合研究所マルチクラウドインテグレーション事業本部金融基盤サービス部エキスパートアーキテクト高棹大樹

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

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

NRIグループ４つの事業 NRIの会社紹介コンサルティング CONSULTING 金融ソリューション FINANCIAL IT SOLUTIONS 1965年の創業以来、シンクタンクとしての深い知見と先見の明を活かし、官と民のさまざまな分野で戦略策定・政策立案を支援してきました。また、政策・産業・事業・テクノロジーへの深い理解とお客様との対話を通じ、課題解決に向けた実行可能な施策を提案し、伴走しています。「VUCA」の時代、ビジネスを次のステージへと導くには、先見性に裏付けられたマネジメントコンサルティングと、デジタルトランスフォーメーションや事業革新を支援するシステムコンサルティングの先進性や実行力が不可欠です。これらは、お客様の持続可能な成功を支え、未来へと導くための私たちならではのコミットメントです。未来を見据え、今を変えることで、私たちは最良のパートナーであり続けることを目指します。 NRIグループは50年にわたり金融機関における情報システムの「所有から利用へ」の流れを牽引してきました。金融ビジネスを取り巻く環境変化を敏感に察知する研究員やコンサルタント、ITソリューションサービスを提供するビジネスアナリストやデジタル人材の連携によって次世代ソリューションを生み出し続け、金融機関の事業継続を多方面から支えています。近年では、金融機関や政策当局、異業種プレーヤーなどとの価値共創により、金融機能の変革に取り組んでいます。金融は、社会の重要インフラです。進化し続けるデジタル技術との相性を常に考えながら、安定かつ先進的な社会インフラを実現し、社会課題に果敢にチャレンジしていきます。

NRIグループ４つの事業 NRIの会社紹介産業ITソリューション INDUSTRIAL IT SOLUTIONS IT基盤サービス IT PLATFORM SERVICES 産業分野の業界トップ企業のビジネスパートナーとして、コンサルティングからシステム開発や運用まで、一貫したサービスを提供しています。コンサルタントとエンジニアが共同でお客様のビジネス環境やデータを分析しながら、最適なITソリューションを提供しています。また、コンサルティング部門から運用部門まで、NRI グループのリソースをインテグレーションし、お客様のデジタル戦略を柔軟かつスピーディーに実現します。長年にわたってミッションクリティカルなシステムを構築・運用してきた経験と実績で、これからもお客様の事業インフラとしてのシステム基盤を支えていきます。事業活動の変化やIT技術の進化とともに、システムがクラウド化・巨大化・複雑化する中で、その土台となるIT基盤は、ますます重要になっています。NRIグループは先進的な技術を見通し、戦略的にサービスやソリューションに取り込み、お客様の成長や変革の実現をサポートします。マルチクラウドを含むシステム全体を運営するマネージドサービスやお客様の働く環境を創り出すデジタルワークプレイス事業などを展開しています。また、先進技術の調査・研究も積極的に実施しています。さらに、お客様が直面するセキュリティ課題の解決や総合的なセキュリティレベルの向上を支援します。 NRIグループはコンサルティングやさまざまなITソリューションの提供を通じて、社会や産業を確かな明日へ導くとともに、世界中のお客様と新しい価値を共創しています。

近年、金融システムのモダナイズ案件が増えていますオンプレ→クラウドへのリフトは一巡クラウドのポテンシャルを最大限享受するフェーズへ従来アーキテクチャの課題を解消し、よりアジリティの高いシステム開発を実現問題が発生すると由々しき事態なるのが金融システム

金融システムで求められる高度な要求 ①高度なセキュリティ ②高度な信頼性エンドユーザ様のお金を扱うシステムなので、守れない場合深刻な問題に繋がる

◼ AWS公開の金融システムで求められるセキュリティと信頼性に関するベストプラクティス集 ⚫ 2022/10/3に初版であるv1.0.0、2024/11/4にv1.5.0がリリース ⚫ https://github.com/aws-samples/baseline-environment-on-aws-for-financial-services-institute ◼ Elastic Container Service (ECS)の例はあるものの、EKSを扱ったものは現状無い。 AWS 金融リファレンスアーキテクチャ日本版 https://github.com/aws-samples/baseline-environment-on-aws-for-financial-services-institute より引用

◼運用コストと利用可能な機能の幅、相互運用性を考慮して選択する ECS or EKS ？ ECS (Elastic Container Service) EKS (Elastic Kubernetes Service) 利用可能な機能の幅 △ AWSが提供しているサービスの機能のみ利用可能 AWS提供サービスに加えてKubernetesやその上で稼動するクラウドネイティブOSSを利用可能マルチクラウド、オンプレミスとの相互運用性 △ ECSはAWS独自サービス Kubernetes APIリソースはマルチクラウド、オンプレミスで使用可能運用コストクラスタのバージョンアップは実施不要 △ Kubernetesのバージョンリリースに追従して定期的にクラスタのバージョンアップを行う必要がある

金融システムに求められる高度な要求をEKSで満たすためには？自身の経験から考える高度なセキュリティ、信頼性を担保するインフラ設計のベストプラクティスを一部紹介します！ KubernetesとAWS両方のサービス・機能を有効活用する必要あり！これまでEKSを運用する上で実際に直面した問題と解決策についてもお話しします!!

◼ 話すこと ⚫ 金融システムを載せる事ができるEKS中心のITインフラを構築するために有用なノウハウ ⚫ EKSを複数年運用した中で直面した問題とその解決方法 ◼ 話さないこと ⚫ EKSを用いて構築したITインフラ上で稼動するアプリケーションを開発を行う上でのノウハウ ⚫ Kubernetesの基礎知識(Pod,Deployment,Serviceとは？ Etc..) ⚫ AWSの基礎知識(EC2,lAMとは？ Etc..) ⚫ Kubernetes、EKSに関連しないITインフラ設計ノウハウ ◼ 注意事項 ⚫ あくまで高度なセキュリティ、信頼性を獲得するための一例を示すものであり、獲得するための対応方法が網羅されている訳では無い点ご了承ください ⚫ 金融システムのITインフラを設計する上で必要な考慮点・設計ポイントが網羅されている訳では無い点ご了承ください話すこと・話さないこと・注意事項

◼ AWS上でAmazon Elastic Kubernetes Service (Amazon EKS)を利用 ◼ FargateではなくEC2でワーカーノードを稼動 ◼ 個別のNamespaceが割り当てられた複数システムが稼動 ◼ AuroraやS3、SQS等のAWSリソースにアプリケーションPodからアクセスする前提となるインフラ構成概要ワーカーノード(EC2) Amazon Elastic Kubernetes Service (Amazon EKS) Aシステム用 Namespace Bシステム用 Namespace Aシステム用 S3バケット Aシステム用 SQSキュー Bシステム用 S3バケット Bシステム用 SQSキュー

◼2024年11月28、29日に開催されたCloudNative Days Winter 2024での登壇内容「レガシーな金融システムをKubernetesを使ってクラウドネイティブ化するためのノウハウ大全」から抜粋したものです ◼登壇のアーカイブ動画、登壇スライドは以下のQAコードからアクセスできます本日お話しするインフラ設計のベストプラクティスについてアーカイブ動画スライド

アジェンダ高度なセキュリティをどの様に実現するか？ 01 高度な信頼性をどの様に実現するか？ 02 EKS運用で直面した問題とその解決策 03

EKSクラスタコントロールプレーン ⑤EKSクラスタのセキュリティ対策ワーカーノード ④ワーカーノードのセキュリティ対策 Aシステム用 Namespace ③Namespace間のセキュリティ対策 Bシステム用 Namespace 各レイヤでのセキュリティ対策 1. 高度なセキュリティをどの様に実現するか？ ①コンテナのセキュリティ対策コンテナ ②コンテナ間のセキュリティ対策コンテナ

①コンテナのセキュリティ対策外部シークレットストアの利用 1. 高度なセキュリティをどの様に実現するか？ ◼ K8sのSecretオブジェクト内のシークレット情報はBase64エンコーディングで保存される ◼ そのため、SecretオブジェクトのマニフェストファイルをGithub等のリポジトリで管理してしまうと、そのマニフェストが漏洩した際に致命的なセキュリティインシデントになる ⚫ マニフェストが漏洩してしまった場合、base64デコードで簡単にシークレット情報を見れてしまうため apiVersion: v1 kind: Secret metadata: name: sample-secret type: Opaque data: password: UEBzc3dvcmQK # "P@ssword" をbase64エンコード Secretのマニフェストファイルリポジトリ

①コンテナのセキュリティ対策外部シークレットストアの利用 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 紐付け設定紐付け設定

②コンテナ間のセキュリティ対策通信の暗号化 1. 高度なセキュリティをどの様に実現するか？ ◼ Pod間の通信はワーカーノードを跨ぐ事もある ◼ 1つの処理を複数Podで連携して行うマイクロサービスアーキテクチャは、1つのPodで処理が完結するモノリスアーキテクチャと比較して通信傍受のリスクが大きい EKSワーカーノード EKSワーカーノードサービス1 サービス2 サービス3 ワーカーノードを跨いで Pod間の通信が行われる

②コンテナ間のセキュリティ対策通信の暗号化 1. 高度なセキュリティをどの様に実現するか？ ◼ 通信傍受の対策として、Pod間通信を全て暗号化させる事が有効 ◼ 稼動させるPodが多くなるに従い、個別の暗号化鍵管理はどんどん大変になる ◼ Istio, Cilium, Linkerd等のサービスメッシュを導入する事でPod個別の鍵管理が不要な暗号化(mTLS)が可能 EKSワーカーノード EKSワーカーノードアプリコンテナサービスメッシュコンテナ (サイドカー) アプリコンテナサービスメッシュコンテナ (サイドカー) アプリコンテナサービスメッシュコンテナ (サイドカー) mTLS通信 mTLS通信サービスメッシュコントロールプレーン暗号化鍵

③Namespace間のセキュリティ対策 K8s/AWSリソースのアクセス制御 1. 高度なセキュリティをどの様に実現するか？ ◼ 単一クラスタ内で複数システムを稼動させる構成ではK8s/AWSリソースが混在 ◼ 情報漏洩等のリスクを考慮し、他システムのリソースにはアクセスを制限する必要がある EKSクラスタ Aシステム用 Namespace Bシステム用 Namespace Aシステム用 S3バケット Bシステム用 S3バケット Bシステム用 SQSキュー Aシステム用 SQSキュー Aシステム管理者 Bシステム管理者 K8sリソース AWSリソース他システムリソースにアクセス可能だとセキュリティリスク

③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システム管理者

③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 紐付け紐付け

④ワーカーノードのセキュリティ対策振る舞い検知 1. 高度なセキュリティをどの様に実現するか？ ◼ 振る舞い検知とは、システムやネットワーク上でのユーザーやデバイスの行動パターンを監視し、異常や潜在的な脅威を検出する方法 ◼ 通常の振る舞いから逸脱した行動が検知されると監視ツール経由でアラートが送信 ◼ ゼロデイ攻撃等、従来のシグネチャベースの対策では検出が難しい、未知の脅威に対して有効な手法システム未知の脅威通常の振る舞いから逸脱した行動権限昇格対話シェル実行怪しいコマンド実行怪しいツール実行 Etc…. 検知監視ツール

④ワーカーノードのセキュリティ対策振る舞い検知 1. 高度なセキュリティをどの様に実現するか？ ◼ GuardDutyランタイムモニタリングでEKSワーカーノード(EC2)とコンテナの振る舞い検知が可能 ◼ aws-guardduty-agent(Daemonset)を導入するのみで自動で検知 EKSワーカーノード amazon-guardduty Namespace aws-guardduty-agent Aシステム用 Namespace コンテナ Amazon GuardDuty OS Bシステム用 Namespace コンテナ EKSランタイムモニタリング:有効

⑤EKSクラスタのセキュリティ対策監査ログのリアルタイムモニタリング 1. 高度なセキュリティをどの様に実現するか？ ◼ 監査ログとはシステム内の一連のイベントやアクションを記録したログファイル ◼ 監査ログのリアルタイムモニタリングは、不正アクセスや異常な活動の早期発見に有効 ◼ AWSリソースに対しての監査ログはAWS CloudTrailで取得可能だが、EKSクラスタ内のK8sリソースに対しての監査ログは別途出力されるため個別に対策が必要 S3バケット SQSキュー EKSクラスタ AWSリソースへの操作は CloudTrailに記録される K8sリソースへの操作は EKSクラスタ監査ログに記録される

⑤EKSクラスタのセキュリティ対策監査ログのリアルタイムモニタリング 1. 高度なセキュリティをどの様に実現するか？ ◼ Guardduty EKSプロテクションでK8sリソース操作の監査ログモニタリングが可能 ◼ EKSコントロールプレーン内のkube-apiserverが出力する監査ログをGuardDutyがモニタリング ◼ CloudTrailと併用する事でシステム全体の監査ログモニタリングが可能になる Amazon GuardDuty EKSクラスタコントロールプレーン ※AWSマネージド EKSワーカーノードクラスタ管理者アプリ開発者 kubectl kubectl YYYYMMDD XXPod create ….. ….. 監査ログ EKS監査ログモニタリング:有効

高度な信頼性を得るための考慮ポイント 2. 高度な信頼性をどの様に実現するか？複数リージョン、AZへのリソースの分散配置その1 リリース時に問題があった際に即座にリリース前の状態に戻せる様にするその2 アプリエラー件数ゼロのEKSクラスタメンテナンスその3 Blue/Green デプロイメントを活用

その1. リソースの分散配置複数リージョンへの分散配置 2. 高度な信頼性をどの様に実現するか？ ◼ 各リージョンにEKSクラスタ、AWSリソースを配置 ◼ Route53のレコードを書き換える事でDR発動 ◼ AWSデータストアのリージョン間レプリケーションの機能を活用してサイト間のデータ同期を行う EKSクラスタ正サイトリージョン EKSクラスタ DRサイトリージョン EFSファイルシステム EFSファイルシステムレプリケーション S3バケット S3バケットレプリケーション Auroraクラスタ Auroraクラスタレプリケーション Amazon Route 53 通常時エンドポイントエンドポイント

その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 マニフェストファイル

その2. 即座にリリース前の状態に戻せる様にする 2つのレイヤでのBlue/Greenデロイメント 2. 高度な信頼性をどの様に実現するか？現Ver.EKSクラスタ現Ver.アプリケーション新Ver.アプリケーション新Ver.アプリに切り替え新Ver.EKSクラスタ新Ver.クラスタに切り替えアプリケーション Blue/Greenデロイメントによるアプリリリース Blue/GreenデプロイメントによるEKSクラスタバージョンアップ

その2. 即座にリリース前の状態に戻せる様にする ArgoRolloutsを用いたBlue/Greenデロイメント 2. 高度な信頼性をどの様に実現するか？ ◼ ArgoRolloutsで新バージョンアプリケーションの自動作成とコマンドによる Blue/Green切り替えが可能 apiVersion: v1 kind: Service metadata: name: blue-green-svc spec: type: ClusterIP selector: app: blue-green ServiceのマニフェストファイルアプリケーションRolloutのマニフェストファイル apiVersion: argoproj.io/v1alpha1 kind: Rollout spec: template: metadata: labels: app: blue-green strategy: blueGreen: activeService: blue-green-svc 現Ver.アプリケーションReplicaSet 新Ver.アプリケーションReplicaSet rollouts promoteコマンドで Blue/Green切り替え

その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

その2. 即座にリリース前の状態に戻せる様にする ALBの機能を活用した接続先EKSクラスタの切り替え 2. 高度な信頼性をどの様に実現するか？ ◼ デフォルトルールの振り分け先を新クラスタ用ターゲットグループに切り替える事で、エンドユーザからの通信を新EKSクラスタに向ける事ができる ◼ ターゲットグループ切替前からの仕掛かり中リクエスト、切替え中の新規リクエストは現EKSクラスタで引続き処理されるのでサービス閉塞すること無く切替える事が可能(ALBの仕様) ALB リスナー現EKSクラスタ用ターゲットグループ新クラスタ用ターゲットグループリスナールールリクエストに稼動確認用Cookie or ヘッダが付与されていたらデフォルトルール優先度:高優先度:低アプリ開発者エンドユーザ現EKSクラスタ Node Port NGINX Ingress Controller 新EKSクラスタ Node Port NGINX Ingress Controller 新Ver.クラスタに切り替え

その3. アプリエラー件数ゼロのEKSクラスタメンテナンス Podの安全停止設定 2. 高度な信頼性をどの様に実現するか？ ◼ EKSクラスタを維持運用する中では、EC2インスタンスのリタイアメント等でワーカーノードを停止させる場面がある ◼ ノード上で起動しているPodを他のワーカーノードに退避させる必要あり ◼ Podの退避は実際にはPodが停止し、その後別ワーカーノードでPodが起動する事で実現される ◼ このPodの停止時にもシステムエラーは許容できないが、Serviceの仕様上Pod停止前にリクエストの振り分け対象から該当Podを手動で切離す事はできない EKSワーカーノード EKSワーカーノードリタイアメントで停止する必要あり ①Pod停止 ②別ワーカーノードでPod起動 Pod停止前にリクエストの振り分け対象から該当Podを手動で切離す事はできない

その3. アプリエラー件数ゼロのEKSクラスタメンテナンス Podの安全停止設定 2. 高度な信頼性をどの様に実現するか？ ◼ 受入れたリクエストの処理が完了する時間分、Podが停止を待つ設定を入れる ◼ 具体的には、アプリケーションのマニフェストファイルに、一律でPreStopフックでsleepコマンド実行、terminationGracePeriodSecondを明示的に指定する ⚫ PreStopフックは、コンテナが停止する前に任意のコマンドを実行できる機能この機能を利用して、アプリPodがkubernetesのServiceから切り離され、受け取ったリクエストの処理が終了するまでの時間コンテナ停止を待つ様にsleepコマンドを実行 ⚫ terminationGracePeriodSecondsは、Podが強制終了されるまでの時間を設定するもの Pod停止の前にリクエストの処理が完了する時間分待つ設定を入れる PreStopフックでsleepコマンド実行 terminationGracePeriodSeconds

住信SBIネット銀行様の事例 3. EKS運用で直面した問題とその解決策 ◼ 次世代のマイクロサービス共通基盤としてEKSを採用 ◼ 「WEBフロントシステム※」「かんたん住宅ローン」をはじめとした複数の重要システムが共通基盤上で稼動中 ◼ マイクロサービス共通基盤を数年運用する中で発生したEKSに関連する問題とその解決方法についてお話ししますかんたん住宅ローン ※現在一部機能がマイクロサービス共通基盤上で稼動。機能を順次移行中。 WEBフロントシステム※

① 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システム

① 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: ワーカーノードに割り当てるサブネットの追加

① 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 ワーカーノード

② 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システム・・・メモリ逼迫でクラッシュ

② 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システム・・・マネージドスクレイパー

③ 別AZに移動したPrometheus Server Podが起動しない！どんな課題だった？ 3. EKS運用で直面した問題とその解決策 ◼ マネージドスクレイパーに移行する前に発生した問題 ◼ ワーカーノードのメンテでPrometheus Server Podを退避させたところ、別AZのワーカーノードにスケジューリングされた ◼ Prometheus Server PodはEBSボリュームをマウントする仕様 ◼ EBSボリュームはAZリソースなのでAZを跨いでマウントする事ができない ◼ 別AZ上のPrometeheus Server PodはPVをマウントできずに起動に失敗した Az-a EKS ワーカーノードメンテ対象 Prometheus Server Pod EBSボリュームマウント Az-c EKS ワーカーノード Prometheus Server Pod 起動失敗 EBSボリュームはAZリソースなのでAZを跨いでマウントできない Drainコマンドで退避マウント

③ 別AZに移動したPrometheus Server Podが起動しない！どうやって解決した？ 3. EKS運用で直面した問題とその解決策 ◼ この問題が発生しない様にワーカーノードのメンテ手順を修正した ◼ 事前に同じAZにワーカーノードを起動させ、そこにPrometheus Sever Podを退避させる様にした ◼ マネージドスクレイパーを導入する事でPrometheus Server Podが無くなったため、現在はこの運用は不要になっています ◼ EBSボリュームをマウントするPodを運用する際には注意が必要 Az-a EKS ワーカーノードメンテ対象 Prometheus Server Pod EBSボリュームマウント EKS ワーカーノード Prometheus Server Pod Drainコマンドで退避マウント Az-c EKS ワーカーノード NEW

④ CoreDNSがパニック! どんな課題だった？ 3. EKS運用で直面した問題とその解決策 ◼ KubernetesにとってDNSによる名前解決はクラスタ内のPod間通信の必須要素 ◼ EKSクラスタ内部で名前解決を行うプラグインであるCoreDNSにパニックが発生し、名前解決ができない問題が発生 ◼ Pod間通信に影響が出てしまう事態に。。。 EKSクラスタアプリA アプリB コンテナ間通信には CoreDNSでの名前解決が必要 CoreDNSアドオンアプリBのサービス 10.100.1.XXX アプリCのサービス 10.100.2.XXX ・・・パニック発生

④ CoreDNSがパニック! どうやって解決した？ (暫定対応) 3. EKS運用で直面した問題とその解決策 ◼ CoreDNSはパニック状態になった事が判るPrometheusメトリクス(coredns_panics_total)を出力する ◼ coredns_panics_totalを収集/アラートする様に、メトリクス収集設定/アラート設定をAMPに追加 ◼ パニック状態を検知したら手動でCoreDNSコンテナを再起動する運用を行った EKSワーカーノード CoreDNSアドオンパニック発生 Amazon Managed Service for Prometheus(AMP) アラート設定・coredns_panics_total > 0 ならアラート・・・マネージドスクレイパーメトリクス収集設定・CoreDNS Podのcoredns_panics_total を収集・・・

④ CoreDNSがパニック! どうやって解決した？ (恒久対応) 3. EKS運用で直面した問題とその解決策 ◼ 共通基盤では、AWSリソースのエイリアスをRoute53プライベートホストゾーンで管理している ◼ CoreDNSのRoute53プラグインを使って、Route53プライベートホストゾーンをCoreDNSに同期していた ◼ Route53プラグインを導入しなくても、CoreDNSがリゾルバとしてプライベートホストゾーンに問合せてくれる事が判る ◼ Routet53プラグインがパニックの原因の可能性があると考え、CoreDNSから削除したところパニックは発生しなくなった EKSクラスタ Route 53 ドメイン名タイプレコード db.XXX.jp CNAME クラスタエンドポイント db-replica.XXX.jp CNAME 読み込みエンドポイントプライベートホストゾーン CoreDNSアドオン Route53 プラグイン同期

◼金融システムには高度なセキュリティ、信頼性が必要 ◼高度な要求をEKS環境で満たすためには、、まとめクラスタ内の各層でセキュリティ対策を実施！高度なセキュリティ分散配置、Blue/Greenデプロイメント、Podの安全停止設定を活用！高度な信頼性

まとめ EKS運用はIaaSベースのシステムとは種類の異なる問題に直面する新機能を活用して EKS構成を継続的に進化させる事が重要! EKS Auto Modeの導入を検討中

金融システムをモダナイズするためのAmazon Elastic Kubernetes Serv...

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

More Decks by 高棹大樹

Other Decks in Technology

Featured

Transcript