「CTOが訊く」は、DeNA CTO の @nekokak （ねこかく）こと小林 篤が、社内のメンバーに、その人となりや仕事っぷり、そして野望を訊く、というコーナーです。

第5回の対談ゲストは、パブリッククラウドチームのチームリーダーを務める小池 啓輔。

当記事の内容は YouTube でもご覧いただけます。
当記事では、お読みいただきやすいよう一部編集して掲載しております。

※ DeNA の IT 基盤（インフラ / SRE）については こちら の TEAM ぺージをご覧ください。

開発未経験での入社。『毎週同期と飲みに行って、分からない言葉をこっそり調べてた』

@nekokak
皆さん、こんにちは！ CTO が訊く、今回は5回目になります。

DeNA は、2018年から3年かけてインフラをパブリッククラウドにリフトしました。今まさに、クラウドネイティブという形で様々なサービスを作っていく中で、DeNA はパブリッククラウドチームを作り、更にパブリッククラウドを使いこなせるように取り組んでいます。

そこで今回は、若きチームリーダーとして活躍されている小池さんをお招きして、色々と話をしていきたいなと思っております。小池さん、よろしくお願いします。

@keisuke.koike
よろしくお願いします。

@nekokak
ではまず、小池さんの自己紹介からお願いします。

@keisuke.koike
はい。小池 啓輔と申します。

僕は2019年に新卒で DeNA に入社して、そこから IT 基盤部というインフラの部門に配属されて、一貫してインフラ部門にいます。主務では全世界向けのゲームタイトルのインフラの運用をしているんですけど、兼務として、nekokak さんから紹介があったパブリッククラウドチームのチームリーダーとして働いています。

@nekokak
なるほど。2019年だと、まだ入社して間もないと思うんですけど、そもそも学生時代ってどういうことされてたんですか？

@keisuke.koike
学生時代は物理学をずっと研究してまして。量子力学系をずっと専攻していて、博士課程までいっていました。

@nekokak
では、ソフトウェアエンジニアリングに関しては、学生時代はあまりやられてなかった？

@keisuke.koike
そうですね、数値計算でちょっと C 言語とか Python とか触ったり、研究室用のサーバを管理したりはしていたんですが、アプリケーション開発とかは一切やったことなかったですね。

@nekokak
なるほど。元々ソフトウェア開発はあまりやられてなかった中で、なぜ DeNA に入社しようと思われたんですか？

@keisuke.koike
「研究を続けていくのがちょっと辛くなったな」と思った時に民間に就職しようって思って。

自分で何ができるかなと思った時に、「数値計算できるし、プログラミングならいけるんじゃないかな」と思って、色々と企業を見てた時に、知り合いに DeNA の方がいて、お話を聞いて「すごくいい会社だな」と思って応募してみようと思ったのがきっかけでした。

@nekokak
なるほど、それがご縁で DeNA に入られたんですね。未経験で入られて、色々と経験を積みながら活躍されているので、今日はちょっと色々と深い話とかもできればと思ってますので、よろしくお願いします。

先程簡単にご紹介いただきましたが、もう少し具体的にどのような業務をやられているのか、お話しいただいてもいいですか。

@keisuke.koike
主務では、全世界に配信する大規模ゲームタイトルのインフラ運用をしていて、インフラエンジニアとして障害対応をやったりとか、新しい機能を作る時にどういうインフラ構成にするかとか、あとはインフラコストを削減するためにどうするかとか、いわゆる QCD (Quality, Cost, Delivery) にすごく着目して業務に取り組んでいます。

兼務のパブリッククラウドチームの方では、全社でパブリッククラウドを使い倒すために、どういう風なことをしていけばいいかっていう、本当に SRE（Site Reliability Engineering）的なことをやっています。

@nekokak
世の中の SRE と聞いてイメージされているものと、DeNA の SRE ってちょっと系統というか、取り組んでいる内容が微妙に違うなと僕は感じているんですけど、小池さんが推進されている SRE としての具体的な取り組みや概要を教えてもらっていいですか？

