6年間の技術革新：アリババのグローバル化とコンプライアンスへの挑戦と探求

グローバル化されたテクノロジーは、グローバル化されたビジネスに根ざしています。 5段階の進化を経て、アリババグループ内で比較的独立した技術システムへと徐々に発展してきました。この記事では、まずグローバル インフラストラクチャ層の課題と技術的な実践に焦点を当てます。

1. 事業展開の経緯

1.1 事業背景

1999年のアリババ設立以来、アリババグループのグローバル化が始まりました。同社の最初の事業部門である Alibaba.com は、グローバルなビジネスです。その後、2009年に会社設​​立10周年を迎え、AliExpressベータ版がリリースされ、アリババはTO C時代へとグローバル化しました。 2016年後半には、「今後20年間で、アリババグループは20億人の消費者にサービスを提供し、1億人の雇用を創出し、1000万の中小企業の利益向上を支援する」と提案された。また、同社はラザダ（東南アジア6カ国）、ダラズ（南アジア5カ国）、トレンディオール（トルコ）など海外の電子商取引企業を相次いで買収し、アリババグループの3大戦略（消費、クラウドコンピューティング、グローバル化）の一つである大航海時代を正式に切り開いた。

アリババが2016年にグローバル化関連の事業買収を完了した後、アリババグループのグローバル事業レイアウトは以下のように最初に形成されました。

1. 上の図は、アリババのグローバルビジネスが現在注力している国・地域を示しています。主要な事業国・地域はアジア、ヨーロッパ、アメリカの3大陸にまたがっていることがわかります。ビジネス上の要求の違いにより、技術的なソリューションにも明らかな違いが生じます。エンドツーエンドの技術ソリューションですべての国/地域を完全にサポートすることは不可能ですが、差別化された階層的な組み合わせ/カスタマイズは実際に実現可能であることが証明されており、当社の[システム標準化]の要件を提示しています。

2. 大規模な伐採の時代は終わった。オペレーションの高度化の時代においては、ユーザーエクスペリエンス/コンプライアンス監視への対応や、ユーザーに近い技術ソリューションの展開がローカルエクスペリエンス構築の基盤となり、 [システムの軽量化]が求められます。

3. デジタル時代の深化に伴い、デジタル化/インテリジェンスは人間社会のあらゆる側面にますます影響を及ぼし、変化をもたらしています。グローバル企業として、当社のユーザーが先進国か発展途上国かに関係なく、デジタル/インテリジェンスによってユーザーの生活をより良くすることが常に当社の目標であり、これは当社の[システムインテリジェンス]に対する要件でもあります。

1.2 グローバル技術システムの反復プロセス

 上記のビジネスニーズを満たすために、グローバルテクノロジーシステムはグループテクノロジーシステムから正式にインキュベートされ、5段階の進化を経て、徐々にアリババグループ内で比較的独立したテクノロジーシステムへと発展しました。

1. 第一段階では、国内のTaobao、Tmall、Sohuなどのチームのシステムをベースに、6か月でLazadaをサポートする新しい電子商取引コアシステム一式を構築しました。

2. 第2フェーズでは、eコマースコアシステムをカスタマイズし、Darazを完全にサポートする新しいeコマースシステムを構築しました。

3. 第3段階では、この電子商取引コアとAEシステムが深く統合され、Taobao、Tmallなどのチームの優れたシステムソリューションが導入され、ローカルおよびクロスボーダー取引モデルの両方をサポートできる国際化されたミドルプラットフォームのプロトタイプが形成されました。

4. 第4段階では、上記の統合バージョンに基づいて、Lazada、Daraz、Tmall Taobao Overseasが合併し、国際ミドルオフィステクノロジー部門の4in1アクションが完成し、最終的に1つのミドルオフィスがNサイトをサポートする新しいグローバルアーキテクチャが形成されました。

5. 第 5 フェーズでは、国際化されたミドル プラットフォームのオープン ソース戦略の実装が開始されました。ミドルプラットフォームのフルリンクオープンソース化が完了するまでに2021年11月まで1年以上かかり、グローバルビジネスとミドルプラットフォームのクローズドループ反復状況が形成されました。

6. フェーズ 6、未来はここにあります。お楽しみに。

次に、一連の記事を使用して、グローバル テクノロジー システムの課題と対応について説明します。この記事では、まずグローバル インフラストラクチャ層の課題と技術的な実践について説明します。

