マイクロサービスについて

マイクロサービスについての勉強メモ

・社会の急激な変化・開発期間の単位が短くなる傾向から、昨今注目されているソフトウェアのアーキテクチャが「マイクロサービス」
・米国の著名なソフトウェアエンジニアである、マーチン・ファウラー氏らが2014年に公開した「Microservices」という記事で世間に知られるように
・マイクロサービスは、個別に開発された小さなサービスを組み合わせて、一つのサービスを提供するというものです。

例:オンラインショッピング全体がひとつの大きなサービスとすると以下のようなサービスを組み合わせて作る
・認証サービス(IDやパスワード)
・ロジック:データのフィルタリングサービス(サイズや色)
・ロジック:レコメンデーションサービス(おすすめ商品の通知)
・アクセス許可:在庫管理システム連携サービス
・データ:販売実績の追加、配送ステータス管理サービス
メリットは以下
開発チームがサービスごとに分かれて、得意な言語を利用して各サービスの開発を進めることができる
変更をかけたいときは、システム全体ではなく、その小さなサービスごとに変更をかけられる
小さなサービスで開発単位を進めるため、ビルドやテストの期間が短くなり開発効率が上がる
モノリシックなシステムだと何か障害が起きたときに、どこがおかしいのかルート構造をたどるのに時間がかかるが、原因の突き止めが比較的容易

実現手段
Salesforce Platformでは、作成する機能やアプリケーションを標準でWeb API化することができるので、マイクロサービスとしても利用することが出来ます

・DX推進の手段として「コンテナ」や「マイクロサービス」が注目を集めていますが、これらの理解に問題があるケースも多い

周知の通り、マイクロサービスは機能や役割ごとに分けた小さな単位で1つのシステムを構成する考え方です。メリットの1つとして、システム改修の際に影響範囲を限定できるため、テスト工数を削減できることがあります。ただ全体のコストを削減できるわけではないので、コスト削減のためにマイクロサービスを導入するというのは間違いです。マイクロサービスが実現できれば、機能の追加・改善が容易になるため、アプリケーション、すなわちビジネスの開発・改善サイクルをスピーディーかつ継続的に回せるようになる。コスト削減ではなく、移り変わる市場ニーズに追従することで、着実に収益を増やしていくための手段の一つなんです

・マイクロサービスを正しく使うために、経営と現場は何をすべきか

単機能のサービスを組み合わせて、1つのシステムを構成するのがマイクロサービスアーキテクチャですから、まず各機能をどのような粒度、種類で切り分けるかという問題があります。その上で、機能(サービス)ごとにチームを構成するのが一般的です。

 こうした機能ごとのチーム構成でポイントとなるのは、各チームに対する権限付与です。責任範囲を明確化し、「ここまではあなたたちが責任を持ち、ここから先はわれわれが責任を持つ」といった理解をチームに浸透させる必要があります。こうした体制づくりは、経営サイドも積極的に協力しなければ作ることができません。

マイクロサービスのデメリット
モノリスのメリットが失われる
┗密結合による効率性
システム間連携で発⽣する問題が機能間連携で発⽣するようになる
┗代表例はデータの不整合、ネットワークレイテンシ
システム全体の運営ノウハウが全く異なる
┗管理対象が圧倒的に増えるため、これまでのシステム横断 管理⼿法ではオーバーヘッドが⼤きすぎる

マイクロサービス化の基本的なアプローチ
・対象システムを段階的にマイクロサービス化
・徐々に適用レベルを上げていく
レベル1:モノリス:機能はシステム内で密結合している
レベル2:API連携:モノリスとAPI連携するサービスがある
レベル3:複雑なサービス:基盤が整備され、DevOpsにも取り組む
レベル4:一般的なMSA:非同期キュー利用や無停止リリース
レベル5:高度なMSA:数十~数百のサービス
レベル6:先進的なMSA:数百~数千のサービス
レベル7:世界最先端なMSA:数千のサービス、MSA技術の開発
基本戦略:ストラングラーパターン
対象システムをマイクロサ ービス化するにあたり、対 象システムに⼿を⼊れては いけない
「既存システムを分割して 機能を切り出す」のではな く「新しく作ったサービス で機能をすり替える」
(既存システムは使わないようにしていく)

・新しいサービスに対するアプローチ:開発はアジャイル(継続的に改善、オーナーはビジネス側、既存の組織とは分断しているとよい)
・運用は自動化していく
運用の主体は開発チーム。DevOpsチームが自動化を実現し開発チームがそれらを利用して運用する
・サービス間連携もマネージドサービス化(認証認可、ロギング、メッセージ連携、APIゲートウェイなど。基盤チームが整備する)

サービスの分割の考え方
・ともかく「ビジネスに貢献するか」
・適切なサイズであること(1チーム(3-7名)が4週間以内に初期構築できること)

DX時代のシステム開発
・「機能間調整」が早さを阻害する
・機能間の依存関係を低くして調整を減らす

<参考>
https://www.salesforce.com/jp/blog/2016/03/microservices.html

シェアする

  • このエントリーをはてなブックマークに追加

フォローする