あらすじ
DX実現のための基礎技術“マイクロサービス”のポイントを手早く習得
マイクロサービスとは何でしょうか？
小さな粒度のソフトウェアコンポーネントのことでしょうか？
いえいえ、その本質は違います。
マイクロサービスとは、サービス指向の革新的ソフトウェアアーキテクチャに加え、
コンテナやKubernetesといったアプリケーションランタイム、CI/CDや
アジャイルプロセスなどの開発手法、RESTやメッセージングなどによる
アプリケーション連携形態を包含する、クラウドネイティブコンピューティングの
包括的なアーキテクチャスタイルです。
本書では、マイクロサービスを、クラウドネイティブ時代のアーキテクチャスタイル
として捉えて、マイクロサービス流のソフトウェアアーキテクチャに加えて、
コンテナ、Kubernetes、サービスメッシュ、DevOps、ハイブリッド＆マルチクラウド
など、DXを支えるクラウドネイティブテクノロジーの全体像を解説します。
DX実現のための最新技術動向を知りたい方、クラウドネイティブコンピューティング
の概要を理解したい方、そしてマイクロサービスに興味をお持ちの技術者にとって、
本書はおすすめの一冊です。本書でマイクロサービスの本質とポイントを学び、
「2025年の崖」を飛翔のきっかけとしてください。
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
Posted by ブクログ
タイトルからもっと平易な内容かと思ってしまいましたが、思ったより詳しく記載があり濃い内容だと思いました。私は過去エンジニアで、今は違うのですが、自分にとっては良いレベルでした。
Posted by ブクログ
やや自分には内容が高度であり、中身は理解が十分にできていない。
但し、マイクロサービスやコンテナを語る上で、何を知るべきかについて一定程度イメージができたことは収穫。
自らの設計力を実践にて高めた上で、マイクロサービスアーキテクチャーを本書等を再読しつつ構想していきたい。
Posted by ブクログ
色々とインプットしているマイクロサービス系の知識を改めて体系的に眺めることができて良かった本です。
体系的に学べるので初学者にもオススメできるかとは思いますが、実装サンプルが皆無なので、IT技術系の事前知識がない人には少し辛いかも？とは思いました。
Posted by ブクログ
マイクロサービスとは何か改めて理解を深めるため手に取りました。
マイクロサービスを運用する上での設計パターンや留意事項を記載している書籍でした。
この書籍から参考資料へ掘り下げてマイクロサービスへの理解を深めることができると思います。
今まで、大きい単位で管理、ごまかしていたのを細かくすることで浮かび上がりそれに対してどういうアプローチ/ソフトウェアがあるのか紹介をしています。
Posted by ブクログ
・Saga：ローカルトランザクション、イベント、補償トランザクションといった技術や手法を駆使して、複数のリソース間で同期を取るためのデザインパターン。
CQRS(Command Query Responsibility Segregation:コマンドクエリ責務分離)とは、データアクセス処理を、更新系処理(コマンド、すなわちデータの挿入/更新/削除)と参照系処理(クエリ、すなわちデータの検索/取得)に二分し、それぞれの実装にあたって、独立したサービスコンポーネントとデータストアを配すというデザインパターンです(図3.9の上)。その発想の背景には、コマンドとクエリはまったく異なるタイプの処理である、という一種の哲学があります。
■Sagaを実装する2つの手法
・コレオグラフィ：データベースにアクセスするサービスが、それぞれメッセージング製品を介してデータの同期を取り合う方法。
・オーケストレーション：Sagaオーケストレーションと呼ばれる特別なサービスが、トランザクションコーディネーションという役割を受け持つことからアプリケーション層に配置されるアプリケーションサービスとして実装。
■リファクタリングパターンの例
・Anti-corruption layer
Anti-corruption layer (腐敗防止層) は、サービスとモノリス連携において生じる通信プロトコルやアプリケーションプロトコルのギャップを解決するためのマイクロサービスパターンです(4.45)。Anti-corruption layerの仕組みは至ってシンプルで、サービスとモノリスの間に、プロトコルのギャップを解決するためのアダプターを設けるというものです。
たとえば、モノリスがSOAPベースのRPCスタイルのWeb APIを提供していると仮定しましょう。サービスが他のサービス(やモノリス)を呼び出す際には、REST APIやメッセージング等を使うのが、マイクロサービスにおける理想形です。また、前項で説明したように、サービスがモノリスに依存することは避けたほうがよいでしょう。
そこで、Anti corruption layerを活用することにします。「腐敗防止」のためにアダプターコンポーネントを開発して配置します。このアダプターには、サービスから呼び出されるインターフェースとしてREST API、そしてREST API呼び出しを受けてSOAPを介してモノリスのWeb APIを呼び出す機能を実装します。さらに、RESTとSOAPベースのRPCの間でアプリケーションプロトコルを変換するロジックも組み込んでおきます。このようなアダプターを設けることでサービスがモノリスに依存することなく、両者が連携できるようになります。
・Strangler application
次に、クラウドネイティブアプリケーションへの移行に役立つマイクロサービスパターンとして、Strangler applicationについて説明します。図4.46は、Strangler applicationパターンを模式化したものです。まずこの図の見方から解説しましょう。一番左側にPoC局面があり、左から右に時間が流れるのに従って、移行局面がリリース1.0、リリース2.0、リリース3.0と進展しています。各局面の中の上段にはSystems of Engagement(SoE)、すなわち顧客接点のWebアプリケーションのサプシステム群、下段にはSystems of Record(SoR)、すなわち基幹システムのサブシステム群が配置されています。バックグラウンドが白い長方形はモノリシックなサブシステム、バックグラウンドが黒い長方形はマイクロサービス化されたクラウドネイティブサブシステムを表現しています。
移行作業はPoCから始まります。PoC局面ではSoEとSoRの一番右側のサブシステムの一部を、マイクロサービスを利用してクラウドネイティブ化します。それと同時に、SoEとクライアントの境界である図4.46の上段部分にStrangler Podを開発/配置します。Strangler Podとは、業務アプリケーションのメニュー画面をWebアプリケ ーションとして提供する、いわばポータルシステムです。 エンドユーザーは、Strangler Podの提供するメニュー画面で業務名をクリックすることで特定のアプ リケーションを利用するのです。
そこで、Strangler applicationパターンでは、各局面の移行作業が終わったら、アプリケーションへのリクエストがマイクロサービス化されたサービスにルーティングされるように、Strangler Podのメニューアイテムが指し示すURIを書き換えます。このような仕組みを用意しておくことで、移行作業後すぐにサービスをリリースし、エンドユーザーに使ってもらうことが可能になりますし、プロジェクトのスポンサーである経営陣にも、具体的な成果を示すことができます。
また、新規リリースされたクラウドネイティブアプリケーションに障害があった場合には、Strangler Pod上のメニューアイテムが指し示すURIを既存の現行アプリケー ション向けのものに書き換えることで、簡単に実績あるモノリシックアプリケーショ ンに切り戻すことが可能です。
以上のプロセスを、リリース1.0、リリース2.0、リリース 3.0と横展開することで、段階的にアプリケーションのモダン化を進めるのがStrangler applicationバターンです。
ちなみに、いささか物騒ですが、Strangleとは「絞め殺す」という意味です。これは他の植物に絡みつき成長するつたやつるなどの植物が、最終的には宿主となっている植物を覆いつくす様を比喩しています。Strangle applicationとは、マイクロサービスがモノリスを置き換えていく様をイメージしたネーミングなのです。
■サーバーレスとは
サーバーレス(もしくはサーバーレスコンピューティング)とは何でしょうか?サーバーレスとは、一言でいうと「サーバー管理を必要としないアプリケーションを構築して実行する」という概念を表したものです。
また、その名前からよく勘違いされますが、コードをホストして実行するために「サーバーが不要になった」わけではありません。サーバーレスとは、サーバーのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティ/プランニングに時間とリソースを費やす必要がないという考え方を指しています。そして、これらのタスクや機能は、すべてサーバーレスプラットフォームによって処理され、開発者や運用チームから完全に抽象化されます。
その結果として、開発者はアプリケーションのビジネスロジックを書くことに集中することができます。運用エンジニアは、よりビジネス上で重要なタスクに集中することができます。
■サーバーレスのユースケース
ここまで、サーバーレスの概要やアーキテクチャを中心に見てきました。ここでは、それらサーバーレスの特長を活かしたユースケースをいくつか見ていきましょう。特にサーバーレスが有効なのは、以下のようなワークロードです。
○非同期/コンカレント/独立した作業単位へと並列化しやすいワークロード
○要求の頻度が低い、散発的なワークロード
○スケーリング要件のばらつきが多く、予測不可能なワークロード
○ステートレスで短命なワークロード
○ビジネス要件が頻繁に変化し、開発もそれにあわせた迅速さが求められるワークロード
■サーバレスの制約
・サーバレス固有の制約
ステート管理の煩雑さ
レイテンシの大きさ
ローカルテストの難しさ
・現在の実装による制約
コールドスタート
ツールや実行環境の制約
ベンダーロックイン
