情報畑でつかまえてロゴ
本サイトは NTTテクノクロスが旬の IT をキーワードに
IT 部門が今知っておきたい最新テクノロジーに関する情報をお届けするサイトです

OpenStack Summit 2017 Boston速報 3日目

OpenStack Summit 2017 Bostonの報告・第三弾です。

本記事に関するお問い合わせ先: /products/privatecloud/index.html


ボストンからこんにちは!

本日も、OpenStackSummit 2017 Bostonのホットな情報をお届けいたします。

OpenStackSummitも折り返し地点を超えて、3日目となりました。
3日目以降はキーノートがないため、本日は興味深かったセッションの情報のみをお知らせします。

※なお、本記事の記述は概要に留まります。見聞きしてきたセッションのより詳しい情報は、後日別記事にてご紹介する予定です。そちらもご期待ください!
※1日目、2日目の記事は以下です。

・1日目:/column/tec/openstack_summit_2017_boston_1/
・2日目:/column/tec/openstack_summit_2017_boston_2/


OpenStack Summit 2017 Boston 会場(Hynes Convention Center)入り口の様子OpenStackサミット会場(Hynes Convention Center)入り口の様子です。

■セッション

Container as a Service on GPU Cloud: Our Decision Among K8s, Mesos, Docker Swarm, and OpenStack Zun

本セッションでは、インハウスのユーザー向けにGPU利用できるコンテナを提供するために、コンテナ関連ツールのGPU対応状況を調査した結果が紹介されていました。

コンテナの種類自体はGPUドライバの扱い等の優位点からNvidia-dockerに決まったそうなのですが、コンテナを制御するスケジューリングツールについては候補がいくつかあり、比較調査を行ったとのことでした。

調査結果は以下の通りで、結論としてはKubernetesを採用したとのことです。

・Nvidia-dockerのスケジューリング機能
 ⇒GPUアイソレーションがコンテナ間で為されず、コンテナがビジーなGPUにアタッチされてしまう可能性がある。
・Docker-Swarm/Swarm mode
 ⇒nvidia dockerをサポートしていない。
・OpenStack Zun
 ⇒GPUリソースが現状まだサポートされていない。
・Mesos
 ⇒Nvidia GPUリソースの対応をしているのはMesosコンテナだけであり、Dockerに対応していない。
・Kubernetes
 ⇒バージョン1.6.1以降はGPUリソースを扱え、Nvidia-dockerにも対応している。

ちょうど約一年前のOpenStack Summit 2016 Austinでは、コンテナ関連技術としてLXCやMesos、Swarmを利用している例もちらほら見かけたのですが、今回のサミットで見た範囲では、ほぼKubernetes + dockerの一強といった印象でした(実際に定量的に比較したわけではないのですが)。
本セッションの調査において、これだけの数のツールを比較してKubernetes + docker(Nvidia-docker)が勝ち抜いたということは、やはり現状においてよく選ばれるだけの実力を有しているということなのではないかと思われました。

Per API Role Based Access Control

現在のOpenStackにおいて、APIへのロールベースアクセス制御はpolicy.jsonという設定ファイルに条件(○○APIはadmin権限のみ実行可能......などの権限条件)を記載することで実現しています。
しかしこの方法にはいくつか難点があり、目的のAPIとpolicy.jsonで指定する名称の対応が非常にわかりづらい、条件の変更を行った場合設定ファイルの再読み込みをさせるためにプロセスの再起動が必要である等、利便性に欠ける点があります。

本セッションでは、上記の難点を解消させるアイデアが紹介されていました。
かいつまんで説明すると、権限確認処理を(現状のトークン認証と同様に)ミドルウェア化して分離し、かつ設定内容も以下のようにAPIとの対応が分かりやすいかたちに変更するということでした。

新しいポリシー設定書式

執筆者もpolicy.jsonの編集をしたことがあるのですが確かに本セッションで述べられている通り分かりにくさがあり、この方法であればだいぶシンプルになるのではないかと思われました。

ただし本件まだ実装完了まで至っておらず、

・仕様は「Backlog」として承認された。
・作成途中のコードをレビュのために投稿はした。

という状況とのことです。

実装状況は以下から追えますので、ご興味お持ちの方はウォッチしてみてはいかがでしょうか。


https://blueprints.launchpad.net/keystone/+spec/role-check-from-middleware


Kuryr-Kubernetes: The Seamless Path to Adding Pods to Your Datacenter Networking

OpenStackのネットワークとKubernetesの統合に関する、Kuryr-Kubernetesというプロジェクトがあります。本セッションではこのプロジェクトの概略と今後の展望を紹介していました。

Kuryr-Kubernetesプロジェクトでは、OpenStack上のVMとKubernetesのPodを同じNeutronネットワークで接続できるようすることを目的としています。
Kuryrは、KubernetesのPodに関するイベントを監視しており、Podが作成されると、NeutronのポートとVIFを作成し、KubernetesのPodをNeutronのポートにバインドすることでVMとPodを接続可能にします。

今後、リソース管理や、マルチテナント、複数ネットワークをサポートできるように機能追加をしたり、機能ごとにkuryrのプロセスを分割する等の改善をおこなっていくようです。

Kubernetesと様々なOpenStackコンポーネントがより強力にインテグレーションされていくことで、IaaSの可能性はますます広がり、かつ利用しやすくなっていきそうです。

Lightning Talk:Non-Native English Speakers in the OpenStack Community: A True Story

OpenStackサミットのセッションは通常一枠40分なのですが、ライトニングトークと呼ばれる、10分間で簡単なプレゼンを行う枠が毎回設けられています。

時間が短いことが幸いして、正式なセッションにするほどではないTipsやトリビアルな知識、個人的取り組みなどが題材となることが多く、存外内容の濃い話を聴くことができます。

その中でも、本ライトニングトーク「Non-Native English Speakers in the OpenStack Community: A True Story(OpenStackコミュニティの非ネイティブ英語話者:真実の物語)」は、ネイティブ日本語話者かつ非ネイティブ英語話者である執筆者にとって非常に気になるタイトルでしたので、足を運んでみました。

本ライトニングトークのスピーカーは、日本・中国・ブラジルの三カ国が出身とのことでした。
みなさま、母国語との文法的・発音的な差異、言語以外の文化的差異にも苦労していたとのことですが、最終的には以下のように、4つのカテゴリに分けてまとめていました。
(各々の注意点は要約しております)

・読む
 ⇒最も簡単だが、開発を行う上では重要。
 ⇒IRCミーティングでは速度も要求されるので注意。

・書く
 ⇒長くきれいな文章を書くのは難しい
 ⇒こちらもやはりIRCミーティングでは速度も要求されるので注意。

・聴く
 ⇒アクセント、語彙、文法の勉強が必要。
 ⇒話す側は、ゆっくり、シンプルな言葉づかいをしてくれると助かる。

・話す
 ⇒発音、語彙、文法の勉強が必要。
 ⇒流暢になるのは大変。

結局のところ、4つの要素全てが必要かつ地道な勉強が重要ということですね......!
(OpenStackコミュニティにオンライン上でのみ関わるのであれば、聴く・話すは不要かもしれませんが)



連載シリーズ
テクノロジーコラム
著者プロフィール
本上 力丸、池尻 恭介
本上 力丸、池尻 恭介