コンテンツデザイン部の金井と申します。今回は、分かり易い説明をする為に心掛けている事を書いていきます。

結論

読む人のリソースを少なくするように心掛ける。
その為に、

• 結論から先に言う
  • 何を要求しているのかが一目で分かる
  • 読み返す際も、全てを読む必要がなくなる
• 長文で纏めず、要点を切り分けて説明する
  • 文章を読者に噛み砕かせる手間を極力省く
  • 文章としての体は重視せずに、箇条書きや強調を駆使する
  • フォーマットがあれば、それに従えば知識などなくてもある程度分かりやすく記述出来る
• 専門用語は必要に応じて噛み砕く
  • 読者が何に長けていて、何に疎いのかを想像する

悪い例

お疲れ様です。
先日より発生している、お勧めユーザーを検索するAPIで長い時間が掛かってしまう問題に関してですが、ユーザーデータの量が想定より多く、またそれに対してデータベースのインデックスが適切に張られていなかった事が原因でした。
また、現在業者によるリセマラアカウントが日々増加している事も鑑みると、インデックスを適切に張り直しても現在の仕様ではその内また時間が掛かるようになってしまう事が想定される為、お勧めユーザーの検索ロジックの変更をしたいと考えています。
現状のお勧めユーザー検索ロジックの問題となっている部分は、3日以内にログインしている、という条件が現状のDAUから考慮すると多過ぎる点と、また、その他の絞り込む条件もその莫大なユーザー数からの抽出には時間が掛かってしまう点です。
その為、3日以内にログインしている、という条件を、直近にログインをしたユーザーの指定数に変更し、その中から抽出するという形にしたいです。
これに変更しても直近に遊んでいる人からお勧めユーザーを参照したいという要望は変わらないまま、DAUに関わらず参照量は一定になりますので、APIで掛かる時間も一定になるからです。欠点を挙げるとするのならば、ゲームが遊ばれなくなる時間帯などには同じユーザーが参照されてしまう可能性が高いという事がありますが、現状の盛況振りから考えるとこれから先も基本無く、またあったとしてもそう強い問題でもないと思いますので、一考願いたいです。
よろしくお願いします。

どこが悪いのか？

順序立てて説明していますが、読むのに疲れますし、最後まで読まないと何をどうしたいのか分かりません。
と言うより……読もうと思えないですよね、これ。
まあ……この文章を総括してしまえば、エンジニアの自己満足です。

エンジニアは問題の原因究明、解決に100%のエネルギーを注いで対応しているかもしれませんが、
プランナーやプロジェクトマネージャー、ディレクターといった、仕様を考える人、最終的に判断を下す人達はもっと色々な事を同時並行でやっていたりします。
要するに、上に立つ人はエンジニアと同じだけのエネルギーを原因解決だけに注いでいられない訳です。
エンジニアから欲しいのは主に、どのような問題が発生し、その解決に必要な事柄は何なのか？　という事です。
そういう事を留意した上で、タスクが多い人のリソースをエンジニアと同等レベルに食わせない事を考えましょう。
その為にすべき事としては、以下になります。

• 結論から先に言う
• 要点を分かりやすくする
• 専門用語は必要に応じて噛み砕く

現状の個人として強く意識している考えなので、もっと考えるべき事柄や無意識に行っている事柄もあると思いますが、ひとまずそれぞれに対して詳細を書いていこうと思います。

結論から先に言う

先ほども述べた、最後まで読まないと何をどうしたいのか分からないという事の何が問題かと言えば、

• 最後まで読む必要がある……言いたい事を理解するのに時間が掛かるし、要点を掴むのにも文章の全てを咀嚼する必要がある
• 読み返す時も、最初に読む時と同程度リソースを要求する

という点です。
なので、まずは言いたい事を先に言ってしまいましょう。
何の為にこの文章は書かれたものなのか？
最終的に何を言いたいのか？
それを最初に提示するだけでも、ぐっと読者のリソースは減ります。
例をざっくり纏めてしまうと、

