TokyoCabinet 64GBの壁
こんにちは、
CyberX エンジニア今井です。
先週から始めたエンジニアブログですが、
今回は自分が担当です。
とはいえ、ブログに何を書くべきか大分悩みました。
悩んだ結果、最近アプリの運用中に起こった
TokyoCabinetの容量が64GBになると、
データが書き込めない件について取り上げたいと思います。
そもそも、64GBもデータを入れることがおかしいって言われると
あれですが…
最近、KVSを使うことも、大分主流になり、
弊社でもTokyoTyrant + TokyoCabinetを利用しております。
自分が知る限りでは、今までトラブルなく運用していたようですが、
先日、TokyoCabinetにデータが書き込めない事象が発生。
原因としては64bit環境で容量64GB以上のTokyoCabinetのデータファイルを扱うには、
HDBTLARGEオプションを指定する必要があるようです。
ちなみに、試しにHDBTLARGEオプションを指定して、64GBの壁を突破できるか検証してみました。
case.1 下記の例のように起動時のオプションに#opts=lを指定し、データベースファイルを作成
例） tt.tch#bnum=10000000#xmsiz=512m#opts=l
検証結果）
見事に64GB以上のデータを格納でき、put,getも正常動作しました。
しかし、メモリサイズが小さいので、64GBに近づくにつれ、
putの処理速度の低下。
case.2 作成済みのデータベースファイルで途中から起動オプション#opts=lを指定→optimizeを実行
→ttserverを再起動
検証結果）
64GBは越えたが、putとgetが正常に動作しない
optimize実行時に-tlオプションをつける必要があるようで、
以下のコマンドで最適化をしたら、読み書きも可能になりました。
tchmgr optimize -nl -tl tt.tch
検証してみて、TokyoCabinetに64GB以上のデータを
格納するよりも、分散するほうがスループットが向上すると
思いました。
（ペンチマークをとったわけではないですが…）
最後に、64GBの壁の対策などをまとめておきます。
■対策
１. TokyoCabinetを分散する。
ディスクI/Oを減らす効果もあるので最も理想的かと。
2. 64GB以上の容量を使用したい場合は、起動オプションに#opts=lをつける
（64bit環境ではつける必要があります）
■一時的な対策
1. TokyoCabinetの最適化をして、容量を減らす。
※この際、不要なデータを削除してから行うと最適
ちなみに、今回はTokyoTyrant + TokyoCabinetでしたが、TokyoCabinetを使用しているKVS
は他にもあるので、注意が必要です。
CyberX エンジニア今井です。
先週から始めたエンジニアブログですが、
今回は自分が担当です。
とはいえ、ブログに何を書くべきか大分悩みました。
悩んだ結果、最近アプリの運用中に起こった
TokyoCabinetの容量が64GBになると、
データが書き込めない件について取り上げたいと思います。
そもそも、64GBもデータを入れることがおかしいって言われると
あれですが…
最近、KVSを使うことも、大分主流になり、
弊社でもTokyoTyrant + TokyoCabinetを利用しております。
自分が知る限りでは、今までトラブルなく運用していたようですが、
先日、TokyoCabinetにデータが書き込めない事象が発生。
原因としては64bit環境で容量64GB以上のTokyoCabinetのデータファイルを扱うには、
HDBTLARGEオプションを指定する必要があるようです。
ちなみに、試しにHDBTLARGEオプションを指定して、64GBの壁を突破できるか検証してみました。
case.1 下記の例のように起動時のオプションに#opts=lを指定し、データベースファイルを作成
例） tt.tch#bnum=10000000#xmsiz=512m#opts=l
検証結果）
見事に64GB以上のデータを格納でき、put,getも正常動作しました。
しかし、メモリサイズが小さいので、64GBに近づくにつれ、
putの処理速度の低下。
case.2 作成済みのデータベースファイルで途中から起動オプション#opts=lを指定→optimizeを実行
→ttserverを再起動
検証結果）
64GBは越えたが、putとgetが正常に動作しない
optimize実行時に-tlオプションをつける必要があるようで、
以下のコマンドで最適化をしたら、読み書きも可能になりました。
tchmgr optimize -nl -tl tt.tch
検証してみて、TokyoCabinetに64GB以上のデータを
格納するよりも、分散するほうがスループットが向上すると
思いました。
（ペンチマークをとったわけではないですが…）
最後に、64GBの壁の対策などをまとめておきます。
■対策
１. TokyoCabinetを分散する。
ディスクI/Oを減らす効果もあるので最も理想的かと。
2. 64GB以上の容量を使用したい場合は、起動オプションに#opts=lをつける
（64bit環境ではつける必要があります）
■一時的な対策
1. TokyoCabinetの最適化をして、容量を減らす。
※この際、不要なデータを削除してから行うと最適
ちなみに、今回はTokyoTyrant + TokyoCabinetでしたが、TokyoCabinetを使用しているKVS
は他にもあるので、注意が必要です。
イベント告知
こんにちは、
CyberX エンジニア白井です。
イベント告知です。
弊社がいつもお世話になっている
ハッチアップさん主催のイベントです。
============================================
"Social Top Runners" Vol.2
"PHP x Social App"
参加企業：CyberX,Sumzap,Pokelab,Cave,Klab
============================================
様々なSAPさんが登場します。
その中に弊社も参加します。弊社から代表の小柳津と私が登壇します。
イベントの詳細ページはこちら
============================================
主催者： 株式会社ハッチアップ
開催日時： 11/01(月) 19:30 ～ 21:15 (あと5日)
会場： 品川イーストワンタワー21Ｆ大会議室
参加費： 無料 支払方法： なし
残席状況： 空席あり
お申し込み期限：11/01(月) 19:30
============================================
SAP業界に興味があるエンジニア、弊社に興味があるエンジニアの方は
是非お越しください。
弊社の"想い"を直にお伝えします。
CyberX エンジニア白井です。
イベント告知です。
弊社がいつもお世話になっている
ハッチアップさん主催のイベントです。
============================================
"Social Top Runners" Vol.2
"PHP x Social App"
参加企業：CyberX,Sumzap,Pokelab,Cave,Klab
============================================
様々なSAPさんが登場します。
その中に弊社も参加します。弊社から代表の小柳津と私が登壇します。
イベントの詳細ページはこちら
============================================
主催者： 株式会社ハッチアップ
開催日時： 11/01(月) 19:30 ～ 21:15 (あと5日)
会場： 品川イーストワンタワー21Ｆ大会議室
参加費： 無料 支払方法： なし
残席状況： 空席あり
お申し込み期限：11/01(月) 19:30
============================================
SAP業界に興味があるエンジニア、弊社に興味があるエンジニアの方は
是非お越しください。
弊社の"想い"を直にお伝えします。
携帯コンテンツのFlashLite1.1を用いたサムネイル画像の作成
こんにちは、
CyberX エンジニア白井です。
今週からCyberXのエンジニアがソーシャルアプリの構築の中で培ったノウハウを
リレー形式でブログという形で公開していきます。
トップバッターを務めさせていただきます。
一つ目の記事として何を書くのか若干かんがえましたが、
あんまり他の会社でやっていると聞いたことがないことを
取り上げることにしました。
とういことで、FlashLite1.1のFlashを用いてサムネイル画像を作成する話をします。
携帯コンテンツではFlashLite1.1がいまだにつかわれます。
そういう弊社のソーシャルアプリも主にFlashLite1.1を使用しています。
たとえばモリんちゅ（弊社のモバゲーに出しているソーシャルアプリです。）
では次のように自分のモリをFlashで表示しています。
当然ユーザごとに合成する内容が違ってきます。
Flashの合成エンジンと、PHPを駆使して作成しています。
さて、ではせっかく合成したFlash、他に使い道はないでしょうか？
これまた、よくあるのが、携帯コンテンツでは、サムネイルを表示します。
ユーザのアバターが代表例です。
サムネイルですから、Flashで表示したのと同じ内容です。
じゃあ、このサムネイルどうつくりましょう？
「わざわざ画像を重ね合わせて、サムネイルつくるの手間がかかる。
・・・Flashつかえないの？」
って考えますよね！
Flashをキャプチャーしようと取り組む中で、さまざまな問題が発生しましたが、
（文末にそのあたりに触れた社内で使用した資料のリンクをはっております。）
現在は目的のサムネイルをFlashから作成できるようになりました。
ただし、同期処理ではなく、非同期処理となっています。
（負荷を考慮した結果、非同期処理におちつきました。）
で、実際の実現方法ですが、
FlashPlayer10（ActionScript3.0）をつかって処理しています。
FlashPlayer10にてキャプチャーしたいFlashLite1.1のFlashファイルを
読み込みます。
その後、ActionScriptにて、読み込んだFlashをBitmapへ変換、
BitmapからJPEGへ、と変換しています。
なぜBitmapが途中ででてくるのか？と疑問に思ったかもしれません。
実は、このBitmapがこのキャプチャーの仕組みの根幹の処理なのです。
ActionScript3.0には次のメソッドがあります。
パッケージ flash.display
クラス public class BitmapData
draw()メソッド
Flash Player のベクターレンダラを使用して、source 表示オブジェクトをビットマップイメージ上に描画します
つまり、Flashのベクター表示をBitmapへ変換してくれるのです。
それはつまり、キャプチャーそのものです。
あとは、キャプチャーしたいFlashLite1.1のFlashを読み込む処理と
Bitmapを任意の画像形式に変換するエンコード処理を
前後にはさむだけです。
（頭でわかっても実際には落とし穴がありました。）
ただし、FlashPlayerを起動する必要があります。
最初は、1枚キャプチャーするたびにFlashPlayerを起動し、
キャプチャーが終わったら、FlashPlayerを終了していました。
（同期処理）
しかし、FlashPlayerの起動コストが高い！
そのため、FlashPlayerを常に立ち上げておく形にし、
特定のURLをポーリングして、データがあるときのみ
FlashLite1.1のFlashを読み込むような処理に変更しました。
（非同期処理）
結果、サーバの負荷は運用に耐えられるレベルに下がりました。
（最終的なソースの一部を文末のスライドに載せています。）
この仕組みが構築できたおかげで、
Flashの合成処理をそのままつかって、
サムネイルをつくれるようになりました。
画像を重ね合わせてサムネイルを作成するよりも、
（GDや、ImageMagickの重ね合わせ）
ベクターデータを重ね合わせた後にBitmapに落とす
こちらの方式のほうが、画像がきれいにみえます。
弊社ではガンガン活用しています。
弊社のソーシャルアプリを見たときに
ちょっと思い出してもらえればと思います。
（星空バータウン（弊社mixiモバイルのソーシャルアプリ） 画像キャプチャー例）
※プレゼン時の資料
FlashLite1.1のSWFを画像キャプチャーする
CyberX エンジニア白井です。
今週からCyberXのエンジニアがソーシャルアプリの構築の中で培ったノウハウを
リレー形式でブログという形で公開していきます。
トップバッターを務めさせていただきます。
一つ目の記事として何を書くのか若干かんがえましたが、
あんまり他の会社でやっていると聞いたことがないことを
取り上げることにしました。
とういことで、FlashLite1.1のFlashを用いてサムネイル画像を作成する話をします。
携帯コンテンツではFlashLite1.1がいまだにつかわれます。
そういう弊社のソーシャルアプリも主にFlashLite1.1を使用しています。
たとえばモリんちゅ（弊社のモバゲーに出しているソーシャルアプリです。）
では次のように自分のモリをFlashで表示しています。
このFlash（上記はFlashを今回説明する仕組みでキャプチャーした画像です）は
Flash合成エンジンをつかって、PHPより素材のSWF
（上記の画像内では、パンダ、背景の草、地面、チューリップ、ひまわり）
を合成し、一枚のFlashにしています。
Flash合成エンジンをつかって、PHPより素材のSWF
（上記の画像内では、パンダ、背景の草、地面、チューリップ、ひまわり）
を合成し、一枚のFlashにしています。
当然ユーザごとに合成する内容が違ってきます。
Flashの合成エンジンと、PHPを駆使して作成しています。
さて、ではせっかく合成したFlash、他に使い道はないでしょうか？
これまた、よくあるのが、携帯コンテンツでは、サムネイルを表示します。
ユーザのアバターが代表例です。
サムネイルですから、Flashで表示したのと同じ内容です。
じゃあ、このサムネイルどうつくりましょう？
「わざわざ画像を重ね合わせて、サムネイルつくるの手間がかかる。
・・・Flashつかえないの？」
って考えますよね！
Flashをキャプチャーしようと取り組む中で、さまざまな問題が発生しましたが、
（文末にそのあたりに触れた社内で使用した資料のリンクをはっております。）
現在は目的のサムネイルをFlashから作成できるようになりました。
ただし、同期処理ではなく、非同期処理となっています。
（負荷を考慮した結果、非同期処理におちつきました。）
で、実際の実現方法ですが、
FlashPlayer10（ActionScript3.0）をつかって処理しています。
FlashPlayer10にてキャプチャーしたいFlashLite1.1のFlashファイルを
読み込みます。
その後、ActionScriptにて、読み込んだFlashをBitmapへ変換、
BitmapからJPEGへ、と変換しています。
なぜBitmapが途中ででてくるのか？と疑問に思ったかもしれません。
実は、このBitmapがこのキャプチャーの仕組みの根幹の処理なのです。
ActionScript3.0には次のメソッドがあります。
パッケージ flash.display
クラス public class BitmapData
draw()メソッド
Flash Player のベクターレンダラを使用して、source 表示オブジェクトをビットマップイメージ上に描画します
つまり、Flashのベクター表示をBitmapへ変換してくれるのです。
それはつまり、キャプチャーそのものです。
あとは、キャプチャーしたいFlashLite1.1のFlashを読み込む処理と
Bitmapを任意の画像形式に変換するエンコード処理を
前後にはさむだけです。
（頭でわかっても実際には落とし穴がありました。）
ただし、FlashPlayerを起動する必要があります。
最初は、1枚キャプチャーするたびにFlashPlayerを起動し、
キャプチャーが終わったら、FlashPlayerを終了していました。
（同期処理）
しかし、FlashPlayerの起動コストが高い！
そのため、FlashPlayerを常に立ち上げておく形にし、
特定のURLをポーリングして、データがあるときのみ
FlashLite1.1のFlashを読み込むような処理に変更しました。
（非同期処理）
結果、サーバの負荷は運用に耐えられるレベルに下がりました。
（最終的なソースの一部を文末のスライドに載せています。）
この仕組みが構築できたおかげで、
Flashの合成処理をそのままつかって、
サムネイルをつくれるようになりました。
画像を重ね合わせてサムネイルを作成するよりも、
（GDや、ImageMagickの重ね合わせ）
ベクターデータを重ね合わせた後にBitmapに落とす
こちらの方式のほうが、画像がきれいにみえます。
弊社ではガンガン活用しています。
弊社のソーシャルアプリを見たときに
ちょっと思い出してもらえればと思います。
（星空バータウン（弊社mixiモバイルのソーシャルアプリ） 画像キャプチャー例）
※プレゼン時の資料
FlashLite1.1のSWFを画像キャプチャーする