200805

なんとなく興味が沸いたので先週DSのヘラクレスの栄光を購入に行ってきました。
そしたら売り切れ。次の日に入荷するらしく、遠出するのもめんどくさいので
その日は退散して出直しました。
と、一回振られてまで購入してきたヘラクレスの栄光ですが、
開始3分ほどプレイしてから全く進んでおりません。

いや、別につまんないとかじゃないんですよ。
というかまだ面白いかどうかの判断なんてできないです。

最近は本当に詰みゲー率が増えたなぁと。
就活終わったら徹夜でクリアする予定のゲームも多かったのに、
今はもうどうでもよくなってしまったという・・・。
本格的にRPGが最後までいかない体になりつつある。

ただヘラクレスは結構期待できそうなので、
今日はちょっと残りの時間はヘラクろうと思います。
楽しみ。

読んだのは
Designing an Enhanced PC Cluster System forScalable Network Servicesという論文。
内容は僕が卒論で考えているものに近め、というかほぼそのまんま。
違いは使用するソフトウェアとかファイルシステムあたりかな。
だから評価方法など参考になる部分がそこそこありました。
(少し怪しい部分もあったけど)

英語の文章を読むのは昔マニュアルを見てうんうん唸ったことがあるから
耐性はできているがやはり時間がかかる。
今回もある程度理解しながら一回読むのに6時間ほどかかったし・・・。
他にもざっとpptを形作るのに5時間ほど。
内容の研磨に1時間ほど。言う内容考えるのに1時間ほど。
レジュメ作るのに1時間半ほど。
あと深く理解するための拾い読みを何度も。
時間きっついなぁ。
論文内容紹介の形式から調べてたから余計に時間がかかる。
まあ、慣れてスピードアップしていければいいかな。
時間はかかったけど頑張った分、そこそこしっかりした発表ができたのではないかと。

さっぱり論文は読んだことがなかったが、
自分のやろうとしている分野に近い論文を読むのは結構面白かった。
あと、ファイルシステムなどの比較は今の自分で調べていくよりも
他人の論文を参照していく方が効率が良いことに気がついた。
もちろん深く理解するためには自分で調べていく必要があるんだけど、
軽い理解をする段階では論文で比較されているのを参照するのが楽。
必ずしもその情報が正しいとは限らないけど、
まあ、論文なら信頼性はそれなりにはあるんでないかな。

次はGFSについての論文を読んでみたいな。

ゼミで論文内容紹介をするために拾ってきた論文をとりあえず読み終わった。
まあ、あとでまた目を通すけど。

大学の図書館データベースは今まであまり利用したことがなかったけど、
いざ利用してみるとIEEEの論文とかが拾えて嬉しい。
今まで使わなかったのがちょっと勿体ないかも。

ToDoまたはスケジュール管理ソフトの良いものを探し中。
使用を決定する要素↓

• 保存する情報の機密性は高くない
• OSに依存しないものが良い
• 複数のPCで内容を共有したい
• 使いやすいインターフェース

この辺を満たしているとなるとオンラインのヤツかな。
今はRemember The MilkとCheckpadを試し中。

自宅のLinuxマシンのFedoraを7から8にアップデートしました。
すでに9も出ているけど、あまり評判がよくないので8で。
別に更新しなくても良いかなとも思っていたのだけれど、
よく考えるとOSはクリーンインストールばかりで
yumからバージョンアップしたことがないなと。

ということでものは試し。

といっても、大して手間はかからなかった。
適当な場所から以下の二つのパッケージを入手。

• fedora-release-8-3.noarch.rpm
• fedora-release-notes-8.0.0-3.noarch.rpm

rpm -Fvh fedora-release-8-3.noarch.rpm fedora-release-notes-8.0.0-3.noarch.rpm
yum clean all
yum -y update

これだけ。
依存関係があってアップデートできないこともよくある模様。
今回はBeryl関係のものが引っかかったのでyum removeで削除した。

今回のアップデートを行ってBerylがCompizと統合されていたことを知った。
なのでアップデート後に独学Linuxさんを参考にCompiz Fusionを導入。

8にしたらロケールを日本語にするか促されたのでとりあえずしてみた。
が、キモすぎるので戻そうと思う。
どうも2バイトディレクトリ名はキモい。
Linuxだと違和感がすごすぎる。

他に目のついたところでWindows用のHDDがオートマウントされてた。
便利だけどツリー上どこにマウントされてるのかよくわからん。
あとで探そっと。