II.世界のインフラレベルで直面する課題

買い手と売り手にサービスを提供する電子商取引ウェブサイトとウェブサイト運営の観点からは、ユーザーがウェブサイトにアクセスするためのパフォーマンスや可用性などの基本的な要件を満たすことに加えて、グローバル展開、法令遵守、データ分離などの新しい要件がグローバル化の文脈で追加されています。これらの要件により、インフラストラクチャの構築に新たな課題が生じています。以下に例をいくつか示します。

• グローバル展開: ユーザー エクスペリエンスや規制遵守を考慮する場合でも、インフラストラクチャのグローバル展開は、グローバル ビジネスのために構築する必要がある基本的な機能です。グローバルに展開されたインフラストラクチャは、グローバル テクノロジー システムの多くの特定のアーキテクチャ形式も直接決定します。同時に、グローバルに展開されるインフラ自体の構築と維持も大きな課題です。
• パフォーマンス: ここでのパフォーマンスは、ユーザー要求の処理の遅延を指します。ユーザーがリクエストを開始してから応答を受信するまでの遅延が短いほど、パフォーマンスは向上します。しかし、グローバル インターネット サービスは、物理的な距離が長くなるという、遅延に関する当然の課題に直面しています。データセンターは米国にあり、ユーザーはオーストラリアにいる可能性があります。私たちのテストデータによると、アメリカのインターネット サービスを要求するアメリカのユーザーの一般的なネットワーク RTT は 10 ミリ秒以内であるのに対し、米国西部のデータ センターを要求するロシアのユーザーの RTT は 150 ミリ秒から 300 ミリ秒の範囲です。これにより、ユーザーの全画面読み込み時間が 1 秒長くなり、1 秒でコンバージョン率が低下したり、ユーザーが離脱したりする可能性があります。
• 可用性: 世界中のユーザーにサービスを提供するにはコストの課題もあり、それがシステムの可用性にも課題をもたらします。ローカルな観点からのみ可用性を確保する場合、高可用性を確保するために各ローカルエリアに 2 つのコンピュータ ルームを構築する必要があります。しかし、これでは他の地域のコンピュータ室の未使用リソースを活用することができず、全体的なコストが非常に高くなります。当社の 24 時間 365 日の可用性要件は、世界的な視点に基づいています。したがって、グローバルな災害復旧を実現できれば、許容可能なコスト範囲内でユーザーの可用性をより適切にバランスさせることができます。
• データの一貫性: データの一貫性の課題とは、データが世界中の複数の場所にいるユーザーによって共有され、複数の場所にいるユーザーがデータを読み書きするときに、データの一貫性をどのように確保するかを指します。たとえば、グローバルな売買シナリオでは、購入者はローカル データ センターで注文を作成し、販売者はローカル データ センターで注文を管理します。同じ注文で、購入者と販売者が別のデータ センターにいる場合、複数の場所で読み取りと書き込みの一貫性を確保するにはどうすればよいでしょうか。世界中のデータ センターが相互に災害復旧を実行する場合、複数の場所で読み取りと書き込みが行われます。データの一貫性を確保するにはどうすればよいですか?

さらに、近年では、グローバル展開アーキテクチャのアップグレードに伴い、既存のデータセンターが徐々にクラウドデータセンターに移行しています。新規ビジネスの拡大や準拠した展開アーキテクチャはすべて、クラウドをインフラストラクチャとして使用します。グローバルビジネスはすでにクラウド上で実行されており、クラウドはより豊富で柔軟性が高く、無制限のインフラストラクチャ機能も提供します。クラウド インフラストラクチャ上に、ユーザー エクスペリエンス、可用性、データ一貫性の問題を解決するために、海外での使用に適したマルチモード展開と災害復旧アーキテクチャを実装しました。コンプライアンス アーキテクチャを定義することで、さまざまな国の法律のビジネス コンプライアンス要件を完全に満たしています。同時に、クラウドネイティブアーキテクチャの概念を通じて、クラウド製品を使用してソフトウェア開発プロセスを再構築する方法を定義しました。

以下では、グローバル化が直面する課題を組み合わせ、海外展開と災害復旧アーキテクチャ、データコンプライアンス、クラウドネイティブアーキテクチャ実践の3つの観点から、グローバル化とコンプライアンスの実践について詳しく説明します。

3. クラウドベースの海外導入事例

3.1 海外派遣と災害復旧の実践

