ソフトウェア設計 on M1KE BL0G

とある分散システムの設計で使ってた概念の棚卸し

Thu, 30 Apr 2026 23:12:00 +0900

背景

とある分散システム上で売買を行うシステムの、設計をする仕事をしていた
P2Pシステム上で、ノード間で平等な売買が行われるもので、初期設計が大事だった
その時にSLAやTX性能など色々検証していたので、そのメモの一部を残す

ネット取引の本質

インターネット上の売買システムについて考える機会があった。結論以下になった。

ネット上の売買ではtxをアトミックにしなければならない
つまり、仲介者が本質的に必要だという事
- 理由は相対取引が不可能だから（例えば、直接物々交換するなど）
- なので、物とお金の交換で、どちらかが先にお金や物をgiveすることになる
- その結果、あとでgiveする方が有利になり、逃げる事＝カウンターパーティリスクが発生するから
- 以下みたいな感じ
  1 2
  
  Alice → Bob に送金 Bob → Alice に送金する保証なし
仲介者抜きではネットの売買は成り立たないという事
- 三方良しにしないとこのメカニズムは成り立たない。
- 二人だけだと利益相反であり、３人だともう一人に利益を渡してインセンティブが無いと、持ち逃げされるから
- ブロックチェーンだって、OpenSeaみたいな仲介者がいないと本質的に成り立たない
- エスクロー取引が必要という事

要件定義

ノックアウトファクター

他の条件がどれほど優れていても、その要素を満たさない（または満たしてしまう）場合に即座に不採用・却下となる致命的な要因・要件のこと
これじゃぁ無理と言われる要項

非機能要件

セキュリティ要件
法的要件
ネットワークのアクセス要件

システム検証

検証の5要素

運用
パフォーマンス
開発コスト
ランニングコスト
セキュリティ

検証結果の共有の三要素

検証・実験・試験は次の三つがミニマムで必要。

前提
結果
結論

用語

信頼性・可用性の観点

RASIS, RAS

コンピュータシステムの信頼性を評価する5つの指標。

Reliability（信頼性）
Availability（可用性）
Serviceability（保守性）
Integrity（完全性）
Security（機密性）

セキュリティの三要素 (CIA)

C: 「機密性」（Confidentiality）
I: 「完全性」（Integrity）
A: 「可用性」（Availability）

SLI, SLO, SLA

Service Level Indicator
Service Level Objective
Service Level Agreement

別の言い方をすると

SLI → 何を測るか
SLO → どの水準を目標にするか
SLA → どの水準を契約・合意として扱うか

SLO (Service Level Objective)

レイテンシ
- 予測値
  - 100ms (TTFB; 99.9パーセンタイル)
- 通信してから帰ってくるまで
- curlでいう、time_starttransferのTTFB (Time To First Byte)
- 単一リクエストに対する応答遅延
- API呼び出し、DBアクセス、ネットワーク往復などの単位で見る
スループット
- 予測値
  - xxx req/s (書き込みで)
- 秒間に書き込めるTXの数
- apache benchmarkなどで実施する
コスト
- 予測値
  - TBD 円/s
- インスタンス費用とスループットから算出
ターンアラウンドタイム
- 予測値
  - xxx ms
- リクエストを送ってから帰ってくるまで
- 実際にAPIを実行して何秒で返ってくるか
- 業務処理やジョブ全体が完了するまでの時間
- 例: 注文作成から確定まで、審査開始から完了まで
同時接続数
- 予測値
- 同時に接続できる数

RAMS規格

システムの安全性と信頼性のための規格

信頼性 (reliability)
アベイラビリティ (availability)
保守性 (maintainability)
安全性 (safety)

整合性・可用性の観点

TxのACID特性

特にアトミック性と一貫性が大切。結果整合性もある。

Atomicity（原子性）
Consistency（一貫性）
Isolation（独立性）
Durability（永続性）

分散システムのCAPの定理

単一障害点（spof）をなくすことはここの可用性と関連。

一貫性 (Consistency)
可用性 (Availability)
分断耐性 (Partition-tolerance)

BASE基準

高可用性を実現するための「システムの特性」のこと。

BA (Basically Available | 基本的に利用可能)
S (Soft state | 厳密ではない状態遷移)
E (Eventual consistency | 結果整合性)

キャパシティ

キャパシティプランニングの3つの観点

latency
throughput
turnaround time

キャパシティ

バックプレッシャー
サーキットブレーカーパターン

分散システム

分散システムのTXパターン

2 Phase Commit
- 全ノードがコミットするか、それとも全ノードがコミットしないかのどちらかの状態になることを保障するプロトコル
3 Phase Commit
- コミットリクエスト、コミット準備、コミットの3段階でメッセージをやり取りするモデル
Sagaパターン
- 複数の状態変更を調整できリソースを長時間ロックすることがないよう設計されたアーキテクチャパターン
- Choreography (コレオグラフィ)と、Orchestrationパターンがある
- 補償トランザクションの設計も必要
Try-Confirm/Cancelパターン

ノードのコンセンサスアルゴ

Paxos
Raft
BFT（Byzantine Fault Tolerance）

二重実行・冪等性

二重決済の問題
二重注文の問題
リトライ時に二重実行
idempotency key

運用

障害モデル

Fail-Stop障害モデル
Fail-Recover障害モデル
Byzantine障害

運用設計

定期実施作業
インシデント対応
セキュリティ対応
キャパシティプランニング

業務フロー・システムフロー

アカウントの発行
アカウントの審査

設計

全体設計

誰が何をやるで全体的な設計をする。

アクター・システム
- エンドユーザー
- オペレーター
- アドミン
ユースケース分類
- エンドユーザー機能
- オペレーター機能
- アドミン機能

2つの詳細設計の方法

個別設計
横断設計

Usecase

Usecaseの必須項目

ユースケースID
ユースケース名
アクター
目的
パラメーター
備考

3つのフローとパラメーター

メインフロー = 期待通りに進む流れ
代替フロー = 期待通りではないが、正常な別パターン
例外フロー = エラー・失敗時の流れ

フローを進むための条件

開始条件 = きっかけ
事前条件 = 始める前の前提
事後条件 = 終わった後の結果

確認項目

シナリオテスト
リーガルチェック

結論

正直、分散システムの設計は難しい
特に障害点が無い代わりにスループットが上げにくい
コンソーシアム型にしてもノード間のコンセンサスを取るのは大変

Deadlockにはまった時に調べた事

Wed, 12 Feb 2025 17:24:53 +0900

背景

負荷試験時にdeadlockがデータベースで発生して困ったのでメモ
背景としては、画像解析処理の為にサーバーで解析結果を保存するときに発生した
そのdeadlockの時に調べたり改めて確認した時のメモ

前提

ソフトウェアアーキ

言語: Python
サーバー
- APサーバー: FastAPI
- ASGIサーバー: Uvicorn
- Webサーバー: Nginx
ORM:
- SQLAlchemy v2
RDB:
- PostgreSQL
- Read Committed

サーバー構成

主に次の三つのサーバー（レイヤー）構造で処理をしている。

FEサーバー
- APIリクエスト受付用のFEサーバー
BEサーバー
- 解析リクエストをする、ブローカー用のBEサーバー
解析サーバー
- 解析処理を行うマイクロサービスのサーバー

処理フロー

FEサーバーでAPIリクエストを受け取りSQSに貯める
BEサーバーでSQSをポーリングする
BEサーバーで解析の実行計画を決定する
BEサーバーが解析用のマイクロサーバー群に解析を依頼する
その結果を集めて、BEサーバーがデータベースに保存する

RDB全般

デッドロックとは

複数のプロセスやトランザクションが、互いに相手が持っているリソース（ロックなど）を待ち続けることで、永久に進行できなくなる状態のこと。

ロックモードの種類

PostgreSQL には 8種類のロックモードがある。

ロックモード	取得される操作	影響
ROW SHARE	`SELECT FOR UPDATE`、`SELECT FOR SHARE`	`DELETE` をブロック
ROW EXCLUSIVE	`UPDATE`, `DELETE`, `INSERT`	`ROW SHARE` より強いロック
SHARE	`LOCK TABLE IN SHARE MODE`	`UPDATE` / `DELETE` は可能だが `SHARE ROW EXCLUSIVE` はブロック
SHARE ROW EXCLUSIVE	特定の DDL	`SHARE` より強いが `EXCLUSIVE` より弱い
EXCLUSIVE	`LOCK TABLE IN EXCLUSIVE MODE`	すべての行の更新をブロック
ACCESS EXCLUSIVE	`LOCK TABLE IN ACCESS EXCLUSIVE MODE`	テーブル全体をロック（`SELECT` すらできない）

クエリが作成するロックモード

各クエリにが作るロックは以下がある。

SQL	ロックの種類	影響
`UPDATE`	行ロック (`ROW EXCLUSIVE`)	対象の行が他のトランザクションで `UPDATE` / `DELETE` されるのを防ぐ
`SELECT FOR UPDATE`	行ロック (`ROW SHARE`)	対象の行を `UPDATE` / `DELETE` から保護する
`DELETE`	行ロック (`ROW EXCLUSIVE`)	削除対象の行をロックし、他の `UPDATE` / `DELETE` をブロックする
`INSERT`	行ロック (`ROW EXCLUSIVE`)	基本的には競合しないが、`UNIQUE` 制約があると競合する可能性あり
`LOCK TABLE IN EXCLUSIVE MODE`	テーブルロック	他のトランザクションが `INSERT`, `UPDATE`, `DELETE` できなくなる
`SELECT`（普通の読み取り）	ロックなし	どのトランザクションも自由に読み取り可能

SELECT FOR UPDATEについて

注意なのは、SELECT FOR UPDATEはSELECTに見えるが、実体はUPDATEに近い
例えば、あるTXのSELECT FOR UPDATEは他のTXのSELECT FOR UPDATEをブロックする
つまり、SELECT FOR UPDATEは、実際は「UPDATEをしないUPDATE」
SELECT FOR UPDATE のロック開放はそのTXのCOMMIT時に解放される
ちなみに、SELECT FOR UPDATEの最中にSELECTはすることができる
ただし、READ COMMITEDではノンリピータブルリードやファントムリードが発生する可能性があるので注意

リード一貫性の問題（Read Consistency Issues）

リード一貫性の問題とは

Readの問題は次の3つがある。

問題	発生条件	影響
ダーティリード（Dirty Read）	未コミットのデータを他のトランザクションが読める	読んだデータが後で `ROLLBACK` されると、データの整合性が崩れる
ノンリピータブルリード（Non-Repeatable Read）	同じトランザクション内で、同じ `SELECT` でも結果が変わる（他のトランザクションの `UPDATE` / `DELETE` の影響）	2回の `SELECT` で異なる値が見える
ファントムリード（Phantom Read）	同じ `SELECT` でも、新しい行 (`INSERT`) が増えたり、削除されたりする	`WHERE` 条件に一致する行数が変化する

ダーティーリードは

他Commit前のTXのCRUDの変更を読み込める事による問題
特に、Rollbackされると、データ不整合が発生する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- トランザクションA
BEGIN;
UPDATE users SET name = 'Bob' WHERE id = 1;
-- まだ COMMIT していない！

-- トランザクションB
SELECT * FROM users WHERE id = 1;
-- READ UNCOMMITTED なら 'Bob' が見えてしまう（ダーティーリード発生）

-- トランザクションA
ROLLBACK;

トランザクションBは、存在しないはずのデータ ‘Bob’ を見てしまったことになった。

ノンリピータブルリード

他コミット済みのTXのUD（UpdateやDelete）による問題
UDによって、既存の行のデータが変わる（値が変わる or 消える）問題

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- トランザクションA
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM users WHERE id = 1; -- 'Alice'

-- トランザクションB
BEGIN;
UPDATE users SET name = 'Bob' WHERE id = 1;
COMMIT;

-- トランザクションA
SELECT * FROM users WHERE id = 1; -- 'Bob'（前回と結果が違う！）

同じトランザクション内で SELECT した結果が変わる（ノンリピータブルリード発生）。

ファントムリード

他コミット済みのTXのCUD（InsertやUpdateやDelete）による問題
CUDによって、結果セットの行数が変わる（新しい行が増える or 減る）問題

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- トランザクションA
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM users WHERE age >= 18;
-- 3件取得: Alice, Bob, Charlie

-- トランザクションB
BEGIN;
INSERT INTO users (id, name, age) VALUES (4, 'Dave', 22);
COMMIT;

-- トランザクションA
SELECT * FROM users WHERE age >= 18;
-- 4件取得: Alice, Bob, Charlie, Dave（行が増えた！）

検索結果の行数が変わってしまう（ファントムリード発生）
REPEATABLE READ では防げず、SERIALIZABLE にする必要がある

トランザクション分離レベルとReadの問題

トランザクション分離レベルのReadの関係

分離レベル	ダーティリード	ノンリピータブルリード	ファントムリード
`READ UNCOMMITTED`	❌ 発生する	❌ 発生する	❌ 発生する
`READ COMMITTED`	✅ 発生しない	❌ 発生する	❌ 発生する
`REPEATABLE READ`	✅ 発生しない	✅ 発生しない	❌ 発生する
`SERIALIZABLE`	✅ 発生しない	✅ 発生しない	✅ 発生しない

トランザクション内の一貫性を保ちたい（変更途中のデータを見たくない）
- => REPEATABLE READ / SERIALIZABLE
- スナップショットを維持し、一貫性を確保
リアルタイムの最新データがほしい
- => READ COMMITTED
- SELECT のたびに最新の COMMIT 済みデータを取得
未コミットのデータも見たい（※PostgreSQL では不可）
- => READ UNCOMMITTED

ACID特性

ACID特性 は、データベースのトランザクションが信頼性を持って処理されるために必要な4つの特性。

特性	説明	例
Atomicity（原子性）	トランザクションは「すべて成功」または「すべて失敗」	送金処理の途中で失敗したら、残高は元のまま
Consistency（一貫性）	トランザクションの前後でデータのルールが守られる	存在しない `product_id` を `orders` に挿入できない
Isolation（分離性）	同時実行のトランザクションが影響し合わない	在庫チェック中に他のトランザクションの変更が見えない
Durability（永続性）	`COMMIT` したデータは消えない	`COMMIT` 直後にDBがクラッシュしても、データは保証される

逆に、ACIDを守らないと何が起こるか？

原子性がない
- 送金処理が途中で止まったら、お金だけ引かれて相手に届かない
一貫性がない
- 存在しない商品IDの注文が通る
分離性がない
- 他のトランザクションの影響で、データが意図しない値に変更される
永続性がない
- COMMIT したのに、障害でデータが消える

デッドロックの例

データ用意

1
2
3
4
5
6


CREATE TABLE users (
 id SERIAL PRIMARY KEY,
 name TEXT NOT NULL
);

INSERT INTO users (name) VALUES ('Alice'), ('Bob');

次の時系列だと、2つのTX間でデッドロックが発生する。T1とT2のどちらもCommitはしていないから。

TX	SQL コマンド	意味
T1	`BEGIN TRANSACTION;`	トランザクション開始
T1	`UPDATE users SET name = 'Alice Updated' WHERE id = 1;`	id=1 の行をロック
T2	`BEGIN TRANSACTION;`	トランザクション開始
T2	`UPDATE users SET name = 'Bob Updated' WHERE id = 2;`	id=2 の行をロック
T1	`UPDATE users SET name = 'Alice Final' WHERE id = 2;`	id=2 のロックを待機（T2 がロック中）
T2	`UPDATE users SET name = 'Bob Final' WHERE id = 1;`	id=1 のロックを待機（T1 がロック中）
PG	`DEADLOCK DETECTED`	デッドロック発生！どちらかのトランザクションが終了

Read Committedの場合、各 UPDATE 文ごとに行のロックを取得する仕様となっている。

共有ロックと排他ロック

共有ロック（Shared Lock、Sロック）
- 他のトランザクションが「読み取り」可能なロック
- 書き込み（更新・削除）を行うことはできない
排他ロック（Exclusive Lock、Xロック）
- 他のトランザクションが「読み書き」できなくなるロック
- 1つのトランザクションだけがデータを操作できる（単独アクセス）

ロック専用テーブルを利用する例

READ COMMITTEDで排他制御をしたい場合はロック専用テーブルを用意する方法もある
なお、テーブルは次を用意する

1
2
3
4
5


CREATE TABLE BATCH_LOCK (
 BATCH_ID VARCHAR(50) PRIMARY KEY, -- バッチ処理の識別子
 LOCK_STATUS CHAR(1) NOT NULL, -- ロック状態（'1'=ロック中、'0'=未ロック）
 LOCK_TIME TIMESTAMP, -- ロックを取得した時間
);

Updateを使った排他制御

READ COMMITTEDなので、UPDATEの前にSELECTでLOCK STATUSをチェックすると、Non-repeatable readsの可能性が生まれる
故に、UPDATE文は排他ロックを取得するため、その条件でLOCK_STATUSを指定する事で排他制御が可能となる
さらに、UPDATEの後にSELECTをすると、このTXによって更新されたのか、または既に別プロセスによってロックされていたのかを区別ができない
- 更新が実際に行われたかどうかを知る唯一の方法が、GET DIAGNOSTICSやRETURNINGになる
何らかの理由でLOCK_STATUSが1になりっぱなしになる対策として、LOCK_TIMEを見て、一定時間ロックされたらフラグを無視する
もし、処理に時間がかかる場合は、TTLであるLOCK_TIMEを更新して、他プロセスに処理をブロックされないようにする必要がある

ロック開始:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


BEGIN;

UPDATE BATCH_LOCK
SET LOCK_STATUS = '1',
 LOCK_TIME = CURRENT_TIMESTAMP
WHERE BATCH_ID = 'DAILY_BATCH'
 AND LOCK_STATUS = '0';

-- 更新件数を確認
GET DIAGNOSTICS affected_rows = ROW_COUNT;
-- affected_rows が 0 ならロック取得失敗

COMMIT;

解除:

1
2
3
4
5
6
7
8


BEGIN;

UPDATE BATCH_LOCK
SET LOCK_STATUS = '0',
 LOCK_TIME = CURRENT_TIMESTAMP
WHERE BATCH_ID = 'DAILY_BATCH';

COMMIT;

ただし、lockされている時にのみ解除する必要があるので注意。

SELECT FOR UPDATEを使った排他制御

SELECT FOR UPDATEを使うことも有効
GET DIAGNOSTICSを使わなくても、LOCK_STATUS = '0'を指定しているので、SELECTの結果で分かる
デッドロックを避けたい場合やシーケンシャルな処理を担保したい場合、nowaitやskip lockedが良い

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


BEGIN;

-- 排他ロックを取得
SELECT LOCK_STATUS, LOCK_TIME
FROM BATCH_LOCK
WHERE BATCH_ID = 'DAILY_BATCH' AND LOCK_STATUS = '0'
FOR UPDATE;

-- 結果の行数をチェック（アプリケーションコード側で）
-- 結果が0行なら、すでにロックされている
-- 結果が1行なら、ロック取得成功

-- ロックされていなければ更新
UPDATE BATCH_LOCK
SET LOCK_STATUS = '1',
 LOCK_TIME = CURRENT_TIMESTAMP
WHERE BATCH_ID = 'DAILY_BATCH'
 AND LOCK_STATUS = '0';

COMMIT;

レコードがないと排他ロックは取れない

そもそも大きな勘違いをしていた
つまり、select for updateで取得したデータが空の時は排他ロックはかからない
- これが結論だった
Aというレコードがないなら挿入する、ただし、2つ同じレコードを挿入したくはないというのが要件
select for updateでAというレコードを探しても、同時に二つのプロセスからselect for updateがかかったら両方空になる
故に、両方のプロセスで空だからinsertしようとして重複するデータが挿入されて破綻する
つまり、レコードがない状態がある場合は、排他ロックが取れないので、重複排除処理をSelect for updateでやるのは難しい
それならロック専用テーブルを用意するしかない、もしくは、その重複したくないものでUniqueキーをつけるしかない
アプリケーションレベルでのユニーク制約はロック専用テーブルを用意するしかない

部分インデックス

mysqlでは後からユニーク制約をつけたい場合は、仮想カラムを追加して処理する方法もある
しかし、Postgresの場合は、条件付きのインデックス（部分インデックス）が作れるのでそれが一番
データマイグレーションもする必要もなく、条件付きでデータ整合性を保つことができる
例えば、次のような感じ
- created_at >= 2022-12-12 => xxxとyyyでは複合ユニークインデックス

AP周り

APレベルでのTX制御は難しい

フロー:

Aを含むコードをselect for update
Aがなかったら、Aをインサート
Commit

つまり、Aというレコードを1つだけインサートしたい
select for updateで対象のAのレコードがない時は排他ロックがかからずAをインサートする
もし、そのコードを2つのプロセスから同時に実行したら、Aというレコードは2つインサートされる可能性がある
なぜなら、排他ロックが両方で取れない為、両方Aをインサートする

これの解決策は、次の2つ:

unique制約をつける
ロック専用テーブルを用意して使う

PythonのAPログの強化

アクセスログ以外にも、デバッグログもJSON化した方が良かった。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


import logging
import json
import sys
from uvicorn.logging import DefaultFormatter

def is_output_a_terminal(stream):
 """
 Check if the provided stream is a terminal.
 """
 return stream.isatty()

class AppJSONFormatter(logging.Formatter):
 def format(self, record):
 full_path = record.pathname
 path_parts = full_path.split("/")

 try:
 my_namespace_index = path_parts.index("my_namespace")
 display_path = "/".join(path_parts[my_namespace_index:])
 except ValueError:
 if len(path_parts) > 3:
 display_path = "/".join(path_parts[-4:])
 else:
 display_path = full_path

 # デフォルトのログフィールド
 log_record = {
 "level": record.levelname,
 "timestamp": self.formatTime(record, "%Y-%m-%d %H:%M:%S"),
 "file": display_path,
 "line": record.lineno,
 "message": record.getMessage(),
 }

 # extra で渡されたカスタムフィールドを追加
 extra_fields = {k: v for k, v in record.__dict__.items() if k not in logging.LogRecord.__dict__}
 log_record.update(extra_fields)

 return json.dumps(log_record, ensure_ascii=False)

use_colors = is_output_a_terminal(sys.stdout)

handler = logging.StreamHandler(sys.stdout)
formatter = AppJSONFormatter()
handler.setFormatter(formatter)

logger = logging.getLogger("app")
logger.setLevel(logging.INFO)
logger.addHandler(handler)

使う時

1
2
3
4


import logging
logger = logging.getLogger("app")

logger.info("ユーザーがログインしました", extra={"UserID": 12345, "SessionID": "abcde12345"})

結果

1
2
3
4
5
6
7
8
9


