EC2からFargateへの移行 ~shadow proxyとカナリアリリース~ | GREE Engineering
こんにちは、メディア事業でエンジニアをしている木村洋太です。 昨年のGREE Tech Conferenceでは「LIMIA」のフレームワーク移行プロジェクトにおけるコードの自動修正について話させていただきましたが、今回は同時に行ったインフラ移行について紹介いたします。 EC2からFargateへの移行例は多く存在しているとは思いますが、今回の移行では安全な移行のために、shadow-proxy環境での移行前のテストやEC2とFargateの同時稼働によるカナリアリリースなどさまざまな工夫を行いました。これらの中で得られた知見や失敗をまとめられたらと思っています。 インフラ移行の概要 フレームワーク移行プロジェクト フレームワーク移行プロジェクトでは、グリーが運営するメディアの一つである「LIMIA」のフレームワークをFuelPHPからLaravelへ移行することを目的としていました。 移
ソーシャルゲーム サーバーアーキテクチャ選定 | GREE Engineering
※Read / Write のレスポンスタイムは大まかに計測した値のため適切な設定ができていない場合もあることをご了承ください MySQL 信頼と実績のあるRDBMS。新規タイトルの場合AWSではAurora、GCPではCloud SQLを利用することで運用の手間をある程度減らすことができる。分散システムではないため1クラスタでの書込性能には限界があり、ソーシャルゲームのように大規模なwrite処理がある用途では水平/垂直分割が必要になり、そのための設計とコーディングが煩雑になりがちである。またインスタンスのスケールアップ・ダウンで対応しきれない場合のクラスタの分割・統合のオペレーションは複雑なものになる。 スケールアップ・ダウンやnodeのメンテナンスなどでMaster nodeを切替える際には不通時間が発生してしまうため、安全のためゲーム自体をメンテナンス状態にする必要が発生する。 ※
オンラインゲーム開発のいにしえの技術 | GREE Engineering
開発本部の堀口です。昨年は git による分散作業パターン を書き、つい先月は 札幌での講演 を行い、当文章ではゲーム開発の設計に関するネタです。 昔話交じりのポエムですが２０日目としてよろしくお願いします。 オンラインゲームとは 20 年ちかく前に Quake というゲームがリリースされ、一見すると単なる一人称視点のシューティングゲームにしか見えないが、プレイヤー自身の Quake の世界を公開し、来場者と遊ぶことができた。当時でいえば、自分のホームページに CGI 掲示板を設置するのと似ていたと思う。 Quake は、ゲーム世界のふるまいと世界の変化を伝える入出力が非常に良く分離されており、参加するプレイヤーはその世界の中に現れた自分の分身となるアバターの行動のみを制御し、アバターの目の代わりに世界の変化を、わずかな情報にしてプレイヤーに伝えた。プレイヤーの目の前にある端末では、その情
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
グリーのインフラに Chef を導入した話 | GREE Engineering
類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
せじまくんの刺さらない話（MySQL Slave増設編） | GREE Engineering
はじめまして。プラットフォーム開発本部のせじまです。好きなものはDisk I/Oです。 今回はMySQL（on Linux）のレプリケーションにまつわる、ちょっとしたお話をさせていただきたいと思います。 はじめに MySQL4.0以降のレプリケーションは、 Masterのmysqldが、INSERT/UPDATE/DELETEなどの更新情報を、バイナリログに記録する。 Slaveのmysqld(IOスレッド)は、masterのmysqldに接続し、バイナリログを転送する。 Slaveのmysqld(IOスレッド)は、受信したバイナリログ内容を、リレーログに記録する。 Slaveのmysqld(SQLスレッド)は、リレーログを読み込み、更新内容をslaveのDBに反映する。 といった仕組みになっています。図にすると次の通りです(*1)。 MySQLのレプリケーションはとても良くできた仕組みな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GREE Engineering