今後のモノづくりには「インフラ・セキュリティ・品質管理がより一層ビジネスに踏み込んだ動きを取ることが重要になってくる」と考えるDeNA執行役員システム本部長のnekokakこと、小林 篤（こばやし あつし）。
そんなnekokakがDeNAのシステム本部各部長と「各領域からビジネスに踏みこむモノづくり」について語り合う『モノづくり対談』第2回目をお送りします。
テーマは「オンプレミスに強みを持つDeNAはなぜクラウド化全面移行を決めたのか」。
オンプレの品質コスト世界一を自負するDeNAに、全面クラウド化というドラスティックな意思決定をもたらしたIT基盤部部長・金子 俊一（かねこ しゅんいち）とプロジェクトの全貌を語り合いました。
「クラウド全面移行を決めた理由」「コストの大幅増への対処法」「経営層の意思決定に担当者工数などの課題」など、気になるクラウド化の裏側を解き明かします！
※この記事の続編はモノづくり対談VOL.5『クラウドへ全面移行するDeNA。現場リーダー2人が3カ年計画の進捗と展望を語る』で読めます。
株式会社ディー・エヌ・エーシステム本部 本部長
小林 篤（こばやし あつし）＠nekokak
法学部法律学科からエンジニアへ転身し、2011年にDeNAに入社。Mobageおよび協業プラットフォームの大規模システム開発、オートモーティブ事業本部の開発責任者を歴任。2018年より執行役員としてDeNAのエンジニアリングの統括を務める。社内では通称で「ネコカクさん」「ネコさん」と呼ばれている。
株式会社ディー・エヌ・エーシステム本部IT基盤部 部長
金子 俊一（かねこ しゅんいち）
新卒で入社した専門商社でエンジニアとして社内プロジェクトや社外SI案件で実績を積み、2009年にDeNA入社。EC事業のシステム刷新、Y!Mobageの立ち上げに携わった後、インフラエンジニアに転身。DeNAのシステムの基盤を横断して設計・管理するIT基盤部でマネージャーを経て2018年４月よりIT基盤部部長。オンプレミスからクラウドへの全面移行をドラスティックに推進中。
世界最高レベルにコストを圧縮したインフラを捨てる
nekokak
DeNAの「モノづくり」を解き明かしていく対談シリーズ第2回目。
第1回目は品質管理部長の三村さんと「DeNAが目指していくデライト品質」についてお話ししました。
お互い、これからの品質管理に課題を感じていたこともあって大変盛り上がりました。世界の潮流から言うと今後避けられないトレンドであり、品質管理分野に関わる人の今後の仕事を根本的に変えうる話ですからね。
そして今日は、IT基盤部を率いる金子さん！ テーマは「オンプレ（※1）に強みを持つDeNAはなぜクラウド全面移行を決めたのか」。これは壮大な一大プロジェクトですよね。
※1……オンプレミス。企業などが情報システムの設備を自社で保有し、自社で運用すること。
金子
ええ、本当に。今年の2018年6月末に全社方針として経営会議で承認がおりましたが、会社としても大きな決断をしたと思います。
nekokak
DeNAは創業時からオンプレ実績があって高品質・低コストの大規模なインフラをつくりあげてきました。今回は、それを全面クラウドに移行するという劇的な意思決定となりましたよね。
金子
そう思います。DeNAのオンプレは世界最高レベルと言ってもいいほど、極限まで圧縮されたコストを実現していますから。
nekokak
その極限まで圧縮されたコスト感が伝わる具体的な数値感って言えますかね？
金子
大丈夫ですよ。オンプレのサーバーは現在約3,000台あり、運用にあたっている人員は、実質工数ベースでは12〜13名程度といったところです。
運用にあたっている人数は25名ですが同じメンバーがパブリッククラウド環境も管理しているので。
同業他社のお話を聞いていると、DeNAほど多角的に大規模トラフィックを持つサービスを展開していれば一般的には少なくともその倍の台数と人員数が必要なようです。
nekokak
かなり圧縮された体制を実現していますよね。
金子
DeNAは、文化としてコスト意識を強く持っているからでしょうね。
私の前任者、前々任者の時代からそうです。創業時の「1円でもコストを削らないと明日の倒産につながる」というベンチャーならではの考え方が根付いている。IT基盤部の文化でもあります。
サービスが成長して、最大トラフィックがかなり上がりそうだ、となっても安易にサーバー追加の判断はしないんですよ。必ず「1台あたりの性能を使い切れているか？」とまず確認します。
nekokak
1台あたりの性能を使い切る、とは？
金子
ユーザーが集中してアクセスが跳ね上がっても「技術でなんとかできないか」をまず考える。これもDeNAのIT基盤部の文化です。
DeNAは「本当に」必要な台数しかサーバーをつくりません。サーバーを余裕持って並べておけばアクセスが集中しても気にすることはないけれど、それはどの会社でもできることですしね。
nekokak
「そんなにコストに厳しいのか」とDeNAに中途入社した人は驚きません？
金子
確かに驚いているみたいですけど、コスト意識に対してというより技術力への驚きですね。これほど自分でチューニングできると思っていなかった、と。
「このオプションを使うとこれだけ負荷が下がるなんて」と同業他社から来たインフラエンジニアはよく言います。
そうして驚いていた人も少し経つと、同じことやもっとすごいことができるようになるんですよ。方法を知らなかっただけなので。そもそも高い技術力を持っている方に入社してもらっていますしね。
nekokak
チューニングの方法を知ることで、サーバーもそれぞれのメンバーのポテンシャルもより発揮される、と。
金子
そうです。チューニング次第でサーバーが発揮できる性能は10倍は変わると思いますね。
nekokak
10倍ってすごいですよね。
金子
たとえば、データベースのMySQL。I/O（※2）が関連するパラメータを適切に設定したり、たった1つ筋の悪いクエリを見直したりするだけで本当にそれほどか、それ以上に性能が変わってくるんです。
※2……Input/Output。「入出力」の意味。
nekokak
なるほど。
金子
それから、メンバーのポテンシャル最大化で言うと、今までDeNAが創業時から蓄積してきたノウハウを学べますし、著名なperlエンジニアや元linux kernelの開発をしていたメンバーなど、在籍している特定分野の第1人者たちにも刺激を受けるようですね。
過去にもすごい技術力を持った人たちがDeNAに在籍していましたが、彼らのチューニングに対する考え方はぜんぶ残っています。
たとえばDeNAではMySQLを10年以上使ってきていますが，蓄積されたノウハウとその運用品質は間違いなく世界レベルだと自負しています。
なので、入社間もなくであっても先輩の蓄積も自分のノウハウにして、実践できるんですよね。
コスト増を3倍から1.1倍に圧縮した試算とは
nekokak
では、そんなオンプレに強みを持つDeNAはなぜ全面クラウド化を決めたのか、これが気になるところですね。
金子
前提として、DeNAのインフラは部分最適にはなっていたんだけれど、全体として非効率な状態になっていたんですよね。それで全体最適を検討した結果、全面クラウド化を決めました。
それまでは基本的にオンプレで運用していたものの、DeNAの事業展開上どうしてもクラウドを使ったほうが効率がいいケースも出てきて、オンプレとクラウドの二重運用になっていたんです。
nekokak
部分的にはクラウドのほうが圧倒的に良いケースがありますよね。
金子
ええ、たとえば世界に向けてゲームをリリースするときなんかそうですよね。オンプレのやり方だとまず海外のデータセンターを選定して、サーバーを購入し、納品してもらい、希望どおりに設定する、という手順ですが、煩雑ですし時間がかかります。それを全世界でやるのはほぼ不可能だ、と。
DeNAの事業スピードで世界向けにサービスを出すとなると、クラウドしか選択肢はありません。実際、DeNAは2015年から世界で展開する大きな事業を開始して、そこでは大規模にクラウドを使っています。
nekokak
今年4月に僕がシステム本部の本部長になって、金子さんがIT基盤部の部長になったときに、DeNAの技術戦略として中期経営計画をちゃんとつくろうよって話をしたんですよね。
オンプレとクラウドを並走させるのが、果たしていいのか。クラウドで行くんだったら、いろいろネックになっている部分もあるから、金子さんを中心に決めきてほしいと。
金子
ええ。それで4月の中旬頃から今までの調査や試算結果も踏まえて、改めて考えをまとめ始めました。
やはりクラウド化でネックになるのはコスト増。DeNAくらいの規模でオンプレを使っていると圧倒的にオンプレのほうが安いんです。そのコスト差に明確な答えを出さないまま普通に考えると「DeNAは基本クラウドを使っていきます。でもオンプレもありますよ」となります。
しかし、これではメッセージ性が弱いし、経営戦略上の判断も曖昧になりかねません。今とあんまり変わらず結局部分最適になるんじゃないかと。
そこで、再度試算と検討を重ねていき、ゴールデンウィーク明けにやっと「クラウド化してもコストは現状とほぼ同じで実現できる」というところまで見えたので「DeNAはクラウドに全部移行します」というメッセージにしたい、と。
nekokak
最初の試算では、クラウドはオンプレの3倍ものコストがかかって、これは絶対にできないという判断でしたよね。どのような試算を重ねたのか、詳しくお願いします。
金子
オンプレと比較して、クラウドの運用コスト圧倒的に高いです。
ですが、オンプレはこの5、6年新規サーバーを買っていなくて故障率も年々上がってきていました。オンプレ運用を続けるとしても、新規投資をしてサーバーを大規模に刷新しなければならないタイミングが来ていたんです。
そこでまず、オンプレを刷新した場合とクラウド化のコストを比較をしたのですが、それでもまだ3倍の開きは縮まりませんでした。オンプレを刷新すれば、サーバーはより高性能になり必要台数は減るので、今のオンプレ運用より更に低コストになる見込みなんですよね。
大規模に刷新するとなると一時的に大きなキャッシュの支出は発生しますが、サーバーは減価償却費として処理するのでPLへの影響は抑えられます。
nekokak
PLへの影響は少ないとしても、一時的なキャッシュ支出は大きいですよね。一方、クラウドにすればそのような設備投資費用はかからない。
金子
ええ。なので、やはりクラウド化をどうにか実現できないか、あらゆる角度から検討を重ねました。その結果、クラウド運用上のコスト減施策の積み重ねで3倍だった運用コスト差を1.1倍まで縮めることができる、と試算を立てることができたんです。
nekokak
1.1倍差なら、開発スピードの向上やサーバー在庫というリスクを持たなくてよくなる、などのクラウドのメリットを考えると十分良いですよね。
金子
ええ、コスト減施策は全部で8つ打つことにしました。2015年から大規模にクラウドを使っているサービスがあるので、そこに施策を打って効果の検証を進めているところです。
nekokak
既に検証を始めているんですよね。
金子
そうなんです。具体的に現時点でお話しできる施策例でいうと、たとえば「オートスケーリング」。
これは新しい考え方ではないのですが、サーバー負荷に応じて、自動的にクラウドサーバーの台数を増減させる機能を採用するんです。アクセスが少ないときはサーバーを減らせるので常に必要最小限のサーバー数を実現できる。
nekokak
負荷実態に応じてサーバー台数を調整できるので品質を落とさずにコストを下げられますね。
金子
そうなんですよね。
それから、中断可能性があるサーバーインスタンスを活用する施策も行っています。どういうことかというと、クラウド事業者がそのとき未使用のサーバーを低価格で利用させてもらうんですね。
クラウド事業者も、彼ら自身はサーバーを保有していて内部の実態はオンプレなわけです。なので、サーバーを保有しているんだけど、顧客のクラウド運用状況でその時点だと稼働していないサーバーが発生してそれを顧客に非常に安価に提供していたりするんです。
中断可能性があるインスタンスで運用しても問題ない部分を見つけて、できる限り利用範囲を広げられるよう工夫をする感じですね。
nekokak
目新しい大型施策をどん！ とやるというより着実に地道に施策をやっていく計画。検証していてもほぼ試算通りの効果が出ています。クラウド全面移行後も、実態として、試算にかなり近いコスト減効果になるでしょうね。
クラウド化決定への壁はどう乗り越えた？
nekokak
しかし「どうやって全社的な意思決定まで持っていったのか」は多くの方が気になるとこなのではないかと。
現場がクラウド化したい、と思っていても経営者にその意図や背景が伝わりにくく断念するケースもあるように思います。
金子
それは今回のプロジェクトにおいても大きな課題になりうると思っていたので、経営層との対話は綿密に行ってきましたよね。今回はnekokakさんにもかなり動いていただいて。
基本的に、経営層とインフラ部門はもっと対話が必要ですよね。
nekokak
このプロジェクトの構想は、初期から私と金子さんでは計画詳細まで綿密に共有していましたけど、ラフな案の段階から社長の守安さんに積極的に相談していましたね。私と守安さんの1 on 1のたびに議題に上げたり。
金子
そのおかげでかなり進めやすかったです。経営層もインフラ部門も「もっとサービスを良くしたい」という思いは同じはずなのに、対話が少ないと、見ている目線が違いすぎてなかなか話が噛み合わない、ということは往々にしてありますし。
「インフラを刷新したいです」と言っても、経営層として気になるのは「で、コストは？」「安定性は大丈夫なの？」みたいなところですよね。
それを詳しく説明しようとしても、専門用語が多いですし、インフラは実務をしたことがないと肌感覚で理解するのは特に難しい領域です。同じ目線を見て話せる土台づくりのためにも、やはり日頃から綿密に対話をしておくほうがいいと思います。
nekokak
それで結果的に経営上の意思決定スピードも全く変わりますし、それこそ全体最適な動きが可能になりますよね。
あと、他に社外の方が気になるであろう点としては「プロジェクト担当者の工数増はどのようにケアするか」もあるのでは。
オンプレからクラウドへの移行は一大プロジェクト。そもそもインフラ運用担当者は常に安定運用を見張り守っていて昼も夜もない、というイメージもありますよね。
金子
一般的にはそういうイメージが強いですよね。しかし、DeNAの運用担当者は、100％の工数を運用に割いているわけではないので、その前提の差は大きいでしょうね。
目の前の運用だけで手一杯になるのではなく，常日頃から運用改善や自動化のための工数をきっちり確保してきているんです。
もともとDevOps（※3）やIaC（※3）という単語が一般的になる遥かに昔から，地でそれをやってきた部門なんですよ。データセンターでの実作業は外部の協力パートナーに委託するなど。自分たちが大きな価値を出せる作業に集中できる環境を作ることが大事だと考えて実践してきています。
※3……DevOps：デブオプス。ソフトウェア開発手法の1つ。開発（Development）担当者と運用（Operations）担当者が連携・協力する手法。
※4……Infrastructure as Code：インフラの構成を管理したり、機械処理可能な定義ファイルを設定したり、プロビジョニングを自動化するプロセス。
インフラエンジニアの仕事の本質は変わらない
nekokak
プロジェクト遂行のために、インフラエンジニアの工数が足りない、という状況ではないと。
しかしそうなると、この記事を読む方には「DeNAのインフラエンジニアってふだん何しているの？」と思われるかもしれないですね。
金子
もちろん、暇しているわけではないですよ。
DeNAのインフラエンジニアに求められる役割は「サービスが、最も安定して最も安く動き続けるために必要なことを全部やること」なんです。これはDeNAに限らず、インフラエンジニアの仕事の本質なのではないかと思っています。
そのためにも、運用でいっぱいいっぱいになっている状態にはしたくない。現にDeNAのインフラエンジニアは仕事の本質を追い求めるためには、通常のインフラエンジニアの領域を超えた動きもたくさんします。
nekokak
本当にそんな動きが起きてますよね。通常のインフラエンジニアの領域を超えた動きを取りたい方にはワクワクできる環境だろうと思います。
金子
そうだと思います。「通常のインフラエンジニアの領域を超える」と言ってもいろんなやり方があります。
たとえば、
「コードまで見てユーザーへのレスポンスを2倍早くする」
「契約オプションの裏技を使って楽して5％コストを下げる」
「技術的に神業みたいなことを駆使して全体のパフォーマンスを2割上げる」
こんなことにワクワクする方には、DeNAのインフラエンジニアという選択はとてもエキサイティングなんじゃないでしょうか。 いろんな方向に尖ったインフラエンジニアがいて、おもしろいですよ。
nekokak
開発エンジニアが書いたコードを読んで、こうしたほうがいいって提案しているインフラエンジニアがいるのはDeNAくらいなんじゃないでしょうか？
金子
あんまりいなそうですよね。webサーバーも、データベースサーバーも、キャッシュサーバーも見るというエンジニアは、同業他社ではそこまでいないと思いますが、DeNAは専任を置かずにインフラエンジニアが全部見る、としています。
ただ、どうしても夜中に障害対応をする可能性もある仕事なので、できるだけ働きやすいように配慮をしていますね。
nekokak
IT基盤部はかなり前から柔軟な勤怠制度作りにも取り組んできてますもんね。自宅での障害対応って、言ってみればリモートワークのようなものですし。
金子
深夜に問題が起こったらインフラエンジニアが対応して、翌日定時出社という会社もありますよね。それではあまりにインフラエンジニアの負担が大きいと思います。
DeNAはだいぶ前からインフラエンジニアの出社退社時刻のしばりをなくしています。共有カレンダーで勤務時間だけは表示してもらっていますが。
週に2日までですが、完全リモートワークも利用できます。その場合はミーティングにもリモートで参加しますね。
nekokak
かなりフレキシブルですよね。
では、意思決定を取りつけたクラウド化は今後どう進めていきますか？
金子
これから2年かけて移行を完了させます。今、オンプレをクラウドに移行する準備をしていて、運用がクラウドに適するようプログラムを書いたり計画を立てたりしていますね。
あとは、先程話したように既存のクラウド環境にコスト削減施策をすべて試行しておくことをしています。いざオンプレ環境をクラウドに移行しますというとき、コストが最適化された状態でスタートするためです。
nekokak
DeNAがクラウドの移行に2年かける理由は、まさにそこですもんね。
金子
一般的には移行先の環境にまったく同じ環境をつくってから移行しますが、コストは2倍かかりますし、施策を試すこともできません。
なのでこの方法を採っているということですね。 施策を実行しPDCAを回す過程でまた知見がたまるのでおもしろいフェーズですよ。
nekokak
クラウドサービスが普及するとインフラエンジニアの役割は変わるのではと思いますが、そこは金子さんはどう考えていますか？
金子
もともとサービスが稼働するために必要なことを全部やるのが、DeNAのIT基盤部の役割だったので、本質はやはり変わらないです。
オンプレもクラウドも中で動いている技術はほとんど変わりません。
セキュリティ、コスト、開発のプログラムまで手を出したりとか、そういう動きをもっとやれるようになって、インフラを強みにしつつ、キャリアを増幅できるのではないでしょうか。
nekokak
クラウド化が進んでもインフラエンジニアの仕事の本質は変わらない。むしろ、強みを活かしつつ仕事の本質を突き詰めるために新たな領域に踏みこむことができそうですね！
金子
ええ。そんなダイナミックな変革期に、DeNAでインフラエンジニアとしての領域を広げていくのは非常に良いチャレンジになると思います。ぜひ、そんなチャレンジをしたい方、お待ちしています！
DeNA の最新情報は、公式Twitterアカウント（@DeNAxTech）にて確認いただけます。ぜひフォローをお願いします！
執筆：さとう ともこ 編集：榮田 佳織 撮影：小堀 将生
