こんにちわ。せじまです。さいきん、ジム用に左右独立型スポーツモデルのBluetoothイヤホン買ったのですが、あまりの快適さに、ジムに通うモチベーションが５割増しになりました。 はじめに innodb_thread_concurrency について書こうかと思ったんですが、まずはその前に MySQL の metric の話から入ったほうが良いかなぁと思ったので、今回は metric の話を書こうと思います。はじめにお断りしておきますが長くなります。 弊社では７年以上前から、 MySQLのサーバ一台あたり（OS側のも含めると）200-300 以上の metric を だいたい15秒間隔で記録しています。最近はSSDなども使ってますが、むかしはHDDにmetricを保存していました。例えばMySQLのサーバ一台分のmetric表示した画面をキャプチャすると、次のような感じになります。 ※画像は

こんにちはインフラの後藤です。 今回はTLS1.3を実環境で試してみました。 TLS1.3はTLSのメジャーバージョンアップとも言われるように、様々な改善が含まれています。 例えば、以前「TLS1.3のハンドシェイクがもう来てる」で書いたように、TLS1.3ではハンドシェイク時のパケットの往復回数が減っており、より早くコネクションを確立できます。 すでに、ブラウザや暗号ライブラリはTLS1.3に対応してきておりますので、実環境で具体的にどれくらいコネクションの確立が早くなるのか確認してみました。 TLS1.3 バージョンネゴシエーションとネゴシエーション 測定の前に今回利用したTLS1.3 draftバージョンについて補足します。 TLS1.3は draft-28 版が最新のバージョンです。こちらが文章上の修正を経て将来的にRFCとなります。 TLS1.3はファイアウォール等の中間装置の不

こんにちわ。せじまです。 すべての基本は monitoring だと考えてるので、イマドキのウェアラブルデバイスいろいろ買っていろいろ計測してるんですが、最近のデジタルガジェット面白いなぁ２１世紀感パないと感心しまくってる今日このごろです。 ちょうど一年くらい前、 MySQL User Conference Tokyo 2015 で MySQLやSSDとかの話　前編を、 GREE Tech Talk #9 で MySQLやSSDとかの話　後編を、お話させていただきました。 その後どうなったの？ということで、後日談をまとめさせていただきました。（今回はMySQL成分それほどありません） 忙しい人のために三行でまとめると 以前の試みはわりとうまくいきました。 SSDの大容量化がさらに進んでますし、前回の経験を活かして、HDD積んだサーバの構成変更しました。 次のステージとしては、１ラックあたり

概要 AWS ECS でマルチプレイゲーム用インスタンスの管理すると限りなく最強。 はじめに リアルタイム・マルチプレイゲームを作る時、まず考えられることは、あるプレイヤーの行動や状態が他のプレイヤーに伝わることではないかと思われます。しかし、スマートフォンアプリは不安定であったり、複数端末同士で(基地局やバックボーンを介さずに)物理的に直接接続することは出来ませんし、理論的にできたとしても、だいたい開発が進んでいくうちに排他制御の問題などで炎上、もしくはとん挫してしまいます。軽い気持ちでマルチスレッド処理をおこない事故る現象と全くおなじです。 もっとも簡単な解決方法としてはマルチスレッド処理のときようにクリティカルセクションを設けることです。ようはサーバを用意してそこで処理すれば、比較的容易に一意な結果が得られますし、接続に関する問題も起こりにくくなります。 長くなるので → http:

SAO The Beginningのαテストに落選したふじもと (@masaki_fujimoto) です。当選されたかたは、無事ログアウトできるといいですね (負け惜しみ感)。 相変わらず長い前置き それはそれとして、最近ディスプレイが余った (別のフロアに1台おきっぱにしてたのを回収してきた) ので、久々にデュアルディスプレイにしてみました。で、画面がひろびろとするのはいいのですが、なんか思ったより快適じゃない感じがしまして、なんでかなぁと思ったら、隣のディスプレイを見たときにアクティブなウィンドウをスイッチするのがかったるいんですよね。一応図にしてみるとこういう感じで: それぞれ27inchで結構大きいので、基本は左側のディスプレイを正面にみておしごとしてます。で、右側にはchatを表示させてて、通知きたらそっちみて、って感じでまぁありがちな感じですね。 で、それはいいんですが、問題

こんにちは、インフラストラクチャ部の後藤です。 懲りずに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 Advent Calendar 2015 の23日目担当の上竹です。普段はアプライアンスLB やネットワークの構築/運用をしております。 概要 バックボーンネットワークを設計運用していると、実際どのようなトラフィックがどのくらい流れているか中身を知りたい(見たい)ことがよくあります。 どのISP からどの回線へどのくらい流入があるのかだったり、どんなAS からどのくらいアクセスがきているか、これら様々な情報を正しく把握することは、Transit 回線やIX 回線をコントロールし今後のネットワーク戦略を考えるうえで非常に有益です。 また、昨今我々を悩ましているDDoS 対策の第一歩として、今流れているトラフィックをまず"知る"ということが必要だと思います。 そこで、今回ネットワークの見える化を、「NetFlow」、「Fluentd + ElasticSearch + Kibana」

