Webアプリを創る

ジブリがアニメ制作から撤退?実際に描きたい人はタイに行けばいい。

2014年8月7日

ジブリがアニメ制作から撤退するというニュースが報道され大きな反響を呼んでいる。詳しい話はよくわからないが、現行の制作部門を解体して常駐スタッフを解雇し、フリーを使う体制に切り替えるようだ。

シネマトゥデイに掲載されている「ジブリは「作り方を変えます」解散報道を否定!宮崎駿監督も短編製作に意欲!」という記事が気になった。鈴木プロデューサーによると

もう始まっているんですよ。タイ、マレーシア、台湾、一部ベトナムでスタートしているんです。おそらくアジア全体で、例えば日本人が企画を考えて実際作るのはタイとかね。おそらくそうなってくる。実際に描きたい人はタイに行けばいい。製作費ではなく意欲の問題。日本でも意欲をもってやってきたけどそれがひと段落した。

アニメ業界も日本では制作ができなくなってしまっているようだ。アニメーターの待遇を調べてみると、日本アニメータ・演出協会がアニメーション制作者実態調査を行っていることがわかった。現在調査中なので、データとして公表されているのは、2008年度に実施した実態調査である。

それによると、月の作業時間が概算で273時間、それに対して年収は以下のようになっているそうだ。

  • 20代 110.4万円
  • 30代 213.9万円
  • 40代 401.2万円
  • 50代 413.7万円
  • 60代 491.5万円

30代になっても平均時給が653円だから、最低賃金以下の報酬しかもらえていない。確かにこれでは生活できないので意欲はなくなると思う。鈴木プロデューサーによると製作費の問題ではないというが、現実はスタッフの人件費がまかなえなくなったということではないかと思う。

アニメの世界は、表面は華やかで稼いでいるアニメーターもいるのは事実だろう。しかし、大多数のアニメーターが極めて低賃金で働いているのも事実であり、30代になって平均時給653円というのではなく、若い世代を育てていくという姿勢は重要だろう。それへのジブリの回答が「実際に描きたい人はタイに行けばいい。」というのは、あまりにも寂しいと思う。

AWS が「さくらのクラウド」と同じ価格性能比になった?

2014年7月17日

「AWS は、さくらのクラウド、Azure より10倍価格性能比が悪い?」というブログを書いた後に、Amazon EC2 では、t2 インスタンスが提供されました。t2 インスタンスは、低価格帯のインスタンスでバースト機能をがあるのが特徴です。

そこで、t2 インスタンスを使って、前回と同じテストをしてみました。テストしたタイプは以下のとおりで、OSは Windows 2012-R2 です。今回は、価格的には「さくらのクラウド」とほぼ同じになっています。

  • さくらのクラウド:2コア, メモリ4GB, SSDプラン 100GB、石狩
  • Amazon EC2: t2.medium (2vCPU, 4GBメモリ), GP (SSD) 100GB、東京リージョン 

コスト(月あたり・円) データ転送量は80GBで計算

 
CPU
ディスク
データ転送
ディスク単価(GBあたり)
さくらのクラウド
5,500
3,500
0
9,000
20円、SSD 35円
Amazon EC2
5,626
1,260
1,688
8,574
8.4円、SSD 12.6円

※Amzon EC2 はドル建てなので 1ドル=105円で

テストの結果は、下の図のとおりで、Amazon EC2 の t2.medium の方が少し良くなっています。

t2 インスタンスについて考えてみると、確かに月100万PVのWebページは個人や中小企業のWebページとしてはかなりアクセス数が多い部類になるのですが、それでも平均すると1分間に23回のアクセスしかないので、1回の処理を1秒でできるように作ってあれば動作しているのは23秒だけで残りの37秒は遊んでいるということになります。実際は処理では特定の時間に集中することが多くそれにあわせて処理能力があるサーバーを選択するので、サーバーのCPUの稼働率というのは普段はかなり低いのが一般的です。そういう点ではバースト機能があるというのはコスト的に相当なメリットがあります。

さくらのクラウドにバースト機能があるかどうかは確認できていません。ただ、フェアシェアのようなCPUを共有する機能は使っていると思います。単価をみると 1Core-2GB 2,139円、2Core-4GB 4,860円、4Core-8GB 11,340円、8Core-16GB 24,300円とコア数が増えるとコア当たりの単価が上がっています。CPUをユーザー毎に完全に独立させているのであれば、Azureのようにコア当たりのコストは上がらないはずです。単価が上がるというのはコア数が多くなると共有が難しくなってくるという事情を考慮した単価設定だと思うのです。

いずれにしても、CPUの利用の仕方については、さくらのクラウドのほうが先進的であって、AWS が追いついたといえるでしょう。「国産クラウド」を代表する「さくらのクラウド」には今後も頑張って欲しいと思います。

Amazon EC2 t2.medium

image

さくらのクラウド

image

AWS は、さくらのクラウド、Azure より10倍価格性能比が悪い?