お勧めユーザー検索に時間が掛かっている問題の解決の為に、検索ロジックそのものを変更したい
“3日以内にログインしている”という条件を”直近にログインをしたユーザーの指定数”に変更したい

という事になるので、まずそれを提示すべきですね。

要点を分かりやすくする

悪い例の文章は、要点が文章の中に紛れ込んでいる為、実際に読んでみないと結論に対して、

• 何の目的でそれをしたいのか？
• それをするメリット、デメリットは何なのか？

と言った事が分かりません。
読者に国語のテストなんてさせるな、って話ですね。
評論文とか書く訳じゃないですし、最初から解答を明示しておけば良いのです。
そういう分かり易さの為には、必ずしも文章の体をしている必要はありません。
必要に応じて箇条書きや強調も使っていきましょう。
それで、要点を纏めてそれを分かりやすくするとなると、フォーマット化してしまうのも良いでしょう。
それだけで誰でも、何も知らなくても、分かりやすいように報告出来るようになるでしょうから。
ただ、フォーマット化に頼り過ぎると報告したい事によってはイマイチ収まりが悪かったりする事もあるので、そこ辺りは柔軟に。
例を要点で分割してみると、

問題:
お勧めユーザー検索で時間が掛かっている

原因:
SV想定より多くのユーザーが遊んでいる
SVの検索処理が最適化されていない
仕様におけるユーザーの参照量が多過ぎる

対応:
ロジックそのものを変更する

対応詳細:
3日以内にログインしているユーザーから対象を抽出する
を、
直近にログインをしたユーザーの指定数
にする。
理由としては以下。
・その仕様が一番冗長且つ時間の掛かる要因
・SVの最適化不足もあるが、DAUの観点からしても参照するユーザー数が多過ぎる
・直近に遊んでいるという条件を崩さない
・上記の変更を行えば、DAUに関わらず参照するユーザー数が一定となりレスポンスがいつでも安定する
また、これに変更するデメリットとして、
プレイ人口が減ると同じユーザーが選出される可能性がある
が、
現状のDAUを考えると殆ど発生しない
と考える為、問題ないと思う。

専門用語は必要に応じて噛み砕く

悪い例において、データベースのインデックスが適切に張られていなかったと説明していますが、
ぶっちゃけプランナーとかになると、エンジニアを経験していたり、DBに対する理解が無かったりしないと、そんな事知らんがなというだけで終わります。
どういう人に読まれるかという事を考えて、専門用語は適切に言い換えたり、抽象化したりしましょう。
この例を書き換えるとすると、
想定以上のユーザー数に対して検索処理に時間が掛かるようになってしまった
データベースの検索の効率化が考慮不足だった
とかで良いかと思います。
他にも、APIだとかDAUだとかリセマラだとか、これらに関しては同じゲームを開発している人達なら基本通じるでしょうが、専門用語には違いないので、ゲーム開発者だったりエンジニア以外に何か説明をする際は、噛み砕いておいたり、注釈を隅に書いておいた方が良いかもしれません。

例を書き換えてみる

フォーマットがあるなら、それに記して出力して終わる……というか、前述の要点を分かりやすくするで書いた形でいいと思うのですが、
先出しとして、チャットツールとかに投げる形を想定して、書き直してみましょうか。

お疲れ様です。
先日より発生している、お勧めユーザー検索で時間が掛かる問題に関して、解決の為に一部仕様変更を願いたいです。
仕様変更したい部分は、検索条件の
3日以内にログインしているユーザーから対象を抽出する
を、
直近にログインをしたユーザーの指定数
への変更です。
詳細を以下に記します。

まず、そもそもの原因に関してですが、
・SV想定より多くのユーザーが遊んでいる
・SVの最適化不足
・ユーザー抽出条件の、3日以内にログインしているユーザーが多過ぎる
が主な問題でした。
また、SVの最適化をしたところで、3日以内にログインしているユーザーが余りにも多い為、それだけでは解決出来ないという結論に至りました。

