2014-04-27

Sales and Trends からダウンロード数を出力

ios itunes connect

iOS アプリをリリースし、その後ダウンロード数をチェックしたいときには itunes connect の Sales and Trends にて確認することができます。ここで、累計ダウンロード数や月ごと日ごとのダウンロード数を簡単に確認できたり、CSV や Excel にエクスポートもすることができます。

そのダウンロード数を毎回ログインしてチェックしてというのも面倒なので、定期的にスクリプトまわして取得し Web 上にでも表示させておこうと思っていたら意外とスムーズにいかなかった。。。数字の取得はできるものの、フィルタリング機能が弱かったり、出力されたファイルも扱いにくかったりと、簡単にできるものと考えていたがやってみると意外にちゃんと解析スクリプトを書かなければということが分かった。

とりあえずダウンロード数の取得は Apple 謹製の自動取得プログラムがあるので以下の方法で簡単に行えます。

Java プログラムの取得

以下の Java プログラムをダウンロードします。

http://www.apple.com/itunesnews/docs/Autoingestion.class.zip

Autoingestion を実行する

ダウンロードしてきた Java プログラムにAutoingestionというクラスファイルがありますので、それを実行することでダウンロード数の取得が行えます。

java Autoingestion <properties_filename> <vendorid> <report_type> <date_type> <report_subtype> <date_yyyymmdd>

f:id:tunanosuke:20140427213121p:plain

これで gz ファイルが生成され、自分に関係のある各アプリのダウンロード数を取得することができます。

この手順を定期実行すればひとまず取得はできるので、それをどう解析し Web 上に表示させようかは別途検討していこうと思います。

※参考：iTunes Connect Sales and Trends Guide

※追記 2014.05.28

casperjs で WEB スクレイピングしてダウンロード数取得しました。

casperjs で iTunesConnect からアプリのダウンロード数をスクレイピングしてみた

WEB スクレイピングというところだと、Python の beautiful soup 使ってもできそうです。

2014-03-28

コンテナ型仮想化 Docker

docker vagrant immutable infrastructure

前々回のエントリーで Immutable infrastructure について触れた際、それを実現するための技術である Docker というワードを出しました。今回はその Docker について触れたいと思います。

Dockerとは

コンテナ型仮想環境を簡単に管理し利用することのできるソフトウェアです。仮想環境といっても VM を用意しハイパーバイザ型のような物理マシンの構築をするのではなく、OS 環境上に複数のユーザ空間を作り出すことによって仮想的に実行環境を作り出します。Docker は LXC（Linux Containers）によって複数の空間を作ることを実現しています。そのためコンテナ型仮想化はハードウェアレベルでの仮想化に比べ、すぐに新しい環境を作り出すことができます。新しい環境をすぐに構築できるので、デモやちょっとした開発用にさくっと構築していらなくなったら破棄することも柔軟に行えるので、ごちゃごちゃすることもないですね。

行ったこと

OS X で Docker を利用します。Docker は LXC ベースのため OS X 上では動きません。そのため、Vagrant を用いて OS X に VM 環境を作り、その VM 内で Docker を動かします。

使ったもの

Mac OS X
Vargant
Docker

Dockerを動かす

Vagrantで仮想マシンを立ち上げる

github リポジトリから Vagrantfile をダウンロードし、ローカルマシンである OS X のワークディレクトリに配置します。そのディレクトリで vagrant up コマンドで Vagrantfile を読み込み VM を起動します。

vagrant up

ローカルマシンと VM を同期するマウントポイント /vagrant を有効にするために再起動します。

vagrant reload

再起動が完了したら vagrant ssh でログインしましょう。

※ vagrant についてはこちらのエントリーに記載しています。

コンテナを立ち上げる

Docker を操作します。Docker の操作は docker コマンドを通じて行います。コンテナを立ち上げるには docker run を実行すれば立ち上がります。試しに docker run で立ち上げた後に「Hello, World!」を表示させてみます。