{
 "level": "INFO",
 "timestamp": "2025-02-14 12:34:56",
 "file": "my_namespace/module/auth.py",
 "line": 42,
 "message": "ユーザーがログインしました",
 "UserID": 12345,
 "SessionID": "abcde12345
}

アプリケーションバグ

以下のようなアプリケーションのバグや問題の可能性を確認した。

txの貼り忘れ
rollbackやcommit忘れ
- commitしたら排他ロックがリリースされるので、変更後に適切にcommit/rollbackされていない事を疑った
- 次の形で排他処理をまとめる所を囲って確実に実行されるように変更した
  1 2 3 4 5 6 7 8
  
  try: pass except: await session.rollback() else: await session.commit() finally: await session.close()
commitが早すぎた
- 途中で早すぎたcommitをしている事を疑った
repositoryの読み間違い
- DDDで実装されているが、repository層でsessionを保持している
- それが、別sessionではないか疑った
不要なNestesd Transatction
- 一部がnested transactionだったので、それをシンプルに変えた
- SAVEPOINTを作ると、ROLLBACK TO SAVEPOINTで戻せるが、シンプルに不要だった
repositoryから取得したentityが古い疑惑
- repositoryから取得したentityが古い可能性がある
- そのため、既に同じentityがあっても、select for updateで取得したentityを利用した
状態チェックは初めに行うべき
- たとえSAVEPOINTを使っても、COMMITするとSAVEPOINTからではなくBEGINからのTX全体がCOMMITされるので注意
- 故に、最初に排他処理を入れるのが正解だった
SQLAlchemyのオプション
- auto_commitやauto_flushなど
排他ロックの回数の順序
- 2回排他ロックのSQLを実行しており、それらのSQLのTXによって実行順番が逆だとデッドロックになる
- もしくは、SQLは1回だったとしても、orderがバラバラだった場合はデッドロックになる
TXの長さ
- 書き込む直前にTXを張り書き込むのがベター
- TXが長いと競合する可能性が高まるため

SQLAlchemy

SQLAlchemyのflushとcommit

flush:
- SQLAlchemyのSessionが追跡している変更内容をデータベースに送信する操作
- 実際のSQLクエリが発行されるが、トランザクションはまだコミットされていない
- 主にセッション内での整合性チェックや、後続の処理で変更内容を参照したい場合に使用する
commit:
- トランザクションを確定させ、変更内容を永続化する操作
- 自動的にflushが実行された後、トランザクションがコミットされる
- 変更内容は他のセッションからも参照可能になる
- with session.begin():を抜けると自動的にcommitになる

SQLAlchemyのAuto Begin

SQLAlchemyhにはAuto Beginという機能がある。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


session = Session()

# SELECT文の実行（この時点ではトランザクションは開始されない）
user = session.query(User).first()

# Insertなので、自動的に最初のトランザクションが開始
user1 = User(name="田中一郎")
session.add(user1)
session.commit() # トランザクション1が終了し、自動的に新しいトランザクションが開始

# Auto Beginで自動的に開始された次のトランザクション
user2 = User(name="鈴木二郎")
session.add(user2)
session.commit() # トランザクション2が終了し、また新しいトランザクションが開始

# withによる明示的なトランザクション
with session.begin():
 user = User(name="山田太郎")
 session.add(user)
 # withブロックを抜けると自動的にcommitされる

# または
session.begin()
try:
 user = User(name="山田太郎")
 session.add(user)
 session.commit()
except:
 session.rollback()
 raise

FastAPIのcontext managerの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


def get_db():
 db = SessionLocal()
 try:
 yield db # NOTE: この時点ではトランザクションは開始されていない
 finally:
 db.close()

@app.post("/users/")
def create_user(user: UserCreate, db: Session = Depends(get_db)):
 db_user = User(name=user.name)
 db.add(db_user) # この時点で自動的にトランザクションが開始される
 db.commit() # トランザクションをコミット

@app.get("/users/{user_id}")
def read_user(user_id: int, db: Session = Depends(get_db)):
 # SELECT操作のみなのでトランザクションは開始されない
 user = db.query(User).filter(User.id == user_id).first()
 return user

ポイント

SELECT単体ではトランザクションは開始されない
INSERT/UPDATE/DELETEで自動的にトランザクションが開始される
commitの後は自動的に新しいトランザクションが開始される
明示的なトランザクション管理（withやbegin）も可能

SQLAlchemyのSelect for update

select for updateを使うSQLAlchemyの例は以下
user = result.scalars().first()のタイミングでDBに問い合わせがかかり排他ロックがかかる
result = await session.execute(stmt)ではないので注意
また、commitしない場合は、他のtxはブロックされるので注意
commitかrollbackのタイミングで他のTXが読み込めるようになる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine
from sqlalchemy.future import select
from sqlalchemy.orm import sessionmaker
from sqlalchemy import Column, Integer, String
from sqlalchemy.orm import declarative_base
from sqlalchemy.exc import SQLAlchemyError
from sqlalchemy import text

DATABASE_URL = "postgresql+asyncpg://user:password@localhost/dbname"

Base = declarative_base()

class User(Base):
 __tablename__ = "users"
 id = Column(Integer, primary_key=True, index=True)
 name = Column(String, index=True)

# Async Engine & Session Setup
engine = create_async_engine(DATABASE_URL, echo=True)
AsyncSessionLocal = sessionmaker(engine, expire_on_commit=False, class_=AsyncSession)

async def select_for_update_example(user_id: int):
 async with AsyncSessionLocal() as session:
 async with session.begin(): # トランザクション開始
 try:
 # `SELECT ... FOR UPDATE` で行をロック
 stmt = select(User).where(User.id == user_id).with_for_update()
 result = await session.execute(stmt)
 user = result.scalars().first()

 if user:
 print(f"Locked User: {user.name}")
 # ここで更新処理などを行う
 user.name = "Updated Name"
 await session.commit()
 else:
 print("User not found")

 except SQLAlchemyError as e:
 await session.rollback()
 print(f"Error: {e}")

実行する場合

1
2


import asyncio
asyncio.run(select_for_update_example(1))

PostgreSQL

Postgresのデバッグ方法

deadlock_timeoutの時間を上げる
pg_stat_activityやpg_locksでデータを確認する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


SELECT client_addr, client_port, query
FROM pg_stat_activity
WHERE state = 'active'
 AND wait_event_type = 'Lock'
ORDER BY state_change;

 client_addr │ client_port │ query
═══════════════╪═════════════╪════════════════════════════════════════════════════
 192.168.2.120 │ 49578 │ SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;
 192.168.2.122 │ 47432 │ SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;
(2 rows)

その後、CLIをPSをチェックする。

1
2


$ lsof -P | grep 49578
myapp 3974 mypc [...] TCP localhost:49578->dbserver:5432 (ESTABLISHED)

もしくは、pg_locksを見ても良い。

1
2
3


SELECT pid, relation::regclass, mode, granted
FROM pg_locks
WHERE relation = 'users'::regclass;

Select for updateのオプション

no key
- 弱いロック
- FKやIDXのKeyの更新しないかつ最新のselectが不要な場合は有効
no wait
- ロックされてたらエラーで中断
- リトライ処理があるならこれでも良い
skip locked
- ロックされてる行をスキップ

PostgresのCompatibility Matrix

Postgresの行レベルのロックの強さの比較表:

Requested Lock Mode	FOR KEY SHARE	FOR SHARE	FOR NO KEY UPDATE	FOR UPDATE
FOR KEY SHARE				X
FOR SHARE			X	X
FOR NO KEY UPDATE		X	X	X
FOR UPDATE	X	X	X	X

see PostgreSQL: Documentation: 17: 13.3. Explicit Locking

NOTE:

「X」で競合する（後がブロックされる）事を意味する
対称行列になっている

PostgreSQLのログオプションの変更

設定確認

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


mydb=> SHOW deadlock_timeout;
 deadlock_timeout
------------------
 1s
(1 row)

mydb=> SHOW log_lock_waits;
 log_lock_waits
----------------
 off
(1 row)

すべてのステートメントをログに記録する。

1
2


log_statement = 'all'
log_line_prefix = '%m [pid=%p] %q[txid=%x] %u@%d '

CLIから更新する。もしくは、RDSの場合は、パラメーターグループから更新する。

1
2


ALTER SYSTEM SET log_lock_waits = ON;
SELECT pg_reload_conf();

結果は以下のようになる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


2022-06-20 17:17:50.888 CEST [pid=19718] [txid=0] mypc@test LOG: statement: BEGIN;
2022-06-20 17:17:52.988 CEST [pid=19718] [txid=0] mypc@test LOG: statement: INSERT INTO child VALUES (100, 1, 'new child');
2022-06-20 17:17:58.215 CEST [pid=19674] [txid=0] mypc@test LOG: statement: BEGIN;
2022-06-20 17:18:03.626 CEST [pid=19674] [txid=0] mypc@test LOG: statement: INSERT INTO child VALUES (101, 1, 'another child');
2022-06-20 17:18:18.979 CEST [pid=19674] [txid=1108] mypc@test LOG: statement: SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;
2022-06-20 17:18:31.550 CEST [pid=19718] [txid=1109] mypc@test LOG: statement: SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;
2022-06-20 17:18:32.551 CEST [pid=19718] [txid=1109] mypc@test ERROR: deadlock detected
2022-06-20 17:18:32.551 CEST [pid=19718] [txid=1109] mypc@test DETAIL: Process 19718 waits for ShareLock on transaction 1108; blocked by process 19674.
 Process 19674 waits for ShareLock on transaction 1109; blocked by process 19718.
 Process 19718: SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;
 Process 19674: SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;
2022-06-20 17:18:32.551 CEST [pid=19718] [txid=1109] mypc@test HINT: See server log for query details.
2022-06-20 17:18:32.551 CEST [pid=19718] [txid=1109] mypc@test CONTEXT: while locking tuple (0,1) in relation 'parent'
2022-06-20 17:18:32.551 CEST [pid=19718] [txid=1109] mypc@test STATEMENT: SELECT pdata FROM parent WHERE pid = 1 FOR UPDATE;

分析ツールの利用

設定ファイル（postgresql.conf）を編集：

1

shared_preload_libraries = 'pg_stat_statements'

サーバーを再起動：

1

$ sudo systemctl restart postgresql

拡張機能を作成：

1

CREATE EXTENSION pg_stat_statements;

デッドロックの発生したクエリの履歴をpg_stat_statementsから取得：

1
2
3
4
5


SELECT query, calls, total_exec_time, rows
FROM pg_stat_statements
WHERE query LIKE '%analysis%'
ORDER BY total_exec_time DESC
LIMIT 10;

結論

次が大切だった:

レコードはUpdateではなくInsertをメインに
- 並列分散処理のシステム設計としてはUpdateを前提とした処理フローは向いていなかった
- なぜなら、一貫性を持ったデータの更新には排他ロックをする必要があるため
- しかし、強い一貫性を持ったデータの構造にする必要はそもそもなかった
- さらに、順序処理を前提としてWaiting処理も入れていたため、それも複雑なシステムの一因だった
- 並列分散システムなので、フローはシンプルに
そもそも排他処理はコストがかかるのでするべきではなかった
- 排他処理は沼なので、排他をやめてAPのバグやリファクタを先にすすめるべき
- 後々もっと長い時間でデータの結果整合性を合わせられるようにするべきだった
- Postgresのログからdeadlockの原因を突き止めるのは難しい
設定の確認
- SQLAlchemyの設定を深く理解するべき
- PostgreSQLの設定をデバッグ可能にする
ローカルで再現するのを優先するべきき
リファクタ・ファースト
- コードが複雑だと追っかけられないので、先に軽いリファクタをするべきだった。
ログ・ファースト
- マイクロサービスのIn/Outのログも出すべき
- アクセスログだけではなく、一般のログもJSONで出すべき
- Don’t guess, just measure

参考文献

アジャイル開発とその手法

Wed, 03 Jul 2024 12:18:11 +0900

背景

チームのタスク管理はAgile開発とAtlassianのツールが便利
JiraとConfluenceは10年以上前からでファクタのアジャイル開発のツール
そこでで改めてAgile開発とJiraとConfluenceについてまとめてみた

NOTE:

同じ用語で英語と日本語がMixしているので注意
例: Agile <=> アジャイル

Agile

Agileとは

アジャイルはソフトウェア開発における方法論や価値観
柔軟性、迅速な応答、顧客との協力、変化に対する適応を重視している

Agileの4つの価値観

アジャイル宣言には以下の4つの価値観と12の原則が含まれている。

個人と対話 をプロセスやツールよりも重視
動くソフトウェア を包括的なドキュメントよりも重視
顧客との協力 を契約交渉よりも重視
変化への対応 を計画に従うことよりも重視

Agileの12の原則

顧客満足を最優先に、価値のあるソフトウェアを早く継続的に提供する
要求の変更を歓迎し、たとえ開発の後期であってもアジャイルプロセスを利用して顧客の競争力を高める
動くソフトウェアを頻繁にリリースし、数週間から数ヶ月のスパンで、新しいリリースが好まれる
開発者とビジネス側の人々は、プロジェクトを通して毎日一緒に働く
やる気に満ちた個人を中心にプロジェクトを構成し、必要な環境と支援を提供して仕事を成し遂げることを信頼する
チーム内の対話はできるだけ対面で行う
動くソフトウェアは進捗の主な指標である
アジャイルプロセスは持続可能な開発を促進し、開発者、スポンサー、ユーザーは一定のペースを維持できるようにする
優れた技術と設計への継続的な注目が俊敏性を高める
シンプルさ（不要な作業を最大限に減らすこと）が本質である
最良のアーキテクチャ、要件、設計は自己組織化チームから生まれる
チームは定期的にどのようにより効率的になるかを振り返り、それに応じて自らの行動を調整する

フレームワーク

アジャイルの概念に基づいて、以下のような具体的なフレームワークがある。

スクラム (Scrum)
カンバン (Kanban)
リーン (Lean)
エクストリーム・プログラミング (XP)
クリスタル (Crystal)

ウォーターフォールとアジャイル開発の違い

アジャイルとウォーターフォールの特徴と性質を比較すると次になる。

特徴:

特徴	Agile	Waterfall
プロセスの進行	反復的かつ増分的	段階的プロセス
柔軟性	高い	低い
変更対応	容易	困難
計画のアプローチ	適応的	事前計画重視
顧客との連携	頻繁なコミュニケーション	最初と最後のみ
ドキュメント	必要な分のみ	各段階で詳細なドキュメント
リスク管理	リスクを早期に発見・対応	後半でリスクが顕在化
チームの作業方法	クロスファンクショナルなチーム	機能ごとのチーム

性質:

適用状況	Agile	Waterfall
プロジェクトの性質	変化が多い、予測が難しい	要件が明確、変更が少ない
プロジェクトの規模	小〜中規模	中〜大規模
チームの特性	自律的でクロスファンクショナル	役割が明確に分かれている
市場のダイナミクス	競争が激しく迅速な対応が求められる	安定している

Scrum

スクラムとは

スクラムはアジャイルの原則に基づいたフレームワーク
ソフトウェア開発チームが反復的かつ増分的に製品を開発するためのガイドラインを提供する

役割

プロダクトオーナー
- プロダクトのビジョンとバックログを管理
- ステークホルダーとの調整、ユーザーストーリーの作成、スプリントゴールの定義など
スクラムマスター
- スクラムプロセスのガイドと障害の除去
- チームのコーチング、障害の除去、スクラムイベントのファシリテーション
開発チーム
- 実際に製品を開発するメンバー
- 計画されたタスクの実施、デイリースクラムへの参加、スプリントレビューでの成果発表

スクラムに定義はされていないが、次のような役割もある。

PdM: プロダクトマネージャー
PM / PjM: プロジェクトマネージャー
PO: プロダクトオーナー
TL: テックリード
EM: エンジニアリングマネージャー

イベント

スクラムには以下の定期的なイベントがある。

スプリント
- 通常2〜4週間の作業期間
デイリースクラム
- 毎日の短いミーティング
スプリントレビュー
- スプリント終了時のレビュー
スプリントレトロスペクティブ
- プロセス改善のための振り返り

アーティファクト

スクラムの重要な成果物には以下がある。

プロダクトバックログ
- 全ての要求と機能のリスト
スプリントバックログ
- スプリントで取り組むタスクのリスト
インクリメント
- 完成した製品の部分

Jira

Jiraとは

Jiraはいわゆるアジャイルプロジェクト管理ツール
特にアジャイルチームのためのプロジェクト管理ツールとして使いやすいように作られている

Jiraの基本

Site

Atlassianアカウントで最初に作るのはSite。

SiteとはAtlassianのSiteはクラウド製品をホスティングするためのドメインの事
Jira、Confluence、Bitbucketなどを使用する際に、そのサブドメイン上で製品にアクセスできるようになる
xxx.atlassian.netみたいな感じ
いわゆるテナントのIDの事

Project

Jiraでは、Siteを作成後に、Projectを作る
Projectはチーム全体でそれらのタスクや課題を整理して追跡するためのコンテナーの事

プロジェクトにはTemplateとTypeがある

Template: Kanban, Scrumなど
Type: Team, Companyなど

Sprintの有効化

スプリント機能を有効にするには、設定から有効化する必要がある
project settings > featuresからsprintをONにする
その際、backlogも有効化する必要がある

Issue

Issueとは

プロジェクト内で追跡される作業項目
タスク、バグ、ストーリーなど、さまざまな種類のイシューがある

Issueの種類

種類	説明	例
Issue	一般的な問題または作業項目	プロジェクトの進行に関する会議の設定、ユーザー調査の実施
Task	具体的な作業項目	ログインページのデザイン、データベースのバックアップ設定
Bug	ソフトウェアの欠陥やエラー	ログイン機能の不具合、ページ読み込み速度が遅い
Subtask	大きなタスクの一部	フォームフィールドの必須チェック、メールアドレスの形式チェック
Story	ユーザー視点から見た機能や価値	ユーザーとして、私はプロフィールを編集したい
Epic	大規模なユーザーストーリーや機能	新しい支払いシステムの導入
Improvement	既存の機能やプロセスの改善	検索機能のパフォーマンス向上
New Feature	新しい機能の追加	2要素認証の実装

EpicとSprint、Versionの違い

Epicは分母が作業であり、Sprintの分母は時間となり、Versionの分母はリリースとなる
Epicは大規模な作業項目や機能なのに対し、Sprintは短期間の開発サイクルとなる

イベント

スプリントプランニングの流れ

スプリントプランニングとは、スプリント開始時の計画ミーティングの事。

イントロダクション
- スクラムマスターがスプリントプランニングの目的と進行方法を説明し、全員が参加するよう促す
スプリントゴールの設定
- プロダクトオーナーがプロダクトバックログの優先度の高いアイテムを提示し、スプリントゴールを提案する
- チームが提案されたスプリントゴールを議論し、合意に達する
スプリントバックログの作成
- チームがスプリントゴールを達成するために必要なバックログアイテムを選択する
- 各バックログアイテムを詳細に分解し、必要なタスクを特定する
タスクの見積もりと割り当て
- 各タスクの作業量を見積もり、適切な担当者を割り当てる
- 見積もりには、ストーリーポイントや時間ベースの見積もりが使用される
チームのキャパシティの確認
- チームの利用可能なリソースを確認し、スプリントバックログが現実的であることを確認する
- 必要に応じてスプリントバックログの調整を行う
スプリントプランニングの締めくくり
- スクラムマスターがスプリントバックログとスプリントゴールの確認を行い、全員の理解を一致させる
- スプリントの開始を宣言し、次のスプリントに向けた作業を開始する

バックログリファインメント

プロダクトバックログにあるアイテムを定期的に見直す事
- アイテムは、ユーザーストーリー、バグ、タスクなどの事
リファインメントとも

具体的には、次を行うする。

詳細化
- DoD（Definition of Done）の決定
優先順位付け
見積もり
依存関係の確認
受け入れ基準の定義

Jiraでのスプリントの流れ

スプリント開始前にスプリントプランニングで作業タスクの明確化と見積りを行う
日々、作業タスクを完了させていく
- その作業中の際にサブタスクが生まれたら随時サブタスクを追加する
- BoardでGroup by subtaskで表示できるので進捗が管理しやすいため
毎朝デイリースクラム（朝会）でチーム一人ひとりの作業状況を共有する
スプリント最終日に成果物を説明するスプリントレビューを開催する
スプリントの最後にスプリントレトロスペクティブ（振り返り会）を開催する
スプリントとは別の時間軸でプロダクトバックログリファインメントを開催し、プロダクトバックログの棚卸・ブラッシュアップを行う

ロードマップの共有

プロダクトオーナーのビジョン共有やチームとの長期的な目標を共有する事
目標とそのストーリーとリリースプランニングを通して合意形成を行う
これはオレオレ定義のモノ

ロードマップの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Q1 2024:
- プロダクト目標: ユーザー登録プロセスの改善
 - エピック: 新ユーザー登録フローの導入
 - ストーリー1: 登録フォームのデザイン
 - ストーリー2: 登録データのバリデーション
 - ストーリー3: 登録完了ページの作成
 - リリース: Version 1.1
 - リリース日: 2024年3月31日

Q2 2024:
- プロダクト目標: 支払いシステムの導入
 - エピック: 支払いゲートウェイの統合
 - ストーリー1: 支払いフォームの作成
 - ストーリー2: 支払いAPIの統合
 - ストーリー3: 支払い確認ページの作成
 - リリース: Version 1.2
 - リリース日: 2024年6月30日

その他の機能

3つの主要機能

いわゆる、Timeline（ガントチャート）、Backlog（リスト）、ボード（カンバン）が主要な機能。

Timeline
- タイムラインはプロジェクトの計画や進行状況を視覚的に表示するツール
- ガントチャート形式でタスクやプロジェクトの期間を表示する
- 依存関係や進行状況を追跡が目的
Backlog
- バックログはプロジェクトに関連するすべての未処理の作業項目のリスト
- 次の2つのbacklogに分けられる
  - プロダクトバックログ（全体のバックログ）
  - スプリントバックログ（特定のスプリントに取り組むアイテム）
Board
- Issueを視覚的に管理するためのツール
- カンバンボードやスクラムボードなどの種類がある
- 進行状況を示す列（例：To Do、In Progress、Done）で構成される
- Swimlanesを使う事で更にまとめる事が可能

BoardはGropu byはAssignerごとにまとめたり、Subtaskを表示できるのでおすすめ。

レポート機能

客観的に進捗を把握するのにもこれらのツールが役立つ。

バーンアップチャート
- プロジェクトの進行状況とスコープの変化を視覚化するためのツール
- 完了した作業量（y軸）と時間（x軸）を表示する
スプリントのバーンダウンチャート
- スプリント内の残り作業量を視覚化するツール
- 完了する予定の作業量と実際の進行状況を比較し、スプリントの進行状況を追跡する
ベロシティレポート
- チームが過去のスプリントで完了した作業量（ストーリーポイントやタスク数）を表示するレポート
- 将来のスプリント計画を立てる際の参考にするのが目的
累積フロー図
- プロジェクトの進行状況を視覚化し、ワークフロー全体の安定性を評価するツール
- 各ステータス（例：To Do、In Progress、Done）ごとに作業量を表示し、ボトルネックや遅延を特定するのが目的