その対応案として、
3日以内にログインしているユーザー
を
直近にログインをしたユーザーの指定数
に変更したいと考えました。
理由としては、
"お勧めユーザーには、直近に遊んでいるユーザーから抽出したい"という要望を崩さない
ままに、
DAUに関わらず参照するユーザー数が一定となりレスポンスがいつでも安定するようになる
からです。
また、これに変えるデメリットとしては、
プレイ人口が減ると同じユーザーが選出される可能性がある
という事が考えられますが、
現状のDAUを考えると殆ど発生しない
と思います。

ご一考願えればと思います。
よろしくお願いします。

……まだまだ分かり易く出来そうだなー。

コンテンツデザイン部の金井と申します。今回はLocustとFargateを使ってゲームアプリケーションの負荷試験をした話をしていこうと思います。

背景

結構前の話になりますが、自分はとあるゲームアプリケーションの開発・運営に携わっていました。
開発・運営に携わると言う事は、リリースにも携わるという事で、その点において自分は負荷試験を主に担当していました。

負荷試験ツールに何故Locustを使ったのか

負荷試験に関しては、別のプロジェクトから引き継いだサーバーソースではJMeterを使っていたのですが、JMeterは

• 専用のGUIでの負荷試験シナリオ作成がややこしく、学習コストも高い事
• 保存されるソースがXML形式であり、gitでのバージョン管理に向かない事
• 負荷試験を行う際も面倒臭い点が多い事

という難点が他にも色々あるのに対し、Locustは

• コードベースでの負荷試験シナリオ作成であり、学習コストは低く、またそれ故にgitでのバージョン管理に向く
• 負荷試験の実行がJMeterに比べると単純で分かり易い

とメリットが多く、また他プロジェクトでも使用実績があった為、Locustに乗り換える事にしました(そして100近いAPIの負荷試験シナリオを1から書き直す事になりました)。

負荷試験サーバーに何故Fargateを使ったのか

そもそもFargateが何なのかを説明すると、AWSにおける、コンテナ向けのサーバーレスコンピューティングリソースです。
実態の無いサーバー、とでも言えばいいでしょうか。
実態……ホストマシンの存在が隠されている為、IPアドレスをこちらで決められなかったり、EC2のようにssh接続して中身を見たりする事は基本出来ない(方法が無い訳では無いみたいだけど)という欠点がありますが、
コンテナベースで立ち上げる為、OSなどを考慮する必要もなく、より手軽な使い方が可能です。
また負荷試験に対しては、インスタンスの増減に必要な設定がEC2よりも少なく、容易であるという点より、

• 負荷試験の規模に関わらず準備の手間が殆ど変わらない
• コストも鑑みて頻繁に起動と削除を繰り返す必要がある為、手軽であるのは強い

というメリットがありました。
それに元々サーバーインフラはAWSで立てていましたし。

負荷掛け環境構築まで

ネット上に先駆者が沢山居ましたので、そこ辺りで色々調べていけば、そこまで苦労する事は……一つだけありましたね。
AWSのPowerUserAccess権限ではECSでのタスク定義やクラスター定義の作成、編集が出来ないという点です。
務め人で、しっかり権限が個々に割り当てられているからこそ起きる問題ですね。最小権限の原則ってヤツです。
そして、AWSはそういう時にコンソール上で、これこれこういう理由で作成出来ませんでしたって通知してくれない場合が多くて(セキュリティ上の都合もあるんでしょうけど)、もっと上の権限を割り当てられていた先輩に聞いてみたら、俺は出来るけど？　何かミスってない？　と返されたりして。
同じ画面で全く同じ操作をして自分だけ出来ないと証明して、やーっと気付きました。
コロナでリモート勤務だったのもあって、1~2日は潰した気がする。

負荷掛けられサーバー環境構築まで

プランナーに本番想定のマスタデータを貰って、それを本番に寄せた開発環境の1環境に反映しておしまいです。
また本番に寄せたと言っても、負荷試験のシナリオの都合上、例えば以下の点で異なってくる部分なども出てくるので、そういうのはきちんと纏めておきましょう。

