OpenStackがエッジコンピューティングスタック[StarlingXをトップレベルプロジェクトに加える

米国時間6月11日、OpenStack Foundationはエッジのデプロイメントを動かすためのコンテナベースのシステムであるStarlingXが「今やトップレベルのプロジェクトである」と発表した。これによりStarlingXは、ライフサイクル管理のAirshipKata Containers、そしてCI/CDプラットホームZuulなどとともに、 メインのOpenStackのプライベートおよびパブリックなクラウドインフラストラクチャプロジェクトに加わる。

StarlingXがこれらほかのプロジェクトとやや違うのは、エッジデプロイメントのためのフルスタックであることで、そのために、ファウンデーションのラインアップの中では他のプロジェクトよりもOpenStackそのものに似通っている。Cephストレージプラットホームのオープンソースのコンポーネントや、KVMによる仮想化、Kubernetes、そしてもちろんOpenStackとLinuxを使っている。そのためStarlingXはユーザーに、コンテナとVMのワークロードをエッジにデプロイする容易な方法を提供できるうえ、スケーラブルかつ軽量でプラットホーム上でホストされるサービスへのレイテンシーの低いアクセスを与える。

StarlingXの初期の採用者はChina UnionPayやChina Unicom、およびT-Systemsだ。オリジナルのコードベースを2018年にファウンデーションに寄贈したのはIntel(インテル)とWind River System。それ以降、このプロジェクトには211のオーサーからの7108のコミットがあった。

OpenStack Foundationのエコシステム担当であるIldiko Vancsa(イルディコ・ヴァンツァ)氏は「StarlingXのコミュニティはこの2年間で大きく進歩しました。オープンソースの素晴らしいソフトウェアを作ることだけでなく、生産性が高く多様性に富んだコントリビューターコミュニティの構築にも影響を与えています。レイテンシーが低くパフォーマンスの高いアプリケーション開発ためのコアプラットホームは、コンテナベースの分散クラウドアーキテクチャと安全なブーティング、TPMによるデバイスイネーブルメント、証明の管理、およびコンテナの分離(アイソレーション)により強化されました。本年後半を予定しているStarlingX 4.0aは、コンテナランタイムとしてKata Containersをサポート、OpenStackのUssuriバージョンを統合、そしてそのほかのプラットホームサービスのコンテナ化などの強化策が重要な特徴になります」と説明する。

なお、ここ数年でOpenStack Foundationがいくつかの変化を体験したことを特記しておくべきだろう。中でも最も重要なのは、OpenStackのコアプロジェクトには含まれないが同団体のミッションと戦略的に横並びしているようなほかのオープンソースのインフラストラクチャプロジェクトを取り込んでいることだ。その中で、パイロット段階を終えてトップレベルのプロジェクトになったものは、2019年4月のKata ContainersとZuul(未訳記事)、そして同年10月に参加したAirshipだ。

OpenStack Foundationで今残っている唯一のパイロットプロジェクトは、OpenInfra Labsプロジェクトだ。これは商用のベンダーと学術研究機関、ボストン大学やハーバード、MIT、インテル、Red Hatなどから成るコミュニティによる、プロダクション的な環境でオープンソースコードのより良いテスト方法を見つけるプロジェクトだ。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

通信市場で争うオープンソースコミュニティ

先日バルセロナで開催されたMWCのことを考えるとき、おそらくあなたは最新のスマートフォンや他の携帯機器について考えることだろう。だがそれは物語の半分に過ぎない。実際には、そうした話題は半分以下なのだ。なにしろMWCで行われているビジネスの大部分は、企業向け通信ビジネスに関わるものだからだ。それほど遠くない昔、そのビジネスとは、高価な専用ハードウェアを売ることに他ならなかった。だが現在は、これらのほとんど全てがソフトウェアに移行している。そして多くのソフトウェアがオープンソースなのだ。

なので、今年Linux Foundation(LF)がMWCに独自のブースを設けたのは当然のことだ。それは巨大なものではなかったが、独自のミーティングスペースを確保できる程度には大きなものだった。ブースはLFによる3つのプロジェクトによって共同利用されていた:Cloud Native Computing Foundation(CNCF)、Hyperledger、そしてONAPOpen Platform for NFV (OPNFV)(どちらも最新ネットワークに欠かせない)などの、基本的なプロジェクトを支えるLinux Foundation Networking (LFN)である。そして5Gの出現により、つかむべき新しい市場シェアがたくさん生まれている。

このイベントにおけるCNCFの役割について議論するために、私はCNCFのエグゼクティブディレクターであるDan Kohn氏の話を聞いた。

MWCでCNCFは、OpenStack上の仮想ネットワーク機能と、CNCFがクラウドネイティブネットワーク機能と呼ぶものの性能を比較したテストベッドを発表した。このクラウドネイティブネットワーク機能は、Kubernetes(とベアメタルホストであるPacket)を利用している。プロジェクトの成果として示されたものは、少なくともこれまでのところは クラウドネイティブコンテナベースのスタックは、競争相手のOpenStackコードよりも1秒あたりにはるかに多くのネットワーク機能を処理できたということである。

「私たちが発信しているメッセージは、ベアメタルもしくは任意のクラウドの上で動作する、汎用プラットフォームとしてのKubernetesを使えば、ほとんどの仮想ネットワーク機能は、クラウドネイティブネットワーク機能上に移植できるということです」とKohn氏は語った。「すべての運用支援システム、すべてのビジネス支援システムソフトウェアも、同じクラスタ上のKubernetesで実行することができます」。

さて、一方OpenStackは、また別の大規模なオープンソースプロジェクトである。ご存知ない方のために説明すると、企業が自身のデータセンターのソフトウェア基盤を管理するための手段を与えるものだ。OpenStackの最大の市場の1つは、長い間通信業界だった。これまでも常にCNCFとOpenStack Foundationの間には、ある種の摩擦が続いていたが、OpenStack Foundationがその組織を、直接コアOpenStackプロジェクトとは関係しないプロジェクトへも開放したことによって、その摩擦傾向は強まった。

私はKohn氏に対して、現在CNCF/Kubernetesスタックを、OpenStackのライバルとして位置付けているのかどうかを尋ねた。「はいそうです。私たちの見解は、Kubernetesをベアメタルサーバー上で動作させるべきで、中間層は不要だというものです」と彼は述べた。これまでCNCFはこうしたことを明言しては来なかったが、内部ではずっとそのように言われていたのだ。彼はまた、こうした摩擦の一部が、CNCFとOpenStack Foundationが、様々なプロジェクトに対して競合関係になっていることから生じていることを認めた。

OpenStack Foundation側は、当然ながらこうした対立には同意しない。OpenStackのCOO、Mark Collierは「KubernetesをOpenStackと対立するものとして扱うことは極めて非生産的です。それに、OpenStackが既に多くのケースで、Kubernetesと組み合わせる形で5Gネットワークを支えているという事実を無視することになります」と私に対して語った。「それに、OpenStackが単なる仮想マシンのオーケストレーターだとおっしゃっているのでしたら、OpenStackが実際に何をしているのかについての理解が不足なさっていることも意味していますね。そうした説明は、もう数年前の過去のものです。多くのワークロードにとって意味のある、仮想マシンからの離脱が、OpenStackからの離脱を意味するわけではありません。今ではOpenStackはそうした環境のなかで、Ironic、Neutron、およびKeystoneサービスを通じてベアメタル、ネットワーク、そして認証を管理しているのです」。

同様に、OpenStack Foundationの元ボードメンバー(ならびにMirantisの共同創業者)であるBoris Renski氏は、私に対して以下のように語った「単にコンテナーがVMに取って代わることができるからといって、KubernetesがOpenStackに取って代わるわけではありません。Kubernetesの基本設計は、低レベルのインフラストラクチャを抽象化する以外のものがあることを前提としています、すなわちアプリケーションを意識したコンテナスケジューラであることを目指しています。一方OpenStackは、ベアメタル、ストレージなどの低レベルのインフラストラクチャ構造を抽象化することを目的に、特別に設計されているのです」。

この議論はKohn氏とCNCFによるKata Containersへの批判にもつながっている。Kata Containersとは、OpenStack Foundationがその組織をOpenStack以外のプロジェクトに対しても開放した後に手がけた、最初のプロジェクトである。Kata Containersは、従来の仮想マシンに対してさらなるセキュリティを加え、コンテナの柔軟性と組み合わせて提供することを約束している。

「KataをめぐるFUD(不安や疑念)に関してはこう言うことができます:通信会社は(a)騒がしい隣人問題(同じテナントに載る他のインスタンスとのリソース競合問題)と、(b)セキュリティに関する問題に対応するために、Kataを使う必要が出てくるでしょう」とKohn氏は語る。「それは未知のものに対するFUDに過ぎませんし、(Kataの採用する)マイクロVMは本当に興味深い技術なのです」。

しかし彼は、サードパーティのコードを実行しているような状況(Firecrackerを実行しているAWS Lambdaを想像して欲しい)に対しては、Kataのやりかたは興味深いと考えているが ―― 残念ながら通信業者たちは通常そのようなコードを実行したりはしないのだ。そして彼はまた、Kubernetesも騒がしい隣人たちをうまく扱うことができると主張している。なぜならそれぞれのコンテナが抱えることのできるリソースの数を限定することができるからだ。

どちらの組織もここではフェアな議論をしているように見える。KubernetesはいくつかのユースケースではOpenStackよりも、よりうまい処理を行い、高いスループットを提供できるかもしれないが、その一方では、OpenStackはそれ以外の多数のユースケースを上手く扱うことができる。だが明らかなのは、ここにかなりの摩擦が生まれていることなのだ。残念なことである。

画像クレジット: Jean Joselle Rosal / EyeEm / Getty Images

[原文へ]
(翻訳:sako)

OpenStackがオープンソースのCI/CDプラットホームZuulを切り離して独立化

OpenStackほど複雑なオープンソースプロジェクトはほかにないと思われるが、これは要するに、AmazonのAWSのような総合的なクラウドコンピューティング環境を、企業が自分のデータセンターの(主としてプライベートな)インフラストラクチャとして装備するためのシステムだ。それを構成するさまざまなサブシステムを作るためにチームは、独自のDevOpsツールを作らざるをえなかった。2012年には、その一環として、オープンソースの継続的インテグレーションとデリバリ(CI/CD)プラットホームZuulを作った。そしてこのほど、Zulu v3のリリースを契機に、ZuluをOpenStackから切り離して独立のプロジェクトにした。でもOpenStackのエコシステムを去るわけではなく、依然としてそれは、OpenStack Foundationがホストするツールだ。

構造をざっと展望すると、OpenStack Foundationは一種の母体的組織であり、その傘下のメインプロジェクトとしてOpenStack本体のほかに、昨年おそく登場したKata Containersと、今回のZuulがある、という構造になる。すなわちOSFは近年、本体OpenStackのほかに、関連のインフラストラクチャプロジェクトも揃えよう、としているのだ。

Zuulはデベロッパーたちに、プロジェクトに新たな変更を加えようとするときの、コードのマージ、ビルド、そしてテストの工程を自動化するシステムを提供する。サポートする開発プラットホームはかなり幅広くて、GitHubや、コードレビューとプロジェクト管理のツールGerritなどもサポートしている。

Zuulの現在のコントリビューターは、BMW, GitHub, GoDaddy, Huawei, Red Hat, そしてSUSEだ。BMWのソフトウェアエンジニアTobias Henkelは語る: “ソフトウェアプロジェクトがCD/CIを幅広く採用することは、高品質なソフトウェアをタイムリーにデリバリするための基盤だ。それにより、個々のコミットチェックからフルリリースに至るまでの、開発サイクルの重要な部分を、すべて自動化できる。弊社BMWのCI/CDチームは、Zuulコミュニティの一員であることを誇りとし、オープンソースのZuulプロジェクトの積極的なコントリビューターであり続けたい”。

Zuulがスピンオフして独立した今の時期は、CI/CDに関して選択肢がとても多くなっている。GoogleとNetflixはオープンソースのSpinnakerで、Zuulと同様の機能を提供しようとしているし、またJenkinsとその類似プロジェクトたちも依然として強い。これらに対してZuulは、大規模で複雑な開発プロジェクトをうまく扱えるmulti-repo gatingマルチリポジトリ・ゲーティング)機能の有利性を強調している。