見積もり

見積もりの前提

完璧な見積もり

アジャイルの見積もりは、スプリント内での作業を予測するための目安
人月の神話ではないが、VOCAなソフトウェア開発において確実性の高い見積もりは不可能
その前提があるがゆえに、Agileはスコープを小さくし漸進的な活動の手法を使っている
人月という言葉の「人」と「月」が交換不可能という事

不確実性のコーン

そもそも、プロジェクトとは、「やったことがないことを、何が起こるのか分からないのに計画して、予定通りのモノ（コト）を期限までに作り上げる（終らせる）こと」
プロジェクトの本質は、このやってみないと分からないという「不確実性」にある
そして不確実性が高いほど、作業終了の見積もりにばらつきが生まれる

見積もり方法

ストーリーポイント

ストーリーポイントは、作業の相対的な複雑さ、規模、および労力を評価するためのアジャイル手法
プランニングポーカーで相対見積もりをする

見積もりの単位としては次のようなモノが使われる。

Tシャツサイズ（S、M、L、XL）
フィボナッチ数列（0, 1, 2, 3, 5, 8, 13, 21, …）

5-Why Technique

問題の根本原因を特定し、タスクの見積もりに役立つ情報を得るための手法
いわゆるTOYOTA WAYの手法

PERT

PERTはProgram Evaluation and Review Techniqueの略
3点見積もり（楽観値、最可能値、悲観値）を使用して見積もりの精度を高める手法

PERTは次の計算式で計算する。つまり、

$$ PERT = (O + 4M + P) / 6 $$

変数は次の意味:

楽観値（O）: 最短時間で完了する場合の見積もり
最可能値（M）: 最も可能性が高い場合の見積もり
悲観値（P）: 最長時間で完了する場合の見積もり

COCOMO

COCOMOはConstructive Cost Modelの略
プロジェクトの規模（KLOC）を基に、基本、中間、詳細モデルを使用してコストを見積る
KLOCはKilo Lines of Codeの略で、ソースコード1000行の事

Confluence

Confluenceとは

Atlassianが提供しているナレッジベースサービス

ドキュメントについて

従来のウォーターフォール型開発と比べてアジャイル開発におけるドキュメントは軽い
包括的なドキュメントはアジャイル開発では二次的なモノとみなされる
ただし、設計についてある程度残すのは引き継ぎも簡易化するので大切
また、データベース定義書はExcelの方が使いやすいので、適材適所で使分ける

ページのタイトル

ページタイトルは次のルールに従う。

Confluenceの全てのページに、参照用に番号とIDを振る
フォーマットは以下になる
- フォーマット：[PageNo ContentId] PageTitle
- PageNo
  - ページ構造の順番
  - フォーマット例: 1.1
- ContentId
  - ページ内のコンテンツのID
  - 例えば、Use Caseなど
    - Use Caseのフォーマット例: UC1.1.4
  - これはオプショナルなので、必要に応じてつける
- PageTitle
  - ページのタイトル
例
- [1] 目的
- [1.2] xxx APIの機能
- [2.4 UC3.5~UC3.6, UC3.12, UC4.22] XXXのユースケース

基本的な書き方

次のルールに従う。

です・ます調ではなく、である調にする
テクニカルライティングのように結論を簡潔に述べる
SD（Software Development）の設計ははUML2.1に準拠する
- 例
  - アクターの定義
  - ユースケースでユーザーの利用シーンをを定義
  - シーケンス
  - クラス図
プロトコルについてはRFCに寄せる
外注する所はRFPを書く

テンプレート

次は一般的な例における、アジャイル開発でのドキュメントの構造の例。

BD情報
- 事業計画
  - 目的・構想・背景・範囲
  - ロードマップ・スケジュール
  - バジェット
  - スコープ
  - ファイナンス
  - ユーザーストーリー
- 事業評価
  - 顧客満足度
  - VoC
  - 投資対効果
- 事業分析
  - 市場調査
  - マーケ
  - 競合調査
  - 提案
  - 課題
- 営業計画
  - 集客
  - 体制
  - STP（Segmentation, Targeting, Positioning）
  - PMF
SD情報
- 体制
  - メンバーとロール
  - 使用しているサービス
  - リンク集
  - オンボーディング
  - 開発者共有情報
- 要件
  - 非機能要件
    - 法的要件・セキュリティ・ネットワークアクセス
  - KOF・KBF
    - Knockout Factor
    - Key Buying Factor
  - テスト要件
- 仕様
  - 用語
    - AP, FE, BE, BFF etc.
  - アクター
  - ユースケース
  - 運用
  - 鍵管理
- 設計
  - アーキテクチャ
  - 業務フロー
  - API設計
  - モジュール設計
  - DB設計
  - データ設計
    - Masterデータ設計
    - Seedデータ設計
    - Mixture設計
  - インフラ設計
  - FE設計
  - AP設計
    - UI設計
- 詳細設計

違い

機能要件・非機能要件の違い

分かりやすくは次の定義になる。

機能要件
- システムが具体的に「何をするべきか」に関する要件
- 例: ユーザー登録機能、商品検索機能、注文処理機能
非機能要件
- システムの「どのように」動作するかに関する要件
- 例: 応答時間、同時接続数、可用性、セキュリティ基準、拡張性など

要件・仕様・設計の違い

要件・仕様・設計の大まかな違いは次になる。

項目	要件（Requirement）	仕様（Specification）	設計（Design）
目的	ユーザーやステークホルダーのニーズを明確にする	システムや製品が「何を」するべきかを定義する	仕様をどのように実現するかを具体化する
内容	ビジネスゴール、ユーザーストーリー	機能要件、非機能要件、制約条件	アーキテクチャ設計、詳細設計、データ設計、インターフェース設計

参考文献

DB設計とSQL周りの備忘録

Tue, 04 Jun 2024 01:47:40 +0900

背景

DB設計や実装、SQL周りの備忘録
SQLはMySQLやPostgresをベースにする

次のデータベースをこれでまで扱ってきたが、それらの詳細などは省く。

NoSQL:
- MongoDB、Redis、Memcached、DynamoDB、ElasticSearch（OpenSearch）、datastore、InfluxDB
RDS:
- SQLite、PostgreSQL、MySQL、PlanetScale
NewSQL:
- CockroachDB
BlockChain:
- Bitcoin、 Ethereum

DB設計

3つの設計

概念設計（Conceptual Design）
- 管理すべき情報を整理する
- 例: 顧客情報、注文情報などのエンティティを特定する
論理設計（Logical Design）
- RDBを使う前提でテーブルスキーマのの設計
- 例: 顧客テーブル、注文テーブルの関係を定義する
物理設計（Physical Design）
- 型やインデックス、制約、デフォルト値などの設計
- 例: 顧客IDのインデックスを設定し、検索パフォーマンスを向上させる

概念設計

次の三つを整理する。

エンティティ
属性（アトリビュート）
関係（リレーション）

エンティティを出す方法

要件から名詞を書き出す
その名詞の事物や事実、行為などの用語を書き出す
関連がありそうなモノをまとめる

また、この段階でER図を書くことがおすすめ。

リレーション

リレーションは3つのパターンがある。

1:多
- 芸能人と一般人のパターン
- 多が1を知る必要がある
  - つまり、多が1のidを保持する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- 芸能人テーブル
CREATE TABLE celebrities (
 id SERIAL PRIMARY KEY,
 name VARCHAR(255)
);

-- ファンテーブル
CREATE TABLE fans (
 id SERIAL PRIMARY KEY,
 name VARCHAR(255),
 celebrity_id INT REFERENCES celebrities(id)
);

多:多
- タグ付けのテーブルなどで使われるパターン
- 2次元では表現できないので、中間テーブルを用意する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


-- 投稿テーブル
CREATE TABLE posts (
 id SERIAL PRIMARY KEY,
 title VARCHAR(255)
);

-- タグテーブル
CREATE TABLE tags (
 id SERIAL PRIMARY KEY,
 name VARCHAR(255)
);

-- 中間テーブル
CREATE TABLE post_tags (
 post_id INT REFERENCES posts(id),
 tag_id INT REFERENCES tags(id),
 PRIMARY KEY (post_id, tag_id)
);

1:1
- 目的ごとに1つのテーブルを分けるパタン
- 意味論的と変更可能性を考慮して設計する
- 例えば、UserテーブルとそのUserのCredentialが合った場合
- UserがCredentialのIDを所有する
  - 意味論的にusers.credential_idの方がcredentials.user_idより良いから
  - もし、credentials.user_idにすると、credentailを作る時に、userが必要になるから
- ただし、今後の変更で1:多になるなら
  - つまり、User:Credential = 1:多になる場合はCredentailがUserを知る必要がある
  - スカラ値は正規化ではRDBでは許容されないから

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- ユーザーテーブル
CREATE TABLE users (
 id SERIAL PRIMARY KEY,
 name VARCHAR(255)
);

-- クレデンシャルテーブル
CREATE TABLE credentials (
 id SERIAL PRIMARY KEY,
 user_id INT UNIQUE REFERENCES users(id),
 password_hash VARCHAR(255)
);

リレーションとアソシエーションの違い

リレーション (Relation)：
- テーブルそのものやテーブル間の関係を指す。
- データベースの構造的な要素。
アソシエーション (Association)：
- エンティティ間の論理的な関係を指す。
- オブジェクト指向やERMにおける関係性を示す。

つまり、リレーションはデータベース設計の物理的・構造的な観点を強調し、
アソシエーションはエンティティ間の論理的な関係性を強調する。

1:1のリレーションの4つの手法

他にもおすすめはしないが4つの1:1のリレーションの実現方法がある。

主キーを共有

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- ユーザーテーブル
CREATE TABLE users (
 user_id SERIAL PRIMARY KEY,
 name VARCHAR(255)
);

-- クレデンシャルテーブル
CREATE TABLE credentials (
 user_id INT PRIMARY KEY,
 password_hash VARCHAR(255),
 FOREIGN KEY (user_id) REFERENCES users(user_id)
);

一方のテーブルに外部キーを持たせる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- ユーザーテーブル
CREATE TABLE users (
 user_id SERIAL PRIMARY KEY,
 name VARCHAR(255)
);

-- クレデンシャルテーブル
CREATE TABLE credentials (
 credential_id SERIAL PRIMARY KEY,
 user_id INT UNIQUE,
 password_hash VARCHAR(255),
 FOREIGN KEY (user_id) REFERENCES users(user_id)
);

両方のテーブルに外部キーを持たせる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


-- ユーザーテーブル
CREATE TABLE users (
 user_id SERIAL PRIMARY KEY,
 name VARCHAR(255),
 details_id INT UNIQUE,
 FOREIGN KEY (details_id) REFERENCES user_details(details_id)
);

-- 詳細情報テーブル
CREATE TABLE user_details (
 details_id SERIAL PRIMARY KEY,
 user_id INT UNIQUE,
 address VARCHAR(255),
 phone VARCHAR(255),
 FOREIGN KEY (user_id) REFERENCES users(user_id)
);

単一テーブルに統合する

1
2
3
4
5


CREATE TABLE users (
 user_id SERIAL PRIMARY KEY,
 name VARCHAR(255),
 password_hash VARCHAR(255)
);

命名規則

カラムの命名規則

テーブル名

ネームスペースでprefixをつける
- 例えば、core_infra_usersみたいなスコープ付きの形
複数形がベター
名前はsnake_caseにする
中間テーブルは
- xxx_xxxと並べる
- もしくはxxx_mappingとする

カラム名の命名規則

snake_caseにする
用途に合わせて命名規則を適用する

例

id, xxx_id
- PK, FKのカラム
xxx_cd, xxx_code, xxx_category
- カテゴリー、コード値のカラム
xxx_by
- usernameのカラム
xxx_at, xxx_time
- datetimeのカラム
is_xxx
- boolのカラム
xxx_status, xxx_type
- enumのカラム
created_by, update_by, created_at, updated_at, deleted_at
- 鉄板のカラム名

制約は2文字でタイプを示してsqlalchemy的に命名する。

pk_<テーブル名>
ix_<テーブル名>_<カラム名>
fk_<テーブル名>_<参照先テーブル名>
ck_<テーブル名>_<カラム名>
uq_<テーブル名>_<カラム名>
uq_<テーブル名>_<カラム名1>_<カラム名2>

ユニーク制約とユニークインデックスの違い

PostgreSQL 9.3.9において、両者には次の違いがある

UNIQUE 制約を作る => UNIQUE INDEX も作られる
UNIQUE INDEX を作る => UNIQUE 制約は作られない

ただし、UNIQUE制約とUNIQUEインデックスのどちらを使用しても、指定されたカラムの値が一意であることを強制する点では同じ。

一般的には、データの一貫性を強制するためにUNIQUE制約を使用し、結果として自動的に対応するUNIQUEインデックスが作成される。

論理設計

論理設計は（RDB）に依存しない形で、次の三つを行う。

リレーションの分解
- 1:N, N:1, N:Nの三つにリレーションはなる
- 中間テーブル（マッピングテーブル）に変換する
キーの整理
- 主キー、外部キー、制約などを定義する
正規化
- 三つのステップで正規化をする

正規化

非正規化
- 正規化前のテーブル
第1正規化
- カラムの値をスカラーにする事
第2正規化
- 部分関数従属（キーの一部に対して従属する列）の排除
第3正規化
- 推移的関数従属の解消

正規化の例

第一正規化

第1正規形の定義は「1つのセルには1つの値しか含まれない」なので、スカラーに編子する。

すると以下のようになる
この状態が関数従属性がない状態となる
正規化後は、以下のように関数従属が成立している

$$ {社員ID} → {社員名} {社員ID} → {子1} {社員ID} → {子2} $$

第二正規化

問題は、「会社名」だけは「会社コード」のみに従属している点
つまり、部分関数従属になってしまっている

第2正規形はエンティティをテーブルごとに分割する作業という事。

第三正規化

問題は推移的関数従属（段階的な従属関係）がある
具体的には次のように形式化できる

$$ {部署コード} → {部署} {会社コード、社員ID} → {部署コード} {会社コード、社員ID} → {部署コード} → {部署} $$

これにより、非キー列は主キー列に対してのみ従属するようになり推移的関数従属もなくなった。

あえて非正規化する

非正規化は、データを冗長にすることで、クエリのパフォーマンスを向上させる方法
関連データを1つのテーブルにまとめることで、JOINを避けることができる
JOINのボトルネックを避ける事で、パフォーマンス向上ができる

下はordersテーブルとcustomersテーブルを一つにまとめた非正規化の例。

1
2
3
4
5
6
7


CREATE TABLE customer_orders (
 customer_id BIGINT,
 customer_name TEXT,
 order_id BIGINT,
 order_date DATE,
 amount DECIMAL
);

物理設計

論理設計で定義されたデータモデルを、特定のDBMS上で実装するための詳細な設計。

テーブルの物理的なストレージ構造を定義する
インデックス、パーティショニング、クラスタリング、データ圧縮などの物理的な最適化を行う
DBMSの特定の機能を使用して、データの格納方法やアクセス方法を最適化する

テーブル設計書

エクセルでテーブル定義書を作るのがおすすめ。

テーブル設計仕様書

論理テーブル名	入出金行為
物理テーブル名	payments
作成日	20XX年10月10日(水)
作成者	Tanaka Taro

カラムの定義

#	PK	FK	論理名	物理名	型（桁）	デフォルト	例外
1	*		入出金行為ID	id	bigint		NOT NULL
2			日付	created_at	DATE		NOT NULL
3		*	利用者ID	user_id	bigint		NOT NULL
4			内容	note	VARCHAR(100)	不明	NOT NULL

パーテーション分割

大規模なテーブルを分割して管理し、クエリパフォーマンスとメンテナンスを向上させる。

水平分割（シャーディング）
- 大きなテーブルを複数の小さなテーブルに分割し、各テーブルを異なるサーバーに配置
- 例えばログテーブルなどは月ごとに分割しても問題がおきにくい
垂直分割
- テーブルの列を複数のテーブルに分割し、関連する列だけを含むテーブルを作成
- あえて関連するモノを別テーブルにまとめると、一括操作の管理が楽になる

水平分割の例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


CREATE TABLE sales (
 id SERIAL PRIMARY KEY,
 sale_date DATE,
 amount DECIMAL
) PARTITION BY RANGE (sale_date);

CREATE TABLE sales_2023 PARTITION OF sales
FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

CREATE TABLE sales_2024 PARTITION OF sales
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

垂直分割の例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


-- 基本情報テーブル
CREATE TABLE user_basic (
 user_id SERIAL PRIMARY KEY,
 name VARCHAR(255),
 email VARCHAR(255)
);

-- 詳細情報テーブル
CREATE TABLE user_details (
 user_id INT PRIMARY KEY,
 address VARCHAR(255),
 phone VARCHAR(255),
 FOREIGN KEY (user_id) REFERENCES user_basic(user_id)
);

Indexの作成

インデックスを使用して、特定のクエリのパフォーマンスを向上させる。

1

CREATE INDEX idx_users_username ON users (username);

複合インデックス

1

CREATE INDEX idx_department_email ON employees (department_id, email);

NOTE:

複合インデックスのカラムの順序は重要
最初のカラムがより選択的である場合、インデックスの効率が向上する
選択的とは=よりユニークであるという事

クラスタリング最適化

テーブルの物理的な並び順をインデックスに基づいて再編成し、範囲クエリのパフォーマンスを向上させる。

1

CLUSTER users USING idx_users_username;

データ圧縮の最適化

ストレージの使用量を削減し、I/Oパフォーマンスを向上させる。

1
2
3
4
5


-- 例: MySQLのInnoDBテーブルで圧縮を有効にする
CREATE TABLE compressed_table (
 id INT PRIMARY KEY,
 data TEXT
) ROW_FORMAT=COMPRESSED;

RDBのアーキ

MVCC

MVCCとは

マルチバージョン並行制御 (MVCC: Multi-Version Concurrency Control) の略
MVCCは、データベース管理システムにおいて、同時実行性を高めながら整合性を保つための技術
PostgreSQLやMySQLなどのモダンなデータベースシステムで広く採用されている

なぜバージョンか？

DBMS が既存の行を上書きしないというものです。代わりに、各 (論理) 行に対して、DBMS は複数の (物理) バージョンを維持するから
複数のクエリが、可能な場合は互いに干渉することなく、同時にデータベースの読み取りと書き込みを行えるようにすることが目的

MVCCの基本概念

Snapshot isolation（SI）:
- 各トランザクションは、自身の開始時点のデータベースの状態を「スナップショット」として取得する
- そして、そのスナップショットに基づいて読み取り操作を行う
- 他のトランザクションによる変更は影響を受けない
バージョニング
- 各データの変更は、新しいバージョンを作成することで管理される
- データベースは、異なるバージョンのデータを保持し、適切なバージョンをトランザクションに提供する
非ブロッキングリード
- 読み取り操作はロックを使用せず、他のトランザクションがデータを書き込んでいる間でもブロックされない
- これにより、読み取りのパフォーマンスが向上する
書き込み競合の処理
- 書き込み操作は、データの現在のバージョンを確認し、競合が発生しない場合に新しいバージョンを作成する
- 競合が発生した場合、適切な処理（再試行やロールバックなど）が行われる

SIの例

ある6つのレコードのODD行をEVENタイプに、EVEN行をODDタイプにする例。

シリアライザブルの場合は、常に順番が存在する
故に直列になり、後勝ちになる
結果、全てがODDもしくはEVENになる
そのため、競合する

他方SIの場合は、スナップショットを取る
そのスナップショットに基づき処理を行うので、他トランザクションの影響は起きない
2つに分かれるので、書き込み競合、ブロッキングリードが起きない

Multi-Versioned Storageの仕組み

例えば、yeraを1985 年から 1983 年に変更すると、新しいタプルが作成され、元のタプルは無効化される
用語
- データベース内部で各行をタプルと呼ばれる
- 複数のタプルが格納される単位の物理ブロックをページと呼ぶ
- タプルID（TID）は各行の物理的な位置を示すための識別子

参照する際は、TIDに紐づくバージョンチェーンを使う
version chainはリンクリストの構造を持ち、各タプルは次のバージョンへのポインタを持つ

検索効率を向上させるため、インデックスが使用される
インデックスにより、検索時の長いトラバースを避けることができる

図の通り、不要なタプルが生まれるため、VACUUMコマンドによって回収する。

InnoDB vs. MyISAM

MySQLで選べるストレージエンジンの違い。

特徴	InnoDB	MyISAM
トランザクション	サポート（ACID準拠）	サポートなし
参照整合性	外部キー制約をサポート	サポートなし
ロック機構	行・テーブルレベルロック	テーブルレベルロック
クラッシュリカバリ	あり（自動リカバリ）	限定的（手動リカバリ）
パフォーマンス	書き込み多いワークロードに最適	読み取り多いワークロードに最適
追加機能	MVCC、データ圧縮、バッファプール	高速なフルテキスト検索、COUNT(*) 操作
使用例	トランザクションが必要なシステム、データ整合性が重要なシステム	読み取り専用のシステム、検索性能が重要なシステム

InnoDBのデメリットはフルテキスト検索ができない点だが、正直そこはElasticSeachを使えばOK。

整合性

データベースシステムや分散システムにおいて3つの整合性のモデルがある。

強い整合性（Strong Consistency）

強い整合性とは、すべてのノードが常に最新のデータを持つ
また、どのクライアントがどのタイミングでアクセスしても一貫したデータを読み取れることを保証する整合性モデル
これは、直前の書き込みが完了してから次の読み取りが行われることを意味する
銀行の口座残高、在庫管理システムなど、データの一貫性が極めて重要なシステムで使用される

弱い整合性（Weak Consistency）

弱い整合性とは、システムがデータの一貫性を常に保証しない整合性モデル
クライアントがデータを読み取るときに最新のデータが返される保証はなく、一貫性の要件が緩和されている
ソーシャルメディアのフィード、キャッシュシステムなど、一貫性が重要ではないがスピードと可用性が重視されるシステムで使用される
PostgreSQLのトランザクション分離レベルはRead Commitedなので弱い整合性に当たる

結果整合性（Eventual Consistency）

結果整合性とは、一時的にデータの不整合が許容されるものの、最終的にはすべてのノードが同じデータに収束する整合性モデル
データの変更がすべてのレプリカに伝播し、最終的に一貫性が保たれる
読み取り操作は最新のデータを返すとは限らないが、最終的に一貫したデータに収束する
DNSシステム、電子メールシステムなど、短期間のデータ不整合が許容されるシステムで使用される

