AWS re:Invent 2017 Serverless re:Cap レポート 〜 Lambda, AppSync, Fargate, Cloud9, ML Service

• イベント名：AWS re:Invent 2017 Serverless re:Cap
• 開催日時：2017-12-11(月)
• 会場：アマゾン 目黒オフィス

最近、Serverless 関係の開発力を付けないとなあ……と思っていることもあって、AWS のイベントに参加してきました。

いずれちゃんとしたレポートが出てくると思いますが、個人的に気になった部分のメモを公開しておきます。

Serverless Updates (AWSJ SA 小梁川貴史)

• AWS Lambda
  • メモリ容量を最大3GBまで設定可能に
  • Go 言語と .NET Core 2.0 のサポートを プリアナウンス
  • CloudTrailに起動イベント(invoke)も記録されるように
  • 関数ごとに同時実行可能数の上限を設定可能に（いままではアカウント全体での上限のみ）
  • コンソールから、その関数に設定したロールでアクセス可能なサービスを確認できるようになった
  • CodeDeploy での段階的デプロイのサポート
  • AWS Serverless Repository
• Amazon API Gateway
  • いままでは Lambda のVPCアクセスを挟む必要があったが、その必要がなくなった
  • カナリアリリースのサポート（複数バージョンの混在）
  • API Integration（統合API）のタイムアウトのカスタマイズ設定が可能に
  • アクセスログの書式指定が可能に
• Amazon Cognito
  • 認証機能の強化（ASF）
• AWS Step Functions
  • re:Invent 前に発表された内容：state machine の update が可能となった

（※もし、スライドが公開されたら「本日ご紹介した update 一覧」のページだけ見れば概要がわかる）

AWS AppSync (AWSJ PS 塚越啓介)

• DevOps Consultant の方
• AppSync
  • フルマネージド GraphQL サービス
  • リアルタイム機能とオフライン機能にフィーチャ
  • 現在パブリックプレビュー中
• AppSync のコンセプト
  • AWS AppSync Client: クライアントライブラリの提供
  • DataSource: Amazon DynamoDB, ElasticSearch, AWS Lambda をサポート
  • Identity: GraphQL Proxy での認証
  • GraphQL Proxy: リクエストのマッピングなど
  • Operation:
  • （※あと2つの特徴はメモできなかった）
• GraphQL の解説
• GraphQL Subscription
  • Mutation をトリガーにしたイベントベースモード
• コンソールのデモ
  • Schema, Data Source の定義など
  • GraphiQL みたいなコンソールを提供してくれる
• クライアントのデモ
  • ネットワークが繋がらないときは、ローカルストレージにキャッシュされる
  • ネットワークが復帰すると、バックグラウンドで同期される
  • 片方のクライアントからイベントを送ると、subscribeしている他のクライアントにpublishされて、画面が更新される
• 質問
  • pagination の実装はどれくらい面倒見てくれるのか？
    • 支援の機能はある。詳しくはサンプルコードを参照
    • データベース側への制約はない。DynamoDB 側で next token とか設定すれば、自動的にやってくれる

AWS Fargate (AWSJ SA 大村幸敬)

• Fargate 概要
  • インスタンス管理不要
  • タスクネイティブAPI
    • タスク → 複数のコンテナを1つにまとめた単位
    • タスクごとに Elastic Network Interface (ENI) が振られる → タスクに直接 IP アドレスを設定できる
    • ECS の場合は、コンテナはホストと通信する構成だった
  • リソースベースの価格
    • CPU と メモリは、50 種類のパターンから選択
    • 秒単位の課金
  • SLA は 99.99%（EC2 と同等レベル）
  • 現在、全世界の Kubernetes 上で動くワークロードの 63% は、AWS 上で動いている
  • Amazon EKS
    • EKS であっても、インフラ部分の管理は必要
    • Fargate の EKS サポートは 2018 年の予定
• Lambda と Fargate の使い分け
  • https://twitter.com/Keisuke69/status/935912885682761729
• デモ
  • マルチAZ、パブリックサブネット/プライベートサブネットの構成
  • タスクごとに CPU、メモリなどを指定
• Fargate Under the Hood
  • Task Definition を登録。これを使ってタスクを実行
  • Per task ENI で動くので、今まで使っていた VPC でのアクセス制御が可能
  • ALB/NLB との組み合わせが可能
  • visibility がなくなった部分は、CloudWatch でメトリクスを確認するなど
  • Fagate 関連セッション（CON333, CON401 あたりが面白い）

