10年もののメトリクス収集機構をリプレースした話 | GREE Engineering
インフラのいわほり（@egmc）です。 久々のエントリとなりますが、今回はインフラのMonitoring Unitとして長期的に取り組んでいた監視システムのリプレースについてのお話になります。 背景含めて長いエントリとなりますが、監視システムの長期的な運用の考え方、リプレースにあたって考慮した点などなにがしか参考になる点があれば幸いです。 何を移行したか？ グリーのインフラ環境では冒頭で述べたMonitoring Unitというインフラ横断で監視システムを提供するチームが商用環境向けの共通システムの提供/運用を行っています。 監視システムにおけるリソースモニタリングシステムの構成として、オンプレ環境ではGanglia、AWS環境ではPrometheus/Grafanaスタックを採用、運用してきました。 規模感としてはざっくりと監視対象ノードがオンプレサーバが約1500台、AWS側は台数変動
fluent-plugin-secure-forwardと戯れた話 | GREE Engineering
こちらのエントリーは「GREE Advent Calendar 2015 14日目」の記事です。 こんにちは、データエンジニアリングチームの山田です。6日目の記事の長谷川、田畠とともにグリーの分析基盤を良くする仕事をしています。主にデータ収集周りを担当しており、fluentdとはいつの間にか2年を超える付き合いとなりました。 さて今回は、fluent-plugin-secure-forwardについてつらつらと紹介していきたいと思います。 fluent-plugin-secure-forward(以下secure-forward)は、SSL/TLSを利用しセキュアにデータ転送を行うためのfluentd pluginです。fluentdにデフォルトで含まれているノード間を転送するためのforward plugin(以下forward)は転送時に暗号化などを行っていないため、インターネットを通
OAuth for Native Apps | GREE Engineering
GREE Advent Calendar 9日目は @nov が担当します。 僕は GREE ではセキュリティ部に所属しており、社外では OAuth や OpenID Connect などの Identity 関連技術についての翻訳や講演などを行ったりもしています。 今日は GREE Advent Calendar ということで、Native App コンテキストでの OAuth の話を少し書いてみようと思います。 はじめに Native App を開発していると、Backend Server とのやりとりや Facebook Login や Google Sign-in などで、必ずと言っていいほど OAuth 2.0 というのが出てきます。 OAuth 1.0 と異なりリクエストに署名が不要だったり、Client Secret (a.k.a Consumer Secret) 無しでも
オーケストレーション入門 - 多種多様化するサービスをConsulで連携させる | GREE Engineering
こんにちは、インフラストラクチャ本部のあだち(@foostan)です。 このエントリは GREE Advent Calendar 2014 19日目の記事です。昨日はにしだ(@hosi_mo)さんによるネイティブゲームクライアントの幸せな設計図でした。 今年のグリーアドベントカレンダーのテーマは「GREEを支える技術」ですが、私からは「GREEを支えるかもしれない技術」としてConsulについてご紹介します。 本エントリの対象者 本エントリでは、簡単なWebシステムを例にとって、Consulやその周辺ツールの基本的な使い方やオーケストレーションする仕組みについて説明していきます。 なので Consulって何？ Consulって便利そうだけどどうやって使うの？ Consul触ってみたけど、使いどころ分からないんだけど？ オーケストレーションって？ と思われた方にとって良い情報源になることを期
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
天下一InfluxDB勉強会開催してきました | GREE Engineering
こんにちは。ちょびえです。先日6/27(金)にDeNAさん会場にて天下一InfluxDB勉強会を開催してきました。当日はあいにくの悪天候ながら参加いただき有難うございました。また、会場を快く提供していただきましたDeNAさんに感謝申し上げます。 天下一InfluxDB勉強会 イベントページ きっかけはanatooのtweetにより始まりました 天下一influxdb勉強会の開催が待たれる — anatoo (@anatoo) May 29, 2014 もともとanatooとはPHPつながりで闇PHP勉強会など企画して頂いて参加させていただいていたのですが、今回は二人共InfluxDBに興味があるよね！ってことでInfluxDBの勉強会を企画・開催してきました。 本記事では天下一InfluxDB勉強会のレポートまとめ、という事で資料＋動画を簡単にまとめておこうかと思います。@sonotsさん
入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください！ こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaやScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得
AMQPによるメッセージング | GREE Engineering
こんにちは。GREEのプラットフォーム開発部でインフラ系の仕事をしているmdoi(@m_doi)と申します。よろしくお願いします。今回は、AMQPについて簡単に紹介したいと思います。 はじめに GREEで稼働中のサーバは、日々サーバの異常ログ、自己監視結果、メール等々、大量のメッセージをやり取りしています。しかしながら、共通のメッセージングインフラが存在しないため、それぞれが独立に色々なメッセージ送信を行っています。 サーバ台数の増大に伴って、メッセージ配送の負荷が無視できないレベルになって来ると、それらのメッセージングシステムについて、個別に負荷対策を施すなど運用上様々な問題が課題が出てきます。また、メッセージの種類によっては、その配送の仕組がスケーラビリティに欠けるものとが存在し、規模の増大に対応できなくなる恐れもあります。そのため、こういうった用途に使えるスケーラブルなメッセージング
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
ImageMagick 改造入門 (その弐) 減色処理前編 | GREE Engineering
こんにちは。クライアント基盤チームのよやです。 アバター等を表示する為に PNG や JPEG の画像を元に GIF アニメーションを生成する事がよくありますが、GIF は 256色までしか扱えない為、元画像が数万といった単位で色を使っていると減色処理に大変時間がかかります。そこで、ImageMagick の減色処理を改造して高速化した事例をご紹介します。 尚、一度に読む分量ではまとめ切れない為、前編と後編に分けました。前編は減色処理、後編はその改造について説明します。 プログラム構成では上の図の magick/quantize.c が減色処理に相当します。 まず、減色処理の一般的な話から始めます。 減色の利点 Web で見かける画像ファイルの多くは、1つのpixel(描画の最小単位)に対して、Red, Green, Blue が各々8bits で計 24bits(= 3bytes) 、透
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GREE Engineering