Software Architecture

10 年以上にわたり、Spring Boot はエンタープライズ Java アプリケーションを構築するための事実上の標準として君臨してきました。 Java は、その豊富なエコシステム、構成より規約のパラ​​ダイム、堅牢な依存関係注入エンジン、および大規模なコミュニティ サポートにより、世界中のバックエンド システムの基盤となっています。 しかし、クラウドネイティブ アーキテクチャ、Kubernetes オーケストレーション、Docker コンテナ化、サーバーレス実行 (AWS Lambda、Knative) への移行により、メモリ効率、インスタント スケーリング、コールドスタート レイテンシといった新しい技術的課題がバックエンド インフラストラクチャに導入されました。 従来の Java フレームワークは、長時間稼働するモノリシック サーバー向けに設計されており、元々は一時的なコンテナ化環境向けに設計されたものではありませんでした。マイクロサービスが Kubernetes 上で 0 から 50 のインスタンスまで水平にスケールしたり、短期間のサーバーレス関数として実行したりする場合、200MB 以上のヒープ メモリを消費しながら、Java 仮想マシン (JVM) プロセスが起動するまで 3 ～ 10 秒待機すると、運用上および財務上のハンディキャップが生じます。 Quarkus は、特に GraalVM および OpenJDK HotSpot 向けに Java を調整するためにゼロから構築された Kubernetes ネイティブ Java フレームワークです。 「Supersonic Subatomic Java」 と呼ばれる Quarkus は、Java コードのコンパイル、起動、実行方法を根本的に再定義します。

30 年近くにわたり、Java はエンタープライズ ソフトウェア開発の主流となってきました。その豊富なエコシステム、堅牢なオブジェクト指向基盤、Java 仮想マシン (JVM) によるプラットフォームの独立性、および Spring Boot などの歴戦のフレームワークにより、バックエンド インフラストラクチャの明白な王者となりました。 しかし、クラウドネイティブ アーキテクチャ、Kubernetes オーケストレーション、コンテナ化 (Docker)、サーバーレス コンピューティング (AWS Lambda、Knative) への移行により、高いメモリ オーバーヘッドと遅い起動時間という、従来の Java アプリケーション フレームワークの深刻な脆弱性が明らかになりました。 トラフィックの急増に対応してマイクロサービスがレプリカを 0 から 100 まで水平にスケールする必要がある場合、またはサーバーレス関数がオンデマンドで実行される場合、Java プロセスの起動を 3 ～ 10 秒待つことは許容できません。最新のクラウド インフラストラクチャでは、即時起動と軽量メモリ消費が求められます。これらの特性は従来、Go、Rust、Node.js などの言語に限定されていました。 Quarkus は、GraalVM および OpenJDK HotSpot 向けに特別に設計された Kubernetes ネイティブ Java フレームワークです。 「Supersonic Subatomic Java」 とも呼ばれる Quarkus は、Java アプリケーションのコンパイル、ブート、実行方法を根本的に再設計します。 この詳細なガイドでは、Java 開発者が Quarkus を採用する理由、Quarkus が 1 秒未満の起動時間とマイクロメモリの使用量をどのように達成するか、ビルド時間の最適化 のアーキテクチャの仕組み、および Quarkus を使用して Java で本番環境に対応したリアクティブ マイクロサービスを構築する方法について説明します。

マイクロサービス アーキテクチャでは、サービスは分散ネットワーク呼び出しの 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) に直接送信する必要があります。

モノリシック アーキテクチャでは、コンポーネントはメモリ内のメソッド呼び出しを介して通信します。これは瞬時に行われ、信頼性が高くなります。ただし、マイクロサービス アーキテクチャに移行すると、これらのコンポーネントはネットワーク境界によって分離されます。通信はアウトプロセス ネットワーク呼び出し (プロセス間通信、つまり IPC) になります。 長年にわたり、JSON ペイロードを使用した HTTP/1.1 経由の REST (Representational State Transfer) が、Web API を構築するためのデフォルトの標準となってきました。 REST は、公開 Web サービスやクライアントとサーバー間の対話には優れていますが、高頻度で低遅延の内部サービス間通信に使用すると、重大なボトルネックが発生します。 このため、最新のマイクロサービスは gRPC (Google Remote Procedure Call) に急速に移行しています。この記事では、REST の制限を分析し、gRPC のアーキテクチャの柱を詳しく分析し、Java での gRPC サービスの完全な実装について説明します。 1. マイクロサービスにおける REST のボトルネック REST は 20 年以上にわたって Web を支えてきました。ただし、その基盤となるテクノロジーは、内部分散アーキテクチャ用に最適化されていません。 A. プレーンテキスト JSON のオーバーヘッド JSON は人間が判読できるため、デバッグが容易ですが、マシン間の通信には非常に非効率です。 シリアル化/逆シリアル化のコスト: テキスト文字列トークンを解析してオブジェクトに変換すると、かなりの CPU サイクルが消費されます。 大きなペイロード サイズ: JSON キーは単一のリクエストごとに繰り返されます (例: {"transactionId": "123", "amount": 99.99})。 1 秒あたり何百万ものリクエストを処理するシステムの場合、この冗長なメタデータは膨大なネットワーク帯域幅を浪費します。 B. HTTP/1.1 接続の制限 REST は通常、HTTP/1.1 上で実行されますが、これにはいくつかの構造的非効率性があります。

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