例えば。

• テスト1
• テスト2

HTMLを解釈してくれるため、もちろんFC2も箇条書きはできるわけである。
他にも、

これとか

こんなとか

　もちろん引用もあるし

ただFC2ははてな記法みたいなものはないっぽいので、
HTMLを知らないと表現方法が少なくなるし(といってもすぐ覚えられるレベルですが)、
何より書くのがめんどくさいです。

FC2は細かく自分で弄れるところが多い・アフィに向いている辺りが利点なんだろうか。
はてなはシンプルだけど、色々な機能が提供されているのが良いかな。アフィには向いてないが。
アフィリエイトやってないし、だらだら雑文やらメモ書く分にははてなのが良さげか。

一応はてな記法で記述ができるはてな記法ワープロなんてものもあるケド。

FC2はHTML展開してくれる記法、ないのかな？
もしかしたらあるかもしれない。
もし知っている方いたら教えてくださいませ。

ファイルシステム比較

Wikipediaに良い感じに纏まっていたのでメモ。

通信の際の取り決め。
渡すデータの形式・その解釈方法など。

アプリケーション層
いわゆるメーラーとかの送信時に、
本文の部分を示す情報や宛て先などの情報がヘッダとして付与される。

プレゼンテーション層
機器固有のデータ表現をネットワーク共通のデータ表現に変換。
データの符号化方式を判別するための情報のヘッダが付与される。

セッション層
通信の際の論理的な道筋やデータの送信方法などを決定。
データをどのような手順で伝えるかなどの情報が書かれたヘッダが付与される。

トランスポート層
通信の信頼性を保障する。
パケット番号などの情報を含むヘッダが付与される。

ネットワーク層
パケットの配送処理を行う。
始点・終点IPアドレスなどの情報がヘッダとして付与される。

データリンク層
直接接続された機器間での通信のやりとりを補助する。
データを2進数で表現し、データを意味のある単位(フレーム)に纏める。

物理層
2進数で表現された情報を光の点滅や電圧の高低で表し、
通信媒体を通してデータを流し込む。


受け取る時はこの逆の処理を行う。
(ヘッダを付与するのではなく、ヘッダを取り除いていく)

コンピュータ・ネットワークの歴史
1950年代
バッチシステム　　　　　　　　　テープに処理を順次記述・読み込み・順次処理
　　　　　　　　　　　　　　　　　 　FORTRAN・COBOLはバッチ処理向けの言語

1960年代
タイムシェアリングシステム　　一つのコンピュータを複数の端末でシェア
　　　　　　　　　　　　　　　　　　　細かい時間でCPU割り当てを切り替える
　　　　　　　　　　　　　　　　　　　BASICの登場・対話型のプログラムが主流に

1970年代
ネットワークの登場　　　　　　 複数のコンピュータを繋いでネットワークを構築
　　　　　　　　　　　　　　　　　　 ファイル移動などにかかる手間が軽減される
　　　　　　　　　　　　　　　　　　 ウィンドウシステムの登場により、複数のプログラムの同時実行が
　　　　　　　　　　　　　　　　　　 可能となる

1980年代
ネットワークの拡大　　　　　　　取引関係にある企業や複数の学術機関のネットワークが結合される

1990年代
インターネットの登場　　　　　　情報処理に力をいれた機関では一人一台のコンピュータ
　　　　　　　　　　　　　　　　　　　World Wide Webによる情報公開

2000年代
通信の統合へ　　　　　　　　　　各々仕様が異なる通信網をIPを用いたものに統合

サーバ負荷分散の本を読んでいたが、
そろそろTCP/IPをもう少し深くやらないと読みにくくなってきたかも。

社会人になる前に、学生のうちにしかできないことをいっぱいしておけ、とか。
旅とか、アルバイトとか、なんかの活動であったりとか。
そう、社会人になったら、自由な時間は圧倒的に減るんだ。
卒業までの時間、卒論があるとはいえ、自由な時間もある。
だから、この間に、やりたいコトを満喫せねばならない。

僕は、勉強・読書・運動・アルバイト・海外旅行・バイク免許取得あたりをやりたいと思う。

ただ、全部をやるのはできるのかな？って感じなわけで。
まあできるだろうけど、一日の時間と僕の体力は有限なわけで、
何かに力を入れた分、何かから力が抜けるだろう。
濃度の問題がある。

