「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク～マイクロサービスの設計技法の課題は何なのか

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析を読んでいて、まだ中身を理解できていない。
ネット上の感想記事を自分用にリンクしておく。

【参考】
『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself

（引用開始）
また、最近話題になっていた『ソフトウェアアーキテクチャの基礎』（以降、「基礎」）を執筆した著者陣が書いたもう一冊の本でもあります。
「基礎」はアーキテクトとしての姿勢や、それぞれのアーキテクチャの簡単な概要が中心でしたが、この本はより実践に近く方法論寄りです。「基礎」が「What」を扱うとすれば、本書は「How」を扱うといった関係性でしょうか。
（引用終了）

（引用開始）
現代ではデータをどのように設計し、分割しつつ整合性を保って保管しておくかといった一連の流れの重要度が増しています。この問題についても本書は拾い上げるよう努力しています。[*1]
従来のアーキテクチャの議論では、マイクロサービスはどう分割するかとか、コードの関心事がどうこうとかそういったアプリケーションに限った範囲が中心だったように私は思っています。が、そうではなくデータをどう分割、配置、保管していくかといった問題についても議論に含めるようにしています。
（引用終了）

『ソフトウェアアーキテクチャ・ハードパーツ』完全に理解した - Mirai Translate TECH BLOG

（引用開始）
一言で言うと
「マイクロサービスの大きさと通信方式をどう決定するか」について書かれた書籍です。
（引用終了）

ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12に参加してきた - 天の月

（引用開始）
レガシーで大規模なモノリシックシステムをどう解決していくか？というのを物語形式で紹介してくれているということです。

ソフトウェアの中でも土台となるような部分の決定は「モノリシックなシステムをどう分解していくか？」で前半部分に表現され、「ソフトウェアアーキテクチャをどう決めるか？」は分散システムで直面する難しい問題をどのように決定するか？で後半部分に表現されているということです。

もう少し具体的に言うと、前半部分は戦術的フォークとコンポーネントベース分解を中心に登場人物がトレードオフ分析を行なっている様が描かれており、後半部分は、粒度分解要因と粒度統合要因のバランスによって決定されるという前提をもとに、分解をどこまでするかが具体的に描かれているそうです。
（引用終了）

「ソフトウェアアーキテクチャの基礎」読書感想

【1】「マイクロサービスの大きさと通信方式をどう決定するか」が根本テーマであるとすれば、マイクロサービスの設計上の課題や留意点がテーマになる。

2020年代の現在では、マイクロサービスの実装はAWSなどのクラウド基盤が前提条件だろう。
AWSならEC2ではなく、CloudFormationを使って各種サービスを組み合わせて一体化したシステム設計をするのではないか。
一方、オンプレ環境のシステムでは、弾力的なスケーラビリティ向上、つまりスケールアップやスケールアウトを動的に変更するのは非常に難しい。
逐一サーバースペックをサイジングしてどれだけのスペックを持つべきか見積もりして導入するまでに非常に手間がかかる。

では、マイクロサービスの落とし穴はどこにあるのか？
マイクロサービスの利点や美味しいメリットを得るにはどんな留意点があるのか？

モノリシックな基幹系システムやモノリシックな巨大なシステムをビジネス上の観点でサービスごとに分割して、分散サービス化した時、それぞれのサービスの粒度は小さくなるので運用保守しやすくなる点もあるだろう。
昨今のDevOpsの観点では、小さな開発チームが設計や開発から運用までを担当する流れなので、チームが担当するシステムのサイズは小さい方が実現しやすい。

一方で、複数のサービスを連携して初めて、顧客が満足する1つのユースケースが成り立つような場合、途中でサービスが停止すると成り立たなくなる。
分散サービスのアイデアは20年以上前のCORBAやEJBからずっと言われていては失敗してきたが、クラウド基盤でようやく実現可能な設計手法になった面もあると思う。
僕はまだAWSやクラウド基盤のことは無知なので、今までのオンプレ環境で構築するシステム設計とは違った観点がマイクロサービスの設計にはあるのだろうと思う。

理解できた内容はBlogに残しておこうと思う。

第25回東京Redmine勉強会の感想 #redminet

第25回東京Redmine勉強会についてラフなメモ書き。

【参考】
第25回東京Redmine勉強会 - redmine.tokyo

2023/11/5 第25回勉強会 - redmine.tokyo #redmineT - Togetter

【1】前田剛さんによるRedmine5.1の機能紹介。
おそらく目玉機能は、クエリ検索にOR機能が入ったこと、プロジェクト画面やユーザ画面にクエリ検索機能が追加されたことだろう。
チケット一覧のクエリ検索では、SQLライクにかなり複雑な検索が可能になった。

また、全文検索後に、さらにクエリ検索で絞り込む機能も追加された。
利用シーンとしては、たとえば、Issueで検索して全文検索結果が出た後、さらに担当者や期間、ステータスで絞り検索することで必要な情報にたどりつきやすくなる。

