BT

Your opinion matters! あなたのご意見でInfoQが変わる!

Qcon LondonにおけるJonas Boner氏による'モノリスからマイクロサービスへ'の講演

| 作者: Daniel Bryant フォローする 209 人のフォロワー , 翻訳者 笠原 王徳 フォローする 0 人のフォロワー 投稿日 2017年3月16日. 推定読書時間: 5 分 |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

原文(投稿日:2017/03/12)へのリンク

QCon Londonにおいて、LightbendのCTOであるJonas Boner氏は'モノリスからマイクロサービスへ'という講演を行った。Boner氏はマイクロサービスを最初の原則から検討し、分散システムの文脈でのアーキテクチャスタイルについて考察した。主題は以下である。小さいモノリスを構築することを避け、代わりに回復力があり弾力性のあるシステムを構築すること。システム内の結合度と通信を最小化すること。リアクティブプログラミングやリアクティブシステム設計、そして結果整合性を活用することにより"現実を受け入れる"こと。スケーラビリティの確保を容易にするために、ステートレスな振る舞いをステートフルなエンティティから分離すること。イベントを中心に据えてドメイン駆動設計(DDD)を実践すること。

Boner氏は"オールマイティなモノリス(の設計上の単純さ)が物事を損なう要因だった"という言葉から講演を始めた。モノリスのコードベースに対して開発行為をスケールさせるための挑戦によりマイクロサービスアーキテクチャスタイルの採用が進んだが、このスタイルは現在の多くの組織にとって'必要悪'となった。マイクロサービスは分散システムに有効であり、開発者はその結果個々のマイクロサービスとアーキテクチャ全体の両方を設計せざるを得なくなった。

アクターベースのアプリケーション、つまり任意の複雑なタスクを完了させるための複数のアクターによる構成と非常に類似した、マイクロサービスベースのアプリケーションは、複数のサービスの組み合わせにより実現される分散システムとして設計されるべきである。

各マイクロサービスは分散システム、つまりマイクロシステムとして設計される必要があります。モノリスからこのマイクロシステムに移行していく必要があります。

Boner氏は多くの開発者が現在'モノリス'を構築していると投げかけた。マイクロサービスの単一のインスタンスには回復力や弾力性がない。'The Reactive Manifesto'を参照し、回復力や弾力性を獲得するための方法には以下が含まれるとした。

  • 中央集権的でないアーキテクチャ
  • バルクヘッドパターンの採用
  • 複製
  • 失敗の検知
  • Supervisionの概念の採用
  • ゴシッププロトコルの採用
  • 自己組織化
  • 位置透過性

Boner氏は、可能な限り早くサービスを終了するか、'非決定性の荒波'が存在する個々のマイクロサービスの外部システムとやりとりすべきであると警告した。光速が通信速度の限界を設定するように、システムは現実を反映していなければならない。Pat Helland氏を引用し、全ての情報には遅延が存在しており、この影響で分散システム通信においては常に過去を観測することになる、とBoner氏は述べた。開発者は結合度と通信を最小化し、結果整合性を受け入れる努力をすべきである。

結果整合性に頼る必要があります。しかし、身構える必要はありません。それが本来の世界の姿なのです。

Boner氏はマイクロサービスシステムを設計するための手法として、リアクティブ設計とイベントを中心に据えたDomain-Driven Design (DDD)を提案した。RxJavaのようなリアクティブプログラミングは個々のサービスインスタンスを高性能・高効率にするための支援を行う。非同期メッセージパッシングを土台としたリアクティブシステムは、弾力性・回復力を持った分散システムの構築を支援する。マイクロサービスを非同期・ノンブロッキングに実装することにより、リソースをより効率的に使用し、共有リソースの競合を最小化することができる。常にback-pressureを適用すること。高速なシステムは低速なシステムに過剰な負荷を与えてはならない。

各々のマイクロサービスは分散システム、つまりマイクロシステムとして設計されるべきであり、個々のサービスのスケーラビリティを確保するために、ステートレスな振る舞いはステートフルなエンティティとは分離されるべきである。このエンティティは'決定論的な安全な島となり、強い一貫性'を獲得しうる。ステートレスな振る舞いをスケールさせるのは容易だが、ステートフルなエンティティをスケールさせることは困難であるというのも重要な点である。

There is no such thing as stateless architecture

Boner氏は開発者はイベントを中心に据えたDDDを実践すべきであること、及び今現在を表現する内部のデータ、過去の事実を表現する外部からのデータ、そして未来のアクションとして使用されるコマンドから構成される、'一貫性のある境界'の観点で検討すべきであることを示唆した。

物事、つまり名詞に焦点を当ててはなりません。何が発生したか、つまりイベントに焦点を当てるのです!イベントに、境界付けられたコンテキストを定義させるのです。

マイクロサービスには任意の変更可能な状態と公開される事実が含まれるべきである。Pat Helland氏の言葉を再び引用し、Boner氏はイベントのロギングについて検討し、イベントログは'過去をデータベース化'したものであり真実に関する変更可能な単一の源であるべきだと述べた。イベントのロギングは悪名高いオブジェクト-リレーショナル間のインピーダンスミスマッチを避けることを可能とし、読み取り及び書き込みモデル(これらはしばしば異なる要件を持つ)のもつれは、Command Query Responsibility Segregation (CQRS)Event Sourcing (ES)により解消することが可能である。開発者は大規模でスケーラブルなアプリケーションを実装するのに分散トランザクションを前提とせずに、代わりに'推測・謝罪・補償'するプロトコルを使用するべきである。Boner氏はこのプロトコルを'世界の動作原理'であるとし、オフラインATMと飛行機のオーバーブッキングを例として挙げた。

Boner氏はLightbendのLagomというマイクロサービスのフレームについて簡単に触れることにより講演を締めくくった。このフレームワークはこの講演で触れた原則の多くを体現し、彼が執筆した無料のオライリーのレポートである'Reactive Microservices Architectures: Design Principles for Distributed Systems'でも紹介されている。'モノリスからマイクロサービスへ'のスライドはBoner'氏のSlidehareアカウントから閲覧することができる。

 
 

Rate this Article

Relevance
Style
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT