ざきの学習帳(旧 zackey推し )

日々の学びを書きます

マイクロサービスパターン を読み始めました / Chapter01 モノシリック地獄からの脱出

モノシリックなアプリケーションをどのような方法で分割、周りを巻き込んでいくか。
また、本当に分割すべきなのか?を学ぶため、 マイクロパターンサービスを読み始めました。

全ページで500ページ超と、読み切るのは先になりそうなため、
読了して気になった章・部分を書き留めていこうと思います。

目次

  • 本書について
  • 1.1 ゆっくりとした足取りによるモノシリック地獄への転落
  • 1.2 本書がみなさんにとって意味を持つ理由
  • 1.3 本書で学べること
  • 1.4 マイクロサービスアーキテクチャで状況打開
  • 1.5 マイクロサービスアーキテクチャの利点と欠点
  • 1.6 マイクロサービスアーキテクチャのパターン言語
  • 1.7 マイクロサービスを越えて: プロセスと組織
  • 1.8 まとめ

概要

冒頭「本書について」では、ロードマップを示してくれています。
ざっくりかいつまむと、

  • モノシリックアプリケーションの事例と症状の説明
  • マイクロサービスパターンとは何か?
  • マイクロサービスにおけるパターンの紹介と深掘り
  • デプロイやサービスメッシュ
  • モノシリックアプリケーションにマイクロサービスパターンを段階的に適用していく方法の紹介

というような流れで、13章構成となっているようです。

また、本書のマイクロサービスアーキテクチャの定義は、以下の本が源流となっているとのことです。

気になったところ

X,Y,Z軸スケーリング

スケールキューブ(The Scale Cube)という概念の紹介がありました。

前職では、AWSのElasticBeanstalkで最小・最大インスタンスを指定し、スケーリングをさせていたのですが、それがスケールキューブでいうX軸スケーリングに当てはまることがわかりました。

ただ、Z軸スケーリング(リクエストをルーティングさせて、使用するアプリケーションインスタンスを制定する)の方法はあまり見たことがなく、事例とかあったらどのように実現しているか、とても見てみたい...。

パイプ・サイクル

本書では、マイクロサービスアーキテクチャが万能薬ではないことを説明してくれています。

その説明の中で、ハイプ・サイクルという理論が紹介されていました。

ja.wikipedia.org

www.gartner.com

新しい技術が出てくると、

  • この技術すげー、銀の弾丸だ!
  • あれ、すごいけど実践ではほとんどうまくいかなくね...(成功することもあるけど)
  • もうこの技術はダメぽ
  • ダメなわけではなくて、適切な使い方ができていないだけだ
  • この技術はこう使用すべき、これ以外は別の技術採用を考えた方がいい

のような傾向になるのが多い印象です。

このような技術(テクノロジ)のライフサイクルをハイプ・サイクルと呼ぶそうです。

新しいことを目の当たりしたり、覚えたりすると、それを実行・実践したくなる気持ちになります。気持ちの高ぶりを抑えて、本当に有効かということを観点において、議論してくことが大切だと、ハイプ・サイクルを見て感じました。

トランジション・マネジメント

1.7 マイクロサービスを越えて:プロセスと組織では、マイクロサービスアーキテクチャを適用するには、システムだけでなくチーム・人の感情にも目を向けるべきという話がありました。

モノシリックアプリケーションにマイクロサービスアーキテクチャを適用しようとすると、当然、適用するための知識やマインドをみんなが身につけていく必要があります。

ただ、新しいことを身につけ、確立するまでには混乱・葛藤、苦戦することもあります。

その感情や反応をマネジメントする方法として、トランジション・マネジメントが紹介されていました。

このマネジメントは開発だけでなく、チームビルディングや、新しいことを始める自分自身を引き上げるための方法としても、利用できそうに感じました。

ページ数も200ページ未満のようなので、折を見て読み進めたいと思います。

おわり

単に技術を語るだけでなく、モノシリック・マイクロサービスアーキテクチャのそれぞれの利点。また、チーム開発をする上で必要なことも含めて書かれており、2章以降を読む意欲が上がりました。

また、13章では、本書内で登場するモノシリックアプリケーションにマイクロサービスアーキテクチャを段階的に適用する方法も書かれています。この13章が一番読みたい章のため、理解するための前提知識を辞書引きしながら、かいつまんで読み進めたいと思います。

(あー、本書を読んだ人たちの感想や解釈を見てみたい...)

じぶん Release Notes ver 0.30.9

f:id:kic-yuuki:20200802174918p:plain

先月分はこちら -> じぶん Release Notes ver 0.30.8 - ざきの学習帳(旧 zackey推し )

  • 学んだこと
      • 読書中
      • 完了
  • ブログ
    • PV数
  • Challenge Every Month
    • 2020/07の結果
    • 2020/08の目標
  • おわりと所感
    • 副業をはじめる
    • JUDGE EYESが楽しかった
続きを読む

モダン・ソフトウェアエンジニアリング 第1部・第2部を読んで / ソフトウェア開発における理論って?

今月から、モダン・ソフトウェアエンジニアリングを読み始めました。

全23章(4部構成)と少し長めの本のため、中間である第2部が終わった時点で、読書メモを書いておきたいと思います。

  • なぜ読み始めたか?
  • どんな本か?
    • Essenceについて
  • 学び・気づき
    • 他業界に比べて、ソフトウェア開発には理論が語られない
    • なぜ理論が語られないのか?
      • 見解
    • Essenceは記述的な理論を提唱する
  • おわり
続きを読む

腎機能が低下し、タンパク質のとりすぎに気をつけるようになった

2020/07の初旬頃、早朝に寒気と高熱が発生、病院へ行ってきました。