@keisuke.koike
はい。DeNA において SRE っていうのは『サービスを落とさないために、できることは何でもやる』としています。

構築・運用・監視・保守というインフラエンジニアリング的なものはもちろんなんですけど、例えば売り上げが下がってしまったとしてもコストを下げればその分、サービスの延命ができるので、コストコントロールにも力を入れています。

あとは、運用の改善ですね。サービスを持続可能にするためには、いわゆるトイルを削減していかに自動化するかが大事なので、そういったことにも取り組んでいるっていうのが DeNA らしいサービスを落とさないためのエンジニアリングだと思っています。

@nekokak
SRE をやられている中で、小池さんが面白いと感じている部分ってどういうところですか？

@keisuke.koike
そうですね、開発エンジニアとかって、比較的自分がやったことが数字として見えにくいと思うんですけど、SRE だと自分がやったコーディングによってどれくらいコストを削減しただとか、どれくらい運用工数が下がっただとか、そういう目に見える成果っていうのがすごく大きいなって自分は思っていて。こういうところがモチベーションになるのは、すごい楽しいなと思っています。

あとは、トイルの削減とかで徹底的に無駄を削減するんですけど、自分がすごい効率化するのが好きなので、そういう快感があるのは楽しいなと。

@nekokak
なるほど。

そういえば、小池さんご自身がソフトウェアエンジニアリングをほぼ未経験で入って、そこから技術を学んでいかれていて、徹底的に自分をチューニングしてましたよね。

@keisuke.koike
そうなんですよ！

周りの同期がすごい強いエンジニアばっかりだったんで、その中で自分がどうやって強くなっていくかっていうのを合理的にやるためには、やっぱりその同期に色々教えてもらうっていうことが最短だと考えました。

毎週のように同期と飲みに行って、その中で同期が話していることを理解できるようになるってことが強くなる近道だと思ったんで、何を話しているんだろうとか、その話してる言葉一つ一つが分からなかったので、その話を止めないように注意しながら質問してみたり、もうちょっと深掘りしてみたりとだとか。あとは見えないところで、スマホでその言葉を調べたりとか。

@nekokak
なるほど。そういうのが、うちの SRE チームとマインドセットというか、考え方がすごい似通っているなと思って。

小池さんが一緒にやられているチームメンバーも効率というか、そもそも本質的なところを知った上できちんとやっていくって思いが強い方々だと思うので、そういう意味ではすごくフィットしたんですかね。

@keisuke.koike
そうですね。正直、入社した時はインフラエンジニアというか、SRE になるって全く思ってなくて、普通に開発のエンジニアになろうと思ってたんですけど、研修の時に「インフラエンジニアに向いていると思うから来てみない？」って先輩に誘われて。

結構、その時は半信半疑で配属希望を出したんですけど、インフラチームに入ってみるとすごい自分に合ってて。先輩にはすごくいいアトラクトをしてもらったなと思っています（笑）。

@nekokak
その人は見る目があったかもしれないですね（笑）。

パブリッククラウドへのリフトと、QCDの担保

@nekokak
2018年にオンプレミスからクラウドにリフトしていく、そして今後 DeNA は積極的にパブリッククラウドを使っていくという意思決定をするときに、DeNA の経営会議とかでもいろんな議論があったんですよね。それで、その中でよく言われたのが『コストとクオリティをきちんと担保できるのか』ということ。

デリバリーは圧倒的にクラウドの方が良いってのはみんな知ってたので、コストとクオリティがちゃんと担保できるのかというのが議論になったところなんですね。計画を作っていく中で、我々は勝算があるって思ったので自信を持って経営会議で提案して、承認されてクラウド化を進めていくことになりました。

ただ、その初期（2018年の頭）のタイミングって単なる計画でしかないんですよ。もちろん、計画作るのも綿密にやってもらっていた部分はあったと思うんですけど、実際に execution していく中で、工夫されていたところを具体的にお話いただけますか？

