Gラインクラウドコンピューティング：フルスタッククラウドアプリケーションクラウド

この記事は、Jin Xin が執筆した WeChat パブリックアカウント「独特の職人技と効果」から転載したものです。この記事を転載する場合は、Jingxinduyun Weimiaoweixiaoの公式アカウントにご連絡ください。

導入

2018年、中国工業情報化部は「企業クラウドコンピューティング推進実施ガイドライン（2018～2020年）」を発行し、次のように明確に述べています。「2020年までに、企業クラウド環境のさらなる最適化に努め、業界企業のクラウド化に対する認識と熱意を大幅に高め、クラウドコンピューティングの割合と適用の深さを大幅に高め、企業の生産、運用、管理におけるクラウドコンピューティングの適用を広く普及させます。全国で100万社の新しいクラウドベース企業が誕生し、100を超える典型的なベンチマーク適用事例と、影響力と牽引力のあるクラウドプラットフォームと企業クラウドエクスペリエンスセンターが数多く誕生します。」エンタープライズクラウドコンピューティングが国家政策となっていることがわかります。

G銀行は2012年から最先端のクラウドコンピューティング技術を積極的に模索してきました。長年にわたる継続的な構築を経て、インフラストラクチャ、技術ミドルプラットフォーム、ビジネスプラットフォームなど、複数のレベルをカバーするAnwo Cloudエンジニアリングシステムを確立しました。リソースの俊敏性を重視した初期のプライベートクラウド段階（IaaS）から、テクノロジーのエンパワーメントを重視したプラットフォームクラウド段階（PaaS）、そしてセキュリティ、制御性、ビジネス実現性を重視した現在のフルスタッククラウド段階（IaaS + CaaS + PaaS + SaaS）に至るまで、「クラウドアプリケーション」は常にG銀行の重要な研究方向でした。フルスタッククラウドプラットフォームは、G銀行の123+Nデジタルバンキング開発システムの基本技術プラットフォームのクラウドコンピューティングプラットフォームとして、2021年に正式に運用を開始しました。次の記事では、フルスタッククラウドのクラウド計画とクラウド設計に焦点を当て、G銀行のアプリケーションクラウドの理論的方法と実践的な経験を共有します。

1. クラウドアプリケーションの全体的な計画のアイデア

G 銀行は、クラウド移行の原則、クラウド移行の設計、クラウド移行の実行という 3 つのレベルから、アプリケーション向けフルスタック クラウドの全体的な計画と設計を実施しました。クラウド移行原則とは、主に、アプリケーション クラウド移行の目標を達成するために、企業がアプリケーション クラウド移行作業を実行する前に策定する一連の指導的戦略的意見を指します。クラウド移行設計とは、クラウド移行の原則に基づいて設計された、完全に実行可能なクラウド移行ガイダンス プランを指します。クラウド移行実行とは、クラウド移行ガイダンス計画に従ってアプリケーションのクラウド移行を中心に実行される一連の本番動作アクティビティを指します。要約すると、クラウド移行の原則はアプリケーションのクラウド移行の全体的な計画を導くために使用され、クラウド移行の設計はクラウド移行計画の策定を導くために使用され、クラウド移行の実行はクラウド移行の原則とクラウド移行設計の最終的な実装をサポートするために使用されます。

図1 アプリケーションクラウド計画システム

2. クラウド移行の原則

G 銀行は、自社の事業開発戦略から出発して、実用的なクラウド移行目標を策定し、合理的なクラウド移行戦略を選択し、多次元のクラウド移行の視点を分析することで、現段階でのアプリケーションのクラウド移行に関する全体的な指針を導き出しました。

1すべてのアプリケーションシステムはフルスタッククラウド上に配置する必要がある

原則として、すべてのアプリケーション システムはフルスタック クラウド上に配置する必要があり、最初にコンテナ化されたクラウド コンピューティングを使用する必要があります。クラウド化できない業務システムについては、個別に検討し、クラウド化できない理由を分析する必要があります。フルスタック クラウド プラットフォームのサポート機能、互換性などが原因で障害が発生した場合は、別の記録を提出できます。アプリケーションシステム自体に問題がある場合は、クラウドに移行する前に対応する修正を行う必要があります。

