突撃！隣のDevOps 【アカツキ編】

はじめに

こんにちは、DevOps導入支援担当の藤村です。今回の突撃！隣のDevOpsはスマートフォン向けゲーム開発で有名なアカツキさんにお邪魔して、DevOpsに関する考えや取り組みについて徹底的に聞いてきました！

アカツキ紹介

どのようなサービスをやっている

アカツキは、「A Heart Driven World.」をビジョンに掲げ、モバイルゲーム事業とリアルな体験を届けるライブエクスペリエンス事業を展開している総合エンターテインメント企業。世界中の人の心にワクワクと感動を届け、幸せにしたいと本気で考え、日々新たなチャレンジを続ける会社です。中でも、スマートフォン向けゲーム事業で、いま一押しのゲームは八月のシンデレラナイン（ハチナイ）とのことです！

インタビューに答えていただいた方

今回のインタビューは、以下のエンジニアの方々にお答えいただきました。

• 湯前さん
  • エンジニア組織のマネージメント
  • 新規タイトルゲームのプロジェクトマネージャー
• 野村さん
  • 運用プロダクトのサーバーエンジニア（新規開発／運用両方）
• 坂尾さん
  • 新規プロダクトのサーバーエンジニア, ゲーム基盤開発
• 河野さん
  • 運用プロダクトのサーバーエンジニア（新規開発／運用両方）
• 関山さん
  • 新規, 運用プロダクトのサーバーエンジニア（新規開発／運用両方）

右から湯前さん、野村さん、坂尾さん、河野さん、関山さんです。

DevOpsについて

文化

貴社の考えるDevOpsの定義とは？

いきなりですが、いままで特にDevOpsという言葉を意識したことはないそうです。アカツキではサーバーエンジニアという役割は定義していますが、その業務内容はアプリケーションの開発、インフラの整備、開発環境の整備から、本番のデプロイ、障害対応まで行なうので、DevとOpsが連携するというより、DevもOpsも当たり前に一つのチームで行っているとのことでした。サーバーエンジニアがインフラも見るので、インフラを専門で見るインフラチームというのも存在しないそうです。

特にソーシャルゲームでは、運用中にイベントの更新などをどんどん行っていく必要があり、インフラにかかる負荷も一般的なWebサービスよりも高くなりやすい特性があるので、運用やインフラのことをサーバーエンジニアが必ず考慮しながら開発を行う必要があるという、ソーシャルゲーム開発ならではの事情もあるとお話しされていました。

なぜDevOpsに取り組んでいるのか？

DevやOpsなどの専門部署や専門職種を作ってしまうと、専門部署や職種の役割を守るような動きが働いてしまうと考えているそうです。そこから生まれるのは、保守的な行動、ムダなコミュニケーション、責任の押し付け合いでしかなく、それだと変化に対応しにくい組織となってしまいます。そのような組織の形は不健全だと考え、あえて専門部署や専門の職種を作るのは最小限にしているそうです。

最小限とお話されたのは、例外として各プロジェクトで利用する共通の基盤開発チームがあるからです。基盤開発チームは6人ほどのチームで、今回のインタビューを受けていただいた坂尾さんも所属しているそうです。どのゲームタイトルにも必要な「認証・課金」等の機能をマイクロサービス化して各プロダクトへ提供したり、研究開発なども行っているチームであり、開発組織の中で唯一の横断的なチームと言えます。

この基盤開発チーム以外は全てそれぞれのチーム内でDevもOpsも完結するようなチーム編成になっており、チーム内で柔軟に役割を変えながら対応しているとお話されてました。

DevとOpsをどのように連携させているのか？

アカツキではゲームタイトルごとにチームを編成しており、個々のチームは一部のゲーム共通機能を除いて、チーム内で開発、運用を全てチーム内で完結できるような職能横断型チーム(フィーチャーチーム)となっているそうです。開発プロセスや、アーキテクチャ、言語、利用するツールまで各チームごとに最適なものを自由に選択し、チームごとに改善に取り組んでいるとのことでした。

