コンテナ クラウド プラットフォームは、どのようにリスクを管理し、主要なテクノロジ ルートを選択するのでしょうか?

序文

コンテナクラウドプロジェクトは、当社がインフラクラウドコンピューティングPaaSプラットフォームを構築するための試みです。コンテナ化されたPaaSプラットフォームの構築を通じて、構築中のマイクロサービスアーキテクチャアプリケーションをサポートしたいと考えています。同時に、会社のインターネット事業の発展に適応し、急速な事業発展と反復のニーズを満たすために、標準化された開発、テスト、運用保守環境を段階的に確立し、会社に適したDevOps（開発と運用の統合）プロセスを形成し、開発、テスト、展開、運用保守の監視ツールチェーンと自動化プロセスを改善し、独立したアジャイル研究開発と継続的統合の能力を強化します。同時に、コンテナクラウドプラットフォームを基盤として、エンタープライズレベルのサービスミドルプラットフォームを段階的に構築し、大規模ミドルプラットフォームと小規模フロントエンドの基本アーキテクチャを実現し、同社の業務アプリケーションの開発をより良くサポートし、業務アプリケーションの研究開発に注力し、変化するビジネスニーズに迅速に対応するIT能力を強化します。従来のモノリシック アプリケーション間の困難な統合と共有の問題を解決します。標準化されたコンテナ技術と標準化されたイメージ出力を採用することで、開発、テスト、生産のための一貫した環境を提供します。コンテナ クラウドの柔軟なスケーリング機能を使用して、インターネット金融ビジネス トラフィックの急速な変化をサポートします。

1. 背景と理由

現在、当社ではVMwareとハイパーコンバージェンス技術を活用したIaaS（Infrastructure as a Service）仮想化構築を完了しております。 IaaS 仮想化レイヤーは、ストレージ、ネットワーク、コンピューティング リソースの管理を提供しますが、会社のソフトウェア、ツール、ミドルウェアなどの管理は提供できません。 クラウド コンピューティングの 3 つのタイプに応じて、PaaS (Platform as a Service) プラットフォームを構築することで、アジャイル開発機能と自動化された運用および保守機能を向上させながら、これらの目標を達成できます。しかし、PaaS プラットフォームの技術は常に未熟であり、多くの技術的な困難があります。 Docker に代表されるコンテナ技術の出現、発展、そして段階的な成熟により、コンテナ技術に基づく軽量 PaaS プラットフォーム、つまりコンテナ クラウド プラットフォームを構築する可能性が見えてきました。

1. コンテナクラウドの定義と機能

コンテナ クラウドは、軽量の PaaS プラットフォームのコンテナ化された実装です。コンテナ技術、コンテナのスケジューリングおよびオーケストレーション技術、コンテナの動作をサポートするオペレーティングシステム技術、分散技術を基盤としたクラウドコンピューティングプラットフォームです。

PaaS 機能に関して言えば、PaaS はアプリケーション開発、アプリケーションホスティング、アプリケーション運用および保守機能を提供します。つまり、PaaS では、顧客がアプリケーションを開発およびテストし、ユーザーが PaaS ランタイム環境にアプリケーションをホストできます。同時に、PaaS は顧客にアプリケーション サービスの運用および保守機能 (アプリケーション管理、監視、ログ記録、セキュリティなど) を提供します。

PaaS プラットフォームは、アプリケーション開発を中心に、アプリケーションのライフサイクル全体の管理、ミドルウェア クラウド サービス、基本リソースの効率的な使用などの問題を解決することを目的としています。アプリケーションの開発と展開から運用と保守の全プロセスライフサイクル管理まで、アプリケーションの自動スケーリング、弾力的な拡張、グレースケールリリース、監視アラーム、障害分析、自動移行、自動回復を実現します。当社は、豊富な事前統合サービスを提供しており、共通のソフトウェア機能をサービスに変換することで、アプリケーションが分散型の高可用性と高スケーラビリティを迅速に実現できるようにします。基盤となるリソースの抽象化とリソース層の分離を通じて、可能な限りリソースを共有または分散し、全体的なリソース利用率を向上させて、インフラストラクチャへの投資を削減します。

非常に多くの機能を実現するために、PaaS テクノロジには、IaaS レイヤーの機能を PaaS にさらにシームレスに統合する方法など、いくつかの困難があります。開発機能、特に IDE ツールをクラウドに展開する方法 (Eclipse はクラウド開発サービスを提供しています)。データストレージや動的移行の問題など。コンテナテクノロジーは、最初に軽量のPaaSを構築してアプリケーションホスティングとアプリケーションの運用および保守機能を実現するオプションを提供し、同時に継続的インテグレーション環境を確立してコンテナクラウドプラットフォームにシームレスに接続します。

2. コンテナ クラウドはどのような新しいテクノロジーとアイデアをもたらしますか?

コンテナ クラウドは、軽量の PaaS を実装する方法です。コンテナ技術の発展により、PaaS プラットフォームの実装が促進され、PaaS プラットフォームの技術的な問題が部分的に解決されました。コンテナ技術とPaaSプラットフォーム技術の発展により、コンテナクラウドはさらに成熟していきます。

コンテナ技術の特性はマイクロサービス アーキテクチャに非常に適しており、マイクロサービス アーキテクチャ アプリケーションの展開と運用および保守がより便利になり、弾性スケーリングやグレースケール リリースなどの運用および保守の困難を効果的に解決できます。

コンテナとコンテナ クラウドは、DevOps の考え方の発展と成熟をさらに促進し、それを実装する方法を見つけました。コンテナ クラウドは、継続的インテグレーションと継続的デプロイメントに便利な方法を提供し、開発、テスト、運用、その他の環境における一貫性を確保する方法も提供します。

