xxxさんの備忘録

xxさんのブログです.xxさんはネカマです.

『新人エンジニアのためのインフラ入門』chapter9~13

##Chapter9 インフラエンジニアの仕事

メインフレームのメリットは「安定性」があることである。
対する、オープン系システムは「様々な製品」が「様々なメーカー」から提供されている。
そのために障害が起きることもある。

1、ハードウェアの不具合
MACアドレスの重複の問題切り分け
NICの問題
2LANケーブルの品質低下
3接続先ネットワークスイッチとの相性
4OSのネットワーク設定に不備がある
5接続先ネットワークスイッチの設定に不備がある
冗長化特有の問題


まず、6を確かめるためにネットワークの冗長化の設定を解除して単純化構成にした。
3、5に関してはネットワークチームを巻き込む必要があったため、先延ばし。
1、2、4について確かめた。
この流れで調べたところ1の可能性が高まった。
これを確認するために、パケットキャプチャをPingを投げながら実施した。

ハードウェア面での不具合はとりわけ時間のかかるため、構築工程の早い段階で顕在化できるように
受け入れ確認やテストを計画する必要がある。

 

 

2、ソフトウェアの不具合
linuxOS上にNetBackupというバックアップソフトウェアをインストールしてoracle領域をバックアップするという構成
・バックアップを取得している最後のタイミングでエラー終了してしまう。という事象が発生した。

この場合の問題切り分けでは
1OSが悪いのか
oracleが悪いのか
3Netbackupが悪いのか
の問題をインフラエンジニアが切り分ける必要がある。
→→・ファイルシステム領域のバックアップ:成功
・raw領域(ファイルシステムをスキップ)のバックアップ:失敗
次に、rawアクセスはOSが提供している機能のため、OSが怪しいのではないかと仮説を立てた。

cf:
・ddコマンド raw領域を扱うことのできるコマンド
・staceコマンド プロセスが使用するシステムコールなどを可視化できる。
つまりコマンドを打った時の動きを通常より細かい単位で確認することができる。


これらのコマンドを使用し、仮設(コマンドも最後に失敗し、その時に細かいエラー内容をOS上で確認できるのではないか)
を確認した。

 

 

3、組み合わせによる不具合
サーバーとサーバ、ネットワーク装置の組み合わせにも注意点はある。
その中の代表的な一つとして 通信タイムアウト がある。
通信には一定時間やり取りがない場合接続を切断するための「タイムアウト値」が設定されている。
普段は問題にならないが、サーバ、OS、ミドルウェア、ネットワーク装置が
関連するとお互いのタイムアウト値に矛盾が発生することがある。

ex)「コネクションプールの未使用タイムアウト(30min)」と「ファイアウォールの無通信タイムアウト(15min)」
この場合、15分以上使用されていないコネクションプールはファイアウォールによって強制的に切断される。
ファイアウォールで切断されたことを知らないAPサーバは「接続できているもの」として扱うため、
実際にコネクションプールを使用して接続するとDBサーバからの応答を待ち続けてしまう。

このような製品間の隙間のようなものに、インフラエンジニアは精通・対応できるように日々基礎知識を身に着けておく必要がある

 

 

・コラム アジャイル開発について
ウォータフォール型の開発→要件定義、設計、構築、テスト
アジャイル→短期間で設計、構築、テスト を繰り返しながらプロジェクトを推進する手法
(その都度での問題点の修復可能なのがメリット)


##chapter10 構築とテスト


・構築とは
前段フェーズの「設計」を通して作成される設計書やパラメータシートに従ってハードウェアとソフトウェア
(OS、ミドルウェア)の設定を行い、システムを実際に組み上げる作業を指す。
 ・サーバ BIOS設定、HBA BIOS設定、ハードウェアRAID設定
 ・ストレージ 筐体設定、ディスク関連設定、オプション(コピーなど)設定
 ・テープ 筐体設定、テープメディア装填
 ・ネットワーク ルーティング設定、VLAN設定、アクセス制御設定、負荷分散設定
 ・OS インストール、ライセンス登録.......
 ・ミドルウェア インストール、各種設定
 
 ↓
これらを技術領域に分けて対応することもある
ファシリティ ハードウェア・ソフトウェアの調達、ライセンス管理、
 工事(ラック、ケーブル)統括、データセンター関連作業統括
サーバ・OS  サーバ・ストレージ関連作業、OS関連作業
ネットワーク ネットワーク関連作業
Web・AP    Web、AP
DB      DBに関連する作業
運用     運用に関連する作業

 

 

・構築の現場
1、構築準備
類似の環境を作成し構築の検証や手順の確認を行っていく。
実際に確認することで設計ミスやソフトウェアのバグ等で上手くいかない部分が見える。
(最近では、類似の環境に仮想サーバやクラウド上のサーバを使用することも多い)
検証や手順確認が完了したら、「構築手順書」を作成していく。
プロジェクトによって粒度は様々である。
また構築に必要な資材(メディアやライセンス、設定ファイル、スクリプト、作業端末)もこのタイミングで準備を進める

2、構築形態
ミドルウェアの構築では、インストールや設定する際に関連するサーバが必要な場合があり、
構築の前後関係やスケジュールに注意が必要。
「サーバ単位で動くもの(対象サーバに設定ファイルで設定)」と
「Manager-Agent構成のもの」
ex 監視用のミドルウェアの場合 監視対象のサーバにAgent 監視状況を管理するサーバにManagerをインストールする。また複数台のサーバ間で通信が必要となるため、ネットワーク周りの設定も必要になる場合がある。
Agentから送られたデータをManager側で受信し、監視できる状態になれば完了である。
が存在する。

 

 

3,構築環境

・開発環境
アプリケーションエンジニアがアプリケーション開発を行う環境

・検証環境
テスト環境とも呼ばれ、本番環境でアプリケーションを動かす前にテストや検証を行う環境。
本番よりもコストを削った構成になっている

・本番環境
実際にユーザへサービスを提供する環境。
ネットワーク上に既存のシステムが稼働している場合もあるため万が一失敗があると周辺のシステムに影響が出る。

 

4、構築Tips

 

 

・作業ログの取得
"script"コマンドは作業ログを残すコマンドである。
作業後にサーバの挙動がおかしくなった際に潔白を証明する材料にもなる。

 

・構築資材の確認
構築に必要なパッケージやファイルを転送する際に転送モードを間違えたり、
転送が不完全だったりするとデータが破損する場合もある。
それを確認するためのコマンドが"cksum","md5sum"である。
コマンド引数にファイルを指定することでファイル内容を元に計算された英数字が出力されます。
これを転送前、転送後で実施し比較することでファイルの破損を確認します。

 

・設定差分の確認
"diff"コマンドは2つのファイル内容を比較し、差分を出力する。
構築中に設定ファイルを編集する場合には必ずバックアップを取得するが、
このバックアップファイルと編集後のファイルをdiffコマンドで比較し、
変更箇所と変更内容が意図したものかどうかを確認する。

 

5,構築の自動化
近年では構築をツールで自動化する手法に注目が集まっている。
代表的なツールとして
Chef(webサーバ構築ツール)、Ansible(構成管理ツール)、Puppet、
といったものがある。
作業者の負担やコストを抑えられるといったメリットがある。
rubyPythonといったような言語の取得が必要になる)

 

●テストとは
テストとは構築したシステムが設計書通りに作られているかを確認する作業である。

 

●テストの現場

 

1,テスト準備

まずテスト計画書を準備する。
テストの目的をはじめ、体制やスケジュール、観点、合格基準なども記載していく。

次にテスト仕様書を準備する。
テストの内容と手順、期待する結果、対象などが記述されており、
実施者はこの内容に従って作業を実施していくことになる

併せて、テスト実施に必要な環境(通信先サーバーや負荷端末など)や
データ(テスト表示用のHTML画面やDB接続をするアプリケーションなど)も用意する。

 

 

cf.ウィルス対策製品をテストする為にテストウィルスを準備したら、
自分の端末のウィルス対策製品で検知されてしまった.......ということなどもある

 

 

2,テストフェーズ

単体テスト
OSやミドルウェアの設定、動作を単体でテストする

 

結合テスト
複数の機能を組み合わせた連携が可能かをテストする。
非機能要件に従って設計された基本設計内容を確認するのが大きな目的である。

 

結合テスト
本番環境で正常に動作するかを確認する。
システムの性能を計る性能試験、実際の運用時に想定される負荷に耐えられるか検証する負荷試験などがあげられる。

 

 

3、テストの自動化
テストにも自動化ツールが存在する。

 

 

●構築とテスト
OSにもミドルウェアにも言えることだが、設定を行った人間は「正しく設定を行ったつもり」になりがちである。
そのため「第三者によるチェックが不可欠」である。


##chapter11 バックアップ・リストア

●バクアップ・リストアとは

 

1,バクアップとは
データ損失に備えてデータを複製することをバックアップという。
システムは年中無休で動いているため、ハードウェア障害やソフトウェアバグ、
人的なミスなどデータを損失する危険性は身近に多くある。

システム上のデータは「数が多い」、「容量が大きい」「更新頻度が高い」といった特性があり、
単純にバックアップするだけでも大変である。

 

・数が多い
webコンテンツやアプリケーション関連ファイル、日々蓄積されるログファイルなどシステムに関わる
データは数が多い。数が多いことでファイルごとにオープン・クローズが発生しオーバーヘッドも大きい

 

・容量が大きい
DBデータのようにテラバイト級のデータも珍しくない。
容量が大きいことでネットワークや保存先のメディアを多く消費し、バックアップ時間も長くなる

 

・更新頻度が高い
DBのように常に更新され続けているものも多い。
更新途中のデータは複製できないため静止点を確保する必要がある。

ある程度のシステム規模になると専用のソフトウェア(ミドルウェア)を用意し、バックアップ作業を運用している。
またバックアップ先にはディスクストレージやテープ装置を使用している。
業務システム用の製品は、ソフトウェアとして公開されている製品もあるため一度インストールしてみるとよい。

 

 

2,リストアとは
データ損失が起きた際に複製しておいたデータから戻すことを「リストア」と呼ぶ。
リストアにも「年中無休で動いているシステムのデータ」という扱いの難しさがあり、
データを戻すだけでは終わらないケースも多々ある。
また、スピードを求められることが難しいところである。

システム構築中にもリストアテストを実施する機会はありますが、
テスト運用中のシステムにおいて実際にデータが入った状態でスピードを求められながら実施しなければならないという点において難しさがつく。
リストアの方法にも様々な選択肢があるが、可能な限りシンプルに設計することが基本になる。

 

 

3,リカバリとは
リストアが「バックアップしたデータをバックアップした状態で戻す」ことを指すが、
リカバリは戻したバックアップデータに何らかの処理を加えてデータを正常化・最新化することを指す。

主にデータベース復旧の場面で使用されており、
ベースとなるデータに更新ログを適用することで障害発生直前の状態までデータを復旧させる。
(ただしログファイルまで損失した場合は復旧できない)


●バックアップ・リストアに必要な知識
1,ハードウェア

ストレージ装置(SANストレージ)、テープ装置(LTO)がある。
ストレージ装置のメリットは扱いやすさと処理速度である。
またディスク間の複製といった高速処理機能も備えており、バックアップ時間の短縮につながる。

テープ装置のメリットはバックアップデータの保管コストが低い点である。
過去のバックアップデータを一定期間保管すると保管コストを無視できない。
数日前のデータベースのバックアップは相当なことがない限り不要だが保管品しなければならない……といったような
データの保管にはテープ装置が向いている。
また記憶媒体を持ち運べるといったメリットもあり、
システムとは別の場所に外部保管する運用を行っているケースもある。

 

 

2,ソフトウェア

専用のソフトウェアを利用したバックアップ運用を行っている。
それらの大まかな運用の支援する機能をまとめる。

 

・集中管理
システムの各サーバに対するバックアップ設定やバックアップ・リストア実行を
管理サーバから集中管理することが可能。

 

 

・バックアップデータの管理
バックアップ実行日やサーバごとにデータを参照する・古いデータを削除するなど

・増分・差分バックアップ
データの更新部分だけをバックアップすることでバックアップの時間の短縮が可能

・バックアップ監視
バックアップ状況を監視し、失敗したジョブの把握・再実行等が容易

・スケジュール実行
あらかじめ設定した時間にバックアップを開始することが可能

 