そう考えた時、俺が一番やりたいことは何なのかなあと。
社会人になると確実に難しくなるものはバイク免許だろうな。
あとアルバイトも。まあ、バイトは働いてるからいいんだけど。
海外旅行は1週間程度ならなんとか行ける機会もあるだろうな。
運動は、毎日は時間ないだろうな。
読書。小説とか悠々と読める時間は減るだろうな。
勉強。社会人になっても勉強する機会は腐るほどあるだろうが、
専門から外れたことを学ぶ機会は激減するだろう。

どれも、やりたいけど。全部できるかはわからない。

この中で特にやりたいの。
たぶん、俺は色々な本を読んで、色々なことを勉強することだと思う。
社会人になってもこれらはできるけど、向き合う心が違うんだな。
今は本当に自由だ。束の間の自由だけれど。
卒論の分野だって興味があるから知りたい分野だし、
それについて知識を深めていくことは楽しい。
時間を気にしないで読書に没頭できる。最高だ。

知識と経験を天秤にかける。
経験はたしかに重要だけど、今の僕には知識を得ることも同様に重要。
そして、自信を得るって観点では、
たぶん僕の場合、今は経験よりも知識を求める方が良い気がする。


限られた時間。
有効に使いたいものだ。

サーバ負荷分散についてて学んでて面白いと思ったコト。
上手く抜け道を探してるなあって。
返答パケットの始点IPアドレスの書き換えを省略するために、
VIPをループバックインターフェースに割りあてるっていうのが面白かった。
いくつものレイヤが重なっていて、今はそれぞれの詳細はよくわからんけど、
それを知ることによりそんな抜け道が見えてくるのかな。

TCPのようなコネクション型通信における原則として、
ある通信パケットが送信された時、送り返されるパケットは
最初に定義した始点・終点IPアドレスのみを用い、
それ以外のIPアドレスからのパケットは破棄するというものがある。
ゆえに、負荷分散装置は始点・終点IPアドレスを適切に書き換える必要がある。
上のことを踏まえた上でサーバ負荷分散のパケットの流れを見る。

サーバ負荷分散におけるパケットの流れは、
1. ユーザーから負荷分散装置のVIP宛てにパケットが送信される
2. 負荷分散装置がパケットを受け取り、終点IPアドレスを実サーバのものに書き換えられる
3. 実サーバがパケットを受け、処理する
4. 応答パケットを負荷分散装置に返す
5. 負荷分散装置が始点IPアドレスを負荷分散装置のVIPに書き換え
　 ユーザーにパケットを送る
といったものである。

このパケットの流れの負荷分散は負荷分散装置の負荷が大きい。
何故なら、実サーバが処理した後のパケットも
負荷分散装置を通らないといけないためである。
そこで、負荷分散装置の負荷をより軽減できる方法として、
DSR(Dynamic Source Routing)がある。
これは上の処理手順における4〜5の処理を省くというものである。
これにより返答パケットを負荷分散装置を経由することなく
直接ユーザーに返すことが可能となる。

DSRではMAT(MAC Address Translation)を行い、
レイヤ2でのパケット操作を行う。
始点IPアドレスを書き換える必要をなくすために、
VIPを実サーバのネットワークインターフェースにも持たせる必要がある。
しかし、ネットワーク上において二つのMACアドレスに対して
同じIPアドレスを割りあてることはできない。
そのため、VIPはループバックインターフェースに割りあてる。
ループバックインターフェースはサーバ内部の通信に用いられ、
そのIPアドレスは127.0.0.1である。
しかし、ネットワークインターフェースに複数のIPアドレスを付与できるのと同様に
(IPエイリアス)、ループバックインターフェースにもIPエイリアスを付与できる。
これにより、複数のMACアドレスに対して同じIPを割りあてることができないという
問題に対処する。

DSRでの負荷分散は次のような手順でパケットが操作される。
1. ユーザーから負荷分散装置のVIP宛てにパケットが送信される
2. 負荷分散装置がパケットを受け取り、MATを用いて終点MACアドレスを
　 実サーバのネットワークインターフェースのものに書き換える
3. パケットが実サーバのループバックインターフェース宛てに届く
4. 実サーバがユーザーに返答パケットを返す

Webトラフィックは約1:8の割合という特徴を持つ。
パケット1を受け取り、その返答パケットを8返す。
(これは処理すべきトラフィックの量であって、パケット数自体はほぼ同一である)
そのため、DSRを用いることにより負荷分散装置の負荷を大幅に削減できることになる。