vagrant@precise64:~$ docker run ubuntu /bin/echo Hello, World
Unable to find image 'ubuntu' locally
Pulling repository ubuntu
5ac751e8d623: Download complete
9f676bd305a4: Download complete
eb601b8965b8: Download complete
9cc9ea5ea540: Download complete
9cd978db300e: Download complete
511136ea3c5a: Download complete
f323cf34fd77: Download complete
6170bb7b0ad1: Download complete
321f7f4200f4: Download complete
1c7f181e78b9: Download complete
7a4f87241845: Download complete
Hello, World

いろいろ出てきました。初回実行時のためOSイメージがリモートからダウンロードされています。ダウンロード完了後に「Hello, World!」と表示されます。

コンテナを立ち上げるにあたって docker run のあとに ubuntu と指定しています。これはイメージの名前で、コンテナを立ち上げるのにそのコンテナのベースになるOSイメージが必要です。今回の実行では ubuntu のイメージを利用して立ち上げています。

コンテナを操作する

コンテナが立ち上がったのでコンテナ内に nginx をインストールしてみます。今いる VM からコンテナ内に切り替わるには -i オプションと -t オプションをつけて /bash を実行します。

vagrant@precise64:~$ docker run -i -t ubuntu /bin/bash

root@bd75ac8f78ec:/#

これでコンテナ内部に入ったので nginx をインストールしてみたいと思います。

sudo apt-get install -y nginx-full

実行するとずらずらとインストールが開始されます。

イメージ（テンプレート）保存する

ここまでで OS イメージからコンテナを立ち上げてコンテナに nginx をインストールしました。この状態でコンテナをイメージとして保存したいと思います。イメージとはテンプレートのようなものです。イメージ保存することで docker run で実体化できます。保存する際は docker commit を実行するだけです。

root@bd75ac8f78ec:/# exit
vagrant@precise64:~$ docker commit 'bd75ac8f78e manato/nginx

今コンテナ内部にいるので一度 exit しそのあとに保存します。docker commit の引数は ”コンテナID” "イメージに付ける名前" となります。

保存されているかは docker images で確認します。

vagrant@precise64:~$ docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
manato/nginx        latest              795c9d9ba184        13 seconds ago      217.4 MB
ubuntu              13.10               9f676bd305a4        7 weeks ago         178 MB
ubuntu              saucy               9f676bd305a4        7 weeks ago         178 MB
ubuntu              raring              eb601b8965b8        7 weeks ago         166.5 MB
ubuntu              13.04               eb601b8965b8        7 weeks ago         166.5 MB
ubuntu              12.10               5ac751e8d623        7 weeks ago         161 MB
ubuntu              quantal             5ac751e8d623        7 weeks ago         161 MB
ubuntu              10.04               9cc9ea5ea540        7 weeks ago         180.8 MB
ubuntu              lucid               9cc9ea5ea540        7 weeks ago         180.8 MB
ubuntu              12.04               9cd978db300e        7 weeks ago         204.4 MB
ubuntu              latest              9cd978db300e        7 weeks ago         204.4 MB
ubuntu              precise             9cd978db300e        7 weeks ago         204.4 MB

一番上にイメージが作成されていることが確認できます。これでコミットしたイメージからコンテナを起動することができます。

docker run -i -t manato/nginx /bin/bash

まとめ

ハイパーバイザ型のように OS レベルでのサーバ立ち上げだと待ち時間が発生しますが、コンテナ型はさくっと一瞬で作れちゃいます。必要なときにすぐに利用できるのはいいですね。

今回は基本的な部分について触れました。もうちょっといろいろいじってみたいと思います。

2014-03-11

Java 差分リリース時に注意したいこと

java

ちょっとした修正をしてリリースする場合、「修正ファイルも1、2ファイルのだから差分リリースでしよう」という事で修正した class ファイルのみリリースした経験がある方も多いのではないでしょうか？また、別案件が並行で開発が進んでおりそれに影響が出ないように差分リリースすることも考えられると思います。そんな差分アップ時に特に注意したい事を2つ上げます。

1. JDK のバージョンが異なる

ビルドして class ファイルを生成した環境と本番リリースする環境とで JDK のバージョンが異なるケース。この状態でリリースすると正常に動かない可能性大ですね。検証時には問題なかったのにリリースしたらなぜか動かないということに陥るでしょう。事前に JDK のバージョンは揃えておくべきだと思います。

2. static や final を用いたクラスを修正

