話題の記事

Docker漬けの一日を共に〜Docker Meetup Tokyo #23 レポート〜 #dockertokyo

とにかくアツかった３つのセッションと5つのLTのDocker Meetup Tokyo #23の参加レポートです。

濱田孝治

2018.05.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本日は、こちらのイベントに参加させていただきました。

Docker Meetup Tokyo #23 - connpass

参加人数は95人と大規模な勉強会なのですが、抽選倍率はさらに3倍程度あったようで大盛況。無事当選したことはなによりの喜び。ワッセロイ。

この記事では、本ミートアップの模様をお届けいたします。メインセッション３つ、LT枠5つというてんこ盛りノンストップ休憩なしというストロングスタイルの勉強会だったのですが、自分がよく知らない界隈、興味深い話が沢山聞けて物凄く楽しかったです。

訂正・補足事項などがあれば、濱田（@hamako9999）までメンションなりなんなりでご連絡いただければ、随時対応させていただきます。

それでは、皆さん、楽しんで行きましょう！

　__
（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     Docker祭りﾀﾞ ﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

講演内容一覧

講演内容 発表者
Docker Meetup Tokyo #23 - Zenko Open Source Multi-Cloud Data Controller Laure Vergeron, R&D Engineer and Technology Evangelist @Scality
機械学習デプロイを支えるコンテナ技術 Chie Hayashida, Cookpad
KubeCon EU報告(ランタイム関連，イメージ関連) Akihiro Suda, NTT
KubeCon報告とmicroscanner試してみた @CS_Toku
Docker_Meetup_Tokyo_23_gVisor_network_traffic_benchmark makocchi
5分でわかる Capabilities と Privilege + KubeCon Recap Masaya Aoyama
Dockerイメージのバージョン管理は GitのCommitHashよりもTreeでやると良い Yuki Yoshida
KubeCon EU 2018でおもしろかったもの Toshihiro Iwamoto

講演資料はこちらにまとめられています。

Docker Meetup Tokyo #23 - 資料一覧 - connpass

Avoiding public cloud vendor lock-in: how Zenko, the multi-cloud data controller can help

「パブリッククラウドベンダーのロックインを避け、Zenkoによりマルチクラウドデータコントローラーを使いましょう！」

皆さん、最近マルチクラウドという単語を耳にすることも増えたかと思いますが、どういったイメージをお持ちでしょうか。代表的なユースケースを上げてみようかと思います。

  • Content Distribution
  • Compute Bursting
  • Analytics
  • Long-term Archival / cold storage

そういたユースケースに対して、Zenkoでは、マルチクラウドデータコントローラーを提供しています。

Zenko CloudServer - Open Source S3 Server written in Node.js

  • Single Interface to any Cloud
    • 単一のS3 APIを利用して、数多のクラウドに接続
  • Allow reuse in the Cloud
    • クラウドネィティブなフォーマットを維持
  • Always know your data and where it is
    • メタデータの検索機能
  • Trigger actions based on data
    • レプリケーションやロケーション変更を管理するデータワークフロー

一つのインターフェース（S3 APIベース）で、様々なクラウドへのインターフェースを利用可能。クラウドネイティブなフォーマットに対応し、APIで差分を吸収する。例えばDynamoDBへのアクセスなども同様のインターフェースでアクセス可能。

これらの特徴により、Zenkoはベンダーロックインを防ぎます。

Zenkoは、一つのエンドポイント、一つのAPI、一つのネームスペース、そして複数のクラウドネイティブフォーマットを提供します。

クライアントアプリケーションからのインターフェースはS3API形式に一本化されており、バックエンドは、独自サービス、AWSストレージ（S3、DynamoDB、Kinesis）、GCP、Microsoft Azureなどに対応しています。

Zenkoのその他の特徴

Zenko Orbit management UI

Multi-Cloud Data Management, Simplified - Zenko Orbit

専用のUIが提供されています。1TBまでのバックエンドデータの扱いが無料。エンドポイント、ネームスペース、ロケーション、レプリケーションわーっ区フロー、ハードウェアステータス等の管理が可能。

CloudServer Standalone

Zenko CloudServer - Open Source S3 Server written in Node.js

S3 APIを提供する。Dockerコンテナ。Node.jsで書かれたオープンソースプロダクト。AWSのS3APIのみで、複数種類かつ、パブリッククラウドでもオンプレミスのバックエンドデータサービス双方へアクセス可能。現在、世界中に100万のエンドポイントが存在している。

Zenko S3 API Support & Roadmap

現在は、Core S3 APIs、Adbanced S3 Apisに対応。2018年には、バケットライフサイクルや、メタデータ検索拡張にも対応予定。