AWS Cloud9 (AWSJ Specialist SA 福井厚)

• Cloud9
  • クラウドネイティブなIDE
  • EC2 か、SSH 接続可能な Linux サーバにインストールできる
  • Cloud9 からコンソールを実行して、AWS CLI を利用したりできる
  • 複数のダッシュボードを利用して、（アカウントを？）切り替えられる
  • AWS CodeStar と連携
  • 一般的な IDE と同様の操作（例：ショートカットキー、ステップ実行、ブレークポイントなど）
• Serverless Application Integration
  • リモートの Lambda ファンクションを参照できる
    • Cloud9 をインストールできるリージョンは限られるが、Lambda は任意のリージョンのものを参照できる
  • SAM のテンプレートを自動作成
  • Cloud9 上で Lambda のパラメータのペイロードを変更して、実行できる
• Collaboration
  • IAM ユーザ間で Cloud9 の環境を共有できる
  • 共有したユーザ間でのチャット、ペアプログラミング（共同編集）ができる
• AWS CodeStar Integration
  • CodeStar から Cloud9 の環境を構築できる
• Cloud9 の利用自体は無料
  • EC2 の実行時間と、ストレージ利用量だけが課金対象

ML Services (AWSJ Specialist SA 西谷圭介)

• 西谷さん、2月末に「サーバーレスアプリケーション開発ガイド」を発売予定
• AWS の ML サービススタックの Services 層に追加された4つの製品の紹介
• Amazon Compprehend
  • 自然言語理解サービス
  • 英語とスペイン語に対応
  • キーフレーズの抽出、関連する用語の分類、言語の認識、感情分析（文章のニュアンス）
  • Twitter 等のリアルタイム分析だけでなく、S3 上のファイルに対するバッチ処理も可能
• Amazon Translate
  • 翻訳サービス
  • 対応言語 → Amazon Translate Features – Amazon Web Services (AWS)
    • At Preview, Amazon Translate supports translation between English and any of the following languages: Arabic, Chinese (Simplified), French, German, Portuguese, and Spanish.
• Amazon Rekognition Video
  • 画像認識サービス Amazon Rekognition の動画版
  • 分析結果は1つの JSON で返される
  • JSON にさまざまな分析結果が格納されており、必要に応じて使う
• Amazon Transcribe
  • 音声をテキストに変換するサービス（文字起こし）
  • プレビューでの対応言語は英語とスペイン語
  • 通常音声と電話音声の両方をサポート
  • タイムスタンプと、その時刻の文字起こしの信頼度
  • ユースケース：コールセンターの音声データの可視化
    • S3 -> Lambda -> Amazon Transcribe -> Amazon Comprehend -> Athena -> QuickSight

感想

Serverless といいつつ、真っ先に連想されそうな Lambda の話はあまりありませんでした。最初のサマリと、あとは Cloud9 の話題が一番 Lumbda に近かったですかね。それでも結構面白かったです。

Fargate は、運用の楽さと AWS サービスとの連携機能が魅力的で、Docker を使うならやっぱり便利そう。Fargate の EKS 対応がリリースされたら、実業務で使ってみたいところです。

GraphQL は以前に少しだけ調べたことがあるんですが、GraphQL Subscription というのが出ているのは知りませんでした。動きが早い分野なので時々見ないと駄目ですね。この辺を読むのがいいでしょうか？

• graphql/Subscriptions.md at master · facebook/graphql
• Tutorial: GraphQL Subscriptions (server-side) – Apollo GraphQL

Amazon Linux, RHEL, CentOS での pip のインストール方法の違い

やらかした話

Amazon Linux は Red Hat Enterprise Linux (RHEL) をベースに開発された Linux ディストリビューションです*1。しかし、古い RHEL 5〜6 をベースにして、その後の開発は分岐しているため、パッケージ管理の方法などには違いがあります。

RHEL や CentOS では、EPEL を使って pip をインストールしても最新版にならず、pip install -U pip (pip install --upgrade pip) を実行する必要があります。

しかし Amazon Linux には独自の yum repository があるため、以下のように yum で最新版にアップデートできます。

$ sudo yum update python27-pip

しかし、それを忘れていて、Amazon Linux 上でつい

$ sudo pip install -U pip

としたところ、/usr/bin/pip が削除されて、新しい pip が /usr/local/bin/pip にインストールされてしまいました。ぐぐってみたら、同様の報告が Stack Overflow にもありました。

