Open Infrastructure Summitで紹介されたCERNやAdobeの事例
OpenStackは、その出自がベンダー主導ではなくユーザーであるRackspaceとNASAから始まったことは以前の記事でも紹介した。そしてOpenStackをホストする組織であるOpenStack Foundationも、デベロッパーとユーザーとが互いに出会う場所としてOpenStack Summitを運営していたことは知られるべきポイントだろう。最近のサミットではだいぶベンダー色が濃くなった感覚もあるが、それでもユースケースをベンダーではなくユーザー自身から紹介されることで、よりリアルな情報が共有されることが最大の良さだろう。
今回の記事では、OpenStackの事例としてはおなじみとも言えるCERNの事例、そして少人数で巨大なクラウドを運用していることでこれも数年前のサミットで紹介されたAdobeのセッションを紹介する。
「故郷」CERNでのOpenStackの状況
CERNは、スイスとフランスの国境付近に存在する素粒子物理学の世界最大の研究施設である。そのため利用するOpenStackの規模もかなりのもので、2013年というかなり初期からのヘビーユーザーだ。コア数で29万コア、900テラバイトのメモリー、9ペタバイトのストレージを3600名以上のユーザーが利用しているという。
CERNはかなり初期からのOpenStackのユーザーで、Grizzlyリリースから利用しているということは2013年から最新のバージョンまで使い続けているということになる。
この年表で興味深いのは、LibertyまではテレメトリーのプロジェクトであるCeilometerが使われていたがそれ以降は消されている点だ。CERNのユースケースとしては、Ceilometerは使われなくなったということかもしれない。
CERNのワークロードは主に仮想マシンベースであったため、OpenStackとよく適合したと記憶しているが、CERNにおいてもコンテナの利用は拡がっているようで、RockyからMagnumというOpenStackからKubernetesなどのコンテナオーケストレーションを操作するAPIを提供する。500以上のクラスター、1700以上のノードに375のKubernetes、140のDocker Swarmが稼働しているという。
研究所らしく分析のためのバッチ処理がメインで、他にはデータ分析のためのJupyter NotebookのワークロードやTensorFlow/Kerasなどの機械学習のワークロードがOpenStack上で稼働しているという。さらにビッグデータ分析のSparkもKubernetes上で稼働していることを紹介し、ここでもいかにしてモダンなワークロードを実行するのかの実例となった。
その他にも多くのサブシステムが紹介されたが、ここではCERNによるコンテナサービスを実装する際の留意点を紹介しよう。
スライドでは、「ネットワークのデザインを決定すること」「ロードバランサーの構成」「プライベートなコンテナレジストリーを実装すること」「セルフサービスでユーザーが更新などを行えるように留意すること」などが挙げられていた。
最後に結論として、CERNにおいてもグループによって必要とするリソースは多種多様であること、Kubernetesが最終的にコンテナオーケストレーションのデフォルトとなったことなどを紹介して、セッションを終えた。
オンプレミス/クラウドに渡るAdobeの事例
次に紹介するAdobeのセッションは、Adobe Advertising CloudにおけるKubernetesのユースケースだ。AdobeもOpenStackをインフラストラクチャーとして利用し、その上でKubernetesのクラスターが稼働しているという概要である。
特に4つのリージョンに渡って6つのOpenStackベースのデータセンター、それにAWSでもクラスターを運用しているという規模だ。AWSでは主に機械学習のワークロードを実行しているという。CERNに比べると規模は小さくなるが、ポイントはオンプレミスのOpenStackクラスターではオートスケーリングを用いない一方で、AWSではオートスケーリングを使っているという部分かもしれない。CERNの事例でもKubernetesのオートスケーリングには苦労しているようで、ここではパブリックスペースベンダーの強みがはっきりと出た部分だろう。
Kubernetesではデフォルトとなった感のあるHelmとともに、KubeCon@上海で紹介したKustomizeが入っていることに注目したい。
Kustomizeについては以下の記事を参考にして欲しい。
参考:KubeConChinaで見たKubernetesエコシステムを支えるツールたち
そしてオンプレミスのOpenStackについては、以下のスライドで解説が行われた。特徴的なのは「Kubernetesの永続的ボリュームは使わない」「オートスケーリングも使わない」「必要なものだけ実装する」といったところだろうか。
実行されるワークロード、アプリケーションをインフラストラクチャー側が理解することで、本当に必要なものはなにかを知ることができるという。特にKubernetesがベアメタル、仮想マシンの全ての利点を実現できるわけではないこと、そしてサービスディスカバリーや永続的ボリューム、ネットワーク構成などについても、よく考えて構成することなどが紹介された。
宣伝色が目立ったCiscoの事例セッション
最後にその他多くのユースケースの中から、Ciscoが主導で発表を行った楽天モバイルのセッションに簡単に触れてみよう。これは「Building Blocks of Rakuten Mobile Telco Cloud」と題されたものだ。楽天モバイルが構築しているという5Gネットワークの事例ということで、日本からの参加者もこのセッションに参加していたようだ。しかしその内容はCiscoの宣伝に終始しており、いわゆるテレコム向けのシステム構成を解説したものであった。セッションのプレゼンテーターに楽天のエンジニアがいない時点である程度は予想されたものだが、この程度の内容であればCiscoのセッションとして楽天の名前は出さないほうが参加者の期待を裏切らないという意味では良かったように思える。
もちろん全てのカンファレンスの全ての事例セッションで深い情報や発見、知見が得られるわけではないのは当たり前だ。だが筆者は、このようなセッションが行われていることで、OpenStackが若干モメンタムを失っていることように感じた。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- OpenStackDays Tokyo 2017、コンテナへの応用が目立つOpenStackの現状
- KubeCon Europeでサービスメッシュの標準化を目指すSMIを発表。Istioの動向にも注目
- Elastic、Elasticsearchの新機能、Kubernetesの可視化を発表
- OpenStack Summit Sydneyに見るOpenStackの今そしてこれから
- OpenStack Summit 2018 Vancouver開催 リアルな情報交換の場となったイベント
- KubeCon Europe 2024開催。前日に開催されたAIに特化したミニカンファレンスを紹介
- OpenStack Days Tokyo 2017 関係者が語る本音ベースの座談会
- KubeCon North America:座談会で見えてきた退屈なKubernetesの次の世界
- NutanixのアーキテクトがNutanixの未来を語る
- NetAppがクラウドネイティブなワークロードにも対応したハイパーコンバージドインフラの新製品を紹介