2015年12月25日

その先の世界へ

はてなブックマークに登録

このエントリーは、KLab Advent Calendar 2015 の12/25の記事です。

最終日なので緊張・・・はさすがにしません(笑

はじめに

KLabがゲーム事業に参入して今年で6年になります。 当時生まれた赤ちゃんが来年小学校へ入学する年月ですね、時が経つのは早いものです。

年末の締めの記事ということで、今年を振り返るような内容にしようかともおもいましたが、 2009年から現在までを技術者(CTO)の視点でざっくりと振り返ってみようとおもいます。

2009年

mixiアプリで「恋してキャバ嬢」をリリースしました。 恋キャバはおかげさまで今でも多くの方々に楽しんで頂いてますが、リリース当初は大量のリクエストを処理しきれずにサーバがダウンしてしまい、新規のユーザ登録を停止せざる得ない状況にまで陥ってしまったことがありました。(当時のユーザのみなさんほんとごめんなさい)

これまで経験したことのない膨大なトラフィックにあたふたしながらも、ボトルネックの調査方法や アプリケーションの軽量化、MySQLのチューニングテクニックなど、ソーシャルゲームの開発と運用に必要な様々なノウハウを習得することができました。

この時の経験は翌年にリリースした「DSAS Hosting for Social」に活かされており、現在でもサーバサイドの負荷対策のベースとなっています。


年始年末も休まずに深夜まで負荷対策に明け暮れていたのは今となっては良い思い出です。

この頃はつらかったけど楽しかったなあ・・・

2010年〜2011年

フィーチャーフォン向けのブラウザアプリ全盛期で、比較的短期間に数多くのタイトルをリリースしました。

技術要素としてはサーバサイドでの軽量な画像合成機能や動的なFlash生成技術などが必要とされ、これらを実現するためにKGDFlamixerといったツールが生まれました。

この頃はすべての案件がPHPで開発しており、フレームワークは symfony を独自拡張(mixi/Mobage/GREEのAPI呼び出しを隠蔽)したものを利用していました。 このフレームワークのおかげで、アプリケーションはプラットフォームの差異を気にする必要がなく、ひとつのアプリを簡単に複数のプラットフォームへ展開することができていました。

また、当時社内でよく聞いていた単語で印象に残っているのが「ヨコテン」とか「ガワガエ」といったものです。 基本的なゲームの骨子が似たものが多かったため、以前作ったゲームをベースにして低コストで新しいゲームを作りたくなりますが、新しいゲームには新しいアイデアやゲームシステムが追加されることが当たり前なので、斬新で面白いゲームを目指すほど古いコードやデータ構造が足かせになってしまい、逆に開発期間が伸びてしまうようなケースもあったように思います。

汎用性や再利用性を重視して設計したとしても、それが必ずしも未来において役に立つ保証はないので、手間ひまかけて時間を書けて設計・実装するより、短期間で開発できることを重視したほうがいいのかな、、とか思いつつ、かといってあまり設計で手を抜きすぎると機能追加や不具合改修時に支障をきたしてしまう恐れもあるので悩ましいところでした。

しかも当時は、多数の開発ラインが同時進行していたこともあり、綺麗に汎用化して実装できるほどの余裕がなかったのも事実で、結局のところ、開発メンバを信頼して「うまくやって」とお願いするしかなかったなあと振り返ってみたりしています。

現在では組織上に「共通基盤G」というグループがあり、全社的に共通化することが望ましい機能を切り出した上で、専任の開発ラインを組める体制ができています。


大晦日の23:30過ぎに大規模なDB障害が発生して元旦の夕方まで対応に追われたことは今となっては良い思い出です。

この頃もつらかったけど楽しかったなあ・・・

2012年〜2013年

スマートフォンの普及に伴い、スマホゲームの開発に着手したのがこの頃です。

最初はどうやって作ればいいのかさっぱりわからなかったので、アプリ開発の経験がある技術者を中心に開発体制を組み、JavaとObjective-Cで開発してみました。

これがまた想像以上に大変でして、開発を担当した技術者からは「この手法でゲームを開発するのは二度とやらないほうがいいよ」との声が上がってきました。Android版とiPhone版のソースコードが別管理になっているため、機能追加や動作検証に多大な手間と時間がかかる上、両方のプラットフォームに対応できるように技術者をアサインする必要があったのです。

では、今後はどうやって開発するのが良いのか考えてみたところ、

  • ゲームロジックをプラットフォームに依存しない共有言語で記述できる
  • AndroidやiPhone向けの処理に変換してビルドできる
こんなツールがあればいいよね、という話になり、実際に作ってみることにしました。 それがKLab製のゲームエンジン「Playground」です。

ちょうどこの時期に某案件で「リズムアクションゲームをつくりたい!」というニーズがでてきており、Unityの開発はノウハウがなかったですし、JavaとObjective-Cで作るのも避けたいということで、ゲーム開発と平行してPlaygroundの開発を本格的に進めることになりました。

このゲームの肝は「音楽をいかに遅延なく再生させるか」ということでした。通常の音楽プレイヤーであれば多少の再生遅延は許容できるかもしれませんが、このゲームではそうはいきません。また、より多くのユーザに遊んでもらえるよう、比較的低スペックな端末でも正しく動作することを目指して「軽量」と「高速」にとことんこだわりました。その反面、3Dを多用するようなリッチなゲームには向いていないので、そこはUnityにおまかせすることにしました。

それから、本格的にUnityを採用して開発するようになっていくわけですが、使ったことのないものを導入するには時間がかかるものです。とりあえずゲームを作ったとしても満足の行く品質に仕上がるかどうかはわからないといった心配もありました。

決してUnityが悪いとかそういう話ではなく、どんなツールも使いこなせなければ本来の性能は発揮できないので、品質の高いアプリを開発するには「Unityを正しく使いこなせるようになること」が必須の課題と考えていました。この課題を解消するため「Unity世話役」というチームを作ったりして様々な対策をしてきましたが、具体的に何をやったのかは、ひとことでは説明しきれないので今回は割愛させていただきます・・・

あと余談ですが、インフラでAWSを本格的に活用し始めたのもこの時期です。 海外向けのゲームをリリースする際に、日本のサーバを利用するのが怖かったというのが大きな理由でしたが、ものすごい勢いで押し寄せてくるクラウド化の波を無視しきれなくなってきたという側面もありました。


年越しで嫁の実家に親戚が集まった際、人目を気にせず某リズムアクションゲームをひたすらプレイしていて白い目で見られていた気がするのも今となっては良い思い出です。

いろんな意味でつらかったけど楽しかったなあ・・・

2014年〜2015年

スマホアプリが主流になっても、サーバサイドはWebサービスで培ってきた技術を利用し続けています。アプリとサーバはHTTPで通信してJSONでデータを送受信するのが主流となっており、テンプレートエンジンでHTML化しなくて済むのでサーバの処理は軽くなったと思います。また、ブラウザゲームでは画面遷移の度に通信が必要でしたが、アプリでは必要なときだけ通信すればよいのでHTTPのリクエスト数が大幅に削減できるようになりました。

また、去年から今年にかけてサーバのリプレースを進めており、1台あたりの性能が飛躍的に向上しています。2Uや4Uのスペースが必要だったDBサーバも1Uで収容できるようになって集積度が向上しましたし、SSDの導入によって以前とは比べ物にならないI/O性能を実現できるようになりました。

負荷対策に追われていた日々が嘘のようですね・・・

サーバサイドの技術はこのまま安息の日々を送るのかな、、などと思っていたらあらたな課題が浮上してきました。 チャットや共闘機能などの常時接続型のサービスです。

HTTPでもWebSocketを使えば常時接続型のサービスは可能ですが、バックエンドのPHPをどうにかしなくてはいけません。もしかするとPHP+WebSocketも可能かもしれませんが、ここであえてPHPにこだわる必要はないですよね。

おそらくMMOなどを運用されているような老舗のゲーム会社さんは、長年をかけてシステムを開発され、品質向上に取り組んでこられて、十分なノウハウをお持ちだと思いますが、当社のようにWebサービスを主体としてきた会社にとっては全く未知の世界です。

WebサービスではApacheやnginxなどのWebサーバに依存できるので、アプリケーションは「稼働し続けること」を意識する必要はありません。リクエストに対するレスポンスを返してしまえば終了してよいのですから。

しかし、常時接続型のサービスでは、自分自身が稼働し続けなければいけないわけで、安定稼働できるサーバを開発するとなると、技術的にまかせられる人はいるものの、品質を担保しながらチームで開発して運用した実績はありませんでした。

まあ、実績がないなら作ればいいわけで、やってみないとわからないならやってみればいいんですね。どんな手段で実現するかを開発者のみなさんにおまかせしたところ、

  • Python + tornado で書く
  • Go言語で書く
  • 外部のサービス(PhotonCloud)を利用する
これらの手法が選択されてリリースされています。 特に社内ではGo言語に対するモチベーションが高く、最近ではインフラの運用スクリプトなどもGoで書かれていたりします。

現状は試行錯誤を続けながら開発運用実績を積んでいき、KLabとしての最適解を選択できればよいかなと考えている次第です。


昨年の年越しは古いDBサーバを利用している案件が年始年末イベントの負荷に耐え切れず、障害を発生させてしまいましたが、今年はSSDに入れ替えたので大丈夫だと信じています。

これもきっと来年には良い思い出になることでしょう。

まとめ

辛いこともあるけれど、私はこの仕事が大好きです。落ち込んだりもしたけれど、私は元気です。

来年もよろしくおねがいします。

klab_gijutsu2 at 18:10│Comments(0)TrackBack(0)

トラックバックURL

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔   
 
 
 
Blog内検索
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント