大学のサーバーに、
迷惑をかけない。

つくぷらは筑波大学の学生が作っている非公式アプリです。 manaba・TWINS・KdBといった大学のシステムは、筑波大生みんなの学びを支える共有のインフラ。 だからこそ「サーバーに余計な負荷をかけない」ことを、機能と同じくらい大切な設計目標にしています。 このページに出てくる数値は、すべてアプリの実装コードにある値そのままです。

負荷を増やさないための、4つの原則。

アプリからの通信は、この順番の考え方で設計しています。

1. まずキャッシュを読む

一度取得したデータは端末に持ち、期限が切れるまではサーバーへ行きません。

2. 同期には最低間隔

自動同期は前回からの経過時間を必ず確認し、間隔が空くまで動きません。

3. 取得には上限

1回のチェックで読むページ数・件数に上限を置き、それ以上は読みません。

4. だめならすぐ引く

すべての通信にタイムアウトを設定。つながらない時は接続を引きずりません。

まずキャッシュ。サーバーは「どうしても」の時だけ。

画面を開くたびにサーバーへ取りに行くのではなく、端末の中に持っているデータを先に使います。 サーバーへのアクセスは、キャッシュの期限が切れた時だけです。

キャッシュが効く仕組み

機能ごとに適切な保持期間を決めて、同じデータを何度も取りに行かないようにしています。

  • 試験まとめ(KdBシラバス)は一度取得したら端末に保存。再取得が走るのはユーザーが更新操作をした時だけで、24時間経過後も「更新を促す」表示にとどめ、勝手に再取得はしません
  • バス時刻表はアプリに内蔵。オンライン更新分も開発者が管理する配信データ(GitHub)から取得するため、時刻表のために大学や交通事業者のサーバーへアクセスすることはありません。取得後1時間はメモリキャッシュを使い、同時に複数の取得が走りそうな時は1本に合流させます
  • 「いまヒマ」「お友達」のクラウド読み取りも同じ方針です。常時接続のリアルタイムリスナーは使わず、必要な時に1回だけ読む get() 方式+10分のメモリキャッシュで読み取り回数を抑えています
つくぷら アプリ 端末内キャッシュ いまヒマ・友達 10分キャッシュ バス時刻表 内蔵+1時間キャッシュ 試験まとめ(KdB) 手動更新まで保持 大学などの サーバー まず読む 期限切れの 時だけ

図1: キャッシュが効く仕組み。サーバーへ行くのは点線の経路だけです。

manabaの自動同期は、60分に1回まで。

課題の自動同期は便利ですが、放っておくとサーバーへのアクセスが増えがちな機能でもあります。 つくぷらでは「同期しすぎない」仕組みを何重にも入れています。

同期スロットルの仕組み

自動同期は、前回の同期からの経過時間を必ず確認してから動きます。

  • 初期設定はオフ(オプトイン)。有効にした人の端末だけが同期します
  • 前回同期から60分未満の間は、アプリを何度起動・復帰させても同期しません
  • バックグラウンド同期も約60分周期で、同じ「60分ルール」を尊重します
  • 同時に走る同期は常に1本だけ(多重実行ガード)。手動の「今すぐ同期」を連打しても、実行されるのは1回分です
  • manabaへのログインは、同期が実際に走る時だけ行い、終わったらセッションを必ず破棄(Cookie消去・接続クローズ)します
  • 読み取るのは課題の集約ページ3枚(レポート・小テスト・アンケート)だけ。履修コースを1つずつ巡回することはありません
manaba自動同期(オンにした場合) 同期 0分 起動しても同期しない 20分 45分 同期 60分〜 前回の同期から最低60分あける

図2: 同期スロットルのタイムライン。間隔が空くまで同期は走りません。

1回のチェックに、リクエストの上限。

試験クイックチェックや大学お知らせのように外部ページを読む機能は、 「何を・何件まで読むか」をあらかじめ決めて、それ以上は読みません。

試験チェックは、ユーザーが押した時だけ。

試験クイックチェックのmanabaアクセスは、ユーザーが「manaba連携」を明示的に実行した時だけ行います。自動でmanabaにアクセスすることはありません。

  • 1科目あたりの取得は、ニュース一覧1ページ+ニュース本文 最大12件、コースページ一覧1ページ+本文 最大10件で打ち切ります
  • manaba側に対応するコースが見つからない科目には、1リクエストも送りません
  • 処理全体も最大120秒で打ち切り、取得できた範囲だけを反映します
  • KdBシラバスの一括取得は同時5接続までに制限し、科目数が多くても一斉アクセスにならないようにしています
  • 取得した試験まとめは端末にキャッシュされるため、結果を見直すだけなら再アクセスは発生しません
試験チェック: 1科目あたりの取得上限 ニュース一覧 1ページだけ ニュース本文 最大12件で打ち切り ページ一覧 1ページだけ ページ本文 最大10件で打ち切り ここまで 上限から先は読みません。全体も最大120秒で打ち切ります。

図3: 1回のチェックで送るリクエスト数の上限(1科目あたり)。

大学お知らせは、公開ページに1リクエスト。

TWINSの掲示一覧は、ログイン不要の公開ページを1回取得するだけです。 サーバーから見れば、ブラウザでページを1回開いたのと同じ負荷しかかかりません。

  • 一覧の取得は公開ページへの1リクエストだけで完結します
  • 重いHTML解析はサーバーではなく、端末内の別スレッド(isolate)で実施します
  • 掲示の本文は、ユーザーが開いたその1件だけを取得します
TWINS 公開掲示ページ 1リクエスト スマホの中で解析 HTML解析・見出し抽出 別スレッド(isolate)で実行 未読バッジ・一覧表示

図4: 取得は1回、解析の仕事は大学ではなく端末側が引き受けます。

つながらない時は、すぐ引き下がる。

障害や混雑でサーバーが重い時に接続を保持し続けると、それ自体が負荷になります。 つくぷらの通信にはすべて明示的なタイムアウトを設定しています。

接続を引きずらない

  • manabaログイン15秒・KdBシラバス15秒・バス時刻表15秒・TWINSお知らせ20秒で打ち切ります
  • バックグラウンド同期は処理全体を25秒以内に収め、超えたら静かに終了します
  • 失敗してもその場で連続リトライはせず、キャッシュや内蔵データで表示を続けます
  • manabaのログインセッションは使い終わるたびに必ず破棄し、接続を閉じます
通信タイムアウトの実装値 manabaログイン KdBシラバス バス時刻表 TWINSお知らせ 背景同期 全体 15秒 15秒 15秒 20秒 25秒

図5: ここまで待ってつながらなければ、接続を打ち切ります。

学生が作るアプリだからこそ。

manaba・TWINS・KdBは、筑波大生みんなの学びを支えるインフラです。
つくぷらは公式サービスの代わりではなく、公式サービスを使いやすくするための補助として、
これからも「サーバーにやさしい」作り方を続けていきます。