ベンチマークについて

どれだけのユーザ数を受け止められるかを確認する

・アクセスログに記録された応答時間より算出

　応答時間の平均から大まかにリクエスト/secを算出する

・モニタリングツールサービスでの計測結果を参考にする

　たとえば、New Relicなど

 

ベンチマークツールで検証する

・Apache Benchを使う

 　例えば、100ユーザが同時にhttp://www.example.co.jp/ に1リクエストを発行した場合を想定。

　　ab -n 100 -c 100 http://www.example.co.jp/

 

　100ユーザが同時に10リクエストを発行した場合を想定。
　-nには100 x 1-0 = 1000を指定します。

　　ab -n 1000 -c 100 http://www.example.co.jp/

・以下の３ページに対してベンチマークをとるとよい

　1)トップページ

　2)トップページの次によく参照されそうなページ

　3)最も負荷のかかりそうなページ

 

サービス提供後の負荷確認方法

・top

　稼働しているプロセス別の負荷状況

・dstat

　CPU、ディスク、ネットワーク、スワップなどのサーバリソース状況

・iostat

　ストレージのIO状況、transaction数。

 

＜参考＞

Apache Benchでサクッと性能テスト - Qiita

ApacheによるWebサーバ構築（15）：Apacheパフォーマンス・チューニングのポイント (2/2) - ＠IT

 

バックアップの考え

まずバックアップ対象のデータを決める

・アプリケーションが直接取り扱うデータファイル

・設定

・ログファイル

・プログラム

 

一番大事なのはデータファイル。これ以外は最悪なんとかなるだろう。

 

考え方

  1. いつバックアップをとるのか
  2. どの範囲をバックアップするのか
  3. どこに保存するのか
  4. 何世代残すのか
  5. バックアップ完了の判断材料は？
  6. リカバリのかかる時間は？
  7. リカバリの確認方法はどのような形にするのか？

バックアップ手法

・rsync

・Amanda

・duplicity

インフラの運用（監視とモニタリング）

外形監視（ユーザから見えている状態）

　・応答時間（3~5秒）

　・HTTPステータス（400番以上はエラー）

　・HTTPキーワード（ページの末尾に含まれるキーワード）

　　途中でデータが途切れたことを検知するため

 

デーモン監視

　・プロセスの死活

　・接続可否

　　接続数超過など

　・ステータス

　　デーモン自体が管理している状態。例えばスレーブサーバの状態など

　・応答時間

リソース監視

　・CPU使用率：恒常的に90%／コア以下か

　・Load Average：Load Averageの値がコア数以上か

　　実行中、実行待ちのプロセス数、スレッド数を計算したもの。なお、CPUコア数を超える処理待ちが出ていても必ずしもサーバ全体の応答時間の低下を意味するものではない。

　・スワップメモリ：使用量が50%を超えていないか

　　メモリは大きく、プログラム利用領域、バッファ、キャッシュの3つの流域が確保されている。Linuxは、メモリに空きがあればバッファ、キャッシュへ割り当てパフォーマンスを向上させている。プログラム利用領域で足りない状況になれば先の２つから解放して回収する。そのうえでメモリが足りない場合はスワップが発生し、スワップファイルにメモリデータが移動する。

　・ストレージ：空き容量が20%以上か

死活監視

Webアプリケーションのインフラ

備忘録

自動化

・インストール、設定の自動化

　Chef（Rubyベース）、Puppet（歴史長い、独自スクリプト）、Ansible（機能は少ないが、サーバ側にエージェントは不要）

・テストの自動化

　serverspec

 

セキュリティ

・sshの公開鍵認証

　接続元のクライアントで鍵を生成（秘密鍵、公開鍵）し、サーバ側には公開鍵を登録する。

　sshd側で秘密鍵のみでログインできるように設定する

Webアプリケーションについての備忘録

Webアプリケーションのインフラってちゃんと整理してことがなかったので

ここで簡単にまとめます。まずはそもそもWebアプリケーションとは。。

 

そもそものWebサーバとのやり取り

1)Webページを見たいというリスエクスと送信

2)指定したページをレスポンスとして返す

 

URLとは？

Webページの場所を示すもの。

http://example.com/about.html

これは、

プロトコルがhttpで、example.comという場所（サーバ）の/about.htmlというパス（ページ）へリクエストを送りなさい

