Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

プロダクション環境で使用しているEC2をArmベースのAWS Gravitonに移行しました

この記事は Akatsuki Games Advent Calendar 2023 の2日目の記事です。昨日は @tkmruさんの「CODE BLUE参加記:食べて Decompile 寝て 繰り返す」でした。コロナで減ってしまったリアルイベントにも活気が戻ってきて良いですね!

はじめに

アカツキゲームスでサーバエンジニアをやっています柴原です。今回は自分の担当しているモバイルゲームのプロジェクトでは、ECS on EC2の環境で運用をしており、Graviton搭載のEC2に移行を行いました。 詳しい手順の紹介というよりは、その思考の過程や工夫を紹介できたらと思います。

経緯

2018年にAWSはArmアーキテクチャのプロセッサGravitonを独自開発したことを発表し、サービス提供を開始しました。 特徴としては、x86ではなくArmベースのアーキテクチャである点とIntelのプロセッサを搭載した従来インスタンスに比べコストパフォーマンスが優れている点が挙げられます。 以下に4xlargeまでのC5(第5世代intel搭載)、C6i(第6世代intel搭載)、C6g(初登場第6世代Graviton搭載)、C7g(最新の第7世代Graviton搭載)のリザーブドインスタンスの価格をまとめた表を示します。 このように前世代と同世代のintel搭載のEC2と比較してもGraviton搭載のEC2は安いことが分かります。

インスタンスタイプ C5 C6i C6g C7g
large USD 551 USD 577 USD 411 USD 490
xlarge USD 1,102 USD 1,154 USD 882 USD 981
2xlarge USD 2,205 USD 2,308 USD 1,764 USD 1,962
4xlarge USD 4,409 USD 4,615 USD 3,527 USD 3,923

ap-northeast-1のリージョンで1年分全額前払いのLinuxの価格

aws.amazon.com

また、AWS re:invent 2021の「Deep dive into AWS Graviton3 and Amazon EC2 C7g instances」にて、ベンチマークにおいてIntel搭載のEC2と比較して性能は向上していることも挙げられており、コスト面以外にも恩恵を受けられる可能性があります。 コスト面、性能面から見て利点がありそうということで、私のプロジェクトではGraviton移行に取り組み始めました。

移行する時の問題点

Gravitonに移行するにあたって考えなければいけない点として次の観点が挙がりました。

  • キャパシティ
  • ビルド
  • Arm未対応ミドルウェアの対応

このブログではキャパシティとビルドについてのみ言及します。

キャパシティ

運用型ゲームの性質上、イベントなどでアクセスが局所的に集中する傾向にあります。 AWSではAutoScalingGroupという機能によってEC2の台数を簡単に増減させることが可能です。 EC2を使っているような構成のインフラでは、アクセスの集中に合わせてスケールアウトすることで局所的なアクセスに対応することができます。 しかし、局所的にアクセスが集中する時では一度にたくさんのインスタンスを起動することがあったり、他のAWS利用者がたまたま多く同じタイプのインスタンスを使用している場合にAWS側のリソースが枯渇することがあります。 仮にコンピューティング最適化のインスタンスを使うと仮定すると、以下のタイプが存在します。

  • Graviton: C6g、C7g
  • Intel: C4、C5、C5a、C6i、C6a

タイプとしての種類が少ないだけでなく、昔から用意されてきたIntel系に比べるとGraviton搭載のEC2が多くないことは推測できます。 先ほどの例で言うとGraviton だけの運用をした場合、C6gとC7gのリソースを使い切ってしまうと、EC2はスケールアウトすることができなくなり、サーバの負荷が高まることが懸念されます。 ゲームに限らず言えることですが、意図しないサービスが継続できない状態は良くありません。

そこで私のプロジェクトでは、x86アーキテクチャ(Intel プロセッサ)とArmアーキテクチャ(Graviton)の両方で動作させるという方針にしました。 Gravitonだけの運用に比べて冗長性があり、リソースの枯渇に対しての対策としては十分な効果が期待できます。

ビルド

x86のみのシングルアーキテクチャの場合と異なり、マルチアーキテクチャではビルドがどうしても複雑になります。

マルチアーキテクチャビルドの問題点

よく利用されるマルチアーキテクチャの方法には以下の2つがあるようです。

CodeBuildは、コードをビルドし単体テスト実行して、イメージを作ることができるサービスです。 ビルドを実行する環境として、x86やArmを選ぶことができます。 両方のアーキテクチャでビルドを実行させることで、それぞれのアーキテクチャに対応したイメージを作成できます。 CodeBuildでのビルドを試したところ、ビルド環境の起動までの時間が長くなるケースがありました。(※2023/12月現在では、CodeBuildがLamdbaをサポートしたので起動速度について改善する可能性があります。) 開発環境のデプロイ時に毎回イメージのビルドを行っていたため、これは開発のペースが悪化する懸念がありました。 一方、buildxはdockerコマンドを拡張するCLIプラグインで、自身のマシンのアーキテクチャとは異なるものを選択してビルドを実行することできます。 buildxはqemuを用いたエミュレーションを行うため、速度低下がありますし、使用する言語・VMによってはエラーの原因になることもあります。 実際、コンテナ内に含まれていたRuby Gemのネイティブバイナリのコンパイルが非常に遅くなるケースもありました。 ここで一度立ち返ってみると、問題点は以下に集約されます。

  • ビルド速度低下によるデプロイ自体の速度の低下
  • buildxを採用する場合のqemuのエミュレーションの懸念

