こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2019 10日目の記事です。 エンジニア組織の成長のために大切にしている2つの事柄 アカツキのエンジニア組織は2~3年かけて成長していく状態を目指しています。 そしてその成長のためには、情熱と技術の積み上げが大事である、と考えています。 1. 情熱という感情を大切に扱う アカツキでは、情熱を持って仕事をしている状態を称賛します。 というのも、その人の想いが込められたプロダクトは明らかに完成物のクオリティが高くなりますし、よりクオリティを上げるためのいかなる努力も惜しまなくなり、結果として人も組織も成長すると考えているからです。 情熱というのは大きな野望である必要はありません。 その人が心からやりたいと思っているものであれば、その情熱の炎に大きさは関係ありません。 個人として

TL;DR 『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』  でRailsを高速化させる素晴らしいハックが紹介されましたが。いまや有効なハックではなくなりました。 TZハックさん、ながい間（2日間）おつかれさまでした。 はじめに アカツキさまで技術顧問をさせていただいている小崎です。 このエントリは『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』をRubyコミッタが読んだらこうなったというアンサーソングになっています。合わせてお読みください TZ環境変数でTime.newが10倍近く速くなるのは素晴らしい発見ですが、コミッタとしてはTZなしでも速くなって欲しいなと思いました。だってめんどうだし。 現状分析 まず問題のテストプログラムを軽く分析してみましょう % strace -c ruby .

こんにちは、ゆのん(id:yunon_phys)です。先日、第二回エンジニアリングマネージャー勉強会にて、タイトルの内容についてLTをしてきました。結構多くの方に興味を持っていただいた内容で、折角なので文章にしてみました。 Management 3.0 Management 3.0によると、内発的モチベーション(同僚による感謝や、自分の能力がしっかり活かせている感)こそが生産性を上げるものだと主張しています。逆に、外発的モチベーションでは生産性が落ちると言われていて、いわゆる、ボーナスや評価などはマイナスにはたらくと言われています。 アカツキでは、誕生日メッセージやサンクスカード、1on1における対話、朝のGood&Newなど、既に内発的モチベーションを高める施策を実施していますが、もっと幸せに働ける職場に出来ないか、というのを常にメンバー自らが探し求めています。そういうわけで、Manag

はじめに Developpers Summit 2016で「大規模Redisサーバ縮小化の戦い」というテーマで発表してきました。 大規模Redisサーバ縮小化の戦い from Yuto Komai Redisのdumpファイルを取得して、それらをマージする方法や、Redis内で使用するdb数を増やせば、接続数も増えていく、といった話をしました。 特にAWS上でRedisを運用する場合、ElastiCacheの接続数上限は変更できないことは見落としがちなポイントなので、サーバを何十台もスケールアウトする人たちにとって役に立つノウハウが共有できたのではないでしょうか。 当日はネタスライドを山程仕込んで 会場は大爆笑だったのですが、slideshareではネタスライドは割愛しております。 今回のお話 デブサミのスライドでは、ほとんどの話が縮小についての話だったので、今回はRedisの信頼性につい

背景 前回の記事で、resize2fsコマンドがどのように1秒未満での容量拡張を実現しているかを知るために、resize2fsコマンドのソースを調査しました。その結果、メタデータの一つであるGlobal Descriptor Tables(GDT)をカーネル内で更新しているからではないか、という示唆を得られました。今回は、実際にカーネルのコードを読んで、この示唆が正しかったことを見ていきたいと思います。 調査対象 今回も新しめのカーネルで調査しました。Amazon Linuxとは多少ソースが異なっているかもしれませんが、本質は大きく変わらないかと思います。 ファイルシステム: ext4 Linux kernel version: 4.1.0-rc7 前回の復習 前回調べたときから約1年空いてしまいましたので、軽く前回の復習をします。 ext4のファイルシステムでは、ブロックグループという単

この記事はLinux Advent Calendar 2014 の23日目の記事です。 背景 アカツキではAWS EC2をテストサーバ、ステージングサーバ、本番サーバとして利用しています。先日１周年を迎えた千メモは、リリース時よりも大分デプロイ時に容量を使うようになってきました。ステージングサーバのストレージ容量が当初想定していたものより大分カツカツになってきたため、Amazon社の出しているマニュアルに従って、ストレージ容量を拡張しました。ストレージ容量の拡張そのものは無事うまくいったのですが、どうしてこんな1秒もかからずに拡張出来るのだろうか(resize2fsコマンドが終わるのだろうか)、という疑問がわいてきました。そこで、Linuxでどのようにファイルシステムのサイズを拡張しているか調査するためのとっかかりとして、resize2fsコマンドを調査しました。 調査対象 調査対象は以下

背景 アカツキではRailsでゲームサーバを開発しています。インフラはAWSにあり、CloudFormation, Chef, Capistrano を用いて、Infrastructure as Code を実現しています。 エンジニアは普段ローカルマシンで開発していますが、ディレクター、レベルデザイナーなどは定義ファイルを変えた後、それを反映して動作を確認するための検証サーバ（以下、検証環境）を使っています。 検証環境へのデプロイも Capistrano で自動化しており、最初は問題が無かったのですが、ゲーム上のデータが増えることによって、一度のデプロイで10分程度かかるようになっていました。 以下、Capistrano ver.2系の話にはなりますが、検証環境のデプロイを高速化したので、その内容を紹介したいと思います。 現状分析 rsync について、capistrano_rsync_

背景 ソーシャルゲームでよく見かける「ガチャ」ですが、この記事ではその重み付き確率の保証方法を紹介します。 ガチャは売上・ユーザー体験・ゲームバランスに直結するので、意図通りの動作をするか慎重に確認する必要があります。 またアカツキではTDD (Test Driven Development)を採用しているので、 実装したプログラムが想定している確率に従っているかを確認するためのスペックが必要となります。 理論 使用する数理モデルは「離散確率密度変数」です。 例えばガチャで入手できるキャラクターのIDが であり、 その入手確率が (実装の便宜上自然数としますが、非負の実数としても一般性を失いません)によって重み付けされているとします。 このとき、ID のキャラクタが入手できる確率は、 となります。 さて、10000回の試行（ガチャを引くこと）をしたとき、入手できる確率が50%のキャラクタを