3,運用
運用においては定期的に行う作業と不定期で行う作業が存在する。
定期作業ー「監視」「ジョブ管理」
不定期作業ー「障害復旧」
などがある。

また、バックアップに限ると
定期作業 ー「データやログのバックアップ」
不定期作業ー「システムのバックアップ」
などが該当する。

・「フルバックアップ」

・「差分バックアップ(フル+差分)」

フルバックアップ後に追加されたデータを取得する。
差分バックアップ後にさらに差分バックアップを実行した場合には、フルバックアップ後に追加されたすべてのデータを取得

 

・「増分バックアップ(フル+増分バックアップ)」

フルバックアップ後に追加されたデータを取得する。
増分バックアップ後にさらに増分バックアップを実行した場合には、前回の増分バックアップ後に追加されたデータのみを取得

 

 

●サーバごとのバックアップ方法


1,webサーバ
webコンテンツなどはデータ容量も小さく更新されるタイミングも頻繁ではないため、
アクセス数が少ない深夜帯やコンテンツ更新などのタイミングでバックアップすることになる。

また、容量の小さなデータが大量にあるという特性があるため、
NASやバックアップサーバにネットワーク経由で転送するといった実装が多くなる。

Webサーバでは大量のアクセスログが発生するが、これらのログもバックアップ対象になる。

 

2,APサーバ
データの特性はWebサーバと似ているため、Webサーバと同様のバックアップ方式を採用することが多い。
アプリケーション関連のデータも存在するため、システムごとに対象データが決定しておらず総量が見積もりにくい。

WebサーバでもAPサーバと同じく大量のアクセスログが発生するが、これらのログもバックアップ対象になる。


3,DBサーバ
データ容量が大きく更新も頻繁に発生している。
バックアップの方法はデータベースミドルウェアに何を使用しているかに依存する。
大まかにわけて「オフラインバックアップ」と「オンラインバックアップ」に分けることができる。

 

・オフラインバックアップ
データベースを停止し、データが更新されない状態でバックアップを取得する方法。
データの整合性が取れた状態でバックアップを行うため実装も単純でリストアも
基本的にバックアップを戻すだけで完了する

 

・オンラインバックアップ
データベースが動作しており、データの更新されている中でバックアップを取得する方法である。
基本的には、データベースの更新は変更内容がログファイルに書き込まれた後で反映される仕組みになっているため、
バックアップ中のデータファイルへの更新を停止してデータファイルをバックアップするのが主流。
障害の発生状況(欠損したファイルの種類)によって
リストア・リカバリの内容が変わってくるためリストアの難易度も上がる。

 

 

4,その他のサーバ
その他のサーバに関しても基本的にミドルウェアに関する管理データをバックアップする。
製品ごとに管理情報を出力する機能があり、それらをバックアップする。

 

●コラム「運用と保守」

運用ーシステムを止めずに動かすことであり、それに伴う作業を実施することである。
不慮のデータ損失に備えてバックアップを取得したりと、システムが提供するサービスに問題が起きないようにする。

保守ーシステムの改善や機能拡張をすることである。システムに手を加える。
バッチの適用やアプリケーションの機能追加、チューニングを実施する


##12セキュリティ

●セキュリティとは

1,非機能要求グレード
非機能要求グレードはシステム発注側と受注側での認識齟齬を防ぐ目的で、
非機能要求としてまとめるべき項目を体系的に整理したツール群のことを指す。

 

 

●セキュリティ要求に対するインフラの対応

 

1,アクセス・利用制限
アクセス・利用制限は「認証機能」、「利用制限」、「管理方法」から構成されている。

 

・認証機能
現在のシステムではIDとパスワードを使用したユーザ認証が主流。
認証を行う場合にはインフラとして認証基盤が必要となり、
その選択肢はOS標準の認証機能、認証ミドルウェアRADIUS製品、ActiveDirectoryなど)複数存在する。
それぞれの特徴を把握し、システムごとにアプリ担当者と決めていく。

 

・利用制限
承認されたユーザごとに使用できるリソースに制限すること(OSでも可能)。
ミドルウェアも制限をかけることができ、データベースに接続する権限やデータベースを作成する権限などがある。
このような利用制限を設計するのもインフラエンジニアの仕事であり、
アプリケーションの実装とも関係してくるため、業務用のユーザ権限に関してヒアリングを行う。

2,データの秘匿
システムが扱うデータには「ネットワーク上を流れるデータ」、「各サーバや危機に蓄積されるデータ」がある。
データを秘匿するには暗号化する方法があり。暗号化しておけば万が一データを盗まれても中を見ることができない。

暗号化をする際には、元のデータを「暗号化アルゴリズム(DES、AESなどがある)」に従って暗号化する。
しかし、暗号化アルゴリズムは誰でも入手できるものなのでそのままでは簡単に復号化されてしまう。
そこで利用者ごとに暗号化内容を変化させる「暗号鍵」が必要となる。

インフラエンジニアの作業としては、暗号化する対象や暗号化アルゴリズムプロトコル、暗号鍵の複雑さ
などを決めていく必要がある。
性能とのトレードオフといった側面もあるため注意が必要となる。
現在のシステムでよく使われている暗号化には以下のものがある。

 

 

・インターネットからロードバランサー・Webサーバ間の通信データをSSLTLSにより暗号化
・DBサーバの重要な一部のデータの暗号化

 

 

3,不正追跡・監視
「不正追跡・監視」は「不正監視」と「データ検証」から構成されている。
ここではシステムを監視して不正を検知することが目的となる。

 

・不正監視
不正監視にはログの確認が有効である。
ログにも「OSログ」「ミドルウェアログ」「アプリケーションログ」、
そして「ネットワーク機器のログ」などがある。
運用ミドルウェアを導入して一元管理することになるが、
大量のログになるために通常は事前に設定したフィルタに引っかかった
ログと個別に指定したメッセージのみが表示されるようにしている。

なお、事前にフィルタ設定したもの以外でも有事の際には解析で必要となるログもあるため、
通常は管理サーバで定期的にログを収集して保存している。

 

●データ検証
データの改ざん検知に関する項目だが、ネットワーク上を流れるデータと
各サーバや機器に蓄積されるデータについて考える必要がある。

通信データに関しては「デジタル署名」を使用するケースが多く、
送信側と受信側でデータのハッシュ値を取得して比較することでデータが改ざんされていないことを確認する。

蓄積されているデータに関しては、改ざん検知ソフトウェアを導入することになる。
監視対象機器に導入してデータの改ざんを検知する方法や
監視サーバなどに導入してユーザと同じ方法でアクセスし、その結果から改ざんを検知する方法などがある。

 

4,ネットワーク対策
ネットワーク対策は「ネットワーク制御」「不正検知」「サービス停止攻撃の回避」から構成される。

 

●ネットワーク制御
通信制御を指すことが多い、選択肢としてTCP/IPにおける各層での制御がある。
ネットワークインターフェース層ではMACアドレスによる制御、
インターネット層ではIPアドレスによる制御、
アプリケーション層ではアプリケーションデータ内容による制御
が可能となる。

ここでよく利用されるのは「L.3スイッチ」や「ルータ」、「ファイアーウォール」
といったネットワーク装置に実装されているアクセス制御を利用したものである。
また、サーバサイドでもOSに実装されているファイアウォールを利用して
アクセス制御しているシステムもある。

 

●不正検知
同一IPから複数ユーザIDでログインしているなど
通常の利用ではありえない通信に関しては不正に検知するための対策が必要となる。
その対策として利用されているのが「IDS」や「IPS」といった製品である。
ネットワークやサーバに製品を導入することで、やり取りするパケットの内容を監視する。
(IDS-警告の表示、IPS-不正アクセスの遮断、IDS/IPS機能を追加した「UTM」という製品もある。)
これらは「何を不正とするか」というチューニングが必要である。

 

●サービス停止攻撃からの回避
DoSDDoS攻撃といったネットワークを混乱させる攻撃に対する対策。
通常DoS攻撃は単一の送信元からアクセスされるため、当該アドレスをネットワーク制御するといった対策が可能
DDoSは対象が複数となり、変化するため選択肢として、DDoS攻撃に対応したファイアウォールや外部サービスを利用するといった対策がある。

 

5,マルウェア対策
マルウェアは対象機器に害を与えるように悪意を持って作成されたソフトウェアなどの総称である。
その種類にはトロイの木馬、ウィルス、ワームなど様々ある。
一般的には対策ソフトウェアを導入することで、対策する。
対策ソフトウェアはサーバをスキャンしてマルウェアを検知する。
サーバで使用する際の注意点としては、DBサーバ上の大きなファイルやダンプファイルを除外する設定をしておかないと、スキャンプロセスでCPUを使い切ってしまう点である。

 

 

6,Web対策
最近ではWebサーバの前段に「WAF(Web Application firewall)」と呼ばれるwebアクセスに特化した
ファイアウォールを配置してパケットを制御する構成をとるシステムもある。
通常、ファイアウォールではアプリケーションの中身までは確認しないが、WAFではその中身まで確認して
不正なアクセスの場合は遮断する。ただし、導入するためにはシステムに合わせて設定をチューニングする必要があり、
実際には本番のアクセスデータがないと設定が完了しないため、導入には時間やコストが必要である。

 


##Capter13 プログラミング

4,コンパイル方式とインタプリタ方式
ソースを作成した後、コンピュータで実行するためには機械語へと変換する必要がある。
この変換にはコンパイル方式とインタプリタ方式が存在する。

 

コンパイル方式
コンピュータの実行前にソースプログラムを機械語で書かれた実行プログラムへと変換する。
事前に実行プログラムへと変換しておかなければプログラムを実行できない。
メリットは実行速度が速い点である。

 

インタプリタ方式
コンピュータの実行時にソースプログラムを機械語に変換する。
ソースプログラムを作ったら即実行してみるという形で手軽に動作を確認し、問題があればすぐに修正できる。
このメリットはメンテナンス性だが、速度面でデメリットがある。

 

 

●システムとプログラミング

 

1,システムにおけるプログラミング
・プログラムとソフトウェア

 

2,インフラにおけるプログラミング
「ツール」をインフラエンジニアがプログラミングする対象になりやすい。
(ex,システム運用をする中で必要となる自動化ツール)

●様々な言語

windowsバッチスクリプト
windowsコマンドプロンプトに実行させる処理を記述してツールを作る

 

PowerShell
使い方はバッチスクリプトと同じ
バッチスクリプトよりも扱えるコマンドが増えている。
windows環境で少し複雑なツールを作成する場合にはPowerShellを選択することが多い。

 

 

UNIXシェルスクリプト
UNIX系OSにおけるツールは基本的にUNIXシェルスクリプトで作成している。
注意点は実行するシェル環境によって微妙な差分が存在することである。

 

 

Python,Ruby
さらに複雑な処理を行う場合や実行速度を気にする場合に選択される。
また、このような言語では「ライブラリー」と呼ばれる様々な便利ツールが公開されていることも大きなメリットであある。

 

●プログラムの構造

 

1,順次処理
処理を順番に実行する方法。

 

2,分岐処理
分岐処理は条件によって実行する内容を変える方法。

 

3,反復処理
反復処理は同じ処理を繰り返し実行する方法。

 

●実行形態
実際に作成されたプログラムはどのように実行されるか。
通常は運用ミドルウェアの一つである、
ジョブ管理ソフトウェアが導入されておりスケジュールに登録することで自動実行している。

また、小さなシステムでジョブ管理ソフトウェアが導入されていない場合にはUNIX系であればCron、windows系であればタスクスケジューラという自動実行を支援するツールが用意されているため、
そこに登録し自動実行することになる。

 

 

なおここで注意が必要な点は実行環境の違いである。
プログラミングしているときには自分の想定した環境(rootユーザであるなど)でエラーが発生しなくとも
自動実行する際には環境が変化している可能性がある。

『新人エンジニアのためのインフラ入門』chapter5~8

##chapter5 物理サーバ

 


●コンピュータとは
5大装置ー演算、制御、記憶、入力、出力

 

 

●演算と制御
・CPUとは
演算と制御を担当するCPUになる。
CPUの役割は「プログラムを実行すること」に当たる。
CPUは制御装置と演算装置から成り立っているが、
制御・演算する際にはメモリ(主記憶装置)上の命令やデータをそのまま使用するのではなく、
CPU内部にあるレジスタという高速なメモリを使用する。
レジスタとメモリ間にはキャッシュメモリというCPUとメモリ(主記憶装置)間の性能差を埋める目的のメモリも存在する。

 

