Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全

Slide 1

Slide 1 text

Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全 CloudNative Days Winter 2025 2025年11月18日株式会社野村総合研究所マルチクラウドインテグレーション事業本部金融基盤サービス部エキスパートアーキテクト高棹大樹

Slide 4

Slide 4 text

3 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. NRIグループ４つの事業 NRIの会社紹介コンサルティング CONSULTING 創業以来、シンクタンクとしての深い知見と先見性を活かし、官民の様々な分野で戦略策定・政策立案を支援してきました。また、政策・産業・事業・技術への深い理解とお客様との対話を通じ、課題解決に向けた施策を提案し、伴走しています。 AIをはじめとする技術革新が加速し、社会や市場の変化が予測困難となる今、ビジネスを次のステージへと導くには、先見性に裏付けられたマネジメントコンサルティング、先進技術で事業・業務革新を加速するシステムコンサルティング、それらを統合する実行力が不可欠です。未来を見据え、今を変えることで、お客様の最良のパートナーであり続けることを目指します。 NRIグループはコンサルティングやさまざまなITソリューションの提供を通じて、社会や産業を確かな明日へ導くとともに、世界中のお客様と新しい価値を共創しています。金融ITソリューション FINANCIAL IT SOLUTIONS NRIグループは、金融ビジネスを取り巻く環境変化を高い洞察力で捉える研究員やコンサルタント、ITソリューションサービスを提供するビジネスアナリストやデジタル人材の連携によって次世代ソリューションを提供し続け、金融機関の事業継続を多方面から支えています。近年は、金融機関や政策当局、異業種プレーヤーなどとの価値共創により、金融機能の変革に取り組んでいます。金融は、社会の重要インフラです。進化し続けるデジタル技術との相性を常に考えながら、安定かつ先進的な社会インフラを実現し、社会課題に果敢にチャレンジしていきます。産業ITソリューション INDUSTRIAL IT SOLUTIONS 産業分野の業界トップ企業のビジネスパートナーとして、コンサルティングからシステム開発や運用まで、一貫したサービスを提供しています。コンサルタントとエンジニアが共同でお客様のビジネス環境やデータを分析しながら、最適なIT ソリューションを提供しています。また、コンサルティング部門から運用部門まで、NRIグループのリソースをインテグレーションし、お客様のデジタル戦略を柔軟かつスピーディーに実現します。長年にわたってミッションクリティカルなシステムを構築・運用してきた経験と実績で、これからもお客様の事業インフラとしてのシステム基盤を支えていきます。 IT基盤サービス IT PLATFORM SERVICES IT技術の革新が加速する中、巨大化・複雑化が進むITシステム基盤の重要性が増しています。 NRIグループは先進的な技術を見通し、戦略的にサービスやソリューションに取り入れ、お客様の成長や変革の実現をサポートします。先進技術の調査・研究やAI技術の活用も積極的に実施しています。また、マルチクラウドを含むシステム全体を運営するマネージドサービスやお客様の働く環境を創り出すデジタルワークプレイス事業などを展開しています。さらに、高度化するサイバー脅威に対応するデジタルトラスト事業やお客様が直面するセキュリティ課題の解決、総合的なセキュリティレベルの向上を支援しています。

Slide 24

Slide 24 text

23 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① 接続設計 2.接続パターン内のコンポーネントを詳細化する 1. インフラ基本設計 ◼アプリケーションPodがAurora PostgreSQLクラスタに接続するパターン No. 詳細接続内容 ① アプリケーションPod内のコンテナは、JDBC Driverのデータベースに接続するメソッドを呼び出す ② アプリケーションコンテナは、CoreDNS Serviceに対して、プライマリインスタンスのホスト名の名前解決の問合せを行う ③ CoreDNS ServiceはCoreDNS Podに問合せ通信を振り分ける。 ④ CoreDNSコンテナは、Amazon Route 53 Resolverに対して、プライマリインスタンスのホスト名の名前解決の問合せを行う。 ⑤ Route 53 Resolverは、AWSの権威DNSサーバに対して、プライマリインスタンスのホスト名の名前解決の問合せを行う。 ⑥ AWSの権威DNSサーバは、プライマリインスタンスのプライベートIPアドレスを返却する。 ⑦ AWSの権威DNSサーバは、プライベートIPアドレスを返却する。 ⑧ CoreDNSコンテナは、プライベートIPアドレスを返却する。 ⑨ JDBC Driverは、プライベートIPアドレスを使用して、プライマリインスタンスに接続処理を行う ⑩ プライマリインスタンスはJDBC Driverからの接続リクエストを検証する。 ⑪ 接続リクエストの検証に成功すると、プライマリインスタンスはその事を通知する。 ⑫ JDBC Driverのメソッドは接続処理が正常に行えた事をアプリケーションコンテナに通知する。アプリケーションPod Aurora PostgreSQLクラスタ詳細化 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

Slide 25

Slide 25 text

