クラウドファーストな時代のアーキテクチャとは？

アーキテクチャとは

アーキテクチャという言葉はよく耳にすると思いますが、アーキテクチャって何？と言われると答えに窮するのではないでしょうか。アーキテクチャ検討の成果物としては「システム構成図」をイメージする方も多いかもしれませんが、プロジェクトによってレベル感は様々で何を表現するかはケースバイケースです。実は「ITシステムにおけるアーキテクチャの定義」というのは明確ではありません。アーキテクチャとは定義するものではなく、システム設計においてまず考えるべき重要なことであり、その範囲はどこからどこまでというのではなく、時代・技術の進化により変わっていくものだからです。

アーキテクチャをとりまく環境の変化

以前からアーキテクチャはコンピュータシステムの重要な要素であったのですが、クラウドと分散システムの発展によりさらに重要性が増しています。また昨今ではシステムの技術的な側面だけではなく、組織・文化までを含む大きなテーマとなってきています。その背景として、

① システムを実現する選択肢が増えた
② アプリケーションの構造が複雑になった
③ データの場所が分散し、さらに連携が必要となった
④ 組織構造とアーキテクチャの関連が意識されるようになった

が挙げられます。これら4点について以下で説明します。

① システムを実現する選択肢が増えた

以前のシステムはある決まったパターンにあてはめることができました。しかし今はクラウド・オンプレミスの選択があり、さらにはハイブリッドクラウドやマルチクラウドがあります。実装形態においてもベアメタルではなくVM・コンテナ・サーバレス・SaaSのような多様な選択肢があります。このように選択肢が増えたことで、アーキテクチャ検討が重要となってきています。ですが、ただ闇雲に選択肢を挙げて比較検討するのでは時間がかかるだけであるため、目的を踏まえてどこかに軸を決めることが大事です。例えばパブリッククラウドの先行技術を積極活用するであったり、Kubernetesのようなクラウドネイティブなプラットフォームへのシフトであったり、AIのような個別ソリューションの活用を重視する、などいろいろなバリエーションがありえます。重要なのはシステムが実現したいこと、将来的な拡張を踏まえてどこに軸を置くのかを定めることです。

② アプリケーションの構造が複雑になった

以前のアプリケーションはいわゆるモノリスが主流でした。モノリスとは、アプリケーションが単一のインスタンスで実行されており、ソフトウェアが書いた通りに直感的に動くシンプルな構造です。だたし規模が大きくなると、変更や追加による影響範囲が見通せなくなり効率が悪くなるという欠点がありました。そこで、クラウドサービスの開発企業を中心にアプリをドメイン単位で分割して疎結合とするマイクロサービスの考え方が出てきました。マイクロサービスは技術的には分散システムと非同期メッセージをベースとしており、影響範囲を限定しやすいというメリットがあるため、細かくリリースしていくアジャイルの考え方に適しています。ただし分散システムであるため、特にトランザクションの扱いにおいてモノリスとは違う観点が必要となり、アプリケーションの構造はより複雑になります。ここでも重要なのは、将来まで見越すことです。今実現したいことだけを考えれば、たいていの場合モノリスのほうが効率的です。ですが将来的な拡張や機能の追加変更がありえるのであれば、マイクロサービスにすることで将来的に差が出てきます。

③ データの場所が分散し、さらに連携が必要となった

従来、データはシンプルにアプリケーションが内部で保持もしくは、共有ストレージやデータベースで管理されていました。しかしあらゆるタスクがシステム化されていくにつれて、アプリケーションが必要とするデータが他のシステムで分散して保持されるケースが増えてきています。またSaaSが導入されることで、データがSaaS間で分散するようにもなりました。このような状態で統合的にデータを管理するためには、データの場所だけではなく同期レベル、可用性、セマンティクスなどのさまざまな要素を含めたデータアーキテクチャが重要となります。データは企業にとってまさに大事な資産であり、守るだけではなく活用していくことが大事となります。特に今後はAI活用のため、データの品質を上げて意味を持つものにしていく必要があります。そのためには分散したデータの扱いがとても重要となります。

④ 組織構造とアーキテクチャの関連が意識されるようになった

コンウェイの法則というのをご存じでしょうか。組織の構造がシステムの構造に影響を与えるという経験則です。逆コンウェイの法則というのも知られています。コンウェイの法則を逆手にとり、実現したいシステムの構造に組織構造を合わせていこうという法則であり戦略です。組織構造とアーキテクチャが関連するということは、システムのことだけではなく、組織・文化をも考慮してアーキテクチャを検討する必要があるということを意味しています。大企業では組織がサイロ化し、その写像としてシステムもサイロ化しているため、横断的なビジネスの創出を阻害しているようなケースも見られます。これがまさにコンウェイの法則です。今やすべてのビジネスはITなくして成立しなくなっています。IT部門・ベンダーに任せているだけではなく、企業全体としてITへの取り組みを考えた組織構造にすることが重要です。

なぜアーキテクチャが重要なのか

アーキテクチャを考えずに場当たり的にシステムを作っていくと、メンテナンス性が悪化するという状況を招きかねません。例えば同じデータを扱う機能が複数のシステムに分散している環境で、新機能実現のためにデータ構造の変更やデータの拡張をしたくなったとしましょう。そのデータを利用している複数のシステムへの影響がありえるため、実装やテストに時間とコストがかかってしまいます。データとそのデータを扱う機能をセットにしたサービスを作っておけば、もしくはデータ構造を横断的に管理する機能を持っておけば、影響範囲が限定されるため、新機能はよりスムーズに実現できます。システムは一度作ったら終わりではありません。システムは作った瞬間から技術的負債（Technical Debt）になります。負債は放っておけば膨らんでいき、いつか返さなくてはならなくなったときに膨大な時間とコストがかかります。よいアーキテクチャはシステムのアップデートを容易にします。技術的負債のメタファーで言えば、よいアーキテクチャは負債をためこまず、こまめに返済していくことができます。それにより攻めの投資ができ、ビジネスのスピードを高め、価値の創出につながるのです。

また同じアーキテクチャという言葉を使っている概念として、EA（Enterprise Architecture）があります。前述の①～④はちょうどEAの4階層にマッピングできます。EAの従来のアプローチとは、ビジネスアーキテクチャが最上位にあり、下の階層に向けて落としていく考え方です。業務から要件を出してITシステムに落としていくという手法です。それに対して昨今のアーキテクチャの観点ではTA/AA/DAが起点となってBAに影響していく、テクノロジードリブンな方向が重要になると捉えられています。だたしこれはどちらが優位ということではなく、ビジネスの構造からITシステムへ落とす方向と、ITシステムやテクノロジーの進化をビジネスに反映させていく方向という両方向を意識してアーキテクチャを考えることが重要になります。そしてこれらの要素は個別ばらばらにあるのではなく繋がっています。その大元にあるのがクラウドの普及であり、分散システム技術です。よって、これらを個別ではなく全体として考えることでクラウドの利点・恩恵を受けられるようになります。

やや抽象的な内容が多くなってしまいましたが、今後の記事ではアーキテクチャについてより具体的な部分にも触れていきたいと思います。

執筆者

鳥居 隆史
デロイト トーマツ コンサルティング合同会社　シニアスペシャリストリード

執筆コンテンツ

• TMT Predictions 2024　日本の視点：ユーザーの主体的な取り組みがクラウド主権実現の鍵
• TMT Predictions 2023　日本の視点：エンタープライズエッジの今後の市場
• Tech Trends 2022 (4) IT部門の再構築：加速する自動化