System Design

従来のモノリシック アプリケーションでは、複数のエンティティ間でデータの一貫性を維持するのは簡単です。リレーショナル データベース エンジンは、ローカル SQL トランザクション内にラップされた ACID (原子性、一貫性、分離性、耐久性) 保証を提供します。注文の発注、支払いの差し引き、または在庫の予約が途中で失敗した場合、ROLLBACK を呼び出すと、データベースのすべての変更が即座に元に戻されます。 ただし、最新の マイクロサービス アーキテクチャ に移行すると、データ管理が根本的に変わります。ドメインの自律性と独立したスケーラビリティを確保するために、各マイクロサービスはプライベート データベースを所有します。電子商取引のチェックアウトの処理などの 1 つのビジネス操作が、複数のサービス境界とデータベース エンジン (注文の PostgreSQL、支払いの DynamoDB、在庫の Redis など) にまたがるようになりました。 分散マイクロサービスは単一のデータベース トランザクションに依存できないため、ネットワーク境界を越えてデータの一貫性を維持することは、分散システム エンジニアリングにおいて最も困難な問題の 1 つになります。 システムの可用性やパフォーマンスを犠牲にすることなくこれを解決するために、ソフトウェア アーキテクトは Saga パターン を利用します。 この詳細な説明では、従来の分散トランザクションが失敗する理由を調査し、Saga パターンの中核的な仕組みを分析し、コレオグラフィーとオーケストレーションを比較し、分離対策を分析し、Go と Java での実稼働コードの実装を調査し、実際の障害ロールバックを安全に処理する方法を学びます。 根本的な問題: マイクロサービスで 2 フェーズ コミット (2PC) が失敗する理由 Saga パターンを採用する前に、エンジニアはよく次のような質問をします: マイクロサービス全体で従来の 2 フェーズ コミット (2PC / XA)​​ を使用できないのはなぜですか? 2PC の仕組み 2 フェーズ コミットは、中央のトランザクション マネージャーを使用して、複数のデータベース ノードにわたる分散トランザクションを 2 つのフェーズで調整します。

現代のイベント駆動型マイクロサービス（Event-Driven Architecture）では、サービス間を疎結合に保ちつつ状態変更を通知するために、OrderCreated や PaymentProcessed などのイベントが日常的に発行されます。 しかし、イベント発行の完全な信頼性を確保するには大きな課題があります：「データベースの更新」と「イベント発行」の双方を、確実に「両方成功」か「両方失敗」にするにはどうすればよいか？ マイクロサービスがローカルDB（PostgreSQLやMySQL）を更新した直後にメッセージブローカー（KafkaやRabbitMQ）へネットワーク経由で送信しようとすると、ネットワーク障害やタイムアウトによってデータ不整合が発生します。 この問題を根本的に解決するのが Transactional Outbox パターン です。 根本的な課題：二重書き込み問題 (Dual-Write Problem) 二重書き込みを単純に行うと、以下のリスクが生じます： ローカルデータベースへビジネスデータを保存 メッセージブローカーへイベントを発行 DBコミットが成功した後にKafkaへの送信がネットワークエラーで失敗した場合、DBにはデータが存在するのに後続サービスへイベントが届きません。結果：データの不一致。 Transactional Outbox パターンとは？ リレーショナルデータベースの ローカルACIDトランザクション を活用する設計パターンです。 イベントを直接ネットワーク経由で送信するのではなく、ビジネスデータの保存と全く同じトランザクション内で、専用の Outbox テーブル にイベントデータを書き込みます。 ACIDの保証により、両方がコミットされるか、両方がロールバックされるかのいずれかになります。 その後、独立したバックグラウンドプロセス（Message Relay）がOutboxテーブルから読み出し、メッセージブローカーへ発行します。 メッセージリレー戦略：Polling Publisher vs CDC (Debezium) 1. Polling Publisher（ポーリング方式） 定期的なスケジューラで未処理レコード（SELECT * FROM outbox_events WHERE processed = FALSE）を取得し、Kafkaに送信後に更新。

