ID:23510さん

【プロジェクト概要（目的・人数・体制など）】 大規模イベント新規開発 サーバーサイドエンジニア ◾️サービス ブラウザゲームの名残を残すゲームで、インゲーム/アウトゲームの多くの処理はサーバーにもたせている。 それゆえ更新系のAPIが叩かれる数が非常に多い。 DBの負荷が高くなりがちであるため負荷対策が重要であり、また同一レコードへの更新が同時に走ることから排他制御を厳密に実装する必要がある。 ◾️人員 プロジェクト全体:50人 このイベントの開発体制 プランナー:1人 ネイティブエンジニア:2人 サーバーサイドエンジニア:2人 フロントエンジニア:1人 デザイナー:1人 ◾️イベント概要 チーム対抗で得点を競うイベント ミニゲームが3種類ほどあり、 ・ミニゲームを通してビンゴを開ける ・ドロップしたアイテムを組み合わせて使用する ことによってポイントを獲得。 ◾️開発規模 期間:3ヶ月 テーブル数:約40テーブル サーバーコード量:約2万行(自動生成を除く) 【プロジェクトにおける自身の役割】 サーバーサイドのリードエンジニア 一部バッチの実装を除き、 テーブル設計、実装、単体テスト を全て担当 【当時の背景/抱えていた課題等】 同一のレコードを多数のユーザーが同時に更新する処理が頻繁に行われることにより ・負荷軽減 ・排他制御 が重要であり課題が多く発生した。 負荷軽減のためにユーザーデータはmemcachedを使っていたが、排他制御の処理のタイミングによりmemcachedとDBのデータ不整合が発生するケースが多発した。 また、ほぼ同時にAPIが叩かれた際に後に叩かれた方のAPIの処理において、先に叩かれたAPIの更新結果ではなく更新前の値を参照して処理をしてしまう不具合が発生した。 【課題に対して自身が発揮したバリュー及び成果】 ・多数のユーザーが同時更新するテーブルはmemcachedを使わず直接DBを参照するように変更 memcachedを使うと参照/更新タイミングを厳密に管理する必要が発生するため、実装が複雑になってしまった。 他のエンジニアが今後触る際不具合になりうる可能性も考えて、実装をシンプルにするために直接DBを参照する設計に変更した。 その代わりユーザー自身しか更新しないテーブルはmemcachedを使用して負荷の軽減をはかった。 ・処理冒頭でselect for updateで更新で値を取得することで、タイミングによって参照データが変わる問題を潰した 処理の中で取得したタイミングを考慮しなくて済むよう、冒頭でselect for updateでの取得することにした。 これにより同時に処理が走った場合でも、先に処理された方が更新した値を確実に取得できるため、排他制御によるデータ不整合は起きない。 その分ロック待ちの時間が長くなりユーザー体感が悪くなる可能性があるため、更新処理は出来る限りチューニングして短くなるよう実装した。

