【CNDW2025】クラウド時代の設計と検証を再構築し、Kubernetesでエンタープライズのインフラ設計とテスト手法を整理

CloudNative Days Winter 2025では「Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全」というセッションで、野村総合研究所 エキスパートアーキテクトの高棹大樹氏が、クラウド時代に求められるインフラ設計・テストの要点を解説した。オンプレミスで成熟してきた手法は、そのままではKubernetesを前提とする環境では十分に活かせない部分があり、構成要素が相互に影響し合うクラウド特有の前提を踏まえた整理が欠かせないという。

クラウド時代に求められるインフラ設計の前提を再整理する

エンタープライズシステムのインフラ設計・テスト手法は長年の運用で体系化され、金融をはじめとするミッションクリティカル領域では品質確保に欠かせない。しかしこれらはオンプレミスを前提に発展してきたものであり、パブリッククラウドの柔軟性やスケーラビリティを十分に活かすには、従来の考え方をそのまま当てはめるだけでは不十分である。

クラウドリフトが一巡した現在、企業はマネージドサービスや動的スケールを活用し、アジリティ向上を目指している。一方でVPC、ALB、EKS、Pod、SQS、Auroraなど多様なコンポーネントが連携するクラウド環境では、構成要素が相互に影響し合い、環境そのものが動的に変化する。そのため、単体の品質だけでなく「どのようにつながり、どのように動作するか」を前提とした設計が不可欠となる。

こうした背景を踏まえ、登壇した野村総合研究所 エキスパートアーキテクトの高棹 大樹氏は冒頭で次のように語っている。「エンタープライズシステムはインフラにも高い品質が求められます。クラウドのメリットを最大限に活かすには、進め方のシフトや追加の考慮が必要になります」。続けて「今回はクラウドとKubernetesを活用したシステムを題材に、インフラ設計・テストの進め方を解説します」と本セッションの焦点を示した。

四つの設計領域でクラウド基盤の要点を明確化する

インフラ基本設計では、クラウド特有の動的挙動を踏まえ、接続・耐障害性・性能・拡張性という四つの領域を体系的に整理する必要がある。このうちのどれか一つでも欠ければ全体品質に影響するため、観点ごとに前提条件を明確にしながら積み上げていくことが重要である。

1.インフラ基本設計 インフラ基本設計の分類

1. 接続設計

接続設計では、環境全体がどの経路で通信し、どこで認証・暗号化が行われるのかを明確にする。CloudFront、ALB、EKS、Aurora、SQSなど関連コンポーネントを洗い出し、実際の通信経路がどのように構成されるかを理解することが出発点となる。加えて、プロトコルや文字コード、タイムアウト、認証・認可方式を設計段階で固定し、最終的にはアプリケーション側と接続仕様をすり合わせる。こうした整理によって「どこがどうつながっているのか」を言語化し、後続の設計の基盤を固める。

2. 耐障害性設計

耐障害性設計では、まず想定される障害ポイントを網羅し、SPOF（Single Point of Failure、単一障害点）を排除する。クラウド環境はPodの再起動やノード障害、多AZ構成の揺らぎなど障害要素が細かいため、障害単位の粒度を把握することが欠かせない。そのうえで障害発生から検知、復旧に至る流れを定義し、リトライやサーキットブレーカーなど動的な挙動も含めて整理する。復旧後の不整合を避ける仕組みまで準備しておくことで、障害時のふるまいを説明できる設計となる。

3. 性能設計

性能設計では、まずサービス全体の要求性能を明確にし、コンポーネントごとのスループットを把握する。Kubernetesの場合、Request/Limitの設定が動作に直結するため、オーバーコミットの許容範囲を踏まえて適切な設定値を決定する必要がある。さらにthrottleやevictionといった逼迫時の挙動まで見越しておくことで、ピーク時でも安定した基盤を構築できる。

4. 拡張性設計

拡張性設計は、負荷変動が前提となるクラウドにおいて、どのタイミングで拡張すべきかを定義する工程だ。スケールアップとスケールアウトの使い分け、恒久増強と一時的増加の判断基準、拡張手順の標準化などを事前に整理する。さらにHPA（Horizontal Pod Autoscaler、水平Podオートスケーラー：負荷に応じてPodの数を増減する機能）の適用可否を検討し、自動化と手動運用の役割分担を決めておくことで、拡張時の予期せぬ挙動を防止できる。

