「プロになるためのWeb技術入門」を読んで 〜Webシステムの三層構成〜
こんにちは。
「プロになるためのWeb技術入門」シリーズ、今回が最後です。
テーマは「Webシステムの三層構成」。
・Webサーバ
・・・女将さん
・Appサーバ
・・・職人さん
・DBサーバ
・・・素材屋さん
こいつらが互いにあんなことやそんなことやこんなことまでしてるんやって。
んで、この３つはシステム開発する上で必ず登場するみたい。
ソフトウェア構成の基本の基本の基本のそのまた基本。
絶対押さえとかなきゃいけないね。
よし、やろう！
と、サーバの話の前に「ノード」について。
ノード
一つのシステムを動かすために、Webサーバ・クラインアントみたいに複数のコンピュータがあった。
この時、各コンピュータのことを「ノード」って呼ぶらしい。
コンピュータの他に、ハブとかルータもそう。
まぁここはさらっと。
では「三層構造」。
それぞれを擬人化して説明していく。
・Webサーバ
まずは女将さんこと「Webサーバ」。
なぜ女将さんかと言うと、こいつが司令塔だから。
クライアントからのリクエストをまず女将さん（Webサーバ）が受け取る。
この女将さんが的確に指示出してあげないと、後に続く職人さん（Appサーバ）や素材屋さん（DBサーバ）が仕事できないってわけ。
どうやらこいつは最強にしないといけなさそうだ。
ちなみに「nginx」（nginx - Wikipedia）使う予定。
・Appサーバ
こいつは職人さん。
女将さん（Webサーバ）から指示を受けてせっせと働くんやな。がんばれ。
こいつの役割は、
・セッション管理
・・・セッションIDの発行や管理
・トランザクション管理
・・・業務上、まとめて確実に実行される一連の処理（トランザクション）
ん、なんやそれ....?
例えば、ネットで買い物したときのトランザクションは
・商品在庫を一つ減らす
・クレジットカードの請求処理を行う
みたいな。
・DB接続の管理
・・・DB接続 / 切断
DBはドラゴンボールやないで。
データベースや。
情報が表にまとまってるイメージかな。
職人さんだからもっとやることはいっぱいあるけど代表的なやつをちょこっと紹介。
うん、どうやらこいつも最強に育てなければならないらしい。
Ruby使うならUnicorn + Sinatra (またはRuby on Rails)かな。
・DBサーバ
今回初登場の素材屋さんこと「DBサーバ」。
大量の情報を管理してくれる。
「CRUD」っていうDBに対する基本操作があって、下の４つがそれ。
・生成（Create）
・・・新しい情報をDBに登録する
・読み取り（Read）
・・・DBに登録されている情報を読み取る。条件によって合致する情報を抽出する（これが検索処理）
・更新（Update）
・・・DBに登録されている情報を更新する。
・削除（Delete）
・・・Dbに登録されている情報を削除する。
例えば、マサ（以前登場した人物。別の記事でちゃんと紹介しますww）のプロフィールをDBに登録する。
まず、「マサのプロフ」っていう表を用意する。
これが「テーブル」。
んで、名前とか誕生日とか身長とか体重とかの各項目があるでしょ。
これが「カラム」。
これだとマサの情報だけで一行になっちゃうからアレなんだけどね。
これが「AKB48のメンバー」になると、何行にもなるよね。
この時、一行のまとまった情報に対して「レコード」って言うんや。
そしてSQLっていうDB専用言語を使って、必要な情報を取り出すってわけ。
SQLの命令は、
・何を
・・・マサの「誕生日」を
・どこから
・・・「マサのプロフ」テーブルと「AKB48のメンバー」テーブルから
・どのように
・・・誕生日が同じ、という条件で
取り出す。
ざっとこんな感じ。
これらをAppサーバとDBサーバがSQLを使って情報の受け渡しをしているんや。
情報が多くなってくるとこいつも最強にしなければならんな。
ちなみに使うとするなら「MySQL」とか「PostgreSQL」かな。
実際にISUCONで戦うとなると、CPUとメモリから判断してこの３つの内、どいつを最強（チューニング）にしていくかってことになる。
各サーバを１つのノードにまとめて入れるのか、それとも１ノード１サーバにするのか。
それぞれにMAXパフォーマンスを出させてあげて、それでも重くなるようだったらサーバ（ノード）分けてあげるとか。
まぁ色々パターンはあるみたい。
一般的な構成としては、WebサーバとAppサーバとDBサーバを１つのサーバ（ノード）にまとめて入れちゃうみたい。
ちなみに「オートスケール」っていう、自動でサーバを増やしたり減らしたりすることもできるみたい。
「あ、こいつやばいな。サーバ増やして負荷軽くしてやろう」
みたいな。
以上が「Webシステムの三層構成」。
女将さん・職人さん・素材屋さんのどれから最強（チューニング）にしていくのか、作戦会議をしながら進めるみたいです。
「プロになるためのWeb技術入門」終わり！！
（ISUCON出場に向けて、本書の全７章のうち５章までを読みました。）
「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか
- 作者: 小森裕介
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/10
- メディア: 大型本
- 購入: 57人 クリック: 1,242回
- この商品を含むブログ (35件) を見る
「プロになるためのWeb技術入門」を読んで 〜Cookie〜
今日は「Cookie」について。
なんだか美味しそうだね。
ちなみにぼくはオートミールクッキーが好きですw
Cookieとは
Webブラウザに情報を持たせる技術。
WebアプリケーションとWebブラウザ間で情報を交換できる技術。
どーゆーことかと言うと、
ログイン情報とかの来訪履歴って感じかな。
ブラウザ：「こんちはー。」
サーバ：「いらっしゃいませー。お、初来店やね。じゃあ会員証（Cookie）やるよ。」
ブラウザ：「あざっす！」
ブラウザ：「やぁ、またきたでー。」
サーバ：「会員証（Cookie）確認おっけー。」
ブラウザ：「お、この前買い悩んでたものまだカゴに残ってるやんけ。」
サーバ：「せやで。おれってええ奴やろ。」
ブラウザ：「あざっす！」
Cookieはサーバからブラウザに送られる。
各アクションごとに情報が更新されてく。
例えば、
・ログイン時のユーザ情報登録で更新
・何か買ったら更新
みたいな。
こうやって毎回同じサイトにきた時にいちいちログイン情報を入力しなくていいわけやな。
うん、便利や〜。
でも、そんな美味しくて便利なCookieにも問題点があるんやと。
どうやらCookieはテキストファイルとしてPC上に保存されるらしい。
ダイアログをのぞけばそれが見れるんだって。
困ったな、どうしようか。
セッションID
銀行窓口の受付番号的なやつ。
「受付番号372番でお待ちのお客様、お手続きが完了いたしましたので窓口までお越しくださいませ。」
そう、これこれ。
こうすれば個人名呼ばれなくて済むよね。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
セッションID：372
名前：マサ
受付：完了
手続き：手続き中
完了：まだ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
このセッションIDをCookieに入れてサーバとクライアントがやりとりをするんやな。
結局のところ、Cookieを使うことに変わりはないからCookieの情報を分からなくしてやろうって考え方やね。
もちろんセッションIDはただの数字（または文字列）だから誰が見ても分からんというわけ。
イメージとしては、DBから取ってきた情報を変数に入れるイメージかな？
ここらへんはもうちょっと調べてみよう。
ではでは、今日はこの辺で。
「プロになるためのWeb技術入門」を読んで 〜HTTP〜
先ほどコンサル会社の2dayインターンシップを終えました。
ナメてかかったわけではないですが、予想以上に頭使いました。
ぼくのザコ脳内メモリでは荷が重すぎたみたいですww
んじゃあ、早速「HTTP」について。
HTTPとは通信プロトコルの一つで、「情報の伝達方法」と「情報の意味付け」を規定するものでしたね。
では、どうやって情報を届けるのか。
「IPアドレス」
を使うんやと。
192.168.0.1 ←これ
人間世界と同じ、住所ってことですな。
このIPアドレスがわかると宛先のホストが特定できて、そいつに情報届けることができるらしい。
その役割は
「TCP/IP」
っていうプロトコルがやってくれるんやと。
情報をパケットという小さな単位に分割して送受信している。
郵便屋さんみたいなやつやね。
ん、待てよ。
URLも住所だよな。
URLとIPアドレス、どっち使えばええねん！
「DNS」
Domain Name System
ほうほう、こいつが打ち込んだURLをIPアドレスに変換しているらしい。
クライアント：「www.dirty.jpのIPアドレス教えてくれや」
DNSサーバ：「187.149.198.45や。覚えときや。」
こんな風に問い合わせることもできるらしい。
しかし、ここで終わらないのがインターネットの奥深さ。
「ポート」
郵便屋さんのTCP/IPは受信した情報がどのようなプロトコルか、どのアプリケーションが処理すべきわからないんだって。（なんだよ、ただ届けるだけかよw）
そこでこの「ポート」、港を使って情報を待つんだと。
Aは第一港、Bは第二港みたいに、その情報がどのプロトコルかを識別しているわけやな。
ちなみにHTTPはポート番号80で、SSHは22らしい。（SSH、22はどこかで使った記憶が....）
だから正確な書き方としては
www.dirty.jp:80
187.149.198.45:80
になるんだけど「:80」は省略されるって。
最後に
「GET」と「POST」
これは情報の渡し方、パラメータの渡し方の違い。
ん、「パラメータ」ってなんぞや.....。
例えば、
http://www.dirty.jp/unko/brown.php?num1=10&num2=20
がある。（入力欄に10と20を入れている）
パラメータはこれで言う、「num1」と「num2」。
「10」と「20」は値。
「?」以下をクエリ文字列と言って、「パラメータ名＝値」の形式で表されている。
おっけ、パラメータ分かった！www
話を戻すと、
http://www.dirty.jp/unko/brown.php?num1=10&num2=20
はGETでの渡し方。
POSTはと言うと、
http://www.dirty.jp/unko/brown.php
になる。
お、クエリ文字列がないやんけ。
なぜか。
答えは「セキュリティ」の問題。
アカウント作るときにユーザ情報を入力するでしょ。
それって個人情報やん。
パラメータとしてそれがURLに出てきちゃったらマズいよねって話。
だからGETとPOSTはちゃんと使い分けよう。
まとめるとこう。
「GETリクエスト」
・メソッド：GETメソッド
・パラメータの格納場所：URL
・セキュリティ：低い（サーバにログが残る）
・パラメータの長さ：制限の可能性あり
・パラメータの保存・再現：しやすい
「POSTリクエスト」
・メソッド：POSTメソッド
・パラメータの格納場所：メッセージ・ボディ
・セキュリティ：比較的高い（サーバにログが残らないことが多い）
・パラメータの長さ：制限なし
・パラメータの保存・再現：しにくい
ざっとこんな感じ。
ではでは、今日はこの辺で。
「プロになるためのWeb技術入門」を読んで 〜URL〜
前回記事の最後にURLの話をしたけど疲れちゃったので続きを。
まずはURLの構成から。
例えば
http:// www.dirty.jp/unko/index.html
ってのがあるとする。（汚くてすいません。）
「えいちてぃーてぃーぴーころんすらすら」のアレ。
これは大きく３つに分けられる。
・「http:」 → スキーム
リソースの取得方法を表している。
・「www.dirty.jp」 → ホスト名
リソースが存在するホストコンピュータ名を指している。
んで、このホスト名はまた２つに分けることができて、
「www」 → ローカル名
「dirty.jp」 → 親ドメイン名
になると。
"jp" → 日本の
"dirty" → dirtyという組織の
"www" → WWWサーバというコンピュータ
って意味らしい。
・「unko/index.html」 → パス名
ホスト名で指定されたコンピュータ上のリソースの位置を示す。
上で言うと、「unko」ディレクトリの下にあるindex.htmlというファイルを示しているんやと。
そうか、URLっちゅーのは
ドメイン → コンピュータ → ディレクトリ → ファイル名
で指定してるのか。
......ん、待てよ。
「http」ってなんぞや。
ざっくり言うと、「http」はお約束ごと。
サーバとクライアントが通信を行うときに、どうやって情報のやりとりするかって取り決めなんだと。
クライアント：「HTMLが欲しいんやけど、どうやってやりとりしようか？」
サーバ：「そうだね。HTTPでよくね。」
クライアント：「おっけ、じゃあそれで。」
みたいな感じかな。
この取り決めを「通信プロトコル」って言うそうな。
そういや昔「狼煙」ってあったよね。
遠くの人に情報を伝える手段の、あの煙や。
狼煙は、
・煙を使って合図を伝えること
・敵の襲来を示すこと
・狼煙の煙を見たら、自分たちも狼煙を上げてさらに周囲の人に伝えること
これがプロトコル、狼煙の取り決めやったんやな。
やはり先人たちはすごい。
便利な世の中になったもんだ今は。
ではでは、今日はこの辺で。
「プロになるためのWeb技術入門」を読んで 〜サーバとクライアント〜
Lesson 2 「Webはどのように発展したか」
この章ではWebの歴史について。
ぼくは歴史が苦手なもんでここはさらっとww
そもそもインターネットは今から約４０年ほど前にその原型ができたそうな。
けど利用者は大学とか研究機関の関係者で一般的ではなかったそうな。
よって当時のWeb技術はこの人たちから生み出されたんだって。
「WWW」という考え方もそう。
研究成果を全世界で共有できないかって思ったらしい。すごいね。
要はインターネット経由で研究成果を閲覧できるようになったわけだ。
しかも「HTML（hyper text markup language）」というコンピュータが理解できる統一形式も作っちゃった。頭良すぎやろ。
・WebサーバとWebクライアント
いよいよ技術的な話。
WWWによるハイパーテキストの公開と閲覧は「Webサーバ」と「Webクライアント」というソフトウェアで実現されているんだって。
Webサーバがネットワーク上にハイパーテキストを蓄積して、Webクライアントの要求に従って必要なHTMLファイルを渡してあげる仕組み。
つまりこう。
クライアント：「HTMLちょーだい」
サーバ：「はい、このHTMLだね。あげる。」
ほうほう、なるほど。エンジニアの人がよく言う
「リクエスト投げてみ」。
これがクライアントの要求、つまり
「HTMLちょーだい」
だったんだね。
ってことはこのサーバの応答が
「レスポンス」。
けどさ、「HTMLください」なんて言わないよねwww
どのHTMLか分からんもん。
ってので出てくるのが「URL」。
・「そのリソースはどこにある？」 ーURL
例えばの話。
ぼくの友達に「マサ（仮・田中正志）」という人がいる。
日本の人口約１億２０００万人の中からこいつを探し出すにはどうするか。
まずは「田中正志」で探してみよう！
.....うん、いっぱいいるよね。
じゃあ次は大学名を付けて「はてな大学 田中正志」で探してみよう！
......だいぶ絞れたけどマサじゃない奴も出てくるな。
よし、今度は学部名も加えて「はてな大学 ブログ学部 田中正志」だ！
......おっ、マサだ！！やっと会えたね、よしよしwww
こんな風に一意のコンテンツを特定するための仕組みが「URL」。
ふぅ、疲れたからURLの話は次回にまとめよう。
