Open Infrastructure Summitで紹介されたCERNやAdobeの事例

Open Infrastructure Summitで取り上げられたさまざまな事例の中から、CERNとAdobeの事例をメインに紹介する。

2019年5月21日 6:00

OpenStackは、その出自がベンダー主導ではなくユーザーであるRackspaceとNASAから始まったことは以前の記事でも紹介した。そしてOpenStackをホストする組織であるOpenStack Foundationも、デベロッパーとユーザーとが互いに出会う場所としてOpenStack Summitを運営していたことは知られるべきポイントだろう。最近のサミットではだいぶベンダー色が濃くなった感覚もあるが、それでもユースケースをベンダーではなくユーザー自身から紹介されることで、よりリアルな情報が共有されることが最大の良さだろう。

参考：OpenStack事例で知る現実解と多様な応用例

今回の記事では、OpenStackの事例としてはおなじみとも言えるCERNの事例、そして少人数で巨大なクラウドを運用していることでこれも数年前のサミットで紹介されたAdobeのセッションを紹介する。

「故郷」CERNでのOpenStackの状況

CERNは、スイスとフランスの国境付近に存在する素粒子物理学の世界最大の研究施設である。そのため利用するOpenStackの規模もかなりのもので、2013年というかなり初期からのヘビーユーザーだ。コア数で29万コア、900テラバイトのメモリー、9ペタバイトのストレージを3600名以上のユーザーが利用しているという。

CERNのOpenStackの規模はこれぐらい

CERNはかなり初期からのOpenStackのユーザーで、Grizzlyリリースから利用しているということは2013年から最新のバージョンまで使い続けているということになる。

CERNがOpenStackのリリース

この年表で興味深いのは、LibertyまではテレメトリーのプロジェクトであるCeilometerが使われていたがそれ以降は消されている点だ。CERNのユースケースとしては、Ceilometerは使われなくなったということかもしれない。

CERNのMagnumの概要

CERNのワークロードは主に仮想マシンベースであったため、OpenStackとよく適合したと記憶しているが、CERNにおいてもコンテナの利用は拡がっているようで、RockyからMagnumというOpenStackからKubernetesなどのコンテナオーケストレーションを操作するAPIを提供する。500以上のクラスター、1700以上のノードに375のKubernetes、140のDocker Swarmが稼働しているという。

Magnumの紹介

CERNにおけるコンテナの使われ方

研究所らしく分析のためのバッチ処理がメインで、他にはデータ分析のためのJupyter NotebookのワークロードやTensorFlow/Kerasなどの機械学習のワークロードがOpenStack上で稼働しているという。さらにビッグデータ分析のSparkもKubernetes上で稼働していることを紹介し、ここでもいかにしてモダンなワークロードを実行するのかの実例となった。

SparkをKubernetes上で事項

その他にも多くのサブシステムが紹介されたが、ここではCERNによるコンテナサービスを実装する際の留意点を紹介しよう。

CERNによるコンテナサービスの要点

スライドでは、「ネットワークのデザインを決定すること」「ロードバランサーの構成」「プライベートなコンテナレジストリーを実装すること」「セルフサービスでユーザーが更新などを行えるように留意すること」などが挙げられていた。

最後に結論として、CERNにおいてもグループによって必要とするリソースは多種多様であること、Kubernetesが最終的にコンテナオーケストレーションのデフォルトとなったことなどを紹介して、セッションを終えた。

オンプレミス／クラウドに渡るAdobeの事例

次に紹介するAdobeのセッションは、Adobe Advertising CloudにおけるKubernetesのユースケースだ。AdobeもOpenStackをインフラストラクチャーとして利用し、その上でKubernetesのクラスターが稼働しているという概要である。

AdobeのOpenStack/Kubernetesユースケースの概要

特に4つのリージョンに渡って6つのOpenStackベースのデータセンター、それにAWSでもクラスターを運用しているという規模だ。AWSでは主に機械学習のワークロードを実行しているという。CERNに比べると規模は小さくなるが、ポイントはオンプレミスのOpenStackクラスターではオートスケーリングを用いない一方で、AWSではオートスケーリングを使っているという部分かもしれない。CERNの事例でもKubernetesのオートスケーリングには苦労しているようで、ここではパブリックスペースベンダーの強みがはっきりと出た部分だろう。

Adobeが使うKubernetesのためのツール

Kubernetesではデフォルトとなった感のあるHelmとともに、KubeCon@上海で紹介したKustomizeが入っていることに注目したい。

Kustomizeについては以下の記事を参考にして欲しい。

参考：KubeConChinaで見たKubernetesエコシステムを支えるツールたち

そしてオンプレミスのOpenStackについては、以下のスライドで解説が行われた。特徴的なのは「Kubernetesの永続的ボリュームは使わない」「オートスケーリングも使わない」「必要なものだけ実装する」といったところだろうか。

Adobe Advertising CloudのOpenStack概要

実行されるワークロード、アプリケーションをインフラストラクチャー側が理解することで、本当に必要なものはなにかを知ることができるという。特にKubernetesがベアメタル、仮想マシンの全ての利点を実現できるわけではないこと、そしてサービスディスカバリーや永続的ボリューム、ネットワーク構成などについても、よく考えて構成することなどが紹介された。

宣伝色が目立ったCiscoの事例セッション

最後にその他多くのユースケースの中から、Ciscoが主導で発表を行った楽天モバイルのセッションに簡単に触れてみよう。これは「Building Blocks of Rakuten Mobile Telco Cloud」と題されたものだ。楽天モバイルが構築しているという5Gネットワークの事例ということで、日本からの参加者もこのセッションに参加していたようだ。しかしその内容はCiscoの宣伝に終始しており、いわゆるテレコム向けのシステム構成を解説したものであった。セッションのプレゼンテーターに楽天のエンジニアがいない時点である程度は予想されたものだが、この程度の内容であればCiscoのセッションとして楽天の名前は出さないほうが参加者の期待を裏切らないという意味では良かったように思える。