コンテナ テクノロジーにより、アプリケーションの展開と管理の方法が変化しました。コンテナ クラウド プラットフォーム、マイクロサービス アーキテクチャ、DevOps 方法論は相互に補完し、促進し合い、アプリケーション開発、アプリケーションの展開、アプリケーションの運用と保守のライフサイクル全体の管理に新しい方法と手段をもたらし、クラウド コンピューティング プラットフォーム上でのビッグ データ アプリケーション、AI アプリケーションなどの大規模な展開も促進します。クラウド コンピューティング プラットフォームをインフラストラクチャとして使用して、基本的なビジネス アプリケーション、ビッグ データ アプリケーション、AI アプリケーションなどをサポートし、グローバル システムとサービス システムを確立することで、顧客に優れたサービスを提供して、顧客の信頼をより確実に獲得できます。

3. 企業が直面する問題と課題 - 現状分析

インターネット金融の出現と急速な発展は、伝統的な金融会社に多大な圧力をかけ、変革と調整を検討せざるを得なくなりました。インターネット金融の要点はインターネット、つまりインターネット思考とインターネット技術にあります。高度なアイデアは高度なテクノロジーにつながり、高度なテクノロジーは高度なアーキテクチャをサポートし、高度なアーキテクチャは高度なビジネスを促進し、高度なビジネスは顧客に優れたサービスを提供して、より多くの顧客を獲得します。

我が国の伝統的な金融企業は、依然として伝統的な考え方と後進的な技術を持っています。新規ビジネスが要件提案からプロジェクトの確立、入札、実装、立ち上げに至るまでには、約 1 年かかります。最も重要なことは、開発された製品が元の製品ではなくなり、満足のいくものでも不満足なものでもない可能性があるということです。最前線の従業員は不満を抱き、IT 担当者は憤りを感じ、顧客は失望して離れてしまいます。この従来の IT 研究開発方法では、新規ビジネス開発の要件を満たすことができなくなりました。

コンテナ クラウド プラットフォームを構築するという当社の提案も、現実的な課題に基づいています。

1) メーカーによって、開発、テスト、展開、配信の段階が異なります。各チームには独自の環境、ツール、方法、仕様があり、チーム間で効率的に共有および共同作業を行うことが困難になっています。

2) 従来のモノリシック アプリケーションには独立したシステムがあり、相互接続して共有することが困難です。 ESB は統合を実現できますが、パフォーマンス、スケーラビリティ、低レイテンシ、迅速な起動などの一部の要件を満たすことはできません。

3) 自動テストおよび自動運用・保守のレベルが低い。通常、システムはプロジェクトの立ち上げから運用・保守まで 1 人の担当者によって管理されるため、大小さまざまなシステムが数百個存在し、多大な人的資源を占有することになります。システムに異常が発生した場合、問題の特定が遅く、複数のシステムに影響する場合が多く、対処に時間がかかります。

4) 1 台の PC に 1 つの環境があり、リソースの使用率が低く、PC が限られている。仮想化後、仮想マシン OS は大量のコンピューティング リソースとストレージ リソースを消費します。仮想マシンOSの実質的な運用保守管理コストは物理サーバと同等であり、仮想マシン数の増加は管理コストの増加につながります。

5) コピーが容易ではなく、環境構築が面倒です。本番環境とテスト環境が一致しておらず、環境が汚いという問題があります。実行するたびに環境が完全に一貫していることを保証することは不可能です。テスト環境では動作しますが、本番環境では動作しない可能性があります。

6) 容量の拡張が遅く、突然のトラフィックの急増に対処するのが非常に困難です。移行は遅くて面倒です。

7) システムが過負荷になり、アプリケーションのスケーリング サイクルが長くなり、VM のスケーリング時にシステム負荷が大きくなり、APP VM 環境を迅速に複製できず、アプリケーションの大規模で迅速かつ柔軟な展開要件を満たすことができません。

8) 迅速な反復をサポートしておらず、ビジネス立ち上げの効率が低く、オンラインアプリケーション環境の適用、構成、切り替えをサポートしておらず、頻繁なリリースとアップグレードに膨大な人的投資が必要です。また、オンライン検証メカニズムが欠如しており、オンラインの問題を迅速に特定して修復することが困難です。問題が発生した後にそれを解決する手段は非常に限られており、非効率的です。

4. コンテナクラウドプロジェクトを導入する理由

私たちが直面する問題や課題を解決するためには、急速に変化する時代を生き残り、革新を起こし、時代の変化に対応していくことが重要です。

まず、私たちは意識を変え、IT技術への投資を重視し、科学技術が主要な生産力であることを認識する必要があります。未来を勝ち取るために、もはや人海戦術に頼ることはできません。 IT システムとプラットフォームはビジネスの基盤であり、ビジネス処理能力の向上に大きく役立ちます。インターネット、モバイル サービス、モノのインターネットの発展は、強力な相互接続と相互運用性、強力なコンピューティングと分析機能、ターゲットを絞ったサービス機能、即時応答機能、快適な顧客体験機能などを必要とする強力なインフラストラクチャによってサポートされる必要があります。これらすべてには、IT システムとプラットフォームのサポートが必要です。

