休日のマイクロサービスに関するお勉強のメモです。
クラウド・ネイティブ・システムとは
(a) コンテナ化されていること。
アプリケーション・デプロイメントの分離された単位として、そして高水準のリソース分離を達成するためのメカニズムとして、ソフトウェア・コンテナー内でアプリケーションおよびプロセスを実行します。 開発者の経験を向上させ、コードやコンポーネントの再利用を促進し、クラウドネイティブアプリケーションの操作を簡素化します。
(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for cloud native applications.
(b) 動的管理であること。
集中的なオーケストレーションプロセスによって積極的にスケジュールされ、積極的に管理されます。 メンテナンスや運用に伴うコストを削減しながら、マシンの効率とリソースの使用率を大幅に向上させます。
(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.
(c) マイクロサービス指向
明示的に記述された依存関係（例えば、サービスエンドポイントを通じて）と疎結合します。 アプリケーションの全体的な敏捷性と保守性を大幅に向上させます。 この基盤は、アプリケーション管理のための最先端技術を進化させ、信頼性の高いインタフェースを介して、その技術をどこにでも簡単に利用できるようにする、技術の進化を形作るでしょう。
(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.
マイクロサービスとは
マイクロサービスは、一つの大きなアプリを開発する代わりに、個別に開始できる複数のアプリを組み合わせて、構築する考え方
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
この「マイクロサービス・アーキテクチャ」という用語は、ソフトウェア・アプリケーションを個別に展開可能なサービスのスイートとして設計する特定の方法を説明するために、ここ数年に誕生しました。 このアーキテクチャー・スタイルの正確な定義はありませんが、ビジネス機能、自動デプロイメント、エンドポイントのインテリジェンス、および言語とデータの分散制御のために、組織の周りに特定の共通の特性があります。 (1),(2)
マイクロサービスには、PaaSが適する理由
設備投資と設備運用スタッフをなくし、無制限のコンピューティング・パワーを利用できるため、PaaSが適する
Cloud-native is an approach to building and running applications that fully exploits the advantages of the cloud computing model. The cloud has redefined the competitive landscape across virtually all industries by eliminating the focus on capital investment and staff to run an enterprise data center, replacing it with limitless computing power on-demand and pay-as-you-go. Reduced IT spend means a lower barrier to entry with competitive advantage becoming a function of the speed teams can bring new ideas to market, which is why software is eating the world and startups are using cloud-native approaches to disrupt traditional industries.
Yet organizations require a platform for building and operating cloud-native applications and services that automates and integrates the concepts of DevOps, continuous delivery, microservices, and containers:
クラウド・ネイティブは、クラウド・コンピューティング・モデルの利点を十分に活用したアプリケーションの構築と実行のアプローチです。 クラウドは、エンタープライズ・データセンターを運用するための設備投資とスタッフの集中をなくし、無制限のコンピューティング・パワーオンデマンドと置き換えて、ほぼすべての業界で競争環境を再定義しました。 削減されたIT支出は競争優位が競争優位で参入障壁を下げることを意味し、チームが新しいアイデアを市場にもたらすスピードの関数となり、ソフトウェアは世界を席巻しており、新興企業は伝統産業を崩壊させるクラウド・ネイティブ・アプローチを使用しています。
ただし、DevOps、継続的な配信、マイクロサービス、およびコンテナの概念を自動化および統合するクラウドネイティブのアプリケーションとサービスを構築および運用するためのプラットフォームが必要です。(3)
マイクロサービスはコンテナで実行する理由
コンテナ・サービスは、仮想化によるロスがなく、素早く起動し、仮想環境やベアメタル上に、OSレベルの分離性を保ちながら同居できるため、極めて高効率のサービス運用環境であることから、マイクロサービスの実行環境として適する。
The best choice for running a microservices application architecture is application containers. Containers encapsulate a lightweight runtime environment for your application, presenting a consistent software environment that can follow the application from the developer's desktop to testing to final production deployment, and you can run containers on physical or virtual machines.
マイクロサービス・アプリケーション・アーキテクチャを実行するための最良の選択肢は、アプリケーション・コンテナです。 コンテナは、アプリケーションの軽量ランタイム環境をカプセル化し、開発者のデスクトップから最終プロダクションデプロイメントまでのアプリケーションに続く一貫したソフトウェア環境を提供し、物理マシンまたは仮想マシンでコンテナを実行できます。(4)
- 理由1 優れた実行環境
仮想サーバーのハードウェアのエミューレーションのコストを削減できる。
Using VMs also imposes a large performance penalty. Every virtual machine, which must run its own execution environment and copy of the operating system, uses up server processing cycles that you otherwise could use to run the applications.
Containers, by contrast, perform execution isolation at the operating system level. Here, a single operating system instance can support multiple containers, each running within its own, separate execution environment. By running multiple components on a single operating system you reduce overhead, freeing up processing power for your application components.
VMを使用すると、パフォーマンスが大幅に低下します。独自の実行環境とオペレーティングシステムのコピーを実行する必要があるすべての仮想マシンは、アプリケーションの実行に使用できるサーバー処理サイクルを使い果たします。
対照的に、コンテナは、オペレーティングシステムレベルで実行分離を実行します。ここでは、単一のオペレーティングシステムインスタンスが複数のコンテナをサポートし、それぞれが独自の独立した実行環境内で実行されます。単一のオペレーティングシステム上で複数のコンポーネントを実行することにより、オーバーヘッドを削減し、アプリケーションコンポーネントの処理能力を解放します。
- 理由2 良い分離を許容する同居環境
アプリの実行に必要なコードセットをOSレベルで独立にまとめる事ができ、仮想サーバーや物理サーバー上に同居できる。
So, because containers enable multiple execution environments to exist on a single operating system instance, multiple application components can coexist in a single VM environment. In addition, with Linux, you can use control groups (cgroups) to isolate the complete execution environment for a particular application code set, ensuring that each has a private environment and so cannot affect the operation of other applications.
This ability to isolate frees developers from the need to segregate application code into separate VMs, retrieves the processing power previously devoted to those VMs, and offers it to the application code.
コンテナは単一のオペレーティングシステムインスタンスに複数の実行環境を存在させることができるため、複数のアプリケーションコンポーネントが単一のVM環境で共存できます。さらに、Linuxでは、コントロールグループ（cgroup）を使用して、特定のアプリケーションコードセットの完全な実行環境を分離し、それぞれがプライベート環境を持ち、他のアプリケーションの動作に影響を与えないようにすることができます。
この分離機能により、開発者はアプリケーションコードを別々のVMに分ける必要がなくなり、以前はそれらのVMに特化した処理能力を取得し、アプリケーションコードに提供することができます。
- 理由3 早い初期化と実行
コンテナの起動は、秒単位であることから、需要の増加に迅速に対応できる。
Containers, by contrast, are much smaller — perhaps one tenth or one hundredth the size of a virtual machine. And, because they do not require the operating system spin-up time associated with a virtual machine, containers are more efficient at initialization. Overall, containers start in seconds, or even milliseconds in some cases. That's much faster than VMs.
That's why, from a performance perspective, containers are a much better execution foundation for microservices architectures. Their quick instantiation maps much better to the erratic workload characteristics associated with microservices. It also makes them a better match for emerging policy-based microservices operations environments, since application topology decisions driven by policy (e.g., always have three instantiations of each microservice) can be more easily implemented via quick-starting, container-based application components.
対照的に、コンテナは非常に小さく、仮想マシンのサイズの10分の1または100分の1になります。また、仮想マシンに関連付けられたオペレーティングシステムのスピンアップ時間を必要としないため、コンテナは初期化時に効率的です。全体的にコンテナは秒単位、場合によってはミリ秒単位で開始されます。それはVMよりはるかに高速です。
そのため、パフォーマンスの観点からは、コンテナはマイクロサービスアーキテクチャの実行基盤として優れています。それらの迅速なインスタンシエーションは、マイクロサービスに関連する不安定なワークロードの特性に非常によく似ています。また、ポリシーによって駆動されるアプリケーショントポロジの決定（例えば、常に各マイクロサービスの3つのインスタンス化を有する）は、クイックスタートのコンテナベースのアプリケーションコンポーネントを介してより容易に実施することができるため、新たなポリシーベースのマイクロサービス動作環境に適している。
マイクロサービスのプロトコルはREST
マイクロサービスは、HTTP と REST を使ってアクセスします。
WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST（Representational State Transfer）と呼ばれるアーキテクチャスタイルです。(5),
これまでは、Java言語と強く結び付いた Webサービスの開発(6)が主流でした。しかし、開発生産性の高い開発言語が普及する中で、Java言語に強く依存する方法では、ニーズに応えられなかったと言えると思います。
出典(7)
マイクロサービスは、
- 小さく、的を絞り、疎結合のサービス
- 個別に開発、デプロイ、アップデートする事ができる
どんな方法で、マイクロサービス間で通信するのか？
REST & HTTP !
- 統一的なステートレス・サービスのインターフェース
- 全てのサービスは、クライアントに依存しない
RESTとは
REST (Representational State Transfer) は、ウェブサーバーで使われる HTTP をそのまま利用して、プログラムから呼び出せる機能を提供するためのアプリケーション・インタフェースである。 以下、ウィキペディアなど、にある説明を引用する。(8),(9)
ステートレスなクライアント/サーバプロトコル
HTTPメッセージの一つ一つが、そのリクエスト（メッセージ）を理解するために必要な全ての情報を含む。そのため、クライアントもサーバも、メッセージ間におけるセッションの状態を記憶しておく必要がない。ただし実際には、多くのHTTPベースのアプリケーションはクッキーやその他の仕掛けを使ってセッションの状態を管理している（URLリライティングのような一部のセッション管理手法を使うシステムは、RESTful ではない）。
すべての情報（リソース）に適用できる「よく定義された操作」のセット
HTTP では操作（メソッド）の小さなセットが定義されている。最も重要なのは "GET"、"POST"、"PUT"、"DELETE" である。これらはデータ永続化に要求されるCRUDと比較されることがある。もっとも "POST" に関しては CRUD にはぴったり対応していない。
リソースを一意に識別する「汎用的な構文」
RESTful なシステムでは、すべてのリソースは Uniform Resource Identifier (URI) で表される一意的な（ユニークな）アドレスを持つ。
アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
RESTシステムでは、多くの場合、HTML文書またはXML文書を使う。こうした文書に情報およびその他のリソースへのリンクを含める。こうすることにより、あるRESTリソースから他のRESTリソースを参照したい場合は単にリンクを辿るだけでよい。レジストリなどの他の基盤的な機能を使う必要はない。
REST APIライブラリ
プログラム・コードから、RESTのURIをGETやPOSTするのは、共通的な重複が多いので、生産性改善や実行品質を高まる様に、Python, node.js, Java などの開発言語のライブラリとして提供されているソフトウェア・モジュール
例として、Watson APIは、RESTサービスとして提供されています。
https://watson-api-explorer.mybluemix.net/
RESTサービスは、Java, Python, Node.js の各プログラミング言語から簡単にアクセスできる様に、RESTをラップした関数ライブラリが提供されています。
https://www.ibm.com/watson/developercloud/conversation/api/v1/?curl#
データ連携 JSON or XML
JSONは、XMLよりシンプルで、多くの人に受け入れられてきました。(10) JSONとはJavaScript Object Notationの略で、XMLなどと同様のテキストベースのデータフォーマットです。その名前の由来の通りJSONはJavaScriptのオブジェクト表記構文のサブセットとなっており、XMLと比べると簡潔に構造化されたデータを記述することができるため、記述が容易で人間が理解しやすいデータフォーマットと言えます。 JSONは2006年に「RFC 4627（http://www.rfc-editor.org/rfc/rfc4627.txt ）」として公開されています。 (11)
JSONは完全に言語から独立したテキスト形式ですが、C、C++、C#、Java、JavaScript、Perl、Python、その他多くのCファミリーの言語を使用するプログラマにとっては、馴染み深い規約が使われています。これらの性質が、 JSONを理想的なデータ交換言語にしています。(12),(13)
ウィキペディア JavaScript Object Notation(14) にさらに詳しい説明があります。
マイクロサービスのフレームワーク
REST API や マイクロサービスを開発するためのフレームワークが、たくさん開発されている。(15),(16),(17) この中で注目のフレームワークを列挙しておきます。
- Node.js Express http://expressjs.com/
- PHP Lumen https://lumen.laravel.com/
- Python Flask http://flask.pocoo.org/
- Java lagom https://www.lightbend.com/platform/development/lagom-framework
- Java JAX-RS https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-2rd-edition/en/index.html
Bluemix REST サンプル
IBM Bluemix にも マイクロサービスの基本単位になる RESTサービスのサンプルコードがあります。(18)
- IBM-Bluemix/get-started-php https://github.com/IBM-Bluemix/get-started-php
- IBM-Bluemix/get-started-node https://github.com/IBM-Bluemix/get-started-node
- IBM-Bluemix/get-started-python https://github.com/IBM-Bluemix/get-started-python
- IBM-Bluemix/get-started-java https://github.com/IBM-Bluemix/get-started-java
- IBM-Bluemix/get-started-ruby https://github.com/IBM-Bluemix/get-started-ruby
- IBM-Bluemix/get-started-swift https://github.com/IBM-Bluemix/get-started-swift
- IBM-Bluemix/get-started-go https://github.com/IBM-Bluemix/get-started-go
最後に感想
モノリシックなサービスを長い時間かけて開発するより、小さなマイクロサービスを積み重ねて、素早いリリースと改善を重ねて洗練されたサービスを育てる環境として、PaaSは重要なんですね。 それにしても、マイクロサービスを設計して、運営するノウハウが不足している感じがするのは、僕だけでしょうか・・・
参考資料
(1) James Lewis/Martin Fowlerの"Microservices"日本語訳 http://kimitok.hateblo.jp/entry/2014/11/09/211820?cm_mc_uid=11149675371314151911387&cm_mc_sid_50200000=1500246735
(2) Microservices a definition of this new architectural term https://martinfowler.com/articles/microservices.html
(3) What are Cloud-Native Applications? https://pivotal.io/cloud-native
(4) 3 reasons why you should always run microservices apps in containers https://techbeacon.com/3-reasons-why-you-should-always-run-microservices-apps-containers
(5) 時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了 http://www.publickey1.jp/blog/10/restsoapwebws-i.html
(6) Webサービスのヒント:JAX-RPCとJAX-WS、第1回 https://www.ibm.com/developerworks/jp/webservices/library/ws-tip-jaxwsrpc.html
(7) REST and Microservices https://www.slideshare.net/shaunabram/an-intro-to-rest-and-microservices
(8) RESTful APIとは何なのか http://qiita.com/NagaokaKenichi/items/0647c30ef596cedf4bf2
(9) ウィキペディア REST https://ja.wikipedia.org/wiki/REST
(10) JSONに押されるXMLの存在 http://www.publickey1.jp/blog/10/jsonxml.html
(11) JSONってなにもの? https://thinkit.co.jp/article/70/1
(12) JSONの紹介 http://www.json.org/json-ja.html
(13) JSONをRuby,Python,JavaScript,PHPで扱う方法 http://qiita.com/MahoTakara/items/f79ab8e3c3ed790bca18
(14) JavaScript Object Notation https://ja.wikipedia.org/wiki/JavaScript_Object_Notation
(15) マイクロサービスフレームワークまとめ https://developer.ntt.com/ja/blog/22f3fa8f-774e-43ef-94cd-cc574715db51
(16) REST APIを構築するのに使えるフレームワークまとめ https://developer.ntt.com/ja/blog/0ff7d83e-d2d4-4c11-8990-4dd4896d2300
(17) マイクロサービスのフレームワークまとめ 不定期更新 http://qiita.com/hat22/items/3c9ad74d89166b7a72db
(18) GitHub Bluemix https://github.com/IBM-Bluemix
(19) IBM developerWorks マイクロサービスの実際 第1回 マイクロサービス入門 https://www.ibm.com/developerworks/jp/cloud/library/cl-bluemix-microservices-in-action-part-1-trs/index.html
(20) マイクロサービス（Microservices） http://www.nttdata.com/jp/ja/insights/trend_keyword/2015072301.html
(21) Cloud Foundry https://ja.wikipedia.org/wiki/Cloud_Foundry
(22) Cloud native systems will have the following properties https://www.cncf.io/about/charter/