最新ユーザー事例探求 第43回

OpenStackを中心とした新インフラを構築、決め手は「アンダーレイネットワーク」

DeNAがベアメタルSDN「Big Cloud Fabric」を導入した背景を聞く

　モバイルゲームの「Mobage」からオンラインショッピング、オークション、キュレーションメディア、最近ではヘルスケア（遺伝子検査）やオートモーティブ（カーシェア、無人運転バス）といった新規事業まで、幅広いインターネットサービスを展開するDeNA（ディー・エヌ・エー）。そのサービスインフラを支えるエンジニア集団が、同社のIT基盤部だ。

　DeNAでは今年、OpenStackを中心としてSDN（Software-Defined Network）、SDS（Software-Defined Storage）、LBaaS（Load Balanccer-as-a-Service）などの機能を統合した、新しいITインフラ／プライベートクラウドの利用を開始した。SDN基盤には、ビッグスイッチネットワークス（Big Switch Networks）の「Big Cloud Fabric（BCF）」を採用している。

　新インフラ構築の背景、そしてBCFを採用した理由について、DeNA システム本部 IT基盤部部長の小野篤司氏に話を聞いた。　

DeNA システム本部 IT基盤部 部長の小野篤司氏

7.2営業日ごとに1案件をリリース、省力化が必須のインフラ運用現場

　「33」。この数字は昨年1年間に、小野氏率いるDeNA IT基盤部が携わった新規プロジェクトの数だ。月平均で2.75案件、7.2営業日ごとに1案件がリリースされるというスピード感である。冒頭でも触れたとおり、DeNAのビジネスドメインは広範にわたる。新規事業、新規サービスへの進出も積極的だ。

「新しいことに挑戦し続けること」がDeNAのDNAだ（同社サイトより）

　その中で、ITインフラの果たす役割は当然大きく、インフラにはビジネス変化のスピードに対応できるだけの俊敏さが求められる。現在、DeNAが展開するインターネットサービスの大半は、オンプレミスのITインフラを使って提供されている。小野氏によると、オンプレミスで運用するサーバー台数は4000台弱、インターネットトラフィックは平均で12～13Gbps程度に達する規模だという。

　こうしたDeNAのITインフラ全体を設計、運用しているのがIT基盤部の役割だ。現在は42名のエンジニアが所属しており、大きく3つのグループで構成されている。サーバーエンジニアが10の事業ドメインのインフラをカバーする「第1グループ」と「第2グループ」、そしてネットワーク部分の運用管理を担当する「ネットワークグループ」だ（ほかに社内システムの担当チームもある）。

　IT基盤部の業務の実情について、小野氏は「DeepなものはDeepに、一方でEasyなものはEasyに回さないとやっていけない」と語る。人員は限られているが、新規プロジェクトは次々に立ち上がる。より高品質なサービスを提供するためには、“Easyな業務”にかかる労力を徹底的に省力化しなければならない。そのため、これまでも物理サーバーのプロビジョニングツールを自社開発したり、「Chef」を採用したりすることで、インフラ構築や運用管理のコード化と自動化を少しずつ進めてきた。

「サーバーとネットワークの業務分担の壁をなくしてしまおう」

　ITインフラの俊敏さを高めていくうえで、小野氏が大きな課題を感じていたのが、サーバーエンジニアとネットワークエンジニアの業務分担だという。「サーバーエンジニアからネットワークエンジニアに『依頼』が行くという仕組み、これを何とかしたいと考えていました」。

　ネットワークの構築や設定、運用管理の作業は、ネットワークグループに所属するエンジニアの専任業務だった。そのため、サーバーエンジニアやグループ会社のエンジニアは、ネットワークグループにその作業を「依頼」する形となる。しかし、ネットワークグループには6名のエンジニアしかおらず、しかも主業務である運用管理が最優先のため、構築や設定変更の作業実施までにはどうしても日数がかかっていた。