レジスタ
メモリを低速メモリとするならば、レジスタは高速メモリと表現することができる。
CPUはメモリから命令を取り出すと命令レジスタというレジスタに保存します。
さらに命令実行に必要なデータも別レジスタに保存し命令を実行する。

 

キャッシュメモリ
CPUはメモリからデータを取得するが、CPUの速度と比較するとメモリの速度は遅くボトルネックになる。
そのためメモリとの間にキャッシュメモリという中速メモリをCPU内部に持っておき、
使用頻度の高い命令やデータを配置しておくことで毎回低速なメモリまで見に行かなくて済むようにしている。

 

 

●記憶
・主記憶装置
「CPUが直接アクセスできる記憶装置」を指す。メインメモリやメモリと呼ばれる。
CPUは基本的にHDDから直接データを読み込むことはできない。
そのため、まずCPUにプログラムを処理させたい場合にはメモリに展開する必要がある。

DRAM
コンデンサを使用している。電荷がたまっていれば"1"なければ"0"を表現する。
つまり1つのコンデンサは1bitを表現できるが、メモリ容量分のコンデンサも必要となる。
時間とともにコンデンサ電荷は放電するため、定期的に再充電する必要がある。

SRAM
トランジスタを使用していて、1bitを表現するために6つのトランジスタを必要とし、
回路が複雑なため集積度を上げるのが難しく価格面でのデメリットがある。
DRAMよりも読み書き性能が良くリフレッシュの必要もなく消費電力も少なく済む。

・補助記憶装置
「CPUが直接アクセスできない記憶装置」を指す。代表的なものではHDD、DVD-ROM、テープ、ディスクストレージ
などを指す。
メモリはコンピュータの電源供給がなくなると同時に内容が失われるために保存したいものは補助記憶装置に
置いておく必要がある。

 

 

●入力・出力
コンピュータの代表的な入力装置としてはキーボードやマウス、出力装置としてはディスプレイなどが存在している。
また、ネットワークインターフェースのように入力と出力を兼ね備えた入出力装置もある。
ネットワークインターフェースに届いたデータはデバイス上のレジスタ(CPUのレジスタとは別のもの)
に保存する。その後レジスタからメインメモリに複製される
(ここまでくるとOSやアプリケーションがネットワーク上のデータを見ることができる)。


BIOS
ハードウェアの基本的な制御をするために、ハードウェア内部にはファームウェアと呼ばれるソフトウェアが組み込まれている。
BIOSファームウェアの一種であり、コンピュータの基本的な制御をするためにコンピュータ内部に組み込まれている。
コンピュータの電源を入れると、BIOSのプログラムが実行される(OSが起動されるわけではない)。
つまり、BIOSはハードウェアのチェックやOSの起動を担当をしている。OSに制御が移るまでがBIOSの出番である。
また、最近ではUEFIという仕組みがBIOSを置き換える形で浸透している。

 

 

##chapter6 OS


osは大まかに部類すると「サービスプログラム」、「言語プロセッサ」、「制御プログラム」に分類される。

 

1,サービスプログラム
コンピュータ利用者を手助けするプログラムを「サービスプログラム」と呼んでいる。

 

2,言語プロセッサ
人間が作成する「ソースプログラム」を言語プロセッサでプログラムへと変換することが行われる。

3,制御プログラム
ハードウェアやソフトウェアを制御するプログラムを指す。
制御プログラムが存在することで個々のプログラムはハードウェア管理から解放され、
プログラム開発の効率が上がるというメリットがある。
ハードウェア処理を行う場合には制御プログラムに仲介をお願いをする必要がありデメリットになる。

制御プログラムは一般に「カーネル(kernel)」と呼ばれている。
カーネルの代表的な役割には以下がある
・ハードウェアの抽象化
・メモリ管理
・タスク管理
・データ管理

 

 

●ハードウェアの抽象化
物理サーバには様々な種類が存在している。
アプリケーションの視点で見たときにハードウェアの細かい仕様から解放されることを意味する。
逆に抽象化されていることで、カーネル以外からハードウェアを制御することは基本的にできないようにもなっている。
そのため、OS(カーネル)の機能を呼び出すために「システムコール」が使われる。

 

 

●メモリ管理
複数の実行と終了を繰り返しているためにメモリ空間は虫食い状態になっている。
空き総量は十分でも連続したメモリ領域を確保できずにプログラムの読み込みに失敗することもあり得る。

1,仮想記憶
仮想記憶ではプログラムが実行されるたびにOSが仮想的なメモリを生成するが、
プログラムに対しては物理メモリではなくこの仮想メモリが割り当てられる。
このようにすることで、物理メモリが虫食い状態であっても領域を有効活用することができ
プログラムに対してはあたかも連続した領域を確保したかのように見せることができる。
また、メモリ空間が分離されているためにプログラムが暴走した際にも他のプログラムに影響を与えることがなくなる。

 

 

2,ページアウトとページイン
最近のOSではプログラム全てのページではなく必要なページだけが物理メモリに読み込まれている。
この必要か否かの判定は常に実施されており、不要と判断されたページは物理メモリからHDDに追い出される。
この追い出しを「ページアウト」と呼ぶ。
また必要とされたページはハードディスクから物理メモリに読み込まれるがこれを「ページイン」と言う。

物理メモリが不足している際にはこのページアウトとページインが頻繁に発生することで動作が遅い状態になり注意が必要である。

 

 

●タスク管理
コンピュータにおいて処理する仕事の最小限の単位をタスクと呼びOSがこのタスクを管理している。
(cf.現場ではプロセスと呼ばれることも多い)

 

●データ管理
(揮発してしまうため)メモリの内容をコンピュータに内蔵されたハードディスクやストレージ装置などの補助記憶装置に書き込む必要があり、これらの読み書きをOSが管理している。
(cf.OSはファイルシステムといった仕組みを使って管理する)

 

●コラムー構築とテスト
テストでは設定値が正しいかの確認から設計書通りの動作になっているかも確認する。
システムが正常通り動作するかを確認する「正常系テスト」と併せて「異常系テスト」も行う。
ex)障害を想定してサーバやネットワーク装置からケーブルを除去したり、
プロジェクトによってはサーバの電源モジュールを抜いたりをする。

 
##chapter7 ミドルウェア


アプリケーションとOSの中間的な処理を行うソフトウェア。

●Web、AP、DBの役割

・現在のシステムにおける一般的なシステム構成は「クライアント・サーバシステム」である。
また、Webページも「Webシステム」というWebブラウザを通して利用できるクライアント・サーバシステムの一つ。
「クライアント」と「サーバ」のように役割が非対称になっており、クライアント端末に専用のアプリケーションを
インストールしなくてもWebブラウザのみでシステムを利用できる
(対称の役割を持つ端末が相互に通信することをP2Pと呼ぶ)。

Webの3層構造がWeb、AP、DBに特化した機能を持つサーバ群である。

・webサーバ
主にクライアントからのリクエストに対して「静的コンテンツを見せること」と
「APサーバに動的コンテンツを要求し、送ってきた結果を見せること」という二つの役割がある。

 静的コンテンツ-誰が見ても常に同じ内容を表示するもの
 動的コンテンツー見る人や時間などによって内容が変わるもの


・APサーバ
APサーバはWebサーバから受けたリクエストを元にJavaPHPなどで作成されたアプリケーションを実行して
動的コンテンツを生成する。


・DBサーバ
DBサーバとはデータベース管理システムが動作しているサーバを指す。
DBサーバはストレージに新たなデータを書き込んだり、必要な情報を引き出したり更新したりする。
データを操作する際には、APサーバのリクエストに従って「SQL」と呼ばれるデータベース言語を実施し、
その結果をAPサーバに返す。

 DBサーバには性能を求められることも多く、物理サーバ自体も多くのCPUやメモリが搭載され、
インフラエンジニアにもより効率良くデータを抽出するための「チューニング」という作業が求められる。

・Web3層構造
Web3層構造が採用される理由には「セキュリティの高さ」、「管理のしやすさ」があげられる。

●コラム「運用引継ぎ」
開発担当から運用担当への引継ぎを「運用引継ぎ」と呼ぶ。
インフラ領域においては「サーバ起動・停止」、「バックアップ、リストア」などが該当する。


##Chapter8 ミドルウェア(システム運用)

 


・システム運用とは何か
運用においては「システム障害は起きるもの」として準備しておくことが重要である。
準備には様々な観点のものがあるが「単一障害ポイントをなくし、バックアップを定期的に取得し、障害検知のために監視すること」が基本になる。

●運用ミドルウェア
・バックアップ
1、バックアップ対象の確定
2、対象データの更新頻度に合わせたバックアップタイミングの決定

・バックアップデータの保存には別領域ディスクやLTO媒体(DtoT)がよく使用される。

・バックアップにおける「バックアップ対象の状態確認」→「バックアップ先の確認」→「バックアップ」
→「バックアップの成否確認」といった一連の処理はバックアップ専用のミドルウェアを介して運用者が扱いやすい
ひとまとまりになっており、これらは「バックアップジョブ」と呼ばれる。

・ジョブ管理

システムの運用中には定期的な定型作業が発生する(ex.ログの取得、サーバの再起動)。
このような作業を手動で1つ1つ実行するのは大変なためジョブ運用が行われる。

ジョブ運用ではバックアップなどの処理を実行するジョブ(スクリプトやコマンド)を設定し、
それぞれのジョブの順序やスケジュールを設定する。

・監視(Zabbix,Nagios,JP1)

・ノード監視
サーバやネットワーク装置、ストレージやLTO装置等の機器が稼働しているかを監視する。
(具体的には、SNMPやICMPといったプロトコルを使用して対象機器がネットワークの中で正常に動作しているかを確認する)
・リソース監視
それぞれの機器のリソース使用状況を監視する。
サーバであればCPU、メモリ、ディスクなどのリソースの使用状況を監視し、
設定した閾値を超えた場合に異常として検知する。
(ディスクがいっぱいで書き込み容量不足や、動作が遅くなる前の対策)

・プロセス監視
プロセスの起動状態を監視する。プロセスが何らかの原因で停止した場合に異常として検知する。
(サーバは起動しているが、サービスが止まっている状態への対策)

・ログ監視
OSのシステムログやミドルウェアのログを監視し、異常が出力された場合に検知する。
異常がログに出力されていても気が付かなければ対応が遅れるため。
(異常として検知するメッセージは設計の中で決める必要がある)

・高可用クラスタ
サーバを停止しないようにする手段としてサーバ冗長化がある。
サーバの冗長化とは「同じ機能を持つサーバを複数台用意する」ことになる。
このサーバの冗長化に使用されるミドルウェアが「高可用クラスタ」である。

冗長化すると「サーバが不慮の障害で停止した場合」などに自動で他のサーバへ切り替えて機能を提供する。
平時から現用系と待機系の両系が稼働している場合をactive/activeクラスタ構成、
平時は現用系のみ機能し障害時に待機系へ切り替わる場合をactive/standbyのクラスタ構成と呼ぶ。

 

 

『新人エンジニアのためのインフラ入門』chapter1~4

『新人エンジニアのためのインフラ入門』

 

 

『新人エンジニアのためのインフラ入門』これが、unlimitedに入っていたのでとりあえず読んでみることにした。

これはそれの備忘。

今回はchapter1~4まで

 

 

##chapter1

ITインフラの全体像システム=アプリケーション+インフラ(ITインフラ)・アプリケーションー業務やサービスに合わせて個別に作るもの
・インフラはシステムソフトウェアとハードウェアの二種類に分けられる


●ハードウェアに関して
物理サーバ24時間365日稼働、高速処理といった要件のシステムで使用される。cf)IAサーバ(Intel Architecture)ーパソコンの構造を許可したものUNIXサーバ -ワークステーション構造をもとに強化したものがある
ストレージ装置データ格納や信頼性といった要件に合わせたデータ保存に特化した装置基本的には物理サーバに接続し、筐体内のハードディスクと同じように使用する(NASはサーバに接続せずに、ネットワーク越しにファイルアクセスできる)
テープ装置ハードディスクの内容をバックアップする目的で使用する装置cf)LTO規格によって読み書き性能が向上した
ネットワーク装置物理サーバ間を相互に接続するための装置。LANケーブルを使用し物理サーバをネットワーク装置に接続する。(構成によってはネットワーク装置とネットワーク装置を接続することもある。)一定規模以上のシステムは2台で1セットとして運用している(固有情報以外は全く同じ設定を2台に対して行っている)ことが多く障害時には自動で通信経路が切り替わることで業務を継続できる。


