Dockerを使った環境構築 Java(Spring)×Maven 

最終的にAWS上でデプロイすることを想定して、Java(Spring)の環境構築をDockerでやってみた。Mavenでライブラリ管理する前提。

手順や考え方についてコメントいただけると嬉しいです。

実現したいこと

  • なるべく簡単に実行環境を構築する。
    (Docker使うことでサーバー立てたりする作業を省く)
  • vscodeで開発する(Eclipseを使わない)

前提

  • Dockerをインストールして、Dockerコマンドを使える
  • ローカルにJava17をインストールしている

作業手順

環境構築から、アプリケーション起動まで。

雛形プロジェクトの作成

spring initializrで、以下の設定内容でspringプロジェクトの雛形を作成する。

雛形プロジェクトにあるDemoApplication.javaの中身は以下のようにする。

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class DemoApplication {

    @RequestMapping("/")
    public String home() {
        return "Dockerizing Spring Boot Application";
    }

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

}

docker-compose.ymlの作成

version: '3.6'
services:
  app:
    image: openjdk:17 # Javaのバージョンはpom.xmlの記載と同じである必要がある
    ports:
      - 80:80
    tty: true
    volumes:
      - ./server:/srv:cached # ymlファイルから見た相対パスで、雛形PJの配置場所をマウントする
    working_dir: /srv

mavenをローカルにインストール

以下の記事を参考に、インストール、PATHを通すところまで実施。
MacにMavenをインストールする - Qiita

コンテナを起動

(base) YondaHouse % docker compose up -d                           
[+] Running 1/1
 ⠿ Container yondahouse-app-1  Started         
(base) YondaHouse % docker ps    # 起動してることの確認                       
CONTAINER ID   IMAGE        COMMAND    CREATED              STATUS              PORTS                NAMES
8d12857b89c7   openjdk:17   "jshell"   About a minute ago   Up About a minute   0.0.0.0:80->80/tcp   yondahouse-app-1

プロジェクトのビルド

Javaプロジェクトを実行するには、ビルドして実行ファイル(jar)を作成する必要がある。
pom.xmlのあるディレクトリに移動して、以下のコマンドを実行。

(base) server % mvn install  
・
・
・
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  28.005 s
[INFO] Finished at: 2023-03-05T09:33:37+09:00
[INFO] ------------------------------------------------------------------------

最終的にBUILD SUCCESSが表示されることを確認する。

Webサービスを起動する

コンテナ内にログインした状態で、作成されたjarファイルを実行して、Webサービスを起動する。

YondaHouse % docker exec -it yondahouse-app-1 bash # コンテナ内にログイン
bash-4.4# java -jar target/demo-0.0.1-SNAPSHOT.jar # jar実行

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v3.0.2)

docker-compose.ymlにentrypointを追記することで、コンテナと起動と同時にjarファイルを実行することもできる。こうすると、コンテナに入ってjarを実行する手間が省ける。

version: '3.6'
services:
  app:
    image: openjdk:17
    ports:
      - 80:8080
    tty: true
    volumes:
      - ./server:/srv:cached
    working_dir: /srv
    entrypoint: ["java","-jar","target/demo-0.0.1-SNAPSHOT.jar"] # コンテナ側のjarファイルを指定する。

ブラウザに接続してみる

https://localhost:80/にアクセスして、DemoApplication.java(雛形プロジェクトの/server/src/main/java/com/example/demo/DemoApplication.java)で指定した文字が表示されることを確認。

気づき

本番環境で不要な環境条件(maven)について

mavenを使った開発をするのであれば、openjdkとmaven両方のイメージが必要。
そして、mavenはビルドするのに必要だけど、本番環境では使わないものなので本来ならコンテナを分けるべき。

ただ、Mavenのコンテナだけ分けて立てるのは結構面倒そう(たぶんDockerfileで別に定義して別で起動することになる?)

openjdkのみのコンテナにして、mavenはローカルにインストールする。
mavenをローカルに入れるということは、開発環境(mavenを使う環境)としてローカルにJavaをインストールする必要がある。

