●システム基盤とは何か

Webシステムのシステム基盤とは、サーバーのOS、Webサーバー、データベース、開発言語の組み合わせのことを指します。
このシステム基盤はいろいろなパターンが存在しますが、どのような組み合わせにするかで運用のしやすさやその後のコストが変わってきます。

●オープンソースのシステム基盤の代表【LAPP】

ラップと呼びます。Linuxを中心としたオープンソースの組み合わせで、OSにLinux、WebサーバーにApache（アパッチ）、データベースにPostgreSQL、開発言語にPHPを用いたシステム基盤のことです。

この組み合わせは定番中の定番で利用者も多く、安心して利用できる組み合わせです。
もちろん全てオープンソースならではの低価格メリットがあります。

ところで、この組み合わせのうち、開発言語のPHPは、特にWebシステムに適している上、ライトウェイトランゲージ(LL)の代表格ともいえる言語です。

ライトウェイトランゲージ(LL)は、習得難易度が低く、さらに少量のコードでやりたいことが実装できる言語のことを指しており、その結果、開発・保守の費用を低減することができます。

※ PHP以外のPerlやPythonなどの言語を使う場合でも、頭文字がPHPと同じ"P"であることからLAPPと表現されます。

●もう１つの代表的なシステム基盤 Windows

マイクロソフト社製品の組み合わせもお勧めです。
OSにWindows Server、WebサーバーにIIS(OSに付属)、データベースにSQL Server、開発言語にASP.NETとC#を使います。
主なメリットは以下の３点です。

• クライアントOSのWindows XP,Vistaと同様の操作性で使い勝手が良いこと。
• 有料でサポート（問い合わせ）が可能であること。
• 言語およびライブラリが優れていること。

●その他の組み合わせ

上記のほかに商用UNIXやOracle, DB2などのデータベース製品、Javaなどのメジャーどころも数多く存在します。
いずれにしてもメリット・デメリットを勘案して選択することになります。

●ところでお勧めは？

この数年、私が携わったシステムではここで紹介した２パターンのどちらかが適しているケースが多かったと思います。構築完了後に社内で自力でメンテナンスするのであれば、マニュアルや書籍が揃っていて、保守のしやすいWindowsがお勧めです。

逆に小規模システムを導入して、システム開発会社に保守を行わせるのであれば、LAPPが低コストでメリットがあるかと思います。

今回ご紹介した２パターンは有力な候補として参考にして頂ければ幸いです。

●主流はPDFを生成する仕掛け

大量出力には向いていないことさえクリアできれば、やはり帳票はPDFをサーバーで生成する仕掛けを採用することが一般的です。

オープンソースではPDFlib+PDIがお勧めです。 PDFlibはPDFの生成ツールで、PDIは既存のPDFに文字や画像などを追加するためのソフトウェアです。 これは、ワープロソフトなどであらかじめ罫線だけのPDF（オーバーレイ）を作成しておき、プログラムから座標指定で文字を配置することで、PDFを生成する仕掛けになります。 PDFlibはオープンソースです。もちろん比較的安価に導入することができます。

別案もあります。ここでは紹介しませんが、優秀な製品もいくつか存在します。これらの製品は、専用のツールで帳票のレイアウトを厳密に設定できるなど、生産性のすぐれていることが多く、帳票出力があるシステムを構築するときは、一定の初期導入コストはあるものの、検討するだけの価値があります。

●社内利用なら実はExcelを使う方法も

社内システムであれば、帳票出力にExcelを使う方法もあります。個々のPCにExcelがインストールされているのであれば、実は最も低価格かつ応用も利く方式です。Webで印刷ボタンが押されるなどのユーザー操作をきっかけに WebサーバーでExcelのデータを生成し、クライアントにレスポンスとして返すようにします。

クライアントのPCでは自動でExcelが起動されます。ユーザーは帳票イメージをExcel上で確認したのち、Excelの印刷ボタンを押して印刷を行います。

●サイジングの要素

サーバーの性能や台数を決めたり、必要な回線速度を決める前に必要な性能について考える必要があります。
一般にこの性能要件を検討する作業をサイジングと呼びます。 Webシステムのサイジングでキーとなるのは以下の２点です。

• 単位時間あたりのアクセス数のピークと平均
• 作成するシステム（アプリケーション）の重さ

●現実的な方法

設計段階で完全な見積もりは困難な場合が多いのですが、 通常は利用者数や処理されるデータの件数などを基礎に一定の安全率を掛けてサーバーのランクや台数、ネットワークの太さに対する要件を整理します。

●サーバーで重要なのはメモリの量とCPU速度

サーバーの性能は十分なメモリが搭載されていれば、あとはCPU速度が重要な指標となります。
ディスクの速度については、十分なメモリがある場合、大部分はキャッシュされるため、あまり重要視されないことが多いようです。

