トスバンク ML Engineer（MLOps）完全合格ガイド：MLFlowからLLMプラットフォームまで技術スタック総整理

• はじめに：トスバンクMLプラットフォームが特別な理由
• 1. チーム分析：トスバンク ML Platform Team
  • チームの実際の業務内容
  • トスバンク内でのチームの位置づけ
  • 2025-2026年に本ポジションが重要な理由
• 2. JD逐行（ちくぎょう）分析
  • 主要業務（しゅようぎょうむ）
  • 必須要件（ひっすようけん）
  • 優遇要件（ゆうぐうようけん）
• 3. 技術スタック詳細解説（ぎじゅつスタックしょうさいかいせつ）
  • 3.1 MLOpsのためのKubernetes
  • 3.2 MLFlow：実験追跡とモデルレジストリ
  • 3.3 Apache Airflow：ワークフローオーケストレーション
  • 3.4 Kubeflow：KubernetesネイティブMLパイプライン
  • 3.5 JupyterHub：マルチユーザーノートブックプラットフォーム
  • 3.6 Triton Inference Server：プロダクションモデルサービング
  • 3.7 ScyllaDB Feature Store：低遅延（ていちえん）特徴量サービング
  • 3.8 LLMプラットフォーム：GPUインフラと推論最適化
  • 3.9 GPUフレームワークとCUDAの基礎（きそ）
  • 3.10 分散データベースの基礎
• 4. MLOps成熟度モデル
  • 5段階（だんかい）レベル
  • トスバンクの現在の位置（推定レベル3-4）
• 5. 面接対策：予想質問30選（めんせつたいさく：よそうしつもん30せん）
  • Kubernetesとインフラ（質問1-6）
  • MLFlowと実験管理（質問7-12）
  • Airflowとパイプラインオーケストレーション（質問13-18）
  • モデルサービングとTriton（質問19-24）
  • 特徴量ストアと分散データベース（質問25-27）
  • LLMプラットフォーム（質問28-30）
• 6. 8ヶ月学習ロードマップ
  • 月1-2：Kubernetesとコンテナの基礎
  • 月3-4：コアMLプラットフォームツール
  • 月5-6：モデルサービングと特徴量エンジニアリング
  • 月7-8：LLMプラットフォームと面接準備
  • 学習スケジュール概要
• 7. トスバンクML Platform向け履歴書戦略（りれきしょせんりゃく）
  • 履歴書の構成
  • 含めるべきキーワード
  • MLOpsポジションでよくある履歴書のミス
• 8. ポートフォリオプロジェクト
  • プロジェクト1：Kubernetes上のエンドツーエンドMLOpsプラットフォーム
  • プロジェクト2：ScyllaDB上の特徴量ストア
  • プロジェクト3：RAG付きLLMサービングプラットフォーム
• 9. 知識確認クイズ
• 10. 参考文献（さんこうぶんけん）とリソース
  • 公式ドキュメント
  • 書籍
  • オンラインコースと認定
  • コミュニティリソース

はじめに：トスバンクMLプラットフォームが特別な理由

トスバンクは単なるフィンテック企業ではない。Tossスーパーアプリを運営（うんえい）するViva Republicaエコシステムの一部として、アジアで最も積極的（せっきょくてき）にMLを活用する金融（きんゆう）プラットフォームの一つである。ML Platform Teamは、データサイエンティストがJupyter Notebookからプロダクションモデルへとわずか数時間で移行できるようにするインフラ基盤（きばん）を構築・運用するチームだ。

このポジションのMLOps Engineerは、「モデルをデプロイして終わり」という典型的な役割（やくわり）ではない。JDの分析から、このチームはMLOps成熟度（せいじゅくど）レベル3-4で運用しており、レベル5（完全自律的ML運用）を目指していることが読み取れる。つまり、個別（こべつ）のツールだけでなく、実験（じっけん）からサービング、監視（かんし）、再学習（さいがくしゅう）、ガバナンスに至るライフサイクル全体を理解することが求められる。

本ガイドでは、JDの各行を徹底分析し、各要件を具体的な技術（ぎじゅつ）と学習リソースにマッピングし、8ヶ月の具体的な学習計画（けいかく）を提示する。バックエンドエンジニアからMLOpsへの転向（てんこう）を考えている人、インフラを理解したいデータサイエンティスト、またはこのポジションを検討している経験豊富（けいけんほうふ）なMLOps実践者（じっせんしゃ）のいずれであっても、この文書が包括的（ほうかつてき）な準備資料となるだろう。

1. チーム分析：トスバンク ML Platform Team

チームの実際の業務内容

ML Platform Teamは、データエンジニアリング、MLエンジニアリング、プラットフォームエンジニアリングの交差点（こうさてん）に位置する。チームの使命（しめい）は三つに集約される。

1. MLインフラ層の構築 — 学習パイプライン、実験追跡（ついせき）、モデルレジストリ、特徴量ストア、サービングインフラ
2. データサイエンティスト向けセルフサービスMLの実現 — JupyterHub環境、自動パイプライン作成、ワンクリックモデルデプロイ
3. LLMプラットフォームの運用 — 推論（すいろん）最適化、GPUクラスタ管理、銀行業務特化のRAGパイプライン

トスバンク内でのチームの位置づけ

組織階層（そしきかいそう）内でのチームの位置を理解することは、面接（めんせつ）準備に重要だ。

ML Platform Teamは重要な中間層（ちゅうかんそう）だ。ビジネスモデル自体は構築しないが、数十人のデータサイエンティストが効率的（こうりつてき）に作業し、モデルを安全にプロダクションへデプロイできるようにする役割を担う。

2025-2026年に本ポジションが重要な理由

三つのトレンドが本ポジションを特に重要にしている。

1. 銀行業務へのLLM統合（とうごう） — 韓国の主要金融機関はすべて、顧客（こきゃく）サービス、文書処理、社内ツールにLLMをデプロイする競争を繰り広げている。トスバンクは、従来のML（信用スコアリング用XGBoost、LightGBM）と生成AI（せいせいAI）ワークロードの両方を同時に処理できるインフラが必要だ。

2. 規制圧力（きせいあつりょく） — 韓国の金融規制当局（FSC/FSS）は、信用判断（しんようはんだん）に影響するMLシステムにモデルの説明可能性と監査証跡を要求している。MLプラットフォームはガバナンス機能を標準装備（ひょうじゅんそうび）する必要がある。