@keisuke.koike
QCD のお話で、クオリティとかコスト、デリバリーに関してをひとつひとつお話していくのがいいかなと思います。

実は、僕が2019年に入社した時点ではもうクラウド移行が始まっていて、残念ながら僕はクラウド移行には全く関わっていなくて、先輩方が作ってきたものに乗っかって、周りのチームがどんどんクラウド化していくのを見てただけなんですけど。僕から見えていた範囲だと、クオリティの部分では「いかにインフラ起因のメンテを少なくするか」っていうことに力を注いでるなっていうのは感じました。

例えば、データベースの failover の時間をすごく短くしていて、メンテを入れなくてもデータベースのインスタンスタイプを小さくしてスペックの最適化をできるようにしていたりとか。あとは、シャード統合してデータベースの台数自体を少なくするっていうのも、メンテを入れないでできる技術的な強みがあったりとだとか。そういうことをクラウドでもやりきるっていうのはすごく難しかったところだと思いますし、DeNA の強みになっているかなと思います。

@nekokak
なるほど。オンプレのときに MHA （Master High Availability Manager and tools for MySQL）ってあったじゃないですか。あれが発明されたことで、DeNA ってシステムをアップデートするためのサービスのメンテナンスなんてほとんどやってなくて。実際、「クラウドにリフトする時に MHA を実現できるんだっけ」というのが検討の際に論点としてあって、それをちゃんとクラウドでも実現したってことですよね。

@keisuke.koike
はい、そうなんです。今も実際にメンテ入れてないですし、確かに DeNA のサービスってほとんどメンテないなって僕自身も思ったりします。

Twitter とかでエゴサーチしてみたりすると「もっとメンテ入れてもいいから」みたいなことが書いてあったりして…いや、裏側ではかなり頑張ってるんだけどなぁって思ったりしてました（笑）。

@nekokak
（笑）

そこは僕はバランスだと思ってて、メンテを入れた方が安全にできるっていう場合は入れていいと思うんですよ。ただ、通常のちょっとしたやつの時に毎回メンテ入ってサービス止めるってあまりユーザーの体験としてよくないので、メンテをしなくて済むというのが手段として選べるってのは、ほんとにすごいことだなって思いますね。

@keisuke.koike
はい、そうですね。

@nekokak
コスト周りは？

@keisuke.koike
コスト周りだと、例えばステートレス系統は全部スポットインスタンスを使ってコストを下げていて。スポットを使うだけだとオンデマンドの10分の1なんですけど、オンデマンドと混ぜながら使っているので、トータルでは半分くらいのコスト削減になっています。

あとは、先程もちょっと話してたんですけど、データベースのシャード統合とかで台数を減らすことで、コストをどんどん削減していくだとか、そういう調節をすごく頑張っていて。コストをオンプレ並みに下げることは、最初は机上の空論だったかもしれないんですけど、実際に実現できてるなと思います。

@nekokak
僕も実際にクラウド化を execution される過程を見てたんですけど、すごいなと思ったのが、いろんなアイデアがあるんですよね。それこそ、スポットインスタンスを使いますだったりとか、リザーブドインスタンスをうまく使っていくだったりとか。

例えば、インスタンスサイズを調節するみたいな本当に細かい点も含めて計画としてあって、それを実行することによって、どの程度のコストが下げられるか、計算されていました。更にそれを実際にそのスポットインスタンスを使っていく時に手動で切り替えるってあり得ないじゃないですか？うちの考え方として。だからそこも仕組み化して実現した上で、コストもちゃんと下げるってのができたのは本当にすごいなって思いますね。

@keisuke.koike
そうですね。スポットインスタンスに関しては ブログ とかも書かれているので、興味がある方はぜひ読んでほしいですけど、本当に自動化されていて。スポットインスタンスでやるっていうことを全く意識してないんですよ。本当にオンデマンドのようにスポットインスタンスを使っているので、仕組みとしてすごいよくできてるなって思います。

