特許 7011127 クラウドプラットフォームでアプリケーションをコンテナ化する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-01-18

(45)【発行日】2022-01-26

(54)【発明の名称】クラウドプラットフォームでアプリケーションをコンテナ化する方法

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20220119BHJP

   G06F 9/455 20060101ALI20220119BHJP

   G06F 9/50 20060101ALI20220119BHJP

【ＦＩ】

G06Q50/10

G06F9/455 150

G06F9/50

【請求項の数】 1

(21)【出願番号】P 2020509408

(86)(22)【出願日】2018-04-30

(65)【公表番号】

(43)【公表日】2020-07-09

(86)【国際出願番号】 KR2018004992

(87)【国際公開番号】W WO2018203635

(87)【国際公開日】2018-11-08

【審査請求日】2019-10-28

(31)【優先権主張番号】10-2017-0056483

(32)【優先日】2017-05-02

(33)【優先権主張国・地域又は機関】KR

(73)【特許権者】

【識別番号】519385629

【氏名又は名称】ナム テク カンパニー リミテッド

【氏名又は名称原語表記】ＮＡＭＵ ＴＥＣＨ ＣＯ．， ＬＴＤ．

(73)【特許権者】

【識別番号】519385630

【氏名又は名称】アコーンソフト カンパニー リミテッド

【氏名又は名称原語表記】ＡＣＯＲＮＳＯＦＴ ＣＯ．， ＬＴＤ．

【住所又は居所原語表記】４Ｆ（Ｙｅｏｋｓａｍ－ｄｏｎｇ）２３９，Ｙｅｏｋｓａｍ－ｒｏ，Ｇａｎｇｎａｍ－ｇｕ，Ｓｅｏｕｌ ０６２２５，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ

(74)【代理人】

【識別番号】100130111

【弁理士】

【氏名又は名称】新保 斉

(72)【発明者】

【氏名】キム、イン ソク

【審査官】谷川 智秀

(56)【参考文献】

【文献】米国特許出願公開第２０１６／０２７４９２８（ＵＳ，Ａ１）

【文献】特開２０１１－２３３１４６（ＪＰ，Ａ）

【文献】特表２０１４－５２７２２１（ＪＰ，Ａ）

【文献】特表２０１５－５０７２２９（ＪＰ，Ａ）

【文献】白石 昌靖，今さら聞けないプライベートクラウドの基本 （第３回）設計時に留意すべきポイント ライフサイクルの意識が必要，日経コンピュータ，No.828，日経BP社，2013年02月21日，pp.94-97，ISSN:0285-4619

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

Ｇ０６Ｆ ９／４５５

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

入出力手段・演算手段・記憶手段・通信手段を備えネットワークを介して相互接続されたクラウド統合部(Cloud Integration)・サービス管理部(Service Management)・アプリケーションオーケストレーション部(Orchestration)・開発/運営部(DevOps View)及びＤＢ/保存所を備えたクラウドプラットフォームシステムにおいて、
前記クラウド統合部(Cloud Integration)は、
アプリケーションクラスタ(カクテルクラスタ)にクラウドネットワークインフラデータを構成及び提供し、アプリケーションにクラウドのコンピューティングインフラデータを構成及び提供するクラウドプロビジョニング手段と、
クラウドインフラ構成データを統合構成ＤＢに提供して保存及び管理し、運営時インフラ変更データを統合構成ＤＢと同期化するクラウド同期化手段とを備えて、
マルチ/ハイブリッドクラウドのインフラを構成してアプリケーションに提供し、管理のための構成情報を同期し、
前記サービス管理部(Service Management)は、
マルチクラウドアカウントデータ及び接続情報データを統合管理し、ネットワークとクラウドプロビジョニング構成に用いる統合アカウント管理(Cloud Provider)手段と、
クラウドネットワークを構成してサービスに割り当てるネットワーク管理手段と、
サービスを管理するチーム構成員データと開発/運営に関わる権限データを管理する使用者管理手段とを備えて、
アプリケーションクラスタを管理する論理的グループでクラウドアカウントと使用者、ネットワーク資源を割り当て及び管理し、
前記アプリケーションオーケストレーション部(Orchestration)は、
アプリケーションをコンテナ化して、アプリケーションプロセスにホスト資源を割り当てて隔離して仮想化したＯＳ上の独立システムであるアプリケーションコンテナを配布して、クラウドインフラをプロビジョニングするアプリケーション配布(Deployment)手段と、
アプリケーションコンテナヘルスチェック(Health Check)手段を通じてアプリケーションを複製する複製(Replication Control) 手段と、
開発/運営部（DevOps View）の作業(job)管理機能を通じてアップデートを遂行するローリングアップデート(Rolling Update) 手段と、
アプリケーションのモニタリングを通じてインストンス(コンテナ及びインフラ)のスケーリングをイン(In)/アウト(Out)し、アプリケーションインフラの資源容量のスケールをアップ(Up)/ダウン(Down)するスケーリング(Scaling) 手段と、
アプリケーションインストンスをモニタリングし、臨界値設定を通じたアラームを発生及び管理するモニタリング(Monitoring) 手段を備えて、
アプリケーションの配布と可用性・拡張性を保障する構成を有し、
前記クラウド統合部(Cloud Integration)により、既存アプリケーションのうちでコンテナ転換対象を選定する段階と、
前記対象アプリケーションが選定されれば、対象アプリケーションに関し、開発及び運営・管理者からの要求入力データを収集する段階と、
ベースイメージ・環境変数・包含項目・コメンドを含むイメージビルドテンプレートを定義して前記対象アプリケーション別コンテナ構成を設計する段階と、
転換インフラ(クラウド/ベアメタル)供給者を選定し、アプリケーションコンテナ別容量を算定して、コンテナクラスタノード数及びインフラ容量を算定し、ストレージ・ネットワーク・保安構成を含むインフラ構成を設計する段階と、
前記インフラ構成が設計されれば、アプリケーション別転換詳細方案を樹立し、転換業務及び組織/役割を定義し、転換日程を樹立するコンテナ転換方案を樹立する段階と、
コンテナ転換のために、事前テスト(PoC)、アプリケーション別段階的転換を繰り返し切り替える段階と、
カクテルクラウドプラットフォームを設置及び構成し、基盤インフラ割り当て及び使用者登録を通じてカクテルクラスタを構成する段階と、
データ転換のために対象アプリケーションコンテナを切り替え、持続性（Persistence）ボリューム設定を通じてカクテルサーバーを設定し、データを抽出して前記カクテルサーバーに送ってデータを切り替える段階と、
検証されたカクテルコンテナを前記カクテルサーバーに配布し、アプリケーションをテスト実行する段階と、
運営移管のために、物理/仮想インフラに管理クラスタ(Managed Cluster)を構成してアプリケーションコンテナを配布・運営・管理するコンテナオーケストレーション(Orchestration)により、運営カクテルクラスタを生成して転換し、カクテルサーバーを生成して連携構成し、運営データを移管してアプリケーションを運営配布/オープンする段階と、
クラウドモニタリングビューを通じてアプリケーション及びインフラ運営モニタリングを行う段階と、
コンテナ移管結果データを前記開発/運営に関わる権限データを管理する使用者へ出力する段階と、を含む
ことを特徴とするクラウドプラットフォームでアプリケーションをコンテナ化する方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、クラウドプラットフォームでアプリケーションをコンテナ化する方法に関するものであり、より詳細には、隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上の多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、少ない大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能なクラウドプラットフォームでアプリケーションをコンテナ化する方法に関するものである。