3. スケールの課題 — トスバンクは数百万人のアクティブユーザーにサービスを提供している。MLプラットフォームは毎秒数千の特徴量計算を処理し、10ミリ秒未満のレイテンシでモデルをサービングし、数十の同時実験を管理しなければならない — すべて金融取引に必要なファイブナインの信頼性（しんらいせい）を維持しながら。

2. JD逐行（ちくぎょう）分析

JDの各要件を分解し、採用（さいよう）チームが実際に何を求めているかを理解する。

主要業務（しゅようぎょうむ）

「MLプラットフォームサービスの設計・開発（MLFlow、Airflow、JupyterHub、Kubeflow）」

これが本ポジションの核心（かくしん）だ。これらのツールを単に使うのではなく、構築しカスタマイズすることが求められる。言及（げんきゅう）された4つのツールは、完全なMLライフサイクルを構成する。

• MLFlow — 実験追跡、モデルレジストリ、モデルバージョニング
• Airflow — データパイプラインと学習ジョブのワークフローオーケストレーション
• JupyterHub — データサイエンティスト向けマルチユーザーノートブック環境
• Kubeflow — Kubernetesネイティブのパイプラインオーケストレーション

「設計」という言葉が重要だ。チュートリアルに従うだけでなく、ソリューションをアーキテクトできる人材を求めている。

「推論サービングインフラの構築・運用（Triton Inference Server）」

モデルサービングはMLOpsの中でも最も難しい部分であることが多い。NVIDIA製のTriton Inference Serverは、複数のモデルフレームワーク（TensorFlow、PyTorch、ONNX、TensorRT）を同時にサポートするエンタープライズグレードのサービングソリューションだ。Tritonをスケールで運用するには以下の理解が必要だ。

• モデルアンサンブルパターン
• 動的バッチング設定
• GPUメモリ管理（かんり）
• モデルのA/Bテストとカナリアデプロイメント

「分散データベースベースの特徴量ストアの設計・開発（ScyllaDB）」

これは強いアーキテクチャ的なシグナルだ。多くの企業は既製（きせい）の特徴量ストア（Feast、Tecton、Hopsworks）を使用する。トスバンクはScyllaDB上にカスタム特徴量ストアを構築している — ScyllaDBはC++で書かれた高性能（こうせいのう）なCassandra互換データベースだ。つまり以下を意味する。

• ミリ秒未満の特徴量ルックアップをスケールで実現する必要がある
• 一貫性（いっかんせい）と低テールレイテンシを重視している（金融サービスに不可欠）
• API使用法だけでなく、分散データベースの内部構造を理解する必要がある

「LLMプラットフォームの構築・運用（GPUインフラ、推論最適化）」

これはポジションの将来志向（しょうらいしこう）の部分だ。LLM運用には従来のMLとは根本的に異なるスキルセットが必要だ。

• GPUクラスタ管理（NVIDIA A100/H100、マルチGPUサービング）
• 推論最適化（量子化、KVキャッシュ最適化、連続バッチング）
• 銀行データに基づくLLM応答のグラウンディングのためのRAGパイプラインアーキテクチャ
• コスト最適化（GPUコンピュートは高価 — 効率的な利用が不可欠）

必須要件（ひっすようけん）

「バックエンド開発またはMLエンジニアリングで3年以上の経験」

バックエンドまたはMLエンジニアリングという二重の表現（ひょうげん）は意図的だ。プロダクション品質のコードを書ける人材を求めている。ノートブック経験（けいけん）のみのデータサイエンティストには厳しく、ML理解のないバックエンドエンジニアにも厳しい。Go/Pythonサービスを書けて、かつMLの概念を理解するエンジニアが理想（りそう）だ。

「Kubernetesとコンテナオーケストレーションの経験」

これは譲れない要件だ。スタック内のすべてのツール（MLFlow、Airflow、JupyterHub、Kubeflow、Triton）がKubernetes上で動作する。以下の理解が必要だ。

• Podスケジューリング、リソースリクエスト/リミット
• カスタムオペレータとCRD（Custom Resource Definitions）
• HelmチャートとKustomizeによるデプロイメント管理
• モデルアーティファクトと学習データのための永続ボリューム管理

「MLライフサイクル（学習、サービング、監視）の理解」

全体像を把握しているかを確認する要件だ。プロダクションにおけるMLは「モデルを学習してデプロイする」ことではない。学習から検証、レジストリ、デプロイメント、監視、再学習への連続的なサイクルだ。各遷移（せんい）ポイントと何が問題になりうるかを理解することが不可欠だ。

優遇要件（ゆうぐうようけん）

「GPUインフラとCUDAの経験」

シニア候補者（こうほしゃ）とジュニアを分ける要件だ。GPUメモリプロファイリング、CUDAカーネル最適化、NCCLによるマルチGPU学習の実務経験があれば、大きなアドバンテージとなる。

「分散システムまたはデータベースの経験」

ScyllaDB特徴量ストアの要件により特に関連性が高い。Cassandra、DynamoDB、または任意のLSMツリーベースのデータベースの経験は大きな強みとなる。

「オープンソースMLツールへの貢献」

優遇要件（ゆうぐうようけん）の中で最も強いシグナルだ。オープンソースへの積極的な貢献は、技術的深さとコミュニティへの関与を示す。MLFlow、Kubeflow、Tritonへの小さな貢献でも注目される。

3. 技術スタック詳細解説（ぎじゅつスタックしょうさいかいせつ）

3.1 MLOpsのためのKubernetes

KubernetesはトスバンクMLプラットフォーム全体の基盤だ。他のすべてのツールがその上で動作する。基本的なデプロイメントを超えたKubernetes知識が必要だ。

MLOps向けKubernetesの重要概念

Kubernetes上のGPUスケジューリング

GPU管理はこの役割にとって重要だ。NVIDIAはKubernetes向けにnvidia-device-pluginを提供しており、以下を理解する必要がある。

apiVersion: v1
kind: Pod
metadata:
  name: gpu-training-job
spec:
  containers:
    - name: training
      image: training-image:v1
      resources:
        limits:
          nvidia.com/gpu: 2
  nodeSelector:
    accelerator: nvidia-a100
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule

この例は、適切なノード選択とtolerationsを使用して2つのNVIDIA A100 GPUを要求する学習Podを示している。プロダクションでは以下も設定する。

• 小規模ワークロード向けのGPUタイムスライシング（MIG — Multi-Instance GPU）
• マルチノード学習のためのRDMAネットワーキング
• 最適なGPU間通信のためのトポロジー認識（にんしき）スケジューリング

