今日はちょっとマニアックな話、ステートフルとステートレスについてお話ししたいと思います。
これ、聞いたことあるけどよくわからないって人、多いんじゃないかな？
でも大丈夫、ここでしっかり理解していきましょう！

ステートフルって何？

まずはステートフルについて。

ステートフルっていうのは、端的に言うと「過去の情報を覚えている状態」のこと。
システムが過去にどんな処理をしたかを記憶していて、それをもとに次の動作を決めるんです。

例えば、Webサイトにログインする時を考えてみてください。
一度ログインすると、そのサイトは「あ、この人はもう認証済みだな」と覚えてくれてますよね。
これがステートフルな動作。ユーザーの状態を保持して、その情報に基づいて何らかの処理をするわけです。

具体例

1. Webセッション管理：
   ユーザーがWebサイトにログインしたとき、サーバーはそのユーザーのセッション情報（例えば、認証情報、プロファイル設定など）を保持します。この情報は、ユーザーがサイトをナビゲートする間、持続し、適切なコンテンツやオプションを提供するために使用されます。
2. データベーストランザクション：
   データベースは、過去のクエリやトランザクションの履歴を追跡し、それに基づいてデータの整合性を保持します。たとえば、銀行の取引記録は、口座の残高を正確に保つために重要です。

じゃあステートレスって？

一方で、ステートレスはその逆。

つまり、「過去の情報を覚えていない状態」を指します。
こっちは、過去の情報に左右されずに、その都度独立して処理を行います。

たとえば、HTTPプロトコル。
これ、実はステートレスなんですよ。
ウェブサーバーは、同じユーザーからのリクエストでも、それぞれを完全に別々のものとして扱うんですね。だから毎回、ページをリロードするたびに「誰この人？」ってなるわけです。

具体例

1. HTTPプロトコル：
   HTTPはステートレスプロトコルです。ウェブサーバーは、同一のクライアントからの複数のリクエストを関連づけません。各リクエストは独立しており、サーバーはそれぞれのリクエストを新規のものとして処理します。
2. RESTful API：
   RESTアーキテクチャはステートレスであり、各APIリクエストは他のリクエストから独立しています。例えば、REST APIを通じてリソースを取得するリクエストは、以前のリクエストやその結果とは無関係に処理されます。

ステートフルとステートレス、使い分けは？

これら二つ、どちらが良いとか悪いとかではなくて、用途によって使い分けるのが大事。

ステートフルは、ユーザーに合わせたカスタマイズや複雑な処理が必要な場合に向いています。
一方、ステートレスはシンプルさとスケーラビリティが求められる場合、例えば大規模なWebサービスとかにぴったり。

要は、状況に応じて臨機応変に使い分けることが大切。
システム設計する時は、この二つの特性をよく理解して、最適なアーキテクチャを選んでいきましょう！

まとめ

いかがでしたか？
ステートフルとステートレス、ちょっと難しいけど、この話を押さえておけば、システムの動きを理解するのに役立つはず。

ぜひこの知識を活用して、もっとITの世界を楽しんでいってくださいね！それでは、また次回！

両者の違いをわからないままノリで進めていくと大恥かくので先に学んでおく事をおすすめします。

UFW（Uncomplicated Firewall）とは

UFWは、Linuxベースのシステムでファイアウォールを設定するためのツールです。

UFWは、iptablesと呼ばれるより高度なファイアウォール設定を簡略化したもので、コマンドラインを通じて簡単に設定できます。

主な特徴は以下です

• ポートベースのファイアウォール設定をサポート
  • 特定のポートへのアクセスを制御
  • IPアドレス、サブネット、アプリケーションなどの設定が可能。
• シンプルな構文
  • ufwは非常に簡単な構文を持っており、コマンドラインで簡単に設定できる
  • ufwはシステム全体のファイアウォールとして機能する。
  • ネットワークトラフィックを制御するために使用される。
  • 特にWebアプリケーションのセキュリティには直接関係なし。

使用例

サーバーに対してセキュリティに関わる制限を設ける。