ローカルにJavaをインストールしておく。

結果的に、Dockerを使うメリットの一つである「ローカルを汚さない」ということは今回諦めた。。

Dockerを使った環境構築について

Dockerを使って環境構築することの意味がよくわからなくなったので、ざっくりまとめてみた。

Dockerを使った環境構築は何がうれしい?

Dockerを使うことで以下のメリットがある。

  1. アプリケーションが動作する環境を手軽に作成できる
    Dockerfileもしくはdocker-compose.ymlに設定情報を記載してDocker起動するだけで、環境構築が完了する。 Dockerを使わない場合、サーバー(Linux)やミドルウェアApache)、プログラミング言語の実行環境を自分で構築する必要がある。

  2. メンバー間や環境(本番、評価、開発)間での環境差異をなくすことができる
    環境の情報がDockerfileもしくはdocker-compose.ymlにまとめられるため、これを配布することで同じ環境を簡単に作ることができる。

  3. ローカル環境を汚さない
    環境構築のために必要なものをローカルにインストールして使用するわけではないため、例えば別の作業でローカルのファイルに変更があった際に、開発環境への悪影響がない。

「環境差異をなくす」とは

ここでの環境とは、開発環境というより実行環境のイメージ。
実行環境とは、プログラムを動かすにあたって必要なものが揃った場所のこと。

つまり、開発段階で動作確認する時の環境と、評価や本番で動かす環境の条件(使用しているプログラミング言語のライブラリのバージョンなど)を揃えるということ。

dockerコマンドとdocker composeコマンド

dockerコマンド
Dockerfileで単独のコンテナを起動する。

docker composeコマンド
docker-compose.ymlで複数のコンテナを起動する。

アプリケーションを実行するためには、基本的に複数のコンポーネント(Webサーバー、DBサーバーなど)が必要になる。そのため、アプリケーションの開発ではdocker composeを用いることが多い。さらに、コンテナ起動時に必要な環境変数やディスクのマウント、ポートの設定などをdocker-compose.ymlに書いておくことで、コマンド実行時にオプションを指定する必要がないため、dockerコマンドに比べると実行するコマンドが簡潔に済むというメリットもある。

また、Dockerfileとdocker-compose.ymlは併用も可能。Dockerfileをビルドする設定をdocker-compose.ymlに書いておくことで、Dockerfileでカスタマイズしたimageをビルドして使うこともできる。

参考

Dockerで環境構築するための最低限の概念理解 - Qiita

[Django] Dockerファイルとdocker-compose.ymlの違い

docker-compose.ymlとDocker fileの使い分けについて

【初心者向け・図解】Docker Composeとは?Dockerとの違いを現役エンジニアがわかりやすく解説 – エンジニア女子の自習室

【Web】Webシステムの構築時に考えること

どんなサービスを提供するか

サービスの内容

  • 何を提供するサービスか
    例)ショッピング、SNS、ブログ

  • どんな人を対象にしたサービスか
    例)男性、女性、学生、高齢者、特定の職業に就いている人、趣味(本、音楽、、)

  • どんな時に使用するサービスか
    例)24h365d、日中帯のみ、イベント時、、

アプリケーションに必要な機能、デザイン

サービスの内容から、それを実現するためにアプリケーションとして必要な機能、デザインを検討する。

  • データを保存する必要がある → DBへのデータ保存やデータ取得をする機能が必要。
  • 外部サービスとの連携が必要 → API実装が必要。
  • 高齢者向き → 文字が大きめでわかりやすいUIデザインが必要。

システム基盤に求められる機能

アプリケーションに必要な機能を実現するために、システム基盤に必要な機能を検討する。

  • データベースが必要なら、DBサーバーを準備する
  • 個人情報を保存するのであればセキュリティを高める
  • 24h365d稼働想定であれば、サーバーを冗長構成にして安定稼働を目指す

プログラム開発でどんな言語、ソフトウェアを使用するか

利用言語

言語ごとに処理の得手不得手や、実行環境の構築要否など特性がある。開発するアプリケーションに沿って選定が必要。

