マイクロサービスのススメ Part1

SAPという会社でSAP Cloud PlatformというPaaSの製品担当をしています。

気が向いて不定期ブログを始めてみましたので、ゆるーく見ていただければと思います。 

 

今回は、SAP Cloud Platform Extension Factoryというマイクロサービスの製品がリリースされる事になったので、その紹介とクラウド上でのマイクロサービスの活用について書きたいと思います。 

マイクロサービス自体がわかりづらいところがあるので、ブログは２回に分け、初回の今回はマイクロサービスとは何かについて、２回目はSAP Cloud Platform Extension Factoryをベースにマイクロサービスの開発という流れで書いていきたいと思います。

第1回目の今回はマイクロサービスとは何かを、背景や要素技術も含めて書いていきたいと思います。

  • マイクロサービスとは

    ここ最近、マイクロサービスという言葉をよく聞くことがあると思いますが、そもそもマイクロサービスとは何なんでしょうか。Wikipediaによると

     マイクロサービスとは、ビジネス機能に沿った複数の小さいサービスに分割し、連携させることで大きいソフトウェア機能を実現するソフトウェアアーキテクチャ。（マイクロサービス - Wikipedia） 

    とあります。ざっくり言うとビジネス的な観点で、再利用可能な単位にコンポーネント化し、組み合わせることでアプリケーションを作ることです。

    しかし、マイクロサービス以前にも、APIファースト、ちょっと古いところでSOAなどでも同じようなアプローチで開発していたので、それらと何が違うのか混同してしまうと思います。そこにはマイクロサービスに至るまでの歴史がポイントになってくるので、流れに沿って書いていきたいと思います。

  • 手続き言語でのコード共通化時代

    製造業でも部品の標準化・規格化をすることで分業化、大量生産を実現してきたように、共通化をして組み合わせていくアプローチは古くから使われてきました。ソフトウェアの世界でもCOBOL/Cなどの手続き型言語の時代からサブルーチン化など共通化は当たり前でした。

  • オブジェクト指向言語の普及

    それが、オブジェクト指向言語の普及によって、カプセル化、インターフェースプログラミング（ポリモフィズム）などを活用して、コンポーネント化が加速し、ドメイン指向設計という考え方が生まれます。加えて同一サーバ内だけでなく、サーバー間をまたがった呼び出しのニーズが高まりCORBAが出てきます。

    ところが、CORBAやそのサブセットのEJBなどは実装のためにスタブなどを作ったり色々と面倒だったので、業務システムではそこまで普及しませんでした。

  • Web2.0とSOA時代

    そこで、もっと手軽に利用できるようにWebインターフェースでアクセス可能なXMLフォーマットのSOAPが普及します。その手軽さからWeb2.0の時代にはサービスを組み合わせるマッシュアップがコンシューマ向けに普及し、ビジネス向けにもXMLベースで、部門間をまたがるようなプロセス連携を実現するSOAが現れ、ESB/BPM/BAMベースのSOA製品が普及していきます。

  • スマートフォンとクラウドの登場と普及

    その後、iPhoneが発売され端末の主流がPCからスマートフォンに移行していきます。加えて、クラウドサービスの登場と普及によりas a Service化が進んでいく中でAPI化の流れが加速していきます。その中で、データフォーマットもスキーマレスが求められるようになり、データベースもBigTableやHbaseのようなNoSQLが、インターフェースもXMLではなくREST+JSONのスキーマレスフォーマットが主流になります。
    こうしてこれまでのモノリシックな開発から、フロントエンドとバックエンドを分離して開発を進めるAPIファーストが主流となっていきます。

  • そしてマイクロサービスへ

    APIファーストの浸透により、バックエンドシステムとの連携はAPIが中心となり、バックエンドのサービス化が進んでいきます。
    こうなってくると、単一のサービスだけではなく、複数のサービスを組み合わせてアプリケーションを構築する手法が求められるようになり、マイクロサービスアーキテクチャが提唱されました。
    マイクロサービス自体は概念的なものなのですが、重要なポイントをざっくり言うと、サービスはビジネス中心で切り離し可能なコンポーネントであること、サービス間のメッセージは軽量かつシンプル、immutable インフラ/アプリベースでDevOpsを実現していることが求められます。（正確にはもっとあるんですが長くなるので割愛）

 

簡単に流れを書くとこうなります。

共通化していこうという流れは昔からやっていたことで、マイクロサービスでも大きな流れは変わりません。ただ、その時々のトレンドに合わせて求められるニーズが変わって、時代に合わせた考え方が必要になっただけです。なので、大きな考え方はSOAやAPIファーストとも変わらないのです。

逆に言うと、昔から問題となってきたサービスの仕様や粒度の問題というのは今も変わらずあります。

  • サービスの仕様

    サービスの仕様は難しいもので、インターフェース用にスキーマをガッチリ決めてプロトコル化を進めるほど組み合わせと統制は取りやすくなるのですが、開発の手間がかかるのでアジリティ性は落ちます。
    XMLベースのSOAPからJSON形式のRESTに移り変わってきた流れを見てもこの辺りはよくわかると思います。

    とはいえ、REST/JSONではAPIごとに仕様を確認しながら実装しなければならないので、手間がかかると言う問題が発生してきたため、今はRESTful APIのドキュメントからコード、エディタやその仕様まで提供するSwaggerフレームワークをベースにした、OpenAPIがデファクトになってきています。

    また、サービス間で接続情報を環境変数で渡す、Open Service Broker APIが策定されサービスメッシュが実現することとなり、マイクロサービスの普及が進んでいます。

  • サービスの粒度

    SOAの時代からサービスの粒度をどうするかは現場での一番の課題です。というのも、サービスの粒度はシステムではなくビジネス観点で決めていくので、ユーザ側が主体となって決めていかないといけないのですが、日本のIT構造上システム構築はシステム会社が請け負うケースが多く、会社全体でのビジネスプロセスという視点でサービスを決めず、システム会社が請け負った範囲内（大体が部門内）でサービスを決めてしまうため粒度が細かく、BPMのフローやルールエンジンが複雑で保守性/再利用性が低く、かつXML解析のオーバーヘッドから性能が出ないなど、問題のあるプロジェクトが多発しました。そんな状態にも関わらずSOA製品（ESB/BPM/BAM）を導入したことでSOA成功事例として喧伝しているようなものも多くあり、SOAは普及しきれず終わっていきました。

    今はクラウド、特にSaaS導入が進んだことで昔よりはサービス粒度の問題は減ってきていますが、まだIaaS/PaaSなどでスクラッチで作る場合には悩まされるケースがあります。

    サービス粒度の基本は、会社全体から部門・課・係という単位で業務を洗い出し、切り離し可能な単位で決めていくというのがセオリーです。
    この辺りはIBM社のSOMAやアクセンチュア社のSIFなど、SOA時代の方法論が参考になると思います。

マイクロサービス自体は全く新しい考え方を元に生まれたものではなく、昔からの流れの中から時代に合わせて進化してきたものです。
なので、昔からあった問題は引き続き抱えている一方で、有効だったアプローチは引き続き有効だったりします。その辺りをきちんと理解し、アジャストして取り組んでいけば効率のよいアプリケーション開発が実現します。

次回の第2回目は、今回の内容を前提としてマイクロサービスの実際の開発について、SAP Cloud Platform Extension Factory/Kymaの製品紹介も合わせて書きたいと思います。