Zenkommunity

デベロッパーコミュニティーの構築に注力している。コミュニティミートアップや、デベロッパーハッカソンなども実施。

濱田感想

最後に、動作デモをみることができました。基本的なセットアップはWebのGUIベースで実施可能。minicubeから、S3API（筆者には見慣れたAWS　CLIベースのインターフェース）で、Windows Azure上にバケットが作成される体験はなかなか衝撃的でした。ストレージの種別が隠蔽されているのは、面白いですね。

細かな仕様の違いをどう吸収するのかはいろいろ興味がつきませんが、まずは、触ってみようと思います。

発表スライドの後半には、プロダクトのもっと詳細があるので、そちらを参考にしていただくと、よりZenkoのことを知ることができると思います。

Docker for Machine Learning（機械学習を支えるコンテナ技術）

講演者はクックパッドの、Chie Hayashidaさん。

PyConJPでPySparkについて発表したり、Web+DB Pressで機械学習系の記事を書いている。実験管理のOSSを作ったりしている。

今日お話する内容は、大きく以下の２点。

  • 機械学習の発展とコンテナ技術
  • コンテナ環境における機械学習のデプロイ

機械学習の活かし方

機械学習とは、「人間が自然に行っている学習能力と同様の機能をコンピュータで実現しようとする技術・手法」のことである。理論自体は1960年ぐらいの昔から存在したが、普及には2つのハードルがあった。

  • 機械学習アルゴリズムの実現の難しさ
  • アプリケーションとしての導入の難しさ

機械学習のプロセスは、ざっくり言うと、データの特徴を表す「モデル」をつくり、作ったモデルに対してデータを使って推論を行う。以前は、大量のデータと大規模な計算リソースが必要で、それだけの物理装置を用意することができなかった　→　実用化が難しかった。

最近発展している背景には、実現するためのハードウェアやソフトウェアの進化があることが関係している。機械学習発展の背景には、それ以外にも以下の要素が絡んでいる。

  • hadoop、Google Big query
  • GPU（NVIDIA）
  • 機械学習ライブラリの確率
  • Arxivによる論文の公開
  • GitHubによるソースコードの公開

これらにより、誰でも機械学習を実装できるようになった。

しかし、アプリケーションとしての導入の難しさは残る。モノリシックな環境において、機械学習導入は難しいものだった。各ロジックのインターフェースが複雑で、ソフトウェアスタックの違いを吸収するのが難しい。通常のWebアプリケーションとは、言語やライブラリが全然違う。

さらに、データサイエンティストにとって、サービス開発に必要な非機能要件の検討が難しい。作ったら、作りっぱなしになったり、運用要件の確率や可用性、冗長化の設計に慣れていなかったりする。そこに、コンテナ技術の進歩による機械学習のマイクロサービス化が進んできた。

  • 独立したソフトウェアスタックによる、ロジックの分離
  • リソースの分離
  • 非機能要件を設定ファイルで管理
  • 作業分担を明確化
  • CD（Continuous Delivery）の導入

マイクロサービス的に機械学習アプリケーションを１つの独立したサービスとして提供可能になった。開発もデバッグも、依存関係が整理されるので、非常にやりやすくなった。

コンテナ技術により、今までの機械学習アプリケーション導入の難しさが解消されつつある。

とはいえ、アーキテクチャの複雑さの問題がなくなったわけではない。

アーキテクチャ検討例①「コンテナの分離」

モデルの違いにより必要なリソースタイプが異なる。例えば、データ処理はメモリを使うことが多く、推論はCPUやGPUを酷使する。ここは分けたほうがリソースコーリツが良い。

モデルの再利用を意識したコンテナの分け方がキモになる。

アーキテクチャ検討例②「スケーラビリティの設計」

コンテナの分離により、コンテナ毎のスケーラビリティの確保が可能

アーキテクチャ検討例③「コンテナ配置設計」

各ハードウェアリソースに対するコンテナの配置を物理的に考慮する必要あり。

アーキテクチャ検討例④「GPU環境へのデプロイの難しさ」

GPUはcgroupによるリソース管理の対象外なので、GPUへのデータ転送などが難しい。そのために、GPUリソース監視の仕組みの導入が必要であったり、GKEでもalphaクラスタでしか使えないものがある。推論においてはGPUが不要なケースも多いため、問題となりにくい。

アーキテクチャ検討例⑤「モデル再学習」

モデルの再学習にはGPU環境との連携が必要。流行語の変遷を追うためには、定期的に再学習を実施する必要あり。

Kubeflowについて

