実適用のポイントと「9つの特徴」1~4一覧はこちら前回、これまでの連載の内容とマイクロサービスの「9つの特徴」との紐付けや特徴同士の関係性を説明しました。「9つの特徴」のうち4つを説明しました。最終回の今回は残りの5つの特徴を説明した後、マイクロサービスの適用シーンについてまとめたいと思います。組織で開発プロセスやフレームワークを「標準化」することで、人材の流動性を高められるといったメリットが得られるなどの理由で中央集権型が当たり前のように語られてきました。マイクロサービスの文脈においては、分散統治が推奨されます。「全ての問題が釘ではなく、全ての解決方法がハンマーではない」のです。非機能の観点では、超高性能を求められる業務にはNode.jsやmemcachedといった選択肢がある一方で、そうでない業務には通常通りJavaでRDBMSを選択するといった使い分けが考えられます。Monolithなアプリケーションにおいても、こういった使い分けは可能ですが、マイクロサービスは、サービス間の独立性を確保できるため、分散統治がやりやすいと言えます。Design)という言葉を聞いたことがあるでしょうか。業務のドメインの境界を定義し、その単位で区切って開発します。これは、前述のNo2「ビジネス遂行能力に基づいた組織整理」での分割により効果的に実現されます。データの管理単位に目を向けると、Monolithなアプリケーションにおいてはシステムで一つのデータベースが好まれます。マイクロサービスにおいては、「分散データ管理」と呼ばれ、それぞれのサービスの単位でのデータベースが好まれ、それぞれのデータベースは異なるRDBMSでも構いません。Persistenceと呼びます。データが分散するということは、当然ながら相互に関連するデータの場合、一貫性の管理が必要となり、Monolithなアプリケーションであれば、2フェーズコミット等を用いたトランザクション管理により実現される場合が多くなります。マイクロサービスにおいては、サービス間を密結合になってしまうことを避けるため、「サービス間のトランザクションレスな連携を重要視」します。この連携方式においては、一貫性は結果的に満たされていればよく、問題が起った場合は補完処理(お金に絡む場合は補償処理)されます。一貫性の確保により失われる機会損失のコストは補償にかかるコストよりも大きいという、ある種の割り切りの考え方に基づいています。した非一貫性を前提としたデータ管理はある種のチャレンジであり、マイクロサービスサービス適用の上での注意点となります。:インフラの自動化インフラの自動化技術はここ数年で目覚ましく進化しています。Delivery:継続的デリバリ)がその中核にあり、インフラの自動化の中では、以下の2点の自動化に着目しています。連載第6回で紹介した内容に当てはめると、第二・第三の自動化が該当します。テスト自動化に関しては、単体テスト・機能テスト・パフォーマンステストといった一連のテストを自動化するものです。デプロイ自動化については、開発環境・ステージング環境・本番環境へのデプロイを自動化します。:障害発生を前提とした設計マイクロサービスが全ての点において、Monolithなアプリケーションよりも優れているというわけではありません。サービスを小さな単位で分割しているが故に、呼び出される側のサービスの稼働状況に起因して呼び出し側の処理が失敗する可能性があり、この状況にうまく対応する設計が必要となります。failure:障害発生を前提とした設計」です。ここでいう設計とは、耐障害性設計と監視設計のことを指します。Netflixでは、主に平日日中帯のオンライン時間帯に、サービスやデータセンタ単位で「敢えて」障害を発生させます。これにより、開発・運用チームは耐障害性と監視の有効性について、絶えず検討・改善することができます。サービスはいつでも停止し得るため、即時検知および可能であれば自動回復の仕組みが重要となります。多くの開発プロジェクトにおいては、個々のサービスごとに、以下を一覧表示するいわゆるダッシュボードが活用されます。:進化的な設計マイクロサービスの導入を検討する際は大きく以下の2通りが考えられます。本節では後者について説明します。「進化的な設計」システム開発の全てが新規開発で、一度作れば終わりというわけではありません。機能追加・削除やハード更改などが行われ、いわば進化していくため、変更容易性が重要となります。当初GurdianのWebサイトは、Monolithで構築されました。いったアプローチはスポーツイベントの特設サイトのような一過性のイベントサイトを構築する際に有効です。Webサイトを構築する際は高生産性が期待できる言語を用いて開発し、イベント終了後削除するのも容易です。金融機関においても同様のアプローチが見られます。マーケティング用のWebサイトを構築し、数ヶ月あるいは数週間にて削除されます。マイクロサービスは銀の弾丸かMonolithなアプリケーションと比較し、マイクロサービスが銀の弾丸となり得るわけではなく、「6.分散データ管理」や「8.障害発生を前提とした設計」等の特徴を踏まえた適用が必要ですし、「9.進化的な設計」にて示されるように、マイクロサービス適用のアプローチを選定していくことが重要です。SIerの立場から言えば、請負開発でフェーズや業務・基盤等の役割で分割したチーム構造になることが多く、マイクロサービスがそのまま適用できるとは限りません。Appに代表されるような、いわば開発標準に相当するものをシステム開発の特性に応じたかたちで整備したりするなどが必要になってくるでしょう。Fowler氏がMicroservicePremiumにて、「複雑さ」に応じてMonolithとマイクロサービスを選択すべきだと述べています。「複雑さ」を表す要素はチームの大きさやマルチテナントなどが挙げられています。Delivery)を実現できないほど複雑なMonolithなアプリケーションに対しては、生産性を大きく下げる要因となるためマイクロサービスを選択すべきです。チームのスキルも選択における大きな要素となります。「複雑さ」と「生産性低下」の関係性の観点でのMonolithとの違い連載を振り返ってこれまで9回に渡って、マイクロサービスをさまざまな切り口から解説しました。マイクロサービスそのものは新しい技術というよりは、さまざまな技術の組み合わせで実現されているため、紹介した技術の一部は既に採用しているという方も多かったのではないでしょうか。オンプレミスからクラウドへ大きく舵を切っていく潮流の中で、マイクロサービスは今後中心となっていく可能性を秘めています。本稿の内容を読者の皆様の技術の引き出しの一つとしてお役に立てれば幸いです。以下に連載回次別の掲載トピックを載せておきますので、気になるところがあれば、見返してみてください。シニア・エキスパート2011年頃まで開発自動化技術のR&Dに従事。その後、開発プロジェクト支援やトラブルシューティング等に主戦場を移す。Code等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。Azure」を自社内に展開できるクラウド基盤のことです。企業内のプライベートクラウドとして、もしくは国内のクラウド事業者が提供するクラウド基盤として注目されています。Stackの概要とAzureとの違いについて解説します。人気記事をお届けしますダウンロードBOXに入れる記事をダウンロードBOXに追加します。よろしいですか?ブックマーク記事をブックマークに追加します。Corporation。