こんにちは、North America事業本部のLiang Fanです。このエントリーは GREE Advent Calendar 2015  10日目の記事です。 本日は、以前所属していたインフラストラクチャ部のサーバ運用と自動化の話を少しご紹介したいと思います。 よろしくお願い致します。 はじめに 運用自動化と聞いて、みなさんは頭の中に何を浮かべますか？仮想化技術(docker、VM)、構成管理ツール(chef、puppet)やクラウドサービス(AWS、Google Cloud Platform）などの答えがたくさん出てくるかもしれません。本日はそれらの技術を使って、かっこいい運用自動化ができたという話ではなく、レガシー環境のサーバ運用を少しでも楽にするための泥臭い自動化の話を紹介したいと思います。 グリーのレガシー環境 レガシー環境と言っても、もう歩けない80歳のおじいさんではなく、

GREE Advent Calendar 2015の1日目担当のふじもとです、グリー株式会社でCTOをしてます、もう10年目です。 今年もChristmasに向けてみんなで毎日更新していきますので、ぜひぜひよろしくおねがいします。 わりとどうでもよい序 去年、一昨年は25日担当だったんですが、今年は (なんでかは知らないけど) 1日目書くことになったので、ちょっと趣向を変えて技術的な内容にしてみたいと思います。 なおタイトルに、Deep Learningだの自然言語処理 (以下NLP) だの書いてますが、ぼくは機械学習やNLP、はたまたDeep Learningの専門家でもなくって、たしなむ程度に勉強していたくらいです。ので、この記事はアルゴリズムについて詳しくなろうっていうよりは、いろいろ試してみたっていう方向になってます。 Summary わりと単純なCNN + 少ないコーパスでも、タ

こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、（標準化されてないけれど） Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取

昨今何かと話題に挙がってきた AWS Lambda と AWS DynamoDB を活用して格安で堅牢、高性能なゲームサーバを作ります。 既存システムの苦労をもとに、サーバの開発や運用を頑張らずにすむための仕組みとネイティブアプリからの AWS Lambda の利用方法を簡単に紹介します。 サーバが良くわからんという、ネイティブゲーム、ネイティブアプリエンジニアにオススメです。 ※当内容は多分に個人主観を含んでおり、時事的な要素も含まれています。 ※検索して十分な資料があると考えられるツールやライブラリの利用方法等は省略しています。 おさらい まずは既存のゲームサーバの構成を初歩からおさらいしてみましょう。 簡単にサービスする方法としてアプリからのリクエストを受ける HTTP のサーバと利用者の情報を格納しておくデータベースが考えられます。しかし、すぐに思いつくだけでもいくつかの問題があり

こんにちわ。せじまです。スティック型PCの購入は、 Core M版が出るまで見送ろうと思っている今日このごろです。 弊社では「Mini Tech Talk」という社内勉強会を隔週で開催しているのですが、それとは別に、「Infra Tech Talk」という社内勉強会を、半年くらい前から毎月開催しています。わたしはそこでほぼ毎月、45-60分くらいのスライドを作って話をしています。今までどういう話をしてきたかといいますと、TCPに関する話を二回、SSDに関する話を二回しました。（InnoDBに関する話だと軽く5-6時間くらいできるんですが、いささかマニアックなので、もっと幅広い人を対象に話をしています） 今までの話はちょっと社内向けの内容だったんですが、前回開催された Infra Tech Talk では、社外の方にも幅広く読んでいただける話ができたと思いましたので、その資料を slides

ひさびさの投稿がイベントいってきましたエントリになりました、ふじもと (@masaki_fujimoto) です。 ということで、sponsoredしたらチケットをいただいたのもあって (いやそんな、してなくても多分いってたと思いますが)、21-22日に参加させていただきました。blogを書くまでがYAPCって1日で10回くらい聞いたので、もはやただの個人の感想文ですが、会社のblogのっとってつらつら感想かきます！ よくわかるYAPCのまとめ 全体的なまとめがあちこちにあるので、もうすでに目を通されてるかたも多いかなーと思いますが、いちおリンクしてみます: YAPC::Asia Tokyo 2015 感想エントリまとめ YAPC::Asia Tokyo 2015 スペシャルレポート YAPC::Asia Tokyo 2015 #yapcasia 全セッション総まとめ さいしょにアピール:

こんにちは、開発統括本部インフラストラクチャ本部の @foostan です。 今回は私が所属している社内コミュニティ(Container/Docker)で勉強会を主催した話をご紹介します。 グリーで行われている勉強会について グリーではエンジニア向けの勉強会を社内外あわせて定期的に開催しており、主なラインナップは以下のようになります。 [一般公開] GREE Tech Talk (http://techtalk.labs.gree.jp/) [社内限定] Mini Tech Talk (http://labs.gree.jp/blog/category/mini-tech-talk/) [社内限定] Tech Talk [社内限定] 各コミュニティの勉強会 * 10ぐらい 社内限定で行っている勉強会が数多く存在し、特に各コミュニティで行われている小規模な勉強会が多数あります。 なおコミュニ

こんにちは、インフラストラクチャ本部の後藤です。 先日、HTTP/2がRFC7540としてRFC化されました。RFCの中でも触れられている通り、日本の方も沢山関与されています。本当に皆様お疲れ様でした。 仕様としては一段落したHTTP/2ですが、実際に使っていく段階へと移ってく上で気になるのがどれ位のクライアントがHTTP/2に対応しているかということです。Google ChromeやFirefoxの最新版では既にHTTP/2対応していますが、全てのユーザがそれを使っているわけではありません。 そこで、今回は実際に弊社のサービスでHTTP/2対応クライアントの接続がどれ程あるのか調べてみました。(HTTP/2をサービスとしてサポートしているわけではありません。) ユーザエージェントから調べる方法もあるのですが、今回はALPNを元に調べました。 ALPNについて HTTP/2で通信する際のネ

開発PRチームの三木です。 グリーで毎週金曜日に開催している社内勉強会「Mini Tech Talk」、3月のラインナップをお届けします。 グリーの社内で、どのようなトピックでエンジニア間の技術的な交流が行われているか、雰囲気を感じて頂ければ幸いです。 (これまでのラインナップはこちらよりご覧下さい) 3月のラインナップ 毎月上旬にその月のラインナップを公開させていただきます 基本的にグリー社員が発表する勉強会ですが、他社からゲストスピーカーをお招きしてお話し頂く事もあります。 発表終了後に資料を公開いたします。ただし【社内限定】となっている発表については資料の公開はございませんのでご了承ください。 「Practical WebGL」劉 光耀昨年９月のiOS8リリースでSafariがWebGLに対応したことから、PC/スマホの主要ブラウザ全てで WebGLが動作するようになりました。 これ

こんにちわ。せじまです。 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 されるようになりました。 詳細な内容についてご興味のある方は続きをど

はじめに こんにちは、インフラ本部の大山裕泰です。今回は OpenStack をより柔軟な環境に拡張できる小ネタをご紹介致します。 前回のエントリでも述べましたが Neutron ではコンピュートノードのエージェントを制御したり、独自の拡張機能を本体の機能と連携させたりといった事がプラグイン機構によって実現できます。 今回は、Neutron のプラグイン機構についてと、ルータに対する各種操作に同期する Neutron L3 プラグインの仕組みと実装について見てゆきます。 また、今回紹介する手法を応用するこよによって、以下のようなことが出来るようになると思います。 Floating-IP 割当/削除時における DNS との連携 テナントネットワーク、及び Flaoting-IP の作成/更新/削除に伴う課金システムとの連携 まずは Neutron のプラグイン機構について少し詳しく見てゆきま

こんにちは、インフラ本部の大山裕泰です。最近はずっと OpenStack の運用をやっています。 昨年の OpenStack Days での発表 にもあるとおり、グリーは一昨年 (2013) の 5 月から商用環境での OpenStack の運用を開始していますが、最近社内システムでも OpenStack の利用を開始しました。 普通は「順番が逆じゃないか!?」と思われるところですが、そこはベンチャーたる所以です (たぶん) 。 はじめに 今でこそ OpenStack の運用に関わってきたことで、僅かながら知識や経験が蓄積してきましたが、初めて OpenStack に触り Neutron について調べ始めた頃、登場した背景や歴史的経緯、API、機能や使い方についていろいろと書かれているページはいくつもありましたが、どれを読んでもイマイチよくわからないということがありました。 恐らく Ope

こんにちは、Art部の和智(@watilde)です。 最近やっと正月ボケが抜けてきました。 2015年1月24日(土) ~ 2015 年1月25日に、 Patch-a-thonと題してOSSにPatchを書いて送ってみる社内イベントを 軽い気持ちで開催してみました。 イベントの模様をお伝えします。 Patch-a-thonとは Hack-a-thonを参考にCreating a Patch Marathonをモジった言葉で、 自分の好きなOSSに(日頃の感謝を込めて)Patchを書いて送ってみるイベントです。 OSSにPull Requestを作るのは怖いですが(英語とか不安ですよね) 参加者内でレビューし合ったりして改善し、自信が付いたらPatchを送ってみる！ という、OSSの内部に貢献するためのハードルを下げることが目的となっています。 大事にしたこと "無理をしない" ということに