タグ

ブックマーク / labs.gree.jp (7)

  • グリーを支える通知システム | GREE Engineering

    はじめに このエントリは GREE Advent Calendar 2014 24日目の記事です。 こんにちは、インフラストラクチャ部の高野(@takano32)です。 いつも社内では GitHub:Enterprise の運用、 デプロイの改善、 大規模なインフラを操作するためのツール作成、 レガシーなサーバのセキュリティ対策、 コミュニケーションツール向けシステムの構築・運用、 などの仕事をしています。節操がありませんね。はい。 そのうち、今回は「コミュニケーションツール向けシステムの構築・運用」のうち「グリーを支える通知システム」という題目について書きたいと思います。 グリーとリアルタイムコミュニケーションツール まず、通知システムについてお話する前に、グリーでどのようなリアルタイムコミュニケーションツールが利用されてきたかを簡単に説明したいと思います。 リアルタイムコミュニケーシ

    グリーを支える通知システム | GREE Engineering
  • オンラインゲーム開発のいにしえの技術 | GREE Engineering

    開発部の堀口です。昨年は git による分散作業パターン を書き、つい先月は 札幌での講演 を行い、当文章ではゲーム開発の設計に関するネタです。 昔話交じりのポエムですが20日目としてよろしくお願いします。 オンラインゲームとは 20 年ちかく前に Quake というゲームがリリースされ、一見すると単なる一人称視点のシューティングゲームにしか見えないが、プレイヤー自身の Quake の世界を公開し、来場者と遊ぶことができた。当時でいえば、自分のホームページに CGI 掲示板を設置するのと似ていたと思う。 Quake は、ゲーム世界のふるまいと世界の変化を伝える入出力が非常に良く分離されており、参加するプレイヤーはその世界の中に現れた自分の分身となるアバターの行動のみを制御し、アバターの目の代わりに世界の変化を、わずかな情報にしてプレイヤーに伝えた。プレイヤーの目の前にある端末では、その情

    オンラインゲーム開発のいにしえの技術 | GREE Engineering
  • MySQLユーザーのためのMySQLプロトコル入門 #4 | GREE Engineering

    なんとなく気分で始めたMySQLプロトコル入門ですが今回は少し趣向をかえてbinlog formatについて書いてみたいと思います。 MySQLでのレプリケーションのメッセージ単位として使われているbinlogですが、そもそもbinlog(バイナリーログ)とはどういったものなのでしょうか?実際問題よくわからなくてもちょちょっと設定すれば素敵に動いてくれるのでわからなくても大丈夫っちゃー、大丈夫なんですがせっかく興味が湧いてしまった事ですし調べていきましょう。 http://dev.mysql.com/doc/internals/en/replication-protocol.html より引用してみます。 Replication uses binlogs to ship changes done on the master to the slave and can be written t

    MySQLユーザーのためのMySQLプロトコル入門 #4 | GREE Engineering
  • よくわかるLinux帯域制限 | GREE Engineering

    矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が

    よくわかるLinux帯域制限 | GREE Engineering
  • Trema で OpenFlow ネットワークプログラミング | GREE Engineering

    こんにちは、インフラストラクチャ部の大山です。 このエントリはGREE Advent Calendar 2013 22日目の記事です。 はじめに "ネットワークプログラミング" という言葉は、恐らくシステム屋さんにとって TCP/UDP あるいは IP といった L4, L3 の世界のプログラミングを想起させるのではないかと思います。ですが OpenFlow によって、そのレイヤが一気に L1 まで落ちました。つまり Layer-1 (物理層)までがプログラマブルに扱える領域になったということです。 これは主に Ethernet と IP に限定されるものの、従来 L1 から L3 の領域はネットワーク屋さんの領分で L4 以上がシステム屋さん、あるいはアプリケーション屋さんの領分という暗黙の了解を OpenFlow が無くしてしまいました。 今日は OpenFlow ネットワークを制御

    Trema で OpenFlow ネットワークプログラミング | GREE Engineering
  • イケててヤバいGit入門 | GREE Engineering

    この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか?私はダメです。ごめんなさい。(´・ω・`) WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基的にA successful Git branching model(有志の方による日語訳)にのっとって開発しています。 Gitについて基的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と

    イケててヤバいGit入門 | GREE Engineering
  • git による分散作業パターン | GREE Engineering

    分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o JavaC++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした

    git による分散作業パターン | GREE Engineering
  • 1