マイクロサービスの最難関、どうするDB分割？
「マイクロサービスアーキテクチャー」はどれくらい世に広まっているだろう。小さなサービスを疎結合に組み合わせ、一連のアプリケーションを構成するマイクロサービス。ソフトウエアの改変しやすさに強みがあり、米ネットフリックスや米アマゾン・ドット・コムといった、サービス改善のスピードを突き詰めたいネット企業を中心に導入が進んできた。 日本でも活用事例は増えている。日経SYSTEMSの特集記事「マイクロサービスの現実解」では、全日本空輸（ANA）や楽天トラベル、モノタロウなどを取り上げた。メリットが大きい半面、特に既存システムからの移行は一筋縄では行かないという印象だ。マイクロサービスの難しさを考えてみたい。 従来型システムに比べたマイクロサービスのメリットは明らかだ。現在主流のWebアプリは、プレゼンテーションと業務ロジック、データアクセスの3レイヤーを一体で開発するのが一般的。こうしたモノリス（一
NGINX Microservices Reference Architectureの3モデルを紹介 - Evolutionary Architectures
Nginx, Inc.のMicroservices Reference Architecture(MRA)についてのドキュメントでProxyモデル、Router Meshモデル、Fabricモデルという3つのネットワーキングモデルが解説されている。 GoFのデザインパターン然り、名前が付いている、というのは重要なことだ。本項ではこの3モデルについて紹介する。 1. Proxyモデル Proxyモデルはマイクロサービスアプリケーションのフロント側にリバースプロキシクラスターを配置する。 出典元: MRA Part 2 – Proxy Model Proxyモデルは比較的単純であり、API Gateway、初期のマイクロサービス、もしくは、複雑なレガシーモノリシックアプリケーションを変換する際のターゲットとして適している。特に大規模なマイクロサービスやトラフィックについての負荷分散に適している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