2. フルスタッククラウドサービス機能を自社で構築することは許可されない

フルスタック クラウド プラットフォームは、さまざまな仕様の多種多様な IaaS および PaaS クラウド サービスを提供します。アプリケーション システムは、クラウド移行プロセス中に、フルスタック クラウド プラットフォームによって提供されるクラウド サービス機能の呼び出しを優先する必要があります。セキュリティ、バックアップ、災害復旧、リレーショナルデータベース、コンテナなどの関連コンポーネントを独自に構築することは原則として許可されません。フルスタッククラウドプラットフォームが業務システムに必要なサービス機能を提供できない場合は、申請後に自社構築が認められます。

3. フルスタッククラウドリソースをオンデマンドで申請する

アプリケーションシステムは、フルスタッククラウドサービスのリソースを申請する際に、「最小限の仕様、オンデマンドで使用」という基本原則に従い、業務システムが扱う業務量、ユーザー数、同時ユーザー数などの要素を総合的に考慮して、リソースの仕様と量を合理的に申請する必要があります。

3. クラウドデザイン

1. クラウド調査を実施する

新しいクラウドベースのシステムの場合、研究ではアプリケーション アーキテクチャの設計とサービス機能の要件に重点が置かれます。アーキテクチャの設計および開発プロセスでは、アプリケーションをフルスタック クラウド プラットフォーム アーキテクチャに適合させ、提供されるクラウド サービス機能を最大限に活用して、上位レベルのアプリケーションと基盤となるプラットフォーム アーキテクチャ間の非互換性やプラットフォーム機能の重複を回避する必要があります。

既存システムをクラウドに移行するには、既存システムの現状を徹底的に分析・収集する必要があります。ビジネスニーズから始めて、システム状況調査、アーキテクチャ、リソースの分類など、アプリケーションシステムをクラウドに移行する必要性、実現可能性、難易度を分析する必要があります。具体的なプロセスについては、下の図を参照してください。まず、システム移行が規制要件に準拠しているかどうかを評価し、関連する技術アーキテクチャ要件があるかどうか、およびその要件を満たすことができるかどうかを確認します。次に、システム移行の難易度、時間、コスト、リソース要件（コンピューティング、ネットワーク、ストレージ、セキュリティ、運用、保守などを含む）を考慮します。最後に、アプリケーション システムのアーキテクチャ、プロセス、境界、リソース、非機能を総合的に考慮して、移行戦略と計画を策定します。

図2 クラウド研究フローチャート

2. 主要な技術的変化を特定する

図3 従来の環境とフルスタッククラウド環境の比較

フルスタック クラウド システムのクラウド サービスは、製品の機能や使用方法の点で既存のプラットフォームとは大きく異なるため、従来のアプリケーション クラウド ソリューションはフルスタック クラウドのシナリオには適していません。これは、従来のクラウド ソリューションに適応し慣れている開発、運用、保守担当者にとって大きな課題となります。具体的な違いは次の点に反映されています。

2.1 大規模レイヤー2ネットワークとレイヤー3ネットワーク

G 銀行は現在、標準的な 2 サイト 3 センターの災害復旧システム アーキテクチャを採用しています。従来のネットワークでは、DCI オーバーレイ カプセル化テクノロジを使用して、同じ都市にある 2 つの物理データ センターを第 2 層で 1 つの論理データ センターに統合し、同じネットワーク セグメント内のセンター間でサービスを展開できるようにします。フルスタック クラウド システムでは、各データ センターのネットワーク アーキテクチャは互いに独立しており、クラウド アグリゲーション スイッチを通じてデータ センター間の 3 層の相互接続が実現されます。つまり、異なるデータセンターに展開されたアプリケーション インスタンスは、同じネットワーク セグメント内に存在しなくなります。この変更は、センター間のマスター/スレーブ切り替えを実現するためのフローティング IP や、センター間の負荷分散を実現するための F5 などの元の技術的ソリューションの失敗に直接つながります。

2.2 ネットワーク セキュリティ ドメイン分離と仮想プライベート クラウド (VPC) 分離

