G-Bank のクラウドネイティブ ビジネス レジリエンスの探求と実践

導入

Bank Gは、フルスタッククラウドプラットフォームを基盤として、クラウドネイティブ技術の応用を徐々に推進し、デジタル変革の道を模索し、銀行業務の急速な発展に強力な技術サポートを提供しています。同時に、クラウド ネイティブは、マイクロサービス管理、クラウド セキュリティ、ヘルス モニタリング、依存パス、回復力要件などにも課題をもたらし、それは次のように現れます。

マイクロサービス管理: 複数のマイクロサービスが有機的に結合され、健全なアプリケーションが構築されます。本質的には、システムが適切に機能するためには、多くの可動部品が連携して動作する必要があります。マイクロサービスに障害が発生した場合、システムはそれを検出し、自動的に修復する必要があります。自動デプロイメントと頻繁なシステム反復の導入により、アプリケーション システム マイクロサービスの管理はますます複雑になり、管理要件もますます高くなっています。

クラウド セキュリティ: クラウド ネイティブ環境の不安定性により、従来の境界セキュリティ モデルではすべてのリスク シナリオをカバーできません。クラウドネイティブテクノロジーアーキテクチャでは、コンテナ間の分離、マイクロサービスのライフサイクル全体の変更、マイクロサービス間のグリッド依存性、クラスターリソースの自動スケジューリングなどの新しい領域により、さまざまなレベルのセキュリティリスクが発生し、アプリケーションシステムの安定性に影響を及ぼす可能性があります。したがって、クラウド ネイティブの複雑さを効果的に保護および確保するためのセキュリティ管理戦略と技術的手段を導入することが非常に重要です。

ヘルスモニタリング: Kubernetes は非常に複雑なプラットフォームです。 Kubernetes をベースとした業務システムを円滑に運用するためには、Kubernetes の健全性状態を把握することが重要です。既存のテクノロジーの中には、Kubernetes クラスターのログ、さまざまなインジケーター データ、イベント、セキュリティの脅威を収集してクラスターの健全性を監視するために使用できるものもありますが、単一のインジケーターでは Kubernetes ベースのアプリケーション システムの健全性を体系的に測定することが困難です。さまざまな指標データを収集、統合、包括的に分析して、視覚的な高レベルのビューを生成するには、よりインテリジェントで直感的な方法が必要です。

依存パス: マルチクラスター、マイクロサービスベースのクラウドネイティブ分散環境では、多数の相互作用と依存ポイントがあり、エラーが発生する可能性のある場所は無数にあります。ハードディスクの障害、ネットワークの停止、特定のコンポーネントに負担をかけるトラフィックの急増。適切に処理されない障害は、ビジネスの停滞、パフォーマンスの低下、その他の予測できない現象につながる可能性があります。同時に、クラウドネイティブ環境では、どのような障害が部分的または完全なシステムクラッシュを引き起こすのかを完全に理解することは困難です。可能であれば、このような状況が発生する前にシステムの脆弱性を特定する必要があります。

回復力要件: クラウド ネイティブによってもたらされる分散型ビジネス、多数のクラスター、クラスター境界の制限などの問題も、クラウド プラットフォームに新たな課題をもたらします。プラットフォームは、安定したビジネス運営を確保するために、信頼性の高い回復力機能を提供する必要があります。ビジネスの分散は、さまざまなクラスター内のアプリケーションの差別化された構成、クラウド間のビジネス アクセス、クラスター間のアプリケーション同期に反映されます。クラスターの数が多いと、面倒で反復的なクラスター構成、クラウド ベンダー間のクラスター管理の違い、断片化された API アクセス ポータル、および上位レベルのユーザーに対してクラスターを透過的にする方法に影響します。クラスター境界の制限は、クラスターによって制限されるリソース スケジューリング、クラスターによって制限されるアプリケーションの可用性、およびクラスターによって制限される弾性スケーリングに反映されます。アプリケーションを複数のクラスターにデプロイして配布する方法や、クラスター全体にわたる自動スケーリング機能を提供する方法も、今後私たちが直面する課題です。