今カナダのバンクーバーで、これらのオープンソースプロジェクトの代表者たちによるOpenDevカンファレンスが行われており、そこでOpenStack Summitも併催されているので、数日〜数週間後にはこれらのプロジェクトすべてに関するより詳しい情報が出てくることだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

OpenStack FoundationがOpenStack以外のオープンソースプロジェクトもホストする方向へ

【抄訳】
最近の数年間で、Cloud Native Compute FoundationやCloud Foundry Foundationなど、オープンソース関連の団体がいくつか立ち上げられた。これらの多くはLinux Foundationの一員になっているが、その仲間に加わっていない大きなオープンソース団体のひとつが、OpenStack Foundationだ。ここは、少なくともこれまでは、クラウドコンピューティングプラットホームOpenStackの開発にフォーカスしてきた。

しかし、時代は変わりつつある。隔年で開催されるOpenStack Summitの最後の数日につき合ってみて明らかに感じたのは、OpenStack FoundationがOpenStackプラットホーム以外のものにも目を向け始めていて、将来この組織はLinux Foundationに似たものになるのではないか、という感触だ。ただしそのビジョンはもっとシンプルで、現在の関心に沿ったオープンなインフラストラクチャにフォーカスするだろうが、それらは必ずしもOpenStackプラットホームの一部である必要はなく、プロジェクトも今のガイドラインに縛られないものになるだろう。