マイクロサービス アーキテクチャでは、サービスは分散ネットワーク呼び出しの Web を形成します。これにより、チームはサービスを独立して構築および拡張できますが、システム全体の信頼性がその最も弱い部分と同じ程度にしか強くないことも意味します。重要なサービスがダウンしたり応答しなくなったりすると、アプリケーション全体が中断される連鎖的な障害が引き起こされる可能性があります。 単一の依存関係が失敗した瞬間に一般的な「500 Internal Server Error」または空白のページがユーザーに返されるのは、ユーザー エクスペリエンスが低下します。代わりに、回復力のあるシステムは、問題が発生した場合に正常に機能を低下させるように構築されています。 ここで、フォールバック パターンが登場します。プライマリ サービス呼び出しが失敗した場合に、安全な代替実行パスを定義することで、機能が低下した状態であってもアプリケーションの機能を維持できます。 このガイドでは、フォールバック パターン、フォールバック パターンを実装するための一般的な戦略、フォールバック パターンが他の復元パターンとどのように相互作用するか、Java (Resilience4j) と Go でフォールバック ロジックを記述する方法について説明します。 現実世界の例え: コーヒーショップのバックアップ計画 ラテを買うために地元のコーヒーショップに入ったと想像してください。バリスタが注文を入力しますが、カードをタップしようとすると、支払い端末が接続エラーを点滅させます。店のインターネットプロバイダーが停止しているためです。 コーヒーショップはすぐに照明を消し、ドアに鍵をかけて、すべての顧客を家に送り返しますか? もちろん違います。彼らは フォールバック戦略 を実装しています。 ※現金を持っている場合は、現金で支払えるか尋ねられます。 ※常連のお客様の場合、バリスタがお客様のお名前と注文を台帳に記載し、次回来店時にお支払いをお願いする場合がございます。 カード トークンをローカルに保存し、後でインターネットが回復したときに支払いを処理するオフライン カード リーダーを使用する場合があります。 ソフトウェア設計では: コーヒーの注文はクライアントのリクエストです。 カード ターミナルは、主要なダウンストリーム サービス (ペイメント ゲートウェイ API など) です。 インターネットの停止は、ネットワークのタイムアウトまたはサービスのクラッシュです。 レジャー/オフライン リーダーはフォールバック実行パスです。 一般的なフォールバック戦略 ビジネス ロジックと失敗したサービスの重要度に応じて、いくつかのフォールバック戦略から選択できます。

マイクロサービス アーキテクチャでは、サービスはメモリ内呼び出しではなくネットワーク経由で通信します。この分離により、大規模な水平スケーリングと独立した展開が可能になりますが、ネットワークの信頼性が低いという重大な脆弱性も生じます。 ダウンストリーム サービスでは、いつでも、短時間のネットワーク障害、一時的な CPU スパイク、データベース ロックの急速な競合、ローリング アップデートの再起動が発生する可能性があります。これらの一時的な障害は 一時的な障害 として知られています。 ダウンストリーム呼び出しが失敗した瞬間にサービスがすぐにエラーをスローし、リクエストを失敗させると、脆弱なユーザー エクスペリエンスが作成されます。代わりに、これらの一時的なエラーの多くは、少し待ってから再試行することで自動的に解決できます。ここで 再試行パターン が役に立ちます。 このガイドでは、再試行パターン、内部でどのように動作するか、単純な実装の危険性、Java (Resilience4j) と Go で再試行パターンを正しく実装する方法について説明します。 現実世界のたとえ: 話し中の回線にリダイヤルする あなたが友人に電話しようとしていると想像してください。あなたは相手の番号にダイヤルしますが、相手は現在別の通話中であるため、話中信号を受け取ります。 あなたはすぐに諦めて連絡先を削除し、二度と話せないと思い込んでいませんか?もちろん違います。電話を切り、少し待ってから、もう一度相手の番号をダイヤルします。まだ通話中の場合は、5 分待ってからもう一度試してください。 最終的に通話は終了し、再試行は成功します。 マイクロサービスでは: 呼び出しは、ダウンストリーム サービスへの API リクエストです。 ビジー信号は、一時的なネットワーク エラーまたは 503 Service Unavailable 応答です。 リダイヤルは再試行です。 待機時間はバックオフ期間です。 危険: 単純な再試行と「再試行の嵐」 再試行メカニズムの実装は、一見すると簡単に思えます。HTTP 呼び出しを for ループでラップし、成功するまで試行し続けるだけです。ただし、単純な再試行の実装では、軽微な問題がシステム全体の壊滅的な停止に簡単に変化する可能性があります。 突然のトラフィックの急増に苦戦しているダウンストリーム サービスを想像してください。データベースは 99% の CPU 使用率で実行されており、リクエストがタイムアウトし始めています。