【背景技術】

【0002】

クラウド(Cloud)はコンピューティングサービス事業者サーバーを雲の模様で表示する慣行によって‘サービス事業者のサーバー'に通じる。ソフトウェアとデータをインターネットと連結された中央コンピューターに保存してインターネットに接続さえすればいつどこでもデータを利用するようにするものである。

【0003】

このようなクラウドはサービス提供形態によってSalesforce.com・Google e-mailなどのように複数の使用者にオンデマンド(On-demand)で提供されるアプリケーションサービスであるSoftware as a Service(SaaS)、ＡＷＳＲＤＳ・Google App Engineなどのように開発用プラットフォームまたはアプリケーション実行に必要なソフトウェアスタックであるPlatform as a Service(PaaS)、ＡＷＳ ＥＣ２などのようにサーバーまたはストレージなどを使用者にサービス形態で提供するInfrastructure as a Service(ＩａａＳ)などで分けることができる。

【0004】

また、クラウドは導入と配布形態によって単に一つの団体のみのために運営されるプライベートクラウド(Private cloud)、公開的利用のために開かれたネットワークを通じてレンダリングされるパブリッククラウド(Public cloud)、明らかな実体は維持するが共に縛られているふたつ以上のクラウドの組合であるハイブリッドクラウド(Hybrid cloud)などでも分けることができる。

【0005】

一方、エンタープライズクラウド(Enterprise Cloud)場合企業のビジネスとＩＴ戦略を具現したクラウドでアプリケーションサービスを中心に技術とインフラをオーダーメード化して最適化することが何より重要であり、またアプリケーションを多様なインフラに構成するか、または配布することに容易でなければならない。

【発明の開示】

【発明が解決しようとする課題】

【0006】

これに本発明はこのような前記問題点を解決するために創出されたものであり、隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、少ない大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能なクラウドプラットフォームでアプリケーションをコンテナ化する方法を提供することにその目的がある。
本発明の技術的課題らは上で言及した課題らで制限されないし、言及されなかったまた他の技術的課題らは下の記載から当業者に明確に理解されることができる。

【課題を解決するための手段】

【0007】

本発明の実施例によるクラウドプラットフォームでアプリケーションをコンテナ化する方法はクラウドプラットフォームシステムがコンテナ/クラウド導入目的と戦略を考慮して既存アプリケーションのうちでコンテナ転換対象を選定する段階と、前記対象アプリケーションが選定されれば前記クラウドプラットフォームシステムが対象アプリケーションを分析する段階と、前記クラウドプラットフォームシステムが分離/統合・連携・可用性・拡張性・保安などを考慮して前記対象アプリケーション別コンテナ構成を設計する段階と、前記クラウドプラットフォームシステムがインフラ構成を設計する段階と、前記インフラ構成が設計されれば、前記クラウドプラットフォームシステムがコンテナ転換方案を樹立する段階と、前記クラウドプラットフォームシステムが事前テスト(PoC)・アプリケーション別段階的転換など繰り返し的で漸増的に切り替える段階と、前記クラウドプラットフォームシステムがクラスタを構成する段階と、前記クラウドプラットフォームシステムがアプリケーションコンテナを構成し、必要時アプリケーション設定及びソースを変更してアプリケーションを切り替える段階と、前記クラウドプラットフォームシステムが対象アプリケーションコンテナを切り替えて、Persistenceボリューム設定などを通じてサーバーを設定し、データを抽出して前記サーバーに送ってデータを切り替える段階と、前記クラウドプラットフォームシステムが検証されたコンテナを前記サーバーに配布し、アプリケーション機能及び性能テストを遂行し、コンテナ及びインフラにテスト結果を反映する段階と、前記クラウドプラットフォームシステムが運営クラスタを生成して転換完了したイメージを基盤で前記サーバーを生成して連携構成し、運営データを移管してアプリケーションをオープンする段階と、前記クラウドプラットフォームシステムがクラウドモニタリングビューを通じてアプリケーション及びインフラ運営モニタリングを遂行して性能イシュー及びエラーを反映する段階と、及び前記クラウドプラットフォームシステムがコンテナ移管結果をレポートして開発、運営体系移管及び適用する段階を含む。

