インフラエンジニア必見!Kubernetesを用いたクラウドネイティブ設計ポイント大全

インフラエンジニア必見! Kubernetesを用いたクラウドネイティブ設計ポイント大全 Tech Challenge Party 2026 2026年2月4日株式会社野村総合研究所
マルチクラウドインテグレーション事業本部金融基盤サービス部エキスパートアーキテクト高棹大樹

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の利用は増えている可搬性、拡張性を求めてコンテナベースのシステム開発 Kubernetesはとっつきづらい、学習コストが高いという声をよく聞きますコンテナ管理にKubernetesを採用

確かにKubernetesには知らなきゃいけないことが色々ある。。 Kubernetesの概要と、Kubernetesを使ってシステム構築する際のインフラ設計のポイントを解説します！理解してしまえば様々な環境で使えるポータブルスキル！学習する価値はある！マニフェスト? Pod? なにそれ。。。。

アジェンダ Kubernetesが行う役割・特徴 01 Kubernetesの主要コンポーネント 02 Kubernetesのインフラ設計ポイント 03

◼聴いて頂きたい方 ⚫ Kubernetesに興味がある方 ⚫ システムのインフラ設計・構築経験はあるもののKubernetesはこれから学習される方 ◼注意事項 ⚫ ITインフラを設計する上で必要な考慮点・設計ポイントが網羅されている訳では無い点ご了承ください聴いて頂きたい方・注意事項

Kubernetesって何？ 1. Kubernetesが行う役割・特徴 ◼コンテナ化されたアプリケーションを自動で配置・スケーリング・管理するためのオーケストレーションプラットフォーム ◼元々Google で開発され、現在は CNCF（Cloud Native Computing Foundation）が運営している ◼略してK8s

役割①: コンテナの配置管理 1. Kubernetesが行う役割・特徴サーバコンテナA サーバサーバコンテナB コンテナA コンテナをどのサーバ上で稼働させるのかを判断・管理するコンテナC 障害が発生してもコンテナの機能提供を継続するために、同一種類のコンテナを複数稼働させる Kubernetes

役割②: 障害発生時の退避・自動復旧 1. Kubernetesが行う役割・特徴コンテナA コンテナB コンテナA コンテナC 障害が発生したコンテナを復旧するコンテナB コンテナA サーバに障害が発生した際、そのサーバ上で稼働していたコンテナを他のサーバに退避する Kubernetes サーバサーバサーバ

役割③: コンテナのリソース拡張・アップデート管理 1. Kubernetesが行う役割・特徴コンテナA コンテナB コンテナA 問合せ量の増加等を契機として、コンテナのリソースを自動拡張するコンテナC コンテナのローリングアップデートのために、一連のコンテナの停止とデプロイの作業を、順序を守って実施するコンテナB NEW Kubernetes サーバサーバサーバ

役割③: コンテナのリソース拡張・アップデート管理 1. Kubernetesが行う役割・特徴コンテナA コンテナB コンテナA 問合せ量の増加等を契機として、コンテナのリソースを自動拡張するコンテナC コンテナのローリングアップデートのために、一連のコンテナの停止とデプロイの作業を、順序を守って実施するコンテナB NEW Kubernetes サーバサーバサーバコンテナ数が少なければ手動作業できるが、増えると困難。。 Kubernetesは自動で実施してくれる!

特徴①: 様々な形態で導入可能 1. Kubernetesが行う役割・特徴 Kubernetes オンプレミス Kubernetes パブリッククラウド様々なパブリッククラウド、オンプレミスでKubernetesを導入可能 Kubernetes上で構築したコンテナのシステム構成は、他のパブリッククラウドやオンプレミス環境へ比較的容易に移行・展開が可能 ※クラウド固有のサービスに依存する部分を除く

特徴②: マニフェストによるリソース定義 1. Kubernetesが行う役割・特徴 apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx-container image: nginx:1.25 マニフェスト Kubernetes 適用 K8sリソース望ましい状態実際の状態修復比較マニフェストをKubernetesに適用することで、K8sリソースが作成される NEW マニフェストで定義した望ましい状態と実際の状態を継続的に比較し、差分を検知した場合は自動的に修復する

特徴②: マニフェストによるリソース定義 1. Kubernetesが行う役割・特徴 Kubernetes 比較望ましい状態：コンテナ(Pod)が3つ実際の状態：コンテナ(Pod)が2つ → 1つ追加誤って削除 NEW 起動 Kubernetes利用者が誤って1つのPodを削除 Kubernetesは差分を検知し、望ましい数に合せる形で自動でPodを1つ起動する