@nekokak
そうですよね。アイデアとして思いつく人はいると思うんです。単純にコスト比較すると10分の1だし、これ全部やったらこんなに安くなるなーといった風に。

そこを実際に仕組みを作って、勝手にそれが自動で動いているっていう状況まで作り上げるのって結構大変だったと思うんですけど、これは本当にすごいなと思いましたね。

デリバリーの部分は、工夫されていることはあるんですか？

@keisuke.koike
やっぱり自動化だったりとか。あとは IaC（Infrastructure as Code）ですかね。全部コードで管理して極力、人間の手ではやらない。人間の手でやってしまうと、再現性がなくなったりだとか、カオスになりがちなので、このあたりをすごく頑張っていて。

我々インフラ部門は全社横断の組織なので、例えば僕が所属しているグループでなんらかのバグを踏んだりした時に、同じバグを他のグループでも踏みがちなので、同じようなバグを踏まないために、『 グローバルインフラ（gi） 』と呼ばれる共通のコードツール群を使うことで自動化が最適化ができているかなと思います。

@nekokak
なるほど。それぞれのチームとかで経験していることとか、踏んじゃった地雷とかを二度と踏まないようにする。それを単純にちっちゃいチームだけの問題でなく、DeNA のインフラチームとして共通のものとしていくっていうことを普段からやってるんですね。

@keisuke.koike
そうですね。もちろん、そのプルリクベースでそういうことが起きたから、こういう風に改修するよっていうのはもちろんあるんですけど、部門の定例会議とかで「こういうおっきい障害があったから気をつけてくださいね」っていうものも共有したりだとかもやってますし、あと Slack ベースで「こういう風なバグがあったから気を付けようね」っていうのを結構密にやり取りしていると思います。

『クラウドベンダーさんと互いに高めあって、一緒にいいモノをつくっていけたらと』

@nekokak
実際にパブリッククラウドに移行して、クラウドの便利なソリューションを使っていくってなった時に、最近だとマネージドサービス系が結構いろいろあるじゃないですか。

我々もデータベースのマネージドサービスを使ったりとか、いろいろと工夫して使っているんですけど。もしサービスに大規模障害が発生してデータが lost しちゃいますっていう事態に備えるために、オンプレの時って結構うまくセカンドバックアップの仕組みを作ったりとかして、定期的にデータを退避しながら「もし何かあってもこのタイミングまで戻れる」と普通に仕組みとして用意されてたんですね。

パブリッククラウドでそういったマネージド系のデータを扱うようなソリューションとかだと、なかなか我々のレベル感まではやってなかったりとかもすることがあると思っていて、そこに対する工夫って何かやられてたんですか？

@keisuke.koike
EC2 のデータベースだと、例えば replication を組んで、そのバックアップをセカンドバックアップ（DR や内部犯行への対策のために、限られたメンバーしか触れない別リージョンへバックアップすること）用に取ることができていました。

それを AWS のマネージドサービス、Aurora で mysqldump を取ってしまうと、サービスに影響を与えるレベルでパフォーマンスが下がってしまったり、Aurora って IO 課金なので、すごく料金が上がってしまったりっていうことがあるので、極力マネージドサービスのものはマネージドのバックアップに寄せたいっていう要望がありました。そこでセカンドバックアップ用の仕組みを、僕がオーナーで作りました。

@nekokak
それはどういう仕組みにしたんですか？

@keisuke.koike
AWS Backup っていうバックアップ用のマネージドサービスがあるんですけど、それが Aurora に対応するようになったので、それでスナップショットをまず取って、更にその AWS Backup の仕組みでクロスアカウントにそのスナップショットを移すことができるようになったので、あらかじめ作業ができる人を絞ったアカウントを作っておいて、そのターゲットのアカウントに全アカウントの Aurora のスナップショットを移すことで、セカンドバックアップとして使うような仕組みを作りました。

