本日は主にインフラの設計的なことに関して。
Contents
トランザクションスコープの設定
トランザクション(一回の処理)が大きすぎる
デメリット
- レスポンスが悪い
- 障害の時に余計に待たされたり、エラーになったりすることがある
- 非同期だと、ユーザーには成功したという表示がでるのに、実際には処理が落ちている・・ということがあり得る
対策
- 普段からプログラムをわかりやすく書く(主にコントローラーの部分に処理を集中させればどれがどれかわからない・・・という状態は防げる)
- 1リクエストでの処理=トランザクションにする(現在業務で使っているアプリは自動的にこれ。かならず1リクエスト=1トランザクションになる。どれがどれだかわからない・・・という状態は防げる)
- 1リクエストにいろいろな処理をいれすぎず、不要な処理は省く
- 継ぎ足しでシステムを構築しない
- キューイングシステムなどの構築
大量データのリアルタイム集計
なんでもかんでもリアルタイムにデータ集計をさせる。ユーザーの要求をいわれるがままにきき、処理量を考慮できていないことが多い。
デメリット
- 画面表示が遅い
- SQLが重くレスポンスが返ってこない→ユーザーがボタン連打→さらに遅くなる
対策
- 最初の段階で大量データでのテストを行う
- 非正規化などの集計テーブル(ビューも考慮に入れる)を使う
- トリガーなどを使い、元データが更新された場合自動的に非正規化された表を反映させる
- 多重処理(いくつもの処理を同時に行う)をやっていない
- バッチなどで回せる場合は、複雑な処理をバッチに回す
詰まると接続が増えるアーキテクチャ
ある1つの接続がつまり、続いて別の接続がつまり・・というように連鎖反応を起こすシステム。負荷系の障害であり、再現しないタイプのもののため難易度は高め
デメリット
- DBへの接続数が異常になり、遅くなる
- 原因がネットワーク不良やIOの遅延など判別しにくく、わからないことが多い
対策
- 性能テスト(同時に接続数を増やすようなテスト)を行う
- コネクションプールの理解
- 接続数の上限を設定しておく
