都市商業銀行のコンテナクラウドプラットフォームのアプリケーションシナリオと永続ストレージの実践

金融業界の情報化構築が進むにつれ、銀行アプリケーションにおけるクラウド技術の人気が高まっています。仮想マシンが従来のベアメタル アプリケーションを大規模に置き換えた後、コンテナーが新しいオペレーティング システム レベルの仮想化テクノロジとして登場しました。コンテナ技術をベースに構築されたアプリケーション開発、アプリケーションホスティング、アプリケーション運用・保守プラットフォームは、PaaS コンテナ クラウド プラットフォームと呼ぶことができます。ログ記録、監視、認証、権限などの基本機能と組み合わせたコンテナにより、エンタープライズ レベルのプラットフォームと再利用可能なサービスを構築して、アジャイルな研究開発とエンタープライズ ビジネスのモデル変革をサポートし、マイクロサービス アーキテクチャを使用してエンタープライズ テクニカル サービスのミドルエンド機能を実現できます。コンテナ クラウドは主にステートレス アプリケーションを実行するために使用されますが、特殊なシナリオでは、コンテナを使用してそのステータスを保存する必要があります。この記事は主に銀行の実際のアプリケーションから始めて、コンテナ クラウドの特徴と永続ストレージ ソリューションの実践について説明します。

1. クラウド プラットフォームとコンテナ

IaaS/PaaS は、クラウド プラットフォームの構築において比較的広く使用されている 2 つの機能です。 PaaS は IaaS をベースにしており、ミドルウェア、データベース、コンテナ クラウドなどの便利な導入および運用・保守機能を提供します。ミドルウェアとデータベースは、仮想マシンの展開形式とコンテナ リソースの展開を提供できます。コンテナ自体の観点から見ると、IaaS レイヤーで基本的なコンピューティング機能を提供し、ステートレス アプリケーションでよく使用されます。コンテナが消えた後は、消えた時点の状態は保存できません。 Docker に加えて、Coreos や Podman などの他のコンテナ テクノロジもあります。相対的に言えば、Docker は現在最も一般的なコンテナ エンジンです。金融業界では通常、コンテナの実行に Docker を使用し、コンテナのオーケストレーションと管理に Kubernetes を採用し、コンテナのスケジュール設定と管理機能を実装するために Kubernetes を使用します。コンテナ技術の応用により、PaaS プラットフォームの実装に新しいリソース形式が提供されます。金融プライベート クラウドでは、通常、テナントは IaaS リソースを分離するために使用されます。テナントは、さまざまなアプリケーション システムを実行するために 1 つ以上の Kubernetes クラスターを構成できます。コンテナとクラウド コンピューティング テナント機能を組み合わせることで、コンテナ クラウド プラットフォーム機能を実現できます。

2. コンテナの機能は、中小規模の銀行のアプリケーション シナリオにどのように適合しますか?

コンテナ化された PaaS プラットフォームは、マイクロサービス アーキテクチャの考え方と組み合わせて構築できます。各コンテナは、実際にはクラウド オペレーティング システムのコンポーネント/プロセスです。 Kubernetes は、これらのコンポーネント/プロセスを管理およびスケジュールするためのカーネルに相当し、コンテナ化された PaaS プラットフォームは、複数のクラスター、複数の種類のリソース、および複数の種類のアプリケーションを備えたエンタープライズ レベルのクラウド オペレーティング システムです。アプリケーション開発、アプリケーション ホスティング、アプリケーションの運用と保守のための PaaS プラットフォーム機能を提供します。コンテナ上に構築されたコンテナ クラウド プラットフォームの利点は、軽量、高速変更、弾力的な拡張と縮小に適しており、コンテナ クラウド プラットフォームはインフラストラクチャ リソースを使用する必要があるというコンテナの特性からも生まれます。通常、コンテナ クラウド プラットフォーム ノードは仮想化に基づいて構築されるため、ミドルウェアなどのサービスを提供する必要がなく、クラウド管理はクラウド インフラストラクチャ リソースのみを管理します。