cf)ファシリティエンジニアデータセンタでハードウェアを設置するラック電源や通信といった設備を扱う。搬入搬出など各種工事にかかわるエンジニア
ラック企業システムはデータセンターやサーバールームに設置されている。その中で、「効率よくハードウェアを設置できるように」と規格化された収納製品

 

 

●システムソフトウェアに関して
OSアプリケーションやミドルウェアが共通で使用する機能を提供するソフトウェア
ミドルウェアOSとアプリケーションの間に存在するソフトウェア。ex.ミドルウェアを使うことでデータベースとの接続を管理してくれるなどのメリットが存在する

 

 

●システムにおけるインフラ
クライアント・サーバシステムシステム利用者が使うコンピュータであるクライアントサービスを提供するコンピュータであるサーバに分かれる
webシステムクライアント・サーバシステムの中でもクライアント側のソフトウェアとして「Webブラウザ」を使用するシステムが主流になっている。
Web3層構造1、Webサーバ静的コンテンツの提供
2、APサーバ動的コンテンツの提供
3、DBサーバデータの提供。主にAPサーバからのリクエストに応じてデータを返す
WebサーバとAPサーバを一台に統合してwebAPサーバとする場合やWebサーバがない場合もある。

 

●システムにおけるインフラとはWeb、AP、DBの3つのサーバを中心にユーザー認証が必要ならば「認証サーバ」、監視・ジョブ管理などを行う「運用管理サーバ」など周辺を固める。

 

 

 

##chapter2サーバ

 


●サーバとはITシステムではクライアントにサービスを提供するモノがサーバであるまた、サーバを用意することで複数のクライアントからの要求を同時に処理できる

特定の役割を持つサーバ
特定の役割を持つサーバ本書では「物理サーバ」を示す。同じ物理サーバであっても導入するソフトウェアによって役割が異なってくる

Webサーバ役割
//TODO:この範囲に関してはインフラの構成に関する書籍や資料を参照

物理サーバ・CPU演算と制御を担当している。
・メモリ

・メモリ一時期的にプログラムや処理データを置くために使用される。基本的には各ソフトウェア(OS、ミドルウェア)の使用料を積み上げて必要な容量を決める

・HDDすぐには使用しないアプリケーションやファイルを入れておくために使用する。HDD容量が大きければ多くのアプリケーションやファイルを保存しておくことができる。(使える状態になるまでに少し時間がかかるという特徴がある)
CPU、メモリ、HDD、はサーバの性能に大きく関係するため、必要な性能や容量を見誤ると「処理能力低下」や「処理不能」に不能につながる。(対処法として、該当サーバのCPUやメモリの追加、物理サーバの増設などを検討する)

 

 

●OS(オペレーティングシステム)OSは「オペレーティングシステム」の略で「基本ソフトウェア」とも呼ばれる。ハードウェアとアプリケーション、ミドルウェアの間に位置し、メモリ管理やネットワーク処理など多くのソフトウェアが共通して利用する機能を提供する。
以下はサーバでよく使用されるOSである

・WindowServer>Microsoft社が提供。普段使い慣れたwindowsのPCと同じ感覚で使用することができる。

Red Hat enterprlse LinuxRHEL)>Red Hat社が提供。コストパフォーマンスに優れている。

CentOSCentOSプロジェクトから無償提供されているサーバOS。RHELとの完全互換を目指しているため、機能に遜色はない。開発環境にはCentOSを本番環境にはRHELをなどの使い分けも見られる。

・HP-UXHP社社が提供。大規模なシステムや重要なサーバでの採用実績が多くあり「信頼性の高いOS」と言われている。その分、導入費用が高くコストがデメリット。フロントサーバ(Webサーバ、APサーバ)はLinux、DBサーバはHP-UXという組み合わせも見られる。

・AIXIBM社が提供するHP-UXと同じ立ち位置にあるサーバOS
OSに関する勉強法>>RHELCentOSUNIXの基礎を勉強するのが良い。

 

 

ミドルウェアミドルウェアはアプリケーションとOSの中間的な役割を持つソフトウェアである。Webサーバはweb機能、APサーバにはアプリケーション機能、DBサーバはデータベース機能...特化した機能を提供する。これらのミドルウェアを導入することで、サーバに役割を持たせることができる。
//TODO:バックアップ、ジョブ運用、監視、高可用性クラスタなど勉強不足

 

 

●周辺装置

1、ストレージ装置高性能なHDDを複数積んだ「データ保存に特化した装置」。大きいものでは大型冷蔵庫くらいのものもある。1セットで数億円というのも珍しくない。データを失われないように耐障害性に優れ、サーバ内のHDDでデータを保存するよりも安全である。また高速の読み書きを実現する為に、多くのパーツがHDD周辺を固めている。機能も豊富であるex)装置内のHDD間でデータを複製する機能。など

2、テープ装置テープ装置はストレージ装置と同様に「テープ保存に特化した装置」である。
ストレージ装置は装置内部に搭載されたHDDにデータを保存する⇔テープ装置は装置内部に装填されたテープメディアにデータを保存する。主にバックアップをターゲットにした装置でテープメディアを取り出すこともできるため、システムとは別の場所に保管して災害などからデータを守るという考え方を取り入れているシステムもある。
テープ装置は、持ち運び性やデータ保存の単価が安い点がメリット。鳴れていないと少し操作が難しいため毛嫌いする人もいる。

 

ウォーターフォール型開発の流れ要件定義→基本設計→詳細設計→構築→単体テスト結合テストシステムテスト>各フェイズの考慮不足や設計ミスにより手戻りすることもある。

 

##chapter3 ネットワーク

 

●ネットワークとは一般的には人やモノを網状につないだものを「ネットワーク」と呼ぶ。現在のネットワークにおける取り決めの基準は「TCP/IP」(プロトコル)である。TCP/IPは元々インターネットを支える技術だったが、インターネットの広がりとともに、TCP/IPを使用しないネットワークを見つけるほうが難しくなった。
LANとWANネットワークにはその接続範囲で分類したときにLANとWANの二種類が存在する。LAN-家庭内や企業の拠点内の閉じたネットワークを指して使われる。WAN-LANをお互いにつなげたものを指す。

 

TCP/IP・階層構造による通信アプリケーション層(ex.HTTP)トランスポート層(ex.TCP)インターネット層(ex.IP)ネットワークインターフェース層(ex.イーサネット)データを送信するコンピュータはこの階層に従って上から下へと処理を行い、データを受信するコンピューターは下から上に処理を行う。

 

●Web通信の例・アプリケーション層WebのミドルウェアApache間でHTTP通信が成り立っている

トランスポート層ポートの使用。コンピュータにはポートが65,536個用意されている。クライアントはwebサーバの80番ポート宛にデータを送信、webサーバでは80番ポートにデータが届いたためApacheが自分宛のデータとして処理した

・インターネット層IPプロトコルが使用される。ネットワークに繋がる機器にはIPアドレスに関する経路情報(ルーティングテーブル)が保存されている、宛先のIPアドレス確認し、次のどの機器へ転送するかが決まる。

・ネットワークインターフェース層イーサネットネットワークに繋がる機器には全てMACアドレスと呼ばれる一意のアドレスが付与されている。MACアドレスは同一ネットワークにおけるダイレクト通信時に使用される。

 

●ネットワーク装置・スイッチコンピュータやネットワーク装置を接続してLANを組む際に使用する。L2スイッチ(ネットワークインターフェース層まで)やL3スイッチ(インターネット層まで)の処理を担当する。L3スイッチではVLANという機能によりハードウェアレベルでIPルーティングが可能である。

・ルータLAN同士を組み合わせてWANを組む際に使用し、インターネット層までの処理を担当する。ルータはソフトウェアでルーティング処理を行うため、ハードウェアでルーティング処理を行うL3スイッチと比較すると処理速度が遅いが様々なプロトコルに対応している点がメリットである。そのため、WANの接続に複雑なプロトコルが必要となる場合に使用されるケースが多くなる。

ファイアウォールインターネットとの境界やLANとLANの境界に配置されることが多い装置。ファイアウォールトランスポート層までの処理を行うことができ、IPアドレスやポート番号の情報を基に通信を許可・遮断する(cf.WAF Webアプリケーションを狙った攻撃から守るため、Webアプリケーションに特化してファイアーウォールを提供する製品)

・ロードバランサWebサーバやAPサーバの前段階に配置し、付加情報により送信先のサーバを変える、パケットの内容に従って送信先のサーバを変えたりする機能を持つネットワーク装置。アプリケーション層までの処理ができ、HTTPヘッダの内容に応じて送信先のサーバ変えるといった柔軟な動作も可能
コラム「要件定義」・機能要件システムに搭載すべき機能(ex.顧客管理機能・メンテナンス機能)

・非機能要件機能要件以外でシステムが備えるべき要件。(可用性、性能・拡張性、運用・保守性、移行性、セキュリティ)

 

 

##chapter4 仮想化とクラウド

 

●仮想化とは・仮想化とは「仮想化」は物理的な構成を隠して、論理的かつ柔軟に構成するための技術である。

 

・サーバの仮想化物理サーバの仮想化

 

1、ホスト型(ex.VirtualBox)物理サーバにインストールされたOSと仮想化ソフトウェア上で仮想サーバが稼働する。アプリケーション感覚で仮想化でき、手軽。

2、ハイパーバイザ型(ex.hyper-V)物理サーバにインストールされた「ハイパーバイザ」と呼ばれる仮想化専用ソフトウェア上で仮想サーバが稼働する。OSが不要なため物理サーバのリソースが制御しやすく、性能面でホスト型よりもメリットがある。

(3、コンテナ型ーex.dockerホストOS内にコンテナを作り、アプリケーションを動作させるに必要なライブラリなどをコンテナ内に閉じ込めることによって個別のサーバのように使用することができるようにしたもの)

 

・仮想化の特徴

1、可用性物理サーバに障害が発生した場合でも他の物理サーバへ切り替え稼働できる。また、仮想サーバの実態はファイルの集合体で容易にバックアップやリストアできるため復旧も容易にできる。

2、拡張性仮想サーバの容量拡張の場合には設定画面でHDDの容量を変更するだけで拡張できる。仮想サーバの自体の追加でも、既存の仮想サーバやテンプレートから複製するだけで追加できる。

3、運用保守性仮想化すると物理的なIT資源を一元管理しやすくなる。1つの管理画面で複数の仮想サーバを管理、コマンドで仮想サーバの運用の自動化することも可能。

 

※1台のサーバのCPU数を変更しているはずが、他のサーバのCPUにも影響を与えてしまうなどの事故。仮想サーバがどのCPUを使用しているのかどのタイミングで設定が変更されるのか正しく理解しておく必要がある。
クラウドとはクラウドとはインターネットなどのネットワークを通じて様々なサービスを提供するシステム形態を指す。自社が持つサービスシステムと異なる点は、クラウドではユーザーはサービス提供を受けるのみであり、実際のコンピューターがどこでどのような構成で稼働しているかネットワークがどのように接続されているかは意識する必要がない。各種サービスはWebブラウザから利用でき、操作性もシンプルである。
・サービス形態IaaSinfrastructure as a Service の略。システムで使用するCPU、メモリ、ハードディスクなどのハードウェアやそのシステムで稼働するOS、ネットワーク環境を提供するサービスである。ユーザが使用するミドルウェアやアプリケーションは利用者が導入・設定する必要がある。
PasSPlartform as a Service の略。アプリケーションが稼働するためのプラットフォームを提供するサービス。IaaSの構成要素に加え、アプリケーションの開発・実行環境に必要なソフトウェアやミドルウェアを提供する
SaaSSoftware as a Service の略。アプリケーションソフトウェアの機能を分割し、ユーザが必要とする機能を提供する。(ex office365)
DasSDesktop as a Service の略。クライアントのデスクトップ環境を提供するサービス。ユーザーはディスプレイとキーボードの準備するだけで利用できる。手元にデータが残らないためセキュリティ面でのメリットもある。
クラウドに対して自社のサーバやネットワークを利用してシステムを構築し運用することをオンプレミスと呼ぶ。
オンプレミスーIaaSーPaaS-SaaSと利用者が管理できる部分が減っていく。

 