kubeflow/kubeflow: Machine Learning Toolkit for Kubernetes

  • 中小規模の利用にはスペックオーバーな気がする
    • tf.servingは便利で、それで十分かも
    • 分散学習が必要な規模のプロジェクトは日本では多くない
    • 実験環境とプロダクション環境の切り分けも必要

フルマネージドサービス

  • SageMaker
  • Cloud ML Engine
  • Azure ML

かなり進化してきたので、便利に使える感触はあるが、まだまだ発展途上の感がある。

実証段階からDockerを利用する

研究開発部には所属しているが、プロダクトとしてデプロイすることを前提としている。そのために、プロダクトデプロイのためのコンテナも意識する必要がある。

nvidia-docker

NVIDIA/nvidia-docker: Build and run Docker containers leveraging NVIDIA GPUs

CookieCutter Docker Science

docker-science/cookiecutter-docker-science: Cookiecutter template for data scientists working in Docker containers

リサーチャーもDockerを利用可能となり、実験段階から環境を共通化し、実験内容の共有や、再現性の担保、デプロイの容易化に利用している。

まとめ

  • コンテナ技術は機械学習デプロイに欠かせない存在になりつつある
  • マイクロサービスにより全てが解決するわけではないが、サービスの堅牢性を高める手段として便利
  • 実験時からデプロイを意識したコンテナ利用を行うことで効率性があがる
  • 分散学習やGPUを用いた推論への対応、今後はマネージド・サービスにも期待したい

濱田感想

機械学習の文脈でのコンテナ活用について、全くイメージが沸かなかったのですが、機械学習の基礎の基礎から解説してもらったので、その界隈においてコンテナが必要とされる理由や使われ方が非常に良くわかり、腹落ちしたセッションでした。

足を踏み込んでいくと物凄い奥深く敷居が高いイメージが強い機械学習ですが、最近はパブリッククラウドベンダーのマネージドプラットフォームも多数出てきているので、コレを機に食わず嫌いにならないようにいろいろ試してみたいと思える、素敵なセッションでした。

KubeCon + CloudNativeCon EU 2018報告(ランタイム関連、イメージ関連)

講演者は、NTTソフトウェアイノベーションセンタの須田　瑛太さん。

KubeCon + CloudNativeCon EU 2018、に参加してきました。そこで自分的に気になったトピックを4つほど紹介します。

参加者4000名、日本からは50名ほど。どんどんDocker界隈が盛り上がっているのを肌で感じます。

トピックはこちら。

  • Container Isolation at Scale(... and introducing gVisor)
  • The Route To Rootless Containers
  • Entitlements: Understandable Container Security Controls
  • Building Images on Kubernates - Toward a first class aproach

Container Isolation at Scale(... and introducing gVisor)

概要：カーネルをコンテナから分離すること（gVisor）でセキュリティを強化した、OCIコンテナランタイムrunscを提案

  • Linuxカーネルをユーザランドで再実装（Go）
  • ptrace版とKVM版がある
  • runcの代替として使える
  • Meltdownを防ぐデモが展示されていた

嬉しいことは、CPUのセキュリティリスクからコンテナーが隔離される点など。

  • 向いているもの
    • 小さいコンテナー
    • セットアップが早い
  • 向いていないもの
    • 信頼された実績のあるイメージ
    • システムコールを頻繁に呼ぶもの

手元で試して見た限りでは、gVisorを利用すると、おおよそ7倍ぐらい処理が重たくなる感触。

The Route To Rootless Containers

概要：root権限無しでコンテナランタイムを動かすことで、セキュリティを強化する取り組み

  • 課題1:複数ユーザーをコンテナーで利用する場合がある
    • newuidmapを使用する
  • 課題2:cgoupsを利用可能にする
    • 予めrootでchownしておく
  • 課題3:CoWファイルシステム
    • Ubuntuならrootlessでoverlayfsが利用できる

Entitlements: Understandable Container Security Controls

概要：'docker run'の --privilegedや--cap-addなどのセキュリティ関連のフラグを簡潔に記述できるようにする取り組み

Imageを作る時に、Imageにサインする動作。Docker統合の準備はできているが、デザインが固まっていないため、まだPRはでていない。Kubernatesへの実装も容易されている。

Building Images on Kubernetes - Toward a first class aproach

概要：Kubernetes上でコンテナイメージをビルドする取り組み。

Kubernatesに関係するイメージビルドツールが登場している。是非一度触ってみて欲しい。

LT: KubeCon報告とmicroscanner試してみた

気になった要素

  • gVisor
  • CSI
  • Cilium
  • セキュリティ系
    • Kube-bench
    • microscanner

Aqua Container Security - Docker, Kubernetes, OpenShift, Mesos

microscannerとは