24 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① 接続設計 2.接続パターン内のコンポーネントを詳細化する 1. インフラ基本設計 ◼アプリケーションPodがSQSキューにメッセージを送信するパターン No. 詳細接続内容 ① アプリケーションコンテナは、内部でAWS SDKが提供するSQSキューへメッセージを送信するためのメソッドを呼び出す。 ② AWS SDKは、アプリケーションPodと同じEKSワーカーノード(EC2)上で稼動するAmazon EKS Pod Identity Agent Podに対して、AWS IAMの一時的な認証情報の問合せを行う ③ Pod Identity Agentコンテナは、EKS Auth APIに対して一時的な認証情報の問合せを行う ④ EKS Auth APIは予めアプリケーションPodに付与されているServiceAccountと紐付け設定されているIAMロールを検証する ⑤ EKS Auth APIはIAMロールの検証に成功すると、一時認証情報をPod Identity Agentコンテナに返却する ⑥ Pod Identity Agentは一時認証情報をAWS SDKに返却する ⑦ AWS SDKのメソッドは、一時認証情報を使用して、AWS SQS APIに対してSQSキューへのメッセージの送信を問合せる ⑧ AWS SQS APIはSQSキューにメッセージを格納する ⑨ AWS SQS APIはAWS SDKのメソッドに対して、メッセージ格納が正常に終了した事をAPIのレスポンスとして返却する ⑩ SDKのメソッドはSQSキューへのメッセージ送信が正常に行えた事をアプリケーションに送付するアプリケーションPod 詳細化 SQSキュー 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

Slide 28

Slide 28 text

27 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① 接続設計 4.接続パターンの認証/認可方法を明確化する 1. インフラ基本設計 ◼認証/認可方法を明確化する事で、必要な設計ポイントに気付ける種類説明接続元メリットデメリット証明書による認証 X.509証明書を利用して接続元を認証アプリ開発者インフラ管理者 Kubernetesの機能のみで認証を行う事ができる証明書や、それに関連する Kubernetesリソースを個別に管理する必要がある外部IDプロバイダによる認証 OpenID Connectを使用して外部IDプロバイダ（例えばGoogleやSalesforce など）と連携し、認証を行うアプリ開発者インフラ管理者既存の認証基盤を活用できる設定が複雑になる。外部IDプロバイダへの依存性が増える。パブリッククラウドの認証基盤による認証パブリッククラウドの認証基盤(AWSだと IAM)の機能を用いて認証アプリ開発者インフラ管理者認証情報をパブリッククラウドと一元管理できる設定が複雑になる。パブリッククラウドへの依存性が増える。 Service Account による認証 Service AccountというKubernetesリソースを用いて認証を行う。Pod等の Kubernetesリソースに関連付けて使用 Kubernetesリソース (Pod等) クラスタ内からAPIへのアクセスを自然に扱える RBACとの統合が容易トークンをSecretとして管理する事による漏洩リスク Kubernetes API経由でリソースに接続・操作する際の認証方法(一部) 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

Slide 64

Slide 64 text

63 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. コンポーネント (サーバorコンテナor etc) リソース CPU数:2 メモリ: 4GiB OS ソフトウェアアプリケーション ④ 拡張性設計 1.リソース拡張の基本方針を検討する 1. インフラ基本設計 ◼スケールアップとスケールアウトのどちらでリソース拡張を行うのかをクラスタ単位で検討 ◼今後システムの需要が大きく拡大し、大きなリソース拡張を実施する可能性がある場合には、スケールアウトを基本路線とすべき(スケールアップはOS・ソフトウェアの制約に抵触する可能性あり) コンポーネント (サーバorコンテナor etc) リソースクラスタコンポーネント CPU数:2 メモリ:4GiB スケールアップ CPU数:4 OS ソフトウェアアプリケーション選択できるスペックには上限がある制約に抵触し、リソースを増強してもそのリソースを十分に使い切れない NEW 自動スケールアウト機能スケールアウト自動スケールアウト機能を活用して自動化が行いやすいコンポーネントコンポーネント (サーバorコンテナor etc) リソース CPU数:2 メモリ: 4GiB OS ソフトウェアアプリケーションクラスタコンポーネント (サーバorコンテナor etc) リソース CPU数:2 メモリ: 4GiB OS ソフトウェアアプリケーションコンポーネント (サーバorコンテナor etc) リソース CPU数:2 メモリ: 4GiB OS ソフトウェアアプリケーションスペックは変更無いためOS・ソフトウェアの制約に抵触しないスケールアップスケールアウト接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

Slide 66

Slide 66 text