特徴③: 高い拡張性 1. Kubernetesが行う役割・特徴プロダクト名用途主なカスタムリソース名 Istio サービスメッシュ VirtualService, DestinationRule, Gateway Linkerd サービスメッシュ ServiceProfile Argo CD GitOpsによる継続的デリバリー Application Prometheus Operator Kubernetesネイティブな監視 ServiceMonitor, PrometheusRule KEDA イベント駆動のオートスケーリング ScaledObject, TriggerAuthentication Argo Workflows バッチ処理・データパイプライン Workflow, CronWorkflow MongoDB Community Operator MongoDBクラスタ運用 MongoDBCommunity MySQL Operator MySQLクラスタ運用 MysqlCluster Postgres Operator PostgreSQLクラスタ運用 PostgresCluster ◼Kubernetesには豊富な種類のリソースがビルトインで揃っている ◼それらに加えて、独自のリソース(カスタムリソース)を定義できる ◼多数のカスタムリソースが開発されており、Kubernetesを中心とした大きなエコシステムを形成している

Pod名： mypod IPアドレス：1111.2222.3333.4444 コンテナ・Pod内には1つ以上のコンテナ・Pod内のコンテナ間は localhostで通信可能 localhost コンテナ・・・代表的なリソース①: Pod 2. Kubernetesの主要コンポーネントヘルスチェック Probe Liveness Probe（コンテナ生存確認） Readiness Probe （コンテナによるサービス提供可否確認） Startup Probe（コンテナ起動確認） Probeは稼働するコンテナのヘルスチェックを行い、異常検知時に自動修復を行うリソース容量設定最低保証値 (Requests) 上限値(Limits) コンテナに割り当てるリソース容量は2段階で指定可能

代表的なリソース②: ReplicaSet 2. Kubernetesの主要コンポーネント ReplicaSet名： myreplicaset Podの数：4 削除 /異常終了 Pod数4つを維持 Podが削除されるか異常終了した場合、自動的に新しいPodを作成してPod数を維持する NEW

Deployment名： mydeployment Podの数：4 ReplicaSet名：mydeployment -YYY NEW 新バージョンのReplicaSet 新しいPodをリリースする際、Deploymentは新しいReplicaSetを作成する代表的なリソース③: Deployment 2. Kubernetesの主要コンポーネント ReplicaSet名：mydeployment -XXX 古いReplicaSetと新しいReplicaSetが管理するPodの数を徐々に変化させる事でローリングアップデートを行う削除 NEW 削除 NEW 削除 NEW

代表的なリソース④: Service(ClusterIP) 2. Kubernetesの主要コンポーネント Deployment名： mydeployment Podのラベル： app: myapp ラベル app: myapp ラベル app: myapp ラベル app: myapp Service名：myservice type：ClusterIP 振り分け先のPodのラベル： app: myapp 紐付け仮想IPアドレス/DNS名 ClusterIPとは、安定した仮想IPアドレスとDNS名を提供し、一貫したネットワークアクセスを実現する仮想的なエンドポイント ClusterIPに対する問合せはラベルで紐付けられた複数のPodに振り分けられる

Kubernetesクラスタの構成要素 2. Kubernetesの主要コンポーネント Kubernetesクラスタワーカーノード(データプレーン) ・・・リソースを稼働させるサーバ群コントロールプレーンリソースを管理

コントロールプレーン kube-apiserver (コントロールプレーンのフロントエンド) 認証認可内容検証リソース状態取得 /作成/更新 Kubernetes API 問合せ Kubernetesクラスタの構成要素①: コントロールプレーン 2. Kubernetesの主要コンポーネント Kubernetesクラスタワーカーノード (データプレーン) ・・・ Kubernetes クラスタ利用者外部システム kube-scheduler (Pod の配置管理(スケジューリング)を実行) ノード未割り当てPod検知スケジューリングノード割り当て情報更新ウォッチ kube-controller-manager (リソースを望ましい状態に収束させる) ノード/リソース状態監視調整のためのリソース作成/更新ウォッチ etcd (全リソースの状態を保持する Key-Valueストア) リソースの状態保持

Kubernetesクラスタの構成要素②: ワーカーノード(データプレーン) 2. Kubernetesの主要コンポーネント Kubernetesクラスタコントロールプレーンワーカーノード(データプレーン) ・・・ etcd kube-apiserver ウォッチ Service/EndpointSlice 状態監視転送ルール再構成 kube-proxy (問合せをPodへ転送するネットワークプロキシ) Iptables /IPVS Pod仕様取得 Pod 起動/停止 Kubelet (Pod のライフサイクルを管理するエージェント) ノード/Pod 稼働状態報告ウォッチ

Elastic Kubernetes Service(EKS)とは？ 3. Kubernetesのインフラ設計ポイント ◼AWSのマネージドKubernetesサービス ◼コントロールプレーンの管理が不要、 IAMユーザ/ロールによる認証などが主なメリットワーカーノード(データプレーン) リソースを稼働させるサーバ群コントロールプレーンリソースを管理・・・コントロールプレーンの管理が不要 IAMユーザ/ロールによる認証

①耐障害性設計: Probeのヘルスチェック設計 3. Kubernetesのインフラ設計ポイント ◼Podを安定稼働させるためには、ヘルスチェック機能であるProbeを適切に設定する必要ありパラメータ説明 tcpSocket/httpGet.scheme ヘルスチェックのプロトコル httpGet.path ヘルスチェックのパス periodSeconds ヘルスチェックを行う間隔 failureThreshold ヘルスチェックが何回NGであればコンテナに障害が発生したとみなすか timeoutSeconds ヘルスチェックのタイムアウト Probeのパラメータの一部

