企業情報化の集中構築は分散ユニットアーキテクチャに戻るべきである

この記事はWeChatの公開アカウント「Ren Yue Liao IT」から転載したもので、著者は何明禄です。この記事を転載する場合は、Renyue Liao IT パブリックアカウントにご連絡ください。

私は2009年より通信事業者の集中型ERP構築に携わってきました。

簡単に言えば、各省や子会社にもともと存在していたITシステムをすべて廃止し、新たに構築した集中型システムを使用して、グループのすべての省会社と専門会社のニーズに対応しました。

このような建設の利点は現在明らかであり、建設コスト、運用および保守コスト、ビジネス、特に財務管理および制御能力のすべての側面が大幅に強化されています。集中化は強化を意味し、コストを削減するだけでなく、さらに重要なことに、グループ全体の管理および制御能力が大幅に向上します。

2009 年の大規模な集中型構築は、基本的に従来の単一アプリケーション アーキテクチャと IOE モデルに基づいていました。

つまり、EMC 集中ストレージ、Oracle データベース、ミニコンピュータを使用して、IT インフラストラクチャ アーキテクチャの構築が完了します。これらの IT ハードウェア デバイスは高価ですが、最大の利点は高可用性と高信頼性であり、IT インフラストラクチャ層の十分な安定性を保証します。

しかし、集中型システムでは依然としてスケーラビリティの問題が残ります。

つまり、5年から10年という長期的な視点で見ると、従来のITインフラのアーキテクチャをスムーズに拡張・サポートできるかどうかが重要な課題となります。特に、以前の記事でよく取り上げた DB データベース機能です。 DB データベース クラスターが完全な水平方向の弾力的な拡張を実現することは非常に困難です。 Oracle RAC クラスタ自体にもパフォーマンスの制限があります。一般的には、単一ポイントの容量の 2 ～ 3 倍まで拡張するのが限界です。

そこで、2012年にプライベートクラウドPaaSプラットフォームの構築を開始し、プラットフォーム+アプリケーション構築モデルを提案し、インターネットの実践を参考にしてIOEを脱却し、オープンソースソフトウェアとX86サーバーを代替手段として活用しました。

これは現在のグループの情報構築においてかなり進んだものです。

これは、脱 IOE やオープンソース ソフトウェア アプリケーションに関することだけではなく、より重要なのは、現在のマイクロサービスと同じ、コンポーネント ベースの分解に関することです。コンポーネント分割の最も重要な部分はデータベースの分割です。モノリシック アプリケーションは、まずコンポーネント モジュールに分割され、次に複数のデータベースに分割されました。同時に、すべての州と組織のニーズを満たすために、データベースは水平に分割され、シャーディングされました。

ご覧のとおり、次のような複雑さが導入されています。

• オープンソースと脱IOE、IaaSからPaaSへの移行
• マイクロサービス分割後の水平統合
• メッセージング、キャッシュ、その他の技術サービスの垂直統合
• DaaS レイヤーでの分散トランザクションを含むデータベース分割

非常に複雑な要素が導入されているため、うまく実行するのは比較的困難です。そのため、プライベートクラウド PaaS プラットフォーム全体の構築と推進は、実際にはあまり成功しませんでした。これは技術的な問題だけではなく、ビジネス、組織管理、メーカー間の連携といった問題も絡んでおり、解決が必要です。

これは、適切なテクノロジーを適切なタイミングで使用することの真実を改めて証明するものでもあります。

さて、今日の質問はこれです。

集中型構築モードでも、高可用性とスケーラビリティに対応するために、モノリシック アプリケーションはマイクロサービスに分割され、データベースは水平方向と垂直方向に分割されて、パフォーマンスとスケーラビリティの要件を満たします。しかし、マイクロサービスとデータベースの分離により、統合コラボレーションや分散トランザクション処理の面で多くの問題が発生します。この問題を解決するより良いアイデアはありますか?

グループの多組織構造

グループには多くの子会社が存在する場合があり、集中型構築の考え方は、管理と制御を容易にするために、それらすべてに 1 つのシステムを使用することです。システムは標準的なビジネス プロセスとルールのセットを表すものであり、この考え方自体には何ら問題はありません。

しかし、以前のシステムでは、すべてのデータが 1 つのデータベースに存在する必要があるのでしょうか?

答えは明らかにノーです。

従来の多組織構造においても、包括的な予算管理、予算発行、財務管理、統一された財務諸表など、グループと子会社の間で相互作用があることがわかります。重要なのは、組織横断的なプロジェクトの承認と確認です。

しかし、実際にはグループと子会社の間にはシナジー効果があまりなく、ほとんどの業務は子会社内で完結できる場合が多いことがわかります。言い換えれば、グループとその子会社の関係は緩やかに結びついていると言えます。

この場合、日常の業務運営では大規模なデータの集中化は必要ありません。データの集中化は、その後のデータ操作とデータ分析を目的としており、同様のビッグデータ プラットフォームとデータ ミドル プラットフォームを構築することで解決できます。