【0008】

前記対象アプリケーションを分析する段階は前記クラウドプラットフォームシステムがアプリケーション・インフラ・データ・連携構造などのアプリケーション現況及び資料調査をして開発及び運営、管理者の要求を収集し、コンテナ構成方向・イシュー及び解決方案を導出する段階を含むことができる。

【0009】

前記対象アプリケーション別コンテナ構成を設計する段階は前記クラウドプラットフォームシステムがベースイメージ・環境変数・包含項目・コメンドなどのイメージビルドテンプレートを定義する段階を含むことができる。

【0010】

前記インフラ構成を設計する段階は前記クラウドプラットフォームシステムが転換インフラ(クラウド/ベアメタル)供給者を選定し、アプリケーションコンテナ別容量を算定し、コンテナクラスタノード数及びインフラ容量を算定し、ストレージ・ネットワーク・保安構成を設計する段階を含むことができる。

【0011】

前記コンテナ転換方案を樹立する段階は前記クラウドプラットフォームシステムがアプリケーション別転換詳細方案を樹立し、転換業務及び組織/役割を定義し、転換日程を樹立し、報告及びフィードバックを反映する段階を含むことができる。

【0012】

前記クラスタを構成する段階は前記クラウドプラットフォームシステムがクラウドプラットフォームを設置及び構成し、ネットワーク・共有ストレージ・保安など基盤インフラを構成し、基盤インフラ割り当て及び使用者登録を通じてサービスとクラスタを生成し、クラスタ構成を検証する段階を含むことができる。

【0013】

前記アプリケーションを切り替える段階は前記クラウドプラットフォームシステムが転換コンテナの機能及び設定などを検証し、コンテナ配布イメージビルド及びレジストリに登録し、前記サーバーを生成してテストする段階を含むことができる。

【0014】

前記データを切り替える段階は前記クラウドプラットフォームシステムがこの機種ＤＢソリューション適用の場合データ変換を遂行し、データ整合性を確認し、運営アプリケーションの場合ダウンタイムを最小化するためにデータ同期化ソリューションを適用する段階を含むことができる。

【発明の効果】

【0015】

本発明によるクラウドプラットフォームでアプリケーションをコンテナ化する方法は隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上の多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、小さい大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能な効果を有する。

【図面の簡単な説明】

【0016】

【図1】本発明の一実施例によるクラウドプラットフォームシステムの構成図

【図2】図１のクラウド統合部の機能を簡略に示した説明図

【図3】図１のサービス管理部の機能を簡略に示した説明図

【図4】図１のアプリケーションオーケストレーション部の機能を簡略に示した説明図

【図5】本発明の一実施例によるアプリケーションコンテナ化のフレームワークを示す説明図

【図6】図１の開発/運営部の機能を簡略に示した説明図

【図7】図１の開発/運営部の機能を簡略に示した説明図

【図8】図１の開発/運営部の機能を簡略に示した説明図

【図9】図１の開発/運営部の機能を簡略に示した説明図

【図10】図１の開発/運営部の機能を簡略に示した説明図

【図11】図１の開発/運営部の機能を簡略に示した説明図

【図12】本発明の一実施例によるクラウドプラットフォームシステムのアーキテクチャーを示す説明図

【図13】カクテルサーバーの構成とその周辺アーキテクチャーを示す説明図

【発明を実施するための最良の形態】

【0017】

本発明の長所及び特徴そして、それらを達成する方法らは添付される図面と共に詳細に後述されている実施例らを参照すれば明確になる。しかし、本発明は以下で開示される実施例らに限定されるものではなく、また他の多様な形態で具現されることができるし、単に本実施例らは本発明の開示が完全であるようにし、本発明が属する技術分野で通常の知識を有した者に発明の範疇を完全に知らせてくれるために提供されるものであり、本発明は単に請求項によって定義されるだけである。

【0018】

明細書全体にかけて同一参照符号は同一構成要素を指称する。
以下、添付された図面らを参考して本発明の実施例によるクラウドプラットフォームシステムに対して説明するようにする。

【0019】

図１は本発明の一実施例によるクラウドプラットフォームシステムの構成図を示し、図２は図１のクラウド統合部の機能を簡略に示した図であり、図３は図１のサービス管理部の機能を簡略に示した図であり、図４は図１のアプリケーションオーケストレーション部の機能を簡略に示した図である。図５は本発明の一実施例によるアプリケーションコンテナ化のフレームワークを示した図であり、図６乃至図１１は図１の開発/運営部の機能を簡略に示した図である。

【0020】

図１のクラウドプラットフォームシステムはマルチ/ハイブリッドクラウド統合管理を基盤でアプリケーション可用性・拡張性を保障して開発・運営の効率化のためのビューと道具を提供する。以下、本発明のクラウドプラットフォームシステムを“カクテルクラウド(Cocktail Cloud)”と称する。

【0021】

図１を参照すれば、カクテルクラウドはクラウド統合部(Cloud Integration)１００・サービス管理部(Service Management)１１０・アプリケーションオーケストレーション部(Orchestration)１２０・開発/運営部(DevOps View)１４０及びＤＢ/保存所１５０を含む。

【0022】

クラウド統合部(Cloud Integration)１００はマルチ/ハイブリッドクラウドのインフラを自動構成してアプリケーションに提供し、管理のための構成情報を同期化する役割を遂行する。

【0023】

