目次
■ソフトウェア設計とメンテナンス
2023.01.05 2024.03.15 約4分
| この記事は 2022年10月発売 『ソフトウェアアーキテクチャ・ハードパーツ―分散アーキテクチャのためのトレードオフ分析』を取り上げた connpass勉強会 を再編集し、記事化したものです。 |
こんな方におすすめ
島田：現代のソフトウェアアーキテクチャ（主にマイクロサービスアーキテクチャ）で直面するベストプラクティスが存在しない難しい問題への取り組み方を解説しています。正解ではなく読者の状況に合わせ選択するための材料を与える本です。2022年03月出版『ソフトウェアアーキテクチャの基礎』に記される「ソフトウェアアーキテクチャの基本的な考え方」が前提ではありますが、未読でも問題ないよう配慮された構成になっているのでご安心ください。
島田：タイトルの「ハードパーツ」は、2つの意味が込められています。
① ソフトウェアアーキテクチャそのものがハード
ソフトウェアの中でも、後から変更するのが難しい堅い部分（ハード）があるという意味
② ソフトウェアアーキテクチャ上の決定がハード
ソフトウェアアーキテクチャで扱う問題は、決めるのが難しいハードな問題であるという意味
島田：本書は2022年03月出版『ソフトウェアアーキテクチャの基礎』で盛り込むことができなかった2つのトピックスを分かりやすく解説しています。
盛り込むことができなかったトピックス
① ソフトウェアアーキテクチャそのものがハード
→ どう変えていくか？
② ソフトウェアアーキテクチャ上の決定がハード
→ どう答えていくか？
アーキテクチャの問題に対して「どうやって」を一般論的に答えるのは、とても難しい
| “アーキテクチャではすべてがトレードオフだ。だからこそアーキテクチャのあらゆる問いに共通する答えは「場合による」のだ（中略）RESTとメッセージングはどちらが良いか。マイクロサービスは正しいアーキテクチャスタイルなのか。こういった問いに対する答えをGoogleで見つけることはできない。それは場合によるからだ。答えはデプロイ環境やビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、その他多くの要因に依存する。環境や状況、問題点はそれぞれに異なるものだ。だからこそアーキテクチャは難しい。” ソフトウェアアーキテクチャの第一法則より |
本書はこれを分かりやすく伝えるため、1つの具体的なコンテキストに沿ってアーキテクチャの議論を進める作りになっています。
島田：具体的なコンテキストには「Sysops Squad サーガ」を用いています（サーガとは長編の英雄物語 のこと）。あらゆる技術書が事例をもとに解説しているように、本書は物語形式で事例を紹介しています。これによりアーキテクチャを考えるための設定・状況・環境をイメージしやすくなっています。
島田：よくある話ではありますが、問題を多く抱えたレガシーで大規模なモノリシックシステムの問題を（分散システムにすることで）どう解決していくかというストーリーです。
「Sysops Squad」は、電機メーカーのテクニカルサポートの名称です。顧客はサポートを受けるためにシステムにチケットを登録し、サポートが完了するとチケットが消化される仕組みです。ユーザ管理をするシステム管理者や、レポート作成をするマネージャーなどもいますね。
島田：このシステムが抱えるトラブルを解決しなければ事業が止まってしまいます。システム再編に巻き込まれたアーキテクト達は、どう立ち向かっていくのでしょうか。
島田：前著『ソフトウェアアーキテクチャの基礎』で盛り込めなかった2つのトピックスに対して、Sysops Squad サーガ は、下記のように具体的に問います。
島田：物語は全15章で構成されます。前半は「モノリシックなシステムをどう分解していくか」を解説し、後半は「分散システムで直面する難しい問題をどう決定していくか」を解説します。
島田：技術書と違い物語風の構成は翻訳に苦労しましたが、一読者として非常にわかりやすいと感じました。登場人物のディスカッションや彼らが使うスキル、テクニックが実際の現場をイメージしやすく『ソフトウェアアーキテクチャの基礎』実践編として役に立つ本になっています。
島田：物語前半の「アーキテクチャの分解」という章をピックアップし一部ご紹介します。
まずコンテキストパートでは、アディソンとオースティン（現場アーキテクト）、ローガン（ベテランアーキテクト） が登場します。巨大なモノリスの分解方法に悩む2人へローガンは「戦術的フォークとコンポーネントベース分解というのがあってだな……」と話しはじめます。
島田：戦術的フォークとコンポーネントベース分解どちらを選択すべきか問う2人にローガンの解説パートが入ります。戦術的フォークは僕も知らなかったアプローチで、切り出しが難しいモノリスの場合、一度モノリスをコピーし不要な部分を削っていく戦術です。コンポーネントベース分解は正攻法なアプローチです。
島田：アディソンとオースティンのトレードオフ分析を経てコンポーネントベース分解が採用されます。
ところで本書では、登場人物がアーキテクチャ上で決定を行うと、ADR（アーキテクチャデシジョンレコード）が記されます。ADRはアーキテクチャ界隈でも注目されているので「フォーマットはわかった、どう書くんだ」と悩む方に参考になると思います。また現在のアーキテクチャにおいては、コードと同じぐらいデータも重要であるということで、データの分解ステップについても解説しています。
島田：アーキテクチャ上の決定を要する問題は、単独では存在せず、双方に影響を与え合うような、絡み合ったものとして存在しています。絡み合った問題をそのまま分析することはできないので、問題を1つずつ解きほぐす作業が必要です。
島田：本書では絡み合う問題を綺麗に解きほぐし順番に並べ解説していますが、実際にはこれだけ入り組んだ難しい問題を複合的に解決しなければなりません。
この問題を解決するときは別の難しい問題をいくつか並べ、その影響を考慮する必要があります。
あるデータの書き込み権をどのサービスが持つのか（1つのサービス or 複数 or 全て）です。データとサービスの関係を考えていかないとサービスの適切なルールは見つけられません。
サービスを分ける際には、サービスが実現しているワークフローを分けた状態でも実現できるのかを考える必要があります。複数のサービスが連携してワークフローを実現する場合、ハッピーケースはともかくエラーケースはどうするのか考えます。
サービスが分かると通信も分かれます。よって、通信フォーマットについても考える必要が出てきます。
サービスを分けるなら共通的なコードの扱いについても考えなければなりません。（共有ライブラリ or 共有サービス or その他）モノリスなら選択肢もリスクも少ないのですが、分散システムの場合はトレードオフを考えて決定すべきです。
合わせて、所有していないデータにどうアクセスするかも考えなくてはいけません。
ワークフローはデータ整合性についても考慮すべきです。
島田：本日は前述した複合的な問題から「サービスの適切な粒度をどう見つけるか」について本書がどう解決しているかを紹介します。
島田：まずコンテキストパートでは、テイレン（現場アーキテクト）、ローガン（ベテランアーキテクト） が登場します。テイレンはドメインサービスの単位が大きすぎるので小さくすべきだと主張し、ローガンは全てをマイクロサービスにすれば良い訳ではないと返します。
島田：本書では「サービスの粒度は、粒度分解要因と粒度統合要因のバランスによって決定される」という興味深い解説が紹介されており、粒度分解要因、粒度統合要因それぞれの違いや観点を詳しく取り上げながら、サービスの粒度についてどのようなトレードオフがあるかを紹介していきます。
島田：サービスを分ける際に分解要因と統合要因をぶつけて考えるという話は他であまりなく、興味深い観点を学ぶことができます。
島田：「Sysops Squad サーガでは、最終的に「分解しすぎないようにしましょう」という結論となっており、こう言ったところも非常に現実的だなと感じました。
島田：このように本書は「Sysops Squad サーガ」の物語という具体的なコンテキストを通し、ソフトウェアアーキテクチャの2つのハードパーツに対して学べる書籍です。特定のアーキテクチャスタイルについてガッツリ語る本が多いなか、アーキテクチャ上の選択肢ごとのトレードオフを主題として書かれた書籍は珍しく大変読みごたえがありますので、ぜひ読んでみてください。
この分野は難しい分やりがいがあります。そして知見を得る何よりの近道はアーキテクティングしてみることです。実践を重ねてより良いアーキテクチャを目指していきましょう！
“偉大なデザイナーになるにはどうしたら良いか?
偉大なデザイナーはもちろんデザインするんだ” Fred Brooks
ここからは事例講演「ソフトウェアアーキテクチャ・ハードパーツ」の視点から見たオープンロジのアーキテクチャ改変事例 に登壇された大平 哲也 氏を加え視聴者からの疑問に答えます。
大平 哲也（株式会社オープンロジ SREチーム リーダー）
大手 BtoC企業各社で主にサーバーサイドのエンジニアとしてインフラ構築やサービスの開発、大規模リプレイス、チームのマネジメントなどを担当。2022年7月にオープンロジに入社。SREチームのリーダーを務める。さだまさしが好き。
;?>/images/ico/ico_blank.svg){kind=spacer}
— マーチン・ファウラー氏の「オブジェクトは分散させるな」という言葉にあるように、分散化は複雑性や通信コストが高くなるのでは、と続いていますね。
島田：まずサーバーやサービスを立ち上げるコストが低くなったことをきっかけに敷居が低くなったのではと考えます。分散化の大変さはご指摘のとおりでしょう。本来マイクロサービスアーキテクチャは、スケールした企業が規模に応じた問題解決のために採用するものです。するとビックプレイヤーは必然的にマイクロサービスに向かうわけですが、それを見て「マイクロサービスを取り入れないと、スケールできない」「今どきのテック企業であるならマイクロサービスを採用しなければならないのだ」と考えてしまい、マイクロサービスに進んでしまうということが一定数あるのだろうなと考えています。
大平：モノリシックなシステムはどうしてもデプロイパイプラインが詰まりがちで開発速度を上げづらいんですね。複雑性やコストは上がるかも知れないけど、そこを最適化させる意味で分散化させて便益を得る選択肢はあるのではないでしょうか。
— 「契約面を含め、SIのようなビジネスモデルのあり方を変えていくべきですか」とのことです。
島田：えにしテックの場合は、開発前に「システムは継続的に改善していくもの。従来のような開発・保守という形ではないですよ。」と説明しています。最近は自社でプロダクト開発される企業も増えているので、昔に比べるとすんなり聞いてもらえる時代になってきたなと感じますね。
島田：私が翻訳した『モノリスからマイクロサービスへ』では、マイクロサービス化をした方がいい理由、まだしなくていい理由、マイクロサービス化の代替案などを提供しながら「マイクロサービス化以外の方法で実現できるならマイクロサービス化しなくてもいい」と主張しているんです。あらゆる選択肢の先に「それでもマイクロサービス化しなければならない」に辿りついたときがベストなタイミングなのではないでしょうか。
— オープンロジさんではマイクロサービス化についてどう考えてますか？
大平：システムが複雑になるので、受け入れ体制（チーム体制の大幅な変更）が必要ですよね。組織が耐えられるかが導入の基準なのかもしれません。個人的には、マイクロサービスを手段にすることは、あまり意味がないと感じています。ビジネスを実現するために、どうしても必要であればやるべきかな。
— 「先人が残したプロダクトのランニングコストが高額で、ADRも残されていない」そうですが、いかがでしょう。
島田：もう少し背景がわかれば具体的なアドバイスができるのですが……参考になるかわかりませんが、金融業界の「バーベル戦略」を開発に応用してみるのは、いかがでしょう。
— ちなみにADRを残されている会社ってどれくらいあるのでしょう？
島田：最近は頑張って残す企業も多いのですが、ADRが適切にメンテナンスされているかは微妙なところです。むしろ適切にメンテナンスできるような企業であればADRでなくとも、何らかの形で意思決定の記録が残っているように思います。
代表取締役社長
『ソフトウェアアーキテクチャ・ハードパーツ』翻訳者 1978年神奈川県生まれ。電気通信大学電気通信学部情報工学科卒。2009年に株式会社えにしテック を設立。2011年からは一般社団法人日本Rubyの会理事も務める。 近著に『ユニコーン企業のひみつ』（オライリージャパン、共訳）、『モノリスからマイクロサービスへ』（オライリージャパン、翻訳）、『ソフトウェアアーキテクチャの基礎』（オライリージャパン、翻訳）など。