3.1.1 Alibaba Cloud インフラストラクチャ

• IAAS レイヤー: Alibaba Cloud のグローバルに一貫したインフラストラクチャを活用し、世界中の 6 つの主要リージョン、13 の物理コンピュータ ルーム、17 の論理コンピュータ ルーム (AZ) を含む海外デジタル ビジネス インフラストラクチャを構築しました。弾力性のあるリソース機能を享受しながら、複数の国/地域にデータセンターを展開して維持する必要がありません。
• PAAS レイヤー: Alibaba Cloud のさまざまなミドルウェア/クラウド製品を活用してグローバル展開することで、グローバル化の一連の技術的課題を徹底的に解決します。

3.1.2 グローバル展開アーキテクチャ

企業間および国境を越えたビジネス モデルに基づいて、リモートとローカルの 2 つの展開アーキテクチャがあります。同時に、地域データセンターでは、複数の国や複数のサイトにサービスを展開する必要があることが多く、マルチテナント アーキテクチャが必要になります。以下では、リモート マルチアクティブ、ローカル デュアルアクティブ、単一リージョン マルチテナントにおける当社の実践について詳しく紹介します。

地域化されたマルチサイトアクティブアクティブ

AliExpress の中心的な要件は、電子商取引におけるグローバルな売買です。さらに、ユーザーの近くのアクセスに対するネットワーク遅延と災害復旧シナリオも考慮する必要があります。この複数地域展開シナリオとコア要件の制約の下では、地域化された展開の全体的な原則は非常に明確です。つまり、Amazon や Lazada のローカル サイト モデルとは異なり、異なるリージョン間でデータの一貫性を保証する必要があります。たとえば、異なる地域の買い手と売り手が取引を行う場合、共有データの一貫性を保証する必要があります。異なる場所で災害復旧を行う場合、ユーザー領域を移行した後、同じユーザーに提供されるサービスの一貫性も保証する必要があります。

• ネットワーク層:ユーザーは DNS に基づいてコンピュータ ルーム内の最も近い IDC に解決し、コンピュータ ルームの統合アクセス層に到達します。
• アクセス層:ユーザーの所属に関する強力な一貫性修正を実行するには、統合ルーティング層をブリッジする必要があります。つまり、ルーティング サービスはアクセス層で呼び出され、ユーザーの所属を照会し、コンピューター ルーム間のスケジューリングを実装して、ユーザーがコンピューター ルーム間を移動するという目的を達成します。
• サービス層:支払いや取引などの一貫性が強いデータの場合、統合ルーティング層でユーザー属性を保証する必要があります。つまり、統合ルーティング レイヤーでルーティング エラーが発生した場合、MSE レイヤーは、ユーザーが使用するために正しく属しているコンピューター ルームにコンピューター ルーム間でサービスを呼び出す必要もあります。同時に、共有データの一貫性の問題に対処するために、集中的な読み取りと書き込みのためのコンピュータルーム間のサービス呼び出し機能を拡張する必要があります。つまり、MSE レイヤーは、ユーザー属性または中央コンピュータ ルームの消費に基づいて、コンピュータ ルーム間の呼び出し機能を実装する必要があります。
• データベース層:プラグインを拡張することで書き込み禁止機能を実装しました。これは、ユーザー所属エラーのバックアップや強力なデータ一貫性としても機能します。つまり、ユーザーの所属エリアが実際の呼び出しエリアと一致していない場合、異なるエリア間でのデータのダーティライトを回避するために書き込み保護を無効にします。
• データ同期層:中央コンピュータ室と地域コンピュータ室の間でデータが双方向に同期され、さまざまな場所での災害復旧のためのデータの一貫性が確保され、ユーザー地域が変更された後のデータ損失が回避されます。

同じ都市でデュアルアクティブ

AliExpress のグローバルな売買ビジネスとは異なり、Lazada/Daraz のビジネスは東南アジアに重点を置いており、Local to Local モデルを採用しているため、ローカル ツー ローカルのアクティブ/アクティブ展開アーキテクチャを採用しています。

名前が示すように、同一都市でのアクティブ-アクティブ災害復旧の構築は、都市内の 2 つの IDC での災害復旧の構築を伴います。目標は、1 つの IDC がビジネスの可用性を確保できない場合に、別の IDC にすばやく切り替えることです。デュアルユニット展開アーキテクチャを採用し、ユニット化を使用してユニット内のトラフィックの自己閉ループ分離を実現します。データベースは、高可用性を確保するために RDS 3 ノード エンタープライズ エディションを使用します。障害による災害復旧が検出されると、入力トラフィック、統合アクセス レイヤーなどを別の IDC にすばやく切り替えて、ビジネスの可用性を確保できます。