G 銀行は現在、ネットワーク セキュリティ ドメインを分割し、ネットワーク セキュリティ制御戦略とファイアウォール機能を調整することで、銀行全体のネットワーク セキュリティ保護を実装しています。ネットワーク セキュリティ ドメイン間のアクセス要求はファイアウォールによって厳しく制限されていますが、実際には、異なるネットワーク セキュリティ ドメイン間のアドレスは相互に到達可能です。フルスタック クラウドは、仮想プライベート クラウド (VPC) を使用してシステム間の分離を実現します。 VPC 内のネットワーク アドレスはプライベート アドレスであり、デフォルトでは VPC 外部のアドレスからは到達できないため、異なる VPC 間のネットワークは自然に分離されます。

2.3 物理ネットワーク通信アドレスと仮想マシンのプライベートネットワークアドレス

G の従来のネットワーク環境では、すべての IP アドレスは実際の物理アドレスであり、アドレス間の通信には複雑なアドレス変換は必要ありません。現在、フルスタック クラウド アプリケーションで使用されているクラウド ネットワークは、主に VPC プライベート ネットワークです。同じ VPC 内のネットワーク アドレスはデフォルトで相互に到達可能ですが、VPC 内と VPC 外のアドレスはデフォルトでは相互に到達できません。通常、VPC 内外のネットワーク アドレス通信は、EIP を使用した NAT 変換によってのみ実現できます。

2.4 IP アドレスを使用したサービス アクセスと DNS ドメイン名を使用したサービス アクセス

銀行 G の従来の大規模なレイヤー 2 ネットワークは、フローティング IP アドレスの使用またはセンター間の IP アドレスの負荷分散をサポートし、統一されたエントリ アクセスを実現します。そのため、従来の環境のアプリケーションでは、データベース、キャッシュ、バッチ、その他のサービスの統合を実現するために IP アドレスを使用する傾向があります。フルスタック クラウドには 3 層のネットワーク アーキテクチャがあり、各データセンターのサービス インスタンスは同じネットワーク セグメント内には存在しません。したがって、ほとんどの場合、サービス アクセスの統一された入口を実現するには、DNS ドメイン名を使用する必要があります。

3. クラウドソリューション設計

アプリケーションをクラウドに移行するということは、主に、アプリケーション システムが動作するために依存しているリソース キャリア (物理マシン、仮想マシン、コンテナー、基本ソフトウェア、ミドルウェア、データベースなど) のすべてまたは一部が、クラウド プラットフォームによって提供、スケジュール、管理されることを意味します。フルスタッククラウドシステムにおけるリソースキャリアの種類に応じて、クラウド移行方法は、コンテナ化されたクラウド移行、仮想マシンクラウド移行、ベアメタル（物理マシン）クラウド移行、ハイブリッドクラウド移行に分けられます。具体的なクラウド移行設計ソリューションは、次のとおりです。

3.1 コンテナ化とクラウド移行

コンテナ化されたクラウド コンピューティングとは、アプリケーション アクセス層 (Web サーバー) とアプリケーション ロジック層 (つまり、JAVA 環境、ミドルウェア、アプリケーション プログラム パッケージを含むアプリケーション ミドルウェア層) をコンテナにパッケージ化し、クラウド プラットフォームを通じて自動的に展開および公開することを意味します。クラウドでコンテナ化を使用する場合、システムはローカルの永続的なデータ転送、つまりビジネス ロジックとビジネス データの分離を実装する必要があります。システムのすべての非構造化データ、キャッシュされたデータ、および構造化データは、ローカル マシンまたはローカルに配置することはできず、共有ストレージまたはデータベースに保存する必要があります。

図4 コンテナ化されたクラウド移行の概略図

上図に示すように、プロキシ サービス層では、フルスタック クラウド エラスティック ロード バランサを使用して、既存の環境のロード バランサに対応できます。アプリケーション サービス層では、フルスタック クラウド上のコンテナ プラットフォームを使用して、Web サービス、小規模プログラム サービスなど、迅速なリリース、柔軟なスケーリング、障害の自己修復機能を必要とするいくつかの小規模なサービス モジュールをデプロイできます。アプリケーションが依存するすべてのミドルウェアは、フルスタック クラウドまたはクラウド ホストによって提供されるミドルウェア PaaS サービスを使用してミドルウェアを展開します。データ サービス層は、フルスタック クラウドまたはクラウド ホスト上の分散クラウド データベースを使用して、既存の環境のデータベースに対応するデータベース ソフトウェアを展開できます。ストレージサービス層では、フルスタッククラウドのブロックストレージサービス、オブジェクトストレージサービス、ファイルストレージサービスを使用して、既存の集中型 SAN ストレージや NAS ストレージに対応できます。