上記の課題に対応するため、当社ではプラットフォームの回復力を向上させ、業務運営の安定性を高めるための調査と実践を行ってきました。

クラウドネイティブビジネスレジリエンスの探求と実践

1. 練習内容

クラウド上のビジネス認識、保護、プロアクティブな最適化機能を向上させ、さらに前述の一連の課題に対応するために、G銀行のフルスタッククラウドは、クラウドネイティブのビジネス回復力機能の構築を最初に完了し、一部のアプリケーションシステムに対してクロスクラスタースケジューリング、障害訓練、マルチセンター相互バックアップなどの機能を実現し、ビジネス回復力を向上させ、ビジネス継続性と災害復旧管理を実現する方法を模索しました。次の図は、クラウドネイティブ テクノロジーに基づいてアプリケーションのクラスター間構成バックアップとデータ バックアップを実装するクラウドネイティブ ビジネス レジリエンス プラットフォームのアーキテクチャを示しています。

クラウドネイティブのビジネス レジリエンス プラットフォームは、マルチクラスター管理、クラウドネイティブ アプリケーション システム データのバックアップとリカバリ、クラスター間リソース、ドリル スケジューリングなどのコア モジュールをカバーします。具体的な内容は以下のとおりです。

• マルチクラスタ管理: クラスタ管理には、アプリケーション管理、バックアップ管理、ポリシー管理、サンドボックス管理、アクティビティ監視、監視アラーム、容量管理、その他のサブ機能モジュールが含まれます。同時に、クラスター ラベル、リソース、ノード、サービス、ステータス、その他のデータの効率的な管理も保証します。
• クラウドネイティブ アプリケーション システムのデータ バックアップとリカバリ: さまざまなビジネス アプリケーション ラインの重要性に基づいて、さまざまなバックアップ戦略を開発します。コアかつ重要なビジネスは数分または数秒でバックアップされます。通常業務や重要度の低い業務は週ごとまたは月ごとにバックアップし、バックアップ時点に応じて迅速に復元できます。
• クラスター間のリソースとドリルのスケジューリング: スケジューリング戦略、スケジューリング グループ、履歴レコードとレポートなどの策定を含む、ビジネス ピーク時のリソース要件を満たすために Kubernetes クラスター間でリソース スケジューリングを実装します。クラウド上の仮想マシンやコンテナアプリケーションの切り替え訓練スケジュール、訓練計画、訓練レポート、シナリオ管理、プロセスライブラリ、ステップライブラリ、ステージライブラリなど、緊急事態に対応するための切り替えスケジュールをサポートします。

2. 応募結果

現在、フルスタック クラウド レジリエンス プラットフォームは、複数の Kubernetes クラスターとクラスター内の一部のアプリケーション システムの管理を完了し、アプリケーションの災害復旧のシームレスな切り替えを実現し、プラットフォーム機能に基づいて次の機能探索を実現しています。

• 柔軟なバックアップ戦略: バックアップ時間を効果的に短縮し、バックアップ頻度を柔軟に調整し、RTO を向上させます。冗長データのバックアップを回避し、リソースの使用率を向上させます。
• 安定した高感度のデュアルステート災害復旧: 異なる言語でのコールバックに基づいて、統一された管理とスケジュールを実現します。スイッチング効率が最適化され、RTO が大幅に向上します。
• マルチクラウド移行: 異なるクラウドベンダー間の切り替えと移行をサポートし、プラットフォームレベルの災害復旧機能を実現します。国内の情報技術革新の要求に準拠し、デュアルスタックを同時に開発し、システムリスクを防止します。

その後の改良

クラウドネイティブ テクノロジーは、インフラストラクチャの抽象化のレベルを高め、アプリケーション開発者がインフラストラクチャからさらに分離して、上位レベルのビジネス ロジックの実装に集中できるようにします。フルスタック クラウドは、レジリエンス機能を構築するプロセスにおいて、アプリケーション システムとの組み合わせで次のような一連の問題にも直面します。