マルチテナントアーキテクチャ

グローバル化されたビジネスの基本的な特徴は、多地域、多通貨、多言語です。ビジネス戦略の洗練された実行を実現するために、これらの次元に基づいてビジネス運営単位を決定することができます。各業務単位間の分離と業務領域のメタデータの標準化を実現するためには、業務領域に対するテナントの概念を提案する必要がある。技術アーキテクチャ レベルでは、複数のリージョンに統一されたテナント アーキテクチャ標準を提供する必要があります。各事業部門の業務量や業務形態はある程度異なるため、展開アーキテクチャではテナントの物理的な分離と論理的な分離を実現できます。技術アーキテクチャでは、構成の分離、データの分離、トラフィックの分離機能を提供する必要があり、テナント定義では統合されたテナント モデルを維持する必要があります。統一されたテナントに基づいてビジネスユニットと技術アーキテクチャ間のマッピング関係が確立されるため、ビジネスユニット次元での開発、テスト、展開、運用保守などの研究開発活動をテナントに基づいて実装でき、研究開発活動中のビジネスユニット間の結合が低減され、ビジネスユニットの独立性が強化されます。

マルチテナント アーキテクチャの設計コンセプトに基づいて、実行状態内の動作原理は次のコア部分に分割されます。

• [トラフィックの色分け] クライアント上のリクエストを識別し、どのテナントのトラフィックがどこから来ているかを判断し、トラフィックの色分けを行います。
• [正確な位置選択] トラフィックの色分けとアクセスゲートウェイ層のサービスルーティング機能に基づいて、テナントが配置されている物理クラスターが正確に選択されます。
• [リンク透過伝送] クラスター内の単一のサービスインスタンス内では、テナントラベルの透過伝送問題、および上流と下流との同期および非同期のやり取り中のテナント情報の透過伝送を解決する必要があります。
• [リソースの分離] 内部ビジネス ロジックの実行中、リソースに対するあらゆる操作では、構成、データ、トラフィックなどの分離の問題を考慮する必要があります。

3.1.3 グローバル災害復旧ソリューション

リージョン レベルおよびネットワークの使用不可:コンピュータ ルーム レベルが使用不可、外部ネットワークの入口が物理的なコンピュータ ルームに到達できない、または物理的なコンピュータ ルームが相互に通信できない。

サービス レベルが利用できません:外部/イントラネット接続は正常ですが、サービスは利用できません。

データ層が利用できません: DB/キャッシュが利用できません。

ネットワーク災害復旧：ユーザーの第 1 ホップ ネットワーク ルーティング (コミュニティ ネットワークに異常がある場合、基本的に操作の余地はありません) に加えて、次の 2->N ホップでは、ネットワーク オペレータ スイッチング機能 (複数の CDN ベンダー スイッチング)、データ センター リンク スイッチング機能 (リージョン レベル スイッチング)、データ センター エントランス オペレータ スイッチング機能 (IDC ネットワーク チーム スイッチング) などの手段を構築して、災害復旧を実行しようとします。

アクセス層の災害復旧:トラフィックが Alibaba Cloud データセンターに到達し、内部ゲートウェイ ルーティング層に入ると、ユーザーの粒度や API の粒度などの複数の次元に基づいてリアルタイムのトラフィック修正が実行され、数秒以内に有効になります。アクセス層の災害復旧は、ネットワークやゲートウェイ製品に異常がない場合、日常的に使用され、最も多く訓練される災害復旧ソリューションです。

サービス層の災害復旧:在庫やマーケティングなどの単一リージョン控除サービスなどの強力な中央サービスの場合、災害復旧機能を構築することも必要です。

データ層の災害復旧:マルチアクティブ アーキテクチャの場合、データに単一のマスターがあることを確認しながら、災害復旧プロセス中にデータがダーティにならないようにします。コンプライアンス シナリオでは、一部のリージョンには機密データが存在しないことを考慮し、限定されたシナリオでコンプライアンスに準拠した災害復旧機能を実装します。

3.2 グローバルデータコンプライアンスの実践

3.2.1 グローバルコンプライアンスの概要