実は最初は、全部自分でドキュメントを読みながら実装していて、AWS Backup を使わない仕組みで作ってたんですよ。Lambda と Python boto3 とかで全部できるなと思ったのでやってたんですけど。そうすると先輩エンジニアから「AWS Backup でマネージド全部できるようになるから、そっち使った方がいいんじゃないの」って教えてもらって、それでそっち（AWS Backup）に作り替えるってことをやったりしました。

@nekokak
先輩エンジニアは、AWS Backup があるってのはどうやって知ってたんですかね？

@keisuke.koike
やっぱり、先輩って情報収集能力が高いですよね（笑）。

@nekokak
なるほど、なるほど（笑）。

@keisuke.koike
見習わなきゃなと思ってすごい真似してるんですけど。AWS Backup を使おうって変えた後に色々と実装しながら出てきた問題点とかあったんですけど、そういうのは AWS さんに結構密に連絡を取って「ここ何とかなりませんかね？」っていうのを相談したりしました。

@nekokak
あれですよね、我々って普段から AWS さんだったりとか、Google Cloud さんだったりとかと具体的な課題を共有しながらお話をすることができるのが僕はすごくいいなと思うんですけど、実際に AWS さんやGoogle Cloud さんとかと相談しながら進めていくってのは結構普段からやられてるんですか？

@keisuke.koike
AWS さん Google Cloud さんに『オフィスアワー』っていうのを入れていただいているんですが、そこで相談することもありますし、パブリッククラウドチームとして月一回、AWS さんとか Google Cloud さんとかと定例をする機会があって、その中でクラウドベンダーさんから「こういう機能があるから使ってみませんか？」っていう提案を受けることもあります。逆に DeNA から「こういう風な課題を持ってるんだけど、どうにかなりませんか？」っていう相談をしたりとか。そういう感じでかなり密に連絡を取ってます。

@nekokak
こちらの事業状況だったりとか、サービスの特性とかを先方に知っていただいた上で、提案してもらったりお話できるのはすごく有り難いですよね。

@keisuke.koike
本当にそう思います。

@nekokak
実際にあった事例としては、AWS さんから「IVS というソリューションを新しく出すので、 Pococha の視点からのフィードバックが欲しい」だったりとか。

こういった協力関係みたいなものを築けているのは、エンジニアが DeNA でチャレンジをしたり、取り組みをする中での面白さの一つかなっていうのは僕自身も感じますね。

@keisuke.koike
そうですね。多分、AWS さんも Google Cloud さんも利用者の声を聞きたいっていう風に思ってくださっていて。「どういう機能が欲しいですか？」っていうのをヒアリングとかしてくれるので、すごく有り難いなと思いますし、先ほどお話しした AWS Backup の件とかでも、機能要望とかをあげていったら、本国のエンジニアの方と話す機会とかもいただけて。1時間くらいかな。そこの中で「こういう機能が欲しい」っていうすごい熱い想いを伝えられたりもすることができたので、そういう機会を作ってくれるっていうのも、DeNA のいいところなのかなと思いました。

@nekokak
そうですね。僕も先方と話した時によく言われたのが「​​feature request をどんどんくれ」って言われるんですよね。やっぱりそれって顧客の声じゃないですか。そういうのは彼ら自身も求めているが故にこういうコミュニケーションが取れる、っていうのはやっぱりあるんでしょうね。小池さんもすごく面白い経験をされてますね。

@keisuke.koike
そうですね。すごい緊張したんですけど（笑）、しかも英語で話さなきゃってすごいビクビクしてたんですけど、通訳を付けてくださって。すごく面白い機会でした。

@nekokak
いいですね。

我々ってどちらかというとサービスを使い倒すタイプで、且つものによってはすごい大規模のトラフィックがある中で、パフォーマンスチューニングだったりとか、ベンチマークみたいなことも結構やるじゃないですか。だから、ベンチマークとかをやっている中で、いつの間にかクラウドのソリューションをハックしてるというか、いろんなところの問題点に気づいたりとかすることも結構あるんじゃないのかなと思うんですけど。その辺りで何かありましたか？