• 通信の暗号化は本番と同等か？
• ミドルウェアはきちんと全て動作させる仕組みになっているか(BigQueryなどにデータを入れるところまできちんと出来るようにしてるか)？
• 課金処理は途中で飛ばしたりしていないか？

そうでないと、後で痛い目を見る事になったりします。

後、ちゃんと監視ツールも設定しましょう。
NewRelic, Datadogやら, それからAWSを使っているのならばCloudWatchで、APIサーバー、それからDBやMemcachedなど各種ミドルウェアのCPU使用率、メモリ使用率、その他諸々を可視化出来るようにしておきましょう。

本番想定の負荷試験を実行するまで

いきなり本番想定で流す、という事はしません。ちゃんと、API全般が基本問題ないかを確認した上で、想定される本番と状況を出来るだけ近付けてやります。

小規模に全てのAPIを流すシナリオを動かして重いAPIがないかを確認する

ここで重いAPIがあった場合は、根本的にソースが重いのでちゃんと直しましょう。

リセマラを想定したシナリオを動かして問題ないかを確認する

要するに、リリース直後にチュートリアル周りを何度も重点的に走らされても問題ないか、という確認ですね。
後、本番想定にする為にDBにユーザーデータを蓄えないといけないのですが、
スクリプトを組んでユーザーデータを大量生産するとかも手としてはありますが、リセマラのシナリオを長時間流していればそれと同等の代物が出来上がって来るので、その方が調査も兼ねられて良いのではないかと思います。

中規模に全てのAPIを流すシナリオを動かして重いAPIがないかを確認する

ユーザーデータが作られた後に、再び全てのAPIを通る負荷試験を流してみましょう。
ここで重いAPIがあった場合は、DBのインデックスが正常に張られてないのが主な原因です。ちゃんと張り直しましょう。

ここまでやれば、サーバーソースの基本的な部分に関しては問題ないと言えるでしょう。

本番想定の負荷試験

ここまでやって、本番想定の負荷試験を行います。
本番想定の負荷を掛けても問題ないか、という他に、

• 長時間に渡って負荷を掛け続けて問題ないか
• 本番想定以上の負荷を掛けてサーバーは落ちないか(DBなどの拡張が簡単に効かないミドルウェアの性能限界はどこか？)
  唐突に急激なリクエスト数が来てもサーバーは落ちないか(AutoScalingは効いてくれるか？)
• デプロイなどを挟んでもサーバーは正常に動くか

といった事等を調べていきます。
本番で起こり得るような事象を前もって列挙し、それらに対して問題ないか、また、この構成の限界はどこにあるのか、そういう点を調査していく訳ですね。

ここまで来たら負荷試験のソースもしっかり整ってますし、後はリクエスト数を変えたりして動かしていくだけなので、負荷試験を行う事自体には苦労はしないでしょう。
ただ……ここからで何か起きたりした場合は、苦労する事になりがちです。
原因がイマイチ見えにくいところにあったり、どこも正常なはずなのに動いてくれなかったり、エラーレートが唐突に爆上がりしたり……。
粘り強くやっていきましょう。はい。それしかないです。

そして、10000RPSの負荷試験は、本番想定以上の負荷を掛けてサーバーは落ちないかという負荷試験で達成しました。

え？　そんな負荷掛けて、どれだけのクラウド料金が掛かったのかって？
うーん……自分の給料の半年分くらいかなあ。
ちゃんと負荷試験やってない時はこまめにサーバー落としたりしても、その位行っちゃいましたね。
まあ、その甲斐あって、リリース後にサーバーが落ちたりする事はなく、何秒も掛かるようなAPIは……ちょっと出てきちゃったけど、即刻メンテに入れなければいけないレベルではなかったです。

アピリッツ コンテンツデザイン部の金井と申します。今回は膨大なレコード数を保有するテーブルからのランダム抽出に関して書いていきます。

結論

元々ある莫大なテーブルから愚直にクエリを叩くのではなくて、別にテーブルを作ってそこから効率的に参照するようにすれば良いと思います。

良くある仕様相談

