Aliyun Liu Weiguang: 財務レベルのクラウドネイティブを解釈するための 20,000 語

著者: Liu Weiguang、Alibaba Cloud Intelligent New Finance & Internet Industry 社長、China Finance Forty Forum 事務局長、清華大学電子工学部卒業

01 序文

2015年にクラウドネイティブの概念が提案されたとき、当時の100年にわたるグローバル金融の発展によって形成された情報化とデジタル化の背景では、金融レベルの技術サービスレベルが長い時間をかけて磨き上げられ、業界のコンセンサス標準を形成しました。。8 年前のクラウドネイティブの古典的な概念は、コンテナ化、DevOps、継続的開発と継続的統合、マイクロサービスアーキテクチャに焦点を当てたソフトウェア開発の新しいパラダイムです。高可用性、高性能、ビジネス継続性、システムのセキュリティと安定性などの財務レベルの要件は、クラウドネイティブアーキテクチャの概念からは遠い 2 つのカテゴリに分類されるように見えます。技術レベルの継続的な進化に伴い、金融機関は新しいアプリケーションシステムの開発において、コンテナ化などのクラウドネイティブ導入アーキテクチャを徐々に導入し始めていますが、開発状態に重点を置いたクラウドネイティブ機能では対応できないことが常にわかっていました。あらゆるレベルの金融システム構築。クラウドコンピューティング技術の急速な変化により、狭義から広義のクラウドネイティブ化が進み、今日のクラウドは、より普遍的な標準インフラとなり、新技術や新たなビジネス革新のプラットフォームとなっています。ビッグデータ、クラウドネイティブストレージ、クラウドネイティブネットワークテクノロジなどのネイティブテクノロジにより、クラウドのネイティブ機能をソフトウェア開発からデータプラットフォーム、さらに基礎となる物理展開アーキテクチャにまで拡張できます。今日のクラウドコンピューティングは、パブリッククラウドであろうとプライベートクラウドであろうと、その技術システムとオープンソースの採用とサポートによってもたらされる進歩により、業界の未来志向の計画を確かに変えています。

長年の探求と実践を経て、私たちはクラウドネイティブを狭義から広義に変え、クラウドの先進的な考え方を拡張するという全く新しい概念「金融グレードクラウドネイティブ」を提案します。 - アプリケーション開発からシステムの物理的な展開アーキテクチャまでをネイティブにカバーし、財務レベルを組み合わせながら、単純な開発状態から設計状態 + 研究開発状態 + 運用状態 + 運用保守状態 + 災害復旧状態までの完全な技術リンク高可用性、高パフォーマンス、ビジネス継続性などの各カテゴリの機能が要約され、財務レベルのフルスタックのクラウドネイティブアーキテクチャパラダイムに定義されます。このようなアーキテクチャパラダイムは、最先端の技術アーキテクチャ概念と最も厳格な財務レベルの SLA を高度に組み合わせ、フルスタックのクラウドネイティブ機能をアップグレードし、従来のアーキテクチャを完全に置き換え、デジタル技術の急速な発展における技術システムを記述することを目的としています。人工知能のクラウド時代の今日、人工知能は最も強力なサポートを提供できます。

02 金融ITアーキテクチャの開発

銀行が鉄人なら、IT システムは彼のスーツです。

過去 40 年間、銀行に代表される金融業界の事業発展と変革に伴い、IT システムの全体構造も進化を繰り返してきました。銀行の情報開発プロセスは、主に 4 つの段階に要約できます。 -単独の時代、ネットワークとオンラインの時代、データ集中の時代、そして分散型クラウドネイティブの時代。

1) スタンドアロン時代：手作業の代わりにコンピュータが使用されますが、情報の相互接続はなく、各支店が別々の「電子台帳」となり、情報の島となります。

2) ネットワーキングの時代: 銀行は、完全なネットワークインフラストラクチャを頼りに、地方自治体のホストを中心とする地方の中規模都市に依存し、さまざまな店舗のビジネスをリンクして、地方自治体の相互接続を実現します。

3) データ集中化の時代: 銀行は、独自の発展に応じて、さまざまな程度でデータとビジネスを集中化し、システムインフラストラクチャ、物理サーバー、データ、アプリケーションの集中化を実現します。

大規模データ集中時代は、銀行のIT情報化が最も早く発展し、業務を最も推進する時期でもあり、ITシステム全体の構築において最も重要となるのが「基幹システム」です。基幹システム：コアバンキングシステム（COREとはCentralized Online Real-time Exchange、「Centralized Online Real-time Transaction」の略称）振替決済を例にすると、従来の半月から半月に短縮されました。中国の金融サービスは、大規模なデータの集中と基幹システムのリアルタイムオンライン取引機能の構築によって、サービス能力と取引効率が大幅に向上しました。銀行の業務の豊かさ、取引量、データ量は常に最高値を更新し続けている一方で、銀行の根幹となる基幹システムは、処理性能や安定性、安定性などにおいて非常に高い課題と課題を抱えています。 IT システムのセキュリティとセキュリティ。当時、国内の IT 企業にはまだこのような非常に高い要件を満たせる余裕はなく、銀行の IT アーキテクチャには集中型アーキテクチャしか選択肢がありませんでした。

4) 分散型クラウドネイティブ時代：金融ビジネス形態の継続的な拡大に伴い、集中型アーキテクチャのスケーラビリティ不足、インターネット型の同時性の高い対応能力の不足、コスト高、独自の研究開発要件などの欠陥が顕在化し続けています。同時に、分散型クラウドネイティブテクノロジーも銀行のインターネットサービスプラットフォームからコアシステムの技術アーキテクチャに徐々に移行しており、徐々に銀行全体の新世代の主流の技術アーキテクチャになりつつあります。

画像.png

集中型アーキテクチャの特徴:集中型アーキテクチャは、IBM、Oracle、および EMC が支配するシステムアーキテクチャパラダイムも指します。IBM のメインフレーム/ミニコンピュータ、Oracle のデータベース、および EMC のストレージは常に国内供給のボードが不足しており、集中型アーキテクチャに大きく依存しています。コアアーキテクチャシステム。集中型アーキテクチャの最大の特徴は、導入構造がシンプルであることであり、基盤となるハードウェアには、一般に IBM、HP、Oracle などのメーカーから購入した高価なメインフレーム、ミニコンピュータ、オールインワンコンピュータが使用されます。複数のノードにサービスを展開する方法を考慮する必要がなく、ノード間の「分散コラボレーション問題」を考慮する必要がありません。一般的には、単一マシンのリソース構成を増やすことでシステムの処理能力を向上させたり、ハードウェア機器や基本ソフトウェアのクラスタ機構を増やすことでシステムの可用性を向上させる「縦横拡張」方式が採用されます。

分散アーキテクチャの特徴:システムは、異なるネットワークコンピュータに展開された複数のモジュールで構成され、ネットワークを介したメッセージパッシングを通じてシステムが相互に通信および調整します。分散システムは、サーバの台数を増やすことでシステムの稼働能力を向上させる「水平水平拡張」という手法を採用しており、理論的には稼働容量を無限に拡張することができます。分散システムはクラスタ展開を採用しており、クラスタ内の各ノードは独立した動作単位であり、タスクのサイズに応じていつでもノードの数を増減できます。単一ノードに障害が発生しても、全体の可用性には影響しません。

03 金融企業はクラウドネイティブの問題と矛盾を受け入れる

「デザインとは、物事を美しくすることではなく、物事をより良く機能させることです。」同様に、クラウドネイティブもファッションのためではなく、問題を解決するためにあります。

アリババは2009年に分散型アーキテクチャを提案し、2013年に分散型アーキテクチャを基本的に完成させた。

ハードウェアに関しては、標準化された X86 サーバーを使用して IBM ミニコンピューターと EMC ストレージデバイスを置き換え、パフォーマンス拡張のプレッシャーを解決します。

ソフトウェアに関しては、Oracleデータベースの代わりにオープンソースのOceanBaseとMySQLを使用します。

システム面では、分散型クラウドネイティブアーキテクチャの考え方を用いて新たなシステムを構築した。

アーキテクチャの分散化の過程で、アリは安価で比較的制御可能な PC サーバーを使用して大規模なコンピューティングの問題を解決するだけでなく、クラウドネイティブテクノロジの成熟と幅広い応用も促進します。金融業界におけるビジネスとテクノロジーの継続的な反復と開発に伴い、分散型クラウドネイティブテクノロジーは、高性能、高信頼性、高柔軟性、高標準の要件を満たす必要があるだけでなく、セキュリティ、リスクにも重点を置く必要があります。、パフォーマンス、および容量のコスト全社的なアーキテクチャ設計の考慮事項という観点からは、次の 8 つの大きな問題に直面する必要があります。

質問 1: クラウドネイティブとは何ですか? 金融グレードのクラウドネイティブとは何ですか?

CNCF によるクラウドネイティブの当初の定義は、ソフトウェア開発レベルでの新しいパラダイムに重点を置いた狭い概念であり、コンテナ化されたデプロイメント + マイクロサービスアーキテクチャ + 継続的開発および継続的インテグレーション + DevOps の 4 つの特徴を持つ「狭いクラウドネイティブ」と定義されています。」のコアはアプリケーション開発者向けです。しかし、クラウドコンピューティングの継続的な進化に伴い、クラウドネイティブストレージ、クラウドネイティブネットワーク、クラウドネイティブデータベース、クラウドネイティブビッグデータ、クラウドネイティブ AI、クラウドネイティブビジネスミドルプラットフォームなどはすべて、クラウドネイティブというカテゴリーが統一されているため、概念が徐々に拡大しており、「狭義のクラウドネイティブ」は依然として開発レベルに焦点を当てており、顧客のアーキテクチャ全体のアップグレード問題を完全には解決できていないため、「広義のクラウドネイティブ」センス」が形成されました。