コンテナ クラウド プラットフォームには、マイクロサービス アーキテクチャのアプリケーションをサポートするという固有の利点があります。マイクロサービスを通じてサービス プラットフォームを構築し、企業内で再利用可能な技術サービス、データ サービス、ビジネス サービスなどを構築することで、エンタープライズ ビジネス アプリケーションのアジャイル反復をサポートできるため、より適合性が高まります。コンテナはオープンソース技術であるため、常に開発と改善が続けられています。テクノロジーの急速な反復と変化により、安定性に対する要求が高い多くの企業は、特に金融業界では、コンテナ テクノロジーを適用する際に、小さなステップで迅速なアプローチを採用しています。コンテナ クラウド プラットフォームは、開発者に便利なデバッグ、開発、展開、運用と保守、移行、容量拡張の機能を提供するため、ますます人気が高まっています。企業のデジタル変革が加速する中、企業は、統合されたリソース管理機能、システムの柔軟なスケーリング機能、低い運用保守コストを備えたプラットフォームを必要としており、DevOps とインテリジェントな運用保守を組み合わせて、開発とテストからシステムの運用と保守、ソフトウェア配信までのライフサイクル全体にわたる統合管理プラットフォームを実現する必要があります。

ご存知のとおり、銀行業界は IT 技術に対する要求が非常に高い業界です。これまでのIT構築において、銀行業界は最先端・最新技術の活用を追求するのではなく、システムの信頼性と安定性を主に追求してきました。したがって、インターネット企業と比較すると、銀行業界におけるコンテナの適用は比較的遅くなるでしょう。しかし、複数の業界でコンテナが深く応用されるにつれて、金融業界もコンテナクラウドの応用を徐々に深めてきました。金融分野では、銀行がコンテナ クラウド プラットフォームの典型的な適用シナリオです。インターネット技術の急速な発展により、新たな金融サービスモデルが銀行業務に影響を及ぼしています。近年、銀行はビジネスモデルの革新を続けており、従来の IT プロセス、インフラストラクチャ、運用・保守モデルのアップグレードも進んでいます。コンテナ テクノロジーの成熟により、従来の金融会社のデジタル変革に新たなアイデアが生まれました。

銀行アプリケーション コンテナの主なシナリオ: 最初のカテゴリは、アジャイル ビジネス シナリオと内部標準化された管理です。ビジネス シナリオは主に、銀行が従来のカウンター サービスから新しいアプリケーションに移行することを指します。急速な需要に応えるインターネット分野のアジャイル領域を設計する場合、アプリケーションの展開機能を高速化し、継続的な配信機能を向上させる必要があります。コンテナ クラウド プラットフォームは、一方ではアプリケーションの展開と配信を標準化し、他方では CI/CD テクノロジーとの統合を強化して、アジャイル ビジネスのニーズに迅速に対応できます。 2 番目のカテゴリは、内部の標準化された管理の必要性であり、これは主に、銀行システムに多くの支店があり、組織構造が複雑であるという事実を指します。クラウド プラットフォームのコンテナ クラウド管理機能により、コンテナ イメージの管理を標準化し、統一された基本的なセキュリティとパフォーマンスの構成ベースラインを実現し、システムのコンプライアンス要件を満たすために IT インフラストラクチャをより効率的に管理することが可能になります。

3. コンテナの保管と構成

3.1 City Merchants Container Cloud 永続ストレージの適用シナリオとコンテナ用永続ストレージの種類

