森山京平のレビュー一覧

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

タイトルからもっと平易な内容かと思ってしまいましたが、思ったより詳しく記載があり濃い内容だと思いました。私は過去エンジニアで、今は違うのですが、自分にとっては良いレベルでした。

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

やや自分には内容が高度であり、中身は理解が十分にできていない。
但し、マイクロサービスやコンテナを語る上で、何を知るべきかについて一定程度イメージができたことは収穫。
自らの設計力を実践にて高めた上で、マイクロサービスアーキテクチャーを本書等を再読しつつ構想していきたい。

絵で見てわかるクラウドインフラとAPIの仕組み

平山毅 / 中島倫明 / 中井悦司 / 矢口悟志 / 森山京平 / 元木顕弘

難解　マルチクラウド下で、ＡＰＩをキーとして、システムを構築するＡＰ基盤のためのテキスト　基盤エンジニア向けなのでＩＴ関連以外にはおすすめしません。
　
１回目は、流れと、図表を中心とした全体を確認しましたが、イメージがつかめませんでいた。何回も読み直すことになりそうです。

ＡＰＩとの連携について

①クラウド、②ＷｅｂＡＰＩ、③ネットワーク、④オーケストレーション、⑤認証、⑥ストレージ、⑦マルチクラウド、そして、⑧アプリケーションのライフサイクルに合わせて管理するインフラ環境　

構成は以下の通りです。

第　１章　クラウドコンピューティングにおけるＡＰＩの役割
第　２章　クラウドの代表的コンポーネント
第　３章　クラウドを制御するＡＰＩの仕組み
第　４章　ＩＴインフラの進化とＡＰＩの考え方
第　５章　サーバーリソース制御の仕組み
第　６章　ブロックストレージリソース制御の仕組み
第　７章　ネットワークリソース制御の仕組み
第　８章　オーケストレーション
第　９章　認証とセキュリティ
第１０章　オブジェクトストレージ制御の仕組み
第１１章　マルチクラウド
第１２章　Immutable Infrastructure

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

色々とインプットしているマイクロサービス系の知識を改めて体系的に眺めることができて良かった本です。

体系的に学べるので初学者にもオススメできるかとは思いますが、実装サンプルが皆無なので、IT技術系の事前知識がない人には少し辛いかも？とは思いました。

絵で見てわかるクラウドインフラとAPIの仕組み

平山毅 / 中島倫明 / 中井悦司 / 矢口悟志 / 森山京平 / 元木顕弘

タイトルは簡易な印象も受けるが、かなりボリュームあります。
クラウドインフラとして、AWSとopenstackを例に挙げて解説してます。
インフラ基盤の構築の考え方がどんどん進化しているのがよくわかる

絵で見てわかるクラウドインフラとAPIの仕組み

平山毅 / 中島倫明 / 中井悦司 / 矢口悟志 / 森山京平 / 元木顕弘

クラウドインフラの普及とAPIの関連性がとても解りやすい言葉とイラストで説明されており、同時に今求められているビジネスニーズとテクノロジーの関係、なぜAPIエコノミーというAPIを中心とした経済圏が台頭しているかが明らかにされている。技術バックグランドがオンプレミス型に基づいている自分のようなエンジニアだと、分かったつもりでいて見過ごしていた「ナゼナゼ」部分が丁寧の解説されていて、とても勉強になった。

絵で見てわかるクラウドインフラとAPIの仕組み

平山毅 / 中島倫明 / 中井悦司 / 矢口悟志 / 森山京平 / 元木顕弘

原理がわからないと実装・展開イメージがわきません。
ざっとおさらいするだけじゃなく、ちょこっと詳しく書いてある感じがとっても参考になりました。

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

マイクロサービスとは何か改めて理解を深めるため手に取りました。

マイクロサービスを運用する上での設計パターンや留意事項を記載している書籍でした。

この書籍から参考資料へ掘り下げてマイクロサービスへの理解を深めることができると思います。

今まで、大きい単位で管理、ごまかしていたのを細かくすることで浮かび上がりそれに対してどういうアプローチ/ソフトウェアがあるのか紹介をしています。

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

まぁ、範囲が広い技術なので、かいつまんでの説明になっているけど
目次としては良いと思う
CNCFのリンクは初めて知ったし

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

・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とは、マイクロサービスがモノリスを置き換えていく様をイメージしたネーミングなのです。


■サーバーレスとは
　サーバーレス(もしくはサーバーレスコンピューティング)とは何でしょうか?サーバーレスとは、一言でいうと「サーバー管理を必要としないアプリケーションを構築して実行する」という概念を表したものです。
　また、その名前からよく勘違いされますが、コードをホストして実行するために「サーバーが不要になった」わけではありません。サーバーレスとは、サーバーのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティ/プランニングに時間とリソースを費やす必要がないという考え方を指しています。そして、これらのタスクや機能は、すべてサーバーレスプラットフォームによって処理され、開発者や運用チームから完全に抽象化されます。
　その結果として、開発者はアプリケーションのビジネスロジックを書くことに集中することができます。運用エンジニアは、よりビジネス上で重要なタスクに集中することができます。


■サーバーレスのユースケース
　ここまで、サーバーレスの概要やアーキテクチャを中心に見てきました。ここでは、それらサーバーレスの特長を活かしたユースケースをいくつか見ていきましょう。特にサーバーレスが有効なのは、以下のようなワークロードです。
　○非同期/コンカレント/独立した作業単位へと並列化しやすいワークロード
　○要求の頻度が低い、散発的なワークロード
　○スケーリング要件のばらつきが多く、予測不可能なワークロード
　○ステートレスで短命なワークロード
　○ビジネス要件が頻繁に変化し、開発もそれにあわせた迅速さが求められるワークロード

■サーバレスの制約
・サーバレス固有の制約
　ステート管理の煩雑さ
　レイテンシの大きさ
　ローカルテストの難しさ
・現在の実装による制約
　コールドスタート
　ツールや実行環境の制約
　ベンダーロックイン

絵で見てわかるマイクロサービスの仕組み

樽澤広亨 / 佐々木敦守 / 森山京平 / 松井学 / 石井真一 / 三宅剛史

マイクロサービスとはなんぞや本。
概念を知りたい人向けの一冊。

実際自分の担当するシステムに、適用すべきかどうか？といったジャッジには直接的に役立つものではない。
おおよそのシステムがマイクロサービス不向きなような。

絵で見てわかるクラウドインフラとAPIの仕組み

平山毅 / 中島倫明 / 中井悦司 / 矢口悟志 / 森山京平 / 元木顕弘

「APIの仕組み」という表題から、プログラム寄りの内容かと想像していたが、どちらかというと仕組みの解説が多い印象だった。

説明は図等を用いて工夫はされていたが、いかんせん内容そのものが難しくてよく理解できなかった。

クラウド以前のハードそのものの仕組みをまず理解していることが前提で、その上でどこが抽象化され、それをどのように動かすか・動かすことができるか・それらはどのような仕組みになっているのかを理解するといった感じで、プログラムの知識はあまり必要なく、むしろインフラ環境を構築・運用した経験の方が内容の理解のために必要と感じた。

ただまあ何となくではあるが、ハードウェアの仮想化というものを、操作・構築の観点でイメージを持って理解できた気はする。