マイクロサービス アーキテクチャでは、単一のアプリケーションが数十または数百の独立した連携サービスに分割されます。この設計により、モジュール性とスケーラビリティが向上しますが、1 つのサービスで障害が発生すると連鎖的にシステム全体が停止する可能性があります。 という大きなリスクも伴います。 ダウンストリーム サービスが遅くなったり応答しなくなったりすると、アップストリーム サービスへの受信リクエストが蓄積され始めます。すべてが同じメモリ、CPU、またはスレッド プールを共有している場合、依存関係が遅いと利用可能なリソースがすぐに使い果たされ、アプリケーション全体がクラッシュする可能性があります。 この連鎖的な失敗はドミノ効果として知られています。これを防ぐために、システム設計者は バルクヘッド パターン を使用します。 このガイドでは、簡単な例え話、アーキテクチャ上の概念、Java (Resilience4j) と Go のコード例を使用して、バルクヘッド パターンとは何か、その仕組み、実装方法について説明します。 現実世界のたとえ: 船の防水隔壁 このパターンの名前は造船業界に由来しています。 隔壁 は、船の船体の内側に作られた水密壁です。船体の内部に単一の巨大なオープンスペースがあるのではなく、内部はいくつかの独立した密閉されたコンパートメントに分割されています。 船が障害物に衝突して船体が破損すると、損傷した区画に水が浸入します。ただし、水密隔壁のおかげで、水はその 1 つのコンパートメントに閉じ込められます。船の残りの部分は乾いていて浮力があるため、浮いたまま安全な場所に到達できます。 隔壁がなければ、水が船体全体を自由に流れ、最終的には船が沈没してしまいます。 ソフトウェアエンジニアリングでは: Ship はアプリケーションまたはサービス全体です。 コンパートメントは、分離されたリソース プール (スレッド、接続、CPU) です。 ハル違反 とは、下流のマイクロサービスでの障害または速度低下です。 フラッディングはリソースの枯渇です。 問題: 共有リソース プールとスレッドの枯渇 なぜバルクヘッドが必要なのかを理解するために、リソースがグローバルに共有される場合に何が起こるかを見てみましょう。 ユーザーリクエストを処理する API ゲートウェイまたは Web サーバーを想像してください。すべての着信呼び出しを処理するための 100 スレッドからなる単一のグローバル スレッド プールがあります。サーバーは 3 つのダウンストリーム サービスと対話します。