金融業界のより厳格な要件に直面して、アジャイル開発の問題だけでなく、アーキテクチャの高度な性質も解決し、金融とセキュリティコンプライアンス、強力なトランザクション一貫性、ユニット拡張、災害対応を統合する必要があります。リカバリ、マルチアクティブ、およびフルチェーンクラウドネイティブテクノロジーとの徹底的な統合により、従来の集中型アーキテクチャのアーキテクチャ全体のアップグレードを実現し、金融業界の標準と要件を満たすだけでなく、ネイティブテクノロジーアーキテクチャの利点があり、「財務レベルのクラウドネイティブアーキテクチャ」を形成します。

質問 2: クラウドネイティブによって IT の運用と保守管理はどこに変わりますか?

「車は同じ道を走り、本は同じテキストを知り、同じ道を歩く。」

IT アーキテクチャの進化の観点から見ると、従来の集中型アーキテクチャは導入が容易であるものの、垂直方向の煙突分割と水平方向の管理分散があり、各レイヤーと各技術製品が独立して管理および保守されています。仮想化技術が成熟すると、基盤となるサーバー、ストレージ、ネットワーク、仮想マシンなどのレベルでの一元的かつ統合的な管理が実現され、運用保守担当者の管理半径が大幅に向上します。クラウドネイティブの中心的な概念は、すべてのリソーステクノロジーがプーリングとサービスの形式で提供されるということであり、これはもはや従来の煙突型のリソース供給関係ではありません。クラウドネイティブアーキテクチャにより、IaaSリソース、PaaSリソース、分散データベース、分散ミドルウェア、コンテナ、研究開発プロセスなどのさまざまな技術サービスの標準化と一元管理がさらに実現され、まさに「同一軌道上、同一テキスト」を実現します。」により、運用・保守の煩雑さが大幅に軽減され、一人当たりの管理対象の規模が向上します。

質問 3: クラウドネイティブシステムはオープンソースガバナンスをどのように実装しますか?

これまで、金融企業がクラウドネイティブのテクノロジーや製品を使用したい場合は、オープンソースプロジェクトの調査、O&M および管理を自分たちで行うことに多大なエネルギーを費やす必要があり、また、統合や安定性の保証などの問題も考慮する必要がありました。クラウドネイティブなプラットフォームを構築するためです。金融機関は、オープンソースソフトウェアが解決できるのは表面上の明示的な機能要件と、表面下の多数の暗黙的な非機能要件のみであることに気づき始めています。クラウドネイティブアプリケーションを構築する際には、特に考慮する必要があります。

開発者や運用・保守担当者がクラウドネイティブテクノロジー製品を使いやすくするために、製品の統合、運用、監視に至るまで一連のエンタープライズレベルのクラウドネイティブテクノロジープラットフォームと技術標準を確立する金融機関が増えています。、運用とメンテナンス多次元の製品とアーキテクチャのガバナンス。SLA 保証、成熟したケース、技術仕様、グレースケールを備えたクラウドネイティブテクノロジーの適応と実装を実現します。

質問 4: 1+1>2 を達成するには、クラウドネイティブを情報テクノロジーアプリケーションのイノベーションとどのように組み合わせることができますか?

完全なトップダウンのクラウドネイティブ技術スタックは、今日の最先端の技術システムを表しており、したがって、「情報技術アプリケーションの革新」のための技術ソリューションの選択においては、単なるハードウェアのアイデアや単純なポイントツーポイントではありません。代替案ですが、もっと活用する必要があります。最先端のクラウドネイティブテクノロジアーキテクチャは、「情報テクノロジアプリケーションイノベーション」変革の機会を活用して、包括的な機能アップグレードを実現します。

金融機関のITシステム構築において「情報技術活用の革新」は無視できない重要な要素となっており、クラウドネイティブシステムを構築する際には、これらの要件によってもたらされる「情報技術活用の革新」などの課題を考慮する必要があります。ハードウェアとソフトウェアのサプライチェーンの安定性と国産チップの信頼性。

「情報技術応用の革新」により、金融機関は必然的に異なるチップサーバーの「断片化問題」（管理の複雑化とコストの増加）に直面することになるが、各種類のチップクラスターを個別に構築してクラウド管理すると、マルチクラウドリソースプールの断片化と分化により、クラウドネイティブアプリケーションがリソースを均一にスケジュールして使用することが困難になり、さまざまなビジネスの山と谷を弾力性のために完全に活用できなくなります。さらに、複数のクラウドを使用すると、導入、アップグレード、容量拡張などの運用と保守が複雑になり、それらを個別に管理する必要があるため、運用と保守の管理コストが高くなり、運用エクスペリエンスが低下します。

