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

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

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

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

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技術の活用も積極的に実施しています。また、マルチクラウドを含むシステム全体を運営するマネージドサービスやお客様の働く環境を創り出すデジタルワークプレイス事業などを展開しています。さらに、高度化するサイバー脅威に対応するデジタルトラスト事業やお客様が直面するセキュリティ課題の解決、総合的なセキュリティレベルの向上を支援しています。

近年エンタープライズシステムにもクラウドネイティブ化の波は来ているオンプレ→クラウドへのリフトは一巡クラウドのポテンシャルを最大限享受するフェーズへ従来アーキテクチャの課題を解消し、よりアジリティの高いシステム開発を実現エンタープライズシステムはインフラにも高い品質が求められる

エンタープライズシステムはインフラにも高い品質が求められる。 ◼エンタープライズシステムの構築プロジェクトの進め方は、長い歴史で体系化されている ◼品質の高いインフラを構築するためにはこの進め方に沿う事が重要要件定義設計実装・構築テスト移行システム構築プロジェクト維持・保守クラウドのメリットを最大限に活かすには、進め方のシフト・追加の考慮が必要！クラウド・Kubernetesを活用したシステムを題材にインフラ設計・テストの進め方を解説します！

アジェンダインフラ基本設計 01 インフラテスト 02

◼本日の内容は、2026年初旬刊行予定の『新版インフラ設計のセオリー』(リックテレコム)から抜粋したものです。 ◼本日解説しない、要件定義、維持・保守フェーズ等も詳細に解説しています！ ◼宜しければ是非手に取ってみてください！実は、、 ←こちらの新版を執筆しました！

◼話すこと ⚫ Kubernetes・クラウドを用いたエンタープライズシステムのインフラ構築を行うための、設計・テストの進め方 ◼話さないこと ⚫ ITインフラの構成・設計パターン ⚫ Kubernetesの基礎知識(Pod,Deployment,Serviceとは？ Etc..) ⚫ クラウドの基礎知識(AWSのEC2,lAMとは？ Etc..) ◼注意事項 ⚫ インフラ設計・テストの進め方の一例を示すものであり、実際の進め方はプロジェクトによって異なる点はご了承ください ⚫ エンタープライズシステムのITインフラを設計する上で必要な考慮点・設計ポイントが網羅されている訳では無い点ご了承ください話すこと・話さないこと・注意事項

前提となるインフラ構成/呼称ルール ➢ パブリッククラウド上でシステム構築を行う ➢ パブリッククラウドはAWSを用いる ➢ コンテナオーケストレーションは、どのパブリッククラウドやオンプレミスでも利用が可能なKubernetesを用いる ➢ AWSのマネージドKubernetesサービスであるAmazon Elastic Kubernetes Service(EKS)を用いる前提となるインフラ構成 ➢ サーバ、コンテナ、その上で稼働するソフトウェア、NW機器ルータ、およびパブリッククラウドのマネージサービス等のシステムの構成要素を「コンポーネント」と総称する ➢ クラスタ構成のコンポーネントを「クラスタ」と呼ぶ呼称ルール

インフラの基本設計とは？ 1. インフラ基本設計 ◼要件定義(概要設計)とパラメータ設計の間にある工程 ◼要件定義で構成図はできているけど、これからいきなりパラメータは設計できないですよね、、、？要件定義インフラ基本設計パラメータ設計・機能要件の定義・非機能要件の定義・インフラ構成検討・各コンポーネントが持つパラメータ値の検討 ALBのターゲットには何を設定する？ PodやALBのヘルスチェック間隔は？他にもたくさんのパラメータを設計する必要あり

インフラの基本設計とは？ 1. インフラ基本設計 ◼要件定義(概要設計)とパラメータ設計の間にある工程 ◼要件定義で構成図はできているけど、これからいきなりパラメータは設計できないですよね、、、？ ALBのターゲットには何を設定する？ PodやALBのヘルスチェック間隔は？要件定義インフラ基本設計パラメータ設計・機能要件の定義・非機能要件の定義・インフラ構成検討・各コンポーネントが持つパラメータ値の検討他にもたくさんのパラメータを設計する必要あり具体的なパラメータ値を決めるためには、コンポーネントのどれとどれが接続するのか、障害時の臨ましい動作は何なのか、等の整理が必要！

インフラの基本設計とは？ 1. インフラ基本設計 ◼インフラ基本設計では、コンポーネント間がどの様に繋がり、どの様な協調動作を行うのかを詳細に整理する。これがパラメータ設計のインプットになる。サーバorコンテナor etc リソースソフトウェアパラメータファイル〜〜〜：〜〜〜〜〜：〜〜〜サーバorコンテナor etc リソースソフトウェアパラメータファイル〜〜〜：〜〜〜〜〜：〜〜〜サーバorコンテナor etc リソースソフトウェアパラメータファイル〜〜〜：〜〜〜〜〜：〜〜〜

インフラの基本設計とは？ 1. インフラ基本設計 ◼インフラ基本設計では様々な場面を想定し、その際の期待動作を整理する。システムが正常稼動している場面システム内のあるコンポーネントに障害が発生した場面問合せが急増して、リソース増強が必要になった場面システムがセキュリティ攻撃を受けた場面大規模災害が発生した場面などなどクラウドの機能を最大限利用しつつ、コストも抑えるためには、インフラ基本設計に組み込む必要あり！

インフラ基本設計の分類 1. インフラ基本設計 ◼インフラ基本設計は場面に沿って分類される ◼分類分けはシステムやプロジェクトによって異なるインフラ基本設計接続設計可用性設計(耐障害性設計) 性能設計拡張性設計運用設計セキュリティ設計災害復旧設計本日の説明範囲

① 接続設計進め方 1. インフラ基本設計 ◼システムを構成するどのコンポーネントが、どれとどの様に接続するのかを詳細に整理する ◼要件定義工程で作成された構成図をブレイクダウンするイメージ 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する

