マイクロサービスアーキテクチャ

モノリス

モノリシックなアプリは 単一のコードベースに全機能を実装し１つのDBに全データを格納する

マイクロサービス

マイクロサービスは 大規模なプログラムを小さな独立したサービスに分割したアーキテクチャ

各マイクロサービスを独立させるには サービスごとに固有のデータストアを使用する

こうすることで各サービスに最適な データストアソリューションを選択できサービスの独立性も維持できる（データストアを介してサービス同士を結合させないことが重要）

マイクロサービスアーキテクチャのメリット

各種マイクロサービスの間に厳密なコントラクトを定義する

ロールバックを含む 独立したデプロイサイクルを可能にする

サブシステムでの 同時A/Bリリーステストを容易にする

テスト自動化と品質保証の オーバーヘッドを最小化する

ロギングとモニタリングの明確さを高める

細かい粒度で費用を計算する

小さなユニットをスケールすることで アプリ全体のスケーラビリティと信頼性を高める

マイクロサービスアーキテクチャの課題

各サービスを個別に開発、デプロイするためのサービス間の明確な境界は簡単に定義できない場合がある

インフラが複雑化し配信するサービスの障害点が多くなる

ネットワークサービスによってレイテンシが増加するため障害や遅延に対処するためのレジリエンスを組み込む必要がある

サービス間の通信をセキュリティで保護する必要がありその結果インフラの複雑さが増す

個別にデプロイ可能なサービスの場合 サービスインターフェースの管理とバージョニングの要件が厳しくなる

以上のようなメリットとデメリットを考慮して、 マイクロサービスアーキテクチャを選択する場合は正当な理由があることが重要

主な理由は 複数のチームが独立して作業し 各チームのペースで 本番環境に配信できるようにすることです こうすると組織の拡大に対応でき チームを増やしてスピードを上げられます

マイクロサービスアーキテクチャとステートフルなアプリケーション

ステートフルなアプリケーションは以下の理由からマイクロサービスの利点を活かしづらくなる

スケールするのが難しい

バージョンアップが難しい

バックアップが必要

しかし完全にステートレスであることは難しく、一般的にある時点ではステートフルサービスを使用せざるを得ないので、ステートフルサービスがシステムのアーキテクチャにどのような影響を与えるかを理解しておく必要がある。

メモリでステート管理するとマイクロサービスのメリットを享受できなくなる

フロントエンドステートレスサービス←→バックエンドサービス（ステートフル） ＆ キャッシュ という構成

Twelve-Factor App

Twelve-Factor AppはウェブまたはSaaSアプリを 構築する際のベストプラクティス一式です Twelve-Factorの設計では アプリの構成要素を分離でき 分離した要素を継続的デプロイを使って 個別にデプロイし シームレスにスケールアップ/ダウンできます この設計原則に従うと さまざまな環境への ポータビリティも最大化できます これらの特性はプログラミング言語や SWスタックに依存しないため Twelve-Factorの設計は さまざまなアプリに適用できます

一般的な話。以下が公式。

I. コードベース

バージョン管理されている1つのコードベースと複数のデプロイ

II. 依存関係

依存関係を明示的に宣言し分離する

III. 設定

設定を環境変数に格納する

IV. バックエンドサービス

バックエンドサービスをアタッチされたリソースとして扱う

V. ビルド、リリース、実行

ビルド、リリース、実行の3つのステージを厳密に分離する

VI. プロセス

アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

VII. ポートバインディング

ポートバインディングを通してサービスを公開する

VIII. 並行性

プロセスモデルによってスケールアウトする

IX. 廃棄容易性

高速な起動とグレースフルシャットダウンで堅牢性を最大化する

X. 開発/本番一致

開発、ステージング、本番環境をできるだけ一致させた状態を保つ

XI. ログ

ログをイベントストリームとして扱う

XII. 管理プロセス

管理タスクを1回限りのプロセスとして実行する