はてなリモートインターンシップ2023 ソフトウェアアーキテクチャ講義資料

by Hatena

Slide 1

Slide 1 text

ιϑτ΢ΣΞΞʔΩςΫνϟ #hatenaintern)*)+ !

Slide 2

Slide 2 text

アーキテクチャとは • 構造? • ソフトウェアに物質的な構造はそもそもなくない? !

Slide 3

Slide 3 text

建築の場合: 構造設計 • そもそも建つために必要 • 物理的に⽴たないものは建たない • 施⼯性の確保 • 安全のため • 建てたあと倒壊したら困る • 法令等で基準が定められている • コストのため • やり直しは⼤変 !

Slide 4

Slide 4 text

なぜ構造設計が必要かミスったときのリスクが⼤きいから !

Slide 5

Slide 5 text

構造設計はいつ必要か不要個⼈で⽝⼩屋を建てる - そもそも作りが簡素で考えることが少ない - 壊れたらまた建てたらよい - ミスったら作り直せばよい必要⼤規模⼯事で⾼層ビルを建てる - 複雑だから闇雲には建たない - 壊れたら⼈命に関わる - 作り直すには莫⼤なコストがかかる - e.g. 耐震補強⼯事 - ⻑年耐えてほしい !

Slide 6

Slide 6 text

ソフトウェアでも同じ! !

Slide 7

Slide 7 text

ソフトウェアのアーキテクチャとは • 簡単には変更できない決定事項 • ⼈間が⾒出す抽象的なもの • フラクタルにどこまでもブレークダウン可能 • 開発者の共通理解として主観的に存在 !

Slide 8

Slide 8 text

ソフトウェアに求めること • 価値提供し続けるために開発‧運⽤コストを低くしたい • 機能追加に耐える • ハードウェアリソースの効率がよく可⽤性が⾼い • 環境変化に迅速に対応したい • 作って終わりではない !

Slide 9

Slide 9 text

優れたアーキテクチャのための指針開発しやすい • 疎結合で凝集性が⾼い • 認知負荷が低い • 変更箇所が局所的 • ⼀度に関わる⼈数が少ない • 開発からリリースまでが短い運⽤しやすい • パフォーマンス‧スケーラビリティ • 耐障害性 • 可観測性 !

Slide 10

Slide 10 text

Webサービスのアーキテクチャ !"

Slide 11

Slide 11 text

システムの外形的アーキテクチャ • モノリス • モジュラーモノリス • マイクロサービス !!

Slide 12

Slide 12 text

モノリス !"

Slide 13

Slide 13 text

モノリスの特徴 • プロダクト全体が1つのコードベース • 単⼀のWebアプリケーション‧単⼀のDB • シンプル • 開発時に触るリポジトリは1つだけ • デプロイが必要なのは1つのアプリケーション !"

Slide 14

Slide 14 text

モノリスが複雑化すると - 技術⾯実はいろいろなコンポーネントがある !"

Slide 15

Slide 15 text

モノリスが複雑化すると - 機能⾯いろいろな機能 !"

Slide 16

Slide 16 text

モノリスが複雑化すると - 組織⾯ 1つのコードベースに複数チームが関わる !"

Slide 17

Slide 17 text