プランナー「ゲーム始めたてのユーザーにもフレンド機能を積極的に活用して欲しいから、以下の条件でお勧めユーザーが出るようにしてくれない？」

• チュートリアル完了済み
• フレンドでない
• BANユーザーでない
• フレンド数がMAXでない
• 3日以内にログインしている
• ユーザーとのプレイヤーランクの差が-5~+5以内
• お勧めユーザーとして出る事を許容している

サーバーエンジニア「りょーかい。(クエリ叩いて該当するユーザーを検索して指定数絞り込むだけだから……うん、そんな時間掛からないかな)1~2営業日で実装できますね」

はい、落とし穴です。

愚直に実装した結果

例えば、以下のように愚直にクエリを叩くような実装にしたら、

FRIEND_COUNT_MAX = 30
RECOMMEND_SEARCH_DATE_RANGE = 3
RECOMMEND_SEARCH_RANK_RANGE = 5
RECOMMEND_SEARCH_LIMIT_COUNT = 100
RECOMMEND_SEARCH_SAMPLE_COUNT = 30
def search_recommend_users(time = Time.current)
  ban_user_ids = BannedUser.current(time).pluck(:user_id)
  friend_user_ids = Friend.where(status: Friend.status_value(:friend), user_id: self.id)
  except_user_ids = ban_user_ids | friend_user_ids

  recommend_users =
    User \
    .where("? < last_login_at", time - RECOMMEND_SEARCH_DATE_RANGE.day) \
    .where(rank: (self.rank - RECOMMEND_SEARCH_RANK_RANGE)..(self.rank + RECOMMEND_SEARCH_RANK_RANGE)) \
    .where.not(id: except_user_ids) \
    .where(is_allow_recommend_search: true, is_tutorial_finished: true) \
    .order(:last_login_at) \
    .limit(RECOMMEND_SEARCH_LIMIT_COUNT)
    .to_a

  friend_counts = 
    Friend \
    .where(status: Friend.status_value(:friend), user_id: recommend_users.pluck(:user_id)) \
    .group(:user_id).count
  recommend_users.select! { |user| friend_counts[user.id].to_i < MAX_FRIEND_COUNT }
  recommend_users.sample(RECOMMEND_SEARCH_SAMPLE_COUNT)
end

幾らインデックスをきちんと張ってようとも、QA検証まで恙無く通っても、負荷試験で莫大なユーザー数を登録するような試験を行うと、死ぬと思います。

もし、そのままリリースしてしまったら、その機能で数秒待たされるとか、そんな事が頻発したりだとか……。
原因としては、上記の仕様においてはユーザーを一意に絞り込めるような条件が存在しないので、ユーザーが増えれば増えるほど、クエリの負荷が増大していく訳ですね。

じゃあ、どうしたら良いんでしょうか。
個人としての現状のベストとしては、以下です。

改善への考察

まず、現状の実装の問題点や、仕様でもうちょっと絞り込めるようにして良いような部分を見つけましょう。

現状の実装の問題点としては、愚直にクエリ検索をする一番のデメリットは、ゲームが繁盛するに連れて検索量が莫大になっていってしまう、って事ですね。

また、仕様を見返してみてみると、一番優先度の低いと言うか、もっと厳しくして良いものが一つありますね。

• 3日以内にログインしている

繁盛しているゲームならこれを1時間以内、とかにしても良いと思いますし、それで検索量も一気に減って解決！　とかなると思うんですけど、繁盛していないゲームになると、深夜にアクセスされた時には、工夫しないと何も検索結果として出てこないとか有り得そうだったり……。

まあ、この2点から考えると、最後に何らかのアクションを起こしたユーザー群から絞り込む、で良いんじゃない？　って発想が浮かんできました。
要するに、別にお勧めユーザー検索用のテーブルを作り、そこにトリガーとなるアクションを起こしたユーザーを入れて、その末尾のレコード数十件を引っ張ってくるって形ですね。
そういう形ならば、幾らユーザーが増えようとも参照量は一定ですし、時間帯で検索に引っ掛からなくなるような不安もなくなります。