① 接続設計 1.システムで用意すべき接続パターンを整理する 1. インフラ基本設計 ◼システム内のコンポーネント間の接続を「接続パターン」として整理する ◼整理の観点は以下アプリケーションの特性や要件・情報取得のために、ある外部システムに問合せを行う必要がある・静的コンテンツのキャッシュのためにCDNを利用したい具体例用いるソフトウェア/サービスの仕様・AWS ALBは転送先のプロトコルに、HTTP/1.1、HTTP/2、gRPCが設定可能・NGINX はgRPCでも待ち受け可能具体例既存システム等で実績のある接続パターンか・非同期処理でAmazon SQSを利用するパターンは、既存システムで実績がある・今回のシステムと似た用途でCloudFrontを用いた実績がある具体例 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 1.システムで用意すべき接続パターンを整理する 1. インフラ基本設計 ◼システム内のコンポーネント間の接続を「接続パターン」として整理する ◼整理の観点は以下アプリケーションの特性や要件用いるソフトウェア/マネージドサービスの仕様既存システム等で実績のある接続パターンか・情報取得のために、ある外部システムに問合せを行う必要がある・静的コンテンツのキャッシュのためにCDNを利用したい具体例・AWS ALBは転送先のプロトコルに、HTTP/1.1、HTTP/2、gRPCが設定可能・NGINX はgRPCでも待ち受け可能具体例・非同期処理でAmazon SQSを利用するパターンは、既存システムで実績がある・今回のシステムと似た用途でCloudFrontを用いた実績がある具体例アプリチームとの十分な擦り合せが大事！技術的な引き出しを多く持っておく事が大事！ 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 1.システムで用意すべき接続パターンを整理する 1. インフラ基本設計 ◼接続パターンの整理の例 No. 接続パターン ① エンドユーザはインターネットを経由して、CloudFrontディストリビューションに接続する ② CloudFrontディストリビューションは、ALBに接続する ③ ALBは、AWSのEKSクラスタ上で稼動するNGINX Podに接続する ④ NGINX Podは、同じEKSクラスタ上で稼働するアプリケーションPodに接続する ⑤ アプリケーションPodは、自システムが持つAurora PostgreSQLのクラスタに接続し、データの参照、更新を行う ⑥ アプリケーションPodは、非同期処理を行うために自システムが持つSQSキューに接続し、メッセージの取得、配置を行う ⑦ アプリケーションPodは、外部システムがS3のバケットに接続し、ファイルを取得する ⑧ アプリケーションPodは、インターネットを経由して外部システムに接続し、更新処理を行う ⑨ アプリケーションPodは、アプリケーションLambda関数を実行する 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 2.接続パターン内のコンポーネントを詳細化する 1. インフラ基本設計 ◼接続パターン毎に含まれるコンポーネントの詳細化する ◼接続パターンを成立させるために必要な、サーバやコンテナ、ソフトウェア、パブリッククラウド各種サービスなどを可能な限り詳細に洗い出す ◼どのコンポーネントがパラメータ設計のポイントとなるのかが浮び上がる洗い出したコンポーネントが具体的にどういった原理、仕組みで接続するのか、腹に落ちるまで理解する事が重要！ 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 2.接続パターン内のコンポーネントを詳細化する 1. インフラ基本設計 ◼個別にIPアドレスを持たないクラウド/K8sのリソースには直接接続できない。APIを介して間接的に接続する必要がある ◼SDKやCLIを用いてAPIを実行する事が判る様に接続パターンを整理する必要があるコンポーネント (サーバorコンテナor etc) パブリッククラウド/Kubernetes コントロールプレーン IPアドレスを持たないマネージドサービス・リソース API IPアドレスを持たないパブリッククラウド/Kubernetesのマネージドサービス・リソースには直接接続できないパブリッククラウド/Kubernetesのコントロールプレーンに対してAPIを実行する事で、関節的にマネージドサービス・リソースに接続するパブリッククラウド /Kubernetes SDK or CLI 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 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. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 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. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 3.接続パターンの通信プロトコルを明確化する 1. インフラ基本設計 ◼コンポーネント間で通信を行う際の通信プロトコルを明確化する ◼プロトコルを明確化する事で、通信に必要なコンポーネントや考慮ポイントに気付ける Application Load Balancer HTTPS NGINX Pod NGINXコンテナ TLS証明書 NGINX PodがHTTPSで待ち受けるためにはTLS証明書が必要この証明書はどうやって発行する? 公的証明書? orプライベートPKI? or etc 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 4.接続パターンの認証/認可方法を明確化する 1. インフラ基本設計 ◼セキュリティ要件等から求められる認証/認可を、コンポーネントで行う事ができるかを確認する ◼行えない様であれば、コンポーネントの追加を検討する EKSクラスタアプリケーション Pod AWS IAMで認可制御を行うためにAmazon API Gatewayを追加 AWS Cloud アプリケーション Lambda関数認証/認可処理実装していない IAMlロール Amazon API Gateway 追加 IAMで認可制御：有効アプリケーションPodからlambda関数に接続するパターン 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 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. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 5.接続パターンで使用する文字コードを明確化する 1. インフラ基本設計 ◼コンポーネント間で異なる文字コード、符号化方式を用いる場合、変換処理を行う必要がある ◼変換処理をどのコンポーネントで行うのかを明確化する事で、処理パターンの妥当性を確認データベース (文字符号化方式：EUC-JP) DBサーバ Javaアプリケーション (内部の文字符号化方式： UTF-16 ) JDBC Driver テーブル群インデックス群 UTF-16 JDBC DriverでUTF-16⇔EUC-JPの変換を行う EUC-JP アプリケーションPod アプリケーションコンテナ (内部の文字符号化方式： UTF-16 ) 外部システム (文字符号化方式：シフトJIS) 接続ライブラリ UTF-16 シフトJIS 接続ライブラリでUTF-16⇔シフトJISの変換を行う 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 6.接続パターンのタイムアウト制御方法を明確化する 1. インフラ基本設計 ◼リソースの涸渇やユーザ体験を考慮し、タイムアウト制御は必須 ◼コンポーネント間の処理の整合性を保つために、接続先の応答タイムアウト値より接続元の応答タイムアウト値が大きい関係が保たれる必要ありコンポーネントコンポーネント応答タイムアウト値処理実施待機処理実施問合せコンポーネント応答タイムアウト値処理実施待機処理実施問合せ応答接続先のコンポーネントの応答タイムアウト値より接続元の応答タイムアウト値が大きい関係が保たれる必要がある 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 6.接続パターンのタイムアウト制御方法を明確化する 1. インフラ基本設計 ◼タイムアウトを制御するコンポーネント、設定項目とその値を明確化する NGINX Pod NGINX コンテナアプリケーションPod アプリケーションコンテナ静的コンテンツ (画像、CSS等) アプリケーション ClusterIP Service 静的コンテンツへの問合せ応答 APIへの問合せ応答 Aurora PostgreSQL クラスタクエリ問合せ応答クエリ処理 API処理 PostgreSQL JDBC Driver 応答タイムアウト setQueryTimeout メソッドリバースプロキシ設定応答タイムアウト proxy_read_timeout APIへの問合せ応答 APIへの問合せ応答 NGINX Pod→アプリケーションPod→ Aurora PostgreSQLクラスタの順で接続するパターンの例 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 6.接続パターンのタイムアウト制御方法を明確化する 1. インフラ基本設計 ◼応答タイムアウト値は大小関係を保って設定するアプリケーション ClusterIP Service NGINX Pod NGINXコンテナアプリケーションPod アプリケーションコンテナ PostgreSQL JDBC Driver Aurora PostgreSQL クラスタクエリ処理時間アプリ処理時間 setQueryTimeout メソッド proxy_read_timeout アプリ処理時間 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

① 接続設計 6.接続パターンのタイムアウト制御方法を明確化する 1. インフラ基本設計 ◼一方、外部システムとの連携やコンポーネントの複雑化により、実際には全てのコンポーネント間でタイムアウト値の大小関係を保つ事が難しいケースも少なくない ◼その様なケースでは、必要に応じて自動リトライ処理を行う、などを検討する ◼自動リトライ処理は、リトライ回数の制御、冪等性の確保、タイムアウト設計との整合性などに十分注意する必要あり 1. システムで用意すべき接続パターンを整理する 2. 接続パターン内のコンポーネントを詳細化する 3. 接続パターンの通信プロトコルを明確化する 4. 接続パターンの認証/認可方法を明確化する 5. 接続パターンで使用する文字コードを明確化する 6. 接続パターンのタイムアウト制御方法を明確化する接続設計耐障害性設計性能設計拡張性設計

