0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

自社環境で動かすなら、何を引き受けるか。Tines 3B のセルフホストを読み解く

0
Last updated at Posted at 2026-10-25

連載「Tines 3B を読み解く」の第9回です。

はじめに

「データは自社の環境に置きたい」。業務システムの選定でよく出る要件です。AI ネイティブのワークフロー基盤「Tines 3B」には、Tines が運用する SaaS のほかに、自社の Kubernetes で動かすセルフホストがあります。

この記事では、セルフホストを選ぶと何が前提になり、何が自分たちの責任になるのかを、公式ドキュメントに沿って整理します。

こんな方に向けて書いています。

  • SaaS とセルフホストのどちらを選ぶか検討している
  • 導入の前に、インフラの前提と運用の負担を見積もりたい
  • 「セルフホストなら安心」の中身を確かめたい

先に結論です。セルフホストの前提は具体的で、導入前に試せます。ただし、クラスタ、ロードバランサー、DB、バックアップ、監視、更新はすべて利用者の責任になります。Tines は監視のダッシュボードもアラートも提供しません。

実行の隔離の仕組みは第2回、シークレットと暗号鍵は第3回、料金の体系は第10回で扱っています。

こんな場面、ありませんか

セルフホストを検討すると、こんな場面が出てきます。

  • 「Kubernetes に入れるだけ」と聞いたが、ノードの条件で起動しないことがあると知った。
  • SaaS より安く済むと思っていたが、運用の人件費を見積もりに入れていなかった。
  • バックアップは取っているが、暗号鍵まで含めた復元は試したことがない。

共通するのは、「動かす」ことと「運用し続ける」ことが別の仕事だという点です。

結論:3つの要点

要点 内容 見落とすと
前提を先に試す x86_64、ユーザー名前空間、PostgreSQL 18、ホスト名2つ 導入の途中で Pod が起動しない
評価と本番を分ける 評価は単一サーバー、本番は Kubernetes と Helm 評価用の構成を本番に使ってしまう
運用を自分で持つ 監視、バックアップ、暗号鍵、更新 障害や鍵の紛失で復旧できない

要点1:前提を先に試す

構成要素と通信の流れ

通信の流れを図にしました。

入口の nginx はチャートに内蔵されているため Ingress コントローラーは不要で、前段にロードバランサーが1つあれば足ります。

4つの前提

前提 内容
CPU amd64(x86_64)のみ。Graviton や Ampere などの Arm は動かない
ノード ユーザー名前空間が使えること(containerd 2.x、新しめのカーネル、user.max_user_namespaces が0以外)
DB PostgreSQL 18。wal_level=logical(リアルタイム同期の Zero sync が必要とする)
ホスト名 2つ(app と public)。public は app と別のホスト名にする。DNS は必須で、IP とポートだけの構成は不可

ユーザー名前空間が要るのは、ステップのコードを gVisor のサンドボックスで隔離するからです(第2回)。導入で最も詰まりやすい点ですが、本番の手順の中に導入前の確認(ノード互換テスト)が用意されています。hostUsers: false のテスト用 Pod が起動し、uid_map が恒等でないことを確かめます。

クラウドごとの落とし穴

各クラウドのガイドは「2026年8月時点」の記述で、クラウド側の既定は変わり得ます。

環境 注意点
AWS EKS Auto Mode のノードは、ユーザー名前空間の上限が0に強化されており、api と worker が起動しない。既定の StorageClass も無い
GCP GKE Standard を使う。Autopilot は hostUsers: false の Pod を許可せず、回避策は無い
Oracle OKE Enhanced クラスタと管理ノードプールを使う(仮想ノードは不可)。Oracle Linux 8 の x86_64、Kubernetes 1.33 以上

もう1つ、全クラウドに共通するのがロードバランサーのタイムアウトです。3B の UI は、リアルタイム同期のために長い WebSocket を保ちます。タイムアウトが短いままだと、「画面は開くが、更新が止まる」状態になります。AWS の ALB(既定60秒)と GCP(既定30秒)のどちらも、大きく延ばす必要があります。

要点2:評価と本番を分ける

方式 用途 特徴
単一サーバー(k3s) 評価(PoV、PoC) 1台で動く。冗長性は無く、落ちれば 3B も止まる
エアギャップ(単一サーバー) インターネットに出られないサーバー 接続できる機械で、全イメージ入りのバンドルを作って持ち込む
Kubernetes と Helm 本番 サービスごとにスケールできる

導入に先立って、まず営業窓口(アカウントエグゼクティブか、カスタマーサクセスマネージャー)へ連絡します。そのあと Tines の技術担当が、レジストリへのアクセスと導入を支援します。入手するのは、レジストリの資格情報、リリースのバージョン、署名付きのライセンストークンです。ソフトウェアの入手元は oci.tines.com だけです。

サイジング

出発点の値です。上限ではなく、監視しながら調整する値とされています。

構成 vCPU メモリ SSD
単一サーバー: 動作確認 8 16 GB 250 GB
単一サーバー: 推奨の PoC 8 32 GB 500 GB
単一サーバー: 重い PoC 16 64 GB 500 GB から 1 TB
Helm: クラスタ 8 vCPU 以上 32 GB 以上 ノードは 4 vCPU / 16 GB 以上

Helm の既定(全サービス1レプリカ)では、リクエストの合計が約 5.5 vCPU と 12 GiB です。クラスタ内の PostgreSQL と nginx はリクエストを持たず、サンドボックスは最大 4 GiB までメモリが伸びるので、余裕を持たせる必要があります。永続ボリュームの既定は、PostgreSQL が 10 GiB、blobstore が 50 GiB です。