現在、都市商業銀行はコンテナ クラウドを使用しており、これは主にアプリケーション層の一部のコンポーネントを展開するために使用されます。フラッシュセール、プロモーションオファー、その他のアジャイルビジネスなど、弾力的なスケーリングを必要とするビジネスシナリオでは、コンテナを使用して、アプリケーションレイヤーで純粋な Java プログラム、ミドルウェア、ステートレス Redis クラスターなどをデプロイします。さらに、コンテナ プラットフォームで状態を保存する必要のあるシナリオに徐々に遭遇することになります。 MySQL や Redis などのデータベースを導入しており、これらのデータベースによって生成されたデータをバックアップする必要があります。コンテナ クラウドでは、Kubernetes にデプロイされたアプリケーションを Pod コンテナの形式で実行します。 Pod にはライフサイクルがあるため、Pod がデータ ボリュームをマウントしない場合、Pod が削除または再起動されるとデータは消えてしまいます。このデータを長期間保持したい場合は、Pod データ永続ストレージを使用する必要があります。

Pod の再起動後にデータが失われないようにするだけでなく、Pod 間でファイルを共有する必要が生じることもあります。したがって、Pod ストレージの永続性という話題が生まれます。クラウドプラットフォームのコンテナクラウドでは、コンテナ上に永続ストレージをマウントする問題を解決するためにいくつかのソリューションが提供されていますが、主にKubernetesが提案するボリュームオブジェクトソリューションをカプセル化することで解決されています。

Container Cloud は、NFS ファイル システム、ISCSI/FC などのマップされたストレージ、Cephfs などの分散ストレージ システム、AWS などのパブリック クラウド ストレージ サービス、EmptyDir や HostPath などの Kubernetes 組み込みストレージ タイプなど、幅広いボリューム タイプをサポートしています。最も一般的なものは、NFS マップ ファイル システムと Hostpath 組み込みストレージです。 Cephfs などの分散オブジェクト ストレージ システムは、柔軟な拡張機能と大規模なストレージ機能を備えているため、現在、一部のユーザーによってコンテナのバックアップに使用されています。

HostPath ボリュームは、Pod がマウントされているホスト マシン上のディレクトリまたはファイルを参照します。 HostPath Volume を使用すると、コンテナーはホストのファイル システムをストレージとして使用できるようになります。 Hostpath はノード レベルのストレージ ボリュームです。 Pod が削除された後も、ストレージ ボリュームは Pod が実行されているワークノード上に存在し、削除されません。同じ Pod がノードにスケジュールされている限り、Pod が削除され、このノードに再スケジュールされた後も、対応するデータは存在します。 Hostpath ストレージ ボリュームの欠点は、Pod が削除された後、データの損失を避けるために同じノードにスケジュールする必要があることです。複数のノードがあるシナリオには適していません。

EmptyDir ボリューム タイプは、Pod がノードに割り当てられたときに作成されます。 Kubernetes はノード上のディレクトリを自動的に割り当てるため、ホストノード上の対応するディレクトリ ファイルを指定する必要はありません。このディレクトリの初期内容は空です。 Pod がノードから削除されると、EmptyDir 内のデータは完全に削除されます。 EmptyDir ボリュームは、一部のアプリケーションで永続的に保存する必要のない一時ディレクトリや、複数のコンテナの共有ディレクトリなどに主に使用されますが、永続的なストレージには適していません。以下では、主に NFS を使用して永続ストレージを構成する方法について説明します。

3.2 コンテナの永続ストレージ構成

ボリュームを使用する場合、コンテナーはバックエンドのストレージ システムを気にする必要がありません。あらゆるタイプのボリュームは単なるディレクトリです。ストレージ ボリュームを使用する場合は、次の手順を実行する必要があります。

1. PersistentVolume を定義し、このボリュームをどのストレージに関連付けるかを示す PVC を定義します。 2. Volumemounts を使用して、コンテナー内の対応するストレージをマウントします。ストレージ ボリュームを正しく使用するには、これら 2 つの手順が必要です。

PersistentVolume (PV) はクラスター内のストレージの一部であり、管理者によって構成されるか、ストレージ クラスを使用して動的に構成されます。ポッドが k8s クラスター リソースであり、LUN ストレージ ユニットが集中ストレージの最小の論理ユニットに類似しているのと同様に、PV はクラスター内の基本リソースとして定義されます。 PV は、そのライフサイクルが PV を使用する単一のポッドから独立したストレージ プラグインと考えることができます。