ビジネスはプラットフォーム上に構築されます!良いプラットフォームがなければ良いビジネスを立ち上げることは困難です。従来のモノリシック アプリケーションは、異なるテクノロジ、開発言語、開発フレームワークを使用して、互いに独立しています。データは分離されており、それぞれに独自のデータベース セットがあります。データの冗長性は無駄につながり、最も重要なのは、データの不整合が多くの問題を引き起こすことです。データは企業の中核資産であるため、重要な企業データをパブリック クラウドに簡単に配置することはできません。企業ビジネスの運用・発展を支えるには、自社独自のプライベートクラウドプラットフォームを構築し、企業内にインフラ基盤を構築する必要があります。これにより、インフラストラクチャ プラットフォームはデータとビジネスに対応できるようになります。データ層は、グローバルな単一のデータ ソースを実現し、データの切断、不整合、冗長性などの問題を解決するための共通データ モデルを確立します。ビジネス層では、サービス共有を実現し、基本サービスをベースにビジネスアプリケーションを迅速に構築し、迅速に展開して運用開始します。

SOA 技術の発展により、マイクロサービスはすべての人に受け入れられ、賞賛されるようになりました。大規模で重いモノリシック アプリケーション システムの問題を解決し、ESB 統合のボトルネックも回避します。コンポーネント サービス指向と分散展開モードを採用しており、コンテナ テクノロジの特性と非常に一致しています。小型で軽量なので、小さな部品で大きな成果を達成できます。

具体的には、顧客センター、アカウントセンター、製品センターなどの継続的な構築と連携し、同社のインターネットビジネスの発展に適応し、ビジネスアプリケーションの迅速な開発と反復のニーズを満たすために、マイクロサービスアーキテクチャを採用し、標準化された開発、テスト、運用保守環境を段階的に確立し、同社に適したDevOps（開発と運用保守の統合）プロセスを形成し、開発、テスト、展開、運用保守監視ツールチェーンを改善し、独立した開発技術と管理レベルを強化します。

5. プロジェクトの潜在的なメリット

共有が実現され、急速なビジネスの変化に適応できます。企業は存続・発展し、従業員は高収入を得ることができ、国民には利便性と利益をもたらすことができます。

1) 技術的には、まずコンテナクラウドプラットフォームを構築し、統一されたサービスホスティング、展開、運用保守プラットフォームを確立し、統一された権限管理システム、認可・認証システム、サービス構成ガバナンスシステム、ログ収集・分析システム、監視・警報警告システムなどを段階的に構築・改善し、社内に統一されたアプリケーションサービスの展開、運用、保守監視エコシステムを実現します。

2) 管理面では、DevOpsの概念を導入することで、自社の実情を踏まえ、自社の開発ニーズに適した開発、テスト、運用、保守プロセスを段階的に確立し、関連データ、業務、技術などの標準や仕様を定義し、開発、テスト、本番環境の一貫性を実現し、アジャイル開発能力を高め、自動化された運用と保守のレベルを向上させます。

3) ビジネス面では、ビジネスの変化のニーズに対応するために迅速なビジネスプロトタイプ開発を提供し、ビジネス担当者が早期に関与して使用方法に慣れ、効果的かつ継続的なフィードバックを提供できるようにすることで、ビジネスと開発の好循環を形成します。

一般的に、コンテナベースの軽量 PaaS プラットフォームはコンテナ技術の特性を活用でき、その技術的特性は、インターネット アプリケーションのタグ システムに基づく迅速な反復開発、柔軟なスケーリング展開、グレースケール リリース メカニズムのニーズに非常に適しています。また、開発側の応答性向上や自立的な開発を可能にするために、現在の分散型マイクロサービスアーキテクチャをコンテナクラウドプラットフォームと組み合わせて採用することも検討しています。技術ルートを統一し、徐々に技術の蓄積と共有を実現します。継続的インテグレーションを実現し、開発環境とテスト環境および本番環境間の一貫性を確保します。継続的なデプロイメント機能を実現し、リリース速度を向上させます。弾力的なスケーリング機能を実現し、容量を迅速に拡大および縮小します。運用と保守を解放し、自動化された運用と保守を実施して、同社のインターネットアプリケーションビジネス開発のニーズと、従来のアプリケーションの変換と統合のニーズを満たします。

6. 業界アプリケーションの現状と動向予測 - 市場調査

現在、同社の業務システムの開発、テスト、導入、運用・保守は、依然として主に従来のモデルに基づいています。開発者は、アプリケーションの開発、テスト、および展開の各段階で、オペレーティング システム、ミドルウェア、Web サービスなどのソフトウェア オペレーティング環境を準備および構成する必要もあります。ビジネス アプリケーションのリリースおよび変更サイクルは比較的長く、近年登場したインターネット アプリケーションに求められる高速性、柔軟性、俊敏性の要件を満たすことができず、統合された効率的な基本プラットフォーム サポートが不足しています。

この目的のために、プロジェクト チームは業界内でのコンテナ クラウドの構築について広範な調査を実施しました。

国内銀行はコンテナクラウド技術を採用する可能性が比較的高いですが、証券会社の多くはまだ研究とPoCテストの段階にあります。すでにいくつかは実稼働環境に適用されています。

ある証券会社は、2013年にコンテナ技術の研究を開始し、2014年に本番環境での活用を試み、2015年に大規模な活用を開始しました。2017年の現地調査によると、証券会社が本番環境で使用しているコンテナインスタンスの数は、6つのコンピュータルームで4,000を超えています。リアルタイム同時接続ユーザー数は 30 万人を超え、市場クラウド全体のスループットは 1 秒あたり約 1.5Gbps で、200 万人以上の顧客にサービスを提供しています。