本番の DB は、管理型(例として AWS RDS)が推奨されています。高可用性が要るなら、外部の PostgreSQL を使います。

ステップごとの資源制限は既定で無効

公平に書いておきたい点です。ステップごとの CPU とメモリの制限(1 vCPU、2 GiB の cgroup v2)は既定で無効で、そのあいだはステップ単位の制限なしで動きます。公式では、ワーカーを増やすときに有効化することが勧められています。有効にするには、書き込み可能な cgroup を持つ containerd のハンドラーをすべてのワーカーノードに用意し、sandboxd.runtimeClassName を合わせます。重いステップが同じノードの他のステップを圧迫する可能性があるため、導入時に決めておくのがよいでしょう。

要点3:運用を自分で持つ

責任の分担

公式では、セルフホストは「利用者が運用するもの」と明記されています。クラスタ、ロードバランサー、TLS 証明書、DNS、バックアップ、監視とアラートは、利用者が自分たちの基準で用意します。

領域 Tines 利用者
ソフトウェア チャート、イメージ、リリースノート、ライセンス 取得と、更新の適用
導入の支援 技術担当による支援 情報の用意
クラスタ、ノード 要件の文書化 構築、運用、正しい動作
LB、TLS、DNS 要件の文書化 設計、運用
DB、ストレージ 要件の文書化 運用、高可用性、容量
バックアップ 単一サーバーの手順 実施、保管、復元の試験
監視 しきい値の推奨 基盤、通知、対応

この表は筆者の整理です。公式に、責任共有モデルの記事は見当たりません。

監視

Tines は、ダッシュボード、アラート、メトリクス基盤を提供しません。利用者が Prometheus や Datadog などで、しきい値を設けます。出発点として、Pod の CPU が要求の約80%超を10分、メモリが上限の約80%超を15分、ボリュームの使用率が60%、などが示されています。

バックアップと暗号鍵

単一サーバーには、自動のバックアップがありません。次の3つは、サーバーの外に置く必要があります。

  1. /opt/3b/.env(設定と暗号鍵)
  2. PostgreSQL のダンプ
  3. ファイルのボリューム

とくに重要なのは1つ目です。この鍵が無いと、データベースが残っていても保存済みの認証情報を復号できません。パスワード保管庫と同じ扱いにする、というのが公式の表現です。Helm 環境では、更新前の DB のバックアップとボリュームのスナップショットの推奨はありますが、復元の手順は見当たりません。

更新

Helm では、同じ設定ファイルで新しい版を指定してアップグレードします。アプリケーションのシークレットは保持され、鍵は回転しません。v2 から v3 への更新では Blobstore の移行方式(fresh か retain)を選ぶ必要があり、どちらも旧ワークロードを止める1回の保守時間が要ります。本番は事前に Tines へ連絡する必要があります。

テレメトリ

v3.1.0 以降、3B は起動時と12時間ごとに、小さなレポートを Tines へ送ります。送る項目は4つです。

  • ライセンス ID(ある場合)
  • 当月の Tines units の使用量
  • 3B のバージョン
  • PostgreSQL のバージョン

ライセンストークン、ワークフローの内容と設定、認証情報、実行データ、ログ、ユーザーの氏名とメールは送らない、と公式では書かれています。送信の失敗はログに残るだけです。ただし、無効化の方法は確認できていません。

守ってくれないこと

  • ネットワークの出口: 宛先に一致しない通信は、公開インターネットへ出ます。出口を絞るなら、利用者側のプロキシで制御します。
  • 内部宛の許可: 社内への到達は ALLOWED_CIDR_BLOCKS で許可します。ただし広い範囲を書くと、インスタンスの資格情報がワークフローのコードに見える危険があります(公式の注意)。最小の範囲にします。
  • STACK_NAME の変更: 初回の起動後は変えません。
  • AI プロバイダへの到達: 3B は HTTPS で到達できることが前提で、AI プロバイダへの外向き通信が要ります。エアギャップ環境での AI の構成は、記事にありません。

他のやり方との違い

提供形態を、一般的な分類で比べます(特定の製品の仕様ではなく、考え方の整理です)。

観点 SaaS セルフホスト ハイブリッド(SaaS と、社内側の出口ノード)
運用の負担 小さい 大きい 小さい(出口ノードは利用者)
データの所在 提供者の環境 自社の環境 SaaS 側
立ち上げ 速い 前提の確認が先 速い
向く場面 運用人員が少ない データを自社に置く要件と、運用体制がある 社内システムへ届きたいだけ

社内システムへ届きたいだけなら、SaaS と Tunnel(社内側で出口ノードを動かす方式)で足りる場合があります。Tunnel はデプロイメントごとに有効化が必要です。

おわりに

  1. 前提(x86_64、ユーザー名前空間、PostgreSQL 18、ホスト名2つ)は具体的で、導入前に試せる。
  2. 評価は単一サーバー、本番は Kubernetes と Helm。評価の構成を本番に使わない。
  3. 監視、バックアップ、暗号鍵、更新は利用者の責任。

「自社に置く」ことは、「自社で守る」ことを含みます。

連載の他の回

連載「Tines 3B を読み解く」(全11回):

参考

公式ドキュメント(docs.3b.tines.com)。Tines 3B Self Hosted の各記事:

補助: Tines 3B pricing and packaging overview / Reach a private network through a secure tunnel / Connect your AI provider

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?