クラウド統合部１００はクラウドプロビジョニング(Cloud Provisioning)とクラウド同期化(Cloud Synchronization)の機能を遂行する。

【0024】

図２を参照すればクラウドプロビジョニング機能はアプリケーションクラスタ(カクテルクラスタ)にクラウドネットワークインフラを構成及び提供し、アプリケーションにクラウドのコンピューティングインフラを構成及び提供する機能である。そして、物理インフラ(Bare Metal)の場合クラスタ設定道具を提供する。サポートクラウドはPublicの場合ＡＷＳ・Azure・Aliyun・Google Computing Engineであり、Privateの場合Openstack・VMWearであり、以外にOn-premise・Datacenter Bare Metal Infraがあることができる。

【0025】

クラウド同期化機能はクラウドインフラ構成情報を統合構成ＤＢ１６０に保存及び管理し、運営時インフラ変更情報を統合構成ＤＢ１６０と同期化する機能である。

【0026】

サービス管理部(Service Management)１１０はアプリケーションクラスタを管理する論理的グループでクラウドアカウントと使用者、ネットワーク資源を割り当て及び管理する役割を遂行する。すなわち、サービス管理部１１０は統合アカウント管理機能・ネットワーク管理機能及び使用者管理機能を遂行する。

【0027】

図３を参照すれば統合アカウント管理(Cloud Provider)機能はマルチクラウドアカウント及び接続情報を統合管理し、ネットワークとクラウドプロビジョニング構成に使用される機能である。

【0028】

ネットワーク管理機能はクラウドネットワークを構成してサービスに割り当てる機能である。例えば、ＡＷＳのVPC・Subnetであることがある。一つのサービスはマルチクラウドの供給者のネットワークを使ってクラスタを生成してアプリケーションを構成・運営する。

【0029】

使用者管理機能はサービスを管理するチーム構成員と開発/運営に必要な権限を管理する機能である。ここで、権限は全社サービス管理権限(Admin)、全社サービス照会権限(Manager)、構成員で割当されたサービス管理権限(DevOps)などを含むことができる。使用者は多くのサービスに構成員で参加可能である。

【0030】

アプリケーションオーケストレーション部(Orchestration)１２０はアプリケーションの配布と可用性・拡張性を保障する機能でカクテルクラスタ(Cluster)の核心機能を担当する。

【0031】

アプリケーションオーケストレーション部１２０はアプリケーション配布(Deployment)機能・複製(Replication Control)機能・ローリングアップデート(Rolling Update)機能・スケーリング(Scaling)機能及びモニタリング(Monitoring)機能を遂行する。

【0032】

図４を参照すればアプリケーション配布機能は、コンテナイメージ基盤の配布で別途設定と構成作業が必要ない容易性を提供し、アプリケーション配布時クラウドインフラを自動プロビジョニングする機能である。

【0033】

ここで、アプリケーションはコンテナ化されて配布されるようになるが、アプリケーションコンテナ(以下、“コンテナ”と称する)はアプリケーションプロセスにホスト資源を割り当てて隔離して仮想化したＯＳ上の独立システムを言う。

【0034】

コンテナに使用される核心技術は、Linux（登録商標）のcgroup(control group)とnamespaceである。cgroupはＯＳ上のプロセスにホスト資源を割り当てるために該当プロセスグループを作って資源の割り当て及び管理を遂行する。namespaceはプロセス・ネットワーク・マウンド(mount)などを特定name spaceで隔離する技術である。これによってコンテナはcgroupを通じてアプリケーションプロセスに資源を割り当て、namespaceで隔離したＯＳ上に仮想化された独立システムを言う。

【0035】

コンテナはハイパーバイザー(Hardware emulator)とゲストＯＳを使用しない軽いＯＳ仮想化方式でホスト資源の消耗量がほとんどなく、機動にかかる時間が非常に少なくてアプリケーション仮想化に好適な技術である。また、ＯＳ上の仮想化で既存物理サーバー(Bare Metal)・仮想サーバー(Virtual Machine)などインフラに独立的な構成と配布が可能である。

【0036】

このように既存または新規アプリケーション構成をコンテナで切り替えるためには、コンテナ化(Containerization)過程が隋伴されなければならない。そして、これによる開発・テスト・運営方式の転換及び運営インフラ構成(カクテルクラウドプラットフォーム)最適化作業を並行しなければならない。

【0037】

既存アプリケーションをコンテナで切り替えるためにはアプリケーションの設定及びソースではない構成の転換が必要であり、配布と運営効率を考慮する時ワークロード(Workload)中心の役割別独立的構成が一般的であり、複製を通じた多重化とスケーリングを考慮した構成が設計されて適用されなければならないであろう。

【0038】

アプリケーション開発・テスト・運営方式の転換のためにはイメージ基盤のアプリケーションビルド・テスト・配布とベースイメージを通じたアプリケーション構成が標準化されなければならないであろう。

【0039】

アプリケーションコンテナ運営インフラ構成最適化のためにはコンテナオーケストレーションのためのクラスタ中心のインフラが構成され、複製・スケーリングを考慮したコンピュータ容量が算定(予備容量最小化、必要時拡張容易)されなければならないし、共有ストレージ・保安・ネットワークなど関連インフラを構成しなければならないであろう。

【0040】

図５を参照すればコンテナ化は大きく分析及び構成設計(Ｓ１００)・コンテナ転換(Ｓ２００)・運営移管(Ｓ３００)で区分される。

【0041】

分析及び構成設計(Ｓ１００)のためにコンテナ/クラウド導入目的と戦略を考慮して既存アプリケーションのうちでコンテナ転換対象を選定する(Ｓ１１０)。

【0042】

