サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
hackerslab.aktsk.jp
エンジニアリングオフィス(以下EO)の島村です。 先日、アカツキゲームスに所属しているエンジニアを対象にディナー(交流会)を開催したのでレポートをさせていただきます。 開催のきっかけ もともと、エンジニア組織としては隔週火曜日17~18時に「エンジニア定例MTG」という完全オンラインの全体ミーティングを開催しています。 そこではエンジニア全体への連絡( イベントの告知など)はもちろんですが、外部カンファレンス参加のレポートや、有志により技術共有発表があったりと、エンジニア主導で様々な情報が交換されています。 そこにEOのメンバーより、最近は出社して作業している人も増えてきており、せっかくの集まる機会だからエンジニア定例のあとの時間に横の繋がりを作るエンジニアディナーを開催しようという提案があり、実施することになりました。*1 きっかけとなったやりとりは以下です。 画像中にある記事へのリンク
Amazon AuroraのS3エクスポート機能 AuroraのS3エクスポート機能は、DBクラスターの現在のデータやスナップショットのデータをS3にApache Parquet形式で出力する機能です。 Apache Parquet形式は、スキーマ情報を内包している・列志向で分析用途にも適している・高効率な圧縮が可能・複雑なデータ構造にも対応しているといった特徴を備えたデータ形式です。AthenaやRedshift、あるいはBigQueryへの取り込みに利用することができ、これらを使ったDB内のデータ分析が可能になります。 高効率さについての実験として、試しに手元の64GBのクラスタースナップショットをS3エクスポートしてみたところ、出力されたParquetファイルの合計サイズは約4GBと、なんと1/16にも圧縮されました。特に毎日何TBもの大容量データをリージョン外に転送するようなケース
こんにちは。 株式会社アカツキゲームスで ATLAS というチームに所属してゲーム内通貨管理基盤の開発及び運用を行っています、なかひこくん (@takanakahiko) です。 最近バイクを買いました。 私の担当するゲーム内通貨管理基盤の開発現場では、「マージ待ち」なるものが存在しました。 今回は、その課題を GitHub の新機能である merge queue で解決した方法を紹介します。 この記事は 2023-07-20 時点での merge queue 及び GitHub Actions の仕様に則ったものです。 今後のアップデートによりこの記事の内容が正しくないものとなる可能性があります。 「マージ待ち」とは 私の担当するゲーム内通貨管理基盤の GitHub リポジトリでは PR のマージ後に走る、同時に実施できない 15 分程度の E2E test が存在しました。 すなわち
この記事では、AWS の EC2 や ECS 上で動作する fluentd から Workload Identity を利用してBigQueryにログを送る方法を紹介します。 背景 AWS から BigQuery にアクセスする際、従来はサービスアカウントキーを利用して認証を行なっていました。しかし、サービスアカウントキーは厳重な管理が必要です。これに対して、Workload Identity を利用すれば、管理が必要なキー自体をなくすことができ、運用の手間を軽減することができます。 先日 googleauth gem 1.5 がリリースされ、Ruby からも AWS からのWorkload Identity による認証をすることが可能になりました。 rubygems.org 早速これを利用して、AWS上のEC2やECSで動作する fluentd から BigQuery にデータ送信する際
こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。 さて本題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。本記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。 hackerslab.aktsk.jp ずばりEMを無くして良かったのか これはマクロに見ると明確に良かったと思って
こんにちは、アカツキゲームスのVPoEのゆのん (id:yunon_phys)です。社内エンジニアリングカンファレンスAkatsuki Dev Meetupを9/13に開催したので、その運営側のレポートを書きます。 社内オンリーにしたのは登壇者への配慮 いきなりタイトルの話に入っていくわけですが、今回は社内の人に限定したカンファレンスにしました。せっかくやるなら社外の人も呼べば良いのにという声も上がるだろうなとは思ったのですが*1、あえて公開範囲を狭めました。僕らがこのカンファレンスを何のためにやるのか、でいうと、社内の情報の流通量を上げることが第一目的だったからです。 社内の情報の流通量を上げたいのは、アカツキで抱えている課題がそもそも出発点としてあります。現在アカツキは様々なゲームタイトルを開発・運用していて、そのタイトル内のチームでは密度の濃いディスカッションが出来ています。一方で、
この記事は、Akatsuki Advent Calendar 2021の24日目の記事です。 こんにちは、セキュリティエンジニアの小竹 泰一(aka tkmru)です。 アカツキでは、アプリケーションに対する脆弱性診断や社内ネットワークに対するペネトレーションテスト、ツール開発/検証を担当しています。 Apple Silicon MacをiOSアプリの脆弱性診断に使用する際にどのような利点、欠点があるのか調査した結果を書きたいと思います。2019年のAkatsuki Advent Calendarから続く、大好評企画(?)「ペンテスターは〇〇に夢を見るか」シリーズ第二弾です。 第一弾はこちら。 Apple Silicon MacでiOSアプリが動作するように! M1搭載MacBookが登場して、iOSアプリがエミュレータを使わずともmacOS上で動作するようになりました。 iPhoneおよ
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2021 の22日目の記事です。 アカツキでは数年前よりEngineering Managerの役割をおいているのですが、この度、Engineering Manager(EM)の役割を公式に無くしました。私の個人的な活動で、EMによるEMのためのPodcastをやっているし*1、社内でもそういう活動を知っている人がいるし、世間からするとお前がそれを言うのか〜と言われそうなのでなかなか勇気のいる決断でした。ただ、今後の会社の方針を考えたときに、今見直すタイミングなんじゃないかと思い、思い切って無くしてみました。 本記事ではなぜ無くすことにしたのか、これからどうしていくのかを書いていきます。 EMのやることが消滅したわけではない アカツキのEMはエンジニアのマネジメントと、プロジ
直感的な文法や生産性の高さから、世界中の人々に愛されるオブジェクト指向スクリプト言語Ruby。この言語には継続的に新しい機能や文法が追加されており、利便性が向上し続けています。コミッターの方々による日々の努力が、Rubyの改善を支えているのです。 コミッターのなかでも、とりわけRubyに大きな貢献をしてきたのがアカツキでフルタイムRubyコミッターを務める中田伸悦さん。(アカツキのCSRの取組みについてを記事下部参照) github.com 中田さんはRubyへのコミット数が全コミッターのなかで最多であり、通称“パッチモンスターと”呼ばれています。 今回のインタビューでは、中田さんがRubyへのコントリビューションを始めたきっかけや、印象に残る機能改修について解説してもらいました。「Rubyのことをもっと詳しく知りたい」「オープンソースソフトウェア(以下、OSS)へのコントリビューションを
この記事は Akatsuki Advent Calendar 2020 の20日目の記事です。 はじめに ゲームサーバでは大量のユーザーデータなどを取り扱うため、データベースの負荷分散のために水平シャーディング(水平分割)が行われることがあります。 アカツキでも、これまで Ruby on Rails や Elixir 等でゲームサーバを開発する中で、それぞれの方法で水平分割を行ってきています。 さて、先日リリースされた Ruby on Rails 6.1 では、待望の水平シャーディング機能が標準でサポートされました。 早速使っていきたいところですが、これまで別の方法で水平シャーディングを実現していたアプリケーションを移行するにあたってはいくつか課題があるため、 それをどう解決するかの一例をご紹介したいと思います。 また、その解決の一環で利用した Ruby の BasicObject クラス
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2020 の12日目の記事です。 アカツキは10周年を迎え、それと同時に経営体制が一新され、経営チームExecutive Leadership Team(ELT)が結成されました。 経営戦略の基本方針も変更となり、社内の構造的にも社内の方針としても、アカツキにとって大きな変化のある1年となりました。 私もELTのメンバーとして現在主力であるゲーム事業の職能組織を束ねる立場(Chief of Staff, Games / CoSG)となり、影響の範囲も、責任の範囲も大きく拡大しました。 これまでは、私はVP of Engineering(VPoE)としてエンジニア組織を束ねる立場にあり、一つの職能のことだけを考えておけば良かったです。 しかし今では、エンジニアだけでなく、デザイ
この記事は Akatsuki Advent Calendar 2020 3日目の記事です。 前回は bluexxsun さんの スプレッドシートの関数では "" を使うな! でした。 はじめに アカツキでエンジニアをやっている tomotaka-yamasaki です。 この記事では、エンジニアとQAがどのように協力しあってソフトウェアを開発していけば良さそうか、をJSTQBの内容を取り上げつつ書いています。去年のアドベントカレンダーではゲームプログラミングのHP計算システムアンチパターンという記事を書いていました。 hackerslab.aktsk.jp 現在、私はアカツキの子会社であるアカツキ福岡に在籍しており、QA業務の効率化やテスト自動化などを行うチームを立ち上げて、活動しています。私自身、エンジニアとして手は動かしたいので、効率化、自動化を行いながら、QA組織がより良い方向に向か
こんにちは! この度サーバサイドエンジニアとしてインターンシップで勤務させていただきました、髙津と申します。 本記事では、インターンシップ期間 (2020年7月6日〜7月31日) 中に取り組んだこと、感じたことなどを書いていきます。似たような技術課題に直面している方々、これからインターンシップを受けようと考えている方などの手助けになれば幸いです。 具体的には インターンシップで取り組んだこと 知見 Capacity Providerの具体的な設定項目 Auto Scalingの仕組みのおさらいと設定項目一覧 検証 懸念事項 1. 動作の上で最適な設定は何か? 1.1. SSPタイプはどちらが良いのか? 1.2. Scalingトリガーとして適切なメトリクスは何か? 2. Scalingは十分に速いか? 3. 安全にScale Inできるか? まとめ インターンシップを通じて感じたこと 取り
こんにちは、セキュリティエンジニアの小竹 泰一(aka tkmru)です。 アカツキでは、Webアプリケーション、ゲームアプリに対する脆弱性診断や社内ネットワークに対するペネトレーションテスト、ツール開発/検証などを担当しています。 メモリ改ざんによるチートとは UI上に表示されている値を端末のメモリ上から検索し、見つけた値を改ざんすることでチートを行うことができる場合があります。 これはゲームのチート方法の中で最も簡単な方法で、脆弱性診断の際にも実際にメモリ上のデータを改ざんをすることでチートできるかどうか確認しています。 対策としては、XOR等を使ってメモリ上ではエンコードされた状態で値を保持し、UI上に表示されている値を検索されても見つからないようにする方法があります。 作ったツール apk-meditという脆弱性診断のためのAndroidアプリ向けメモリ改ざんツールを作成しました。
これは Akatsuki Advent Calendar 2019 20日目のネタです。 CTO兼セキュリティの責任者を担当している田中です。株式会社アカツキでは、ネットワークとエンドポイントデバイス、一部のビルドサーバ以外のリソースを全てクラウドに置いています。 「出来る限りクラウドを利用する」という考え方は事業の柔軟性を重視し、インフラ管理コストを下げたい企業では一般的になっているかと思います。 クラウドをインフラにすることであまりセキュリティを重視していない会社も多いと思います(昔のアカツキもそうでした)が、「個人情報を扱うようになった」「事業が成功した」といった事業状況の変化によって求められるセキュリティレベルも変わってきます。 セキュリティを意識せずに開発していた時代から現在まで、様々なセキュリティ対策を検討し、実施してきました。 セキュリティは組織・プロセス・規範/法律・技術と
この記事は、Akatsuki Advent Calendar 2019の21日目の記事です。 こんにちは、セキュリティエンジニアの小竹 泰一(aka tkmru)です。 アカツキでは、アプリケーションや社内ネットワークに対する脆弱性診断やツール開発/検証を担当しています。 この記事では内部ネットワーク診断でDBサーバーを発見したときに確認する項目を紹介したいと思います。 内部ネットワーク診断とは 社内ネットワークにつないだ診断員のPCからネットワーク上の端末へ攻撃を行い、ミドルウェアの設定不備による脆弱性や、ソフトウェアが古いバージョンのまま放置されていることによる脆弱性などを発見するのが内部ネットワーク診断です。 脆弱性を見つけるだけではなく、見つけた脆弱性を使って更にどれだけ会社にダメージを与えられるかまでを検証し、ペネトレーションテスト相当のことにまで踏み込んで診断を実施しています。
この記事は Akatsuki Advent Calendar の 16 日目の記事です。 アカツキでエンジニアをしているe__komaと申します。 今年はAWS Summit TokyoやAmazon Game Developers Conference などを始め、色んなところでAWS運用を紹介させていただいております。 今回もそんなAWS運用話の1つです。 AWSアカウントが増えてくると、統制をとるのが大変ですよね。AWS Configを使えばポリシー違反のリソースを検知し、システム監査を自動化することができます。 この記事では、IAMユーザのIP制限を題材に、AWS Configのカスタムルールを作成する事例をご紹介いたします。 経緯 弊社ではEC2 IAMロールを利用したり、一時的な認証情報を利用することで、極力IAMユーザを作らない運用を目指しています。 一方で、各種サードパーテ
この記事は Akatsuki Advent Calendar の 15 日目の記事です。 thinca です。普段は Vim を使って開発をしています。 そんな Vim ですが、つい 2 日ほど前、待望の Vim 8.2 がリリースされました!やったね🎉 本記事では Vim 8.2 で何ができるようになったのかを、同時に公開されたデモプラグインを通して見ていこうと思います。 Vim のリリースについて その前に、Vim の開発体制について少し説明します。 Vim の開発は GitHub の vim/vim リポジトリで開発されています。ブランチは master のみで、最新版は同時に開発版でもあります。 Vim は、パッチ(Git 管理になった今ではコミットとほぼ同義)を積み重ねて改善が行われます。前回のマイナーバージョンアップ(Vim 8.1)から少しずつパッチを積み重ね、ある程度のと
この記事は Akatsuki Advent Calendar 2019 11日目の記事です。 はじめに アカツキでクライアントエンジニアをやっている tomotaka-yamasaki です。 私が所属しているプロジェクトは長く運用されているタイトルなので、実装当時に書かれたソースコードでは到底実現できない開発を迫られることがあります。*1 この記事では、ゲームのバトル中に行われるHP計算周りの改修を行ったときに踏んだアンチパターンと、最終的に行き着いた設計についてまとめています。バトルが存在するゲームになくてはならないHP計算システムについて、考えるきっかけになればと思います。 TL;DR C++を前提とした記事です。 既存のHP計算システムでは実現できない仕様が追加されたのでリファクタリングに踏み切りましたが、苦しみました。 この記事ではHP計算システムの4つのアンチパターンとそれぞれ
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2019 10日目の記事です。 エンジニア組織の成長のために大切にしている2つの事柄 アカツキのエンジニア組織は2~3年かけて成長していく状態を目指しています。 そしてその成長のためには、情熱と技術の積み上げが大事である、と考えています。 1. 情熱という感情を大切に扱う アカツキでは、情熱を持って仕事をしている状態を称賛します。 というのも、その人の想いが込められたプロダクトは明らかに完成物のクオリティが高くなりますし、よりクオリティを上げるためのいかなる努力も惜しまなくなり、結果として人も組織も成長すると考えているからです。 情熱というのは大きな野望である必要はありません。 その人が心からやりたいと思っているものであれば、その情熱の炎に大きさは関係ありません。 個人として
この記事は Akatsuki Advent Calendar 2019 の 9 日目として書きました。 はじめに みなさん、マルチクラウドしてますか!? 株式会社アカツキでエンジニアをしている @sachaos です。 弊社では各ゲームプロダクトから利用される共通基盤をマイクロサービスとして構築しています。 この共通基盤は Google Cloud Platform (以降 GCP) の Google App Engine (以降 GAE) Standard Environment により運用されています。 現在、ゲームプロダクトでは主に Amazon Web Services (以降 AWS) を利用しているため、ゲームサーバは AWS と 共通基盤は GCP のマルチクラウド構成となっています。 アカツキでは海外向けに提供しているゲームもあります。 日本にゲームサーバがあれば日本のプレ
この記事は Akatsuki Advent Calendar 2019 - Adventar 5日目の記事です。 はじめに UniTaskとは🤔🤔🤔 やりたいこと🤔 まず最初に考えたやり方🤔 Incremental Compilerが不要に!😇 とはいえ全部をいきなりUniTaskに置き換えるのは難しくない? UniTaskCompletionSource UniTaskの中身を解析してみよう🤔 PlayerLoopHelper PlayerLoopHelper.csの中身 ContinuationQueue PlayerLoopReusablePromiseBase UniTask IsCompleted Awaiter IAwaiter ICriticalNotifyCompletion 次に気になったこと どうやってAsyncUniTaskMethodBuilderを呼
この記事は Akatsuki Advent Calendar 2019 - Adventar 4日目の記事です。 こんにちは! suwahime です。 昨今どの業界を見渡しても、アクティブユーザー数や入会数といったデータは、当たり前のように日々追っているかと思います。 私の所属するチームでは、主にRedashを用いてKPIを可視化しています。 今日は、先月BigQueryにBetaリリースされたスクリプトとプロージャ機能を使って、RedashのQuery作成を、よりシンプルに、管理しやすい形で書いてみたことをお話しさせていただきます。 RedashはQueryごとに定義が分散してしまいがち 例として、「期間内にサービスを訪れたユーザー」の利用デバイスを調べる、以下のようなQueryをRedashに作成していたとします。 SELECT B.device_name, COUNT(DISTIN
TL;DR 『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』 でRailsを高速化させる素晴らしいハックが紹介されましたが。いまや有効なハックではなくなりました。 TZハックさん、ながい間(2日間)おつかれさまでした。 はじめに アカツキさまで技術顧問をさせていただいている小崎です。 このエントリは『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』をRubyコミッタが読んだらこうなったというアンサーソングになっています。合わせてお読みください TZ環境変数でTime.newが10倍近く速くなるのは素晴らしい発見ですが、コミッタとしてはTZなしでも速くなって欲しいなと思いました。だってめんどうだし。 現状分析 まず問題のテストプログラムを軽く分析してみましょう % strace -c ruby .
この記事は Akatsuki Advent Calendar 2019 1日目の記事です。 はじめに アカツキでは Ruby on Rails を使ったゲームサーバを開発・運用しています。ゲームの体験を向上するために、レスポンスタイムは一つの重要な要素となるため、種々のパフォーマンスチューニングを行なっています。今回はその一例として、環境変数を1つ設定するだけで、あるAPIのレスポンスタイムが10%も改善した例をご紹介します。 TL;DR 多数の時刻を含むレコードを扱う Ruby on Rails サーバでは、 TZ 環境変数を設定することで、デフォルトタイムゾーン設定ファイル /etc/localtime へのアクセスが減り、高速化が図れるかもしれません。 効果は Time オブジェクト1個あたり数μsの短縮といったオーダーですが、チリも積もれば山となり、数千個のレコードを処理するAPI
こんにちは、ゆのん(id:yunon_phys)です。みなさん、良いチームを作っていますか? 良いプロダクトを生み出すためには、良いチームであることが必要です。 そして、良いチームであるためには、チーム構成が適切になっていないといけません。 今回は、どうやったら良いチーム構成が出来るか、というのを考えるときの思考ツールをご紹介します。 チーム構成はトレードオフの関係がある モバイルゲームはリリースがゴールではなく、むしろリリースがスタートです。 リリースしたら何年も運用することになり、プロダクトチームは数ヶ月~1年後を見据えてアセットを用意していきます。 そのため、いかに普段から効率的にアウトプットを出せるプロダクト組織を作ることが重要です。*1 効率的にアウトプットを出すためには様々な工夫をしますが、プロダクト組織内のチーム構成も一つの鍵です。 私がチーム構成が鍵であると考えるようになっ
この記事はAkatsuki Advent Calendar 2018の12日目の記事です。 前回は hayamaruさんの、知覚メカニズムと網膜投影でした。 はじめに 継続的デリバリーという文脈で、素早く、安全にデプロイする手法について、近年多くの記事を見かけます。 例えば、カナリアのおかげで命拾い : CRE が現場で学んだこと でカナリアリリースについて詳しく触れられています。このアイデアは「たとえテスト環境で十分な検証をしたとしても、本番環境で問題が発生しないということを保証するのは難しいので、少しづつトラフィックを移動して問題があったらすぐにロールバックをしよう」というものです。 上記記事中に紹介されているKayentaといったツールを使ってカナリア分析を行い、自動的にカナリアリリースするというのも良いですが、人間による承認を元にデプロイするならもう少しコストの低い方法で良さそうで
こんにちは、mizzy です。業務委託でアカツキさんのお手伝いをしています。お手伝いの一環として、aktsk/atgen という、Go用HTTP APIテストコードジェネレータを開発しています。 この記事では、Atgenの概要や開発の背景、今後の予定などについてご紹介します。 Atgen とは HTTP API Test Code Generatorの略で、HTTP APIをテストするためのコードを自動生成する、Go製のコマンドラインツールです。 YAMLで記述されたテストすべきHTTPリクエスト/レスポンスと、Goで書かれたテストコードのテンプレートから、実際にテストを実行するためのコードを生成します。 atgen/example at master · aktsk/atgen に動かすことができるサンプルがありますので、READMEの通りに動かしてみると、どんなツールなのか掴んでいただ
この記事は Akatsuki Advent Calendar 2018 の23日目の記事です。 前回は id:yunon_phys さんの、エンジニア組織の責任範囲の透明性をRACI図で高めてみた でした。 はじめに アカツキではElixirを使ってゲームのAPIサーバを開発・運用しています。 ゲームのAPIサーバは、大量のリクエストを低いレイテンシで捌くことが要求されるため、Erlang VMの高いスケーラビリティが利用できるのは効果的です。加えてRubyなどを書き慣れている人にとっつきやすいElixirの文法も魅力です。 とはいえ、その性能を引き出すためには、やはりアプリケーションのパフォーマンスチューニングは不可欠です。 その際、"Don't guess, measure" という言葉の通り、どこを改善すれば良いかを知るための良い計測ツールが必要になります。 これまでRuby on
次のページ
このページを最初にブックマークしてみませんか?
『Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く