@keisuke.koike
クラウドってマネージドサービスがいっぱいあると思うんですけど、そのマネージドサービスもブラックボックスとして使うのではなくて、新しくマネージドサービスを使うのであれば、それが DeNA のインフラのクオリティにちゃんと届いているか？っていうのを確認するために、必ず負荷試験とか検証をやってるんですけど。その中で「あれ、なんかドキュメントと書いていることと違うな」とか、「これバグじゃないかな？」っていうのを見つけたりだとかはすごくあって。それを各ベンダーさんに「これって、こういうことですか？」って聞いて、直していただいたりとかっていうのもありますね。

@nekokak
一般的には、マネージドサービスってクラウドベンダーさんがいい感じでやってくれるっていうのが売りでもあるから、そこら辺は「いい感じやってくれるだろう！」くらいの感じでコードだけ変えて使う、というのが世の中的に多いのかなと思うんですけど、DeNA のインフラチームはそうではなく、ちゃんと自分達で確認をするっていうのを必ずやるんですね。

@keisuke.koike
やっぱり、「クラウドベンダーさんのせいで障害になった」っていうのは完全に言い訳でしかなく、DeNA のクオリティとしては許せないので、ちゃんと確認するっていうことをやってます。

ベンダーさんとかからも「ここまで負荷試験されるお客さんもなかなかいないですね」って言われたりもするので、やっぱりそうなのかなって思ったりしますね。

@nekokak
そうですよね。負荷試験や確認をやることによって新しい発見もあったりとか、それこそ、その問題を見つけたときにそれをフィードバックすることによって、我々だけじゃなくてそのソリューションを使う他の会社さんだったりとかにいい影響を与えているんじゃないかなって、個人的に思っていて。

@keisuke.koike
はい、そうです。『お互いに高めていく』関係だと思っているので、別にどっちが偉いとかじゃないと思うので、一緒にいいものを作り上げていけたらなと思いますね。

@nekokak
そうですね。それはすごくいい発想だと思います。あれ、まだ新卒今3年目になったばかり？

@keisuke.koike
今、4年目ですね。

@nekokak
そうか、4年目になったんですよね。

そうなると、この3年間の濃密さ加減が半端ないっすね。

@keisuke.koike
なんかもう、本当にジェットコースターみたいな（笑）。いい意味ですごい急角度に成長できたので。すごい嘘くさいですけど（笑）、本当にいい環境に入れてもらったなと思ってます。

『DeNA のインフラ部門がすごいなと思うのは、コミット力』

@nekokak
これを読んでくださっている方たちからすると、実際に我々が扱ってるサービスとかってどの程度の規模感なのか興味があるかなと思うんですけど、言える範囲でサービスの規模感とか教えていただけますか？

@keisuke.koike
そうですね。昨年、 南場さんが AWS Summit Online でお話しされてた んですけども、まさにあの通りで、例えばオンプレサーバでいうと3,000台ぐらいだったりだとか。データ量全体でいうと、ペタバイト級だったりとか。あとは、リクエストの多さとかも秒間数十万リクエスト per sec ぐらいだったりとか、そういうかなり強烈な規模感かなと思っています。

@nekokak
その中でね、どんどんクラウドにしていってそれを3年間でやり切ったって、本当にすごいなと思います。

@keisuke.koike
やっぱり DeNA のインフラ部門がすごいなと思うのは、コミット力のすごさだと思っていて、『やるといったらやりきる』っていう。

@nekokak
それは本当にそうですよね。半端ないですよね。昔から僕もそう思うんですけど、絶対にやりきりますからね。

@keisuke.koike
これ言っていいかわかんないんですけど、3年のクラウド移行計画で、僕たちが入ったのが2019年なので計画の中盤ぐらいの時点だったですけど、「いやこれ、絶対残りの期間で終わらないだろう」っていう風に僕が入った時は見えてて。けどそれをちゃんと3年でやり切っていたので、コミット力はすごかったなと思いました。