学習リソース

• Kubernetes公式ドキュメント：Conceptsセクション（無料）
• 「Kubernetes in Action」Marko Luksa著 — 決定版の深掘り書籍
• NVIDIA GPU Operatorドキュメント
• CKA（Certified Kubernetes Administrator）認定 — 強く推奨

3.2 MLFlow：実験追跡とモデルレジストリ

MLFlowはML業界における実験追跡のデファクトスタンダードだ。トスバンクでは、実験追跡システムとモデルレジストリの両方として機能する。

アーキテクチャ概要（がいよう）

MLFlowには4つのコアコンポーネントがある。

1. Tracking — 各実験実行のパラメータ、メトリクス、アーティファクトを記録
2. Projects — MLコードを再利用可能な再現性のある形式でパッケージ化
3. Models — フレームワーク間のモデルパッケージングを標準化
4. Model Registry — バージョニング、ステージング、承認ワークフローを備えた一元化されたモデルストア

トスバンクでのMLFlow活用方法（かつようほうほう）（推定）

金融機関では、モデルガバナンスは任意ではない。MLFlow Model Registryが中央制御（ちゅうおうせいぎょ）プレーンとなる。

import mlflow
from mlflow.tracking import MlflowClient

client = MlflowClient()

# 新しいモデルバージョンを登録
model_uri = "runs:/abc123/model"
mv = client.create_model_version(
    name="credit-scoring-v2",
    source=model_uri,
    run_id="abc123",
    description="47特徴量のLightGBM信用スコアリングモデル"
)

# 承認を経てステージを遷移
client.transition_model_version_stage(
    name="credit-scoring-v2",
    version=mv.version,
    stage="Staging"
)

# 検証後、プロダクションに昇格
client.transition_model_version_stage(
    name="credit-scoring-v2",
    version=mv.version,
    stage="Production",
    archive_existing_versions=True
)

重要な学習トピック

• Kubernetes上のMLFlowトラッキングサーバーデプロイ（PostgreSQLバックエンド、S3/MinIOアーティファクトストア）
• カスタムMLFlowプラグイン（カスタム認証、カスタムアーティファクトストアなど）
• MLFlowモデルサービングと専用サービングソリューション（Triton）の比較
• 自動学習パイプラインのためのAirflowとの統合
• メトリクス比較と実験分析API

学習リソース

• MLFlow公式ドキュメント（包括的で良質）
• 「Practical MLOps」Noah GiftとAlfredo Deza著（O'Reilly）
• MLFlow GitHubリポジトリ — トラッキングサーバーのソースコードを読む

3.3 Apache Airflow：ワークフローオーケストレーション

Airflowはデータパイプラインオーケストレーションの業界標準（ぎょうかいひょうじゅん）だ。MLの文脈では、データ準備、特徴量計算、モデル学習、評価、デプロイメント間の複雑な依存関係を管理する。

MLパイプラインにAirflowを使う理由

例：ML学習DAG

from airflow import DAG
from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator
from datetime import datetime, timedelta

default_args = {
    "owner": "ml-platform",
    "retries": 2,
    "retry_delay": timedelta(minutes=10),
}

with DAG(
    dag_id="credit_scoring_daily_retrain",
    default_args=default_args,
    schedule_interval="0 2 * * *",
    start_date=datetime(2025, 1, 1),
    catchup=False,
) as dag:

    feature_extraction = KubernetesPodOperator(
        task_id="extract_features",
        name="feature-extraction",
        namespace="ml-pipelines",
        image="feature-pipeline:v3",
        arguments=["--date", "{{ ds }}"],
        resources={
            "requests": {"cpu": "4", "memory": "16Gi"},
            "limits": {"cpu": "8", "memory": "32Gi"},
        },
    )

    model_training = KubernetesPodOperator(
        task_id="train_model",
        name="model-training",
        namespace="ml-pipelines",
        image="training-pipeline:v5",
        arguments=["--date", "{{ ds }}", "--experiment", "credit-scoring"],
        resources={
            "requests": {"cpu": "8", "memory": "32Gi", "nvidia.com/gpu": "1"},
            "limits": {"cpu": "16", "memory": "64Gi", "nvidia.com/gpu": "1"},
        },
    )

    model_evaluation = KubernetesPodOperator(
        task_id="evaluate_model",
        name="model-evaluation",
        namespace="ml-pipelines",
        image="evaluation-pipeline:v2",
        arguments=["--date", "{{ ds }}"],
    )

    feature_extraction >> model_training >> model_evaluation

重要な学習トピック

• KubernetesExecutor vs CeleryExecutor — MLワークロードにおけるトレードオフ
• MLFlow統合のためのカスタムオペレータ
• タスク間のメタデータ受け渡しのためのXCom（モデルメトリクス、アーティファクトURI）
• シークレットのためのConnectionとVariable管理
• Kubernetes上のAirflow：Helmチャートデプロイと設定
• DAGバージョニングとテスト戦略

学習リソース

• Apache Airflow公式ドキュメント
• 「Data Pipelines with Apache Airflow」Bas HarenslakとJulian de Ruiter著（Manning）
• Astronomer.ioブログとガイド

3.4 Kubeflow：KubernetesネイティブMLパイプライン

Kubeflowは、パイプラインオーケストレーション、ハイパーパラメータチューニング、分散学習機能を提供するKubernetesネイティブMLプラットフォームだ。Airflowが汎用（はんよう）ワークフローオーケストレーションを扱う一方、KubeflowはML専用に構築されている。

このポジションに関連するKubeflowコンポーネント

Kubeflow Pipelinesの例

from kfp import dsl
from kfp import compiler

@dsl.component(
    base_image="python:3.11",
    packages_to_install=["scikit-learn", "pandas"]
)
def preprocess_data(input_path: str, output_path: dsl.OutputPath(str)):
    import pandas as pd
    from sklearn.preprocessing import StandardScaler
    df = pd.read_parquet(input_path)
    scaler = StandardScaler()
    df_scaled = pd.DataFrame(
        scaler.fit_transform(df),
        columns=df.columns
    )
    df_scaled.to_parquet(output_path)

@dsl.component(
    base_image="python:3.11",
    packages_to_install=["lightgbm", "mlflow"]
)
def train_model(data_path: str, model_name: str):
    import lightgbm as lgb
    import mlflow
    import pandas as pd
    df = pd.read_parquet(data_path)
    # 学習ロジックここ
    mlflow.lightgbm.log_model(model, model_name)

