はじめに
ランサーズ Advent Calendar 2017 10日目の記事です。
ランサーズサービスの運用に欠かせない管理画面について紹介したいと思います。
紹介
lancers.jpではサービスを運営するための監視やお問合わせへの対応として、管理画面によりエンジニア以外でもデータ閲覧や適切な状況に更新することができるようになっています。
管理できる対象としては、仕事依頼やお支払いなど数十種類のデータを管理することができます。
社内のメンバーが全てのページに誰でも操作できるわけではなく、管理画面を操作する各アカウントに対して権限を設定したロールを持たせて閲覧や変更できる情報を制御しています。
問題とその対策
サービス以外に管理画面に対しても保守は必要となります。
サービスに比べてユーザアクセスが少ない管理画面ですが、保守していく上で問題となることもあります。
管理機能の追加や修正するためにサービス側の仕様や発生処理を細かく理解することが必要となり、開発する処理が漏れていると運用により不具合が発生してしまうことがあります。
また、管理画面は運用としてデータを管理するため比較的負荷の高い抽出や更新の処理を行うことが多く、更にデータが増えるにつれて重くなってしまいます。少し重くても正常に処理がされるのであれば、修正の優先度は低くなり対応は後回しとなってしまうことがあります。
処理が重くなるにつれて運用としてのオペレーションに影響が発生します。
処理が重くなってしまったことによる障害例と対策について紹介したいと思います。
サービスの拡大に伴い処理対象のデータは増加しており、それまで問題なかった処理が正常に動かなくなることがあります。
処理の対象を抽出して一括で処理する処理において、実行時間が掛かり過ぎてしまいブラウザエラー画面表示や処理が中断してしまったことがありました。
以前の一括処理
・処理実行をHTTPリクエストにより行う。
・対象のユーザごとにトランザクション処理を実行する。
・トランザクション後に一括して対象のメールアドレスにメールを送信する。
・既に実行された対象は実行対象条件から除外し、重複実行を回避する。
発生した現象
・一定時間レスポンスが返ってこないため、HTTP504エラーの表示となる。
・処理が数分かかったことでタイムアウト設定時間を超えてしまいHTTP499エラーが返される。
問題
・HTTPエラー表示により、リロードやブラウザバックの操作を誘導させてしまう。
・処理中にリロードした場合には先に実行された処理対象で未実行状態の対象がリロード時に実行対象となってしまい、重複で処理されてしまう。
・処理が中断してしまった場合に、障害となる。
対策
・一括処理の実行をSSHでバッチ処理する。
・ユーザごとの全ての処理をトランザクションに含め原子性を持たせる。
・既に処理が実行されている場合は処理全体にロックを掛けることで重複処理を防止する。
改善効果
・運用操作実行時に実行完了のレスポンスまで待たせることがない。
・ブラウザによるエラーを発生させない。
・万が一、途中で処理が落ちても途中から再開させることで障害とならない。
最後に
あまり表に出ることのないランサーズ管理画面について簡単に紹介をさせていただきました。
管理画面を開発されている方から共感や参考となれれば幸いです。