ソニー銀行と富士通が勘定系のシステム化に
マイクロサービスアーキテクチャを
採用してスケジュールが遅れて居る。
なぜ、だろうね？ 少し纏めて見よう。
この文章を一通り読んで省いて
1970-1980の現役が読んでも混乱はないが
要件はメーカーSEが10人程度で300人に作らせても
半年1年では無理だろうね！
当然手戻りありでバージョンを作れないだろうね！
勘定系の現場が何があるか？分析なって
捨てろって言えないなら無理だろうね！
みずほ銀行ATM単画面 還付詐欺も治らないよ！
まあコンテナアーキテクチャーの資料が見つからないのは幸運だが現在動いている勘定系にスペックが残って居たなあ！それが一昨年から11件のトラブルに現れた。それの説明には以下の文章は実に良く分かる。
ど真ん中で苦しんだろうね！
マイクロサービスアーキテクチャとそれを支える技術
公開日2018-12-06
更新日2022-03-22
最近では「マイクロサービス」と呼ばれる、機能毎に細かくサービスを分割して開発や運用を行うアーキテクチャの採用例が増えている。
簡単に言えばサービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法で、2011年ごろから提唱されているものだ。
・個々のマイクロサービスはそれぞれ独立したプロセスとして動作する
・各マイクロサービスは主にネットワーク経由で通信して所定のタスクを処理する
・各マイクロサービスはほかのマイクロサービスに依存せず起動でき、独立してデプロイやアップデートが可能
3つの特徴
1.の「個々のマイクロサービスが独立したプロセスとして動作する」
各マイクロサービスをそれぞれ異なる言語で実装できる
Perlで実装し、Pythonで実装する
使用するライブラリやフレームワークも独立して選定
2.の「各マイクロサービス間は主にネットワーク経由で通信して所定のタスクを処理する」
マイクロサービスを異なるマシン上で実行
マイクロサービス間の依存性を小さくする
マイクロサービスのプロセスを複数同時に実行
冗長化や性能向上（スケーリング）
3.の「独立してデプロイが可能」
マイクロサービス毎に独立した開発・メンテナンス計画
マイクロサービス毎に独立したチームで開発・運用
各マイクロサービスの規模を小さくしてプログラムの複雑性を減らす
開発やメンテナンスに必要なコストの圧縮
仮想化技術やクラウドサービスとの相性
インフラストラクチャでは
高スペックなマシンを1台用意する
よりも
比較的低スペックなマシンを複数台用意して組み合わせるクラスタ構成
低コストになるケース→検索など！
比較的小規模なプロセスを多数実行→勘定系が狙われる！うふふ！落とし穴
コスト面でも優位性→嘘！ 考えて御覧？
デメリットと設計時の留意点
コンポーネントを小さな粒度で分割
コストやパフォーマンスに影響するオーバーヘッド
発生しやすい→チョット考えれば馬鹿でも分からない
デメリット
トータルのメモリ使用量は増える
ネットワーク経由でのデータのやり取りある程度の遅延→予想外の、見積ったコトがない！
マイクロサービス同士の通信は公開APIを通じてのみ行う
APIの仕様を事前に十分に検討→出来ないよ！
→見切り発車さ、当然手戻りさ
データベースについても設計時に注意
基本的にはマイクロサービスごとに固有のデータベースやストレージを持ち
基本的にほかのマイクロサービスが管理しているデータベースやストレージには直接アクセスできない
→これをデータベースと呼んでは行けない？
→唯の馬鹿集団となる
→データベースって1985頃にキャアキャア言って一週間回してA4一頁のアウトプットとなった
複数のマイクロサービスにまたがるトランザクション
→これが滑稽さ
求められる機能をどのように分割して各マイクロサービスに割り当てるかが重要→下らない努力さ？
各機能を細かく分割しすぎオーバーヘッドは大きくなる
逆に分割粒度が大きいとマイクロサービスのメリットは少ない
→マイクロサービスって人跡未踏のアホ道となる
運用時の課題として監視対象が増える
サービスの死活監視やログの管理が煩雑
→これが見積れない予想出来ない作って知る
設計時には十分な検討が必要→これは成功しない
→成功したコトがない
データベースの選択と設計
マイクロサービスアーキテクチャ
データをデータベースに格納して管理
アーキテクチャと変わらない
特別なアクセスの仕方はなく
データベース
Oracleや
MySQL
PostgreSQL
リレーショナルデータベースや
MongoDB
Redisといった
Key-Valueストア/ドキュメントデータベース
各マイクロサービスが独立してデータを管理
各データベースに格納するデータが比較的シンプル
データベースシステム自体の管理やチューニング作業
不要なクラウド型のデータベースサービスを活用
大量のデータを操作したり
複雑なクエリを処理したり
マイクロサービスは独自にデータベースサーバーを用意
マイクロサービスについてはクラウド型のデータベースを利用する
住み分けも可能だ→矛盾さ、予想外、見積されてない
マイクロサービスごとの独立性が向上
ロックやトランザクションなどにまつわるトラブルやパフォーマンス低下などを防ぐ
→チョットした変化にアホの様に弱い
マイクロサービスごとに適切なデータベースエンジンを採用
万が一データベース構造を大きく変更せざるを得ない状況になった場合でも、それによる影響範囲を抑えられる→これが嘘、何でもそうだが、嘘って経験がないってコト
他のマイクロサービスが管理するデータベース内のデータが必要となる場合
そのマイクロサービスを経由してデータを取得→これを禁じれない→これが美味いビジネスだった
アクセスが必要な場合はデータをやり取りするためのAPIを用意する必要がある→これを禁じない
複数のマイクロサービスにわたるトランザクション処理を実装するのは難度が高い→これを禁じない
トランザクションが必要となる場合、1つのマイクロサービス内で完結
コンポーネント間通信技術の選定
マイクロサービスアーキテクチャ
各マイクロサービスがほかのマイクロサービスと通信して処理を実行
通信方法の選定もマイクロサービスアーキテクチャを利用するに当たって重要なポイント
マイクロサービス同士がやり取りする情報
「メッセージ」
メッセージのやり取り
同期的な手法と非同期的な手法の2種類
同期的なメッセージ通信では送信元と送信先が同期
メッセージの送信元は送信先がメッセージを受け取って何らかの処理を実行してその結果を送り返すまで、処理を一時停止して待機する
実際の実装
マルチスレッドやイベントキュー
複数の処理を並行して実行
通常プロセスが完全に停止することは少ない
送信先がその結果を送信しない限り次の処理には進めない
非同期的なメッセージ通信では、
マイクロサービスが送信したメッセージは
メッセージキューに保存され、
送信後に即座に次の処理を実行できる
送信されたメッセージを処理するマイクロサービス側
メッセージキューに格納されたメッセージを順次取り出し
対応する処理を実行
非同期的なメッセージ通信ではリアルタイム性は保証されない
通信先マイクロサービスの状況に左右されずに処理を完了させることができる
同期的なメッセージ通信の選択肢
HTTPベースでメッセージのやり取りを行う手法
HTTPは広く普及
クライアント/サーバーを実装ライブラリも多数選択肢がある
やり取りしたいデータやエンドポイント（接続先URL）
どのような形で表現するか
複数の手法
「REST」と「RPC（RPC over HTTP）」
RESTは、操作対象とするリソースをディレクトリ構造（木構造）で表現しそれをURLにマッピングして指定する
実行する処理は「GET」や「POST」、「PUT」、「PATCH」、「DELETE」といったHTTPリクエストメソッドによって指定
GETメソッドがリソースの取得、
POSTメソッドがリソースの作成、
PUTメソッドおよびPATCHメソッドがリソースの更新、
DELETEメソッドが削除
POSTやPUT、PATCHといったメソッドの場合、
クライアントは何らかの形で送信するデータを構造化
データの構造化にはXMLやJSON
RESTを利用したシステムの中でも
Cookieなどを使ったセッション管理を用いず、
セッションに依存しない
実装は「RESTful」
RPCは、URLではなく送信するメッセージ内で操作対象や実行する処理（メソッド）を指定する点がRESTと異なる
RPCはHTTPだけでなくさまざまなプロトコルで利用できる
HTTPをベースにする
送信するデータフォーマットもさまざまなもの
HTTPベースの場合XMLもしくはJSONが使われる
RESTでは処理対象のリソースに応じてURLが動的に生成される
RPCではエンドポイントとなるURLは1つもしくは少数となるためURLの設計や変更がしやすい
URLだけでは実行する処理を判断できない
HTTPベースではないRPC
「gRPC」も注目
gRPCはGoogleが開発を進めるRPC実装
効率的にデータをやり取りできる
HTTP/2ベースでの双方向通信がサポート
C++やPython、Java、Rubyの言語向けのライブラリが提供されているほか、
「protocol buffers」というフォーマットでメソッドの名前や受け付けるデータ形式、
戻り値となるデータ形式を記述し、
そこから対応するコードを自動生成するツール
異なる言語で実装したシステム間でも整合性の取れた実装
同期的なメッセージやり取りに使える技術
Apache Hadoopで使われる「Apache Avro」
Facebookが開発した「Apache Thrift」
フレームワークもある
非同期的メッセージ通信の選択肢
「メッセージキュー」
「ブローカード」と「ブローカーレス」の2つ
「ブローカー」は直訳すると「仲介者」
仲介者となるプログラムを介してメッセージをやり取りするアーキテクチャを「ブローカード」
仲介者なしで直接送信元と送信先がメッセージをやり取りするアーキテクチャを「ブローカーレス」
ブローカードのメッセージキュー
「RabbitMQ」や「Apache ActiveMQ」
AMQP（Advanced Message Queuing Protocol」利用の際はブローカーとなるプログラムを立ち上げておく
メッセージを受け取るプログラムがクラッシュするなどして動作していない場合でも、メッセージ送信元はブローカーさえ動作していれば問題なくメッセージ送信が行える
送信されたメッセージはブローカー内に保存され、メッセージ送信先が再度動き出したときに順次処理される
ブローカー自体がクラッシュした場合は送信元でなんらかの対処を行わなければならない
ブローカーレスのメッセージキューでは、メッセージを受け取るプログラムがそれぞれにキューを持ち、送信元のプログラムが送信先のプロセスに直接メッセージを送信する
遅延が少なく高速に処理できる
プログラムにメッセージキューの機能を組み込む
プログラムの複雑性や使用するリソースが増える
ブローカーレスのメッセージキューの代表的な実装
「ZeroMQ」
ZeroMQはプログラムにライブラリとして組み込む
メッセージキュー機能を実現する
任意のデータをメッセージとしてやり取り
主要な言語向けのバインディングも提供
プログラミング言語と組み合わせての利用
データベースをキュー代わりに利用する
広義にはブローカード型のメッセージキュー
データベースにはトランザクションやロック
データの一貫性を保つ機能
メッセージキューのようなものを独自に実装
インフラストラクチャの選択とサービスメッシュ
マイクロサービスアーキテクチャでは、多数の独立したサービスを協調動作
所定のサービスを提供する
デプロイしなければならないコンポーネントの数も増える
仮想化やクラウドインフラストラクチャを使ってサービスを運用
各マイクロサービスは「独立したプロセス」
必ずしも各マイクロサービスを別のマシンで実行させる必要は無い
ライブラリの依存性などの問題から、
各プロセスはそれぞれ独立したマシン（もしくは仮想マシン、コンテナ）上で実行させる
インフラストラクチャの選定
マイクロサービスアーキテクチャとはやや外れた話題
クラウドインフラストラクチャやコンテナ
各マイクロサービスが使用するIPアドレスが動的に変動する
こういった環境ではほかのマイクロサービスとメッセージをやり取りする際、目的のマイクロサービスに割り当てられているIPアドレスを何らかの方法で特定しなければならない。
冗長性確保やスケーリングのために同じマイクロサービスを並行して複数稼動させる
この場合ロードバランサーのように動的に接続先を管理する仕組みが必要
サービスやそのネットワーク接続を管理するシステムを「サービスメッシュ」
クラスタインフラ管理機能を提供する「Kubernetes」ではシンプルなサービスメッシュ機能が組み込まれている
独自のサービスメッシュ機能を提供するクラウドインフラストラクチャもある
「Istio」や「Linkerd」
インフラストラクチャに依存せずにサービスメッシュ機能を提供するソフトウェア
独自のプロキシを利用してマイクロサービス間の通信を管理する仕組みになっており、
適切な接続の転送に加えて、
ロードバランサーや
ネットワークゲートウェイ、
認証、
モニタリング
などの機能も備える
LinkerdはKubernetesと組み合わせて利用する
IstioはKubernetesを使ったインフラ
仮想マシンベースのインフラも対応している
IaaS型のクラウドサービスでも利用できる
デプロイとアップデート
マイクロサービスアーキテクチャ
サービスを構成するマイクロサービスの数が多くなる
デプロイメント（デプロイ）やアップデート作業の自動化も必要
手作業でいちいち個別にこういった作業を行うのは手間がかかり、ミスなども発生しやすくなる
クラウド型のインフラストラクチャを利用する場合、ある程度はインフラストラクチャ側でデプロイやアップデートのための機能が提供される
Kubernetesでは「deployment」という、デプロイのための機能が用意されている。また、多くのクラウドサービスでは自動化のためのAPIなどが提供されている。
IstioやLinkerdといったサービスメッシュ支援ツールにもデプロイのための機能が用意されている。
こういったデプロイ機能やデプロイツールを利用するメリットの1つとして、
サービスを停止させずに各マイクロサービスのソフトウェアをアップデートしたり、
トラブルを少なくするようなアップデート手法を容易に利用できる点がある。
たとえばシステムのアップデート手法の1つとして、古いバージョンのソフトウェアを稼動させたまま新たに新しいバージョンのソフトウェアを使ってプロセスを立ち上げ、
その後接続先を切り替える、
というやり方がある。
これは「ブルーグリーン（Blue-Green）デプロイメント」と呼ばれるものの一種で、
もしアップデート後に新バージョンのソフトウェアに不具合が見つかった場合、接続先を戻すだけでロールバックを速やかに実行できるというメリットがある
ブルーグリーンデプロイメントは、
元々はデプロイ先の本番環境を2つ用意しておき、
デプロイごとに使用する環境を切り替えるという手法であり、
クラウド型インフラストラクチャではない環境でも利用できたが、クラウド型インフラストラクチャではこういった冗長な構成を容易かつ比較的低コストで実現できるため普及が進んでいる。
また、マイクロサービスアーキテクチャにおいては冗長性を持たせるため、1つのマイクロサービスを複数のプロセスで並行動作させておくことが多い。
そのため、本番環境を一気に切り替えるのではなく順次切り替えていく「ローリングアップデート」と呼ばれるやり方も使われる。
ブルーグリーンデプロイメントを発展させた「カナリアリリース」という手法も考案されている。
カナリアリリースはブルーグリーンデプロイメントと似ているが、複数稼動させているノードのうちまずは少数のノードだけを新しいバージョンのものに入れ替えて様子を見て、問題がなければその後残りのノードを入れ替えていく、という手法だ。
この手法は、かつて炭鉱での作業時に有毒ガスを検知するためにカナリアを持ち込んでいた（もし有毒ガスが発生したら人間より先にカナリアが異常をきたす）という話に由来して「カナリアリリース」と名付けられている。
カナリアリリースを応用した手法として、管理者や一部のユーザーのみに限定して新バージョンを使わせるといった手法もある。
クラウド型インフラストラクチャとマイクロサービス、サービスメッシュの組み合わせでは、比較的簡単に一部のマイクロサービスのみを入れ替えることが可能になる。
これを利用したテスト手法も考案されている。たとえば一部のプロセスのみをあえて不具合を起こすようなものに入れ替えて、そういった場合でも適切にエラー処理が行われシステム全体として適切に動作するかを確認する「フォールトインジェクション」といった手法があり、サービスメッシュ管理ソフトウェアによってはこのような機能を提供するものもある。
ソフトウェアやインフラストラクチャの進化によって実用的になったマイクロサービスアーキテクチャ
このように、
マイクロサービスアーキテクチャではクラウドインフラストラクチャや仮想化、そしてさまざまな周辺ツールが活用されている。
そのため、各マイクロサービスの規模は小さくなるが、その分開発にあたるエンジニアは同期/非同期通信やデータベース、インフラに関するものまで、より幅広い知識が求められる。
また、特に機能毎のサービス分割に関しては十分な検討が必要となる。そのため、開発の際には「とりあえず流行っているから」などの理由でマイクロサービスアーキテクチャを採用するのではなく、
事前に十分に検討を行い、対象システムがマイクロサービスアーキテクチャでの構築に本当に適しているのかを考える必要があるだろう。
なお、プロセス間通信やコンポーネントの分離、デプロイ手法など、マイクロサービスアーキテクチャの考え方はそれ以外のアーキテクチャでも参考になる点も多い。
たとえばメインの処理は非マイクロアーキテクチャで構築し、一部のみをマイクロアーキテクチャ風の形で構築する、といった形も考えられる。
既存システムのアップデートなどでは、こういった手法も十分実用的だろう。
さて、マイクロサービスアーキテクチャの採用例が増えた一因としては、
クラウドインフラストラクチャの普及や関連ツールの登場が大きい。
次記事ではマイクロサービスの構築に使われるサービスメッシュについて、実際の環境構築も含めた解説を行う予定だ。
コンテナアーキテクチャーと比較すると実に面白い。
別の機会にするが、コンピュータービジネスの貪欲なチャレンジって、既に滑稽だなあ！
みずほ銀行ATM単画面 還付詐欺を
地元ヤクザ 送金システムと呼んで
本気で解決するには公表しかないと
俺の後輩に言わせたい
残り3ヶ月は切ったよ！
マイクロサービスアーキテクチャを
採用してスケジュールが遅れて居る。
なぜ、だろうね？ 少し纏めて見よう。
この文章を一通り読んで省いて
1970-1980の現役が読んでも混乱はないが
要件はメーカーSEが10人程度で300人に作らせても
半年1年では無理だろうね！
当然手戻りありでバージョンを作れないだろうね！
勘定系の現場が何があるか？分析なって
捨てろって言えないなら無理だろうね！
みずほ銀行ATM単画面 還付詐欺も治らないよ！
まあコンテナアーキテクチャーの資料が見つからないのは幸運だが現在動いている勘定系にスペックが残って居たなあ！それが一昨年から11件のトラブルに現れた。それの説明には以下の文章は実に良く分かる。
ど真ん中で苦しんだろうね！
マイクロサービスアーキテクチャとそれを支える技術
公開日2018-12-06
更新日2022-03-22
最近では「マイクロサービス」と呼ばれる、機能毎に細かくサービスを分割して開発や運用を行うアーキテクチャの採用例が増えている。
簡単に言えばサービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法で、2011年ごろから提唱されているものだ。
・個々のマイクロサービスはそれぞれ独立したプロセスとして動作する
・各マイクロサービスは主にネットワーク経由で通信して所定のタスクを処理する
・各マイクロサービスはほかのマイクロサービスに依存せず起動でき、独立してデプロイやアップデートが可能
3つの特徴
1.の「個々のマイクロサービスが独立したプロセスとして動作する」
各マイクロサービスをそれぞれ異なる言語で実装できる
Perlで実装し、Pythonで実装する
使用するライブラリやフレームワークも独立して選定
2.の「各マイクロサービス間は主にネットワーク経由で通信して所定のタスクを処理する」
マイクロサービスを異なるマシン上で実行
マイクロサービス間の依存性を小さくする
マイクロサービスのプロセスを複数同時に実行
冗長化や性能向上（スケーリング）
3.の「独立してデプロイが可能」
マイクロサービス毎に独立した開発・メンテナンス計画
マイクロサービス毎に独立したチームで開発・運用
各マイクロサービスの規模を小さくしてプログラムの複雑性を減らす
開発やメンテナンスに必要なコストの圧縮
仮想化技術やクラウドサービスとの相性
インフラストラクチャでは
高スペックなマシンを1台用意する
よりも
比較的低スペックなマシンを複数台用意して組み合わせるクラスタ構成
低コストになるケース→検索など！
比較的小規模なプロセスを多数実行→勘定系が狙われる！うふふ！落とし穴
コスト面でも優位性→嘘！ 考えて御覧？
デメリットと設計時の留意点
コンポーネントを小さな粒度で分割
コストやパフォーマンスに影響するオーバーヘッド
発生しやすい→チョット考えれば馬鹿でも分からない
デメリット
トータルのメモリ使用量は増える
ネットワーク経由でのデータのやり取りある程度の遅延→予想外の、見積ったコトがない！
マイクロサービス同士の通信は公開APIを通じてのみ行う
APIの仕様を事前に十分に検討→出来ないよ！
→見切り発車さ、当然手戻りさ
データベースについても設計時に注意
基本的にはマイクロサービスごとに固有のデータベースやストレージを持ち
基本的にほかのマイクロサービスが管理しているデータベースやストレージには直接アクセスできない
→これをデータベースと呼んでは行けない？
→唯の馬鹿集団となる
→データベースって1985頃にキャアキャア言って一週間回してA4一頁のアウトプットとなった
複数のマイクロサービスにまたがるトランザクション
→これが滑稽さ
求められる機能をどのように分割して各マイクロサービスに割り当てるかが重要→下らない努力さ？
各機能を細かく分割しすぎオーバーヘッドは大きくなる
逆に分割粒度が大きいとマイクロサービスのメリットは少ない
→マイクロサービスって人跡未踏のアホ道となる
運用時の課題として監視対象が増える
サービスの死活監視やログの管理が煩雑
→これが見積れない予想出来ない作って知る
設計時には十分な検討が必要→これは成功しない
→成功したコトがない
データベースの選択と設計
マイクロサービスアーキテクチャ
データをデータベースに格納して管理
アーキテクチャと変わらない
特別なアクセスの仕方はなく
データベース
Oracleや
MySQL
PostgreSQL
リレーショナルデータベースや
MongoDB
Redisといった
Key-Valueストア/ドキュメントデータベース
各マイクロサービスが独立してデータを管理
各データベースに格納するデータが比較的シンプル
データベースシステム自体の管理やチューニング作業
不要なクラウド型のデータベースサービスを活用
大量のデータを操作したり
複雑なクエリを処理したり
マイクロサービスは独自にデータベースサーバーを用意
マイクロサービスについてはクラウド型のデータベースを利用する
住み分けも可能だ→矛盾さ、予想外、見積されてない
マイクロサービスごとの独立性が向上
ロックやトランザクションなどにまつわるトラブルやパフォーマンス低下などを防ぐ
→チョットした変化にアホの様に弱い
マイクロサービスごとに適切なデータベースエンジンを採用
万が一データベース構造を大きく変更せざるを得ない状況になった場合でも、それによる影響範囲を抑えられる→これが嘘、何でもそうだが、嘘って経験がないってコト
他のマイクロサービスが管理するデータベース内のデータが必要となる場合
そのマイクロサービスを経由してデータを取得→これを禁じれない→これが美味いビジネスだった
アクセスが必要な場合はデータをやり取りするためのAPIを用意する必要がある→これを禁じない
複数のマイクロサービスにわたるトランザクション処理を実装するのは難度が高い→これを禁じない
トランザクションが必要となる場合、1つのマイクロサービス内で完結
コンポーネント間通信技術の選定
マイクロサービスアーキテクチャ
各マイクロサービスがほかのマイクロサービスと通信して処理を実行
通信方法の選定もマイクロサービスアーキテクチャを利用するに当たって重要なポイント
マイクロサービス同士がやり取りする情報
「メッセージ」
メッセージのやり取り
同期的な手法と非同期的な手法の2種類
同期的なメッセージ通信では送信元と送信先が同期
メッセージの送信元は送信先がメッセージを受け取って何らかの処理を実行してその結果を送り返すまで、処理を一時停止して待機する
実際の実装
マルチスレッドやイベントキュー
複数の処理を並行して実行
通常プロセスが完全に停止することは少ない
送信先がその結果を送信しない限り次の処理には進めない
非同期的なメッセージ通信では、
マイクロサービスが送信したメッセージは
メッセージキューに保存され、
送信後に即座に次の処理を実行できる
送信されたメッセージを処理するマイクロサービス側
メッセージキューに格納されたメッセージを順次取り出し
対応する処理を実行
非同期的なメッセージ通信ではリアルタイム性は保証されない
通信先マイクロサービスの状況に左右されずに処理を完了させることができる
同期的なメッセージ通信の選択肢
HTTPベースでメッセージのやり取りを行う手法
HTTPは広く普及
クライアント/サーバーを実装ライブラリも多数選択肢がある
やり取りしたいデータやエンドポイント（接続先URL）
どのような形で表現するか
複数の手法
「REST」と「RPC（RPC over HTTP）」
RESTは、操作対象とするリソースをディレクトリ構造（木構造）で表現しそれをURLにマッピングして指定する
実行する処理は「GET」や「POST」、「PUT」、「PATCH」、「DELETE」といったHTTPリクエストメソッドによって指定
GETメソッドがリソースの取得、
POSTメソッドがリソースの作成、
PUTメソッドおよびPATCHメソッドがリソースの更新、
DELETEメソッドが削除
POSTやPUT、PATCHといったメソッドの場合、
クライアントは何らかの形で送信するデータを構造化
データの構造化にはXMLやJSON
RESTを利用したシステムの中でも
Cookieなどを使ったセッション管理を用いず、
セッションに依存しない
実装は「RESTful」
RPCは、URLではなく送信するメッセージ内で操作対象や実行する処理（メソッド）を指定する点がRESTと異なる
RPCはHTTPだけでなくさまざまなプロトコルで利用できる
HTTPをベースにする
送信するデータフォーマットもさまざまなもの
HTTPベースの場合XMLもしくはJSONが使われる
RESTでは処理対象のリソースに応じてURLが動的に生成される
RPCではエンドポイントとなるURLは1つもしくは少数となるためURLの設計や変更がしやすい
URLだけでは実行する処理を判断できない
HTTPベースではないRPC
「gRPC」も注目
gRPCはGoogleが開発を進めるRPC実装
効率的にデータをやり取りできる
HTTP/2ベースでの双方向通信がサポート
C++やPython、Java、Rubyの言語向けのライブラリが提供されているほか、
「protocol buffers」というフォーマットでメソッドの名前や受け付けるデータ形式、
戻り値となるデータ形式を記述し、
そこから対応するコードを自動生成するツール
異なる言語で実装したシステム間でも整合性の取れた実装
同期的なメッセージやり取りに使える技術
Apache Hadoopで使われる「Apache Avro」
Facebookが開発した「Apache Thrift」
フレームワークもある
非同期的メッセージ通信の選択肢
「メッセージキュー」
「ブローカード」と「ブローカーレス」の2つ
「ブローカー」は直訳すると「仲介者」
仲介者となるプログラムを介してメッセージをやり取りするアーキテクチャを「ブローカード」
仲介者なしで直接送信元と送信先がメッセージをやり取りするアーキテクチャを「ブローカーレス」
ブローカードのメッセージキュー
「RabbitMQ」や「Apache ActiveMQ」
AMQP（Advanced Message Queuing Protocol」利用の際はブローカーとなるプログラムを立ち上げておく
メッセージを受け取るプログラムがクラッシュするなどして動作していない場合でも、メッセージ送信元はブローカーさえ動作していれば問題なくメッセージ送信が行える
送信されたメッセージはブローカー内に保存され、メッセージ送信先が再度動き出したときに順次処理される
ブローカー自体がクラッシュした場合は送信元でなんらかの対処を行わなければならない
ブローカーレスのメッセージキューでは、メッセージを受け取るプログラムがそれぞれにキューを持ち、送信元のプログラムが送信先のプロセスに直接メッセージを送信する
遅延が少なく高速に処理できる
プログラムにメッセージキューの機能を組み込む
プログラムの複雑性や使用するリソースが増える
ブローカーレスのメッセージキューの代表的な実装
「ZeroMQ」
ZeroMQはプログラムにライブラリとして組み込む
メッセージキュー機能を実現する
任意のデータをメッセージとしてやり取り
主要な言語向けのバインディングも提供
プログラミング言語と組み合わせての利用
データベースをキュー代わりに利用する
広義にはブローカード型のメッセージキュー
データベースにはトランザクションやロック
データの一貫性を保つ機能
メッセージキューのようなものを独自に実装
インフラストラクチャの選択とサービスメッシュ
マイクロサービスアーキテクチャでは、多数の独立したサービスを協調動作
所定のサービスを提供する
デプロイしなければならないコンポーネントの数も増える
仮想化やクラウドインフラストラクチャを使ってサービスを運用
各マイクロサービスは「独立したプロセス」
必ずしも各マイクロサービスを別のマシンで実行させる必要は無い
ライブラリの依存性などの問題から、
各プロセスはそれぞれ独立したマシン（もしくは仮想マシン、コンテナ）上で実行させる
インフラストラクチャの選定
マイクロサービスアーキテクチャとはやや外れた話題
クラウドインフラストラクチャやコンテナ
各マイクロサービスが使用するIPアドレスが動的に変動する
こういった環境ではほかのマイクロサービスとメッセージをやり取りする際、目的のマイクロサービスに割り当てられているIPアドレスを何らかの方法で特定しなければならない。
冗長性確保やスケーリングのために同じマイクロサービスを並行して複数稼動させる
この場合ロードバランサーのように動的に接続先を管理する仕組みが必要
サービスやそのネットワーク接続を管理するシステムを「サービスメッシュ」
クラスタインフラ管理機能を提供する「Kubernetes」ではシンプルなサービスメッシュ機能が組み込まれている
独自のサービスメッシュ機能を提供するクラウドインフラストラクチャもある
「Istio」や「Linkerd」
インフラストラクチャに依存せずにサービスメッシュ機能を提供するソフトウェア
独自のプロキシを利用してマイクロサービス間の通信を管理する仕組みになっており、
適切な接続の転送に加えて、
ロードバランサーや
ネットワークゲートウェイ、
認証、
モニタリング
などの機能も備える
LinkerdはKubernetesと組み合わせて利用する
IstioはKubernetesを使ったインフラ
仮想マシンベースのインフラも対応している
IaaS型のクラウドサービスでも利用できる
デプロイとアップデート
マイクロサービスアーキテクチャ
サービスを構成するマイクロサービスの数が多くなる
デプロイメント（デプロイ）やアップデート作業の自動化も必要
手作業でいちいち個別にこういった作業を行うのは手間がかかり、ミスなども発生しやすくなる
クラウド型のインフラストラクチャを利用する場合、ある程度はインフラストラクチャ側でデプロイやアップデートのための機能が提供される
Kubernetesでは「deployment」という、デプロイのための機能が用意されている。また、多くのクラウドサービスでは自動化のためのAPIなどが提供されている。
IstioやLinkerdといったサービスメッシュ支援ツールにもデプロイのための機能が用意されている。
こういったデプロイ機能やデプロイツールを利用するメリットの1つとして、
サービスを停止させずに各マイクロサービスのソフトウェアをアップデートしたり、
トラブルを少なくするようなアップデート手法を容易に利用できる点がある。
たとえばシステムのアップデート手法の1つとして、古いバージョンのソフトウェアを稼動させたまま新たに新しいバージョンのソフトウェアを使ってプロセスを立ち上げ、
その後接続先を切り替える、
というやり方がある。
これは「ブルーグリーン（Blue-Green）デプロイメント」と呼ばれるものの一種で、
もしアップデート後に新バージョンのソフトウェアに不具合が見つかった場合、接続先を戻すだけでロールバックを速やかに実行できるというメリットがある
ブルーグリーンデプロイメントは、
元々はデプロイ先の本番環境を2つ用意しておき、
デプロイごとに使用する環境を切り替えるという手法であり、
クラウド型インフラストラクチャではない環境でも利用できたが、クラウド型インフラストラクチャではこういった冗長な構成を容易かつ比較的低コストで実現できるため普及が進んでいる。
また、マイクロサービスアーキテクチャにおいては冗長性を持たせるため、1つのマイクロサービスを複数のプロセスで並行動作させておくことが多い。
そのため、本番環境を一気に切り替えるのではなく順次切り替えていく「ローリングアップデート」と呼ばれるやり方も使われる。
ブルーグリーンデプロイメントを発展させた「カナリアリリース」という手法も考案されている。
カナリアリリースはブルーグリーンデプロイメントと似ているが、複数稼動させているノードのうちまずは少数のノードだけを新しいバージョンのものに入れ替えて様子を見て、問題がなければその後残りのノードを入れ替えていく、という手法だ。
この手法は、かつて炭鉱での作業時に有毒ガスを検知するためにカナリアを持ち込んでいた（もし有毒ガスが発生したら人間より先にカナリアが異常をきたす）という話に由来して「カナリアリリース」と名付けられている。
カナリアリリースを応用した手法として、管理者や一部のユーザーのみに限定して新バージョンを使わせるといった手法もある。
クラウド型インフラストラクチャとマイクロサービス、サービスメッシュの組み合わせでは、比較的簡単に一部のマイクロサービスのみを入れ替えることが可能になる。
これを利用したテスト手法も考案されている。たとえば一部のプロセスのみをあえて不具合を起こすようなものに入れ替えて、そういった場合でも適切にエラー処理が行われシステム全体として適切に動作するかを確認する「フォールトインジェクション」といった手法があり、サービスメッシュ管理ソフトウェアによってはこのような機能を提供するものもある。
ソフトウェアやインフラストラクチャの進化によって実用的になったマイクロサービスアーキテクチャ
このように、
マイクロサービスアーキテクチャではクラウドインフラストラクチャや仮想化、そしてさまざまな周辺ツールが活用されている。
そのため、各マイクロサービスの規模は小さくなるが、その分開発にあたるエンジニアは同期/非同期通信やデータベース、インフラに関するものまで、より幅広い知識が求められる。
また、特に機能毎のサービス分割に関しては十分な検討が必要となる。そのため、開発の際には「とりあえず流行っているから」などの理由でマイクロサービスアーキテクチャを採用するのではなく、
事前に十分に検討を行い、対象システムがマイクロサービスアーキテクチャでの構築に本当に適しているのかを考える必要があるだろう。
なお、プロセス間通信やコンポーネントの分離、デプロイ手法など、マイクロサービスアーキテクチャの考え方はそれ以外のアーキテクチャでも参考になる点も多い。
たとえばメインの処理は非マイクロアーキテクチャで構築し、一部のみをマイクロアーキテクチャ風の形で構築する、といった形も考えられる。
既存システムのアップデートなどでは、こういった手法も十分実用的だろう。
さて、マイクロサービスアーキテクチャの採用例が増えた一因としては、
クラウドインフラストラクチャの普及や関連ツールの登場が大きい。
次記事ではマイクロサービスの構築に使われるサービスメッシュについて、実際の環境構築も含めた解説を行う予定だ。
コンテナアーキテクチャーと比較すると実に面白い。
別の機会にするが、コンピュータービジネスの貪欲なチャレンジって、既に滑稽だなあ！
みずほ銀行ATM単画面 還付詐欺を
地元ヤクザ 送金システムと呼んで
本気で解決するには公表しかないと
俺の後輩に言わせたい
残り3ヶ月は切ったよ！