※エンジニアリーダー、開発ディレクターは別セクションに譲り、ここでは技術的挑戦で一番大きかったものを紹介 これ以外にも大型開発を多数実施。 【プロジェクト概要（目的・人数・体制など）】 最大25 vs 25の計50人で戦うとGvGがメインのカードゲーム。 ヘビーユーザー同士(参加人数、行動回数が多いチーム同士)の対決では、レイテンシがかなり高くプレイ体感が悪いことが発覚し、調査及びレイテンシ改善を行った。 その結果、最大約60%のレイテンシ削減に至った。 【プロジェクトにおける自身の役割】 原因の調査、分析 チューニングのための実装 評価 【解決までの流れ】 ■調査 ○New Relicでボトルネックの調査 本番のAPIサーバーに仕込んでいるNew Relicをもとに、レイテンシが高い時の各処理の所要時間を計測。 レイテンシが高い時の所要時間99%はロック待ちだった。 ロック待ち時間が肥大化したことによって、行動数の多いGvGではレスポンス速度が悪化していたことが推測された。 ○待ち時間行列モデル(M/M/1)による検証 上記ロック待ちの仕組みの置いて、ロック中の処理時間と平均レイテンシの関係は待ち時間行列のM/M/1モデルを適用して検証した。 待ち時間行列のM/M/1モデルとは、1つしかない窓口にお客がランダムに到着した場合の、 ・お客の到着する頻度 ・窓口での処理時間 を元に、平均の待ち時間を算出するモデル。 M/M/1モデルをGvGのロック待ちの仕組みに適用すると 単位時間当たりに到着するgvgのリクエスト数:λ 単位時間当たりにサーバーが処理するリクエスト数:μ として、平均のレイテンシ(W)は W = 1/ (μ - λ) で計算できる。 これをグラフ化し数値検証したところ、 ロック中の処理時間を20%改善すればレイテンシは最大70%改善することが分かった。 そのため ・ロック中に行う処理を減らす ・ロック中の処理を高速化する を行うことにした。 ■取り組んだチューニング ○ロック中に行う処理を減らす 必ずしもロックが必要ない処理(排他制御をしなかったとしてもデータの整合性が崩れない)のみで構成されるAPIを洗い出し、ロック処理を削減した。 インゲームにおけるリクエスト数の25%を占めるAPIのロック処理を削除することができた。 ○ロック待ちの間に、ロックが不要な計算を始める ロックを取得した後に各種データを取得・計算をすると、どうしてもロック中の処理は長くなる。 ロックを取得した前後で計算結果に差がない処理を抽出し、ロック取得前に処理を行うようリファクタした。 ○アベイラビリティゾーンの統一（インフラ） もともとAPIサーバー、Redis、MySQL全てアベイラティビティゾーンを半分つずつに分けて2つのアベイラビリティゾーンに配置していた。 APIサーバーごとのレイテンシを確認すると、存在するアベイラビリティゾーンによってレイテンシにばらつきが確認された。 それぞれのアベイラビリティゾーンに存在するAPIサーバーにNew Relicを入れて検証したところ、逆ゾーンに存在するRedis、MySQLへアクセスする際レイテンシが高いことが分かった。 これを受けて、API、Redis、MySQLのアベイラティビティゾーンを全て片側に寄せた。 各MySQLのレプリカを全て逆のアベイラティビティゾーンにおくことで、データの信頼性は担保した。 この対応でGvGのletencyが改善しただけではなく、ゲーム全体のレイテンシが平均10%程度改善したり、一部バッチの処理時間が1/3になったりなど、ゲーム全体として大幅な改善が見られた。 ○テーブルのindexの見直し、不要レコードの削除 不要に貼られたindexが多かったため、精査の上削除した。 更新処理におけるindexの更新時間を少しでも短くするために行った。 ○Auroraの導入、統合（インフラ） 過去の負荷対策によって、4台に水平分割していたGvGのDBを1台のAuroraに集約した。 書き込み処理が多かったためAuroraと相性が良く、同じ費用で更に処理性能の高いものに変更できた。 同じクエリのレイテンシを比較しても、Aurora導入前より改善されていた。 ○遅い処理の探し出し、チューニング 上記のような抜本的な改修と合わせて地道なリファクタリングも行った。 長年の運用開発が積み重なった結果、効率の悪い検索ロジックやや不要なDB参照をしている箇所がいくつか見受けられたため、 計測→リファクタリング→計測を繰り返し、を改善を行った。

# ①リリース直前で負荷試験 リリース直前で負荷試験の進行に問題があることが発覚し、状況を改善すべく役員に呼ばれ参画。 今までのプロジェクトの負荷試験経験をもとに、 - リリースまでに担保すべき負荷試験のパターン(スパイク試験、長時間試験etc)の整理 - サービスが担保すべき負荷試験の数値の策定 - 負荷試験実施スケジュールの策定 - 有識者を呼んでの進捗/試験結果の精査 を推進し、リリースまでに負荷試験を間に合わせた。 # リリース後の不具合/障害対応 サービス運用経験のあるメンバーが少なかったため、障害対応や不具合の調査の取りまとめ及び実行の推進を行なった。 # リリース後の大型機能開発のリード 開発期間2ヶ月、バックエンド3人体制の大型新機能追加においてテックリードを担当。 技術的設計要素: - 多人数系による厳密な排他制御(メイン実装担当) - テーブル数:20 リリースが間に合わない状況から、不具合の出にくい設計と工数が膨らむ要件のプランナーとの調整を行い、無事リリースに間に合わせ、不具合がほぼ起きなかった。 # エンジニアリングマネージャー就任 それまでのエンジニアリングマネージャーが異動になったため、エンジニアリングマネージャーに就任。 それまで弱かったプランナー/事業責任者との連携を強め、よりエンジニアチームが事業にコミット出来る状態にしていった。

※リリース後に行っている業務は上2プロジェクトと似ているのでここでは割愛。 下記はリリース前に行なった一番大きな対応の紹介 リリース後にカスタマーサポートのお問い合わせ調査で - ユーザー行動ログの調査 - ユーザー状態確認 が必須となる。 それまでリリースされたタイトルではバックエンドエンジニアが調査を担当することも多かったが、リリース後のユーザー規模的にバックエンドエンジニアでは対応不可能であることが見越されていた。 非エンジニアでの調査が出来る環境と継続な調査環境改善を実現すべく、 - 調査ツールに必要な内容の要件定義 - バックエンドの実装とログ基盤を鑑みたカスタマーサポート用ログの設計/実装 - redashを用いた調査環境の整備 - 調査用クエリの実装 - CSエンジニア(クエリ調査)の採用と育成 を一貫して行なった。 結果リリース後カスタマーサポートチームだけでお問い合わせ調査をほぼ裁くことができ、その後追加が必要になったクエリはCSエンジニアで完結出来るようになった。 バックエンドエンジニアは開発に集中できる環境になり、チーム全体の生産性向上につながった。