無印吉澤

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

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

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 のソースコード公開のお知らせ

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 を作って公開したら、プレイヤーが多いのか少ないのかわからなくなってきた話

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

Ansible の --extra-vars 引数を安全に使うためのラッパーを書いてみた

f:id:muziyoshiz:20160313233740p:plain

最近は、仕事でも趣味でも、サーバ構築を自動化したいときは Ansible を使ってます。

アプリケーションのデプロイには Capistrano も使うんですが、つい最近 Ansistrano という便利な Ansible role の使い方を覚えてしまったので、そこも Ansible で済むようになりました。

recruit.gmo.jp

ansible-playbook の --extra-vars 引数

ところで、Ansible の playbook を書いていると、「普段の動作は決まっているけど、ごくまれに違う動作をさせたい」ことがたまにありませんか? そういうとき、僕は ansible-playbook の --extra-vars 引数(-e 引数)を良く使います。

例えば、自作のアプリケーションをデプロイするための playbook で、「普段は master ブランチをデプロイするけど、たまに違うブランチをデプロイしたい」ことがあったとします。そういう場合、playbook のなかで version 変数を、

- hosts: apservers
  vars:
    version: master

のように定義しておいて、master ブランチをデプロイしたい場合は --extra-vars 引数なしで実行します。

$ ansible-playbook -i inventory deploy-app.yml

そして master 以外のブランチをデプロイしたい場合だけ、以下のように --extra-vars 引数を使ってブランチ名を指定します。

$ ansible-playbook -i inventory deploy-app.yml --extra-vars="version=develop"

Ansible 公式の Variables にある通り、あらゆる変数指定のなかで --extra-vars の指定は最優先されます。そのため、このような上書きが可能なわけです。

--extra-vars のデメリット

この方法はだいたいうまくいくのですが、「変数名を間違えても何のアラートも出ない」というデメリットがあります。

例えばつい最近、僕が書いた playbook を使ってアプリをデプロイした同僚から、「develop ブランチを指定したのに master ブランチがデプロイされてる。playbook がバグってないか?」と言われたことがありました。何か実装間違えたかな、と思って彼が実行したコマンドを見たら、こうなっていました。

$ ansible-playbook -i inventory deploy-app.yml --extra-vars="develop"

調べてみたところ、これは無効な変数指定として ansible-playbook に無視されるようです。その結果、version 変数はデフォルトの master のままで、master ブランチがデプロイされました。その同僚はどうも「引数でブランチ名を変えられる」程度の理解だったようです。

そのときは同僚に --extra-vars 引数の使い方を解説して終わったのですが、あとから考えてみると、--extra-vars で動作を変更させること自体が危険なんじゃないか? という気がしてきました。今回は引数の使い間違えでしたが、引数の使い方を理解していても version を versoin と書き間違えてしまうくらいは、普通にありそうです。

--extra-vars の代替案としての vars_prompt

--extra-vars の代替案としては、Prompts に説明のある vars_prompt を使うという方法があります。

vars_prompt は、playbook の実行後に、変数入力のプロンプトを表示するためのオプションです。例えば、playbook に、

- hosts: apservers
  vars_prompt:
    - name: "version"
      prompt: "Branch name?"
      default: master

と書いておくと、playbook の実行時に以下のプロンプトが表示されます。そのまま Enter キーを押せば version 変数に "master" が代入され、ブランチ名を入れればそちらに変わります。

Branch name? [master]:

これでまあ確かに安全になるので、多くの場合は vars_prompt を使うのがよいと思います。

ただ、master ブランチをデプロイするのが大半、というケースでは Enter キーを無駄にぺちぺち押さないといけないのが面倒です。また、カスタマイズ可能な変数がもっと多い場合は、その変数の数だけ Enter キーをぺちぺち押さないといけなくなります。何も考えずに Enter キーをぺちぺち押す習慣ができるのは、またなにか別の障害の原因になりそうで嫌な感じです。

--extra-vars を安全に使うためのラッパー ansible-playbook-se

さっきの同僚の例について考え直してみると、要するにあれは "develop" という僕の想定しない変数名を、ansible-playbook コマンドが受け入れてしまったのがいけなかったわけです。

それなら、--extra-vars 引数に指定できる変数名を限定できれば、それで十分安全になるのでは? そう考えて、ansible-playbook コマンドのラッパー "ansible-playbook-se" を試作してみました。最近覚えた Python 3 で実装し、GitHub にソースコードを置いておきました。

github.com

使い方はまず、このリンク先にある ansible-playbook-se と extra-vars-cheker を、どこかパスが通ったところに置きます。

次に、playbook が置いてあるのと同じディレクトリに、以下のような内容で extra-vars.yml という名前のファイルを作ります。このファイルには、playbook のファイル名と、各ファイルが --extra-vars で指定するのを許す変数名を書きます。

---
deploy-app.yml:
  - version

そして、いつも使っている ansible-playbook の代わりに、ansible-playbook-se を使うようにします。そうすると、想定外の変数が指定された場合、ansible-playbook-se は以下のようなエラーを出して、処理を中断します。

$ ansible-playbook-se -i inventory deploy-app.yml --extra-vars="develop"
ERROR: Invalid extra-var format: develop
ERROR: extra-vars-checker Failed.

安全になりましたね? なりましたよね? でも、これはこれで何だか面倒な気がしますね……。

試しに作ってはみたのですが、まだ実際の環境には導入していません。こういうニーズって、他の人にもあるもんでしょうか? もしニーズがあればもう少しちゃんと作ろうと思うので、ご意見お待ちしています。