Webアーキテクチャ設計術

目次

• 第27回 Webアーキテクトの仕事（後編）

  　選択した解決策は「アーキテクチャ説明書（記述書）」にまとめ，成果物として残します。

  2008.01.18

• 第26回 Webアーキテクトの仕事（前編）

  　これまでの解説を振り返りながら，Webアーキテクトの仕事の基本的なプロセスと成果物，心得を説明します。

  2008.01.17

• 第25回 アプリケーション設計と標準化（後編）

  　アプリケーション・アーキテクチャを固めたら，それに基づいて設計方法や実装方法の標準化を図ります。一般に標準化はプロジェクト管理者（PM）の仕事と考えがちですが，Webアーキテクチャとアプリケーション・アーキテクチャの両設計に関与したWebアーキテクトは，標準化のうえでもプロジェクト管理者を支援する…

  2008.01.16

• 第24回 アプリケーション設計と標準化（前編）

  　一般にWebシステム基盤の設計者とアプリケーションの設計者は別な担当者であることが多いのですが，アプリケーションはWebシステム基盤と整合性を取っていなければ正しく動きません。整合性を取るために，WebアーキテクトはアプリケーションSEの設計作業を支援することが不可欠で，設計支援するにはアプリケー…

  2008.01.15

• 第23回 運用性を高める・実践編（後編）

  　電子商取引システムは，不特定多数の利用者からアクセスが殺到してパフォーマンスが低下したり，ひどいときにはサービスが停止してしまったりすることが考えられます。こうしたサービス・レベルの低下を避けるには，稼働中のサーバーを止めることなく，サーバー・マシンを増設するだけでシステム処理能力を増強できる「ス…

  2008.01.10

• 第22回 運用性を高める・実践編（前編）

  　昨今のWebシステムは，社内系ではサーバー・リソースに余裕が多くある半面，社外系では過負荷な状態になりがちです。こうした傾向を考慮に入れ，相反する運用要件を満たす運用設計術を説明します。

  2008.01.09

• 第21回 運用性を高める・コンセプト編（後編）

  　一般に運用設計とは，運用業務プロセスや手順書などの作成を指します。しかし実際はそれらだけでなく，運用業務を自動化するために監視用のAPIを実装したり，運用証跡を残すためにロギング機能を追加したりと，システム設計に影響することもたくさんあります。だからこそ運用設計は，Webアーキテクチャの設計段階で…

  2008.01.08

• 第20回 運用性を高める・コンセプト編（前編）

  　システムは安定稼働して初めて，ビジネスを支援するという本来の目的を果たせます。だから，カットオーバー後の運用を見据えて設計しておくことは非常に大切です。最近でこそ「ITIL」という運用の標準ガイドラインも登場していますが，設計者や開発者の多くは，残念ながら運用の経験やノウハウを持っていません。その…

  2008.01.07

• 第19回 セキュリティを保つ・対策編（後編）

  　利用者の成りすましを防ぐには，経路上でのIDとパスワードの盗聴防止，認証・権限管理，既知の脆弱性補正――を考慮します。セッション管理設計も重要ですが，実務上はAPサーバーのセッション管理機能を利用することが多いので，ここでは説明しません。

  2007.12.21

• 第18回 セキュリティを保つ・対策編（中編）

  　ここからは，技術の選定と制約条件の確認に絞って掘り下げます。「外部から侵入できないこと」「内部犯行による情報漏洩を防ぐこと」「利用者の成りすましを防ぐこと」――という三つのセキュリティ要件を例に説明します。

  2007.12.20

• 第17回 セキュリティを保つ・対策編（前編）

  　セキュリティ要件から具体的な対策を導き出すには，7段階のステップを踏みます。

  2007.12.19

• 第16回 セキュリティを保つ・上流工程編（後編）

  　対策を検討するときは，情報を重要度や価値に応じて分類し，リスクの大小を見極めてメリハリを付けます。留意したいのは，機密性と可用性がトレードオフの関係になりやすいということです。例えば，USBキーによる情報の持ち出しを考えてください。すべての情報の持ち出しを全面的に禁止すれば，機密性は高まりますが，…

  2007.12.18

• 第15回 セキュリティを保つ・上流工程編（前編）

  　Webシステムは，攻撃を受けやすい特性を持っています。その理由の一つは，HTTPというシンプルなプロトコルを使うことにあります。テキスト形式のプロトコルなので，クライアントとサーバーが送受信するメッセージ内容を盗み見される危険があります。不正にリクエスト（要求）メッセージを書き換えられるかもしれま…

  2007.12.17

• 第14回 信頼できるWebシステムを目指す（後編）

  　サーバー機は1台しかなく，そのサーバー機が壊れるとシステム全体が停止する。このような場合のサーバー機のことを「単一障害点」と呼ぶ。システムの停止時間は，故障個所を修理して復旧するまでの間であり，この時間を「故障修理時間」という。

  2007.12.13

• 第13回 信頼できるWebシステムを目指す（前編）

  　本連載ではこれまで，Webシステムにとって重要な「可用性」と「パフォーマンス」について説明してきた。今回と次回ではその集大成として，次の要件におけるWebアーキテクチャを読者とともに考えたい。

  2007.12.12

• 第12回 パフォーマンス管理・実践編（後編）

  　システムが完成に近づいたら，実際に負荷をかけて，選んだネットワーク帯域やサーバー機が適切だったかどうかを確認したい。以下では，「同時リクエスト数の上限が100件/秒で，レスポンス時間が10秒以内」というパフォーマンス要件を満たしているかどうかの検証方法を説明する。

  2007.12.11

• 第11回 パフォーマンス管理・実践編（前編）

  　Webシステムのパフォーマンスを管理するには，「設計→実装→検証→対処→設計に戻る」というサイクルを回すと前回説明した。今回と次回ではこのサイクルの中でも特に重要な，「設計」と「検証」の実践法を説明する。具体的には，設計時にネットワーク帯域やサーバー機のスペック，台数などを見積もる「キャパシティ・…

  2007.12.10

• 第10回 パフォーマンス管理・待ち行列理論

  　Webサーバーに負荷がかかるとレスポンス時間が長くなるということは，「待ち行列理論」によって説明がつく。図1左は，Webサーバーでの平均待ち時間（Wq）を計算したものだ。リクエストの平均到着間隔をTa，平均処理時間をTsとすると，Webサーバーの利用率（ρ）と平均待ち時間（Wq）は図中のように表さ…

  2007.12.07

• 第9回 パフォーマンス管理・コンセプト編（後編）

  　実装後はパフォーマンスの変化を計測し，利用者の要件を満たしているかどうかを検証する。検証はソフトウエア構成とハードウエア構成に対して実施する。

  2007.12.06

• 第8回 パフォーマンス管理・コンセプト編（前編）

  　Webシステムに利用者からのアクセスが殺到すると，パフォーマンス上のトラブルが生じることがある。トラブルは，リクエストが受け付けられない，応答速度が低下するなどの現象として表れる。

  2007.12.05