@nekokak
ぴったり3年でやりきりましたからね。すごいなと思いますね。その中で、それだけの規模感を扱っているシステム群があって。で、それを通常のやり方で運用してたりとか、構築してたりとかすると、どう考えてもランニングコストというか、メンテナンスとか運用の工数がかかってくるじゃないですか。それに対して、いろんな仕組みを作ったりとか、効率良くしていくってのってすごく重要になってくると思うんですけど、その辺りで何か取り組まれてたことってあるんですか？

@keisuke.koike
身の回りが自動化され過ぎていて、なかなかぱっと出てこないんですけど（笑）。

例えば、最近自分で作ったやつだと、AWS の IAM とかをアクティブディレクトリ（社員情報）と自動で比較して、部署が入れ替わった人がいたら『この人は部署が変わっているけど IAM を残してていいの？』っていうのを自動で通知してくれる機能とかをサクっと作ったりとか。

@nekokak
サクっとってどれぐらいで作ったんですか？

@keisuke.koike
1日もかからなかったと思います。

@nekokak
おー！何気に、権限管理ってめちゃくちゃめんどくさいじゃないですか。DeNA の場合って、組織変更とか、異動とか、兼務付けて外したりとかが結構、頻繁にあるんで、ちょっと油断するともう余計な権限が付いたままの状態で放置される。で、それがセキュリティイシューになりかねないっていうのがありえるじゃないですか。

そういう課題をちょっと1日くらい時間かけて仕組みを作って、そこも自動で棚卸ができるようにするっていう発想ですよね。

@keisuke.koike
そうですね。

これを言うと、DeNA のインフラ部分をすごい売り込んでいるように聞こえるかもしれないんですけど（笑）、インフラってあんまりコードを書かないイメージがあると思うんですけど、DeNA のインフラ部門って逆にコードが書けないと一人前じゃないっていう文化なので『みんながエンジニア』なんですね。そういう自動化をみんなができるので、すごくいいところかなと思います。

@nekokak
徹底的に自分たちのやってることを効率良くするために、自動化する仕組みやツールを作っているってことですね。

@keisuke.koike
はい、そうですね。

新卒もインフラ枠って募集していないと思うんですけど、それもやはり大規模インフラの経験なんて学生時代に絶対できないので、そこの経験を全く問わないので、まずはソフトウェアエンジニアとしての力をつけてきて、それからインフラ部門に入ってきてねっていうメッセージなのかなと思ってます。

@nekokak
なるほど。

そういえば、インフラ部門だけじゃなくて、セキュリティ部と連携しながら、セキュリティの自動監査みたいなこともやったりされてますよね。

@keisuke.koike
そうですね、セキュリティ自動監査や脆弱性の自動監査だとか、あとはクラウドコストの自動監査とか。そういう風に全体最適化のためのいわゆる SRE 的な取り組みとかも、パブリッククラウドのチームだけじゃなくてセキュリティ部と協力して取り組んでいますね。

@nekokak
小池さんとのお話を通して、DeNA のインフラチームや SRE のチームがどういう雰囲気の人たちかってのはなんとなく見えてきたなと思ったんですけど、改めて DeNA の SRE の人達の考え方とか基本的な行動理念はどういったものになりますか？

@keisuke.koike
IT 基盤部には行動規範があるんですけど、その中ですごく僕が印象的だったのは『事象への執着』っていうのがあって。

何か障害が起きた時にとりあえずの対応、っていうのはいっぱいあると思うんですよ。根本的な対応じゃなくて。でも一次対応だけっていうのは、IT 基盤は絶対に NG で。なぜそれが起きて、それを次回起きないためにはどうするかっていうのを、徹底的に事象を追求して深掘りをするっていうことがとても大切にされてます。

@nekokak
いやーそれ、自分もありとあらゆるところで感じますね。徹底的に課題や問題を深掘りをしていく中で、こんなエピソードがあったとかありますか？