2014年6月28日

短時間で大量のアクセスがあったこともあって、クラウドはどれを選択したらいいのかを調べていたら、Gihyou.jp の記事「クラウド,良いとこ・悪いとこ(第6回)」では、「AWSとAzureではunixbenchでは5倍,さくらとでは10倍の価格性能比があります」という結論になっていたので、本当にそうなのか調べてみました。

テストしたタイプは以下のとおりで、性能がよく似ていると思われるものを選択しました。OS については、すべて Windows Server 2012-R2 です。

  • さくらのクラウド:2コア, メモリ4GB, SSDプラン 100GB、石狩
  • Amazon EC2: c3.large (2vCPU, 3.75GBメモリ), GP (SSD) 100GB、東京リージョン
  • Azure 仮想マシン: 標準 A2 (2コア, 3.5GBメモリ) 、東日本リージョン

コスト(月あたり・円) データ転送量は80GBで計算

 
CPU
ディスク
データ転送
ディスク単価(GBあたり)
さくらのクラウド
5,500
3,500
0
9,000
     20円、SSD 35円
Amazon EC2
12,110
1,260
1,688
15,058
     8.4円、SSD 12.6円
Azure 仮想マシン
16,089
0
1,454
17,543
     5.1円、SSD 未対応

※Amazon EC2 の CPU の価格は、1年間の重度使用リザーブドインスタンスを使うとして計算しています。普通のインスタンスを利用するとCPUだけで17,470円となり、Azure より高額になります。また、ドル建てなので1$=105円で計算しています。

CrystalMark でのテストの結果

CrystalMark でテストをした結果は以下のとおりです。GDI以下は画面性能で関係がないので無視してください。

さくらのクラウド

image

Amazon EC2

image 

Azure 仮想マシン

image

結論として「さくらのクラウド」がCPUについての価格性能比では一番いいというのは間違いないようです。でも、Gihyou.jp の記事のように価格性能比が10倍というのではなく2~3倍程度だと思います。Gihyou.jp の記事が必ずしも間違いというわけでなく、AWS が最近 EC2 を m1, c1 の旧世代から m3, c3 の新世代に交代させたこと、ディスクに SSD を使えるようになったこと、価格も大幅に引き下げたことなどが大きく影響していると思います。クラウドも厳しい競争の世界だと本当に思います。

さくらのクラウドはCPUの価格性能比がいいこと、AWS は API が成熟していることや関連サービスが充実していること、Azure はディスクやデータ転送の価格が比較的安く、標準タイプだとロードバランサー等の機能が追加費用なしで使えること、月額使用料が5万1千円を超えると長期契約で割引が受けられることなどで企業にとってはコストパフォーマンスがいいし、東京と大阪でバックアップができるという特徴があります。結局、変化の速い世界なので特徴も時間によって変化するし、用途によっても適当なサービスが違ってくるので、時々見直しをしながら使っていけばいいと思います。

最後に、Azure 仮想マシンでは標準ではなく基本タイプがあるのでそちらが価格性能比がいいのではないかという意見があると思うのですが、A2 の基本タイプでテストすると、下の図のように標準の7割ぐらいの性能しか出なかったのです。自分にはそうなる原因がよく分からないので、標準にしておきました。

image

短時間で大量のアクセスがあったけど、どう対応する?

2014年6月27日

最近、テレビ番組のクイズの関係で自分の Webサーバーに短時間で大量のアクセスがあったので、その時の様子を参考までにメモをしておきます。アクセスについてはスマートフォンからが殆どで、テレビを見ながらスマートフォンを使っている人が多いようです。

下の図がそのアクセスの状況をグラフにしたもので21時56分には、1分間で3,500PVもの処理をしていました。時間に直すと21万PVなので、月1千万PVのアクセスにも余裕で対応できそうです。

image

 

最近は、スマートフォーンの普及でいつどこからでもアクセスできるようになったので、テレビやSNSで話題になったことをすぐにアクセスする人が増えており、短時間にアクセスが集中する傾向が強くなっています。

こういうアクセスにどう対応するかですが、今回も2分間だけのアクセスなので、あらゆる場合に対応するというのはコストからいって無理なように思います。でも、短時間で多くのアクセスが一気に来るような事態は今後増加していくと思うので、レスポンスタイムを短くするとか、時間のかかる処理を改善しておくとかいう日頃の努力が重要だと思っています。

サーバー等のスペック

サーバー: AWS m1.medium
サーバーOS: Windows Server 2012
使用しているソフトウェア: ASP.NET MVC 4, Umbraco

この時の CPU の負荷を CloudWatch で見ると最大で70%になっています。

image

JavaScript は PHP より10倍速い!

2014年6月25日

JavaScript の処理速度が予想以上に速くなってきている。最近、スマートフォン用のアプリケーションをどうするか試行錯誤していたがその際の正直な実感だ。熾烈なブラウザー競争の結果 JavaScript の JIT コンパイラーが優秀になってきているのが原因だろう。