　「当初は『依頼から作業実施までには5営業日かかる』という内部ルールがあったくらいです。さすがにそれは遅すぎると撤廃してもらいましたが、作業依頼の件数が多いときは、やはり何日か待たなければなりません。日数がかかると、依頼する側も依頼した作業を忘れてしまうことがあり、決して効率の良い仕組みではありませんでした」

　そこで小野氏は、IT基盤部として「アプリ／サーバー／ネットワークをワンストップで対応できる人材を増やす」という目標を立てた。IT基盤部はあくまでもITインフラ周りを担当する部門だが、実はこれまでも、トラブル原因究明の際にはアプリケーションレイヤーにかなり踏み込んだ調査も行ってきた経緯がある。「それならば、サーバーとネットワークの業務分担の壁もなくしてしまおう」と考えたのだ。

　もっとも、ネットワークの専門的なスキルは一朝一夕に身につくわけではない。だが、近年技術進化の著しいSDNソリューションを導入すれば、ネットワーク構築や設定変更の基本的な作業は半自動化され、サーバーエンジニア自身で安全かつ迅速に実行できるようになるはずだ。

　「もちろん、高度な作業は引き続きネットワークエンジニアが行うのですが、簡単な作業をサーバーエンジニア自身で実施するようにして『依頼』件数を減らせば、ネットワークエンジニアもよりコア業務に集中できます。そのために、SDNやLBaaSが活用できるのではないかと考えました」

ネットワークとストレージの統合運用基盤としてOpenStackを選択

　小野氏らIT基盤部では、「サーバーとNWの運用統合」と「仮想化基盤の運用改善」という2つのテーマを掲げ、新しいITインフラ構築に取り組むことにした。この新インフラは、OpenStack（IaaS／オーケストレーター）を中心に据え、「Ceph」（SDS）、F5ネットワークスの「BIG-IP」（LBaaS）、そしてBig Switch Networksの「Big Cloud Fabric（BCF）」（SDN）の各コンポーネントが選択されている。

DeNAの新インフラ構成図（概要）

　OpenStackについては、2013年ごろから注目していたという。ただ、当時はまだプロダクトとしての成熟度が低く、使える機能も「単に仮想マシンをサーブする程度」（小野氏）と貧弱だったため、採用は見送っていた。「複雑な仕組みのOpenStackを入れても、既存の自社開発ツールと同じことしかできないのなら必要ありませんから」。

　本格的に導入を検討し始めたのは、昨年（2015年）の夏だった。OpenStackの機能が徐々に拡充され、「OpenStackサポート」をうたう商用SDN／SDSプロダクトも増えてきたことで、導入の機運が一気に高まったという。

　「ネットワーク（SDN）とストレージ（SDS）の運用をインテグレーションする基盤としてOpenStackを使うといいのでは、と考えるようになり、そこから本格的な情報収集と製品検討に入りました」

　ここで小野氏が強調するのは、新インフラは必ずしも“OpenStackありき”ではなかったという点だ。前述したテーマから新インフラの要件を考えると、SDNやSDS、LBaaSのコンポーネントを取り入れる必要があり、その全体をオーケストレーションする仕組みも求められる。「これらは、全体がかみ合ってこそ初めて意味を持つもの。OpenStackだけが先に決まっていたわけではありません」。

　その後、昨年11月から12月にかけてBCFやCephの技術検証を実施。今年1月から2月には既存の運用体制の見直しや既存管理システムとの統合実装を行い、3月に一部社内システムを新インフラに移行。3月中旬にカットオーバーした。今後、様子を見ながら徐々に移行を進めていく方針だ。

　「新インフラへのマイグレーションは、まだ途中段階です。社内システムのような軽いシステムならば問題ないですが、インスタンス数などのボリュームが大きなサービスになると、想定外の問題も生じるだろうと思っています。『すべてを新インフラに持っていく』と判断しているわけではなく、移行するシステムの規模を徐々に拡大しながら様子を見ている段階ですね。もしも解決できない問題が発生すれば、どこかで移行を止めるという選択肢も残してあります」