@dsl.pipeline(name="credit-scoring-pipeline")
def credit_scoring_pipeline(input_path: str = "s3://data/features/"):
    preprocess_task = preprocess_data(input_path=input_path)
    train_task = train_model(
        data_path=preprocess_task.outputs["output_path"],
        model_name="credit-scoring"
    )

compiler.Compiler().compile(credit_scoring_pipeline, "pipeline.yaml")

Kubeflow vs Airflow：使い分けの基準

• Airflow：混合ワークロード（データ + ML + ETL）を含む複雑なDAGに最適、500以上のオペレータを持つ成熟したエコシステム、強力なスケジューリング機能
• Kubeflow：純粋なMLパイプラインに最適、ネイティブKubernetes統合、組み込みのハイパーパラメータチューニングと分散学習、より優れた実験追跡統合

多くのチーム（トスバンクを含む可能性が高い）は両方を使用する。Airflowはトップレベルのオーケストレーションとデータパイプラインに、Kubeflowはワークフロー内のML固有パイプラインステップに使う。

学習リソース

• Kubeflow公式ドキュメント
• Kubeflow Pipelines SDK v2ドキュメント（現行バージョン）
• Google Cloud Vertex AI Pipelines（内部でKFPを使用）

3.5 JupyterHub：マルチユーザーノートブックプラットフォーム

JupyterHubはJupyterノートブックのマルチユーザーサーバーだ。MLプラットフォームの文脈では、データサイエンティストが実験しモデルを開発するセルフサービス環境（かんきょう）を提供する。

このポジションにJupyterHubが重要な理由

JupyterHubを単にデプロイするだけではない — 金融機関（きんゆうきかん）向けにカスタマイズされた、安全なエンタープライズグレードのノートブックプラットフォームを構築する。以下が含まれる。

1. 認証と認可（にんかとにんか） — 企業IDプロバイダー（LDAP、OIDC、SAML）との統合
2. リソース管理 — ユーザーが特定のコンピュートプロファイル（CPUのみ、単一GPU、マルチGPU）を要求できるようにする
3. イメージ管理 — MLフレームワークがプリインストールされた精選（せいせん）Dockerイメージの管理
4. 永続（えいぞく）ストレージ — サーバー再起動時のノートブックとデータの永続化を保証
5. セキュリティ — ネットワーク分離、シークレット管理、銀行環境でのデータ流出防止

Kubernetes上のJupyterHubアーキテクチャ

Kubernetes上では、JupyterHubはkubespawnerを使用して各ユーザー用に個別のPodを作成する。

# JupyterHub Helmの値（簡略版）
singleuser:
  profileList:
    - display_name: 'CPU - Small (2 CPU, 8GB)'
      description: 'データ探索と軽処理向け'
      kubespawner_override:
        cpu_limit: 2
        mem_limit: '8G'
    - display_name: 'GPU - A100 (8 CPU, 32GB, 1 GPU)'
      description: 'モデル学習とファインチューニング向け'
      kubespawner_override:
        cpu_limit: 8
        mem_limit: '32G'
        extra_resource_limits:
          nvidia.com/gpu: '1'
        node_selector:
          accelerator: nvidia-a100
  storage:
    type: dynamic
    capacity: 50Gi
    storageClass: fast-ssd

学習リソース

• Zero to JupyterHub with Kubernetesドキュメント
• JupyterHub for Kubernetes Helmチャートドキュメント
• KubeSpawnerドキュメント

3.6 Triton Inference Server：プロダクションモデルサービング

NVIDIA Triton Inference Serverは、プロダクションでMLモデルをサービングするための業界をリードするソリューションだ。複数のフレームワークを同時にサポートし、動的バッチング、モデルアンサンブル、GPU利用率最適化（さいてきか）などの高度な機能を提供する。

金融サービスにTritonを選ぶ理由

Tritonモデルリポジトリ構造

model_repository/
  credit_scoring/
    config.pbtxt
    1/
      model.onnx
    2/
      model.onnx
  fraud_detection/
    config.pbtxt
    1/
      model.plan
  text_classifier/
    config.pbtxt
    1/
      model.pt

Triton設定例

name: "credit_scoring"
platform: "onnxruntime_onnx"
max_batch_size: 64
input [
  {
    name: "features"
    data_type: TYPE_FP32
    dims: [ 47 ]
  }
]
output [
  {
    name: "probability"
    data_type: TYPE_FP32
    dims: [ 1 ]
  }
]
instance_group [
  {
    count: 2
    kind: KIND_GPU
    gpus: [ 0 ]
  }
]
dynamic_batching {
  preferred_batch_size: [ 16, 32, 64 ]
  max_queue_delay_microseconds: 100
}

重要な学習トピック

• モデル変換：PyTorchからONNX、TensorFlowからTensorRT
• 動的バッチング設定とチューニング
• 前処理/後処理パイプラインのためのモデルアンサンブル
• Kubernetes上のTriton Inference Serverデプロイ（Helmチャート）
• Triton Model Analyzerによるパフォーマンス分析
• 非標準モデルフォーマットのためのカスタムバックエンド
• Kubernetes統合のためのヘルスチェックとReadinessプローブ

学習リソース

• NVIDIA Triton Inference Serverドキュメント
• NVIDIA Deep Learning Examples GitHubリポジトリ
• Triton Model Analyzerドキュメント
• 「Serving Machine Learning Models」Yaron Haviv著（O'Reilly）

3.7 ScyllaDB Feature Store：低遅延（ていちえん）特徴量サービング

ScyllaDB上に特徴量ストアを構築するという決定は、トスバンクMLプラットフォームの最も特徴的（とくちょうてき）な側面の一つだ。このアーキテクチャを選んだ理由を理解することで、チームの優先事項が見えてくる。

特徴量ストアとは何か

特徴量ストアは、ML特徴量を保存、管理、サービングするための一元化（いちげんか）されたリポジトリだ。いくつかの重要な問題を解決する。

1. 特徴量の一貫性 — 学習時と推論時に同じ特徴量計算が使用されることを保証
2. 特徴量の再利用 — 複数のモデルが冗長な計算なしに同じ特徴量を共有可能
3. 低遅延サービング — 推論時にミリ秒未満のレイテンシで事前計算された特徴量を提供
4. ポイントインタイム正確性 — 学習のために特定の過去のタイムスタンプ時点の特徴量を取得（データリーケージ回避）

ScyllaDBをRedisやDynamoDBの代わりに選ぶ理由

特徴量ストアアーキテクチャパターン

                          バッチ特徴量
学習データ --------> [Airflow + Spark] -------> ScyllaDB（オフラインストア）
                                                       |
                                                       v
                          オンライン特徴量        [特徴量サービングAPI]
ライブリクエスト ---> [ストリーミングパイプライン] --->  |
                                                       v
                                                [モデルサービング（Triton）]

特徴量のためのScyllaDBデータモデリング

CREATE TABLE feature_store.user_features (
    user_id text,
    feature_timestamp timestamp,
    avg_transaction_amount_7d double,
    transaction_count_30d int,
    max_single_transaction_90d double,
    credit_utilization_ratio double,
    days_since_last_late_payment int,
    PRIMARY KEY (user_id, feature_timestamp)
) WITH CLUSTERING ORDER BY (feature_timestamp DESC)
  AND default_time_to_live = 7776000;

重要な学習トピック

• ScyllaDBアーキテクチャ：シャードパーコアモデル、Seastar フレームワーク
• ワイドカラムデータベースのデータモデリング（Cassandra/ScyllaDB）
• 特徴量ストアの概念：オンライン vs オフラインストア、特徴量鮮度、タイムトラベル
• 既存の特徴量ストアとの比較（Feast、Tecton、Hopsworks）
• ScyllaDBパフォーマンスチューニング：コンパクション戦略、キャッシング、読み書き一貫性レベル
• 高スループットワークロードのためのドライバ選択とコネクションプーリング

学習リソース

• ScyllaDB University（無料オンラインコース）
• 「Cassandra: The Definitive Guide」Jeff CarpenterとEben Hewitt著（概念はそのまま移行可能）
• Feastドキュメント（一般的な特徴量ストア概念の理解のため）
• ScyllaDBアーキテクチャドキュメント

3.8 LLMプラットフォーム：GPUインフラと推論最適化

LLMプラットフォームの責任は、このポジションの最も将来志向的な部分だ。大規模言語モデル（だいきぼげんごモデル）のためのインフラ構築には、従来のMLとはまったく異なる制約の理解が必要だ。

銀行業務におけるLLMインフラの課題

1. データプライバシー — 銀行データは組織外に出せないため、ほとんどのクラウドLLM APIは使用不可。オンプレミスまたはVPCホスト推論が必要
2. レイテンシ要件 — 顧客向けチャットボットは最初のトークンレイテンシ500ミリ秒未満、生成速度（せいせいそくど）毎秒30トークン以上が必要
3. コスト管理 — NVIDIA H100 GPU1台で3万ドル以上。GPUクラスタの効率的な利用がROIに不可欠
4. モデルガバナンス — 規制要件により、銀行におけるすべてのLLM応答はトレーサブル、監査可能、説明可能でなければならない

主要LLMサービング技術

LLM推論最適化技術

• 量子化（りょうしか）：モデル精度をFP16からINT8またはINT4に削減。AWQとGPTQが最も一般的。通常、最小限の精度低下でGPUメモリ使用量を50-75%削減。
• KVキャッシュ最適化：PagedAttention（vLLMで使用）はキーバリューキャッシュを仮想メモリページのように管理し、同時リクエストのスループットを劇的に改善。
• 連続バッチング：静的バッチングとは異なり、前のリクエストが完了すると新しいリクエストがバッチに参加でき、GPU利用率を最大化。
• 投機的（とうきてき）デコーディング：小さなドラフトモデルで候補トークンを生成し、大きなモデルが検証。推論速度を2-3倍高速化する可能性。
• テンソル並列性（へいれつせい）：1つのGPUのメモリに収まらないモデルをサービングするため、単一モデルを複数GPUに分割。

銀行向けRAGパイプライン

検索拡張生成（Retrieval-Augmented Generation）は、銀行LLMアプリケーションがレスポンスを正確な最新情報に基づかせるために不可欠だ。

ユーザークエリ --> [埋め込みモデル] --> [ベクトルDB検索]
                                           |
                                      取得コンテキスト
                                           |
                                           v
               [プロンプトテンプレート + コンテキスト + クエリ] --> [LLM] --> レスポンス
                                                                    |
                                                               [ガードレール]
                                                                    |
                                                               最終レスポンス

学習リソース

• vLLMドキュメントとGitHubリポジトリ
• NVIDIA TensorRT-LLMドキュメント
• 「LLM Engineer's Handbook」Paul IusztinとMaxime Labonne著
• Hugging Face Text Generation Inferenceドキュメント
• NVIDIA NIMドキュメント

3.9 GPUフレームワークとCUDAの基礎（きそ）

GPUコンピューティングのより深い理解は、強い候補者と平均的な候補者を分ける。CUDAカーネル開発者である必要はないが、基礎は理解する必要がある。

GPUアーキテクチャの基本

Multi-Instance GPU (MIG)

MIGは単一GPUを複数の分離されたインスタンスにパーティショニングする。GPU利用率の最大化に不可欠だ。

# MIG対応GPUの一覧
nvidia-smi mig -lgip

# MIGインスタンスの作成（A100の3g.40gbプロファイル）
nvidia-smi mig -cgi 9,9 -C

# 作成されたインスタンスの一覧
nvidia-smi mig -lgi

銀行の文脈では、MIGにより各モデルに専用GPU全体を割り当てるのではなく、A100/H100のフラクション上で小規模推論ワークロードを実行できる。

MLエンジニアのためのCUDAメモリ管理

GPUメモリの理解は、メモリ不足エラーのデバッグと学習最適化に不可欠だ。

• モデルパラメータ：GPUメモリに保存（例：FP16の7Bパラメータモデルは約14GB必要）
• 勾配（こうばい）：学習中はパラメータと同サイズ（さらに14GB）
• オプティマイザ状態：Adamオプティマイザは追加で2つのコピーを保存（さらに28GB）
• 活性化値（かっせいかち）：フォワードパス中の中間値（バッチサイズとシーケンス長に依存）

FP16でAdamを使用する7Bモデルの学習メモリ合計は大まかに：14 + 14 + 28 = 最低56GB、さらに活性化値が加わる。

NCCL（NVIDIA Collective Communications Library）

NCCLは効率的なマルチGPUおよびマルチノード通信を可能にするライブラリだ。

