『正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について』を読んだ

私はアジャイルを「ろくろを回して楽しい人」がやるものだと思っていたのですが、

この本で「良いもの(この本でいう正しいもの)」をお客さんに渡して尚且つ(無駄な)会議をなくしたいだけだったのかもなぁと思えました。

知らなかった言葉、内容のメモ

・SOR
->
動作に信頼性が求められるもの(要件定義が重い)
etc>社内システム、基幹システムなど

・SOE
->「こうあるといいのではないか」という機能の実装(誰も正解をもってない可能性がある)
etc>ECサイトなど

●不確実性との戦い方
(これまで)
・要求定義によって確実性を上げる
・合意を重視する
・合意形成を遵守する

これらの戦い方をしても開発に付随する不確実性には勝ち続けることはできなかった
(要求定義時点に戻るような手戻り、技術的な難しさなど)
->この点を解消するのがアジャイル開発としている
「あたりをつけながら開発する、関係者内で合意形成しながら進める」
(スプリントごとに開発するような形になるため、ユーザーに試してもらいやすいなど)

スクラムの難点
->経験主義(実践知)

「対話、動くソフトウェア、(顧客側などとの)協調、(計画の)変化への対応」に重きをおいている
(『アジャイルマニフェスト』)

ここの対話の部分に「心理的安全」などがかかってきている気はする。

2-4スクラムイベント　辺りを読んでいると「無」の会議をしたくないんだろうなというのは伝わってくる。

早く(少しだけ)形にできることで得られる良さとは何か？」内の④チームの学習効果が高いはSESでチームが変わる自分からすると魅力的に思えた。

3-4　スプリントの強度を高める技術
->やり抜く力(リモートワークでの開発中のコミュニケーション不足からさらに求められるようになった)

・小さくとも成果を認める必要がある(これが自分は下手)
->表面的にではなくチーム内のお互いの信頼感を醸成するには、「このチームはやれる」という期待が必要

他の参考本

・『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』は「主人公がいて...」という物語の形式になってしまっている部分が強く
(このことはあんまり言い出したらキリがないため、言ってもしょうがないのだが)
「こうしてみんなアジャイルによって幸せに暮らしましたとさ」というオチにつながりすぎているように感じた。
(本当にそれでみんなが幸せな開発が可能なのかという疑問がぬぐい切れなかった)

・『正しいものを正しくつくる』とプロフィールで同じ人だったことに気が付くなど

laravel(2)-CRUD

#環境
windows10 64bit
Vagrant

#参考にしたページなど

https://qiita.com/apricotcomic/items/07f172a957c1f342fd91
→

・全部書いてある。

・その前の”LaravelでDBにテストデータを仕込む(

https://qiita.com/apricotcomic/items/ee09850ab2b7447a2cfc

)から読んだ。

・データに関しては必ずしもこの方法でやる必要はない気がする。(DBサーバーがある場合など環境によりけりだと思うので、その都度調べるほうが安心かもしれない)

今回は参考にしたページと合わせるために比較的沿ってやった。

その他 

・blade(のテンプレート)がいまいち理解してないため、少しダサいが画面が表示されることのみを手掛けた。

#やったこと(1~3はテーブル作成)

1,マイグレーションファイルの作成

   $php artisan migrate

2,modelクラスの作成

    $php artisan make:model Book

3,seederの作成

　$php artisan make:seeder BookTableSeeder

4,controllerの作成、ルートの追加

　$php artisan make:controller BookController --resource

(5~9は

・blade.phpで画面を作る。

・controllerに処理を追加する

が大まかにやっていることです。

)

5,一覧画面

6,create画面

7,show画面

8,edit,update画面

9,del画面

#words

・seeder=>デモデータを流し込む(ためのファイル)

・store=>formで入力されたデータを保存しているメソッド

#修正点など

・手を付けたのが日曜日からだったので遅すぎる気がした。

=>一度にやってしまう癖がついているので、もう少しもらった作業分を自分で分割してみる必要があるかもしれない(cf:想定作業時間*3をすると大体ぴったりに終わるので、週3日やるとしての目標などを立てるべきかもしれない。)