上海証券取引所も、トップレベルから計画され、複数のベンダーが関与するコンテナ クラウド プラットフォームを実装しました。アプリケーションはマイクロサービス アーキテクチャを採用しています。このプラットフォームは、コンテナ クラウド、継続的インテグレーション、継続的デプロイメントを実装しており、2016 年の「オープン ソース クラウド コンピューティング。効果的なアプリケーション」賞を受賞しました。

ある証券会社は、ユーザー センター (電子口座システム)、タスク センター (ストリーム データ処理)、支払センター (社内支払サービス) などのビジネス シナリオで使用される 360 を超えるコンテナ インスタンスをテスト環境と本番環境に導入しました。

ある証券会社は、アプリケーション開発の継続的インテグレーションプロセスにおいてコンテナ技術を主に活用し、独自の研究開発プロセスプラットフォームを実現しています。現在、開発およびテスト環境に数百のコンテナが展開されており、20 を超えるプロジェクト開発およびテスト プロセスがあります。

7. 建設目標

コンテナ クラウドを構築する目的は、マイクロサービス アーキテクチャ アプリケーション ソフトウェアの運用をサポートするコンテナ テクノロジに基づく基本プラットフォームを構築し、アプリケーションの開発、テスト、展開、運用、保守中のソフトウェア インフラストラクチャ環境の複雑さを軽減し、開発者がビジネスの実装に集中できるようにし、開発、テスト、運用、保守の効率を向上させ、テクノロジがビジネス ニーズに対応する速度を向上させることです。

コンテナクラウドの構築はサービスアプリケーション開発が中心となります。高可用性、弾性スケーリング、グレースケールリリース、監視アラーム、ログストレージなどのビジネスアプリケーションの機能要件は、コンテナクラウドプラットフォームを通じて統一的に実装され、アプリケーションの完全なライフサイクル管理、ミドルウェアクラウドサービス、基本的なリソース利用の問題が解決され、インフラストラクチャへの投資が削減されます。コンテナ クラウド プラットフォームは、主にアプリケーションの開発と運用保守に対して以下のサポートを提供します。

 開発環境のサポート：開発者は、コンテナクラウドプラットフォームが提供する迅速な展開機能を使用して、アプリケーション開発に必要な技術環境、プログラミング言語フレームワーク、ミドルウェアサービスなどを確立し、開発環境を迅速に準備します。

 アプリケーション展開サービス: 開発者が作成したアプリケーションは、イメージの形式でコンテナ クラウドに迅速に展開できるため、テスト環境や本番環境でのアプリケーションの迅速な展開と更新が可能になります。

 マイクロサービスアーキテクチャサポート：マイクロサービスアプリケーション向けのアプリケーション登録センター、ログセンター、監視センター、コンテナスケジューリングおよびオーケストレーションサービスを提供し、マイクロサービスアーキテクチャに従って開発されたカスタマーセンターやサービスセンターなどのアプリケーションの基本環境サポートを提供します。

アプリケーションの運用および保守サポート: アプリケーションの運用および保守担当者は、基盤となるハードウェア リソース、オペレーティング システム、およびミドルウェアを管理する必要がありません。統一されたイメージ方式でアプリケーションを展開および変更できるため、アプリケーションの運用と保守の複雑さが大幅に軽減され、アプリケーションの運用と保守管理（スケーリング、構成、アップグレードなど）の自動化が段階的に実現されます。

当社のコンテナクラウドプラットフォーム構築の基本目標は、アプリケーションホスティングとアプリケーション運用・保守のための統一プラットフォームを提供し、コンテナクラウドが提供する構成センター、登録・検出センター、ログセンター、監視・アラームセンターなどを通じて、あらゆる業務アプリケーションに基本的なサービスを提供することです。 R&D 担当者は、アプリケーションの展開や運用、保守を気にすることなく、ビジネス アプリケーションの開発に集中できます。クラウドコンピューティングをベースとしたマルチテナントシステムと権限管理システムは、アプリケーション間の分離を効果的に実現し、安全なアクセス制御システムを提供します。

コンテナ化されたPaaSプラットフォームの構築を機に、基本的な統合監視、アラーム、ログ、構成、認証、API管理などのサービス機能を構築します。同時に、ビッグデータプラットフォームの構築と組み合わせて、機械学習、ディープラーニングなどの人工知能の応用シナリオを事前に研究し、各システムの長所と機能を統合し、各システムの独立した構築によって発生するシステムの孤立、データの分散、データの冗長性、データの不整合などの問題を回避します。統合認証センター、監視およびアラーム センター、サービス登録センター、サービス構成センター、ログ管理センター、API ゲートウェイ、API 管理機能を段階的に構築します。

8.PoCテスト状況分析--工場評価

プロジェクトチームは、国内のコンテナクラウド製品メーカーの予備調査と技術力、プロジェクト実施状況に基づき、A、B、C、D、E、F、Gの7つのメーカーの製品をPoCテスト用に選定しました。テストが完了しました。評価の次元として以下の側面を選択しました。

 マルチテナント: テナント分離機能と、組織構造、ユーザー、権限、およびロールのサポート機能を検査します。

 リソース管理: クラスター、ホスト、コンピューティング、ストレージ、ネットワーク リソースを管理および割り当てる機能。

 DevOps: アジャイルな研究開発と運用機能。継続的インテグレーションと継続的デプロイメントの機能。

 アプリケーション管理: アプリケーションのリリース (グレースケール リリース)、デプロイメント、アプリケーション テンプレート、エラスティック スケーリング、アプリケーションの運用と保守、サービス、インスタンス、ポッド、コンテナー、その他の管理機能が含まれます。

 マイクロサービス サポート: サポートされているマイクロサービス フレームワーク、サービス オーケストレーション、サービス ガバナンス機能などが含まれます。

 イメージリポジトリ/ミドルウェアのサポート: イメージリポジトリ機能とパブリックミドルウェアサポート機能。

 基本コンポーネント: ログ記録、監視、スケジュール、権限、ヘルスチェックなどの基本コンポーネントの機能。

 使いやすさ: 操作と理解がどれだけ簡単か。主な考慮事項は顧客体験です。インストール構成、展開操作、更新とアップグレード、高可用性などが含まれます。命名定義が適切かどうか、操作が便利かどうか、構成が複雑かどうか、人々の習慣に適合しているかどうかなど。

 メーカーの状況：背景、技術力、運用・保守サポート、プロジェクト経験など

