スケーラブルWebサイト(1〜2章)

web 書評

著者がFlickrのエンジニアリング・マネージャーであり、「大規模なWebサイトの構築」に関する全般的な知識を得られるのではないかと思い読んでみました。
日本語の初版が発売されたのが2006年であり少し古いですが、書かれていることは、今でも勉強になる部分はたくさんあると思います。
環境は主にLAMP環境でサンプルコードはPerlとPHPが多いかなと思います。

以下、各章ごとにまとめや感想などを。

第1章 はじめに

  • ここでは、そもそもウェブアプリケーションとは？アークテクチャとは？についての定義がされています。
  • 優れたウェブアプリケーションの設計は、「トップダウンでまずネットワークとハードウェアのアーキテクチャが定義され、続いてプラットフォームを構成するコンポーネントが、そして各レイヤによって実現される機能が定義される」とされています。
  • そのアーキテクチャとは、後々発生しうる問題や要望に対応しやすいための基礎を設計することであるとされています。といっても、何でも対応できるようにとアークテクチャやフレームワークに多く盛り込みすぎると、それはそれで難解なシステムになって保守性が落ちてしまうかと思いますので、「シンプル」にということも大事かなと思います。
    • そうして考えてみると、シンプルで拡張を受け入れやすいアーキテクチャであることが大事かなと思います。

第2章 ウェブアプリケーションのアーキテクチャ

ウェブアプリケーションの階層
  • ウェブアプリケーションは下記のような階層化された構造になるということを、トライフルというお菓子に例えて説明されています。
    • 階層の構造
      • 永続的なストレージ→ビジネスロジック→ページロジック→インタラクションロジック→出力(HTML,XML,JSON...)
      • その他要素として、プレゼンテーションロジックがある。（CSSなど）
      • インタラクションロジックはSmartyなどのテンプレートエンジンで行う処理で、ページロジックはそのページごと固有の処理(出力する変数の取得、設定など)という理解でいいのでしょうか？？
インターフェイスの分離
  • また、画面ロジック(HTMLなど)とアプリケーションロジックの分離は、テンプレート化などの方法を取るにしても常に双方(画面ロジックとアプリケーションロジック)から分離を意識することが重要。
    • ファイルとしては分離されているけど、テンプレート側にアプリケーションのロジックが大量に記載されている例もよく観ますので、この辺りは注意すべき点だと思います。
    • デザイナーさんとの分業なども考慮すると、やはり画面ロジックとアプリケーションロジック間のインターフェイスをしっかり定義することが理想なんでしょうね。
  • アプリケーションの中でも、ページロジックとビジネスロジックを明確に分離しておくことが重要。
    • phpの場合は、ビジネスロジックをwebroot以下には置かず、拡張子も.phpでなく、.incにする。
      • 著者自身もこの方法については疑問を投げかけていましたが、PHPではこのような.incが使われているのでしょうか？perlの.pmみたいなもの？？
    • Perlの場合は、名前空間を分離する。ページロジックはMyApp::WWW::*、ビジネスロジックはMyApp::Core::*とすべき。そうするとMyApp::MobileやMyApp::WebServiceなどを簡単に追加できるからとあります。
      • 個人的には、ビューはビューでさらに階層を作ってまとめた方がいいんじゃないかと思いますがどうでしょう？MyApp::View::WWW::*やMyApp::View::WebServiceなどのように。
  • 各ロジック間でインターフェイスを定義し明確に分離することで、「あるインターフェイスの処理を別の言語に置き換えたり」、「データベースの変更やクラスタ化すること」が容易に実施できるようになるというのはその通りだと思います。
分離の流れ
  • 巨大関数に支配された世界や、プロトタイピングのウェブアプリケーションを分離していく流れとして、「ロジックとマークアップのファイルを分離する」→「マークアップコードを１ページ１ファイルにする」→「テンプレートシステムを導入する」→「ページロジックとビジネスロジックを分離する」を段階的に実施する方法が示されています。
    • またFlickerでは、コメントを格納するテーブルを操作する処理は全て一つのモジュールに入れているそうです。
      • インターフェイスを分離することは、MVCなフレームワークを使用していれば自然に行われるというものではないと思いますので、常にこれはどの層のロジックであるべきかということを意識することが重要であると感じました。
ソフトウェアとハードウェア
  • ここではウェブアプリケーションが稼働するハードウェアについて、導入や構築、ホスティングについての注意点が書かれています。
    • ハードやOS、ソフトウェアの選定する際は、「一般的なハードウェア」、「ビルド済みのOS」、「(OSと一緒に含まれている)}ビルド済みのソフトウェア」を使用することが、コスト面(時間を含む)で最善の判断であるとされています。(MySQLは例外でMySQL.comで入手した方がいい)
      • これについては、独自に調達したハードウェアでカーネルの設定をチューニングしたOSを使用し、ソースからコンパイルしたソフトウェアを使用されている環境も多く、異論があるのではないかと思います。ただある程度のアプリケーションであれば、ビルド済みのものを使用していても十分であるとも感じますが。(そのある程度がどの程度であるかは難しい判断だとは思いますが。。)
  • また、サーバーの配置環境として、「共有ハードウェア」→「専用ハードウェア」→「コロケーション」→「セルフホスティング」を挙げられており、それぞれの利点や注意点なんかが挙げられています。
  • その他、ハードウェアを自社で保持している場合の注意点として下記が挙げられており、こうして改めて記載されるととても参考になります。
    • ハードの入手可能性と調達期間
      • これはまぁ当然ですよね。前述した「一般的なハードウェア」という部分にも関連する部分だと思います。
    • 輸入、出荷、設置
      • これは国をまたいだホスティング、ハードウェアの輸入をしている際に考慮する問題ですね。
    • 場所
      • 規模が大きくなってきた場合に問題となる項目ですね。ラック、電源、ケーブルの敷設など。
    • 電源
      • UPSやアンペア数など見落としがち(!?)な項目なのかなと思います。
    • ネットワーク
      • バックアップ回線の有無や接続速度(100-baseT、1000-baseTなど)
その他
  • データがどう流れているかをTCP/IPスタックを意識して理解するなど、ネットワークの基礎を理解しておくことの重要さについても書かれています。この辺りはウェブアプリケーションを作る場合には、理解しておきたい部分だなと思います。


と、２章はこれから詳細に語られる内容について触れられた概要的な章になっています。

続きはまた後日書いていきたいと思います。