読者です 読者をやめる 読者になる 読者になる

無印吉澤

ソフトウェア開発、運用管理(俗にいう DevOps)、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

Exrm を使った Phoenix アプリケーションのデプロイ方法を ansible-elixir-stack から学ぶ

Elixir Phoenix Framework Ansible
f:id:muziyoshiz:20161122004038p:plain

これまでのあらすじ

Elixir の世界には、Ruby での Ruby on Rails に相当する “Phoenix” という Web アプリケーションフレームワークがあります。しかし、Capistrano に相当するものは無くて、デプロイの考え方は Rails とはだいぶ違いそうです。

前回は Elixir の世界のビルドツール Elixir Release Manager (Exrm) で作った tarball をデプロイする方法について紹介しました。ただし、upgrade コマンドで無停止アップグレードしたいなら、ビルド環境には最新のソースコードだけでなく、アップグレードする前のバージョンのビルド結果も置いておかなければいけない(!)という話をしました。

muziyoshiz.hatenablog.com

今回は、この Exrm を使ったビルド方法の話の続きです。

Phoenix アプリケーションの情報に関するネット上の情報

Phoenix アプリケーションのデプロイについてネット上の情報を探したところ、(検索ヒット数はかなり少なかったのですが)ansible-elixir-stack という Ansible role と、その紹介記事が見つかりました。この Ansible role のコードを読んでみたところ、デプロイ方法がやっと理解できたので今回ご紹介します。

ansible-elixir-stack の使い方

github.com

ansible-elixir-stack は ansible-galaxy からインストールできます。

$ ansible-galaxy install HashNuke.elixir-stack

Phoenix アプリケーションの mix.exs に exrm を追加してから、

$ curl -L http://git.io/ansible-elixir-stack.sh | bash

を実行すると、その Phoenix アプリケーションのディレクトリ内に、Ansible の実行に必要なファイル(playbook や inventory など)が自動生成されます。自動生成された playbook は ansible-elixir-stack を呼び出して、inventory ファイルに記載されたサーバに Phoenix アプリケーションをデプロイします。

この ansible-elixir-stack という role は基本的にオールインワンなので、Nginx サーバなども自動的にインストールしてしまいます。開発環境の構築に使うならこのままでいいかもしれませんが、本番環境を構築する場合、これを参考に独自の playbook を書く必要がありそうです。

ansible-elixir-stack を実行するための手順については、以下のブログ記事で詳しく紹介されています。そのため、この記事では特に触れません。

blog.johanwarlander.com

ansible-elixir-stack は自動アップグレードをどうやって実現しているのか?

deploy_type 変数での動作の切り替え

ansible-elixir-stack を普通に使うと、前回のブログ記事に書いた「方法1. ソースコードをサーバに置いて、mix phoenix.server で起動」と同じように、サーバを1回停止して、再起動します。

ただし、deploy_type という変数に “upgrade” という値をセットしておくことで、無停止アップグレードの動作に切り替わります。この動作の切り替えについては Hot code-reloading のページ に記載されていました。今回はこちらの動作を解説します。

role 内部で実行されるコマンド

ansible-elixir-stack では、初回デプロイ時の playbook(setup.yml)と、2回目以降のデプロイ時の playbook(deploy.yml)が分かれています。ただ、いずれの場合も project.yml の以下の部分で git clone を実行し、サーバ上に Phoenix アプリケーションのソースコード一式をダウンロードします。

- name: "clone project"
  git:
    repo: "{{ repo_url }}"
    version: "{{ git_ref }}"
    dest: "{{ project_path }}"
    accept_hostkey: True
    force: True
    remote_user: "{{ deployer }}"

デフォルトでは project_path は /home/deployer/projects/{{ app_name }} です。

そして、release.yml の以下の部分で、Phoenix アプリケーションをビルドします。ちなみに、mix は ~/.mix 以下にインストールされたファイルを使うため、bash -lc の指定は必須です。

- name: "compile and release"
  command: bash -lc 'SERVER=1 mix do compile, release' chdir="{{ project_path }}"
  remote_user: "{{ deployer }}"
  environment:
    MIX_ENV: "{{ mix_env }}"
    PORT: "{{ app_port }}"

そして、最後の部分で、「git clone した最新バージョンのバージョン番号取得」、および「upgrade コマンドの実行」を行います。