インターネット電子商取引プラットフォームの場合、全体的なリスクとコンプライアンスの領域は非常に広範囲にわたります。リスク領域とコンプライアンス領域の違いとそれぞれの内容は、上図に大まかに示されています。コンプライアンスには通常、データ コンプライアンス、知的財産権侵害、製品コンテンツのセキュリティ、インタラクティブ コンテンツのセキュリティ、技術輸出コンプライアンス、APP コンプライアンスなどの内容が含まれます。これらの内容は、現在の規制上の注目の的でもあります。データコンプライアンスを除き、その他のコンプライアンスの問題は、主に個々のビジネスシナリオに集中しています。たとえば、知的財産権侵害や製品コンテンツのセキュリティは主に製品領域に存在し、インタラクティブ コンテンツのセキュリティは主に買い手と売り手のコミュニケーションやライブ ブロードキャストなどのシナリオに存在します。

コンプライアンス作業の焦点は、eコマース プラットフォームのほぼすべてのシナリオに適用されるデータ コンプライアンスです。データ処理に関するあらゆる問題は、データコンプライアンスに関連している可能性があります。同時に、データコンプライアンスは、規制に対する敏感さから、プラットフォームにとってビジネス上のサーキットブレーカーリスクとなります。

3.2.2 データコンプライアンス要件と展開アーキテクチャ

個人情報の閉鎖範囲に応じて、越境業務は一般的に地域化アーキテクチャ計画、プライバシーデータ閉鎖計画、個人情報閉鎖計画の3つのタイプに分けられます。この事業では、独立ユニットクローズドソリューションを採用しています。

3.2.3 ローカルストレージソリューション

データコンプライアンスの側面では、多くの場合、データのローカルストレージ（国外への持ち出しや将来の参照用にローカルに保持することは許可されません）などの直接的な規制要求に直面します。機密性の高いビジネスでは、さらに厳しい規制要件が課せられる場合があり、パブリック クラウドの使用が禁止されたり、高度なセキュリティと独立したパブリック クラウド リソースが要求されることがあります。これを実現するには、準拠した Web サイト構築のニーズを満たす独自の完全なインフラストラクチャを構築する能力が必要です。

3.3 クラウドネイティブアプリケーションアーキテクチャ

クラウド ネイティブ テクノロジーにより、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。これらの技術により、フォールト トレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブ テクノロジーにより、エンジニアはシステムに頻繁かつ予測可能な重大な変更を加えることが容易になります。

グローバルな技術研究開発においては、クラウド上での業務運営に加え、自社の業務研究開発の課題や問題点からさらに出発し、クラウドネイティブ技術と関連するアーキテクチャ概念を組み合わせて、業務研究開発や運用保守自体の効率化の問題を解決することも必要です。

3.3.1 従来のアプリケーションアーキテクチャが直面する課題

図 従来のアプリケーション アーキテクチャ モデル

上の図は、従来のアプリケーション アーキテクチャにおけるソフトウェア配信プロセスを示しています。このプロセス全体を通じて、アプリケーションは、R&D 状態ではオブジェクト、配信状態ではキャリア、実行状態ではコンテナの役割を果たします。ソフトウェアに期待されるすべての機能は、アプリケーションのソース コード内で宣言的に参照され、全体的なソフトウェア配信は統合ビルドを通じて完了します。このプロセスは、ソフトウェアのリッチ アプリケーション配信と呼ぶことができます。

グローバル プラットフォームは、もともと実際のビジネス システム (トランザクション、マーケティング、支払いなど) から進化したものであるため、プラットフォームも例外ではなく、従来のアプリケーション アーキテクチャ モデルを継承しています。しかし、プラットフォーム自体が徐々に進化し、プラットフォーム上でのビジネスの多様性が進むにつれて、組織構造とビジネス構造の両方に大きな影響を与えてきました。主に次の3つの課題に直面しています。

持続不可能なアプリケーション アーキテクチャ:リッチ アプリケーション配信モデルでは、ソフトウェア制作プロセスには常に 1 つのポイント、つまりアプリケーションが存在します。アプリケーションがサポートするコンテンツがますます大規模かつ複雑になると、R＆Dの効率に影響を与える重要なポイントとなり、国際的なプラットフォームアーキテクチャ全体の持続可能性に影響を与える最大の課題になります。