PersistentVolumeClaim (PVC) は永続的なストレージ ボリュームです。このタイプのストレージ ボリュームは、Pod を作成するときに定義できます。ポッドに似ています。ポッドはノード リソースを消費し、PVC は PV リソースを消費します。ポッドは特定のレベルのリソース (CPU とメモリ) を要求できます。 PVC は、PV を申請するときに、特定のサイズとアクセス モード (たとえば、1 回の読み取り/書き込み、または複数回の読み取り専用) を要求することもできます。

3 つの PV アクセス モード:

(1) ReadWriteOnce: これは最も基本的な方法で、読み取りと書き込みの両方が可能ですが、単一の Pod によるマウントのみをサポートします。

（2）ReadOnlyMany：複数のPodから読み取り専用でマウントできます。

（3）ReadWriteMany：このストレージは、複数のポッドで読み取り/書き込み方式で共有できます。

すべてのタイプのストレージがこれら 3 つの方法をサポートしているわけではありません。たとえば、共有方式は現在多くのシステムでサポートされておらず、より一般的に使用されているのは NFS です。 PVC を PV にバインドする場合、通常は 2 つの条件が使用されます。1 つはストレージ サイズ、もう 1 つはアクセス モードです。設計時には業務システムに合わせてPVを搭載することが可能です。ビジネス システムの複数のポッドは同じ PV ストレージを共有し、ReadWriteOnce モードを使用してディレクトリごとに区別されます。また、ReadWriteMany モードを使用して、各ポッドを 1 つの PV に対応させ、洗練された方法で管理することもできます。

3 つの回収ポリシー:

（１）保持は手動で再利用する方法です。通常、保持する必要があるデータとログを保存するため、実稼働システムで最も一般的に使用されます。