入札段階に入るメーカーは、総合的な評価結果に基づいて選定されます。

9. 実施計画

パイロットファーストと段階的な進歩の原則に従って、コンテナクラウドプラットフォームの構築計画は2つのフェーズに分かれています。

フェーズ1：コンテナクラウド基本プラットフォームの構築。コンテナ エンジンとコンテナ管理およびスケジューリング システムを導入し、カスタマー センターおよびサービス センター システムのオンライン導入をサポートします。また、カスタマー センター、アカウント センター、製品センターなどのアプリケーションや、使用されるミドルウェア サービス用のホスティングおよび運用管理プラットフォームを提供します。同時にマイクロサービスアーキテクチャサポートシステムを構築し、サービス構成センター、サービス登録センター、サービスログ処理セン​​ター、サービス監視およびアラームセンターなどのコンポーネントを確立して、サービスの運用と保守の要件をより適切にサポートします。マイクロサービス アーキテクチャに基づいて設計されたサービスは、コンテナ クラウドと適切に統合され、弾力的なスケーリング、グレースケール リリース、ルーティング構成、サーキット ブレーカー保護、アプリケーション監視などの機能を実現できます。同時に、ロードバランシングサービス、メッセージミドルウェアサービス、Redisキャッシュクラスターサービス、アプリケーションサーバーサービスなどのパブリックミドルウェアサービスをコンテナクラウドプラットフォーム上で提供しようとしています。最初のフェーズはNか月かかると予想されています。

フェーズ 2: 既存のサービス開発の移行と DevOps プロセスの実装フェーズ。このフェーズでは、エンタープライズ サービス バス、ビッグ データ アプリケーション、OTC、製品センターなど、コンテナ化された展開に適した既存のアプリケーションの一部を移行し、上記のビジネス アプリケーションに、ログ収集、ログ分析、監視、アラームなどの運用および保守機能だけでなく、弾力的なスケーリング機能も持たせます。開発、テスト、本番環境の一貫性を実現し、継続的インテグレーション、継続的リリースプロセス、標準仕様を完成させ、徐々に自社に適したDevOpsシステムを形成し、継続的に改善し、徐々に他のチームに推進していきます。工期はNヶ月と見積もられています。

2. コンテナクラウドプロジェクトの現フェーズで期待される具体的な適用効果

前述したように、コンテナ クラウド プロジェクトの実装では、パイロット ファーストの段階的なアプローチを採用しています。第一フェーズでは、コンテナクラウドの基本プラットフォームを構築し、同時にマイクロサービスアーキテクチャの適用をサポートします。第 2 フェーズでは、継続的インテグレーション、継続的デプロイメント、継続的フィードバックの DevOps クローズドループ プロセスを実装し、ツール チェーン全体の選択と統合を完了し、変換が必要な既存のサービス指向アプリケーションとモノリシック アプリケーションを移行します。これらのタスクが完了すると、企業、IT システムの構築、運用と保守、開発者に大きなメリットがもたらされます。

1. 企業にとっての価値

コンテナ クラウドは、建物の基礎のようなインフラストラクチャ プラットフォームです。建物が強固で耐震性があるかどうかは基礎が鍵となります。企業にとって、エンタープライズアプリケーションシステムの開発・運用基盤プラットフォームの構築は、アジャイルなアプリケーション開発と迅速なビジネス対応を実現するための基盤となります。

従来のモノリシック アプリケーションの開発サイクルは、基本的に半年または 1 年で計算されます。 SOA/ESB 統合サービスを導入すると、ESB の設計コンセプトによって制限されます。応答性を向上させ、アプリケーション機能を分離し、アプリケーション開発サイクルを数か月、数週間、さらには数日に短縮することはできますが、パフォーマンスと低レイテンシでは要件を満たすことができないことがよくあります。 ESB はシステム統合に基づいており、基盤となるシステムの機能によって制限され、自由に拡張することはできません。マイクロサービス アーキテクチャは、下から上までサービス指向のコンポーネントを重視し、アプリケーション システムを徹底的に変革して、マイクロサービス指向のアプリケーション システムを実現します。コンテナ クラウド プラットフォームは、マイクロサービス アプリケーションのための環境を提供し、企業のサービス ミドル プラットフォームを簡単に構築できます。これは企業にとって重要な機能です。サービス ミドル プラットフォームによってのみ、迅速なビジネス対応機能と、アプリケーションの迅速な構築、展開、運用能力を真に実現できます。

コンテナ クラウドの柔軟なスケーリング機能により、基本的な共有コンポーネントを完全に分離し、単一のマシンのリソースの制限に制約されなくなり、企業全体のニーズをサポートできるようになります。たとえば、ログ センターでは、会社全体のすべてのアプリケーション システムとアプリケーション サービスのログを収集して分析できます。 Container Cloud のマルチテナント機能は、さまざまなビジネス、部門、チームの分離ニーズに十分対応できます。

