レガシーな金融システムをKubernetesを使ってクラウドネイティブ化するためのノウハウ大全

レガシーな金融システムを Kubernetesを使ってクラウドネイティブ化するためのノウハウ大全 CloudNative Days Winter 2024 2024年11月29日株式会社
野村総合研究所マルチクラウドインテグレーション事業本部金融基盤サービス部エキスパートアーキテクト高棹大樹

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中心のITインフラを構築するために有用なノウハウ ◼話さないこと ⚫ 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キュー

アジェンダ高度なセキュリティをどの様に実現するか？ 01 高度な信頼性をどの様に実現するか？ 02

EKSの責任共有モデル 1. 高度なセキュリティをどの様に実現するか？ ◼ マネージドサービス(EKS)なのでコントロールプレーン管理はAWSが責任を持つ ◼ AWS利用者はワーカーノード管理に責任を持つ必要がある https://aws.github.io/aws-eks-best-practices/security/docs/ より引用コントロールプレーン:AWS管理ワーカーノード:AWS利用者管理

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

EKSワーカーノード ①コンテナのセキュリティ対策特権モード/Rootユーザでのコンテナ実行の禁止 1. 高度なセキュリティをどの様に実現するか？ ◼ 特権モード、およびRootユーザでのコンテナ実行には以下のリスクがある ◼ 一般的な業務アプリケーションでは特権モード、Rootユーザでのコンテナ実行は不要コンテナからワーカーノードOSで任意のコード実行されるリスク (いわゆるコンテナエスケープ) 脆弱性に合致する可能性、影響範囲が拡がるリスクハッキング時の影響範囲が拡がるリスクコンテナ OS SW OS Rootユーザで実行特権モード:有効

①コンテナのセキュリティ対策特権モード/Rootユーザでのコンテナ実行の禁止 1. 高度なセキュリティをどの様に実現するか？ ◼ 非Rootユーザで起動するコンテナを作成 ◼ マニフェストファイルのSecurityContextで権限昇格を禁止する等を設定 ◼ 正しく設定されているかポリシー管理機能を使って(gatekeeper/kyverno等)apply時にチェックコンテナイメージ FROM amazoncorretto ARG USER=1000 RUN adduser $USER USER $USER:$USER Dockerfile containers: - image: <コンテナイメージ名> securityContext: runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false privileged: false capabilities: drop: ["ALL"] マニフェストファイル Gatekeeper Apply時にチェック

①コンテナのセキュリティ対策コンテナイメージの脆弱性スキャン 1. 高度なセキュリティをどの様に実現するか？ ◼ コンテナイメージ内で使用しているOS/SWの脆弱性は、攻撃者に付けこまれる隙になる ◼ 定期的に脆弱性をチェック(スキャン)し、重大な脆弱性には対策を打っていく必要ありコンテナイメージ OS SW 脆弱性の定期的なチェックが必要

①コンテナのセキュリティ対策コンテナイメージの脆弱性スキャン 1. 高度なセキュリティをどの様に実現するか？ ◼ Amazon Elastic Container Registry (Amazon ECR) の機能で脆弱性スキャン可能 ◼ ECRのイメージスキャンには基本スキャンと拡張スキャンがある。拡張スキャンがよりセキュアコンテナイメージ基本スキャン拡張スキャンスキャン対象 OSのみ OSとプログラミング言語スキャンするタイミング・レジストリにイメージをプッシュするタイミング・手動実行・レジストリにイメージをプッシュするタイミング・定期的に自動実行費用無料追加コストが発生 Amazon Elastic Container Registry (Amazon ECR) 脆弱性スキャン

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

③Namespace間のセキュリティ対策 Namespace間の通信制御 1. 高度なセキュリティをどの様に実現するか？ ◼ 他システムのServiceに直接通信可能だとセキュリティ上問題となるケースがある (認証機能が無いバックエンドService等) EKSクラスタ Aシステム用 Namespace Bシステム用 Namespace 認証無し認証無しの他システムServiceに通信可能だとセキュリティ上問題

③Namespace間のセキュリティ対策 Namespace間の通信制御 1. 高度なセキュリティをどの様に実現するか？ ◼ Networkpolicyを各Namespace毎に用意し、Namespace間の通信を制限 EKSクラスタ VPC CNIプラグイン Aシステム用 Namespace Aシステム用Networkpolicy Bシステム用 Namespace Bシステム用Networkpolicy