対象アプリケーションが選定されれば対象アプリケーションを分析する(Ｓ１２０)。この時、アプリケーション・インフラ・データ・連携構造などのアプリケーション現況及び資料調査をし、開発及び運営・管理者の要求を収集する。そして、コンテナ構成方向・イシュー及び解決方案を導出する。

【0043】

そして、分離/統合・連携・可用性・拡張性・保安などを考慮して対象アプリケーション別コンテナ構成を設計する(Ｓ１３０)。この時、ベースイメージ・環境変数・包含項目・コメンドなどのイメージビルドテンプレートを定義することができる。

【0044】

その後、インフラ構成を設計する(Ｓ１４０)。転換インフラ(クラウド/ベアメタル)供給者を選定し、アプリケーションコンテナ別容量を算定する。そして、コンテナクラスタノード数及びインフラ容量を算定し、ストレージ・ネットワーク・保安構成を設計する。

【0045】

インフラ構成が設計されればコンテナ転換方案を樹立する(Ｓ１５０)。この時、アプリケーション別転換詳細方案を樹立し、転換業務及び組織/役割を定義し、転換日程を樹立する。そして、報告及びフィードバックを反映する。

【0046】

コンテナ転換(Ｓ２００)のためには繰り返し/漸増的転換(Ｓ２１０)が必要である。事前テスト(PoC)、アプリケーション別段階的転換など繰り返し的で漸増的に切り替える。

【0047】

そして、カクテルクラスタを構成(Ｓ２２０)するためにカクテルクラウドプラットフォームを設置及び構成し、ネットワーク・共有ストレージ・保安など基盤インフラを構成する(クラウドの場合カクテルでプロビジョニング)。基盤インフラ割り当て及び使用者登録を通じてカクテルサービスとクラスタを生成し、クラスタ構成を検証する。

【0048】

そして、アプリケーション転換(Ｓ２３０)のためにアプリケーションコンテナを構成し、必要時アプリケーション設定及びソースを変更する。転換コンテナの機能及び設定などを検証し、コンテナ配布イメージビルド及びレジストリに登録する。そして、カクテルサーバーを生成してテストする。

【0049】

データ転換(Ｓ２４０)のために対象アプリケーションコンテナを切り替え、Persistenceボリューム設定などを通じてカクテルサーバーを設定し、データを抽出してカクテルサーバーに送る。この機種ＤＢソリューション適用の場合データ変換を遂行し、データ整合性を確認する。運営アプリケーションの場合ダウンタイムを最小化するためにデータ同期化ソリューションを適用する。

【0050】

その後検証されたコンテナをカクテルサーバーに配布し、アプリケーション機能及び性能テストを遂行し、コンテナ及びインフラにテスト結果を反映する(Ｓ２５０、Ｓ２６０)。

【0051】

運営移管(Ｓ３００)のために運営配布/オープン(Ｓ３１０)が遂行されるが、具体的に運営カクテルクラスタを生成して転換完了したイメージを基盤でカクテルサーバーを生成して連携構成する。そして、運営データを移管してアプリケーションをオープンする。このようなアプリケーションコンテナを配布・運営・管理する技術をコンテナオーケストレーション(Orchestration)と称する。

【0052】

コンテナオーケストレーションは物理/仮想インフラに管理クラスタ(Managed Cluster)を構成してアプリケーションコンテナを配布・運営・管理する技術であり、コンテナの軽くて早い起動性と移動性の長所を活用して既存社内、データセンターインフラのクラウド化とプライベート/パブリッククラウドのアプリケーション管理プラットフォームに拡散している。

【0053】

カクテルクラウドモニタリングビューを通じてアプリケーション及びインフラ運営モニタリングを遂行して性能イシュー及びエラーを反映する(Ｓ３２０)。

【0054】

開発・運営体系移管及び適用(Ｓ３３０)のためにコンテナ移管結果をレポートし、担当開発及び運営組織にコンテナ基盤開発/運営体系教育を実施し、カクテルクラウドプラットフォーム使用教育を実施する。

【0055】

これによってコンテナは次のような長所を有する。
第一、コンテナは独立性を有する。

【0056】

隔離されたアプリケーション実行環境であり、独立的な資源が割り当てされて(CPU、Memory、Disk、Networkなど)、同一ホスト上の多重アプリケーションが運営される。
第二、コンテナは軽い仮想化を具現する。

【0057】

ＯＳ水準の仮想化(Non Hypervisor)が可能であり、早い操作が可能であり(生成・実行・再起動など)、少ない大きさのコンテナイメージで配布及びアップデートが効率的である。
第三、コンテナは移動性を有する。

【0058】

インフラは独立的イメージを有して、ベアメタル(Bare Metal)・仮想マシン(Virtual Machine)・クラウド(Cloud)など、どこでも移動が可能であり、イメージレジストリを通じたオンライン配布及びバージョン管理が可能であり、主要ホストＯＳ(Linux（登録商標）系列、Windows)を支援する。このようなコンテナの移動性はマルチ/ハイブリッドクラウド環境下にアプリケーション運営/開発の生産性及び効率を高め、特に、規格化されたコンテナイメージで異種のインフラにアプリケーション配布及び以前の難しさを解決し、特定クラウドに従属されるロックイン(Lock-in)問題を解決してくれる。

【0059】

複製機能はアプリケーション安全性と可用性のために初期指定した複製数(多重化)を維持し、アプリケーションコンテナヘルスチェック(Health Check)を通じて異常時に再起動する方式でＯＳ再起動方式より早くて効率的である。複製されたアプリケーションはロードバランシングを通じてサービスされる。

【0060】

ローリングアップデート機能はアプリケーションサービスの中断なしに配布・インフラ変更などのアップデート作業を遂行し、多くのアプリケーション間の依存性がある場合DevOps Viewの作業(job)管理機能を通じて自動化を構成する機能である。