OSFのこの多様化路線がうまくいけば、Linux FoundationやApache Foundationなどと並ぶ、大きくて総合的なオープンソース団体がもう一つでき、彼らのOpenStack関連の知識と経験がコミュニティをサポートしていくことになって、オープンソースのコミュニティに変動をもたらすだろう。またOpenStack Foundationが従来ならLinux Foundationに行ったようなプロジェクトもホストするようになると、二者間に興味深い競合関係が生ずるかもしれない。

その初期からOpenStackを採用しているMirantisの協同ファウンダーでCMOのBoris Renskiによると、OSFのこの新しい動きを引っ張るにふさわしい人物は、CTOのMark Collierと事務局長のJonathan Bryce、そしてマーケティングとコミュニティサービス担当のVP Lauren Sellだ。Renskiの見解では、OSFが多様なプロジェクトを手がけていくのは良いことであり、OpenStackが安定期に入りつつある現在は、新しいことに取り組む時期としても適している、と。

では、OSFが今後新たにフォーカスしていくべきテーマは、なんだろうか? Bryceによると、今計画に上(のぼ)っているのは、データセンターのクラウドインフラストラクチャ、コンテナのためのインフラストラクチャ、エッジコンピューティング(Collierがとくに関心を持っている)、継続的インテグレーション/継続的デリバリ、そして可能性としては機械学習とAIの分野だ。

Linux Foundationが主にLinuxユーザーの便宜のためにさまざまなプロジェクトを傘下に収めてきたのと同様、OSFも主にOpenStackでメインのシステムを構築しているユーザーの便宜を図っていく。だから団体の名称はOpenStack Foundationのままでよい、とBryceらは考えている。

【後略】

[原文へ]
(翻訳:iwatani(a.k.a. hiwa