AI分野における
コンテナーオーケストレーション
株式会社スタイルズ
矢野 哲朗
2018年4月17日
商用利用改変可、CCライセンス変更不可
自己紹介
経歴 : システム運用 10年・ネットワーク 6年・SI 8年
近頃はNextcloud/Rancherを担当
その他 : 全く上達しないRubyist
一番最初のPCは、OKI if-800 でした…。
矢野 哲朗
tetsurow.yano
株式会社スタイルズ
1
最近の記事
2
https://www.atmarkit.co.jp/ait/series/12464/
最近の記事
3
https://www.atmarkit.co.jp/ait/series/12464/
プチ炎上
AIワークロードにはコンテナ(Docker)が最適?
4
AI(特にDeepLearning)では、コンテナを使うことが非常に多い
 コンテナイメージを入れ替えるだけでバージョンアップも簡単
 ライブラリーの依存関係とかnVidiaドライバーとかの相性とかを解決できる
 すでに整った各種フレームワークのコンテナが便利に利用できる
Dockerコンテナイメージのおかげ!
 GPUをオーバーヘッドなしに直接利用できる
コンテナにはVMにある抽象化レイヤーがないおかげ!
しかし、だんだんつらさを感じている方も..。
5
コンテナの実行状態を管理で
きない
誰が何を動かしているの?
動いてるのはいつ終了する
の?
コンテナのイメージの種類がフ
レームワークがバージョンアッ
プする度に増える
どれがどうなっているか作った
人も分からない
コンテナを実行する設定を管
理できない設定ファイルを毎回
手で直すのはもう無理
AIのモデルはできたけど、推論
で使う環境の用意が大変
モデルの更新も大変
しかし、だんだんつらさを感じている方も..。
6
コンテナの実行状態を管理で
きない
誰が何を動かしているの?
動いてるのはいつ終了する
の?
コンテナのイメージの種類がフ
レームワークがバージョンアッ
プする度に増える
どれがどうなっているか作った
人も分からない
コンテナを実行する設定を管
理できない設定ファイルを毎回
手で直すのはもう無理
AIのモデルはできたけど、推論
で使う環境の用意が大変
モデルの更新も大変
これらは要するに
7
Dockerでは管理が大変になるという問題
世はオートメーションの時代
8
コンテナのもっと管理しやすく
オートメーションに適したプラットフォーム
が
渇望されていた!
そこでコンテナ界に出てきたのが
9
クーバネーティスと読みます
サイバネティクスと語源が一緒だそうです
なんてのもありましたが、
デファクトは取れませんでした
Kubernetesはオープンソースソフトウェア
ソースコードは、GitHub上で無料で公開されています
ライセンスは、Apache License 2.0 (商用利用化、改変後公開不要、ライセンス変更
不可)です
だれでも、そのソースコードを動かすことができます
Googleが主導して作っていますが、RedHatやマイクロソフトも一緒に開発しています
10
Kubernetesはなぜ必要か?
Dockerはコンテナ実行基盤
Kubernetesはコンテナ管理運用を行うオーケストレーター
オーケストレーターとは?
問:1つのホストでDockerを動かすのではなく、複数のホストで連携
してDockerを動かすにはどうすればいいでしょう?
ホスト
OS
Docker
コン
テナ
コン
テナ
コン
テナ
コン
テナ
ホスト
OS
Docker
コン
テナ
コン
テナ
コン
テナ
コン
テナ
ホスト
OS
Docker
コン
テナ
コン
テナ
コン
テナ
コン
テナ
ホスト
OS
Docker
コン
テナ
コン
テナ
コン
テナ
コン
テナ
どこで何のコンテナがいくつ動いていて、どのコ
ンテナを起動したり、どれとどれが連携している
かについて、誰かが管理する必要がある 11
オーケストレーターがなかったら?
複数のDockerホストの管理
コンテナのデプロイ先を管理
自動スケールアウト
コンテナのローリングアップ
デート
コンテナのサービスディスカバリ
ロードバランシング
コンテナの死活監視
障害時のセルフヒーリング
リソース管理
ストレージ管理
設定ファイル管理
パスワード管理
ネットワーク管理
ログ管理
12
以下のような管理をしなければいけない
kubernetesでは何ができるのか?
13
コンテナを網羅的に管理
コンテナの可用性・拡張性を管理しやすくなる
kubernetesでは何ができるのか?
14
コンテナの管理、GPUを使ったコンテナワークロードの管理
さらなるオートメーション(MLOpsやAI DevOps)の為の基盤
AI分野での各種パイプラインのプラットフォーム
 例:KubeFlow、Argo(intuit社)、Rekcurd(LINE社)、
