AI分野におけるコンテナオーケストレーションとは
•Descargar como PPTX, PDF•
1 recomendación•1,718 vistas
[機械学習/DL/TDA]ReNom User Group (RNUG) #11 登壇資料
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a AI分野におけるコンテナオーケストレーションとは
Similar a AI分野におけるコンテナオーケストレーションとは (20)
Más de Tetsurou Yano
Más de Tetsurou Yano (20)
AI分野におけるコンテナオーケストレーションとは
- 2. 自己紹介 経歴 ： システム運用 10年・ネットワーク 6年・SI 8年 近頃はNextcloud/Rancherを担当 その他 ： 全く上達しないRubyist 一番最初のPCは、OKI if-800 でした…。 矢野 哲朗 tetsurow.yano 株式会社スタイルズ 1
- 5. AIワークロードにはコンテナ(Docker)が最適？ 4 AI（特にDeepLearning）では、コンテナを使うことが非常に多い コンテナイメージを入れ替えるだけでバージョンアップも簡単 ライブラリーの依存関係とかnVidiaドライバーとかの相性とかを解決できる すでに整った各種フレームワークのコンテナが便利に利用できる Dockerコンテナイメージのおかげ！ GPUをオーバーヘッドなしに直接利用できる コンテナにはVMにある抽象化レイヤーがないおかげ！
- 11. Kubernetesはオープンソースソフトウェア ソースコードは、GitHub上で無料で公開されています ライセンスは、Apache License 2.0 (商用利用化、改変後公開不要、ライセンス変更 不可)です だれでも、そのソースコードを動かすことができます Googleが主導して作っていますが、RedHatやマイクロソフトも一緒に開発しています 10
- 16. kubernetesのメリットとデメリット 15 kubernetesのメリット コンテナを実行する複数台サーバーでの管理性の良さ よく考えられたコンテナ管理システム クラウド(AWS、Google、Azure)のKubernetesマネージドサービスを使え ば、管理手法を統一できる コンテナイメージ管理、データ管理、設定管理とセットで管理できる kubernetesのデメリット これまでの管理方法とは全く違っているため、Kubernetesの管理の仕 方を勉強し直す必要がある 小規模でのオンプレ運用にはあまり向かない(とはいえDocker単体で の運用も難しい)
- 17. 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をインストールしてみる
- 18. Kubernetesのポイント1(操作方法を理解する) Kubernetesをどのように操作するか →コマンドで操作せず、構成情報の設定ファイルで操作する 17 1. Kubernetesの設定フ ァイルを作成 2. kubectlコマンドで Kubernetes APIへ登録 3. Kubernetesマスターが 各Kubernetesノードへ 設定を反映 manifest.yaml $ kubectl apply –f manifest.yaml Kubernetesクラスター
- 20. 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アドレス
- 21. 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は消滅し ます。それらを避けて冗長 性・スケールをもたせるた め
- 22. Deployment Deployment 1つ以上のReplicasetを管理する単位 複数のReplicasetを管理して、ローリングアップデートやロールバックを行う Replicasetの起動停止を管理する 21 Replicaset Replicasetv1 v2 バージョンアップする
- 23. 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 分散される 新しく追加されるとメンバー に自動的に追加される
- 24. Ingress ServiceリソースへのL7でのトラフィックを処理する 外部L7ロードバランサーを使う場合とL7を処理するポッドを 利用する場合の2つのパターンがある 23 Service Pod Pod Pod 外部 L7 LoadBalancer Service Pod Pod Pod 外部LoadBalancer L7処理 Pod L7処理 Pod
- 25. 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
- 26. Volume Volume Volume Podに外部Volumeをマウントできる Pod専用のVolumeを切り出してマウントすることもできる 再利用することも可能 ボリュームのクローンなどはストレージ側による 25 Pod Pod ・NFSサーバーのマウント ・ボリュームの自動切り出し ・再マウント
- 29. なぜ、このような仕組みが必要か 28 ・学習はPythonでモデルを作り、推論(Inference)の利用もPythonを使 う。 しかし、利用側の業務システムはJavaで書かれてて困る。 ・Pythonで推論プログラムを作るにしても、推論するアプリとモデル が1対1で繋がってしまうと動的に切り替えられない。 ・モデルを入れ替える機能を推論するアプリに入れるのは無駄なコー ドが入ってしまうのでそれも無駄。 推論アプリ(Python) 学習済 モデル 推論 プログラム 密結合 • APIで外部から呼び出したい(疎結合) • アプリはJavaにしたい • モデルをバージョンで切り替えたい • モデルの利用をスケールアウトしたい
- 30. TensorFlow Servingのアーキテクチャ 29 TensorFlow Serving のサーバーアーキテクチャは以下のようになっています。 Clientは、gRPC でAPIを呼び出す 以下のURLが呼び出しリクエストを投げるURI http://{host}:{port}/v1/models/{model_name}:predict {host}：サービングサーバーのIPアドレス {port}：サービングサーバーのポート番号 {model_name}：モデル名 Predict:実行するメソッド名 指定のモデルへ リクエストを転送 モデルで推論して 返答を返す(複数) モデルファイル (複数)
- 32. 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
- 33. 32 ご清聴 ありがとうございました スタイルズはNextcloud/Rancher 国内の正式パートナーです 株式会社スタイルズ 〒101-0052 東京都千代田区神田小川町1−2 風雲堂ビル 6F http://stylez.co.jp http://owncloud.jp kubernetesにご興味がありましたら、お声がけください