3.2 クラウド上の仮想マシン

仮想マシン クラウドとは、ビジネス システムの IT サブシステム (コンピューティング、ストレージ、ネットワーク、負荷分散など) がクラウド プラットフォームの仮想化環境によってサポートされることを意味します。仮想マシンを使用してクラウド上に新しいアプリケーションを構築する場合、従来の方法と比較してアプリケーション コード レベルに違いはありません。

図5 クラウド上の仮想マシンの概略図

上図に示すように、プロキシ サービス層では、フルスタック クラウド エラスティック ロード バランサを使用して、既存の環境のロード バランサに対応できます。アプリケーション サービス層は、フルスタック クラウド上のクラウド ホストを使用して、既存の環境内の仮想マシン、物理マシン、ミニコンピュータに対応できます。データ サービス層は、フルスタック クラウド上の分散クラウド データベース、またはクラウド ホストに展開されたデータベース ソフトウェアを使用して、既存の環境のデータベースに対応できます。ストレージ サービス レイヤーでは、フルスタック クラウドのブロック ストレージ サービス、オブジェクト ストレージ サービス、ファイル ストレージ サービスを使用して、既存の集中型 SAN ストレージや NAS ストレージを置き換えることができます。

3.3 ベアメタル移行

ベアメタル クラウド移行は、仮想化クラウド移行に似ています。フルスタック クラウド プラットフォームを通じて物理ホストの自動プロビジョニングを実装し、自動化されたネットワーク サービスとハード ディスク管理 (マウント、アンマウント、拡張を含む) をサポートします。主に以下のシナリオで使用されます。

• コア データベース シナリオ: 一部の顧客は、重要なデータベース サービスを仮想マシンに展開できず、専用のリソース、ネットワーク分離、保証されたパフォーマンスを備えた物理サーバー上でホストする必要があることを要求しています。
• 高性能コンピューティングのシナリオ: スーパーコンピューティング センター、遺伝子配列解析、グラフィックス レンダリングなどの高性能コンピューティングのシナリオでは、大量のデータを処理し、コンピューティング パフォーマンス、安定性、リアルタイム パフォーマンスなどに対する要件が非常に高くなります。これらのシナリオでは、仮想化によってもたらされるパフォーマンスの低下やハイパースレッディングの影響に耐えることができません。
• 高度なセキュリティと規制要件のあるシナリオ: 金融や証券などの業界でのビジネス展開のコンプライアンス要件、および一部の顧客のデータ セキュリティに関する厳格な要件は、専用リソース、データの分離、制御性と追跡可能性を確保するために物理サーバー展開を通じてのみ実現できます。

3.4 ハイブリッドクラウド

ハイブリッドクラウド移行とは、業務システムをクラウドへ移行する際に、上記クラウド移行手法のうち2つ以上を採用することを指します。これは主に、技術アーキテクチャが複雑で、技術アーキテクチャの要件とビジネス開発のニーズを満たすことができない単一のクラウド移行モードを持つビジネス システムを対象としています。さまざまなモジュールのニーズに応じて、適切なクラウド移行モードを選択できます。詳細についてはここでは説明しません。

要約する

アプリケーションをクラウドに移行することは、非常に大規模で複雑な作業です。すべての企業のクラウド移行ニーズに適応できる、いわゆるユニバーサルソリューションは存在しません。そこで、この記事では、G 銀行のフルスタック クラウドのクラウド移行計画とクラウド移行設計を通じて、アプリケーションのクラウド移行に関する G 銀行の理論的手法と実践経験を共有することに重点を置いています。私たちは、いくつかの一般的なクラウド移行方法論を使用して、読者が独自のクラウド移行環境を組み合わせて、最適なクラウド移行プラクティスを形成できるようにしたいと考えています。