●レンタルサーバーも検討の価値あり

Webシステムを構築するのであれば、サーバーをどこかに設置することになります。 社内利用の場合はもちろんサーバーは社内に設置することになるかと思います。（セキュリティ上の観点からもそのほうが望ましいです。）

インターネットからアクセスされるシステムを構築する場合は、自社にサーバーを置くと、もちろんインターネットに接続するための回線を確保する必要があります。ただしこの回線コストは切れないことを前提として品質管理されるため、比較的高価です。
回線コストを節約するためには、レンタルサーバーやホスティングサービスを利用する方法があります。最近では価格が安く、かつ品質があり、融通の利くサービスが増えてきており、ある程度の規模の場合であっても一考の価値があります。

●ボトルネックになりやすいのはデータベースへのアクセス

経験上、レスポンスが問題になるときは、極端なボトルネックがあることがほとんどです。「プログラムの10%が処理時間の90%を消費する」と言われるほど問題点は局所化する傾向があります。

ボトルネックになりやすい箇所の第１位は、データベースへのアクセスです。

データベースに関連した部分の開発は相当以上に気をつけて設計・実装する必要があります。構造に無理があったり、セオリーに反した実装にすると、簡単にそこがボトルネックになってしまいます。

余談ですが、現在主流のデータベースはリレーショナルデータベースと呼ばれます。実はこのリレーショナルデータベースはコンピュータの性能が有限であることを無視した理論からスタートしたものです。つまり生まれながらにして、レスポンス問題が発生しやすい部分と言えます。

●データベースを扱うときのセオリー

少々専門的になりますが、たとえば以下のようなセオリーが存在します。

• システムの全体像を俯瞰してからテーブル構造の設計に着手するようにします。
  例えば、ある程度大規模なシステムを開発するときは、テーブル構造の設計のための専門チームを立ち上げますが、そのチームは全体の仕様を把握するようにするのが普通です。
• どのようなアクセスが行われるかを考えてテーブル構造を設計します。
  常に無理がないようにすることが大切です。
• テーブルは適切に正規化し、極端な設計にしないようにします。
• 検索は常にインデックスが使われるようにします。
  例えば、【条件指定した文字列を含むデータを検索する処理は、インデックスが効かないので、できる限り使わないようにします。（前方一致はインデックスが効くので大丈夫です。）
• 複雑なSQLを書かないようにします。
  SQLが複雑になりすぎる場合、テーブル設計に問題がないか疑うべきです。
• バランスを重視します。
  構造の理解しやすさや、アクセスのしやすさや、レスポンスの確保しやすさなど、複数の要求をバランスよく満たすのが良い設計です。

●後勝ちの排他制御

今時は、Webの求人広告もWeb上の管理画面で原稿の確認・修正ができるようになっています。

だいぶ前の話なのですが、複数のメンバーで求人広告の確認作業と修正を行ったことがあります。
そのとき、修正した内容が元に戻る現象が発生しました。 おそらくは、こんな操作だったと思います。

• Ａさんがページを開く
• Ｂさんがページを開く
• Ａさんがある個所（たとえば電話番号）を修正して保存
• Ｂさんが別の個所（たとえばファックス番号）を修正して保存

すると、この地点でＢさんが保存したデータの電話番号は、Ａさんが修正を行う前の状態なので、
Ａさんの電話番号の修正が元に戻ってしまう。

いわゆる"後勝ち"の方式です。
これはこれで誤っているとは言いませんが、もっとよい方法はないのでしょうか。

●楽観的なロックを採用して気の利いたステムに

実は答えは簡単です。保存するときに、ページを開いたときから更新されているかチェックすればよいのです。
まず保存するデータ構造に更新日時か更新番号を用意して、 ページを開くときにこれを読み込みます。

そして、ユーザーが書き込み操作を行ったら、もう一度このデータを読み込んで更新されていないか（つまり他の誰かが更新していないか）をチェックします。

並行して処理が実行されないように、この読み込み処理は明示的なロックを伴って実装します。(SQLを書くときにSELECT FOR UPDATEを使います。)そして、最後にデータを更新してロックを解除すればOKです。

実はこの方式は楽観的ロックと呼び、一般的な手法です。
書き込む直前まで他の誰も書き込まないことを期待する手法なので"楽観的"と呼ぶのです。

ちなみに同じデータを２人の人が更新しないように、ページを開く段階からロックすることを悲観的ロックと呼びます。

この２種類のロック、システムの実態に応じて使い分けるべきものですが、通常、Webシステムではクライアントがブラウザを閉じたことをサーバーが察知できないので、楽観的ロックで問題が発生しないように画面構成を設計することが一般的です。

上記のとおり、実装は比較的簡単です。細かいところまで気の利いたシステムがいいですよね。