これらの機能により、ビジネス ニーズに対応する際に、ビジネスの実装のみに焦点を当て、プラットフォーム、ストレージ、フレームワークなどを考慮する必要がなくなります。サービス ミドル プラットフォームのサービスの組み合わせとオーケストレーションにより、ビジネス サービスを迅速に実装できるため、ビジネス担当者はビジネス チャンスを捉え、顧客に適切なビジネス サービスをタイムリーに提供でき、既存の顧客を維持し、新規顧客を獲得できます。

2. ITシステムへのメリット

コンテナクラウドを構築した後は、IT システムではなくビジネス アプリケーションに重点を置きます。すべてのビジネス アプリケーションは、全体としてエコシステムであるエンタープライズ レベルの IT システムを構成します。公共サービスと公共コンポーネントが共有され、重複した構築がなくなります。たとえば、従来のモノリシック アプリケーションでは、各システムにログ モジュールが必要であり、これにより重複と冗長性が生じ、多くの不整合とデータの分離が発生し、包括的かつ長期的なビジネス分析に支障をきたします。コンテナクラウドに基づくITエコシステムには、ログコンポーネントサービスのセットが1つしかありません。これには、コンテナクラウドプラットフォーム上の分散展開に基づいて多くのログサービスインスタンスがある場合があります。他のコンポーネントサービスやビジネスアプリケーションサービスにも同じことが当てはまります。たとえば、メッセージングサービスは、エンタープライズ全体のメッセージの公開とサブスクリプションのサポートを提供し、モバイルアプリ、Wechat、SMS、Webサイトアプリケーションなどのさまざまなチャネルに接続します。これにより、多くの作業が節約され、それにより応答時間が改善され、コストが節約されます。

3。運用およびメンテナンス担当者の利点

コンテナクラウドプラットフォームを採用した後、運用およびメンテナンス担当者の責任は、リソースの運用とメンテナンスとアプリケーションの運用とメンテナンスに分割される場合があります。リソースの運用とメンテナンス担当者は、ITインフラストラクチャリソースの運用とメンテナンスに焦点を当て、コンピューティング、ストレージ、ネットワーク、およびアプリケーションサービスにその他のリソースを提供します。アプリケーションおよびメンテナンス担当者は、アプリケーション開発者によって同時に採用され、ビジネスアプリケーションの自動運用およびメンテナンス監視を実現することもできます。健康チェック、ログ、監視、アラーム、フィードバックオートメーション。自動化されたプロセスとツールを通じて運用とメンテナンスを解放し、異常を迅速に見つけ、迅速なフィードバックを提供し、問題を解決するのに役立ちます。

このようにして、誰もが自分の職務を遂行することができ、リソースの運用とメンテナンス担当者は、アプリケーションの欠陥のために不平を言うことはありません。アプリケーションの運用およびメンテナンス担当者は、開発するビジネスアプリケーションに精通しており、独自の技術的能力を使用して、アプリケーションの運用とメンテナンスをサポートするための適切な運用およびメンテナンスツールを選択および開発できます。

4。研究開発担当者への利点

コンテナクラウドプラットフォームは、R＆D担当者に継続的な統合プラットフォームと一貫した環境を提供します。基本的な開発とテスト環境のセットアップに時間を費やす必要はもうありません。数日かかる可能性のある準備作業は数分で完了できます。開発者は、基礎となるデータのストレージ、モデル、システムアーキテクチャ、展開方法などを心配することなく、ビジネスアプリケーションの開発に集中できます。サービスミドルプラットフォームのサービスを使用してビジネスアプリケーションを構築する方法を検討する必要があります。開発を単純化し、ビジネスの対応を改善するだけでなく、標準化された、正規化された、一貫したインターフェイスサービスも、通常の開発者の能力要件を削減し、学習コストを削減します。

III.主要なリスクの開示と管理

リスクは常にどこにでもあります。コンテナクラウドには多くの利点がありますが、コンテナクラウドの採用と実装にも多くのリスクがあります。コンテナテクノロジーは、急速に開発および変化している新興のオープンソーステクノロジーであり、まず第一に、技術的なリスクがあります。急速な発展と変化とは、多くの人々が技術の変化に追いつくことができず、スキルと経験を欠いており、深い知識を欠くことができないことを意味します。これは人間のリスクです。新しいオープンソーステクノロジーに関しては、企業はしばしば認識と投資を欠いており、良い実用的なケースを欠いています。多くの場合、テクノロジーが成熟して実際に実装されるまでに1年から数年かかります。

1。技術的なリスク

コンテナテクノロジーは数年しか存在しておらず、まだ進化しています。オープンソースのテクノロジーは、すべての人の知恵を簡単にプールできますが、同時に、この問題に関する視点が異なるため、オープンソーステクノロジーの寄せ集めも作成し、テクノロジーの選択に混乱をもたらします。

昨年、コンテナテクノロジーの採用を検討し、選択を開始したとき、MESO、Docker Swarm、Kubernetesなどのコンテナスケジューリングと管理フレームワークの選択に直面しました。しかし、POCテストを完了するまでに、MesosとDocker Swarmはすでに衰退しており、すべての国内コンテナベンダーはKubernetesに頼りました。急速な技術の変化は、プロジェクトの選択と構築にいくつかの問題をもたらします。間違った選択は、その後の操作とメンテナンスの困難を引き起こす可能性があります。

コンテナテクノロジーはオープンソーステクノロジーです。オープンソースのコミュニティと商業企業には、焦点が異なります。コミュニティのオープンソースバージョンには、多くの場合、商業エンタープライズバージョンと比較して強力なサポートがありません。

