インフラ戦略最前線～トップ技術者たちが語るインフラ戦略のリアルな裏側～
2020年7月15日に開催したFLEXY主催CTOmeetup。今回のテーマはインフラ戦略の最前線です。
登壇するのはDeNA、メルカリ、DMM、ミクシィの計4社のCTO及びVP of Backendのみなさん。
応募者多数、また登壇最中も質問がかなり寄せられる大人気イベントとなりました。
日本を代表するトップ技術者たちがインフラ戦略についてどのような考えを持っているのか、各社のインフラ事情も含めてオンラインで2時間ディスカッションしていただいている様子をライブ中継しました。
＜パネラー＞
- 株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏
- 合同会社DMM.com CTO 松本 勇気 氏
- 株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏＜モデレータ＞
- 株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏
目次
登壇各社のインフラ事情Overview
YouTube Liveでの中継イベントは登壇各社のインフラ事情の説明からスタート。
各社の共通点は、オンプレからクラウドへの移行が現在進行系で進んでいることです。
移行の経緯や手法も語られた本イベントレポートは、特に自社サービスのクラウド移行を検討している方必見です。
DeNA / 緻密なコスト試算によって経営承認を得てクラウド移行を実施
株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏（以下、小林）：株式会社DeNAのCTOを務めている小林と申します。
DeNAはもともとオンプレ＋Perl、プロジェクトによってはRubyやAWSという技術スタックで事業開発を進めていました。それが近年は徐々にAWSの利用が増え、経営としてオンプレとパブリッククラウドどちらで進めるのか、方針を決める必要性が出てきました。 その結果、2018年に社内システムも含めてパブリッククラウドへ移行することが決定し、現在はAWSやGCPをメインとして、IDCF、Tencent Cloud、Alibaba Cloudなどを必要に応じて利用しています。
クラウド移行にあたっての一番大きな論点はコストでした。DeNAは長らくオンプレを利用していたのでそれなりの規模に成長しており集約効率が高く、インフラコストが圧倒的に安かったんです。当初、オンプレとクラウドを比較すると4倍ものコスト差があり、クラウドは全く勝負になりませんでした。
ただ、このときは償却が切れたサーバーのランニングコストと比較しており、サーバー入れ替えのための購入費なども試算に入っていませんでした。比較基準に問題があるということで、極力条件が揃うような形で試算し直してみると、クラウドのほうが約2倍高いという結果になりました。
小林： これなら可能性がありそうだったので、ほかにもBCPの観点でのDRやクラウドにかかるコストのさらなる最適化、インフラの運用人員などの条件を付与。最終的にオンプレとクラウドでほぼコスト差異は出ないというレベルまで落とし込むことができました。
コストに差が無いのであれば、優秀な社員をよりクリエイティブな業務に向かわせたいという意見を経営陣に伝え、クラウド移行の承認に至ったのです。
経営承認されたのは2018年6月で、基盤の設計などの準備を経て、2019年10月からオンプレ上にあるサービスを本格的にクラウド移行し始めました。現在は移行期のど真ん中ですね。2021年4月に3カ年計画が終わり、全てのクラウド移行が完了する予定です。
移行期の中で我々が得た知見は積極的に外に発信しようとしていて、さまざまなカンファレンスでお話ししたり、DeNAのエンジニアブログでインフラチームのことを書いたりしています。Twitterアカウント（@DeNAxTech）でも取り組みをお伝えしていますから、良ければフォローお願いします。
メルカリ ／ マイクロサービス化を目指し、GCPメインでクラウドを活用中
株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏（以下、田中）：メルカリの田中です。よろしくお願いします。
メルカリのこれまでのインフラは主にアプリケーションサイドの言語がPHP、データストアはMySQL、インフラはオンプレミスという環境でした。
創業した2013年からずっと同じ環境で続けてきましたが、2018年頃にそろそろマイクロサービスを検討しようということになりました。社内で話し合った結果、言語はGo、データストアはCloud Spannerなど、インフラはGCPを中心として進めることにしました。
このときコスト面に関する議論も当然出たのですが、プロダクティビティやアジリティなどを重視して、マイクロサービスへの移行を決定しました。
移行にあたって難しかったポイントは、もともとオンプレ環境が北海道のデータセンターにあったことです。マイクロサービスの環境は東京で作ろうとしていましたから、データセンター間とのレイテンシの大きさがアーキテクチャを考える上でのハードルでした。
具体的なマイクロサービス移行の手順については以下のような形です。マイクロサービスに移行する以前は非常にシンプルな構成で、オンプレミスの環境にアプリケーションサーバーがあり、裏にデータベースがあるという状態でした。
田中：これがマイクロサービスに移行すると一気に複雑になりました。まず東京側にAPI Gatewayと呼ばれる入り口があり、そこにAuthorityという認証を扱うサービスが並列しています。その裏にマイクロサービス群が並ぶのですが、移行するにしても一気に全てをマイクロサービス化できるわけではないので、当初は多くのトラフィックをMercari API、つまりオンプレミス側に飛ぶ形にしていました。
加えてGCPの環境とオンプレの環境に物理的な距離があるので、GCPだけにマイクロサービスを置けばいいという話でもありませんでした。マイクロサービスを切り出すタイミングでGCPかオンプレどちらに置いたほうが良いのか、少しずつ設計しながら進めていきましたね。
田中：データも最初は全てMySQLにありましたが、少しずつGCPに移動させているところです。数年かけてじわじわ進行していて、まだ道半ばですね。
システム的なアップデートと並行して、組織的なアップデートも行なっています。以前はモバイルエンジニアとバックエンドエンジニア、DevOpsを扱うSREのエンジニアが職能ごとに分かれていました。現在はバックエンドエンジニアにマイクロサービスを切り出す単位として「ドメイン」という考え方を導入しています。バックエンドエンジニアがドメイン単位でチームを作り、マイクロサービスの移行を進めるというやり方です。
田中：将来的にはそれをさらにクロスファンクショナルチーム化し、モバイルエンジニアとバックエンドエンジニア、SREが一つのチームになって特定の機能を担当する形にしていきたいと思っています。同じようなチームが複数あり、全体のシステムをまかなうというわけです。
DMM ／ 10年で300事業の展開を目指し、アジリティの高い環境づくりを推進
合同会社DMM.com CTO 松本 勇気 氏（以下、松本）：DMMでCTOや人事などを務めている松本です。
DMMのインフラについてほかの皆さんと違うのが、当社は事業数が40以上あるカオスな状態だということです。我々の手掛けるサービスは2017年頃から一気に数が増えたのですが、古いものだと20年ほど稼働しているシステムもあります。
内容としてはハードウェア製造からものづくりの拠点、プログラミングスクール、最近では水族館といったように実にさまざまです。全体のサービス規模を数字で表すと売上が2211億円、会員数は3196万人です。
こうした多岐にわたる事業をほとんどオンプレで捌いていたのですが、直近はどんどんクラウドに移行しようとしています。全て一気に移行するケースもありますが、サービスの状況に合わせながらときには分割して進めたりもしています。AWSを使う場合もあればGCPを使う場合もありますね。サービスごとに自社のプラットフォームとの関係の濃淡もあるため、状況に合わせて技術選択しています。
戦略に悩んだ場合の基準として捉えているのが「アジリティ」という言葉です。これは僕がCTOに就任して以来掲げている「DMM Tech Vision」の4つのバリューのうちの一つです。
小林さんのお話にあったように、人件費やサーバー交換のコストを踏まえても確かにオンプレは若干安いのですが、それでも大切なのはアジリティだという考えで最適なものを選ぶと、現時点ではクラウドに分があります。特にアプリケーションサーバー群に関してはどんどんクラウドにリプレースする方針です。
松本： 実際に行なっている作業が、上記の図にある①～③の内容です。
1について…我々のサービスは一つのプロセスで複数の事業が動いていたので、まずオンプレ内で環境を分離しました。それらを順次クラウドにリフトして、その後クラウドに合わせた改善しています。いわゆるAWSが提案しているLift-and-Shiftです。
2について…プラットフォームと呼ばれる各事業で利用している共通機能を、マイクロサービスとして切り出す作業です。特に認証や決済といった重要な機能のみを共通機能として分離して疎結合にし、各事業がAPIを探す形で連携する戦略です。
3について…最後がモノリスの解体ですね。AWS CloudFrontやALBなどを上手く活用しながら新しいシステム群をルーターで受け、少しずつモノリスの部分を減らしていこうとしています。
今後はAWSやGCPのさまざまなマネージドサービスの恩恵を受けながらアジリティの高い環境を作り、10年の間に300事業くらい立ち上げられる会社にしていこうと話しています。
もちろんオンプレ環境がプラスになる領域もあるので、おおよそはクラウド化しながらも一部はオンプレを使いながら最適化を進めていく感じですね。
ミクシィ ／ コスト以外の諸要素を検討すると今後オンプレという選択肢は無い
株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏（以下、村瀬）：株式会社ミクシィ取締役CTOの村瀬です。
当社は現在「コミュニケーション」を軸として、スポーツ事業、デジタルエンターテイメント事業、ライフスタイル事業の3つの領域でサービス展開しています。どの事業においても、目指すのは家族や身近な友人を幸せにするコミュニケーションの活発化です。
村瀬： みなさんのお話をお伺いしていると、パネルディスカッションで意見がぶつかることはなさそうだなという印象ですね。当社も現在基本的にクラウドに寄せています。コストというよりも、先ほど松本さんがおっしゃったアジリティが大切だという考え方も含め、エンジニアリソースや事業の独立性、依存関係、さらには撤退などの諸要素が持つ目的に沿っていこうとすると、結果としてクラウドに寄せていくことになるのだと思っています。
ですから、ミクシィも基本的には今後オンプレという選択肢は選びません。一部オンプレ環境も存在しますが、これは適材適所ですね。動画の配信でAWSのElemental Applianceを入れていたりします。
さらに詳しい技術スタックについては、ミクシィのオウンドメディア「ミクシル」で紹介していますので、ご覧いただければと思います。
質疑応答
※当日は、視聴者からリアルタイムで様々な質問が寄せられました。
大規模なインフラ戦略は事業・採用計画を考慮しながら進行する
小林：各社のインフラの現状が見えてきたところで、YouTubeコメントからいただいた質問に答えていきたいと思います。
質問者：クラウド移行、マイクロサービス化など＋組織を検討する際、CTOとしてビジネス的な計画（事業計画、採用計画）も同時にやっていますか？
小林：DeNAとして簡単に答えるとイエスですね。
DeNAの場合、オンプレからクラウドにリフトする際にインフラコストがオンプレとクラウド両方でかかってしまうんですよね。これは事業計画にも大きなインパクトがあります。そのため、想定外のコストが発生しないよう、どんなタイムラインでどういう風にリフトを進めていくのか、きちんと経営レベルで中長期的な計画に落とし込んでいます。 クラウド化によって事業が拡大すれば当然人員が必要になりますから、必要に応じて採用計画も立てます。ただし、クラウド化のためだけに採用するケースは少ないですね。
田中：うちの場合は、エンジニアリング組織として主体性を持って事業計画の作成をリードすることはやっていません。プロダクトサイドやビジネスサイドが事業計画を立て、そこに合わせたエンジニアの採用計画を考えています。
マイクロサービス移行はエンジニア発のプロジェクトですから、必要な人員の採用計画はエンジニア主体で作りました。
松本：僕自身はマイクロサービスやインフラ戦略のための採用計画及び事業計画には関わる動きが多いですね。経営管理室長という肩書きも持っているので事業計画をモニターしているのですが、その中で「CxOが決めた事業戦略をどう達成できるか」という点を考えています。「ここの領域にだけはマイクロサービス化が必要だ」ということが見えてきたら、必要な兵站を整えるために採用などをする感じです。
村瀬：僕は田中さんに近いと思います。事業計画自体は各事業の担当者が立て、僕は経営会議で予算や事業をどう成長させるのかといった内容を見て、実現可能性や採用計画に関する意見を出します。採用しやすいアーキテクチャなどもありますからね。
会社的に注力する事業の場合は、一人目のリードエンジニアをどう採用するか、どんなアーキテクチャを組んでメンテナンスの手間を減らすのかといった計画を考える役割を持つこともあります。
先行き不明なプロダクトに対してオンプレを採用するメリットはほぼゼロ
質問者：パブリッククラウドが充実している現在でもオンプレを選択するケースはありますか？特に新規で立ち上げる場合についてお伺いしたいです。
小林：DeNAの場合は新規立ち上げでオンプレを選択することは今後無いです。というのも、現在はこれまで持っていたデータセンターを全て解約していっている状況なので、オンプレを選ぶと立ち上げコストがかなりかかってしまうんです。メルカリさんはいかがですか？
田中：小林さんとほとんど同じ回答です。今の時代、新規でオンプレを採用するのはあまり現実的な選択肢ではありません。仮にオンプレで何か作業をするとしたら、巨大なシステムのスケールメリットを生かしてコストを圧縮する場合や、特殊なハードウェアを使う場合などでしょうか。
一般的なサービスなら、基本的にスケールメリットよりもコストメリットが上回ると思います。
松本：事業を立ち上げる瞬間から「当たる」とわかっているのならオンプレを選択する可能性もあるかもしれませんが、何が当たるかなんてわかりませんよね。先行き不明な状態の中で一番大事なのは、素早く回収ができること、失敗しても捨てられるということですから、新規事業でいきなりオンプレスタートという選択肢は無いと思います。
すでに大きく成長した事業で、明らかにシステム運用の安定化や高速化、コストダウンが見込めるなら、オンプレミス回帰という意思決定もできるでしょう。Dropboxが例ですね。
逆に言えばそこまで安定してからでなければ選べない選択肢ということだと思うので、僕自身はオンプレ回帰には懐疑的です。
村瀬：もう僕から特に言うことは無いのですが（笑）、確かに今は当たるかどうかわからないものに対してわざわざハードウェアを買わなくてもいい時代ですよね。そういう流れに乗るのが一番選択肢としては正しいと思います。
ただ、オンプレでしかできないことも確かにあり、うちも動画配信部分はオンプレです。逆に言えばそこくらいかもしれません。
経営とエンジニアが同じ方向を向くために求められるCTOの立ち回り
質問者：インフラの開発・運用に取り組む際にエンジニア視点と経営者視点でそれぞれ考えていることはありますか？
松本：コンウェイの法則ではありませんが、組織設計とプロダクト設計は沿わせていこうとしていますね。僕が言っているだけかもしれませんが（笑）。
前職ではそこに採用目線も入れていました。例えばサーバーレスが流行りはじめた頃にバリバリのサーバーレスアーキテクチャのサービスを発表したところ、多くの方が採用に応募してくれました。そういう色目を使ったアーキテクチャを考えることもあります。
田中：どうやったら経営とエンジニアが同じ方向を向けるのかは意識していますね。エンジニアはやはり新しい技術を使いたいとか、リスクを減らして安全なオペレーションをしたいと考えます。経営側はコストや採用について考えるので、それらを一貫した形に整えて同じ目線になれるようにすることが大事だと思います。
村瀬：人材や事業のスケールについて考えだすと結局は俯瞰で見なければならなくなりますよね。人を採用して急激にスケールしなければならなくなったときに、最善なアーキテクチャや言語は何なのかということをよく話すのですが、これは経営視点とも現場視点とも言えると思います。
■関連記事：