Web 開発の初期の頃、ソフトウェア アプリケーションの構築は簡単でした。コードを記述し、それを単一の実行可能ファイルまたは展開可能なアーカイブにパッケージ化し、サーバー上で実行するだけでした。 モノリシック アーキテクチャとして知られるこのアプローチは、何十年にもわたって業界に役に立ちました。 しかし、アプリケーションが数百人の開発者と数百万人の同時ユーザーを抱える大規模なエンタープライズ プラットフォームに成長するにつれて、モノリスには限界が見え始めました。デプロイメントは遅くなり、リスクが高く、データベースがボトルネックになり、コードベースが複雑すぎて単一の開発者が理解できないようになりました。 これらのスケーリングのボトルネックを解決するために、業界は マイクロサービス アーキテクチャ に移行しました。開発者は、単一の巨大なアプリケーションを構築するのではなく、HTTP/REST、gRPC、メッセージ ブローカーなどの軽量プロトコルを介して通信する、小規模で独立した疎結合サービスのコレクションにシステムを分割します。 この記事では、マイクロサービスが最新のアプリケーションにもたらす主な利点、マイクロサービスによってもたらされる深刻な課題、そしてこのアーキテクチャが次のプロジェクトに適しているかどうかを判断する方法を分析します。 1. モノリシック アーキテクチャとマイクロサービス アーキテクチャ 詳細に入る前に、これら 2 つの設計パラダイムの基本的な違いを視覚化しましょう。 モノリスでは、すべてのモジュール (ユーザー管理、製品カタログ、注文処理など) が同じ実行スペースを共有し、単一の共有データベースに書き込みます。 マイクロサービス セットアップでは、各サービスが独自のプロセスで実行され、独自のプライベート データベースを管理し、クリーンな API を公開します。 API ゲートウェイ はクライアントの単一のエントリ ポイントとして機能し、リクエストを適切なバックエンド サービスにルーティングします。 2. マイクロサービスの利点 マイクロサービス アーキテクチャを採用すると、大規模な最新のシステムに推奨される選択肢となる、いくつかの魅力的な利点が得られます。 A. 独立した展開可能性とリリース速度 モノリスでは、チェックアウト システムに小さな変更をデプロイするには、アプリケーション全体を再構築して再デプロイする必要があります。 1 つのチームの機能が壊れると、リリース全体がブロックされます。 マイクロサービスでは、各サービスに独自の独立した CI/CD パイプラインがあります。配送サービス チームは、在庫チームや支払いチームと調整することなく、1 日に 10 回アップデートを展開できるため、機能の配信速度が大幅に向上します。

現代のソフトウェア エンジニアリングでは、複数のタスクを同時に実行できるアプリケーションを構築することはもはや贅沢ではなく、中核的な要件となっています。高スループットの Web サーバーからリアルタイム ストリーミング サービスに至るまで、同時実行性はパフォーマンスの中心です。 何十年もの間、C++、Java、Python などの従来のプログラミング言語は、オペレーティング システムのネイティブ スレッド モデルに依存して同時タスクを処理していました。しかし、2000 年代後半に Google が Go (Golang) を設計したとき、彼らは根本的に異なる道を歩みました。 Go は、生の OS スレッドを公開する代わりに、Goroutines と特殊な M:N Scheduler を導入しました。 この記事では、従来のスレッド モデルのアーキテクチャ上の制限を検討し、Go の同時実行設計が大幅に効率的でスケーラブルで開発者に優しい理由を探ります。 1. 従来のスレッディング (1:1 モデル) のボトルネック 従来のランタイム システムのほとんどは 1:1 スレッド モデル を使用します。このモデルでは、ユーザー空間コードで作成されたすべてのスレッドが、オペレーティング システム (OS) によって管理される 1 つのカーネル空間スレッドに直接マップされます。 この 1:1 マッピングは単純ですが、次の 3 つの重大なボトルネックを引き起こします。 A. メモリのオーバーヘッド (大きなスタック サイズ) OS スレッドは重いリソースです。デフォルトでは、オペレーティング システムは各スレッドに固定の連続したスタック サイズ (通常は 1MB ～ 8MB) を割り当てます。

大規模言語モデル (LLM) は、私たちがテクノロジーと対話する方法を変革し、単純な会話型チャットボットから、複雑な複数ステップのアクションを実行できる推論エンジンへと急速に移行しました。単一のプロンプト応答インタラクションは強力ですが、企業環境における生成 AI の真の価値は 自律 AI ワークフローにあります。 人間のオペレーターに依存してすべてのステップを調整するのではなく、自律型ワークフローは、長期間にわたってタスクを計画、実行、評価、自己修正する中心的な意思決定者として LLM を使用します。 この詳細な説明では、最新の設計パターン、ステート マシン、堅牢なガードレールを使用して、信頼性の高い自律型 AI ワークフローを設計、構築、展開する方法を探ります。 1. エージェントの変化: チャットボットとワークフロー LLM アプリケーションの進化は、自律性の 4 つの異なるレベルに分類できます。 レベル パラダイム 人間の役割 コアメカニズム レベル 1 会話型チャット 高 (毎ターンプロンプトが表示されます) ステートレスな 1 ターンの完了 レベル 2 ツール呼び出し / 関数呼び出し 中 (コンテキストを提供) モデルは呼び出す API を選択します。結果を返します レベル 3 指示されたワークフロー 低 (目標とグラフを定義) LLM ルーティングを備えたハードコーディングされたステート マシン レベル 4 完全自律型エージェント 最小限 (目的/予算を定義) LLM 主導の計画、実行、およびリフレクション ループ レベル 4 エージェントは柔軟性に優れていますが、運用環境での予測が難しいことで知られています。したがって、ほとんどのエンタープライズ アーキテクチャは、ソフトウェア ステート マシンの決定論的な信頼性と LLM の動的な推論を組み合わせた レベル 3: 指示されたワークフロー に基づいて構築されています。