ニュース
ウェブからゲームに採用が広がる「AppDynamics」とは何か？
北米ではEAやBlizzardが採用するアプリケーションパフォーマンス管理ツール
2017年2月6日 10:00
- 12月取材
- 新日鉄住金ソリューションズ社内（東京）
「AppDynamics」というプロダクトをご存知だろうか。「AppDynamics」とは、ウェブの世界、特にアメリカのECサイトで広く利用されているアプリケーションパフォーマンス管理ツールで、ウェブサイトへの来訪者のアクティビティを監視、分析して、サイトの問題点を定量的に分析するツールだ。アメリカでは、オンライン旅行サイト「エクスペディア」や、証券取引所「NASDAQ」、全米第3位のモバイルキャリア「Tモバイル」、ネットワーク機器の最大手「シスコ」など、名だたる企業が本製品を活用している。日本においては、グルメ情報サイト「ぐるなび」が、「ぐるなび」のメインサイトを始めとして、同社が運営する多数のグループサイトにて、「AppDynamics」を活用した状態監視や問題点の分析を行なっている。
オンライン取引やカスタマーケアが企業活動の生命線とも言える大規模なサイトでは、サービスがいつでも水や空気のように当たり前に円滑に作動していることが、企業の販売戦略上、高い重要度で位置付けられている。だからこそ「AppDynamics」を採用して、問題点の洗い出しに注力していると言えるだろう。
この「AppDynamics」が、近年では、ゲーム業界においてサーバーの状態監視、問題のあるコードの発見、ユーザーアクセス動向の分析ツールとして活用されつつある。日本国内ではまだ事例がないが、アメリカでは、EAやBlizzardがすでに本製品を導入して、ゲームサーバーの開発、運用に役立てているという。
筆者の知る限り、ユーザー側のゲームクライアントと通信して、ゲームそのものの処理を行なうゲームサーバーに対して、サービスを停止することなくサーバープログラムの問題点の把握を、コードレベルで行なえる汎用ツールというものは存在しない。これが本当だとすれば、枯れていないゲームサーバープログラムにとって、実に有用なソリューションとなるはずで、非常に気になる存在だ。
そこで、今回は本製品の日本での販売パートナーである新日鉄住金ソリューションズにお伺いして、本製品の概略をお伺いすることにした。話を聞いてみれば、なるほどと納得する部分もあり、活用の方向性も見えたように思う。本稿では、「AppDynamics」の具体的な機能を紹介すると共に、導入を検討すべき企業像を大きく2つのケースに分けて、実際に活用可能なシナリオを考えていきたい。
AppDynamicsが新たなアプローチで解決する諸問題
AppDynamicsとは、言い換えればデータマイニングツールの一種だ。そもそも、ウェブ用のデータマイニングツールそのものは古くから存在し、それこそインターネットがポピュラーになった1990年代から多種多様なツールが開発されてきた。古典的にはアクセス、リファラといったテキストのログデータを事後的に解析して分析するものに端を発している。ユーザー側のクッキーやブラウザとのセッションにユーザーの振る舞いをトレースしやすくする情報を加えるようになり、ページがリクエストされたときにウェブプログラムが実行されるのが当たり前になってからも、収集したデータをリアルタムに利用可能にするためにログデータの格納方法に工夫が加えられることはあっても、基本的な部分はそう大きく変わらずに、現在でも利用されている。
サービス中のサーバープログラムの不具合やエラーといったものは、プログラム内にデバッグに必要な情報をログとして吐き出すようにコーディングしておき、丹念にそのログを追いかけることで、問題の核心を突き止めて修正していくのが基本だ。開発中ならゲーム画面やウェブページに出力することも可能だが、デバッグ表示は美しいものではないし、詳細な内部のパラメータまでもエンドユーザーに見せるわけにはいかないからだ。
しかも、サーバープログラムは、ユーザーのデータを破壊したり、著しく誤った結果を蓄積してしまうといった、取り返しのつかない深刻なエラーが生じない限り、基本的に止まってはならない。サーバープログラムが停止してしまうと、ゲームで言えば「プレイ不能」という、最悪の事態に陥ってしまうからだ。ログデバッグが基本なのは、ウェブのみならずモバイルを中心としたゲームにも、よく利用されるPHPやPythonといったスクリプト言語はデバッグ機能が充実しており、さほど特別な手続きをしなくてもログデバッグが始められるということも背景にはあるだろう。
ところが、ログデバッグでは画面表示と突き合わせることができないため、問題の発生時点の状況を把握しにくく、原因の特定に時間がかかることが多い。ログに対して、過不足なくデバッグに必要な内容を出力できていればまだ良いが、経験的に充実させていくことも多いため、当初はログ情報が不足することも多い。
通常のスタンドアロン、あるいはクライアント側のプログラムの場合、最も強力なツールはデバッガだ。デバッガを使えば、プログラムのエラーでクラッシュした場合でも、そこから遡ってプログラムのどこを通ってきたか知ることができるし、値の変化を見ながら、1ステップずつ実行していくことも可能だ。こういった、プログラマにとって、いわば“当たり前”のデバッグ方法が取れないのが、サーバープログラムの修正を、より困難にしている要因として大きい。
「AppDynamics」は、この問題を解決してくれる。「AppDynamics」エージェントのパラメータとして、ゲームのサーバープロセスを与えて起動すると、「AppDynamics」エージェントが起動して、その子プロセスとしてゲームプロセスが起動する。ちょうど、あらゆるプロセスをデーモン化する「Supervisor」や「Daemon Tools」のイメージだ。この状態で、仮にゲームプログラムがクラッシュすると、「AppDynamics」エージェントがクラッシュログを記録し、それに付随してデバッグ情報をダンプしてくれる。この結果、プログラマは、任意のテスト環境などで、バックトレースして不具合の原因を追求することができるようになる。エージェントは、サーバープロセスの死活監視の機能も有しているため、クラッシュ後のサービスの復旧も自動的に行なうことができる。ここまでの導入の流れに対して、何ら特別な設定は必要とせず、エージェントプログラムを導入した直後から、デフォルトの状態で動作させることができる。
日常的なサーバーの状態監視ツールとしては、「AppDynamics」エージェントをインストールしたサーバー群を配したサービス構成マップを自動的に作成し、さらにそこに処理の流れを視覚的に表示する機能がある。構成マップはウェブベースのフロントエンドで、先に触れたクラッシュログやバックトレースの表示も、このウェブフロントエンドを起点にして行なうことができる。また、サーバープロセスの性能分析という意味では、エンドユーザー側からのネットワーク応答時間、各セグメントの通信帯域の状態、CPUロードやメモリ使用量といったサーバーハードウェア、プロセスの稼動状況を定量的に分析して、エンジニアに対して問題点を視覚的に通知する機能がある。
AppDynamicsを導入すべき2つのシナリオ
さて、日本のゲーム会社の場合、実際のところ、いったいどういったゲーム会社なら、本プロダクトを活用できるのだろう。お勧めできるのは、以下の2つのシナリオだ。
ひとつは、スタートアップしてから経過年数の少ない、まだ若い企業だ。サービスしているタイトルが1作品、あるいは2～3作品であれば、まだまだ自社のスタイルが確立しているとは言えず、場合によってはタイトルごとに個別の改良を重ねてきた結果、むしろ共通化が課題であるかも知れない。
あるいは、限られた人員をゲームのコア部分の開発に投入せざるを得ない状況が続いてしまった結果、デバッグ環境や情報量の見直しに取り組むことができずに、些細なバグが積もり積もっているケースもあるだろう。こういったケースでは、「AppDynamics」を積極的に検討できるはずだ。たとえ、現状の社内ツール環境に大きな不満がないとしても、将来的に大きな問題になるかも知れないし、問題を解決するために、多大なコストを投下することになるかも知れない。過去に投下したコストが少ないうちなら、まだまだ“もったいない”と感じるほどではないはずだ。
もうひとつは、長期に渡って複数のタイトルの運営を続けてきて、必要十分を満たす分析ツールを自社で用意していても、スタッフ間で問題点を共有できていないケースだ。叶氏によると、「AppDynamics」をエンジニアのみならずプロジェクトメンバー全員で活用すれば、サーバーを管理するエンジニアと、プロジェクトマネージャーやプロデューサー、マーケッターといった営業的側面を担う人との“共通言語"ができるのだという。なるほど、確かにそうだろうと思う。というのも、同じゲーム会社の一員だとしても、職務内容による注目点の違いや、技術的内容への理解の度合いは異なり、有意義な意見を交換はおろか、それ以前の対話すら難しい場合もあるからだ。
また、安定稼動しているサービスの日常的なサーバーの状態監視を行なう人員としてなら、「AppDynamics」を利用すれば、さほど高度な技能を有しているスタッフを配置する必要がなくなるのも大きい。ゲームプロダクトの開発ができるほどの高い技術力を持つスタッフは、より生産的な業務に専念することができるのだ。
とは言え、当然、今まで積み上げてきた自社ツールをいきなり捨てることはできないだろうから、小規模のプロジェクトに導入して、小さいテストをしてみてもいいだろう。テストが成果を上げた暁には、過去に開発して現在サービス中のタイトルも移行しても良いだろうし、過去のタイトルは現状維持とし、以降将来のタイトルのみ「AppDynamics」導入を前提に開発していくという選択肢もある。
かつては、すべて自社で製作するするのが当たり前だったゲームそのものの開発も、ゲームエンジンやミドルウェアを活用しての開発が普及した結果、スタートアップしたばかりの小規模スタジオから、長年にわたって数多くのタイトルをリリースしてきた老舗ゲーム会社まで、ゲームの最も重要な部分、つまりゲーム性の根幹に関わる部分に集中して開発を行なうようになった。
同様に、サーバーの運用を伴うネットワークサービス型のゲームにおいても、すべてを自社で用意する時代は過ぎ去ろうとしているのではないだろうか。「AppDynamics」が、自社のサービス固有の内容に特化した“かゆいところに手が届く”ものではないとしても、十分なパフォーマンスと汎用性を持つ「AppDynamics」なら、優れたコストパフォーマンスを発揮するはずだ。
新日鉄住金ソリューションズでは、「AppDynamics」の機能評価を目的に、1カ月間という期間の制約はあるものの、従来より機能に制限のないアカウントを提供している。さらに導入を検討中の企業には、無償のテクニカルサポートが提供される。加えて、本誌での特集を良い機会とみて、ゲーム業界の3社限定でオンサイトでの「AppDynamics」のセットアップを含めた導入支援を約束してくれた。
これは、ゲーム会社にとっても、またとないチャンスである。本特集で初めて「AppDynamics」を認知した企業も、すでに認知はしていたが導入に戸惑っていた企業も、この機会にまずは評価まで進めてみてはいかがだろうか。