• AllReduce：分散学習中のGPU間での勾配集約
• AllGather：テンソル並列のためにすべてのGPUからテンソルシャードを収集
• ReduceScatter：パイプライン並列のために削減と分配を組み合わせ

学習リソース

• NVIDIA CUDAプログラミングガイド
• 「Programming Massively Parallel Processors」David KirkとWen-mei Hwu著
• NVIDIA Deep Learning Performance Guide
• PyTorch分散学習ドキュメント

3.10 分散データベースの基礎

トスバンクが特徴量ストアにScyllaDBを使用し、金融グレードのスケールで運用しているため、分散データベースの理論（りろん）と実践の堅固な理解が不可欠だ。

CAP定理（ていり）とその実践的影響

CAP定理は、分散システムが一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）の3つの保証のうち最大2つしか提供できないと述べている。実践的には以下のとおりだ。

• ScyllaDB/Cassandra：チューナブルな一貫性を持つAPシステム（クエリごとに一貫性レベルを設定可能）
• 特徴量サービングの場合：通常、一貫性のためにQUORUM読み取り、レイテンシ最適化のためにLOCAL_QUORUM
• 特徴量書き込みの場合：バッチ特徴量計算中の高書き込みスループットのためにONEまたはLOCAL_ONE

実践における一貫性レベル

LSMツリーアーキテクチャ

ScyllaDBとCassandraはストレージにLog-Structured Mergeツリーを使用する。

1. 書き込みはインメモリのMemtableに送られる
2. Memtableが一杯になると、ディスクにSSTableとしてフラッシュされる
3. バックグラウンドのコンパクションがSSTableをマージし、スペースを回収（かいしゅう）して読み取りを最適化
4. ブルームフィルタとパーティションインデックスが高速ルックアップを可能にする

コンパクション戦略（Size-Tiered、Leveled、Time-Window）の理解は、特徴量ストアのパフォーマンスチューニングに不可欠だ。

コンシステントハッシングとデータ分散

ScyllaDBはコンシステントハッシングを使用してノード間にデータを分散する。

• 各ノードはトークン値の範囲を所有する
• パーティションキーがハッシュされ、どのノードがデータを保存するかを決定
• 仮想ノード（vnodes）がデータ分散の均一性を改善
• レプリケーションファクターが各データの何コピー存在するかを決定

学習リソース

• 「Designing Data-Intensive Applications」Martin Kleppmann著 — 必読
• ScyllaDB Universityコース（無料）
• 「Database Internals」Alex Petrov著（O'Reilly）
• Jepsen.io — 分散システムの正確性分析

4. MLOps成熟度モデル

トスバンクがMLOps成熟度モデルのどこに位置するかを理解することは、面接の回答をフレーミングし、戦略的思考を示すのに役立つ。

5段階（だんかい）レベル

トスバンクの現在の位置（推定レベル3-4）

JD分析に基づき、トスバンクはレベル3-4にあると推定される。

レベル3以上の根拠：

• 専任のML Platform Team（アドホックではない）
• 成熟したツールスタック（MLFlow、Kubeflow、Airflow）
• プロダクションモデルサービング（Triton）
• カスタム特徴量ストア（ScyllaDBベース）

レベル4-5への志向：

• LLMプラットフォーム開発（最先端の能力）
• GPUインフラ管理（スケールアップ）
• 採用活動自体が拡大と成熟を示唆

面接では、チームを現在のレベルから次のレベルに進めるための貢献としてフレーミングする。ツールだけでなく、MLOps成熟のために必要な組織的・プロセス的変化を理解していることを示す。

5. 面接対策：予想質問30選（めんせつたいさく：よそうしつもん30せん）

Kubernetesとインフラ（質問1-6）

Q1. ML学習ワークロードとモデル推論サービングの両方をサポートするKubernetesクラスタをどう設計しますか？両者の考慮事項の違いは何ですか？

Q2. KubernetesでのNVIDIAデバイスプラグインの動作を説明してください。GPUスケジューリングはどう処理し、学習ジョブ中にGPUノードが異常になった場合はどうしますか？

Q3. 学習ジョブがノードの利用可能なGPUメモリをすべて消費し、他のPodのスケジューリングを妨げています。Kubernetesのリソース管理を使ってこれをどう防止しますか？

Q4. Kubernetes上でのMLモデル更新のブルーグリーンデプロイメント戦略をどう実装しますか？カナリアフェーズではどのメトリクスを監視しますか？

Q5. Multi-Instance GPU (MIG)はどのように機能し、どのシナリオで専用GPU割り当てよりMIGを選びますか？

Q6. 学習ワークロードとサービングワークロードを分離するために、1つの大きなKubernetesクラスタを使うか、複数の小さなクラスタを使うかのトレードオフを説明してください。

MLFlowと実験管理（質問7-12）

Q7. 高可用性とセキュリティの要件を持つ50人以上のデータサイエンティスト向けのMLFlowデプロイをどう設計しますか？

Q8. 大規模組織でのMLFlow実験とランの整理方法を説明してください。実験の乱立をどう防ぎ、発見可能性をどう維持しますか？

Q9. MLFlow Model Registryを使用したモデル承認ワークフローをどう実装しますか？どのステージを定義し、どの自動チェックを追加しますか？

Q10. MLFlowのトラッキングサーバーが大量の実験でパフォーマンス問題を経験しています。これをどう診断し解決しますか？

Q11. モデルの再現性をどう確保しますか？実験からプロダクションデプロイまでのステップを説明し、任意のモデルバージョンを再作成できることを保証してください。

Q12. MLFlowをCI/CDパイプラインに統合し、モデルテストとデプロイメントを自動化する方法を説明してください。

Airflowとパイプラインオーケストレーション（質問13-18）

Q13. MLパイプラインワークロードにおけるAirflowのKubernetesExecutorとCeleryExecutorを比較してください。トスバンクにどちらを推奨し、その理由は何ですか？

Q14. 新しいモデルが現在のプロダクションモデルを下回る場合に自動ロールバックする日次モデル再学習DAGをどう設計しますか？

Q15. 重要なAirflow DAGが午前3時に失敗し、朝のモデル予測が古くなっています。インシデント対応プロセスを説明してください。

Q16. Airflow MLパイプライン内でデータ品質チェックをどう実装し、破損した不完全なデータでの学習を防止しますか？

Q17. Airflow DAGのテスト戦略を説明してください。DAGの変更がプロダクションワークフローを壊さないことをどう保証しますか？

Q18. さまざまなデータソースやMLサービスへの接続のために、Airflowでシークレットと認証情報をどう管理しますか？

