VMwareでの自社運用へマネージドKubernetesから移行 脱クラウドに挑む銀行の事例：クラウド依存というリスクからの脱却

特定ベンダーに依存しない運用を目指し、システムを自社インフラに移行するのは1つの手だ。しかしいざ自前で構築しようとすると想定外の動作などの問題に直面しがちだ。安定稼働を手にした銀行の事例を紹介する。

[TechTargetジャパン]

　金融機関にとって、ITインフラの選択は事業の命運を分ける重要な意思決定だ。デンマークに本社を置くオンライン銀行のSaxo Bankは、クラウドベンダーが提供するマネージド「Kubernetes」で稼働していたシステムを、オンプレミスインフラに構築したKubernetesクラスタへと移行する取り組みを進めている。

　この決断の背景にある最大の要因は、コンプライアンス要件への適合とインフラ費用の最適化だ。特定ベンダーに依存しない出口戦略を持つことが、金融機関の厳格なコンプライアンスにおいて不可欠になっている。システム障害発生時の影響を抑え、安定した稼働を維持するための信頼性向上も理由に挙げられる。

　とはいえ、クラウドサービスにおいて数回のクリックで構築できた構成をオンプレミスインフラで再現するには、ネットワーク設定やドメイン管理などでさまざまな壁が立ちはだかった。Saxo Bankはこの困難をどのように乗り越え、安定したシステムを手に入れたのか。移行プロジェクトを主導したエンジニアが語る、運用を効率化する具体的な技術的工夫と、オンプレミスインフラに移行する際の留意点を解説する。

脱クラウドへの道に潜む落とし穴

併せて読みたいお薦め記事

Kubernetes運用のヒント

• 「Kubernetesクラスタ」の自前構築はなぜ難しい？　Kubernetes運用の基礎知識
• 「Kubernetes」運用の“ベストプラクティス”と“ワーストプラクティス”9選

　本稿は、2026年3月に開催された、クラウドネイティブ技術の普及団体CNCF（Cloud Native Computing Foundation）が主催するイベント「CNCF-hosted Co-located Events Europe 2026」におけるセッション「We Broke Free From Cloud-Managed Kubernetes: Now What?」の内容に基づく。登壇したのは、Saxo Bankでコンテナインフラエンジニアリングを率いるペール・ヘデゴー・クリスチャンセン氏と、シニアエンジニアのカーリス・アコツ・グリブリス氏だ。

　自社インフラの構築に当たり、Saxo BankはVMwareの仮想化製品を採用し、OSにはコンテナ実行に特化した軽量OS「Flatcar」を選択した。クラスタの構成と管理には構築ツールの「Kubeadm」と、複数クラスタの構成を自動管理する「Cluster API」を組み合わせた。

　このシステムに移行する過程で最初の大きな課題になったのが、複数の物理データセンターにまたがって1つのクラスタを構成する「ストレッチクラスタ」の構築だ。

　クラウドサービスでは複数の可用性ゾーンにまたがる構成を容易に構築できるが、オンプレミスインフラでは単一のデータセンターに縛られがちになる。複雑な通信経路の制御や、複数データセンター間で1つのIPアドレスを共有できないといったオンプレミスインフラ特有の制約があり、ネットワーク設定の難度は極めて高かった。

　この課題を解決するため、Saxo Bankは分散システム下でノード同士が状態情報を相互交換・監視するプロトコル「Gossip」を利用した、独自のコントロール機能を開発した。各データセンターに配置されたポッド（コンテナの最小実行単位）が通信し、数秒間応答がないポッドを切り離してDNS（ドメインネームシステム）レコードを自動更新することで、障害が発生したデータセンターに通信がルーティングされるのを防ぐ仕組みを実現している。同社は毎月、片方のデータセンターのネットワークを遮断する連続性テストを実施し、システムの堅牢（けんろう）性を検証している。

DNSと管理ツールにおけるオープンソースへの対応

　ドメイン管理においても想定外の動作に直面した。Saxo Bankはクラウド型DNSのAzure DNSから、CNCFが管理するオープンソースの「CoreDNS」に移行したが、DNS機能の拡張プラグインを利用した際、意図しないサブドメインの情報まで一括で返されてしまう仕様上の課題があった。複数のサブドメインを一括設定できる「ワイルドカードレコード」機能が未実装である点や、レコードの追加のみで削除が実行されないといった制約も存在した。これらの問題に対し、同社はオープンソースコードに独自のパッチを当てることで挙動を修正し、自社の要件に適合させている。

　「VMware vSphere」でCluster APIを利用した管理では、複数の設定項目が変更不可（イミュータブル）であるという扱いづらさがあった。このため、パッケージ管理ツール「Helm」やポリシー管理ツール「Kyverno」などを連携させることで、システム構成の変更を制御できる仕組みを整えた。

移行の成果とハードウェア投資を見据えた将来展望

　これらの綿密な事前準備とツールによる抽象化の恩恵もあり、アプリケーションの移行作業は比較的スムーズに進行している。Kyvernoを用いて新旧システムの仕様差を吸収し、開発者が構成変更を意識することなく移行できるようにしたことが奏功し、講演時点ではワークロードの10〜15％の移行が完了した。開発者の作業負担を軽減し、恩恵を享受しやすい移行プロセスが機能している。

　将来のロードマップとして、Saxo Bankは特定システム構成に依存しない構成を目指している。VMware製品に依存する構成から、極小OS「Talos」や仮想マシン実行ツール「KubeVirt」を用いた構成への検証を進めている他、省電力で費用対効果に優れたプロセッサアーキテクチャARM CPUの活用による費用削減と性能向上を検討している。

　最後に、登壇者はこの脱クラウドの移行を他社にも一律に勧めるかという問いに対し、「その企業の状況による」と回答した。Saxo Bankの場合、20年の運用実績がある自社のデータセンターと専門のエンジニアチームが存在していたからこそ実現できた取り組みだ。昨今のAI需要に伴うハードウェア価格の高騰や投資対効果（ROI）を総合的に評価し、自社の要件に最適なインフラを選択することが重要だと示唆している。

本稿は、CNCFが2026年4月14日に公開した動画「We Broke Free From Cloud-Managed Kubernetes... Kārlis Akots Gribulis & Per Hedegaard Christiansen」を基に作成しました。