Forkwell Press

SHARE

目次

目次

SHARE

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

── 「つぎの一歩が見つかる、気づきと学びの場」 Forkwell Library シリーズ 第12回は、2022年10月27日に発売されたばかりの『ソフトウェアアーキテクチャ・ハードパーツ』を取り上げます。

こんな方におすすめ

  • アーキテクチャ選択のトレードオフに苦しんでいる
  • 現代的なトレードオフ分析を学びたい
  • ソフトウェアアーキテクチャに関わるソフトウェア開発者

島田 浩二

株式会社えにしテック 代表取締役社長

『ソフトウェアアーキテクチャ・ハードパーツ』翻訳者 1978年神奈川県生まれ。電気通信大学電気通信学部情報工学科卒。2009年に株式会社えにしテック を設立。2011年からは一般社団法人日本Rubyの会理事も務める。 近著に『ユニコーン企業のひみつ』(オライリージャパン、共訳)、『モノリスからマイクロサービスへ』(オライリージャパン、翻訳)、『ソフトウェアアーキテクチャの基礎』(オライリージャパン、翻訳)など。

『ソフトウェアアーキテクチャ・ハードパーツ』は、こんな本

正解を与えるのではなく、最適解への道しるべ

島田:現代のソフトウェアアーキテクチャ(主にマイクロサービスアーキテクチャ)で直面するベストプラクティスが存在しない難しい問題への取り組み方を解説しています。正解ではなく読者の状況に合わせ選択するための材料を与える本です。2022年03月出版『ソフトウェアアーキテクチャの基礎』に記される「ソフトウェアアーキテクチャの基本的な考え方」が前提ではありますが、未読でも問題ないよう配慮された構成になっているのでご安心ください。

「ソフトウェアアーキテクチャ・ハードパーツ」の意味

島田:タイトルの「ハードパーツ」は、2つの意味が込められています。

① ソフトウェアアーキテクチャそのものがハード

ソフトウェアの中でも、後から変更するのが難しい堅い部分(ハード)があるという意味 

② ソフトウェアアーキテクチャ上の決定がハード

ソフトウェアアーキテクチャで扱う問題は、決めるのが難しいハードな問題であるという意味

ソフトウェアアーキテクチャの基礎に盛り込めなかった内容をもとに執筆

島田:本書は2022年03月出版『ソフトウェアアーキテクチャの基礎』で盛り込むことができなかった2つのトピックスを分かりやすく解説しています。

盛り込むことができなかったトピックス

① ソフトウェアアーキテクチャそのものがハード

 → どう変えていくか?

② ソフトウェアアーキテクチャ上の決定がハード

 → どう答えていくか? 

盛り込めなかった理由

アーキテクチャの問題に対して「どうやって」を一般論的に答えるのは、とても難しい

“アーキテクチャではすべてがトレードオフだ。だからこそアーキテクチャのあらゆる問いに共通する答えは「場合による」のだ(中略)RESTとメッセージングはどちらが良いか。マイクロサービスは正しいアーキテクチャスタイルなのか。こういった問いに対する答えをGoogleで見つけることはできない。それは場合によるからだ。答えはデプロイ環境やビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、その他多くの要因に依存する。環境や状況、問題点はそれぞれに異なるものだ。だからこそアーキテクチャは難しい。”  ソフトウェアアーキテクチャの第一法則より 

本書はこれを分かりやすく伝えるため、1つの具体的なコンテキストに沿ってアーキテクチャの議論を進める作りになっています。

具体的なコンテキストは、物語形式でわかりやすく

島田:具体的なコンテキストには「Sysops Squad サーガ」を用いています(サーガとは長編の英雄物語 のこと)。あらゆる技術書が事例をもとに解説しているように、本書は物語形式で事例を紹介しています。これによりアーキテクチャを考えるための設定・状況・環境をイメージしやすくなっています。

「Sysops Squad サーガ」の物語

島田:よくある話ではありますが、問題を多く抱えたレガシーで大規模なモノリシックシステムの問題を(分散システムにすることで)どう解決していくかというストーリーです。

「Sysops Squad」は、電機メーカーのテクニカルサポートの名称です。顧客はサポートを受けるためにシステムにチケットを登録し、サポートが完了するとチケットが消化される仕組みです。ユーザ管理をするシステム管理者や、レポート作成をするマネージャーなどもいますね。

システム再編に巻き込まれたアーキテクト達の戦い

島田:このシステムが抱えるトラブルを解決しなければ事業が止まってしまいます。システム再編に巻き込まれたアーキテクト達は、どう立ち向かっていくのでしょうか。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

島田:前著『ソフトウェアアーキテクチャの基礎』で盛り込めなかった2つのトピックスに対して、Sysops Squad サーガ は、下記のように具体的に問います。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

島田:物語は全15章で構成されます。前半は「モノリシックなシステムをどう分解していくか」を解説し、後半は「分散システムで直面する難しい問題をどう決定していくか」を解説します。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

登場人物のディスカッションが、現場をイメージしやすい