①耐障害性設計: Probeのヘルスチェック設計 3. Kubernetesのインフラ設計ポイント ◼ プロトコルは原則業務通信と同一 ◼ パスはコンテナの正常稼動を確認できるものヘルスチェック𝑵𝑮の回数 − 𝟏 × ヘルスチェックの間隔 + ヘルスチェックのタイムアウト + 障害コンテナの復旧動作に掛る時間コンテナ障害発生から復旧動作完了までの最大時間 ◼ 障害復旧の目標時間に収まる様に、ヘルスチェックの間隔、ヘルスチェックNGの回数、ヘルスチェックのタイムアウト値を検討

①耐障害性設計: Podの分散配置 3. Kubernetesのインフラ設計ポイント ◼ ワーカーノードをマルチAZ構成で配置(EKSノードグループにマルチAZなサブネットを複数指定) ◼ Podを複数台起動させるだけでは不十分。偏る可能性あり。topologySpreadConstraintsを設定してワーカーノード、AZ間で分散配置するアプリケーション ClusterIP Service アプリケーションPod アプリケーションコンテナサイドカーコンテナ Availability Zone1 Availability Zone2 アプリケーションPod topologySpreadConstraints - AZ - ワーカーノード EKSワーカーノード(EC2) EKSワーカーノード(EC2) EKSワーカーノード(EC2) topologySpreadConstraintsを用いて AZ,ワーカーノード間で分散してアプリケーションPodを起動させるアプリケーションPod アプリケーションコンテナサイドカーコンテナアプリケーションコンテナサイドカーコンテナ

②メンテナンス設計: Podの安全停止設定 3. Kubernetesのインフラ設計ポイント ◼Podの退避は実際にはPodが停止し、その後別ワーカーノードでPodが起動する事で実現される ◼このPodの停止時にもシステムエラーは許容できないが、Serviceの仕様上Pod停止前にリクエストの振り分け対象から該当Podを手動で切離す事はできない EKSワーカーノード EKSワーカーノードリタイアメントで停止する必要あり ①Pod停止 ②別ワーカーノードでPod起動 Pod停止前にリクエストの振り分け対象から該当Podを手動で切離す事はできない

②メンテナンス設計: Podの安全停止設定 3. Kubernetesのインフラ設計ポイント ◼ 受入れたリクエストの処理が完了する時間分、Podが停止を待つ設定を入れる ◼ 具体的には、アプリケーションのマニフェストファイルに、一律でPreStopフックでsleepコマンド実行、terminationGracePeriodSecondを明示的に指定する ⚫ PreStopフックは、コンテナが停止する前に任意のコマンドを実行できる機能この機能を利用して、アプリPodがkubernetesのServiceから切り離され、受け取ったリクエストの処理が終了するまでの時間コンテナ停止を待つ様にsleepコマンドを実行 ⚫ terminationGracePeriodSecondsは、Podが強制終了されるまでの時間を設定するもの Pod停止の前にリクエストの処理が完了する時間分待つ設定を入れる PreStopフックでsleepコマンド実行 terminationGracePeriodSeconds

②メンテナンス設計: Podの安全停止設定 3. Kubernetesのインフラ設計ポイント ◼ 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マニフェストファイル

Pod アプリケーションコンテナ Limit 1,000m Limit 800Mi Limitsでコンテナに割り当てるリソースの上限を指定する ③性能設計: コンテナのリソース容量設定 3. Kubernetesのインフラ設計ポイント ◼コンテナのリソース容量設定のパラメータは2段階ある ⚫ Requests: 起動時からコンテナに確保されるリソースの最低保証値 ⚫ Limits: コンテナに割り当て可能なリソースの上限値仮想CPU数メモリ容量 Request 200m Request 600Mi Requestsでコンテナに確保される最低限のリソースを指定する

③性能設計: コンテナのオーバーコミット 3. Kubernetesのインフラ設計ポイント ◼コンテナ稼動に必要なワーカーノードの台数やスペックは、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 サイジングしたコンテナの総リソースより、ワーカーノードの総リソースが小さい → オーバーコミット

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

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

④セキュリティ設計: 特権モード/Rootユーザでのコンテナ実行の禁止 3. Kubernetesのインフラ設計ポイント ◼ 非Rootユーザで起動するコンテナを作成 ◼ Podマニフェストのセキュリティ設定(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時にチェック

まとめ Kubernetesならではのインフラ設計ポイントをしっかり抑えることが重要！「Pod」「Deployment」「Service」は基本リソースなのでここから理解しましょう! Kubernetesは「導入形態の幅」「高い拡張性」「マニフェストを用いた運用」に特徴があります！

インフラエンジニア必見!Kubernetesを用いたクラウドネイティブ設計ポイント大全

インフラエンジニア必見!Kubernetesを用いたクラウドネイティブ設計ポイント大全

More Decks by 高棹大樹

Other Decks in Technology

Featured

Transcript