Production-Ready Microservices:
Building Standardized Systems Across an Engineering Organization

４年前に読んだ本ですが、最近復習してきたのでメモを残しておきます。

マイクロサービスとコンテナの時代になりましたが、これで「ビジネスロジック開発に専念できた！」と思ったら大間違いです。
結局にライフサイクル、ネットワーク、状態、バインディングなど意識しないとだめですね。
従来のインフラ（VMも物理マシンも）、たとえばUnixのマシン上にたくさんのプロセス（Kernelを含めて）が動いていて、
メモリやネットワークやルーティングやストレージやDBやキャッシュやログやメールなどなど、
いろんな事をやってくれていて、実際に意識していない人がほとんどですよね。
でもコンテナになっても、これも必要、あれも必要、
ネットワーク系はサービスメッシュがほしいよねとか、
段たん見えてきました。

「分散アプリケーションに必要なものは何ですか？」に対して、下記のような回答がありました。

マルチランタイム・マイクロサービスアーキテクチャ

サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
サービスメッシュは、(一般的にはマイクロサービスベースの)分散ソフトウェアシステム内における、すべてのサービス間"east-west"トラフィックを管理するテクノロジです。ルーティングのようなビジネス指向の機能運用に加えて、セキュリティポリシの適用やQOS(Quality of Service)、レート制限のような非機能サポートも提供します。一般的には(すべてではありませんが)サイドカープロキシを使用して実装され、すべてのサービスがそれを通じて通信するようになります。

サービスメッシュはデータプレーンとコントロールプレーンという、2つの高レベルなコンポーネントで構成されます。

データプレーンは"仕事をする(does the work)"もので、"[ネットワークエンドポイントを]出入りするすべてのネットワークパケットの条件付き変換、転送、監視"を役割としています。最近のシステムでは、データプレーンは(Envoy、HAProxy、MOSNなどのように)プロキシとして実装されるのが一般的で、サイドカーとして各サービスとともにプロセス外部で動作します。

コントロールプレーンは"仕事を監督する(supervises the work)"主体として、データプレーンの個々のインスタンスすべて -- 独立したステートレスなサイドカープロキシ群 -- を分散システムとして構成する役割を担います。

ユースケース

マイクロサービスアーキテクチャの正しい設計 - QCon NYで学んだMichael Bryzak氏の教訓

ソフトウェアアーキテクチャのためのC4モデル

C4はコンテキスト（context）、コンテナ（containers）、コンポーネント（components）、コード（code）の略です。ソフトウェアアーキテクチャを様々な表示倍率で記述するための一連の階層図で、それぞれが（関心の）異なる聞き手に有用です。
C4モデルはコンテナ（アプリケーション、データストア、マイクロサービスなど）やコンポーネント、コードの観点からソフトウェアアーキテクチャの静的構造に関心を払っています。また、構築するソフトウェアシステムを使う人々についても考慮しています。

Strategies for Decomposing a System into Microservices
将系统分解为微服务的策略

ソフトウェアのオブジェクト指向設計やDBMSのER図設計には、
粒度についていつも難解な課題ですが、
マイクロサービスも同様で、サービスをどこまで細かく分割するかは、
今までベストプラティクスがなかった。

このドキュメントは、結構参考になるかもしれません。

マイクロサービスにおけるデータ管理

実践的でいいドキュメント。

クラウド・ネイティブ開発運用ソリューションのご紹介

マイクロサービス実践のポイントの部分はよかったですね。

Polyglot Persistence Powering Microservices
混合持久化让微服务如虎添翼

ユースケース１　CDN URL
OCAs (Open Connect Appliances )はnetflixのビデオ保存場所。
ビデオのURL生成は、Amazonベースのマイクロサービスにより処理される。
データは、分散オンメモリーキャッシュとしてEVCacheをも使用。

ユースケース２　Playback error
エラー情報があまり複雑すぎて、Elasticsearchを使ってログを調べることにした。
UIは、Kibanaを使った。
Elasticsearchを導入することによって、今まで2時間かかる障害特定作業は、10分以内に完了できた

ユースケース3 Viewing history
利用者の鑑賞履歴は、Cassandraに保存されている。
なぜかというと、Wide Column機能によって、
一行データに一人の利用者の利用履歴を全部保管できるから。

インターネット技術においてサービス化はすごい勢いで進んでいます。
IaaS、BaaS、PaaS、SaaS、ウェブサービス、クラウドサービス、マイクロサービスなどなど、毎日目に触れるようになっています。
当たり前の話かもしれないが、本当にその本質を理解するには、あまり簡単なことではありません。

ここでは、自分がサービス化に対する理解と、アマゾンの事例を交えて説明してみようと思います。
抽象的な話なので、分かりづらいと思いますが、すみません。

まず2002年。（当然このことを知ったのは、下記記事が発表されたの2011年10月以降のことです）
Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（前編）から引用

それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。 彼の巨大な指令はこんな感じだった。

1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！

それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 WalMart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。

それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。