【0061】

スケーリング機能はアプリケーションのモニタリングを通じてインストンスのスケーリングをイン(In)/アウト(Out)し、アプリケーションインフラの場合資源容量のスケールをアップ(Up)/ダウン(Down)する機能である。そして、モニタリング情報を通じてスケーリング自動化を構成する。

【0062】

モニタリング機能はアプリケーションインストンス(コンテナ+インフラ)をモニタリングし、臨界値設定を通じたアラームを発生及び管理する機能である。

【0063】

開発/運営部(DevOps View)１４０はサービス現況機能、クラスタマップ機能、モニタリングビュー機能、リソース管理機能、メータリング機能、作業管理機能、及び全社現況管理/分析機能を含む。それぞれの機能を図６乃至図１１を参照して説明すれば次のようである。

【0064】

サービス現況機能はカクテルクラウドの全体アプリケーションクラスタの現況をサービス中心に把握することができるビュー(図６参照)を提供する。これにサービス現況・クラスタ現況・モニタリングアラームなどの項目が表示されることができる。

【0065】

サービス現況ではカクテルクラウドの全体サービス現況を照会することができるし、サービス内のクラスタの構成現況を総合してクラウド供給者・クラスタ・サーバー・クラウドコンポネント・現在月使用費用などを把握することができる。ここで、クラスタはアプリケーションの構成単位を意味し、サービスはクラスタの論理的グループを意味する。

【0066】

クラスタ現況ではクラスタの供給者・リージョン・サーバー・クラウドコンポネント・月使用費用をカード形態で照会可能であり、物理(Bare Metal)クラスタの場合使用費用は除かれることができる。

【0067】

モニタリングアラーム表示機能ではクラスタ内のアプリケーションとインフラでアラームが発生した場合、クラスタカードで確認が可能である。

【0068】

クラスタマップ機能はカクテルサーバー(アプリケーション)の構成と状態情報をマップ形態で視覚化して管理することができるビューを提供する(図７参照)。

【0069】

クラスタマップはクラスタのサーバーとクラウドコンポネント構成をマップ形態で照会/管理して構成情報の可視性を高める。クラスタマップではカクテルサーバー・クラウドコンポネント・サーバーグループなどの項目を含むことができる。

【0070】

カクテルサーバーはアプリケーションオーケストレーションの基本単位でロードバランシング・アプリケーションコンテナ・インフラで構成され、マルチ/ハイブリッドクラウド管理に標準化されたインターフェースを提供する。カクテルサーバーはサーバー内のアプリケーション状態と複製、資源使用量を確認し、スケーリング・ローリングアップデートなどを管理遂行する。カクテルサーバーは複製機能の有無によってマルチとシングルインストンスタイプで区分される。ＡＷＳではマルチゾーンオプションを支援する。

【0071】

クラウドコンポネントは供給者が提供するPaaSサービスを管理する。例えば、ＡＷＳのＤＢサービスであるＲＤＳであることができる。
サーバーグループはサーバー構成の論理的グループの管理的便宜性を提供する。

【0072】

モニタリングビュー機能はクラスタ内のアプリケーションとインフラの資源容量と状態を確認し、クラウドリソースの状態を確認することができる情報を提供する(図８参照)。

【0073】

モニタリングビューはクラスタ内のアプリケーションとインフラに対するモニタリング情報を視覚化して提供し、CPU・メモリー・ディスクの平均・ＴＯＰ情報提供で資源の使用量を確認して運営で対応されるようにする。
モニタリングビューはビュー転換(トレンド/データ)項目、対象転換(サーバー/リソース)項目などを含むことができる。

【0074】

ビュー転換項目でトレンドビューはサーバーと複製されたインストンス・アプリケーションコンテナに対する時間別モニタリング情報を提供し、データビューは現在時間の平均・ＴＯＰモニタリング数値を提供する。

【0075】

対象転換項目でモニタリング対象はクラスタ内のサーバーとクラウドインフラのリソースで区分される。クラウドリソースは供給者が提供する情報を使用する。

【0076】

リソース管理機能はアプリケーションを構成するクラウドインフラのリソースを確認し、必要時詳細設定を調整することができるビュー(以下、“リソース管理ビュー”と称する)を提供する(図９参照)。

【0077】

リソース管理ビューはカクテルサーバーを構成するクラウドインフラリソースを確認して設定を詳細に変更することができる。ここで、カクテルサーバーはアプリケーションオーケストレーションのための基本構成を自動で遂行するが、必要な場合直接クラウドリソースを調整する必要がある時に使用される。

【0078】

リソース管理ビューはリソース情報/アクション項目を含むが、リソース情報のうちでアプリケーションはコンテナ設定と配布情報を管理する。クラウドリソース情報はロードバランサー・インストンス(VM)・保安で構成され、インストンスは容量とボリュームを管理する。調整が必要なリソース情報はアクションを通じて遂行される。

【0079】

メータリング機能はアプリケーションが使用するクラウドインフラリソースの費用情報を確認することができるビュー(以下、“メータリングビュー”と称する)を提供する(図１０参照)。メータリングビューはクラスタインフラ使用費用項目・サーバー・リソース別費用項目などを含むことができる。

【0080】

クラスタインフラ使用費用項目ではクラスタとカクテルサーバーが使用するクラウドリソースの費用現況を確認することができるし、前月・現在月費用情報と翌月推定費用を提供する。また、月別で費用増減推移グラフを提供する。

【0081】

サーバー・リソース別費用項目はカクテルサーバー別に使用するクラウドリソース費用をＴＯＰを基準で提供し、クラウドリソース種類別に使用する費用をＴＯＰを基準で提供する。