② 耐障害性設計 1. インフラ基本設計 ◼システム内の様々なコンポーネントに障害が発生した場面を想定し、その際のクラスタ構成の望ましい復旧動作を整理する 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 1.システムの単一障害点をクラスタ化する 1. インフラ基本設計 ◼システムを構成するコンポーネントのうち単一障害点(SPOF: Single Point of Failure)となりうるものが無いか確認する ◼SPOFとなりうるものはクラスタ構成を取る事で冗長化させる ◼接続設計で抽出されたコンポーネントもSPOFになるものはクラスタ化を検討ロードバランサアプリケーションサーバロードバランサアプリケーションサーバアプリケーションサーバ DBサーバ SPOF 接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 2.クラスタの障害発生ポイントを洗い出す 1. インフラ基本設計 ◼クラスタを構成するコンポーネントのうち、単体で障害が発生する可能性があるものを障害発生ポイントとして洗い出すコンポーネントの実体を理解する事が重要！接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 2.クラスタの障害発生ポイントを洗い出す 1. インフラ基本設計 ◼アプリPodの並列クラスタの障害発生ポイントの洗い出しの例アプリケーションPod → Kubernetesの論理的なリソースアプリケーションコンテナ →実体はプロセスサイドカーコンテナ →実体はプロセス障害発生ポイント障害発生ポイント障害発生ポイントではないアプリケーションClusterIP Service → Kubernetesの論理的なリソース障害発生ポイントではないコンテナの実体はワーカーノード上で稼動するプロセス単体で障害が発生する可能性があるアプリPodの並列クラスタアプリケーションPod アプリケーションコンテナサイドカーコンテナ ClusterIP ServiceやPodはKubernetesの仮想的なリソース単体で障害が発生するものではないアプリケーションPod アプリケーションコンテナサイドカーコンテナ接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 2.クラスタの障害発生ポイントを洗い出す 1. インフラ基本設計 ◼EKSクラスタの障害発生ポイントの洗い出しの例 EKSワーカーノード(EC2) 障害発生ポイント kube-proxy →実体はコンテナ障害発生ポイント kubelet →実体はプロセス障害発生ポイントその他EKSクラスタに必要なコンテナ、プロセス障害発生ポイント EKSクラスタ EKS コントロールプレーン障害発生ポイント EKSワーカーノード(EC2) 障害発生ポイント kube-proxy →実体はコンテナ障害発生ポイント kubelet →実体はプロセス障害発生ポイントその他EKSクラスタに必要なコンテナ、プロセス障害発生ポイント接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 3.クラスタの実行環境の障害発生ポイントを洗い出す 1. インフラ基本設計 ◼コンポーネントの稼働に影響を与える可能性がある、クラスタの実行環境の障害発生ポイントの洗い出しを行う ◼前述のクラスタの障害発生ポイントの洗い出しは、クラスタを構成するコンポーネントに着目したミクロな視点で行うもの ◼それに対して、クラスタの実行環境の障害発生ポイントの洗い出しは、検討の範囲を広げたマクロな視点で行う必要あり！接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 3.クラスタの実行環境の障害発生ポイントを洗い出す 1. インフラ基本設計 ◼アプリPodの並列クラスタから見たEKSクラスタ障害の例 EKSワーカーノード(EC2) EKSワーカーノード(EC2) アプリケーション Pod アプリケーションコンテナサイドカーコンテナアプリケーション ClusterIP Service アプリPodの並列クラスタ障害発生ポイント kube-proxy 障害発生ポイント kubelet 障害発生ポイントその他EKSクラスタに必要なコンテナ、プロセス障害発生ポイント EKS コントロールプレーン障害発生ポイント EKSクラスタアプリケーション Pod アプリケーションコンテナサイドカーコンテナアプリケーション Pod アプリケーションコンテナサイドカーコンテナ EKSクラスタの障害発生ポイントをアプリPodの実行環境の障害発生ポイントとして考慮する接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 3.クラスタの実行環境の障害発生ポイントを洗い出す 1. インフラ基本設計 ◼アプリPodの並列クラスタから見たAWS障害の例 EKS ワーカーノード EKS ワーカーノード東京リージョン障害発生ポイントアプリケーション Pod アプリケーションコンテナサイドカーコンテナアプリケーション ClusterIP Service アプリPodの並列クラスタアプリケーション Pod アプリケーションコンテナサイドカーコンテナアプリケーション Pod アプリケーションコンテナサイドカーコンテナ Availability Zone1 Availability Zone2 障害発生ポイント障害発生ポイント障害時にアプリPodクラスタに影響を与える可能性があるため、リージョン、AZも障害発生ポイントに含める接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 4.障害発生ポイント毎のクラスタの復旧動作を整理する 1. インフラ基本設計 ◼障害発生から復旧までの流れを、障害発生ポイント毎に詳細に整理する ◼どのコンポーネント・パラメータが復旧動作のポイントなのかが浮び上がる ◼完全にダウンするケースもあれば、コンポーネントは起動しているがハングで正常に処理を行えないケースも。考えられる障害内容それぞれに対して復旧動作を整理するどういった原理、仕組みで復旧動作が行われるのか、腹に落ちるまで理解する事が重要！接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 4.障害発生ポイント毎のクラスタの復旧動作を整理する 1. インフラ基本設計 ◼アプリケーションPodの並列クラスタ内のコンテナハングの例 No. 復旧動作内容 ① アプリケーションPod内コンテナにハング発生 ② Readiness Probeのヘルスチェック処理が失敗 ③ Readiness Probe のヘルスチェック処理失敗を受けて、 kubeletは問合せ振り分け対象から当該アプリケーションPodを除外 ④ 接続元のコンポーネントが問合せを行うと、クラスタ内の障害が発生したPod以外のPodに振り分けられる ⑤ Liveness Probeのヘルスチェック処理が失敗 ⑥ Liveness Probe のヘルスチェック処理失敗を受けて、 kubeletはコンテナの再起動を行う ⑦ コンテナ再起動によりReadiness Probeのヘルスチェック処理が成功 ⑧ Readiness Probe のヘルスチェック処理成功を受けて、 kubeletは振り分け対象にアプリケーションPodを組込む ⑨ 接続元のコンポーネントが再度問合せを行うと、クラスタ内の障害が発生したPodにも振り分けられる接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 5.クラスタのヘルスチェック設計を行う 1. インフラ基本設計 ◼復旧動作を行うための重要な設計ポイントの1つにヘルスチェックが挙げられる ◼復旧動作を自動発動するために必要となる、ヘルスチェックの設計項目を詳細に検討 ◼もし、復旧動作を自動で行いたいにも拘わらず、どこからヘルスチェックが行われるのか不明瞭であれば、前述の復旧動作の流れの整理が不十分と言える接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 5.クラスタのヘルスチェック設計を行う 1. インフラ基本設計 ◼Kubernetes上でPodを稼動させるためには、Kubernetesのヘルスチェック機能である、 Liveness Probe, Readiness Probeを適切に設定する必要ありパラメータ説明 tcpSocket/httpGet.scheme ヘルスチェックのプロトコル httpGet.path ヘルスチェックのパス periodSeconds ヘルスチェックを行う間隔 failureThreshold ヘルスチェックが何回NGであればコンテナに障害が発生したとみなすか timeoutSeconds ヘルスチェックのタイムアウト Liveness Probe, Readiness Probeのパラメータの一部接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 5.クラスタのヘルスチェック設計を行う 1. インフラ基本設計 ◼ プロトコルは原則業務通信と同一 ◼ パスはコンテナの正常稼動を確認できるものヘルスチェック𝑵𝑮の回数 − 𝟏 × ヘルスチェックの間隔 + ヘルスチェックのタイムアウト + 障害コンテナの復旧動作に掛る時間コンテナ障害発生から復旧動作完了までの最大時間 ◼ 障害復旧の目標時間に収まる様に、ヘルスチェックの間隔、ヘルスチェックNGの回数、ヘルスチェックのタイムアウト値を検討接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 6.クラスタの分散配置設計を行う 1. インフラ基本設計 ◼コンポーネントが偏って配置されると、実行環境で障害が発生した場合に、多数のコンポーネントに影響が出てしまい、想定した復旧動作を行えない恐れがある ◼それを避けるために、実行環境の障害発生ポイントを複数跨がる様にコンポーネントを分散配置する接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 6.クラスタの分散配置設計を行う 1. インフラ基本設計 ◼アプリPodの並列クラスタの分散配置の例アプリケーション ClusterIP Service アプリPodの並列クラスタアプリケーションPod アプリケーションコンテナサイドカーコンテナ Availability Zone1 Availability Zone2 アプリケーションPod topologySpreadConstraints - AZ - ワーカーノード EKSワーカーノード(EC2) 障害発生ポイント EKSワーカーノード(EC2) EKSワーカーノード(EC2) topologySpreadConstraintsを用いて AZ,ワーカーノード間で分散してアプリケーションPodを起動させる障害発生ポイント障害発生ポイント障害発生ポイントアプリケーションPod アプリケーションコンテナサイドカーコンテナアプリケーションコンテナサイドカーコンテナ障害発生ポイント接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 7.クラスタ接続元コンポーネントの設計ポイントを検討する 1. インフラ基本設計 ◼自動リトライ ⚫ 自動リトライを行うか、関連パラメータをどの様に設定するかが設計ポイント ⚫ 更新系問合せを自動リトライするためには、冪等性の考慮が必要接続元コンポーネントコンポーネント (サーバorコンテナor etc) クラスタコンポーネント (サーバorコンテナor etc) コンポーネント (サーバorコンテナor etc) ・・・自動リトライ機能更新系問合せ応答更新系問合せ応答更新系問合せ応答自動リトライ自動リトライ障害発生データストアデータ挿入データ挿入接続元コンポーネントの自動リトライにより、データの二重登録が行なわれてしまう接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