・最近の動向クラウドファースト企業がシステムを設計・構築する際にオンプレミスではなく第一にクラウドサービスの利用者を検討すること
クラウドネイティブクラウドサービスを最大限利用し、その特性や利点を生かしてアプリケーションを実装すること

 

クラウドにおけるインフラ・必要となる知識クラウドのベースには仮想化技術が使用されています。AWSXen」、Azure「Hyper-V」、Google Cloud「KVM」と別々の仮想化技術が採用されている。
・自動化クラウド事業者が提供する自動化ツールを利用できることもクラウドを利用する一つのメリットです。(ex. 基本となるマスタテンプレートを元にサーバ用途ごとに異なるミドルウェアをインストールする、構築後のテストまで一貫して自動化したりといったことが自動化ツールで行われている)

「プロになるためのWeb技術入門」lesson6-7まで

## lesson6 Webアプリケーションを効率よく開発するための仕組み

6.1サーブレット/JSP
・ログインサーブレットの処理
→リダイレクトではなくフォワードが使われる

リダイレクト…サーバからクライアントに対して一度302を返すことで遷移先のURLを伝えクライアントからサーバへ改めてHTTPリクエストを発行している

フォワード…アプリケーションサーバの中でだけで遷移処理が行われる。そのため1回のHTTPリクエスト遷移が可能になる。

リダイレクトよりもフォワードは応答が速いため処理結果で異なるjspを表示する際などはフォワードを使用することが推奨されている。


・リクエストスコープにおける情報の受け渡し
リクエストスコープ…フォワード元とフォワード先の間でJavaのオブジェクトを共有するための仕組みである。
(→cf.リクエストパラメータ…HTTPのGET、POSTメゾットによってクライアントからWebアプリケーションに文字列として渡されるものである。受け取った値を変更することはできない。)
アプリケーションサーバから提供される仕組み。フォワードの前後でJavaオブジェクトを共有することができる。
一回のHTTPリクエストを処理する間のみ有効なため、リクエスト処理が終了するとリクエストスコープに保持されていた情報は消えてしまう。

・セッションスコープとリクエストスコープの違いに関して
セッションスコープはCookieなどの仕組みを利用し、アプリケーションサーバのメモリに保存される。
そのためセッションが増えるとメモリ不足になる。
(cf.タイムアウト→最終アクセスから一定時間経過したセッション情報をすでに使われなくなったものと判断し自動的に削除する仕組み Tomcatではデフォルト30分に設定されている)

セッションスコープでは、複数のリクエストにまたがって有効なため
ログイン状態や購入商品などユーザーがWebアプリケーションを使用している間に保持しておきたい情報を格納するのに適している。
リクエストスコープではクライアントからリクエストが届いてから、レスポンスを返す間しか有効にならない。


・コラム/URLリライティング
PHPなどではCookieが利用できない場合「PHPSESSID」というパラメータ名でリクエストのURL
にセッションIDが含められるようにformタグが自動で書き換えられサブミット時にGETパラメータとしてセッションIDが渡されるようにしている。

・Webアプリケーションのアーキテクチャ
ロジックとデザインの分離
ソフトウェアの設計スタイルとその設計に基づく全体構造を「アーキテクチャ」と呼ぶ。

cf)カスタムタグ
エラーメッセージなどを開発者が自分で用意したタグをカスタムタグと呼ぶ。

・例題Webアプリのアーキテクチャ

webアプリケーション内の細かな処理は「入力データの取り出し(Input)」「データ処理(Process)」「HTML出力準備(Output)」
という「IPO」の流れで構成されている。

例題のWebアプリは「モデル(model)」、「ビュー(view)」、「コントローラ(controller)」で構成される、「MVCモデル」である。

a)model
モデルはアプリケーションの「処理」の部分とそれにかかわる情報を保持する。
そのため、画面に対する入出力といった部分には一切関わりを持っていない。

b)view
ビューはモデルによる処理結果の画面への表示を担当する。
処理結果自体はmodelが持っているためビューがモデルから取り出してユーザに見やすいように整形した上で画面へ表示する。
あくまで画面への表示が役割であり、情報処理には関わらない

c)controller
controllerは画面からの情報入力とモデルの呼び出し及びにその結果に従ったビューの呼び出しを担当する。
controllerはユーザーがユーザが画面に入力した情報を取り出し処理を担当するmodelに渡す。
modelの処理結果によって結果を表示するviewを呼び出す。

MVCモデルに基づくことで、「ロジックとデザインの分離」を実現することができる。
ロジックーmodel
デザインーview

MVCモデルによる処理の流れ
1、Webブラウザから送信されたリクエストはまずコントローラが受け取る。
2、コントローラはリクエストからパラメータを取り出し、必要に応じてセッションからの情報を取り出す。
3、入力情報を処理するモデルを呼び出し、各パラメータを処理、格納する
4、モデルはそれらの結果をコントローラに返却する。(この際に返すのは処理結果そのものではなく、成功・失敗程度のステータスになる)
5、コントローラは受け取ったステータスから表示すべき画面を選択し、その画面を表示するためのビューを呼び出す。
6、ビューはモデルを参照し、表示すべき情報を取り出しその結果をHTMLとして出力してHTTPレスポンスとしてWebブラウザに返す。

 

フレームワークによるアーキテクチャーの実現
フレームワークとは
アーキテクチャを実現する部分は共通化し、見た目など個々のアプリケーションで異なる部分は別々に開発できるようになれば効率よくアプリケーションを開発できるようになる。
品質も保ちやすい。
この共通部品の考え方がソフトウェアにおけるフレームワークである。

cf)Struts(フレームワーク)

・レイヤーパターンによるデータアクセス層の分離

224

JavaではdbにアクセスするAPIとしてJDBCが用意されており、JDBCを使ってDBに対してSQLを発行し結果を取得する。

a)データソースの取得
WebアプリケーションがDBに接続するにはまず「JNDI」と呼ばれるAPIを利用してアプリケーションサーバからDataSourceクラスの
オブジェクトを取得する

b)コネクションの取得
DataSourceが取得できたら、getConectionメソッドを呼び出してデータベースへ接続する。データベースへの接続はConnectionクラスのオブジェクトとしてあらわされる。

c)SQLの発行
SQLを発行するにはConnectionオブジェクトのcreateStatementメソッドを呼び出してStatementオブジェクトを取得する。
引数にSQL文を指定してStatementオブジェクトのexecuteQueryメソッドを呼び出すことでSQLが発行される

d)SQL実行結果の取得
SQLの実行結果はexecuteQueryメソッドの戻り値として得られるResultSetオブジェクトから取得できる。
ResultSetオブジェクトではnextメソッドでレコードを呼び出し引数にgetXXXXメソッドを呼び出すことで各カラムの値を取り出すことができる。


・「Layers」と呼ばれるアーキテクチャーパターン
上位レイヤーが下位レイヤーの提供する機能を利用することで、各レイヤの作りを単純化していく考えである。

a)プレゼンテーション層
●コントローラー・ビューが属する
システム利用者とのインターフェースを担当するレイヤ。
Webブラウザを通してユーザからの入力を受け付けて下位のレイヤであるビジネスロジック層に渡し、その処理結果を再びWebブラウザへ表示させたりといったことを担当する

b)ビジネスロジック
●モデル
アプリケーションが実現すべき固有の処理を実行するためのレイヤ。「業務ロジック」と訳される。
ビジネスロジックは、ユーザーが入力した情報をプレゼンテーション層から受け取り、必要に応じてデータベースを利用し、処理を実行する。処理結果は、プレゼンテーション層へ返す。

c)データアクセス層(cf.インテグレーション層)
●モデル
ビジネスロジック層とデータベースの仲立ちを行うためのレイヤ。
データベースへのアクセスなど面倒な処理をビジネスロジックから切り離し、データベースへの細かなアクセス手順を意識せずとも利用できるようにする。
cf)DAOを使用する。

O/Rマッピングフレームワークによるデータアクセス層の実現
cf)
▲「iBATIS
・「インピーダンス・ミスマッチ」ーリレーショナルデータベースとオブジェクト指向の表現の違い。

フレームワーク利用におけるメリットとデメリット

●メリット
1、設計・開発工数の削減
ー優れた設計の再利用。共通で必要なデータベースアクセスなどはフレームワークの規定に沿って必要なコードを作成するだけで済む点。

2、品質の向上
ー生産性の向上から結果としての品質の向上。

3、テスト工数の削減
ー新たに作成されるコード自体がフレームワークによって減るため、テスト工数の削減につながる。

●デメリット
1、学習コストの増大

2、設計における自由度の低下
フレームワークの設計者の意図した範囲ではないことを実現しようとすると難易度が高くなってしまうことなどがある。

3、長期的な技術力の低下
フレームワークは簡単に使えるように内部をブラックボックス化してしまうために、裏側で何が行われているのか知ることができなくなる。
また開発現場で不具合が生じた場合フレームワーク起因の可能性もある。そのために開発者はフレームワークの裏側でどのようなことが行われているのか知る必要がある。

 

 


##lesson7セキュリティを確保するための仕組み 

・Webアプリケーションにおける守るべき情報セキュリティ
1、第三者への情報の流出を防ぐこと(機密性)
2、第三者による情報の改ざんを防ぐこと(完全性)
3、適切な権限を持った人間が適切な情報を利用できること(可用性)

・代表的なWebアプリケーションの攻撃手法とその対策
SQLインジェクション
Webフォームなどの入力インターフェースを利用してデータベースに発行されるSQLを開発者が意図しない形に変更すること。(cf.不正ログイン)
インターネット経由でどこからでも攻撃が可能な点
被害者が情報流出に気が付きにくい点

入力値のチェック(ex.バリデーション)
プリペアード・ステートメント
(文字列連結などでSQLを組み立てず、WHERE句など条件によって変化する部分をプレースホルダとして登録したSQLを事前に用意しあとからパラメータを割り当てる方法)

クロスサイトスクリプティングXSS
HTML内に悪意のある動作をするJavaScriptを埋め込む。クッキーの盗難やページの改ざんなどができる。セッションハイジャックなどにつながる恐れがある。

サニタイジング
(HTMLの破壊をする文字列を、無害な文字列に変換するなどの処理を行うこと。多くのプレゼンテーション層を扱うフレームワークで同様の機能を備えている。)

入力チェック(受け付ける文字列を絞る)→出力時に出力対象に応じてサニタイジングを行うのが理想。

セッションハイジャック
クライアントとサーバの間でやり取りされているセッションIDを第三者が盗み取ること。

1、XSS対策

2、通信経路の暗号化
インターネットを流れる通信は盗聴できるため、通信経路をSSLによって暗号化することが必要になる。

3、セッション・タイムアウト値の変更
利用者がログアウト処理を忘れてしまった場合、セッション・タイムアウトが発生するまでセッションIDも有効なため、セッションIDが盗まれた場合被害を受ける。
セッション・タイムアウト時間を短めに設定することでセッションIDが悪用される可能性を低くできる

4、セッションIDのランダム化
セッションはアプリケーションサーバなどによって実現されているため、開発者が自分で対策することは少ない。セッションの安全性は「セッションIDが十分大きな桁の数字の中からランダムに選択された」という事実によって支えられている。

●コラム
SSLによる通信経路の暗号化
httpsSSLで暗号化された通信である。
公開鍵暗号
→二つで一対の鍵を使う。
相手に送る暗号化用の鍵を「公開鍵」
自分で持っておく復号用の鍵を「暗号鍵」と呼ばれる。
cf)「SSLアクセラレータ」ー暗号化処理を高速実現している。

クロスサイトリクエストフォージェリCSRF
攻撃者が捏造したフォームから強制的にサブミットすることで、掲示板に意図しない書き込みをされたりする攻撃。

①フォーム表示のリクエストがアプリケーションサーバに届いた際に「ワンタイムトークン」を生成
②生成したワンタイムトークンを「hiddenパラメータ」に埋め込みフォームを表示
③サブミットされた際に、ワンタイムトークンも送られる(→これを照合し、自サーバで生成したものであればサブミットを受け入れる)