スポーツドリンク等の味もするし、3密に当てはまる箇所へ赴いた心当たりがなかったため、病院へいきました。

2日後、血液検査が出ました。結果、腎機能が低下していたことがわかりました。

この記事では、腎機能低下の原因と対策について、メモしておきたいと思います。

  • なぜ腎臓が悪くなったのか?
    • タンパク質の過剰摂取
  • 予兆
  • 対策
    • 低タンパク質・低塩分な食事
      • ごはん・レトルト
      • カロリーアップ
    • 水分補給
  • おわり
続きを読む

Design It!の輪読会が終わった / 実際の開発メンバーと輪読会すると効果が高い本と思った

challenge-every-monthというコミュニティで行なっていた、Design It!の輪読会が終わりました。

yoshitaku-jp.hatenablog.com

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

  • 作者:Michael Keeling
  • 発売日: 2019/11/25
  • メディア: 単行本(ソフトカバー)

まだ、全体振り返り&打ち上げの意味を含めた、座談会を残していますが、Design It!を読んで&輪読会を経て、とくに自分が記憶に残った学びや気づきをメモしておきたいと思います。

輪読会について

輪読会の「輪読1」は

数人が一冊の本をかわるがわる読んで解釈し意見を交わすこと。

と言う意味です。

今回、自分が輪読会に参加したのは、以下の理由からです。

  • 読破するモチベーションを高める
  • 理解を深める(1人だと理解が曖昧なところを、他人と意見を交わすことで深掘りできる)

会社でも輪読会を実施されているところがあるようです。

実施方法

以下のような形で実施しました。

  • 参加人数 ... 5人
  • 読書ペース ... 1章/週
  • 使用ツール ... Slack / Zoom / Jamboard / Google Slides

輪読会メンバーに感謝

輪読してくれるメンバーがいることで、議論が発生・理解が深まりました。本当にお疲れ&ありがとうございました!

(以下、輪読会に参加された方のブログリンクです)

Design It!について

読もうとした理由

なぜこの本を読もうと思ったかの理由は以下です。

  • プロダクト開発において、詳細設計・開発だけでなく、ステークホルダーとどのように関われば良いかの指針を知りたい
  • チーム開発において、設計の判断をどのように記録・インデックス付けするかを知りたい

学び・気づき

いますく実践できるということに着目し、学び・気づき点を記載します。

ステークホルダーには、開発チームも含まれる

「4章 ステークホルダーに共感する」では、ステークホルダーは誰なのか?解決すべき問題をどのように話し、設計を始めるのか...ということを教えてくれています。

本章にて、ステークホルダーは「ソフトウェアに興味関心を抱く人たち」と定義されている。ステークホルダーには、実際に使用するユーザーはもちろん、開発チームも含まれています。

なぜ、開発チームがステークホルダーに含まれるのか?
それは、品質特性・トレードオフ・技術的負債を議論するために必要な、ビジネス目標(ソフトウェアを使って、何を達成したいか)を定義するためです。

ビジネス目標の例(社内システムを使い、売り上げをたてるイメージ)

ステークホルダー ビジネス目標
ユーザー 担当業務の効率化、利益向上
開発チーム(改善) 要求分析〜リリースまでの時間短縮
開発チーム(新機能) 保守しやすいアーキテクチャ設計

ユーザー・開発チームに限らず、ソフトウェアに関わる人々をステークホルダー、ビジネス目標を定義することにより、何をどのような優先度で開発を進められる...という点が学びとなりました。

手法「ステークホルダーマップ」

ステークホルダーを洗い出し&視覚化する手法として、「ステークホルダーマップ」という手法が紹介されていました。

uxdaystokyo.com

アーキテクチャを記録する「アーキテクチャデシジョンレコード(ADR) / アーキテクチャ俳句」

11章「アーキテクチャを記述する」では、アーキテクチャを明文化し、チームメンバーへアーキテクチャを伝えるマインドや手法が紹介されていました。

印象的だったのは、以下の手法です。

手法 概要 参考資料
アーキテクチャデシジョンレコード(ADR) アーキテクチャの意思決定を記録する Architecture Decision Records導入事例 | Fintan
アーキテクチャの意思決定を記録する Lightweight Architecture Decision Records について - Tbpgr Blog
アーキテクチャ俳句 アーキテクチャの重要部分を1枚絵に収めて説明する Architecture Haiku

のような運用方法が推奨されています。アーキテクチャ俳句を読むことで、全体像(またはアーキテクチャの重要部分)を理解、詳細はADRを辿る...というような導線ですね。

「どのような歴史を辿り、今のアーキテクチャに至ったのか?」「なぜAというFWを採用し、Bを選ばなかったのか?」というアーキテクチャの歴史を知ると、(とくに参入時期の浅いメンバーの)アーキテクチャへの関心と理解が深まり、今後どのような設計にすべきかも考えやすくなります。

アーキテクチャの歴史は、自分の経験上、以下のような方法で知ることが多いです。

上記は理解の個人差が発生してしまいますが、アーキテクチャ俳句 x ADRの手法を用いることで、「アーキテクチャの歴史」理解を平準化の方向に持っていける...という点が学びでした。

おわり

座談会でさらなる気づきも得られると思いますが、とりあえずここまでです。

Design It!は、実業務がアーキテクトではなくても(プログラマーであっても)、個人からでも始められることが書いてありました。

しかし、実際の開発(会社)のメンバーでDesign It!の輪読会を行うと、アーキテクトの考えをメンバー全体で咀嚼・実践でき、効果が高いと感じました。

もし、今からDesign It!を読もうと思っている方がいらっしゃいましたら、ぜひ開発メンバーを誘い、輪読会またはディスカッションの場を設けることをお勧めします。