#HTTPS の port 開放 
sudo ufw allow 443

#MySQL の port 開放 
sudo ufw allow 3306

#sshの port 閉鎖 
sudo ufw deny 22

ufw にてポートの開閉を明示的に指示ができる。

WAF（Web Application Firewall）とは

WAFは、Webアプリケーションのセキュリティを強化するためのセキュリティツールです。

WAFは、Webトラフィックに対する特定のセキュリティルールを適用し、Webアプリケーション攻撃（例：SQLインジェクション、クロスサイトスクリプティングなど）から保護します。

主な特徴は以下です

• Webアプリケーションに対するトラフィックフィルタリング
  • WAFは、HTTPおよびHTTPSトラフィックを対象として、不正なリクエストや攻撃を検出し、遮断します。
  • パターンマッチング：WAFは特定の攻撃パターンや脆弱性に対する署名またはルールを使用して攻撃を検出します。
  • ロギングと監視：WAFは攻撃試行をログに記録し、セキュリティエンジニアがそれを監視および対応できるようにします。

WAFはWebサーバーとWebアプリケーションの間に配置され、攻撃をブロックしてWebアプリケーションを保護します。

WAFは販売されている

今回の勉強をするまでは、WAFの防御する内容が SQLインジェクションや XSS などであったため、自分で記述するプログラムにて防御するものだと思っていました。（自分で書くべきプログラムの総称と思っていた…

内容を深掘っていくとWAFはかなりの数が外反されており、運用を楽にするためにたくさんの企業が導入しているということがわかりました。

独自のルールを付加させる事のできるAWS WAF はその内勉強しないといけないなぁという印象です…

用途の異なるセキュリティツール

UFW（Uncomplicated Firewall）とWAF（Web Application Firewall）は、異なるセキュリティ関連のツールであり、異なる用途と機能を持っています。

簡単にまとめると以下のとおりですー。

• UFWはシステムのファイアウォール設定を簡単に行うためのツール
• WAFはWebアプリケーションのセキュリティを向上させるための特化したセキュリティツール

「Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]」という雑誌に出会ったので、SOLID原則を学習中です。これを機に3流プログラマーに慣れたらいいなぁと。

前回の学習内容はこちら

[getpost id=”1332″ cat_name=”1″ date=”0″]

まずはInterfaceから

PHPにおけるInterface（インターフェース）は、クラスが実装するべきメソッドのシグネチャ（メソッド名、引数、戻り値の型）を定義するための機能です。

Interfaceは抽象的なクラスであり、実際の実装を持ちません。
(じゃあいらんやん…って思っちゃいますよね)

なぜ必要なのかというと、
クラスはInterfaceを実装することで、そのInterfaceで定義されたメソッドを必ず実装しなければならないからです。

例えば、ユーザーにメッセージを送信する場面を考えて下さい。

どの様なメッセンジャーを使うにしても必ず「メッセージを生成する機能」と「メッセージを送信する機能」の2つが必要になるはずです。

ここではメールで送信する場合(メールクラス)とLineで送信する場合(Lineクラス)を想定してみます。

interfaceを以下のように定義することで、実装したクラスはinterfaceの内容を必ず実装しなければいけません。

interface Message {
    public function createMesseage();
    public function sendMessage();
}

上記の様に定義することで、メールクラスとLineクラスは必ず同じメソッドがある事が担保されます。(クラスは同じ振る舞いを持つことが保証されます)

仮にSlackでメッセージを送信したい場合、Slackクラスに同じメソッドを実装するだけで済むため拡張性が高くなりますよね。あら、わかりやすい。笑
(既存のクラス(メールクラス、Lineクラス)に影響なく実装できる)

class Mail implements Message {
    public function createMessage() {
        //処理    
    }

    public function sendMessage() {
        //処理   
    }
}

class Line implements Message {
    public function createMessage() {
        //処理    
    }

    public function sendMessage() {
        //処理   
    }
}

interface Message {
    public function createMessage() {}
    public function sendMessage() {}
}