【0082】

作業管理機能は配布・遠隔命令・リソース管理などの運営作業をスケジューリング/自動化することができる管理ビュー(以下、“作業管理ビュー”と称する)を提供する(図１１参照)。

【0083】

作業管理ビューはアプリケーションとインフラの運営のためのスケジューリング及び一括処理機能を提供する。このような作業管理ビューは作業現況項目、作業管理項目などを含むことができる。

【0084】

作業管理ビューで作業現況項目は配布・遠隔命令語・リソース管理タスクで区分し、各タスクを組み合わせて構成される。ここで、配布はアプリケーション配布、遠隔命令語はＯＳ命令語を遠隔で遂行、リソース管理はスケーリング、状態/設定変更を意味する。

【0085】

作業管理ビューで作業管理項目は直ちに遂行・スケジューリング・アラーム発生によって遂行方式を設定することができる。アラーム発生による遂行は容量モニタリングの基準値による自動スケーリングなどで使用される。作業管理項目で作業の実行状態とログ確認を提供する。

【0086】

全社現況管理/分析機能は全社アプリケーション・クラウド・費用現況を把握して分析することができるカクテルダッシュボード(Dashboard)を提供する。

【0087】

カクテルダッシュボードは全社次元でアプリケーションとクラウドインフラの現況を照会し、費用/予算管理、費用最適化分析、統計レポートを提供するビューである。このようなカクテルダッシュボードはアプリケーション現況項目、クラウド現況項目、費用/予算管理、費用最適化分析項目、統計/レポート項目を含むことができる。

【0088】

アプリケーション現況項目を通じてカクテルサーバー・クラスタ・クラウドコンポネントの標準化された要素を基準でアプリケーションとインフラ現況を全社的に把握して照会することができるし、サービス中心の現況ビューを提供する。

【0089】

クラウド現況項目を通じて全社で使用するクラウドを供給者・リージョン・リソース別に現況を把握することができるし、インフラ中心の現況ビューを提供する。

【0090】

費用/予算管理、費用最適化分析項目を通じて全社クラウド費用現況を把握し、サービス別予算割り当て/統制と最適化分析を通じてクラウドリソース費用効率化ができる情報を提供する。
統計/レポート項目は分析及び報告に必要な統計情報とレポートビューを提供する。

【0091】

ＤＢ/保存所１５０でイメージ保存所(レジストリ)１８０はアプリケーションコンテナの登録・共有・ダウンロード・検索・バージョンを管理し、モニタリングＤＢ１７０はアプリケーションとインフラのモニタリング情報を管理し、統合構成ＤＢ(Configuration Management ＤＢ、ＣＭＤＢ)１６０はプロバイダー・ネットワーク・サービス・クラスタ・サーバー・コンポネント・クラウドリソースの構成情報を管理する。

【0092】

図１２は本発明の一実施例によるクラウドプラットフォームのアーキテクチャーを示し、図１３はカクテルサーバーの構成とその周辺アーキテクチャーを示す。

【0093】

図１２を参照すればカクテルクラウドはカクテルクラスタ２００、プロバイダープラグイン２１０、サーバーマネージャー２２０、DevOpsマネージャー、ＣＭＤＢ１６０、モニタリングＤＢ１７０、イメージレジストリ１８０、ＡＰＩサーバー２９０、使用者コンソール３００を含む。

【0094】

カクテルクラスタ２００はオーケストレーション基盤アーキテクチャーを提供し、プロバイダープラグイン２１０はクラウド供給者ＡＰＩ２８０を通じて統合管理のための基本モジュールで使用される。

【0095】

クラスタ２００はノードとマスターで構成され、ノードの場合ワーカー(worker)３１０を通じてマスターの命令語を処理する構造である。ワーカー３１０はマスターとの通信を担当し、遂行命令語によってExecutorが支援される。Monitoring Executor３２０はノードとコンテナモニタリング情報を収集し、Command Executor３３０はＯＳとコンテナ命令を遂行する。その外にContainer Engine(Docker)３４０がある。

【0096】

プロバイダープラグイン２１０はマルチクラウドとBare MetalのためのKubernetes ＡＰＩ支援のためのＡＰＩ Rapperであり、プロバイダー拡張のためのプラグインモジュールで構成される。

【0097】

カクテルサーバーはアプリケーションオーケストレーションの基本単位であり、クラスタマスター２００とプロバイダープラグイン２１０を通じてコンテナとクラウドインフラの複製・スケーリング・ローリングアップデートを遂行する。

【0098】

カクテルサーバーは図１３に示されたようにコンテナとクラウドインフラで構成されるが、ロードバランサー・インストンス(ノード)・コンテナ・ボリューム・保安などで構成され、ＡＷＳの例を挙げると、ELB・EC２ Instance・ Security Group・ESBであることができる。カクテルサーバーはクラウド提供者のPaaSのためにクラウドコンポネントを提供する。例えば、ＡＷＳのＲＤＳであることができる。

【0099】

サーバーマネージャー２２０はサーバー内のアプリケーションコンテナとインフラのオーケストレーションを遂行する制御モジュールとして、非正常終了されたコンテナを再起動/復旧する複製制御、スケールイン/アウトとインストンスタイプとボリューム拡張を通じたアップダウンを遂行するスケーリング、アプリケーションコンテナ配布を順次に無中断で遂行するローリングアップデート機能を提供する。

【0100】