島田:技術書と違い物語風の構成は翻訳に苦労しましたが、一読者として非常にわかりやすいと感じました。登場人物のディスカッションや彼らが使うスキル、テクニックが実際の現場をイメージしやすく『ソフトウェアアーキテクチャの基礎』実践編として役に立つ本になっています。

モノリシックなシステムをどう分解していくか

悩む若手2人にベテランがアドバイス

島田:物語前半の「アーキテクチャの分解」という章をピックアップし一部ご紹介します。

まずコンテキストパートでは、アディソンとオースティン(現場アーキテクト)、ローガン(ベテランアーキテクト) が登場します。巨大なモノリスの分解方法に悩む2人へローガンは「戦術的フォークとコンポーネントベース分解というのがあってだな……」と話しはじめます。 

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

戦術的フォーク vs. コンポーネントベース分解

島田:戦術的フォークとコンポーネントベース分解どちらを選択すべきか問う2人にローガンの解説パートが入ります。戦術的フォークは僕も知らなかったアプローチで、切り出しが難しいモノリスの場合、一度モノリスをコピーし不要な部分を削っていく戦術です。コンポーネントベース分解は正攻法なアプローチです。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

アーキテクチャ界隈でも注目のADRで導く解決策

島田:アディソンとオースティンのトレードオフ分析を経てコンポーネントベース分解が採用されます。

ところで本書では、登場人物がアーキテクチャ上で決定を行うと、ADR(アーキテクチャデシジョンレコード)が記されます。ADRはアーキテクチャ界隈でも注目されているので「フォーマットはわかった、どう書くんだ」と悩む方に参考になると思います。また現在のアーキテクチャにおいては、コードと同じぐらいデータも重要であるということで、データの分解ステップについても解説しています。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

分散システムで直面する難しい問題とどう決定していくか

分散システムで直面する難題を決定していく際の難しさ

島田:アーキテクチャ上の決定を要する問題は、単独では存在せず、双方に影響を与え合うような、絡み合ったものとして存在しています。絡み合った問題をそのまま分析することはできないので、問題を1つずつ解きほぐす作業が必要です。

分散システム上で直面する問題がどれだけ絡み合っているか

島田:本書では絡み合う問題を綺麗に解きほぐし順番に並べ解説していますが、実際にはこれだけ入り組んだ難しい問題を複合的に解決しなければなりません。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

サービスの適切な粒度をどう見つけるか

この問題を解決するときは別の難しい問題をいくつか並べ、その影響を考慮する必要があります。

データ所有権をどう割り当てるか

あるデータの書き込み権をどのサービスが持つのか(1つのサービス or 複数 or 全て)です。データとサービスの関係を考えていかないとサービスの適切なルールは見つけられません。

ワークフローをどう実現するか

サービスを分ける際には、サービスが実現しているワークフローを分けた状態でも実現できるのかを考える必要があります。複数のサービスが連携してワークフローを実現する場合、ハッピーケースはともかくエラーケースはどうするのか考えます。

サービス間通信の方式をどうするか

サービスが分かると通信も分かれます。よって、通信フォーマットについても考える必要が出てきます。

共通的なコードをどう扱うか

サービスを分けるなら共通的なコードの扱いについても考えなければなりません。(共有ライブラリ or 共有サービス or その他)モノリスなら選択肢もリスクも少ないのですが、分散システムの場合はトレードオフを考えて決定すべきです。

所有していないデータにどうアクセスするか

合わせて、所有していないデータにどうアクセスするかも考えなくてはいけません。

データ整合性をどう確保するか

ワークフローはデータ整合性についても考慮すべきです。 

サービスの適切な粒度をどう見つけるか

島田:本日は前述した複合的な問題から「サービスの適切な粒度をどう見つけるか」について本書がどう解決しているかを紹介します。

粒度分解要因 vs. 粒度統合要因

島田:まずコンテキストパートでは、テイレン(現場アーキテクト)、ローガン(ベテランアーキテクト) が登場します。テイレンはドメインサービスの単位が大きすぎるので小さくすべきだと主張し、ローガンは全てをマイクロサービスにすれば良い訳ではないと返します。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

島田:本書では「サービスの粒度は、粒度分解要因と粒度統合要因のバランスによって決定される」という興味深い解説が紹介されており、粒度分解要因、粒度統合要因それぞれの違いや観点を詳しく取り上げながら、サービスの粒度についてどのようなトレードオフがあるかを紹介していきます。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

島田:サービスを分ける際に分解要因と統合要因をぶつけて考えるという話は他であまりなく、興味深い観点を学ぶことができます。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

「分解しすぎないようにしよう」が現実的

島田:「Sysops Squad サーガでは、最終的に「分解しすぎないようにしましょう」という結論となっており、こう言ったところも非常に現実的だなと感じました。

「ソフトウェアアーキテクチャ・ハードパーツ」島田 浩二

実践を重ねてより良いアーキテクチャを目指そう!

島田:このように本書は「Sysops Squad サーガ」の物語という具体的なコンテキストを通し、ソフトウェアアーキテクチャの2つのハードパーツに対して学べる書籍です。特定のアーキテクチャスタイルについてガッツリ語る本が多いなか、アーキテクチャ上の選択肢ごとのトレードオフを主題として書かれた書籍は珍しく大変読みごたえがありますので、ぜひ読んでみてください。