stackoverflow.com

「もしかして、これって最新の RHEL や CentOS でも同じことになるんだろうか？」と思って、EC2 上で検証してみました。

検証結果

結果を先に言うと、RHEL や CentOS ではそうなりませんでした。

• Amazon Linux AMI 2017.09.1

  • 最新の pip が入っており、これ以上アップデートできない（Python 2.7.12, pip 9.0.1）

• Amazon Linux AMI 2017.03.0

  • Python 2.7.12, pip 6.1.1 がインストールされている
  • pip は alternatives で管理されており、/usr/bin/pip は /etc/alternatives/pip へのシンボリックリンク
  • pip install -U pip を実行すると、/usr/bin/pip は削除され、/usr/local/bin/pip にインストールされる
  • yum update python27-pip でアップデートすれば /usr/bin/pip のままで pip 9.0.1 になる

• Red Hat Enterprise Linux 7.4 (HVM), SSD Volume Type

  • Python のバージョンは 2.7.5 で、pip はインストールされていない
  • yum install epel-release で EPEL をインストールできず、rpm ファイルをダウンロードしてインストールする必要がある
  • yum install python-pip で pip 8.1.2 がインストールされる
  • インストール先は Amazon Linux と同じ /usr/bin/pip
  • pip install -U pip を実行すると、パスは /usr/bin/pip のままで pip 9.0.1 にアップデートされる

• CentOS 7 (x86_64) - with Updates HVM

  • Python のバージョンは 2.7.5 で、pip はインストールされていない
  • yum install epel-release で EPEL をインストールできる
  • これ以降は RHEL と同じ

補足：現時点の最新バージョンは Python 2.7.14, pip 9.0.1

まとめ

結論としては、Amazon Linux では pip install -U pip しちゃ駄目ですが、他の Red Hat 系だと特に問題ない（むしろ yum では最新版が入らない）みたいです。Amazon Linux の pip は alternatives で管理されていることが影響しているんでしょうか？

Qiita で同様の症状がいくつか報告されていて、これらはどうも Amazon Linux ではなさそうですが、これ以上は深入りしないでおきます。

• パッケージ更新インストール後にコマンドが実行できない場合の対処 - Qiita
• pipコマンドが壊れた件 - Qiita

この件を Python に詳しい同僚に話したところ、yum が Python 2 で動作する関係で、RHEL や CentOS ではなかなか Python のバージョンを上げられないという事情もあるそうです。

pip は Python 3.4 以降に標準添付されていますが、RHEL や CentOS でその恩恵が受けられるのは当分先になりそうですね……。

おまけ(1)：今回の検証に使った AMI

おまけ(2)：そもそものきっかけ

今回そもそも何故 Amazon Linux で pip をアップデートしようとしたかというと、こんな経緯でした。

• Amazon Linux 上で Ansible 2.4.1 を使いたくなった
• Ansible 2.4.1 は cryptography に依存しているが、この cryptography が pip のバージョンアップを要求してきた
  • error in cryptography setup command: Invalid environment marker: python_version < '3' · Issue #31741 · ansible/ansible
• 何も考えずに sudo pip install -U pip を実行した
• sudo pip install ansible==2.4.1.0 を実行したら /usr/bin/pip: そのようなファイルやディレクトリはありません とか言われて真顔に

pyenv や virtualenv を使っていれば、今回みたいな目には遭わないと思います。Ansible で使いたいだけだから、と手抜きしたのがよくなかったですね。

Ansible が Python に依存してるせいで、ときどきどうでもいいところでつまづく気がします（今回のは完全に自業自得ですけど）。運用管理ツールを Go で作りたくなる人の気持ちが最近よくわかります……。

*1:AWS Developer Forums: Amazon Linux AMI - what distro is this based on? での Ben@AWS の回答によると、Amazon Linux は RHEL 5.x と、RHEL 6 の一部を元にしている。

Nginx でリバースプロクシを立てるときに気にすべき proxy_next_upstream 設定

個人的に、Nginx で「これは危険だ」と思っている設定があって、Nginx でなにかあるたびにその設定をつい疑ってしまいます。その設定について他の人に話すたびに、いちいち資料を集めるのが面倒になってきたので、今回はその設定項目についての情報をまとめておきます。

まだ理解に自信がない部分があるので、新しい情報が入ってきたら、この記事を適宜修正します。

リバースプロクシ設定の基本