コンテナクラウドテクノロジーには、Docker + Kubernetesだけでなく、ネットワーク、ストレージ、ログ、監視、セキュリティ、マイクロサービスなども、多数のコンポーネントとテクノロジーが含まれます。それらすべてを一度に習得することは困難であり、技術的なリスクがあります。

2。人間のリスク

コンテナクラウドは、軽量PAAを真に実現するために、対応する基本コンポーネントサービスサポートを必要とするインフラストラクチャプラットフォームです。 Docker + Kubernetesだけの場合、会社のビジネスアプリケーションの開発と運用と保守のニーズをサポートするだけでは不十分です。ただし、現在、中国のコンテナクラウド市場全体の理解は、Docker + Kubernetesでまだほとんど詰まっており、Kubernetesでさえコンテナクラウドと同一視されています。認知と技術の未熟さが、コンテナクラウド構造の故障の主な理由かもしれません。

人事スキルの欠如と経験は、コンテナクラウドプロジェクトの実装における多くの変数につながります。ほとんどの人は表面的な理解しかあり、実践的な経験がありません。実際のプロジェクトでは、過去の経験、テクノロジー、および管理の観点から全体的な制御を持っている人がいない場合、コンテナクラウドプロジェクトは成功しません。

ITプロジェクトでは、人々は最大の制御不能な要因です。プロジェクト担当者のスキルが一致しているかどうか、主観的なイニシアチブを行使できるかどうか、責任感、人員の流れ、プロジェクトの理解、認知、および制御がすべてプロジェクトの質に影響を与えるかどうか。

3。資本投資が不十分なリスク

現在、ほとんどの企業は新しいテクノロジーに懐疑的であり、その投資とサポートは不十分です。多くの企業がPOCテストと検証を実施しているか、パイロットとして小さなプロジェクトを実施しています。これにより、コンテナクラウドインフラストラクチャプラットフォームの完全な構築が制限され、コンテナクラウドプラットフォームの利点を真に実証できません。 Service Middleプラットフォームの機能が特定のスケールに基づいて実現または部分的に実現された場合にのみ、その価値と機能を真に実証できます。

4.これらのリスクを回避する方法

上記のリスクを回避するために、当社はコンテナクラウド製品の開発を購入または協力することにより、コンテナクラウドプロジェクトを実装することを推奨しています。詳細な要件、使用シナリオ、製品開発のためのアーキテクチャデザイン、詳細な設計を提供し、これらの要件、シナリオ、設計に基づいて実装するコンテナクラウドベンダーをサポートできます。最終製品が要件を満たしている場合、入札候補メーカーに入ります。これは、コンテナクラウドベンダーが製品を改善し、仲間の先を行く機会です。当社にとって、特定のリスクを回避し、コストを節約できます。

1）製品の要件

製造業者が提供する製品は基本的に私たちのニーズを満たすことができ、不十分な部分を後の段階で使用するために実装および配信する必要があります。使用中にいくつかのカスタマイズされた変更を行う必要がある場合は、友好的な方法で交渉し、一定量の追加報酬を支払い、後で分割払いで完了することができます。製品の欠陥はタイムリーに修正する必要があり、当社のビジネスの通常の運用に影響を与えてはなりません。私たちの能力を超えており、タイムリーに修復できない欠陥のために、適切な解決策を見つける必要があります。さらに、製品コンポーネントには、更新や交換を容易にするために、ゆるく結合されたアーキテクチャが必要です。

2）製品のインストール、展開、アップグレード、および移行

コンテナテクノロジーは新興技術です。徐々に成熟していますが、依然として急速に発展して変化しており、さまざまなコンポーネントが常に出現しています。したがって、製品は、さまざまなシステムプラットフォームへのインストールと展開をサポートし、物理マシン、仮想マシン、その他のシステムをサポートできる必要があります。コンテナクラウドコンテナエンジンとコンテナ管理およびスケジューリングシステムは、シームレスなアップグレードと移行機能をタイムリーに提供できます。アップグレードと移行計画を提供し、潜在的なリスクを特定し、これらのリスクを回避します。

3）後期段階の要件と新機能開発、カスタマイズされた開発

製品がすべてのニーズを満たすことは不可能であるため、一定期間使用した後、各チームからのフィードバックに基づいて新しい変更と新しい機能要件を提案します。欠陥のない新機能要件については、交渉に基づいて特定の合理的なR＆D料金を支払うことができます。

4）技術サポート

製品の使用の初期段階では、オンサイトのサービスサポートが必要になる場合があり、後の段階でリモートサービスサポートが提供される場合があります。製品の使用中に大きな欠陥によって引き起こされる主要な事故が発生した場合、メーカーは、問題を解決するために2時間以内に技術者がサイトに到着するよう手配する必要があります。そして、欠陥を固定する必要があり、展開を24時間以内に完了します。

5）高可用性要件

主要な製品コンポーネントの高可用性展開を実現し、潜在的なリスクポイントにバックアップメカニズムを提供します。

• プラットフォーム制御ノードの高可用性をサポートします。
• アプリケーションサービスの高可用性展開をサポートします。
• 画像倉庫の高可用性をサポートします。
• 負荷分散と高可用性をサポートします。
• プラットフォームコントロールノードのダウンタイムは、コンテナ内のサービスの通常の動作に影響を与えることができません

4。予算評価

このプロジェクトの予算は、サーバーハードウェア、コンテナクラウドソフトウェア製品認証、実装サービスの購入に使用されるxx百万元です。詳細については、以下の表を参照してください。

