OpenStack Summit Vancouver 2018参加レポート (1/2)

初めまして、LINE株式会社のVerda 2チームでPrivate Cloud(Verda)の運用と開発に従事している西脇です。
5月21日から5月24日にかけて開催されたOpenStack Summit Vancouverに発表者/聴講者として参加してきましたので、その様子を本ブログで2回にわたってご紹介します。

1つ目の記事では、OpenStackの簡単な説明と参考になったセッションを一部ご紹介させていただき、2つ目の記事で我々が発表してきた内容をご紹介させていただきます。


OpenStackとは

まずは、簡単にOpenStackについてご紹介します。OpenStackは、AWSやGCPのようなクラウド基盤を構築するためのオープンソースソフトウェアです。

みなさんご存知の通り、一言にクラウド基盤と言っても様々なユースケース/対象のサービスがあります。AWSやGCPのように、クラウド基盤上のリソースをユーザに商品として提供する形態(Public Cloud)や弊社のように社内のアプリケーション開発者向けにリソースを提供する形態(Private Cloud) 、また提供するリソースの形態においても、単純に仮想マシンやブロックストレージのみをユーザに提供する形態(IaaS)やアプリケーションのデプロイメントからアプリケーションのマネージメント機能を提供する形態(PaaS)など様々なユースケースがあります。OpenStackはこれらの様々なユースケースに対して複数のコンポーネント、複数のプラグインを組み合わせる、または開発することで目的のユースケースの達成をサポートします。この点を踏まえるとOpenStackはクラウド基盤構築ソフトウェアという一面だけでなく、クラウド基盤構築ライブラリ/フレームワークの一面もあると言えるでしょう。弊社のPrivate CloudもOpenStackをそのまま使うのではなく、カスタマイゼーションを施し運用しております。

聴講したセッション

Private Cloud & Hybrid Cloud

Root your Openstack on a solid foundation of leaf-spine architecture!

OpenStackというよりは、データセンターネットワークをどのように設計するかに重点が置かれているセッションです。Lightning Talkだったので10分の短いセッションでしたが、ぜひ本セッションで40分お話を聞きたかったと思わせてくれる素晴らしいセッションでした。我々の発表とかなり被るところがありますが、データセンターネットワーク側の話を中心にお話されていました。私たちのセッションに興味を持っていただけた方は、こちらもぜひ見ていただくと我々のセッションの理解が深まると思います。我々のセッションの内容の紹介は、次回の記事でご紹介させていただきます。

Container Infrastructure

Kata Containers: The way to run virtualized containers

昨年の12月にOpenStack Foundationが発表した新しいコンテナ技術のOSS Kata Containerがどのように動くのかという発表でした。セッションの敷居がとても低く設定されており、コンテナとは何だろうかと思っている方にもぜひ1度見ていただきたいとても良いセッションでした。Kata Containerの公式ページの説明をすでに見られている方は、ご存知かと思いますがKata Containerは軽量VMをコンテナのように扱えるようにし、Containerのデメリットの1つであったContainer間でKernelが共有されてしまうというセキュリティの問題を取り除いてしまおうというプロジェクトです。

本セッションでは、Kata Containerがどのように軽量VMやコンテナを作成するか、またDockerやKubernetes上からリソースへアクセスを可能にするためにどのようなことをしているが述べられているだけでなく、KSMやShared Rootfsの利用など、本アーキテクチャ上もっとも懸念される点である軽量のVMのオーバヘッドをどう軽くしていくかについても述べられています。また私自身盲点だった点は、ContainerごとにKernelのバージョンが変更できるため、Host KernelでサポートされていないハードデバイスをパススルーしサポートされているKernelのコンテナで利用できるようにするというユースケースも面白いと思いました。

Friendly coexistence of Virtual Machines and Containers on Kubernetes using KubeVirt

VMをKubernetes Podと同じように管理できるようにすることを目的としたKubeVirtというKubernetesの拡張ソフトウェアに関するセッションです。一見Kata Containerと同じようなものを想像される方がいらっしゃる方がいるかもしれませんが、全く別の方向性を持ったソフトウェアです。少し前からアプリケーション開発者の間でコンテナ化やk8sを使ったデプロイメントの流れがきており、新しく開発するソフトウェアはコンテナ化を前提に設計されている方も多いことでしょう。しかし現実社会では、システムを構成する全てのサービスがコンテナ化できる訳ではありません。どうしても動作OSの縛りがある古いソフトウェアなどVMとしてデプロイしなければならないサービスもあり、一部はコンテナ、一部はVMとして運用されている方も多いのではないでしょうか。そのようなケースだと、システムのデプロイ/運用にどうしても”コンテナ用の管理ツール”, “VM用の管理ツール”と2つ以上のツールを組み合わせて運用することになるかと思いますがこれでは運用が複雑になってしまいます。そこでKubeVirtでは、コンテナ用の管理ツールであるKubernetesでVMの管理もできるように拡張をし、コンテナ管理ツールのみでVMを含むシステムを運用可能にしようと試みています。

実装は、KuberenetesのCustom Resource Definitionを使ってVMを表現するような新しいリソースタイプを追加し、その他のコントローラーと同じようにCustom ControlerがEtcdのKeyをwatchし、変更があった際にHypervisorのスケジューリングやVMのデプロイメントを実施しているようです。詳細はぜひセッションをご覧ください。

Bringing Istio to Openstack

