®マイクロサービス
独立した開発は助けになることもありますが、分散したサービスが多すぎると、それがかえって難しくなることもあります。意味のある業務上の境界を見極め、通信、データ責任、リリース、運用を含めて適切なアーキテクチャを実現します。
OTOKO®へのご依頼内容
業務部門と開発チームとともに、用語、ルール、変更点を検討します。頻繁に同時に変更する必要がある機能を、安易に分離すべきではありません。モジュール化されたモノリスは、分散運用を導入しなくても明確な境界を実現できます。マイクロサービスが選択肢となるのは、独立したチーム、負荷特性、リリース周期が明確な効果をもたらす場合です。この判断は、単に流行に従ってアーキテクチャを選ぶのではなく、運用面への影響とあわせて文書化します。
具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。
技術を分かりやすく解説
複数のサービスにまたがる案件には、共通のデータベーストランザクションが自動的に存在するわけではありません。状態遷移、一時的な不整合、補償アクションを計画します。アウトボックスパターンは、データ変更と発行するイベントを整合的に結び付ける助けになります。再試行には業務上の冪等性、つまり再処理時にも結果が一定であることが必要です。タイムアウトと依存関係には上限を設け、遅いサービスが処理チェーン全体を止めてしまわないようにします。これらのルールは、関係するチームが理解し、テストできるものである必要があります。
新しいサービスには、責任の所在、監視、設定、安全なリリース手段が必要です。選定した部分障害をテストし、個々のコンテナだけでなく、案件全体の挙動を観察します。引き渡しにはアーキテクチャの意思決定、インターフェース契約、ランブックが含まれます。既存のボトルネック、チーム構成、リリースの依存関係が、最初のアセスメントの最も重要な基礎情報となります。
検証可能な成果
引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。
貴社の取り組みの詳細
アプリケーションのどの部分を独立して変更・運用すべきかを検討します。マイクロサービスは、アーキテクチャ上の選択肢の一つです。重要なのは業務上の境界、チームの責任範囲、そして管理可能な運用手順です。
サービスには、分かりやすい業務上の役割が必要です。コンポーネントを切り出す前に、プロセス、データの所有関係、そして変更に伴う依存関係を調査します。複数のサービスが同じテーブルを共有し、常に同時にリリースしなければならない場合、望んだ効果は得られず、依存関係が分散するだけになることが少なくありません。
同期的な照会と非同期の処理ステップを明確に区別します。複数のサービスにまたがる業務プロセスについては、中間状態と補償アクションを明示的にモデル化します。たとえばキャンセルされた予約は業務上の操作であり、すべてのデータベースにまたがる任意の技術的ロールバックではありません。
複数のサービスを用いることで、通信経路が増え、部分的な障害が起こり得る状況が生まれます。処理の遅いサービスがアプリケーション全体を止めてしまわないように、タイムアウト、制限値、再試行を設計します。自動的な再試行を行うには、ある操作が意図せず複数回実行されないことが前提となります。
導入は、効果を測定できる限定された領域から始めます。ログ、トレース、デプロイ、オンコール対応に関する共通の基準を設けることで、サービスごとに独自の運用ルールが生まれることを防ぎます。想定される効果が工数に見合わない場合には、明確に構造化されたモジュール式アプリケーションの方が引き続き適した解決策となることもあります。
プロジェクトシナリオの例
例：文書生成処理が、負荷の高い時間帯に業務アプリケーションの速度を低下させているとします。その業務上および技術上の依存関係を確認し、必要に応じてこの処理だけを切り出します。結果は明確な処理ステータスを通じて提供され、その間もコア処理は制御された形で稼働を続けます。
この例は想定される進め方を説明するものであり、顧客事例ではありません。
最初の一歩の前に
いいえ。運用モデルは、サービスの数、スケーリング、要件によって決まります。Kubernetesが適することもありますが、業務上分離されたアプリケーションに必須というわけではありません。
いいえ。分散システムには、追加の調整作業と運用負荷が伴います。貴社の実際の依存関係とボトルネックに照らして、その効果を検証します。