チーム内では、Devの比重が大きい人、Opsの比重が大きい人それぞれがいますが、DevもOpsもどちらも必ず経験するようにしており、緊急時にはDev寄りの人もOps寄りの人も一丸となって課題解決に取り組むような文化が定着しているそうです。お話しを聞いて、当たり前にDevOpsが行われている状況だなと感じました。

チームのメンバー構成はどうなっているのか？

野村さんと河野さんから、それぞれが所属するチーム構成について聞いてみました。

野村さんのチーム

エンジニアは全員が機能開発チームに所属し、その中で主にクライアントサイドチームとサーバーサイドチームの2つに分かれているそうです。機能開発チームにはエンジニア以外にもデザイナーやプランナー、検証チームも所属し、チーム内ですべてが完結する構成になっているとのことです。

エンジニアがDevもOpsも兼ねると先述しましたが、その割合はサーバーサイドチームでは半々、クライアントチームではDev8割、Ops2割ぐらいの割合で分担しており、クライアントサイドで使っているUnityの処理の自動化など、クライアントサイドでもOps的な動きをしているエンジニアもいるそうです。

河野さんのチーム

河野さんが所属するチームは全部で100人近くのメンバーが所属する大所帯なので、開発チームを2つに分け、それぞれのチームが異なるバージョンの開発を実施し、交互にリリースするような開発プロセスを採用しているそうです。1チームの開発期間は3ヶ月程度、それを2チームが交互に行なうことによって、1ヶ月半ごとのリリースを実現しています。2つのチームは完全に分かれていますが、お互いのチームが何をやっているかを知っておく必要もあるため、適切な粒度で会議体を設定し、情報共有も行っているそうです。

個人的にはコンフリクトが起きないか気になって質問してみたところ、先行するチームの変更を後続するチームが頻繁にマージして取り組むことで、特に問題は起きていないとのことでした。

開発のフェーズがデバッグ、リリース準備のフェーズに入ると、サーバーサイドでは少し余裕が生まれるため、そのタイミングでツールの整備や、パフォーマンスチューニング、オペレーションの自動化などに取り組んでいるそうです。クライアントサイドでも、アプリのビルドやテストのためのツールの開発をクライアントサイドエンジニア自身で行っていますが、そのようなことが得意なエンジニアに作業が集中しがちなことが現状の課題だとお話しされていました。

新メンバーへのキャッチアップの支援をどのようにやっているか？

野村さんのチーム

クライアントサイドでは、機能開発用のチュートリアルを独自で作成し、新メンバーはそのチュートリアルに取り組むことによって開発の進め方を学べるそうです。このチュートリアル自体も新メンバーからのフィードバックを元に日々ブラッシュアップしているとのことでした。

サーバーサイドでは、特に具体的なキャッチアップの手順は無いそうですが、小さめの機能開発から着手してもらってレビューを通してフィードバックしたり、緊急時対応に備えて開発環境内のトラブル対応をまずは担当してもらうなどして徐々に担当範囲を広げているそうです。

河野さんのチーム

開発周りのキャッチアップよりも、社内の独自運用ツールのトレーニングが特に重要だと考えているそうです。独自の運用ツールとしては、ゲームにおいて非常に重要なマスターデータのチェックツールなどがあり、Excel上でのマクロを使ったチェックから、シェルを使ったチェックまで独自の運用ツールを使用しており、それらの使い方を手順書などを使って理解してもらっているとのことでした。

最近は幸いなことに本番でのトラブルが減って安定稼働しているため、本番でのトラブル対応のキャッチアップをどう進めるかが課題となっているそうです。過去のトラブルのポストモーテムは書き溜めてあるので、それを読むことである程度のノウハウ共有はできると考えていますが、やはりそれだけでは不十分なので、前回のインタビューでも話題になったカオスエンジニアリングの必要性についてもお話しされていました。

DevOpsを進めていく上で苦労したことなどはなにか？

4年前に湯前さんが入社した時には、すでにサーバーエンジニアがインフラも担当するようなDevOps文化が定着しており、特に苦労したようなことはないそうです。会社も社員もDevOpsネイティブって印象を受けました！

