BT

マイクロサービス設計概論

作者: Jan Stenberg , 翻訳者 吉田 英人 投稿日 2014年6月27日 |

原文(投稿日:2014/06/15)へのリンク

我々はモノリスのようなソフトウェアの大きな塊の構築を続けた末に,SOAへと移行した。それでも問題は解決せず,今はマイクロサービスに移りつつある — 先日のJavaプラットフォームによる耐脆性(anti-fragile)マイクロサービスの設計と開発を紹介する中で,Russ Miles氏はソフトウェア開発の現状をこのように説明した。

氏は岩盤,岩,小石を比較する。モノリスはあたかも岩盤のように,変更も移行も極めて難しい。SOAは岩のようで,同じように移行が難しい上,期待するほどのメリットは実際には得られていない。マイクロサービスは小石のように,自由に変更することができる。

氏が述べている耐脆性とは,システムの破棄を厭わない,ということだ。 変化を抱擁するだけではなく,それを糧としてこそ我々は成長できる。これを達成するための出発点として氏が挙げるのは,同じ目的のためにひとつの仕事を行う多数の小さなパーツ,という簡潔な構造だ。シンプルなコンポーネント,シンプルなシステム設計こそが,マイクロサービスに移行するための鍵となる。重視すべきはコンポーネントの発展であり,発展と変化を可能にするシステム構築方法なのだ。

氏が考えるマイクロサービスとは,実行時と設計時において重視すべき問題を検討してシステムの進化をサポートする上で,適切な粒度の処理が可能な,単一目的のサービスのことである。そこで重視されるのは,アーキテクチャの全体的変更による変化をサポート可能な詳細さを持って初めて適応可能な,ソフトウェア構造を構築することだ。

マイクロサービスはSOAとして正しい方法なのだろうか? SOAで氏が問題とするのは,SOAという名称自体が非常な重荷になっているのではないか,という点だ。SOAとマイクロサービスのアーキテクチャ的な最大の違いは,システムを通じたデータの流れにある,と氏は主張する。UNIXパイプラインと同じく,重要な抽象化としてのデータパイプラインである。氏はこのパイプラインを,マイクロサービス開発を推進する理由として非常に重要なものだと考えている。レイヤ構成されるサービス階層が一般的なSOAでは,このデータフローはサービス内で編成されるため,外部から認識することはできないのだ。

マイクロサービスについて氏が耳にする大きな不満のひとつは,システムを多数の小システムに分解することで管理や監視面に問題があるのではないか,というものだ。それに対して氏は,OKやエラーを送信するようなサービスを開発してはならないとアドバイスする。そうではなくて"実行情報",つまり問題の内容とともに対処手段も返送することが必要だ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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でリプライする

ディスカッション
サイト全般について
バグ
広告
記事
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com and 株式会社豆蔵 InfoQ Japan hosted at Contegix, the best ISP we've ever worked with.
プライバシー
BT

広告ブロッカーを使用されています。

何かの理由で広告ブロッカーを使用されていることと存じますが、InfoQを今後も無料でお使いいただけるようにするために、広告の表示にご協力いただけますと幸いです。InfoQはあなたの許諾なしに第三者にあなたの情報を提供することはありません。広告は読者の皆さんに関連するもののみを表示いたします。広告表示可能なサイトとしてご登録いただけますと幸いです。