俺の言語がこんなに遅いわけがない!? 〜C, Java, PHP, Python, Rubyによるプログラミング言語 速度比較〜」というブログの記事の結果に、C# と JavaScript の処理時間を追加すると以下のようなグラフになる。プログラム言語の処理速度は、C < C# ≒ Java < JavaScript << PHP のようだ。

image 

JavaScript に数値を入れていないのは、同じ計測方法がとれなかったためで、概略で図を描いたもので詳しくは下で説明している。この結果は、プログラミング言語についての計算速度を測定するサイトである Computer Language Benchmarks Game の JavaScript と PHP を比較したデータを一番下に示しているが、処理速度に大きな差があるので概略値としては間違っていないと思っている。

普通の Web サイトでは、数値計算を大量にすることは殆どなくて、データベースとのやり取りや文字列処理が中心なので、PHP 等のスクリプト言語でも十分に実用的である。しかし、ユーザーインターフェースを本当によくしようと思えば、計算量が飛躍的に増大するので、プログラム言語の選択は重要になってきている。

巷では PHP が人気のようだが、これから新しくプログラム言語を覚えるのであれば JavaScript の方がお勧めだと思うのだがどうだろうか。JavaScript の方が速度的にも遙かに優位だし、PHPだけではリッチなクライアントのプログラムをすることは不可能で、結局は JavaScript を使わないといけなくなる。一方、JavaScript だとクライアントでの親和性は抜群だし、サーバー側でも node.js を使えるので、JavaScript だけを覚えればサーバー側もクライアント側もそれだけで処理ができてしまう。

そういえば、PHP も JIT を実装する方向で動いているようだ。やはり処理速度は重要だということだろう。

最後に処理時間の計測方法についてメモしておく。C#については、「俺の言語がこんなに遅いわけがない!? 〜C, Java, PHP, Python, Rubyによるプログラミング言語 速度比較〜」の例にならって、以下のコンソールアプリケーションのプログラムを書いた。

class Program
{
    private const int N = 10000;
    static void Main(string[] args)
    {
        Console.WriteLine("C# start.");
        var sw = new Stopwatch();
        sw.Start();
        var result = new int[N];
        for (int count = 1; count <= N; count++)
            result[count - 1] = SumUp(count);
        sw.Stop();
        Console.WriteLine(sw.ElapsedMilliseconds + "ミリ秒");
        Console.WriteLine("C# end.");
    }

    static int SumUp(int n)
    {
        int sum = 0;
        for (int i = 1; i <= n; i++)
            sum += i;
        return sum;
    }
}

C#は、マイクロソフトが開発したプログラム言語で、Java や Delphi の影響を受けているといわれており 2000年に登場した比較的新しい言語である。マイクロソフトの言語と思われているが、ISO で標準化されており、最近では、Mono や Xamarin によって、Linux、Mac、iPhone、Android 等でも動作する。

テスト環境は、例と同じくアマゾン・ウェブサービス(AWS)の t1.micro インスタンスを使ったが、Linux ではなくて、Windows Sever 2008 の 32ビット版を使用した。Linux のように単純に time コマンドで時間を計測はできないので、PowerShell のスクリプトを次のように作成して起動させて時間を計測した。

$wmi = Get-WmiObject -Class Win32_OperatingSystem
echo $wmi.LocalDateTime
.\ProgramTest.exe
$wmi = Get-WmiObject -Class Win32_OperatingSystem
echo $wmi.LocalDateTime

測定結果は、実行時間が161ミリ秒で、計算部分だけだと53ミリ秒だった。例のJavaの場合、集計に long を使っているので、C# でも sum を int から long に変更すると、実行時間が187ミリ秒になり、Java より少し遅いという結果になった。C# と Java は処理方法が似ているので実行時間もほぼ同じということになると思われる。

次に、JavaScript の実行時間の計測だが、例の方法に準じてテストをするには node.js をインストールしてテストするのがいいと思ったが、今興味があるのはブラウザーでの処理なので、計算部分の処理時間だけで C# と比較することにした。

JavaScript に関しては、以下のページに公開しているので、ソースはそちらを見てください。また、実際にテストもできます。

自分のPCだと計算時間は、C#の場合で13ミリ秒、Chrome、IE11はともに 42ミリ秒~100ミリ秒で計算時間は安定していない。iPhone の場合は、C#73ミリ秒、Safari は約282ミリ秒だった。計算部分の処理時間については、概ねC#の4倍といったところだと思う。JavaScriptの場合は、計算部分の前後の処理については、下にPCの場合のタイムラインを表示しておくけどそれほど時間は要さないと考えられる。

image

なお、例の方のグラフでは、C の実行時間は255ミリ秒となっているが、Cで最適化オプションをつけてコンパイルすると58ミリ秒になったという記載があるのでそちらを採用している。

Computer Language Benchmarks Game での JavaScript と PHP の処理時間の比較

image