●コラム「ハッシュ関数
ハッシュ関数とは任意の長さの入力に対して「メッセージダイジェスト」と呼ばれる固定長の値を出力する関数である。
1、ハッシュ関数は入力となる情報が少しでも変化すると結果が大きく変化する
2、異なる入力に対して同じ出力がなされる「衝突」が起きにくい
3、メッセージダイジェストから元の入力を推測するのが困難

情報改ざんの発見
ワンタイムトークンなど推測不可能な文字列の生成
パスワードの保存
などに使用されている

●強制ブラウズ
webブラウザんぽアドレスバーにURLを直接入力することで本来表示されるべきではない画面を表示させる攻撃である。
ログイン状態の確認→ログイン画面の経由をどのような画面にアクセスされても可能としなければならない。
ディレクトリのファイル一覧を表示する機能が見えることもある。(ex. Apache→Indexesというアクセスが有効になっている場合など)

jsによるアドレスバー非表示(URLの確認や直接入力の禁止、ブラウザによってはjsを無効にできるため有効ではない)

ディレクトリトラバーサル
リクエストで渡された文字列を使ってシステム内のファイルを表示するアプリケーションで注意すべき(アクセスされたくない親フォルダーなどに対するアクセスを相対パスなどで可能にする)
「¥0」-ヌルバイト(¥0という文字列は文字列の終端を示すことが多いため、これが挿入されるとそれ以降の文字列が無視されてしまう)

サニタイジング
ファイルシステムのアクセス権を適切に設定する
ユーザから入力されたパラメータをファイル名として使用する設計にしない

●コラム Digest認証(ダイジェスト認証)
ハッシュ関数を利用して、ユーザー名やパスワードを直接送受信せずに実現する
(HTTP通信そのものは暗号化されないためSSL/TLSの利用が必要)

・設計/実装ミスに起因する誤作動やセキュリティ問題を防ぐために

●「戻る」ボタン対策
1、ブラウザによるキャッシュ無効化
フレームワークが提供していることも多いので一度確認する。

2、戻るボタンの無効化
jsでの無効化になるため、js自体が無効化されている場合には意味をなさない
企業内で使用するWebアプリケーションなどの場合は有効

3、ワンタイムトークンの利用
hiddenパラメータにワンタイムトークンを埋め込み、サブミットされた際に他の値と一緒に調べる

●ダブルサブミット対策
二重押下問題

1、jsによる対策
ボタンが押されたかを変数に格納し、一度目はfalseで返し二度目以降はtrueで返すなど。

2、ワンタイムトークンによる対策

●hiddenの注意点
・hiddenパラメータは任意の情報をフォームに格納することでリクエストをまたいだ情報の受け渡しを可能としている。これらはWebブラウザから容易にのぞくことができる。そのためログイン中かなどをアプリケーション上の状態を直接保持するなどはしない。

CSRF対策としてのワンタイムトークンを使用する。更新画面等を表示する際にサーバが発行するため、ワンタイムトークンが分からなければ捏造したhiddenパラメータを直接POSTし処理させることは困難になる。
使い捨て、推測困難なため 連続した攻撃に使えない・ワンタイムトークン捏造することも難しい。

デバッグ情報を出力させない
エラー情報をそのままブラウザ出力せずにログファイルなど決められた場所へ出力するなど方針を決めておく

 

 

グローバル変数に情報を持たせない
どこからでもアクセスできる可能性のある変数に格納することで想定しなかったユーザに画面を表示してしまう可能性がある

JavaのWebアプリケーション>アプリケーションサーバは「スレッド」という仕組みで複数のクライアントからリクエストが来ても同時に実行ができる。
サーブレットインスタンスはリクエストごとに生成されるのではなく、アプリケーションサーバの中で1つだけしか生成されない。
そこで表示に使用する情報などをインスタンス変数に保持していると、同時にアクセスしているほかの利用者の情報が誤って表示されてしまう。

 

 

 

 

 

 

「プロになるためのWeb技術入門」lesson4-5まで

lesson4


宅配ピザの注文サイトの作成流れ

 

(要求分析フェイズ)
→お客様が何を求めているかを整理する(また業務の流れなどの知識を持つ)

 

①画面構成を考える
→ラフスケッチで作成、5つの画面から作る(ユーザー登録などは省略)
画面遷移図の作成等

 

②画面モックの作成
→「モック」とは模造品を指し、HTMLの画面の張りぼてを作成し、
お客様とイメージ・画面遷移の関係などを確認にするために作成される

 

③ログイン認証機能を作成する

リダイレクト動作のHTTP通信の確認
レスポンス・ラインが「302 Found」で返ってくる。
つまり、最初に要求したURLと異なるURLに遷移することを「リダイレクト」と呼ぶ。

 

●コラム
PHPエンジンはWebサーバーのプログラムに対して「モジュール」という形で組み込まれている。

 

ログイン状態の記録
・HTTP通信ではログイン(状態)を記録できない。

cf)FTPによる通信の場合、
前回のリクエスト結果を踏まえて次のリクエストを実行する。
このようなやり取りを「ステートフル・プロトコル」と呼ぶ。

HTTPの場合、FTPのようなリクエストのやり取りが必要なく、
一回のやり取りのみで済んでしまう。
このようなやり取りを「ステートレス・プロトコル」と呼ぶ。

FTPの問題点
FTPは通信手順が多いためオーバーヘッド(本来の処理を行うために余計に処理がかかってしまうこと)が大きい。
・アクセスのために認証を必要とすること
このため、「認証が不要」、「オーバーヘッドが少なく」実装が簡単なFTPに代わるプロトコルとして
HTTPが開発された。

 

 

HTTPでの状態の表現方法
Cookie(クッキー)はHTTPの仕様を拡張してWebアプリケーションとWebブラウザの間で
情報の交換できるようにしたものである。

 

WebサーバからCookie(ex:user=xxx; pass=xxxx)を受け取ったWebブラウザは次に同じWebサーバにアクセスする際に
受け取ったCookieをそのままHTTPリクエストヘッダに入れて送る。
Webアプリケーション側ではリクエストヘッダに入っている
Cookieを調べることでアクセスしてきた相手がどのような相手か知ることができる。

 

 

4.6安全に状態を保存するための技術-セッション-

Cookieにまつわる問題点
Cokkieを利用した情報のやり取りは、HTTPのリクエスト・ヘッダやレスポンス・ヘッダを利用して行われる。
PC上に保存されたCookieをのぞくことも容易なため、セキュリティ面に危険性がある。
そこで考えられた方法がセッションである。

 

 

セッションIDに関して
セッションIDはWebサーバにリクエストを発行したWebクライアントに識別できるもの(一意なものを指定する)
HTTPにおけるセッションIDの受け渡し方法
Cookieの中に情報そのものを格納するかセッションIDだけ格納するのかが違いである。

 

 

Webサーバによる認証機能

・本書にも載っているような認証方式をフォーム認証(HTMLで画面を作成していることから)と呼ぶ。ほかの認証方式として「Basic認証」がある。
この認証方式の特徴はパスワードが平文で送信される/ログアウトのような処理ができないなどがある。
Basic認証は平文で送信されるため、SSLの暗号化通信、パスワードを直接やり取りしないDigest認証を使用するほうが安全である)


Lesson5

 

Webアプリケーションの構成要素
・Webサーバ
アプリケーションサーバ
・データベースサーバ
が存在する

 

 

●コラム
複数のコンピュータをつなげて1つシステムを構成しているものを「ノード(Node)」と呼ぶ。
「同一ノード上で動かす」ー複数のプロセスを同じコンピュータ上で動かすことを指す
「異なるノードで動かす」ー異なるコンピュータ上で動かすことを指す。

 

5.1 webサーバとwebクライアントの時代


・クライアントサイドではwebクライアントと呼ばれるノード上でwebブラウザというソフトウェアが動作している
・サーバサイドではwebサーバと呼ばれるノード上でwebサーバというソフトウェアが動作している。

 

CGIの時代
最終的にwebサーバの中でPerlPHPのプログラムを直接実行できるようになる


●コラム
ソフトウェア/プログラム/アプリケーション/サーバ
以下はすべてソフトウェアを指し示すものである。


a)プログラム
コンピューターが行う処理の手順を示したもの。
ソースコードそのものを示して「プログラム」と呼ぶこともある。

 

b)アプリケーション
pc上で動作して人に提供する物が主。

 

c)サーバ
サーバは特定の機能に特化したソフトウェアでそれ単体ではシステムを成さない。
今後紹介されるDBサーバがサーバと呼ばれるソフトウェアの代表例である。

cf.プロセスーこれらはコンピュータ上で動作しているソフトウェアを指す際に使われる。

 

 


5.2 データベースサーバの登場
●データベース管理システムの登場
・大量の情報を間違いなく記録し、また情報の検索や集計を人間の手で行うよりも早く処理するために作られた。
このようにコンピュータ上で扱う情報の集合を「データベース」と呼ぶ

そこで、データベースの実現と取り扱いに特化したソフトウェアが開発され、広く利用されるようになった。
それらが「データベース管理システム(DBMS)」である。

 

●コラム
DB,DBMS,RDBMSの三種類の呼び方をする。厳密な違いに関しては以下になる。

 

a)DB
コンピュータで扱う情報の集合のこと
DBMS」との混同が多い。

 

b)DBMS
データベース管理システム、データベースを構築し使うためのソフトウェア

 

c)RDBMS
リレーショナル・データベースを扱うDBMS

 

 


●データベースに対する操作

a)Create 生成
新しい情報をデータベースに登録することを指す。

 

b)Read 読み取り
データベースに登録されている情報を読み取ることを指す。
合致する条件を抽出するような検索処理も含まれる

 

c)Update 更新
データベースに登録されている情報を更新することを指す。
読み取りと同じく合致する条件を抽出し、更新日時の書き換えなどを行うこともある。

 

d)Delete 削除
データベースに登録されている情報を削除することを指す。

これら四種類を「CRUD操作」と呼ぶ。


●データベースによる情報操作の管理
DBは「テーブル(表)」とテーブルの列「カラム」、情報の入った「レコード」から構成されている。

 

●コラム「データベース設計はITシステムの要」
ーどのように「表」と「列」を分けるかを「データベース設計」といい、
データベースを利用するシステムでは初期の段階で必要となる作業である。

・重複した情報を排除することを「正規化」と呼ぶ。
・データベース設計を適切に行えるかが、システムの使いやすさや汎用性に大きく影響を及ぼすことがある。
以上は「データベース設計」の重要な部分ではあるが、今回は割愛する。

 

 

・データベースから情報を抽出する
→必要な情報をSQLでデータベースへ伝える。

a)「何を」
SELECT文で指定している箇所

b)「どこから」
SELECT文で指定した個所をどこから取り出すのかを指定している。

c)どのように
条件をどのように取り出すのかそれらの条件を指定する部分

 

 

・データベースとクライアントの関係
データベースクライアント→人間がSQLを書き発行するのに向いている。
Webアプリケーション→人間ではなくWebアプリケーションのプログラムがSQLを発行している。
ex)「商品一覧」の画面を表示する際にDBから商品の一覧を取得するほうがデグレ等の不安がない。


・データベースサーバの分離
小規模)データベースサーバ上でDBMSを起動させる

大規模)Webサーバを動作させるコンピュータとデータベースを起動させるコンピュータを別々に用意し、各プロセスをそれぞれのコンピュータ上で起動させる。(負荷が小さくなる/既存システムとの結合)

 

・Webアプリケーションとデータベースの通信
webアプリケーションとDBはデータベース固有の通信プロトコルを使用し通信している。

 

●代表的なDB
Oracle Database
ーシェアが大きい。歴史がある

・Micrsoft SQLserver
マイクロソフトが開発。winにしか基本的には使えない

PostgreSQL
オープンソースとして公開されているデータベース。

MySQL
ーPostgreと同じくオープンソースGPLと商用二つの形態がある。

 

 


・5.3アプリケーションサーバ(APサーバ)の登場
概要:Javaの利用が広まった。ServretやJSPといった技術を利用してWebアプリケーションを開発するようになった。
JSPやServretはどこで動いているのか

ex)Tomcatを使った例
Tomcatは、オープンソースアプリケーションサーバ

 

大まかな流れ
1)ApacheへHTTPリクエストが届く
2)mod_jk(連携モジュール)がTomcatへ転送する(ajp13というTomcat独自のプロトコルで通信している)
3)Webアプリケーションサーバに届く
アプリケーションサーバは逆ルートで返す(3)~(1)に向かうような)