モデルサービングとTriton（質問19-24）

Q19. 信用スコアリング判断に5ミリ秒未満のp99レイテンシが必要なモデルをサービングする必要があります。Tritonを使ってサービングインフラをどう設計しますか？

Q20. Triton Inference Serverの動的バッチングを説明してください。最適なスループット-レイテンシトレードオフのためにバッチサイズとキュー遅延パラメータをどうチューニングしますか？

Q21. Tritonを使用して2つのモデルバージョン間のA/Bテストをどう実装しますか？どのメトリクスを追跡し、テストをどのくらいの期間実行しますか？

Q22. デプロイされたモデルが2週間にわたり徐々にパフォーマンスが低下しています。モデルドリフトの診断と解決へのアプローチを説明してください。

Q23. 特徴量プリプロセッサ、主要モデル、ポストプロセッサをチェーンするTritonのモデルアンサンブルをどう設計しますか？

Q24. PyTorchモデルをTritonデプロイ用の最適化TensorRTエンジンに変換するステップを説明してください。注意すべき潜在的な落とし穴は何ですか？

特徴量ストアと分散データベース（質問25-27）

Q25. 特徴量ストアバックエンドとしてRedisよりScyllaDBを選ぶ理由は何ですか？Redisがより良い選択となる状況はどのような場合ですか？

Q26. リアルタイム不正検知モデルの特徴量鮮度（せんど）要件をどう処理しますか？ニアリアルタイムで特徴量を更新するアーキテクチャは何ですか？

Q27. 特徴量ストアにおけるポイントインタイム正確性を説明してください。なぜ重要で、ScyllaDBでどう実装しますか？

LLMプラットフォーム（質問28-30）

Q28. すべてのデータがオンプレミスに留まらなければならない銀行環境向けのLLMサービングプラットフォームをどう設計しますか？主要なアーキテクチャ決定は何ですか？

Q29. 大規模言語モデルのサービングにおけるテンソル並列とパイプライン並列の違いを説明してください。それぞれいつ使用しますか？

Q30. レスポンス品質に大きな影響を与えずにLLM推論コストを50%削減する任務を与えられました。どのようなアプローチを検討しますか？

6. 8ヶ月学習ロードマップ

このロードマップは、現在基本的なPythonとクラウド経験を持つバックエンドエンジニアまたはジュニアMLエンジニアであることを前提としている。出発点に応じてタイムラインを調整すること。

月1-2：Kubernetesとコンテナの基礎

目標（もくひょう）：CKAレベルのKubernetes習熟度を達成する

毎日の練習：平日1.5時間、週末3時間 リソース：KodeKloud CKAコース、Kubernetesドキュメント、killer.sh模擬試験

月3-4：コアMLプラットフォームツール

目標：MLFlow、Airflow、JupyterHubをKubernetes上にデプロイしカスタマイズする

毎日の練習：平日2時間、週末4時間 リソース：各ツールの公式ドキュメント、「Practical MLOps」書籍

月5-6：モデルサービングと特徴量エンジニアリング

目標：Tritonデプロイをマスターし、特徴量ストアプロトタイプを構築する

毎日の練習：平日2時間、週末4時間 リソース：Tritonドキュメント、ScyllaDB University、「Designing Data-Intensive Applications」

月7-8：LLMプラットフォームと面接準備

目標：LLMサービング経験を積み、面接に備える

毎日の練習：平日2時間、週末5時間 リソース：vLLMドキュメント、Hugging Faceリソース、模擬面接練習

学習スケジュール概要

月1-2: [========== Kubernetes + CKA ==========]
月3-4: [==== MLFlow ==][== Airflow ==][= JupyterHub =]
月5-6: [=== Triton ===][=== ScyllaDB Feature Store ===]
月7-8: [=== LLMプラットフォーム ===][== 面接準備 ==]

7. トスバンクML Platform向け履歴書戦略（りれきしょせんりゃく）

履歴書の構成

履歴書はJDの要件に直接マッピングする。推奨構成は以下のとおりだ。

ヘッダーセクション

• 氏名、連絡先、GitHubプロフィール、ブログ/ポートフォリオURL

サマリー（3-4行）

• 経験年数、主要ドメイン（MLOps/MLエンジニアリング）
• JDに合致する主要技術（Kubernetes、MLFlow、Triton）
• 定量化された成果（例：「モデルデプロイ時間を2週間から4時間に短縮」）

経験セクション（STAR形式）

各ポジションについて、以下の構造でバレットポイントを作成する。

• Situation：コンテキストは何だったか
• Task：具体的な責任は何だったか
• Action：何をしたか（技術的詳細）
• Result：測定可能な結果は何だったか

例文：

「30人以上のデータサイエンティスト向けにKubernetes上にMLFlowベースの実験追跡システムを設計・デプロイし、実験からプロダクションまでの時間を80%短縮。SOC 2監査要件を満たすモデルガバナンスワークフローを確立。」

含めるべきキーワード

以下の用語が履歴書に自然に含まれるべきだ。

MLOpsポジションでよくある履歴書のミス

1. コンテキストなしのツール列挙 — 「MLFlowの経験あり」は弱い。「5チーム横断で10,000以上の実験実行を処理するMLFlowトラッキングサーバーをデプロイ」は強い。
2. モデル精度のみに注力 — プラットフォームのポジションでは、インフラメトリクスがより重要（デプロイ頻度、サービングレイテンシ、プラットフォーム稼働率）。
3. スケール指標の欠如 — 常に数字を含める：何モデル、何ユーザー、何スループット、何レイテンシ。
4. ガバナンス角度の欠如 — 金融サービスは監査証跡、コンプライアンス、モデル説明可能性を非常に重視する。明示的に言及すること。

8. ポートフォリオプロジェクト

プロジェクト1：Kubernetes上のエンドツーエンドMLOpsプラットフォーム

目的：コアMLプラットフォームスタックの構築と統合能力を実証する。

アーキテクチャ：

JupyterHub（実験）
     |
     v
MLFlow（実験追跡 + モデルレジストリ）
     |
     v
Airflow（自動学習パイプライン）
     |
     v
Triton（モデルサービング）
     |
     v
Prometheus + Grafana（監視）

実装詳細：

