本記事は
【Advent Calendar 2025】
15日目の記事です。
🌟🎄
14日目
▶▶ 本記事 ▶▶
16日目①
🎅🎁
はじめに
システムエンジニアの檀上です。 今年もアドベントカレンダーを書くことになりました。 丁度、少し前の2025/11/20, 21にベルサール羽田空港で開催されたアーキテクチャConference 2025に現地参加してきました。 参加して色々と考えたことがあるので、今回はこちらを整理していきます。
アーキテクチャConference とは
ファインディ株式会社さんが2024年から開催されているカンファレンスです。 アーキテクチャの思考法や手法などをテーマに、様々な登壇者のお話を聞けます。 2024年・2025年は参加費は無料で、現地参加とオンライン視聴が可能でした。（現地会場限定のセッションあり）
昨年はオンラインで参加したのですが、あまりにも自分の興味のある分野の話が多かったため、今年は現地参加に踏み切りました。
architecture-con.findy-tools.io
モノリスとマイクロサービス
昨今のアーキテクチャについて語るのに、避けて通れないテーマだと思います。 最近では「モノリスからマイクロサービスへ」といった文脈でよく見かけるため、モノリスは良くないものという印象を持たれている方もいるかもしれません。 しかし、今回のカンファレンス全体を通しての印象は、「モノリスが悪いわけではない、適切なアーキテクチャがあるだけ」という考え方でした。 絶対的に良いアーキテクチャが存在するわけではなく、すべては各要素のトレードオフで決まります。
まずは、各アーキテクチャについて、特徴を整理してみます。
なお、今回は私が勉強中のため簡略化のためアーキテクチャを3つだけ取り上げます。
モノリス
モノリシックなアプリケーションのことを一般に「モノリス」と呼びます。 モノリシックなアプリケーションは、ソフトウェアがすべて一つのプログラム群にまとまっています。 ある1機能のアップデートをリリースするとき、システム全体をビルド・デプロイ・リリースするというイメージです。
マイクロサービス
モノリスと対照的に、ソフトウェアがいくつかの独立したプログラム群に分割されたものです。 分割されることで、機能間の関連性が把握しやすくなると言われています。 機能それぞれでビルド・デプロイ・リリースを行い、機能間のやりとりはAPIなどを通して行うというイメージです。
モジュラーモノリス
ソフトウェアアーキテクチャの基礎*1で紹介されているアーキテクチャの一つです。 今回のカンファレンス全体を通して、このアーキテクチャを採用されている企業が多かったように感じました。 立ち位置としては、モノリスとマイクロサービスの中間地点にあると考えると良いと思います。
一つのアプリケーション内の機能がモジュールと言われる単位に分割されたものです。 モジュールをどの単位で分けるのか？については議論の余地があり、各々のアプリケーションで決める必要があります。 モジュールごとの通信はメソッド呼び出しで実施します。 開発はモジュールごとに行いますが、デプロイやリリースはモノリスと同様に一括で実施するというイメージです。
各アーキテクチャの整理
3つのアーキテクチャについて、いくつかの観点で整理してみます。 自分の経験からの考えを多分に含みますし、簡略化のためにニュアンスをかなり捨てて記載します。
チーム編成
- モノリス：大規模な1チームが必要になりそうです。適切に階層化できていれば、担当機能とその周辺のみに集中して開発が可能です。
- モジュラーモノリス：各モジュールにも精通し、アプリケーション全体も把握できる技術者が多数必要になりそうです。
- マイクロサービス：各サービスの担当者は、分割されたサービスの機能にのみ集中できます。各アプリケーションのチームは小規模で実施できます。ただし、全体を横断して把握する共通基盤チームなどが必要になると言われています。
CI/CD
- モノリス：シンプルな単一のパイプラインで完結します。変更の影響範囲が広いので、テスト時間やデプロイにかかる時間が長くなりがちです。1日に何度もリリースするといったマイクロリリースは難しい傾向にあります。
- モジュラーモノリス：モジュール単位でパイプラインを並列化できます。モジュール境界を適切に守れば、変更の影響範囲を局所化できます。デプロイは一括で実施するため、時間はモノリスと同じくらいかかるかもしれません。
- マイクロサービス：サービスごとに独立したパイプラインが必要です。変更の影響範囲が限定されるので、個別にビルド・テスト・デプロイが可能です。マイクロリリースのハードルも低いです。
インフラコスト
- モノリス：テスト・デプロイ・監視などの運用は一つの大きなものを用意するだけで済みます。
- モジュラーモノリス：モノリスと同じく単一デプロイで済みます。モジュール境界の違反が大きな問題になるため、それを守るための静的解析ツールなどの導入が必要になります。
- モジュール境界の違反について：マイクロサービスはAPIで別機能を呼び出しますが、モジュラーモノリスは一般に関数呼び出しで別機能を呼び出します。このため、ルールを無視した呼び出しが簡単に実装できてしまいます。違反が横行すると、せっかくのモジュール分割による疎結合が台無しになってしまいます。
- マイクロサービス：各サービスごとに個別のインフラコストがかかります。監視基盤についても、各サービスごとに導入するにしても全体に導入するにしても、最適化が必要になるため大変です。
「適切なアーキテクチャ」とは？
ここまで整理してわかるように、それぞれのアーキテクチャは完璧な解法ではありません。 それぞれにメリット・デメリットがあり、あなたが携わっているアプリケーションの特徴によって適切なアーキテクチャは変わります。
アーキテクチャConference2025の1日目の午後のキーノート「アーキテクト思考ーチームでより良い技術的意思決定を導くリーダーシップ」では、次のようなお話がありました。
- 世間で成功例を発表している大企業と、あなたが開発しているシステムで採用すべきアーキテクチャは異なる。あなたが開発しているのはMetaやGoogleではない。
- 地図について考える
- 鳥瞰図・衛星写真・路線図・地質図などたくさんの種類がある
- 目的によって適切な表現方法が異なるように、システムによって適切なアーキテクチャは異なる
適切なアーキテクチャを決定するには、自分の開発するアプリケーションがどのような特徴を持つのかを把握しておく必要があります。 その時に必要になるのは、新しいアーキテクチャを採用するための技術の知識だけではなく、アプリケーションで解決したい課題は何か、対面のお客様はどのような方がいるか、アプリケーションが必要とされる業界はどんな速度で要件が変化していくかなどの、ドメイン知識、言い換えると業務知識だという指摘が多くありました。
おわりに
今回のカンファレンスで自分が一番感銘を受けたのは、1日目の午後のキーノートの「次元の知識があれば、ニュアンスのある決定ができる」という言葉でした。 アプリケーションに関わる業務知識、各アプリケーションの特徴、各技術の特徴など、一歩引いてメタ認知できれば、「この部分はモノリスっぽくして、この部分はマイクロサービスに寄せた作りにしよう」という一辺倒ではない選択ができるようになります。
いままで自分は、エンジニアとして価値を発揮するには、新しい技術やアーキテクチャをすべて把握することが非常に大事だと考えていました。 しかし、自分がいままで向き合ってきた、顧客の業界の業務知識や成長戦略などが、アーキテクチャを選択していくうえでむしろ重要であるということに気付かされました。
新しい情報のキャッチアップももちろん大切ですが、目の前の業務に向き合って、メタ認知するという視点も必要です。これからもいろんな知識を得て、いろんな人と話して、複数の視点を持ってアプリケーション開発に向き合って行こうと思います。
システムエンジニア。人の話を聞くことが好きです。