② 耐障害性設計 7.クラスタ接続元コンポーネントの設計ポイントを検討する 1. インフラ基本設計 ◼サーキットブレーカー ⚫ 障害を検知した際に問合せを自動で遮断し、スレッド涸渇を回避する接続元コンポーネントサーキットブレーカー機能問合せアプリケーションサーキットブレーカー：無効サーキットブレーカー発動サーキットブレーカー：有効スレッド処理実施問合せ即時エラー応答問合せ応答スレッド処理実施待機問合せ問合せサーキットブレーカー導入でスレッド枯渇を回避するスレッド処理実施問合せ即時エラー応答問合せ応答コンポーネント (サーバorコンテナor etc) コンポーネント (サーバorコンテナor etc) ・・・障害発生コンポーネント (サーバorコンテナor etc) クラスタ接続設計耐障害性設計性能設計拡張性設計 1. システムの単一障害点をクラスタ化する 2. クラスタの障害発生ポイントを洗い出す 3. クラスタの実行環境の障害発生ポイントを洗い出す 4. 障害発生ポイント毎のクラスタの復旧動作を整理する 5. クラスタのヘルスチェック設計を行う 6. クラスタの分散配置設計を行う 7. クラスタ接続元コンポーネントの設計ポイントを検討する

③ 性能設計 1. インフラ基本設計 ◼性能要件を満たすために必要となる、各コンポーネントのCPU/メモリ等のスペックや台数を検討する。これらの検討は一般的にサイジングと呼ばれる 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

③ 性能設計 1. インフラ基本設計 ◼性能要件を満たすために必要となる、各コンポーネントに割り当てるCPU数やメモリ容量等のスペックやコンポーネントの台数を検討する 1. 1台のサーバ/コンテナのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討するサイジングが不十分だと余計にクラウド利用料を払っている事に気付けない恐れあり！

③ 性能設計 1.サーバ/コンテナ1台あたりのスペックを検討する 1. インフラ基本設計 ◼考慮ポイントは以下 ①更改前・類似システムのスペックを参考にする ②ソフトウェアの推奨スペックを確認する・実績あるスペックを参考にする事で、リソース不足に起因する障害発生のリスクを抑えられる・既存システムの稼働統計情報や性能テストの結果などから、何処にボトルネックがあるのかの確認も重要・コンテナのスペックがソフトウェアの推奨を満たせているか公式ドキュメントやサポート窓口経由でチェック接続設計耐障害性設計性能設計拡張性設計 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

③ 性能設計 2.サーバ/コンテナ1台あたりのスループットを算出する 1. インフラ基本設計 ◼1台あたりのスペックが確定したら、それがどれだけのスループットを出せるのかを算出する ⚫ 秒間あたりトランザクション数、API応答数など ◼更改前システム/類似システム/プロトタイプの情報を元に算出更改前システム/類似システム/プロトタイプコンテナスペック・仮想CPU数： 200m ・メモリ容量： 1Gi コンテナスペック・仮想CPU数： 400m ・メモリ容量： 1.5Gi ・最大スループット・最大スループット出力時のCPU使用率稼動統計情報/性能テスト結果スペック差異出力可能なスループット稼動統計情報とスペック差異から、出力可能なスループットを算出する接続設計耐障害性設計性能設計拡張性設計 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

③ 性能設計 3.性能要件を満たすためにサーバ/コンテナが何台必要か算出する 1. インフラ基本設計 ◼システムの性能要件を満たすためには、どれだけの台数用意する必要があるのかを算出 ◼性能要件として定められたスループットを、算出した1台あたりのスループットで割る ◼Deploymentのspec.replicasの値として設定 ◼場合によっては性能要件を越えるリクエスト発生や障害発生時を考慮して、追加の台数を起動させる事も検討 apiVersion: apps/v1 kind: Deployment metadata: name: app-deployment spec: replicas: 4 Deploymentマニフェストファイル接続設計耐障害性設計性能設計拡張性設計 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

③ 性能設計 4.オーバーコミットの許容範囲を検討する 1. インフラ基本設計 ◼Kubernetesのスペック設定のパラメータは2段階ある ⚫ Requests: 起動時からコンテナに確保されるリソースの最低保証値 ⚫ Limits: コンテナに割り当て可能なリソースの上限値 Pod アプリケーションコンテナ仮想CPU数メモリ容量 Limit 1,000m Request 200m Limit 800Mi Request 600Mi Requestsでコンテナに確保される最低限のリソースを指定する Limitsでコンテナに割り当てるリソースの上限を指定する接続設計耐障害性設計性能設計拡張性設計 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