• 多数のアプリケーションのカスタマイズ: 各アプリケーション システムには独自のアーキテクチャ特性があります。アプリケーションのワンクリック災害復旧管理を実装することは技術的に不可能です。各アプリケーションを個別にカスタマイズすることしかできません。
• 複雑な構成: 純粋なクラウドネイティブ アプリケーションであっても、安定性に敏感なデュアル ステート アプリケーションであっても、プラットフォーム レベル、システム レベル、サービス レベルでさまざまな複雑な構成が存在します。災害復旧側の管理ではミスが起きやすく、深刻な場合にはメインアプリケーションの正常な動作に影響を及ぼすこともあります。
• 困難なビジネス検証: アプリケーション システムに対して完了した災害復旧バックアップは、プライマリ アプリケーションとのビジネス上の同等性について完全かつ適切に検証できません。
• マスターとスレーブの同期が弱い: クラウドネイティブ アプリケーション システムは反復が速く、ビジネスは頻繁に更新されます。バックアップ アプリケーションは、1 回限りの管理と同期反復の要件を満たすことができません。バックアップ側は、プライマリ サービスとバックアップ サービスの一貫性を確保するために、各反復でプライマリ側のアプリケーション システムと積極的に同期する必要があります。
• 上記の問題を解決するために、「API + クラウドサービス」という形でサービスエコシステムを構築するというトレンドの下で、私たちは技術手段と管理メカニズムの統合に関する実現可能なソリューションも模索しています。
• フォワード災害復旧: 管理面では、アプリケーション システムのクラウド変換とクラウド災害復旧管理が統合されています。技術的には、クラウド移行が完了した時点で災害復旧構築が完了するように、アプリケーション システムごとに異なる災害復旧仕様が策定されます。
• 平時と戦時の統合：平時のBCPとDRPを改善してその正確性と有効性を確保し、検証するための訓練を実施する。戦時中は迅速に対応し、迅速に決定し、迅速に対処します。平時と戦時を統合し、戦うことも勝つこともできる事業継続システムを構築します。
• 安定した状態とアジャイル状態の共存: ビジネス ラインは、アジャイル状態と安定した状態を経て実行されます。情報システムのローカル緊急対応機能とリモート災害復旧機能は、安定モードとアジャイルモードの両方で構築する必要があります。安定した俊敏な技術アーキテクチャは、BCM システムに準拠し、サポート機能を構築します。リスクはビジネス部門と IT 部門を結び付け、安定性と俊敏性の両方を考慮した二重状態の組織と緊急対応システムを構築します。
• 高頻度イベントと低頻度イベントの連携：低頻度イベントを活用して、BCM システムビジネスと IT の最後の防衛線を構築します。高頻度のイベントに直面し、日常の運用とメンテナンスとコンポーネントの切り替えとの連携を実現します。高頻度イベントと低頻度イベントをリンクして、リソース共有を効果的に実現し、災害復旧投資の ROI を向上させます。

次の図は、指標策定、戦略策定、能力構築、緊急訓練、緊急切り替え、最適化と改善、影響分析レポートからビジネスシステムの最適化クローズドループを形成する、フルスタッククラウドレジリエンスプラットフォームの実現可能な最適化プロセスを示しています。各ステップでは、期待される目標を達成するために関連する技術的手段が使用されます。今後の作業では、アプリケーション システムのビジネス継続性を実現するためのテクノロジと管理の統合をさらに検討します。

今後、G銀行はIaaS、PaaS、SaaS、DevOpsなどの観点からクラウドネイティブシステムの管理、スケジュール、監視、災害復旧機能をさらに向上させ、あらゆる面で完全なエコロジカルクラウドシステムを構築し、クラウドビジネスの回復力を守ります。同時に、クラウドネイティブアーキテクチャー計画に基づく業務システム構築を推進し、金融テクノロジー分野へのさらなる深掘りと、サービスコストの透明性と信頼性の向上に努めてまいります。当社では、独自のクラウドネイティブ アーキテクチャの実装を通じて、業界にデジタル変革のエクスペリエンスを提供したいと考えています。