したがって、「複数のコアを備えた 1 つのクラウド + クラウドネイティブ」が断片化の問題に対する最適な解決策となり、「複数のコアを備えた 1 つのクラウド」は、異なる種類のチップの共存によって引き起こされるマルチクラウド管理の問題を根本的に解決します (断片化の一元管理、統合化「マルチコア」の違いが「ワンクラウド」の標準化されたサービスに変わり、リソース統合（大小の断片化したリソースの組み合わせ）の問題をクラウドネイティブで解決します。クラウド上のリソースプールの強力なコンピューティング能力を最大限に活用し、複数のチップクラスター機能のコンピューティング能力リソースの統合を実現し、真に 1+1>2 のクラウドを形成します。

画像.png

質問 5: クラウドネイティブアーキテクチャはビジネスセキュリティの実現にどのように対応しますか?

「マーフィーの法則」によると、「すべてを疑ってください。ノード障害は必ず起こります。」 (「うまくいかない可能性のあるものはすべてうまくいかない」)。クラウドネイティブアプリケーションアーキテクチャの設計原則は、安全な運用に影響を与える潜在的な「ブラックスワン」リスクを「正常」なものとみなすことです。

クラウドネイティブアーキテクチャの提案は、障害の発生を許容し、各サーバーと各コンポーネントがシステムに影響を与えることなく障害が発生しても、自己修復機能と交換可能な機能を備えていることを保証することです。即時障害 (フェイルファストとフェイルスモール) は、クラウドネイティブシステムの重要な設計原則です。その背後にある哲学は、障害は避けられないため、問題が早く露呈するほど、アプリケーションの回復が容易になり、アプリケーションの回復が容易になるというものです。実稼働環境に入る際の問題。フェイルスモールの本質は、障害の範囲、つまり影響範囲を制御することであり、焦点は、システムの問題を解決する方法から、障害を迅速に発見して適切に処理する方法に移ります。

金融グレードのクラウドネイティブアーキテクチャでは、技術的なリスクも最優先事項です。トランザクション処理にエラーが発生すると、予測できない経済的損失が発生する可能性があります。システムアーキテクチャプラットフォームからリスク文化メカニズムに至るまで、アーキテクチャ設計、製品開発、オンライン変更、安定性評価、障害の各側面を保証するための専門的な技術リスクシステム (SRE、サイトリスクエンジニアリング) を確立する必要があります。ライフサイクル全体を通じてリスク品質管理を確保し、システム変更に対する包括的な保証を提供します。

質問 6: クラウドネイティブアーキテクチャはビジネス継続性をどのように保証しますか?

金融機関にとって、ビジネスがオンライン化されると、最も容認できないのは、ビジネスが利用できなくなることです。

クラウドネイティブの復元力は、システムが依存するソフトウェアおよびハードウェアコンポーネントにさまざまな異常が発生した場合のシステム全体の復元力を表します。これらの異常には通常、ハードウェア障害、ハードウェアリソースのボトルネック (CPU/ネットワークカードの帯域幅の枯渇など)、ビジネス要因が含まれます。ソフトウェアの設計能力を超えるトラフィック、コンピュータ室の作業に影響を与える障害や災害、ソフトウェアのバグ、ハッカーの攻撃など、ビジネスの可用性の低下に致命的な影響を及ぼします。レジリエンスとは、ビジネスサービスを多面的に継続的に提供するシステムの能力を意味し、システム全体のビジネス継続性を向上させ、クラウドネイティブアーキテクチャ設計からシステムのレジリエンスを強化することが中心となります。財務レベルのクラウドネイティブの復元機能には、サービスの非同期機能、再試行/電流制限/劣化/融合/バックプレッシャー、マスター/スレーブモード、クラスターモード、AZ 内の高可用性、ユニット化、クロスリージョンの災害復旧、リモート複数ライブが含まれます。災害復旧など

質問 7: クラウドネイティブアーキテクチャはトランザクションの一貫性をどのように処理しますか?

人々は分散システムをスタンドアロンシステムのように使いたいと考えているため、「分散一貫性」の問題に直面することは避けられません。

クラウドネイティブのマイクロサービスにおける「マイクロ」とは、サービスの粒度が小さくなり、金融取引の複雑さが相対的に大きくなることを意味します。したがって、クラウドネイティブシステムにおけるデータの一貫性は比較的複雑な問題であり、異なるマイクロサービスに独立したデータストレージがあるため、データの一貫性を維持することが困難になります。CAP 定理に基づいて、分散マイクロサービスシステムではネットワークエラーが避けられないため、ネットワークの分断が発生した場合には、一貫性と可用性のバランスを取るクラウドネイティブアーキテクチャが必要になります。

したがって、財務レベルのクラウドネイティブアーキテクチャを計画する場合、金融サービスから一貫性までの課題にも直面することになります。この一貫性は、ビジネスロジック (TCC、SAGA、XA トランザクション、メッセージキューなど) に反映されるだけでなく、データレベルでの一貫性の保証 (マルチノードの一貫性、マルチセンターの一貫性) がさらに必要になります。

質問 8: クラウドネイティブアーキテクチャとアプリケーションの設計と開発の課題は何ですか?

人を疲れさせるのは、遠くの山ではなく、靴の中の砂粒です。

クラウドネイティブテクノロジーには多くの利点がありますが、金融機関は多くの既存システムを所有していることが多く、これらの既存システムの技術システムはクラウドネイティブテクノロジーとは異なることがよくあります。既存のシステムと新しいクラウドネイティブアプリケーションをどのように統合して管理するか? マイクロサービスの分割戦略を策定する方法、分割ディメンション、分割標準、分割粒度を測定する方法は? クラウドネイティブの監視可能なシステムを確立し、効果的な監視、ログ管理とアラームを実装し、アプリケーションのパフォーマンスとリソースの使用状況をリアルタイムで監視し、問題が発生したときに迅速に特定して解決するにはどうすればよいでしょうか?

これらの問題は、徹底的な解決策を必要とするものであり、多くの金融機関は、クラウドネイティブテクノロジーでは、設計、研究開発、運用、運用と保守、災害復旧の 5 つの状態で統一された技術仕様を実装する必要があることを認識しています。設計と開発段階では、運用と保守、災害復旧、セキュリティなどのフロントエンドが考慮、設計され、バックエンドの人的作業負荷と管理の複雑さを解決するためにクラウドネイティブテクノロジーが使用されます。

04 財務レベルのクラウドネイティブの「新たな標準と新たな青写真」

金融グレードのクラウドネイティブの開発プロセス

『アウト・オブ・コントロール: 全人類の究極の運命と結末』におけるケビン・ケリーの現代テクノロジーの予測の正確さにより、著者は多くのテクノロジー関係者の心の中で預言者王となり、この本もまた聖なる本となった。この本の説明では 2 つの重要な点が強調されています。

1. 複雑なシステムは、多数の独立した自律的な単純なシステムで構成されます。

2. 複雑な動きは、単純な動きから組み立てられるものであり、変更されるものではありません。

システム全体は、異なるレベルで単一の責任を持つ複数の「マイクロシステム」（マイクロサービス）で構成されており、システム自体はフォールトトレランスと反復の自由を備えており、全体として動的なフォールトトレランスを実現できます。最も重要なことは、このシステムには「集中化された神の手」が存在しないということです。これはクラウドネイティブが提唱するシステムアーキテクチャ設計と一致しており、クラウドネイティブの誕生もこれにインスピレーションを受けています。

「一頭のクジラが倒れれば、すべてが成長する」ということわざにあるように、従来の集中型アーキテクチャの衰退と衰退に伴い、クラウドネイティブテクノロジーが全面的に成長し、出現しています。

クラウドネイティブとは、本質的にはクラウドから生まれたソフトウェア、ハードウェア、アーキテクチャです。クラウドネイティブも継続的な開発と進化のプロセスです。クラウドネイティブ (Cloud Native) の概念は 2015 年に提案され、その後 CNCF によってさらに開発および洗練されて、コンテナー、継続的デリバリー、継続的インテグレーション、サービスグリッド、マイクロサービス、不変の基盤「ほぼクラウドネイティブ」な機能と宣言型 API の概念。

現在、「デジタル化」というと、実は 2 つの概念があり、1 つはオリジナルと呼ばれるもの、もう 1 つはトランスフォーメーションと呼ばれるものです。狭義のクラウドネイティブテクノロジは、主にインターネットベースの「デジタルネイティブ」企業、主にステートレスなインターネットベースのアプリケーションの新しいアジャイルイノベーション要件を満たし、データの一貫性のために最終的な一貫性を必要とします。しかし、従来の金融「デジタル変革」企業の既存の技術標準と技術資産（負担）には、より大きな障害が存在することがよくあります。

クラウドコンピューティングテクノロジーの継続的な深化と普及に伴い、ますます多くの新しいテクノロジーが「クラウドから誕生」しており、これらの製品、テクノロジー、ソフトウェア、ハードウェア、アーキテクチャは「 クラウドで生まれ、クラウドよりも長い」ものになりつつあります。成熟して構成された「一般化されたクラウドオリジン」の概念が誕生します。将来的には、新世代のデータベース、人工知能、ストレージ、チップ、ネットワーク、健康コードなど、「クラウドで生まれ、クラウドで成長する」「クラウドネイティブ」製品が引き続き登場するでしょう。クラウドネイティブの極めて高い弾力性、サービスの自律性、および大規模な複製可能性により、異種リソースの標準化、デジタル生産性のリリースの加速、ビジネスアプリケーションの反復速度の加速、およびビジネスイノベーションの促進が容易になります。これはデジタル時代の多くの不確実性の中で「最大の確実性」であり、その強力な包括性は将来のデジタル企業の全体的な技術アーキテクチャの方向性を表しています。「デジタルネイティブ企業」の技術アーキテクチャに対するアジャイルイノベーション要件に加えて、一般化されたクラウドネイティブテクノロジーは、従来の「デジタルトランスフォーメーション企業」の技術標準とアーキテクチャ互換性要件も考慮しているため、より幅広い技術的要件を備えています。アーキテクチャの適用性とエンタープライズレベルのサービス機能の向上。

画像.png

今日、クラウドネイティブが徐々にコミュニティから金融機関に移行し、人々の間でますます人気が高まっているため、金融機関は金融シナリオの要件とクラウドネイティブ実装 (金融セキュリティコンプライアンス、強力なトランザクション一貫性、ユニットの拡張、ディザスタリカバリとマルチアクティブ、フルリンクのビジネスリスク管理、運用および保守管理、その他の業界要件がクラウドネイティブテクノロジーと深く統合され、一連の「金融グレードのクラウドネイティブアーキテクチャ」を開発します。金融レベルの IT 環境の厳しい課題と要件をより適切に満たし、金融機関の従来の「安定したアプリケーション」 (デジタルトランスフォーメーション) および「機密性の高いアプリケーション」 (デジタルネイティブ) アプリケーションに統合された技術アーキテクチャサポートを提供します。

かつての中央集権的な金融アーキテクチャ（中枢頭脳）による一元管理を「左」、完全オープンソースの分散型クラウドネイティブを「右」とすると。金融クラウドネイティブアーキテクチャの下で、金融機関が必要とする技術アーキテクチャは、財務レベルのセキュリティ、強力な一貫性、信頼性だけでなく、フォールトトレラント、スケーラブル、そして素早い対応力。アプリケーションの複雑さを保護する「強力な地方自治、弱い中央制御」アーキテクチャ (例: GRC アーキテクチャ、G-Global グローバルシステム、R-Region 地域システム、C-City ローカルシステム) を提案し、判断する必要があるもののみを提案します。複雑なロジックはグローバルシステム（中枢）で完成させて中央システムの負担を軽減し、日常の多数の単純な判断や実行動作はローカルシステムの閉ループで完結させることで耐障害性を向上そしてシステム全体の堅牢性。

画像.png

金融クラウドネイティブを定義する 10 の新しい要素

クラウドネイティブアーキテクチャは、クラウドネイティブテクノロジに基づく一連のアーキテクチャ原則と設計パターンであり、クラウドアプリケーション内の非ビジネスコード部分を最大限に分離して、クラウド施設が元の非機能部分の多くを引き継ぐことができるようにすることを目的としています。アプリケーションの機能 (弾力性、粘り強さ、セキュリティ、可観測性、グレースケールなど) を活用し、非機能的なビジネス中断の問題を発生させることなく、ビジネスを軽量化、俊敏性、高度に自動化します。従来のアーキテクチャでは、アプリケーション層にはより多くの非ビジネスコードが含まれていますが、クラウドネイティブアーキテクチャでは、非機能コードがアプリケーションコードロジックに反映されず、インフラストラクチャに組み込まれることが理想的な状況です。また、保守担当者も業務コードに関連する部分のみに集中すれば済みます。財務レベルのクラウドネイティブの中核を、次の 10 個の主要なアーキテクチャ要素に要約します。

画像.png

要素 1: プラットフォームエンジニアリングと不変のインフラストラクチャ

クラウドネイティブテクノロジーの大規模な利用に直面して、金融機関の研究開発と運用保守の複雑さを軽減することは、クラウドネイティブテクノロジーの導入を制限する大きな障害となっています。現時点では、研究開発管理と運用保守管理の観点から、「プラットフォームエンジニアリング」と「不変インフラストラクチャ」は、複雑さを大幅に軽減できる 2 つの重要なクラウドネイティブ機能です。

DevOps の哲学は「誰が構築し、誰が実行するか」であり、開発者はアプリケーションをエンドツーエンドで開発、デプロイ、実行できる必要があります。しかし、ほとんどの金融機関にとって、これを達成するのは実際には簡単ではありません。実証済みの効果的な分業 (運用と開発) では、人材に対する要件は比較的低くなりますが、DevOps パラダイムの推進により、研究開発担当者はすべてをよく知っている必要があり、「認知的負担」が大幅に増加します。これは金融機関の研究開発チームに高い要求を課しており、ユニバーサル人材の育成には役立たず、金融機関によるクラウドネイティブアプリケーションの包括的な導入にも大きな支障をきたすことになる。最も可能性の高い改善の方向性の 1 つがプラットフォームエンジニアリングである場合、プラットフォームエンジニアリングは DevOps とビジネスプログラマーの間の架け橋となります。開発者がより迅速かつ優れたビジネスソフトウェアを提供できるようにするセルフサービスプラットフォーム。ページベースの簡単な操作でこのリンクのシリーズ構成が完了するため、研究開発者は多くの運用保守ツールの詳細に注意を払う必要がなくなり、アプリケーション機能の開発に集中できます。Gartner のプラットフォームエンジニアリングの説明「プラットフォームによって統合されるツール、機能、プロセスは、ドメインの専門家によって慎重に選択され、エンドユーザーの利便性を考慮してパッケージ化されています。最終的な目標は、ユーザーに適切なサービスを提供する、摩擦のないセルフサービスエクスペリエンスを作成することです」最小限のコストで重要な作業を完了できるようにする機能を提供し、エンドユーザーの生産性を向上させ、認知負荷を軽減します。」

従来の可変インフラストラクチャは、物理マシンまたは仮想サーバーに基づくアプリケーションサービスの展開を指します。オペレーティング環境の構築は、動的に構成または分散できる一部のサーバーの構成や基本ソフトウェアなど、多くの変数に依存します。異なる環境間での相互運用アプリケーションのステータスを更新するための外部サービスへのリアルタイムアクセスアプリケーションサービス全体が依存するインフラストラクチャは常に変化しています緊急ロールバックが必要なシナリオが発生した場合、運用保守担当者の処理プロセスは多くの場合、複雑で間違いが起こりやすい。

クラウドネイティブの不変インフラストラクチャとは、クラウドネイティブのミラーリングソリューションに基づいて、アプリケーションが依存するインフラストラクチャ (オペレーティングシステム、セキュリティスクリプト、運用および保守エージェント、開発フレームワーク、オペレーティング環境など) が不変のイメージにパッケージ化されていることを意味します。コンテナをプルアップするためにイメージに依存するだけでよいため、アプリケーションのデプロイメント、運用および保守のコストが大幅に削減され、アプリケーションのデプロイメントおよび運用および保守がより簡単かつ予測可能になり、同時にアプリケーションの動作環境の安定性と信頼性も向上します。また、イメージに基づいて自動ローテーション置換や自動ロールバックなどのO&M機能を実現できるため、アプリケーションO&Mの自動化レベルが大幅に向上します。イメージの階層化によりイメージ管理レベルが向上する一方で、イメージの階層化によりイメージのロード効率がコンテナローディングの原理に従ってある程度向上し、アプリケーションの起動速度が向上します。

画像.png

要素 2: 弾力性のあるハイブリッドクラウド

クラウドアーキテクチャが金融機関の主流のプラットフォームおよびインフラストラクチャになるにつれて、ビジネスユニットに応じてオンデマンドで弾力的に拡張する機能があり、トラフィックのピークに直面したときにリソースとアプリケーションの処理能力を向上させるために迅速かつ弾力的に拡張でき、リリースすることができます。最大のリソース使用率を達成するには、アプリケーショントラフィックがピークに達した直後にリソースを再利用する必要があるため、柔軟性があり、低コストで複製できる柔軟なアーキテクチャを構築する必要があります。弾性アーキテクチャの本質は、ユニット化アーキテクチャの拡張であり、ユニット化アーキテクチャ内でビジネスユニットの最小の粒度で、主にポップアップとバウンスバックを含む弾性スケーリングを実行する機能を提供します。ポップアップとは、コンピューティングリソース、ネットワーク、アプリケーション、データレベルをビジネスユニットに基づいて包括的にポップアップするもので、下位レベルのリソースから上位層のトラフィックに至るまで全体的に柔軟な手段です。ポップアップユニットはエラスティックビジネスと呼ばれます単位。通常のビジネスユニットとは異なり、フレキシブルビジネスユニットには次の特徴があります。

局所性:通常モードで展開される各ビジネスユニットには、すべてのアプリケーションとすべてのデータが含まれる必要がありますが、エラスティックアーキテクチャの下でポップアップするエラスティックビジネスユニットには、ユニット内のアプリケーションの一部とデータの一部のみが含まれる必要があります。高トラフィックのリンク関連アプリケーションが関係しています。

一時的:通常のビジネスユニットの長いライフサイクルとは異なり、フレキシブルビジネスユニットのライフサイクルは比較的短いです。「ダブルイレブン」やその他の大きなプロモーション支払いのピークをサポートした後、フレキシブルビジネスユニットのビジネスリクエストは通常のレベルに戻ります。ビジネスユニットを削除し、コストを節約するために弾力性のあるビジネスユニットを解放します。

クロスクラウド:エラスティックなビジネスユニットは、通常、1 つまたは複数の他のクラウドに配置されています。エラスティックアーキテクチャを使用するシナリオが直面するトラフィックのピークは、日常的なトラフィックの数倍です。日常的なクラウドコンピューティングベースで十分なリソースを提供することは困難です。時間が経つと、他のクラウドコンピューティングベースが大量のリソースサポートを提供する必要があります。

柔軟なアーキテクチャにより、ハイブリッドクラウドの利点が最大限に発揮されます。大規模なクラウドリソースにより、アプリケーションは、非常に高いトラフィックピークに対処するために無限に拡張できます。トラフィックピークに達した後は、リソースをすぐに解放し、リソースを柔軟にスケールオンできます。要求。

要素 3: リソースの混合デプロイメント

日常の運用では、高品質のサービスを確保するために、オンラインサービスアプリケーションは長時間実行され、CPU リソースを独占することがよくありますが、CPU 使用率は非常に低いのに対し、オフラインコンピューティングタスクはその逆で、通常は短時間で実行されます。ライフサイクルとリソースサービスの品質への影響要件は高くありませんが、実行時の CPU 使用率は高くなります。ビジネス規模の拡大に伴い、オンラインビジネスクラスターとオフラインクラスターのリソースプールは徐々に大きくなり、ビジネスのピーク時間が低いため、リソースの使用率に問題が発生します。高いが、実際の稼働率は低い。

金融機関は、クラウドネイティブアーキテクチャ構築の過程でオンラインおよびオフラインのクラスターを展開し、CPU エラスティックシェアリングや優先度プリエンプション、オフライン/オンラインアプリケーションの時差スケジューリング、アプリケーションの QoS 分類、メモリ階層管理などのコア機能に加え、リソース分離ベースのオンおよび動的調整、さまざまな属性タイプのオンラインサービス、およびオフラインコンピューティングサービスを正確に組み合わせて、効率的なリソース利用の問題を解決します。財務レベルの複雑さに応じて、次のような部門混合の能力基準を確立する必要があります。

大規模でマルチシナリオの混合部門。事業運営のためのインフラストラクチャと環境に混合部門のテクノロジーを構築し、混合部門の技術能力の成果を向上させ、他のリソース環境への昇格を促進します。

部門が混在する管理・制御システムと運用・保守システムの一貫性を実現します。リソースアクセスプロセスを統合して、基本的なソフトウェアと構成のグローバルな一貫性の維持と管理を保証します。

リソーススケジューリング、オンライン/オフラインサービスの高速リソース切り替え、および統合されたリソーススケジューリングのための、柔軟で効率的かつきめ細かいプロセス。

混合部品の安定性は非混合部品と同レベルの安定指数に達します。きめ細かいサービス測定の定式化、およびリソースの分離とビジネス運営の適応性の向上に依存します。

実行時監視、異常発見および診断機能を向上させる混合監視システム。

混合部門の異常緊急時対応メカニズムは、安定性リスクのシナリオを事前に特定し、プロセスベースの緊急時対応メカニズムを策定して、異常かつ迅速な復旧能力を生み出します。

要素 4: 複数のテクノロジースタックの異種統合

サービスメッシュは、サービス間の通信を処理するインフラストラクチャ層と考えることができます。最新のクラウドネイティブアプリケーションには複雑なサービストポロジがあり、サービスメッシュはこれらのトポロジ全体でリクエストを確実に配信する役割を果たします。実際には、サービスグリッドは通常、アプリケーションと一緒に展開される一連の軽量ネットワークエージェントであり、サービス間のネットワーク呼び出し、電流制限、ヒューズ、監視を担当する、アプリケーションまたはマイクロサービス間の TCP/IP にたとえることができます。

サービスグリッドテクノロジを適用する前に、マイクロサービスシステムの実装は、多くの場合、ビジネスアプリケーションのミドルウェアチームによって提供されます。SDK には、サービスディスカバリ、ロードバランシング、サーキットブレーク、サービスガバナンス機能などのさまざまなサービスガバナンス機能が SDK に統合されます。電流制限、およびサービスルーティング。実行時には、SDK とビジネスアプリケーションコードが 1 つのプロセスで混合されて実行され、結合度が非常に高いため、一連の問題が発生します。

1回のアップグレードコストが高い。SDK がアップグレードされるたびに、ビジネスアプリケーションは SDK のバージョン番号を変更し、アプリケーションを再公開する必要があります。ビジネスが急速に発展している場合、このようなアップグレードは研究開発の効率に影響を与えます。

次に、バージョンの断片化が深刻です。SDKのアップグレードやミドルウェアの継続的な開発には高額なコストがかかるため、時間の経過とともにSDKのバージョンの不一致や機能の不均一などの問題が発生し、一元管理に多大な負荷がかかります。

第三に、ミドルウェアの進化は難しい。SDK バージョンの断片化が深刻なため、ミドルウェアが進化する際には、コード内のさまざまな古いバージョンのロジックと互換性を持たせる必要があり、足かせを付けられたまま前進しているようなもので、迅速なイテレーションを実現できません。

金融機関のサービスグリッドは、基本的な RPC、メッセージ、DB アクセス機能に加え、サービスディスカバリ、融合、電流制限、トラフィック制御、サブデータベース機能など、元々 SDK を通じて統合されていた一部のネットワーク通信機能を Sidecar に組み込みます。データベースのサブテーブルは、より透過的な通信インフラストラクチャをビジネスシステムにもたらし、インフラストラクチャの反復的な進化をビジネスシステムから切り離し、ビジネスの研究開発がビジネスロジックに集中できるようにし、ビジネスシステムの負担を軽減します。ビジネスの改善システムとインフラストラクチャの反復効率を向上させます。

要素5：インフラの継続性（官民一体）

ますます多くのコアシステムも完全なクラウドネイティブ化に向けて移行しており、大規模リソースのスケジューリングとオーケストレーションは金融インフラの継続性に不可欠な機能となっています。金融機関のさまざまな事業部門の数千のアプリケーションにサービスを提供する方法、さまざまなアプリケーションがクラウドをうまく利用できるようにする方法、さまざまなアプリケーションのリソース需要の違いに対応し、クラウドの能力を最大限に活用してビジネスの成長をサポートする方法、インフラストラクチャの継続性には、パブリッククラウドのような統合リソース管理機能が必要であり、これには従来の汎トランザクションおよびデータシナリオだけでなく、大規模コンピューティングにおける GPU に代表される新しい異種コンピューティングハードウェアの採用の増加も含まれます。学習トレーニングタスク、オンライン推論タスク、ストリーミングメディアのエンコードおよびデコードタスクなどには、より豊富なリソースコンピューティングシナリオが必要です。

基盤となるリソースの統合運用および管理のための統合インフラストラクチャの継続性により、サプライチェーン、容量予測、容量計画、リソースプールの弾力性などのさまざまな側面からの豊富なクラウドネイティブ技術手段を通じてコストを最適化し、効率を向上させることができます。制御、基盤となるリソースの漏洩ゼロ、フラットで管理が簡単、柔軟で構成可能な柔軟な方法ですべてのシナリオをサポートします。

要素 6: フルリンク技術リスクの予防と制御

金融ビジネスシステムの本番環境の障害の多くは変更によって引き起こされており、変更管理は技術的リスクの予防と制御にとって重要です。特にマイクロサービス分散アーキテクチャ下では、サービスの規模が巨大で変更の原因も広範囲に及ぶため、変更の制御や追跡機能が強力でないと、オンラインで問題が発生すると、最初に対応する変更を迅速に見つけることが困難になります。また、変更自体の品質を効果的に制御することも難しく、リンク全体にわたるリスクと変更を管理および制御するには、クラウドネイティブアーキテクチャに基づく「技術的リスク予防および制御システム。

技術的なリスクの予防と制御の中核となる指針は、「変化の 3 つのトリック」、つまり観察可能、グレースケール、緊急です。あらゆる変更には、予想される効果を評価し、予期せぬ問題を特定し、変更の範囲のさらなる拡大と緊急対応行動の意思決定を導くために、実装前に観察可能な機能を導入する必要があります。「グレースケール」では、変更の範囲を徐々に拡大し、地域、データセンター、環境、サーバー、ユーザー、時間などの多次元からグレースケールのプロセスを設計する必要があることを強調しています。「緊急」は、変更計画ではロールバック機能の確保を優先する必要があることを強調しています。特殊な状況により、一部の変更にはロールバック機能がないか、ロールバックコストが許容できない場合があります。これは、データなどの他の変更を追加することで処理する必要があります。修正あり、新版オンライン等「変化の 3 つの軸」は、金融クラウドネイティブアーキテクチャにおける変更リスク管理の中核機能でもあり、機能の統合、変更プロセス中のヒューズ機能と自己修復機能の構築です。

「フルリンクリスク防止および制御システム」の中核となる責任は、すべての変更情報を統合することで変更を可視化し、より追跡しやすくすることです。同時に、変更手配、変更グレースケール検査、変更事前チェック、変更結果の監視と早期警告などの機能を提供し、問題発生時には変更の関連付けを提供してオンラインでの問題処理を迅速化します。

さらに、フルリンクリスク予防・制御システムは、キャピタルロスリスクポイントの分析、予防・制御策の策定、計画の詳細の明確化も可能である必要があり、品質テストと分析段階では、テストと分析が行われます。資本検証の分析を実行する必要があります。リリース前に、リアルタイム検証、T + M 分レベルの検証、T + H 時間レベルの検証、T + 1 翌日検証等「早期警戒を確認するために加入すると同時に、事業者側は資金の流れの完全な受け入れを行わなければなりません。」資金フロー操作は、証明書、証明書、口座、口座などの検証モードを通じて実行されます。

要素 7: クラウドネイティブのセキュリティと信頼性

現在、インターネット環境における外部脅威は多様化・新規化する傾向にあり、従来の防御手法では既知の脆弱性悪用や脅威攻撃手法には十分対応できますが、APT攻撃や0Day脆弱性攻撃などには十分に対応できません。。ただし、これらの既知の脅威と新しい脅威には、すべてビジネスが予期しない動作であるという共通の特徴があります。この機能に基づいて、クラウドネイティブテクノロジは、すべてのサービスリクエストとリソースの読み込み動作の信頼できる測定を実行し、信頼できる動作に基づいてセキュリティの多層防御システムを確立して、予期される動作のみがアクセスして正常に実行されることを保証する必要があります。ブロックとインターセプトにより、既知および未知の脅威に対抗する効果が得られます。

同時に、金融業界における事業者間のセキュリティ隔離を確保するために、インフラストラクチャなどの技術サービスにおいても、事業者から隔離された環境を構築し、独立した隔離されたネットワーク環境とより高いセキュリティレベルを構築する必要がある。クラウドネイティブプラットフォームテクノロジサービスは、信頼できるネイティブサービス標準に準拠した、マルチテナントの分離、統合された管理と制御、信頼できるチャネルの収束などの関連する変換を通じて、信頼できるネイティブサービスにアップグレードされます。アプリケーションが実行される環境では、クラウドネイティブの安全で信頼できるアーキテクチャに、インフラストラクチャ内の ID、認証、認可、フルリンクアクセス制御、フルリンク暗号化などのセキュリティと信頼できる機能が組み込まれており、次のことを実現します。アプリケーションの分離により、信頼できるネイティブな方法でサービスの中断が軽減され、信頼できるアプリケーションの動作環境が提供されます。

要素 8: 財務レベルの一貫性

画像.png

クラウドネイティブアプリケーションは主に分散システムであり、アプリケーションは複数の分散マイクロサービスシステムに分割されます。分割は一般的に水平分割と垂直分割に分けられます。これはデータベースやキャッシュだけを指すものではありません。分割は主に分割と分割を表します。アイデアとロジックを克服する。

分散システムの最下層は、「CAP の不可能な三角形」 (C: 一貫性、一貫性、A: 可用性、可用性、P: 分割許容度、分割許容度) から逃れることはできません。CAP 原則は、分散システムは上記の 2 つの点を同時に満たすことしかできず、3 つすべてに対処することはできないことを証明しています。ただし、分散サービスシステムはパーティショントレランスを満たす必要があるため、一貫性と可用性の間でトレードオフを行う必要があります。ネットワークに異常が発生すると、分散システム内の一部のノード間のネットワーク遅延が増大し続け、分散システム内のネットワーク分断が発生する可能性があります。コピー操作が遅れる可能性があります。ユーザーがコピーの完了を待ってから戻ると、限られた時間内に戻ることができなくなり、利用できなくなる可能性があります。また、ユーザーがコピーの完了を待たずに戻った場合は、プライマリシャード書き込み直後に戻ると使いやすさはありますが、一貫性が失われます。

金融機関にとって、アーキテクチャレベルでの高可用性とビジネスレベルでの強力な一貫性はほぼ同等に重要です。そのため、財務レベルのクラウドネイティブには「CAPの不可能なトライアングル」をうまくバランスさせることが求められ、ビジネスの強固な一貫性とシステムの高可用性を可能な限り考慮する必要がある。

しかし、「一貫性の課題」は、分散システムにおける単なるデータベースの問題ではなく、トランザクションの一貫性、ノードの一貫性、システム間のビジネスの一貫性、メッセージパワーの等価な一貫性、キャッシュの一貫性、相互一貫性など、分散システムのあらゆるレベルをカバーする大きなトピックです。 IDCの一貫性などしたがって、クラウドネイティブアーキテクチャには、財務レベルの一貫性という厳しい課題に対処できる一連のテクノロジーが必要です。

トランザクションレベル:さまざまな金融シナリオに応じて適切な分散トランザクションモデルを選択する必要があり、コストとパフォーマンスのバランスを考慮した上で、SAGA と TCC が金融機関で一般的に使用される 2 つの分散トランザクションモデルです。SAGA モードはアプリケーション実装への影響はそれほど大きくありませんが、設計の一貫性を確保するために補償トランザクションに基づいており、前後のステップの実行中にトランザクションの分離は保証されません。一方、TCC モードは次のことを実現できます。トランザクションの分離性は向上しますが、アプリケーション層の認識がより複雑になる必要があります。結果を同期的に返す必要がないトランザクションプロセス内の一部のノードについては、非同期メッセージキューを使用して実行効率を向上させることができます。トランザクションプロセスが長い一部のシナリオでは、トランザクション実装の複雑さを大幅に軽減し、ピークとフィルをカットできます。谷。顧客によるウェルスマネジメントの購入などの典型的なシナリオは、預金口座の控除とウェルスマネジメントアカウントの入金の 2 つのステップに簡略化されます。「to」の異常な状態では、システムはトランザクションの一貫性を確保するために預金口座の控除を取り消す必要があります。TCC モードが選択された場合、預金口座引き落としと資産管理口座入力のロジック処理が連続して完了し、預金システムと資産管理システムはそれぞれロジック処理のステータスを記録する必要があります。両方が成功した後、統合送信が行われます。が開始されます。

データベースレベル:財務シナリオでは、データが失われないようにするための極めて高い要件があります。一方で、複数のコピーを同じ都市または異なる場所の複数のコンピュータルームに保存する必要があり、オフサイトの RPO は近いです。ゼロに。Paxos アルゴリズムは、メッセージパッシングに基づいて分散システムでデータの一貫性を実現するためのアルゴリズムであり、データの一貫性を中央で保証します。

コンピュータルームレベル:コンピュータルーム間のルーティング機能と、異常なトランザクションに対するコンピュータルーム間の回復機能。コンピューター室で障害が発生した場合、データベースは同じ都市/オフサイトのコピーに切り替えて RPO がゼロであることを保証し、アプリケーション層でのトランザクションルーティングの切り替えと連携してコンピューターを完成できる必要があります。ルームレベルの災害復旧スイッチと復元ビジネス。コンピュータ室の障害によりトランザクションプロセスの一部が中断された場合、分散トランザクションコンポーネントは自動的に回復し、中断されたトランザクションプロセスを再開して、事前に設定されたビジネスルールに従って順方向または逆方向の処理を完了する機能を備えている必要があります。。

要素 9: ユニット化、複数の場所、複数の活動

画像.png

デジタル金融サービスの急速な発展に伴い、従来の集中型の生産環境では需要を満たすことが困難になっています。現在の進化の方向性は、高い適時性と財務レベルのセキュリティ要件を満たすユニット化されたコンピュータルーム（以下、LDC）をベースとした「異場所マルチアクティブ」のユニット化構造です。

金融機関が一般的に採用している「2 か所に 3 つのセンター」アーキテクチャには、いくつかの典型的な欠陥があります。第 1 に、このアーキテクチャでは、同じ都市にある 2 つのセンターに、完全な切り替えに対応できる同等のコンピュータルーム容量が必要です。第 2 に、このアーキテクチャモデルでは、リモート災害が発生します。通常、復旧システムは「コールド」システムであり、実際にはビジネストラフィックを処理しないため、災害が発生したときに完全なビジネスを引き継ぐのは困難です。新しいデータセンターは一般に内モンゴルや貴州省など従来のデータセンターから遠く離れた地域に集中しており、新旧データセンターの容量比率が非常にアンバランスであるため、金融機関は「3センター2センター」の打破が求められている。従来のモデルは、N+1 の「マルチアクティブ」災害復旧ソリューションに進化し、障害復旧のシステム機能をさらに向上させます。

「リモートマルチアクティブアーキテクチャ」とは、LDC ユニットアーキテクチャに基づく拡張機能を指します。LDC ユニットはさまざまな地域の IDC に展開され、各 LDC ユニットは「ライブ」であり、回線上の実際のビジネストラフィックを実際に引き受けます。障害が発生した場合でも、LDC ユニット間の高速切り替えが可能です。リモートマルチアクティブユニットアーキテクチャは、次の 4 つの主要な問題を解決します。

ユニット間のやり取りを最小限に抑え、非同期を使用するため、オフサイト展開が可能です。システム全体の水平方向のスケーラビリティが大幅に向上し、同じ都市の IDC に依存することがなくなりました。

N+1 リモート災害復旧戦略を実現し、災害復旧コストを大幅に削減すると同時に、災害復旧施設を確実に利用できるようにします。

システム全体に単一点が存在しないため、全体の高可用性が大幅に向上し、同一都市内、異なる場所に複数台配備された場合でも、相互バックアップのための災害復旧設備として利用でき、運用保守による迅速な切り替えが可能です。管理および制御プラットフォーム。100% の継続的可用性を達成する機会があります。

このアーキテクチャの下では、サービスレベルでのトラフィックの入口と出口が、統合された制御可能およびルーティング可能な制御ポイントを形成し、システム全体の制御性が大幅に向上します。このアーキテクチャに基づいて、オンライン圧力測定、トラフィック制御、グレースケールリリースなど、これまで実装が困難であった運用保守管理および制御モードを非常に簡単に実装できるようになりました。

要素 10: 事業継続性とデジタルインテリジェンスの運用と保守

クラウドネイティブ環境では、サービスがダウンしている理由と、定義された SLO が実装されていない理由を解明するために、複数のコンテナ、複数の仮想マシン、複数のホスト、複数のアベイラビリティゾーン、さらには複数のリージョンに関する情報を関連付ける必要があります。障害などの影響を受けるユーザーや企業は、運用保守データとAIインテリジェンスに基づいた効率的なデジタルインテリジェントな運用保守管理を実現できます。

クラウドネイティブのデジタルインテリジェントな運用と保守には、主に次の 7 つの機能の側面が含まれます。

監視および検出機能: インジケーター、ログ、およびリンクの全方向の可観測性、サービス、ミドルウェア、およびインフラストラクチャーの包括的なカバレッジ、およびドリルダウン機能。

障害緊急対応機能: 異常の包括的な検出、迅速な位置特定および回復機能により、ビジネス SLA を保証します。

変更リスクの防止および制御機能: 「グレースケール可能、観察可能、ロールバック可能」の 3 つの軸を厳密に遵守した、包括的なビジネス変更管理および制御。

容量管理機能: ビジネスからインフラストラクチャに至るまで、フルリンク容量の正確な評価とリスクの早期特定を提供して、安定性とコストのバランスを実現します。

災害復旧管理機能: プラットフォームベースの災害復旧を手配でき、コンピュータ室の災害復旧、ユニット化された災害復旧およびその他のシナリオ、カバレッジ訓練、スイッチングおよび大画面機能をサポートします。

訓練および評価機能: カオスエンジニアリング、赤と青の攻撃と防御などを通じて、ビジネスリスク保証機能が検出およびテストされます。

資本安全保証機能：資本安全チェックルールに基づき、ビジネスシステムの資本の流れはオフライン、リアルタイム、ファイルなどの方法で監視されます。

クラウドネイティブのデジタルインテリジェントな運用保守には、主に次の 3 つの特徴があります。

効率化：運用保守業務のプラットフォーム化により、運用保守の効率を向上します。システム監視プラットフォーム、変更管理および制御プラットフォーム、動的リソース管理および制御プラットフォーム、スケジューリングセンター、登録センターなど。

セキュリティ：自動ビジネス検証基盤とビッグデータ運用ルールに基づき、システム運用の安定性と正確性を保証します。データ検証センター、依存関係管理・制御プラットフォーム、容量検出管理・制御プラットフォームなど。

インテリジェンス：ビッグデータ分析とルール計算に基づくインテリジェントな運用保守管理と制御。自動障害解析・処理システム、自動容量検出・拡張システムなど。

金融クラウドネイティブの新しい青写真を構築する

金融グレードのクラウドネイティブアプリケーションアーキテクチャ

『Architecture is the Future』という本では、分散アプリケーション設計の 14 の基本原則を提唱しています。これらは、最も重要なクラウドネイティブアプリケーションアーキテクチャの中核要素です。

N+1 設計: 開発するシステムには、障害が発生した場合に備えて少なくとも 1 つの冗長インスタンスがあることを確認してください。ロールバック設計: システムを以前にリリースされたバージョンにロールバックできることを確認します。

Switch Disable Design : 公開されている機能をオフにする機能。モニタリング設計: モニタリングは、実装完了後に追加するのではなく、設計段階で考慮する必要があります。

マルチアクティブデータセンターを設計する: 設計時にマルチアクティブデプロイメントを考慮し、データセンターソリューションに制限されないようにします。

非同期設計: 非同期は同時実行に適しており、絶対に必要な場合にのみ同期呼び出しを実行します。

ステートレスシステム: ステートレスシステムは、拡張と負荷分散にさらに役立ちます。ビジネスで本当に必要な場合にのみ状態を使用してください。

垂直アップグレードではなく水平スケーリング: より大規模で高速なシステムに依存しないでください。マイクロサービスの中心的な考え方は、すべての機能を 1 つのシステムに集中させることではなく、水平方向に拡張することです。必要に応じて、元のシステムをアップグレードするのではなく、要件を複数のシステムに分割します。

将来を見据えた設計: 次の段階のシステムのスケーラビリティの問題に影響を与える解決策を事前に検討し、パブリック共有サービスを継続的に改良してリファクタリングの回数を減らします。

中核ではない場合は購入する: それがあなたの得意分野ではなく、差別化された競争上の優位性を提供しない場合は、直接購入してください。データベースやクラウドサービスなどを購入できます。

小規模なビルド、小規模なリリース、迅速な試行錯誤: すべての研究開発では、システムを継続的に成長させるために、小規模なビルドと継続的な反復が必要です。失敗率はソリューションの変更数に直接関係しているため、小規模リリースでは失敗率が低くなります。

故障の分離: 故障を分離した設計を実現し、開回路保護を通じて故障の伝播と相互影響を回避します。複数のシステム間の相互影響を避けることは非常に重要です。

自動化: 「自動化は知恵の源です。」クラウドネイティブアーキテクチャでは、迅速な導入と自動化された管理が中核となります。設計は、アーキテクチャと設計を通じて可能な限り自動化するプロセスから始まります。機械ができるなら人間に頼らないでください。

実績のあるテクノロジーを使用する: 失敗率が高いテクノロジーは、決して使用すべきではありません。

金融グレードのクラウドネイティブプラットフォームアーキテクチャ

金融クラウドネイティブプラットフォームアーキテクチャ全体は、設計ドメイン、研究開発ドメイン、運用ドメイン、運用保守ドメイン、災害復旧ドメインの 5 つの主要ドメインに分類できます。

設計モード: ドメイン駆動設計や、マイクロサービスアーキテクチャシステムと自然に互換性のあるその他の設計手法を採用し、設計プロセス中にデータの一貫性やサービスの粒度などの問題に注意を払い、分散アーキテクチャ設計の設計原則と仕様を実装します。。

研究開発の状況: 研究開発担当者向けに、ワンストップの研究開発生産性ツールを提供し、分散テクノロジーの複雑さを防ぎ、研究開発担当者の経験と生産性を向上させます。広範なコンセンサスエンジニアリングテンプレートに到達して、組織の認知コストを削減します。

実行状態: アプリケーション指向の、分散アプリケーション運用のためのインフラストラクチャ。作成、展開、監視、構成変更を含むアプリケーションのライフサイクル全体をカバーし、さまざまな形式のアプリケーション対話とデータストレージをサポートします。最下層は、さまざまな形式のコンピューティング方法とそのスケジューリング方法をサポートします。

運用および保守の状態: 運用および保守担当者にとって、分散アーキテクチャ固有の複雑さを解決し、エンジニアリング手法を広く使用してシステム全体の可用性を確保します。

災害復旧状態: 災害を重視しており、ノードレベル、コンピュータルームレベル、都市レベルでの災害に耐える機能を提供します。

画像.png

金融グレードのクラウドネイティブデータアーキテクチャ

クラウドネイティブフレームワークには、高速配信、柔軟なスケーリング、標準化、自動化、分離などの固有の利点があり、新世代のデータテクノロジと継続的に統合されて、次の特性を持つクラウドネイティブデータアーキテクチャシステムを形成します。

1. 複数のコンピューティングモードのスケーラブルな融合

クラウドネイティブのデータアーキテクチャは、バッチ、ストリーム、インタラクティブ、マルチモード、グラフなどのさまざまなコンピューティングモードの統合を均一にサポートできます。たとえば、レイクとウェアハウスの統合、ストリームとバッチの統合、ストリーム機械学習などです。さまざまなコンピューティングシステムの緊密な統合が可能になり、相補的な機能とエコロジーにより、ユーザーは 1 つのシステムでより多くの種類の計算を完了でき、プラットフォームの運用効率が向上し、使用コストが削減されます。

2. マルチレイヤーインテリジェント分散ストレージレイヤー

ストレージとコンピューティングの分離は 2 ～ 3 年以内に標準となり、データプラットフォームはホスティングとクラウドネイティブの方向に発展するでしょう。ストレージ内の洗練された階層化は、パフォーマンスとコストのバランスをとるための重要な手段となっており、分散ストレージシステム上の多層ストレージ (ホットストレージ/標準ストレージ/コールドストレージなど) とストレージ使用率の組み合わせに基づいて、ストレージコストを大幅に削減できます。削減。AI は階層化されたアルゴリズムでより大きな役割を果たしますが、汎用プロセッサーでのエンコードと圧縮の最適化スペースが限られている場合、将来のブレークスルーと技術アップグレードは、ソフトウェアとハードウェアの統合の技術開発と応用に依存します。

3. 統合スケジューリングと柔軟なスケーリングのリソースプール管理

データレイクストレージとコンピューティングの分離が深まるにつれ、クラウドネイティブアーキテクチャに基づく統合コンテナ化リソーススケジューリングシステムの確立が、データレイクストレージとコンピューティングの分離の開発に必要なコンポーネントとなり、統合されたリソースプーリングとオフラインを提供します。ビッグデータとAIの統合アーキテクチャのためのストレージ混合部門の基本サポート、統合されたコンピューティングパワーリソースプールを通じてリソースの全体的な計画とスケジューリングを実現し、きめの細かいリソースの管理とスケジューリングを最適化し、オフラインで組み合わせることができますコンピューティングおよびその他のオンラインコンピューティングタスクを実行して、ピークとバレーの相補性の効果を実現し、サーバーリソースの使用率を向上させることができます。同時に、コンピューティングタスクのリソースをビジネスの優先順位に従って割り当てて、リソーススケジューリング中に競合が発生しないようにすることもできます。これにより、ビジネスのピーク期間中に、コンピューティング能力リソースを弾力的な拡張および収縮モードで呼び出して、リソースのコンピューティング能力を最大限に活用することができ、応答効率が向上します。

4. ビッグデータ SRE インテリジェントな運用保守機能

ビッグデータテクノロジーの多様性とデータプラットフォームアーキテクチャの複雑さは、ビッグデータプラットフォームの運用と保守に課題をもたらしています。新世代のビッグデータプラットフォームは、オンラインローリングアップグレードをサポートしてアップグレード時間を短縮し、さまざまな異種ワークロードプロセスの統合操作、ジョブライフサイクルの統合管理、タスクワークフローの統合スケジューリングを提供し、タスクの規模とパフォーマンスを保証します。ジョブログ、パフォーマンスインジケーター、リソース使用率、その他のデータを履歴記録やリアルタイムの負荷条件と組み合わせて、機械学習手法を使用してクエリプランニング、データモデル、リソース管理の自己適応、およびシステム異常を分析、検出、最適化します。継続的な最適化の観点から、大規模なデータプラットフォームのインテリジェントな運用および保守機能を形成します。

金融グレードのクラウドネイティブインフラストラクチャ

金融グレードのクラウドネイティブインフラストラクチャは、5 つの一般要件と 13 の管理要件を満たす必要があります。

(1) 5 つの一般要件は次のとおりです。

1 つは、成熟したクラウドプラットフォーム製品を採用して、IaaS と PaaS の統合クラウドコンピューティングプラットフォームを構築し、テナント側と運用保守側で完全なサービスカタログを実現し、ソフトウェア開発システムと本番運用保守とをシームレスに接続することです。システム;

2 つ目は、全社的な基本リソースの柔軟な供給を実現し、安全な生産の要件を満たす分散テクノロジーフレームワークに従って高可用性の災害復旧アーキテクチャを実現する全社的なビジネスシステムをサポートすることです。

3つ目は、情報技術アプリケーションの革新要件を完全に満たすことで、クラウドプラットフォームベースからソフトウェアサービスに至るまで、フルリンク情報技術アプリケーションを革新して実行する能力を備えていると同時に、分散アプリケーションの高性能で安定した動作を保証します。 ;

第 4 に、大規模なアプリケーションをクラウドに提供する基盤があり、完全なアプリケーションフレームワークを提供し、アプリケーションシステムに対して安定的、継続的、高パフォーマンスのサポートを提供します。

第 5 に、クラウドプラットフォーム製品には成熟したエコシステムがあり、基本的に業界のパブリッククラウドテクノロジーの発展と歩調を合わせ、最新のオープンソーステクノロジーの進化に適応します。

(2) 13 の管理能力要件は次のとおりです。

統合リソース管理: 統一された物理リソースタイプとアーキテクチャを使用して、サーバー、スイッチ、オペレーティングシステムなどの基本的なハードウェアリソースの統合管理を実現します。クラウド管理プラットフォームは、統合管理方法 (コンソール、コンソール、 API など）、ストレージ、ネットワークなどのクラウドリソースを管理し、開発や運用保守の複雑さを軽減します。

統合データ管理: 都市内のアクティブ/アクティブおよびリモートのマルチアクティブ構造において、データの保存、移行、同期などを通じて分散クラウドノードのデータの一貫性が保証され、ビジネスに合わせて統合された災害復旧および連携スイッチング機能が提供されます。継続性要件を最大限に満たします。たとえば、統合ミラーリングソリューション、オブジェクトストレージの災害復旧、データベースのリージョン間のバックアップと同期などを提供します。

統合サービス管理: 2 か所で 3 つのセントラルノードをサポートし、サービスの展開と更新のための統合コントロールプレーンなど、統合 API、SDK、コンソールなどを通じてクラウドサービスを管理します。これにより、クラウドサービス管理の複雑さが大幅に軽減され、効率が向上します。クラウド利用のこと。

一元的な運用保守管理：クラウド管理により、3センターの異なるノードを2か所で同じ運用保守システムで管理することができ、一貫した運用・監視・信頼性SLAなどのサービスを提供し、運用保守管理者の負担を軽減します。運用と保守の効率が向上し、システム障害が大幅に減少し、ダウンタイムが短縮されます。

統合セキュリティ管理: プラットフォーム側のセキュリティは、物理インフラストラクチャ、ネットワークセキュリティ、データプレーン/コントロールプレーンの分離などを通じて実現される一方で、セキュリティサービスはホストセキュリティ、アクセス制御、ファイアウォール、統合的なセキュリティを確保するための状況認識など。

統合リソーススケジューリング：クラウド管理により、2箇所3拠点の計算能力リソースの統合スケジューリングを実現し、さまざまなスケジューリング戦略をサポートします。ロケーションベースのスケジューリングは遅延や帯域幅に敏感なサービス (モバイルバンキングのオーディオおよびビデオアプリケーションなど) に対応し、コンピューティングベースのスケジューリングは AI、ビッグデータ、その他の大規模コンピューティングサービス (タイダルスケジューリング、混合部門、その他のシナリオなど) に対応します。 ; ベースのワークロードスケジューリングは、多次元かつ異種シナリオ (金融パニック買い、ポイント交換、ダブル 11 およびその他のアプリケーションシナリオなど) を満たします。

統合監視管理: クラウド上およびクラウド外のさまざまな種類の監視指標へのアクセスと統合表示を完了し、クラウド上およびクラウド外の分散リンク追跡機能を完了し、ビジネス監視からレイヤーごとの監視を実現します。アプリケーションサービスの監視、およびリソースの監視ドリルダウン分析と多次元分析により、障害位置と分析機能を向上させます。統合アラームセンターのドッキングと最適化を通じて、動的しきい値を完成させ、全体的なビジネスイベント認識機能、迅速な測位機能、およびインテリジェントな分析と意思決定機能。

複数のコンピューティング能力のサポート: クラウドリソースプールは、CPU や GPU などの複数のコンピューティング能力と互換性があり、人工知能、深層学習、科学技術コンピューティングなどの複数分野のシナリオにおける新しい金融テクノロジーアプリケーション製品に効率的なクラウドコンピューティング能力サービスを提供します。。

フルスタックの情報技術アプリケーションの革新をサポートする: マルチ製品サービス機能と互換性のあるシステムを通じて、ワンクラウドマルチコア、フルスタックの XC クラウドプラットフォームサービス機能をサポートし、情報技術アプリケーションの革新戦略の実装を促進します。

洗練された管理のサポート: プラットフォームの計測および課金機能と、業界のさまざまなシステムとの接続を通じて、コンピューティング、ストレージ、ネットワーク、セキュリティ、およびその他のリソースの計測および課金機能が実現されます。ITコストの高度な管理を段階的に実現し、ビジネスIT投資とビジネス成果の測定と評価を実現し、コストと効率のバランスを実現し、ITリソースの効率的な使用を実現します。

ベアメタル管理のサポート: ベアメタル配信プロセスの自動化と、サーバーラック、自動インストール、システム設定、およびソフトウェアオーケストレーションによるバッチ処理に対応し、配信効率を向上させ、手動作業負荷を軽減します。ベアメタルの統合管理要件を満たし、ベアメタルの統合監視と管理を実現します。金属製の警報器。

サービス品質のサポート: インフラストラクチャ管理プラットフォームの構築は、セルフサービス機能の向上を通じて、効率的かつ安定した運用と洗練された管理を提供して、より良いサービスを提供することができ、プラットフォームのデータ収集と分析によると、効果的に改善されます。管理の方向性や内容を適切に調整し、サービス品質を効果的に向上させることができます。

サポートアーキテクチャの開発：業界をリードする独自のクラウドアーキテクチャを採用し、パブリッククラウドと同じソースでクラウドプラットフォームを構築し、金融業界の災害復旧要件を満たし、一連のシステムを通じてすべての製品をサポートし、将来のフルスタッククラウドプラットフォームの能力構築に対応するため、有機的で統一されたアーキテクチャ設計を通じて、銀行全体の統合されたオンラインおよびオフラインの運用保守システムを構築します。

05 財務レベルのクラウドネイティブ実装パス

財務レベルのクラウドネイティブ機能評価

「未来に投資する最良の方法は、現在を改善することです。」

金融レベルのクラウドネイティブは、デジタル時代の恩恵を大きく受けていますクラウドネイティブは、クラウドの設計思想を完全に継承しています今後、より多くのアプリケーションがクラウドをベースに開発されるでしょう。クラウドアーキテクチャに適しており、クラウドコンピューティングもクラウドネイティブアプリケーションに適しており、リソース分離メカニズム、分散展開、高可用性アーキテクチャなど、より優れた基本サポートを提供し、新しいアーキテクチャとテクノロジを通じて、アプリケーションシステムはより堅牢になります。クラウドネイティブアプリケーションはクラウドのメリットを最大限に活かしたアプリケーションと言えます。

IaaS/PaaS 統合クラウドプラットフォームに基づいて、銀行は分散マイクロサービスフレームワーク、クラウドミドルウェア、コンテナ、DevOps およびその他のクラウドネイティブテクノロジを使用して、水平拡張、第 2 レベルのスケーリング、インテリジェントな運用とサービスを提供できるクラウドプラットフォームを構築します。 PaaS レベルのクラウドプラットフォームは、従来のアーキテクチャからインターネットアーキテクチャへの銀行の進化を促進します。このプラットフォームは、コンテナーに基づいてリソースをデプロイ、実行、スケジュールし、コンテナーの軽量機能を利用して、サービスの数が急増したときにアプリケーションのデプロイメントと運用のリソースをさらに節約し、変動するビジネストラフィックに簡単に対処できます。同時に、アプリケーションのイメージ配信形式により「1 つのビルド、複数のデプロイメント」が実現され、従来のデプロイメントプロセスによってもたらされる運用の複雑さと運用上のリスクが回避されます。このプラットフォームにより、アプリケーションの配信サイクルが 80% 短縮され、ビジネスニーズへの応答速度が 50% 向上しました。

しかし、金融機関がクラウドネイティブ技術を大量に購入・導入し始めると、クラウドネイティブ技術の製品システムが複雑すぎる、オープンソースのエコシステムにガバナンスが欠如している、製品間の互換性や適応性が低いなど多くの問題が発生しました。難しい。部分的な技術的特性が金融機関の選択に大きな支障をきたし、高額な試行錯誤コストが発生することがよくあります。

「全体を放棄して局部の細部に注目するのはフーリガンだ。」

テクノロジーがプラットフォームベースになればなるほど、全体的な観点から検討する必要があります。したがって、金融機関がクラウドネイティブ技術変革の開発段階に位置し、欠点を比較および分析できるように、業界の特性を組み合わせて金融機関に機能参照モデルを提供する一連の統一標準が緊急に必要とされています。クラウドネイティブのキャパシティビルディングの構築、および将来のテクノロジーと機能の策定の方向性。当社は、いくつかの金融業界の実践を組み合わせて、クラウドネイティブテクノロジーを導入するための完全な技術能力フレームワークと 9 次元の成熟度評価モデルを金融機関に提供します。これらのモデルは、次の指標を参照して開発できます。

マイクロサービスアーキテクチャレベル、アプリケーションのクラウド化レベル、可観測性、高可用性管理、構成自動化、DevOps、クラウドプラットフォーム機能、クラウドネイティブセキュリティ、コンテナーおよび K8s 機能。

画像.png

財務レベルのクラウドネイティブの進化パス

優れたアーキテクチャは進化から生まれます。整合性と構築仕様を確保するには、完全なアーキテクチャ計画が必要ですが、全体的な安定性と制御性を確保するには、アーキテクチャが進化し続ける必要もあります。そのため、2 つのクラウドネイティブアーキテクチャをまとめました。進化経路は参考として使用します。

参照パス 1: グローバルなマクロスケール (上から下) を見て、クラウドネイティブの機能評価に基づいて技術的な欠点と進化の道筋を探します。次の例は、クラウドネイティブアーキテクチャの 3 段階の進化パスです。これは、金融機関がアプリケーションアーキテクチャの単一マイクロサービスからユニット化への変換を段階的に実現し、同じ都市内のダブルアクティブからマルチアクティブへの移行を実現するのに役立ちます。別の場所。ビジネス開発と厳しいシナリオテストに対応するために、最もバランスのとれたアーキテクチャ開発パスを模索します。

参照パス 2: 問題から開始して (下から上へ)、アーキテクチャの進化の目的は、特定のタイプの問題を解決することである必要があります。クラウドネイティブアーキテクチャ全体の進化を設計するために、「問題」の観点から始めたい場合があります。次の例は、技術的な問題を解決することでクラウドネイティブアーキテクチャを継続的に進化させる実践です。

ステップ 1: アプリケーションアーキテクチャ全体に「より優れた基盤サポート」を持たせるために、クラウドプラットフォーム上でアプリケーションアーキテクチャを実行します。

ステップ 2: モノリシックアーキテクチャの「複雑さの問題」を解決するために、マイクロサービスアーキテクチャを使用する

ステップ3：マイクロサービス間の「通信例外問題」を解決するために、ガバナンスフレームワーク＋監視を活用する

ステップ 4: マイクロサービスアーキテクチャ下で多数のアプリケーションの「デプロイメント問題」を解決するには、コンテナーを使用します

ステップ 5: コンテナーの「オーケストレーションとスケジューリングの問題」を解決するには、Kubernetes を使用します

ステップ 6: マイクロサービスフレームワークの「侵入的な問題」を解決するには、サービスメッシュを使用します

06 エピローグ

この記事では、一般化されたクラウドネイティブ技術概念と財務レベルの技術標準をマッピングして組み合わせ、高度なクラウドネイティブテクノロジの概念をオールラウンドなテクノロジに拡張することを目的として、財務レベルのクラウドネイティブテクノロジの青写真と 10 の要素を定義します。このスタックは、IT アプリケーションの革新に向けた金融業界のアーキテクチャ計画のためのまったく新しいリファレンスアーキテクチャを提案しています。金融レベルのアーキテクチャの革新を加速するために、一緒に探索と実践を続けていきましょう。

著者について：

Alibaba Cloud Intelligent New Finance & Internet Industry の社長、China Finance 40 Forum のエグゼクティブディレクターである Liu Weiguang 氏は、清華大学電子工学部を卒業しています。Alibaba Cloud に入社する前は、Ant Financial で金融テクノロジーのビジネス推進とエコロジー構築、および Ant Blockchain のビジネス開発を担当しており、長年エンタープライズソフトウェア市場に深く関与しており、かつて Pivotal Software Greater を設立しました。中国支社、エンタープライズレベルの構築これは、ビッグデータおよびエンタープライズレベルのクラウドコンピューティング PaaS プラットフォームの市場では初です。Pivotal China Software Company を設立する前は、Liu Weiguang は EMC Greater China のデータコンピューティング部門のゼネラルマネージャーを務め、長年 Oracle China に勤務し、かつては Exadata Greater China の製品部門を設立し、ディレクターを務めていました。分割。