Nginx をリバースプロクシとして使う時には、ngx_http_upstream_module でサーバのグループを定義します。そして、サーバ名やロケーション（パス）に対して、送信先のグループを指定します。

以下はマニュアルにある例です。その Nginx サーバへのすべてのアクセスを、backend グループに指定されたいずれかのサーバに送信します。

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

この送信に関わる設定は、proxy_pass を含む ngx_http_proxy_module の方にあります。このモジュールの設定のなかで、（僕が個人的に）よくつまづくのが proxy_next_upstream から始まる設定です。

proxy_next_upstream から始まる設定

これらは、upstream（リクエストの送信先）からエラーが返されたり、リクエストがタイムアウトした場合の動作に関する設定です。

• proxy_next_upstream
  • 失敗したリクエストを他のサーバに再送する条件（複数指定可）
• proxy_next_upstream_timeout
  • Nginx 側でリクエストがタイムアウトしたと判断するまでの時間
  • proxy_next_upstream で timeout が指定された場合のみ、この設定が使われる
  • 時間の単位は Configuration file measurement units を参照
• proxy_next_upstream_tries
  • proxy_next_upstream の条件に合致したリクエストを、最大で何台のサーバに送信するか
  • マニュアルには明示されていないが、この送信回数は最初の1台を含む
    • 1が設定されたら、最初のサーバ1台にしかリクエストを送信しない
    • 3が設定されたら、最初のサーバ1台への送信と、それ以外の2台への再送を行う

これらの設定が明示的に指定されなかった場合のデフォルト値と、その意味は以下の通りです。

• Default: proxy_next_upstream error timeout;
  • 何らかのエラーが発生した場合、または Nginx 側でリクエストがタイムアウトした場合に、リクエストを再送する
  • ここで言う「エラー」とは、（転送先）サーバへの接続時、リクエストの転送時、またはレスポンスヘッダの読み込み時に発生するエラーのこと
  • 4xx 応答、5xx 応答は、ここで言う「エラー」には含まれない
• Default: proxy_next_upstream_timeout 0;
  • Nginx 側でのタイムアウトは起こらない（0 は無制限を表す）
• Default: proxy_next_upstream_tries 0;
  • upstream ディレクトリで定義されたすべてのサーバに対して順番に、エラーが発生したリクエストを再送する（0 は無制限を表す）

不適切な設定が問題になるケース

proxy_next_upstream_tries を指定せずに使っていると、バックエンドのサーバへの接続で何らかのエラーが発生したら、最悪の場合、そのリクエストはすべてのサーバに対して送信 されます。

例えば、以下のような状況になると、無駄なリクエストが Nginx で大量に増幅されて、システム全体の負荷が急増します。

proxy_next_upstream 設定を何も指定していない状態で、
→ アプリケーションサーバが何かのバグで不正なレスポンスを返すようになる
→ そのバグを踏むリクエストが来る
→ そのリクエストがアプリケーションサーバの台数だけ複製される（サーバ10台なら10倍になる）
→ システム全体の負荷が急増

また、proxy_next_upstream_timeout だけ設定していると、こういうこともあり得ます。

proxy_next_upstream_timeout が2秒に設定されていて、proxy_next_upstream_tries は未指定の状態で、
→ 処理時間が2秒を超える重いリクエストが来る
→ その重いリクエストがアプリケーションサーバの台数だけ複製される（サーバ10台なら10倍になる）
→ システム全体の負荷が上がって、普段は2秒未満のリクエストも2秒以上かかるようになる
→ それらのリクエストも10倍に複製される
→ システム全体の負荷が急増

あるべき設定

個人的に考える、あるべき設定は以下の通りです。

proxy_next_upstream_tries は必ず0以外に設定する

この値がデフォルト値の0（無制限）でさえなければ、上記のような問題は起こらないので、まずこれを設定します。

1にすれば再送は起こりませんが、アプリケーションサーバを再起動するような場合にいちいちエラーが出てしまいます。再起動の場合のみを考えるなら、この値が大きすぎても意味はありません。そのため、proxy_next_upstream_tries は2〜3でいいと思います。

proxy_next_upstream_timeout はアプリケーションサーバ側の応答時間より長くする

proxy_next_upstream_timeout がアプリケーションサーバ側の応答時間よりも短いと、せっかくアプリケーションサーバがレスポンスを返しても Nginx で破棄されてしまいます。これではサーバの計算資源の無駄遣いです。