ビルドの速度低下については、単一のアーキテクチャでなくなった以上ある程度は仕方ない部分はあります。 しかし、これを最小限にしつつも速いビルドを実現し、エミュレーションであることを気にしたくはないです。 そこで、次の方針を立てました。

ビルドの工夫

デプロイは、コードを変更した時やライブラリの更新をした時などに行います。 一般的に、ライブラリの更新以上にコードの更新の方が多いです。 つまり、コードの更新の時だけでも速くなればストレスは少ないということが言えます。 そこで、イメージを分割することを考えました。 以下の図に示すように、Gem等ネイティブバイナリ部分を含むベースイメージとそのベースイメージにコードをコピーしただけのコードイメージに分けるという方法です。

ベースイメージにはネイティブイメージが含まれエミュレーションを気にしたくないため、CodeBuildを用いて必要な時(ライブラリ更新やセキュリティパッチの適用)にのみビルドさせます。 そして、そのベースイメージに対してコードのコピーや環境変数の設定のみの作業をdocker buildxに実行させます。 こうすることでコード更新によるデプロイの速度の低下を最小限にしつつ、エミュレーションを気にしないで済みます。

まとめ

このような問題点を考慮しつつビルド方針を定め、私のプロジェクトではGravitonへの移行に成功しました。 年間でかかるインフラ費用を抑えつつ、スケールアウト時の冗長性を高めることができました。 また、既存デプロイへの組み込みを無事終了し、この体制で運用をしています。 インフラにかかる費用を抑える工夫は、常に考え今後も実施していきたいですね。 AWS re:Invent 2023では、CEOのKeynote セッションにてGraviton4搭載のR8gが発表されました! 更なる高速化が期待できるので、東京リージョンに来るのが楽しみですね! 皆様も良きGravitonライフを送ってください。

明日は、Jingyuan Zhaoさんの記事となります。お楽しみに!

CODE BLUE 2023参加記:食べて Decompile 寝て 繰り返す

セキュリティエンジニアの小竹(aka tkmru)です。 先月、CODE BLUEというセキュリティカンファレンスに行ったので、その参加記を書きました。 このエントリーはAkatsuki Games Advent Calendar 2023の1日目の記事です。

CODE BLUE とは

CODE BLUEは、2014年より東京で開催されているセキュリティカンファレンスです。 日本国内で開催されているセキュリティカンファレンスの中では、最大級のカンファレンスです。 去年は「オンライン配信」+「リアル会場」によるハイブリッド開催となっていましたが、今年は会場のみでの開催でした。 去年は登壇者として参加していましたが、今年は去年よりも参加者が増えているように感じました。

Hex Rays社のグッズに心を奪われる

今年のCODE BLUEでは、なんとIDA Proの開発元であるHex Rays社がスポンサーになっていました。 Hex Rays社のブースでは、サッカーのゲームのスコア次第でTシャツやノートなどをもらえるというイベントをやっていました。

私はTシャツをもらうことができました。愛用しているツールグッズをもらえるというのは、とても嬉しいですね。 食べて、Decompile、寝て繰り返し、マントノン侯爵夫人と一生を添い遂げようと決意しました。

印象に残った発表

ここでは印象に残った2つの発表を紹介します。

休憩中に飲む紅茶が非常に美味しい!!!!!

stelftools: クロスアーキテクチャに対応した静的結合されたライブラリ関数の特定ツール

stelftoolsという静的リンクされたライブラリ関数を特定するツールの発表が行われました。 この発表はツールに関する発表が行われるBluebox枠での発表です。 本ツールのリポジトリは以下です。 github.com

多くのIoTマルウェアでは、ライブラリを静的リンクしており、解析時に攻撃者が定義した関数なのか、ライブラリ内の関数なのかが特定しづらくなっています。 動作を詳細に解き明かしたいのは攻撃者が定義した関数であり、ライブラリ内の関数と区別できれば、効率的に解析が行なえます。 また、ライブラリ内のどの関数がどの部分で用いられているかが分かれば動作を理解する助けになります。

しかし、IoTマルウェアは様々なアーキテクチャのCPU向けに開発されており、関数のシグネイチャを用意するのは大変です。 この問題を解決するためにstelftoolsは開発されました。stelftoolsは17のアーキテクチャと700以上のツールチェーンに対応しています。 静的リンクされたELFバイナリを解析するためのツールということでst(atic)-elf-toolsと名付けられています。

