サイバーエージェントアメリカでエンジニアとして働く鷹雄健氏（写真1）は，スマートフォン向けの広告事業を展開しているAMoAdで利用していたシステムの内製化プロジェクトに参加，無事カットオーバーに至りました。そのプロジェクトが始まった背景や，移行したシステムの構成，そしてサイバーエージェントにおける広告配信システムの今後などについて伺いました。

サイバーエージェントのノウハウで早期の内製化を実現

――どのような背景からシステム内製化プロジェクトが始まったのでしょうか。

鷹雄：これまでサイバーエージェントでは，事業の立ち上げにおいてスピードを優先してきました。このため，ビジネスで何らかのシステムが必要になったときに，内製ではなく外注，あるいはASP（Application Service Provider）が提供するサービスを利用するケースがあります。

スマートフォン広告ネットワークサービスを運営しているAMoAdにおいても，事業スピードを優先し，あるシステムでASPを利用していましたが，システムの柔軟性向上や課題の解決などを目的として，2013年1月にそのシステムを内製化することが決まりました。

この移行作業は本当に大変でした。最初のメンバーは私とJavaエンジニアの2名だけで，このままではいつまで経っても移行できないと判断し，まずはリソースを集めることに集中しました。最終的には，サイバーエージェントグループ全体のリソースやノウハウを活用することで，3ヵ月で自社にシステムを構築して移管することができました。

――今回の移行作業は3ヵ月で完了したということですが，もしサイバーエージェント全体のリソースやノウハウが使えなければ，どれくらいの時間がかかったでしょうか。

鷹雄：まったくわからないですね。そもそも移行できたのかすら怪しいと思っています。サイバーエージェントグループには1,000人以上のエンジニアが在籍していて，何か調べたいことがあったときに，それについて詳しいエンジニアにすぐに話を聞くことができます。もちろんインターネットや書籍でも調べることはできますが，難しいのは実現できないことについて答えを知りたいときなんです。多くの場合，何ができるのかについては書かれていても，何ができないかについてはあまり触れられていません。つまり，できないことについて調べていると，答えにたどり着けない可能性があるのです。しかし，実際に同じようなことで悩んだエンジニアに話を聞くことができれば，実現できないことがすぐにわかります。こういったところで，エンジニアが多数在籍しているサイバーエージェントならではのメリットをあらためて実感しました（図1⁠）⁠。

一般的なサーバで無停止システムを構築

――新しいシステムのインフラはどのような構成になっているのでしょうか。

鷹雄：サーバは100台以上あり，基本的にはオンプレミスで運用しています。外部のIaaS（Infrastructure as a Service）を利用しないのは，システム規模が大きくなるとオンプレミスのほうがコストを抑えられることと，システムの要件に合わせて柔軟に構成できることが理由です。

IaaSのメリットはハードウェアの運用管理負担を軽減できることだと言われていますが，それなりの規模でセキュリティに配慮しつつ，かつ冗長性も確保しなければならないというシステムでは，やはりインフラエンジニアがきちんと面倒を見ないと実現は難しいんです。そうすると，運用管理にもそれなりのコストが必要で，また仮想サーバの利用料金も相当な額になるため，オンプレミスで運用することを決めました。

――今回のシステムでは，サーバ仮想化技術は使われているのでしょうか。

鷹雄：すべてのサーバではありませんが，KVMを利用して仮想化しています。サーバを仮想化するというとパフォーマンス面でのオーバーヘッドが話題になることが多いのですが，KVMに関してはハードウェア構成や設定が適切であれば物理サーバと変わらない感覚で利用できます。また，仮想サーバを別の物理サーバへ移行したり，仮想サーバの作成や削除も簡単に行えたりと，運用負荷を軽減するメリットまで考えると，データベースサーバなど高負荷なものを除いて，物理サーバで直接運用する理由はあまりないのかなと考えています。

――プロジェクトを進めていく中で，難しかった点があれば教えてください。

鷹雄：今回のシステムで要件の1つとして求められていた完全無停止を実現することです。一般的なサービスであれば，たとえばサーバのスケールアップやスケールダウンといった構成の変更，あるいはバックアップの取得といった理由で深夜にサービスを止めることがあります。しかし，今回のシステムの要件は，どのような理由があろうと止めることはできない，というものでした。もちろん，ミドルウェアのダウンといったトラブルが起きてもシステムを稼働し続ける必要があるので，インフラやミドルウェアなど，さまざまなレイヤで冗長化を図っています。

特に難しさを感じたのはシステム全体の設計です。時間をかけることができれば，どうすればシステムを止めずに運用し続けられるかをじっくり検証できますが，カットオーバーが遅れれば遅れるほどビジネスへの影響も大きくなります。そのため，短い検証期間の中でベストな設計を見つけ出す必要がありました。この点は苦労したところです。

ハードウェアの耐障害性の向上という意味で言えば，まず選択肢として考えられるのは信頼性の高い製品を使うことです。ただ，そうした製品は概して高価であり，用途や要件によっては選択できないケースもあるでしょう。今回のシステムについても，高い信頼性が求められるシステムではありましたが，用途や要件を考えると信頼性よりも性能面にコストをかけたいところでした。実際，パフォーマンスの点ではFusion-IO社のioDriveを利用する形で投資しています。一方，信頼性については一般的なサーバを利用し，冗長化ができて，かつ低遅延で切り替えられるアクティブスタンバイ構成にすることなどによって，コストを抑えて対応しています。