はじめに
Dataikuのチュートリアルを進めていく中でAPIデプロイが必要だったが、
チュートリアルに従うと設定項目がないため、インフラ作成を行った際のまとめ
Dataiku APIデプロイエラーに関する調査・対策レポート
1. これまでの対応経緯
Dataikuのチュートリアルにおいて、開発環境（Designノード）で作成したAPIサービス job_postings を、Kubernetesインフラ（APIノード）へデプロイしようとした際、処理が途中で強制終了するエラーが発生した。
試みた手順
- API Deployerのインフラ作成画面（+ New Infrastructure）から、インフラタイプ
Kubernetes clusterを選択。 - 命名規則（半角小文字＋ハイフンのみ）に準拠した一意のID
my-k8s-clusterを手動入力してインフラを作成。 - 作成したインフラを指定して「Deploy」を実行。
2. エラーの根本原因
API Deployerの詳細ログ（History ＞ View Log）から、以下の致命的なエラーメッセージを確認。
returned non-zero exists status 1: tar: Error is not recoverable: exiting now
com.dataiku.dip.exceptions.ProcessDiedException: Command failed: '/data/dataiku/datadir/bin/python' (exit code: 1)
原因の分析
-
ファイルのアーカイブ（圧縮）失敗 (
tar: Error)
デプロイ環境（Kubernetesのコンテナ）にAIモデルやプログラム、Pythonのコード環境を転送するために、Dataikuのシステムが内部でそれらのファイルを1つの塊（tarファイル）にまとめる処理を行った際、処理が破綻（クラッシュ）している。 -
想定される内部理由
- キャッシュの破損：前回の失敗時（ID未入力や名前の命名規則エラー時）に生成された不完全な一時ファイルがシステム内に残り、処理を邪魔している。
- 容量・メモリ不足（無料体験版の制限）：モデルやPythonのコード環境（ライブラリ群）のサイズが大きすぎて、Dataiku Cloudの無料体験用サーバーのメモリ上限を超え、処理（Pythonプログラム）が強制切断（Killed / exit code 1）された。
3. リトライ時のアプローチ方法
デプロイの容量対策に終始しているが、結局チュートリアルのだと使えないとかアナウンスしてくれてる方が嬉しいのだが。。。
対策A：バージョンIDを新しくしてキャッシュをリセットする（実行済みでダメだった）
壊れた圧縮ファイルの履歴を完全に回避するため、開発画面（Designノード）からパブリッシュする際に、バージョンIDを毎回新しい名前（例: v2, v3 など）に手動で書き換えてからAPI Deployerへ送り直す。
対策B：Pythonコード環境を「標準（Built-in）」に固定する
デプロイ時の容量を最小限に抑えるため、APIサービスの「Settings」＞「Python/Code Environment」を「Inherit（引き継ぎ）」ではなく「None (Use DSS builtin) / 標準環境」に変更し、余計な外部ライブラリをコンテナに詰め込まないようにする。
対策C：モデルを軽量なアルゴリズムに変更する（そもそも大したものは使ってないが念のため）
ディープラーニングなどの重いモデルは避け、容量が非常に小さい軽量なモデルでAPIサービスを作り直し、ビルド時の負荷を減らす。
最後に
今回の失敗とは別にAWSとか他のデプロイ仕組みと比較してみるのも面白いかと思いました（もうすでに誰かがやってそうではありますが）