Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。 さて本題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。本記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。 hackerslab.aktsk.jp ずばりEMを無くして良かったのか これはマクロに見ると明確に良かったと思って
ボトルネックマネージャーを抜け出す方法 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2020 の12日目の記事です。 アカツキは10周年を迎え、それと同時に経営体制が一新され、経営チームExecutive Leadership Team(ELT)が結成されました。 経営戦略の基本方針も変更となり、社内の構造的にも社内の方針としても、アカツキにとって大きな変化のある1年となりました。 私もELTのメンバーとして現在主力であるゲーム事業の職能組織を束ねる立場(Chief of Staff, Games / CoSG)となり、影響の範囲も、責任の範囲も大きく拡大しました。 これまでは、私はVP of Engineering(VPoE)としてエンジニア組織を束ねる立場にあり、一つの職能のことだけを考えておけば良かったです。 しかし今では、エンジニアだけでなく、デザイ
CTOとエンジニアリングマネージャーでDelegation Boardを作ってみた - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは、ゆのん(id:yunon_phys)です。先日、第二回エンジニアリングマネージャー勉強会にて、タイトルの内容についてLTをしてきました。結構多くの方に興味を持っていただいた内容で、折角なので文章にしてみました。 Management 3.0 Management 3.0によると、内発的モチベーション(同僚による感謝や、自分の能力がしっかり活かせている感)こそが生産性を上げるものだと主張しています。逆に、外発的モチベーションでは生産性が落ちると言われていて、いわゆる、ボーナスや評価などはマイナスにはたらくと言われています。 アカツキでは、誕生日メッセージやサンクスカード、1on1における対話、朝のGood&Newなど、既に内発的モチベーションを高める施策を実施していますが、もっと幸せに働ける職場に出来ないか、というのを常にメンバー自らが探し求めています。そういうわけで、Manag
RailsでTZ環境変数を設定するハックを不要にした話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
TL;DR 『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』 でRailsを高速化させる素晴らしいハックが紹介されましたが。いまや有効なハックではなくなりました。 TZハックさん、ながい間（2日間）おつかれさまでした。 はじめに アカツキさまで技術顧問をさせていただいている小崎です。 このエントリは『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』をRubyコミッタが読んだらこうなったというアンサーソングになっています。合わせてお読みください TZ環境変数でTime.newが10倍近く速くなるのは素晴らしい発見ですが、コミッタとしてはTZなしでも速くなって欲しいなと思いました。だってめんどうだし。 現状分析 まず問題のテストプログラムを軽く分析してみましょう % strace -c ruby .
GAE/Go & CircleCI でカナリアリリースをする - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
この記事はAkatsuki Advent Calendar 2018の12日目の記事です。 前回は hayamaruさんの、知覚メカニズムと網膜投影でした。 はじめに 継続的デリバリーという文脈で、素早く、安全にデプロイする手法について、近年多くの記事を見かけます。 例えば、カナリアのおかげで命拾い : CRE が現場で学んだこと でカナリアリリースについて詳しく触れられています。このアイデアは「たとえテスト環境で十分な検証をしたとしても、本番環境で問題が発生しないということを保証するのは難しいので、少しづつトラフィックを移動して問題があったらすぐにロールバックをしよう」というものです。 上記記事中に紹介されているKayentaといったツールを使ってカナリア分析を行い、自動的にカナリアリリースするというのも良いですが、人間による承認を元にデプロイするならもう少しコストの低い方法で良さそうで
ElixirのサーバアプリケーションをDatadog APMでトレースする - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
この記事は Akatsuki Advent Calendar 2018 の23日目の記事です。 前回は id:yunon_phys さんの、エンジニア組織の責任範囲の透明性をRACI図で高めてみた でした。 はじめに アカツキではElixirを使ってゲームのAPIサーバを開発・運用しています。 ゲームのAPIサーバは、大量のリクエストを低いレイテンシで捌くことが要求されるため、Erlang VMの高いスケーラビリティが利用できるのは効果的です。加えてRubyなどを書き慣れている人にとっつきやすいElixirの文法も魅力です。 とはいえ、その性能を引き出すためには、やはりアプリケーションのパフォーマンスチューニングは不可欠です。 その際、"Don't guess, measure" という言葉の通り、どこを改善すれば良いかを知るための良い計測ツールが必要になります。 これまでRuby on
急いで覚えるElixir: Enumerable編 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
ElixirのEnumerable 前回の記事から続いて、今回はElixirで利用する基本的な制御構文について学んでいきます。 Keyword list 多くの関数型プログラム言語では、2要素のtupleによって関連付けられたデータ構造を表現します。 Elixirでは、最初の要素がAtomであるTupleのListのことをKeyword listと呼びます。 iex> list = [{:a, 1}, {:b, 2}] [a: 1, b: 2] iex> list == [a: 1, b: 2] true iex> list[:a] 1 キーが重複している場合、先頭に格納された値が優先的に読まれます。 iex> new_list = [a: 0] ++ list [a: 0, a: 1, b: 2] iex> new_list[:a] 0 Keyword listは以下の重要な性質を持ちま
React Conf 2017 現地レポート (1日目) - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
ライブエクスペリエンス事業部 エンジニアの高松(@shimpeiws)です。 2017/3/13 ~ 14の期間で開催中のReact Conf 2017に参加するためにサンノゼに来ています。 React Conf 2017 つい数時間前に終わったばかりの1日目のレポートを現地からお送りします! 会場の様子 1日目の感想 Keynote (Tom Occhino, Jing Chen, Sebastian Markbage) 概要 Tom Occhino Jing Chen Sebastian Markbage A Cartoon Intro to Fiber (Lin Clark) 概要 メモ Next.js: Universal React Made Easy and Simple (Guillermo Rauch) 概要 メモ React + ES.next = ♥ (Ben Ileg
5分で分かるRedis Clusterの構築方法 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
はじめに Developpers Summit 2016で「大規模Redisサーバ縮小化の戦い」というテーマで発表してきました。 大規模Redisサーバ縮小化の戦い from Yuto Komai Redisのdumpファイルを取得して、それらをマージする方法や、Redis内で使用するdb数を増やせば、接続数も増えていく、といった話をしました。 特にAWS上でRedisを運用する場合、ElastiCacheの接続数上限は変更できないことは見落としがちなポイントなので、サーバを何十台もスケールアウトする人たちにとって役に立つノウハウが共有できたのではないでしょうか。 当日はネタスライドを山程仕込んで 会場は大爆笑だったのですが、slideshareではネタスライドは割愛しております。 今回のお話 デブサミのスライドでは、ほとんどの話が縮小についての話だったので、今回はRedisの信頼性につい
Rails4.2のコネクションプールの実装を理解する - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
tl;dr Railsではコネクションプール数を設定していても、1スレッド辺り1コネクションしか持ちません。 発端 アカツキではRails + Unicorn + Nginx + MySQLの構成をAWSで運用しており、c3.4xlargeのインスタンス上で1台辺り64のUnicornワーカープロセスが実行される設定になっています。 ソーシャルゲームでは時にたくさんのアプリケーションサーバを並列稼働される必要がでてきます。特に年末年始の時期は平時の2-3倍のトラフィックが予想され、アプリケーションサーバを最大100台で稼働させる必要がありました。 Railsのdatabase.ymlのpool設定は5だったので、単純に考えると最大 100台 * 64プロセス * 5接続 = 32,000個の接続が常時貼られるのでは？MySQLのmax_connectionsの設定は大丈夫か？という議論があ
新規事業で Elixir, Phoenix, React を使う - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
エンジニアリング・アドバイザーの noto です。先月末から新規事業チームのエンジニアリングについてもお手伝いすることになりました。 アカツキでは今年 (2015 年) の夏より、従来のゲーム事業の枠を超えて、教育、ヘルスケア、「働く」などの領域を対象とした新規事業の検討・開発を開始しています。(新規事業に関するプレスリリース / 新規事業公式ページ) こういった領域では「作っては壊し、作っては壊し」のトライアル・アンド・エラーが繰り返されると想定されるため、技術の選択に失敗した場合でもリカバリできる可能性も高くなります。そのため、従来のゲーム事業に比べると新しい技術を取り入れるチャレンジがしやすいと考え、社内で使い慣れた サーバサイド: Ruby on Rails ゲームクライアント: C++, Cocos2d-x とは別の技術を導入し始めています。 サーバサイド サーバサイドについては
急いで学ぶElixir#01 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
Motivation クラスメソッドさんがDevelopers.IOにとても良い記事を投稿されていたので、Elixir版も書きたくなりました。 Elixirを始める 最近のソーシャルゲームでは、ユーザー同士によるリアルタイムマルチプレイがトレンドになってきました。 アカツキが最近リリースしたメザマシフェスティバルも、Node.jsによってマルチプレイが実装されています。 個人的にリアルタイムゲームサーバーの他の実装例が気になったので、調べてみることにしました Call of Dutyの実装言語であるErlangですが、このErlangのVM上で動作するElixirという言語があります。 筆者はErlangも関数型言語も知見が全く無いですが、学んだことをまとめていきたいと思います。 動作環境 今回使用した動作環境は以下のとおりです。 OS: MaxOS X 10.9.5 Elixir 1.0
急いで学ぶElixir#02 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
Elixirの基本型 以下の基本型があります。 - integer : 1, 0x1F - float : 1.0 - boolean : true, false - atom (symbol) : :atom - string : "Elixir" - list : [1, 2, 3] - tuple : {1, 2, 3} 演算 iex> 1 + 2 3 iex> 5 * 5 25 iex> 10 / 2 5.0 Elixirでは/は必ずfloatを返します。 整数の商や余剰を得るには、divまたはremを使用します。 iex> div(10, 2) 5 iex> div 10, 2 5 iex> rem 10, 3 1 このように、Elixirでは関数を呼び出すのに括弧を省略できます。 ２進数や８進数、１６進数は以下のように使用でいます。 iex> 0b1010 10 iex> 0o
AWS ElasticCacheのRedisをDefault設定で使ったときのConnection Leakの解決方法 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
現在、弊社にて提供しているサービスのほぼ全てにおいてAWS(Amazon Web Service)を利用しており、その中でも頻繁にアクセスが必要なデータについてはElasticCacheのRedis/Memcachedを利用しています。今回は、そのElasticCacheでRedisを利用する場合において、弊社の運用で発生してしまったトラブルと対応方法について紹介させていただきたいと思います。 TL;DR AWS ElasticCacheのRedis ServerのDefaultのパラメータ設定では、Connection Timeoutの設定がされていないので、そのまま放置するとConnection数が溜まり続けて危険ですので、ConnectionのTimeout設定を行いましょうというお話になります。 今回発生した問題 Blue-Green Deploymentを多用して何度もデプロイを
9分43秒のデプロイを19秒にした話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
背景 アカツキではRailsでゲームサーバを開発しています。インフラはAWSにあり、CloudFormation, Chef, Capistrano を用いて、Infrastructure as Code を実現しています。 エンジニアは普段ローカルマシンで開発していますが、ディレクター、レベルデザイナーなどは定義ファイルを変えた後、それを反映して動作を確認するための検証サーバ（以下、検証環境）を使っています。 検証環境へのデプロイも Capistrano で自動化しており、最初は問題が無かったのですが、ゲーム上のデータが増えることによって、一度のデプロイで10分程度かかるようになっていました。 以下、Capistrano ver.2系の話にはなりますが、検証環境のデプロイを高速化したので、その内容を紹介したいと思います。 現状分析 rsync について、capistrano_rsync_
そのガチャの確率、本当に合ってます？〜RSpecで統計的に確認する話〜 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
背景 ソーシャルゲームでよく見かける「ガチャ」ですが、この記事ではその重み付き確率の保証方法を紹介します。 ガチャは売上・ユーザー体験・ゲームバランスに直結するので、意図通りの動作をするか慎重に確認する必要があります。 またアカツキではTDD (Test Driven Development)を採用しているので、 実装したプログラムが想定している確率に従っているかを確認するためのスペックが必要となります。 理論 使用する数理モデルは「離散確率密度変数」です。 例えばガチャで入手できるキャラクターのIDが であり、 その入手確率が (実装の便宜上自然数としますが、非負の実数としても一般性を失いません)によって重み付けされているとします。 このとき、ID のキャラクタが入手できる確率は、 となります。 さて、10000回の試行（ガチャを引くこと）をしたとき、入手できる確率が50%のキャラクタを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