KAMONOHASHI(NSSOL社)
ReNomをそれらのパイプラインに組み合わせるというのも有効
kubernetesのメリットとデメリット
15
kubernetesのメリット
 コンテナを実行する複数台サーバーでの管理性の良さ
 よく考えられたコンテナ管理システム
 クラウド(AWS、Google、Azure)のKubernetesマネージドサービスを使え
ば、管理手法を統一できる
 コンテナイメージ管理、データ管理、設定管理とセットで管理できる
kubernetesのデメリット
 これまでの管理方法とは全く違っているため、Kubernetesの管理の仕
方を勉強し直す必要がある
 小規模でのオンプレ運用にはあまり向かない(とはいえDocker単体で
の運用も難しい)
kubernetesをどのように使うか(覚えるか)
16
まずは、1台で実行するのを覚える
 WindowsではMinikubeがおすすめ
 UbuntuではMicroK8sがおすすめ
各種コマンドの使い方を覚える
 Katacodaをやってみる
Learn Kubernetes using Interactive Browser-Based Labs | Katacoda
https://www.katacoda.com/courses/kubernetes
kubernetesの概念とリソースを勉強する
 kubernetes完全ガイドを読む
実際に使ってみる
 GoogleのGKEで試す
 オンプレのマシンにkubernetesをインストールしてみる
Kubernetesのポイント1(操作方法を理解する)
 Kubernetesをどのように操作するか
→コマンドで操作せず、構成情報の設定ファイルで操作する
17
1. Kubernetesの設定フ
ァイルを作成
2. kubectlコマンドで
Kubernetes APIへ登録
3. Kubernetesマスターが
各Kubernetesノードへ
設定を反映
manifest.yaml
$ kubectl apply –f manifest.yaml
Kubernetesクラスター
ネットワークを管理する
(サービスディスカバリ
ーとトラフィック分散)
ストレージを管理する
コンテナを管理する
Kubernetesのポイント2(リソースを理解する)
 Kubernetesで必ず理解しておくべき3種類のリソース
18
Service Volume
LoadBalancer
Deployment
Pod
Config
Map
Secret
Replicaset
Service
Ingress
Pod
 1つ以上のコンテナを構成する単位
 ポッド内のコンテナは、必ず同じホストにデプロイされることが保証されている
 IPアドレスは、Podに付与される。その為、Pod内にあるコンテナはlocalhostで通信できる
 Podを管理する上位のReplicasetがある
 Kubernetesではコンテナ単位での管理はできず、かならずPod単位での管理となる
19
Pod
Container Container
Pod単位で起動
Node Node
なぜ、Podという概念が必要か?
コンテナ、一つに1つの役割を持たせようとすると、1
つのコンテナに複数のプロセスを含める必要がでてき
てしまう。これはコンテナの原則である1つのコンテナ
には1つのプロセスという考え方から外れてしまう。そ
こで、コンテナ1つに1つのプロセスとしつつ、役割を
与える単位としてPodという概念が追加された。
Pod内のコンテナはIPアドレスとポート、プロセス空間、
ファイルシステムを共有し、プロセス間通信が可能
プロセス、IPアドレス、ファイル
システムを共有する
IPアドレス
Replicaset
 1つ以上のPodを管理する単位
 Pod起動数を指定する(replicas)
 Podの起動停止を管理する
 Podが起動しているか監視している
 Podにはラベルを付け、そのラベルのついているPodを管理する
 Replicasetを管理する上位Deploymentがある
20
Replicaset
Pod Pod Pod
replicas: 3
同じラベルのついているPod
が3つになるように起動する
Podが足りなくなっ
たら補うように
自動的に起動する
なぜ、Replicasetという概
念が必要か?
コンテナ環境でのPodは、
プロセスなのでVMと違っ
て落ちてしまうことがあり
ます。またホストがダウン
した場合にもPodは消滅し
ます。それらを避けて冗長
性・スケールをもたせるた
め
Deployment
Deployment
 1つ以上のReplicasetを管理する単位
 複数のReplicasetを管理して、ローリングアップデートやロールバックを行う
 Replicasetの起動停止を管理する
21
Replicaset Replicasetv1 v2
バージョンアップする
Service
 Podの起動停止に合わせたサービスディスカバリ
 Pod宛てのトラフィックをロードバランシングする
 ロードバランシングの接続先仮想IPアドレスの付与
 クラスタ内DNSへの自動登録
 外部ロードバランサーへの登録