結果整合性の比較

データの整合性で言うと次の順番になる。

$$ 強い整合性　＞　結果整合性　＞　弱い整合性 $$

メリットとデメリットの比較は次。

整合性モデル	メリット	デメリット
強い整合性	常に最新のデータを保証	- レイテンシが増加する、可用性が低下する可能性がある
弱い整合性	高速な読み取りを提供、高い可用性を提供	- データの一貫性が保証されない、古いデータが返されることがある
結果整合性	高い可用性を提供、高いスループットを提供	- 一時的な不整合が発生する、最終的な一貫性までに時間がかかることがある

結果整合性の例

AWS S3が結果整合性のモデルだったが強いな整合性に変わった。その違いが分かりやすい。

結果整合性モデルなので、「時間はかかるかもしれないけど最終的にはデータの整合性は取れるよ」というのが元々の仕組みだった。

故に、取得したデータが完全に正しいかは保証がなかった。

強い結果整合性になったので、「データを追加したり更新したりした直後でも、最新の情報にアクセスできる」という仕組みになった。

CAP定理

CAP定理（CAP Theorem）は、分散データベースシステムが同時に以下の3つの特性を満たすことができない定理。

C: Consistency（一貫性）
- すべてのノードが常に同じデータを持つこと
A: Availability（可用性）
- すべての要求が成功または失敗の応答を返すこと
P: Partition tolerance（分断耐性）
- システムがネットワークの分断（パーティション）に耐えること

これに基づき、システムは以下のいずれかの組み合わせを選ぶ必要がある。

CA（Consistency and Availability）
- 分断耐性がない（単一のノードシステム）
CP（Consistency and Partition Tolerance）
- 可用性が制限される可能性がある
AP（Availability and Partition Tolerance）
- 強い整合性が制限される

インデックス

B-tree index

B-Treeの流れ

いくつかのデータ構造を説明する。

