「Webを支える技術」と「[Web開発者のための]大規模サービス技術入門」を読んだので、学んだことをアウトプットしたいと思います。
どちらも比較的古い本なので、細かい技術的な話は流し読みしてしまったのですが、基礎的な部分で勉強になったことを書いていきたいと思います。
URIはそのリソースを表現する名詞です。
基本的に動詞は使ってはいけません。
また、当然ですがURIはクライアントから見た時の可読性が高い方が良いですし、
変わりにくいように設計することも重要です。
POSTもPUTもリソース作成ができます。
POSTでリソースを作成する場合は、クライアントはリソースのURIを指定できません。
URIの決定権はサーバーにあります。
逆にPUTでリソースを作成する場合は、リソースのURIはクライアントが決定します。
なので例えば、作成したリソースをすぐにGETで取得させたいとき、
POSTの場合はレスポンスのLocationなどにURIをいれてレスポンスする必要がありますが、
PUTの場合はその必要がありません。（PUTでリクエストしたURIにGETでリクエストすれば良い）
ただ、クライアントがURIを指定するということは、クライアントとサーバーが密結合になるということでもあるので、基本的にはPOSTを利用するのが良いです。
HTTPメソッドはそれぞれ以下の性質を持つように設計すべきです。
冪等とは「ある操作を何回行っても結果が同じこと」で、
安全とは「操作対象のリソースの状態を変化させないこと」です。
特に、PUTやDELETEは何回行っても必ず同じ結果（リソースの内容が更新されている、リソースが削除されている）が得られるようにすべきです。
PUTやDELETEが冪等でなくなってしまう例を紹介します。
コンピュータは、入力→記憶/演算→出力という流れでタスクを処理します。
当然、大量のタスクがあると、CPUでの演算やI/Oでの待ちが発生します。
この待ちがどれくらいあるかを表す指標がロードアベレージです。
もう少し正確に表現すると、
単位時間あたり待たされたタスクの数、つまり、平均的にどの程度のタスクが待ち状態にあったかを報告する数字です。
ロードアベレージとはload averageであり、平均的な負荷（待ち状態）という意味ですね。
「ロードアベレージが高い = 待ち状態のタスクが多い = 遅延が発生している」ということがわかります。
ただし、遅延の原因はCPU負荷なのか、I/O負荷なのかはこれだけでは判断できません。
どちらが原因なのかは、それぞれCPU使用率や、I/O待ち率を見る必要があります。
本書では、sarコマンド（System Activity Reporter）を薦めていました。
Webサービスでは主にAPサーバーとDBサーバーを使います。
性能を上げたい時は単純にこれらのサーバーを増やせば良いと思いがちです。
APサーバーに関しては確かにその通りなのですが、DBサーバーはそうとも限りません。
それはDisk I/Oは分散しづらいからです。
Readに関してはレプリケーションすれば良いだけなので、多少のラグが発生するもののサーバーを増やすことは難しくはありません。
ただ、Writeに関しては整合性が取れなくなるのでサーバーを増やす（マルチマスター）ことは非常に難しいです。
基本的にDBの利用は参照がメインなので、参照用のDB（スレーブ）をスケールアウトすれば解決することも多いのですが、更新の負荷が高い場合は工夫が必要です。
RDBを使わずにNoSQLを使うというのも有効な選択肢の一つだと思います。
入会申込
ログイン
