Testingツールのインフラアーキテクチャ設計を行いました。その時の学びをまとめていきます。Flagを用いてA/Bテストできれば良いのですが、以下は守る必要がありました。僕達の最終的なアウトプットはこのようになりました。書いてありますが、大事なのは以下の2つです。service(構成図右下)にpostする。上図の通り、とりあえずUIを表示し非同期で取得し次回起動時に反映するという方式をとりました。することで、「UIの表示速度に影響しない」という要件を満たします。デメリットもあります。Flag取得までにラグがあることです。Flagを切り替えたい時に、二回のアプリ起動が必要になります。そのためアプローチとして以下の措置をとりました。プッシュ通知でアップデートフラグをローカルに立てるクライアントが次回アクティブになった時に強制的に反映(ロードが生じる)わざわざローカルにフラグを立てるのは、プッシュ通知時に一斉にアップデートするというモデルはスケーラブルではないからです。瞬間的にアクセスが集中する部分はflag取得前のtestユーザーチェックだと考えました。(↓緑で囲われてる部分)そこで、MySQLの前段にRedisを置くことを決断しました。set型の集合にuser_idをkeyにして、testユーザーチェック等の処理に必要な情報を置いておきます。することで、O(1)でのreadが可能になります。Clusterを使用することで複数ノードに自動的に分散することができます。永続化とクラスタリングにはデータ更新時に整合性の問題がありますが、今回はtest終了時まで更新はないので問題ありません。Architectureに従って設計するべきだとのフィードバックを受けました。Architectureとは、以下3つのレイヤーから構成される設計指針です。バッチレイヤー:ログをバッチで集計するので正確だけど、リアルタイムではないサービスレイヤー:バッチレイヤーの集計結果を提供するスピードレイヤー:データはリアルタイムだが、データは少し不正確の可能性あるスピードレイヤーの集計で得た最新の値とバッチレイヤーの集計によって得た確定した値をマージすることで、素早く推定することが出来るというモデルらしいです。理解していないので、詳しくは以下書籍を読んでみます。www.oreilly.co.jpまとめ無知は罪だということを痛感しました。引き続きインプットの質を高めていこうと思います。(2)月別アーカイブはてなブログをはじめよう!NakaWatchさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。