最新のクラウドネイティブ システムでは、マイクロサービスはビジネス ロジックを実行する以上のことを行うことが期待されています。ログの処理、SSL/TLS 証明書の管理、メトリクスの収集、再試行メカニズムの実装、および他のサービスとの安全な通信の調整を行う必要があります。 この横断的な機能をすべて各アプリケーションのコードベース内に直接埋め込むと、コードの肥大化、密結合、言語のロックインが発生します。 ここで、サイドカー パターンが登場します。このガイドでは、サイドカー パターンとは何か、それが最新のマイクロサービス アーキテクチャに不可欠である理由、および簡単な例えと Kubernetes 構成例を使用してそれがどのように機能するかを詳しく説明します。 現実世界の例え: オートバイのサイドカー このパターンを理解する最も簡単な方法は、サイドカー付きのオートバイを考えることです。 あなたが高性能のオートバイを持っていると想像してください。この車両は、1 人のライダーを迅速に輸送するという 1 つのことを非常にうまく実行するように設計されています。ここで、乗客の手荷物を運ぶ必要があるか、追加の座席を追加する必要があるとします。 オートバイのフレーム、エンジン、ホイールを完全に再設計して車に変えることができます。しかし、それには多大な労力が必要で、バイクのシンプルさが損なわれ、メンテナンスが難しくなります。 代わりに、サイドカーを接続します。 サイドカーは、オートバイに接続する独立した自己完結型ユニットです。バイクの移動を共有し、バイクの行くところならどこへでも移動し、緊密に連携して動作します。しかし、オートバイの核となるエンジンは手つかずのままです。 ソフトウェア アーキテクチャでは: Motorcycle は、主要なアプリケーション コンテナです (チェックアウトやユーザー認証などのコア ビジネス ロジックを実行します)。 サイドカーは、別個のヘルパー コンテナーです (SSL 終了、監視、ログ配布などのユーティリティ タスクを実行します)。 ジャーニー は、デプロイメント (Kubernetes ポッドなど) のライフサイクルです。 問題: 分野横断的な懸念とコードの肥大化 サイドカーが登場する前は、開発者はアプリケーション コードにヘルパー ライブラリを直接組み込む必要がありました。たとえば、ログを中央サーバーに送信する場合は、ログ ライブラリをインポートします。メトリクスが必要な場合は、メトリクス SDK を追加しました。

現代のソフトウェア エンジニアリングでは、レガシーのモノリシック アプリケーションが共通の課題となっています。時間が経つにつれて、成功したコードベースは非常に大きくなり相互接続されるため、単純な変更を行うのは危険になり、デプロイには数時間かかり、個々の機能を拡張することは事実上不可能になります。 チームがマイクロサービスに移行してシステムを最新化することを決定したとき、現在のビジネスを中断することなくシステムを書き直すにはどうすればよいですか? という一か八かの質問に直面します。 選択肢の 1 つは、「ビッグバン」書き換えです。つまり、密室で新しいシステムをゼロから構築し、1 日ですべてを切り替えることです。ただし、これは非常に危険であり、多くの場合失敗につながります。 幸いなことに、より安全で信頼性の高い代替手段、ストラングラー フィグ パターンがあります。このガイドでは、ストラングラー フィグ パターンとは何なのか、なぜ機能するのか、そして明確な図と実際のコードを使用してそれを段階的に適用する方法を説明します。 現実世界のたとえ: ストラングラー イチジクの植物 このパターンは、熱帯雨林に自生する植物であるストラングラー イチジクにちなんで名付けられました。 ストラングラー イチジクの種子は、既存の「宿主」の木の上部の枝で発芽します。イチジクは地面から上に成長するのではなく、下に向かって成長します。 根を宿主の木の幹に送り込み、林床に到達して土壌に固定します。 時間の経過とともに、より多くの根が成長し、宿主の周りを包み込み、融合します。 イチジクは、宿主の木に届く光を遮る葉を生やします。 最終的に、宿主の木は枯れて腐り、中空のストラングラー イチジクの木がその場所にしっかりと立っています。 ソフトウェア アーキテクチャでは、従来のモノリス がホスト ツリーであり、新しいマイクロサービス が絞殺図です。私たちはモノリスのエッジの周りに新しいサービスを構築し、モノリスが完全にシャットダウンできるまでトラフィックをレガシー システムから徐々に移行させます。 「ビッグバン」書き換えが失敗する理由 ストラングラー フィグ パターンの仕組みに入る前に、代替案 (完全な書き換え) がなぜ非常に危険なのかを理解しましょう。 数か月 (または数年) では価値がありません: 開発者はコードの作成に長い時間を費やしますが、プロジェクト全体が完了するまではコードが実際に公開されることはありません。 スコープ クリープ: 2 年間の書き換え中に、ビジネス ニーズが変化します。ターゲットは移動し、新しいシステムは書き換え開始時には存在しなかった機能をサポートする必要があります。 暗黙的な動作の欠落: Monoliths には、文書化されていないバグ修正とエッジケースの処理が何年にもわたって含まれています。白紙の状態で書き直すと、これらの詳細が忘れられることがよくあります。 導入リスクが高い: 大規模なレガシー システムをオフにして新しいシステムを一度にオンにすると、何か問題が発生した場合に大きな爆発範囲が発生します。 ストラングラーフィグパターンの仕組み Strangler Fig パターンの中心となるアイデアは 増分移行 です。システム全体を移行するのではなく、一度に 1 つの小さな機能、つまり「スライス」を移行します。