ただ……この手法にも欠点がない事もなくて。
ゲームが過疎ってしまうと、同じユーザーばっかり抽選されるようになります。
この手法はお勧めユーザー抽選以外でも、アクティブなデータからの効率的な参照方法として使えると思いますが、ゲームそのものが過疎らなくても、その機能が余り使われなくなるとか、そういう要因でこの事象が発生してしまう可能性はぼちぼちあります。

そういう点も留意した上で、プランナーに今のままの仕様じゃサーバーが死ぬ事と、これこれこういう理由で、ここの仕様をこう変えて貰いたいという事を伝えて、首を縦に振って貰って、改修しましょう(振ってくれない？　……その時は青い空の広さをぼんやりと眺めましょう)。

書き換えたら多分こんな感じのソースになる

FRIEND_COUNT_MAX = 30
RECOMMEND_SEARCH_RANK_RANGE = 5
RECOMMEND_SEARCH_LIMIT_COUNT = 100
RECOMMEND_SEARCH_SAMPLE_COUNT = 30

# フレンド数が増減した、お勧めユーザーランクが上下した、ログインした、などの各種トリガーの度に呼び出す
def check_user_recommend
  # lastで参照する為、古いデータは削除する
  UserRecommend.where(user_id: self.id).delete_all

  return unless self.friends.where(status: Friend.status_value(:friend)).count < FRIEND_COUNT_MAX
  return unless self.is_allow_recommend_search
  return unless self.is_tutorial_finished

  UserRecommend.create!(
    user_id: self.id,
    user_rank: self.rank,
    ...
  )
  end
end

def search_recommend_users(time = Time.current)
  ban_user_ids = BannedUser.current(time).pluck(:user_id)
  friend_user_ids = Friend.where(status: Friend.status_value(:friend), user_id: self.id)
  except_user_ids = ban_user_ids | friend_user_ids
  rank_range = (self.rank - RECOMMEND_SEARCH_RANK_RANGE)..(self.rank + RECOMMEND_SEARCH_RANK_RANGE)

  recommends =
    UserRecommend \
    .where(user_rank: rank_range) \
    .where.not(user_id: except_user_ids) \
    .last(RECOMMEND_SEARCH_LIMIT_COUNT)

  User.where(recommends.sample(RECOMMEND_SEARCH_SAMPLE_COUNT).pluck(:user_id))
end

対象ユーザーを抽出する部分がとってもスッキリしましたね！

没案

ユーザー単位に1~100くらいでランダムな数字を振ったりして、その値を参照される度にランダムに指定し、数値が合致するユーザーだけを抽出する。
=> QA検証的にも分かりづらいし、本番で不具合が起きても検証出来ない

検索を全ユーザーDBからではなく、自分の属するユーザーDBのみからにする。
=> ……妥協案で敗北した気分になるから嫌だ。

アピリッツ コンテンツデザイン部の金井と申します。前回から一年半以上が経過し、自らが携わっているゲームも無事リリースまでこぎつけ、そして暫くの時間が経過しました。
その中で、こういう改修はすべきではなかったなー、という事を書いていこうと思います。

結論

状態の増える改善は改悪！

過程

引き継いだソースは、基本的に全てのAPIでミッションの受注処理が含まれていました。
その受注処理は煩雑であり、その処理が入っているが為に、許容出来るものだとは言え、全体的にレスポンスの遅延が発生していました。

私はそれを嫌い、ログインの段階で必ず通るAPIにのみ、ミッションの受注処理を仕込むように変更しました。

すると、日付変更、データ更新などの、必ずログインに戻されるタイミング以外でのミッション……例えば、イベント開始と同時に有効にしたいミッションの受注が不可能になりました。

それへの解決の為に、私は、未来のミッションを予め受注しておく、という処理を組み込みました。

ま、多少問題もあったものの、負荷試験も大丈夫だったし、受注処理も1APIでのみ対応になってソースコード的にもスッキリ！
リリース後もミッション関連でバグは起きて……しまった。

問題