1. ローカルKubernetesクラスタ（kindまたはGPUサポート付きminikube）のセットアップ
2. PostgreSQLとMinIO（S3互換ストレージ）によるMLFlowのデプロイ
3. KubernetesExecutorによるAirflowのデプロイ
4. 以下を行う学習DAGの構築：
   • 特徴量テーブルからデータを取得
   • LightGBMモデルを学習
   • MLFlowにメトリクスとアーティファクトを記録
   • MLFlow Model Registryにモデルを登録
   • パフォーマンスが閾値を満たせばTritonにモデルをデプロイ
5. インタラクティブ実験のためのJupyterHubのデプロイ
6. すべてのサービスのPrometheusスクレイピングとGrafanaダッシュボードのセットアップ

GitHubリポジトリ構成：

mlops-platform/
  infrastructure/
    kubernetes/
      mlflow/
      airflow/
      jupyterhub/
      triton/
      monitoring/
  pipelines/
    training/
    evaluation/
    deployment/
  models/
    credit_scoring/
    fraud_detection/
  docs/
    architecture.md
    setup.md
  Makefile
  README.md

実証すること：プラットフォームエンジニアリングスキル、Kubernetes習熟度、ツール統合、MLライフサイクル全体の理解。

プロジェクト2：ScyllaDB上の特徴量ストア

目的：分散データベース設計と特徴量ストア概念を深いレベルで理解していることを示す。

実装詳細：

1. Kubernetes上に3ノードScyllaDBクラスタをデプロイ
2. 信用スコアリングユースケースのための特徴量スキーマを設計：
   • ユーザーデモグラフィック特徴量（ゆっくり変化）
   • トランザクション集約特徴量（日次計算）
   • リアルタイムトランザクション特徴量（トランザクションごとに更新）
3. 日次集約特徴量を計算しScyllaDBに書き込むバッチパイプライン（Airflow使用）を構築
4. リアルタイム特徴量を更新するストリーミングパイプライン（KafkaとPythonコンシューマ使用）を構築
5. ユーザーIDで5ミリ秒未満のp99レイテンシで特徴量を取得する特徴量サービングAPI（FastAPI）を構築
6. 学習データ生成のためのポイントインタイム正確性を実装
7. 監視を追加：特徴量鮮度、サービングレイテンシ、エラー率

文書化すべき主要設計判断：

• パーティションキー設計とその理由
• コンパクション戦略の選択
• 読み書きの一貫性レベルの選択
• 特徴量有効期限（ゆうこうきげん）のためのTTL戦略
• コネクションプーリングとドライバ設定

実証すること：分散データベースの専門性、特徴量ストアアーキテクチャの理解、リアルタイムシステム設計、パフォーマンス最適化スキル。

プロジェクト3：RAG付きLLMサービングプラットフォーム

目的：LLMインフラと推論最適化の実務経験を実証する。

実装詳細：

1. GPU付きKubernetes上でvLLMを使用してオープンソースLLM（Llama 3 8BまたはMistral 7B）をデプロイ
2. RAGパイプラインの実装：
   • ドキュメント取り込みパイプライン（PDF/テキストから埋め込みへ）
   • 類似性検索のためのベクトルDB（ChromaDBまたはMilvus）
   • コンテキスト注入付きプロンプトテンプレートシステム
   • ストリーミングレスポンス生成
3. 推論の最適化：
   • AWQを使用してモデルをINT4に量子化
   • 量子化前後のレイテンシとスループットのベンチマーク
   • 連続バッチングパラメータの設定
   • よくあるクエリのためのリクエストレベルキャッシングの実装
4. システムをデモするシンプルなチャットインターフェースの構築
5. 監視を追加：毎秒トークン数、最初のトークンまでの時間、GPU利用率、キャッシュヒット率

ボーナス：TensorRT-LLMバックエンドでTritonに同じモデルをデプロイし、vLLMとパフォーマンスを比較。

実証すること：LLMインフラスキル、最適化の専門知識（せんもんちしき）、RAGアーキテクチャの理解、定量的なエンジニアリング判断能力。

9. 知識確認クイズ

10. 参考文献（さんこうぶんけん）とリソース

公式ドキュメント

1. Kubernetesドキュメント — https://kubernetes.io/docs/
2. MLFlowドキュメント — https://mlflow.org/docs/latest/
3. Apache Airflowドキュメント — https://airflow.apache.org/docs/
4. Kubeflowドキュメント — https://www.kubeflow.org/docs/
5. JupyterHubドキュメント — https://jupyterhub.readthedocs.io/
6. NVIDIA Triton Inference Server — https://docs.nvidia.com/deeplearning/triton-inference-server/
7. ScyllaDBドキュメント — https://docs.scylladb.com/
8. vLLMドキュメント — https://docs.vllm.ai/
9. NVIDIA TensorRT-LLM — https://nvidia.github.io/TensorRT-LLM/
10. Feast Feature Store — https://docs.feast.dev/

書籍

11. 「Designing Data-Intensive Applications」Martin Kleppmann著（O'Reilly）— 分散システム概念の必読書
12. 「Kubernetes in Action」Marko Luksa著（Manning）— 包括的Kubernetesの深掘り
13. 「Practical MLOps」Noah GiftとAlfredo Deza著（O'Reilly）— MLOpsプラクティスとパターン
14. 「Data Pipelines with Apache Airflow」Bas HarenslakとJulian de Ruiter著（Manning）— Airflowベストプラクティス
15. 「Programming Massively Parallel Processors」David KirkとWen-mei Hwu著 — GPUコンピューティングの基礎
16. 「Cassandra: The Definitive Guide」Jeff CarpenterとEben Hewitt著（O'Reilly）— ScyllaDBに適用可能な分散DB概念
17. 「Database Internals」Alex Petrov著（O'Reilly）— ストレージエンジンと分散システム内部
18. 「Machine Learning Engineering」Andriy Burkov著 — 実践的MLエンジニアリングパターン

オンラインコースと認定

19. CKA（Certified Kubernetes Administrator）— https://www.cncf.io/certification/cka/
20. ScyllaDB University — https://university.scylladb.com/
21. NVIDIA Deep Learning Institute — https://www.nvidia.com/en-us/training/
22. Made With ML（MLOpsコース）— https://madewithml.com/
23. Full Stack Deep Learning — https://fullstackdeeplearning.com/

コミュニティリソース

24. MLOps Community Slack — https://mlops.community/
25. Kubeflow Slackチャンネル
26. NVIDIA Developer Forums — https://forums.developer.nvidia.com/
27. Toss Tech Blog — https://toss.tech/
28. Airflow Summitカンファレンストーク（YouTube）