プラクティスとツール

CI、デプロイ、構成管理どのようにやっているのか？

CI、デプロイはJenkins、CircleCI、AWS CodeBuild、AWS ECSを組み合わせて使っているそうです。その組み合わせ方やデプロイの方法もチーム単位で最適な方法を選択しているそうで、JenkinsのGUIからデプロイしているチームもあれば、デプロイ用のシェルを実行するチーム、またChatOpsでSlack経由でデプロイしているチームもあるそうです。

以前はJenkinsの運用管理がとても大変で属人化してしまっていたそうですが、現在はDocker使ったコンテナでCI環境を構築することでいつでも誰でも再構築できるようになり、運用管理がかなり楽になったそうです。

テストについては、サーバーサイドのUTの自動化は十分にできているそうですが、クライアント側のE2Eテストの自動化は行っておらず、専門の検証チームが人力でテストを実施しているそうです。一方、先述したゲームのマスターデータのテストは、CIで自動化できているとのことでした。

ゲームの場合、そもそも何が正しいかを定義するのが難しいこともあり、人間にしか判断できないものは人間で確認するというように割り切って考えているそうです。その中でも、エンジニアがプルリクエストに想定影響範囲を記述し、検証チームもその内容を確認できるようにするなど、小さな改善を繰り返しながら進められているとお話しされていました。

デプロイについては、基本的にはクライアントサイドとサーバーサイドでバージョンを合わせる必要があったり、イベントの開催に合わせてタイミングを人の手で調整する必要がある点などは、ゲームならではの制約ではないかとのことです。

障害をどのように検知して、どのような対応フローで進めているのか？

障害の検知は、主にAWS CloudWatchで検知してSlackに通知するようにしているそうです。基本的にはチーム内で反応するようにしているそうですが、通知先のチャンネルをオープンにすることでチーム外の人でも気づけるような体制にしているとのことでした。検知後は、まずはアプリにログインできるか、正常にプレイできるかを確認し、状況に応じてメンテナンスに切り替え、社内関係者やステークホルダーへの報告などを行っているそうです。サーバーエンジニアであれば誰でもメンテナンスに切り替えられる権限が与えられているとお話しされていました。

他にも、Sentryでサーバーサイドのエラーを検知、SmartBeatでアプリのエラーを検知、Mackerelを使ってロギングのプロセス監視も行っているそうです。

さらに、Slack通知と同時にアラームが鳴動するパトランプや、下図のメトリクスを常時表示するLED電光掲示板なども自作して設置していると聞いて、とても面白い取り組みだと思いました！

※なお数値は撮影用のダミーです

チャットツールなど補助的なツールはどのようにつかっているか？

チャットツールとしてSlackを使っているそうですが、チーム内外のコミュニケーションの中心になっているのはもちろんのこと、以下のようなChatOps的な使い方もしているそうです。

• デイリーのKPIの確認
• インフラにかかっているコストの通知
• マスターデータのバリデーションチェック結果通知
• プラットフォームのユーザーレビューのまとめを通知
• Twitterでのユーザーの反応のまとめを通知

ChatOpsで実現したいことをスプレッドシートにまとめて優先順位順に並べており、エンジニアの手が空いた時に優先度の高いものから順にChatOps化を進めているとのことでした。

また、コミュニケーション面でも、チーム外の人がチームのチャンネルに入ることを推奨しており、何かわからないことを質問するとそれについて詳しい人が回答してくれるような文化も定着しているそうです。

どのようなメトリクスを取得して、どのように改善をおこなっているのか？

NewRelicやrack-lineprofを使ってパフォーマンスに関するメトリクスを取得し、呼び出される頻度とその処理時間から優先順位を決めてパフォーマンスチューニングを行っているそうです。チューニングの方法としては、N＋１問題の解消、クエリのチューニング、キャッシュの利用など、やるべきことを着実に実施している印象を受けました。