OS

アプリケーションを動作させるOS。基本的にはWindowsLinuxであるが、比較的安価に利用できるLinuxが選ばれる場合が多い。 ※ソフトウェアを載せる機器のOS?

ミドルウェア

サーバーソフトウェアのこと。OSとアプリケーションの中間に位置する。
使用するOSによって使用できるものが絞られることもある。

ネットワーク構成

ネットワークは3つに分割して、DBサーバーなど機密情報の保存先へはインターネットから直接アクセスできないようにすると安全。

  • 外部ネットワーク
    インターネットからアクセス可能な、ファイアウォールより外部のネットワーク。

  • 内部ネットワーク
    インターネットからアクセスできないネットワーク。

  • DMZ(DeMillitarizedZone)
    外部ネットワークと内部ネットワークの間に位置し、双方からのアクセスが可能なネットワーク。ファイアーウォールを通ることのできる通信のみを内部ネットワークに通す。

ネットワーク機器構成のボリューム

  • ファイアフォール
    インターネットから接続するようなシステムなら必須。
  • IDS, IPS, WAF
    高価であるため、求められるセキュリティ要件次第。

さらに、耐障害性を高める場合にはこれらの機器を複数配置して稼働が止まることがないようにする。

サーバー構成

各ネットワークに配置するサーバーの構成を検討する。

配置先のネットワーク

インターネットに接続する必要があるサーバーはDMZに、必要がなければ内部ネットワークに配置する。

サーバーの冗長構成

ある程度のリクエスト量が予想される場合は、Webサーバー、APサーバーを複数配置することも検討する。また、システム全体的として可用性を重視するのであれば、各サーバーを複数台とすることも考える。
Webサーバーを冗長構成とする場合、リクエストを各サーバー機器に振り分けるためにロードバランサーを設置する。ロードバランサーを設置すると、サーバーの負荷分散も実現できる。

サーバー基盤の検討

  • クラウド
    仮想サーバーを設置できる環境にサーバーを設置する。

  • オンプレミス
    自身(自社)で、機器を購入して設置する必要があるが、自由度が高い。

  • レンタルサーバ
    他者のサーバーに間借りさせてもらい、自分のWebアプリケーションを配置する。

近年は、自由度の高さや気軽な課金体系から、企業個人ともにクラウド利用者が急増している。(サーバーのディスク構成やセキュリティなどの設計は、各クラウドサーバーごとのベストプラクティスを確認する。)

DB設計

論理設計

DBに格納すべきデータの洗い出しとそのデータ同士の関連性を定義する。
関連がある場合は、1対1なのか、もしくは1対他(0以上)、1対他(1以上)なのかも考える。さらに、洗い出したデータに重複がないように整理する。

物理設計

論理設計で整理したデータを実際のDBにどう格納するかを定義する。
データ型や、文字数、整数なのか小数を含むのか、など、、

バックアップ

バックアップの対象は、アプリケーションやコンテンツのファイル、DBの中身。
基本的に別のサーバー機器(物理的に異なる場所)にバックアップのデータを保管しておく。復旧時にできるだけ障害地点の状態に戻すために、できる限り頻繁にバックアップをとっておく必要がある。過去のバックアップは何世代か残しておくのが望ましい。

Webサイトのパフォーマンス

応答時間などのパフォーマンスは、システムに対する利用者の満足度につながる。これはリクエスト数増加によるサーバーへの負荷によって影響を受ける。
パフォーマンスを維持するために、サーバー負荷状態を示すCPU使用率やメモリ利用率を監視しておき、異常があれば適切に処置しシステムを改善していくことが重要。

参考

イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon

(Apache/Nginx/IIS)Webサーバー機能とは?よく使われるサーバーごとの違いについても解説 | クラウド導入・システム運用ならアールワークスへ

【Web】セキュリティと認証

情報セキュリティ

情報の「機密性」「完全性」「可用性」を維持すること。

  • 機密性
    アクセス権がある者だけがアクセスできる状態であること。

  • 完全性
    情報が改竄、消去など、手を加えられていない状態であること。

  • 可用性
    利用者が必要な時にアクセスできること。