このような静的な修飾子を用いたメソッドやクラスに手を加えた場合、当然ですがそれらを参照している他のクラスについても意識しなければなりません。そうなると参照しているファイルを洗い出しそれらも合わせてリリースするため、結果的にファイルが増えたり、漏れが出てきてしまう可能性もあると思います。このケースの場合は差分アップは行わない方が良いですね。逆に不具合や障害を招いてしまします。

まとめ

差分リリース時に上記の事は最低限注意すべきだと思いますが、個人的には差分リリースはあまりおすすめしません。ちょっとした修正だから差分リリースではなく、常にクリーンな状態でリリースすべきであり、それが簡単に行える環境を作るべきだと思います。1つの解決策として、リリースを自動化しコストを削減することで、敢えて差分リリースする必要もなくなりますしヒューマンエラーも防げると思います。

2014-03-10

最近のインフラ系技術が興味深い〜Blue Green DeploymentとImmutale Infrastructure〜

devops blue green deployment immutable infrastructure

これまでは Javascript を中心としたクライアントサイドの技術が結構活発でしたが、去年あたりからインフラ周りの技術の流れがおもしろく、興味深いなと感じています。特にタイトルにも書いてある Immutable Infrastructure は最近は話題に上がることも多いです。ということで Immutable Infrastructure が提唱された背景にある技術の一つである Blue Green Deployment とそれを一歩進めたアプローチ Immutable Infrastructure についてまとめてみました。

Blue Green Deployment

まずは Blue Green Deployment について。これはブルーとグリーンの2つの環境を用意し、サーバにデプロイするたびにルーターやロードバランサで向き先を変更させる手法です。ブルーがアクティブとして稼働していた場合、グリーンに変更を加え、変更完了後にブルーに向いている向き先をグリーンに変更することでバージョンアップを行います。

これによる利点は問題があった際の切り戻しが簡単に行えます。元々アクティブだったブルーに向き先を戻すだけで対応できます。

欠点としてはコストがかかるという点です。2つの環境が必要なため、単純にサーバ台数も2倍必要になります。

Immutable Infrastructure

続いて、Immutable Infrastructure。名前を訳すと「不変なインフラ環境」。つまり一度運用に乗ったサーバについてはいっさい変更は加えず、変更が必要な場合は新規でサーバを立ち上げ、不要になったサーバは破棄するという手法です。そのためクラウドの利用が前提です。

利点は毎回クリーンな環境を扱うことができ、それによりデプロイ失敗を防ぐことができます。クリーンな環境なので、長年変更を繰り返されてきたサーバに比べ、すべてのサーバが同じ状態であるという保証ができます。また、使い捨てであることから Blue Green Deployment の欠点であるコストについても解消されるかと思います。

ただ Immutable Infrastructure にも欠点はあります。それはログが残らないということです。これについては別途ログを集約するためのストレージを用意するなどの対応が必要になってきます。

まとめ

クラウドの利用により、簡単に仮想サーバを構築できるようになり Immutable Infrastructure のような使い捨てができるようになりました。それらを実現するための技術である「Packer」や「Docker」にも注目していきたいと思います。

※参考

Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowler

2014-03-05

Apache HttpClient4

java

java での http 接続を行いました。やったことは画像のバイナリーデータを受け取って対象のサーバへ http で post します。

久々に触れたら3系は非推奨で3系と4系では結構インターフェースも変わっていました。検索しても以外と4系の情報って少ないんですね。実装は以下のように行いました。

String url = "http://~~"
byte[] byteData = IOUtils.toByteArray(request.getInputStream());

CloseableHttpClient httpClient = HttpClients.createDefault();
HttpPost post = new HttpPost(url);
ByteArrayEntity entity = new ByteArrayEntity(byteData, ContentType.create("image/jpeg"));
post.setEntity(entity);

//  http接続
HttpResponse response = httpClient.execute(post);

if (response.getStatusLine().getStatusCode() == HttpStatus.SC_OK) {
    String imageData = IOUtils.toString(response.getEntity().getContent());
}

処理は HttpPost 生成〜 Entity セット〜 http 通信するだけ。必要であれば response.getEntity().getContent() でレスポンスのデータを解析すればよいと思います。