受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering
こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し
10年もののメトリクス収集機構をリプレースした話 | GREE Engineering
インフラのいわほり（@egmc）です。 久々のエントリとなりますが、今回はインフラのMonitoring Unitとして長期的に取り組んでいた監視システムのリプレースについてのお話になります。 背景含めて長いエントリとなりますが、監視システムの長期的な運用の考え方、リプレースにあたって考慮した点などなにがしか参考になる点があれば幸いです。 何を移行したか？ グリーのインフラ環境では冒頭で述べたMonitoring Unitというインフラ横断で監視システムを提供するチームが商用環境向けの共通システムの提供/運用を行っています。 監視システムにおけるリソースモニタリングシステムの構成として、オンプレ環境ではGanglia、AWS環境ではPrometheus/Grafanaスタックを採用、運用してきました。 規模感としてはざっくりと監視対象ノードがオンプレサーバが約1500台、AWS側は台数変動
MySQLのmetricに関する話 | GREE Engineering
こんにちわ。せじまです。さいきん、ジム用に左右独立型スポーツモデルのBluetoothイヤホン買ったのですが、あまりの快適さに、ジムに通うモチベーションが５割増しになりました。 はじめに innodb_thread_concurrency について書こうかと思ったんですが、まずはその前に MySQL の metric の話から入ったほうが良いかなぁと思ったので、今回は metric の話を書こうと思います。はじめにお断りしておきますが長くなります。 弊社では７年以上前から、 MySQLのサーバ一台あたり（OS側のも含めると）200-300 以上の metric を だいたい15秒間隔で記録しています。最近はSSDなども使ってますが、むかしはHDDにmetricを保存していました。例えばMySQLのサーバ一台分のmetric表示した画面をキャプチャすると、次のような感じになります。 ※画像は
Prometheusによる数百台規模のモニタリングで直面した問題について | GREE Engineering
インフラの反田 (@mtanda) です。 GREEでは、多くのサービスをAWS環境で運用しており、それらサービスのモニタリングシステムとしてPrometheusを利用しています。 Prometheusを導入してから約2年がたち、1台のPrometheusで数百台規模のインスタンスをモニタリングするなかで、さまざまな問題に直面しました。 それら問題の原因を分析し、設定や利用の仕方を改善することで、ある程度安定して運用できるようになりました。 これらの知見が少しでもお役に立てばと思い、ここで共有いたします。 なお、対象とするPrometheusのバージョンは1.xです。Prometheus 2.0では、これら問題のほぼ全てに対して改善されています。そのため、2.0でどういった点が改善されているかを知るためにも有用だと思います。 Prometheusのストレージ実装の基礎知識 Promethe
Deep Learning を用いた画像識別モデルの導入 | GREE Engineering
背景 僕の開発担当しているチームでは、プロダクト（ SNS、Web ゲーム等 ）におけるユーザの任意投稿をオペレータによって目視で監査し、サービス運営上、不適切な投稿の検知と削除を行っています。 しかし、ユーザ投稿すべてを目視で監査するのはオペレータの負荷が高いため、不適切と思われる投稿をシステムで選別した上で、オペレータの目視監査に回しています。 ここで、具体的に不適切な投稿とは 異性との出会いを希望・誘導する投稿（青少年の健全な育成） 個人情報を掲載する行為（個人情報保護） わいせつ、およびグロテスクな内容（サービスクオリティ維持） 等 グリーが禁止している行為を指します。 上記、システムの精度向上が僕らチームの目標となっています。中でも画像付きの投稿はシステムによる選別が難しく、大量に目視監査に回すことでサービスのクオリティを維持しているという課題がありました。 そこで今回、ユーザの
Docker と ECS と WebSocket で最強のリアルタイム・マルチプレイ環境を運用 | GREE Engineering
概要 AWS ECS でマルチプレイゲーム用インスタンスの管理すると限りなく最強。 はじめに リアルタイム・マルチプレイゲームを作る時、まず考えられることは、あるプレイヤーの行動や状態が他のプレイヤーに伝わることではないかと思われます。しかし、スマートフォンアプリは不安定であったり、複数端末同士で(基地局やバックボーンを介さずに)物理的に直接接続することは出来ませんし、理論的にできたとしても、だいたい開発が進んでいくうちに排他制御の問題などで炎上、もしくはとん挫してしまいます。軽い気持ちでマルチスレッド処理をおこない事故る現象と全くおなじです。 もっとも簡単な解決方法としてはマルチスレッド処理のときようにクリティカルセクションを設けることです。ようはサーバを用意してそこで処理すれば、比較的容易に一意な結果が得られますし、接続に関する問題も起こりにくくなります。 長くなるので → http:
Subiamを使いAWSのIAM管理をコードベースでおこなう | GREE Engineering
矢口です。 みなさんはAWSのIAMをどのように管理されていますか？ グリーでは色々な要件からMiamというツールをforkして Subiam というツールを開発し利用しはじめました。 Subiamは既存のAWSアカウントのIAM運用を阻害せずにコードベースで安全なIAM管理を始めることのできるツールです。 https://github.com/gree/subiam 特徴 コードでIAMを管理できる 差分を自動検出して適用 IAM全体ではなく任意の範囲だけを切り取って管理でき、システム全体に影響を与えないよう配慮されている dryrunできる 現在の状態をユーザーが管理し保存しておく必要がない 複数AWSアカウントで扱いやすいようRole Nameなどを自分で定義でき共通にできる 既存ツールとの比較 ツールの優劣を示すものではなく、自分たちに必要であった要件についてのみ比較しています。
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) 無しでも
EthernetやCPUなどの話 | GREE Engineering
こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、（標準化されてないけれど） Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取
CPUに関する話 | GREE Engineering
こんにちわ。せじまです。スティック型PCの購入は、 Core M版が出るまで見送ろうと思っている今日このごろです。 弊社では「Mini Tech Talk」という社内勉強会を隔週で開催しているのですが、それとは別に、「Infra Tech Talk」という社内勉強会を、半年くらい前から毎月開催しています。わたしはそこでほぼ毎月、45-60分くらいのスライドを作って話をしています。今までどういう話をしてきたかといいますと、TCPに関する話を二回、SSDに関する話を二回しました。（InnoDBに関する話だと軽く5-6時間くらいできるんですが、いささかマニアックなので、もっと幅広い人を対象に話をしています） 今までの話はちょっと社内向けの内容だったんですが、前回開催された Infra Tech Talk では、社外の方にも幅広く読んでいただける話ができたと思いましたので、その資料を slides
忙しい人のための MySQL 5.7.6 DMR における InnoDB Flushing の変更点について | GREE Engineering
こんにちわ。せじまです。 Cherry Trail が出たら艦これ用タブレット買い換えるべきか、思案している今日このごろです。 5.7.6 での InnoDB Adaptive Flushing の重要な変更を三行をまとめると redo log の更新頻度も考慮されるようになりました。更新頻度に比例して flush される dirty page の量が増減するようになりました。 innodb_io_capacity_max 上げ過ぎないほうが良いでしょう。場合によっては innodb_flushing_avg_loops も見なおしてよいでしょう。 innodb_buffer_pool_instances >= 2 のとき、dirty page が多い instance ほど、多くの dirty page が flush されるようになりました。 詳細な内容についてご興味のある方は続きをど
MySQLユーザーのためのMySQLプロトコル入門#2 | GREE Engineering
前回の記事ではInitial PacketまでParseしました。今回はAuth Response Packetを作って認証までやってみましょう Handshake Response Packet 認証の一連の流れはhttp://dev.mysql.com/doc/internals/en/connection-phase.htmlに書いてあるので図をさらっと眺めつつ行きます。 ServerからInitial Packetを受け取った後に、ClientがHandshake Response Packetを作ってServerに送信すれば認証結果が返されます。 毎度のごとくdev.mysql.comからデータの定義の説明を参照するんですが、if文が入っていて分かりづらいので認証を通すために必要な部分だけを抜粋してみました: 4 capability flags, CLIENT_PROTOCOL
MySQLユーザーのためのMySQLプロトコル入門 | GREE Engineering
さいきんMySQLユーザーのためのほげほげ、みたいなのが巷で流行しているようなので暇つぶしがてらに読んでいるMySQLプロトコルについて書いてみようかと思います。 いやまぁ、こういうプロトコルが読めるからといってすごく役立つということは全くないんですが、お酒の席のネタにできたり、高速、簡単、無料で試せるRDS MySQLからRedshiftへのデータ同期に出てくるようなreplicationをいじったツールとかのメンテが容易にできるかもしれなかったり、俺mysqldだぜ、みたいな事ができたり、なんかよくわからないけどちょっとハッピーになれそうですね！ 今日は手始めにMySQLとmysql clientがどういう通信をしているのか見ていき、実際にInitial Handshake Packetをparseしてみるところまでをやってみます。 Max OSXでのセットアップ 普段homebrew
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
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
柔軟な IT インフラとそれを支える技術 | GREE Engineering
こんにちは、インフラストラクチャ本部の大山裕泰です。最近話題の WhiteBox スイッチと、そのミドルウェアについてお話したいと思います。 柔軟な IT インフラを目指して 我々に限らず IT インフラに携わるエンジニアにとって、アプリケーションレイヤの人たちが望むアプリケーション実行環境の構築・運用は主要な目標の一つかと思います。 アプリケーション実行環境の形態は様々ですが、突き詰めてゆくと物理的なネットワーク機器に Ethernet ケーブルで接続された物理サーバの集合になります。やや管理的な話になりますが、こうした物理機器は減価償却してゆくので、これが終了するあるいはサポートが切れるまでの 4～5 年の期間、同じ機器を使い続けることになりますので、機器の選定においては長い目で見る必要があります。 これに対して、アプリケーションやアプリケーションを取り巻く環境は日々目まぐるしい速度で
入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください！ こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaやScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得
過去をふり返るためのしくみ (主に MySQL) | GREE Engineering
どうも、いちい (@ichii386) です。 GREE Advent Calendar 2013 の 24 日目です。 もうクリスマスですね。もしかしたらプレゼントを買わなきゃいけないのに何も準備してなくて、今日は仕事終わったら急いで買いに行かなきゃ、なんて焦っている人もいるかもしれません。 去年のクリスマスは? 去年は何買ったんだったかな、と思い返し、 20日に給料とボーナスが出たので、予算はいくらくらいだった 相手はちょうど引っ越したので、部屋にモノが少なかった なんてとこから「あー、ペンダントライトをプレゼントしたんだったな」とか思い出します。しかし去年はちょっと高かった割にあまり喜んでもらえなかったし、今年はボーナスが減ったのでできたら予算は減らしたいです。(※完全に架空の話なんでご注意ください) 今年を改善するためにも、まずは去年をふり返ることが重要です。プレゼントを決めるには
SWFバイナリ編集のススメ番外編 (zlib 伸張) 前編 | GREE Engineering
こんにちは。アプリケーション基盤チームのよやと申します。 バイナリの目利きや書き換えを主な業務フィールドとし、1% でも多くのユーザの皆様にサービスをお届けする為、より良質のバイナリを探し求める毎日です。 SWF の番外編として zlib 伸張について２回のブログに分けて解説します。(圧縮処理は対象外です) 前編の今回は概要についてお話し、具体的な実装は後編で扱う予定です。 はじめに SWF フォーマットは zlib 圧縮を多用します。例えば、GIF/PNG 画像は独自画像形式(DefineBitsLossless の BitmapPixelData)に変換後 zlib 圧縮して格納します。 http://labs.gree.jp/blog/2010/12/1902/ SWFバイナリ編集のススメ第五回 (PNG) SWF バイナリの中の zlib 圧縮されたデータが怪しい場合に、zlib
『エキスパートObjective-Cプログラミング - iOS/OS Xのメモリ管理とマルチスレッド』 | GREE Engineering
こんにちわ。エンジニアの坂本 一樹(@splhack)です。 今回は、スマートフォンアプリ開発に非常に役立つ本を紹介させていただきます。 『エキスパートObjective-Cプログラミング - iOS/OS Xのメモリ管理とマルチスレッド』という本です。 はい、表紙画像からお分かりのとおり、私が執筆しました。つまり、このエントリは宣伝ということになってしまいますが、それはそれとして。とても深く、とてもわかりやすい本になっていると自負しております。いままでに培った技術をすべて注ぎ込みました。 本書は、AppleのiPhone/iPod touch/iPadといった、iOS搭載デバイスで動作するアプリ開発に非常に役立ちます。 Xcode 4.2から使用できるようになったAutomatic Reference Counting (ARC) iOS 4から使用できるようになったBlocks iOS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
