Open6
ソフトウェアアーキテクチャハードパーツ
kkitadate6章 業務データの分解
6.1 データ分解の推進要因
6.1.1 データ分解要因
6.1.2 データ統合要因
6.1.3 Sysops Squadサーガ：データベース分解の根拠
6.2 モノリシックなデータを分解する
- モノリシックデータベースを分解する5段階プロセス
- データベースをサッカーボールに見立てる
- 六角形のデータベースオブジェクトはデータドメインに属する
- データドメインを抽出する際には、ドメイン間の依存関係（データベースアーティファクト）を削除する必要がある
- 例えば、とあるサービスから顧客テーブルへの参照を削除した場合、顧客サービスを呼び出して顧客名などのデータを取得しなければならない
6.2.1 ステップ1：データベースを分析し、データドメインを特定する
6.2.2 ステップ2：テーブルをデータドメインに割り当てる
6.2.3 ステップ3：データベースコネクションをデータドメインごとに分離する
6.2.4 ステップ4：スキーマを別個のデータベースサーバーに移動する
6.2.5 ステップ5：個別のデータベースサーバーへコネクション先を切り替える
6.3 データベース種別を選択する
6.3.1 リレーショナルデータベース
6.3.2 キーバリューデータベース
6.3.3 ドキュメントデータベース
6.3.4 列指向データベース
6.3.5 グラフデータベース
6.3.6 NewSQLデータベース
6.3.7 クラウドネイティブデータベース
6.3.8 時系列データベース
6.4 Sysops Squadサーガ：ポリグロットデータベース
kkitadate7章 サービスの粒度
「サービスの粒度を正しく把握するには、意見や直感を排除し、粒度分解要因と粒度統合要因を使ってトレードオフを客観的に分析し、サービスを分割するかどうかの確固たる根拠を形成することが重要」 by ローガン
- モジュール性: システムを個別のパーツに分解すること
- 粒度: その個別のパーツの大きさ
- 分散システムにおける問題や課題の多くは、モジュール性ではなく、粒度に関連している
- 多くの開発チームは、粒度分解要因に注力しすぎて、粒度統合要因を無視してしまう
7.1 粒度分解要因
- どのような場合にサービスを分解することを検討すべきか
7.1.1 サービスの範囲と機能
- 2つの側面を考慮する必要がある
- 凝集度: 特定のサービスの操作が相互に関連する度合いと方法
- コンポーネントのサイズ: サービスを構成するクラスから合計された総ステートメント数、サービスへの公開エントリーポイント数、またはその両方
- 「単一の目的」のサービスにしたいという理由では、分割の根拠として十分ではない
- 「単一の目的」かどうかは個々人の意見や解釈に委ねられている
- 凝集度の観点
- 比較的強い凝集のあるサービスは、機能だけに基づいて分解するのには向いていない
- 凝集度が比較的低いサービスは分解に適している
- マイクロサービスの定義：「単一の目的を持ち、個別にデプロイされる、1つのことをうまくこなすソフトウェアの単位」
- 開発者は、なぜそうするのかを考えずに、サービスをできるだけ小さくしたいと考えてしまう
- 何が単一の責任であり、何が単一の責任でないのかという主観的な問題
7.1.2 コード変動率
- ソースコードの変更の度合い
7.1.3 スケーラビリティとスループット
7.1.4 耐障害性
- 致命的なクラッシュ（メモリ不足など）が発生しても、アプリケーションや特定のドメイン内の機能が動作を継続できる能力
- サービスを分解する際には "「残った」機能が強い凝集度を保っているか" を確認する
7.1.5 セキュリティ
- 機密データのセキュリティを確保する際によくある落とし穴：データの保存方法だけを考えてしまう
- たとえば、PCIデータを非PCIデータから分離するには
- スキーマやデータベースを別の安全な領域に配置すると良い
- しかし、この方法では、データにアクセスする方法の安全性が確保されないことがある
- このような場合は、サービス自体を分けることで "単一目的のサービスからのみ" のアクセスに限定する
7.1.6 拡張性
- サービスに新たなコンテキストが加わるのに合わせて、機能を追加していける能力
- 計画された拡張性は良い分解要因となる
- ただし、以下の場合にのみ適用するのをおすすめする
- ビジネス機能にコンテキストを追加していくことが予定・要望されている
- ドメインとして通常のことであると事前に分かっている
- パターンが確立されるか、継続的な拡張性が確認されるまでは、この要因を粒度分解の第一の根拠として用いるのは控えた方がよい
7.2 粒度統合要因
- どのような場合にサービスをまとめることを検討すべきか
7.2.1 データベーストランザクション
7.2.2 ワークフローとコレオグラフィ
7.2.3 共有コード
7.2.4 データ関係
7.3 適切なバランスを見極める
7.4 Sysops Squadサーガ：チケット割り当ての粒度
7.5 Sysops Squadサーガ：顧客登録の粒度
kkitadate8章 再利用パターン
- “多くのモノリシックアーキテクチャでは、コードの再利用方法について考えるべきことはほとんどない”
- “Write every time or Write everything twice”
8.1 コードレプリケーション
- 共有コードを各サービスにコピーすることで、コード共有を完全に回避する手法
- バグが見つかったり、重要な変更が必要になったりした場合
- レプリケートされたコードを含んでいるすべてのサービスを更新する必要がある
- 非常に困難で時間がかかる
- ほとんど変更のない一度書かれたらそれっきりのコードの場合
- 静的でバグを含まない（将来的にも含まれない可能性が高い）
- コードレプリケーションに適している
8.1.1 使いどころ
- “一度書かれたらそれっきりのクラスであったり、不具合や機能変更のために変更される可能性が低いコードであったりする、単純な静的コード（アノテーション、属性、単純な共通ユーティリティなど）がある場合に適したアプローチ”
- 他のコード再利用の選択肢を検討するのがよい
8.2 共有ライブラリ
8.2.1 依存関係の管理と変更の制御
8.2.2 バージョニング戦略
8.2.3 使いどころ
8.3 共有サービス
8.3.1 変更リスク
8.3.2 パフォーマンス
8.3.3 スケーラビリティ
8.3.4 耐障害性
8.3.5 使いどころ
8.4 サイドカーとサービスメッシュ
8.4.1 使いどころ
8.5 Sysops Squadサーガ：共通基盤ロジック
8.6 コードの再利用：どのようなときに価値が生まれるか？
8.6.1 プラットフォームによる再利用
8.7 Sysops Squadサーガ：共有ドメイン機能
kkitadate9章 データの所有権と分散トランザクション
9.1 データの所有権を割り当てる
9.2 単独所有シナリオ
9.3 全体共有シナリオ
9.4 共同所有シナリオ
9.4.1 テーブルの分割
9.4.2 データドメイン
9.4.3 委譲
9.5 サービスコンソリデーション
9.6 データ所有権のまとめ
9.7 分散トランザクション
9.8 結果整合性パターン
9.8.1 バックグラウンド同期パターン
9.8.2 リクエストベースのオーケストレーションパターン
9.8.3 イベントベースパターン
9.9 Sysops Squadサーガ：チケット処理のデータ所有権
kkitadate10章 分散データアクセス
- “所有しなくなったデータにアクセスするための別のソリューション”
10.1 サービス間通信パターン
- メリット
- シンプルさ
- データ量の課題がない
- デメリット
- レイテンシ（パフォーマンス）の問題
- スケーラビリティとスループットの問題
- 耐障害性がない
- サービス間のコントラクトが必要
10.2 列スキーマレプリケーションパターン
- メリット
- データアクセス性能が高い
- スケーラビリティとスループットの問題がない
- 耐障害性の問題がない
- サービスへの依存がない
- デメリット
- データ整合性の問題
- データ所有権の問題
- データの同期が必要
10.3 レプリケーションキャッシュパターン
- メリット
- データアクセス性能が高い
- スケーラビリティとスループットの問題がない
- 優れた耐障害性
- データ整合性が支持される
- データの所有権が保たれる
- デメリット
- “キャッシュデータと起動タイミングに関するサービス依存関係”
- “データ量”（大容量のデータには向かない）
- “データを変更する頻度（更新頻度）が多すぎる場合”に向かない
- ”構成や設定の管理”が煩雑（クラウドやコンテナでの設定が難しい）
10.4 データドメインパターン
- メリット
- データアクセス性能が高い
- スケーラビリティとスループットの問題がない
- 耐障害性の問題がない
- サービスへの依存がない
- デメリット
- “より広い範囲の境界づけられたコンテキストが形成され”てしまう
- “データアクセスに関するセキュリティリスク”
- “厳格な境界づけられたコンテキスト”（“データ所有権の統制”）が必要