・WebサーバとAPサーバの分担
HTTPリクエストを一度Webサーバが受け取り、URLのパスによってはAPサーバに投げる。
これらをApacheTomcatの連携では、設定ファイルを書き明示的に示す。
cf)
localhost127.0.0.1(自分自身を示す)

・WebサーバとAPサーバの連携メリット
WebサーバとAPサーバを異なるノードに配置するメリットとして、

軽い処理で回数の多い静的コンテンツへのリクエストはWebサーバへ
回数が少なく処理の重い動的コンテンツはAPサーバへと
異なる性格のリクエストを分けることができる。
(APサーバを複数立てることも可能。)

 

 

●APサーバが提供する機能

a)セッション機能
JavaのAPサーバではセッションIDの管理をAPサーバが行うこともできる。

 

b)トランザクション
業務上まとめて実行すべきである一連の処理を「トランザクション」と呼ぶ。
また、処理が失敗した際には巻き戻すための「ロールバック」という処理もある。

 

c)DB接続管理
データベースの接続/切断処理を個々の処理の中で行うのではなく、システム全体で一括して管理することが一般的になっている。
APサーバではデータベースの接続を管理する機能を提供し、開発者がDBの接続状態を気にしなくてもいいようにしている。
また、Webアプリケーションの必要に応じて接続を使いまわすことでDBアクセスを高速化する仕組み「コネクション・プーリング」といったものもある

 

d)Webアプリケーションの管理とシステムの可用性・性能向上
何かの原因でAPサーバがダウンした際のために、複数のAPサーバを用意させておきダウンしたサーバの肩代わりをさせることでシステムの可用性を高める方法がある。
そのために、「セッション・レプリケーション」というAPサーバ同士が連携してセッションの状態を共有する必要がある。
これらにかかわるような機能を提供しているAPサーバも存在する。

 

 

5.4 Webシステムの三層構造
・最小構成のWebシステム
サーバサイドは一台のコンピューターの中でAPサーバとDBサーバのみ機能させる。
Webサーバ部分は、APサーバが提供する機能を利用している。

 

ex)小規模なシステムやWeb開発環境、テスト環境として利用されることが多い

・一般的な構成

①それぞれのサーバを別々のノード上に配置する。
それぞれのコンピュータの持つリソースを各サーバの役割へ最大限振り分けることができる。
ex)利用者が多く、扱うデータ数も多いショッピングサイト

 

②また扱うデータが多い割に利用者がそれほど多くないシステムではDBサーバのみを異なるノードへ分離して
WebサーバとAPサーバを同じノードへ配置することもある。
利用者が多くないものの扱う企業全体にかかわるデータを扱う場合などがある。
そのため、DBに大きなリソースを必要とする場合が想定される。
ex)利用者が限られる企業内の業務システムなど

 

 

ソフトウェア上のサーバサイドでは「Webサーバ」、「APサーバ」、「DBサーバ」の3つの構成要素が必ず登場する。
このようにWebシステムを構成するソフトウェアを大きく3つに分けて連携させる構成を「三層構成」と呼ぶ。

 

 

●現代のWebシステムを支えるオープンソースOSS
プロプライエタリ・ソフトウェア」ー購入(ソフトウェアを利用する権利を購入している)・ソースは非公開
オープンソース」ー無償利用・人類の共通財産という思想に基づきソースコードの一般公開(※無保証)

 

 

オープンソースのライセンス
cf 「コピーレフト」(考え方)
ー「GPL」はコピーレフトの考え方を最も厳格に実現しているライセンスである。
GPLではソースコードの開示を義務づけ、コピーレフトに従って派生物にもソースコード開示が義務とされる。
(これを緩めたものに「準コピーレフト」型と呼ばれるライセンスであり「LGPL」「MPL」などがある)

 

「プロになるためのWeb技術入門」lesson1-3まで

人に勧められたのでとりあえず、「プロになるためのWeb技術入門」を読んでます。

とりあえず、以下は備忘。

 

 

 

## lesson1「Webアプリケーション」とは何か
・Webアプリケーション
    処理の主体がサーバー、画面の表示がWebブラウザ、インストールが不要のものを指す

 

##lesson2 Webはどのように発展したか    
・wwwの誕生
→図表などをテキストファイル形式で表現できるようにHTML、また相互参照のためにハイパーリンクなども生まれた

 

●Webを支える技術の発明
 ・Webサーバーとクライアント
 ・wwwによるハイパーテキストの公開と閲覧は「Webサーバー」と「Webクライアント」というソフトウェアで成り立っている。
 wwwでは、webサーバーがネットワーク上に公開するハイパーテキスト(htmlの形式ファイル)を蓄積し、webクライアントの要求に
 したがって必要なHTMLファイルを渡す仕組みになっている。
 ・一般的にクライアントからサーバーに対する要求を「リクエスト」、
 サーバーからクライアントに対する応対を「レスポンス」と呼ぶ。
 ・現在webサーバー用のソフトウェアとして、「Apache」や「IIS」(cf.「nginx」)などが利用されている。
 ・Webクライアントは「IE」、「Firefox」、「Safari」などが一般的

 

●なぜクライアントとサーバーに分けるのか
 ・wwwのように様々なコンテンツを不特定多数の人にコンテンツを公開するには、コンテンツをできるだけ一か所にまとめておいたほうが(更新などの)管理が楽になるため。そのため、wwwを実現するにはWebサーバーのように1つのコンピュータに情報を管理する
 ・wwwでは多くの人が自由にコンテンツを閲覧できなければならない。そのため、利用者の手元にあるPCをWebクライアントとして利用できるようにした。●「そのリソースはどこにある?」-URL
・url -リソース(資源)の位置を指し示す統一的な記述方法
スキーム、ホスト名、パス名で構成される。a)スキーム
リソースを取得する方法を示す
https 暗号化されたhttp通信を表すスキーム
mailto 電子メールの宛先を表すスキーム
ftp ftpプロトコルによるスキーム
file ファイルシステムのなかのファイルやディレクトリを参照するためのスキームb)ホスト名
リソースが存在するホスト(コンピューター)名を示す。ネットワークに接続され他のコンピューターからのリクエストを受け取り結果を返すものをホストコンピューターと呼ぶ。
ホスト名にはローカル名と親ドメイン名に分けられる。

 

・親ドメイン名 ホストが存在する組織を示す
(親ドメインは自由に決めてしまうとインターネット上での一意性が失われるため、指定された団体が管理をしている)
・ローカル名 組織のなかのコンピューターにつけられた名前c)パス名
ホスト名で指定されたリソースの位置を示す

 

●HTTP
サーバーとクライアントがやりとりするためには通信を行うための取り決めを「通信プロトコル」とよぶ。また、HTMLの転送に適したプロトコルを「HTTP」(他のプロトコルと比べてシンプルかつ実装が簡単である)と呼ぶ。
1996年、HTTP/1.0
現在はHTTP/1.1普及している。●コラム
以上の規約・仕様はインターネット上に公開されておりRFCと呼ばれる。●CGIの誕生・静的コンテンツへの要求~CGIの誕生
 サーバーは元々用意されていたコンテンツをクライアントからのリクエストに応じて返していた。
 Webサーバー上で動作するプログラムを作成し、そのプログラムが人間の代わりにコンテンツを生成することを考え出した。
 動的コンテンツープログラムによって生成されたHTMLをはじめとするコンテンツ
 静的コンテンツー従来のようにあらかじめ用意されたコンテンツ
 動的なコンテンツを生成してWebクライアントに渡すにはWebサーバとコンテンツを生成するプログラムとの連携が必要である。
 そこで「CGI(Common Gateway Interface)」という仕組みを考え出した。
CGIではWebサーバがクライアントから受け取ったリクエストをWebサーバ上に動作するプログラムへ渡す。
 プログラムはリクエストを参照してHTMLを生成し、Webサーバーに返した。
 これらのコンテンツを生成する目的で活用されたのが「Perl」や(大規模なものや高速性が求められるもの)「C」
 であった。・Webの爆発的な普及
 CGIの普及によって「検索サイト」、「掲示板システム」、「ショッピングサイト」などを提供するサイトが実現できるようになった。
 
サーブレットの登場
 ①開発言語の問題、②性能の問題の二点の問題が浮上した。
 ①大規模化、複雑化によって当時主に使われていたPerlが、
 テキスト処理を得意としていたために大規模なアプリケーションの開発を得意としていなかった。また、
 オブジェクト指向プログラミングも取り入れられていなかった。
 ②Webブラウザからリクエストが届くたびにCGIを通してプロセスを起動していた。これらには時間がかかりすぎ処理が追い付かなくなった。
 
 Java/サーブレットの誕生
 この時期に登場したのが「Java」である。
 ・オブジェクト指向の機能のフルサポート
 ・Cに似た文法
 ・(マルチスレッド・セキュリティ・ネットワーク通信など当時重要性が増していた技術が標準であった)
 といった利点から多くの開発者に受け入れられた
 Java自体はWebアプリケーションのために開発された言語ではなかったため、
 JavaEEの一部として「サーブレット」というWebアプリケーション開発をサポートするための機能が提供されるようになった。
 
 「サーブレット」とは、JavaでつくられたHTMLなどのWebコンテンツを生成するプログラムのことを指す。
 コンテンツを生成する言語がJavaであり、オブジェクト指向のサポートによって大規模アプリケーションの開発に向いていること、 Webサーバーと同じプロセスを毎回起動することなく、比較的高速に動作する利点があった。
 
Javaでアプリケーションを開発する利点
 Javaには特定のOSやハードウェアに依存せずに動作する。
 これらはC言語のようにソースコードを直接コンピュータの機械語コンパイルするわけではなく、
 「JavaVM」と呼ばれる仮想のコンピューター言語にコンパイルして実行するためである。
 しかし、サーブレットの場合「Webコンテナ」の設置が難しいなどの点もあります。

 

●コラム cf.Javaアプレット
JavaアプレットWebブラウザ画面の中でJavaプログラムの実行をできるようにしたものである。

 

JSPの誕生
サーブレットの問題点

①デザイン修正(Webデザイナー)、プログラムの修正(開発者)で同じソースを触るため、問題が起きやすくなる
②(javaからhtmlの文字列をそのまま書きだす形式だったため)出力されるhtmlが想像しにくい
これら問題点を解決するために、jspが誕生した。・JSPの誕生
jspでは動的に出力したい部分を「<%」,「%>」で括りその内部にJavaプログラムを記述することができる。
このようにJSP内部に書かれたJavaプログラムを「スクリプトレット(Scriplet)」と呼ぶ。
JSPの誕生によって開発者はJavaコード部分に集中し、Webデザイナーはhtmlの部分に集中することができるようになった。

 

●Webアプリケーションフレームワークの時代
サーブレットJSPの問題点
①大規模なアプリケーションをゼロからサーブレットJSPで作成しているとコーティン量が膨大
②開発現場によって独自のライブラリが多くできてしまう
・webアプリケーションフレームワークの誕生
よく使われる処理は「ライブラリ」と呼ばれるプログラム部品として整備されていた。
→これらの考え方をさらに進め、再利用できる部品を増やしてアプリケーションを開発しやすくする土台となったものを「フレームワーク」と呼ぶ。##lesson3 HTTPを知る
・HTTPの知識はなぜ必要か
Webアプリケーションでの不具合が起きた際に、「なぜ起きたのか」などの問題切り分けに大きな役割を果たすため。

●HTTP通信をのぞく
「プロキシサーバー」と呼ばれる仕組みを使い、HTTPリクエストをのぞく。リクエストの1行目をリクエストラインと呼びHTTPリクエストで重要な部分である。
リクエストラインは「メゾッド」、「URI」、「HTTPバージョン」の三つで構成されている。

 

a)メゾッド
リクエストの種類を表す。本書の例では「GET」つまり「URIで指定した内容を送ってください」という意味になっている。
メゾッドには他にも何種類か定義があるが、大半はGETメゾッドによるリクエストである

 

b)URI
例のGETなどのみでは「どの」情報が欲しいかなどの部分が欠けている。そのため、「何が欲しいのか」を表すのが「URI」である。c)HTTPバージョン
HTTPのバージョンを表す。バージョンによって利用できるメソッドの種類やリクエスト・ヘッダーの種類が変わるため、ここでどのバージョンなのかを指定している。2行目以降の残りの部分は「メッセージ・ヘッダー」と呼び、リクエストの付加的な情報を表す。
メッセージ・ヘッダーは各行が<フィールド名>:<フィールド値>という形式で表されている。以下は代表的なヘッダーの意味である。

 