- when: deploy_type == "upgrade"
  name: get app version
  command: bash -lc "mix run -e 'IO.puts Mix.Project.config[:version]'" chdir="{{ project_path }}"
  remote_user: "{{ deployer }}"
  register: app_version

- when: deploy_type == "upgrade"
  name: set upgrade command
  set_fact: upgrade_command='rel/{{ app_name }}/bin/{{ app_name }} upgrade "{{ app_version.stdout }}"'

- when: deploy_type == "upgrade"
  name: upgrade app
  command: bash -lc "{{ upgrade_command }}" chdir="{{ project_path }}"
  remote_user: "{{ deployer }}"
  environment:
    MIX_ENV: "{{ mix_env }}"
    PORT: "{{ app_port }}"

上記の upgrade コマンドの実行は、仮にアプリケーション名を sample_app、バージョン番号を 0.0.2 とすると、以下と同じ意味になります*1

$ cd /home/deployer/projects/sample_app
$ SERVER=1 mix do compile, release
$ rel/sample_app/bin/sample_app upgrade 0.0.2

デプロイ作業を常にこの playbook で実行しているなら、デプロイ先サーバの以下のディレクトリには、前回のバージョンのビルド結果が残っているはずです。

/home/deployer/projects/sample_app/rel/sample_app/release/0.0.1

そのため、前回のブログ記事で問題に挙げた「ビルド環境に、アップグレードする前のバージョンのビルド結果も置いておかなければいけない」という条件はクリアされます。

しかし、そう考えると新しく追加したサーバにいきなりバージョン 0.0.2 をデプロイする、という場合にはどうなるのか?が気になります。そういうケースでは、git clone しても上記の 0.0.1 ディレクトリは作られません。ただ、その場合はアプリはまだ動いていないため、単にバージョン 0.0.2 のアプリが新たに起動されるだけで、特に問題は起こらないようです。

この方法の懸念点

サーバごとのコードの状態の違い

Capistrano の場合は、通常はデプロイするたびに新しいディレクトリで git clone が実行されます。そのため、すべてのサーバで、余計なファイルがない環境で最新のコードが実行されるという安心感があります。

一方、上記の方法では、force=Yes で git clone が実行されるとはいえ、すべてのサーバ上のファイルが同じにはならない可能性があるのが気になります。まあ、そんなことを気にするなら、無停止アップグレードは諦めて Docker でも使え、という話かもしれません。

バージョン番号を上げるのを忘れそう

この方法に限らず、Exrm の upgrade コマンドを使う場合に共通した問題ですが、デプロイのたびに毎回必ず mix.exs 内のバージョン番号を上げて、git push する必要があります。ちょっとした更新のたびにこれを実行するのはかなり面倒です。