攻撃の種類

パスワードを盗む:パスワードクラッキング

会員制のWebサイトなどで、パスワードを繰り返し入力して正しいパスワードを抜き出そうとする攻撃。
パスワードの長さを指定したり記号を必須とする、また入力を試すことのできる回数を制限する、などで対策できる。

サーバーに負荷を与える:DoS攻撃

短時間にサーバーが処理しきれないような数のアクセスを行い、サーバーをダウンさせる攻撃。SYN Flood攻撃や、F5攻撃などがある。
不自然なアクセス数の増加を検知し、送信元のIPアドレスからのアクセスを遮断するような手段を取る。

CookieやURLの仕組みを利用した攻撃

  • セッションハイジャック
    認証機能のあるWebサイトなどで、第三者CookieやセッションIDを取得し、ログイン済みのユーザーになりすましてシステムを利用すること。
    CookieやセッションIDは通信の盗聴などで盗まれることがあるため、通信を暗号化したり、ログインしたユーザーが異なるIPからアクセスしてきた場合に強制的にログアウトさせるなどの対策が必要となる。

  • ディレクトリトラバーサル
    URLでWebサーバーのディレクトリ名を相対パスで指定し、Web上に公開する想定のないファイルを送信させること。
    リクエストのURLをチェックし、公開していないファイルを指定していないか確認することで防ぐ。

スクリプトを送り込む

  • クロスサイトスクリプティングXSS
    Webサイトに悪質なスクリプトが埋め込まれることで、利用者の操作によってスクリプトがWebサーバーに送信され、結果として利用者のブラウザ上で偽のページが表示されたり、Cookie情報が漏洩することがある。

  • クロスサイトリクエストフォージェリCSRF
    XSSと同様に、Webサイトに悪質なスクリプトを埋め込み、利用者の操作によってスクリプトをWebサーバーに送信する攻撃。認証機能のあるWebサイトでログインした状態の利用者をターゲットとし、罠ページに誘導し意図しないリクエストをWebサーバーに送信させる。結果として、利用者の登録情報の改ざんや、ログインした状態でしか利用できないサービスを悪用されることがある。

  • SQLインジェクション
    利用者が入力した情報をDBサーバーに連携する処理を行う画面で、送信する内容にDBが解釈できる情報(SQLクエリ)を混ぜることで、DBに意図しない操作をさせる攻撃。

悪質なスクリプトを埋め込むような攻撃に対しては、入力欄でのサニタイズ処理(スクリプトの構成に必要な特殊文字エスケープ処理)やプログラム上での入力値の制限などが有効である。

対策