マイクロサービス アーキテクチャでは、当社のシステムは、ユーザー サービス、注文サービス、製品サービスなど、多数の小規模で焦点を絞ったサービスに分割されます。 しかし、この情報をユーザーに表示する場合、デバイスごとにニーズは大きく異なります。高速デスクトップ コンピューター上の Web ブラウザーには、テーブル、サイドバー、グラフが満載のリッチなダッシュボードが必要です。低速のセルラー ネットワーク上のモバイル アプリでは、帯域幅とバッテリーを節約するために、シンプルで軽量なレイアウトが必要です。スマートウォッチ アプリには 1 行のテキストのみが必要な場合があります。 これらすべてのフロントエンドがまったく同じバックエンド API をクエリする場合、誰かが妥協する必要があります。モバイル アプリは大量の役に立たないデータをダウンロードすることを強いられるか、Web アプリは必要なものをすべて取得するために何十もの個別のネットワーク リクエストを行うことを強いられます。 これは、フロントエンド用バックエンド (BFF) パターン によって解決されるまさに問題です。このガイドでは、このパターンを簡単な言葉で説明し、現実世界の類似点を見て、それを標準の API ゲートウェイと比較し、実際のコード実装について説明します。 現実世界のたとえ: レストランのメニュー 3 つのまったく異なるタイプの食事を提供するレストランを想像してください。 食品評論家。詳細な成分リストを含む完全な 5 コースのテイスティング メニューを望んでいます。 忙しい通勤者で、電車の中で簡単に包装済みの軽食を食べたいと考えています。 子供は、スパイシーな食材を使わず、少量でシンプルなお子様の食事を望んでいます。 もしレストランに、3 つのオプションすべてを詳細に記載した 1 つのメニューしかなかったとしたら、それは圧倒されるでしょう。通勤者は5品コースのレシピを読むのに時間を無駄にし、子供の親は簡単な食事の選択肢を見つけるのに苦労するでしょう。 代わりに、レストランでは 3 つのカスタム メニュー (テイスティング メニュー、エクスプレス To-Go メニュー、キッズ メニュー) を印刷します。 各メニューは同じキッチン (マイクロサービス) から取得されますが、その顧客 (クライアント) に合わせて選択肢の形式とサイズが設定されます。 このシナリオでは: キッチンはマイクロサービス (ユーザー、カタログ、支払い) を表します。 カスタム メニューはあなたの BFF (Web BFF、Mobile BFF、Watch BFF) です。 ダイナーはフロントエンド (デスクトップ ブラウザ、モバイル アプリ、スマートウォッチ) です。 問題: 「万能」API マイクロサービスが最初に普及したとき、多くのチームは、すべてのフロントエンド クライアントを処理する単一の共有 API ゲートウェイを構築しました。