また、nginxのアクセスログやユーザーの行動ログもFluentdのtd-agent経由ですべてGoogle BigQueryに集約し、RedashやTableauを使って可視化しているそうです。

最後に

最後に、インタビューを受けて頂いた皆さんから、今後目指していることについてお話ししてもらいました。

目指すところはどこか？

湯前さん

DevOpsに具体的な成功イメージがあるわけではなく、チームがDevもOpsも一丸となって実行している状態が理想と言えます。状況によってDevに重きをおいた方が良い場合、Opsに重きをおいた方が良い場合もあるので、チームとしてはいつでもそういった変化に対応できるように、日々どうやったら良いんだろうと考えながら推進していきたいと考えています。今のチームは状況状況に応じて変化しながら改善を継続しており、そういった意味で今の状態はかなり理想に近いと言えます。

野村さん

あまりDevOpsということを意識したことはないですが、クライアントエンジニアがJenkinsの対応をしてくれるなど、今でも当たり前に支え合ってやれているのではないかと考えています。ただ達成して終わりというものでもないので、今後もより良い状態を目指していきたいと思います。

坂尾さん

楽に楽しく運用開発したいという思いを持っています。常にHowを考え、実践していきたいです。例えば、先述した電光掲示板も楽しいから作ったということもありますし、今後はスマートスピーカー経由でのデプロイとかにもチャレンジしたいと考えています。

他にも、プルリクエストを送ったら自動的に環境が立ち上がるようにしたいとか、色々やりたいことがあるので、今後も楽に楽しくを意識していきたいです。

河野さん

今後はオペレーションのテーマが変わっていくと良いかと考えています。デプロイだけでオペレーションが手一杯になるのではなく、負荷の改善や不具合の回収、分析結果の可視化やあらゆることの自動化など、できることをどんどん実施していきたいです。

関山さん

チームごとに出てきたベストプラクティスをコードに落として、全社的にもっと共有できるようにしていきたいと考えています。それが実現できれば、坂尾さんが話していた楽な運用にもつながりますし、ゲームの面白さに直結できる部分により注力できると思います。

絶賛採用活動中

サーバーエンジニアは裁量を持って色々なことにチャレンジできる環境です。ゲームの開発を行ないたい、インフラを担当したい、オペレーションの改善をしたいなど、その場に応じてやりたいことを自由にできる環境なので、そういった変化を楽しめるような人にぜひ来てほしいとのことでした。

ご興味ある方はぜひ応募してみてください！

中途採用 | 株式会社アカツキ（Akatsuki Inc.)

まとめ

今回のインタビューで特に印象に残ったのは以下の3点です。

1. フィーチャーチームに振り切っている

アカツキではチーム構成をフィーチャーチームに振り切ることで、そのメリットを十分に活かせているのではないかと思います。この辺りについては、大規模開発向けのアジャイル開発フレームワークであるLeSSの影響が大きいと、湯前さんがお話しされていました。

2. チーム単位の独立性の担保と連携が素晴らしい

チーム内で良いと思うものは自由に採用できる、他のチームの良いものも自由に取り込める、その結果良いものは残り、良くないものは淘汰されるような流れができているのは素晴らしいと思いました。

3. DevOpsネイティブなマインド

インタビューを受けて頂いた皆さんが口を揃えて言っていたのが、DevOpsということ自体を意識したことがないということでした。DevOpsなんて意識せず、いかにより良いゲームの開発、運用ができるかを突き詰めた結果、サーバーエンジニアがインフラも当たり前に担当するような文化が定着しているのは、まさにDevOpsネイティブなマインドではないかと感じました。

最後にインタビューに答えて頂いた皆さんと、クラスメソッド山崎(左端)、藤村（右端）とで一緒に記念写真を撮らせてもらいました！

アカツキの皆様、インタビューのご協力、ありがとうございました。

ちょっと宣伝

クラスメソッドでは、変化の激しいビジネス環境において、お客様のビジネス競争力向上を目的とした DevOps導入支援サービスを提供しています。

ご興味ある方はぜひお問い合わせください！