• 株式会社サイバーエージェント
  • Ameba事業本部 エンジニアリーダー
  • 田中 清

「組み合わせ」次第で変わる!インフラエンジニア以外もサーバー構築が可能なAWS

今回のソリューション:【AWS】

アマゾン ウェブ サービス(以下AWS)は、Amazon Web Services, Inc.が提供する、WEBサービス/アプリサービスの開発者が必要とするインフラを提供するクラウドサービスだ。2006年7月のサービス公開後、日本国内でも近年、利用者が拡大し続けている。

株式会社サイバーエージェントで、2015年2月に配信を開始したソーシャルゲームの開発リーダーを務める田中 清さんは、3年前より同社でのゲーム開発においてAWSを活用している。AWSによって「インフラのブラックボックスが透明化した」と語る田中さんに、導入の経緯から現在の活用法に至るまでを聞いた。

ソーシャルゲームのエンジニアチームのリーダーを務める

現在はサイバーエージェントのAmeba事業部で、2015年2月に配信を開始したソーシャルゲームの開発チームに、プロジェクト発足当時から1年半ほど在籍しています。プロジェクトの人数は全部で約30名となります。

私はエンジニアチームのリーダーをしているんですが、メンバー構成としてはサーバーサイド4人、フロント5人、アニメーション専任が3人です。私自身の業務としては、メインがサーバーサイドで、AWSを使ったインフラ周りも手がけています。

サーバーサイド4人の役割分担として、私はインフラやアプリの基盤部分といったアーキテクチャーの部分を担当していて、残りのメンバーはギルドバトルのメインが1人、あとの2人はNode.jsを使った新規機能やイベントの開発を行っています。

AWSを使い始めたのはまだ事例の少なかった3年前

このゲームのサーバーはAWSを使っていますが、もともと初めて使ったのは3年前です。当時ピグのチームで新規スマホサービスを開発しようとしていて、せっかく新しいものを開発するので、当時の流れ的に伸びて来ていたクラウドサーバーに挑戦してみようかと。まだ世間的にも、社内的にも、ほとんど事例がないような時ですね。

導入した際の狙いとしては、まず開発と運用のスピード感を上げたいという目的がありました。それまで使っていた既存インフラだと、ちょっとした変更を適用するのにも時間がかかってしまっていたので。あとは新規サービスだったので、スケーラビリティーの点で柔軟に対応したいと考えていました。そういった点で、AWSはトータルでいいなと判断して導入することに決めました。

まずは検証を開始 2ヶ月でひと通り全てを試した

AWSを使う場合はどういう構成を組むかということがポイントになってくるので、当時AWSにあったサービスはほぼ、全て検証しましたね。検証の際に重視したのは、まずはサーバーを立てて動くかという点、分散ができるかという点、そしてゲームの動作性の部分です。実際にアプリを動かしてみると「動きが違う…」ということも当時はあったので。検証期間を2ヶ月ほど設けて、ひと通りテストしてから構築していきました。

最終的にはELB、EC2、S3、CloudFront、SNS、Route53等を組み合わせて構築し、1個のサービスにしました。当時すごくAWSが良いと思ったのは、機能追加が早くて、ユーザーの声を的確に反映しているんです。検証中に、できなかったことができるようになったり。

例えばELBで内部のサーバーにロードバランシングしたかったんですが、検討している段階ではできなかったんですね。それでEC2にプロキシサーバーを立てて実行しようとしていたんですが、そうしたらInternal ELBがリリースされて、内部のサーバーを負荷分散できるようになったんですよね。これはかなり嬉しかったです。

AWSで重要なのは「組み合わせ」を設計するスキル

そういった経緯でAWSを使い始めましたが、AWSだからって何か新しいことをあんまり意識したことはないんですよね。それが逆にいいところだと思います。あまりにも既存インフラと中身が違いすぎるとAWSのスキルがロックインされてしまいますしね。

AWSで重要になってくるのは設計のスキルですよね。構成もですし、分散の仕組みづくりも重要です。データベースでもAmazonのサービスをそのまま使うか、他のものを使うか。選択肢が数多くあります。「組み合わせのスキル」のようなものが必要で、それが設計技術の差になってくるのかなと思います。

サイバーエージェントのソーシャルゲームのサーバー構成とは?

今開発しているサービスは、実は最初は社内データセンターを使っていたんですよね。でも、ギルド対ギルドのリアルタイムバトルがあり、それをゲームのメイン機能として考えています。そこでリアルタイム処理実現と開発工数を考え、Socket.IOというライブラリを採用しようとしていました。しかし、社内データセンターのネットワーク構成上、他サービスへの影響も踏まえた時に不都合があり、AWSへ移行したという背景があります。

システム構成としては、アプリケーションサーバーとしてNode.js、バックエンドにはMongoDBを使っています。あとはWebSocketを使ったリアルタイム通信が動いていて、ブロードキャストしたい時だけサーバーからソケットサーバーに飛ぶ仕組みができています。後からサーバーを足せる状態には常にありますが、現状はオートスケールの仕組みは使っていません。

アプリエンジニアでも使えるAWSを、今後も活用したい

AWSを使うことで、アプリエンジニアでもインフラエンジニアと協力しつつ、システム全体のことを意識するきっかけになるのが大きいと思っています。社内データセンターを使っていると、どうしてもインフラメンバーに頼ってしまい、それがエンジニア間の壁に繋がっていく気がします。AWSだと全部可視化されていますし、コードを書くだけでインフラの操作もできますので。今後サーバーサイドでもアプリでも、より多くのエンジニアがAWSの設計ができるようになって使いこなしていくといいのかな、と思います。

;