d)Accept
Webクライアントが受け取ることのできるデータの種類を表したもの。データの種類はContent-Typeという形式で表され、
クライアントで受け取ることのできるContent-Typeをコンマ区切りで指定している。ex)テキストファイルを示す「text/plain」、JPEG画像を表す「image/jpeg」e)Accept-Language
Webクライアントが受け取ることのできる自然言語(人間の使用する言葉)の種類を示す。
Accept-Languageヘッダーによって、webサーバーがクライアント使用する言語に合わせたコンテンツを返すといったことができる。
ex)Accept-Language 「ja-JP」

 

f)User-Agent
利用しているWebブラウザの種類やバージョンを示す。
Webサーバーがアクセスしてきたクライアントの種類に応じて適切なコンテンツを返すために利用されている。

 

g)Host
リクエストの送信先ホスト名やポート番号を指定する●コラム
URI、URL(URN)
リソースの位置を指定する為にURLが考え出された。その後、その拡張した概念としてURI(URLにURNを加えたもの)が考え出された。
※URNは使われる機会がめったにない●HTTPレスポンスをのぞくa)ステータスライン
HTTPレスポンスでも1行目、HTTPステータス・ラインが重要となる。HTTPバージョン/ステータスコード/レスポンス・フレーズ の3つで表現され
→HTTP/1.1 200 OK のような形になる・ステータス・コードは、3桁の数字とそれに続くメッセージで表されている。

 

最初の1桁目の数字がカテゴリーを表している。1xx (情報ーリクエストの処理が継続していることを示す)
2xx (成功ーリクエストが成功したことを示す)
3xx (リダイレクションーリクエストを完了させるにはさらに動作が必要であることを表す)
4xx (クライアントエラー -クライアントに起因するエラーによってリクエストが失敗したことを示す)
5xx (サーバ側に起因するエラーのため、リクエスト失敗したことを表す)ex )
200 (OK リクエストが正常に完了した)
302 (Found リクエストされたリソースが一時的に別のURIに属していることを示す。リダイレクトで使用される)
401 (Unauthorized ユーザ認証に失敗したことを示す)
403 (Forbidden アクセス権限なしにより、サーバにリクエストを拒否されたことを示す)
404 (Not Found リクエストに一致するリソースが見つけられなかったことを示す)
500 (Internal ServerError サーバ内部のプログラム実行においてエラーが発生したことを示す)b)メッセージ・ヘッダー
HTTPリクエストのメッセージ・ヘッダーと同じ形式でレスポンスに関する付加的な情報が入っている。c)メッセージ・ボディ
例えばHTMLファイルを要求した場合はHTMLファイルの内容がそのまま入る
JPEG形式の画像ファイルを要求した場合そのデータがそのまま入る。)

 

3.3 情報はどのようにインターネットの大海原を超えるのか

 

●インターネット上の住所・IPアドレス
・URLのホスト名部分は、人間に理解しやすい文字列で表現されているが、実際はインターネットに接続されたコンピュータは「IPアドレス」という数値によって識別されている。
IPアドレスとはピリオドで区切られた4組の数字で表される。●IPアドレスを頼りに情報を届ける TCP/IP
IPアドレスが分かると宛先のホスト名が特定でき、情報を届けることができる。これらの役割を担うのが「TCP/IP」と呼ばれるプロトコルである。
TCP/IPはブラウザなどから受け取ったHTTPリクエストなどの情報を「パケット」という小さな単位に分割して送信し、受け取った側で元のように組み立ててから受け手となるWebサーバなどのアプリケーションへ渡している。つまり
・情報はパケットと呼ばれる単位に分割されて送受信されている
・パケットの送受信はTCP/IPが責任を持って行っている。●IPアドレスは誰が決めるのか
IPアドレス世界中で唯一の値になる必要がある。
これらは特定の団体が管理しており、そこへ申請する必要がある。
しかし、我々私人がインターネットを利用する際にはインターネット・サービス・プロバイダーがまとまった数の確保したIPアドレスの一つをインターネットに接続するたびに一時的に割り当てられている。

 

グローバルIPアドレスとプライベートIPアドレス
・以上のようにして割り振られたインターネット上で唯一のIPアドレスを「グローバルIPアドレス」と呼ぶ。
・インターネットなどほかのネットワーク接続されてないネットワークを「プライベートネットワーク」と呼ぶ。
これを使用するIPを「プライベートIPアドレス」と呼ぶ。クラスA(10.~)、クラスB(172.~)、クラスC(192.
168.~)のように利用可能なアドレスの数によって違う。

 

●コラム
IPアドレスと個人情報
・企業ー「ゲートウェイ」という出入口サーバを通してWebサイトにアクセスする。そのため、アクセス先のWebサーバにはゲートウェイIPアドレスが通知される。そのため個人情報の特定は容易
・個人ーISP経由でインターネットに接続することがほとんどである。ISPでは毎回違うIPアドレスが割り当てられるため、個人を特定するのが難しい。しかし、IPアドレスの割り当て記録はされているため、必要があれば警察に提示されることがありうる。


●ホスト名をIPアドレスに変換するDNS
DNSドメイン名とIPアドレスの対応表を持ったコンピュータ(DNSサーバ)をインターネット上に配置しておき、DNSサーバへの問い合わせればドメイン名に対応するIPアドレスを教えてもらえるという仕組み
//TODO:nslookupのやつできなかった IPのダイレクトが禁止されてるかタイポ?ドメイン名の代わりに直接IPの指定

 

DNSはどのように実現されるか
DNSではドメイン名に対応したDNSサーバを多数用意し、情報を分散管理している。
また、jp,com,net,orgなど最上位のドメインを「トップレベルドメインTLD)」と呼び、TLDDNSサーバーを管理するのが「ルートサーバ」である。

 

●ホスト内の宛先を決定するポート番号
・受信した情報がどのようなプロトコルのものであり、どのようなアプリケーションが処理すべきかをTCP/IPは判断できない。
そこで「ポート」が登場する。TCP/IPによって情報を受け取るアプリケーションは必ず「待ち受けポート」を決めて情報を持つ。
ポートは0~65,535までの数字で表され、複数のアプリケーションが利用することはできない。
よく使われるプロトコルに関するポートは標準で使用するポートを取り決めている。
それらは「ウェル・ノウン・ポート」と呼ばれる。
以下は代表的なものである。
ex)
20,21 -FTP
22 -SSH
23 -Telent
25 -SMTP
53 -DNS
80 -HTTP
110 -POP3
443 -HTTPS3.4 Webサーバへの要求をどのように伝えるか

 


●GETによるパラメータ渡し
「クエリ文字列」ー通常のURLから「?」以降の部分。フォームに入力された文字列などをWebサーバへ渡すために使われる。

 

●アプリケーション側でのパラメータの受け取り

 

●POSTメソッドによるパラメータ渡し
・GETによるパラメータ渡しはURLに情報が含まれるために、①どのような情報をWebサーバに送信したのか第三者に漏洩しやすい。②WebサーバやWebクライアントでは利用できるURLの長さが255文字に制限されているため多くの情報が渡せないなどもある。
そこで「POSTメソッド」によるパラメータ渡しがある。
POSTリクエストの場合、クエリ文字列を使用する代わりにメッセージボディを利用してパラメータを渡す。
これによって、①アドレスバーから第三者への漏洩が減る ②メッセージボディには文字数の制限がないためパラメータの量が多い場合でも問題がなくなる。

 

●GET、POSTどちらを使えばいいか
・GETではURLにパラメーターが含まれるため、パラメーターごと人に伝えることができる。
このように同じ要求を何度も繰り返しても同じ結果が得られることを「副作用がない」と言う。
つまりGETでは「副作用がないこと」を期待する。
・POSTでは前述したようなGETにはない、機密性・(決済処理など)副作用を伴う処理・クエリ文字列に収まりきらない大量の情報などに向いています。

 

●日本語はどのように渡すか
日本語はそのままアドレスバーに入力してしまうと「文字化け」が発生する。
そのため「パーセントエンコード」が使用される。
「パーセントエンコード」とは文字列を文字コードで表したものである。
これらの処理はすべてブラウザ側で自動的に行われるため、基本的には気にする必要はない。 

 

 

 

 

 

リーダブルコード (第四部)

## 4部
# 14.テストと読みやすさ
本番のコードの振る舞いを確認するために書かれるコードを指す

・テストは読みやすくて保守しやすいものにする
→他のプログラマが安心してテストの追加や変更ができるようにテストコードは読みやすくする

・テストを読みやすくする
→大切ではない詳細はユーザーから隠し、大切な詳細は目立つようにすること
そのために、最小のテストを作り、このテストが何をしようとしているのかを簡単な言葉で説明できるようになる。

・エラーメッセージを読みやすくする
→便利なアサーションメソッドを使う
(エラーメッセージはできるだけ役に立つようにする cf.自分好みのエラーメッセージを印字する「手作りのアサート」を用意するなど)

・テストの適切な入力値を選択する

コードを完全にテストする最も単純な入力値の組み合わせを選択しなければならない
テストには最もキレイで単純な値を選ぶ
1つの機能に複数のテスト
テストコードを(ソート、マイナスは削除……といったように)分割させていることで次の人がコードを扱いやすくする・バグを発生させた際に失敗したテストによってその場所がわかる)などの効果がある

・テストの機能に名前をつける

"Test1"のような名前ではなく、テストの内容を表した名前を付けるべきである。
以下の点がすぐに理解できるといい
    ・テストするクラス
    ・テストする関数
    ・テストする状況やバグ
ex.Test_<関数名>()やテストの関数を分割する場合はTest_<関数名>_<状況>のようにするとわかりやすい。
また、テスティングフレームワークを使っている場合、その規約にのっとる

・このテストのどこがダメだったのか?(用例のまとめ)

    ・テストステートメントが長すぎる
    ・テストが簡単に追加できない
    ・失敗メッセージが役に立たない(デバッグに使える情報が足りない)
    ・一度にすべてのことをテストしている(分割するべき)
    ・テストの入力値が単純ではない(-9998.7のような値は「大音量」で目立つが、意味はないためもっと単純なマイナス値で十分である)
    ・テストの入力値が不完全(スコアが0の場合などテストしていないため、どのような振る舞いをするのか不明確)
    ・極端な入力値を使ってテストしていない(空のベクタ、巨大なベクタ、スコアが重複したものなど)
    ・Test1()のような意味のない名前がついている。テストの関数名はテストする関数や状況を表したものにする

テストに優しい開発
テスト駆動開発(TDD)
本物のコードを書く前にテストを書くプログラミング手法

・やりすぎ

    ・テストのために本物のコードの読みやすさを犠牲にしてしまう。
    ・テストのカバレッジを100%にしないと気が済まない
    ・テストがプロダクト開発の邪魔になる

・まとめ

    ・テストのトップレベルはできるだけ簡潔にする。
    ・テストが失敗した際のエラーメッセージはバグの発見や修正がしやすいものにする
    ・テストに有効な最も単純な入出力値を使う
    ・何をテストしているのか明らかにするTest_<関数名>_<状況>のような名前にする
新しいテストの追加や修正を簡単にすることが大事である


#15.「分/時間カウンター」を設計・実装する
実際のコードの改善をする

①名前の改善
→    ・ex)count()というメソッド名には名詞と動詞があり、
     この場合動詞で使っているが名詞(これまでのカウントが欲しい)と解釈されやすい。
     変更する用例として
        ●Increment()増加
        ●Observe()観察する
        ●Record() 記録する (名詞で)記録    
        ●Add()     加える

②コメントの改善
    外部の視点を得る(他の人に聞くなど。 6か月後の自分なども含まれる)

③書く→読みやすく書く

④パーフォーマンスの問題などの問題を挙げる、バグの(数字を丸めてしまうもの)の修正

⑤複数の下位問題を分割し、解決した


以上
とりあえず、一冊読んだ。この本、最初は1部をしっかり読んで定着(やってほしいことは本のなかにも書いてあるが1部にまとまっていて、後の部はその「やり方」が書いてあるだけなので)させるくらいの方がいいのかなぁと思った。
めちゃめちゃ覚えていたらになるのだけど来年も同じくらいの時期に読むと感想が変わるかもなぁという感じ。