ソフトウェアエンジニアリングは、さまざまな人が手を加え続けるなかで、負荷のもとでも何年にもわたって正しく、変更しやすい状態を保つシステムを構築する実践です。アーキテクチャとは、後から変更するのに大きなコストがかかる部分を指します。境界をどこに引くか、どのコンポーネントがどのデータを所有するか、コンポーネント同士がどう通信するか、そのいずれかが故障したときに何が起きるかです。
アーキテクチャの問題の多くは境界の問題です。データベースを共有するサービスは独立してデプロイできません。互いのテーブルに直接アクセスするモジュールは、切り離して考えることができません。5つの同期呼び出しが連なれば、全体の可用性は5つの可用性の積にしかなりません。境界を正しく引くことは、モノリスかマイクロサービスかの選択よりも重要であり、同じドメイン分析がどちらにも役立ちます。
Staroneのアーキテクトは、制約から構造を選びます。チームの規模、変更の頻度、整合性の要件、負荷の特性、運用の成熟度です。本ページではアーキテクチャとエンジニアリングプラクティスを扱います。フロントエンド、バックエンド、モバイルの各エンジニアリングには、それぞれ個別のケイパビリティページがあります。
エンジニアリング領域
モジュラーモノリスは、内部の境界が強制された一つのデプロイ単位です。マイクロサービスは、それぞれが自らのデータを所有し、独立してデプロイできるサービス群です。サービス指向アーキテクチャはその中間にあり、より粒度の粗いサービスがインフラストラクチャを共有することも少なくありません。独立してリリースする必要のあるチームの数と、各部分のスケーリング要件の違いの大きさに合ったスタイルを選びます。
ドメイン駆動設計（DDD）は、データベーススキーマではなく業務を分析することで境界を見いだします。境界づけられたコンテキストとは、ある用語が一つの意味を持ち、一つのチームが所有する領域です。集約は、単一のトランザクションで一緒に変更されなければならない範囲を定めます。これらの境界がモジュールやサービスとなり、システムのなかで最も長く残る決定になります。
イベントは、プロデューサーと、それに反応するコンシューマーとを、時間と可用性の両面で疎結合にします。即時の応答を必要としない処理はキューに移し、バーストを吸収して遅い依存先を切り離します。その代償は結果整合性とデバッグの難しさです。そのため、疎結合にする価値がある箇所にはイベントを、呼び出し元が結果を必要とする箇所には直接呼び出しを使います。
システムが複数のプロセスにまたがると、ネットワークは故障し、メッセージは二重に届き、時計は一致しなくなります。私たちはこれを前提として明示的に設計します。操作ごとに整合性のレベルを選び、書き込みを冪等にし、読み取りモデルと書き込みモデルの形や負荷が大きく異なる箇所ではCQRSで両者を分離します。イベントソーシングは、台帳や監査要件の厳しいドメインのように、変更の履歴そのものが要件である場合に用います。
耐障害性とは、ある依存先の障害が一つの機能を劣化させるにとどまり、システム全体には及ばないことを意味します。水平スケーリングにはステートレスなサービスが必要で、状態はそのために作られたデータストアに保持します。どちらも、タイムアウト、回数を限定したリトライ、ロードシェディングによって最初から設計に組み込み、負荷テストと障害テストで検証します。
アーキテクチャは、日々のプラクティスがそれを守ってはじめて維持されます。私たちは階層化されたテスト戦略を採り、すべての変更をレビューし、継続的に統合し、APIコントラクトをバージョン管理された成果物として扱います。重要な決定はアーキテクチャデシジョンレコード（ADR）として記録し、次にシステムを保守する人がその理由を参照できるようにします。
マイクロサービスが解決するのは組織上の課題です。多数のチームがそれぞれ独立したスケジュールでリリースし、システムの各部分のスケールの仕方や故障の仕方が異なる、という状況です。その代償として、関数呼び出しがネットワーク呼び出しに置き換わり、分散トランザクション、サービスごとのパイプライン、そしてはるかに広い運用対象を抱えることになります。
モジュラーモノリスは、構造上の利点の大半をより低いコストで実現します。モジュールは明示的な公開インターフェースを持ち、自らのテーブルを所有し、プロセス内呼び出しまたは内部イベントで通信します。境界はビルドルールやアーキテクチャテストによって強制されます。デプロイは一つ、トランザクション境界も一つ、デバッグする場所も一つです。
現実的な進め方は、モジュラーな構成から始め、具体的な理由が生じたときにサービスを切り出すことです。あるモジュールに独自のスケーリング特性、リリース頻度、技術、分離が必要になった場合です。境界がきれいに保たれていれば、切り出しは機械的な作業で済みます。保たれていなかったのであれば、マイクロサービスにしていても分散モノリスになっていたはずで、それは両者の欠点を併せ持つものです。
アーキテクチャ
クライアント
APIゲートウェイ / BFF
ドメインサービス
各サービスが1つの境界づけられたコンテキストを担う
非同期メッセージング
データストア
サービスごとにデータベースを持ち、テーブルは共有しない
プラットフォーム
単一のデータベースであれば、アトミックなトランザクションが得られます。サービスをまたぐとそのような保証はなく、2フェーズコミットは、ほとんどのシステムが受け入れられない形で可用性を結合させます。標準的な答えはSagaです。ローカルトランザクションを連ね、それぞれがイベントを発行し、後続のステップが失敗したときには補償アクションを実行します。
これを安全にする仕組みが二つあります。トランザクショナルアウトボックスは、状態の変更と送信するイベントを同じデータベーストランザクションで書き込みます。これにより、イベントが失われることも、ロールバックされた変更についてイベントが発行されることもありません。冪等なコンシューマーは再配信を無害にします。ブローカーは実際には少なくとも一回の配信を行うためです。この二つが揃えば、結果整合性は予測可能なものになります。
ただし、すべての操作が結果整合性を許容できるわけではありません。残高、在庫の引当、一意性のチェックには通常、強整合性が必要です。そのため、これらの不変条件は一つの集約、一つのサービスの内側に保ちます。
分散システムでは、部分的な障害が通常の状態です。応答の遅い依存先は、停止している依存先よりも厄介です。呼び出し元は待っている間スレッドとコネクションを保持し続け、その遅さが上流へと広がっていくためです。
そのため、すべてのリモート呼び出しには、呼び出し元自身のレイテンシ予算から導いたタイムアウト、回数を限定しジッターを加えたリトライ、そして不健全な依存先への呼び出しを止めるサーキットブレーカーを設定します。バルクヘッドは依存先ごとに専用のコネクションプールを割り当て、一つの依存先が共有リソースを使い果たすことを防ぎます。過負荷のときには、際限なくキューに積むのではなく、優先度の低い処理を早い段階で破棄します。
エンジニアリングの進め方
アーキテクチャの検討はドメインと制約から始め、早い段階で動くコードによって検証します。
業務プロセスを、それを実際に担う人々とともに確認し、境界づけられたコンテキスト、主要なエンティティ、重要なイベントを整理します。
可用性、レイテンシ、スループット、整合性、コンプライアンスの制約を、計測可能な目標として書き出します。構造を左右するのは、機能よりもこれらです。
スタイル、データの所有、通信パターンを選び、重要な選択はそれぞれ、却下した代替案とともにADRとして残します。
範囲を広げる前に、CI、デプロイ、オブザーバビリティを含むすべてのレイヤーを貫く薄いスライスを一つ届けます。変更のコストが低いうちに、アーキテクチャを現実に照らして検証できます。
自動テスト、コントラクトチェック、コードレビューを通して小さな変更をリリースし、境界を越えた場合にビルドを失敗させるアーキテクチャテストを備えます。
ローンチ前に負荷テストを実施し、依存先の障害を注入します。その後、実際のトラフィックデータが得られるのに合わせて決定を見直します。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
セキュリティは設計の一部です。アーキテクチャ段階での脅威モデリング、すべてのサービス境界で強制する認証と認可、入力の検証、保管庫（ボールト）で保持するシークレット、CIでの依存関係スキャンを行います。サービスは必要最小限の権限で実行します。
サービスはステートレスで、ロードバランサーの背後で水平にスケールします。状態は、必要に応じてパーティショニングまたはレプリケーションされたデータベース、キャッシュ、ブローカーに保持します。キャパシティの限界は、インシデントではなく負荷テストによって把握します。
すべてのサービスが、共通の相関IDを付けた構造化ログ、メトリクス、分散トレースを出力します。サービスレベル目標（SLO）が正常な状態を定義し、アラートはユーザーが気づく症状に紐づけます。
すべての変更は自動テストを通過し、イミュータブルな成果物としてビルドされ、変更を加えられることなく各環境へ昇格します。リリースにはローリング、ブルーグリーン、カナリアの各戦略を用い、データベースマイグレーションは後方互換とし、フィーチャーフラグでデプロイとリリースを分離します。
連携はバージョン管理されたコントラクトを通じて行います。呼び出しにはOpenAPIまたはgRPC、メッセージングにはスキーマ登録されたイベントを用います。腐敗防止層がドメインモデルをサードパーティやレガシーのシステムから隔離し、コンシューマー駆動のコントラクトテストが破壊的変更をリリース前に検出します。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
制約から決めます。ドメインの境界、チームの数、求められる可用性と整合性、想定される負荷、そして構築したものを運用する組織の能力を確認したうえで、それらを満たす最も単純な構造を選び、その理由を記録します。
はい。まずコードとその運用履歴を読み込み、変更する箇所の周囲にテストを追加し、機能開発と並行して構造を段階的に改善します。
チームが自信を持ってシステムを変更できる程度です。実際には、ドメインロジックに対する高速なユニットテスト、データベースなど実際の依存先に対する結合テスト、サービス境界でのコントラクトテスト、そして重要なユーザージャーニーに対する少数のエンドツーエンドテストを指します。
アーキテクチャデシジョンレコード、コンテキスト図とコンテナ図、API仕様、運用作業のランブック、そして新しいエンジニアがシステムを動かせるようになるREADMEです。ドキュメントはリポジトリに置き、コードとともに更新されるようにします。
