DeNAにおけるOpenStack運用#1

DeNAでシステムインフラを運用しています小野です。
今回から3回に渡って、OpenStackの運用についてご紹介したいと思います。

OpenStackとは

OpenStack とは、いわゆるクラウド環境を構築/運用管理するためのOSS platformです。2010年にRack Space社とNASAのjoint projectとして始まり現在ではOpenStack Foundationが管理しています。

OpenStackは多数のOSSで構成されています。mysqlやrabbitmqなどお馴染みのOSSもbackendに使われていますが、OpenStack固有のOSSが主要コンポーネントになっています。例えばcomputing(vmやcontainer)の管理をするnova、ネットワークを管理するneutron、WebUIを管理するhorizonなどなどです。こちらでどういったコンポーネントがあるかを確認できます。

stackalytics.com というサイトでOpenStackの開発状況のactivityが見れるのですが、最新versionでは150社以上が開発に参加しているようで非常にglobal且つ活発であることがわかります。

半年毎に新versionがリリースされるスケジュールになっており、名称はアルファベット順に頭文字を使うルールになっています。Aから始まり最新versionではMまで進んでおりMitakaと呼ばれています。次期version(もう間もなくリリース予定なのですが)はMの次のNの頭文字を使いNuetonに決まっています。

この半年のリリーススケジュールに合わせ、半期毎にOpenStack summitというカンファレンスが開催されておりOpenStack界では一番のイベントとなっています。ここでは最新knowledgeの共有やuser事例紹介、次期version設計の為のdiscussionがopenに行われます。DeNAでも2014年11月に開催されたパリsummit以降参加するようになりました。

以前は完成度の低さが揶揄されていた時期もあったようですが、現在ではprivated cloudのみならずPublic cloudの基盤としても使われており、今やこの分野では完全なデファクトになっています。日本でも数年前からIT系企業を中心に利用する企業が増えています。

取組みの背景

何が課題だった？

DeNAでは以前からマイクロなレベルの効率化を追求していましたが長らく大きくは変わっていないところがあり、それはネットワーク管理の部分でした。この分野はサーバ管理と比べるとレガシー度が高く、市場環境として商用ハードウェアアプライアンス製品の独壇場になっていたことが主要因でなかなか効率化が進んでいませんでした。サーバ管理がよりオープンに進化しエコシステムが形成されていったのと比べると、違いは歴然です。その為自動化・効率化したくてもし難いという状況が続き、ネットワークのconfig変更が発生すると「依頼」という形で専任の担当者に作業してもらうということが続いていました。

またサーバがハードウェア故障等でお亡くなりになってしまった場合、代替機を構築する必要が発生します。いくらそれなりにprovisioningを自動化していようとも、creativeではない作業に時間を割くのは何となく気が乗らず不毛に感じるもので、こういうのを何とかしたいという考えがありました。

Publicクラウドの充実

一方でここ3〜5年ほどでPublicクラウドの品質/機能も著しく向上し、クラウドfirstが普通になってきました。あらゆることを最少人数且つ最速でやり易いこういった環境と比べると、オンプレミスの作業効率は見劣っています。それならばPublicクラウドに移行するという考えもあり得るわけですが、弊社の現時点での試算ではコストが割に合いません。CAPEXではなくOPEXで考えてもです。その為オンプレのまま作業効率を上げたいという方向での取組も重要と捉えていました。
※ とはいえ適材適所でPublicクラウドもかなり利用してはいます

高難度技術への取組み

また違う観点として、より広範な人材を育てるべくサーバー管理、ネットワーク管理の融合を進めたいという考えもありました。
どうしてもある程度組織的に大きくなると業務分担が進みます。現在のDeNAでもサーバ管理とネットワーク管理でグループが別れているのですが、以前は違っておりその方がスピード感がありました。
なのでそれに近付けたいという思いと、OpenStackの運用は非常に広範囲な技術知識が要求されますので、個々人にとってもより広範な技術領域の習得に繋がる機会を創出することはプラスであるという考えからも、この両者の管理を融合してきたいという考えを持っていました。

ちなみにDeNAのインフラ部門では以前からアプリケーションレイヤーも含めた全方位的な管理スタイルをとっています。アプリケーションがトラブルを起こすことは極めて多いので、one stopで障害対応等する為にはアプリケーションのソースを理解しカバーすることが重要と考えています。

以前のOpenStackは単にサーバーをサーブするだけの仕組みにしかみえず、その割にバックエンドの構成が複雑なことと、そういう範囲であれば既に内製開発した同機能を提供するtoolを持っていたことから利用メリットを感じませんでした。
それが近年この分野でOpenStackがデファクトの位置を得始めるとOpenStackとのintegrationをうたう製品やソフトウェアが増え始め、ネットワーク管理とのintegrationも現実的になってきました。その為最初に挙げたような課題解決の為の基盤の中心としてOpenStackの導入を本格検討し始めました。
そしてDeNAでも2016年3月よりOpenStackを使った新世代のインフラ基盤の稼働を開始しています。
今年年初の弊社のTechカンファレンスで発表させて頂いた構想で、ほぼこれを実現したものになります。 ※ 但し最後の方にあるOSコンテナ、S(M)R-IOVなどはまだこれからのロードマップになっています。

SDX integration

SDXとは？

