受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering
こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し
CTO15年やったので仕事を増やしてみた | GREE Engineering
みなさまこんにちは、グリー株式会社でCTOをしておりますふじもとです。最近は諸般の事情でWebUSBとWebNFCを観察しています、iOS SafariでWebNFCサポートしてくれないかな...。 そして今回は来たる2021/11/11に開催予定のGREE Tech Conference 2021の宣伝にやってまいりました。という！ことで！ GREE Tech Conference 2021 は 2021/11/11 開催です、ご登録はこちらから！ みなさまのご参加をお待ちしております。なおぼくは最初の基調講演で20分ほど (当然グリー株式会社の) お話をさせていただきます。 以上でだいたいこのエントリでお伝えしたいことはお伝えできましたので、以下は蛇足となりますが、グリー株式会社でCTOになって以来初めて社外での仕事をすることにしたので、少しだけそのあたりについて書かせていただこうと思
CTO15年やってみた (その1かも) | GREE Engineering
とても久しぶりのエントリになります、グリー株式会社でCTOをやっておりますふじもとです。Pixel Budsを買ったはいいものの、イヤフォンの位置なおすたびにジェスチャ認識されて通知読み上げられることに悩んでいます。たぶん耳にちゃんとフィットしてないのが原因です。 気がつけば、今年でCTOというタイトルでお仕事をしてはや15年が経ち16年目に突入しておりまして、よい機会なので今どんなことを思うか、何が変わったか、などなど勢いで書いてみようと思った次第です...というそれっぽい理由はほんの少しで、ほんとのところそんな立派な理由でもなく、来たる 2020/09/18 (fri) に GREE Tech Conference 2020 (online) が開催されるので、その宣伝をしたいなーと思ったのです。ということで...！ GREE Tech Conference 2020 2020/09/
遅ればせながら、Folding@home のタンパク質構造解析プロジェクトに参加させていただくことにしました。 | GREE Engineering
HOMEInfo遅ればせながら、Folding@home のタンパク質構造解析プロジェクトに参加させていただくことにしました。 こんにちわ。せじまです。 今日はMySQLの話ではありません。 はじめに こちらのスライドなどでも触れておりますが、弊社では、一部のサービスでオンプレミス環境の物理サーバを使っています。それらは仮想化せずに、消費電力効率などを改善することで、コストの最適化を図っています。 具体的に言うと ピーク時の最大負荷を想定してベンチマークを実行し、そのときの消費電力を測定する。 ラック内にあるすべてのサーバに最大の負荷がかかった状態でも、何台かは修理交換やOSのアップデート作業などが実施可能になるよう、突入電流を想定して電源のマージンを確保する。 といった観点で、ラックごとの構成を設計しています。消費電力の試算をし、弊社のワークロードや（わたしが考える）InnoDBに最適な
Jenkinsfile、書いてますか？ | GREE Engineering
インフラの駒崎です。Jenkins の Pipeline スクリプトについてのお話です。 早速ですが Jenkins の Pipeline スクリプト、使われていますでしょうか。 もしかしたら以前ちょっと書いていたけどやめてしまったとか、従来の GUI 設定のほうが楽だ、となんとなく敬遠してしまっている方もいるのではないでしょうか。 私が実際そうだったのですが、最近になってやっと Jenkinsfile - Pipeline スクリプトが身近に感じられてきましたので、現状の簡単なまとめを書いてみたいと思います。少しでも似た状況の方へのヒントやきっかけになれば幸いです。 Pipeline スクリプトは難しい？ 私は正直、2016年に Jenkins 2 の目玉機能として Pipeline が出た当初は、とっつきにくい…わからん…と思っておりました。Jenkins を上っ面でなんとなく使ってい
innodb_thread_concurrencyに関する話 | GREE Engineering
こんにちわ。せじまです。今回の話は軽く書こうと思っていたのですが、長くなりました。まぁInnoDBの話なのでしょうがないですね。 はじめ 今回はinnodb_thread_concurrencyについてお話しようと思います。できれば、事前にInnoDB の mutex の話（入門編）を読んでいただいた方が、より深く理解していただけるのではないかと思います。 長いので、最初に五行でまとめます 現代において、ほとんどのケースでは、innodb_thread_concurrencyはデフォルトの0のままで問題ないと思います。なぜなら、最近のInnoDBはかなり良くなってきたからです。 それでもinnodb_thread_concurrencyをチューニングするとしたら、「高負荷状態になったときでもスレッド間の公平性をなるべく担保し、安定稼働させるため」と割り切って使うのが良いでしょう。 inno
AWS FargateとDocker Composeで簡単分散RSpec | GREE Engineering
AWS Fargate早く東京に来てくれという願いをこめて、東京で1つでも事例を増やそうと記事を書いていたら公開する前にAWS Fargateが東京に来ることが先日発表されました！めでたいです。アリネ事業部の平田です。 今日はARINEで使っていく(かもしれない) AWS Fargate を使ったRSpecの実行環境の話と、Docker Compose使っているならFargateいいかもしれませんよ、という話をします。 背景 アリネ事業部では、なりたい自分がきっと見つかる美容メディア ARINE を運用しています。 ARINEのサーバサイドはRubyで書かれており、ウェブアプリケーションフレームワークはRuby on Railsを採用し、テストにはRSpecを使っています。 テストは徐々に増えており現在テストが1000件ほどで、テストにかかる時間も徐々に長くなり、完走するのに10分以上かか
さいきんのMySQLのJSONまわり | GREE Engineers' Blog
こんにちわ。せじまです。 さいきん、しばしば庭園や日帰り登山に行って風景写真を撮っているのですが、カメラで写真を撮るという行為は（中略）実行計画を考えながらSQLを書く行為に近しいことだと思いますので、エンジニアの方にはけっこうオススメです。 今日は軽めの話をさっくりさせていただこうかと思います。 はじめに 皆さんは最近のMySQLがJSON型をサポートしているのをご存知でしょうか。「なぜ正規化されていないJSONをRDBMSに格納するのですか！正規化しましょう正規化」という至極ごもっともなご意見もあるでしょうが、 MySQLは5.7からJSON型のサポートをはじめ、8.0でかなり開発が加速している印象を受けます。JSON型がネイティブでサポートされるようになったのは、MySQL5.7のRelease Candidate以降です。5.7 RCがリリースされた2015年あたりから、MySQL
ソーシャルゲーム サーバーアーキテクチャ選定 | GREE Engineering
※Read / Write のレスポンスタイムは大まかに計測した値のため適切な設定ができていない場合もあることをご了承ください MySQL 信頼と実績のあるRDBMS。新規タイトルの場合AWSではAurora、GCPではCloud SQLを利用することで運用の手間をある程度減らすことができる。分散システムではないため1クラスタでの書込性能には限界があり、ソーシャルゲームのように大規模なwrite処理がある用途では水平/垂直分割が必要になり、そのための設計とコーディングが煩雑になりがちである。またインスタンスのスケールアップ・ダウンで対応しきれない場合のクラスタの分割・統合のオペレーションは複雑なものになる。 スケールアップ・ダウンやnodeのメンテナンスなどでMaster nodeを切替える際には不通時間が発生してしまうため、安全のためゲーム自体をメンテナンス状態にする必要が発生する。 ※
TLS1.3だとハンドシェイクがどれくらい早くなるか測定した | GREE Engineers' Blog
こんにちはインフラの後藤です。 今回はTLS1.3を実環境で試してみました。 TLS1.3はTLSのメジャーバージョンアップとも言われるように、様々な改善が含まれています。 例えば、以前「TLS1.3のハンドシェイクがもう来てる」で書いたように、TLS1.3ではハンドシェイク時のパケットの往復回数が減っており、より早くコネクションを確立できます。 すでに、ブラウザや暗号ライブラリはTLS1.3に対応してきておりますので、実環境で具体的にどれくらいコネクションの確立が早くなるのか確認してみました。 TLS1.3 バージョンネゴシエーションとネゴシエーション 測定の前に今回利用したTLS1.3 draftバージョンについて補足します。 TLS1.3は draft-28 版が最新のバージョンです。こちらが文章上の修正を経て将来的にRFCとなります。 TLS1.3はファイアウォール等の中間装置の不
社内AIプログラミングコンテストで優勝したゲームプレイAIの紹介 | GREE Engineering
こんにちは、応用人工知能チームの辻本です。 最近は計算リソース、データ量、アルゴリズムの改善によって簡単に精度の高いAIが利用できるようになりつつあります。しかし、現状では全てのタスクにおいてAIを利用すればいいわけでもありませんし、リソースの制限もあるため、特性を理解して上手に応用することが重要です。そこで、社内ではAI応用のための知見や環境を積み上げていく機会を増やす取り組みを行っています。 先日、取り組みの一環でゲームプレイAIのプログラミングコンテストが開催され、約20チームが参加して盛り上がりました。このコンテストで優勝したゲームプレイAIについて紹介します。 AIによるゲームプレイ動画です。 コンテスト概要 AIにアクションゲームなどのデバッグの一部を任せられるかどうか検証したいという考えもあったので、ゲームプレイAIが対象として選ばれました。ゲームをAI用に変更せずに画面情報
Prometheusによる数百台規模のモニタリングで直面した問題について | GREE Engineering
インフラの反田 (@mtanda) です。 GREEでは、多くのサービスをAWS環境で運用しており、それらサービスのモニタリングシステムとしてPrometheusを利用しています。 Prometheusを導入してから約2年がたち、1台のPrometheusで数百台規模のインスタンスをモニタリングするなかで、さまざまな問題に直面しました。 それら問題の原因を分析し、設定や利用の仕方を改善することで、ある程度安定して運用できるようになりました。 これらの知見が少しでもお役に立てばと思い、ここで共有いたします。 なお、対象とするPrometheusのバージョンは1.xです。Prometheus 2.0では、これら問題のほぼ全てに対して改善されています。そのため、2.0でどういった点が改善されているかを知るためにも有用だと思います。 Prometheusのストレージ実装の基礎知識 Promethe
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などを自分で定義でき共通にできる 既存ツールとの比較 ツールの優劣を示すものではなく、自分たちに必要であった要件についてのみ比較しています。
AWS EC2 での最強の Public IP 取得方法 | GREE Engineering
概要 AWS EC2 インスタンスの Public IP は起動毎に変わってしまい、 ssh や curl コマンドに与えるアドレスを毎回確認するのに困っていませんか？ 特に常時起動しない検証や開発のための環境、 Auto Scaling に依存した環境と相性が悪いと思われます。 よくある手法１、EIP を付与する。 しかし EIP はインスタンス起動してない間に費用がかかり、頻繁に Stop したり新規追加するのに向いていません。 よくある手法２、 Route53 を利用する。 Route53 にインスタンスと対照になる名前を与え、 Lambda 等で定期的に更新すれば IP アドレスを意識せずに済みます。 しかし Public Hosted Zone の費用が掛かってしまいます。 Lambda 更新間隔や TTL でのタイムラグもあります。 よくある手法３、 AWS CLI を ssh
DC内通信のHTTP/2化を検討する | GREE Engineering
こんにちは、インフラストラクチャ部の後藤です。 懲りずにHTTP/2の記事です。 HTTP/2を実サービスに投入するのには様々な障壁があり、議論が足りてない部分だと感じています。 サイトのHTTPS化 TLS ALPN, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 サポート モニタリング・監視 Dependency Based PriorityとRUM コネクションの生存時間が長く、運用上のDNSを用いたサーバ切り替えと相性が悪い(GOAWAY出せるものもあるが) ELBを使用している場合はTCPで利用する必要がある そもそもL7ネットワーク機器が対応していないという場合もあるかとおもいます。 そこで、今回は比較的容易なDC内のHTTP通信をHTTP/2化することを考えます。 DC内HTTP通信のHTTP/2化 DC内でサーバ間のHTTP/2通信であれば、h
ネットワークの可視化 | GREE Engineering
GREE Advent Calendar 2015 の23日目担当の上竹です。普段はアプライアンスLB やネットワークの構築/運用をしております。 概要 バックボーンネットワークを設計運用していると、実際どのようなトラフィックがどのくらい流れているか中身を知りたい(見たい)ことがよくあります。 どのISP からどの回線へどのくらい流入があるのかだったり、どんなAS からどのくらいアクセスがきているか、これら様々な情報を正しく把握することは、Transit 回線やIX 回線をコントロールし今後のネットワーク戦略を考えるうえで非常に有益です。 また、昨今我々を悩ましているDDoS 対策の第一歩として、今流れているトラフィックをまず"知る"ということが必要だと思います。 そこで、今回ネットワークの見える化を、「NetFlow」、「Fluentd + ElasticSearch + Kibana」
泥臭いサーバ運用自動化の話 | GREE Engineering
こんにちは、North America事業本部のLiang Fanです。このエントリーは GREE Advent Calendar 2015 10日目の記事です。 本日は、以前所属していたインフラストラクチャ部のサーバ運用と自動化の話を少しご紹介したいと思います。 よろしくお願い致します。 はじめに 運用自動化と聞いて、みなさんは頭の中に何を浮かべますか？仮想化技術(docker、VM)、構成管理ツール(chef、puppet)やクラウドサービス(AWS、Google Cloud Platform）などの答えがたくさん出てくるかもしれません。本日はそれらの技術を使って、かっこいい運用自動化ができたという話ではなく、レガシー環境のサーバ運用を少しでも楽にするための泥臭い自動化の話を紹介したいと思います。 グリーのレガシー環境 レガシー環境と言っても、もう歩けない80歳のおじいさんではなく、
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) 無しでも
DynamoDBを使ったKPI保存システム | GREE Engineering
こんにちは！データエンジニアリングチームの長谷川と田畠です。 グリーのデータ分析基盤を良くする仕事をしています。 これはGREE Advent Calendar 2015の6日目の記事です。昨日のRobinさんの記事はVR開発に取り組んだことがあるからこそ書ける記事で、みなさんにとっても新鮮だったのではないでしょうか？ 今日はゲームから少し離れて、KPIダッシュボードのバックエンドをオンプレミスからAWSに移行した話をしたいと思います。最後までお付き合いよろしくお願いします。 はじめに KPI分析を定常的に行うことは、プロダクトの改善のために非常に重要であり、グリーにおいても多くのプロダクトがKPIを閲覧/分析するためのシステムを利用しています。 社内の分析環境では、KPIのデータは時系列データベースに保存されており、内製のグラフ描画ツールにアクセスすることでグラフとして閲覧することができ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
攻めるための自動化、汎用化のすゝめ | GREE Engineering