R&D 提供の不確実性:グローバル プラットフォームとビジネス レイヤーの R&D モデルは、目的と変更のリズムに一貫性がありません。両者の違いを解決するために、アプリケーション自体が徐々に肥大化、腐食し、日々の研究開発の反復に大きな不確実性と予測不可能性をもたらすことになります。

運用および保守機能の標準の欠如:アプリケーションの複雑さが増すにつれて、対応する運用および保守機能もそれに応じて増加します。現在提唱されているDevOpsの概念も、多くの関連製品やツールを生み出していますが、これらの製品やツールの標準は統一されておらず、統一された製品の入り口がないために断片化と複雑化という現象につながり、運用と保守の効率と理解コストが継続的に増加しています。

上記の課題に対して、クラウド ネイティブ テクノロジーは新しいソリューションを提供します。

コンテナ オーケストレーション テクノロジー:クラウド ネイティブのコンテナ オーケストレーション テクノロジーにより、従来のソフトウェア配信プロセスがコンテナ オーケストレーションを組み合わせた配信へと進化し、単一のアプリケーション配信が複数のモジュールに分割されて柔軟なオーケストレーションと配信が可能になり、グローバル アプリケーション配信システムの進化が促進されます。

成果物のミラーリング:アプリケーションはもはや R&D の唯一の対象ではありません。代わりに、ミラー化された R&D システムが作成されます。ミラーの不変性は、配信されるコンテンツの確実性を確保し、プラットフォームの機能をミラーリングし、独立した安定した研究開発システムを持つために使用されます。

統合された O&M 標準:クラウド ネイティブの IaC/OAM などの GitOps コンセプトを活用して、統合モデルを通じてクラウド ネイティブ アプリケーションの O&M 標準を統合および定義します。そして、ビジネス組織の SRE を再定義し、アプリケーションの運用および保守機能とリソース使用状況の現状を統一された視点から照会、分析、測定します。

3.2 グローバルクラウドネイティブアーキテクチャの実践

3.2.1 クラウドネイティブアプリケーションアーキテクチャ

上記のクラウドネイティブの問題解決のアイデアを組み合わせることで、全体的なグローバル R&D 配信プロセスを抽象化し、より広範なグローバル アプリケーション アーキテクチャのアップグレードをサポートしました。このプロセスでは、高度なクラウドネイティブ テクノロジーも完全に統合し、グローバル シナリオに適用しました。

IaC:統一された R&D インフラストラクチャ宣言パラダイムを提供します。プラットフォームのビジネス依存関係をより適切に分離し、プラットフォームの認知コストを削減するために、サイト アプリケーションの IaC の階層化された抽象標準、グローバル シナリオを中心としたインフラストラクチャ標準を定義し、仕様、ログ収集、プローブ、フック、リリース戦略などからの統合を統一して、IaC へのビジネス アクセスのコストを削減しました。

OAM:統合アプリケーション モデルの定義を提供します。 OAM 開発と運用保守の分離、プラットフォームの独立性と高いスケーラビリティ、モジュール型アプリケーションの展開と運用保守の特性に依存して、ビジネスとプラットフォームのアプリケーション指向の標準を定義し、アプリケーション開発者、運用保守担当者、アプリケーション インフラストラクチャをより適切に接続し、クラウドネイティブ アプリケーションの配信と管理プロセスの一貫性を高めます。

GitOps:ビジネスの研究開発に継続的な配信機能を提供します。クラウドネイティブの GitOps 宣言型コンセプトに基づいて、機能統合から運用・保守管理まで、プロジェクト内で外部依存コンポーネントを統一的に宣言できます。次に、統一された GitOps 標準に基づいて依存機能を宣言および定義するだけで、コンポーネント機能の配信と管理が基盤となる GitOps エンジンに引き継がれ、ソフトウェア システム全体の整合性と持続可能性が向上します。

ACK:統合されたリソース スケジューリング エンジンを提供します。 Alibaba Cloud の ACK コンテナ サービスに基づいて、強力なコンテナ オーケストレーション、リソース スケジューリング、自動化された運用および保守機能を使用して、さまざまな環境にさまざまなビジネス モジュール機能を提供します。上位層のトラフィックスケジューリングに基づいて、オンデマンドのビジネス展開とスケジューリングを実現します。

