SQS、ElastiCache、Lambdaで作る高可用なアラート通知システム | GREE Engineering
インフラのいわほり（@egmc）です。 サーバ監視を構成するシステムは色々ありますが、今回はAWS環境上での監視に使われているアラート通知の仕組みについて紹介させて頂きます。 監視システムの構築そのものは2015年頃、AWSの本格的な利用に伴い、AWS環境を対象とした新規システム（AWSモニタリングシステム）の構築プロジェクトにて作成されたものですが、稼働から約2年が経過し、それなりに実績が積めてきたのではないかと思います。 通知システムにはYusuraという名前がついていて、機能的には過去のエントリで紹介されていたAWACSに近いものとなります。 主な機能としては 設定に基づいた通知先の振り分け アラートの集約(summarize) 同一アラートの抑制（suppress） インスタンスのタグ情報に基づいたignore処理（特定のタグがついているインスタンスを通知の対象とする） を行います
Capistrano ではじめるオートスケーリング | GREE Engineering
インフラの駒崎です。 Capistrano を使ったデプロイから、オートスケーリングをスムーズに導入するための弊社事例を紹介させていただきたいと思います。 こんな方へ 本稿で想定するのはこのような状況です。 Capistrano を使って中央管理型デプロイをしている AWS などのクラウドインフラを使ってオートスケーリングをやりたい オートスケーリング時のデプロイをどうするか検討している コンテナベースのデプロイやブルーグリーンデプロイには準備が足りない 理想は見えているもののなかなか進まない状況から、できるだけスムーズに改善を重ねることを目指します。 本稿のゴールは AWS でオートスケーリングを実現することです。 過度な一般化を避けるため、本稿では AWS 環境を前提として記述します。 オートスケーリングに必要なもの スケーリングのサイクルは、おおまかに次のように考えられます。 イメー
HTTP2を試してみる | GREE Engineering
初めまして、インフラストラクチャ本部の後藤です。普段はChefを用いたサーバの自動構築環境の開発に従事しております。 今回は、近頃若者の間でも話題になっているHTTP2についてお話したいと思います。 2012年の末頃、HTTP1.1のセマンティクスを維持したままパフォーマンスを改善するという目的でHTTP2の仕様策定が開始されました。そんなHTTP2もワーキンググループ・ラストコールに向けて大詰めを迎えています。 現在最新版はdraft12となっており、すでに幾つかの実装が存在しています。HTTP2のwikiで確認できます。例えば、Google ChromeのCanaryビルドやFirefox Nightlyビルド では既にHTTP2が使用可能です。 またサービスとしては、twitter.com が対応しています。 HTTP2の特徴 HTTP2はGoogleの考案したSPDYと言うプロトコ
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
GREEのUserAgent比率を公開します(2014/06) | GREE Engineering
人をダメにするソファとゴロ寝deスクを買ってしまったago（@kyo_ago）です。 これから定期的にGREEを利用して頂いているクライアントのUA比率を公開していきたいと思います。 OS Android iOS グラフは以下のデータを元に作成しています。 { "os":{ "Android":66.4, "iOS":33.5 }, "version":{ "Android":[ { "percent":35.8, "name":"4.2" }, { "percent":22.3, "name":"4.0" }, { "percent":21, "name":"4.1" }, { "percent":14.7, "name":"2.3" }, { "percent":4.2, "name":"4.3" }, { "percent":2, "name":"other" } ], "iOS":
CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering
Merry Christmas! GREE Advent Calendar もいよいよ最終日、25日目はグリー株式会社でCTOをしておりますふじもとがお送りします。 今日まで24人のGREE Engineersなみなさまにエントリを書いていただいたわけですが、思ったよりも多種多様な内容で、あらためていろいろな方面で素敵なエンジニアがいるなー、としみじみしてしまいました。いやしかしgitとchefの記事人気ですね、そして、「当然CTOはすごい記事書くんですよね」とプレッシャーをかけて楽しむ仲間たちに囲まれてぼくは幸せです、あーすごい幸せー。そんなプレッシャーの中、今までのエントリとはちょっと方向性を変えて、CTOの話でも書いてみようかと思います。なお、ぼくの趣味は多分問題解決です。 そんなわたくしふじもとは来年で、CTOっていう肩書きでお仕事をはじめて10年とかになるんですが、なかなか先輩と
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
グリーのインフラに 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の習得
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
ImageMagick 改造入門 (その四) | GREE Engineering
こんにちは。マルチメディアエンジニアリングチームのよやです。最近は ImageMagick の ストーキング(アップデートの差分追跡)に余念のない日々を送っています。 尚、本エントリは GREE Advent Calendar 2013 の 7日目です。よろしくお願いいたします！ ImageMagick をサービスに適用している皆様におかれましては、バージョンアップに大変な慎重さをもって臨まれていると思いますが、自分なりの薀蓄を共有出来ればと、バージョンアップに絡んだ最近の闘いの記録を公開します。(長文です) 参考までに今まで ImageMagick について解説したエントリを並べます。 ImageMagick 改造入門 (その壱) GIFアニメーション ImageMagick 改造入門 (その弐) 減色処理前編 ImageMagick 改造入門 (その参) 減色処理後編 GIF アニメ生
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 今回スポンサーセッションとしてひと枠頂き
第1回 サイバーエージェント×グリー合同勉強会 〜合同勉強会の作り方〜 | GREE Engineering
はじめまして。GREEの開発本部の吉川(@tsuyoshikawa)と申します。 普段は内製のソーシャルゲーム開発を中心とした開発業務を行っています。 一ヶ月前くらいの7月27日(水)に、クローズドな開催ではありますが、株式会社サイバーエージェント様(以下敬称略とさせて頂きます)と合同技術勉強会を開催しましたので、レポートさせていただきます。 合同開催に至った経緯やその進め方といった、GREEなりの「合同勉強会の作り方」を公開してみたいと思いますので、ご意見や反響を頂くこと、あわよくば「GREEと合同勉強会やりたい！」という声を頂くことが本エントリのねらいでございます。 なお、このエントリはサイバーエージェントのエンジニアブログと相互リンクさせて頂いていますので、こちら「あわせて読みたい」ということでよろしくお願いいたします。 ⇒サイバーエージェント 公式エンジニアブログ また、勉強会の当
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
大規模インフラの監視システム その2 | GREE Engineering
こんにちは。グリーのmdoi(@m_doi)です。 今回は、グリーの監視システムについて説明したいと思います。以前、こちらの記事にて、リソース監視システムの説明をさせて頂きましたが、死活監視やログ監視については語られなかったので、気になっていた方も多いと思います。ということで、今回は、グリーのインフラにおける死活監視やログ監視、アラート通知システムを紹介したいと思います。 何を使っているの？ グリーでは、死活監視にNagiosを使用していました。監視システムの中では、かなり有名なソフトウェアですから、監視システムの構築に使用したことがある方も多いのではないでしょうか。プラグインも豊富に存在するので、様々な監視を行うことができます。死活監視は、このNagiosの機能をそのまま利用し、ログ監視は、Nagiosと独自に作成したエージェント及びログフィルタを連携させて行っていました。 全体のシステ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
グリー主催 第1回『GREE Tech Talk』開催！ | GREE Engineering