複数のシステムを集中管理できますか?

例えば、当グループはSCMサプライチェーンシステムを構築しています。

従来の集中型アプローチでは、システムを構築してからそれをマイクロサービスに分割し、展開、管理、運用を統合します。しかし、中央集権化自体も新たな問題をもたらします。

• 一つは、後から拡張について議論するのは非常に面倒であったり、弾性拡張を実現することが不可能であったりすることです。
• 第二に、システムがダウンしたり故障したりすると、多くの場合、すべての組織の業務運営に影響が及びます。

では、各ビジネス システムを完全に垂直的に独立して展開および管理しながら、すべての組織で 1 つのシステムを使用することは可能でしょうか?アプリケーション、ミドルウェアから上位の業務システムまで、分散単位のモジュールを構成します。

つまり20の組織です。

次に、各組織が独立したシステムを使用する、SCM システムの独立した展開を 20 個開発しました。もちろん、小規模な組織であれば、複数の組織が独立したシステムを利用することも可能。

組織とシステムの間に、疎結合された構成可能な関係が形成されます。

導入された 20 のシステムには、統一されたリリースと配信、およびその後の統一された監視と運用と保守が必要です。従来のモードではこれを実行するのは難しいでしょう。

ただし、現在のクラウドネイティブ アーキテクチャでは、DevOps に基づく継続的インテグレーションと継続的デリバリーの機能を完全に実現できます。つまり、業務システムは 20 個ありますが、全体を管理・制御するシステムは 1 つだけなので、集中管理・制御が可能です。

このモードでは、解決する必要がある唯一の問題は次のとおりです。

グループとその子会社間の共同作業に関連する機能を分離し、この少量の統合と配信を処理する独立した集中型システムを構築します。それでも、この集中型システム自体はそれほど多くのビジネス データを生成するのではなく、基盤となるビジネス システムの既存の API サービス機能の組み合わせ、アセンブリ、オーケストレーションに基づいていることがわかります。

ビジネス システムはサブ組織に分割されており、複雑な DaaS データ レイヤーや分散トランザクションの問題を考慮する必要はありません。同時に、さまざまなサブ組織間の相互影響も構築します。

サブ組織ごとに分割できるが、マイクロサービスごとに分割することはできない

マイクロサービスに戻りましょう。

モノリシック アプリケーションからマイクロサービスまで、重要なポイントは、従来のモノリシック アプリケーションのスケーラビリティの問題と、その後のビジネス システムへの変更の影響を解決することです。同時に、アジャイル開発やチーム管理のアイデアを推進するのにも便利です。

しかし、マイクロサービスによってもたらされる大きな問題は、統合とコラボレーション、分散トランザクションなどの難しさです。

例えば、前述のように、集中化構築後は業務システム全体の同時実行性やデータ量が飛躍的に増加しました。この時点で、スケーラビリティとパフォーマンスの問題を解決するために、大きなモノマーを分割する必要があります。

ただし、集中型の構築は、ビジネス標準プロセス + IT 管理および制御の集中化になります。

導入できる業務システムは 1 つだけというわけではありません。

組織に応じて複数のシステムを導入し、一元的に管理できます。サブ組織ごとに分割すると、当然ながら、単一のビジネス システムに特有の同時実行性やパフォーマンスの問題は発生しません。

組織ごとに分割することでパフォーマンスの問題を解決した後、なぜマイクロサービスを分割し続ける必要があるのでしょうか?

実際、システムを組織ごとに分割し、各組織にシステムを割り当てて、システムを統一的に管理するのが最善のアプローチであることもわかります。このコスト投資は、分割マイクロサービス アプローチよりもはるかに少なくなります。

統合管理 - DevOps とコンテナ クラウド

従来のモデルでは、20 個の同一システムを導入して管理するのは比較的困難です。

しかし、コンテナクラウドとDevOpsの急速な発展により、継続的インテグレーションと継続的デリバリーの能力が獲得され、コンテナクラウドを通じてリソースの急速な拡張を実現できるようになりました。

たとえば、20 個のコンピューティング ノード リソースを予約し、20 個の業務システムを統合的に監視できます。明らかなパフォーマンスの問題が見つかった場合は、アプリケーション グループのリソースを動的に拡張できます。これらの操作は、k8s による動的なスケジューリングとリソース割り当てによって迅速に完了できます。

クラウド ネイティブの不変のインフラストラクチャにより、複数のシステムが同じデプロイメント バージョンとイメージを使用し、ビジネス システム自体のバージョンの統一性を確保することもより便利になります。

もちろん、この分散ユニット アーキテクチャに基づいて、システム グループ間の相互冗長性とホット スタンバイ機能も実現できます。たとえば、組織 A に対応するシステム A のデータは、非同期かつタイムリーにシステム B に同期できます。その後、システム A でシステム障害が発生した場合、トラフィック切り替えによって組織 A のすべてのアクセスをシステム B にすばやく切り替えることができ、システム A の高可用性を確保できます。