いよいよ依存性反転の原則

一旦、呼び出し元の観点を持ってみましょう。

interfaceを実装することで、呼び出し元のコードはinterfaceに対して依存し、具体的な実装クラスに対して依存しないためコードの結合が低くなります(疎結合。。。)

先程のコードで考えると呼び出し元はメールクラスを呼び出しているつもりでもinterfaceを経由しているのが実態です。

Interfaceを使用することで、クラス間の依存関係を抽象化し、実装にではなくインターフェースに依存するようにすることができます。

• 呼び出し元の見ているところがinterfaceになる
• interfaceは定義する場所
• interfaceを継承したクラスは必ず同じメソッドある
• 結果、呼び出し元と実装クラスはinterfaceに依存している

これにより、依存性反転原則が達成されます。

ちゃんちゃん。

これから設計に関する知識も増やしていきたいな〜と思っていた矢先、「Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]」という書籍に出会いました。中々嬉しいタイミングですね！笑

いわゆるクリーンアーキテクチャに関する内容が紹介されている雑誌になります。

今回はシリーズ形式で各記事に分けて書いていこうと思います〜！

SOLID原則を簡単に

1. 単一責任の原則 (Single Responsibility Principle, SRP)
2. オープン/クローズドの原則 (Open/Closed Principle, OCP)
3. リスコフの置換原則 (Liskov Substitution Principle, LSP)
4. インターフェース分離の原則 (Interface Segregation Principle, ISP)
5. 依存性逆転の原則 (Dependency Inversion Principle, DIP)

単一責任の原則

SRP : Single Responsibility Principle

一言で表すとクラスは単一の責務を持つべきということらしいです。

もっと噛み砕くと1つのクラスが1つの目的や責務にのみ集中するべきことを指します.

//良くない設計
<?php
class DB {
	private $host;
	private $dbName;
	private $userName;
	private $password;
	
	public function __construct($name, $email) {
		$this->host = env('host');
		$this->dbName = env('dbName');
		$this->userName = env('userName');
		$this->password = env('password');
		
		try {
			$database_handler = new PDO('mysql:host=' . $this->host . ':3306;dbname=' . $this->dbName . ';charset=utf8mb4', $this->userName, $this->password);
		} 
    	catch (PDOException $e) {   
        	echo $e->getMessage() . "\n";
        	exit;
    	}  
	}
	
	public static function selectUser() {
		$PDO = $db = new self();
		
		//取得処理	
	}
	
	public static function editAdmin() {
		$PDO = $db = new self();
		
		//編集処理	
	}
}
?>

上記のコードではDBクラスを定義しているのですが、ユーザーの取得処理と管理者の編集処理を記述しています。

理想とするクラス設計では、ユーザーのクラス/管理者のクラスという形で分けるべきですよね。↓

DB接続クラス

class DB {
	private $host;
	private $dbName;
	private $userName;
	private $password;
	
	public function __construct($name, $email) {
		$this->host = env('host');
		$this->dbName = env('dbName');
		$this->userName = env('userName');
		$this->password = env('password');
		
		try {
			$database_handler = new PDO('mysql:host=' . $this->host . ':3306;dbname=' . $this->dbName . ';charset=utf8mb4', $this->userName, $this->password);
		} 
    	catch (PDOException $e) {   
        	echo $e->getMessage() . "\n";
        	exit;
    	}  
	}
}

ユーザクラス（管理者も同様に）

class User {
	public static function selectUser() {
		$PDO = $db = new self();
		
		//取得処理	
	}

	//他のユーザーに関する処理を記述していく
}

良くないコード例として出したソースは以前の現場で書いていた手法なんですよね。笑
DBクラスの内容が1000以上になっていたので、拡張性や保守性がかなり良くない事が単一責任の原則を学んで理解できたので良しとしましょう。

ちなみに前の現場で書いていた内容はいつか爆発することは目に見えているのですが、爆破する前に逃げ出すことが出来ました。笑

[getpost id=”1204″ cat_name=”1″ date=”0″]