③ 性能設計 4.オーバーコミットの許容範囲を検討する 1. インフラ基本設計 ◼コンテナ稼動に必要なワーカーノードの台数やスペックは、Requests値の積み上げに依存 ◼Requestsを小さく設定する事で、ワーカーノードの総リソースを抑えられる ◼所謂オーバーコミットが可能 ◼オーバーコミットで、クラウド利用料を抑える事ができるワーカーノードの総リソース仮想CPU数:XX メモリ容量:XX 仮想CPU数:XX メモリ容量:XX 仮想CPU数:XX メモリ容量:XX 仮想CPU数:XX メモリ容量:XX 仮想CPU数:XX メモリ容量:XX Requestsで指定したコンテナの総リソース仮想CPU数:YYメモリ容量:YY 仮想CPU数:YYメモリ容量:YY 仮想CPU数:YYメモリ容量:YY 仮想CPU数:YYメモリ容量:YY 仮想CPU数:YYメモリ容量:YY 仮想CPU数:ZZ メモリ容量:ZZ サイジングしたコンテナの総リソース仮想CPU数:ZZ メモリ容量:ZZ 仮想CPU数:ZZ メモリ容量:ZZ サイジングしたコンテナの総リソースより、ワーカーノードの総リソースが小さい → オーバーコミット接続設計耐障害性設計性能設計拡張性設計 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

③ 性能設計 4.オーバーコミットの許容範囲を検討する 1. インフラ基本設計 ◼許容範囲は、クラウド利用料とリソース枯渇のリスクを考慮して決める必要あり ⚫ 開発環境のオーバーコミットの度合いを本番環境よりも高める ⚫ コンテナの重要度で度合いを変化させる事で、信頼性とクラウド利用料のバランスを取る Requestsで指定したコンテナの総リソースワーカーノードの総リソースサイジングしたコンテナの総リソース Requestsで指定したコンテナの総リソースワーカーノードの総リソースサイジングしたコンテナの総リソース開発環境本番環境開発環境のRequestsを本番環境より小さくする。その結果必要なワーカーノードが本番環境より少なくなる。システムの機能提供に重要なコンテナ仮想CPU数メモリ容量 Limit Request Limit Request RequestsとLimitsの差を小さくする事で、リソースが確保できないリスクを極小化するシステムの機能提供に重要でないコンテナ仮想CPU数メモリ容量 Limit Request Limit Request RequestsとLimitsの差を大きくする事で、オーバーコミットの度合いを大きくする接続設計耐障害性設計性能設計拡張性設計 1. サーバ/コンテナ1台あたりのスペックを検討する 2. サーバ/コンテナ1台あたりのスループットを算出する 3. 性能要件を満たすためにサーバ/コンテナが何台必要か算出する 4. オーバーコミットの許容範囲を検討する

④ 拡張性設計 1. インフラ基本設計 ◼拡張性設計では、迅速なリソース拡張のための仕組みや手順を整理する ◼クラウド利用料の最適化には、クラウドやKubernetesの機能を活用し、システムの処理量に自動でリソースを追従させる事が効果的 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する時間システムの処理量拡張縮小リソース拡張拡張拡張縮小縮小

④ 拡張性設計 1. インフラ基本設計 ◼拡張性設計では、迅速なリソース拡張のための仕組みや手順を整理する ◼クラウド利用料の最適化には、クラウドやKubernetesの機能を活用し、システムの処理量に自動でリソースを追従させる事が効果的 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する時間システムの処理量拡張縮小リソース拡張拡張拡張縮小縮小クラウドが持つリソース確保の迅速性、容易性を最大限享受するには緻密な拡張性設計が重要！