関数の発見にはパターンマッチだけではなく、分岐先のアドレスや呼び出しの依存関係を比較することで精度の向上が図られています。 rand(3)のような、内部で別の関数をそのまま呼び出すだけの関数はサイズが小さすぎ、単純なパターンマッチだけでは大量に一致してしまう問題を解決しており、 IDA F.L.I.R.T.、BinDiff、rizzoなどの他のツールよりも精度が高いものを実装できたとのことです。 リポジトリ内のYARAのパターンファイルを見ると、膨大な量のシグネイチャが用意されており、 開発の大変さがうかがえます。

IDAやGhidraのプラグインが用意されており、 非常に便利そうで私自身も使いたいツールではありますが、チーターの皆さんには使ってほしくないツールだなと思いました。

PowerAutomate C2: クラウド寄生型ステルスC2フレームワーク

PowerAutomate C2というツールの発表が行われました。この発表もBluebox枠での発表です。 Power AutomateはMicrosoftが提供している「新しいPowerShell」とも称される強力なローコードツールです。 このPower AutomateをC2マルウェアとして活用しようという発表でした。 本ツールのリポジトリは以下です。 github.com

去年のAVTOKYOでも発表されており、その時の内容は発表者のブログにまとめられています。 jp.security.ntt

Power Automate C2を活用するための攻撃シナリオは次のようになります(上記ブログより引用)。 PowerAutomateで構築された自動化処理はフローと呼ばれ、フローの実行ログは1ヶ月程度保管されますが、フローを消すとログが消失します。

  1. 攻撃者はユーザーを侵害して Power Automate へのアクセス権を入手し、悪意あるフローを作成する。
  2. 侵害されたことを知らないユーザーが、たまたまパスワードを変更する。
  3. 攻撃者は C2 経由で Power Automate へのアクセスを継続し、任意のフローを作成・実行する。
  4. 攻撃者は目的を達成したらフローとともに痕跡を削除する。

Power Automateを活用する利点として、クラウド上で完結するため、ユーザーの端末を必要とせず、EDRやIDSの監視対象外で活動を行える点、ログを消すことが容易な点が挙げられます。

ノーコードツールを攻撃に使用する方法のドキュメントは不足しており、大変勉強になる発表でした。 他のノーコードツールでも似たことができないか確認してみたいと思いました。

PwCによるアフターパーティー

CODE BLUEでは全ての発表が終了した後、最後に公式のネットワーキングパーティーが開催されています。 その後にPwCが去年から独自にアフターパーティーをクラブで行っています。 今年は六本木のクラブに観光バスで移動しての開催となりましたが、移動費、参加費もなんと無料です!!!! 普段クラブに行かないので新鮮な体験でした。ネットワーキングパーティでは会えなかった人ととも出会えて非常に楽しかったです。

まとめ

発表を楽しむだけでなく、なかなか普段会う機会がない知人たちとも会えて、とても楽しいカンファレンスでした。 カスペルスキーの学生招待枠での参加だったり、学生スタッフとしての参加だったり、発表者としての参加だったり、形態は様々ですが、2015年より毎年参加している(多分....)ので、来年も機会があればぜひ参加したいと思います。

今年も社内向けカンファレンスを開催しました

こんにちは、エンジニアリングオフィスの島村です。

去る10月27日(金)に Akatsuki Dev Meetup 2023 という社内向けのカンファレンスを開催しました。

今回も運営サイドからの開催レポートをお届けいたします。

一昨年から毎年継続的に開催しており、今回が3回目の開催となります。

Akatsuki Dev Meetupとは?

”技術”を対象にした社内のみの公開を対象とした内部カンファレンスです。
チームの枠を超えた技術交流が主な目的となります。

登壇及び参加者はエンジニアに限らず、アカツキゲームスに所属している人全員が対象となり、「Dev」と冠していますが職種を制限しないイベントとしています。

続きを読む

ATLASチームにおける就業型インターン参加レポート

こんにちは。

株式会社アカツキゲームスで ATLAS というチームに所属してゲーム内通貨管理基盤の開発及び運用を行っています、なかひこくん (@takanakahiko) です。 最近は良い気候なので、バイクでの運転が気持ち良いですね。

私の担当するゲーム内通貨管理基盤の開発現場で、インターン生を受け入れました。 ありがたいことに、そのインターン生がブログ向けに参加レポートを書いてくれたので私の方から代理投稿させていただきます。

上記の通り、この記事は代理投稿となります。 投稿者と執筆者は異なるのでご承知ください。

続きを読む

アカツキゲームスで Cocos2d-x / C++コース のインターンシップに参加しました

こんにちは。 株式会社アカツキゲームス クライアントエンジニアの、軍曹 (@maupukuncarbon) です。

この度、私たちのチームでインターンの方を受け入れました。ありがたいことに、参加レポートを書いてくれたので、私の方から代理投稿させていただきます。

上記の通り、この記事は代理投稿となります。 投稿者と執筆者は異なるのでご承知ください。



2023/09/04~2023/09/22の3週間、株式会社アカツキゲームスのインターンシップに参加させていただきました。 今回はインターンシップで取り組んだことを備忘録としてまとめていきます。

続きを読む