単一のモノリシック アプリケーションからマイクロサービス アーキテクチャに移行すると、多くの問題が解決されます。これにより、チームが独立して作業し、サービスを個別に展開し、必要に応じてシステムの一部を拡張することができます。ただし、クライアントはこれらすべての独立したサービスとどのように対話するのかという新たな課題も生じます。 10、50、または数百の小さなマイクロサービスがある場合、モバイル アプリまたは Web ページはそれぞれのマイクロサービスに直接接続する必要があるでしょうか? ここで、API ゲートウェイ パターン が登場します。このガイドでは、API ゲートウェイとは何なのか、なぜそれが必要なのか、そして API ゲートウェイがどのようにマイクロサービス システムを簡素化するのかについて、簡単な言葉と現実世界の例えを使用して詳しく説明します。 現実世界の例え: ホテルの受付係 あなたが大規模な高級リゾートホテルにチェックインしていると想像してください。リゾートにはさまざまな部門があります。 ハウスキーピング（クリーンシートの場合） ※ルームサービス（お食事） ※コンシェルジュ（ツアー予約担当） Billing (請求書を支払うため) 清潔なタオルが必要な場合は、リゾート内を歩いて清掃棟を探す必要はありません。夕食が食べたければ、キッチンのドアをノックする必要はありません。代わりに、フロントデスクの受付に電話してください。 受付担当者がお客様のご要望を伺い、どの部門が解決できるかを判断し、おつなぎするか、対応させていただきます。 このシナリオでは: あなたはクライアント (モバイル アプリまたはブラウザ) です。 受付は API ゲートウェイです。 部門 (ハウスキーピング、ルームサービス、請求) は マイクロサービス です。 問題: クライアントからサービスへの直接通信 ゲートウェイがどのように機能するかを説明する前に、ゲートウェイを「使用しない」場合に何が起こるかを見てみましょう。 e コマース アプリケーションに 3 つの個別のマイクロサービスがあるとします。 ユーザー サービス (プロファイルを管理) 製品サービス (カタログの管理) 注文サービス (チェックアウトの管理) API ゲートウェイがない場合、クライアント アプリは個別のリクエストを各サービスの個別のアドレス (IP または URL) に直接送信する必要があります。

組織がモノリシック アーキテクチャからマイクロサービスに移行するとき、サービスの境界線をどのように引くかという、一か八かの重大な問題に直面します。 理論的には、マイクロサービスは、独立して開発、デプロイ、スケーリングできる、緩やかな分離されたユニットである必要があります。しかし、実際には、多くのチームが 分散モノリス を構築することになります。これは、サービスが非常に密接に結合されているシステムであり、1 つのビジネス変更で複数のサービスを同時に変更および展開する必要があり、ネットワーク遅延と展開の行き詰まりが悪化します。 この落とし穴を避けるために、ソフトウェア アーキテクトは ドメイン駆動設計 (DDD) に注目します。 2003 年に Eric Evans によって初めて導入された DDD は、コード構造をそれが表す複雑なビジネス ドメインに適合させるソフトウェア開発方法論です。 この記事では、クリーンで分離された、保守性の高いマイクロサービスを設計するための戦略的および戦術的な青写真を DDD がどのように提供するかを見ていきます。 1. 戦略的青写真: サービスの境界線を引く DDD は、戦略設計 と 戦術設計 という 2 つの主なフェーズに分かれています。戦略的設計とは、ビジネス コンテキストをモデル化し、サービスの境界を定義することです。アーキテクチャの「マクロ」ビューを提供します。 A. ユビキタス言語 企業内では、異なる部門が同じ言葉をまったく異なる意味で使用します。たとえば: 営業チームにとって、「ユーザー」は見込み客または潜在的な顧客です。 セキュリティ チームにとって、「ユーザー」はログイン資格情報のセットです。 配送チームにとって、「ユーザー」は物理的な受信者の住所です。 すべての人を満足させる「ユーザー」向けの単一の統合データベース モデルを構築しようとすると、大規模で複雑なコードベースが作成されます。 DDD は、ユビキタス言語 (特定の境界内でビジネス ドメインの専門家と開発者の両方によって定義および使用される共有語彙) を確立することでこの問題を解決します。