コンポーネント (サーバ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. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 1.リソース拡張の基本方針を検討する 1. インフラ基本設計 ◼ロードバランサと複数サーバ/コンテナによる並列クラスタ構成はスケールアウトが比較的容易 ◼以下の点が迅速なスケールアウトを妨げる要因となるため注意が必要ロードバランササーバ/コンテナサーバ/コンテナ NEW IPアドレスリソース OS ソフトウェアアプリケーション監視ソフトウェアサーバ/コンテナ IPアドレスが自動で設定されない使われていないIPアドレスの選定とサーバ/コンテナへの設定を手動で行う必要がある監視設定を手動で行う必要がある OSやソフトウェアのライセンス体系が台数や仮想CPUコア数等に基づく接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 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. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 2.リソース拡張を行う契機を整理する 1. インフラ基本設計 ◼リソース拡張には一時的なものと恒久的なものがある ◼一時的なリソース拡張は、リクエストが上昇した場合や、リソースを大きく消費した場合、それらが見込まれる日時に先立って行われる事が一般的 ◼一時的なリソース拡張に対して、リソース縮小を行う契機も合せて整理クラスタ内に含まれる全てのコンテナのCPU使用率を平均したものが、 90％を越えたら毎月25日の9時には問合せ量が大きく上昇するので、その30分前である8時30分にコンテナ1台が処理した単位時間あたりの問合せ数が、 300を越えたらクラスタ内に含まれる全てのコンテナのCPU使用率を平均したものが、 50％を下回ったら毎月25日の11時にはリクエスト量が落ち着くので、その30分後である11時30分にコンテナ1台が処理した単位時間あたりの問合せ数が、 50を下回ったら一時的なリソース拡張の契機の例リソース縮小の契機の例接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 2.リソース拡張を行う契機を整理する 1. インフラ基本設計 ◼恒久的なリソース拡張は、維持運用フェーズのインフラキャパシティ管理として実施時間 CPU使用率 80％ 2ヶ月後 1ヶ月後現在 2ヶ月後にCPU使用率が80％を上回る事が予測されるため恒久的なリソース拡張を計画する最大CPU使用率の近似直線需要予測これまでの使用実績データを元に、サーバ1台あたりの最大CPU使用率の近似直線を作成する。近似直線に需要予測を加味したものが2ヶ月後にCPU使用率80％を越える事が予想される場合にリソース拡張を実施恒久的なリソース拡張の契機の例接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 3.リソース拡張/縮小に必要な作業を洗い出す 1. インフラ基本設計 ◼拡張/縮小のための具体的な作業を詳細に洗い出す ◼自動化のインプットとしても、拡張/縮小作業の洗い出しは非常に重要 CICDパイプラインアプリケーションPod アプリケーション ClusterIP Service アプリケーションPod アプリケーションPod アプリDeployment apiVersion: apps/v1 kind: Deployment metadata: name: app-deployment spec: replicas: 3 → 4 Deploymentマニフェストファイル ① ② 変更を適用アプリケーションPod NEW ③ No. スケールアウト作業内容 ① 該当アプリケーションのDeploymentマニフェストファイル内のspec.replicasの値を、スケールアウト後のアプリケーションPodの数に書き換える ② CICDパイプラインを用いて、修正したDeployment マニフェストファイルの変更を適用する ③ k8sクラスタは、Deploymentマニフェストファイルの変更内容に従い、アプリPodを追加する。アプリケーションPodのスケールアウトの例接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 3.リソース拡張/縮小に必要な作業を洗い出す 1. インフラ基本設計 ◼接続元のコンポーネントの作業も確認する事で、実際のリソース拡張/縮小作業時に、考慮漏れによる問題を避ける事ができる Aurora PostgreSQLクラスタのスケールアップ作業の例 No. スケールアップ作業内容 ① AWSマネジメントコンソールから2号機インスタンスのインスタンスタイプを上位のものに変更する ② Aurora PostgreSQLクラスタのフェイルオーバを行う。これにより、1号機インスタンスをプライマリインスタンスからレプリカインスタンスに降格させる ③ 1号機インスタンスのインスタンスタイプを上位のものに変更する ④ 再度Aurora PostgreSQLクラスタのフェイルオーバを行う。これにより、1号機インスタンスを再度プライマリインスタンスに昇格させる ⑤ 管理サーバからアプリケーションPodの再起動を行う。これによりAurora PostgreSQLクラスタとのDB コネクションの再確立を行う接続元であるアプリPodの作業接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 1. インフラ基本設計 ◼一時的なリソース拡張/縮小作業は、システムの機能提供中に求められる事が多い ◼その場合でも、機能提供に影響を与えない様に作業を行う必要がある時間システムの処理量リソース拡張縮小一時的なリソース拡張/縮小作業はシステムの機能提供中に求めらえる事が多い → システムの機能提供に影響を与えずに作業を行う必要がある接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 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. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 5.リソース拡張/縮小の”作業”の自動化を検討する 1. インフラ基本設計 ◼作業を自動化する事で工数・手間、作業時間、作業ミスの確率を極小化できる ◼工数と時間を減らせる分、一時的なリソース拡張が行い易くなる ◼Kubernetesの機能のHorizontal Pod Autoscaler(HPA)を用いる事で、Podの自動スケールアウト、スケールインが可能アプリケーションPod アプリケーション Horizontal Pod Autoscaler アプリDeployment アプリケーションPod アプリケーションPod スケールアウト/ インを指示スケールアウト/イン作業を自動化接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

④ 拡張性設計 6.リソース拡張/縮小の”発動”の自動化を検討する 1. インフラ基本設計 ◼前のステップで整理した、契機(CPU使用率やリクエスト数等)を自動発動の設定に落とし込む ◼発動を自動化する事で、より処理量に追従したリソース拡張・縮小を行える Pod Horizontal Pod Autoscaler Deployment 閾値メトリクス対象Deployment 等設定設定 Prometheus Adapter for Kubernetes Metrics APIs Kubernetes カスタムメトリクス変換 Prometheus メトリクス Prometheusメトリクスを契機としてHPAを設定するイメージ ①Prometheus Adapter for Kubernetes Metrics APIs を導入し、Prometheusメトリクスを、 HPAが連携可能なKubernetesのカスタムメトリクスに変換する。 Pod Pod ②カスタムメトリクスをHPAのマニフェストに設定する閾値は、予め整理したリソース拡張/縮小の契機のものを使用する接続設計耐障害性設計性能設計拡張性設計 1. リソース拡張の基本方針を検討する 2. リソース拡張を行う契機を整理する 3. リソース拡張/縮小に必要な作業を洗い出す 4.拡張/縮小作業がシステムの機能提供へ及ぼす影響を確認する 5. リソース拡張/縮小の”作業“の自動化を検討する 6. リソース拡張/縮小の”発動”の自動化を検討する

インフラ設計・テストのV字モデル 2. インフラテスト ◼インフラ設計工程とテスト工程はV字で表現できる ◼設計工程とマッチしたテストを実施時間経過インフラ単体テストインフラ連結テスト総合テストインフラ構築パラメータ設計インフラ基本設計要件定義インフラ設計工程インフラテスト工程詳細概要本日の説明範囲

インフラ設計・テストのV字モデル 2. インフラテスト ◼インフラ設計工程とテスト工程はV字の形で表現する事ができる ◼設計工程とマッチしたテストを実施時間経過インフラ単体テストインフラ連結テスト総合テストインフラ構築パラメータ設計インフラ基本設計要件定義インフラ設計工程インフラテスト工程詳細概要設計した内容は、その通りに動作してはじめて意味を持ちます！

インフラテストの進め方 2. インフラテスト ◼それぞれのテスト工程で、テスト計画から結果評価まで行う ◼品質に問題無い事を確認した後、次のテスト工程を開始する事が基本 ◼確認漏れや手戻り無く、効率的にインフラの品質を確認できる 1.テストを計画する 2.テストの事前準備を行う 3.テストを実施する 4.テスト結果を評価するインフラ単体テスト計画準備実施評価インフラ連結テスト計画準備実施評価総合テスト計画準備実施評価テスト結果の評価を行い、十分品質を確保できている事を確認してから、次のテストを開始する本日の説明範囲 (テスト分類/テストケース作成の考え方/テストケース例)

① インフラ単体テスト 2. インフラテスト ◼システム内の各コンポーネントが設計通りに構築されているか、単体での動作を問題無く行えるかを確認 ◼インフラ品質の積み上げの土台として、まずは各コンポーネントの品質を確認するアプリケーションインフラコンポーネントコンポーネントコンポーネントシステムインフラ単体テストシステム内に構築するコンポーネントそれぞれで以下を確認・設計通りに構築されているか・単体での動作を問題無く行う事ができるかインフラ品質の土台として、まずは各コンポーネントの品質を確認

① インフラ単体テストテスト分類 2. インフラテスト ◼パラメータ確認テストで、コンポーネントのパラメータが設計通りに設定されているかを確認 ⚫ IaCでインフラ構築を自動化している場合でも、コードの誤り等が原因で設計通りにインフラが構築されないリスクあり。そのためIaCを用いる場合でもパラメータ確認テストは必要 ◼基本機能確認テストで、コンポーネント単体の期待動作を行えるか確認コンポーネント (サーバorコンテナor etc) パラメータパラメータ設計どおりにコンポーネントのパラメータは設定されているか比較パラメータ設計書コンポーネントコンポーネント単体は期待する動作を問題無く行えるか通信のルーティングコンポーネント DNSリクエストへの応答コンポーネントログ転送コンポーネント HTTPリクエストへの応答 Etc・・・・・確認確認確認確認パラメータ確認テスト基本機能確認テスト

① インフラ単体テストテストケースの例 2. インフラテスト ➢ 狙い：NGINX のKubernetesマニフェストがパラメータ設計で整理したものと同一かどうかを確認する。 ➢ 確認手順：テスト環境にデプロイしたNGINX に関連するDeployment等のAPIリソースのマニフェストをkubectlコマンドで出力する。出力されたマニフェストの設定内容と、パラメータ設計で整理したものとを比較する。 ➢ 期待結果：kubectlコマンドで出力されたマニフェストの設定内容が、パラメータ設計の内容と同一である事。 ➢ エビデンス：kubectlコマンドの出力ログパラメータ確認テスト: NGINX のKubernetesマニフェスト確認 ➢ 狙い： EKSクラスタ上に構築したNGINX Podが、HTTPS問合せの応答を正常に行う事ができるかを確認する。 ➢ 確認手順：テスト環境のEKSクラスタ上に構築したNGINX Podに対して、テスト用PodからHTTPS問合せを行う。 ➢ 期待結果： NGINX Podからステータスコードが200 OKのHTTPS応答が返却される事。 ➢ エビデンス：テスト用Podの操作ログ、NGINX Podのログ基本機能確認テスト: NGINX PodによるHTTPS応答

② インフラ連結テスト 2. インフラテスト ◼インフラ連結テストでは複数コンポーネントが協調動作を行い、期待する動作を問題無く行えるかを確認するアプリケーションインフラコンポーネントコンポーネントコンポーネントシステムインフラ連結テスト複数コンポーネントが協調動作を行い、期待する動作を問題無く行う事ができるかを確認・コンポーネント間で想定通り接続できるか・コンポーネントに問題が発生した場合に、期待する復旧動作が行えるか・クラスタは想定通りに自動で性能拡張/縮小するか Etc..

② インフラ連結テストテスト分類 2. インフラテスト ◼インフラ連結テストの分類はインフラ基本設計の分類とリンクする接続設計可用性設計(耐障害性設計) 性能設計拡張性設計運用設計セキュリティ設計災害復旧設計インフラ基本設計接続テスト障害テスト性能テスト拡張テスト運用テストセキュリティテスト災害復旧テストインフラ連結テスト本日の説明範囲

② インフラ連結テストアプリケーションに設定されるインフラ基本設計の内容の確認 2. インフラテスト ◼アプリマニフェストにインフラ基本設計の内容を設定する ◼インフラ連結テストで確認できない場合は、総合テストに申し送る等の対応が必要アプリケーションPod ・Podの数： 3 ・ワーカーノード間でPodを分散配置する・起動しておくべき最小Pod数： 2 ・コンテナに対して5秒おきにHTTPヘルスチェック送信・・・・コンテナあたりの上限CPU： 0.5vCPU ・コンテナあたりの上限メモリ容量： 1GiB ・・・・CPU使用率が80％以上になったらPodの台数を増やす・CPU使用率が50％以下になったらPodの台数を減らす・コンテナ停止前に60秒Sleepする・・・アプリケーションPod関連のマニフェスト(イメージ) 耐障害性設計のパラメータ性能設計のパラメータ拡張性設計のパラメータ適用アプリケーションコンテナアプリケーションPodに関連するマニフェストに、インフラ基本設計で整理した設計観点を設定する必要がある・・・

② インフラ連結テストアプリケーションに設定されるインフラ基本設計の内容の確認 2. インフラテスト ◼Kubernetesを用いる場合、アプリマニフェストにインフラ基本設計の内容を設定する必要がある ◼インフラ連結テストで確認できない場合は、総合テストに申し送る等の対応が必要アプリケーションPod ・Podの数： 3 ・ワーカーノード間でPodを分散配置する・起動しておくべき最小Pod数： 2 ・コンテナに対して5秒おきにHTTPヘルスチェック送信・・・・コンテナあたりの上限CPU： 0.5vCPU ・コンテナあたりの上限メモリ容量： 1GiB ・・・・CPU使用率が80％以上になったらPodの台数を増やす・CPU使用率が50％以下になったらPodの台数を減らす・コンテナ停止前に60秒Sleepする・・・アプリケーションPod関連のマニフェスト(イメージ) 耐障害性設計のパラメータ性能設計のパラメータ拡張性設計のパラメータ適用アプリケーションコンテナアプリケーションPodに関連するマニフェストに、インフラ基本設計で整理した設計観点を設定する必要がある・・・アプリ/基盤チーム間でポテンヒットになりがち！確認漏れが無い様に歩み寄りが必要！

② インフラ連結テスト 1.接続テスト 2. インフラテスト ◼接続設計でコンポーネント間の接続パターンを詳細に整理している ◼接続パターンをインプットに、整理した通りに接続できるか確認接続パターンコンポーネントコンポーネントコンポーネントコンポーネント接続パターン接続パターン・・・接続設計通りに各接続パターンの接続が行えるのかを確認する確認確認確認

② インフラ連結テスト 1.接続テスト/テストケース作成の考え方 2. インフラテスト ◼基本的に接続設計で整理した全ての接続パターンをテスト対象にする ◼接続パターン毎に、整理した項目通りに接続できるのか、機能するのかを確認するためのテストケースを作成経由するコンポーネント通信プロトコル認証/認可方法文字コードタイムアウト制御 Etc… 接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 1.接続テスト/テストケースの例 2. インフラテスト ➢ 狙い： ALBからNGINX Podへの接続を接続設計通りに行う事ができるか確認する。 ➢ 確認手順：テスト用サーバからALBに対してHTTPS問合せを行う。 ➢ 期待結果： NGINX Podからステータスコードが200 OKの応答が返却される事。その際、接続設計で整理した項目通りにALBとNGINX Podとの間で問合せ・応答のやりとりが行われている事。 ➢ エビデンス：テスト用サーバの操作ログ、ALBのログ、NGINX Podのログ ALBからNGINX Podへの接続 ➢ 狙い： NGINX PodからアプリケーションPodに接続するパターンで整理した、NGINX Podのタイムアウトが接続設計通りに行われる事を確認する。 ➢ 確認手順：疑似的な処理遅延を発生させる様に設定した接続テスト用アプリケーションPodをテスト環境のEKSクラスタ上にデプロイする。NGINX Podは問合せをアプリケーションPod(正確にはClusterIP Service)にリバースプロキシする様に設定する。テスト用PodからNGINX Podに対して問合せを行う。 ➢ 期待結果： NGINX Podからステータスコードが504 Gateway Timeoutの応答が返却される事。接続設計で整理した値でNGINX Podのタイムアウトが発生している事。 ➢ エビデンス：テスト用Podの操作ログ、NGINX Podのログ NGINX Podのタイムアウト接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 2.障害テスト 2. インフラテスト ◼耐障害性設計で、障害発生ポイント毎に期待する復旧動作を整理している ◼障害を擬似的に発生させ、想定通り復旧動作を行うかを確認するクラスタコンポーネントコンポーネントコンポーネントコンポーネントクラスタ・・・障害発生ポイント疑似的な障害発生復旧動作復旧動作クラスタ耐障害性設計通りに各クラスタが復旧動作を行えるのかを確認する確認確認

② インフラ連結テスト 2.障害テスト/テストケース作成の考え方 2. インフラテスト ◼クラスタ毎に整理した障害発生ポイント・復旧動作単位でテストケースを作成する ◼処理中に障害が発生した際の動作を確認するケースも場合によって用意アプリケーションPod アプリケーションコンテナ Aurora PostgreSQL 1号機インスタンス Aurora PostgreSQL 2号機インスタンス Aurora PostgreSQLクラスタアプリケーションPod アプリPodの並列クラスタトランザクション処理 Aテーブル更新クエリ実行 Bテーブル更新クエリ実行 Cテーブル更新クエリ実行 Aテーブル更新 Bテーブル更新コンテナダウン発生 Aテーブルロールバック Bテーブルロールバックトランザクション処理・・・問合せ応答問合せ応答トランザクション処理中にアプリケーションコンテナダウンが発生した場合、処理がロールバックされる事を期待する接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 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クラスタ間で行われるトランザクション処理の復旧動作確認接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト 2. インフラテスト ◼性能設計ではサイジングを行い、各コンポーネントのスペックと台数を決めている ◼サービス稼働を想定したボリュームの処理を実行し、性能に関連する観点を確認するアプリケーションインフラコンポーネント ※サイジング通りのスペック/台数テスト環境サービス稼働を想定したボリュームの処理を実行確認コンポーネント ※サイジング通りのスペック/台数コンポーネント ※サイジング通りのスペック/台数サイジングしたコンポーネントで性能要件を満せるのかどこまでの性能で処理を行う事ができるのか長期間安定した性能で処理を行えるか

② インフラ連結テスト 3.性能テスト/テストケース作成の考え方 2. インフラテスト ◼テストケースは、性能テストの種類をベースに作成する ◼オンライン処理性能テスト ⚫ サービス稼働を想定した量の擬似的な問合せを行い、スループットや、レスポンスタイム等のオンライン処理の性能要件を満たせるか、リソース使用量は想定範囲かなどを確認インフラアプリケーションテスト環境サービス稼働を想定したオンライン処理を実行負荷テストツールテストシナリオサービス稼働を想定した量の問合せコンポーネントコンポーネントコンポーネント確認・オンライン処理の性能要件を満たす事ができるか (スループット、レスポンスタイム Etc..) ・エラーは発生していないか確認・リソース使用量は想定の範囲に収まっているか・エラーは発生していないかテストデータ接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト/テストケース作成の考え方 2. インフラテスト ◼バッチ処理性能テスト ⚫ サービス稼働相当の件数・構造・偏りを持ったテストデータを用いてバッチ処理を実行し、所定の時間内に完了するか、リソース使用量は想定範囲かなどを確認 ⚫ 必要に応じてバッチ処理を並走させるテストを実施インフラアプリケーションテスト環境バッチ処理A コンポーネントコンポーネントコンポーネントテストデータバッチ処理B バッチ処理C ・・・・確認・バッチ処理を並走させても全て所定の時間内に完了するか・エラーは発生していないか確認・リソース使用量は想定の範囲に収まっているか・エラーは発生していないか複数のバッチ処理を並走させる接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト/テストケース作成の考え方 2. インフラテスト ◼オンライン/バッチ処理並走テスト ⚫ システムによってはオンライン処理とバッチ処理で共通のコンポーネントを利用する事がある(例:データベース) ⚫ 処理が並走する事で、共通のコンポーネントがボトルネックになるリスクがあるため性能テストで確認インフラアプリケーションテスト環境オンライン処理負荷テストツールテストシナリオデータベースコンポーネントテストデータバッチ処理オンライン処理とバッチ処理を並走させるオンライン処理とバッチ処理で共用するコンポーネント(例：データベース)がボトルネックにならないか要注意確認・オンライン処理の性能要件を満たす事ができるか (スループット、レスポンスタイム Etc..) ・バッチ処理は所定の時間内に完了するか・エラーは発生していないか確認・リソース使用量は想定の範囲に収まっているか・エラーは発生していないかコンポーネント接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト/テストケース作成の考え方 2. インフラテスト ◼限界性能テスト ⚫ 構築したシステムがどこまでの性能を発揮できるのかを確認する ⚫ 問合せの量を徐々に増やしていき、それに伴うスループットの変化を確認。スループットの伸びが鈍化する箇所を限界性能と考える問合せの量スループット限界性能のスループット ①あるところまでは、問合せの量に比例する形でスループットも増加する ②あるところからスループットの伸びが鈍化していき、問合せの量を増やしてもスループットが伸びなくなる。限界性能接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト/テストケース作成の考え方 2. インフラテスト ◼ロングランテスト ⚫ オンライン処理を長期間継続させ、性能劣化が発生せずに安定して処理を継続できるのかを確認 ⚫ ロングランテストの期間の決め方として、アプリケーションがどれだけ起動し続けるのかを参考にする、が一例月火水木金土日月火水木金土日アプリリリースアプリリリース月火水アプリリリースアプリケーションコンテナ/プロセスが起動し続ける期間ロングランテストの実施期間ロングランテストの実施期間期間圧縮アプリケーションは毎週リリースを行うコンテナ/プロセスが起動し続ける期間とロングランテストの実施期間を合せる問合せ量をそのままに期間を圧縮する事もあるアプリケーションコンテナ/プロセスが起動し続ける期間接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト/テストケースの例 2. インフラテスト ➢ 狙い：サイジングしたコンポーネントを用いてオンライン処理を行い、性能要件を満たす事ができるのか、リソース使用量は想定の範囲に収まっているか等を確認する。 ➢ 確認手順：負荷テストツールからテスト環境に対して、実際のサービス稼働を想定した量の擬似的な問合せを実行する。 ➢ 期待結果：以下が確認できる事。 ➢ 負荷テストツールのログから、性能要件として規定されたスループットを満たせていること ➢ 負荷テストツールのログを確認し、実施した問合せに対してエラーが返ってきていないこと ➢ システムを構成するコンポーネントのログを確認し、問題が発生していないこと ➢ コンポーネントのリソース使用量が運用設計の監視閾値より下回っていること ➢ エビデンス：負荷テストツールのログ、システムを構成するコンポーネントのログ、コンポーネントのリソース使用量が出力されたテキスト・スクリーンショットオンライン処理性能テスト接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 3.性能テスト/テストケースの例 2. インフラテスト ➢ 狙い：オンライン処理を長期間継続させ、安定して処理を継続できるのか、リソース消費に問題は見られないか等を確認する。 ➢ 確認手順：オンライン処理性能テストで用いた負荷テストツールおよびテストシナリオを用いて、擬似的な問合せを一定期間行う。 ➢ 期待結果：ロングランテストを実施した期間全てを対象に以下が確認できる事。 ➢ 負荷テストツールのログから、ロングランテストとして定められたスループットを満たせていること ➢ 負荷テストツールのログを確認し、実施した問合せに対してエラーが返ってきていないこと ➢ システムを構成するコンポーネントのログを確認し、エラーが発生していないこと ➢ コンポーネントのリソース使用量が運用設計の監視閾値より下回っていること ➢ コンポーネントのリソース使用量に上昇傾向が見られないこと ➢ エビデンス：負荷テストツールのログ、システムを構成するコンポーネントのログ、コンポーネントのリソース使用量が出力されたテキスト・スクリーンショットロングランテスト接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

② インフラ連結テスト 4.拡張テスト 2. インフラテスト ◼拡張テストでは主に以下を確認 ⚫ 拡張性設計で整理した作業手順でリソース拡張/縮小が行えるか ⚫ 拡張性設計で整理したリソース拡張/縮小の自動化の仕組みが想定通りに動作するのかクラスタコンポーネントコンポーネントコンポーネントクラスタ・・クラスタ拡張性設計通りに各クラスタがリソース拡張/縮小を行えるのかを確認するリソース拡張/縮小の作業手順リソース拡張/縮小の自動化の仕組みコンポーネントリソース拡張/縮小確認確認リソース拡張/縮小の作業手順リソース拡張/縮小の自動化の仕組み

② インフラ連結テスト 4.拡張テスト/テストケース作成の考え方 2. インフラテスト ◼拡張性設計でクラスタ毎にリソース拡張/縮小の実現方法を整理している ◼その整理を網羅する様にテストケースを作成するのが一般的接続テスト障害テスト性能テスト拡張テストテストケースの考え方テストケース例

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

◼高品質なITインフラを構築するためには、インフラ基本設計・インフラテストが重要！ ◼クラウド・Kubernetesを活用したシステムで行うためには、、、まとめ複雑になりがちなコンポーネント間の協調動作の仕組みを詳細に理解・整理する事が重要！説明責任を果せるのがインフラエンジニアの差別化要因！インフラ基本設計インフラ設計の内容を漏れなく確認！アプリ設定にも踏み込む事で確認漏れを無くす！インフラテスト

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

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

More Decks by 高棹大樹

Other Decks in Technology

Featured

Transcript