④ワーカーノードのセキュリティ対策ワーカーノードのチューニング 1. 高度なセキュリティをどの様に実現するか？ ◼ AWSが提供するEKS最適化AMIを利用する ◼ 極力最新バージョンのAMIを利用する ◼ EKS最適化AMIのkubeletの「eventRecordQPS」はデフォルトで5 に設定されているため、1秒間にイベントログを5件まで記録できるが、それ以上のイベントログは破棄され、インシデント発生時に必要な調査を実施できない可能性がある ◼ セキュリティを考慮すると「eventRecordQPS」は0に設定して無制限に記録する方がベター EKSワーカーノード .. eventRecordQPS=5→0 ..

④ワーカーノードのセキュリティ対策マルウェアスキャン 1. 高度なセキュリティをどの様に実現するか？ ◼ マルウェアは悪意のあるソフトウェア全般を指す ◼ マルウェア感染により個人情報の漏洩やデータ改ざん等に繋がる可能性があるため、定期的なマルウェアスキャンが必要マルウェアコンピュータウイルス宿主に寄生/自己増殖するトロイの木馬別プログラムに偽装/自己増殖しないワーム単体で活動/自己増殖する etc …..

④ワーカーノードのセキュリティ対策マルウェアスキャン 1. 高度なセキュリティをどの様に実現するか？ ◼ GuardDuty EC2 Malware Protectionでワーカーノード(EC2)のマルウェアスキャンが可能 ◼ 検知からスナップショットスキャンまで自動で実行 ◼ この機能はマルウェア検知までで駆除はしない。事前に検知後の対応方針や手順書を準備しておく必要あり EKSワーカーノード Amazon GuardDuty EBSボリューム ①マルウェアと疑われる挙動を検知スナップショット ②該当ワーカーノードのEBSからスナップショット、レプリカEBSを作成レプリカEBSボリューム ③レプリカEBSに対してスキャン EC2 Malware Protection :有効

④ワーカーノードのセキュリティ対策振る舞い検知 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. 即座にリリース前の状態に戻せる様にする Blue/Greenデロイメントによるアプリリリース 2. 高度な信頼性をどの様に実現するか？ ◼ Servive(ClusterIP)からDeploymentの振り分け先を切替え apiVersion: v1 kind: Service spec: type: ClusterIP selector: app: blue → green Serviceのマニフェストファイル現Ver.アプリケーション Deployment kind: Deployment spec: template: metadata: labels: app: blue 新Ver.アプリケーション Deployment kind: Deployment spec: template: metadata: labels: app: green app: blue app: green

その2. 即座にリリース前の状態に戻せる様にする Blue/Greenデロイメントによるアプリリリース 2. 高度な信頼性をどの様に実現するか？ ◼ IngressからService(ClusterIP)の振り分け先を切替え kind: VirtualServerRoute spec: upstreams: - name: upstream-sevice service: blue-service → green-service subroutes: - path: / action: proxy: upstream: upstream-sevice rewritePath: / Ingressのマニフェストファイル現Ver.アプリケーション Service kind: Service metadata: name: blue-service 新Ver.アプリケーション Service kind: Service metadata: name: green-service name: blue-service name: green-service

その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. 即座にリリース前の状態に戻せる様にする Blue/GreenデプロイメントによるEKSクラスタバージョンアップ 2. 高度な信頼性をどの様に実現するか？ ◼ 接続するEKSクラスタを切り替える方法は、DNSによる切り替えとロードバランサによる切り替えのパターンがある ◼ 端末のDNSキャッシュ状態に依らずに変更する点でロードバランサ切替えにメリットあり DNSによる切り替えロードバランサによる切り替えイメージ図リソース管理のしやすさ現/新クラスタのIngressリソースとしてロードバランサを管理可能 △ 現/新クラスタの両方から接続する必要があるため、 K8sリソース外としてロードバランサを用意する必要あり切替え、切り戻しの即時性 △ 端末の名前解決頻度、キャッシュ状況に依存する端末に依存せずサーバーサイドで即時に切替え/切り戻しが可能現クラスタ新クラスタ LB LB DNS 現クラスタ新クラスタ LB

その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.クラスタに切り替え

