2009年のモバイルコンテンツ関連の動向や市場規模がまとめられた資料「総務省　モバイルコンテンツの産業構造実態に関する調査結果」
    このエントリをはてなブックマークに登録

2010/7/8 木曜日 matsui Posted in 記事紹介・リンク | 1 Comment »

総務省が発表した、2009年のモバイルコンテンツ関連の市場規模がまとめられた資料「モバイルコンテンツの産業構造実態に関する調査結果」が公開されたようなのでご紹介します。

モバイル業界の動向が見えて面白いです。

 

→　総務省　モバイルコンテンツの産業構造実態に関する調査結果 [soumu.go.jp]

→　別添：モバイルコンテンツの産業構造実態に関する調査結果　PDFファイル [soumu.go.jp]

 

上記のページによると、調査は委託先がやっているようで、そちらの方にもまた別の資料が公開されていました。

→　MCF/モバイルコンテンツフォーラム MCF発表統計データ [mcf.to]

→　2009年モバイルコンテンツ関連市場規模　PDFファイル [mcf.to]

 

市場規模は右肩上がりで、昨年より14%増の5525億円とのことです。

プレゼンの裏づけ資料やマーケティング分析などに有用ではないでしょうか。
興味のある方はチェックしてみてください。

 

関連：


タグ: , , ,



GIGAZINEに掲載されていた記事「モバイルページ向けの画像をリアルタイムで作成するためにlsyncdを使ってみた」
    このエントリをはてなブックマークに登録

2010/7/7 水曜日 matsui Posted in 記事紹介・リンク | No Comments »

数日前の記事になりますが、GIGAZINEに興味深い記事があったのでご紹介します。

PC向けの画像を縮小して、ケータイ用として用意する、というのはケータイサイトでよくやる手法ですが、GIGAZINEではそれに「lsyncd」を使っているようです。

 

→　GIGAZINE　モバイルページ向けの画像をリアルタイムで作成するために「lsyncd」を使ってみた [gigazine.net]

 

「lsyncd」は、Linuxカーネルのinotify機能を利用して、ファイルの更新時にミラー先にミラーリング処理をかけるためのものですが、rsyncの他にも任意のコマンドを実行できるようです。

→　lsyncd – Live Syncing (Mirror) Daemon [code.google.com]

 

GIGAZINEでは、rsyncの代わりにImageMagickのconvertコマンドを実行し、画像の縮小を行っているようですね。

複数解像度用の画像を生成するのは、アプリ側で生成することが多いと思いますが、こういう方法も便利そうですね。

cronやキューなどの仕掛けを使うよりもタイムラグが少なそうです。

 

「lsyncd」は意外と多くのところで実績があるようなので、安心度も高そうです。
興味のある方は調べてみてはいかがでしょうか。

 

関連：


タグ: ,



ドコモが来年の4月から発売する全端末でＳＩＭロックを解除できるようにするとのことです
    このエントリをはてなブックマークに登録

2010/7/6 火曜日 matsui Posted in ニュース | 1 Comment »

SIMロック関連のニュースです。

最近何かと話題になっているSIMロック解除問題ですが、ドコモが来年2011年4月以降に発売する全機種でSIMロック解除できる機能をつけるとのことです。

 

→　asahi.com　ドコモ、ＳＩＭロック解除へ　大手初、来春機種から [asahi.com]

→　日本経済新聞　ドコモＳＩＭロック解除へ　11年４月から全機種で　ライバル各社の対応焦点 [nikkei.com]

 

どちらかといえば保守的なドコモが、真っ先に全機種SIMロック解除の姿勢を見せるとは少し意外です。
これもシェアトップや自社インフラに対する自身の表れなのでしょうか。

 

対して、iPhoneなどをはじめとして魅力的な端末を持つソフトバンクですが、「SIMロックによって、端末とサービスをお買い求めやすく提供できている」、「スタンスに変化はない」として、SIMロックの解除の方向を見せませんでした。

→　CNET Japan　ドコモがSIMロック解除表明でもソフトバンクは「スタンスに変化ない」 [japan.cnet.com]

 

iPhoneは端末自体の出来は良いのですが、ソフトバンクの回線が貧弱なせいか繋がらないことがよくあります。
今のままでは顧客はただ流れるだけになってしまうでしょうから、確かにSIMロック解除はできないでしょうね。

 

業界の動向に大きく作用しそうな、このSIMロック問題。
他キャリアのカードを入れた場合に、iモードなどのサービスはどこまで使えるのか、通信ゲートウェイはどうなるかなど、色々と気になる点がいっぱいですね。

 

関連：




ブックレビュー：DBマガジン2010年8月号「モバゲータウン構築/運用のすべて」
    このエントリをはてなブックマークに登録

2010/7/5 月曜日 matsui Posted in ブックレビュー | No Comments »

雑誌月刊DBマガジンの2010年8月号に「教科書にはない実践ノウハウを学べ – モバゲータウン構築/運用のすべて」という記事が掲載されていましたので、レビューを書いてみたいと思います。

ケータイ界のメガサイト「モバゲータウン」の運用ノウハウがぎゅっとまとめられた、30ページにも及ぶ大特集となっています。

 

dbmagazine201008L

→　株式会社翔泳社:SEShop.com – DBマガジン2010/8月号 [seshop.com]

 

特集は主に4つの記事に分かれており、それぞれ次の通りです。

Part1　社内メンバー中心で構築／運営する”モバゲー”システムの裏側
Part2　誰でも公開できるモバゲーアプリの作り方
Part3　安定稼動を実現する大規模サーバ群の運用と監視
Part4　メガサイトで活用するMySQL性能管理テクニック

 

