こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- 基調講演：ソフトウェアアーキテクチャ・ハードパーツ by島田 浩二さん
- 事例講演：「ソフトウェアアーキテクチャ・ハードパーツ」の視点から見たオープンロジのアーキテクチャ改変事例 by大平 哲也さん
- Q＆A
- オブジェクトを分散させるな(分散オブジェクト設計第一の法則)という考え方があるが、近年は分散化のの通信コストや複雑性は低下したと考えていいのか？また、それはなぜか？
- SIと継続的なアーキテクチャ改善の相性が悪いのだが、どのように変えていくと良いか？
- どのような段階でマイクロサービス化を考えるべきか？
- ADRが残されていないようなPJで高額なランニング費用に悩まされている。どのハードパーツから優先的に見直すと良いのか？
- ADRの導入/メンテナンス
- マイクロサービスの初期設計や標準化はアジャイルよりWF的に進めるのがベターだと考えているが、このあたりはどのように進めるのがよいか？
- マイクロサービス化すると、各サービスで通信している時はどのようにエラーハンドリングするべきか？
- 「ソフトウェアアーキテクチャ・ハードパーツ」では、モノリスからマイクロサービスの再構築がテーマなのか？モジュラモノリスのような考え方は紹介されているのか？
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。
しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。
今回の第12回目では2022年10月27日に発売されたばかりの『ソフトウェアアーキテクチャ・ハードパーツ』を取り上げます。ソフトウェアアーキテクチャには、難しい問題やベストプラクティスが存在しない問題など、妥協点の中から選択しなければならない事柄が数多くあります。その中で少しでもより良い選択をする為にはどうしたら良いのか、どのようにして「最悪でないもの」を探るのか、そのような事柄を人気書籍である『ソフトウェアアーキテクチャの基礎』を翻訳され、本書の翻訳も手掛けられた島田浩二氏をお招きしてお伺いしていきます。
会の様子
基調講演：ソフトウェアアーキテクチャ・ハードパーツ by島田 浩二さん
ソフトウェアアーキテクチャ・ハードパーツ本の概要
まず、書籍の特徴に関する言及がありました。
本書は、読むことで正解を学べるような書籍にはなっていないものの、現場でアーキテクチャに関する意思決定をする際に、どのような点を考慮した方が良いのか？が分かる本になっているそうです。
また、「ソフトウェアアーキテクチャの基礎」に記載されているような考え方は前提になっている部分がある一方で、「ソフトウェアアーキテクチャの基礎」を読まないと読めないような書籍構成にはなっていないので、そこは安心してほしいという言葉もありました。
タイトルに込められた思い
- ソフトウェアの中でも土台となるような部分は変更がハードである
- ソフトウェアアーキテクチャは決めるのがハードである
という2つのハードがタイトルに込められているそうです。
本書が目指していたこと
ソフトウェアアーキテクチャで「どうやって？」を一般論として答えるのは非常に難しいため、本書ではコンテキストを限定してアーキテクチャの議論を進め、この議論の過程を読者が追従することで、読書が意思決定のスキルを高められるようにしてくれているという話がありました。
本書の概要
レガシーで大規模なモノリシックシステムをどう解決していくか？というのを物語形式で紹介してくれているということです。
ソフトウェアの中でも土台となるような部分の決定は「モノリシックなシステムをどう分解していくか？」で前半部分に表現され、「ソフトウェアアーキテクチャをどう決めるか？」は分散システムで直面する難しい問題をどのように決定するか？で後半部分に表現されているということです。
もう少し具体的に言うと、前半部分は戦術的フォークとコンポーネントベース分解を中心に登場人物がトレードオフ分析を行なっている様が描かれており、後半部分は、粒度分解要因と粒度統合要因のバランスによって決定されるという前提をもとに、分解をどこまでするかが具体的に描かれているそうです。*1
また、各章は、コンテキストパート→解説パート→結論パート、という順で進んでいるという紹介もありました。
本書の注意点
最後に本書の注意点として、以下の2つが挙げられていました。
- コンテキストを定めることで読みやすいものにできた反面、コンテキストから外れる部分については触れられていない
- 扱われているコンテキストは「今」の技術環境に基づいているので、時の変化とともに、取り得る選択肢やトレードオフも変わっていく
事例講演：「ソフトウェアアーキテクチャ・ハードパーツ」の視点から見たオープンロジのアーキテクチャ改変事例 by大平 哲也さん
続いて、オープンロジの大平さんから、オープンロジで現在実践しているモノリシックなシステムを分散アーキテクチャシステムに改変している話を聞いていきました。
モノリシックなシステムでもビジネスやサービスが円滑に回っているのであれば問題ないと考えているそうですが、オープンロジではテストの実行時間が遅くなるなど開発効率の低下に関する問題が出てきているそうで、
- 開発効率の向上
- 運用効率性の向上
- 可観測性の向上
- システムの堅牢性の向上
を目指してシステム改変に取り組んでいるということです。
本書で言われている分解は、「新規に開発するコンポーネント」*2と「共通基盤として整理すべきもの」に2軸で機能分解をして、統合は、「共有サービス」の形で実践しているということでした。
このような方法をとったことで、当初目的としていた開発効率は向上し、インフラ部分でベストプラクティスの導入にも成功したそうです。
一方で課題/反省点もあるということで、
- 既存コード全体の分析が必ずしも行われているわけではないため、個別最適に陥る可能性がある。本に書かれているような「コンポーネントの特定及びサイズ調整パターン」を活用できると考えている
- ADRを含め、決定事項が文書として残っていないので、方向性がぶれたり個々人の認識齟齬が発生していた。今はPRDやDesign Docsなどで設計書を作成しようという流れになっている。(厳密にいうとADRとPRD&Design Docsは違うが、)
- 横断的関心ごとについて、新しいアーキテクチャでコードや機能*3をどのように再利用するかの整理が足りていなかったため、コピペコードなどが一部見受けられた。*4
- システムスタックとチーム構成が乖離しているため、SREチームがアプリ開発に深く入り込んでいたりする。現在は最適化に向けて進んでいる。
などなど、まだ考慮の余地があると考えられているということでした。
Q＆A
以下、Q&Aセッションの様子を常体で書いていきます。
オブジェクトを分散させるな(分散オブジェクト設計第一の法則)という考え方があるが、近年は分散化のの通信コストや複雑性は低下したと考えていいのか？また、それはなぜか？
- クラウドによるサーバ構築コストの低下などはあるが、オブジェクトを分散化させることは前と同じく大変。
- ビジネスをスケールさせるためにBigTechがマイクロサービスを導入して、技術的にも分散システムを作りやすいように後押しした結果、真似をしてまだマイクロサービスを導入する段階でない企業もこうした構成をしだしたために敷居が下がったように見えるかもしれないが、今までと同じように分散オブジェクトがあればシステムの複雑性は上がる。
- ネットワーク的なコストも考えると質問の通り今も複雑になると思われる。ただ、単一なモノリシックなシステムだとデプロイパイプラインの速度低下やビジネス要件への素早い対応が難しいなどといった課題も出てくる。そのため、複雑性をとってでもこういった課題に対処する必要が出てきたから分散化を検討する、というような話になっていくと思う。分散化が楽になったからマイクロサービス、みたいなことはない。
SIと継続的なアーキテクチャ改善の相性が悪いのだが、どのように変えていくと良いか？
- SIというと一括りにしすぎな気はするが、継続的にシステム改善をする前提で最初から話をするようにしている。
どのような段階でマイクロサービス化を考えるべきか？
- 「モノリスからマイクロサービスへ」の本に書かれているような内容が参考になると思う。それぞれに対してマイクロサービス以外の選択肢を幾つも提供してくれるので、本当にマイクロサービス化するの？というのは考えてほしい。
- マイクロサービスって準備が必要*5になるし、それを受け入れる組織体制があるのか？という問題もあるので、非常に難しいと考えている。そのため、組織がマイクロサービスに耐えうる基準があるのか？という観点で検討する。また、マイクロサービスか否か、という観点になっているのはおかしい。
ADRが残されていないようなPJで高額なランニング費用に悩まされている。どのハードパーツから優先的に見直すと良いのか？
- コンテキストがわからないので解答が難しいのが正直なところだが、バーベル戦略の考え方は参考になるかもしれない。やってすぐに(あるいは簡単に)よくなることはどんどんやっていくようにするのがいいかもしれない。
- ADRが残されていないが故にどういう背景で意思決定されているのか理解できない、という部分と、数年経っても成功体験が掴めないのは一番疲弊すると思う。
ADRの導入/メンテナンス
- 導入は最近頑張っている企業が多い印象があるが、メンテナンスが非常に難しくて苦戦している気はする。ADRが適切に運用できるようなチームなら、ADR以外の方法で適切にドキュメントが残って運用しているのでは？と思う
- 意思決定は早いけど何も残っていないというパターンか、ドキュメントを頑張るんだけど何が正しいドキュメントなのかわからずソースコード任せになるパターンが多い。人間の性善説に頼ってしまうと、クオリティが人に依存したりしてしまうので、ある程度強制力は持たせた方が良いと思う(例えばとある条件をパスしないとpushできないなど)
マイクロサービスの初期設計や標準化はアジャイルよりWF的に進めるのがベターだと考えているが、このあたりはどのように進めるのがよいか？
- WFかアジャイルか、みたいな部分は解像度をもう少し上げないとコメントが難しい。事前準備がそれなりに大掛かりに必要だという話なら、それは当然で、開発プロセス云々ではなく、仕事のやり方として考えないといけない。
- WFかアジャイルかは別にして、最初にこのあたりを決めておくのが重要だとは思っている。機能要件の検討などで決定が後回しになってしまうと大変なことになる。
マイクロサービス化すると、各サービスで通信している時はどのようにエラーハンドリングするべきか？
- 残念ながら一般論はない。どのワークフローを扱っているかやどれくらい重要なデータを扱うか？で決まる。
- 基本的にはエラーが起こってしまう前提でシステムを組んで、設計の中でデータの状態遷移の不整合が発生した場合のフローも盛り込んで設計するのが重要。それらが乱れた場合に監視をするところも作り込む必要がある。
「ソフトウェアアーキテクチャ・ハードパーツ」では、モノリスからマイクロサービスの再構築がテーマなのか？モジュラモノリスのような考え方は紹介されているのか？
- 本書で書かれているのはトレードオフ分析だが、「ここはモジュラモノリスで言うと変数を固定して進めているんだな」というように読むことはできる。個別具体な部分は自分達の技術基盤からアプローチしていくのがいいかな？と思っている。
会全体を通した感想
島田さんの講演は見事に本の概要をまとめてくれた上で、読む上での注意点や、本を読む上で意識するといいことなどが丁寧にされていて、非常に参考になる話でした。いつも通りの落ち着いた語り口もよかったです。
事例講演も、アーキテクチャ改変で成功した部分だけではなく、どのような部分が課題として残り、どのように対処していこうと思っているのか？というお話を聞くことができてよかったです。
今回は特に、ソフトウェアアーキテクチャがテーマだったので、非常にありがたく感じました。
最後のQ&Aでも、コンテキストを限定したりしつつ、一つ一つの質問に対して限られた情報で丁寧に答えてくれていたので、聞いていて終始楽しかったです。