ただし、DSRは設定の複雑化や、
レイヤ5-7のURL解析やハッシングが動作しない他、
通常はクッキーを使う維持機能が動作しないなどの欠点がある。


他のサーバ負荷分散方式としては、
始点・終点IPアドレスどちらかのみを書き換えるハーフNATや
両方を書き換えるフルNATなどがある。
フルNATはプロキシやキャッシュのサービスにおいて有効な場合がある。


負荷分散装置は通常サーバベース負荷分散装置と
スイッチングベース負荷分散装置の二つに分けられる。
以下それぞれのメリット・デメリットである。
ただし、これらのメリットなどは常にあてはまるものではなく、
ベンダや機種により大きく異なる場合がある。

サーバベース負荷分散装置
ネットワークスタック上のソフトウェアコードによりパケット書き換えを行う。
メリット
・使用するOSの開発者が雇いやすいため、開発が容易
　→コード変更や新機能の追加を迅速に行える
デメリット
・コードのサイクルが短いため、バグが出やすい

スイッチングベース負荷分散
ASIC(Application Specific Integrated Circuit)チップを使いパケット書き換えを行う。
メリット
・ASICチップは専門化されたプロセッサで汎用プロセッサより高速である
・安定している
デメリット
・ASICチップの柔軟性に欠け、
　新たな機能の追加の際にはASICを設計しなおす必要がある
　(IP自体は変化しないためそれらの機能をASICに埋め込み、
　再設計を避けられる場合もある)
・コード開発が難しくリリースが遅い(だがそのため安定性が高い)

大学での様々な経験。
自分はそれらを通して大きく成長したと思う。
けど同時に自信をなくしたなと。
まあ、元々薄っぺらい表面だけの自信だったから、
遅かれ早かれ剥がれるもんだったんだろうけど。

何にせよ今の俺は自信がない、けど、
そろそろ自分を信じなければ、信じれる自分にならなければならない。
と、ふと思った。

卒論関係のカウントダウンプラグインを設置してみた。
残り何日かというのを目に見える状態にしておくのは非常に重要。
取り組む心持ちがとても変わってくる。
卒論完成させるぞ。

2007年
・8月
TISのインターンシップに応募、ES通過・面接で死亡。
この時ES応募や面接対策で自己PRなどを考えたのは良い経験だった。
ここで考えたものが後の就活でのベースとなる。

・10月
合同企業説明会に参加し始める。
大体3回か4回ほど参加した後、これ以上はあまり意味がないと思うようになり、
以後合同企業説明会は参加しなくなる。
面接や試験対策の本を購入。
面接対策の本を読む。
学校の就活対策講座などに出席する。

・11月〜12月
試験対策の本を少しずつ進めていく。
適当に興味のある企業を物色していく。
学校の就活対策講座などに出席する。
自己分析して自己PRなどを練り始める。
企業研究。

2008年
・1月
学内説明会に参加する。
企業のセミナーに参加する。
興味がある企業に片っ端からエントリーしていく。
自己分析して自己PRなどを練り始める。
企業研究。

・2月
学校推薦が関連した学内説明会が始まってきている事実を知り焦る。
と思ったら丁度良いぐらいの時期だったようで、特に説明会を逃すことは無かった。
いくつかの企業の選考を進めていく。
進めつつ受ける企業の企業研究。

・3月
本格的に選考漬け。
おそらくスケジュールは一番この時がキツキツだった。
受ける企業の企業研究。

・4月
ヤフージャパンから内定をいただき、返事を待ってもらう。
他の途中の選考を切り、日立に集中する。
日立のジョブマッチングを受ける。
日立に落ちる。
丸々2日不貞寝。泣く。
寝ようとしても目が冴えすぎて寝れないので起きる。
ヤフージャパンへの返事期限が迫る。
もう一度何がやりたいのか、仕事に何を求めるのかを考え直す。
ヤフージャパンを辞退する。
立ち直ってきたころ、丁度NRIの二次エントリー〆切直前。
NRIに申し込む。
他にもいくつか弾数を補充するつもりだったが、行きたい企業があまりないので増えず。
NRIは企業研究をしているかどうかをかなり見られるらしいので、企業研究を頑張る。
NRI一次面接。通ってるかかなり不安だった。
結果待ちの不貞寝。
予想外に通っていたので、企業研究を超頑張る。
大学が始まる。
NRI二次面接。結構深く質問されるが、
一次よりも自分の気持ちと考えを伝えられたと思う。