Part1では、モバゲータウンのサービスの説明や開発体制、基本システムのアーキテクチャーなどについて触れられています。
ゲームなどサイクルの早い開発に対応するため、プログラマをリーダーとしたtracによるチケット駆動開発を行っているようです。
また個人的には、今もApacheのバージョン1.3を使っているということに少し驚きました。

 

Part2ではPerlを使ったソーシャルアプリ開発について触れられています。
私はDBマガジンは初めて買ったのですが、このようにDBだけの記事ではなく、プログラム周りのことに関しての記事も掲載されているのですね。
Perlモジュールを使ったアプリの実装について結構突っ込んだ解説がされています。

 

Part3はサーバ運用についてです。
DeNAで独自開発したサーバ情報を一元管理するためのシステム「AdminTool」で、どのような点を押さえる形で監視をすればよいかについてが解説されています。
またそれだけではなく、サーバの発注や運用体制などのローレベルな部分までのノウハウが語られており、運用体制作りの参考になると思います。

 

Part4はいよいよDBマガジンらしくMySQLの運用についてです。
モバゲーで行われているオペレーションの解説や性能管理方法などについて、また負荷分散やメンテナンス方法などにも言及されています。
MyDNSを使ったスレイブ管理は、他ではあまり目にすることはなく、DeNA独特のテクニックと言えるかもしれませんね。

 

DBマガジンに掲載されているのでDBに関する記事がほとんどなのかと思うとそんなことはなく、基本的にはケータイに限らず大規模システムを構築・運用する人にとってかなり参考になる内容になっていると思います。

雑誌なのでAmazonでは買うことができずちょっと不便ですが、上記のサイトから購入するか、次号が出る7/24までであれば、少し大きめの本屋であれば普通に手に入れることが可能だと思います。

 

サーバ管理者にとってはもちろんですが、プログラマにとっても参考になる良記事だと思います。
大規模システム運用に興味のある方は、ぜひチェックしてみてはいかがでしょうか。

 

関連：


タグ: , ,



MySQLとPostgreSQLのRepeatable Read時の挙動の違いについて
    このエントリをはてなブックマークに登録

2010/7/2 金曜日 matsui Posted in サーバ | 1 Comment »

モバイルとは全く関係ないですが、自分のメモ代わりに記事にしてみたいと思います。

たまたまテストしていて、MySQLとPostgreSQLのRepeatable Read時の挙動の違いを見つけました。

 

AさんとBさんという二人のユーザが同時に一つのレコードを更新している場合です。

user_tblのuser_typeというカラムを「0」→「1」にアップデートしています。

分離レベルはMySQL、PostgreSQLともにRepeatable Readです。

 

Aさん
Bさん
mysql> begin;
Query OK, 0 rows affected (0.00 sec)		 トランザクション開始
mysql> select user_type from user_tbl where user_id
= 1000;
+———–+
| user_type |
+———–+
| 0 |
+———–+
1 row in set (0.00 sec)		 参照
mysql> begin;
Query OK, 0 rows affected (0.00 sec)		 トランザクション開始
mysql> select user_type from user_tbl where user_id
= 1000 for update;
+———–+
| user_type |
+———–+
| 0 |
+———–+
1 row in set (0.00 sec)		 行ロック
mysql> update user_tbl set user_type = 1 where user_id
= 1000;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0		 更新
mysql> commit;
Query OK, 0 rows affected (0.05 sec)		 コミット
mysql> select user_type from user_tbl where user_id
= 1000;
+———–+
| user_type |
+———–+
| 0 |
+———–+
1 row in set (0.00 sec)		 参照（ロックなし）
mysql> select user_type from user_tbl where user_id
= 1000 for update;
+———–+
| user_type |
+———–+
| 1 |
+———–+
1 row in set (0.00 sec)		 参照（ロックあり）

※結果が違うことに注意

 

最後のSELECTが、「FOR UPDATE」の有り無しで違う結果を返していることにご注意ください。

FOR UPDATE以外は全く同じSQL文なのに、結果が違うというのは、少し違和感がありますね。

 

Aさん
Bさん
test=# begin;
BEGIN		 トランザクション開始
test=# select user_type from user_tbl where user_id = 1000;
user_type
———–
1
(1 row)		 参照
test=# begin;
BEGIN		 トランザクション開始
test=# select user_type from user_tbl where user_id = 1000 for update;
user_type
———–
1
(1 row)		 行ロック
test=# update user_tbl set user_type = 0 where user_id = 1000;
UPDATE 1		 更新
test=# commit;
COMMIT		 コミット
test=# select user_type from user_tbl where user_id = 1000;
user_type
———–
0
(1 row)		 参照（ロックなし）
test=# select user_type from user_tbl where user_id = 1000 for update;
user_type
———–
0
(1 row)		 参照（ロックあり）

PostgreSQLの場合は「FOR UPDATE」の有る無しでSELECTの結果は変わりません。
こちらの方が直感的な感じがしますね。

 

（MySQLの内部構造には詳しくないのできっとですが）MySQLでは最初のSELECTでスナップショットが展開されるので、FOR UPDATEで取得した場合とそうじゃない場合でSELECTの結果が違うのだと思います。

「あるテーブルの値を元に、他テーブルの値を更新する」みたいなプログラムの場合、上記の例のようなパターンにはまることがありそうです。

そのような参照の前にはしっかりロックをかけましょう、というそんなお話でした。

 

関連：


タグ: ,



« 過去の記事へ
次の記事へ »