ISUCON6 で優勝しました : DSAS開発者の部屋
@methane です。タイトルの通り、 ISUCON でとうとう優勝してきました。 チームメンバーは、(予選と同じく) @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) でした。 私は予選のときはガッツリとアプリを書いていたのですが、本戦では netstat -tn (←老害), top, dstat -ai, sudo perf top などをみつつ指示をだしたり、方針を決めたり、完全に未経験だった node.js & react.js 対策をしたりが主な仕事で、あとは序盤のインフラのタスクが大量にあるときに MySQL を docker から外して基本的なチューニングを入れたり Go を100行程度書いただけです。 結果的には優勝できましたが、メンバーの2人がよく準備し本番でも実力を発揮してくれたのに対して 僕の戦略ミスで中盤から全くスコアを上げられなかったので
リアルタイム通信環境の(一部)構成紹介 : DSAS開発者の部屋
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
Go ではエラーを文字列比較する？という話について : DSAS開発者の部屋
Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか？ 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の（文字列比較によらない）エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、
Goでアロケーションに気をつけたコードを書く方法 : DSAS開発者の部屋
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア
チャットで学ぶ Go ネットワークプログラミング : DSAS開発者の部屋
簡単なチャットプログラムは、ネットワークプログラミング用のフレームワークでは定番のサンプルプログラムです。 echo サーバーが Hello World とするなら、チャットは FizzBuzz といったところでしょう。 とりあえず動くだけのチャットならだれでもすぐに作れるようになりますが、まじめにチャットを作ることで、 ネットワークプログラミングで考えないといけない点やエラー処理の重要な基礎を学ぶことができます。 ということで、 Go でシンプルなチャットを実装してみました。 (ソースコード) 以降、何を考えてどういう設計を採用したのかを解説していきます。 考慮すべきポイント 特定のクライアントへの送信に長時間待たされた場合に、他のクライアントへの送信が遅れないようにする。 クライアントを切断するのは、 (1)ルーム側から kick する場合, (2)受信エラー, (3)送信エラー の3
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
Redis Sentinel で冗長構成を組む際の注意点 : DSAS開発者の部屋
KVS界隈ではすっかりおなじみ(?)のRedisですが、当社でも徐々にそのニーズが高まってきました。 標準機能として、レプリケーション、Pub/Sub、ソート等の便利機能が満載のRedisですが、サービスに投入する際に冗長構成をどう組むかといった点が気になっている方もいるのではないでしょうか。 まだまだ検証中ではあるのですが、Redisに実装されているRedisSentinelを用いて冗長構成を組んだ際にハマった所をご紹介したいと思います。 RedisSentinelとは Redisに標準実装されている機能の一つで、Redisのステータス監視、通知、自動フェイルオーバーが行なえます。 詳細な仕様、設定に関しては以下のドキュメントをご確認下さい。 http://redis.io/topics/sentinel RedisSentinel導入前の構成 特に何の変哲も無い構成です。 Redisサ
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
