もくじ

• ADR 8 : 稼働状況表示機能の導入
  • Status : 🟢 承認
  • Context
  • Decision
    • データベース構成
    • 頻度
    • データベースの圧迫
    • API の仕様
      • リクエスト
  • Consequences
    • Pros
    • Cons
  • Notes
  • References

ADR 8 : 稼働状況表示機能の導入

Status : 🟢 承認

Context

かどでポータルやかどでペーパーにおいてかどで日記の稼働状況が必要になっているが現状データも API もない。

Decision

全体の日記数の推移や処理した統計数の推移をデータベースに保存し、API から取得できるようにする。
アクセス数などではなく、ユーザーの数などかどで日記のコア機能の利用状況によるもの。
アクセス数は GA など使いたい。

データベース構成

モデル:OperationCoreTransitionPerHour
テーブル:operation_core_transition_per_hours

今後レスポンス速度のテーブルなども増える可能性があり、あくまで日記のコア機能に注目しているという意味で OperationCore。
あくまで現状のステータスでなく推移を表すため TransitionPerHour。

作成後更新しないため、created_at のみ。

id	user_total	diary_total	statistic_per_date_total	created_at
1	100	3000	2870
2	101	3012	2920
3	103	3040	3002

頻度

1 時間に 1 度程度 Cron で走らせることを想定。完全なリアルタイムだとそもそも RDB じゃなくて Redis を用いるべき。
そこまで細かい頻度では必要ないと思っている。

データベースの圧迫

MySQL 系の行上限は無いが、id のオーバーフローはありえて、laravel の migrations で定義する id()は unsigned big int になり、この上限値は 18446744073709551615。
1 時間に 1 つ行を追加する想定だと、1 日で 24 行、1 ヶ月で 720 行、1 年で 8640 行。オーバーフローの懸念は不要。
とりあえず定期削除は走らせなくて良さそうだが、SELECT が遅くなるのは困るので場合によっては古いデータを削除する Cron を入れる。

API の仕様

かどで日記で API を生やすのはこれが初めてなので、命名は慎重に扱う必要がある。
フロント側の処理を減らしたい方向性なので、GraphQL みたいなたいそうなものでなく、フロント側に併せてバックエンドの API の中身を調整していきたい。
あくまで取得のみであるから、RESTFul である必要もない。

ただ今後も踏まえて命名は大事。

リクエスト

とりあえず現状はすべて GET で返すようにする。 レスポンスは JSON。

エンドポイント	役割
/api/OperationCoreTransitionPerHours/relative/day	直近 24 時間のデータを返す
/api/OperationCoreTransitionPerHours/relative/week	直近 1 週間のデータを返す
/api/OperationCoreTransitionPerHours/relative/month	直近 1 ヶ月のデータを返す

絶対形式での取得エンドポイントも実装する場合は/absolute?start=date&end=date みたいな感じを予定しているが、現状特定の期間のデータは現状必要ない上、チャンクしたりページネーションしたりが手間なので一旦見送る。

Consequences

Pros

• かどで日記の利用状況や推移が分かるため、今後のインフラ調整がしやすい。
• 稼働状況を表示することで生きたサービスであることを示せる。

Cons

• 1 時間ごとに行が増えていくため将来的なデータベースの圧迫が懸念される。

Notes

References