そのため、アプリケーションサーバの応答時間を事前に見積もって、それより長い時間を proxy_next_upstream_timeout に指定しましょう。これは、タイムアウト設計をきちんとしましょう、そして時間がかかる処理（データベース接続）があるならアプリケーション内にきちんとタイムアウト処理を入れましょう、という話ですね。

応答時間の見積もりが難しいなら、proxy_next_upstream_timeout はデフォルト（タイムアウトなし）のままでもいいと思います。

サービスによっては再送処理をオフにする

API 提供時など、クライアント側で再送処理をしてくれるなら、proxy_next_upstream off; を設定し、再送処理をオフにするという手もあります。

関連情報

• Nginxのproxy_next_upstreamが意図した挙動にならない問題を調べた - らっちゃいブログ
• nginx ちょっと不思議だったリクエストリトライのお話 - Cybozu Inside Out | サイボウズエンジニアのブログ

艦これアーケードのプレイデータ管理ツール Admiral Stats 1年分のユーザデータ解析

今月の9月3日に、艦これアーケードのプレイデータ管理ツール Admiral Stats の公開から1周年を迎えました。少しずつユーザが増え、開発に協力してくれる方も現れて、おかげで今日まで楽しく開発を続けてこられました。本当にありがたいことです。

1周年というのはよい節目なので、今回は Admiral Stats のユーザデータを解析して、利用傾向を調べてみました。この手のプレイデータ管理ツールを公開すると、どれくらい人が集まるのか（あるいは集まらないのか）の参考としてどうぞ。

解析対象は MySQL 上のデータです。解析方法の詳細は、このブログ記事の最後に貼っておきます。

アクティブユーザ数

Admiral Stats は、Twitter アカウントがあれば誰でもログインできるようになっています。しかし、この時点では、プレイデータは何も表示されません。

ログイン後に、SEGA 公式サイトからエクスポートしたプレイデータを Admiral Stats にインポートすると、プレイデータを時系列に表示できるようになります。

そのため、ログインしただけではアクティブユーザとは言えず、インポート機能を使っていればアクティブユーザと言えます。ただ、1回インポートして辞めてしまう人も割といるので、いくつかの基準で集計してみました。

グラフ上の項目名	集計基準	9月3日時点
ログイン	その日の23:59までに1回以上ログインしたユーザ数	417
インポート	その日の23:59までに1回以上インポートしたユーザ数	248
インポート（過去30日）	その日から過去30日以内に1回以上インポートしたユーザ数	113
インポート（過去60日）	その日から過去60日以内に1回以上インポートしたユーザ数	134

このデータを見ると、だいたい、以下のような傾向がありそうです。

• ログインしても、インポートする前に離脱してしまうユーザが多い。しかし Admiral Stats 自体の改善が進んだためか、離脱率は徐々に下がっている
• 2016年9月の まとめサイト取り上げ時 は、離脱率がかなり高かった
  • その後の1週間で増加したログインユーザのうち、78%（=61/78）が離脱してしまった
  • 当時は Ruby 版エクスポータしか無く、使うのが難しかったためと思われる
  • 流入の効果は1週間程度しか続かなかった
• 2017年7月に 艦らぼ で紹介してもらった際は、離脱率が低かった
  • 公開後1週間で増加したログインユーザのうち、32%（=9/28）しか離脱していない（！）
  • これは、艦らぼに 丁寧な解説記事 を書いてもらえた影響もかなり大きいと思ってます
• 艦これアーケードの期間限定海域（イベント）の期間中はアクティブユーザが増えて、終わると一時的に落ち込む

余談ですが、Admiral Stats は、おーぷん2ちゃんねると Twitter(@admiral_stats) で宣伝していました。おーぷんで宣伝したのはまとめサイトでの取り上げを期待してのことだったのですが、

• 機能追加しても、まとめサイトでは最初の1回しか取り上げられなかった
• おーぷんで宣伝しても、ある時期から PV が増えるだけでインポートユーザ数は増えなくなった

ことから、いまは Twitter でしか宣伝していません。

MAU (Monthly Active User) と継続率

インポート機能を使っているユーザを「アクティブユーザ」と定義して、これをもう少し詳しく調べてみました。

グラフ上の項目名	集計基準	8月末日時点
MAU（全体）	その月に1回以上インポートしたユーザ数	118
MAU（その月の新ユーザ）	MAU のうち、その月に初回ログインしたユーザ数	29
継続率	前月に1回以上インポートしたユーザのうち、その月もインポートしたユーザの割合	83.3 %