リスト
- 直列でつながるデータ構造
二分木（binary tree）
- 木構造(ツリー構造）のうち、どの親ノードも二つ以下の子ノードを持つもの
平衡木（バランスドツリー）
- 木構造は単一の根ノードを起点に「親ノードは複数の子ノードを持つことができる」という規則に従ってノードを連結したデータ構造
- 挿入、削除、および検索操作を効率的に行うために設計された木
平衡二分木（balanced binary tree）
- 二分木を平衡にした構造
AVL木
- 「どのノードの左右部分木の高さの差も1以下」という条件を満たす木
- ノードの回転操作によってバランスを保つ
B-tree
- 「1つのノードがm個 (m>=2) の子ノードを持つことができる」という条件を満たす木
- AVL木を一般化したような木
- ノード分割や結合によってバランスを保つ

直列のツリーと平衡木

リストは探索に$O(n)$かかる
他方、平衡木は節点の挿入/削除・探索どれもO(logN) で済む

例えば、下の9の右に10が挿入されたとき、節点8から見た右部分木は2(9,10)になる
しかし、左部分木は0や2からは高さが2になる
故に、AVL木の条件を満たさないため、再構成する必要がある

AVL木は回転操作をし、高さを制約である1以下にする
それとは実際には違うが、このようにノード分割や結合によってバランスを保つのがB-tree
検索は下記のようにタプル（行）に対して検索が行われる

マークルツリー

ちなみに、ブロックチェインではデータの整合性の為にマークルツリーが利用されている
マークルツリーの頂点がマークルルートであり、全部のトランザクションを要約したモノとなる
これによってblockのIDであるhashが最新のデータが改ざんされていないかの高速な検証が可能になる

基本的な構文

4つのSQLカテゴリー

RDBには4つのSQLカテゴリーが定義されている。

DDL（Data Definition Language）

データ定義言語は、データベースオブジェクト（テーブル、インデックス、ビュー、スキーマなど）の定義と管理を行う。

CREATE: 新しいデータベースオブジェクトを作成
ALTER: 既存のオブジェクトを変更
DROP: 既存のオブジェクトを削除
TRUNCATE: テーブルの全データを削除（構造は保持）

DML（Data Manipulation Language）

データ操作言語は、データベース内のデータの操作を行う。

SELECT: データの検索と取得
INSERT: 新しいデータの挿入
UPDATE: 既存のデータの更新
DELETE: 既存のデータの削除

DCL（Data Control Language）

データ制御言語は、データベースのアクセス制御と権限管理を行う。

GRANT: ユーザーに権限を付与
REVOKE: ユーザーから権限を剥奪

TCL（Transaction Control Language）

トランザクション制御言語は、トランザクションの管理を行う。

COMMIT: トランザクションの変更を確定
ROLLBACK: トランザクションの変更を取り消し
SAVEPOINT: トランザクション内の保存ポイントを設定
SET TRANSACTION: トランザクションの特性を設定

データ定義言語（DDL）

DDLは、データベーススキーマを定義および管理するために使用される。

CREATE

テーブルの作成

1
2
3
4
5
6


CREATE TABLE employees (
 id SERIAL PRIMARY KEY,
 name VARCHAR(100),
 department_id INTEGER,
 hire_date DATE
);

ALTER

テーブルの変更

1

ALTER TABLE employees ADD COLUMN salary NUMERIC;

DROP

テーブルの削除

1

DROP TABLE employees;

データ操作言語（DML）

DMLは、データベース内のデータを操作するために使用される。

SELECT

データの取得

1

SELECT * FROM employees;

特定の列の取得

1

SELECT name, department_id FROM employees;

条件付きのデータ取得

1

SELECT * FROM employees WHERE department_id = 10;

INSERT

データの挿入

1

INSERT INTO employees (name, department_id, hire_date) VALUES ('John Doe', 10, '2023-01-01');

UPDATE

データの更新

1

UPDATE employees SET salary = 60000 WHERE id = 1;

DELETE

データの削除

1

DELETE FROM employees WHERE id = 1;

データ制御言語（DCL）

DCLは、データベースに対するアクセス権限を制御するために使用される。

GRANT

権限の付与

1

GRANT SELECT, INSERT ON employees TO user_name;

REVOKE

権限の剥奪

1

REVOKE SELECT, INSERT ON employees FROM user_name;

トランザクション制御言語（TCL）

TCLは、トランザクションの制御を行うために使用する。

BEGIN

トランザクションの開始

1

BEGIN;

COMMIT

トランザクションの確定

1

COMMIT;

ROLLBACK

トランザクションの取り消し

1

ROLLBACK;

関数と集約

集約関数

SUM, AVG, COUNT, MAX, MIN

1
2
3
4
5


SELECT SUM(salary) FROM employees;
SELECT AVG(salary) FROM employees;
SELECT COUNT(*) FROM employees;
SELECT MAX(salary) FROM employees;
SELECT MIN(salary) FROM employees;

グループ化

GROUP BY

1

SELECT department_id, COUNT(*) FROM employees GROUP BY department_id;

条件付き集約

HAVING

1

SELECT department_id, COUNT(*) FROM employees GROUP BY department_id HAVING COUNT(*) > 10;

結合（JOIN）

内部結合

INNER JOIN

1
2
3


SELECT e.name, d.name
FROM employees e
INNER JOIN departments d ON e.department_id = d.id;

外部結合

LEFT JOIN

1
2
3


SELECT e.name, d.name
FROM employees e
LEFT JOIN departments d ON e.department_id = d.id;

RIGHT JOIN

1
2
3


SELECT e.name, d.name
FROM employees e
RIGHT JOIN departments d ON e.department_id = d.id;

クロス結合

CROSS JOIN

1
2
3


SELECT e.name, d.name
FROM employees e
CROSS JOIN departments d;

サブクエリ

サブクエリの使用

1
2
3


SELECT name
FROM employees
WHERE department_id = (SELECT id FROM departments WHERE name = 'HR');

インデックス

インデックスの作成

1

CREATE INDEX idx_department_id ON employees(department_id);

ビュー

ビューの作成

1
2


CREATE VIEW employee_view AS
SELECT name, hire_date FROM employees;

トリガー

トリガーの作成

1
2
3
4


CREATE TRIGGER update_timestamp
BEFORE UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION update_modified_column();

指定順序と実行順序

指定順序	実行順序	句	内容
2	1	FROM（JOINも含む）	実行対象のテーブルを指定する
3	2	WHERE	テーブルに対してレコードの抽出条件を指定する
4	3	GROUP BY	レコードをグループ化する
5	4	HAVING	グループ化した結果に対して抽出条件を指定する
1	5	SELECT	取得（表示）する列を指定する
6	6	ORDER BY	取得した列を並び替える

その他

エイリアス

エイリアス（as）は省略可能

InとBetweenの使い分け

複数の値に対して同じ条件をチェックする場合、IN を使う
また、範囲をチェックする場合は BETWEEN を使う

1
2


SELECT * FROM employees WHERE department_id IN (10, 20, 30);
SELECT * FROM employees WHERE hire_date BETWEEN '2020-01-01' AND '2020-12-31';

Case句

1
2
3
4
5
6


SELECT
 department_id,
 SUM(CASE WHEN gender = 'M' THEN 1 ELSE 0 END) AS male_count,
 SUM(CASE WHEN gender = 'F' THEN 1 ELSE 0 END) AS female_count
FROM employees
GROUP BY department_id;

集合系

集合操作

SQLの集合の操作とは、テーブルから取得した結果セットに対して、和集合、積集合、差集合などの操作を行う事。

和集合

$$ BLUE + RED $$

重複を削除する場合

1
2
3


SELECT * FROM BLUE
UNION
SELECT * FROM RED ;

重複を削除しない場合

1
2
3


SELECT * FROM BLUE
UNION ALL
SELECT * FROM RED ;

積集合

$$ BLUE - RED $$

1
2
3
4
5


/* BLUE * RED */

SELECT * FROM BLUE
INTERSECT
SELECT * FROM RED ;

差集合

1
2
3
4
5


/* BLUE - RED(BLUEにはあって、REDにはないもの) */

SELECT * FROM BLUE
EXCEPT
SELECT * FROM RED ;

重複排除

1
2


SELECT DISTINCT column1, column2
FROM table1;

部分集合

1
2
3


SELECT column1, column2
FROM table1
WHERE column1 IN (SELECT column1 FROM table2);

部分集合

集計系

Group by

指定した列に基づいて行をグループ化し、そのグループごとに集計を行う。

1
2
3
4
5
6
7


SELECT
 department_id,
 AVG(salary) AS avg_department_salary
FROM
 employees
GROUP BY
 department_id;

selectに指定できるのは次の3パターン。

group byで指定したカラム
集計関数
定数

Window

元の行を消さずに、集計関数を使って行ごとに結果を計算する
下のクエリは、各従業員の部門ごとの平均給与を計算し、それを元の行と共に表示する
下のPARTITION BY department_idがgroup by department_idに相当する
つまり、元のemployeesは維持される

1
2
3
4
5
6
7


SELECT
 employee_id,
 department_id,
 salary,
 AVG(salary) OVER (PARTITION BY department_id) AS avg_department_salary
FROM
 employees;

ウィンドウ関数には、次の関数などがある。

ROW_NUMBER()
- 各行に一意の番号を振る
RANK()
- 値に順位を付け、同じ値には同じ順位を振る
- なお、次の順位はスキップされる
DENSE_RANK()
- 値に順位を付け、同じ値には同じ順位を振る
- 次の順位はスキップされない
SUM()
- 累積合計を計算する
AVG()
- 平均値を計算する
OVER()
- ウィンドウの指定を行う

JOIN

基本

複数のテーブルを結合して関連するデータを取得するための手段

1
2
3


SELECT columns
FROM table1
JOIN table2 ON table1.common_column = table2.common_column;

Apply演算子

Apply演算子とは

APPLY 演算子は、SQL Serverで提供される特有の演算子
APPLY 演算子は、左側のテーブルの各行に対して右側のテーブル関数を適用し、その結果を結合する
つまり、行ごとに異なるサブクエリを実行することができる
ただし、これは結局Outer Joinと同じなのでApplyを使わなくても大丈夫である

Applyの例

業員テーブル（employees）とその従業員のプロジェクトを管理するテーブル（projects）があると仮定する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


CREATE TABLE employees (
 employee_id INT PRIMARY KEY,
 first_name VARCHAR(50),
 last_name VARCHAR(50)
);

CREATE TABLE projects (
 project_id INT PRIMARY KEY,
 employee_id INT,
 project_name VARCHAR(50),
 FOREIGN KEY (employee_id) REFERENCES employees(employee_id)
);

従業員ごとに、その従業員が担当するプロジェクトを取得するクエリは次となる
CROSS APPLY を使用すると、各従業員のプロジェクトが取得される

1
2
3
4
5
6
7


SELECT e.employee_id, e.first_name, p.project_name
FROM employees e
CROSS APPLY (
 SELECT project_name
 FROM projects p
 WHERE e.employee_id = p.employee_id
) p;

データを準備する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


INSERT INTO employees (employee_id, first_name, last_name)
VALUES
(1, 'John', 'Doe'),
(2, 'Jane', 'Smith');

INSERT INTO projects (project_id, employee_id, project_name)
VALUES
(1, 1, 'Project A'),
(2, 1, 'Project B'),
(3, 2, 'Project C');

実行結果

employee_id	first_name	project_name
1	John	Project A
1	John	Project B
2	Jane	Project C

ただし、これは結局Left Outer Joinと同じなので、outer joinさえ分かっていればよい。

18のJoinテクニックの詳細

18のJoinテクニックとは

18個のMSのTSQLのテクニック
TSQLでは多くのJOINタイプがあり、それぞれ異なる状況に応じて適切に選択する必要がある
各JOINは、特定の状況で適切に使用することで、必要なデータを効率的に取得することができる
MySQLやPostgreSQLでも応用ができる

SELECT from two tables

2つのテーブルからデータを単純に取得する場合、それぞれ個別にSELECT文を使用。

1
2


SELECT * FROM Table1;
SELECT * FROM Table2;

INNER JOIN

INNER JOINは、両方のテーブルに共通するデータのみを取得
内部結合には共通のキーが必要

1

SELECT * FROM Table1 t1 INNER JOIN Table2 t2 ON t1.fk = t2.id;

LEFT OUTER JOIN

LEFT OUTER JOINは、左側のテーブルの全データと、右側のテーブルの一致するデータを取得
右側のテーブルに一致するデータがない場合、NULLが返される

1

SELECT * FROM Table1 t1 LEFT OUTER JOIN Table2 t2 ON t1.fk = t2.id;

RIGHT OUTER JOIN

RIGHT OUTER JOINは、右側のテーブルの全データと、左側のテーブルの一致するデータを取得
左側のテーブルに一致するデータがない場合、NULLが返される

1

SELECT * FROM Table1 t1 RIGHT OUTER JOIN Table2 t2 ON t1.fk = t2.id;

FULL OUTER JOIN

FULL OUTER JOINは、両方のテーブルの全データを取得し、どちらか一方にしかないデータにはNULLが返される。

1

SELECT * FROM Table1 t1 FULL OUTER JOIN Table2 t2 ON t1.fk = t2.id;

CROSS JOIN（交差結合）

CROSS JOINは、両方のテーブルの全ての組み合わせを生成する
データの掛け算のようなもの
CROSS JOINは、2つのテーブルのすべての組み合わせを返す
結合条件はない

1

SELECT * FROM Table1 t1 CROSS JOIN Table2 t2;

SEMI JOIN（半結合）

SEMI JOINは、左側のテーブルから右側のテーブルに一致する行が存在する場合、その行のみを取得
INNER JOINは、結合条件に一致する両方のテーブルの行を取得するが、Semi joinは片方のみ

1

SELECT * FROM Table1 t1 WHERE EXISTS (SELECT 1 FROM Table2 t2 WHERE t1.fk = t2.id);

ANTI SEMI JOIN（反半結合）

ANTI SEMI JOINは、左側のテーブルから右側のテーブルに一致しない行のみを取得する
ANTI SEMI JOINはマスターなのにFKとして使用されていないモノのみを取るイメージ

1

SELECT * FROM Table1 t1 WHERE NOT EXISTS (SELECT 1 FROM Table2 t2 WHERE t1.fk = t2.id);

APPLY（適用）

CROSS APPLY（交差適用）
1

SELECT * FROM Table1 t1 CROSS APPLY (SELECT * FROM Table2 t2 WHERE t1.fk = t2.id) AS t;
CROSS APPLYは、左側のテーブルの各行に対して右側のテーブルのサブクエリを適用。
OUTER APPLY（外部適用）
1

SELECT * FROM Table1 t1 OUTER APPLY (SELECT * FROM Table2 t2 WHERE t1.fk = t2.id) AS t;
OUTER APPLYは、左側のテーブルの各行に対して右側のテーブルのサブクエリを適用し、一致する行がない場合はNULLを返す。

複合JOIN

Two FULL OUTER JOINs（2つの完全外部結合）

1

SELECT * FROM Table1 t1 FULL OUTER JOIN Table2 t2 ON t1.fk = t2.id FULL OUTER JOIN Table3 t3 ON t1.fk_table3 = t3.id;

3つのテーブル間で完全外部結合を行う。

Two INNER JOINs（2つの内部結合）

1

SELECT * FROM Table1 t1 INNER JOIN Table2 t2 ON t1.fk = t2.id INNER JOIN Table3 t3 ON t1.fk_table3 = t3.id;

3つのテーブル間で内部結合を行う。

INNER JOIN and a LEFT OUTER JOIN（内部結合と左外部結合）
1

SELECT * FROM Table1 t1 LEFT OUTER JOIN Table2 t2 ON t1.fk = t2.id LEFT OUTER JOIN Table3 t3 ON t1.fk_table3 = t3.id;
内部結合と左外部結合を組み合わせてデータを取得する。

サブクエリ

基本

サブクエリの構文

サブクエリは、括弧 () で囲まれ、通常はSELECT文の中に含める
SELECT文、FROM句、WHERE句などで使われる

1
2
3


SELECT 列1, 列2, ...
FROM テーブル名
WHERE 列 = (SELECT 列 FROM 他のテーブル WHERE 条件);

サブクエリの使いどころ

フィルタリング:
- 特定の条件に一致するデータを抽出する際に使用
- where句とin句でサブクエリを使うなど
集計:
- 集計関数と組み合わせて、特定のグループに対する集計結果を利用する場合
- 複数行返すサブクエリをWhere句とAVG句と共に利用するなど
比較:
- 比較演算子と一緒に使用して、条件を満たすかどうかを確認する
- =,>,<,!=など
データの挿入、更新、削除:
- 複数のテーブルからのデータを使って操作を行う際に使用される
- INSERT, UPDATE, DELETE文で利用するなど

サブクエリを使用した例

全ての従業員の名前と給与を表示すが、給与がその従業員の部門の平均給与以上の人のみを対象とするクエリ。

1
2
3
4
5
6


--
SELECT name, salary
FROM employees e1
WHERE salary >= (SELECT AVG(salary)
 FROM employees e2
 WHERE e1.department_id = e2.department_id);

また、In句との相性も良い。

1
2
3
4
5
6
7
8
9


SELECT department_id, AVG(salary)
FROM employees
WHERE department_id IN (
 SELECT department_id
 FROM employees
 GROUP BY department_id
 HAVING AVG(salary) > 50000
)
GROUP BY department_id;

サブクエリの種類

単一行サブクエリ

結果が1行1列のみを返すサブクエリ

1
2
3
4
5


SELECT name
FROM employees
WHERE department_id = (SELECT department_id
 FROM departments
 WHERE department_name = 'Sales');

複数行サブクエリ

複数の行を返すサブクエリ
IN, ANY, ALL演算子と一緒に使うことが多い
下の例は普通のサブクエリなので、サブクエリに引数がないので1度だけ実行される

1
2
3
4
5


SELECT name
FROM employees
WHERE department_id IN (SELECT department_id
 FROM departments
 WHERE location_id = 1700);

相関サブクエリ

外側のクエリの結果に依存するサブクエリ
サブクエリ内で外側のクエリの列を参照する
サブクエリの引数（下の例だとe1.department_id）があるため、引数が変わったタイミングで実行される

1
2
3
4
5


SELECT e1.name
FROM employees e1
WHERE salary > (SELECT AVG(salary)
 FROM employees e2
 WHERE e1.department_id = e2.department_id);

自己相関サブクエリ

各行ごとに個別に評価されるのでパフォーマンスは良くない

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


SELECT
 employee_id,
 employee_name,
 salary,
 (SELECT COUNT(*)
 FROM employees e2
 WHERE e2.department_id = e1.department_id AND e2.salary >= e1.salary) AS salary_rank
FROM
 employees e1
ORDER BY
 department_id, salary_rank;

ネストされたサブクエリ

サブクエリ内にさらにサブクエリを含む場合

1
2
3
4
5
6
7


SELECT name
FROM employees
WHERE department_id = (SELECT department_id
 FROM departments
 WHERE location_id = (SELECT location_id
 FROM locations
 WHERE city = 'Seattle'));

サブクエリの代替

CTE（共通テーブル式）とは

WITH句を使用して共通テーブル式を定義することがベター
サブクエリは複数回評価される可能性があるが、CTEは一度だけ評価されるため、複数回の計算を避けることができ、効率的
また、サブクエリは再帰的に使用する事ができないが、CTEは再帰的に使用できるため、階層構造や親子関係のデータを扱うのに便利
簡単なフィルタリングならサブクエリでもOK

サブクエリの場合

1
2
3


SELECT id, name
FROM employees
WHERE salary > (SELECT AVG(salary) FROM employees);

CTEの場合

1
2
3
4
5
6
7


WITH AverageSalary AS (
 SELECT AVG(salary) AS avg_salary
 FROM employees
)
SELECT id, name
FROM employees
WHERE salary > (SELECT avg_salary FROM AverageSalary);

Viewとは

ビューは仮想的なテーブルとして定義され、データベース内に保存される
ビュー自体にデータは保持されないが、基になるテーブルのデータを参照する
基になるテーブルの構造を隠し、特定の列やデータだけを公開することができ、データの抽象化が可能

1
2
3
4
5
6


CREATE VIEW high_salary_employees AS
SELECT id, name, salary
FROM employees
WHERE salary > 50000;

SELECT * FROM high_salary_employees;

Viewとセキュリティ

サブクエリは一時的なものでそのクエリ内でのみ有効だが、ビューはデータベースに保存され、複数のクエリで再利用可能
また、ビューは特定の列やデータだけを公開することで、セキュリティを強化する手段として使用もできる

元テーブル

1
2
3
4
5
6


CREATE TABLE employees (
 id INT,
 name VARCHAR(100),
 department VARCHAR(50),
 salary DECIMAL(10, 2)
);

ビューの作成:

1
2
3
4
5
6
7
8


CREATE VIEW public_employees AS
SELECT id, name, department
FROM employees;

CREATE VIEW hr_employees AS
SELECT id, name, department
FROM employees
WHERE department = 'HR';

ビューの利用

1
2


SELECT * FROM public_employees;
SELECT * FROM hr_employees;

こうする事で次の2つができる。

特定の行のみ参照
特定の列のみ参照

また、ビューの権限設定をする事でユーザーごとの認証も可能。

1

GRANT SELECT ON public_employees TO user_role;

user_roleというロールに対してpublic_employeesビューへのSELECT権限を付与する事ができる
これによって、そのロールに属するユーザーはビューを通じてデータにアクセスできるようになる

Materialized View

Materialized Viewはクエリの結果を物理的に保存するビュー
通常のビューがクエリの定義を保存だけだが、Materialized Viewは実際のデータも保存する
そのため、複雑なクエリを高速化することができる
ただし、データは基となるテーブルが更新されたときに自動的に更新されるわけではないので注意

1
2
3
4
5
6
7
8
9


CREATE MATERIALIZED VIEW sales_summary AS
SELECT
 product_id,
 SUM(quantity) AS total_quantity,
 SUM(price * quantity) AS total_sales
FROM
 sales
GROUP BY
 product_id;

データのリフレッシュ

1
2


-- 完全リフレッシュ
REFRESH MATERIALIZED VIEW sales_summary;

トランザクション

トランザクション分離レベル

標準SQLの分離レベル

トランザクション分離レベルは4つある
Postgresのデフォルトはリードコミッティド
つまり、1回目のリードでは、最新を取得できるという事

分離レベル	ダーティリード	反復不能読み取り	ファントムリード
リードアンコミッティド	可能性あり	可能性あり	可能性あり
リードコミッティド	安全	可能性あり	可能性あり
リピータブルリード	安全	安全	可能性あり
シリアライザブル	安全	安全	安全

リードアンコミッティド（Read Uncommitted）
- 他のトランザクションがコミットしていない変更を読み取ることができる
- SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
リードコミッティド（Read Committed）
- 他のトランザクションがコミットした変更のみを読み取る
- SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
リピータブルリード（Repeatable Read）
- トランザクションが開始された後に他のトランザクションがコミットした変更を読み取らない
- SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
シリアライザブル（Serializable）
- トランザクションが完全に順序付けられたかのように実行される。最も厳密な分離レベルであり、並行トランザクションによる影響を受けない
- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

禁止される現象

次の3つの現象が発生する恐れがある。

ダーティリード
- 同時に実行されている他のトランザクションが書き込んで未だコミットしていないデータを読み込んでしまう事
反復不能読み取り
- トランザクションが、以前読み込んだデータを再度読み込み、
- そのデータが（最初の読み込みの後にコミットした）別のトランザクションによって更新されたことを見出す事
ファントムリード
- トランザクションが、複数行のある集合を返す検索条件で問い合わせを再実行した時、
- 別のトランザクションがコミットしてしまったために、同じ検索条件で問い合わせを実行しても異なる結果を得てしまう事

Serializable分離の仕組み

Serializableではネクストキーロックを行う
つまり、行ロックとギャップロックをかけているという事
具体的には、selectにselect for updateをかけいるようなモノ
その間は排他処理になるので、トランザクション間でデータ整合性が保たれる

PostgreSQLのREAD COMMITTEDの注意

PostgresのデフォルトはRead Commited
なので、ダーティーリード（他のトランザクションのcommit前の変更の読み取り）は発生しない
また、1回目のクエリは常に最新になる
しかし、二回同じクエリを発行する際は注意
- 反復不能読み取りで、同じトランザクションの中で、2回目の結果が変わる事がある
- ファントムリードで、同じトランザクションの中で、複数読み取りの結果が変わる事がある

原始性、一貫性、隔離性、耐久性（ACID特性）

信頼性のあるトランザクションシステムの持つべき性質として定義した概念
トランザクション分離性は他のトランザクションに影響を与えない性質

原子性 (Atomicity)

トランザクション内の操作が全て実行されるか、または全て実行されないかのどちらかになる
中途半端な状態は有り得ないです
つまり、トランザクションはそれ以上細かい単位に分割することができない作業単位であるということ

一貫性 (Consistency)

トランザクションの実行前と後でデータに矛盾がなく整合性が保たれる性質

分離性 (Isolation)

トランザクション中に行われる操作は他のトランザクションに影響を与えない性質
つまり、それぞれのトランザクションは分離された状態で操作を行わなければならない

永続性 (Durability)

トランザクションが完了すると、その処理結果は永続的となる
たとえシステム障害が発生してもデータが失われることがない性質

サブトランザクション

サブトランザクションの方法

サブトランザクションは入れ子になったトランザクションの事
サブトランザクションを使いたい場合は次のようにSavepointでできる
入れ子にするSavepoint内でのサブトランザクションのrollbackも可能
ただし、Savepointはあくまでrollback用なので注意
savepointでcommitしても、上位のトランザクションでrollbackされるとsavepointもrollbackする

1
2
3
4
5
6
7
8
9


BEGIN;

INSERT INTO my_table (id, value) VALUES (1, 'value1');

SAVEPOINT my_savepoint;
INSERT INTO my_table (id, value) VALUES (2, 'value2');
ROLLBACK TO SAVEPOINT my_savepoint;

COMMIT;

SavePointのPythonでの例

以下はSQLAlchemyでの例
注意点としてはネストされたトランザクションを部分コミットできない
そのため、形式上はネストされたトランザクションをコミットしているように見えるが実際は違う
親のトランザクションがロールバックすると子のコミット（に見えるもの）はロールバックする

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


try:
 # 外側のトランザクションの開始
 session.begin()

 # 最初の操作
 t = MyTable(id=1)
 session.add(t)
 session.commit()

 # ネストされたトランザクションの開始
 with session.begin_nested() as nested:
 try:
 t2 = MyTable(id=2)
 session.add(t2)
 session.commit() # 本当はwithを抜けると自動でcommitされる
 except:
 nested.rollback()

 # 注意: ここですでにcommitしているがsavepointなので、rollbackすると上のt2の変更も消える

 # 他の操作が続く
 t3 = MyTable(id=3, value='value3')
 session.add(t3)
 session.commit()

except:
 session.rollback()
finally:
 session.close()

これを解決するには新たにトランザクションを切るしかない
結局サブトランザクションの内容をコミットするには、コミットしてトランザクションを新規に作る必要がある
つまり、beginの時にcommitされる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


try:
 # 外側のトランザクションの開始
 session.begin()

 # 最初の操作
 t = MyTable(id=1)
 session.add(t)
 session.commit()

 # ネストされたトランザクションの開始
 with session.begin_nested() as nested:
 try:
 t2 = MyTable(id=2)
 session.add(t2)
 session.commit() # 本当はwithを抜けると自動でcommitされる
 except:
 nested.rollback()

 # この時点ではまだt1, t2の内容はコミットされない
 session.commit()

 # 新しいトランザクションの開始
 # ここで先行するトランザクションが確定し、t1, t2が保存される
 session.begin()

 # 他の操作が続く
 t3 = MyTable(id=3, value='value3')
 session.add(t3)
 session.commit()
except:
 session.rollback()
finally:
 session.close()

排他ロックと共有ロック

select for updateとselect for shareの違い

SELECT FOR UPDATE（排他ロック）
- 排他ロック（他のトランザクションは読み取りや更新ができない）が目的
- 用途は、読み取った後すぐにその行を更新する場合
SELECT FOR SHARE（共有ロック）
- 共有ロック（他のトランザクションはSELECT FOR UPDATEでロックできないが、読み取りは可能）が目的
- 用途は、読み取り専用だが、他のトランザクションがその行を更新するのを防ぎたい場合

select for updateの用途

一つの例としては、銀行口座の更新
他のトランザクションは読み込みはできるが変更はできなくなる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


BEGIN;

-- 口座の残高をチェックし、他のトランザクションが残高を変更しないようにロック
SELECT balance FROM accounts WHERE account_id = 12345 FOR UPDATE;

-- 残高が十分にあるかを確認
-- この間に他のトランザクションが残高を変更することはできない
-- ただし、読み取りは可能

-- 残高が十分にある場合、引き出しを行う
UPDATE accounts SET balance = balance - 100 WHERE account_id = 12345;

COMMIT;

select for shareの用途

例えば、複数のユーザーが同時にレポートを生成する場合
それぞれのユーザーが読み取るデータが一貫していることを保証する必要がある

1
2
3
4
5
6
7
8
9


BEGIN;

-- レポート生成のために共有ロックを取得
SELECT * FROM sales_data WHERE report_date = '2024-06-22' FOR SHARE;

-- データを使用してレポートを生成
-- 他のトランザクションが排他ロックを取得してデータを変更するのを防ぐ

COMMIT;

つまり、頻繁に変わるデータがあり、かつ複数人があるタイミングで同時に処理する必要があり、
その時にその複数人で同じデータを参照したいときに、select for shareを使ってロックする用途

楽観ロックと悲観ロック

データベースにおける同時実行制御のためのロック戦略
これらのロックは複数のトランザクションが同時に同じデータを操作する際のデータ整合性を保つために使用する

楽観ロック

楽観ロックは、データの競合が発生しないことを前提としたロック戦略。
トランザクションがデータを読み取り、変更を加えてコミットする際に競合が発生していないかを確認する

特徴

競合の前提
- データの競合が稀であると仮定する
ロックの方法
- データをロックせずに読み取り、更新時にデータの整合性をチェックする
適用シナリオ
- 読み取りが多く、書き込みが少ないシステムに適している

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


-- 準備
CREATE TABLE employees (
 id SERIAL PRIMARY KEY,
 name VARCHAR(100),
 department_id INTEGER,
 salary DECIMAL
);
INSERT INTO employees (name, department_id, salary) VALUES ('Alice', 10, 50000);
INSERT INTO employees (name, department_id, salary) VALUES ('Bob', 20, 60000);

-- Aliceの給料を1.1倍に変更
WITH updated AS (
 UPDATE employees
 SET salary = salary * 1.1
 WHERE department_id = 10
 RETURNING *
)
SELECT COUNT(*) FROM updated;

もしくは、SELECT ROW_COUNT();を使用してもいいかもしれない。

悲観ロック

悲観ロックは、データの競合が発生することを前提としたロック戦略
トランザクションがデータを読み取る際にロックを取得し、他のトランザクションが同じデータにアクセスできないようにする

特徴

競合の前提
- データの競合が頻繁に発生すると仮定
ロックの方法
- データを読み取る際にロックを取得し、トランザクションが終了するまでロックを保持する
適用シナリオ
- 書き込みが多く、競合が頻繁に発生するシステムに適している

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


-- トランザクションの開始
BEGIN TRANSACTION;

-- 排他ロックの取得とデータの読み取り
SELECT id, name, price
FROM products
WHERE id = 1
FOR UPDATE;

-- データの更新
UPDATE products
SET price = 120
WHERE id = 1;

-- トランザクションのコミット
COMMIT;

ロック

テーブルロック

RDBのテーブルのスキーマのマイグレーション時に特に使う処理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- テーブルを読み取り専用モードでロック
LOCK TABLES task READ;

-- テーブルを読み取り/書き込みモードでロック
LOCK TABLES task WRITE;

-- 例: task.Statusを更新するためのトランザクション
START TRANSACTION;
LOCK TABLES task WRITE;

UPDATE task
SET Status = 'IN_PROGRESS'
WHERE Status = 'WAITING';

-- ロックを解除してトランザクションを終了
UNLOCK TABLES;
COMMIT;

行ロック

これはWAITINGのステータスを持つレコードをロックしている
そのため、例えば、もっと具体的なモノがあればそれでロックするのがベター
行ロックはさらに、排他ロックと共有ロックに分かれる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- トランザクションの開始
START TRANSACTION;

-- 特定の行をロック（この場合、FOR UPDATEを使用）
SELECT * FROM task WHERE Status = 'WAITING' FOR UPDATE;

-- 例: task.Statusを更新
UPDATE task
SET Status = 'IN_PROGRESS'
WHERE Status = 'WAITING';

-- トランザクションをコミットしてロックを解除
COMMIT;

ネクストキーロック

ネクストキーロックは行ロックとギャップロックの組み合わせ
いわゆるselect for updateみたいなモノ

$$ ネクストキーロック = 行ロック（レコードロック）+ ギャップロック $$

Serializableトランザクション分離レベルでの一貫性を保てる
つまり、ファントムリードを防ぐ事ができる

ギャップロック

名前の通りギャップに対してロックをする事

例：

価格が100から200の範囲にある行に対してギャップロックが取得され、この範囲内に新しい行が挿入されるのを防ぐ。

1
2
3
4
5
6
7
8


START TRANSACTION;

-- 範囲クエリに対してギャップロックを取得
SELECT * FROM products WHERE price BETWEEN 100 AND 200 FOR UPDATE;

-- このロックにより、他のトランザクションがこの範囲内に新しい行を挿入するのを防ぐ

COMMIT;

排他処理

排他処理のコツ

排他処理をする場合は状態遷移図を先に書いた方がベター
排他処理をする前のステータスでロックとWhere句をかけて処理をする形になる

Current State	Next State	Condition
WAITING	IN_PROGRESS	Analysis started
IN_PROGRESS	FAILED	Error occurred
IN_PROGRESS	DONE	Successfully completed
FAILED	WAITING	Retry after failure

また、関連するレコードも変えたい場合はそれらもその間に取得する必要がある
全く同じ処理で別インスタンス、プロセス、スレッド、コルーチンなどからアクセスされる場合は同じ
また、IN_PROGRESSだからRDBの別のレコードを変更する場合、基本的に同じトランザクションの中でやらないといけない
ただし、ロックしているトランザクションのスコープが長くなるとよくないので、別の同じような処理をしている所でもロックする必要がある

排他制御の処理方法

次のようにトランザクションの中で処理する
- 前提条件をWhere句にする事で状態遷移を確定する
- select for updateで他のプロセスから読み込ませないようにする

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- テーブルを読み取り専用モードでロック
LOCK TABLES task READ;

-- テーブルを読み取り/書き込みモードでロック
LOCK TABLES task WRITE;

-- 例: task.Statusを更新するためのトランザクション
START TRANSACTION;
LOCK TABLES task WRITE;

UPDATE task
SET Status = 'IN_PROGRESS'
WHERE Status = 'WAITING';

-- ロックを解除してトランザクションを終了
UNLOCK TABLES;
COMMIT;

競合状態の回避方法

次のような処理が同時に走るとデッドロックになる。

あるトランザクションで、Aをロック -> Bをロックする順番で、
別のトランザクションで、Bをロック -> Aをロックのが同時に走る

その解消方法は以下。

ロックの順番を揃える
ロックの範囲を狭める
トランザクションを短くする
ロックのタイムアウトの設定

パフォーマンスチューニング

最適化の理由

大規模なサービスだとRDBの性能がボトルネックになることがある
データベースの効率的な運用、リソースの最適化、スケーラビリティの確保、そして全体的なユーザー体験と直結するから

自動インクリメント

グローバルな一意性を確保するために自動インクリメントIDを使用することが一般的
これにより、スケーリング時に各シャードで一意のIDが生成

1
2
3
4
5


CREATE TABLE users (
 id BIGINT AUTO_INCREMENT PRIMARY KEY,
 username VARCHAR(255) NOT NULL,
 email VARCHAR(255) NOT NULL
);

複数ノードでIDのコンフリクトが置きそうな気もするが、シャード事に設定を変えて避ける事が可能。

1
2
3
4
5
6
7
8
9


-- シャード1の設定
-- 1, 11, 21
SET @@auto_increment_increment=10;
SET @@auto_increment_offset=1;

-- シャード2の設定
-- 2, 12, 22
SET @@auto_increment_increment=10;
SET @@auto_increment_offset=2;

UUIDv4だと分散システムにも耐えられるのでOK
UUIDv3だと別マシンでコリジョンが起きる可能性があるので注意
ソートもできるUUIDv7が今後は主流になるかもしれない

あえてFKをつけない

高トラフィックのアプリケーションで見た設計手法
テーブルの外部キーに対して、あえてFKをつけずに定義する
パフォーマンスとスケーラビリティを担保するために制約を極力使わない戦略

理由

パフォーマンス
- オーバーヘッド
  - 外部キー制約により、データベースは参照整合性を確保する必要がありオーバーヘッドになる
- 同時実行数
  - FK制約は挿入および更新によるロックが増加し、同時実行数が減少する
スケーラビリティ
- シャーディングの問題
  - シャードまたはノード間で外部キー制約を維持することは複雑で非効率的になる
- レプリケーションラグ
  - 外部キー制約によりレプリケーション処理が複雑になり、レプリケーションラグが発生
フレキシビリティ
- 整合性
  - アプリケーションレベルでのFKデータ整合性が取れるため
- スキーマ変更
  - 外部キー制約により、スキーマの移行がより複雑になる
つまり、アプリケーションレベルでのデータ整合性の担保するという方法
一番深刻なのが、同時実行デッドロックの問題、高負荷なアプリではこれが問題になる
さらにサブデータベスにはFK自体が貼れない問題もある

インデックスの設計

適切なインデックスの設計: クエリパフォーマンスを向上させるために、適切なインデックスを設定
特に、頻繁に検索されるカラムやジョインに使用されるカラムにはインデックスを設定

1
2


CREATE INDEX idx_username ON users(username);
CREATE INDEX idx_email ON users(email);

次のカラムなどにつける。

頻繁に検索されるカラム
ジョインに使用されるカラム
一意性を保証する場合（UNIQUEインデックス）

シャーディング戦略

Vitessを基盤とすることでmysqlでシャーディングをサポートできる
シャーディングキー（dynamodbでいうpatitionkey）の選定が大切
データを均等に分散させ、負荷分散をする事が目的のため

1
2
3
4
5
6


CREATE TABLE orders (
 order_id BIGINT AUTO_INCREMENT PRIMARY KEY,
 user_id BIGINT NOT NULL,
 product_id BIGINT NOT NULL,
 order_date DATETIME NOT NULL
) /* vtgate={keyspace: ecommerce, sharding: true, shard_key: user_id} */;

リードレプリカの活用

主に読み取り専用のクエリを処理する目的で使用されるデータベースのコピーの事
例
- Staticな製品カタログの閲覧や検索クエリをリードレプリカにオフロードする
- ダイナミックメインデータベースは注文処理や在庫管理などの書き込みトランザクションに集中させる
CDNとAPIの違いみたいなモノ

クエリ最適化

EXPLAINとEXPLAIN ANALYZE、ANALYZEを使ってクエリの実行計画を取得する
ここら辺のチューニングは深いので、別ページにする

水平スケール vs. 垂直スケール

RDBによる、例えば、次のような違いがRDBによってある。

PostgreSQLは、垂直スケーリング（スケールアップ）型
CockroachDBは、水平スケーリング（スケールアウト）型

分散システム

分散ロック

分散ロックとは

分散ロックは、複数のプロセスやノードが同時にリソースにアクセスするのを制御するためのメカニズム
分散システムにおいてデータの整合性と一貫性を維持するため使用する
有名なのはRedisやApache Zookeeperによる分散ロック

RDBを使ったロック

一番シンプルなのがRDBを使ったロック
あるリソースに対して使用中のロックのフラグを立てる
CONFLICT DO NOTHINGはINSERT文を実行する際に、挿入しようとするデータが既に存在する場合に何も行わないようにするためのもの

テーブルの定義

1
2
3
4
5


CREATE TABLE locks (
 resource_id VARCHAR(255) PRIMARY KEY, -- 一意のリソースID
 lock_token VARCHAR(255) NOT NULL, -- ロックを保持するためのトークン
 expires_at TIMESTAMP NOT NULL -- ロックの有効期限
);

分散ロックの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- ロックの取得
INSERT INTO locks (resource_id, lock_token, expires_at)
VALUES ('resource_1', 'token_123', NOW() + INTERVAL '1 minute')
ON CONFLICT (resource_id) DO NOTHING;

-- ロックの解放
DELETE FROM locks WHERE resource_id = 'resource_1' AND lock_token = 'token_123';

-- 有効期限が切れたロックのクリーンアップ:
DELETE FROM locks
WHERE expires_at < NOW();

Redisを使った分散ロック

RedisのSETNX（Set if Not Exists）コマンドを使用して分散ロックを実現できる
SETNXコマンドは、キーが存在しない場合にのみセットするため、ロックの取得が競合しない

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import redis
import uuid

client = redis.StrictRedis(host='localhost', port=6379, db=0)
lock_token = str(uuid.uuid4())

# ロックの取得
if client.setnx('resource_1_lock', lock_token):
 try:
 # リソースに対する操作
 pass
 finally:
 # ロックの解放
 if client.get('resource_1_lock') == lock_token:
 client.delete('resource_1_lock')

分散トランザクション

分散トランザクションとは

分散トランザクションは、複数のネットワーク上にある独立したデータベースやシステムに対して、一貫性を保ちながらトランザクションを実行するためのプロセス
複数のデータベースにまたがってアトミックに処理しなければならない時などに必要となる

分散トランザクションのパターン

分散トランザクションは、大体以下の2つのプロトコルによって実現する。

2フェーズコミットプロトコル（2PC: Two-Phase Commit Protocol）
- フェーズ1: 準備（Prepare）:
  - トランザクションコーディネータは、すべての参加者に対してトランザクションの準備を依頼
  - 参加者はローカルトランザクションを準備し、成功したかどうかをコーディネータに通知
- フェーズ2: コミット（Commit）:
  - すべての参加者が準備完了を通知すると、コーディネータはコミットを指示
  - コーディネータがコミットを指示すると、すべての参加者はトランザクションをコミットし、完了を通知
  - もし一つでも準備に失敗した場合、コーディネータはすべての参加者にロールバックを指示

3フェーズコミットプロトコル（3PC: Three-Phase Commit Protocol）
- 2PCのデッドロック問題を回避するために、3PCではさらに準備段階を追加して、参加者がコミットする準備ができるかどうかを確認
- これにより、ネットワーク分断などの障害が発生した場合にデッドロックを回避することができる

分散トランザクションの例

SpringとAtomikosを使った例

Atomikos Transaction Manager

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


import com.atomikos.icatch.jta.UserTransactionManager;
import com.atomikos.icatch.jta.UserTransactionImp;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.annotation.EnableTransactionManagement;
import org.springframework.transaction.jta.JtaTransactionManager;

@Configuration
@EnableTransactionManagement
public class TransactionManagerConfig {

 @Bean(initMethod = "init", destroyMethod = "close")
 public UserTransactionManager atomikosTransactionManager() {
 // 分散トランザクションを管理する、Prepare Phaseなどを行う
 UserTransactionManager userTransactionManager = new UserTransactionManager();
 userTransactionManager.setForceShutdown(true);
 return userTransactionManager;
 }

 @Bean
 public UserTransactionImp userTransactionImp() throws Throwable {
 // トランザクションの開始、コミット、ロールバックなどを行う
 UserTransactionImp userTransactionImp = new UserTransactionImp();
 userTransactionImp.setTransactionTimeout(300);
 return userTransactionImp;
 }

 @Bean
 public PlatformTransactionManager transactionManager() throws Throwable {
 return new JtaTransactionManager(userTransactionImp(), atomikosTransactionManager());
 }
}

使用例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class ExampleService {

 @Autowired
 private RepositoryA repositoryA;

 @Autowired
 private RepositoryB repositoryB;

 @Transactional
 public void performDistributedTransaction() {
 // RepositoryAの操作
 repositoryA.save(new EntityA());

 // RepositoryBの操作
 repositoryB.save(new EntityB());
 }
}

その他

UNIQUE_KEYへのNull

ユニークキーへの2つ以上のnullの挿入では次の違いがある。

postgres: OK
mysql: duplicated

入れるべきモノは最初に入れるべき

基本的に制約は消すのは簡単だが後から追加するのは大変
- 例えば、新たにFKの追加や、UKの追加など
また、データは本来正規化後に決定されるモノ
故に、今は使わなくても入れるべきリレーションや制約は最初に追加するべき
後々データマイグレーションをすると大変になる

重複したデータ

基本的にマスターテーブル以外でも重複したデータは入れるべきではない
何かしらのカラムで本来はユニークできるはずだから
不用意に完全に重複したレコードがある場合は設計ミス

N+1クエリ

N+1クエリ問題は、データベースアクセスにおけるパフォーマンス上のアンチパターン
ORMではEager LoadingやPrefetchなどで無駄なクエリが走らないように注意する

owner_idパターン

あえてレコード全てに所有者のuser_idをFKとして持たせる手法
owner_idとして必ずそれらをチェックする事でデータの権限の整合性を保つ
ただしパフォーマンスは良くない

JOINやサブクエリを発行しない

JOINやSub queryもパフォーマンスの問題にあたるのでパフォーマンスが余裕な時を除いて行わない
するならWITH句のCTE（Common Table Expression）式を使ってあらかじめ計算する

例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


CREATE TABLE orders (
 order_id BIGINT PRIMARY KEY,
 customer_id BIGINT,
 order_date DATE,
 amount DECIMAL
);

CREATE TABLE customers (
 customer_id BIGINT PRIMARY KEY,
 customer_name TEXT
);

あらかじめCTEで過去一年間分を別途計算しJOINする。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


WITH total_sales AS (
 SELECT customer_id, SUM(amount) AS total_amount
 FROM orders
 WHERE order_date >= CURRENT_DATE - INTERVAL '1 year'
 GROUP BY customer_id
)

SELECT c.customer_id, c.customer_name, ts.total_amount
FROM customers c
LEFT JOIN total_sales ts ON c.customer_id = ts.customer_id;

STI（Single Table Inheritance）

STIはRailsで行うテーブル設計のパターン
OOPの継承に似ているが実態は、タグ付きUnion型に近いイメージ

1
2
3
4


type Android = {type: 'android', value: string}
type iPhone = {type: 'iphone', value: [number, number]}

type SmartPhone = Android | iPhone

下の図では、androidとiphoneというテーブルは存在せず、一つのphoneというテーブルで管理される
その際にsmartphoneテーブルのtypeによってアプリケーション側で必要なカラムのみを出す仕組みとなる
完全な親子関係（is-a）があるテーブル同士をDIYにまとめる手法

発番テーブル

次のフローで裁判テーブルを更新する。

トランザクション開始
採番テーブルからレコードを取得してロックする
noを+1してレコードを更新する
トランザクションをコミット（ロックが解除される）

1
2
3
4
5
6
7
8


CREATE TABLE id_sequences (
 name VARCHAR(64) NOT NULL,
 next_id BIGINT NOT NULL,
 PRIMARY KEY (name)
);

-- 初期シーケンス値の挿入
INSERT INTO id_sequences (name, next_id) VALUES ('user_id', 1);

実行は次のSQLでロックする。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


BEGIN;

-- シーケンス行をロック
SELECT * FROM id_sequences WHERE name = 'user_id' FOR UPDATE;

-- シーケンス番号をインクリメント
UPDATE id_sequences SET next_id = next_id + 1 WHERE name = 'user_id';
-- 新しいシーケンス番号を取得
SELECT next_id - 1 AS user_id FROM id_sequences WHERE name = 'user_id';

-- トランザクションをコミットしてロックを解除
COMMIT;

もしくは、IDの設計をして、Prefix+BigIntとするのが良い
単なるBigIntだとFKエラーも抜けてしまうため

過去の値を元にロックする手法

下の商品の在庫の個数を減らすコードは同時実行されると、
トランザクションの分離レベルによるが、破綻する可能性があるので注意

1
2
3
4


UPDATE products
SET remaining_amount = remaining_amount - 1
WHERE id = 1
 AND remaining_amount > 0

上の在庫管理はクリティカルなビジネスプロセスなので、ロックするべき
つまり、下のようになる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


BEGIN;

-- 在庫を減らす前に行をロック
SELECT remaining_amount FROM products
WHERE id = 1
FOR UPDATE;

-- 在庫があるか確認して更新
UPDATE products
SET remaining_amount = remaining_amount - 1
WHERE id = 1
 AND remaining_amount > 0;

COMMIT;

ただし、簡易的な排他処理、例えばブログの投稿のrevision管理などでは、
パフォーマンス重視でわざわざ行ロックをしなくてもいい気もする

1
2
3


UPDATE posts
SET title = title, content = content, revision_no = revision_no + 1
WHERE post_id = 1 and revision_no = 10;

辞書テーブル

本質的にアプリケーションの設定は2種類ある。

Static setings
- コードレベルで決まっている設定値
Dynamic settings
- ユーザーレベルで決まっている設定値

このうち、StaticはYamlでもコードでもいいが、DynamicはDBに落す必要がある。
（なぜなら、そうしないとユーザードリブンで変えられないから）

上のような形でテーブルを定義し、seedやfixtureという形でmasterデータを投入する。　　もしdict_typeにメタ情報を付与したいなら、別テーブルにしてもいいかもしれない。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


CREATE TABLE dictionary (
 dict_type VARCHAR(50) NOT NULL,
 dict_code VARCHAR(50) NOT NULL,
 dict_value VARCHAR(100) NOT NULL,
 PRIMARY KEY (dict_type, dict_code)
);

-- 国コードの挿入
INSERT INTO dictionary (dict_type, dict_code, dict_value) VALUES
('country', 'US', 'United States'),
('country', 'JP', 'Japan'),
('country', 'DE', 'Germany'),
('country', 'FR', 'France');

-- 言語コードの挿入
INSERT INTO dictionary (dict_type, dict_code, dict_value) VALUES
('language', 'EN', 'English'),
('language', 'JA', 'Japanese'),
('language', 'DE', 'German'),
('language', 'FR', 'French');

-- ステータスコードの挿入
INSERT INTO dictionary (dict_type, dict_code, dict_value) VALUES
('status', 'ACT', 'Active'),
('status', 'INA', 'Inactive'),
('status', 'SUS', 'Suspended'),
('status', 'DEL', 'Deleted');

接続テスト

接続テキストには軽量クエリを使ってチェックすることが多い。

1

select 1

参考文献

OOPでのプログラムの設計の基本（DI、AOP）

Tue, 28 May 2024 21:22:48 +0900

前提

Spring BootのPJの管理をするにあたって改めてOOP、DI、AOPなどを整理した
DB設計や関数型プログラミングなどのパラダイムにおける設計は省く
また、DDDでの設計やGoFなどのデザインパターン、UMLでの要件定義などもここでは省く

モジュール論

モジュールの定義

「複合/構造化設計」では以下のようにモジュールが定義されている。

閉じたサブルーチンであること
プログラム内の他のどんなモジュールからも呼び出すことができること
独立してコンパイルできる可能性をもっていること

モジュールの独立性を高める方法

モジュールの独立性を高めるには次の2つの観点が重要になる。

各モジュール内の関連性を最大にすること => 凝集度を上げる
モジュール間の関連性を最小にすること => 結合度を下げる

凝集度（Cohesion）

凝集度とは

凝集度とは、単一モジュール内の要素間の関連性についての一つの尺度
プログラムの構造の"良さ"あるいは"悪さ"を評価する尺度

凝集形態

凝集度は、望ましいものから順に、以下のように分類される。

機能的凝集度（Functional Cohesion）
- 1つの固有の機能を実行するモジュール
情報的凝集度（Informational Cohesion）
- 概念、データ構造、資源などを1つのモジュール内に隔離したモジュール
連絡的凝集度（Communicational Cohesion）
- データに関連のある複数の機能を逐次的に実行するモジュール
手順的凝集度（Procedural Cohesion）
- 仕様によって定められた、関連の少ない複数の機能を逐次的に実行するモジュール
時間的凝集度（Temporal Cohesion）
- 関連の少ない幾つかの機能を逐次的に実行するモジュール
論理的凝集度（Logical Cohesion）
- 関連したいくつかの機能を持っていて、呼び出しモジュールによって選択され、実行するモジュール
暗合的凝集度（Coincidental Cohesion）
- 何を根拠にモジュールになっているのか説明できないような、論外の状態

機能的凝集度と情報的凝集度は同列になる。

結合度（Coupling）

結合度とは

結合度は、主に、モジュール間の関連性についての尺度
結合度を小さく保つために次の2つが大切
- モジュール間の不要な関連性をなくすこと
- 必要とされる関連性の強さをできるだけ小さくする

結合形態

結合度は、望ましいものから順に、以下のように分類される。

非直接結合（Indirect Coupling）
- モジュールが直接的に互いに依存しないが、他のモジュールを介して間接的に依存しているもの
- 例
  - モジュールAとモジュールBがイベントバスを介して通信する
データ結合（Data Coupling）
- モジュール間のインタフェースデータが単一のデータであるもの
- 例
  - モジュールAがモジュールBに単一の数値を渡す
スタンプ結合（Stamp Coupling）
- 2つのモジュール間でやり取りするデータがグローバルではないもの
- 例
  - モジュールAがモジュールBに構造体全体を渡し、その一部だけを使用する
制御結合（Control Coupling）
- 1つのモジュールが他のモジュールの論理をはっきりと制御する関連、制御されるモジュール
- 例
  - モジュールAがフラグをモジュールBに渡し、そのフラグでモジュールBの処理を制御する
外部結合（External Coupling）
- 内容結合でも共通結合でもなく、単一のグローバルデータを参照しているも
- 例
  - モジュールAとモジュールBが同じファイルシステムの設定ファイルを参照する
共通結合（Common Coupling）
- グローバルな、データ構造を参照するモジュールのグループの間で生じるもの
- 例
  - モジュールAとモジュールBがグローバル変数を共有している
内容結合（Content Coupling）
- 2つのモジュールで、1つが他の内部を「直接」参照するケース
- 例
  - モジュールAがモジュールBの内部データに直接アクセスする

凝集度と結合度の図

図のように、凝集度（Cohesion）が高く、結合度（Coupling）が低いと良い。

OOP, DI, AOPと結合度および凝集度の関係

それぞれの関係は次のようになる。

パラダイム	結合度	凝集度
OOP	- インターフェースやポリモーフィズム	- SOLID原則
DI	- 依存関係の外部注入	- 依存関係の管理を明示的に
AOP	- クロスカッティング関心事を分離	- モジュールが特定の責務に集中
GoF	インターフェースと抽象クラスを利用	責務の分離

OOP

OOPの三大要素

いわゆるOOPの三大要素。

ポリフォーリズム

ポリモーフィズムとは、多態性とも呼ばれ、同じインターフェースを使用して異なる実装を利用できる能力
interfaceやprotocolをimplementsせずに、ダックタイピングすることもある

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class Animal:
 def speak(self):
 pass

class Dog(Animal):
 def speak(self):
 return "Woof!"

class Cat(Animal):
 def speak(self):
 return "Meow!"

def make_animal_speak(animal):
 print(animal.speak())

dog = Dog()
cat = Cat()

make_animal_speak(dog) # "Woof!"
make_animal_speak(cat) # "Meow!"

カプセル化

カプセル化とは、データ（属性）とそれに関連するメソッド（操作）を1つのオブジェクトとしてまとめること
アクセッサー（ゲッター・セッター）やインデクサーを使い、隠蔽する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


class Person:
 def __init__(self, name, age):
 self._name = name
 self._age = age

 def get_name(self):
 return self._name

 def set_name(self, name):
 self._name = name

 def get_age(self):
 return self._age

 def set_age(self, age):
 if age > 0:
 self._age = age

person = Person("John", 30)
print(person.get_name()) # "John"
person.set_age(31)
print(person.get_age()) # 31

継承

継承とは、既存のクラス（親クラスまたはスーパークラス）の属性とメソッドを、新しいクラス（子クラスまたはサブクラス）に引き継ぐこと
いわゆるis-a関係を表現するために利用する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


class Vehicle:
 def __init__(self, brand, model):
 self.brand = brand
 self.model = model

 def drive(self):
 return "Driving"

class Car(Vehicle):
 def __init__(self, brand, model, num_doors):
 super().__init__(brand, model)
 self.num_doors = num_doors

 def honk(self):
 return "Honking"

car = Car("Toyota", "Corolla", 4)
print(car.drive()) # "Driving"
print(car.honk()) # "Honking"
print(car.brand) # "Toyota"
print(car.model) # "Corolla"
print(car.num_doors) # 4

継承とコンポジションと委譲

明確な「is-a」関係がある場合は継承をする
それ以外の「has-a」関係がある時はコンポジションをする
一般的に、継承より委譲を優先する

コンポジション（has-a関係）の例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class Engine:
 def start(self):
 print("Engine started")

class Car:
 def __init__(self):
 self.engine = Engine() # Car has-a Engine

 def start(self):
 self.engine.start() # Delegating the start action to the engine

my_car = Car()
my_car.start()

委譲の例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class Printer:
 def print_document(self, document):
 print(f"Printing: {document}")

class Office:
 def __init__(self):
 self.printer = Printer() # Office has-a Printer

 def print_report(self, report):
 self.printer.print_document(report) # Delegating the print action to the printer

office = Office()
office.print_report("Annual Report")

NTOE:

コンポジションと委譲の違いは、意味論的なモノにある
車はエンジンを持っているが、OfficeはPrinterを持っていない
違いは次
- コンポジット: Car has an Engine.
- 委譲: Office uses a Printer.

システム設計の原則

SOLID原則

クラス設計は最低限次の原則に従うべき。

単一責任の原則（Single Responsibility Principle, SRP）

クラスは、単一の責任を持つべき
その責任に対する変更理由は一つだけであるべき

オープン/クローズド原則（Open/Closed Principle, OCP）

ソフトウェアエンティティ（クラス、モジュール、関数など）は拡張に対して開かれているべき
変更に対して閉じられているべき

リスコフ置換原則（Liskov Substitution Principle, LSP）

基底クラスのインスタンスは、派生クラスのインスタンスに置き換え可能でなければならない

インターフェース分離の原則（Interface Segregation Principle, ISP）

クライアントは、それが使用しないインターフェースに依存してはならない
つまり、大きなインターフェースを小さなインターフェースに分割するべき

依存関係逆転の原則（Dependency Inversion Principle, DIP）

高レベルのモジュールは低レベルのモジュールに依存してはならず、両者は抽象に依存すべき
具体的な実装ではなく、抽象に依存する設計を行う
importing cycleなどが悪いパターン

分離

関心の分離と責任の分離

クラスを分ける時の分離の基準は以下になる。

関心の分離（Separation of Concerns）
- ソフトウェアの各部分が異なる機能やロジックに集中することを指す
- 例
  - MVC、レイヤードアーキテクチャ
責任の分離（Separation of Responsibilities）
- システムの各部分が特定の機能やロジックに対して責任を持つようにする設計
- 例
  - 単一責任の原則（Single Responsibility Principle, SRP）

DIとAOPが必要な理由

クラスに対して次を担保するため。

クリーンにする事
単一責任（SRP: Single Responsibility Principle）にする事
再利用性を高める事
疎結合にする事

共通の機能はAOPで注入し、依存するインスタンスはDIで注入する。

GRASP

GRASPとは

Applying UML and Patterns（実践UMLパターン）で紹介された9つのOOPの設計パターン
GRASPの意味は、General Responsibility Assignment Software Patterns（汎用責任割り当てソフトウェアパターン）

GRASPの9つのパターン

オブジェクト指向設計において適切な責任の割り当てを行い、保守性、再利用性、拡張性の高いシステムを構築するための9つの指針。

Information Expert（情報エキスパート）
- 情報を持っているオブジェクトに、その情報に基づく責任を割り当てるという原則
Creator（生成者）
- あるオブジェクトが他のオブジェクトの生成責任を持つべき場合についてのガイドライン
Controller（コントローラー）
- システム操作を調整し、利用者からの入力を処理するオブジェクトに責任を割り当てるという原則
Low Coupling（低結合）
- オブジェクト同士の依存関係を最小限に抑えることで、システムの柔軟性と保守性を向上させるという原則
High Cohesion（高凝集）
- クラスやモジュールが一貫した責任を持ち、それを中心に機能がまとまっていることを目指す原則
Polymorphism（ポリモーフィズム）
- 異なるオブジェクトが同じインターフェースを実装することで、多態性を実現し、柔軟性を向上させる原則
Pure Fabrication（純粋な構築）
- ドメインモデルに直接関連しないが、システムの設計をシンプルにするために導入される人工的なクラスやオブジェクト
Indirection（間接化）：
- 関係性や依存性を間接的に管理することで、柔軟性や再利用性を向上させる原則
Protected Variations（保護された変動）
- 変動する可能性のある部分を保護し、変動の影響を最小限に抑えるための設計手法

DI

DIの基礎

なぜDIが必要か？

下の例の通り、X1 < X2 < X3 の順で疎結合になっている
プログラムの再利用性や変更可能性を上げるために、疎結合に作るのが基本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


class Dep():
 pass

# フィールド
class X1:
 """プログラムロード時（クラス読み込み時）に初期化する"""
 dep = Dep()

# コンストラクター
class X2:
 """クラスを利用時に初期化する"""
 dep: Dep
 def __init__(self, dep):
 self.dep = dep

# DI
class X3:
 """DIコンテナを利用する"""
 dep: Dep
 def __init__(self, ctx):
 self.dep = ctx.get_by_name("dep")

DIの利点

疎結合:
- オブジェクト間の依存関係を外部から注入することで、クラス同士の結合度が低くなり、変更に強くなる
テストの容易さ:
- 依存関係を外部から注入するため、モックオブジェクトを用いたユニットテストが容易になる
再利用性の向上:
- 同じオブジェクトが異なる文脈で再利用しやすくなる

DISの種類

次の3つの方法がある。

アノテーションによるDI

次のアノテーションをクラスに付与することで、Springのコンテナがそれらのクラスを管理する
- @Component、@Service、@Repository、@Controllerなど
依存関係を注入するためには、@Autowiredアノテーションをフィールドやコンストラクタに付与する
自動でコンポーネントスキャンされる
- コンポーネントスキャンとは、Bean定義用のアノテーションが付与されたクラスをDIコンテナに登録すること
- Bean定義用のアノテーションとは、@Component, @Controller, @Serviceといったアノテーションのこと

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Bean定義
@Service
public class GreetingService {
 public String greet() {
 return "Hello, World!";
 }
}

@RestController
public class GreetingController {
 private final GreetingService greetingService;

 @Autowired
 public GreetingController(GreetingService greetingService) {
 this.greetingService = greetingService;
 }

 @GetMapping("/greet")
 public String greet() {
 return greetingService.greet();
 }
}

Java ConfigによるDI

@Configurationアノテーションを付与したクラス（Java Config）で、@Beanアノテーションを使ってBeanを定義する
これにより、明示的にBeanを定義して管理することができる
DIコンテナに登録したコンポーネントの事をBean、Configurationの事をBean定義と言う

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


public class GreetingService {
 public String greet() {
 return "Hello, World!";
 }
}

@Configuration
public class AppConfig {

 @Bean
 @Scope("prototype")
 public GreetingService greetingService() {
 return new GreetingService();
 }
}


@RestController
public class GreetingController {
 private final ApplicationContext context;

 // これがBean定義
 @Autowired
 public GreetingController(ApplicationContext context) {
 this.context = context;
 }

 @GetMapping("/greet")
 public String greet() {
 GreetingService greetingService = context.getBean(GreetingService.class); // これがBean
 return greetingService.greet();
 }
}

XMLによるDI

以前はXMLファイルを使用してDIの設定を行う方法が主流だった
Spring Bootでは主にアノテーションベースの設定が推奨されている

Beanのスコープ

Beanのスコープは、Beanのライフサイクルと可視性を定義する事。
以下のようなスコープがある。

Singleton（シングルトン）
- グローバルに共有されるオブジェクトに適している
Prototype（プロトタイプ）
- 各Beanのリクエストごとに新しいインスタンスが生成される
Request（リクエスト）
Session（セッション）
Application（アプリケーション）
WebSocket（ウェブソケット）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


package com.example.demo.service;

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Service;

@Service
@Scope("prototype")
public class GreetingService {
 public String greet() {
 return "Hello, World!";
 }
}

NOTE:

シングルトンの中のプロトタイプの注意
- なお、シングルトンBeanにプロトタイプBeanを注入すると、プロトタイプBeanは1回だけインスタンス化される
- そして、それ以降は同じインスタンスが使用されてしまう
- そのため、@Lookupメソッドインジェクションを利用する事で、毎回新しいインスタンスを取得でるようになる
当然singletonはスレッドアンセーフなので注意

インジェクション

Spring BootのDIには3つのインジェクションがある。

コンストラクタインジェクション

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@RestController
public class GreetingController {
 private final GreetingService greetingService;

 @Autowired
 public GreetingController(GreetingService greetingService) {
 this.greetingService = greetingService;
 }

 @GetMapping("/greet")
 public String greet() {
 return greetingService.greet();
 }
}

セッターインジェクション

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@RestController
public class GreetingController {
 private GreetingService greetingService;

 @Autowired
 public void setGreetingService(GreetingService greetingService) {
 this.greetingService = greetingService;
 }

 @GetMapping("/greet")
 public String greet() {
 return greetingService.greet();
 }
}

フィールドインジェクション

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@RestController
public class GreetingController {
 @Autowired
 private GreetingService greetingService;

 @GetMapping("/greet")
 public String greet() {
 return greetingService.greet();
 }
}

オートワイヤリング

@Autowiredアノテーションは型ベースと名前ベースの2種類で推測する。

例えば、同じ型名が複数あったときに分からなくなる。
その場合は、それぞれ次の方法で解決する。

型ベース
- @Qualiferアノテーション
- @Primaryアノテーション
名前ベース
- @Resourceアノテーション
  - NOTE: Resourceはコンストラクタインジェクションでは利用できない

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


@Service("greetingService1")
public class GreetingService1 implements GreetingService {
 public String greet() {
 return "Hello, World! from GreetingService1";
 }
}

@Service("greetingService2")
public class GreetingService2 implements GreetingService {
 public String greet() {
 return "Hello, World! from GreetingService2";
 }
}

@RestController
public class GreetingController {
 private GreetingService greetingService;

 @Resource(name = "greetingService1")
 public void setGreetingService(GreetingService greetingService) {
 this.greetingService = greetingService;
 }

 @GetMapping("/greet")
 public String greet() {
 return greetingService.greet();
 }
}

コンポーネントスキャン

Spring Bootは、特定のパッケージやそのサブパッケージ内のBeanを自動的に検出して登録する
コンポーネントスキャン（@ComponentScan）を使用する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.ComponentScan;

@SpringBootApplication
@ComponentScan(basePackages = "com.example.custom")
public class DemoApplication {
 public static void main(String[] args) {
 SpringApplication.run(DemoApplication.class, args);
 }
}

@Component
- 汎用的なSpring Beanとして定義されるクラスに使用
- 例: 汎用的なサービスやヘルパークラス
@Service
- サービスレイヤーのBeanを示す
- 例: ビジネスロジックを実装するクラス
@Repository
- データアクセスオブジェクト（DAO）クラスに使用
- 例: データベース操作を行うクラス
@Controller
- プレゼンテーションレイヤー、特にWeb MVCのコントローラとして使用
- 例: HTTPリクエストを処理し、レスポンスを返すクラス
@RestController
- 特にRESTful Webサービスのエンドポイントを定義するコントローラに使用
- 例: REST APIのエンドポイントを提供するクラス
@Configuration
- JavaベースのSpring設定クラスに使用
- 例: Bean定義や設定を行うクラス

Beanのライフサイクル

Spring BootのBeanのライフサイクルはJava EE環境でのBeanのライフサイクル（JSR 250）と同じ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.sql.DataSource;
import org.springframework.stereotype.Component;

@Component
public class MyBean {

 @Resource(name = "java:comp/env/jdbc/MyDataSource")
 private DataSource dataSource;

 @PostConstruct
 public void initialize() {
 System.out.println("Initializing MyBean");
 // 初期化処理
 }

 @PreDestroy
 public void cleanup() {
 System.out.println("Cleaning up MyBean");
 // クリーンアップ処理
 }

 public void performService() {
 // サービスのロジック
 System.out.println("Performing service in MyBean");
 }
}

プロファイル管理

@Profileアノテーションの利用してBeanを定義する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import org.springframework.context.annotation.Profile;
import org.springframework.stereotype.Component;

@Component
@Profile("dev")
public class DevService {
 // 開発環境専用のサービス
}

@Component
@Profile("prod")
public class ProdService {
 // 本番環境専用のサービス
}

Bean Validation

バリデーション（入力チェック）用のフレームワーク
以下がBean Validationの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


package sample.bean_validation.ejb;

import java.util.Set;
import javax.ejb.Stateless;
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
import sample.bean_validation.bean.HelloBean;

@Stateless
public class HelloEjb {

 public void hello() {
 // Validator を取得
 ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
 Validator validator = factory.getValidator();

 // Bean を作成
 HelloBean bean = new HelloBean();

 // バリデーションを実行
 Set<ConstraintViolation<HelloBean>> result = validator.validate(bean);

 // 結果の確認
 System.out.println("size = " + result.size());
 System.out.println("message = " + result.iterator().next().getMessage());
 }
}

1
2
3
4
5
6
7
8


package sample.bean_validation.bean;

import javax.validation.constraints.NotNull;

public class HelloBean {
 @NotNull
 private String hoge;
}

JSR 330との比較

JSR 330アノテーションは、Javaの依存性注入に関する標準仕様で、Springとの対応は次になる
Spring BootでもJSR 330の一部のアノテーションは使用可能である

機能	Spring アノテーション	JSR 330 アノテーション
コンポーネントの定義	@Component	@Named
依存関係の注入（フィールド/メソッド/コンストラクタ）	@Autowired	@Inject
依存関係のクオリファイ	@Qualifier	@Named
ライフサイクルコールバック（初期化）	@PostConstruct (JSR 250)	@PostConstruct (JSR 250)
ライフサイクルコールバック（破棄）	@PreDestroy (JSR 250)	@PreDestroy (JSR 250)
スコープの設定	@Scope	@Singleton
プロバイダの使用	@Autowired (もしくは `ObjectProvider`)	`Provider`

AOP

AOPとは

アスペクト指向プログラミング（AOP: Aspect-Oriented Programming）は横断的関心事を効果的に管理する為のパラダイムの事

横断的関心事

横断的関心事とは

横断的関心事（Cross-cutting concerns）ソフトウェア開発において、アプリケーション全体にわたって共通して発生する機能や要件など。

ロギング
トランザクション管理
エラーハンドリング
メトリクスとモニタリング

横断的関心事の分離

関心の分離があるように、横断的関心事の分離もある
アプリケーション全体にわたって共通して必要となる機能やロジックを、ビジネスロジックから独立させて管理すること

SpringとAOP

SpringはAOPの機能がある
内部ではAspectJのライブラリを利用している

AOPの主要な用語

AOPの概念図

簡潔に表現すると、次のようになる。

プログラム実行時、Adviceという処理はさむ
はさむ箇所（メソッド）はPointcut式定義する
そのメソッドの一つ一つの事をjoint Pointという

アスペクト（Aspect）

横断的関心事の事
- 例えば、ログを管理するなど
横断的関心事を定義するモジュール

$$ Aspect = Advice + Pointcut $$

ジョインポイント（Join Point）

アプリケーション実行中の特定のポイント
通常はメソッドの呼び出しや実行がジョインポイントになる
ポイントカットはjoin pointsの集合の事

アドバイス（Advice）

実際に横断的な機能を実行するコード
アドバイスは、特定のジョインポイント（Join Point）に適用される

アドバイスの種類

Srpingには以下の種類がある。

Before Advice:
- 対象メソッドが実行される前に実行される
After Advice:
- 対象メソッドが実行された後に実行される
Around Advice:
- 対象メソッドの前後で実行され、メソッドの実行を制御できる
After Returning Advice:
- 対象メソッドが正常に終了した後に実行される
After Throwing Advice:
- 対象メソッドが例外をスローした後に実行される

ポイントカット（Pointcut）

ポイントカットはJoint Pointsの集合の事。

$$ Pointcuts : Joint Points = 1 : N $$

ポイントカット式

下のような形式に従う。

ポイントカット式の例

Method Signature Patterns

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


@Pointcut("execution(public * *(..))")
public void anyPublicMethod();

@Pointcut("execution(* com.example.app.service.*.*(..))")
public void anyMethodInServicePackage();

@Pointcut("execution(* com.example.app.service..*.*(..))")
public void anyMethodInServicePackageAndSubPackage();

@Pointcut("execution(public Account com.example.app.service.TransferService.*(..))")
public void allPublicMethodOfTransferServiceReturnTypeAccount();

@Pointcut("execution(void com.example.app.service.TransferService.*(Account account, ..))")
public void allMethodOfTransferServiceVoidReturnTypeFirstArgumentAccount();

@Pointcut("execution(public * com.example.app.service.*.tranfer(Account account1, Account account2))")
public void allTranferMethodsInServicePackageWithTwoArgumentsOfAccountType();

Type Signature Patterns

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@Pointcut("within(com.example.app.service.*)")
public void allMethodsInServicePackage();

@Pointcut("within(com.example.app.service..*)")
public void allMethodsInServicePackageAndSubPackages();

@Pointcut("within(com.example.app.service.TransferService)")
public void allMethodsOfTransferService();

@Pointcut("within(com.example.app.service.TransferService+)")
public void allMethodsOfTransferServiceImpl();

Bean Name Patterns

1
2
3
4
5


@Pointcut("bean(transferService)")
public void allMethodsOfTransferServiceBean();

@Pointcut("bean(*Service)")
public void allMethodsOfBeanNameAsTransferService();

Combining Pointcut Expressions

1
2
3
4
5
6
7
8


@Pointcut("execution(public * *(..))")
private void anyPublicOperation() {}

@Pointcut("within(com.example.app.service..*)")
private void inService() {}

@Pointcut("anyPublicOperation() && inService()")
private void serviceOperation() {}

ウィービング（Weaving）

アスペクトがアプリケーションコードに統合するプロセスの事
コンパイル、クラスロード、実行時などのタイミングがある

ターゲット（Target）

アスペクトが適用されるオブジェクトまたはメソッドを指す

まとめ

モジュールを分割してdivide and conquerする
クラスの設計にはSOLIDの原則に従い設計する
クラスを綺麗に保つにはDIやAOPが効果的

参考文献

【Spring Boot + MyBatis】はじめてREST APIを作成してみる #初心者 - Qiita
MyBatisとは？使い方やSpringとの連携方法をサンプル付きで解説！ | プログラミングを学ぶならトレノキャンプ（TRAINOCAMP）
設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度- | オブジェクトの広場
ソフトウェアの複合/構造化設計
GRASPパターン
GoFデザインパターン
P of EAA
Applying UML and Patterns（実践UMLパターン）
【オブジェクト指向設計】GRASPの９つのパターンを分かりやすく解説 | ほわらぼIT大学
Declaring Pointcut Expressions with Examples - Dinesh on Java
Object Oriented Analysis and Design | TRUNGTQ.COM

AIサービスの推論APIのシステム設計の備忘録（DDD）

Thu, 14 Mar 2024 18:47:30 +0900

概要

FastAPIとPydanticでDDD likeなAIのシステム設計をした時の備忘録
Djangoや他のMVC-likeなFWとは違い、コアにはPydanticのみを使用した
サーバー構成は重い処理に対処するため非同期分散処理のアーキテクチャを採用した
その時の実装のメモ（特にDDD周り）を備忘録として残した
ADR（Architectural Decision Records）に近いWhyを残す

構成

処理内容

AIの推論処理は次のような特徴がある
- 重い処理
- 場合に応じてマシンにGPUが必要
- CPU/GPUやRAM/VRAMバウンディングな処理
- 実行時間が長い
- 並列実行数の制限が必要
そこで、推論処理は別サーバーに分離し非同期で行う事とした
また、個別の推論処理に合わせてマイクロサービスに分離した
- 理由は推論処理に合わせて、インスタンスタイプを最適化するため

DBの選定

DBは次の理由からPostgresを採用した。

垂直スケールアップ型で対応可能な負荷だったため
Pythonと相性のいいため
推論結果のリレーションが必要だったため
NoSQL程のパフォーマンスは必要なかったため

テーブル設計

テーブルは次のようなエンティティを定義した。

ユーザー（users）
画像データ（images）
分析結果（analysis）
推論結果（faces, quotes, etc..）

ID発番は将来的な分散処理を見越してUUIDv4を採用した。
NOTE: UUIDv3は別ホストで衝突する可能性がある。

アーキテクチャ

アーキテクチャには、プロデューサー / コンシューマーアーキテクチャを採用した。
マイクロサービスは20個ほど分離して処理毎に別インスタンスを用意した。

アクターは次になる。

Frontend Application
Producer Server（BFF）
Consumer Server（Batch）
Microservice Servers

大まかにフローは次のような流れである。

Frontend ApplicationからProducer Serverにリクエストを投げる
Producer ServerがJob Queue ServerにMessageをEnqueuする
Consumer ServerがそのMessageをDequeueする
Consumer ServerがMicroserviceの依存関係を解決して推論処理をMicroserviceにPostする
Consumer ServerがDBに結果を記録する
Producer ServerがDBの結果を取得する

プログラミング言語の選定

GoかPythonが候補にあったがPytonに決定
理由はAIサービスと相性がいいため
Go + gRPCもありだったがあくまで推論処理なのでPythonを選んだ
- 殆どのワークロードはAIの推論処理
  - その推論処理はONNXを使うだけ
- プログラミング言語の差は問題ではない
  - GPU, Memoryバウンディングの処理が多いため
- Goのようなcorutine（gorutine）で同時並行に処理する必要がなかった
- アーキテクチャで処理ごとに分散処理しているため
またgRPCのようにスキーマをmicroservice毎に定義せず、1つにまとめた

FWの選定

Pydanticを採用した
また、Web FWはPydanticと相性のよいFastAPIを採用
OpenAPIを利用してドキュメント化できるのが良かった
また、Web APIはNginxとそのローカルキャッシュを利用した
テストはpytestで行った

Manager-Workerでの通信規格の統一化

Microserviceの推論の結果としてMicroserviceRepresentationDTOに統一した
具体的には以下のようにPydanticでクラスを作り、それをベースにFastAPIのRequest型とした
- corutineで並列処理をする必要がないため、uvicornではなくgunicornなどのAPサーバーでも良かったのかもしれない
そしてそれぞれの規格でタグ付き共用体でLiteralを利用する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


from pydantic import BaseModel, EmailStr, Field, field_validator, root_validator, ValidationError
from typing import Optional, NewType, Any, TypeAlias, Literal, Union
from PIL import Image, JpegImagePlugin, PngImagePlugin
import base64
import io
import json
from enum import Enum
import numpy.typing as npt
import numpy as np

class XXXEntity(BaseModel):
 pass

class MicroserviceInferenceRepresentationDTOV1(BaseModel):
 version: Literal[1]
 xxx: list[XXXEntity]

class MicroserviceInferenceRepresentationDTOV2(BaseModel):
 version: Literal[2]
 xxx: list[XXXEntity]
 zzz: list[XXXEntity] | None = None

MicroserviceInferenceRepresentationDTO = MicroserviceInferenceRepresentationDTOV1 | MicroserviceInferenceRepresentationDTOV2


def parse_microservice_inference_representation(body: dict[str, Any]) -> MicroserviceInferenceRepresentationDTO:
 version = body.get("version", -1)
 if version == 1:
 return MicroserviceInferenceRepresentationDTOV1.parse_obj(body)
 elif version == 2:
 return MicroserviceInferenceRepresentationDTOV2.parse_obj(body)
 else:
 raise ValueError("Unsupported version provided")

# 使用例
body = {
 "version": 2,
 "xxx": [],
}

try:
 dto = parse_microservice_inference_representation(body)
 print(f"DTO parsed successfully: {type(dto)}")
except (ValidationError, ValueError) as e:
 print(f"Error parsing DTO: {e}")

モジュール化

機能・責務ごとに別pythoin packageに分けてモジュールとして分割統治する
DDDの流儀でまとめたビジネスロジックもそのモジュールの一つである
例えば、CVの共通処理はxxxpj-cvみたいな形である
それらをxxxpj/cv/ようにimplicit namespaceを置いて、別々モジュールも一つのnamespaceで一元管理する

非同期化

特に分析の処理は時間がかかるため、分析の受付と処理を分離した
その受付と処理の間をリトライとアクセス量の制御ができるように、メッセージキューで非同期にする
キューに入ったメッセージは複数のコンシューマーがハンドリングしてしまう可能性があるため、2つの対策をした
- 分析（analysis）のstatusを管理する事で排他処理を行っている
  - statusカラムとimage_id単位でのロックによって排他処理してステータスをIN_PROGRESSにしてから開始する
- 可視性タイムアウトは最大分析1.5倍の時間で取り、処理が成功してもその時間を超えたらrollbackする
  - SQSからの取得量は計算できるため、
- 分析用のいくつかのマイクロサービスとも接続する必要があるため、可視性タイムアウトは1.5倍の時間を取る

テーブル構造

1
2


images(id)
analysis(id, image_id, status)

分散システム

分散処理の通信パターン

上述のアーキテクチャ図からわかるように、今回は次の2つのパターンを採用した。

プロデューサー・コンシューマー

プロデューサ・コンシューマパターンは、プロセスの役割をデータを登録（生産）するものと処理（消費）するものに区別しているパターン
プロデューサーとコンシューマの間には仲介する有限のバッファで間接的に通信となり、両者間で非同期な通信をする
ほかの言い方だと、メッセージキュー（Message Queue）パターン
MessageはTaskとも呼ばれたりする

マスタ・ワーカー

マスタ・ワーカーパターンはマスタ・スレーブ（Master Slave）モデルとも呼ばれるパターン
1つのマスタがプログラムの実行を管理し、そのプログラム全体や一部の処理の実行をワーカーに割り当てる

通信パターンの比較

クライアント・サーバーパターンとマスタ・ワーカーパターンの違いは次。

クライアント : サーバー = N : 1
マスター : ワーカー = 1 : N

また、N:Nの通信は次の2つのパターンがある。

Hubパターン
- NodeはHubと通信するのでNodeの処理は楽になる
- ただし、Hubが単一障害点になる問題がある
P2Pパターン
- BitcoinなどのCryptoのClientのパターン
- 非中央集権でありスケーラビリティに優れている

分散トランザクション

トランザクションに関してはManagerのインスタンスでシングルトンのように一元的に状態を管理する
つまり、Managerからのみ、RDBにのみ対してAtomicな処理が走るので、分散トランザクションにはならない
そのため、TCCパターンとSagaパターンのような分散トランザクションのパターンの適用は不要だった

DDD関連

ドメイン

ドメインの目的とは何か？

ドメインとはビジネスモデルをカプセル化したもの
OOPでアクセッサーを経由してフィールドにアクセスするように、ビジネスモデルを独立するのが狙い
その実態なドメインのモデル（エンティティ＋値オブジェクト）やサービス（ドメインサービス）である
エンティティはドメイン層の中で、JavaのPOJOのような基本的にどこにも依存しない作りにする
DDDの思想としてビジネスロジックをFWから独立させるのが目的
- 例えば、RailsのModelにビジネスロジックを書き込むと、そのFWが終了した時に直せなくなる
- つまり、FWよりビジネスモデルの方がライフサイクルが長いので、ビジネスモデルをFWから切り離した構造になっている
故にデータを取得するのはRepository層が行い、データはエンティティとし、ドメインサービスでビジネスロジックを実行する

他のアーキテクチャとの比較

コアにあるのはビジネスモデルをFWに依存させない事
故に、DDDでもクリーンアーキテクチャでもオニオンアーキテクチャでもドメインがコアにある

エンティティと値オブジェクト

エンティティ vs. 値オブジェクト

エンティティ
- 値オブジェクトを複数もつストラクト（社員、記事、商品など）
値オブジェクト
- ストラクトの中の要素（名前、誕生日、体重など）

エンティティ

識別
- IDの識別子を持つ
- IDによる等価性
フィールド
- フィールド名は自由
- フィールドの値の更新はできる
  - ただし、値オブジェクトのフィールドの場合は、その値オブジェクトを再生成して詰める
例
- ユーザー、注文、製品など識別する必要があるもの

値オブジェクト

識別
- IDの識別子を持たない
- 値による等価性
フィールド
- フィールドの値
  - イミュータブル
  - 更新はできない
- valueのフィールドを持つ
- 作成時にバリデーションが走る
例
- 住所、金額、日付範囲などの識別する必要がない値

モデルとは

DDDの定義だとモデルは大まかに次の関係にある。

$$ モデル = エンティティ + 値オブジェクト $$

ドメインイベントとドメインサービス

ドメインサービス (Domain Service)

ドメインサービスは、エンティティや値オブジェクトに自然に属さないビジネスロジックをカプセル化するために使用されるサービス
具体的にはInputとOutputのDTOと、各種リポジトリを引数に撮り、ビジネスロジックを実行する
ドメインサービスは、ドメインモデルの一部であり、アプリケーションのビジネスルールやビジネスプロセスの事

ドメインイベント (Domain Event)

ドメインイベントは、システム内で発生した重要なビジネスイベントや状態の変化を表すオブジェクト
「注文が完了した（OrderCompleted）」や「顧客が登録された（CustomerRegistered）」など
ドメインイベントは、その情報をシステムの他の部分に伝えるために使用されるDTO的なもの

DDDのレイヤーの名前の違い

層は次のような物がDDDやクリーンアーキテクチャでは利用される。

プレゼンテーション層
アプリケーション / ユースケース層
ドメイン層
インフラストラクチャ層

PoEAAでの鉄板

DAO vs. DTO

DAO（Data Access Object）
- データベースやその他の永続化メカニズムへのアクセスを抽象化し、データアクセスロジックをカプセル化する事が目的
- 故にメソッドはCRUD関連のメソッドなどになる
DTO（Data Transfer Object）
- 異なるソフトウェアの層やシステム間でデータを転送するためのコンテナ
- ネットワーク越しにデータを効率的に送受信するため、または異なる層間でのデータの受け渡しを簡素化するために使用される

DTO vs. エンティティ

一言で言うと、DTOはデータを移動差せる為のオブジェクト
他方、DDDのEntityはビジネスのモデルの写像
故に、レイヤー間をまたいで一時的に利用する用途の場合はDTOを使う
他方、ビジネスモデルを表現したドメインエンティティなどはエンティティを使う
あくまで、DTOはコンテナにすぎない

アグリゲート

アグリゲートとは

アグリゲート（Aggregate）は一貫性と整合性を維持するために一緒に管理されるべきエンティティと値オブジェクトのクラスター
簡単に言うと、RDBでいう値オブジェクトがカラム、エンティティがテーブルに対応するとき、アグリゲートはRDBでいうデータベースに対応する
DBでも複数のテーブルで不整合がないように外部キー制約をかけるが、アグリゲートでもそれに近いことを行う

ルートエンティティ

アグリゲートはエンティティの集合だがアクセスポイントとしてルートエンティティを持つ
アグリゲートの一貫性を保証するためのビジネスルールを強制する
RDBのようにグラフ構造ではないので、DDDでのアグリゲートはクラスター構造となる
故にアクセスポイントが必要となる

具体的な例

ドメインエンティティと値オブジェクトの例

前提

下はCustomerAnalysisのDomain Entityの例
DBにはCustomer、User、UserProfileテーブルなどがある
それらをドメインオブジェクト化したものが以下のEntity
python 3.10を使用
画像解析も実際には下のような形でビジネスモデルを定義した

例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


from pydantic import BaseModel, EmailStr, Field, field_validator, model_validator
from typing import Optional, NewType, Any, TypeAlias
from PIL import Image, JpegImagePlugin, PngImagePlugin
import base64
import io
import json
from enum import Enum
import numpy.typing as npt
import numpy as np

UserId = NewType('UserId', int)
CustomerAnalysisId = NewType('CustomerAnalysisId', int)

ImageNp: TypeAlias = npt.NDArray[np.uint8]
ImagePil: TypeAlias = Image.Image

class ImageUtil:
 @staticmethod
 def base64_to_image(base64_str: str):
 image_data = base64.b64decode(base64_str)
 image = Image.open(io.BytesIO(image_data))
 return image

 @staticmethod
 def image_to_byte_array(image: ImagePil):
 img_byte_arr = io.BytesIO()
 image_format = 'JPEG' if isinstance(image, JpegImagePlugin.JpegImageFile) else 'PNG'
 image.save(img_byte_arr, format=image_format)
 return img_byte_arr.getvalue()

 @classmethod
 def image_to_base64_str(cls, image: ImagePil):
 return base64.b64encode(cls.image_to_byte_array(image)).decode('utf-8')


class MyBaseModel(BaseModel):
 class Config:
 # デフォルトでは、Pydanticは標準のデータ型しか型が使えないため
 # 例えば、int、str、float、list、dict など）およびPydanticモデルのインスタンス
 arbitrary_types_allowed = True

class UserProfileCategory(str,Enum):
 STANDARD = "standard"
 ADMIN = "admin"
 GUEST = "guest"

class UsernameValue(BaseModel):
 value: str

 @field_validator('value')
 def validate_username(cls, v):
 if not v.isalnum() or len(v) < 3:
 raise ValueError('Username must be at least 3 characters long and contain only alphanumeric characters')
 return v

class EmailValue(BaseModel):
 value: EmailStr

class ProfileImageValue(MyBaseModel):
 value: ImagePil
 mime_type: str

 class Config:
 json_encoders = {
 ImagePil: ImageUtil.image_to_base64_str,
 }

class CustomerAnalysisEntity(BaseModel):
 id: CustomerAnalysisId
 user_id: UserId
 username: UsernameValue | None = None
 email: EmailValue | None = None
 profile_image: ProfileImageValue | None = None
 user_type: UserProfileCategory

 @model_validator(mode="after")
 def validate_root(cls, values):
 if not (values.username or values.email):
 raise ValueError('Either username or email must be provided.')
 return values

 def to_json(self):
 return self.json(exclude_none=True)

 def to_dict(self):
 return self.dict(exclude={})

 @classmethod
 def from_dict(cls, data: dict[str, Any]):
 if 'profile_image' in data and data['profile_image'] is not None and 'value' in data['profile_image']:
 base64_str = data['profile_image']['value']
 image = ImageUtil.base64_to_image(base64_str)
 data['profile_image']['value'] = image
 return cls(**data)

 @classmethod
 def from_json(cls, data: str):
 json_data = json.loads(data) # str -> dict
 return cls.from_dict(json_data)

次のように使用する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


class Test:
 img_path = 'image.png'
 @classmethod
 def to_json(cls):
 img = Image.open(cls.img_path)
 customer_analysis = CustomerAnalysisEntity(
 id=CustomerAnalysisId(111),
 user_id=UserId(12345),
 username=UsernameValue(value="JohnDoe"),
 email=EmailValue(value="johndoe@example.com"),
 profile_image=ProfileImageValue(
 value=img,
 mime_type="image/jpeg"
 ),
 user_type=UserProfileCategory.STANDARD
 )

 user_profile_json = customer_analysis.json()
 file_path = 'customer_analysis.json'
 with open(file_path, 'w') as file:
 file.write(user_profile_json)

 @staticmethod
 def from_json():
 file_path = 'customer_analysis.json'
 with open(file_path, 'r') as file:
 user_profile_json = file.read()
 customer_analysis = CustomerAnalysisEntity.from_json(user_profile_json)
 print(customer_analysis)

 @staticmethod
 def to_dict():
 file_path = 'customer_analysis.json'
 with open(file_path, 'r') as file:
 user_profile_json = file.read()
 customer_analysis = CustomerAnalysisEntity.from_json(user_profile_json)
 user_json = customer_analysis.to_dict()
 print(user_json)

 @staticmethod
 def from_dict():
 user_profile_dict = {
 "id": 111,
 "user_id": 12345,
 "username": {"value": "JohnDoe"},
 "email": {"value": "johndoe@example.com"},
 "profile_image": None,
 "user_type": "standard"
 }
 customer_analysis = CustomerAnalysisEntity.from_dict(user_profile_dict)
 print(customer_analysis)



if __name__ == "__main__":
 Test.to_json()
 Test.to_dict()
 Test.from_json()
 Test.from_dict()

ドメインサービスの例

前提

エンティティ

エンティティはドメインオブジェクトなので、基本的にどこにも依存しない作りにする
DDDの思想としてビジネスロジックをFWから独立させるのが目的
- 例えば、MVCのようなFWの、Modelにビジネスロジックを書き込むとMVCのFWが終了した時に直せなくなる
そこで。ビジネスモデルはドメイン層としてFWから分離したのがDDDの思想

リポジトリ

インフラ層で定義するデータアクセッサー
実装はドメイン層のrepository_interfaceを参照する
ドメインサービスの入力となる
リポジトリ層の戻り値はエンティティになる

サービス

DDDのサービスはいわゆるドメインサービスの事
ドメインサービスでは少し特殊な形で用意する
具体的には、Repositoryに依存しないようにRepositoryを引数にとる関数となる
- ただし、型定義の際にRepositoryをImportするとRespository層に依存してしまうため、あくまでDomain層のRepository Interfaceを型にする
また、入力と出力が煩雑になるため、InputDTOとOutputDTOを用意する
入力とシンプルにリポジトリとInput（DTO）を利用して実装された関数
具体的には外部のリポジトリを利用するが、ドメインサービスがリポジトリに依存しないようにIFとして型をとる
内部では、引数で渡った関数の入力とリポジトリーから取得したドメインエンティティを元に処理を行う
サービスは基本的にビジネスロジックなのでビジネスロジックの言葉で書くのが正しい
例えばデータを保存するドメインサービスなどでは、トランザクションなどはドメインサービスを呼び出す側が処理するのが正しい

具体例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


class XXXInputDTO(BaseModel):
 aaa: str
 bbb: str

class XXXOutputDTO(BaseModel):
 xxx: str
 yyy: str

def domain_subdomain1_xxx_serveice(
 xxx_input_dto: XXXInputDTO,
 xxx_repo: IXXRepository,
 yyy_repo: IyyyRepository
) -> XXXOutputDTO:
 pass

DDDのLibのフォルダ設計例

前提

AWSのCodeartifactを利用し、共通ライブラリをpython packageに分離した
マイクロサービスで共通して使うため、libとして各サービスでimportするようにした
便宜上形式的に__init__.pyは省略している

実例

フォルダの構成の具体例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


$ tree -L 3
└── common
 ├── models
 │ ├── representation_dto.py
└── domain
 ├── subdomain1
 │ ├── model
 │ │ ├── entity.py
 │ │ ├── value_object.py
 │ ├── service.py
 │ ├── repository_interface.py
 ├── subdomain2
 │ ├── model
 │ │ ├── entity.py
 │ │ ├── value_object.py
 │ ├── service.py
 │ ├── repository_interface.py
└── application
 ├── use_cases
 │ ├── subdomain1_use_case.py
 │ ├── subdomain2_use_case.py
└── infrastructure
 ├── repository
 │ ├── subdomain1_repository_impl.py
 │ ├── subdomain2_repository_impl.py
 │ ├── dao
 │ │ ├── xxx_dao.py
 ├── external_services
 │ ├── xxx_service_adapter.py
 ├── database
 │ ├── orm_models.py
 │ ├── database_accessor.py
└── presentation
 ├── web
 │ ├── controllers
 │ ├── views
 │ ├── viewmodels
 ├── api
 │ ├── controllers
 │ ├── dtos

DDDのUsecaseの利用例

使い方は次のように使う。

1
2
3
4
5
6
7
8
9


# app/use_cases/subdomain1_use_case.py
from domain.subdomain1.service import SomeDomainService
from infrastructure.repository.subdomain1_repository_impl import Subdomain1RepositoryImpl

def execute_some_use_case():
 repository = Subdomain1RepositoryImpl()
 domain_service = SomeDomainService(repository)
 result = domain_service.perform_some_operation()
 return result

usecase層では引数に撮らないが、ドメインサービスは独立するために、repositoryやinputなどを入力としてとるのがキモである
なぜなら、ドメイン層はコアであり、他の層に依存してはいけないから

名前空間の設計例

前提

複数のlibの外部パッケージに分割し、共通の名前空間を利用した
具体的には、pythonのImplicit Namespace Packages機能を利用した
pythonはフォルダに__init__.pyを設置する必要がある
それを設置しないフォルダは、packageとして読み込めない
ただし、__init__.pyを設置すると、そのフォルダの初期化がかかってしまう
故に複数のライブラリ、aaa_libとbbb_libがあったとき共通のフォルダに__init__.pyを置くと先勝ちしてしまう
例
- xxx_pj/aaa_lib/main.pyとxxx_pj/bbb_lib/main.pyがあるとする
- これらは別々のpythonのpackageであり、それぞれpip install aaa_lib bbb_libとしてインストールする
- 両方の共通フォルダであるxxx_pjには__init__.pyが設置してある
- 故に、import aaa_libをすると、bbb_libは読み込めなくなってしまう
- なぜなら、すでにimport aaa_libでxxx_pj/__init__.pyが初期化されるから
- つまり、同じパッケージ名のものがあった場合は、先勝ちになってしまう
そこで、xxx_pjはimplicit namespace packageとして、xxx_pj/__init__.pyを置かず、pj全体の共通の名前空間を利用する
すると、import aaa_libとimport bbb_libが問題なく行えるようになる
これは開発時のIDEの補完にもxxx_pjから複数の別々のライブラリを読み込めるので、dx（dev experience）にも効果的である

具体例

下のように、共通するnamespaceには__init__.pyをおかないようにしている。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$ cd aaa_lib
$ tree -L 3
└── xxx_pj
 ├── aaa_lib
 │ ├── __init__.py
 │ ├── main.py

$ cd bbb_lib
$ tree -L 3
└── xxx_pj
 ├── bbb_lib
 │ ├── __init__.py
 │ ├── model
 │ │ ├── __init__.py
 │ │ ├── main.py

結論

上記の通り、DDDでAIの解析システムを作るのは、以外と考える事が多い
他にもPrecommit、Lint、pytest、Dockernize、FastAPIのエラーの共通化やら色々なトピックがある
ただ、少なくとも、プロダクトのライフサイクルに合わせて、ソフトウェア設計を見極めるべき
- ライフサイクルが短い => MVCでサクッと作る
- ライフサイクルが長い => DDDで重厚に作る
特に、必要最低限、疎結合かつDRYかつKISSに作るには一貫した設計が必要

参考文献

ソフトウェアに関連する色々な格言や法則

Mon, 29 Jan 2024 16:26:58 +0900

概要

はてブロでソフトウェア開発者が知るべき10の法則といういい記事があったのでそれの転載
他にも名前の知っている法則はGPTに手伝ってもらって書いた

法則や格言

コンウェイの法則（Conway’s Law）

メルヴィン・コンウェイが提唱した法則で、「システムの設計は、それを設計する組織のコミュニケーション構造を反映する」というもの
つまり、組織内のコミュニケーションの仕方が、その組織が作り出す製品やサービスの設計に影響を与えるという考え方

パレートの法則（Pareto Principle） / 80-10-10の法則

ヴィルフレド・パレートによって提唱された法則で、「全体の結果の80%は全体の原因の20%によって生じる」というもの
この法則はビジネス、経済学、品質管理など様々な分野で応用されている

グッドハートの法則（Goodhart’s Law）

チャールズ・グッドハートによって提唱された法則で、「指標として利用されると、その指標は効果を失う」というもの
つまり、ある指標が目標達成のために使われると、その指標自体の意味が失われるという考え方

パーキンソンの法則（Parkinson’s Law）

サイリル・ノースコート・パーキンソンによって提唱された法則で、「仕事は与えられた時間いっぱいに広がる」というもの
つまり、時間が多く与えられると、仕事が不必要に複雑化し、時間がかかるようになるという考え方

ブルックスの法則（Brooks’s Law）

フレデリック・ブルックスによる法則で、ソフトウェアプロジェクト管理において、「遅れているプロジェクトに人員を追加すると、さらに遅れる」というもの
これは、新しい人員の教育やコミュニケーションの負担が増加するため

リトルの法則（Little’s Law）

ジョン・リトルによって提案された法則で、待ち行列理論において、「長期的に見た場合、システム内の平均在庫数は入力率と在庫滞在時間の積に等しい」というもの
これは物流や製造業で重要な考え方

ピーターの法則（Peter Principle）

ローレンス・J・ピーターによる法則で、「組織内では、従業員は自身の無能力のレベルまで昇進する」というもの
つまり、能力があると認められた従業員は昇進し続け、最終的には自分の能力を超えるポジションに就くことになるという考え方

ハインリッヒの法則（Heinrich’s Law）

H.W.ハインリッヒが提唱した、安全管理に関する法則で、「1つの重大な事故に対して、29の軽微な事故と300のノンインシデント（事故に至らないが危険な状況）が存在する」というもの
この法則は、事故予防において、小さな事故や異常に注目することの重要性を示している

ピーク・エンドの法則（Peak-End Rule）

ダニエル・カーネマンによって提唱された心理学の法則で、「人々は経験を、その最も強い感情があったピーク時と終わりの感情で評価する」というもの
つまり、長い経験の全体よりも、特定の瞬間の印象が記憶に残るという考え方

ホフスタッターの法則（Hofstadter’s Law）

ダグラス・ホフスタッターが提唱した法則で、「物事は予想よりも時間がかかる、たとえその予想にホフスタッターの法則を適用していたとしても」というもの
これは、特にプロジェクトの計画や時間管理において、予測が困難であることを示している

メトカーフの法則（Metcalfe’s Law）

ロバート・メトカーフが提唱した法則で、通信ネットワークの価値は、ネットワークに接続されているユーザーの数の二乗に比例するというもの
特にインターネットやソーシャルネットワークの成長と関連している

ムラフィーの法則（Murphy’s Law）

「何か悪いことが起こりうる状況があれば、いつか必ず起こる」という俗説
特に工学やプロジェクト管理において、リスク管理の重要性を示唆している

ダニング＝クルーガー効果（Dunning-Kruger Effect）

低い能力を持つ人ほど自分の能力を過大評価し、高い能力を持つ人は自分の能力を過小評価する傾向があるという心理学の現象

オッカムの剃刀（Occam’s Razor）

複数の仮説がある場合、最も単純な説明が最も可能性が高いという原則
14世紀の哲学者ウィリアム・オッカムにちなんで名付けられた

ジェヴォンズの逆説（Jevons Paradox）

リソースの効率的な利用がそのリソースの消費量を増加させるという経済学の原則
1865年にウィリアム・スタンレー・ジェヴォンズによって提唱された
資源効率を高めてもエネルギー消費量が増えるという逆説

クレイトンの破壊的イノベーション理論（Christensen’s Theory of Disruptive Innovation）

破壊的イノベーションは市場に革命をもたらし、既存の大企業を脅かす新しい技術やビジネスモデルを指す
クレイトン・クリステンセンによって提唱された

ベンフォードの法則（Benford’s Law）

自然発生的なデータセットにおいて、小さい数字（特に「1」）が最初の数字として現れる確率が高いという法則

割れた窓の法則（Broken Windows Theory）

犯罪学の理論で、小さな犯罪や秩序の乱れ（例えば割れた窓）が放置されると、より大きな犯罪や社会の荒廃につながる可能性があるというもの
ジェームズ・Q・ウィルソンとジョージ・L・ケリングによって提唱された

コンウェイの法則（Conway’s Law）

ソフトウェア開発において、システム設計はその設計を行う組織のコミュニケーション構造を反映するという法則
メルヴィン・コンウェイが提唱

エントロピーの法則（Law of Entropy）

物理学の第二法則に基づく概念で、閉じた系ではエントロピー（無秩序さ）が時間とともに増加するというもの
これは物理学だけでなく、経済学や情報理論にも応用されている

ジョシュアツリーの法則（Joshua Tree Principle）

ソフトウェア開発において、初期のアーキテクチャの決定がプロジェクトの将来の方向性と複雑さに大きな影響を与えるという概念
ジョシュアツリーの成長パターンに例えられている

セカンドシステム症候群（Second-system Effect）

エンジニアが初めて成功したシステムに続いて設計する二番目のシステムが、過剰に複雑で非効率になる傾向にあるという現象
フレデリック・P・ブルックスが『人月の神話』で記述

車輪の再発明（Reinventing the Wheel）

既に存在する方法やツールを知らずに、同じものを新たに作成すること
しばしば無駄な労力と見なされるが、学習過程や改善には価値がある場合もある

ヤクの毛刈り（Yak Shaving）

本来の目標から逸れ、関連しない多くの小さなタスクに引き込まれてしまう現象
この言葉は、ソフトウェア開発やプロジェクト管理で使われ、予期せぬ問題に対処する過程で目的を見失うことを示している

YAGNI（You Ain’t Gonna Need It）

ソフトウェア開発における原則で、「現時点で必要ではない機能は実装しない」という考え方
この原則は、開発の複雑さを減らし、不必要な作業を避けることを目的としている

ドライ原則（DRY - Don’t Repeat Yourself）

ソフトウェア開発において、同じ情報やコードを重複させないことを推奨する原則
この原則に従うことで、メンテナンスが容易になり、エラーのリスクを減少させることができる

KISS原則（Keep It Simple, Stupid）

設計をシンプルに保つことを奨励する原則
不必要に複雑な設計は、エラーや問題の原因になる可能性があるため、シンプルさを保つことが重要

ビッグデザインアップフロント（BDUF - Big Design Up Front）

プロジェクト開始前に詳細な設計を行うアプローチ
この方法は、計画性と予測可能性を重視しするが、柔軟性の欠如や変更への対応の遅さが批判されることもある

早まった一般化（Premature Generalization）

ソフトウェア開発やデータ分析の分野でしばしば言及される概念
これは、不十分な情報や経験に基づいて、広範な結論や決定を下すことを指す

オープン-クローズドプリンシプル（Open-Closed Principle）

ソフトウェアのエンティティ（クラス、モジュール、関数など）は拡張に対してオープンであるべきだが、変更に対しては閉じているべきであるという原則
つまり、既存のコードを変更せずに新しい機能を追加できるように設計すること

堅牢性の原則（Principle of Robustness）

シンプルでクリアな設計を心掛けることで、予期せぬ状況にも強い、堅牢なシステムを作るという原則

最小電力のルール（Rule of Least Power）

効率的なソフトウェア開発において、必要最小限の能力（電力）を持つ解決策を選ぶべきであるという考え方

Unix哲学

シンプルで小さなプログラムを書き、それらを組み合わせて大きなタスクを達成するという考え方
プログラムは一つのことをうまく行うべきで、ユーザーに強力な組み合わせ能力を提供すべき

悪い方が良い（Worse is Better）

ソフトウェア設計において、完璧よりも実用的でシンプルな解決策を優先する考え方
これはNJの哲学の事
c言語が買って、LISPが負けた事もこれに起因する

MITの哲学 vs. NJの哲学

MITの哲学は"the right thing"
NJの哲学は"Worse is Better"
MIT哲学の優先順位
- Correctness = Consistency > Completeness > Simplicity (Interface) > Simplicity (Implementation)
NJの哲学の優先順位
- Simplicity (Implementation) > Simplicity (Interface) > Correctness > Completeness > Consistency

SOLID（オブジェクト指向設計）

ソフトウェア設計のための5つの原則のセット

次の5つを含む。

単一責任の原則
オープン/クローズドの原則
リスコフの置換原則
インターフェース分離の原則
依存性逆転の原則

信頼できる唯一の情報源（SSOT, Single Source of Truth）

ある種の情報について、その情報の正確で最新のバージョンを保持するためのシステムやプラクティスを指す
この原則に従うことで、データの一貫性、正確性、信頼性が保たれ、データの重複や不一致を防ぐことができる

単一真実のバージョン（Single Version of the Truth, SVOT）

組織内の情報やデータに関して、その情報の一貫性と正確性を保証するためのアプローチ
SVOTは、特定のデータに関して、その最も信頼できる、正確な、そして常に最新のバージョンが一箇所に存在し、
全ての関連するプロセスや意思決定がこのバージョンを基に行われるべきであるという考え方を指す

Nocode

信頼できるプログラムを作る方法は、プログラムを書かない事という哲学
Dockerfileでfrom scratchだけ書いたリポジトリでそれを示した

自分

ワンパスを通す

システムで枝葉に拘らずに細くてもいいので一度全体を作り上げる法則
最低限の機能をざっくり作ってMVPを狙うと行ってもいいかもしれない

テストは依存性が無い所からテストする

MVCのアプリケーションでテストを書く時は依存性が少ないところから書く
すなわち、Modelから書くべし
そうでないと、Controllerから書くとModelのテストの後にまたテストの修正をする二度手間になるから

QCDのうち一番大切なのはCとD

アプリも命（ライフサイクル）がある。なので、アプリがビジネスとして役立って長生きする可能性もある
しかし、その逆の可能性もある
故に、正直、お金がなくなったらプロジェクトやアプリは終わる
ゆえに、QCDのうち、CとDが最も大切
特に速度、速度がないなら意味がない。変なアプリに3か月も待ってられない
実行速度はビジネスとしての仮説が検証されてお金を生み出すものと分かってからリファクタやリプレイスしてもいい
とにかくDevSpeed。じゃないと作ってもゴミとなる

テストリポジトリで試す

本当にわけが分からないときはテストリポジトリを作る
条件を削って最低限度でテストしてみる
めんどくさいが、これが一番確実

一行はemacs、複数行はvimバインドを使う

emacsバインド、ctrl-a,e,k,uで操作できるので早い
複数行はvimバインドが速い

先に理解してから開発する

理解すれば作れる
逆に理解していないと作れない
なので作る前に必ず理解する

技術調査でいい数字が出ない時の対処

使い方を変える
- シンプルに現状の使い方、課題では使えないが、別の使い方を考える
- 例えばある別の課題を解くための特徴を生成するための機能として使うなどという感じ
部分適用する
- 全体に適用はできなくても、部分適用ではいい数字を出す場合がある
- シンプソンのパラドックスパターン
- 例えば、全体では70%、これは使えない
- でも部分では、前提を絞ったら90%これは使えるなどという感じ
前提を変える
- 元々の数字がおかしいパターン

機械学習では80点を絶対狙う

30点をたたき出したら死刑宣告と同じ
データの範囲を変えたり、指標を変えて80点を狙う
それ以外は、異民族に蹂躙される
80点ならその後に90点を出されてもメンタルが持つ
30点から80点をだされたらメンタルブレイクする
これは機械学習のスコア以外にもなんでも当てはまる
基本的にRecall -> Precisionと進む

見積もりと実際は大体3倍の差がある

不確実性のコーンから
見積から2倍から3倍の工数がかかる

まとめ

まあ色々な法則があるし、他にも設計系の格言や法則は色々あるだろう
ただし、経験上、あくまでこれらはrecommendationのレベル
これらは経験則的なもので、first principleとまではいかない
適材適所でこれをベースに演繹して考えるのがいい気がする