クラウド移行の「運用管理者にとっての価値」とは何か。ひいてはビジネスにとっての価値とは何か――オンプレミスからクラウドへシステム基盤の全面移行を進めているDeNAに聞いた。
1999年に創業したディー・エヌ・エー(以下、DeNA)は、2018年の現在に至るまでの約20年の間に、オンプレミスとクラウドを使い分け、低コストで高効率なシステム基盤を構築、運用している。
数千台規模のサーバをオンプレミスの物理サーバ、KVM仮想化基盤、OpenStackによるプライベートクラウド基盤で稼働させる一方、それと同規模のコンピューティングリソースをパブリッククラウド(以下、「クラウド」はパブリッククラウドと同義)でも利用し、ゲームからeコマース、オートモーティブ、ヘルスケア、スポーツ、AIなど多岐にわたるDeNAの事業とサービスを支えている。
そのDeNAが2018年に、インフラ基盤の運用を大刷新する全社プロジェクトをスタートさせた。2018年度からの3カ年計画で、オンプレミスで運用する全てのシステム基盤を全面的にクラウドに移行するプロジェクトだ。
1年目の2018年度は、全面移行に備えた準備と移行に向けたコスト削減がテーマで目下推進中だ。2年目の2019年度は実際の移行作業に入り、ここで基本的に全てのシステムをクウラド化する予定だ。そして3年目の2020年度は、レガシーシステムを中心に2年目までの作業でクラウドに移行し切れなかったシステムの最終移行を図っていく。
ITベンダーにも匹敵するほどのシステム構築運用ノウハウを持ちながら、なぜDeNAは、オンプレミスを捨てフルクラウドに移行することを選択したのか。そうした取り組みを進める上で、運用管理者が考えるべきことは何か。運用管理者にとってのクラウド移行の価値とは何か。システム本部 IT基盤部 部長の金子俊一氏に聞いた。
金子氏は、新卒で入社した専門商社でエンジニアとして社内プロジェクトや社外SI案件で実績を積み、2009年にDeNAに入社。EC事業のシステム刷新、「Y!Mobage」の立ち上げに携わった後、インフラエンジニアに転身し、IT基盤部のマネジャーを経て、2018年4月から部長を務めている。
IT基盤部は、DeNAが展開する多岐にわたるサービスのインフラ基盤を横断的に設計、管理する部署だ。開発部隊は、ゲームやeコマース、エンターテインメントといった各事業部に所属しており、IT基盤部がそれらのサービスに必要なインフラを一括して提供する体制だ。
──一時は、オンプレミスの物理/仮想サーバ、計数千台を10人程度で管理していたこともあるそうですが、現在のシステム環境、組織体制を教えてください。
サーバは数千台で大きく変わりませんが、提供するサービスの要件に合わせてクラウドも活用するようになりました。クラウドはオンプレミスと同程度の規模です。顧客向けサービスの稼働環境がポリュームゾーンで、SaaSやPaaSを利用していない社内システムもあります。
IT基盤部の人数は60人。顧客向けサービスの運用を担当するチームが26人、社内システムが5人、クラウドとオンプレミスのネットワーク管理が7人、Hadoopを中心とした分散データ環境のチームが14人、購買や計上を担当しているチームが4人、それにR&D的な動きやヘルプなど遊撃的に動く3人がいます。人数は今が最大規模ですね。
──運用を効率化してオンプレミスの効果を最大限に引き出すために、どのような工夫を行っているのでしょうか?
インターネットのサービスを中心に事業を行うDeNAにとってシステム基盤は重要な経営資源の一つです。信頼性や可用性といった品質の面では、オンプレミスで最高のものを常に追求しています。コストについても1円でも安くしなければならない。極論すると「1件のアラートも許さず、1件のダウンも許さない」という品質を少しでも安いコストで実現することを追い求めています。
例えば、CPUをムダなく使い切るためにMySQLのインスタンスを1つのベアメタルサーバの中で複数稼働させたり、可用性を高めるために、サーバが故障したらそれを検知して自動的にサービスの利用から外してその間の数秒間におけるサービスへの影響を極小化したりなどです。
コストについては、2012年頃にインフラを大規模に入れ替えて償却を終えていることもあり、2018年現在、ラックの利用料くらいしかかかっていません。パプリッククラウドと比較すると圧倒的なコストメリットがあり、これまでのノウハウがあるので信頼性も極めて高いという状況です。
──では、なぜここにきてクラウドへの全面移行なのでしょうか?
これまではサービスの特性に合わせてインフラを提供してきました。「最適なインフラが何か」をまず考え、それを実現する手段としてクラウドだったり、オンプレミスだったりを選択できるようにしてきました。事業にスピードや柔軟性が求められないなら、安いオンプレミスを使えばいい。逆に、世界展開する上でスピードや柔軟性が必要なら、海外のデータセンターを借りて機器を購入して……というわけにはいかないので、クラウドを使うという具合です。
ただ今までは、全体を見て最適解を選んできたわけではなく部分最適のアプローチと言えました。今後は、世界市場向けにゲーム事業の展開や、オートモーティブ、ヘルスケア、AIなど新しい取り組みに合わせたシステム基盤の提供が求められます。システム基盤に求められる要件も多岐にわたり、セキュリティを確保することや事業のスピード感にのっとった基盤を用意することが必要です。
そうなると、少ない人数で多角化したシステムを常に高品質かつ安いコストで運用維持し続けるのは難しくなります。むしろシステム運用がリスクになりかねない。そのため、特定のシステム基盤へと寄せていくことで、リスクを避け品質とコストを維持し続けようと考えました。その手段がクラウドへの全面移行だったということです。
──ただDeNAの場合、クラウドに移行するとシステムの可用性も落ちるし、コストも高くなるのではないでしょうか?
「なぜ、このタイミングなのか」にもつながりますが、今回、クラウドに全面移行しようと決めた背景には、オンプレミスと同等のものがクラウド上で構築できるというメドが立ったことがあります。コスト面でも品質の面でもオンプレミスと遜色ないレベルまで見積もれるようになったのです。
そうすると、必要なときにリソースを調達できたり、世界中でインスタンスを立ち上げたりといったクラウドそのもののメリットが生きてきます。「DeNAの事業運営に必要なものが全てクラウドでまかなえる」という判断がクラウドへの全面移行につながったのです。
──それはクラウドサービスの機能や品質がDeNAの求める水準に追い付いたということですか?
いいえ、実際には、クラウドの品質という点では劇的に変わっていないと思います。インスタンスの利用料も少しずつ下がってきていますが、劇的に下がったわけではありません。
ただ、この3年くらい大規模にクラウドを使ってきて(一定のサービス品質を担保しながら)『こういう工夫をすれば、これだけ安くできる』『こういう機能を使えば、やりたいことがスピーディーにできる』というポイントをつかんできました。それを踏まえて、オンプレミスと遜色ないレベルにまでコストを下げて実施できる算段がついたということです。
もちろん、サーバの大規模リプレース時期とも重なったこともあります。この5〜6年はリプレースしておらず、部品の故障率も上ってくる頃なので、タイミングとしてもちょうどよかったといえます。
──クラウドを使いたいという声は、開発現場から寄せられたものなのでしょうか?
それもあります。開発側からは「もっと早くクラウドにしてほしかった」という声は多くありましたね。ただ、開発者は「クラウドか、オンプレミスか」というより「とにかくコードを書きたい。管理などの面倒なことは考えたくない」のが本音です。全面的にクラウドに切り替えていこうと判断したのは運用側です。
──開発と運用の距離感を教えてください。
昔からそうなのですが、DeNAのエンジニアは「サービスを安定的に低コストで提供するために全てやる」という役割意識を持っています。今でこそSREという役割が国内でも認知されてきましたが、昔からSREのような役割意識なので、開発か運用かという分け方もあまり意識されてこなかった。だからよく、新しくDeNAに入社してきた人は「ここまでやるんですか」と驚くことも多いですよ。
例えば、パフォーマンスが悪くなったので開発側が書いたコードをたどってSQLのクエリをチューニングしたり、ネットワークを監視して「性能劣化がないか」を確認して定期的にミーティングを開いて相談したり。「これってDBAやネットワーク管理者の仕事じゃないんですか」と言うと「いやいやここまでがインフラエンジニアの仕事だよ」と返すようなやりとりはよくあります。DeNAでは昔から開発と運用の仕事は切り離されることなくサービスを提供する体制でした。インフラエンジニアもコードを書けて当然という文化があります。
──クラウドに全面移行することに対して、経営陣はどう反応したのでしょうか?
経営陣としてまず考えるのは「なぜ今、安定して安く動いているオンプレミスにあるシステム基盤までクラウドに移行する必要があるのか」ではないでしょうか。
実際、当初はそうした声もありましたし、そこはきちんとコミュニケーションをとって、「なぜクラウドに全面移行する必要があるのか」「メリットがこれだけあり、品質を維持できる」といったことを訴えていきました。
──現場発信で経営陣を巻き込んでいったのですね。
3カ年計画ともなると、いろいろなことが障害になります。人とのコミュニケーションやプロセスをしっかりと踏んで進めていくことは大事です。最終的にはボードメンバーの承認を得て全社方針にすることで、そうした障害を乗り越えて、皆が同じ方向を向いて取り組みを進めていくことができるようになりました。現場だけで対応を考えていると限界もあるので、コミュニケーションや調整は3カ年計画を立てる前にかなり綿密にやりましたね。
Copyright © ITmedia, Inc. All Rights Reserved.