Linux TC (帯域制御、帯域保証) 設定ガイドライン | GREE Engineering
Abstract このドキュメントはLinuxにおいて帯域制限のためにtcを用いる際のガイドラインです。 tcは様々な用途に活用できるものですが、プロダクションにおいて特定のserver daemonのトラフィックを制限するというシナリオで活用することを目的としています。 tcのより詳しい詳細については別にドキュメントを書きましたのでそちらを参照してください。 よくわかるLinux帯域制限 Root qdiscの選定 帯域制限を行いたい場合のqdiscは主に以下のようになるでしょう。 TBF PRIO + 内部qdiscとしてTBF HTB それぞれ用途に合わせて適切なものがあるのですが、機能としてはHTBが前者2つの上位互換となるので、迷った場合にはHTBを使えば問題ありません。ということで以後HTBの設定について解説します。 class構造,トラフィックのclassify, filte
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
MySQLユーザーのためのMySQLプロトコル入門 | GREE Engineering
さいきんMySQLユーザーのためのほげほげ、みたいなのが巷で流行しているようなので暇つぶしがてらに読んでいるMySQLプロトコルについて書いてみようかと思います。 いやまぁ、こういうプロトコルが読めるからといってすごく役立つということは全くないんですが、お酒の席のネタにできたり、高速、簡単、無料で試せるRDS MySQLからRedshiftへのデータ同期に出てくるようなreplicationをいじったツールとかのメンテが容易にできるかもしれなかったり、俺mysqldだぜ、みたいな事ができたり、なんかよくわからないけどちょっとハッピーになれそうですね！ 今日は手始めにMySQLとmysql clientがどういう通信をしているのか見ていき、実際にInitial Handshake Packetをparseしてみるところまでをやってみます。 Max OSXでのセットアップ 普段homebrew
グリーのインフラに Chef を導入した話 | GREE Engineering
類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください！ こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaやScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
開発ワークフローを、いつどう変えるか | GREE Engineering
こんにちは、岡崎 @watermintです。 このエントリは GREE Advent Calendar 2013の記事です。この記事は5日目の記事です。 今日はGREE Tech Talk #04 スマートフォン時代のソフトウエアテストが弊社セミナールームで行われます。岡崎は「Jenkinsによるテスト自動化の会社への導入」というパネルディスカッションに参加させていただきます。パネルディスカッションの内容がどうなるかは会場の皆様からのご質問などによって変わっていくと思いますが、今日の記事では開発ワークフローについての考えを紹介します。 開発プロセスをなぜ変えるのか 開発プロセスを変えようとするモチベーションはいくつかあると思います。組織規模、ビジネスモデルなどによって多少諸条件は違うとしても大まかには次のような目標を達成することがモチベーションになるでしょう。 開発メンバーが変わっても対応
GREEにおけるJenkins, その5 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。 今回も前回に続き初期導入のお話です。 どんどん水平展開する Jenkins導入初期で、いくつかジョブが動き始めるようになったら類似のプロジェクトにどんどん水平展開していくのが最も簡単な方法です。Jenkinsには既存のジョブをコピーして新しいジョブを作る機能がありますので、これを積極的に使いましょう。 GREEでの導入事例ではまず最初に、iOSネイティブアプリのビルドに導入し、ある程度安定して運用が出来上がった段階から、新規開発機能向けのgitブランチを追いかける別のジョブを作る等まずは類似のプロジェクトへの展開を最初に行いました。 同様に、PHPのコードをテスト＆品質チェックするプロジェクトも最初に作ったジョブをベースにコピーして各種プロジェクトで利用しています。PHPのJenkins上での環境整備についてはPHPでTDD&CI
GREEにおけるJenkins, その6 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。 今回は、Jenkinsを運用に使うテクニックを紹介します。 JRubyとgemをgitで管理 GREEのシステムではいくつもの管理系のスクリプトがあるのですが最近岡崎が管理している管理系スクリプトはすべてRubyで書いています。実行はRubyのJava実装であるJRubyを使っています。また管理系スクリプトと一緒に、JRubyのランタイムやGEM(Rubyのパッケージ管理システム)レポジトリ一式もgitで管理しています。これの狙いは二つあります。 どのSlaveでも動作する Jenkins SlaveもJavaで動いています。ということは、JRubyを実行するのに必要となるJavaは既にある訳で、Slave側のソフトウエア構成を気にせず実行することが出来ます。OSを選ばないのも大きなメリットです。 バージョンが指定できる すべての
GREEにおけるJenkins, その4 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。 今回は、先日行われたJenkinsユーザカンファレンスで発表した内容をもう少し掘り下げて紹介していこうと思います。今回のカンファレンスでは、「開発者とディレクターの視点を変えていく方法」と題してJenkins初期導入時のこつ、その後の運用の改善について説明していきました。今回は特に初期導入の部分についてもう少しご紹介します。 Jenkins導入のコツ Jenkinsを導入したいがなかなか進まないという経験をお持ちの方は多くいらっしゃると思います。CI(継続的インテグレーション)のようなツール群は一度回り始めれば必要不可欠とも思えるような仕組みを持っていますが、利用経験の無い方からすると得られるメリットのイメージが既存の仕事のやり方やワークフローを変えるコストをなかなか超えることが出来ないために積極的になれないということが多いようで
Jenkins ユーザ・カンファレンス 2012 東京 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。7月29日に行われましたJenkins ユーザ・カンファレンス 2012 東京に参加してきました。今回は簡単にそのレポートを。 うだるような夏空のもと、なんと600名近い参加者が会場提供いただいた法政大学に集まりました。 カンファレンスの内容については参加された多くの方によってまとめられているのでそちらをぜひご覧ください。 2012/07/29Jenkins ユーザ・カンファレンス 2012 東京 Vol.1 #juc2012 (Togetter) 2012/07/29 Jenkins ユーザ・カンファレンス 2012 東京 Vol.2 #juc2012 (Togetter) [勉強会][Jenkins]Jenkins ユーザ・カンファレンス 2012 東京 に参加してきた #juc2012 今回スポンサーセッションとしてひと枠頂き
GREEにおけるJenkins, その3 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkins導入1年半のなかでの、反省点とこれから導入する方へのおすすめを紹介します。 GREEでのJenkins(当時はHudson)導入は、最初、岡崎の個人的な導入から始まりました。そこから徐々に利用してもらえるプロジェクトが増えて、いまや開発には欠かせないシステムに成長しました。今回は、この1年半でのJenkins導入の反省点と、これから導入される方へのTIPSをご紹介します。 ジョブの命名規則 Jenkinsに登録されているジョブも100を超えるようになってきた昨今、そろそろてこ入れをしたい問題です。 ジョブは1画面に収まる程度であれば、Jenkinsダッシュボード画面でも難なく目的のジョブを探し出したり、ジョブの状態を確認することが出来るのですが、さすがにジョブを探すためにスクロールをしなければなら
GREEにおけるJenkins, その2 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単
GREEにおけるJenkins, その1 | GREE Engineering
はじめまして。エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsの利用について紹介します。 Jenkinsは継続的インテグレーションの代表的なツールです。JenkinsがどういうものかはJenkinsコミュニティーの説明をみると良く分かります。 一言で言えば、Jenkinsは、容易ないわゆる「継続インテグレーションシステム」を提供し、開発者が変更をプロジェクトに統合でき、ユーザーがより新しいビルドを容易に取得できるようにします。自動化された継続的なビルドは、生産性を向上させます。 Meet Jenkinsより 継続的インテグレーションという言葉について耳慣れないというかたは、JenkinsならびにJenkinsの前身であるHudson開発者である川口さんによる解説をご覧ください。 Hudsonを使ったアジャイルな開発入門 GREEにおけるJenkinsの導入
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
"PHP Apocalypse"を開催しました！ | GREE Engineering
どうも。GREE開発本部の吉川(@tsuyoshikawa)です。 この記事はGREEのエンジニアブログではありますが、PHP AdventCalender2011の12/21の回ともなっています。 去る12/17(土)に、弊社会場、主催私で"PHP Apocalypse"なるイベントを開催しましたので、それのふりかえりとご紹介をさせて頂こうかと思います。 イベントの概要 - ATND "PHP Apocalypse"とは このイベントはいわゆる技術勉強会ではありますが、直接的には過去にはてなブックマークで300くらいのユーザを集めた“PHP のよいところとよくないところ - id:k-z-h”というエントリーへのリアクションがきっかけになって起こっています。 エントリーの内容はPHPの批判が含まれるものとなっていますが、その批判自体にどうこうというより、エントリーを書いたid:k-z-h
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
