トラブル知らずのシステム設計を読んで学んだことなどメモ

トラブル知らずのシステム設計を読んで学んだことなどメモしておきます。

PRG(POST/Redirect/GET)パターン

Webブラウザの戻る対策の1つとしてPRGパターンがあります。これは登録処理(POST)と画面遷移(Redirect/GET)に分ける方法です。

登録処理(POST)を行った後、登録完了画面へのリダイレクトのレスポンスを返すことで、登録完了画面にGETリクエストを発行します。

POSTリクエストの内容がブラウザの履歴として記録されないため、送信した内容をブラウザの履歴がたどることを防止しています。そのため実装コストはかかりますが、PRGパターンは二重送信抑止、セキュリティ対策の点で効果的な手法です。

ただ、二重送信抑止として完璧ではなく、Webブラウザの戻る対策としては効果的であって、例えばヒストリバックから登録画面まで遡って表示した場合、登録ボタンをクリックすることで登録処理(POST)が行われてしまいます。つまり、二重送信を完全に防いでいるわけではありません。

別ウィンドウを使用して異なる画面を表示する「子画面遷移」という方式があります。

この子画面には親画面を見たり操作したりできない「モーダル」と子画面を表示している時でも親画面を見たりそうしたりできる「モードレス」の2種類があります。

モーダルやモードレスのように複数画面に分ける場合、前の画面で入力したデータの内容を後続画面に引き継ぐことが必要です。一時的なデータ保持方式として「セッション方式」と「Hidden方式」があります。

セッション方式は、Web・APIサーバでユーザセッションごとに管理しているメモリ領域を使用してデータを格納する方法です。注意点は、Web・APIサーバのメモリを消費するので、同時接続のユーザ数や同時画面起動数が増えるとメモリ使用量が大きく変動し、アウトオブメモリ(OOM)のリスクが高まります。

また、モードレスの場合はセッション管理をしっかり行わないと、複数の画面から同一のメモリ領域を更新してしまい、セッションの上書き問題が起きてしまうため注意が必要です。

Hidden方式は、HTMLのinputタグのType属性をhiddenに指定し、画面に入力したデータをHTML文に含める方法です。注意点は、データ量が多いとブラウザとサーバ間の通信量が増大し、遅延の原因になることです。

また、ブラウザの開発者ツールなどを使用してhiddenの内容を編集できてしまいます。そのため、暗号化するなどの不正改ざんを防ぐ対策が必要です。

DBの実行計画とは、発行されたクエリを実行するための手順書のことです。対象のテーブルからのデータ取得方法や結合方法などが書かれています。

そのためSQLのパフォーマンスは実行計画によって大きく左右されます。実行計画を確認しインデックスを貼ることでパフォーマンスを向上することができます。

ちなみにMySQLで実行計画を確認するにはEXPLAINステートメントを使います。クエリの先頭にEXPLAINをつけることで実行計画を確認することができます。実行結果のそれぞれの項目がどのような意味なのかは以下の記事が参考になります。

大量のデータが格納されているテーブルをフルスキャンすると多大なコストがかかります。フルスキャンを避ける手法がインデックススキャンです。インデックスとは索引のことで、書籍などの索引と同じ考え方です。

DBは一定サイズのデータブロックにデータが格納されており、テーブルフルスキャンでは全てのデータブロックを読み取ります。インデックスを使うとダイレクトにデータブロックを特定できます。