その2. 即座にリリース前の状態に戻せる様にする ALBの機能を活用した接続先EKSクラスタの切り替え 2. 高度な信頼性をどの様に実現するか？ ◼ この構成を用いる事で、切り替え後に問題が発生した場合でもデフォルトルールの向き先を再度現EKSクラスタ用ターゲットグループに戻すだけで、エンドユーザからの通信を即座に現EKSクラスタに向ける事が可能になる ALB リスナー現EKSクラスタ用ターゲットグループ新クラスタ用ターゲットグループリスナールールリクエストに稼動確認用Cookie or ヘッダが付与されていたらデフォルトルール優先度:高優先度:低アプリ開発者エンドユーザ現EKSクラスタ Node Port NGINX Ingress Controller 新EKSクラスタ Node Port NGINX Ingress Controller 現Ver.クラスタに切り戻し

ALB リスナーその2. 即座にリリース前の状態に戻せる様にするシステム単位でのEKSクラスタ切り替え/切り戻し 2. 高度な信頼性をどの様に実現するか？ ◼ システム毎に事情は異なるため、複数システムで同じタイミングで切り替える事が難しいケースが多い ◼ 切替え後に、一部のシステムの問題に引き摺られて全システムを戻す事は避けたい ◼ 各システム毎にリスナールールを持つ事でシステム単位で切り替え/切り戻しが可能に新EKSクラスタ Node Port NGINX Ingress Controller Aシステム用 Namespace Bシステム用 Namespace Aシステム用リスナールール現EKSクラスタ用ターゲットグループ新クラスタ用ターゲットグループエンドユーザエンドユーザ現EKSクラスタ Node Port NGINX Ingress Controller Aシステム用 Namespace Bシステム用 Namespace Bシステム用リスナールール Bシステムだけ新Ver.クラスタに切り替え

その2. 即座にリリース前の状態に戻せる様にする永続データの外部ストア保管 2. 高度な信頼性をどの様に実現するか？ ◼ 業務閉塞せず、処理を継続させたままBlue/Greenデプロイメントを行うためには、現/新クラスタ上のPodが同時に同じデータにアクセスできる必要がある ◼ そのため永続データは極力外部ストアに保管した方が良い ◼ Mountpoint for Amazon S3 CSI Driver等を活用 Aシステム用 S3バケット Aシステム用 ALB 新EKSクラスタ Node Port NGINX Ingress Controller Aシステム用 Namespace S3 CSI Driver 現EKSクラスタ Node Port NGINX Ingress Controller Aシステム用 Namespace S3 CSI Driver

その3. アプリエラー件数ゼロのEKSクラスタメンテナンス EKSワーカーノード停止時の考慮ポイント 2. 高度な信頼性をどの様に実現するか？ ◼ EKSクラスタを維持運用する中では、EC2インスタンスのリタイアメント等でワーカーノードを停止させる場面がある ◼ オンプレやlaaSの構成であれば事前にロードバランサから該当のノードを切離すことでリクエストを遮断できるが、 Kubernetesの場合Pod間でワーカーノードを跨いで通信するのでそれだけでは不十分 EKSワーカーノード EKSワーカーノード ALB EKSワーカーノード NodePort NodePort NodePort externalTrafficPolicy:local リタイアメントで停止する必要あり停止予定のワーカーノード上で稼動するPodへリクエストがルーティングされる切り離し

その3. アプリエラー件数ゼロのEKSクラスタメンテナンス EKSワーカーノード停止時の考慮ポイント 2. 高度な信頼性をどの様に実現するか？ ◼ ALBからの切離しに加えて、ノード上で起動しているPodを他のワーカーノードに退避させる必要あり ◼ Kubectl drainコマンドで該当ノードからのPodの退避と新規Podのスケジューリング対象からの除外が可能 EKSワーカーノード EKSワーカーノード ALB EKSワーカーノード NodePort NodePort NodePort externalTrafficPolicy:local リタイアメントで停止する必要あり DrainコマンドでPodを退避切り離し

その3. アプリエラー件数ゼロのEKSクラスタメンテナンス Podの安全停止設定 2. 高度な信頼性をどの様に実現するか？ ◼ 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

その3. アプリエラー件数ゼロのEKSクラスタメンテナンス Podの安全停止設定 2. 高度な信頼性をどの様に実現するか？ ◼ 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マニフェストファイル

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

レガシーな金融システムをKubernetesを使ってクラウドネイティブ化するためのノウハウ大全

レガシーな金融システムをKubernetesを使ってクラウドネイティブ化するためのノウハウ大全

More Decks by 高棹大樹

Featured

Transcript