DeNAではOpenStackを導入するにあたって、SDN(Software Defined Network)とSDS(Software Defined Storage)を当初から導入しています。Software Defined Xというのは、XをSoftware的に扱うという意味です。ネットワークもストレージも従来はハードウェアアプライアンスが支配的で管理操作のためのAPIというのは非常に貧弱でしたが、そういったものにAPIをしっかり持たせてあらゆる操作をAPI経由で行う≒ソフトウェア的に扱えるようにしよう、というものでよく使われる表現です。

SDN(Software Defined Network)

SDNにはBigSwitch Networks社のBigCloudFabric(以下BCF)という製品を使っています。

BCFの場合各スイッチを管理するcontrollerが存在し、configuration変更等はcontrollerを介して各スイッチに反映されます。
なので何かを変更したい、情報を取得したいという場合controllerに投げればあとはよしなにやってくれるというわけです。
こう出来ると、サーバを起動する前にネットワーク(VRF/VLAN)の作成をしそこに配置する、なんて連携も簡単に出来ます。awsでvpcを作成しsecurity groupでacl管理するような事ができるわけです。

*OpenStack画面上からのネットワーク作成がスイッチ側に伝わる様子
プロジェクトの作成はVRFの作成にあたります*

スイッチ上ではSwitch Light OSというLinux(Debian)ベースのネットワークOSが動いておりcontrollerからの指示を受け自身の設定変更などを行っています。このSwitch Light OSもBigSwitch社が提供していますが、スイッチそのものはDELL社の製品を使っています。
このようにハードウェアとOSが分かれて組合せ出来るのはサーバ管理の世界では当たり前ですが、ネットワーク機器においてはこういうことも長らくできなかったわけです。

BCFの機能上の特徴としてはunderlayネットワークをサポートしてるというのがあります。underlayネットワークの説明をするには、その逆のoverlayネットワークの説明をした方がわかりやすいです。

overlayネットワークとは、ネットワークアドレスが重複しても動作できるネットワークのことです。例えば172.16.0.1/24というネットワークをいくつ作っても動作出来るようなネットワークです。Publicクラウドではこれが当たり前に出来ないと困ります。利用者側で自由にアドレス設計出来ないと使い難くてしょうがないですからね。

overlayネットワークはvxlanやgreというプロトコルを使うことで実現します。実は現在世にあるSDN製品は殆どが何故かoverlayを前提にしています。
underlayはその逆で、ネットワークアドレスの重複を認めないネットワークです。従来型のネットワークと言え、オンプレミスの環境ではこちらが普通です。

overlayネットワークは非常に柔軟性は高いのですが、それを実現する為のprotocolが重く性能面でのデメリットがあるのと、セグメントを跨って通信するにはNATが必要になるという制約も発生します。オンプレミス環境ではIP managementを自分達で出来ますのでoverlayの必要性はそもそも低く、余計なプロトコル層が増えることで負荷や障害の難易度をいたずらに上げたくはないというのもあり、DeNAではunderlayネットワークでの運用を優先しBCFを採用しています。

SDS(Software Defined Storage)

そしてSDSとしては Ceph を使っています。

Cephは分散ストレージソフトウェアです。カリフォルニア大学サンタクルーズ校で開発された後2006年にOSS化されました。現在ではRedHat社がメンテナンスをしており商用サポートも行っています。
blockストレージとしてもobjectストレージとしてもfileストレージとしても使える代物なのですが、DeNAでは主にblockストレージとして使っています。awsで言えばEBSにあたる使い方になります。

CephはOpenStackのBlock Strage Interfaceであるcinderに対応してるので、cinderのapi callでcephに自由にボリュームを作成することが出来ます。

DeNAではcephをguestの起動diskとして使っています。こうすることで再構築のような作業をほぼ0にすることが出来ます。仮にguestが稼働しているhostサーバが死んでもすぐ別のhostサーバで起動すればいいだけなので。

cephによるstorage poolからguestのimageを再読込して別のhostサーバで起動する様子
cephはデータを3重化して保持しておりこのstorage pool自体が壊れてしまうことはない想定

また、livemigrationも可能になりハードの不調が疑われる筐体からguestを逃がす事が簡易に出来るなど、運用面でかなりのメリットを得ています。

なお、ハードウェア構成としてはいわゆるハイパーコンバージドな、compute nodeとstorage nodeを一体化した構成にしており、hypervisorはKVMを使っています。

最後に

SDNやSDSで実現してることはPublicクラウドでは当たり前のことですが、それがオンプレの環境でも出来るというのをイメージ頂けたかと思います。
OpenStackを使うならSDN、SDSもしっかり含めインフラ全体をintegrationし、単なるvmをサーブするだけではない環境として高い運用効率を得ることがポイントではないかと思います。

PublicクラウドはこういったIaaSだけではなくPaaSも充実してるものもありますが、OpenStackもPaaS関連のprojectが多々あるので、今後はそこも似てくるかもしれません。

OpenStackはOSSですが、各ベンダーが商用サポートを付けているdistrubusion版が多数存在します。CentOSに対するRedHat Enterpriseのようなものです。
そういうものが存在するというのは、裏を返せば運用していくのはそれなりの難易度が必要ということで、そこそこ骨が折れるのが正直なところです。
次回以降はSDN、SDS周りのより詳細な部分をお伝えしたいと思います。
本格運用を開始してまだ半年程度ではありますが、結構いろいろな格闘がありました。