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はファイアウォール等の中間装置の不
MySQLやSSDとかの話 その後 | GREE Engineering
こんにちわ。せじまです。 すべての基本は monitoring だと考えてるので、イマドキのウェアラブルデバイスいろいろ買っていろいろ計測してるんですが、最近のデジタルガジェット面白いなぁ２１世紀感パないと感心しまくってる今日このごろです。 ちょうど一年くらい前、 MySQL User Conference Tokyo 2015 で MySQLやSSDとかの話 前編を、 GREE Tech Talk #9 で MySQLやSSDとかの話 後編を、お話させていただきました。 その後どうなったの？ということで、後日談をまとめさせていただきました。（今回はMySQL成分それほどありません） 忙しい人のために三行でまとめると 以前の試みはわりとうまくいきました。 SSDの大容量化がさらに進んでますし、前回の経験を活かして、HDD積んだサーバの構成変更しました。 次のステージとしては、１ラックあたり
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
YAPC::Asia Tokyo 2015にいってきました | GREE Engineering
ひさびさの投稿がイベントいってきましたエントリになりました、ふじもと (@masaki_fujimoto) です。 ということで、sponsoredしたらチケットをいただいたのもあって (いやそんな、してなくても多分いってたと思いますが)、21-22日に参加させていただきました。blogを書くまでがYAPCって1日で10回くらい聞いたので、もはやただの個人の感想文ですが、会社のblogのっとってつらつら感想かきます！ よくわかるYAPCのまとめ 全体的なまとめがあちこちにあるので、もうすでに目を通されてるかたも多いかなーと思いますが、いちおリンクしてみます: YAPC::Asia Tokyo 2015 感想エントリまとめ YAPC::Asia Tokyo 2015 スペシャルレポート YAPC::Asia Tokyo 2015 #yapcasia 全セッション総まとめ さいしょにアピール:
Neutron サービスプラグインの作り方 | GREE Engineering
はじめに こんにちは、インフラ本部の大山裕泰です。今回は OpenStack をより柔軟な環境に拡張できる小ネタをご紹介致します。 前回のエントリでも述べましたが Neutron ではコンピュートノードのエージェントを制御したり、独自の拡張機能を本体の機能と連携させたりといった事がプラグイン機構によって実現できます。 今回は、Neutron のプラグイン機構についてと、ルータに対する各種操作に同期する Neutron L3 プラグインの仕組みと実装について見てゆきます。 また、今回紹介する手法を応用するこよによって、以下のようなことが出来るようになると思います。 Floating-IP 割当/削除時における DNS との連携 テナントネットワーク、及び Flaoting-IP の作成/更新/削除に伴う課金システムとの連携 まずは Neutron のプラグイン機構について少し詳しく見てゆきま
OpenStack Networking の仕組み | GREE Engineering
こんにちは、インフラ本部の大山裕泰です。最近はずっと OpenStack の運用をやっています。 昨年の OpenStack Days での発表 にもあるとおり、グリーは一昨年 (2013) の 5 月から商用環境での OpenStack の運用を開始していますが、最近社内システムでも OpenStack の利用を開始しました。 普通は「順番が逆じゃないか!?」と思われるところですが、そこはベンチャーたる所以です (たぶん) 。 はじめに 今でこそ OpenStack の運用に関わってきたことで、僅かながら知識や経験が蓄積してきましたが、初めて OpenStack に触り Neutron について調べ始めた頃、登場した背景や歴史的経緯、API、機能や使い方についていろいろと書かれているページはいくつもありましたが、どれを読んでもイマイチよくわからないということがありました。 恐らく Ope
適当勝手な技術トレンド予測 (2014年末版) | GREE Engineering
tl;dr 去年も言われたので先に書いておきます。今年は(も)そんなに有用なエントリでもなく、脊髄反射で「1年後こんな感じかなー」という予測を、思いつきなテーマでつらつら書いてるだけです。 きっと1年後には、「あー外してるわー」とかとか自分で振り返れるので楽しそうですよねー、というのが主な目的なので、あんまりまじめに受け取らないでくださいなにとぞよろしくおねがいします。 はじめに (駄文且つ長め) ということで Merry Christmas! GREE Advent Calendar 25日目は、グリー株式会社でCTOをしておりますふじもとがお送りします。今年も育児休暇からオンラインゲーム開発、OpenStackまで、多種多様な24のエントリーがある中で、最後のエントリーをどんな内容にしたものか、と悩んでいたらはや12月も23日になってしまいまして、こんな素敵な冬晴れの日 (2014/1
(OpenStack juno) ホストスケジューラの仕組み | GREE Engineering
はじめに こんにちは。『GREE Advent Calendar 2014』の 23 日目の記事を担当しますインフラストラクチャ本部開発部の大山です。昨年の AdventCalendar で OpenFlow コントローラ Trema について書き、少し前には WhiteBox について の記事を書いてみたりとし、最近はずっと OpenStack の構築と運用を行っています。 OpenStack は AWS や Google Cloud, Microsoft Azure といったものに代表されるような IaaS クラウド基盤環境を実現する OSS として知られ、ヤフーや楽天といった大手サービスプロバイダや、GMO インターネットといったクラウドホスティングサービスを提供する会社などで採用されています。また、ニーズの増加や OpenStack の機能面・実績面での強化に伴い、今後ますます利用
Varnishでテストコードを書こう！～実践編～＋Bodyを読もう！ | GREE Engineering
こんにちは、Service Reliabilityチームのいわなちゃんさん(@xcir)です。 先日、社内で行われたチューニングハッカソンではチームマイナス5500万としてVarnishをいれる簡単なお仕事をしてきました。 このエントリは GREE Advent Calendar 2014 17日目の記事です。 以前とある勉強会で 「varnishtestの使い方がよくわからない」 「別のツールを使ってテストをやっている」 という話を聞きました。 varnishはvarnishtestというテストツールがありますが、あまり利用されていないようです。 原因はいくつかあると思いますが、まずは実際のテストコード(VTC)を見てみましょう。 以下は公式のrollback機能のVTCです。 varnishtest "Test Rollback" server s1 { rxreq expect re
初めてのHTTP/2サーバプッシュ | GREE Engineering
前回はWebサイトをHTTP/2に対応するためにリバースプロキシを検証した記事を書かせていただきました(HTTP2を試してみる)。 あれから幾つかの議論を経てHTTP/2の仕様も大分安定してきており、HTTP/2を実装したクライアントや実験的にHTTP/2を有効にしているサービスもあるので実際に試すことも出来ます。 そこで今回は応用編としてHTTP/2のサーバプッシュについて、その仕組と実際に試したことについて書かせていただきます。 余談ですが、 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称になります。 HTTP/2概要 まず、軽くHTTP/2の概要に触れておきます。 HTTP/2は2012年の末頃より、HTTP/1のセマンティクスを維持したままパフォーマンスを改善する目的で議論が開始されました。 Googleの考案したSPDYと言
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
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
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
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と言うプロトコ
CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering
Merry Christmas! GREE Advent Calendar もいよいよ最終日、25日目はグリー株式会社でCTOをしておりますふじもとがお送りします。 今日まで24人のGREE Engineersなみなさまにエントリを書いていただいたわけですが、思ったよりも多種多様な内容で、あらためていろいろな方面で素敵なエンジニアがいるなー、としみじみしてしまいました。いやしかしgitとchefの記事人気ですね、そして、「当然CTOはすごい記事書くんですよね」とプレッシャーをかけて楽しむ仲間たちに囲まれてぼくは幸せです、あーすごい幸せー。そんなプレッシャーの中、今までのエントリとはちょっと方向性を変えて、CTOの話でも書いてみようかと思います。なお、ぼくの趣味は多分問題解決です。 そんなわたくしふじもとは来年で、CTOっていう肩書きでお仕事をはじめて10年とかになるんですが、なかなか先輩と
グリーのインフラに Chef を導入した話 | GREE Engineering
類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
Trema で OpenFlow ネットワークプログラミング | GREE Engineering
こんにちは、インフラストラクチャ本部の大山です。 このエントリはGREE Advent Calendar 2013 22日目の記事です。 はじめに "ネットワークプログラミング" という言葉は、恐らくシステム屋さんにとって TCP/UDP あるいは IP といった L4, L3 の世界のプログラミングを想起させるのではないかと思います。ですが OpenFlow によって、そのレイヤが一気に L1 まで落ちました。つまり Layer-1 （物理層）までがプログラマブルに扱える領域になったということです。 これは主に Ethernet と IP に限定されるものの、従来 L1 から L3 の領域はネットワーク屋さんの領分で L4 以上がシステム屋さん、あるいはアプリケーション屋さんの領分という暗黙の了解を OpenFlow が無くしてしまいました。 今日は OpenFlow ネットワークを制御
GREEにおけるJenkins, その6 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。 今回は、Jenkinsを運用に使うテクニックを紹介します。 JRubyとgemをgitで管理 GREEのシステムではいくつもの管理系のスクリプトがあるのですが最近岡崎が管理している管理系スクリプトはすべてRubyで書いています。実行はRubyのJava実装であるJRubyを使っています。また管理系スクリプトと一緒に、JRubyのランタイムやGEM(Rubyのパッケージ管理システム)レポジトリ一式もgitで管理しています。これの狙いは二つあります。 どのSlaveでも動作する Jenkins SlaveもJavaで動いています。ということは、JRubyを実行するのに必要となるJavaは既にある訳で、Slave側のソフトウエア構成を気にせず実行することが出来ます。OSを選ばないのも大きなメリットです。 バージョンが指定できる すべての
ImageMagick 改造入門 (その壱) GIFアニメーション | GREE Engineering
こんにちは。ミドルウェア開発チームのよやです。 今回は、ImageMagick についてお話します。 http://www.imagemagick.org/ ImageMagick は高機能で大変便利な画像処理ツールです。弊社でも利用させて頂いていますが、稀に実サービスにそのまま適用出来ないケースがあります。 そこで、困った時に ImageMagick 自体を改造する際のポイントと、実際の応用例をご紹介します。 ImageMagick のプログラム構造 ImageMagick のプログラムは主に以下のディレクトリに分かれます。(Magick+ ディレクトリ等幾つかは割愛します) utilities/<コマンド名>.c コマンドラインツールの起点(main 関数) wand/〜.c (コマンド共通処理とコマンド毎の処理、Wand API) magick/〜.c (機能モジュール、ユーティリテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