この分野は難しい分やりがいがあります。そして知見を得る何よりの近道はアーキテクティングしてみることです。実践を重ねてより良いアーキテクチャを目指していきましょう!

“偉大なデザイナーになるにはどうしたら良いか?

偉大なデザイナーはもちろんデザインするんだ” Fred Brooks

ここからは事例講演「ソフトウェアアーキテクチャ・ハードパーツ」の視点から見たオープンロジのアーキテクチャ改変事例 に登壇された大平 哲也 氏を加え視聴者からの疑問に答えます。

大平 哲也

株式会社オープンロジ SREチーム リーダー

大手 BtoC企業各社で主にサーバーサイドのエンジニアとしてインフラ構築やサービスの開発、大規模リプレイス、チームのマネジメントなどを担当。2022年7月にオープンロジに入社。SREチームのリーダーを務める。さだまさしが好き。

Q:分散化の敷居が低くなった要因は?

— マーチン・ファウラー氏の「オブジェクトは分散させるな」という言葉にあるように、分散化は複雑性や通信コストが高くなるのでは、と続いていますね。

島田:まずサーバーやサービスを立ち上げるコストが低くなったことをきっかけに敷居が低くなったのではと考えます。分散化の大変さはご指摘のとおりでしょう。本来マイクロサービスアーキテクチャは、スケールした企業が規模に応じた問題解決のために採用するものです。するとビックプレイヤーは必然的にマイクロサービスに向かうわけですが、それを見て「マイクロサービスを取り入れないと、スケールできない」「今どきのテック企業であるならマイクロサービスを採用しなければならないのだ」と考えてしまい、マイクロサービスに進んでしまうということが一定数あるのだろうなと考えています。

大平:モノリシックなシステムはどうしてもデプロイパイプラインが詰まりがちで開発速度を上げづらいんですね。複雑性やコストは上がるかも知れないけど、そこを最適化させる意味で分散化させて便益を得る選択肢はあるのではないでしょうか。

Q:継続的なアーキテクチャ改善とSIビジネスの相性は悪いのでは?

— 「契約面を含め、SIのようなビジネスモデルのあり方を変えていくべきですか」とのことです。

島田:えにしテックの場合は、開発前に「システムは継続的に改善していくもの。従来のような開発・保守という形ではないですよ。」と説明しています。最近は自社でプロダクト開発される企業も増えているので、昔に比べるとすんなり聞いてもらえる時代になってきたなと感じますね。

Q:マイクロサービス化のベストなタイミングは?

島田:私が翻訳した『モノリスからマイクロサービスへ』では、マイクロサービス化をした方がいい理由、まだしなくていい理由、マイクロサービス化の代替案などを提供しながら「マイクロサービス化以外の方法で実現できるならマイクロサービス化しなくてもいい」と主張しているんです。あらゆる選択肢の先に「それでもマイクロサービス化しなければならない」に辿りついたときがベストなタイミングなのではないでしょうか。

— オープンロジさんではマイクロサービス化についてどう考えてますか?

大平:システムが複雑になるので、受け入れ体制(チーム体制の大幅な変更)が必要ですよね。組織が耐えられるかが導入の基準なのかもしれません。個人的には、マイクロサービスを手段にすることは、あまり意味がないと感じています。ビジネスを実現するために、どうしても必要であればやるべきかな。

Q:アーキテクチャの見直しは、どのハードパーツから着手すべき

— 「先人が残したプロダクトのランニングコストが高額で、ADRも残されていない」そうですが、いかがでしょう。

島田:もう少し背景がわかれば具体的なアドバイスができるのですが……参考になるかわかりませんが、金融業界の「バーベル戦略」を開発に応用してみるのは、いかがでしょう。

  • 長期的な効果を生むものはやる
  • 中途半端なことはやらない
  • 短期的な効果をすぐに生むものはやる

— ちなみにADRを残されている会社ってどれくらいあるのでしょう?

島田:最近は頑張って残す企業も多いのですが、ADRが適切にメンテナンスされているかは微妙なところです。むしろ適切にメンテナンスできるような企業であればADRでなくとも、何らかの形で意思決定の記録が残っているように思います。

イベント動画の視聴はこちら

Forkwellで次のキャリアを描いてみませんか

Forkwellは、あなたに魅力を感じた企業から直接スカウトが届くサービスです。
プロフィール機能やポートフォリオの自動生成によりスキルの可視化も可能です。
気になる企業との面談は「オンライン面談してみる」「ご飯でも食べながら」「コードを見に行ってみる」など温度感を選べます。
スキルの棚卸しをしていろんな企業の話を聞き、あなたが本当に実現したいキャリアについて考えてみませんか? Forkwellで次のキャリアを実現する(3分で登録)
ForlkwellPress ロゴ画像

編集部

Follow

エンジニアに役立つ情報を定期的にお届けします。

エンジニアに役立つ情報を定期的にお届けします。