IstioというApplication service mesh frameworksを紹介するセッションになります。コンテナやマイクロサービスアーキテクチャが実アプリケーションで使われるようになり、複数のコンテナで1つのシステムを構築することは珍しくなくなりました。しかし、そのようなシステムを実際に運用してみるとコンテナ間の依存関係をどのようにうまくコントロールするかという問題にぶち当たることは珍しくないでしょう。例えば、100種類のコンテナでシステムが構成されているとき、ある1つのコンテナに障害(または致命的バグの混入)が起きた際いくつのコンテナに影響があるのでしょうか、また1つのコンテナをアップグレードしたいが当面は、20%のトラフィックを古いバージョンのコンテナに、80%を新しいバージョンのコンテナにということを実現したいときどのように別のコンテナからのトラフィックコントロールを実現しますか、といった問題を解決してくれるのがApplication service mesh frameworksになります。本セッションでは、Istioの説明の他にKubernetesとOpenStack環境でどのように利用するかtype LoadbalancerやPod間のネットワーキングの話なども触れ最後には、Cloudinitからユーザスクリプトを動かし、VMをIstioのサービスメッシュに参加させるようなデモを公開しています。興味はあったけど詳細はわからないという方はぜひこのセッションをご覧いただけたらと思います。

Leveraging Serverless Functions in Heat to deliver Anything as as Service (XaaS)

FissionというKubernetes上で動くサーバレスフレームワークとOpenStack Heatと連携させるという話でした。Heatテンプレートにコードをそのまま書き込み、Heatのstackを作成すると、HeatのFission用のプラグインが該当のリソース定義からFission用のパッケージを生成し、実行してくれるというものです。当日のセッションでは、シンプルなAPIサーバを実行する例が紹介されていましたが、別途質問をしてみるとTimerやEventで起動するということもすでに検討が始まっておりEventについては、OpenStackの各コンポーネントがresourceの変更をメッセージキュー経由で通知するnotificationにも対応するという案は現在出ているようです。

単純なサーバレスAPIサーバが作成できるという仕組みだけでは、まだ物足りなさを感じますが、EventやTimerなどAPI以外のトリガーにも対応することができたらOpenStackの拡張性をより広げることができるでしょう。OpenStackに限らずクラウド上で実際に、アプリケーションを構築/運用をしてみると様々なタイミングで特定の処理を実施したいという思うことは少なくありません。それはデプロイ時だけでなく、オートスケーリングの実装、特定のパターンのアプリケーション障害からの復旧、ガバナンスを効かせるために特定のリソースの作成をaudit logとして持ちたいなどなどシチュエーションは多岐に渡ります。もちろんこれらをクラウド基盤の外側で実現してすでにアプリケーション運用の効率化ができている人たちもいますが、クラウド基盤の開発に従事している私たちの思いとして、これらのクラウドの特性を生かしたオペレーションの効率化はできる限り我々のクラウド管理者側で実施し、アプリケーション開発者はに自身のビジネスロジックの実装になるべく集中できるような環境を提供したいと考えております。

実際に、弊社でも似たような取り組みが進んでおりOpenStackを含めたクラウド上の特定Eventに対して、ユーザが任意のコードを紐づけできるような仕組みを現在開発/導入を検討しております。今回の発表で取り上げられていたFissionのOpenStackのインテグレーションは、セッションを聞く限りではまだ始まったばかりで弊社でそのまま導入できますというような簡単な話ではないように思えますが、今後の動向が非常に気になるソフトウェアの1つとなりました。

ここまでコンテナを取り巻くいくつかの技術に関するセッションを取り上げてきました。最近では弊社内でもコンテナを使おうという動きや、コンテナオーケストレータの評価、Private Cloudでコンテナをファーストクラスとして扱って欲しいなどたくさんのコンテナにまつわる議論がなされています。ですが一言にコンテナといってもそれを取り巻く技術には、非常にたくさんのコンテキストや実装があります。今回取り上げていないセッションにもOpenStackのネイティブコンテナオーケストレータであるZunや、k8sのcatalog機能であるHelmなどたくさんのコンテナに関わる技術が今回のOpenStack Summitでお話しされていました。これらのなかには、似たような切り口のものもたくさんありますが、一見同じに見えても根本の思想が違えば1年後には違うソフトウェアになっていることもあるので、新しい技術に振り回されず根本的に何を解決するための仕組みなのかに注意を払いこれらの技術動向をこれからもチェックし、弊社で活用できるものを見極め、導入を進めて行きたいと思います。

全体所感

2、3年前と比べOpenStack Summitの盛り上がりは半分もしくは1/3ぐらいになっているように感じました。おそらく2、3年前はOpenStackの導入を検討している人、導入したてで問題が山積みな人が非常に多かったのでしょう。それに引き換え、今回参加されている方はHypervisor 1000台以上、クラスタ数が20クラスタを超えている、k8sなどアプリケーションワークロードの管理もOpenStackの一部として実現をしたいなどのOpenStackを単純に利用するだけでなくスケーラビリティの問題やIaaSより上の層もサポートしたいなど特殊なユースケースがある方が多かったように感じます。2010年のリリースから8年、単純に中規模で利用する際のベストプラクティスはすでに各社で確立され、安定運用できるまでOpenStackが成熟したということでしょうか。

弊社も単純なIaaS基盤の提供という観点ではある程度落ち着いてきておりますが、記事中にも一部記載している通りより開発者が使いやすい安定したPrivate Cloudを目指して日々改良に取り組んでおります。OSSやミドルウェアに興味がある方や、下記に興味がある方はぜひこちらをご確認いただければと思います。

・IaaS基盤のスケーラビリティ、複数クラスタの運用効率化

・アプリケーション開発者のための開発/運用の効率化

・プログラマブル Private Cloudを目指した Event Handler(AWS Lambdaのようなもの)の実装

・k8sを始めとするManaged Middleware Serviceの提供

2つ目の記事では、我々の発表「Excitingly simple multi-path OpenStack networking: LAG-less, L2-less, yet fully redundant」の内容についてご紹介させていただきます。

Related Post