・5月
NRI最終面接。
2〜3分で自己紹介してと言われたが、40秒ぐらいしか答えられなかったと思う。
もう少しアドリブ頑張ればよかったかな？と思う。
自分の中では自己紹介と自己PRは区別されているため、自己紹介は短い。
ここは自己紹介はおそらく自己PRという意味あいが強いのだろうか？
二次もあっさり自己紹介したら自己PRがないか聞かれたし。
GW突入。さっぱり休みという気がしない。
GW明けに内々定取得。



大体こんな流れだっただろうか。
大筋はあってると思う。
就職活動当初は無い内定を回避するため、
面接の練習をするためにとにかく色々な企業の選考をいれたのだが、
選考をあまり入れすぎた結果、第一志望群の企業研究が疎かになってしまった。
(といっても選考を進めている企業並みにはしているのだが)
日立に落ちて、ヤフージャパンの内定受諾をどうするか考えることを通して、
自分の中で仕事に求める軸がしっかりしたと思う。
NRIに関してはかなり企業研究を頑張った。
今まで受けたどこよりも、真剣に、時間をかけて、理解に努めた。
企業案内とWebページを熟読。説明会自体は2月頃に行ってた。
しっかりと企業研究を進めていくうちに、心からNRIに行きたいと思うようになった。
だから内定をいただけて、頑張った甲斐があった。

自分は自己PRなどの自分をよく見せるアピールの方にはかなり力をいれ頑張っていたが、
NRI以外の企業はどれも企業研究が甘かったと思う。
自分をよく見せる方に力を入れるあまり相手を理解する気持ちが弱かった。
人間関係と同じで、きちんと相手を理解することが重要だと思い知った。
当たり前といえば当たり前なのだが、その覚悟の度合いが甘かったと思う。
結果、日立でそれを思い知ることになる。
日立に落ちた時はめちゃくちゃ凹んだが、人間意外と立ち上がれるもんである。
しっかりと企業研究し、自分の求めるものを考え、精一杯頑張った結果、
今はNRIに行くことに迷いはないし、本当にここに行きたいと思う。

精一杯卒論頑張って、卒業して、NRIで社会人として頑張ります。
良い就職活動だった。

NRI内定いただきました。
後は卒業論文に集中するのみ。

ラウンドロビンDNSの問題点を解決した、
さらなる柔軟性・可用性・拡張性を持ったソリューションが求められた。
そこでサーバ負荷分散の登場である。
Webサービスは今や企業戦略上で重要なポジションを占め、
サイトがダウンすることは利益の損失に直結する。
負荷分散装置はサイトが受けるトラフィックを受け、
そのパケットを操作して負荷を分散する。
逆にユーザーにパケットを送り出す時にもパケットを操作する。

サーバ負荷分散の三つの強み
・柔軟性
サーバ負荷分散はいつでもサーバの追加・撤去ができ、
その効果を即座に現すことが可能である。

・可用性
サーバ負荷分散は利用できるサーバをチェックし、利用できないサーバには
処理を割り振らない。利用できる状態に復帰したサーバは、
自動的に処理が割り振られるようになる。

・拡張性
サーバ負荷分散はサーバの数を増やして処理能力を増強する。
一般的にハイエンドサーバの導入よりも多数の汎用サーバの導入の方が
安価かつ費用対効果が高い。

サーバ負荷分散の他に、負荷分散技術としては
・ファイアウォール負荷分散
・グローバルサーバ負荷分散
・クラスタリング
などがある。

このうちクラスタリングはサーバ負荷分散に似ているが、
サーバ負荷分散は負荷分散装置がトラフィックを振り分け、
実際に処理を行うノードは負荷分散していることを意識しない。
一方クラスタリングは全てのサーバ上でソフトウェアエージェントが動作し、
どのサーバがどの処理を行うか、などのサーバ間での緻密な連携が必要である。
また、クラスタリングは特殊なソフトウェアが必要なことが多く、
これらのソフトウェアの多くは限られたプラットフォーム上でのみ動作するものであるが、
サーバ負荷分散は負荷分散装置上で処理が完結しており、
サーバのプラットフォームに依存しない。

この本ではサーバ負荷分散を、負荷分散装置を用いて、
ネットワークトラフィックを複数のサーバに振り分けるものと定義する。