複雑化したモノリスの課題 • 雰囲気の違ういろんなコードが混ざり合ってしまいがち • 「⼤きな泥だんご (big ball of mud)」 ['OP Foote & Yoder] • チーム間のコンフリクト • 変更箇所のコンフリクト • リリースタイミングのコンフリクト • 技術スタックが1つに縛られる • e.g. 機械学習は適した⾔語でやりたい • デプロイパイプラインに無駄が多い • e.g. Webサーバとバッチは別でデプロイ • 不要なコンポーネントのテストも毎回必要になる !"

Slide 18

Slide 18 text

モジュラモノリス • 性質の異なる単位ごとにコンポーネントを分ける • コード上は最上位のディレクトリを分けるなどする • コンポーネント間は限られたインタフェースでのみやりとり !"

Slide 19

Slide 19 text

モジュラモノリスで課題は解決するか? • 雰囲気の違ういろんなコードが混ざり合ってしまいがち • コンポーネントごとに切り分ける • チーム間のコンフリクト • チームごとに担当コンポーネントを分ける • 技術スタックが1つに縛られる • コンポーネントごとに技術スタックも分けてしまう? • → もはやリポジトリが同じだけで単⼀のコードベースとは呼べなくなる • デプロイパイプラインに無駄が多い • コンポーネントごとにパイプラインを分ければ解決? • → もはやリポジトリが同じだけで(ry !"

Slide 20

Slide 20 text

マイクロサービス !"

Slide 21

Slide 21 text

マイクロサービスの特徴 • 1つのプロダクトを複数サービスの連携により実現 • 性質の異なるコンポーネントごとにサービスを分ける • 各サービスは独⽴して開発‧リリースできる !"

Slide 22

Slide 22 text

サービスの分け⽅の基準 • ドメインの境界で分ける • e.g. 課⾦機能と投稿画⾯と閲覧機能 • 再利⽤性の⾼いものを分ける • e.g. アカウント基盤 • 技術スタックで分ける • e.g. 機械学習 • 開発のライフサイクルの違いで分ける • e.g. ネイティブアプリ向けAPI 層 • BFF (Backend For Frontend) • 組織構造に合わせて分ける • e.g. ユーザグロースチームと CMS基盤チーム !!

Slide 23

Slide 23 text

サービス間通信のパターン同期的 • サブルーチン呼出しが別サービスへのリクエストになるだけ • リクエスト先のサービスが⽌まるとリクエスト元もエラーを返すしかなくなる !"

Slide 24

Slide 24 text

サービス間通信のパターン⾮同期的 • 呼出し元はメッセージを送信 • レスポンスを待たない • 呼出し先はメッセージを受信したら処理する • サービス同⼠の独⽴性が⾼く⼀部の障害が全体に波及しにくい !"

Slide 25

Slide 25 text

サービス間通信のパターン⾮同期的: Pub/Subモデル • 送信元は誰が受信するか知らない !"

Slide 26

Slide 26 text

サービス間通信のプロトコル同期的 • RPC • gRPCなど • サブルーチン呼出しに近い • REST • GraphQL • etc. ⾮同期的 • AMQP • RabbitMQなど • 独⾃ • Apache Kafka • Amazon SQS • Google Cloud Pub/Sub • etc. !"

Slide 27

Slide 27 text

サービス間の整合性の取り⽅ CAP定理分散システムにおいて以下の3つをすべて保証することはできない • Consistency (⼀貫性) • Availability (可⽤性) • Partition-tolerance (分断耐性) !"

Slide 28

Slide 28 text

サービス間の整合性の取り⽅結果整合性 (eventual consistency) • ⼀時的に古いデータが参照されることを許容する • 最終的には不整合のない更新内容が反映される !"

Slide 29

Slide 29 text

サービス間の整合性の取り⽅ Sagaパターン • ⻑⼤なトランザクションを分割するパターン • マイクロサービスではサービスごとのトランザクションに分解 • サービスA, B, CのトランザクションTG, TH, TI • トランザクションには失敗時に元の状態に戻す補償トランザクションを⽤意 • TG, TH, TIに対してCG, CH, CI • TIが失敗したらCHとCGを実⾏ !"

Slide 30

Slide 30 text

サービス間の整合性の取り⽅ TCCパターン (Try-Confirm-Cancel) • Tryフェーズ • 各サービスで仮登録状態にする • Confirm/Cancelフェーズ • すべてのサービスでTryが成功したらConfirmリクエスト • いずれかのサービスでTryかConfirmが失敗したらCancelリクエスト !"

Slide 31

Slide 31 text

サービス間の整合性の取り⽅羃等性 (idempotency) • 同じ操作を何度やっても同じ結果になる性質 • サービス間のリクエストは羃等が望ましい • 失敗したらリトライしたい • 失敗と成功レスポンスの受け取り失敗は厳密には区別できない • e.g. リクエストの処理中にネットワークが切断した場合⽅法 • (a) リクエストする側が操作にIDを振っておく • 処理する側は処理済みのIDは覚えておく • 過去に処理済みのリクエストは無視する • (b) 差分ではなく最終状態にバージョンをつけてリクエスト • 古いバージョンによる上書きは無視する !"

Slide 32

Slide 32 text

ここまでのまとめ • アーキテクチャとは • 後戻りできない決定事項 • 外形的に優れたアーキテクチャ • うまい分割 • ドメインや技術スタックなど • リードタイム短縮 • ⼈と組織が重要 • 分散システムにすると考えることは増える • どこまで頑張るかは規模や想定する運⽤年数による !"

Slide 33

Slide 33 text

システムの内側のアーキテクチャ !!

Slide 34

Slide 34 text

よりミクロな視点 • うまい分割 • 認知負荷を下げる • 重要な箇所が些細な変更に影響されない • スピード • テストしやすい → 変更しやすい !"

Slide 35

Slide 35 text

ビジネスロジックとビューの分離 MVC • もともとはデスクトップGUIアプリのアーキテクチャ • M : モデル • ビジネスロジックを表現する • データとその操作や永続化⽅法 • V : ビュー • モデルのデータをUIとして表⽰する • C : コントローラ • ⼊⼒イベントをモデルに渡す • モデルの変更がビューに反映されるように繋ぐ !"

Slide 36

Slide 36 text

ビジネスロジックとビューの分離 MとVが分離されていないと何が困るか • ビューの各所にロジックが偏在 • ロジック(仕様)を変えるにはビューのいろんな箇所の変更が必要 • ロジック(仕様)が正しいかテストするのにビューのテストが必要 • ⾒せ⽅を変えただけでロジックが壊れる !"

Slide 37

Slide 37 text

ビジネスロジックのさらなる分解レイヤー化アーキテクチャ • ビジネスロジック = ドメインモデル + ユースケース • ドメインモデル • 登場⼈物とその関係 • e.g. 「著者」は「記事」を投稿できる • e.g. 「記事」には「カテゴリ」を設定できる • ユースケース • ユーザの体験としてどのようなドメインモデルの操作が可能か • e.g. ユーザは「著者」として「カテゴリ」設定した「記事」を投稿できる • 「カテゴリ」がまだ存在しなければ作成される • 永続化⽅法などは実装上の都合 (インフラ層) !"

Slide 38

Slide 38 text

依存関係逆転の原則 MVCの場合 • ビュー ← モデルではない • モデルが⾃⾝の変更を能動的にビューに伝える = モデルがビューに依存 • モデルのテストにビューが必要になってしまう • 依存を逆転する⽅法 • (a) モデルに変更があったらイベントを発⽕するだけ • フロントエンドで典型的なアプローチ • (b) 変更後のモデル状態をコントローラがビューに渡す • バックエンドで典型的なアプローチ !"

Slide 39

Slide 39 text

依存関係逆転の原則レイヤー化アーキテクチャの場合 • ドメイン層 → インフラ層ではない • ドメインロジックは永続化⽅法によらない • e.g. データベースをMongoDBからMySQLに変えてもドメインロジックは不変 • 依存を逆転する⽅法: リポジトリインタフェース • モデルの変更の反映はリポジトリを介する • リポジトリのインタフェースはドメイン層に置く • リポジトリの実装はインフラ層に置く !"

Slide 40

Slide 40 text

もっと細かいアーキテクチャ • MVCのビューまわりの解像度を上げる • MVVMやMVPなど • ビューまで考慮したレイヤー化アーキテクチャ • クリーンアーキテクチャなど !"

Slide 41

Slide 41 text

まとめ • アーキテクチャとは • 後戻りできない決定事項 • 優れたアーキテクチャ • 開発しやすい • 運⽤しやすい • アーキテクチャの選択 • マクロな視点とミクロな視点 • 規模や想定する運⽤年数に応じて決める !"