BT

マイクロサービスの配置とビルドのパターン

| 作者: Jan Stenberg フォローする 37 人のフォロワー , 翻訳者 徳武 聡 フォローする 1 人のフォロワー 投稿日 2014年7月27日. 推定読書時間: 2 分 |

原文(投稿日:2014/07/08)へのリンク

マイクロサービスを管理するのは、互いに通信しあい、自動的にプロビジョニングするたくさんの小さなシステムの面倒を見ることであり、インフラの自動化が極めて重要だ、とJames Lewis氏は言う。氏はマイクロサービスアーキテクチャがもたらす、増大する運用の複雑性に対処するための方法を共有する中で、このように書いている。

氏はThoughtWorksのコンサルタントであり、マイクロサービスの起源をテストや変更、管理が難しい巨大な一枚岩アプリケーションを開発してしまったことに対する反動であると説明している。つまり、スパゲッティコードが絡み付いた巨大な泥だんごに対する反動というわけだ。解決策として小さなシステムを作り、それらが互いに通信するようにしたのがマイクロサービスだ。

氏にとってマイクロサービスとは、大規模なアプリケーションの境界ビジネス機能を特定し、それに基づいて分割をして、ひとつの統合されたデータベースではなくアプリケーションデータベースにデータを格納するようにする、ということだ。重要なのはコンテキストマップの頂点から始めることだ。ビジネスのドメインを理解するためだ。氏は同僚のIan Cartwright氏に言及して次のように言う。

ビジネスとアーキテクチャは異種同形になるべきです。ビジネスパーソンはハイレベルのアーキテクチャマップを探し、ビジネスそこに反映されているかを考える必要があります。同様に技術者もビジネスを探り、アーキテクチャが反映されているかを考える必要があります。

マイクロサービスの重要な側面はサイズだ。James氏は単一責任パターン(SRP)が良い物差しになる、という。ひとつのサービスにはひとつの変更理由しかない。これによってサービスは小さくなり、概念的につかむことができる程度の大きさになる。

氏にとってマイクロサービスのコンセプトは独立して配置、スケールできるということだ。サービスは複数のインスタンスとして配置され、異なるサービスが同じサーバにホストされる場合もある。分散システムを開発し配置する場合、自動プロビジョニングへ注力するが重要だ、とJames氏は強調する。各サービスやアプリケーションは自動的にビルドされスケールされなければならない。統合は多くの複雑さを生むが、マイクロサービスを導入することで解決できる。また、氏は書籍Continuous Deliveryに言及してパイプラインを構築するパターンを紹介している。

ChefPuppetのようなインフラ自動化ツールは自動プロビジョニングを支援してくれる。これらのツールは多くのサービスから生まれる複雑さを管理する上で中心的な役割を担う。Phoenixのインフラパターンは自動化に仕組みと使ってどうやってインフラ全体を常に再作成できるようにするかについて説明をする。例えば、スクリプトを実行してインフラをすべての依存物とともに完全にビルドし直すというような処理だ。

James氏が言及するマイクロサービスカンファレンスは11月末にロンドンで開催される。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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