22
Service
Pod
Pod
Pod
Pod
外部LoadBalancer
10.42.0.138
10.42.0.43
10.42.0.110
ClusterIP
10.43.10.132 分散される
新しく追加されるとメンバー
に自動的に追加される
Ingress
 ServiceリソースへのL7でのトラフィックを処理する
 外部L7ロードバランサーを使う場合とL7を処理するポッドを
利用する場合の2つのパターンがある
23
Service
Pod
Pod
Pod
外部 L7
LoadBalancer
Service
Pod
Pod
Pod
外部LoadBalancer
L7処理
Pod
L7処理
Pod
Config
Map
ConfigMap&Secret
 設定用情報を管理する
 環境変数で参照することができる
 ファイルから作成し、Volumeとしてマウントするとファイルとして参照することができる
24
Config
Map
設定ファイル
設定ファイル
Config
Map
Config
Map
環境変数
環境変数
Pod
Pod
設定ファイル
環境変数
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user
[$time_local] "$request" '
'$status $body_bytes_sent
"$http_referer" '
'"$http_user_agent"
"$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
nginx.conf
nginx.conf
Volume
Volume
Volume
 Podに外部Volumeをマウントできる
 Pod専用のVolumeを切り出してマウントすることもできる
 再利用することも可能
 ボリュームのクローンなどはストレージ側による
25
Pod
Pod
・NFSサーバーのマウント
・ボリュームの自動切り出し
・再マウント
これだけではあまりにもKubernetesなので
26
TensorFlow Servingについて
Tensorflow Servingとは?
27
モデルを推論で使うためのクライアントとサーバーの仕
組み
※TensorFlowServingと「TensorFlow」とついていますが、あまりTensorFlowとは関係がありません
TensorFlow
Servingアプリケーション
学習済
Model
※要コンバート
gRPC
なぜ、このような仕組みが必要か
28
・学習はPythonでモデルを作り、推論(Inference)の利用もPythonを使
う。
しかし、利用側の業務システムはJavaで書かれてて困る。
・Pythonで推論プログラムを作るにしても、推論するアプリとモデル
が1対1で繋がってしまうと動的に切り替えられない。
・モデルを入れ替える機能を推論するアプリに入れるのは無駄なコー
ドが入ってしまうのでそれも無駄。
推論アプリ(Python)
学習済
モデル
推論
プログラム
密結合
• APIで外部から呼び出したい(疎結合)
• アプリはJavaにしたい
• モデルをバージョンで切り替えたい
• モデルの利用をスケールアウトしたい
TensorFlow Servingのアーキテクチャ
29
TensorFlow Serving のサーバーアーキテクチャは以下のようになっています。
Clientは、gRPC
でAPIを呼び出す
以下のURLが呼び出しリクエストを投げるURI
http://{host}:{port}/v1/models/{model_name}:predict
{host}:サービングサーバーのIPアドレス
{port}:サービングサーバーのポート番号
{model_name}:モデル名
Predict:実行するメソッド名
指定のモデルへ
リクエストを転送
モデルで推論して
返答を返す(複数)
モデルファイル
(複数)
TensorFlow Servingの動かし方
30
・TensorFlow Servingの起動方法
1.通常のサーバーとして起動
2.Dockerでサーバーとして起動
3.Kubernetesで起動
4.Kubeflowで起動
1、2は手軽だが管理方法が複数大規模に動かす場合には、煩
雑になりがち。
3、4は管理は楽になるがそれぞれのオーケストレーションの
理解が必要
TensorFlow Servingを動かす(直起動)
31
1. サービングサーバーバイナリーをインストール
する
2. モデルのディレクトリを構成する
3. model.configを指定する
4. 起動
/root/serving-example/<モデル名>/
/<バージョン>/
assets/
assets.extra/
variables/
variables.data-?????-of-?????
variables.index
saved_model.pb
tensorflow_model_server --model_name='default’ 
--model_base_path=/root/serving-example/ 
--model_config_file=/root/model.config
# apt-get update && apt-get install tensorflow-model-server
32
ご清聴
ありがとうございました
スタイルズはNextcloud/Rancher
国内の正式パートナーです
株式会社スタイルズ
〒101-0052 東京都千代田区神田小川町1−2 風雲堂ビル 6F
http://stylez.co.jp
http://owncloud.jp
kubernetesにご興味がありましたら、お声がけください

AI分野におけるコンテナオーケストレーションとは