攻撃者からのアクセスを防ぐ

  • ファイアーウォール
    サービスに必要な通信のみを許可し、それ以外の通信を遮断するもの。 インターネットと内部ネットワークの間に設置して、通信されるデータを監視し、通信の許可・拒否を行う。
    パケットフィルタ型と呼ばれる方式では、送受信されるデータ(パケット)のIPアドレス、ポート番号をチェックして、通信可否を判断している。
    不特定多数のユーザーが利用するシステムの場合、IPアドレスで通信可否を判断することは難しいが、ポート番号を制限するだけでも攻撃手段を減らす効果はある。

  • IDS, IPS
    ファイアーウォールを通過してきた通信を監視する手段。
    ネットワーク上の通信を監視し、不正アクセスと見られる通信や異常な通信を検知する。不正アクセスの検知方法としては2つある。1つは、既知の攻撃による通信パターンと比較して一致すれば不正と判断する方法(シグネチャー型)、もう1つは、普段の通信とは大きく異なる通信パターンを検知する方法(アノマリー型)である。
    また、不正を検知したときの動きとして、IDSは管理者に通知するのみでIPSは通知と同時に通信の遮断まで行う。
    → IDS, IPSによってDoS攻撃のような明らかな攻撃は防ぐことができる。

  • WAF(Web Application Firewall
    送信されるパケットの中身をチェックするファイアーウォール。データパターンをチェックして、特定のパターンのデータの通信を遮断する、もしくは正常なデータパターンに適合する通信のみ通す。
    WAFは、高機能な仕組みであるものの機器が高価であることや運用にもコストがかかるため、導入前に検討が必要である。

Webアプリケーション側での対策

暗号化

通信の盗聴リスクを考えて、通信や保存データの暗号化が必要である。

公開鍵証明書(SSL証明書

やり取りする相手が本物であることを証明するもの。
公開鍵証明書によって、アクセスするWebサイトが本物であることを確認(Webサイト側からすると証明)できる。 公開鍵証明書は認証局から発行され、偽造されにくく偽造されても検知できる。Web上での身分証明書とも言える。

本人確認の仕組み

認証

Webサイトごとではなく、利用者の多いWebサイト(Google, Twitter, Facebookなど)が認証の仕組みを提供することも増えている。

参考

https://www.amazon.co.jp/dp/4797388811/ref=cm_sw_r_tw_dp_NBMH9B9CJXY503PKBGP6

【Web】スクリプト言語とデータ形式

Webサイトの動的処理にはスクリプト言語が使用される。 スクリプト言語には、サーバーサイドスクリプトとクライアントサイドスクリプトがある。

サーバーサイドスクリプト

Webサーバー側で動作し、クライアント(ブラウザ)に結果を返す処理を行うプログラム言語。
(例)PHP, Ruby, Perl, Pythonなど

クライアント側からの要求を受け取ったサーバーが、クライアント側から送信されたデータやサーバーにあるデータを使って処理を行い新たに作成したファイルを返す、という流れで動作する。
この方式をCGI(Common Gateway Interface)と呼ぶ。サーバーサイドスクリプトCGIから呼び出されるため、HTMLとは別のファイルに書く。

クライアントサイドスクリプト

クライアント(ブラウザ)側で動作するプログラム言語。
〈例〉JavaScript, css
HTML内に直接書き込むことも可能だが、Webサイト内で使いまわすことが多いためファイルを分けるのが一般的。

DOM(Document Object Model

HTMLやXML文書の各要素を参照、制御するための手法(API)。
DOMでは、対象となる文書の各要素を抽出しそれらを階層構造として扱う。 DOMを経由することで、プログラムからHTMLやXMLの要素にアクセスして操作することができる。

現在ではほとんどのWebブラウザがDOMを実装しており、JavaScriptを使ってDOM経由で要素を取得し、HTMLを操作することができる。

JSONJavaScript Object Notation)

Web上のデータのやり取りによく使用される。理由は以下。

  • JavaScriptの書式に従っているため、そのままJavaScriptとして読み込むことができる。
    XMLのようにDOMを使用する必要がない。

  • データサイズが小さく転送が速い。
    XMLなどと比較するとタグ名などが不要な分、データサイズが小さく済む。

参考

イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon

スクリプト言語

【Web】Webアプリケーションの基本

MVCモデル

MVCモデルは、サーバーサイドスクリプト部分の設計モデル。

  • Model
    データ処理に関する部分。コントローラから命令を受けて処理を実行し、結果(表示データ)をビューに渡す。

  • View
    出力(表示)部分に関する部分。コントローラから表示命令を受けて、モデルに対してデータを要求し、返ってきた結果を受け取って表示する。

  • Controller
    ユーザー(クライアントサイド)からの命令を受けて、ビューとモデルに命令を出す。

Webサーバー

Webサーバーは、Webクライアントからの命令を受け取る役割を担うプログラム(が動いているコンピューター)である。

クライアントからのリクエストを受け取って静的コンテンツを配信したり、動的処理が必要であればAPサーバーに処理を依頼する、といった動きをする。

Webサーバーの構成について

Webサーバーが動作しなくなると、サービス提供ができない上に、ユーザーに対して サービスが停止中であることの通知もできない。そのため、Webサーバーは冗長構成をとるのが一般的である。

冗長構成とすることで、クライアントからの大量アクセスを捌くことができ、どれかが故障しても他のサーバーで処理を継続できる。また、こういった運用とする場合は、全サーバーで常に同じコンテンツが保存されるようにしておく必要がある。

サーバーに求められる性能

リクエスト量が増えたときの、レスポンス処理の速さが求められる。
レスポンス処理を早くするための性能としては、以下がある。

  • ハードディスクの読み取り速度
  • CPUの性能の高さ

Webクライアント

Webシステムを利用するためのプログラムのこと。Webサーバーにリクエストを送り、Webサーバーからのレスポンスを受け取る。

Webクライアントの種類

アプリケーションサーバ

APサーバーとも呼ばれる。 Webアプリケーションにおいて、サーバーサイドのプログラムでデータ加工などの動的処理を実行する役割のサーバー。

3層アーキテクチャにおいては、アプリケーション層に位置しており、プレゼンテーション層とデータ層の両方とやり取りを行う。実行するプログラムが複雑になるほど負荷がかかりやすいため、CPU性能やメモリ容量の設定が重要となる。

※Webサーバーのみで動的処理やデータ処理を担うこともできるが、サーバーへの負荷を考えて、動的処理はAPサーバー、データ処理はDBサーバーというように分散した構成にすることが一般的である。

APサーバーの機能

  • セッション管理機能
    ショッピングサイトなどでステートフルな処理を行う必要がある場合、APサーバーがセッションIDを発行して、セッション管理を行う。APサーバーは、クライアントごとにセッションIDを発行し、それを通信データに含める。

  • トランザクション管理機能
    セッション中の、一連の作業の最小単位をトランザクションと呼ぶ。
    予約手続きなど1つの通信で完結しない処理については、関連する通信を一つのトランザクションとしてまとめて管理している。トランザクション内の処理は、一つでも失敗すればトランザクションとしては失敗と見なされる。

データベース管理システム(DBMS

DBMSがのったサーバー機器をDBサーバーと呼ぶ。

DBサーバーの構成

データ保持のため、DBサーバーは冗長構成をとることが一般的である。 冗長構成とする上で、使用している機器間でのデータの同期をとることが重要となる。 冗長化の方法としては以下の3つがある。

  • ミラーリング
    APサーバーからの命令を受ける正のDBサーバーが更新命令を受けたときに、同時に副DBサーバーのDBMSに対して、同じ命令を転送する方法。平常時は、正のDBに対して命令が送られ、障害時には副のDBに命令が送られる。

  • レプリケーション
    ミラーリングと同様に、正のDBサーバーを更新したときに他のDBも同様に更新する方法だが、更新履歴を転送するという点が異なる。更新履歴の情報を受け取った副DBサーバーは、任意のタイミングでDBの更新を行う。

  • シェアードディスク
    DBを共通の一つの機器にもち、複数のDBサーバからそれを更新しにいく方法。この場合、DBサーバーには正副の概念はない。(APサーバーからどのDBMSにも命令が行くことがある。)また、DB自体は冗長化されないため、障害に強い機器を採用する。

キャッシュサーバー

更新が少ないコンテンツやデータとリクエストをキャッシュサーバーに保存しておき(この記憶をキャッシュと呼ぶ)、同じリクエストがあったときにキャッシュサーバーからコンテンツを読み出すようにすることで、サーバーの負荷を下げることができる。
Webサーバーの手前にキャッシュサーバーがいて、記憶しているリクエストが来た場合にはキャッシュサーバーからレスポンスを返すイメージ。

キャッシュの有効期限

キャッシュには有効期限をつけておく必要がある。同じリクエストに対して同じレスポンスを返し続けると、コンテンツやデータの更新がレスポンスに反映されなくなるため。

Web API

プログラムが、外部のWebシステムの機能を利用するためのインターフェース。 プログラムがWeb APIにデータを送信することで、データを受け取った外部のWebサーバーがプログラムに対して処理結果を返す。プログラムは受け取った結果を処理に使ったり、表示したりする。

〈WebAPIの例〉

  • 位置情報を送信すれば、その場所の天気予報が送信される天気予報API
  • ログイン情報と投稿内容を送信すれば、Twitterにその文章が投稿されるTwitter投稿API

マッシュアップ

複数のWebサービスを組み合わせて、新たなWebサービスを生み出すこと。
マッシュアップでは、Googleマップなどの位置情報やAmazonの商品情報がよく使用される。

CGI(Common Gateway Interface)

Webサーバー上でサーバサイドスクリプトを実行する仕組み。
クライアントがCGIプログラムの場所(URL)にアクセスすることで、プログラムが起動する。 WebサーバーはCGIへのリクエストに対してはCGIプログラムの実行結果を、それ以外のリクエストに対してはURLに対応するコンテンツを返す。
APサーバーを用意することなくサーバーサイドスクリプトを実行できるため、小規模な動的ページの作成に用いられる。

CGIへのデータの渡し方

クライアントがCGIのURLにアクセスした際、CGIにデータを送信することができる。 データの渡し方は4種類ある。

  • コマンドライン引数渡し
    形式:URL + ? + データ1 + データ2
    CGIプログラムの実行と同時にデータを渡す。

  • パス渡し
    形式:URL + / + データ1 + / + データ2
    データは「PATH_INFO」という変数に格納されるため、プログラム内でこの変数からデータを取り出して使用する。

  • GETメソッド
    形式:URL + ? + データ名1=データ1 + & + データ名2=データ2
    データは「QUERY_STRING」という変数に格納されるため、プログラム内でこの変数からデータを取り出して使用する。

  • POSTメソッド
    URLとは別に、リクエストのメッセージボディとしてデータを送信する。

サーバー間の連携

Webサーバーと、APサーバー、DBサーバー間の連携は、ネットワーク通信によって行われる。つまり、IPアドレスとポート番号を指定してTCP/IP通信が行われる。

IPアドレスは機器ごとに割り当てられているため、各サーバーが稼働している機器のIPアドレスを指定する。(通信相手のサーバーが同じ機器で稼働している場合は同じIPアドレスを指定することになる。)

サーバー間の通信に利用するプロトコル

Webサーバー<>APサーバー

以下のプロトコルがよく使用される。

  • HTTP
  • AJPApache JServ Protocol)
  • WebSocket

APサーバー<>DBMS

DBMSではそれぞれ独自のプロトコルが使用されており、APサーバーがそれら全てに対応するのが難しい。そのため、ODBC(Open Database Connectivity)というAPIを使用している。APサーバーは、ODBCドライバを使用して各DBMSプロトコルに対応して通信している。

参考

イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon

スクリプト言語

Webクライアント

APサーバー

Web API

CGI

【Web】HTTPでやりとりする仕組み

HTTPリクエストメソッド

ブラウザからWebサーバーに対して出されるお願い。

GETとPOST

GETメソッドとPOSTメソッドは、HTTPリクエストメソッドの一つ。GETメソッドは、HTMLファイルや画像などのデータが欲しいときに、POSTメソッドは、入力データを送信したい場合に使用する。
GETメソッドもPOSTメソッドのように、データの送信に使用できるが、データの送信方法が異なる。GETメソッドでは、リクエスト行(URL)のパラメータにデータを指定して送信するため、送信データの情報がブラウザの履歴に残ってしまう。一方で、POSTメソッドでは、メッセージボディにデータが組み込まれるため、履歴に残ることはない。したがって、ユーザーIDやパスワードといった情報を送信する場合は、機密性の観点からPOSTメソッドを使う。

HTTPS

HTTP over SSL/TLSの略。
HTTPの通信において、暗号化方式であるSSL(Secure Sockets Layer)やTLS(Transport Layer Security)を利用したもの。

SSL/TLSの仕組み

  • 盗聴防止(暗号化通信)
    万が一傍受されたとしても内容を解読させないためにデータを暗号化する。

  • 改ざん防止
    あるデータから一意の短いデータ(ハッシュ値)を計算して取り出すメッセージダイジェストを使用して、ハッシュ値の比較により改ざんを検知する。

  • なりすまし防止(Webサイト運営元の確認)
    Webサーバーに配置されたSSLサーバー証明書を接続時に検証することで、Webサイト運営会社の身元を確認できる。SSLサーバー証明書自体は誰でも発行できるが、信頼された認証局以外の証明書が利用されている場合はWebブラウザ上に警告画面が表示され、検知できる。

ステートフルとステートレス

ステートレスは「状態を保持しない」、ステートフルは「状態を保持する」という意味。
HTTPのプロトコルはステートレスである。リクエストとレスポンスの一往復のやり取りで完結する。HTTPは、多数のクライアントからの接続が発生するWebシステムで使用されるため、要求された内容に対して応答するだけのステートレスな設計が適している。

(仮に1対1のやりとりであれば、ステートフルなシステムでも負荷にならない。)

Cookie(クッキー)

HTTPはステートレスなプロトコルであるため、WebブラウザとWebサーバーとの一連のやり取りにおいて、状態を保持し管理する仕組みがない。そのため、ECサイトなどで状態を保持し管理する必要がある場合はCookieと呼ばれるデータが用いられる。

Cookieのやり取り

Webサーバーに接続してきたブラウザに対して、コンテンツとともにブラウザに保存してもらいたい情報をCookieとして送る。

ブラウザは、受け取ったCookieを保存しておく。

次回、Webサーバーに接続するとき、保存しておいたCookieを送信する。
Webサーバーは、接続してきた相手をCookieから判断することができる。

Cookieの送信方法

Cookieは、HTTP通信のメッセージヘッダーに含めることで送信する。
ブラウザは、HTTPリクエストのヘッダーにSet-Cookieヘッダーを、Webサーバーは、HTTPレスポンスのヘッダーにCookieヘッダーを含めることでCookieを送信できる。

Cookieの有効期限

Set-Cookieヘッダーでは、オプションでCookieの有効期限を設定することが可能である。
この有効期限が設定されていないCookieは、Webブラウザが閉じられると同時に削除される。このようなCookieをセッションCookieと呼ぶ。
CookieWebブラウザの識別にも利用されるため、盗まれて他人へのなりすましに悪用されることもある。そのため、セキュリティ上の観点からショッピングサイトなどではセッションCookieがよく利用される。

セッション

ブラウザとWebサーバーのやり取りにおいて、一連の関連性のある処理の流れをセッションと呼ぶ。

〈sessionの例〉
ECサイトでの、「商品を選ぶ」「商品を買い物かごに入れる」「買い物カゴの中身を確認する」「商品を購入する」といった処理の流れ。

セッションの管理

1つのブラウザからの処理を一連の処理(=セッション)として扱いたいときには、Cookieを用いてセッションを管理できる。
セッション内でのやり取りのデータ(どの商品を買い物かごに入れたのかなどの情報)は、セッションIDと紐付けてWebサーバーに保存される。
ブラウザは、セッションIDを用いてWebサーバーに保存されているセッションデータを参照できる。
セッションIDは個人を識別するために使われるため、なりすましを防ぐ推測されにくい値である必要がある。

URI

情報やデータなどのリソースを識別するための記述方法をURI(Uniform Resource Identifier)と呼ぶ。URIのうち、リソースが存在する場所を示すものをURL(Uniform Resource Locator)という。HTTPにおいても、リソースを特定するためにURIが利用される。

URIで使用できる文字

  • 予約文字:!, #, $などの記号
  • 非予約文字:半角英数字
  • 予約文字、非予約文字以外の文字:日本語など

URIでは、非予約文字のみ使うことができる。予約文字、非予約文字以外の文字をURIで使用する場合、パーセントエンコーディングと呼ばれる方法で文字を変換する必要がある。
パーセントエンコーディングでは、「%」に表記できない文字の文字コードを16進数で表した数値を付加した形に変換する。

URL

Webページを表示するために、取得したいWebページをURLで指定する。 URLには、どのやりとりの手順で、どのWebサーバーに、何のコンテンツを取りに行くか、の情報が含まれている。

参考

イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon

HTTPリクエス