クラウドとオンプレミスを組み合わせた機械学習基盤構築 株式会社スリーシェイク　永瀬滉平 Copyright © 3-shake, Inc. All Rights Reserved. 

自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. - 所属: 株式会社スリーシェイク - 仕事: マネージャー・エンジニア - 所在: 岩手県某所 - 今年は雪が多くなりそうな予感がしています 永瀬 滉平 (@koh_naga) 

Copyright © 3-shake, Inc. All Rights Reserved. 会社名 株式会社スリーシェイク 設立日 2015/1/15 Mission: インフラをシンプルにして イノベーションが起こりやすい世界を作る 3 About US Vision: 労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける Value: エンジニアリングレイヤーに横たわる人、手法、ツールが サイロ化されて労苦が発生しているプロセスをシンプルにし サービス機能開発に集中できるソリューション （SRE、DevSecOps、DataOps、HROps）を提供する 2015 2016 2017 2018 2019 2020 2021 2022 0 50 100 従業員: 200名over Engineer 60% 所在地 東京都中央区銀座8丁目21番1号 　　 住友不動産汐留浜離宮ビル7F　 代表者 代表取締役社長　吉田 拓真 沿革 2021年1月 JAFCOから総額5億円の資金調達 2022年8月 自動脆弱性診断ツール「Securify Scan」をリ リース。JAFCO、MUCAPから総額8.48億円の資金調達 2025年9月29日 新オフィスに移転 Googleクラウド・AWSの両方のエンジニアリングに強みを持つ （2024年8月に国内2例目の、GoogleCloudのDevOpsスペシャライゼーションを取得） Google Cloud×SRE / GenAIにおいて、スリーシェイクは国内トップパートナー 

SREを主軸にクラウドネイティブ化/エンジニアリング内製化を支援 SRE/DevOps SecOps BizOps HR ・SRE総合支援からセキュリティ対 策を全方位支援 ・Geminiを用いた生成AIの活用支援 ・ワンストップで脆弱性診断を行う セキュリティ対策SaaS ・クラウド型ETL/データパイプ ラインSaaSの決定版 ・あらゆるSaaSをノーコードで連携 ・ハイスキルフリーランスエンジニ ア紹介エージェント IT内製化 / 高度化 クラウドネイティブ化 モダナイゼーション ITアジリティ向上 

機械学習基盤 開発者が利用できる社内共通の機械学習基盤の構築を企画中。 ● 拠点が全国に存在し、拠点内にあるデータは拠点 LAN内に閉じておきたい -> 各拠点にあるオンプレサーバを利用する必要あり ● 拠点内にあるデータを用いて、開発者が誰でも MLモデルの構築のための様々な作業ができる基盤を構 築したい ○ リモート開発環境の提供 ○ モデルトレーニングと作成したモデルのサービング -> MLモデルに関する一通りの機能をパッケージしている Kubeflowを利用したい オンプレが絡むことからKubernetesをクラウドとオンプレで利用するマルチクラスタ構成のコンセプト 

構成概要 拠点内はDMZとInternet facingの疎通性が あり、DMZからはSquid Proxy経由でイン ターネットと疎通できる KubeflowをDMZに置くことで、以下を実現 する ● 拠点ごとにアクセス可能なユーザを 絞る ● データをDMZに留めながら各種処理 を実行 全拠点共通で利用するツールは AWS 上のEKSでホスティング 

話すこと 拠点に置く KubernetesとEKSの担う役割を見直したいと絶賛思っている状況です。 役割分担と実装について現時点の検討状況をご共有しますので、もし何かご意見やご 知見をいただけると大変助かります 󰢛 

今時点抱えている課題 DMZ k8sはオンプレミスになるため、物理サーバの扱いが発生する。 GPUノードも含まれているため、要件上 DMZ内である必要がない Podでリソースを圧迫したくない オンプレのため増設の手間を 省くために最もリソース効率 を重視したい DMZ内のデータを実際にreadす るPod。 このような性質のPodだけをスケ ジュールしたい DMZ内のデータを扱わないので クラウドなどのスケーラブルな 環境にもっていきたい 

案1: オンプレ・クラウドを含めて1つのクラスタとして扱う EKSではハイブリッドノード機能を使ってオンプレノードも EKSのコントロールプレーンで管理できる メリット ● コントロールプレーンが AWSマネージドになる ● 1つのクラスタ内のため、標準の Podスケジュール機能 が使える ● 拠点毎に冗長だった Kubeflowのコンポーネントをクラ ウド側に集約できる デメリット ● ネットワークの複雑性が高く、オンプレ側は DMZ内の ノードがクラスタに参加するための設定が複雑になる ● 誤ったノードへのスケジュールに対して対策が必要 ● 拠点ごとの利用把握が大変 

案2: 既存構成のままマルチクラスタスケジューリングを実装 クラスタを跨いで該当拠点 DMZ内データのreadを必要とするPodのみを指定の場所にスケジュール メリット ● クラスタわけが直接的に分離境界になるため把握がしや すい ○ セキュリティポリシーの管理が楽 ● ネットワークは今まで構築したものが利用できるので考慮 不要 ● 拠点毎に冗長だった Kubeflowのコンポーネントをクラウド 側に集約できる デメリット ● コントロールプレーンの管理工数が増える ● カスタムスケジューリングのロジックを作る必要がある ● コンポーネントごとの配置先の管理が大変 

論点の整理 Podスケジューリング機構として以下 2つの実装のうちどちらが速度高く実装でき、運用しやすいものかが論点に なると考える 1. クラスタ跨ぎでのPodスケジューリング機構 2. 誤ったノードにPodをスケジュールすることを防ぐ機構 

1. クラスタ跨ぎでのPodスケジューリング機構〜現状の構想〜 KueueのMultikueue機能を使った実装 MultiKueueを利用した外部クラスタへのジョブスケジューリング ：https://sreake.com/blog/multikueue-job-scheduling-to-external-cluster/ Kueue： ● Kubernetesネイティブなジョブキューイングを提供す るツール ● 合わせて、リソースマネジメントとそれに伴うジョブス ケジューリング機能も要する この中のMultiKueueというマルチクラスタでのジョブディス パッチ機能を利用する 課題点： Kubeflowの一部コンポーネントでは公式に統合されているも のの、Notebookのような常駐系のワークロードがうまく扱え ない 

2. 誤ったノードにPodをスケジュールすることを防ぐ機構〜現状の構想〜 ValidatingAdmissionPolicy（VAP）・MutatingAdmissionPolicy（MAP）の活用 (未検証) ※どちらもKubernetesネイティブな機能 VAP：Kubernetesにデプロイされる各種オブジェクトが指定した ルールに沿ったパラメータになっているかを確認する機能 MAP：Kubernetesにデプロイされる各種オブジェクトに指定した ルールに沿ったパラメータになるように追加・修正する機能 Kubernetes Mutating Admission Policyの調査、検証 ：https://tech.preferred.jp/ja/blog/kubernetes-mutating-admission-policy/ (参照 2025/12/17) 

終わりに まだ構想・検討段階のお話をあえて持ち込んだので、あまり実践的な感じではなく申し訳ないです。。。 前述した2点の解決策を検証したうえで、よさそうな方向に倒していければと思っています。 また進展があればどこかの機会で共有できればと思っているので、頭の片隅で楽しみにしていてください。 何か良い知見があればぜひ授けていただけるとありがたいです お気軽に私にお声がけください！（助けて欲しい。。。）