さて……これの何がいけなかったでしょうか。
私はリリース後までこの改修で発生してしまう問題に気付けませんでした。
また、これが引き起こす特殊な事象に関しては、運用になってからやっと気付けるような代物で、リリース前のQAでも素通りしてしまいました。

また、上記の改修が顕在化した要因として以下の事柄があります。

• この頃のソーシャルゲームでは、ミッションを達成した瞬間、通知がゲームの端に飛んでくるような仕組みが良くあると思うのですが、それが一つ。
• そして、未来のミッションを予め受注しておく、という処理を組み込んだとは言え、そのプロセスは基本的な受注処理と同じ部分を通っているという事が一つ。

…………。
はい。
例えば、初心者の為のイベントミッションで、累計*回**をする、みたいなミッションがあったとします。
ここで重要なのは、開始してからのカウントではなくこれまでの累計という事です。
初心者でもゲームを遊んでいれば簡単に達成出来るようなミッションで、既に長時間遊んでいれば即時達成しているようなミッションです。
要するに、こういうミッションでは予め受注して即時達成するという事が起きる訳ですね。
そこで私は、考慮漏れを引き起こしました。

即時達成したミッションの通知が、ミッション開始前の時刻なのにユーザーに飛んでしまったんですね。

ユーザーからしたら、何か通知飛んできたけど、ミッション一覧にそんなミッションないし、受け取る事も出来ないしで、訳が分かりませんね！
他にも一定の操作をしていると、一部のミッションが達成不可能になったりだとか、そういう事まで起きてしまい。
後から補填の為のバッチ処理を組み込んだりする必要が出て来ました。
まあ……後から補填処理を組み込んで修正出来るくらいの代物で、本当に大事には至らなかったのですが。それでも不具合としては結構大きめな部類で、結構凹みました。

原因

改修によって、状態が増える、それに対する影響などを考慮出来ていなかった事ですね。
今回の未来のミッションを受注するという改修に関して言えば、

• 未来のミッションを受注しておらず、まだ有効でもない時間
• 未来のミッションを受注しており、まだ有効でない時間
• 未来のミッションを受注しており、有効となっている時間

という3つの状態が新規に発生してしまった訳です。そして、それらへの考慮が足りなかった。
いや、そもそも、そんな新たに発生した状態を考慮する必要が出てくるような改修はするべきではなかった。
修正するにせよ、その未来受注をそのままにして対応しようとした場合、

• 予め受注、即時達成したミッションを開始時刻が過ぎた直後のAPIで達成通知を送る必要がある
• 累計カウントのミッションの場合、予め受注し、そして有効でない時間に進捗した分への考慮

等々、とてもじゃないけれど、やってられないような、やったとしてもエンバグを発生させそうな複雑な処理になりそうですし。

対応

結局、未来のミッションを予め受注するという処理をやめました。
詳しくは書きませんが、全てのAPIにミッション受注処理を入れ直すというような汚い事はせず、それだけはしないようにする、という対応が出来たので。
その修正を反映して、無事に本番で機能している事も確認出来て、やーっと、ほっと出来ました。

反省

最初にも書いた通り、リファクタリングにおいては、状態の増える改修はすべきではない、という事ですね。
良かれと思ってやった事が、実は改悪だった。そんな事を今回、自分はやらかしました。
なので、思いついたような実装方法や改修が、どんなに素晴らしいものに見えても、着手する前に距離を取って考えてみる時間が必要だと実感しました。
特にそれがシステムの根幹に位置するものに関しては、寝かせて翌日に見直してみたりだとか、どんなに一任されている事柄だろうと他者の目もしっかりと入れたりだとか、そういう事をした上で着手に入る必要がある。
そう、実感しました。

また、後から色々考えた結果、今回に関しての最善策は、

全てのAPIにミッション受注処理を入れる事は変えずに、受注する必要があるかどうかを軽い処理で判定出来るようにする。

という所感です。
それがクライアントもサーバーも、多少コードとしては煩雑でも一番安心出来る、簡潔な受注処理になりそうだと思っています。