この指標で見ても、Admiral Stats の離脱率は徐々に下がっている（＝継続率が徐々に上がっている）と言えそうです。

また、意外なことに、毎月増えるユーザ数（その月の新ユーザ）はイベントにそれほど左右されず、一定の値を保っていたようです。しかし、それが今年の7月で2倍近く増加しています。とうとう普及が一山越えたんでしょうか？

インポート回数

ユーザ1人あたり、1ヶ月に何回くらいインポートしているか調べてみました。インポート回数が多いほど、Admiral Stats を日常的に使っていると言えます。

Admiral Stats は複数のプレイデータ（提督情報、艦娘情報、など）をサポートしていますが、「提督情報」のインポート回数のみを数えました。ほとんどのユーザがこのデータをインポートしており、これを Admiral Stats の利用回数と同一視して差し支えないと判断しました。

以下がその結果です。僕自身のインポート回数（動作確認含む）と、それぞれの月で最もインポート回数が多かったユーザは、外れ値として計測対象外としました。

月	平均	標準偏差	合計
2016-09	5.84	4.51	111
2016-10	5.33	4.80	192
2016-11	5.52	5.35	276
2016-12	5.71	6.57	217
2017-01	4.65	4.36	214
2017-02	5.02	5.10	246
2017-03	7.45	7.83	417
2017-04	8.02	7.73	497
2017-05	9.60	8.83	806
2017-06	8.36	9.64	619
2017-07	9.50	11.40	893
2017-08	9.77	11.05	1133
全期間	7.76	8.79	5621

インポート回数も、イベント期間中は増えて、終わると一時的に落ち込んでいます。それとは別に、インポート回数の平均と標準偏差が増えていますが、これは Admiral Stats のヘビーユーザが徐々に増えている影響のようです。

エクスポータの種類別のユーザ数

SEGA 公式サイトからプレイデータをエクスポートするために、以下のエクスポータを提供しています。エクスポータは Admiral Stats の「使い方」ページ からダウンロードできます。

• Ruby 版
  • 僕が最初に公開したエクスポータ
• PowerShell 版
  • sophiarcp さんが Ruby 版を移植してくれたもの（2016-09-18 提供開始）
• ブックマークレット版
  • sophiarcp さんが開発してくれたもの（2016-10-29 提供開始）
• Python 版
  • mimikun さんが開発してくれたもの（2017-04-18 提供開始）

今年の3月12日に、エクスポートしたプレイデータを Admiral Stats に自動アップロードする機能を追加しました。この自動アップロード時の User Agent から、実際に使われているエクスポータの種類が（やっと）わかるようになりました。

以下がその結果です。全ユーザが自動アップロード機能を使っているわけではないので、MAU よりは少なくなっています。また、1人が複数のエクスポータを使っている場合もあります（例：家では Ruby、外ではブックマークレット）。

月	Ruby 版	PowerShell 版	ブックマークレット版	Python 版	その他
2017-03	5	10	14	0	0
2017-04	5	8	26	0	0
2017-05	7	9	45	0	2
2017-06	5	8	43	0	1
2017-07	6	7	69	1	1
2017-08	3	6	86	1	1

ブックマークレット版のユーザ数が圧倒的ですね。正直、この集計をするまで、Ruby 版を使ってる人はもっと多いと思ってました……。PowerShell 版とブックマークレット版を作ってくれた sophiarcp さんにはホントに頭が上がらないです。

集計方法

今回の集計は、以下の手順で行いました。普通ですね。

1. MySQL のバックアップデータをローカル開発環境に持ってくる
2. rails console で CSV 出力する
3. CSV を Excel に取り込んで、グラフを書いたり、ピボットテーブルを作る

rails console で実行したコマンドは、2周年のときの集計のために（自分が忘れないように）Gist に貼っておきました（Gist: Admiral Stats 1周年のユーザデータ解析）。Admiral Stats のソースコードは GitHub (admiral_stats) にあるので、興味のある方はそちらもどうぞ。Star を押すと開発者が喜ぶのでオススメです。

あわせて読みたい

muziyoshiz.hatenablog.com

Admiral Stats がどういうものかわかるプレゼン資料です。

muziyoshiz.hatenablog.com

今回は Admiral Stats の利用傾向を見ましたが、こちらはプレイデータの中身を掘り下げた記事です。