65 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ④ 拡張性設計 2.リソース拡張を行う契機を整理する 1. インフラ基本設計 ◼契機を明確化しておく事で、躊躇せず迅速にリソース拡張を行える ◼システムの特性/処理の内容から、クラスタ毎にリソース拡張の契機を検討するカテゴリ指標の例説明 CPU CPU使用率 CPUが枯渇すると応答時間の劣化等に繋がる可能性があるメモリメモリ使用率メモリ逼迫はOOM（Out of Memory）を招く恐れがあるネットワークネットワークI/O・送受信量ネットワークがボトルネックなると、応答時間の劣化や処理エラーに繋がる可能性があるディスクディスクI/O・読み書き量ストレージへのアクセス集中時にボトルネックとなる可能性がある問合せの数秒間あたりのAPI問合せ数主にオンライン処理で、秒間の問合せ数をリソース拡張の指標にするレイテンシ問合せに対する応答時間問題となる応答時間を閾値に設定する（例：500ms以上など）エラー率 HTTP 5xxエラー率サービスが正常に処理できなくなる兆候を判断できる同時接続数 DB同時接続数 DBサーバに設定した最大同時接続数を上回る数のDB接続は失敗する日時処理量がピークになる時間帯処理量がピークになる時間帯が固定されているシステムに対し、その時間帯に先立ちリソース拡張を行う事が有効な場合があるリソース拡張の契機となる指標の例接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

Slide 72

Slide 72 text

71 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ④ 拡張性設計 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 1. インフラ基本設計 ◼並列クラスタのスケールインを行う場合、実行中の処理がエラーになる恐れがあり ◼対策の1つとして、実行中の処理が完了するまでの猶予時間を待ってからスケールインを行う ◼KubernetesではPreStopフックを使ったアプリケーションPod停止の猶予時間設定が有効ロードバランササーバ/コンテナサーバ/コンテナリソース OS ソフトウェアアプリケーションサーバ/コンテナ実行中処理実行中処理エラーエラー並列クラスタのスケールインを行う場合、実行中の処理がエラーになる恐れがありスケールインのため停止アプリケーション ClusterIP Service アプリケーションPod アプリケーションPod アプリケーションPod コンテナソフトウェアアプリケーション実行中処理実行中処理 PreStopフック： 60秒sleep 完了完了 PreStopフックにより、 Podの停止処理が開始されてから 60秒たった後で実際にコンテナが停止する 60秒sleepが実行されている間に、アプリケーションの処理は完了するスケールインのため停止 K8s では接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

Slide 93

Slide 93 text

92 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ② インフラ連結テスト 2.障害テスト/テストケースの例 2. インフラテスト ➢ 狙い：アプリケーションPodの並列クラスタを対象に、1つのPod内のアプリケーションコンテナがダウンした際のクラスタの復旧動作を確認する。 ➢ 確認手順：テスト用サーバから kubectl execコマンドを用いて対象コンテナへのシェルを獲得する。シェル内でkill -9 1 コマンドを実行し、対象コンテナのメインプロセスを終了させる。 ➢ 期待結果：メインプロセスが終了するため、対象コンテナが異常終了する事。その後 kubelet によって再起動が行われ、対象コンテナが自動的に正常稼働の状態に復旧される事。 ➢ エビデンス：テスト用サーバの操作ログ、テスト対象コンテナのログアプリケーションPodの並列クラスタにおける、アプリケーションコンテナダウン発生時の復旧動作確認 ➢ 狙い：アプリケーションPodとAurora PostgreSQLクラスタとの間で行われるトランザクション処理の復旧動作が設計通りに行われるのか確認する。 ➢ 確認手順：アプリケーションPod上でAurora PostgreSQLクラスタに対するテーブル更新問合せを含めたトランザクション処理を実行する。トランザクション処理を実行している最中にアプリケーションPod内のアプリケーションコンテナをダウンさせる。 ➢ 期待結果： Aurora PostgreSQLクラスタに対するテーブル更新がロールバックされる事を確認する。 ➢ エビデンス：アプリケーションPodのログ、トランザクション処理の更新対象のテーブルの内容が出力されたログアプリケーションPod-Aurora PostgreSQLクラスタ間で行われるトランザクション処理の復旧動作確認接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

Slide 104

Slide 104 text

103 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ② インフラ連結テスト 4.拡張テスト/テストケースの例 2. インフラテスト ➢ 狙い：アプリケーションPodのスケールアウトが拡張性設計通りに自動発動する事を確認する ➢ 確認手順：負荷テストツールを用いてアプリケーションPodの並列クラスタに対して疑似的な負荷を掛ける ➢ 期待結果：アプリケーションPodのリソースの使用量が拡張性設計で整理した閾値を超過したタイミングで、自動でアプリケーションPodが追加される事 ➢ エビデンス：アプリケーションPodのリソース使用量の推移が出力されたテキスト、アプリケーションPod数の推移が出力されたテキストアプリケーションPodの並列クラスタにおける、スケールアウト自動発動確認 ➢ 狙い：リードレプリカのスケールアウトが拡張性設計通りに自動発動する事を確認する ➢ 確認手順：負荷テストツールを用いてAurora PostgreSQLクラスタのリーダーエンドポイントに対して疑似的な負荷を掛ける ➢ 期待結果：Aurora PostgreSQLクラスタのリードレプリカのリソースの使用量が拡張性設計で整理した閾値を超過したタイミングで、自動でリードレプリカが追加される事 ➢ エビデンス：Aurora PostgreSQLクラスタのリードレプリカのリソース使用量の推移が出力されたテキスト・スクリーンショット、リードレプリカ数の推移が出力されたテキスト・スクリーンショット Aurora PostgreSQLクラスタにおける、リードレプリカのスケールアウト自動発動確認接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text