DevOpsマネージャーはマルチクラウドインフラプロビジョニングのための構成管理(Configuration Manager)２３０、マルチクラウド資源の使用量及び費用管理のためのメータリング管理(Metering Manager)２４０、マルチクラウド資源現況及び設定管理のための資源管理(Resource Manager)２５０、コンテナ/インフラモニタリング情報収集及び管理のためのモニタリング管理(Monitoring Manager)２６０、多くの作業タスクを結合して一括遂行し、直ちに遂行・遂行時間・イベント発生が遂行条件であり、配布・サーバーアクション・遠隔命令語のタスクのための作業管理(Job Manager)２７０を提供するものとしてDevOpsのためのマネージャーモジュールである。

【0101】

カクテルクラウドはアプリケーションとインフラの構成情報管理・モニタリング情報管理・アプリケーションコンテナイメージ管理のためのＤＢを提供し、使用者とプログラミングのためのインターフェースを提供する。

【0102】

ＣＭＤＢ１６０はプロバイダー・ネットワーク・サービス・クラスタ・サーバー・コンポネント・クラウドリソースの構成情報を管理する。
モニタリングＤＢ１７０はアプリケーションとインフラのモニタリング情報を管理する。
イメージレジストリ１８０はアプリケーションコンテナの登録・共有・ダウンロード・検索・バージョンを管理する。

【0103】

ＡＰＩサーバー２９０はカクテルクラウドのすべての機能をＡＰＩ２８０で提供し、企業戦略によるオーダーメード化と他のソリューションとの連携を支援する。
使用者コンソール(Console)３００はWeb ＧＵＩ形態で提供される。

【0104】

このようなカクテルクラウドは次のように活用されることができる。
第一、マルチクラウドとして活用されることができる。

【0105】

カクテルクラウドは標準化コンポネントを通じて異質的で複雑なマルチクラウド環境の統合管理のためのプラットフォームであり、またアプリケーション中心の企業クラウド全量を具現する。具体的に、カクテルクラウドはプロバイダー・ネットワーク・サービス・クラスタ・サーバー・クラウドコンポネントを通じて管理対象を標準化して異質的で複雑なマルチクラウドリソースの統合管理(統合アカウント・資源・費用)する標準化管理コンポネントである。また、アプリケーションはビジネスの核心資源であるが、カクテルクラスタを通じてアプリケーション可用性と拡張性が強化され、カクテルDevOps Viewを通じた開発/運営業務効率化を通じてアプリケーション中心の企業クラウドを具現することができる。

【0106】

第二、カクテルクラウドは社内、データセンターBare Metalインフラのクラウド化を通じてハイブリッドクラウドを構築/運営の基盤を提供する。また、複雑なハイブリッドインフラの統合管理と開発/運営効率化を提供する。

【0107】

具体的に、社内、データセンターのBare Metalインフラにアプリケーションクラスタを構成し、コンテナ基盤のクラウド環境を駆逐することで別途仮想化のためのプラットフォームが不必要であり、可用性・スケーリングなど拡張性を提供し、既存プライベートとパブリッククラウドを統合管理することができる物理インフラのクラウド化を具現することができる。
また、カクテルクラウドの標準コンポネントを通じて管理し、カクテルクラウドDevOpsビューを通じた開発/運営業務効率化を提供する。

【0108】

第三、カクテルクラウドはコンテナとCI/CDのための自動化を通じてクラウド上のアプリケーションの効率的管理とマイクロサービスの構築及び運営プラットフォームを提供する。

【0109】

カクテルクラスタはコンテナを基盤でクラウドインフラでアプリケーション配布及び管理環境を提供(クラウドネイティブアプリケーション)する。ここで、カクテルクラスタはマイクロサービスを駆逐して管理する基本単位である。

【0110】

カクテルDevOpsビューの作業管理はアプリケーションをビルドして配布することができる自動化基盤を提供し、コンテナはCI/CDをより軽くて容易に遂行することができる技術である。カクテルクラウドはマルチ/ハイブリッドクラウド上にアプリケーションを配布/運営することができるプラットフォームを提供する。

【0111】

第四、カクテルクラウドはクラウドサービスブローカーのインフラ再販売及びサービス提供プラットフォームとしても活用されることができる。

【0112】

パブリッククラウド・データセンターインフラを統合管理して使用者に再販売とクラウド管理プラットフォームをサービス形態で提供するＣＳＢ用プラットフォームをカクテルクラウドで構築・運営し、SaaSのためのマルチテナンシーとビリングシステムを提供し、大きい規模の企業の場合系列社クラウド提供及び管理プラットフォームで活用可能である。

【0113】

また、既存データセンター事業者のインフラをクラウド化して提供し、パブリッククラウド提供者に特化されたサービス(カクテルクラウドコンポネント(PaaS))を提供する。

【0114】

一方、上述した本発明の実施例らはコンピューターで実行されることができるプログラムで作成可能であり、コンピューターで読める記録媒体を利用して前記プログラムを動作させる汎用デジタルコンピューターで具現されることができる。前記コンピューターで読める記録媒体はマグネチック記憶媒体(例えば、ロム(Read Only Memory)・フロッピー・ハードディスクなど)、光学的判読媒体(例えば、CD-ROM・DVDなど)及びキャリアウェーブ(例えば、インターネットを通じた伝送)のような記憶媒体を含む。

【0115】

このように本発明によるクラウドプラットフォームでアプリケーションをコンテナ化する方法によれば隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上の多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、少ない大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能である。

【0116】

今まで本発明に対してその望ましい実施例らを中心に説明した。本発明が属する技術分野で通常の知識を有した者は本発明が、本発明の本質的な特性から脱しない範囲で変形された形態で具現されることができることを理解することができる。それで、開示された実施例らは限定的な観点ではなく、説明的な観点で考慮されなければならない。本発明の範囲は前述した説明ではなく特許請求範囲に示されているし、それと同等な範囲内にあるすべての差異点は本発明に含まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】