aquasecurity/microscanner: Scan your container images for package vulnerabilities with Aqua Security

Aqua Securityuが出しているツール。コンテナイメージに対するセキュリティスキャンをしてくれる。Free版、SaaS版、PaaS版がある。Free版はパッケージスキャンのみ。今回は、Free版を試してみた。

  1. 登録してトークンを取得
  2. Dockerfileの最後にコマンドを追加
  3. 結果を確認

パッケージが古いほど、沢山脆弱性がでてくる。導入コストは低いので、とりあえずやっておいて損はないのでは？まずはFree版で試してみましょう！

LT: gVisor での Network Traffic の性能を比較してみた

gVisorを利用した場合のネットワークトラフィックについて、性能をためしてみた様子をお届けします。

install gVisor

gVisorの導入の仕方は簡単。Dockerで動かす場合は、runtimeを追加してあげればOK。

limitation of gVisor

  • Dockerで動かすなら 17.09以上が必要
  • Podの中に1つのコンテナしかサポートしてない
  • 一部のsystem callが動かない

gVisor's Network Performance

iperf3を利用。比較のためにVM同士とruncも計測。実際に計測してみると、かなりネットワーク性能が落ちる。Sentryがpacketを処理するためにそこがネックになる。

まとめ

普通に使うとかなりNetwork性能は落ちるが、--network=hostを設定することで、ある程度はパフォーマンスを出すことができる。その他考慮点を頭に入れ、適切なユースケースで使うのが望ましい。

LT: 5分でわかるCapabilityとPrivilege

root権限と一口にいっても、rootの中にも複数の種類が割り当てられている。デフォルトのCapabilityではホスト名の変更は受け付けられない。その場合は、必要なCapabilitiesを渡してあげる必要がある。

LT: Dockerイメージのバージョン管理はGitのCommitHashよりもTreeでやると良い

  • AWSのECRとECSを利用
  • デプロイはTeffaform
  • アプリはGo、Python、Javaなどいろいろ
  • GitHubとDrone
  • 開発はGitHub Flow
  • デプロイにはGitLab Flow

開発の流れは以下の通り

  • ECRを本番環境AWSアカウントに構築
    • イメージは不要な更新により即、プロダクション環境に影響がある
    • 開発環境からのスイッチロールでアクセスを制限することにより、ECRにアクセスする人を制限
  • GitLab Flowにより、各環境（開発、ステージング、本番）用にブランチを作成
    • デプロイ先環境とブランチを1対1で対応させることで、デプロイを直感的にわかりやすくしている

このフローをそのまま回すと、ECRにイメージが各環境ごとに複数作成されるためムダが多い。そのため、Treeを利用してイメージにタグを付けることで、ディレクトリ構成のファイル内容と同一のものは同じイメージを利用することで、ムダを省きデプロイフローをシンプル化することに成功した。

LT: KubeCon EU でおもしろかったもの (caicloudのunionpay事例, cilium)

Kubernetes on Supporting $8 Trillion Card Payments in Chine

  • SSO
    • 一回ログインすればk8sでもOpenStackでもつかえる
  • マルチテナント
  • ネットワーク

非常に面白いセッションだったので、ぜひ皆さんもググって参考にして欲しい。

Accelerating Envoy with the Linux Kernel

参加レポートなど、まとめは、近日こちらで公開予定！！

VA Linux Systems Japan株式会社

まとめ「Docker界隈あつすぎやろ、これ」

ぶっちゃけ自分は、Dockerやコンテナ全般に対して知見が深いわけではないので、非常に楽しみにしていた勉強会でした。期待にそぐわず、セッション内容が多岐にわたっていて盛りだくさんで、各発表者の熱量もすごく、懇親会も含めてすごく楽しめた勉強会でした。

AWS界隈でも既に実績が豊富なECSから、東京リージョンが熱望されるFargate、GAが待ち遠しいEKSなど、今後のリリースロードマップが非常に豊富で、楽しみなところ。

アプリケーションホスティングの選択肢として完全に無視できなくなっているコンテナ界隈。今後もウォッチし続けていこうと思います。

それでは、今日はこのへんで。濱田（@hamako9999）でした。

customer-story-analytics

関連記事

【イベントレポート】筋肉エンジニアのビルドアップ会#4 に参加してきました

佐藤雅樹

2024.04.04

【イベントレポート】「Unreal Engine Meetup in Nagoya Season2 Vol.1」に参加してきました。

入井啓太

2024.03.24

ハックツハッカソン ~ブラキオカップ~ にメンターとして参加してきました

森田力

2024.03.22

「GitLab Connect Japan 2024」に参加してきました

きだぱん

2024.02.16