Android/iOS向けテストアプリ配信ツール 「EMLauncher」を公開しました : DSAS開発者の部屋
先日、TestFlightのAndroidサポート終了、Appleによる買収といったニュースが世間を騒がせましたが、皆さんテストアプリの配信はどうしていますか？ KLabでは自社製のテストアプリ配信ツール「EMLauncher」を使用しているのですが、せっかくなのでOSSとして公開することにしました。 https://github.com/KLab/emlauncher 今すぐ試す 今すぐ試したい方のために、セットアップ済みのAWS EC2イメージを用意しました。 ami-9b295f9a EMLauncher Sample インスタンスを起動後、設定ファイルのAWSアカウント情報を編集し、S3のバケットを作成してください。 (設定の詳細はconfigディレクトリのサンプルをご覧ください) /home/ohoflight/emlauncher/config/emlauncher_confi
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
ログからは見えてこない高負荷サイトのボトルネック : DSAS開発者の部屋
ちょうど１年前に「高負荷サイトのボトルネックを見つけるには」という記事を掲載していますが、この手のトラブルシューティングって結構大変で悩ましいですよね。はじめまして、新入りの@pandax381です。 ログからは見えてこないもの 「サイトの応答が遅い」という問題が発生した場合、その原因はどこにあるでしょうか。 Webアプリケーションの処理に時間が掛かっている DBサーバに投げたクエリーの応答が遅い サーバの処理能力を超えている などなど、いくつもの可能性があります。通常、上に挙げているような問題は、アプリケーションやサーバのログを調査することで、原因を突き止めることができます。 一方で、こういったログの調査だけでは、その原因にたどり着くことができなかったり、相当な苦労が伴うケースもあります。 あるサイトのある日の出来事 つい先日のことですが、KLabの運営している某ソーシャルゲームにて、サ
Linux 2.6 kernel の IPsec と NAT -- 2.6.15 と 2.6.16 の IPsec の違い : DSAS開発者の部屋
Linux 2.6 kernel の IPsec と NAT -- 2.6.15 と 2.6.16 の IPsec の違い 先に結論から書くと，2.6 kernel の IPsec を NAT と絡めて使う場合，NAT の方向によっては 2.6.16 以後のカーネルを使う必要がある，というお話です．2.6.15 系までのカーネルでは，意図したとおりに NAT が適用され無いことがあります．これは，IPsec のチャンネルを通るパケットが ESP パケットにカプセル化されるタイミング，に依るものです． ここ(日本語のページはこちら)にある図のように，iptables の各テーブルとチェインを順に辿っていきます．次のように IPsec 接続されたネットワークがあるとします． IPsec LAN 1 -- GW1 ======= GW2 -- LAN2 この場合，LAN1 から LAN2 に流れ
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
トラフィックが急増! ボトルネックを退治しよう〜 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の14日目です。 このシリーズも、初めは専らアプリケーション寄りの話題でしたが、ここ二回ほどはインフラ寄りの話題でした。今日はさらに(OSIの7階層モデルにあてると)下寄りの話題になります…。できるだけ分かりやすく書くつもりですので、お付き合い頂ければと思います。 負荷分散機がボトルネック さて、DSAS for Social ではいくつかのアプリケーションが動いているわけですが、では1つのアプリケーションがピーク時に使う帯域はどれくらいになるか、皆さん想像がつきますでしょうか。答えはもちろんアプリケーションによって全く変わるのですが、今まで記録した中での最大値は、2Gbps を越えました。これは、サーバに搭載されている NIC の能力を越えています。もちろん、1台の web サーバでこの
DSAS開発者の部屋:サーバ管理者向け無精のすすめ 〜ちょっと便利なツールの紹介〜
弊社のLinuxサーバ、ネットワークインフラのDSASの特徴のひとつに、100台近くある全てのサーバの内容が(数個の役割設定ファイルを除いて)同期されているという点があります。 これにより、 スケーラビリティ 予備機をサービス投入するだけで済むので、テレビCMなど突発的な高アクセス時にも迅速な対応が可能です。 増強が容易 サーバをラックマウントしたら適当なサーバからまるまんまコピーすればクラスタに参加可能です。まとまった台数の増強をする際に、いちいちCD-ROMからOSをインストールしていると日が暮れちゃいます。 役割の変更が容易 ディスクの内容が同じなので、もし、メールサーバが故障しても、適当なWebサーバの役割設定ファイルを変更して再起動するだけでメールサーバに早変わりできます。 メンテナンスが容易 ディスク上のファイルを更新した場合は、rsyncなどで全サーバに同期コピーすれば更新完
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KLab勉強会#6の資料公開 : DSAS開発者の部屋