高棹氏はこれら四領域について「クラウドでは構成要素が増えるため、基本設計は従来以上に整理して説明できる状態にすることが重要です」と語り、モダンインフラにおける基本設計の重みを強調した。

設計内容を段階的に裏付けるインフラテストの要点

インフラテストは、基本設計で整理した内容が意図どおりに動作することを段階的に検証し、クラウド上でもエンタープライズ品質を担保するための工程である。AWSやKubernetesのように構成要素が多く、挙動が動的に変化する環境では、設計を「書いて終わり」にせず、一つずつ確かめながら検証していく姿勢が欠かせない。

2.インフラテスト インフラテストの進め方

1. インフラ単体テスト

最初に行う単体テストでは、設定されたパラメータが正しく反映されているか、ALB・EKS・Auroraなどの各コンポーネントが個別に正常動作するかを確認する。KubernetesではConfigMapや環境変数、Liveness/Readiness Probeなどアプリ寄りの設定も基盤側と密接に関わるため、これらも単体テストの対象となる。この境界の曖昧さを踏まえ、どこまで確認するかをチームで共有しておくことが重要である。

2. インフラ連結テスト

単体の品質を固めたうえで、コンポーネント同士が連携した際の動作を検証する連結テストへ移る。内容は基本設計の四領域、すなわち接続、耐障害性、性能、拡張性に沿って構成され、アプリ側が未完成の部分は総合テストへの申し送りを前提に進められる。

(1) 接続テスト

CloudFront、ALB、EKS、Aurora、外部サービスまで、整理した通信パターンが正しい認証情報・プロトコル・タイムアウト条件で動作するかを確認する。

(2) 障害テスト

Pod再起動、ノード障害、ALBの異常など、障害単位ごとに復旧シーケンスが期待どおりかを検証し、処理中に障害が発生した場合の中断・復旧シナリオも確かめる。

(3) 性能テスト

オンライン処理、バッチ処理、その並走、限界性能、ロングランなど複数観点から性能を測定し、スループットやリソース利用が設計と一致しているかを確認する。

(4) 拡張テスト

拡張性設計に基づき、スケールアウトや縮小が正しく行われるかを検証する。手動・自動の両方を確認し、HPAが適切に発動するか、逆に不要な拡張を引き起こさないかを見極める。

これらのテストを通じて、設計した構成がクラウド環境でも実際に期待どおり動作することが裏付けられ、初めてエンタープライズ品質を満たす基盤となる。高棹氏は「インフラテストは、設計の正しさを『動作として』確認するための重要な工程です」と語り、この工程の価値を強調した。

設計と検証を往復しながらクラウド品質を確立する

クラウド上でエンタープライズ基盤を構築するうえで重要なのは、設計とテストを分離せず、両者を往復しながら環境全体の挙動を把握し、意図したとおりに動作することを確認していく姿勢だ。クラウドは柔軟性と拡張性を備える一方、構成要素が多く動作が変化しやすいため、そのふるまいを丁寧に整理しておくことが欠かせない。

まとめ

とりわけKubernetesを採用した構成では、基盤とアプリケーションの境界が曖昧になり、設定や負荷の変化がどこに影響するかを説明することが難しくなる。だからこそ基本設計の観点を過不足なく整理し、それぞれの前提条件を明確にしておく必要がある。テストでは、設計で定義した内容を一つずつ動作として裏付け、想定との差分を着実に解消することで、クラウド特有の動的な環境にも安定して耐えられる基盤が形成される。

クラウドネイティブな基盤づくりは、従来の延長ではなく、環境全体のふるまいを理解し説明できることが新たな価値になる設計手法である。しかしこの前提を押さえれば、クラウドのメリットはエンタープライズ領域でも十分に発揮できる。高棹氏は最後に「SIerでもクラウドネイティブできます」と語り、従来の設計力と品質担保の知見を活かしながらクラウドへ適応することで、エンタープライズ基盤はさらに進化できると強調した。