@keisuke.koike
最近だと、MySQL の failover の MHA の仕組みが失敗したっていうのがあって。とりあえず一次対応として failover をちゃんとやり切ってサービスに影響ないところに持っていった後に、「なんでそれが失敗したんだろう」っていうのを僕と後輩エンジニアで色々とログを読んだりとかしていって深掘りをずっとしていきましたね。それで結局、原因を追求して、コードのバグとかもあったんで、修正とかをしたっていうこととか。これは一例ですけど、そういうのがいっぱいあります。

『インフラは、「裏方」ではない』

@nekokak
小池さん個人でもいいですし、SRE のチームという観点でもいいんですけど、今後チャレンジをしていきたいことだったりとか、野望みたいなのがありますか？

@keisuke.koike
インフラエンジニア、SRE っていう観点での野望なんですけど、「インフラエンジニアって裏方でしょ」って言われるのがすごく悲しくて、そういう風なことを変えていきたいなと思ってます。

インフラエンジニアみんなが思っているかっていうのはちょっとわからないんですけど、個人的にはインフラエンジニアって裏方ではなくて、そのサービスの中のインフラという機能を作っているっていう『サービスを作っている側』だと思っていて。そういうマインドがないと、深夜に起こされて障害対応とか絶対できないと思っているんですね。

@nekokak
そうですよね。

@keisuke.koike
はい。だから、やっぱりサービスへの愛は絶対あるので、そういう風には言われないように、縁の下の力持ちであるのはもちろん大事なんですけど、もっと『サービスを作っている側』だっていうのを強く出していきたいなと思っています。

@nekokak
僕もインフラのメンバーや SRE メンバーを見ていても、誰よりも責任感を持ってサービスを維持する！安定的に提供する！ということにこだわってるじゃないですか。

規模の小さい感じでやっていく時にはそこまで考えなくていい部分はあるかもしれないんですけど、やっぱり一定以上のトラフィックが来た時に安心・安定的に使ってもらわないと、サービスとしての価値ってどんどん下がると思うんですね。『価値を下げない』ことに対するインフラチームのコミットメントは本当にすごいなと思いますね。

技術的なところで小池さんがチャレンジをしていきたいなとか、こういうことに取り組んでみたいなとかありますか？

@keisuke.koike
入社してから、自動化とかいわゆるインフラエンジニアとしては、結構レイヤーが高い部分にすごい取り組んできていて、そこでのバリューは出せるようになってきたなと思うんですけど、やはりまだ4年目なので、ハードに近い部分というか、ミドルウェア以下の深いところにまだ入り込めてないなっていうのをすごい自分として課題感があるので、例えば、データベースだったり、そういうのにもっと深く知識をつけて一人前の強いエンジニアになりたいなと思ってます。

@nekokak
あとは Graviton ですよね。

@keisuke.koike
ああ、そうですね。Graviton を入れられると、かなりコストが下がるのでどんどんやっていきたいですし、あとはそのデータベースでいうと、運用負荷がすごい高い、Write のスケーリングとかができない仕組みを使っていることが多いので、例えば TiDB だったり、Spanner だったり、そういう風にどんどん Write のスケールもできるような、DeNA ではいわゆる 第3世代 って呼んでるんですけど、そういうデータベースを使っていきたいとか、そういう野望もあったりしますね。

@nekokak
なるほど、そういうチャレンジをぜひ積極的にやってもらいたいですね。小池さんご自身もやられてると思うんですけど、DeNA のインフラチームは、ブログや、カンファレンスで頻繁に発表したりしているので、引き続き我々が学んだ知見だったりとかを積極的に対外的に発信していけるといいですね。

@keisuke.koike
はい、そうですね。

@nekokak
すごく期待してますので、今後ともぜひ頑張っていただきたいなと思っております。

ということで、今回は DeNA の SRE チームのリーダーである小池さんに来ていただきました。DeNA のいろんなインフラの取り組み、クラウドの活用について、少しでも皆さんにお伝えできていれば、我々としても嬉しいです。

本日は以上となります。ありがとうございました。

@keisuke.koike
ありがとうございました。