Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

5 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 近年、金融システムにもクラウドネイティブ化の波は来ている オンプレ→クラウドへのリフトは一巡 クラウドのポテンシャルを最大限享受するフェーズへ 従来アーキテクチャの課題を解消し、 よりアジリティの高いシステム開発を実現 問題が発生すると 由々しき事態なるのが金融システム

Slide 7

Slide 7 text

6 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 金融システムで求められる高度な要求 ①高度なセキュリティ ②高度な信頼性 エンドユーザ様のお金を扱うシステムなので、 守れない場合深刻な問題に繋がる

Slide 8

Slide 8 text

7 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼ 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 より引用

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

9 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 金融システムに求められる高度な要求をEKSで満たすためには？ 自身の経験から考える高度なセキュリティ、信頼性を担保する インフラ設計のベストプラクティスを一部紹介します！ KubernetesとAWS両方のサービス・機能を 有効活用する必要あり！

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

11 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼ 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キュー

Slide 13

Slide 13 text

12 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. アジェンダ 高度なセキュリティをどの様に実現するか？ 01 高度な信頼性をどの様に実現するか？ 02

Slide 14

Slide 14 text

13 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 13 1. 高度なセキュリティをどの様に実現するか？

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

17 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ①コンテナのセキュリティ対策 特権モード/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時に チェック

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

20 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のマニフェストファイル リポジトリ

Slide 22

Slide 22 text

21 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 紐付け設定 紐付け設定

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

24 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リソース 他システムリソースにアクセス可能だとセキュリティリスク

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

36 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 36 2. 高度な信頼性をどの様に実現するか？

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

38 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 通常時 エンドポイント エンドポイント

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

40 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クラスタバージョンアップ

Slide 42

Slide 42 text

41 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その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

Slide 43

Slide 43 text

42 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その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

Slide 44

Slide 44 text

43 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その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切り替え

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

45 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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

48 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 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.クラスタに切り替え

Slide 50

Slide 50 text

49 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

52 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その3. アプリエラー件数ゼロのEKSクラスタメンテナンス Podの安全停止設定 2. 高度な信頼性をどの様に実現するか？ ◼ Podの退避は実際にはPodが停止し、その後別ワーカーノードでPodが起動する事で実現される ◼ このPodの停止時にもシステムエラーは許容できないが、Serviceの仕様上Pod停止前にリクエストの振り分け対象 から該当Podを手動で切離す事はできない EKSワーカーノード EKSワーカーノード リタイアメントで停止する必要あり ①Pod停止 ②別ワーカーノードでPod起動 Pod停止前にリクエストの振り分け対象から 該当Podを手動で切離す事はできない

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

54 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. その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マニフェストファイル

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

56 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 56 SIerでもクラウドネイティブできます！！

Slide 58

Slide 58 text

No content