コンテナ オーケストレーション: ACK の柔軟なコンテナ オーケストレーション テクノロジーにより、グローバル アプリケーション アーキテクチャが正常にアップグレードされました。ビジネス ロジックとインフラストラクチャ、プラットフォーム機能、パブリック リッチ クライアントは、R&D 状態では完全に分離されます。実行状態では、ビジネスプロセスと運用・保守プロセスは軽量コンテナによって比較的完全に分離されており、アプリケーションの全体的な研究開発配信効率とビジネスフォームの安定性が向上します。

コンテナ状態におけるグラフアプリケーションアーキテクチャの統合

ここではコンテナ オーケストレーションの実践に焦点を当てます。グローバル アプリケーション アーキテクチャをアップグレードするプロセスでは、上図に示すように、3 種類のコンテナーが登場しました。

インフラストラクチャ コンテナー (ベース コンテナー)。運用および保守コンテナーやゲートウェイ コンテナーなどのアプリケーションが依存するインフラストラクチャの機能が含まれます。

一時コンテナ: このコンテナにはライフ サイクルがありません。その機能は、Pod 下の共有ディレクトリを介して、独自の R&D 製品をメイン アプリケーション コンテナーとビジネス コンテナーに統合し、機能全体の統合と使用を完了することです。主にプラットフォームコンテナで構成されています。

ビジネス コンテナ: メイン アプリケーション コンテナと同様に、このコンテナには完全なライフ サイクルがあり、gRPC を介してメイン アプリケーションと通信します。主にカテゴリや多言語コンテナなどのリッチクライアントコンテナで構成されています。

3.2.2 クラウドネイティブO&Mシステム

図2. グローバルアプリケーションアーキテクチャにおける運用保守システム

アプリケーション アーキテクチャのアップグレードに伴い、グローバル化によりアプリケーションの運用および保守システムもアップグレードされました。クラウドネイティブ アーキテクチャ システムと IaC 標準の宣言型リファレンスの助けを借りて、複数のアプリケーションの運用および保守機能の使用がグローバルに統一され、インフラストラクチャの強力な機能を通じて効率が向上します。これには以下が含まれますが、これらに限定されません。

• アプリケーションリリース: インテリジェントなリリース決定、インプレースアップグレード、ローリングアップグレード、バッチリリース
• 弾力性容量: 自動弾力性、スケジュール弾力性、CPUShare
• バッチ操作とメンテナンス: アプリケーション コンテナのインプレース再起動、コンテナの置き換え、ログのクリーニング、JavaDump
• 軽量コンテナ: コンテナの独立した運用と保守、サイドカーオーケストレーション
• マルチコンテナ配信の展開: ポートの競合、プロセスの競合、ファイルディレクトリの共有
• 可観測性と安定性: アプリケーション ライフサイクル、起動例外診断、ホワイト スクリーン、コンテナのパースペクティブ監視

画像クラウドリソースのBaaS

この運用保守システムでは、グローバル化によりクラウドネイティブの BaaS 機能も導入されています。 BaaS は、エンド ステート指向の関心事の分離 (アプリケーション、インフラストラクチャ) ソリューションの完全なセットを提供します。これは、Alibaba Cloud とミドルウェア リソースの生産、計測と課金、ID 認証、消費プロセスを接続し、IaC をエントリ ポイントとして使用してエンドツーエンドのユーザー エクスペリエンスを提供します。 BaaS 機能を導入することで、グローバル化により SRE によるアプリケーション クラウド リソースの使用の統一された測定管理が実現しました。同時に、R&D 担当者は BaaS を使用して複数のリソースを一貫して宣言的に使用し、使用コストを大幅に削減できます。

図 Javaプロセスライフサイクルの正規化

クラウドネイティブ環境におけるアプリケーションの自己修復機能を向上させるため、K8sPod では Java アプリケーションのライフサイクル仕様も統一し、アプリケーションの起動、運用 (生存と準備)、シャットダウンなどの各段階の定義を標準化し、IaC および SDK モデルを通じてビジネス利用に開放することで、Java アプリケーション ライフサイクルとコンテナ ライフサイクルの一貫したバインディングを実現しました。

IV.要約と展望

テクノロジーはビジネスに役立ち、グローバル テクノロジーはグローバル ビジネスに根ざしています。 「世界中どこでもビジネスが簡単にできる」という当社の事業方向性においては、まだまだやるべきことがたくさんあります。同様に、長年にわたる構築にもかかわらず、世界の技術システムには依然として多くの欠陥があり、克服すべき多くの技術的課題が残っています。私たちはまだ道の途中です。