【QAチーム ブログリレー2日目】
こんにちは。猛暑のさなか仁左衛門の体調がいささか気になる、エンジニアリンググループ・マルチデバイスチームQAの前川です。
1月のエンジニアブログで紹介のありましたように、私がQAエンジニアとして所属するマルチデバイスチームは、各事業チームの展開サービスを横串でサポート・開発を行う横断チームにあたり、私はその中でm3.comアプリ、Web講演会アプリ、ToDo PlusアプリのiOS/Androidアプリとそのapiサーバサイド、Push通知のバックヤードなど、チームが関わるプロダクトの大半を担当しています。 多岐にわたるサービスを呼び出すアプリのテストは、時にはサービスのinternal-apiにも目を配る必要があり、横軸としてのサービス広範さ×縦軸としてひとつひとつの事象解析の深堀りも要求される、学ぶところの多いQAを日々繰り広げています。
運用品質
今回はマルチデバイスQAの紹介として、横断チームならではの「プラットフォーム共通プロダクトの信頼性Reliability」、あるプロダクトのシステム改善と応答改善の道のりについて駆け足で触れてみたいと思います。同じくQAに携わる方々の何か一助になれば幸いです。
メインのテスト業務のiOS/Androidアプリの機能検証やapi応答の担保、UI/UXの改善提案に加えて、もうひとつの大事な柱、運用監視という点で横断サービスはなかなかに手こずるケースが発生します。 バックエンド、フロントエンドともにぶら下がるプレーヤーが多いため、エラー解析の因数も多く、QAの本領「同定と弁別」が問われるケースが起こります。
「今日のToDo」サービス構成
担当するプロダクトに「今日のToDo」というサービスがあります。 m3.com＆sp.m3.comサイト、m3.comアプリでサービススタートし、その後ToDo Plusというアプリでも提供を加えたプラットフォーム共通のサービスで、デイリーでその日のレコメンドコンテンツを5件、ユーザーイベントキックで生成し、リスト全てを既読いただくと完了を返すサービスです。 各サービス間に配置された共通システムが、各サービスからコンテンツをPULL し、リストを生成して返す仕組みになっています。
余談ですが、上記のフローではなく各サービスが任意のタイミングでregisterApiを叩いてBigQuery/BigTableへPushする形で、ユーザーごとに最適化したコンテンツリストをリアルタイムで生成するシステムへの載替えを試みたことがありました。
最適コンテンツのリアルタイム応答を試みた設計ではありましたが、
・既読/未読などユーザー単位のステータスをALLUSERで洗いがえる頻度を高める必要がある
・BigQueryへの吸い上げにdelayもあるので、ステータスのリアルタイムの取得は難しい
・リアルタイム化となるとアクセスしてToDo取得apiを叩く都度state-apiやデータ管理の内部apiが叩かれる
動かしてみると可用性/運用性に課題があり、期待する実現性と運用のギャップを設計フェーズで見積る困難さの学びとなりました。
応答改善のみちのり
本題に戻りまして現行のサービスPull型、対象サービス拡充とともにリクエストが集中する時間帯の負荷エラー解消という課題が立ち上がってきました。
「今日のToDo」サービス構成ですが、
- 日付変わって0時以降に生成する通常ToDoと
- 通常ToDocompleteのユーザーを対象に、Web講演会など時限サービスの開催時間帯に回遊を期待して、startTime=18:00から生成リクエスト可能となる追加ToDo
の2部構成で展開しています。日に2回生成タイミングの山が発生することになります。 課題は
- リクエスト自体の分散
- リクエスト集中時の耐性
1. 通常ToDo
m3.comサイトのトップページにアクセスするだけで生成されるToDoコンテンツです。こちらは、ユーザーにより広く認知してもらい、さらに少ないSTEP数でサービスに参加できるように、能動的なキックは無しで生成される形にしました。 まず朝方アクセスによる自動生成の山が出来ますが、ToDoManager.classは専用システムではなく、その他の重たいロジックも扱うクラスであるため、システムslowやタイムアウトが投げられるケースが他サービス同様に発生しました。（この観点から先述のPush型の試み＆回帰して現行システム改善の現在に至っています。） また、ToDo自体のslowやタイムアウト以外にも、各コンテンツのconversionはサービスロジック依存のため、コンテンツ生成後に個別サービスが取得NGとなると「今日のToDo」コンポーネントも巻き込まれるという基本的な仕様制限の課題があります。
2. 追加ToDo
次に追加ToDoは、ユーザーが能動的に「開始ボタン」を押すことで、生成されるToDoになります。このボタンは通常ToDoを完了すると、18時以降に表示されます。 この夕刻の18:00という時間帯は、ユーザーに人気のWeb講演会という時限の動画ストリーミングサービスが、ライフサイクルに沿って多く開催される時間帯であり、ToDoリストもその参加に照準を合わせたいという意図から設定されました。 朝の通常ToDoと比較して能動的トリガーが挟まるためターゲットは絞られるものの、
- Web講演会サービスのシステムが同じToDoの生成箇所と同じサービスに載っており、同じ時間帯でリクエストが重なる
- Web講演会に付随するメール配信、社内広告の生成も重なる
というジレンマがありました。 ポータルサービスで人が集まる時間帯は、おのずから他施策コンテンツのリクエストも多いタイミングでもあります。 Sentryエラー監視、kibanaで流量監視しつつ、横断サービスゆえの切り分け、
- 中間api<->Gateway-api<->個別サービスのどこ起因か
- 広告システムなどの負荷の巻き添えか
- どこを緩めどのパーツの一時的縮退が有効なのか
を経過観察しつつ試行する運用が夕刻にちょくちょく発生しました。
対応
1. リクエスト自体の分散
まず、ToDoサービス自体の認知も進んだと判断し、m3comトップアクセスでの自動生成をm3.comアプリなどと同様に能動的に開始ボタンでのキックに変更しました。
これは朝方以外に夕刻の混雑帯に初アクセスでリクエストが自然発生するケースの負荷押し下げの効果もありました。
次に、Web講演会の開催時間にキックすることでリアルタイムで視聴対象を生成し追加ToDoのロジックとconversionポイントを、任意の対象、任意タイミングでconversion可能、かつ対象が時限で終了の場合はSKIP可能な実装、に改修しました。これにより追加ToDoの生成タイミングの前倒しが可能となり、運用を18:00->17:30と負荷のピーク前に変更、これがslowとタイムアウトの減少に大きく寄与しました。
2. リクエスト集中時の耐性
また、外部要因での解消となりますが、Web講演会サービスをmonolithicな既存システム-社内広告システムから切り出して新サービスへの移行が進み、ToDoサービス生成も載っている既存システムの負荷、キャパシティの問題が改善されました。 加えてWeb講演会の開催時の負荷分散の取り組み
- ストリーミング時の訴求に引いていたリアルタイム視聴カウント（5000人視聴中など）のデータソース参照をレプリカサーバに分ける
- ストリーミング開始の通知メールの配信タイミングを分割する
などサービスサイドの運用改善もエラー解消に寄与しました。
最後に
エムスリーでは数多くの事業サービス事業を開発してますが、マルチデバイスチームには採用技術の異なるアプリテストに関わるのみでなく、このようなサービス横断での性能＆運用を踏まえた非機能要件にも留意した、全方位のQAスキルを磨く機会があると思います。
We are hiring!
苦労話とはなりましたが、マルチデバイスチームではOSや採用技術を問わないモバイルアプリ開発＆検証、そして運用フェーズにも興味のあるQAエンジニアを絶賛募集しています。 興味がありましたらぜひご応募ください！