という意味。

 

HTTPリクエスト

GET / HTTP1.1

これは、

GETというmethodでパス「/」にHTTPのバージョン「1.1」でリクエストを送るコマンド。

実際にやり取りしているリクエスト、レスポンスの中身はいくつくのブラウザで確認することができる。

例えば、FirefoxのFirebugなど。

 

HTTPのレスポンス

主なレスポンスは以下の通り。

200：OK。正常にレスポンスが返る。

300番台：リダイレクト

400番台：クライアント側のエラー。404 NotFoundなど

500番台：サーバ側のエラー。500 Internal Server Errorや503 Serive Unavailableなど

 

動きを与えるJavaScript

クライアントサイド側での動的な仕掛けとして使われるのが「JavaScript」

・Webページの特定の部分を動かすやアニメーションを加えるなど

 

動的サイトとは？

まずは静的サイトとは？

リクエストに応じにて静的なファイルを返却する。

静的なファイルとは、HTML、CSS、JavaScrip。

動的サイトとは、リクエストに応じてサーバ側のプログラムでページを生成するもの。

例えば、ユーザにログインさせユーザごとに異なる情報を表示するページを作成したりする。

言語としては、

PHP、Ruby、Perl、Python、Javaなど

 

セキュリティ対策

XSS（クロスサイトスクリプティング）とは？

ユーザフォームなどユーザが情報を入力するサイトで、送信されたデータを再びユーザにHTMLとして描画する際に、不適切な処理を行い何かしらの攻撃を行うこと。

もっとも多いのがJavascripのコードが埋め込まれているテキストを「そのまま」HTMLをして描画すると、意図せず実行されてしまうケース。

対策としては、<>を文字参照を使い&lt;&gt;などに変換することで対応。

 

CSRF（クロスサイトリクエストフォージェリ）とは？

悪意のあるユーザがユーザに被害を与える攻撃方法。アカウント乗っ取り。

対策は、悪意のあるユーザが知りえないセッションIDなどを使ってWebアプリ側で照合する。

 

XSSやCSRFなど主な攻撃については、フレームワークが対策用の機能やライブラリを用意していることが多い。

 

CRUD

Webアプリではデータの出し入れが基本。

Create

Read

Upload

Delete

 

SQLite

MySQLやPostgreSQLのようにリレーショナルデータベースのように使える＋ファイルやメモリ上にデータが保存できるなど手軽に使えるツール。

 

CSS（Cascading Style Sheets）

質素なHTMLのページの見た目をクールにしてくれるための土台

CSSのフレームワークとしては、Twitterが提供している「Bootstrap」がある。

ソフトウェアフレームワーク - Wikipedia

 

セッション

Webアプリが1セッションを表す「セッションID」を生成し、Webブラウザのクッキーへ記録する。サーバ側はそのクッキーを取得してセッションの特定を行う。

セッションの機能はWAF（Webアプリケーションフレームワーク）で備わっていることもある。

Dockerって？

Dockerとは？

  • 元々はPaaSのエンジン「dotCloud」であった。PaaSなので、事業者側の指定した開発環境・実行環境（フレームワーク、ライブラリ）を利用するのだが、利用者から自分たちの環境を使いたいとの要望もあった？そこで利用者が独自に環境を使えるように事業者から切り離したものが「Docker」とのイメージ。
  • 役割は、アプリケーションのイメージ作成と実行。
  • 開発者は、自分で開発した環境をDockerイメージとして固めてサービス環境へ移行が可能。

 目指すものは？

  • ミドル、アプリをDockerイメージとして固めておくことでいろんな場所に開発環境で動いているものを展開することが可能。
  • ※仕組みとしてLinuxコンテナを利用。Dockerからすると内部的に利用する仕組みに過ぎない。

インフラ管理者のメリット

  • Dockerが動く環境を準備すればよい
  • OSのバージョンアップがアプリケーション都合に関係なく対応可能
  • ミドルウェアのDockerイメージ化も可能。簡単に再利用できる。

開発者側のメリット

  • 開発環境と本番環境の違いを意識することがない。Dockerイメージをそのまま移行すればよいので開発環境と同じものを利用できる。
  • 修正・拡張、パッチ当ては本番機に行うのではなく新たにDockerイメージ上の環境に実施し簡単に入れ替えることが可能。環境の使い捨てを実施可能。