Thundering herd 対策の本命、 EPOLLEXCLUSIVE を試してみた : DSAS開発者の部屋
epoll を使った prefork 型アプリケーションサーバーにおける Thundering herd 対策の決定版として注目されていた EPOLLEXCLUSIVE が、 3/13 にリリースされた Linux 4.5 で導入されました。 昨年 SO_REUSEPORT というソケットオプションが登場して、 Thundering herd 対策として話題になったものの、ワーカーごとに listen キューが作られるため graceful restart するときに listen キューに入ってるリクエストを取りこぼす可能性があり利用するのが難しい状況でした。 参考: epoll の thundering herd 問題について解説しているサイト http://tech.geniee.co.jp/entry/so_reuseport http://uwsgi-docs.readthedo
リアルタイム通信環境の(一部)構成紹介 : DSAS開発者の部屋
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
「パスワードの管理を避ける」という考え方 : DSAS開発者の部屋
手持ちのアカウントが増えてくるとパスワードの管理方法が考えどころとなります。このところメジャーなネットサービスへの不正ログインやアカウントの悪用が相次いで報じられていることもあり パスワード管理の重要性は「古くて新しい問題」としてあらためて広い層に浸透しつつあります。 その一方でパスワードをきっちり管理することは必ずしも簡単ではありません。平易な内容だと第三者によって類推・導出されるリスクが大きいものの複雑にすると覚えにくい。だからと言って複数のサービスで同じものを使いまわすとそれが漏洩した場合に一斉に攻撃を受ける危険がある。結局、安全度の高いパスワードをサービスごとに使い分けることは人間の記憶だけでは困難なので何らかの外部記憶を利用することになります。ただし、それが何らかのデバイスであれコンピュータデータの形式であれ、情報としてそこへ保存した時点で盗難・流出の可能性はゼロではなくなります
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
Redis Sentinel で冗長構成を組む際の注意点 : DSAS開発者の部屋
KVS界隈ではすっかりおなじみ(?)のRedisですが、当社でも徐々にそのニーズが高まってきました。 標準機能として、レプリケーション、Pub/Sub、ソート等の便利機能が満載のRedisですが、サービスに投入する際に冗長構成をどう組むかといった点が気になっている方もいるのではないでしょうか。 まだまだ検証中ではあるのですが、Redisに実装されているRedisSentinelを用いて冗長構成を組んだ際にハマった所をご紹介したいと思います。 RedisSentinelとは Redisに標準実装されている機能の一つで、Redisのステータス監視、通知、自動フェイルオーバーが行なえます。 詳細な仕様、設定に関しては以下のドキュメントをご確認下さい。 http://redis.io/topics/sentinel RedisSentinel導入前の構成 特に何の変哲も無い構成です。 Redisサ
過負荷をかわす Apache の設定 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
親指サイズの USB 赤外線リモコンが面白い : DSAS開発者の部屋
2013.01.29 追記 Mac OS X 用の試作コードを掲載しました 昨年末、調べごとをしていた時にちょっと気になる商品が目に留まりました。 株式会社ビット・トレード・ワン 様の「USB 接続 赤外線リモコン KIT」という製品です。 特徴をざっくりまとめてみるとこんな感じです。 [パソコンから家庭用機器をリモコン操作]、[リモコンでパソコンを操作] の２つの機能を持つ 赤外線送信用のライブラリやツール・ファームウェアのソースコードが公開されている 家電協/ NEC/ SONY の各リモコンコードフォーマットに対応 某清涼菓子のケースにぴったり収まるサイズ キットは 1,680 円、組立ずみ製品でも 2,480 円と低価格 PC 側対応 OS はWindows 7, Vista, XP PC から制御可能な学習型赤外線リモコンといえば 2006 年の発売以来ロングセラーを続ける PC
並列プログラミング（その１） : DSAS開発者の部屋
1.マルチプロセッサ時代の並列プログラミング Pentium4でHyperThreadingが採用されてから、一般的なPC用のCPUでも並列動作が発生するようになりました。 マルチスレッドプログラムにおいて、シングルプロセッサ環境では問題にならなかった事が、マルチプロセッサ 環境では問題になってきます。 もちろん、pthreadなどを利用して普通にプログラムを書いている場合は、複数のスレッドから同一の メモリにアクセスするところを全てMutexやSemaphoreで同期しておけば問題ありません。が、プロセッサ間の 同期ってどんな問題があってどうやって対処しているのか気になったので、調べてみました。 IntelやAMDのDeveloper's Manualなどを読んで勉強しながら書いているので、間違っている部分が あるかもしれません。間違いに気づかれた方は、宜しければコメントやトラックバック
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
クラッシュダンプからカーネルメッセージを取り出すツール「crashdmesg」を作りました : DSAS開発者の部屋
Linuxカーネルには、カーネルパニック時にkexecを使ってダンプ取得用のカーネル(セカンドカーネル)を起動する仕組みがあります。 このセカンドカーネルは予めリザーブされたメモリ内で起動するため、クラッシュしたカーネルが処理していたメモリの内容はそのまま残っていて、procファイルシステム経由でクラッシュダンプを取得する事ができます。 このDSASブログでも、以前「Linuxでクラッシュダンプを採取(1) 〜 kexec + kdump を使ってみる 〜」と言うタイトルでクラッシュダンプの取得方法をご紹介しました。 「crashdmesg」は、kexec+kdumpで保存したクラッシュダンプから、カーネルメッセージの内容を取り出すツールです。 デバッガと比べてはるかに軽量なため、セカンドカーネル上で直接/proc/vmcoreからカーネルメッセージを取り出すこともできます。 最近のクラッ
負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋
負荷試験ツール インターネット破壊を公開しました。 こちらはずっと社内で負荷試験に使用していたツールです。社内で使用していたものなので、ソーシャルアプリ向けの機能などが多少追加されていますが、もちろんんそれ以外のWebアプリケーションでも使用できます。 基本的にはApache JMeterのようなWebアプリケーションむけのシナリオ負荷試験ツールです。コマンドラインオペレーションだけで実行でき、サーバー上で簡単に負荷試験を実施できるのが特徴です。POSTリクエストなどはもちろん、レスポンスのチェックやUserAgentの偽装、ランダムな値をパラメーターにセットする機能も実装しています。 注意: 当然ながら自分の管理下にないサイトに向けて負荷試験ツールを実行するのは絶対にやめてください。非常に危険です。 物騒な名前がついていますが、これは完全にわたしの小児的感性の趣味によるところです。地震で
Windows用フリーウェア「MyCloudFile」を公開します : DSAS開発者の部屋
※2015.04.02 追記 2010年に公開した本ソフトウェアの実装には Google 固有の認証方式である「ClientLogin」を使用していますが、Google 社は本年 4月20日をもってこの ClientLogin のサポートを終了する旨を表明しています。本ソフトウェアの公開当時にはストレージサービスとしての「Google ドキュメント」のユーザインターフェイスは発展途上の段階にありこうした補助的なソフトウェアにも相応の役割がありましたが、その後同社サービスのブラウザでの操作性が格段に向上した事情も踏まえ、総合的に判断した結果、今回の Google 社側の措置に伴い本ソフトウェアの配布・サポートをこの機に一旦終了させて頂きたいと考えています。何卒ご理解・ご了承下さいます様お願い致します。本ソフトウェアをご利用頂いた皆様に謹んで御礼申し上げます。 （※以下は過去の補足記事です）
DSAS開発者の部屋:GREEさんの勉強会の資料を公開しました
先日発表してきた、グリーさんの 第9回 オープンソーステクノロジー勉強会 『DSASのいろいろ』の発表資料と音声を公開しました。 発表資料 (PDF, 2,294 KB) 音声 (mp3, 32,151 KB) 発表はこんな内容です。 自己紹介 [0:22] (1) DSASの特徴の紹介 [6:34] 設計思想、全体構成など (2) DSASの構成要素の紹介 [17:22] ロードバランサ - LVS, keepalived [17:33] ネットワークブートの活用 [30:23] 故障に強いストレージサーバ - DRBD [37:15] NICの二重化 - bonding [44:29] シリアル接続 温故知新 [46:24] サーバリソースの見える化 - ganglia [49:11] 質疑応答 [58:00] 発表はかなり駆け足でしたが、 ロードバランサ (LVS, keepaliv
クラスタファイルシステム「lustre」を触ってみます : DSAS開発者の部屋
負荷分散環境では必須ともいえるネットワークストレージですが、皆様の環境ではどのようなものをお使いでしょうか。 「ファイル共有なんてなくしてしまえっ！！」って言いたくなることも時々あったりしますが（笑）、画像などの素材データ類はDBに格納するよかファイルとして扱う方が運用上楽だったりするので、そう簡単に抹殺するわけにもいきません。 DSASではDRBDで冗長化したNFSサーバ（もちろんLinuxベース）をネットワークストレージとして使っていますが、構成上どうしても特定のサーバに負荷が集中しがちになるのが悩みの種です。 特にせっぱ詰まって困ってる訳ではないのですが「どーしたもんかなあ」と物思いにふけっていると、いつもお世話になっている協力会社の方から「lustreってのもあるよん」と教えてもらったので軽く調べてみました。これはなかなか楽しそうなクラスタファイルシステムじゃあないですか！ lus
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
カラフル端末で視認性を高める - grepとシェルのプロンプト編 : DSAS開発者の部屋
このブログに含まれる「DSAS」という文字列をgrepしてみます。 どこに「DSAS」があるのかさっぱりわかりません (^^; grepの結果を| less -p DSASとかに渡せばlessがハイライトして識別しやすくなるのですが、ここはgrepのカラフル機能(--color=auto)を使ってみます。 だいぶ識別しやすくなりました。 ハイライトの色を変更するには、色指定を環境変数GREP_COLORにセットします。指定の形式は前回紹介したlsのdircolorsと同じです。例えば、太字の黄色にしたい場合はこのようにします。 export GREP_COLOR='01;33' あと、毎回--color=autoと指定するのは面倒なので、環境変数GREP_OPTIONSにセットしておきましょう。GREP_OPTIONSにセットしたオプションは、暗黙的に効果を発揮します。 export GR
DSAS開発者の部屋:ネットワークパケットを覗いちゃえ
レイヤを問わず (ethernet から HTTP や SMTP まで) 、ネットワーク絡みのトラブルシューティングや挙動の確認をするときにパケットの流れが見られると非常に有益です。 開眼すると「パケットの流れが目で見える」そうですが、私などはまだまだ修行が足りず裸眼では見えないので、tcpdump というツールを使って見ています。 tcpdump はその名前があまりよくないと私は思っていて、"tcp" だけでなく udp やICMP や ethernet フレームまで覗ける超強力ツールです。 というわけで tcpdump の簡単な説明を書いてみます。 tcpdumpについて tcpdump は UNIX 系の OS で使えるツールなのですが、Windows 用にはWinDumpという CUI のツールがあり、tcpdump と同じように使えます。 GUI がお好みの方は、後でも紹介するE
OpenSSH クライアントの proxy -- 踏み台サーバを経由しての ssh : DSAS開発者の部屋
DSAS のメンテナンスは，基本的に ssh を使ったリモートメンテナンスで済んでしまいます．夜中や休日に非常事態が起こったとしても，ネットワーク接続さえ確保できればその場で対応できます．ただ，さすがにインターネットから DSAS に直接 ssh できる様にしておくのは一抹の不安があります．ですので，DSAS への ssh 接続は社内のサーバからのみ許すようにしておいて，外からログインする必要があるときは一旦社内のサーバを経由することにしています． このような形にしている場合，DSAS にログインしようとする際は，一旦社内のサーバに ssh 接続する必要があって，小さなことですが一手間かかってしまいます．できればワンステップで接続できる方法が無いかと思って色々検索してみた(※)ところ，このページで ProxyCommand という設定項目を見つけました(見つけたのがボスの個人サイトなのは本
DSAS開発者の部屋:keepalivedの運用ノウハウお見せします 〜 設定ファイルを同期する
keepalivedはLinuxで冗長構成を組む道具としてとても便利ですが、運用面に関する配慮に物足りなさを感じることがあります。例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑） naoyaの日記でnaoyaさんも悩んでいるようですが、設定ファイルをうまく保守する仕組みをどう作るかが導入する際の大きな鍵になると思います。今回は、DSASではどのようにして2台のkeepalivedを運用しているかを少しだけご紹介させて頂きたいと思います。 1) マスターで設定ファイルを編集する 2) バックアップに設定ファイルを転送する 3) バックアップで設定を反映する 4) マスターとバックアップの差分を確認する 5) マスターで設定を反映する 具体的にはどのようにしているかというと、、、 lv1:# vi 設定ファイル lv1:# lvs-sync -ine lv1
高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、 こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや？」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