git 

github.com

画面

=>delじゃなくて　writerとかの方がそれっぽかったな...。

gitプルリク、エビデンス

laravel(1)-環境構築

laravelの環境を作ってphpに入門してみたらとアドバイスされたので、
環境を作ってみました。

#環境
windows10 64bit
Vagrant

#参考にしたページなど
https://qiita.com/7968/items/97dd634608f37892b18a#%E7%AC%AC6%E7%AB%A0-%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%81%AE%E6%A7%8B%E7%AF%89
→

・めちゃめちゃ丁寧に書いてあるので、入門者向け。
大体全部書いてある。(分量があるので上の環境を作ったことのある人は読まなくていいかもしれないです。)

・若干難点は少し記事が古めなこと(version違いなどがあったら適宜ググってほしい形式)

#やったこと
細かいことは上のURLに書いてあるので、備忘録的に何をやったかだけ

(・git hubにリポジトリー作成)
(・virtualbox/Vagrantをダウンロード）
・ssh鍵ファイル作成
・Homestead.yamlを修正
・vagrant up =>仮想マシンの起動

(・仮想環境につなげるフォルダーが日本語名だったので、移動してやり直し

・Homestead.yamlの修正↓

folders:
- map: C:\app\code
  to: /home/vagrant/code

sites: - 
-map: homestead.test 
 to: /home/vagrant/code/Laravel/public

・.yamlを修正しなおしたため、

vagrant reload --provision　で再起動。(たぶんvagrant reloadでも読みこめる気がする)

)

#words
・VirtualBox
=>自分のpc(ホストos)に仮想環境(ゲストos)を作成するソフトウェア

・Vagrant
=>仮想環境を構築するオープンソフトウェア
(visialBoxと)Vagrantboxを使用することで仮想マシンのインポートができる

・Homestead
=>laravelが動作する環境を構築できるツール
　Homestead.yamlの記述をする
　
・Composer
　ライブラリの依存関係管理ツール

#修正点など
・コマンドを打つのや覚え間違えが多すぎるので何とかしっかり覚えるか、
入力補完の使い方などを覚えたい。

 ・windowsでやってるので、フォルダー名を日本語にしてたので詰まった

git 

github.com

とりあえずエビデンス(お気に入りが見えて気持ち悪かったので黒つぶし)

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

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

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

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

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

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

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

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

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

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

３、組み合わせによる不具合
サーバーとサーバ、ネットワーク装置の組み合わせにも注意点はある。
その中の代表的な一つとして 通信タイムアウト がある。
通信には一定時間やり取りがない場合接続を切断するための「タイムアウト値」が設定されている。
普段は問題にならないが、サーバ、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、
といったものがある。
作業者の負担やコストを抑えられるといったメリットがある。
（ruby、Pythonといったような言語の取得が必要になる）

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

●テストの現場

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サーバ間の通信データをSSL・TLSにより暗号化
・DBサーバの重要な一部のデータの暗号化

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

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

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

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

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

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

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

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

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

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

●サービス停止攻撃からの回避
DoSやDDoS攻撃といったネットワークを混乱させる攻撃に対する対策。
通常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"を表現する。
つまり１つのコンデンサは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の３層構造がWeb、AP、DBに特化した機能を持つサーバ群である。

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

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

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

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

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

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

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

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

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

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

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

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

・ジョブ管理

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

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

・監視（Zabbix,Nagios,JP1）

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

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

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

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

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

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

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

新人エンジニアのためのインフラ入門 ThinkIT Books

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

これはそれの備忘。

今回はchapter1~4まで

##chapter1

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

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

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

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

●システムにおけるインフラ
クライアント・サーバシステムシステム利用者が使うコンピュータであるクライアントサービスを提供するコンピュータであるサーバに分かれる
webシステムクライアント・サーバシステムの中でもクライアント側のソフトウェアとして「Webブラウザ」を使用するシステムが主流になっている。
Web３層構造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 Linux（RHEL）＞Red Hat社が提供。コストパフォーマンスに優れている。

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

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

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

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

●周辺装置

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

２、テープ装置テープ装置はストレージ装置と同様に「テープ保存に特化した装置」である。
ストレージ装置は装置内部に搭載された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 仮想化とクラウド

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

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

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

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

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

・仮想化の特徴

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

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

３、運用保守性仮想化すると物理的なIT資源を一元管理しやすくなる。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と利用者が管理できる部分が減っていく。

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

●クラウドにおけるインフラ・必要となる知識クラウドのベースには仮想化技術が使用されています。AWS「Xen」、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モデルによる処理の流れ
１、Webブラウザから送信されたリクエストはまずコントローラが受け取る。
２、コントローラはリクエストからパラメータを取り出し、必要に応じてセッションからの情報を取り出す。
３、入力情報を処理するモデルを呼び出し、各パラメータを処理、格納する
４、モデルはそれらの結果をコントローラに返却する。（この際に返すのは処理結果そのものではなく、成功・失敗程度のステータスになる）
５、コントローラは受け取ったステータスから表示すべき画面を選択し、その画面を表示するためのビューを呼び出す。
６、ビューはモデルを参照し、表示すべき情報を取り出しその結果を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」
・「インピーダンス・ミスマッチ」ーリレーショナルデータベースとオブジェクト指向の表現の違い。

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

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

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

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

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

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

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

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

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

・代表的なWebアプリケーションの攻撃手法とその対策
●SQLインジェクション
Webフォームなどの入力インターフェースを利用してデータベースに発行されるSQLを開発者が意図しない形に変更すること。（cf.不正ログイン）
インターネット経由でどこからでも攻撃が可能な点
被害者が情報流出に気が付きにくい点
→
入力値のチェック（ex.バリデーション）
プリペアード・ステートメント
（文字列連結などでSQLを組み立てず、WHERE句など条件によって変化する部分をプレースホルダとして登録したSQLを事前に用意しあとからパラメータを割り当てる方法）

●クロスサイトスクリプティング（XSS）
HTML内に悪意のある動作をするJavaScriptを埋め込む。クッキーの盗難やページの改ざんなどができる。セッションハイジャックなどにつながる恐れがある。
→
サニタイジング
（HTMLの破壊をする文字列を、無害な文字列に変換するなどの処理を行うこと。多くのプレゼンテーション層を扱うフレームワークで同様の機能を備えている。）

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

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

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

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

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

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

●クロスサイトリクエストフォージェリ（CSRF）
攻撃者が捏造したフォームから強制的にサブミットすることで、掲示板に意図しない書き込みをされたりする攻撃。
→
①フォーム表示のリクエストがアプリケーションサーバに届いた際に「ワンタイムトークン」を生成
②生成したワンタイムトークンを「hiddenパラメータ」に埋め込みフォームを表示
③サブミットされた際に、ワンタイムトークンも送られる（→これを照合し、自サーバで生成したものであればサブミットを受け入れる）

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

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

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

●ディレクトリトラバーサル
リクエストで渡された文字列を使ってシステム内のファイルを表示するアプリケーションで注意すべき（アクセスされたくない親フォルダーなどに対するアクセスを相対パスなどで可能にする）
「￥0」－ヌルバイト(￥0という文字列は文字列の終端を示すことが多いため、これが挿入されるとそれ以降の文字列が無視されてしまう)
→
サニタイジング
ファイルシステムのアクセス権を適切に設定する
ユーザから入力されたパラメータをファイル名として使用する設計にしない

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

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

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

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

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

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

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

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

●hiddenの注意点
・hiddenパラメータは任意の情報をフォームに格納することでリクエストをまたいだ情報の受け渡しを可能としている。これらはWebブラウザから容易にのぞくことができる。そのためログイン中かなどをアプリケーション上の状態を直接保持するなどはしない。
→
CSRF対策としてのワンタイムトークンを使用する。更新画面等を表示する際にサーバが発行するため、ワンタイムトークンが分からなければ捏造したhiddenパラメータを直接POSTし処理させることは困難になる。
使い捨て、推測困難なため　連続した攻撃に使えない・ワンタイムトークン捏造することも難しい。

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

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

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