前述のように、比較的成熟した製品を選択し、プロジェクトベースの配信を回避することをお勧めします。人々は最大の変数であり、最大の制御不可能な要因であるため、リスクを減らしてコストを制御できるように、人間の変数を可能な限り削減する必要があります。

2回の問い合わせと複数の通信の後、コンテナクラウド製品ソフトウェアのセットは約xx百万元の費用がかかります。さらに、ノードの数に基づいた承認料金があります。これは、ノードあたり約xx百万元です。特定の割引比は、ノードの数に基づいて提供されます。コンテナクラウド製品の展開、構成、テスト、およびデバッグの実装コストは、約100万人民元です。サーバーハードウェアは、アプリケーションの展開要件に従って決定されます。現在、X PCサーバー、XXXGメモリ、XX Xeon 6150 CPU、およびハードディスク、ネットワークカードなどが必要です（上の表に示すように）。コンテナクラウドベンダーのその後のサービス料金は最初の年に無料で、その後の年の総プロジェクト額の約10％〜20％が請求されます。現在の需要に基づいて、全体的な計算後、ソフトウェアとハ​​ードウェア、実装、3年間のメンテナンスサービスを含むコンテナクラウドプロジェクトを実装するための合計予算は約x x百万です。価格はメーカーごとに異なります。

5。主要なテクノロジールートの選択

コンテナクラウドプロジェクトを計画するときは、複数の技術的なルートの選択に直面しています。最初はコンテナエンジンテクノロジー、コンテナオーケストレーションとスケジューリングテクノロジー、マイクロサービスフレームワークなどです。

1。コンテナエンジン

主なコンテナエンジンテクノロジーには、DockerのDockerエンジンとCentosのRKTエンジンが含まれます。理論的には、RKTはセキュリティと互換性の点で優れていますが、生産慣行がありません。現在、ほとんどのユーザーはDockerを使用しています。 Dockerコミュニティもよりアクティブであり、Dockerが以前にリリースされ、より多くの人々が参加したという事実に関連している可能性があります。現在、ほとんどのコンテナベンダーはDockerサポートを好み、RKTはまだ十分に成熟していないため、Dockerエンジンをコンテナエンジンとして選択します。

2。コンテナオーケストレーションとスケジューリングフレームワーク

主なコンテナオーケストレーションとスケジューリングフレームワークには、Mesos、Docker Swarm、Kubernetes、OpenShiftなどが含まれます。

Docker Swarmはシンプルで使いやすいです。 Dockerのネイティブサポート、Dockerをインストールした後、Swarmモードを有効にすると、使用できます。小さなクラスター管理により適しています。

主流のDockerコンテナ（Dockerコンポーネントを個別にインストールする必要がある）をサポートすることに加えて、KubernetesはCoreos Rktなどのコンテナテクノロジーもサポートしています。現在、最も活発なコミュニティがあり、メーカーからのサポートが最も多くなっています。基本的に、すべてのコンテナクラウドベンダーは、Kubernetesのサポートに切り替えました。

Dockerプログラムをインストールせずに、MesosでDockerコンテナを実行できます。 Mesosは、Docker画像を解析してコンテナを起動できます。メソスはより成熟しています。 Kubernetesは数千のノードでテストされていますが、Mesosは数万のノードでテストされています。メソスコミュニティはもはやアクティブではなく、メソスは非常に大きなクラスターをサポートするのに適しています。

OpenShiftは、DockerとKubernetesに基づいたRedhatによってパッケージ化されたオープンソースコンテナアプリケーションプラットフォームです。 Redhatは、迅速なアプリケーション開発、展開、拡張、その他のライフサイクル管理機能をサポートするために、多くの新機能を追加しました。 OpenShiftの実装は、通常、Redhat Partnersによって実行されます。パートナーの能力は、プロジェクトの品質を決定します。

テクノロジーの急速な変化を考慮して、後でアップグレードとメンテナンスのニーズを確保するために、アクティブなコミュニティと高いサポートを備えたコンテナオーケストレーションとスケジューリングフレームワークを選択するのに適しています。包括的に考慮すると、KubernetesまたはOpenShiftが現在より良い選択です。

3。マイクロサービスフレームワーク

現在、最も人気のあるマイクロサービスフレームワークはSpringCloudとDubboです。 SpringCloudは、Springboot Frameworkに基づいてPivotalによって開始されたマイクロサービス開発オープンソースフレームワークです。サービス構成、登録と発見、サービスゲートウェイ、サービスメッセージバス、ヒューズ、ログコレクションなどの比較的完全な機能を提供します。DubboはAlibabaのオープンソース製品です。それは比較的単純で、中国ではもっと使用されていますが、一定期間中断されており、Pivo​​talのシステムのサポート機能がありません。アリババの製品は一般に、アリババ自身のニーズの結果であるため、パフォーマンスの特定の側面を追求するために、標準化と標準化の考慮がしばしば欠けています。全体として、SpringCloudを選択してマイクロサービスを開発することがより良い選択です。

VI.実現可能性評価の結果と提案

上記の分析と評価に基づいて、コンテナクラウドテクノロジーをできるだけ早く使用することをお勧めします。会社のプライベートコンテナクラウドインフラストラクチャプラットフォームをできるだけ早く構築するには、継続的な統合、継続的な展開、継続的なフィードバックを備えた閉ループアプリケーションR＆Dプロセスを構築します。同社の独立した研究開発能力を改善し、ビジネスニーズに対する対応能力を向上させます。製品を購入する方法を使用して、企業のコンテナクラウドプラットフォームを構築して、長いプロジェクトサイクルによって引き起こされる技術的および人間のリスクを回避します。