以前、インターネットは主に学術機関の中で使用されるものであった。
1995年頃から個人にも普及されはじめ、ネットワークが広がっていったが、
Webショッピングなどのインターネットを利用したサービスは少量で、
当時はまだ単独のサーバで対応することが十分に可能なアクセス数であった。
しかし、時が進むにつれて、徐々に企業がインターネットの有用性に気付き、
それに伴いトラフィックが増加し、何らかの形でそれらを処理できるようにすることが
必要となった。

処理可能件数を増加させたい時、まず初めに考えられるのは、
メモリの拡張やCPUのグレードアップでサーバの能力を増強することである。
しかし、この方法は、ハードウェアプラットフォームや使用するOSの制限で、
その拡張性は頭打ちになるときがくるし、
そうしたサーバのスペックアップを行う期間はサービスをダウンさせなければならない。

そこで柔軟性・拡張性が優れた方法としてサーバ負荷分散がある。
これは、サーバの数を増やせば増やすほどトラフィックの処理可能件数が向上し、
また、その際は新たなサーバを既存のサーバ群に加えるだけで良いため、
スペックアップのようにサービスを停止する必要がない。

サーバ負荷分散が普及するまでの方式としては、
ラウンドロビンDNSによる負荷分散が行われることが多かった。
ラウンドロビンDNSを用いるとホスト名に複数のIPアドレスを関連付けることが可能となる。
(revelation.a.ne.jpに192.168.1.2、192.168.1.3、192.168.1.4を関連付けるといった具合)
こうすると、名前解決の際にホスト名がそれぞれのIPアドレスのどれかに関連付けされ、
トラフィックが分散される。

しかしラウンドロビンDNSには、予測不可能なトラフィック分散やキャッシュ問題、
そして耐障害性に欠けるという欠点がある。

通常DNSの名前解決は、
1. ローカルDNSに問い合わせ
2. ローカルDNSにそのホスト名の関連付けがないならルートDNSに問い合わせ
3. ルートDNSよりそのホスト名を知る権限のあるDNSが紹介される
4. 権限のあるDNSよりそのホスト名のIPアドレスを知る
上記のようなプロセスで行われる。

毎回名前解決の際に、新たに権限のあるDNSに名前解決を行えば良いのだが、
一度名前解決を行った際に、DNSの負荷を減らすため、
その内容はキャッシュとしてローカルDNSに保存され、
次からはそのキャッシュ情報の有効期限が切れるまでは
1のローカルDNSに問い合わせをするのみで名前解決が終わる。

通常、ホスト名とIPアドレスの関連付けはそう頻繁に変わることはないため、
これによる影響は少ないのだが、ラウンドロビンDNSにおいては問題がある。

キャッシュ情報がある限り、
次回からは同じクライアントは同じサーバに関連付けされるため、
処理するサーバの偏りが発生する恐れがある。
また、サーバを追加し、トラフィックをさらに分散しようという時にも、
以前のキャッシュ情報が消えるまでは既存のサーバにしか処理がいかず、
新たに追加したサーバは導入後すぐにはトラフィック分散への貢献度が低くなってしまう。
これによりラウンドロビンDNSは速急なトラフィック処理可能数の増加には向いていない。

サーバ負荷分散技術とスケーラブルWebサイトという本を買った。
卒業論文では、負荷分散を行う[and|or]可用性を高めたシステムの実装を
行おうとしているのだけれど、そもそもそれらについてちゃんとしたことを
全然知らないな、ということで参考用に。
まあ、前から欲しかったので良いきっかけかな。

ざっと見た感じ、後者はシステムの上に乗るアプリの話がメインかな？
少々ロードバランシングについての話などもでるけれど、
それはあくまで一部であって、メインとしてはWebサービスの構築について
様々な視点から語られている。
これはこれで興味があるけど、卒業論文にはあんまり近くないかも。

前者の方は完全に負荷分散についてのお話なのだが、
これはかなり自分の考えている卒業論文に近い気がする。
レイヤ4レベルでのロードバランシングについてメインに書かれているっぽい。
どんぴしゃ。
ただ、この本はどちらかといえばソフトでの負荷分散というよりも、
ハードでの負荷分散という傾向が強いかな？
(本書ではソフトでの負荷分散はクラスタリングと定義され、負荷分散とは区別されていた)
でも、負荷分散についての基本的な考え方がまとまっているっぽいので、
大変参考になりそう。
とりあえずこちらを読み進めていこうと思う。

人間ってのはよくできてる。
同じ失敗を繰り返したり、同じ過ちを避ける傾向がある。

受けてきました。
とても行きたいので、通ってると良いな。
通ってますように。