（2）リサイクル基本データ消去（「rm -rf /thevolume/*」）

（3）AWS EBS、GCE PD、Azure Disk、OpenStack Cinderなどの関連するバックエンドストレージボリュームを削除します。

ローカル ディスクと NFS のみがデータ ディスクの Recycle 消去とリサイクルをサポートし、AWS クラウド ディスクまたは Cinder ストレージ ボリュームは削除ポリシーをサポートします。

PV ボリュームには 4 つのステータス段階があり、そのうち「使用可能」状態はリソースがまだ要求されていないことを示します。バインド状態は、ボリュームがクレームにバインドされていることを示します。解放済み状態は、クレームが削除され、ボリュームが解放済み状態にあるが、クラスターによって再利用されていないことを示します。失敗ステータスは、ボリュームの自動リサイクルが失敗したことを示します。

PV はクラスター内のリソースであり、PVC はそれらのリソースに対する要求であり、リソースのチェックとしても機能します。 PV と PVC 間の相互作用は、プロビジョニング、バインド、使用、解放、リサイクルというライフ サイクルに従います。

（１）プロビジョニングプロビジョニングは静的と動的に分けられます。静的プロビジョニング: クラスター管理者は複数の PV を作成します。これらは、クラスターのユーザーが利用できる実際のストレージの詳細を保持します。これらは Kubernetes API に存在し、使用するために使用できます。実稼働システムでは、管理者がストレージ セグメントの管理を標準化できるように、静的 PV を使用することをお勧めします。さらに、管理者は静的に割り当てられたストレージ データを保存するかどうかを決定できます。 PVの命名も事業ごとに区別できます。 NFS は動的ストレージをサポートしていないため、通常はサードパーティのプラグインを使用する必要があります。管理者によって作成された静的 PV がユーザーの PersistentVolumeClaim と一致しない場合、クラスターは PVC のボリュームを動的に構成しようとする場合があります。動的に割り当てられたストレージは常に削除されます。動的メソッドは実際にはほとんど使用されず、開発やテストなどの非本番環境のシナリオで検討できます。

（２）拘束力PVC は要求条件に応じて対応する PV を選択してバインドします。 PVC が PV にバインドされると、他のバインドは除外されます。つまり、この PV に設定されたアクセス モードによって複数のノードによる読み取りと書き込みが許可されている場合でも、他の PVC は同じ PV にバインドできません。さらに、PVC が対応する条件の PV と一致しない場合は、バインドされていないものとして表示され、一致が見つかるまでバインドされていない状態のままになります。

（３）使用すること。 Pod はストレージをマウントします。つまり、特定の PVC を使用するために Pod のテンプレート ファイルでボリュームを定義します。ユーザーはポッド内の PVC をボリュームのように使用できます。

（4）解放ユーザーがストレージリソースを再利用するためにPVCを削除すると、PVは「解放」された状態になります。以前のデータがまだ保持されているため、このデータは別の戦略に従って処理する必要があります。そうしないと、これらのストレージ リソースを他の PVC が使用できなくなります。 PersistentVolumeReclaimPolicy を参照してください。

（５）回収この段階では、解放されたPVをどのように処理するかをクラスターに指示します。データは保持（手動クリーンアップが必要）、リサイクル、および削除される場合があります。

（6）リサイクル---PVは、保持、リサイクル、削除の3つのリサイクルポリシーを設定できます。保持ポリシー: 保持されたデータの手動処理を許可します。削除ポリシー: PV および外部関連ストレージ リソースが削除されるため、プラグインのサポートが必要です。リサイクル戦略: クリーンアップ操作が実行され、新しい PVC で使用できるようになります。プラグインのサポートが必要です。

3.3 NFS構成の永続ストレージエクスペリエンスの共有

実際の運用環境では、ステートフル コンテナ用のストレージを設計する際には、高可用性、柔軟な拡張機能、管理のしやすさを考慮する必要があります。都市商業銀行の既存のケースでは、より一般的なソリューションは、集中型または分散型の NAS ストレージを使用して永続的なストレージ サービスを提供して、ファイル システムを分割し、PV ボリュームをコンテナ クラウドにマウントすることです。現在、高可用性、柔軟な拡張機能、便利な管理の要件をより適切に満たすことができる永続ストレージ サービスを提供するために、集中型または分散型ストレージが使用されています。

1. 安定性とパフォーマンス:コンテナが弾性スケーリングまたは障害回復を実行している場合、ストレージ ボリュームは頻繁にマウントおよびアンマウントされます。実稼働環境全体の安定性を確保するには、ボリュームのマウントおよびアンマウント操作中に十分な安定性を確保する必要があります。同時に、PV ボリューム サーバーは、アプリケーションの遅延を回避するために高いパフォーマンスを保証できる必要があります。専用の集中ストレージ NFS を使用すると、比較的安定した高性能なストレージ サービスを提供できます。集中型ストレージ デバイスは、RAID、冗長ストレージ ヘッド、分散クラスター マルチノードなどの機能により、ハードウェア障害が発生した場合でも高い安定性を保証します。 NFS のパフォーマンスが不十分な場合、集中型ストレージではポート バインディングを追加することで帯域幅を増やすことができます。分散ストレージでは、バインドされたポートを追加し、分散ノードを拡張することで帯域幅を増やし、クラスター全体のストレージ パフォーマンスを向上させることもできます。

2. 災害復旧の要件:銀行業界では通常、重要な業務を 2 つの場所にある 3 つのセンターに展開することが求められます。集中ストレージと分散ストレージのデュアルセンターデュアルアクティブ機能により、デュアルセンターアーキテクチャを備えたコンテナクラスターも構築できます。

3. 運用および保守管理の要件:コンテナ ステートフル アプリケーションの増加に伴い、従来のストレージ運用および保守作業も課題となります。全体的なソリューションでは、俊敏かつ安全な運用と保守の両方を考慮する必要があります。集中型および分散型の NAS ストレージ製品には、ユーザーフレンドリーで便利な管理方法が備わっています。

4. 容量拡張の要件:コンテナ アプリケーション データが増加するにつれて、アプリケーション操作への影響を最小限に抑えるために、ストレージ ボリュームの容量を拡張する能力を考慮する必要があります。分散クラスターはより柔軟な拡張機能を備えており、集中型ストレージは、構成可能な最大ハードディスク キャビネットの範囲内でより便利に拡張できます。

以下は、NAS を既存の集中ストレージと分散ストレージに分割して、永続ストレージ機能を備えたコンテナ クラスターを正常に実装した実践的なケース スタディです。この事例は、都市商業銀行のリスク管理関連システムに関するものです。現在、複数の業務システムが稼働しており、複数の業務システムは独立した K8S コンテナ クラスターによって実行され、担われています。そのうち 12 個の Pod は、より大規模な業務システムの Kubernetes クラスターにデプロイされており、主に業務システムの Java アプリケーションと Web アプリケーションを実行します。永続ストレージのシナリオは、主に業務操作ログを保存することです。コンテナ クラスターの永続ストレージは、デュアル センター レプリケーションを備えた 2 つのストレージ クラスターによって提供されます。 1 つは Huawei OceanStor 5500 シリーズ ミッドレンジ ストレージで、アクティブ/アクティブ NAS ストレージを構成してコンテナ クラウド クラスターにサービスを公開し、それらを PV としてポッドにマッピングします。もう 1 つは、デュアル センター ディレクトリ同期レプリケーションを備えた SDS 分散クラスタ構成です。データ センターは、複製されたボリュームを災害復旧センターの Kubernetes 災害復旧クラスターに公開できます。バックアップ センターの Kubernetes クラスターはコールド バックアップ クラスターとして使用され、メイン センターに障害が発生した場合に切り替えられます。

コンテナ クラウドでは、nfs パス XX.XX.XX.XX:/nfsshare をマウントする PV を定義し、Pv-admin に関連付けられた PVS をアプリケーション名前空間 spacegs12zr9a にマップします。永続的なログストレージとして使用し、アプリケーションの複数の Pod に同時に書き込む必要がある場合、アクセス モードは通常 ReadWriteMany を採用します。本番ログが削除されないようにするために、persistentVolumeReclaimPolicy の PV リカバリ ポリシーには Retain を採用することをお勧めします。この方法では、PV が手動で再定義された場合にのみ、PV 内のデータが消去されます。

PVC 構成のほとんどの属性は PV 定義から継承されます。 PVC では、PV とアプリケーション間の関連付けを定義することが重要です。 PV とアプリケーションの関連付けは、名前空間を構成することによって完了します。

IV.結論

初期の頃は、Kubernetes のストレージ インターフェースの進化の方向性が不明瞭で、ステートフル コンテナが未熟であったこと、インターフェース プロトコルに限界があったことから、Kubernetes と相性のよい「分散型」オープンソース ストレージが主に使用されていました。初期の頃は、Kubernetes と互換性があり、適切に適応していたストレージ製品でも、パフォーマンスと信頼性の面でビジネス ニーズを満たすことができないことが多かったのです。現在、CSI プラグインの公式マニュアルのドライバー セクションでは、Huawei など国内外の主流のストレージ メーカーのいくつかが推奨されています。コンテナの永続ストレージとしての集中型ストレージ サービスは、比較的成熟してきました。一般に、コンテナ クラウドの永続ストレージを選択するには、実行されるワークロードに基づいた特定の分析が必要です。たとえば、リレーショナル データベースがコンテナ クラウド上に展開されており、データベース データが重要なビジネス システム データである場合は、集中型ストレージを選択するのが適切です。業務アプリケーションシステムのログや設定ファイルであれば、拡張性やコスト効率の面で優れている分散ストレージを優先することをお勧めします。