つまり、Redmineを長く使い込んでチケット枚数が多い環境ほど、全文検索やクエリ検索の機能強化のメリットが出てくる。
RedmineはナレッジDBであるからこそ、過去の作業履歴から意味ある内容をいつでも検索できる点は重要なポイントの一つだろう。

【2】前橋市役所のRedmine利用事例はRedmineJapanの再演講演。
講演後に4人の質問があった事実からも、この事例に興味を持つ人が少なからずいたことが分かった。

ポイントはいくつかある。
一つ目は、Redmineを運用するためにかなり準備されていたこと。
たとえば、他部署からの問い合わせを受けて、情報システム部門が1次対応し、ベンダーにエスカレーションすべきかどうか判断していること。
ITILの運用を意識しているように見られた。

他には、事業年度ごとにプロジェクトを新規作成していること。
デメリットは、事業年度のプロジェクトに連なる子プロジェクト、チケットがいったんすべてリセットされること。
一方、メリットは、公務員は3年おきに配置転換されて担当がコロコロ変わるし、年度ごとのオペレーションの意義が重要なので、年度末にすべてのチケットを棚卸しするタイミングが発生することもあるようだ。

2つ目は、アジャイル開発のプラクティス、たとえば、KPTによるふりかえりを効果的に利用してプロセス改善活動につなげていること。
3つ目は、他の自治体とも連携してRedmine運用の幅を広げていること。

プライベートクラウドに載せているのでベンダにサーバ運用はお任せしているみたいだが、実運用に注力している点が興味深かった・

【3】RedmineのチケットDBをNoSQLのグラフDBで関連度合いをグラフ化し、関連チケットや類似チケットを表示する機能追加の事例もあった。
特徴は、RDBではチケットの関連度合いをSQL検索するのは時間がかかりすぎるが、グラフDBであれば検索機能もSQLライクに書けて、性能応答もかなり高速であること。
この特徴を活かして、関連チケットや類似チケットをチケット画面に表示する機能を追加したらしい。

レコメンドエンジンをRedmineのようなチケットDBに適用することで、お勧めチケットを表示する機能改善のアイデアは以前からあった。
その場合、機械学習で学習させる事前処理が必要だったが、今回の機能追加では、グラフDBへ格納する事前処理に置き換わった点があると思う。
この辺りのメリット、デメリットを聞いてみたいと思う。

【4】チケット管理システム有識者の集いのパネルディスカッションでは、Redmine・Jira・Asana・Backlogのユーザがパネラーとして意見を述べ合う話があった。

僕が興味深く聞いた点は、3つある。
1つは、プロジェクトとタスクの違いは何か？
プロジェクトは期間や独自性がある点、プロジェクトは引き継ぎの大きな単位、などのツイートもあり、興味を引いた。
やはりプロジェクトの基本は、達成したい目的があり、期間が限定されていることだろう。
実際、市役所での事業年度ごとのプロジェクト、農作業を毎年行う年度のごとのプロジェクトのように、繰返し性や定常業務の意味合いが強くても、何らかの期限を切っている。
そして、そのプロジェクトの作業履歴は過去資産として次年度にも流用する。
そういう観点があると思う。

2つ目は、Asanaのコンサルの方が話されていたが、プロジェクト型の仕事とプロダクト型や定期タスクのようなオペレーションでは、仕事のやり方が異なること。
プロジェクトの仕事はQCD管理が基本。
やはり納期が決まっているので、納期厳守が必須で、それが一番の評価になる。
一方、プロダクト型や定期タスクでは、明示的な納期がないので、日々の改善がタスクになり、プロジェクトという概念があまりない。
評価基準も変わってくる。

3つ目は、Asanaのコンサルの方が話されていたが、プロジェクトに入っているSIメンバーの立場と、既に事業やオペレーションを回しているユーザ企業の立場は異なること。
ユーザ企業であれば、既に事業は回っているし、その事業を強化する課題を一つのプロジェクトに切り出しているだけであって、プロジェクトは一つの部品に過ぎない。
しかし、プロジェクトに入っているメンバーや契約したコンサルは、その中で成果を出そうとするが、その観点が現場寄りであり、ユーザ企業の目線と異なるので、目的や評価が変わってくる時がある。

【5】コロナが終わってオフライン勉強会は3回目だが、盛り上がって楽しかった
Backlog、Jira、Asanaユーザの方から、11月3連休のど真ん中の休日に懇親会までこんなに人が集まるのはすごい、すごい熱気ですね、と言われた。

確かに、北海道、福岡、松江、山梨からも来られている人もいて、本当にありがたい。
また、いつものコアメンバーが盛り上げてくれたし、懇親会で聞くと、土木建築業界のユーザが問題意識を持って初参加されたり、友人紹介で初参加されたり、多様な人が入ってきたのはよかったし、刺激にもなった。

僕も今までたくさんのコミュニティ活動をしてきたけれど、ここまで皆が熱気を持つコミュニティは少ないと思う。
年2回、5月と11月に間を開けて定期的に開催するリズムも心地良い。
また来年も開催したいなと思う。