山口 大祐

エンジニア

技術統括部 BAG 

KLab株式会社

ストア反映に振り回されない

アプリ更新

2
2018年5月 中途入社



前職でもソーシャルゲームのサーバーサイドを担当していました



Twitter: @_gutio_



山口 大祐

エンジニア

技術統括部 バックエンドアーキテクチャグループ

KLab株式会社

自己紹介

3
アプリを運営している皆さん

こんな経験ありませんか?

4
とあるアプリのアップデートメンテナンス

メンテナンスイン

↓

アップデートをリリース

↓

ストア反映されない!

↓

メンテナンス終了できない。。。

5
しかもこれ

同時多発的に起きるので。。。

6
阿鼻叫喚

Twitterなど

アプリA:メンテナンス延長です!

アプリB:メンテナンス延長です!

アプリC:メンテナンス延長です!



7
運営内部も阿鼻叫喚

プレス公開や版元など関係各所との調整



緊急の延長・お詫びなどお知らせ作成



イベント期間の調整







etc...

8
余談: 最近のAppStore反映遅延

つい先日(9/24,25)も、AppStoreで大規模な反映遅延が発生した
のは、記憶にあたらしいのではないでしょうか?







9
回避方法を確立しました

10


・どうやっているのか?

・何を気をつけているのか?



これらを簡単にご紹介します



11
メンテナンス中に新バージョンを公開する理由

アプリのバージョン混在を回避するためです



例えば

・他人のデータが見えることでのネタバレやバグ回避

  ランキングなどで新要素が旧バージョンに出てくる



・データ形式変更のメンテナンスがシンプル

  スキーマ変更などの作業をユーザーからのアクセスがない状態
で一斉にできる



12
メンテナンス

















メンテナンス中に新バージョンを公開し、メンテナンス終了までに
旧バージョンの受け入れを停止する





   14:00 18:00 



             ↓ ストア反映  ↓反映遅延 

一般的なアップデート

旧バージョン

新バージョン

13
ストアガイドライン(App Store)

引用

公開日:(略)選択されたすべてのストアフロントでAppが公開され
るまでに、最大24時間かかることがありますのでご了承ください。



つまり反映まで最大で24時間かかるルールになっている



ガイドラインページ:https://developer.apple.com/jp/app-store/review/guidelines/#after-you-submit





14
ストアルール上は仕方がない

15
じゃあどうするか?

16
新旧アプリが混在できればいい

17
新旧混在したアップデート(並行稼動

メンテ2
メンテ1
 並行稼働期間

バージョンアップのメンテナンスを分割し、並行稼動の準備(メンテ
1)、並行稼働期間、強制アップデートメンテナンス(メンテ2)という
形で運営する。



9/1 14:00-17:00 9/9 15:00 9/10 14:00-17:00

旧バージョン

新バージョン

18
新旧混在したアップデート(並行稼動

メンテ1:新バージョンが並行稼働するために最低限必要なRDB差
分などを設定します。 旧バージョンのアプリサーバーにも並行稼
働用の変更を設定。



9/1 14:00-17:00 9/9 15:00 9/10 14:00-17:00

メンテ2
メンテ1
 並行稼働期間

旧バージョン

新バージョン

19
新旧混在したアップデート(並行稼動

メンテ2
メンテ1
 並行稼働期間

並行稼働期間:メンテ2の24時間以上前にストアでアプリアップ
デートを公開します。並行稼働期間中に新バージョンのストア反映
が行われます。



9/1 14:00-17:00 9/9 15:00 9/10 14:00-17:00



旧バージョン

新バージョン

20
新旧混在したアップデート(並行稼動

メンテ2
メンテ1
 並行稼働期間

メンテ2:メンテナンスに入れて旧バージョンの受け入れを停止しま
す。新バージョンに対して追加で必要な初期化や、並行可動用の
ロジックを解除します。



9/1 14:00-17:00 9/9 15:00 9/10 14:00-17:00



旧バージョン

新バージョン

21
並行稼働期間を考慮した仕様策定

気をつけること

 ・新旧バージョンで有利不利を起こさない

 ・新機能一斉公開のインパクトを逃さない



「アクセサリー装備追加」を仮定して説明していきます

22
仮想新機能:アクセサリー装備

アクセサリーを装備して状態異常耐性などの補助を得る機能



基本仕様

 新規装備枠として追加する

 状態異常耐性やドロップ率UPなど補助効果を中心とする

 大ダメージを受けると確率でスタンするようになる



 入手方法

  装備のレアリティ値の合計で交換

  イベントの報酬

23
仮想新機能:アクセサリー装備

画面イメージ

24
新旧混在したアップデート(並行稼動

メンテ2
メンテ1
 並行稼働期間

この並行稼働期間中の新バージョンは、なにを気をつけるべきで
しょうか?



9/1 14:00-17:00 9/9 15:00 9/10 14:00-17:00



旧バージョン

新バージョン

25
並行稼動中に気をつけること

・新旧バージョンで有利不利を起こさない

  アクセサリー交換所を隠す

  スタン効果は並行稼動が終わってから有効化する

 

・新機能一斉公開のインパクトを逃さない

  アクセサリーの装備枠表示を隠す

  装備効果値のステータス表示を隠す



26
どのように実現するのか?

部署連携の流れ

企画連携の流れ

リリース前テストの流れ



実装上の工夫

マスタ管理

機能有効化管理マスタ



27
企画連携の流れ

新規企画(企画)

機能コンセプト

仕様設計

すり合わせ(企画・開発)

詳細設計

マスタデータ形式

スケジュール調整



並行稼働時の仕様

実装(開発)

並行稼動を

考慮した実装

並行稼働時の仕様もすり合わせ中に決めるのが大切です

機能実装後には内部のデータ形式変更は難しい

28
テスト連携の流れ

旧バージョン

既存ユーザー準備

並行稼働期間

旧バージョン

↕

新バージョン



バージョンを入れ替えながら遊
んでも問題がないこと

新バージョン

新機能テスト

新規ユーザー

複数端末所持やアカウント復旧時のストア状況次第では戻ること
もあるためテストケースが2倍、3倍になることも



29
実装上の工夫

アプリサーバー

RDB
マスタデータのバージョン間分離

/v1100/*







/v2000/*

イ
ン
タ
|
ネ
ッ
ト
v1.10.0
 旧APIプロセス

sqlite

v2.0.0
 新APIプロセス

sqlite

30
実装上の工夫

機能制限管理マスタデータ



テーブルイメージ: functional_restriction



機能キー 有効化日時
equip_accessory 2019-09-01 00:00
31
実装上の工夫

機能制限管理マスタデータ



ソースコードイメージ: 

if ( FunctionalRestriction.EquipAccessory.IsOpen() ) {

// UI を表示有効化したりするロジック

}





32
まとめ

強制アップデート前から新バージョンを並行稼働できれば、ストア
反映時間に振り回されずに強制アップデートが可能



並行稼働させるためには、メンテナンス回数の増加や、仕様の定
義・実装追加・テスト工数増加などがあります。

しかし、ストア反映に振り回されない予定通りの運営ができること
は非常に大きなメリットです。

また準備が増える点についても、手法の仕組み化により低減して
いっています。

33
ご清聴ありがとうございました


ストア反映に振り回されないアプリ更新