def project do
  [app: :hello_phoenix,
   version: "1.4.1",
   elixir: "~> 1.0",
   ...

この問題への対応として、ansible-elixir-stack の作者は Hot code-reloading のページ にて「バージョン番号の末尾に Git のコミットハッシュ値を自動的につける」という方法を提案しています。

def project do
  {result, _exit_code} = System.cmd("git", ["rev-parse", "HEAD"])

  # We'll truncate the commit SHA to 7 chars. Feel free to change
  git_sha = String.slice(result, 0, 7)

  [app: :hello_phoenix,
   version: "1.4.1-#{git_sha}",
   elixir: "~> 1.0",
   ...

もしこの方法を採用するなら、この対策は絶対に入れておいた方がよさそうです。

*1:SERVER=1 というのは ansible-elixir-stack が勝手に作ったフラグなので気にしないで OK です。

Exrm(Elixir Release Manager)を使った Phoenix アプリケーションのデプロイ

Elixir Phoenix Framework
f:id:muziyoshiz:20161122004038p:plain

Elixir の勉強中

最近、職場の飲み会で同僚に「Erlang VM はいいぞ」と熱弁されたのをきっかけに、「プログラミング Elixir」を買って Elixir を触りはじめました。Elixir でサンプルコードを動かすだけだと身に付かなそうなので、「Phoenix で API サーバを書く」というのを当面の目標にしています。

Phoenix というのは Web フレームワークの名前で、Elixir 版の Rails みたいなものです。ディレクトリ構造なども Rails に近く、Rails 経験者にはとっつきやすい代物です。実際、MySQL から取得したデータをそのまま JSON で返すだけの単純な API サーバはすぐ書けました。

そして、この API サーバをレンタルサーバにデプロイしようとしたんですが、Phoenix には Capistrano に相当するものがないんですね。でもまあ、同じような処理を Ansible で書けば済むだろう……と最初は思ってたんですが、Erlang VM の機能をフルに使おうと思ったら Capistrano のような流儀ではうまくいかないことがわかってきました。今回はそんな話をします。

Phoenix アプリケーションのデプロイ方法

Phoenix のサイトにあるガイドでは、Phoenix アプリケーションを(Heroku とかではない)普通のサーバにデプロイする方法が2通り紹介されています。

方法1. ソースコードをサーバに置いて、mix phoenix.server で起動

1つ目の方法は、Deployment / Introduction にある方法です。

Phoenix アプリケーションをローカルで開発するときは mix phoenix server というコマンドで起動するのですが、本番環境でも同じように起動する、という方法です。以下のようにすると、デーモンとしても起動できます。

MIX_ENV=prod PORT=4001 elixir --detached -S mix phoenix.server

この方法は単純でわかりやすいのですが、アプリケーションの起動・停止や、決まったディレクトリへのログ出力、といった Web アプリで普通必要になるものを、自前で用意する必要がでてきます。

例えば、Phoenix アプリをデーモンとして起動した場合、PID を記録しておかないと停止できませんが、そういう処理を自分で書く必要があります。私の探した範囲では、How to reload the server in production. · Issue #1288 · phoenixframework/phoenix にある方法で、起動と同時に PID を記録できるようです。

elixir --detached -e "File.write! 'pid', :os.getpid" -S mix phoenix.server

また、ログ出力についても、onkel-dirtus/logger_file_backend などを使って、出力先ファイルを指定しておく必要があります。

方法2. Exrm でビルドした結果をサーバに置いて、Exrm が自動生成したスクリプトで起動

そしてもう1つは、Deployment / Exrm Releases にある方法です。

Elixir Release Manager (Exrm) というのは、Elixir で書かれたアプリケーションを、配布可能な tarball にまとめるためのビルドツールです。開発マシンやビルドサーバ上で mix release コマンドを実行すると、以下のようなディレクトリ構成でファイルが生成されます。ここでは、ビルドしたアプリケーションの名前を、仮に admiral_stats_api とします。

rel
└── admiral_stats_api
    ├── bin  (アプリケーション管理用のスクリプト群)
    │   ├── admiral_stats_api
    │   ├── admiral_stats_api.bat
    │   ├── install_upgrade.escript
    │   ├── nodetool
    │   └── start_clean.boot
    ├── erts-8.1  (Erlang ランタイム)
    │   ├── bin
    │   ├── doc
    │   ├── include
    │   ├── lib
    │   └── man
    ├── lib  (アプリケーションが依存するすべてのモジュール)
    └── releases
        ├── 0.0.1
        │   ├── admiral_stats_api.bat
        │   ├── admiral_stats_api.boot
        │   ├── admiral_stats_api.rel
        │   ├── admiral_stats_api.script
        │   ├── admiral_stats_api.sh
        │   ├── admiral_stats_api.tar.gz (※)
        │   ├── start.boot
        │   ├── start_clean.boot
        │   ├── sys.config
        │   └── vm.args
        ├── RELEASES
        └── start_erl.data

上記のツリーで (※) を付けた admiral_stats_api.tar.gz には、このファイル自身を除く配布物すべてが入っています。この tarball をデプロイ先(仮に /var/www/admiral_stats_api とする)で解凍して、

$ bin/admiral_stats_api start

を実行するとサーバが起動し、

$ bin/admiral_stats_api stop

を実行するとサーバが停止します。ログファイルは、自動生成される log ディレクトリ以下に出力されます。

また、Exrm の凄い点として、アプリケーションの無停止アップグレードが可能です。これは、Capistrano がやるような「一瞬止めて、シンボリックリンクの向き先を変えて、再起動」という無停止っぽいアップグレードではなくて、本当に無停止で、内部状態も含めてアップグレードする、という機能です。

例えば、新しいバージョン 0.0.2 をリリースしたいときは、さっきと同じように mix release で tarball を作り、その tarball をデプロイ先の /var/www/admiral_stats_api/releases/0.0.2/admiral_stats_api.tar.gz に置いてから、

$ bin/admiral_stats_api upgrade 0.0.2

を実行すると、以下のようなメッセージが表示されて、バージョン 0.0.2 が動作し始めます。

$ bin/admiral_stats_api upgrade 0.0.2
Release 0.0.2 not found, attempting to unpack releases/0.0.2/admiral_stats_api.tar.gz
Unpacked successfully: "0.0.2"
Generating vm.args/sys.config for upgrade...
sys.config ready!
vm.args ready!
Release 0.0.2 is already unpacked, now installing.
Installed Release: 0.0.2
Made release permanent: "0.0.2"

単純な API サーバで使うにはオーバースペックな機能な気もしますが、せっかく Erlang VM を使うんだし、今回はこちらの方法でデプロイすることにしました。

しかし、自動化しようとするとうまくいかない(なんで??)

上記の手順をコマンドで手で打ちながら確認して、「なるほど完全に理解した。この手順を単に Ansible で自動化すればデプロイ自動化できるよな!」と思って、こういう Ansible playbook を書きました。

  • git clone で最新版をダウンロード
  • Git リポジトリ上に置いてない、パスワードなどを含むファイル(prod.secret.exs)を自動生成
  • コンパイル(mix do deps.get, deps.compile, compile
  • リリース用の tarball を作成(mix release
  • tarball をデプロイ先にコピー
  • tarball を /var/www/admiral_stats_api/releases/バージョン番号 に配置(解凍はしない)
  • upgrade コマンドを実行(bin/admiral_stats_api upgrade バージョン番号

で、この playbook を実行したところ、最後の upgrade コマンド実行のところでエラーメッセージが出て失敗しました。playbook と同じコマンドを手で打ったところ、こんなエラーメッセージでした。

$ bin/admiral_stats_api upgrade 0.0.2
Release 0.0.2 not found, attempting to unpack releases/0.0.2/admiral_stats_api.tar.gz
Unpacked successfully: "0.0.2"
Generating vm.args/sys.config for upgrade...
sys.config ready!
vm.args ready!
Release 0.0.2 is already unpacked, now installing.
escript: exception error: no case clause matching
                 {error,{enoent,"/var/www/admiral_stats_api/releases/0.0.1/relup"}}

一体何なのこれ……。

Phoenix のサイトや Exrm のサイトを読んでも理由が分からず、「プログラミング Elixir」にもそれらしい説明はなく、エラーメッセージで検索した結果をひたすら探し回ってわかったのですが、どうやら

「0.0.1 から 0.0.2 にアップグレードするための tarball を作るためには、 rel/アプリケーション名/releases/0.0.1 ディレクトリ以下が残っている状態で mix release コマンドを実行しなければならない」

らしいです。

改めて確認したところ、0.0.1 ディレクトリがない状態で 0.0.2 の mix release を実行したところ、コンソール出力は以下のようになっていました。

$ MIX_ENV=prod mix release
Building release with MIX_ENV=prod.
==> The release for admiral_stats_api-0.0.2 is ready!
==> You can boot a console running your release with `$ rel/admiral_stats_api/bin/admiral_stats_api console`

その一方、0.0.1 ディレクトリがある状態で mix release を実行したところ、以下のように 0.0.1 から 0.0.2 へのアップグレードのためのファイルが生成されたことを示すメッセージが増えました。

$ MIX_ENV=prod mix release
Building release with MIX_ENV=prod.
This is an upgrade, verifying appups exist for updated dependencies..
==> All dependencies have appups ready for release!
==> Generated .appup for admiral_stats_api 0.0.1 -> 0.0.2
==> The release for admiral_stats_api-0.0.2 is ready!
==> You can boot a console running your release with `$ rel/admiral_stats_api/bin/admiral_stats_api console`

ここまでのまとめ:結局どうしたらいいの?

要するに、Exrm を使って Phoenix をリリースするためには、ビルド時に、少なくとも1つ前のバージョンのビルド結果をローカルに置いておく必要があります。upgrade コマンドを使ってアップグレードする限り、これは必須のようです。

世間の人はどうやって Exrm を使っているのか調べてみたところ、例えば andrewvy/ansible-elixir という role では、ビルド結果をすべて git push していました。ただ、Phoenix アプリのビルド結果には秘密情報(prod.secret.exs)も含まれるので、Phoenix アプリを OSS にするならこの手は使えません。秘密情報をすべて環境変数から読み込むように書き換えるという手はありますが、それでも、本来 Git に登録する必要がないファイルを Git に登録しなければならない、というデメリットは残ります。

Phoenix アプリケーションを開発してる人って、普通はどうやってデプロイしてるんでしょうか? Exrm なんて使わずに、mix phoenix.server で起動する方法を採用して、起動スクリプトは自分で書いてるんでしょうか。経験者の方にぜひ教えてほしいです……。

この記事の続き

続きを書きました。

muziyoshiz.hatenablog.com

参考ページ

参考書籍

プログラミングElixir

プログラミングElixir

第18章「OTP:アプリケーション」の18.6節「EXRM − Elixir のリリースマネージャ」に、Exrm の解説が8ページほど書かれています。内部状態をマイグレートするために必要なコードについても若干説明あり。

Programming Phoenix: Productive |> Reliable |> Fast

Programming Phoenix: Productive |> Reliable |> Fast

まだざっと読んだだけですが、デプロイに関する話題は(少なくとも独立した節は)なさそうです。

艦これアーケードのプレイデータ管理ツール Admiral Stats のソースコード公開のお知らせ

Ruby on Rails Admiral Stats 艦これアーケード
f:id:muziyoshiz:20161011225236p:plain:w600

ソースコード公開しました

艦これアーケードのプレイデータ管理ツール "Admiral Stats" のソースコードを、GitHub で公開しました。https://www.admiral-stats.com/ で動いているのと全く同じものです。

github.com

先日正式リリースされた Ruby on Rails 5 で開発しています。Admiral Stats の開発に興味がある方や、動作の詳細に興味がある方はぜひご覧ください。

gitter のチャットルームも作りました

僕は本当につい最近まで知らなかったんですが、艦これブラウザ版には MyFleetGirls ってツールがあるんですね(完全に Admiral Stats の先人だ……)。ここの開発スタイルを参考にさせてもらって、gitter のチャットルームを作りました。

gitter.im

GitHub アカウントがあれば誰でも入れますので、ご意見・ご要望のある方はこちらにお寄せください。もちろん、お知らせ用の Twitter アカウント @admiral_stats や、GitHub の issue ページにお寄せいただいても OK です。

Admiral Stats の関連記事

Rails 5 での実装の解説と、Admiral Stats の利用状況の分析を過去に書きました。

muziyoshiz.hatenablog.com

muziyoshiz.hatenablog.com

艦これアーケードのプレイデータ管理ツール Admiral Stats を作って公開したら、プレイヤーが多いのか少ないのかわからなくなってきた話

Admiral Stats 艦これアーケード
f:id:muziyoshiz:20161011225236p:plain:w600

これまでのあらすじ

艦これアーケードにハマった勢いで、夏休みにプレイデータ管理ツール Admiral Stats を開発し、9/3 にリリースしました。

www.admiral-stats.com

艦これアーケードと、Admiral Stats の詳細については、以前書いた記事をご覧ください。

muziyoshiz.hatenablog.com

簡単に言うと、艦これアーケードとは、艦娘と呼ばれるキャラのカードを集めて、選りすぐりのデッキを作成し、ステージを攻略していくアクションゲームです。数ヶ月に1回、大きなゲーム内イベントがあるので、それに向けてキャラのカード集めやレベル上げをしていくのが主な楽しみ方になります。Admiral Stats はそういう楽しみ方を助ける(主に自分が楽しくプレイする)ことを目的に開発しているツールです。

9/3 のリリースから約1ヶ月が経過しましたが、正直言って、なかなかユーザが増えずに苦戦しています。そこで今回はこれまでの Admiral Stats のアクセスログを解析し、今後の対策を考えようとしたら、よくわからなくなってきた……という話をします。

最近追加した機能

リリース後に追加した機能で、大きな機能は以下の4点です。

  • 9/10:Lv. 99 到達予想日の追加
  • 9/17:本家のデータ形式変更に対応(★の数のインポート、および一覧表示)
  • 9/18:Ruby なしで使える PowerShell 版のエクスポータ(ユーザの @sophiarcp さんが開発してくれた機能の取り込み)
  • 10/7:全艦娘との比較(艦娘カード入手率)ページの追加

特に、9/18 の PowerShell 版のエクスポータ は、利用者増に大きく貢献してくれました。それまでは Ruby 版のエクスポータ(しかも bundler のインストールとか要求する)しか無かったので、そこで脱落する人が多かったと思われます。

また、10/7 に追加した 艦これアーケードの艦娘カード入手率 は、Admiral Stats にプレイデータをアップロードした提督全体に対する、各艦娘カードを入手済みの提督の割合を表示する機能です。例えば、最もレアと言われる「秋月」のカードを、提督全体の何%が持っているか、といったことがわかります。

f:id:muziyoshiz:20161011225334p:plain:w600

これらの機能でユーザ数は増えたのですが、それでもプレイデータを Admiral Stats にインポートしてくれたユーザはまだ 30 名程度となっています。まだまだ少ないですね……。

Admiral Stats の利用状況

Admiral Stats 自体のログと、Google Analytics のデータを元に、利用状況を調べてみました。3行で 4行でまとめると、結果はこんな感じです。

  • Admiral Stats の離脱率は高いが、1回使ってもらえればそこからの定着率はそれほど悪くない
  • Admiral Stats にアクセスしたユーザのデバイスは、おおよそ PC:Android:iOS = 3:1:1 の割合
  • そもそもアクセス数が少ない
  • ユーザ増に一番寄与したのは、1回だけ取り上げてもらったまとめサイト

以下は、その詳細です。

Admiral Stats のログ(9/3 〜 10/9 の 37 日間)

まず、Admiral Stats のログを使って、定着したユーザ数を見ていきます。

利用状況 ユーザ数 ログインユーザ数に対する比率 GA 計測のユーザ数に対する比率
1回以上ログインしたユーザ(以下、ログインユーザ) 107名 - 16.8 %
1回以上データをインポートしたユーザ 30名 28.0 % 4.7 %
2回以上データをインポートしたユーザ 22名 20.6 % 3.4 %
3回以上データをインポートしたユーザ 19名 17.8 % 3.0 %
先週(10/3〜9)に1回以上データをインポートしたユーザ 19名 17.8 % 3.0 %

Google Analytics(GA)で計測したユーザ数に対するログインユーザの比率は 16.8 % でした。1回ログインするだけでも心理的抵抗があると思うので、これは、この種のツールにしてはそこまで低くないと考えています。

また、1回ログインしてくれたユーザのうち、何らかの理由で脱落したユーザが 72 % でした。この脱落率は高いですね……。理由は以下のように予想しています。

  • エクスポータが PC 必須のため、PC を持っていない(あまり使わない)ユーザが使えなかった
  • 使う気にはなったが、エクスポートツールのインストールに失敗した
  • ログインしてみたが、機能が期待したものと違った

3回以上データをインポートしてくれたユーザはそれなりに定着してくれたアクティブユーザである、と仮定すると、アクティブユーザの比率はログインユーザの 17.8 %、1回以上インポートしたユーザの 63.3 % でした。1回インポートしてもらえれば、そのまま定着する割合はまあまあ高いと言えそうです。

Google Analytics のデータ(9/3 〜 10/9 の 37 日間)

PV 数などの基本的な数値は以下の通りです。少ないですね。検索エンジン経由のアクセスはほとんどなく、アクセス元はこのブログに書いた記事、Twitter での宣伝、おーぷん 2ch での宣伝と、そのまとめブログ記事でした。

項目 計測結果
PV 数 3,845
ユーザ 638
セッション 1,328
新規セッション率 47.97 %

じゃあ、定着せずに離脱してしまったユーザはどこから Admiral Stats に来て、どんな端末を使っていたのか? 以下は、集客のサマリーから、Oauth 認証のトラフィックと、(ブックマークなどを介した)直接アクセスを除外したものです。これは、ユーザ定着後のアクセスを除いた、初回アクセスの数に近いと思います。

参照元 デバイス セッション 新規セッション率 新規ユーザ
まとめサイト デスクトップ 167 83.83% 140
Twitter デスクトップ 125 16.80% 21
まとめサイト モバイル 122 90.16% 110
Twitter モバイル 97 92.78% 90
おーぷん 2ch デスクトップ 59 27.12% 16
おーぷん 2ch モバイル 37 70.27% 26
はてなブログ(このブログ) デスクトップ 27 40.74% 11

Admiral Stats は PC のみ対応(モバイルは表示のみ対応)なので、デスクトップの新規ユーザ獲得が大事なのですが、その点で一番強かったのは1回だけ取り上げてもらえたまとめサイト(【艦これアーケード】プレイデータ管理ツールを作ってみた : 艦これアーケードまとめ速報@艦アケ 艦これAC)でした。Twitter もアクセスは多いのですがモバイルが主体で、デスクトップの新規ユーザは少なく、なかなか厳しいです。

なお、iOS と Android の比率は、若干 Android のほうが多いもののほぼ同率で、どちらか一方だけ対応すればよいという状況ではなさそうでした。

艦これアーケードのプレイヤーってどれくらいいるの?

とりあえず定着率は改善すべきことがわかりましたが、そもそもアクセス数が少ないこともわかりました。

アクセス数が少ないってことは、プレイヤーにリーチできてないのか、そもそもプレイヤー自体が少ないのか? そもそも、艦これアーケードのプレイヤーって実際に何万人くらいいるんだろう?と疑問に思い、手に入る情報の範囲でプレイヤー数を見積もってみました。

Admiral Stats のデータから推測 → 7,000 人

せっかくなので、まずは Admiral Stats のデータを使って推測してみます。

艦これアーケードのプレイヤーズサイトには「暫定順位」という項目があり、ここに全国での順位が表示されます。ただし、順位が低すぎると「圏外」と表示されます。集まったデータを見る限りでは、暫定順位は 3,000 位くらいから下になると「圏外」と表示されるようです。ちなみに、僕は週1回ゲーセンに通う程度なので、「圏外」以外の表示を見たことないです。

f:id:muziyoshiz:20161011225746p:plain
(プレイヤーズサイトより抜粋)

Admiral Stats のデータを調べてみたところ、9月に1回以上データをインポートしている提督は21名で、9月末時点の暫定順位は以下の通りでした。

  • 3,000 位以内:9名
  • 圏外:12名

もし、艦これプレイヤー全体もこれと同じ比率に従うなら、9月のプレイヤー数は 7,000 人、ということになります。ただ、さすがにそんなに少ないわけないですよね……。

Admiral Stats を使ってくれているユーザには(こんな地味なツールに興味を持ってくれるくらいなので)ライトユーザはあまりいないので、コアユーザに比率が偏りすぎているのだろうと思います。この推測は置いておいて、別の方法を試してみます。

ゲーセンの混み具合と設置店舗数から推測 → 約 37,000 人

僕は土日しかゲーセンに行かないので、平日の状況はわからないのですが、土日に行くと無制限台はだいたい埋まっていて、制限台は半々くらいで空いている印象です。

公式サイトの設置店舗検索 にある店舗がすべてなら、艦これアーケードの設置店舗数は10月11日現在で 652 店舗です。

各店舗への納品数はわかりませんが、僕がよく行く地域のゲームセンターを例に上げるとそれぞれ 10, 2, 4, 4, 4 台で、平均 4.8 台設置されています。まずはこの値で概算すると、全国に筐体が 3129.6 台あることになります。あとは、少し雑ですが、以下のような仮定を置きます。

  • 筐体の主な稼働時間は9時〜21時間の12時間で、各筐体とも、その半分の6時間はプレイされている(半々くらいで空いている印象から)
  • 1人あたりの、1日のプレー時間は1時間
  • 一般的なプレイヤーは土日どちらかの1回だけ来る
  • 平日来るようなランカーは土日も当然来るだろうから、平日の分は無視

この仮定に基づくと、現在も艦これアーケードをプレイしているプレイヤー数は 652 * 4.8 * 6 * 2 = 37,555 名となります。うーん、こっちのほうが実体に近いですかね。

公式サイトからの推測 → ??

意外なことに、艦これアーケード専用の Twitter アカウントは存在せず、元々あった艦これの Twitter アカウント 「艦これ」開発/運営(@KanColle_STAFF) が艦これアーケードの告知も兼ねています。ブラウザ版とアーケード版でアカウントが分かれていれば、フォロワー数からプレイヤー数を見積もれたんですけどね。

他の公式サイトとしては、Admiral Stats もお世話になっている SEGA の艦これアーケード プレイヤーズサイト があります。

余談ですが、最近このプレイヤーズサイトで、SEGA IDを登録するとプレゼントが貰えるキャンペーンをやっていました(敵泊地への突入!準備キャンペーン)。こういうキャンペーンをするということは、プレイヤー数と比較して、プレイヤーズサイトを使っているユーザはあまり多くないのかもしれません。

Wiki からの推測 → ブラウザ版の 100 分の 1

艦これアーケードに関する Wiki はいくつかあり、アクセスが多いのは以下の2つのようです。

前者の PV はわからないのですが、後者はサイドバーの一番下にアクセスカウンタがあり、10/9(日) の PV は 1,251 でした。艦これブラウザ版の Wiki の同じ日の PV は 127,706 で、艦これアーケード版の約100倍でした。

この差はプレイヤーの規模を表してるのでしょうか? それとも、アーケード版はブラウザ版ほど難しくないから、Wiki のニーズが低い、というだけなのでしょうか。アーケード版でイベントが始まったら、また状況は変わるかもしれません。

まとめサイトからの推測 → ブラウザ版の 8 分の 1

ブラウザ版のまとめサイトは複数ありますが、艦これアーケード専用のまとめサイトで、きちんと編集されていそうなのは1個くらいしか見当たりませんでした。元々あるまとめサイトが(公式 Twitter と同様に)ブラウザ版とアーケード版の両方の話題を扱っているため、新規参入が難しいのかもしれません。

まとめサイトのPV数はわかりませんが、Twitter のフォロワー数を比較すると、10/10時点で 艦これアーケードまとめ速報@艦アケ (@kancolleAC) のフォロワー数が 15,700、艦これ速報(@kancollect) のフォロワー数が 123,250 で、こちらは約8倍の差のようです。

ちなみに、Admiral Stats は1回だけまとめサイトに取り上げられたのですが、艦これ界隈ではツール関係の話題は嫌がられるようで、それ以降はスルーされています。宣伝方法として、まとめサイトに頼るのはちょっと難しそうです。

ブラウザ版とアーケード版のユーザ比からの推測 → 約 50,000 人

ブラウザ版のプレイヤー数は非公開ですが、先人の動向分析では MAU(Monthly Active User、月間の総ログインユーザ数)が約40万人と推測されています。

このデータを使えば、ブラウザ版とアーケード版のユーザ比さえわかれば、アーケード版の MAU を推測できます。

人気の比較手段の定番として、Google Trends で人気度を調べてみました。上のグラフは「艦これアーケード」のみ、下のグラフは「艦これアーケード」と「艦これ」の、2016年4月28日(艦これアーケード稼働開始日)以降の比較です。

人気度の平均値は 艦これアーケード:艦これ = 5:47 でした。「艦これ」に「艦これアーケード」も含むと考えると アーケード版:ブラウザ版 = 5:42 で、つまりブラウザ版はアーケード版の約 8.4 倍となります。奇しくも、まとめサイトのフォロワーの比率に近くなりました。

以上から、ブラウザ版の MAU はアーケード版の約 8 倍と仮定すると、アーケード版の MAU は約 5 万人となります。

その他、攻略サイト、ブログなど

定量的でない比較としては、アーケード版はブラウザ版と比べて、ユーザ発のコンテンツがほとんど無いような気がします。

例えば、ブラウザ版の攻略サイトに当たるものは、アーケード版についてはあまり見当たりませんでした。"艦これアーケード" "攻略" でググると 約 356,000 件 (0.46 秒)と表示されるのですが、その大半が Wiki のようで、ページをめくっていくと(似たページを除外した状態では)7 ページ目までしか出てきませんでした。

あとは、ニコ動や YouTube に、解説動画や、単艦プレイ動画などが挙がっていて、参考になるものもたくさんあるのですが、それほど数は多くありません。アクションゲームなのでプレイ中の記録が難しいのと、SEGA 公式が撮影 OK としてないので、ユーザ主体のコンテンツもなかなか出にくいのでしょうか。

まとめ:Admiral Stats がこの先生きのこるためには

長くなりましたが、艦これアーケードのプレイヤー数としては 3 〜 5 万人くらいが妥当な推測に思えます。Admiral Stats としてはその 1 % の 300 〜 500 人くらいを目標に頑張りたいところです。

今後の予定としては、PC ユーザの定着率を上げるためにエクスポータを使いやすくし、検索エンジン経由のアクセスを増やすために 艦これアーケードの艦娘カード入手率 のようなコンテンツを増やそうと思います。あとはイベント対応で何か面白い機能が浮かんだら突っ込みたいですね。

根本的にはスマホ対応しないとユーザ増は難しそうですが、僕にそのスキルがないのと、非公式ツールなので審査を通らない気がするため、着手すべきか悩んでいるところです……。

ともあれ今後もいろいろ機能追加していきますので、艦これアーケードをプレイ中の提督は是非一度使ってみてください。ただ、プレイデータのエクスポートに非公式ツールを使わざるを得ない関係上、利用は自己責任でお願いします。

www.admiral-stats.com

github.com