優秀な若手エンジニアが成長できる場を作りたい

私は20代の後半にIT業界に入りました。SIerで大規模システムの開発を経験した後、ソーシャルゲームのインフラや解析システムを構築していました。複数のゲームのログを収集、解析する、今でいうビッグデータですね。

そのデータ解析基盤はHadoopやFluentdなどを活用して構築しました。その過程で、社内向けにFluentdのプラグインを作ったり、コミュニティに関わらせてもらったりして。そういうことをしていくなかで、OSSを活用して開発していくような、Web系のスタイルって良いなと思ったんですね。

ちょうどそのときにご縁があり、当時社員が5名程度だったマーベリックに入社しました。

前職の会社では、先輩や上司も尊敬する人がたくさんいて、社内環境も整っていました。ベンチャーだった頃から会社を作っていったような社員もいて、そういった人たちが作り上げてきたシステムって凄いと思ったんです。辛かった時期も含めてくぐり抜けてきた体験、って凄いじゃないですか。

自分はその恩恵を受ける側だったので、今度は自分より年下で優秀なエンジニアに、そういった場を提供したいなと思います。新しい仕組みを取り入れてみたり、仕組みを作る段階から関われたりする機会を提供することで、彼らの成長に寄与していきたいですね。

入社当時は2名だけだったエンジニアも、今では30名弱になりました。今どき珍しく物理サーバーを使っていて、かつトラフィックも多いDSPシステムなので、メンバー数の割にはシステム規模は大きいです。

100%ハウジングのDSPにも、クラウドで試したノウハウが活きる

弊社は、DSPのシステムと、紙媒体向けの広告サービスを取り扱っています。DSPのシステムは、100ms以内に入札のレスポンスを返さなければ、入札資格が無くなってしまうんですね。そのため、サービス開始当初からハウジング100%でスタートしています。

現在では、紙媒体向けの広告サービスなどは一部をクラウドに移行したり、ハイブリッドで構築しています。

ハイブリッドにすることで、相乗効果が生まれているように思います。最初はハウジングで始めて、良かった所はそのまま残しつつ、ちょっと面倒だったところはクラウドで構築するときに改善する。そして改善できた所を、またハウジングに持ち込む。

例えば、DSPの物理サーバーは200台以上にも及ぶので、構成管理ツール「Ansible」を使っています。

Ansibleも、最初にハウジングで構築したときは、nginxをインストールするとか、アプリをデプロイするといった用途に限られていました。それを、クラウドで新規構築するときに、Zabbixエージェントの設定も追加したり、ハウジングでは物理サーバーのOSインストールまでカバーするようになりました。

200台を超える物理サーバーの管理も「Ansible」で効率化

Ansibleは、サービス開始当初から活用しています。サーバーの台数が数百台にもなると、1台ずつ手でデプロイするというのはあり得ないですよね。Ansibleなら、ローカルからコマンドを叩くだけで、ターゲットのサーバーにsshで接続し、自動的に構築をしてくれます。

Ansibleなら、ミドルウェアのバージョンを統一することも簡単です。覚えることもそれほど多くなく、YAML表記で設定を書くだけなので、インフラ経験のある人であれば馴染みやすいと思います。

Chefも使ったことがありますが、当時は構築までが大変でした。まずChefのサーバーを用意して、ターゲットとなるホストにはChefのエージェントをインストールして・・・と、案外手間がかかりました。

一方Ansibleは、ローカルにPythonの環境さえあれば、ターゲットはsshで接続できるUNIX系OSなら何でも動きますし、最近はWindowsもターゲットにできるようです。

また、Ansibleなら構成管理用のサーバーも必要ありません。できたばかりのベンチャーにとって、新しいサーバーを立てるコストって痛いと思うんですよね。

1,000台管理するための1台ならいいですが、10台のための1台は痛い。特に、ハウジングだと数十万円のサーバーを追加するのはもったいないし、クラウドサーバーを1台だけ混ぜるというのもネットワーク的に難しいんです。

Slackへの通知も「いつの間にかできていた」

Ansibleでデプロイを簡単にしたとしても、「じゃあ誰が何をどこにデプロイしたの」というのは当然知りたいじゃないですか。そのため、弊社ではSlackと連携する仕組みを構築しています。YAMLにパッケージ化していて、デプロイするとGitのSHA1を含めたメッセージが通知されるようにしています。

この仕組みは、あるといいなと思っていたらいつの間にか部下が作ってくれていましたね。「あれ？Botが通知してるじゃん」って（笑）。

YAMLで書いたプレイブックはGitHubのリポジトリに置いています。プロダクトの構成が変わったり、サーバーの種類が増えたときに、誰でもプルリクエストが送れるように運用しています。

自由に扱えるハウジングの環境を、より効率化していく

Ansibleには今のところ、大きな不満はありません。今後は、弊社で使っているハードウェアのロードバランサやクラウドのWebAPIに対してもAnsibleが使えないか、試していきたいです。

また、昔のプロダクトほどAnsibleでカバーできていない部分があるので、そこも全て統合して、今よりもスピーディーに構築・運用できるようにすることが、今後の課題だと思っています。

ただ、サーバーの設定を少し書き換える程度であれば、Ansibleを使わないケースも考えられます。物理サーバーでよくあるのは、ハードウェア障害時に接続先を切り替えるというシチュエーションです。

このケースのために、わざわざありとあらゆる状態を想定したAnsibleのプレイブックを用意しておく必要はないと思うんですよね。

Ansibleのようなツールは、できるだけプロジェクトを越えて統一していきたいと考えています。個人で使うもの、例えば開発用のOSとかエディタというものは各々が好きなもの、得意なものを使って最大の生産性を発揮できる方がいいと思います。

ただ、ソースの管理はすべてGitHubにしますとか、コミュニケーションはSlackに統一しますといった、みんなで使うものとのメリハリを持たせていますね。

ツールに限らず、OSやミドルウェアも、果敢に新しいものを使っているので、知人や同僚にもよく「攻めてるね」と言われます（笑）。

インフラエンジニアにとっては、ハウジングのサーバーを駆使してトラフィックとレイテンシーに挑める良い環境なので、今後もその環境は継続して作っていきたいなと思います。（了）