(57)【要約】クラスターリソース割り当て要請が入力されれば、クラウドプラットフォームシステムがサービスグループ情報を生成する段階と、前記サービスグループの使用者を追加/削除する段階と、前記サービスグループの使用者に割り当てるクラスターが選択されて割り当て情報が入力される段階と、クラスター資源可用量を問い合わせする段階と、前記資源可用量問い合わせ結果資源が使用可能ならば、前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、前記資源可用量問い合わせ結果資源が不足ならば、クラスター資源が加えられるかを確認する段階と、前記クラスター資源が追加できれば、前記クラスター資源を追加登録する段階と、前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、及び前記クラスター資源が追加できなければ、可用クラスターを再選択する段階と、を含むクラウドプラットフォームでのクラスターリソース割り当て及び管理方法を提供する。【選択図】図１９
2021530801.tif 000002
【特許請求の範囲】
【請求項１】
クラスターリソース割り当て要請が入力されれば、クラウドプラットフォームシステムがサービスグループ情報を生成する段階と、前記クラウドプラットフォームシステムが前記サービスグループの使用者を追加/削除する段階と、前記サービスグループの使用者に割り当てるクラスターが選択されて割り当て情報が入力される段階と、前記クラウドプラットフォームシステムがクラスター資源可用量を問い合わせする段階と、前記資源可用量問い合わせ結果資源が使用可能ならば、前記クラウドプラットフォームシステムが前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、前記資源可用量問い合わせ結果資源が不足ならば、前記クラウドプラットフォームシステムがクラスター資源が加えられるかを確認する段階と、前記クラスター資源が追加できれば、前記クラウドプラットフォームシステムが前記クラスター資源を追加登録する段階と、前記クラウドプラットフォームシステムが前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、及び前記クラスター資源が追加できなければ、可用クラスターを再選択する段階と、を含む
ことを特徴とするクラウドプラットフォームでのクラスターリソース割り当て及び管理方法。
【請求項２】
前記クラスターリソース使用のためにアプリケーション資源使用量が登録される段階と、前記クラウドプラットフォームシステムがクラスター資源可用量を問い合わせする段階と、資源使用ができれば前記クラウドプラットフォームシステムがアプリケーション資源を割り当てて機動する段階と、前記クラウドプラットフォームシステムが残余リソース割り当て情報をアップデートする段階と、及び前記クラスターリソース使用が完了される段階と、をさらに含む
請求項１に記載のクラウドプラットフォームでのクラスターリソース割り当て及び管理方法。
【請求項３】
前記クラスターリソース返納のためにアプリケーションが終わる段階と、前記クラウドプラットフォームシステムが割り当てリソースを回収する段階と、前記クラウドプラットフォームシステムがクラスター可用リソース情報をアップデートする段階と、及び前記クラスターリソース返納が完了される段階と、をさらに含む
請求項１に記載のクラウドプラットフォームでのクラスターリソース割り当て及び管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドプラットフォームでのクラスターリソース割り当て及び管理方法に関するものであり、より詳細には、クラスターリソースを効率的に割り当てて管理することができるクラウドプラットフォームでのクラスターリソース割り当て及び管理方法に関するものである。
【背景技術】
【０００２】
クラウド(Cloud)はコンピュータサービス事業者サーバーを曇模様で表示する慣行によって‘サービス事業者のサーバー'で通じる。ソフトウェアとデータをインターネットと連結された中央コンピューターに保存してインターネットに接続さえすれば、いつどこでもデータを利用するようにするものである。
【０００３】
このようなクラウドはサービス提供形態によってSalesforce.com・Google e-mailなどのように複数の使用者にオンディマンド(On-demand)で提供されるアプリケーションサービスであるSoftware as a Service(SaaS)、AWS ＲＤＳ・Google App Engineなどのように開発用プラットフォームまたはアプリケーション実行に必要なソフトウェアスタックであるPlatform as a Service(PaaS)、ＡＷＳＥＣ２などのようにサーバーまたはストレージなどを使用者にサービス形態で提供するInfrastructure as a Service(IaaS)などで分けることができる。
【０００４】
また、クラウドは導入と配布形態によってただ一つの団体のみのために運営されるプライベートクラウド(Private cloud)、公開的利用のために開かれたネットワークを通じてレンダリングされるパブリッククラウド(Public cloud)、明らかな実体は維持するが、共に縛られているふたつ以上のクラウドの組合であるハイブリッドクラウド(Hybrid cloud)などでも分けることができる。
【０００５】
一方エンタープライズクラウド(Enterprise Cloud)の場合企業のビジネスとＩＴ戦略を具現したクラウドでアプリケーションサービスを中心に技術とインフラをオーダーメード化して最適化することが何より重要であり、またアプリケーションを多様なインフラに構成するか、または配布することに容易でなければならない。そして、アプリケーションが動作することができるクラスターのリソースを割り当てて管理する技術が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
これに、本発明はこのような前記問題点を解決するために創出されたものであり、クラスターリソースを効率的に割り当てて管理することができるクラウドプラットフォームでのクラスターリソース割り当て及び管理方法を提供することにその目的がある。
【０００７】
しかし、本発明の技術的課題らは上で言及した課題らに制限されないし、言及されなかったまた他の技術的課題らは下の記載から当業者に明確に理解されることができるであろう。
【課題を解決するための手段】
【０００８】
本発明の実施例によるクラウドプラットフォームでのクラスターリソース割り当て及び管理方法は、クラスターリソース割り当て要請が入力されれば、クラウドプラットフォームシステムがサービスグループ情報を生成する段階と、前記クラウドプラットフォームシステムが前記サービスグループの使用者を追加/削除する段階と、前記サービスグループの使用者に割り当てるクラスターが選択されて割り当て情報が入力される段階と、前記クラウドプラットフォームシステムがクラスター資源可用量を問い合わせする段階と、前記資源可用量の問い合わせ結果資源が使用可能ならば、前記クラウドプラットフォームシステムが前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、前記資源可用量問い合わせ結果資源が不足ならば、前記クラウドプラットフォームシステムがクラスター資源が加えられるかを確認する段階と、前記クラスター資源が追加できれば、前記クラウドプラットフォームシステムが前記クラスター資源を追加登録する段階と、前記クラウドプラットフォームシステムが前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、及び前記クラスター資源が追加できなければ、可用クラスターを再選択する段階と、を含む。
【０００９】
前記クラスターリソース使用のためにアプリケーション資源使用量が登録される段階と、前記クラウドプラットフォームシステムがクラスター資源可用量を問い合わせする段階と、資源使用ができれば前記クラウドプラットフォームシステムがアプリケーション資源を割り当てて機動する段階と、前記クラウドプラットフォームシステムが残余リソース割り当て情報をアップデートする段階と、及び前記クラスターリソース使用が完了される段階と、をさらに含むことができる。
【００１０】
前記クラスターリソース返納のためにアプリケーションが終わる段階と、前記クラウドプラットフォームシステムが割り当てリソースを回収する段階と、前記クラウドプラットフォームシステムがクラスター可用リソース情報をアップデートする段階と、及び前記クラスターリソース返納が完了される段階と、をさらに含むことができる。
【発明の効果】
【００１１】
本発明によるクラウドプラットフォームでのクラスターリソース割り当て及び管理方法は、クラスターリソースを効率的に割り当てて管理することができる効果を有する。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施例によるクラウドプラットフォームシステムの構成図を示す。
【図２】図１のクラウド統合部の機能を簡略に示したものである。
【図３】図１のサービス管理部の機能を簡略に示したものである。
【図４】図１のアプリケーションオーケストレーション部の機能を簡略に示したものである。
【図５】本発明の一実施例によるアプリケーションコンテナ化のフレームワークを示す。
【図６】図１の開発/運営部の機能を簡略に示したものである。
【図７】図１の開発/運営部の機能を簡略に示したものである。
【図８】図１の開発/運営部の機能を簡略に示したものである。
【図９】図１の開発/運営部の機能を簡略に示したものである。
【図１０】図１の開発/運営部の機能を簡略に示したものである。
【図１１】図１の開発/運営部の機能を簡略に示したものである。
【図１２】本発明の一実施例によるクラウドプラットフォームシステムのアーキテクチャーを示す。
【図１３】カクテルサーバーの構成とその周辺アーキテクチャーを示す。
【図１４】本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理機能を説明するための図面である。
【図１５】本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理機能を説明するための図面である。
【図１６】本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理機能を説明するための図面である。
【図１７】本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理方法を示した流れ図である。
【図１８】本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース割り当て管理機能を説明するための図面である。
【図１９】本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース割り当て方法を示した流れ図である。
【図２０】本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース使用方法を示した流れ図である。
【図２１】本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース返納方法を示した流れ図である。
【発明を実施するための形態】
【００１３】
本発明の長所及び特徴、そしてそれらを達成する方法らは添付される図面と共に詳細に後述されている実施例らを参照すれば明確になるであろう。しかし、本発明は以下で開示される実施例らに限定されるものではなく、また他の多様な形態で具現されることができるし、単に本実施例らは本発明の開示が完全であるようにさせて本発明が属する技術分野で通常の知識を有した者に発明の範疇を完全に知らせてくれるために提供されるものであり、本発明は単に請求項によって定義されるだけである。
【００１４】
明細書全体にわたって同一参照符号は同一構成要素を指称する。
【００１５】
以下、添付された図面らを参考して本発明の実施例によるクラウドプラットフォームシステムに対して説明するようにする。
【００１６】
図１は、本発明の一実施例によるクラウドプラットフォームシステムの構成図を示し、図２は図１のクラウド統合部の機能を簡略に示したものであり、図３は図１のサービス管理部の機能を簡略に示したもので、図４は図１のアプリケーションオーケストレーション部の機能を簡略に示したものである。
【００１７】
図５は、本発明の一実施例によるアプリケーションコンテナ化のフレームワークを示し、図６乃至図１１は図１の開発/運営部の機能を簡略に示したものである。
【００１８】
図１のクラウドプラットフォームシステムは、マルチ/ハイブリッドクラウド統合管理を基盤でアプリケーション可用性・拡張性を保障して開発・運営の効率化のためのビューと道具を提供する。以下、本発明のクラウドプラットフォームシステムを“カクテルクラウド(Cocktail Cloud)”と称することにする。
【００１９】
図１を参照すれば、カクテルクラウドは、クラウド統合部(Cloud Integration)１００・サービス管理部(Service Management)１１０・アプリケーションオーケストレーション部(Orchestration)１２０・開発/運営部(DevOps View)１４０及びＤＢ/保存所１５０を含む。
【００２０】
クラウド統合部(Cloud Integration)１００はマルチ/ハイブリッドクラウドのインフラを自動構成してアプリケーションに提供して管理のための構成情報を同期化する役割を遂行する。
【００２１】
クラウド統合部１００はクラウドプロビジョニング(Cloud Provisioning)とクラウド同期化(Cloud Synchronization)の機能を遂行する。
【００２２】
図２を参照すれば、クラウドプロビジョニング機能はアプリケーションクラスター(カクテルクラスター)にクラウドネットワークインフラを構成及び提供し、アプリケーションにクラウドのコンピュータインフラを構成及び提供する機能である。そして、物理インフラ(Bare Metal)の場合クラスター設定道具を提供する。サポートクラウドはPublicの場合AWS・Azure・Aliyun・Google Computing Engineであり、Privateの場合Openstack・VMWearであり、以外にOn-premise・DatacenterBare Metal Infraがあることができる。
【００２３】
クラウド同期化機能は、クラウドインフラ構成情報を統合構成ＤＢ１６０に保存及び管理し、運営時インフラ変更情報を統合構成ＤＢ１６０と同期化する機能である。
【００２４】
サービス管理部(Service Management)１１０はアプリケーションクラスターを管理する論理的グループとしてクラウド計定と使用者、ネットワーク資源を割り当て及び管理する役割を遂行する。すなわち、サービス管理部１１０は統合計定管理機能・ネットワーク管理機能及び使用者管理機能を遂行する。
【００２５】
図３を参照すれば統合計定管理(Cloud Provider)機能は、マルチクラウド計定及び接続情報を統合管理し、ネットワークとクラウドプロビジョニング構成に使用される機能である。
【００２６】
ネットワーク管理機能はクラウドネットワークを構成してサービスに割り当てる機能である。例えば、AWSのVPC・Subnetであることがある。一つのサービスはマルチクラウドの供給者のネットワークを使ってクラスターを生成してアプリケーションを構成・運営する。
【００２７】
使用者管理機能はサービスを管理するチーム構成員と開発/運営に必要な権限を管理する機能である。ここで、権限は全社サービス管理権限(Admin)、全社サービス問い合わせ権限(Manager)、構成員に割当されたサービス管理権限(DevOps)などを含むことができる。使用者は多くのサービスに構成員で参加可能である。
【００２８】
アプリケーションオーケストレーション部(Orchestration)１２０はアプリケーションの配布と可用性・拡張性を保障する機能としてカクテルクラスター(Cluster)の核心機能を担当する。
【００２９】
アプリケーションオーケストレーション部１２０はアプリケーション配布(Deployment)機能・複製(Replication Control)機能・ローリングアップデート(Rolling Update)機能・スケーリング(Scaling)機能及びモニタリング(Monitoring)機能を遂行する。
【００３０】
図４を参照すればアプリケーション配布機能は、コンテナイメージ基盤の配布で別途設定と構成作業が必要ない容易性を提供し、アプリケーション配布時クラウドインフラを自動プロビジョニングする機能である。
【００３１】
ここで、アプリケーションはコンテナ化されて配布されるようになるが、アプリケーションコンテナ(以下、“コンテナ”と称する)はアプリケーションプロセスにホスト資源を割り当てて隔離して仮想化したＯＳ上の独立システムを言う。
【００３２】
コンテナに使用される核心技術は、Linux（登録商標）のcgroup(control group)とnamespaceである。cgroupはＯＳ上のプロセスにホスト資源を割り当てるために該当プロセスグループを作って資源の割り当て及び管理を遂行する。namespaceはプロセス・ネットワーク・マウンド(mount)などを特定name spaceで隔離する技術である。これによってコンテナはcgroupを通じてアプリケーションプロセスに資源を割り当て、namespaceで隔離したＯＳ上に仮想化された独立システムを言う。
【００３３】
コンテナはハイパーバイザー(Hardware emulator)とゲストＯＳを使わない軽いＯＳ仮想化方式でホスト資源の消耗量がほとんどなく、機動に入る時間が非常に少なくてアプリケーション仮想化に好適な技術である。また、ＯＳ上の仮想化で既存物理サーバー(Bare Metal)・仮想サーバー(Virtual Machine)などインフラに独立的な構成と配布が可能である。
【００３４】
このように既存または新規アプリケーション構成をコンテナで切り替えるためには、コンテナ化(Containerization)過程が隋伴されなければならない。そして、これによる開発・テスト・運営方式の転換及び運営インフラ構成(カクテルクラウドプラットフォーム)最適化作業を並行しなければならない。
【００３５】
既存アプリケーションをコンテナに切り替えるためには、アプリケーションの設定及びソースではない構成の転換が必要であり、配布と運営効率を考慮する時ワークロード(Workload)中心の役割別独立的構成が一般的であり、複製を通じた多重化とスケーリングを考慮した構成が設計されて適用されなければならないであろう。
【００３６】
アプリケーション開発・テスト・運営方式の転換のためにはイメージ基盤のアプリケーションビルド・テスト・配布とベースイメージを通じたアプリケーション構成が標準化されなければならないであろう。
【００３７】
アプリケーションコンテナ運営インフラ構成最適化のためにはコンテナオーケストレーションのためのクラスター中心のインフラが構成され、複製・スケーリングを考慮したコンピュータ容量が算定(予備容量最小化、必要時拡張容易)されなければならないし、共有ストレージ・保安・ネットワークなど関連インフラを構成しなければならないであろう。
【００３８】
図５を参照すればコンテナ化は、大きく分析及び構成設計(Ｓ１００)・コンテナ転換(Ｓ２００)・運営移管(Ｓ３００)で区分される。
【００３９】
分析及び構成設計(Ｓ１００)のためにコンテナ/クラウド導入目的と戦略を考慮して既存アプリケーションのうちでコンテナ転換対象を選定する(Ｓ１１０)。
【００４０】
対象アプリケーションが選定されれば、対象アプリケーションを分析する(Ｓ１２０)。この時、アプリケーション・インフラ・データ・連携構造などのアプリケーション現況及び資料調査をして、開発及び運営・管理者の要求を収集する。そして、コンテナ構成方向・イシュー及び解決方案を導出する。
【００４１】
そして、分離/統合・連携・可用性・拡張性・保安などを考慮して対象アプリケーション別コンテナ構成を設計する(Ｓ１３０)。この時、ベースイメージ・環境変数・包含項目・コメンドなどのイメージビルドテンプレートを定義することができる。
【００４２】
その後、インフラ構成を設計する(Ｓ１４０)。転換インフラ(クラウド/ベアメタル)供給者を選定し、アプリケーションコンテナ別容量を算定する。そして、コンテナクラスターノード数及びインフラ容量を算定し、ストレージ・ネットワーク・保安構成を設計する。
【００４３】
インフラ構成が設計されれば、コンテナ転換方案を樹立する(Ｓ１５０)。この時、アプリケーション別転換詳細方案を樹立し、転換業務及び組織/役割を定義し、転換日程を樹立する。そして、報告及びフィードバックを反映する。
【００４４】
コンテナ転換(Ｓ２００)のためには、繰り返し/漸増的転換(Ｓ２１０)が必要である。辞書テスト(PoC)、アプリケーション別段階的転換など繰り返し的で漸増的に切り替える。
【００４５】
そして、カクテルクラスターを構成(Ｓ２２０)するためにカクテルクラウドプラットフォームを設置及び構成し、ネットワーク・共有ストレージ・保安など基盤インフラを構成する(クラウドの場合カクテルでプロビジョニング)。基盤インフラ割り当て及び使用者登録を通じてカクテルサービスとクラスターを生成し、クラスター構成を検証する。
【００４６】
そして、アプリケーション転換(Ｓ２３０)のためにアプリケーションコンテナを構成し、必要時アプリケーション設定及びソースを変更する。転換コンテナの機能及び設定などを検証し、コンテナ配布イメージビルド及びレジストリに登録する。そして、カクテルサーバーを生成してテストする。
【００４７】
データ転換(Ｓ２４０)のために対象アプリケーションコンテナ切り替え、Persistenceボリューム設定などを通じてカクテルサーバーを設定し、データを抽出してカクテルサーバーに送る。この機種ＤＢソリューション適用の場合データ変換を遂行し、データ整合性を確認する。運営アプリケーションの場合ダウンタイムを最小化するためにデータ同期化ソリューションを適用する。
【００４８】
その後、検証されたコンテナをカクテルサーバーに配布し、アプリケーション機能及び性能テストを遂行し、コンテナ及びインフラにテスト結果を反映する(Ｓ２５０、Ｓ２６０)。
【００４９】
運営移管(Ｓ３００)のために運営配布/オープン(Ｓ３１０)が遂行されるが、具体的に運営カクテルクラスターを生成して転換完了されたイメージを基盤でカクテルサーバーを生成して連携構成する。そして、運営データを移管してアプリケーションをオープンする。このようなアプリケーションコンテナを配布・運営・管理する技術をコンテナオーケストレーション(Orchestration)と称する。
【００５０】
コンテナオーケストレーションは物理/仮想インフラに管理クラスター(Managed Cluster)を構成してアプリケーションコンテナを配布・運営・管理する技術であり、コンテナの軽くて早い起動性と移動性の長所を活用して既存社内、データセンターインフラのクラウド化とプライベート/パブリッククラウドのアプリケーション管理プラットフォームで拡散している。
【００５１】
カクテルクラウドモニタリングビューを通じてアプリケーション及びインフラ運営モニタリングを遂行して性能イシュー及び間違いを反映する(Ｓ３２０)。
【００５２】
開発・運営体系移管及び適用(Ｓ３３０)のためにコンテナ移管結果をレポートし、担当開発及び運営組織にコンテナ基盤開発/運営体系教育を実施し、カクテルクラウドプラットフォーム使用教育を実施する。
【００５３】
これによってコンテナは次のような長所を有する。
【００５４】
第一、コンテナは独立性を有する。
【００５５】
隔離されたアプリケーション実行環境であり、独立的な資源が割り当てされ(ＣＰＵ、Memory、Disk、Networkなど)、同一ホスト上多重アプリケーションが運営される。
【００５６】
第二、コンテナは軽い仮想化を具現する。
【００５７】
ＯＳ水準の仮想化(Non Hypervisor)が可能であり、早い操作が可能で(生成・実行・再始作など)、少ない大きさのコンテナイメージで配布及びアップデートが効率的である。
【００５８】
第三、コンテナは移動性を有する。
【００５９】
インフラは独立的イメージを有して、ベアメタル(Bare Metal)・仮想マシン(Virtual Machine)・クラウド(Cloud)などどこでも移動が可能で、イメージレジストリを通じたオンライン配布及びバージョン管理が可能であり、主要ホストＯＳ(Linux（登録商標）系列、Windows)を支援する。このようなコンテナの移動性はマルチ/ハイブリッドクラウド環境下にアプリケーション運営/開発の生産性及び効率を高めて特に、規格化されたコンテナイメージで異種のインフラにアプリケーション配布及び以前の難しさを解決して特定クラウドに属するロックイン(Lock-in)問題を解決してくれる。
【００６０】
複製機能はアプリケーション安全性と可用性のために初期指定した複製数(多重化)を維持し、アプリケーションコンテナヘルスチェック(Health Check)を通じて異常時再起動する方式でＯＳ再起動方式より早くて効率的である。複製されたアプリケーションはロードバランシングを通じてサービスされる。
【００６１】
ローリングアップデート機能はアプリケーションサービスの中断なしに配布・インフラ変更などのアップデート作業を遂行し、多くのアプリケーション間の依存性がある場合DevOps Viewの作業(job)管理機能を通じて自動化を構成する機能である。
【００６２】
スケーリング機能はアプリケーションのモニタリングを通じてインスタンスのスケーリングをイン(In)/アウト(Out)して、アプリケーションインフラの場合資源容量のスケールを業(Up)/ダウン(Down)する機能である。そして、モニタリング情報を通じてスケーリング自動化を構成する。
【００６３】
モニタリング機能はアプリケーションインスタンス(コンテナ+インフラ)をモニタリングし、臨界値設定を通じたアラームを発生及び管理する機能である。
【００６４】
開発/運営部(DevOps View)１４０はサービス現況機能、クラスターマップ機能、モニタリングビュー機能、リソース管理機能、メータリング機能、作業管理機能、及び全社現況管理/分析機能を含む。それぞれの機能を図６乃至図１１を参照して説明すれば次のようである。
【００６５】
サービス現況機能はカクテルクラウドの全体アプリケーションクラスターの現況をサービス中心に把握することができるビュー(図６参照)を提供する。ここにサービス現況・クラスター現況・モニタリングアラームなどの項目が表示されることができる。
【００６６】
サービス現況ではカクテルクラウドの全体サービス現況を問い合わせすることができるし、サービス内のクラスターの構成現況を総合してクラウド供給者・クラスター・サーバー・クラウドコンポネント・現在月使用費用などを把握することができる。ここでクラスターは、アプリケーションの構成単位を意味し、サービスはクラスターの論理的グループを意味する。
【００６７】
クラスター現況ではクラスターの供給者・リージョン・サーバー・クラウドコンポネント・月使用費用をカード形態で問い合わせ可能であり、物理(Bare Metal)クラスターの場合使用費用は除かれることができる。
【００６８】
モニタリングアラーム表示機能ではクラスター内のアプリケーションとインフラでアラームが発生した場合、クラスターカードで確認が可能である。
【００６９】
クラスターマップ機能はカクテルサーバー(アプリケーション)の構成と状態情報をマップ形態で視覚化して管理することができるビューを提供する(図７参照)。
【００７０】
クラスターマップはクラスターのサーバーとクラウドコンポネント構成をマップ形態で問い合わせ/管理して構成情報の可視性を高める。クラスターマップではカクテルサーバー・クラウドコンポネント・サーバーグループなどの項目を含むことができる。
【００７１】
カクテルサーバーはアプリケーションオーケストレーションの基本単位でロードバランシング・アプリケーションコンテナ・インフラで構成され、マルチ/ハイブリッドクラウド管理に標準化されたインターフェースを提供する。カクテルサーバーはサーバー内のアプリケーション状態と複製、資源使用量を確認してスケーリング・ローリングアップデートなどを管理遂行する。カクテルサーバーは複製機能の有無によってマルチとシングルインスタンスタイプで区分される。AWSではマルチゾーンオプションを支援する。
【００７２】
クラウドコンポネントは供給者が提供するPaaSサービスを管理する。例えば、AWSのＤＢサービスであるＲＤＳであることがある。
【００７３】
サーバーグループはサーバー構成の論理的グループを管理的便宜性を提供する。
【００７４】
モニタリングビュー機能はクラスター内のアプリケーションとインフラの資源容量と状態を確認してクラウドリソースの状態を確認することができる情報を提供する(図８参照)。
【００７５】
モニタリングビューはクラスター内のアプリケーションとインフラに対するモニタリング情報を視覚化して提供し、ＣＰＵ・メモリー・ディスクの平均・ＴＯＰ情報提供で資源の使用量を確認して運営で対応できるようにする。
【００７６】
モニタリングビューはビュー転換(トレンド/データ)項目、対象転換(サーバー/リソース)項目などを含むことができる。
【００７７】
ビュー転換項目でトレンドビュはサーバーと複製されたインスタンス・アプリケーションコンテナに対する時間別モニタリング情報を提供し、データビューは現在時間の平均・ＴＯＰモニタリング数値を提供する。
【００７８】
対象転換項目でモニタリング対象はクラスター内のサーバーとクラウドインフラのリソースで区分される。クラウドリソースは供給者が提供する情報を使用する。
【００７９】
リソース管理機能はアプリケーションを構成するクラウドインフラのリソースを確認して必要時詳細設定を調整することができるビュー(以下、“リソース管理ビュー”と称する)を提供する(図９参照)。
【００８０】
リソース管理ビューはカクテルサーバーを構成するクラウドインフラリソースを確認して設定を詳細的に変更することができる。ここでカクテルサーバーは、アプリケーションオーケストレーションのための基本構成を自動で遂行するが、必要な場合直接クラウドリソースを調整する必要がある時に使用される。
【００８１】
リソース管理ビューはリソース情報/アクション項目を含むが、リソース情報のうちでアプリケーションはコンテナ設定と配布情報を管理する。クラウドリソース情報はロードバランサー・インスタンス(ＶＭ)・保安で構成され、インスタンスは容量とボリュームを管理する。調整が必要なリソース情報はアクションを通じて遂行される。
【００８２】
メータリング機能はアプリケーションが使用するクラウドインフラリソースの費用情報を確認することができるビュー(以下、“メータリングビュー”と称する)を提供する(図１０参照)。メータリングビューはクラスターインフラ使用費用項目・サーバー・リソース別費用項目などを含むことができる。
【００８３】
クラスターインフラ使用費用項目ではクラスターとカクテルサーバーが使用するクラウドリソースの費用現況を確認することができるし、前月・現在月費用情報と翌月推定費用を提供する。また月別で費用増減推移グラフを提供する。
【００８４】
サーバー・リソース別費用項目はカクテルサーバー別で使用するクラウドリソース費用をＴＯＰを基準で提供し、クラウドリソース種類別で使用する費用をＴＯＰを基準で提供する。
【００８５】
作業管理機能は配布・遠隔命令・リソース管理などの運営作業をスケジューリング/自動化することができる管理ビュー(以下、“作業管理ビュー”と称する)を提供する(図１１参照)。
【００８６】
作業管理ビューはアプリケーションとインフラの運営のためのスケジューリング及び一括処理機能を提供する。このような作業管理ビューは作業現況項目、作業管理項目などを含むことができる。
【００８７】
作業管理ビューで作業現況項目は配布・遠隔命令語・リソース管理タスクで区分して各タスクを組み合わせて構成される。ここで配布は、アプリケーション配布、遠隔命令語はＯＳ命令語を遠隔で遂行、リソース管理はスケーリング、状態/設定変更を意味する。
【００８８】
作業管理ビューで作業管理項目は直ちに遂行・スケジューリング・アラーム発生によって遂行方式を設定することができる。アラーム発生による遂行は容量モニタリングの基準値による自動スケーリングなどで使用される。作業管理項目で作業の実行状態とログ確認を提供する。
【００８９】
全社現況管理/分析機能は全社アプリケーション・クラウド・費用現況を把握して分析することができるカクテルダッシュボード(Dashboard)を提供する。
【００９０】
カクテルダッシュボードは全社次元でアプリケーションとクラウドインフラの現況を問い合わせして費用/予算管理、費用最適化分析、統計レポートを提供するビューである。このようなカクテルダッシュボードはアプリケーション現況項目、クラウド現況項目、費用/予算管理、費用最適化分析項目、統計/レポート項目を含むことができる。
【００９１】
アプリケーション現況項目を通じてカクテルサーバー・クラスター・クラウドコンポネントの標準化された要素を基準でアプリケーションとインフラ現況を全社的に把握して問い合わせすることができるし、サービス中心の現況ビューを提供する。
【００９２】
クラウド現況項目を通じて全社で使用するクラウドを供給者・リージョン・リソース別で現況を把握することができるし、インフラ中心の現況ビューを提供する。
【００９３】
費用/予算管理、費用最適化分析項目を通じて全社クラウド費用現況を把握してサービス別予算割り当て/統制と最適化分析を通じてクラウドリソース費用効率化ができる情報を提供する。
【００９４】
統計/レポート項目は分析及び報告に必要な統計情報とレポートビューを提供する。
【００９５】
ＤＢ/保存所１５０でイメージ保存所(レジストリ)１８０はアプリケーションコンテナの登録・共有・ダウンロード・検索・バージョンを管理し、モニタリングＤＢ１７０はアプリケーションとインフラのモニタリング情報を管理し、統合構成ＤＢ(Configuration ManagementＤＢ、ＣＭＤＢ)１６０はプロバイダー・ネットワーク・サービス・クラスター・サーバー・コンポネント・クラウドリソースの構成情報を管理する。
【００９６】
図１２は、本発明の一実施例によるクラウドプラットフォームのアーキテクチャーを示し、図１３はカクテルサーバーの構成とその周辺アーキテクチャーを示す。
【００９７】
図１２を参照すれば、カクテルクラウドはカクテルクラスター２００、プロバイダープラグイン２１０、サーバーマネージャー２２０、DevOpsマネージャー、ＣＭＤＢ１６０、モニタリングＤＢ１７０、イメージレジストリ１８０、ＡＰＩサーバー２９０、使用者コンソール３００を含む。
【００９８】
カクテルクラスター２００はオーケストレーション基盤アーキテクチャーを提供してプロバイダープラグイン２１０はクラウド供給者ＡＰＩ２８０を通じて統合管理のための基本モジュールで使用される。
【００９９】
クラスター２００はノードとマスターで構成され、ノードの場合ワーカー(worker)３１０を通じてマスターの命令語を処理する構造である。ワーカー３１０はマスターとの通信を担当して遂行命令語によってExecutorが支援される。Monitoring Executor３２０はノードとコンテナモニタリング情報を収集して、Command Executor３３０はＯＳとコンテナ命令を遂行する。その外にContainer Engine(Docker)３４０がある。
【０１００】
プロバイダープラグイン２１０はマルチクラウドとBare MetalのためのKubernetes ＡＰＩ支援のためのＡＰＩ Rapperであり、プロバイダー拡張のためのプラグインモジュールで構成される。カクテルサーバーはアプリケーションオーケストレーションの基本単位であり、クラスターマスター２００とプロバイダープラグイン２１０を通じてコンテナとクラウドインフラの複製・スケーリング・ローリングアップデートを遂行する。
【０１０１】
カクテルサーバーは図１３に示されたようにコンテナとクラウドインフラで構成されるが、ロードバランサー・インスタンス(ノード)・コンテナ・ボリューム・保安などで構成され、AWSの例えば、ELB・EC２Instance・Security Group・ESBであることがある。カクテルサーバーはクラウド提供者のPaaSのためにクラウドコンポネントを提供する。例えばAWSのＲＤＳであることがある。
【０１０２】
サーバーマネージャー２２０はサーバー内のアプリケーションコンテナとインフラのオーケストレーションを遂行する制御モジュールとして、非正常終了されたコンテナを再始作/復旧する複製制御、スケールイン/アウトとインスタンスタイプとボリューム拡張を通じたアップダウンを遂行するスケーリング、アプリケーションコンテナ配布を順次に無中断で遂行するローリングアップデート機能を提供する。
【０１０３】
DevOpsマネージャーはマルチクラウドインフラプロビジョニングのための構成管理(Configuration Manager)２３０、マルチクラウド資源の使用量及び費用管理のためのメータリング管理(Metering Manager)２４０、マルチクラウド資源現況及び設定管理のための資源管理(Resource Manager)２５０、コンテナ/インフラモニタリング情報収集及び管理のためのモニタリング管理(Monitoring Manager)２６０、多くの作業タスクを結合して一括遂行して直ちに遂行・遂行時間・イベント発生が遂行条件であり、配布・サーバーアクション・遠隔命令語のタスクのための作業管理(Job Manager)２７０を提供するものとしてDevOpsのためのマネージャーモジュールである。
【０１０４】
カクテルクラウドはアプリケーションとインフラの構成情報管理・モニタリング情報管理・アプリケーションコンテナイメージ管理のためのＤＢを提供し、使用者とプログラミングのためのインターフェースを提供する。
【０１０５】
ＣＭＤＢ１６０はプロバイダー・ネットワーク・サービス・クラスター・サーバー・コンポネント・クラウドリソースの構成情報を管理する。
【０１０６】
モニタリングＤＢ１７０はアプリケーションとインフラのモニタリング情報を管理する。
【０１０７】
イメージレジストリ１８０はアプリケーションコンテナの登録・共有・ダウンロード・検索・バージョンを管理する。
【０１０８】
ＡＰＩサーバー２９０はカクテルクラウドのすべての機能をＡＰＩ２８０に提供し、企業戦略によるオーダーメード化と他のソリューションとの連携を支援する。
【０１０９】
使用者コンソール(Console)３００はWeb GUI形態で提供される。
【０１１０】
このようなカクテルクラウドは次のように活用されることができる。
【０１１１】
第一、マルチクラウドとして活用されることができる。
【０１１２】
カクテルクラウドは標準化コンポネントを通じて異質的で複雑なマルチクラウド環境の統合管理のためのプラットフォームであり、またアプリケーション中心の企業クラウド全量を具現する。具体的に、カクテルクラウドはプロバイダー・ネットワーク・サービス・クラスター・サーバー・クラウドコンポネントを通じて管理対象を標準化して異質的で複雑なマルチクラウドリソースの統合管理(統合計定・資源・費用)する標準化管理コンポネントである。また、アプリケーションはビジネスの核心資源であるが、カクテルクラスターを通じてアプリケーション可用性と拡張性が強化され、カクテルDevOps Viewを通じた開発/運営業務効率化を通じてアプリケーション中心の企業クラウドを具現することができる。
【０１１３】
第二、カクテルクラウドは社内、データセンターBare Metalインフラのクラウド化を通じてハイブリッドクラウドを構築/運営の基盤を提供する。また、複雑なハイブリッドインフラの統合管理と開発/運営効率化を提供する。
【０１１４】
具体的に社内、データセンターのBare Metalインフラにアプリケーションクラスターを構成してコンテナ基盤のクラウド環境を駆逐することで別途の仮想化のためのプラットフォームが不必要であり、可用性・スケーリングなど拡張性を提供し、既存プライベートとパブリッククラウドを統合管理することができる物理インフラのクラウド化を具現することができる。
【０１１５】
また、カクテルクラウドの標準コンポネントを通じて管理し、カクテルクラウドDevOpsビューを通じた開発/運営業務効率化を提供する。
【０１１６】
第三、カクテルクラウドはコンテナとＣＩ/ＣＤのための自動化を通じてクラウド上のアプリケーションの効率的管理とマイクロサービスの構築及び運営プラットフォームを提供する。
【０１１７】
カクテルクラスターはコンテナを基盤でクラウドインフラでアプリケーション配布及び管理環境を提供(クラウドネイティブアプリケーション)する。ここで、カクテルクラスターはマイクロサービスを駆逐して管理する基本単位である。
【０１１８】
カクテルDevOpsビューの作業管理は、アプリケーションをビルドして配布することができる自動化基盤を提供し、コンテナはＣＩ/ＣＤをより軽くて容易に遂行することができる技術である。カクテルクラウドはマルチ/ハイブリッドクラウド上にアプリケーションを配布/運営することができるプラットフォームを提供する。
【０１１９】
第四、カクテルクラウドはクラウドサービスブローカーのインフラ再販売及びサービス提供プラットフォームとしても活用されることができる。
【０１２０】
パブリッククラウド・データセンターインフラを統合管理して使用者に再販売とクラウド管理プラットフォームをサービス形態で提供するＣＳＢ用プラットフォームをカクテルクラウドで構築・運営し、SaaSのためのマルチテナンシーとビリングシステムを提供し、大きい規模の企業の場合系列会社クラウド提供及び管理プラットフォームで活用可能である。
【０１２１】
また、既存データセンター事業者のインフラをクラウド化して提供し、パブリッククラウド提供者に特化されたサービス(カクテルクラウドコンポネント(PaaS))を提供する。
【０１２２】
図１４乃至図１６は、本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理機能を説明するための図面である。
【０１２３】
本発明によるクラウドプラットフォームシステムであるカクテルクラウドはBare metal、cloud platform、public cloudなど多様なインフラにコンテナ基盤アプリケーションが動作することができるクラスター環境を自動生成するマルチクラスタープロビゾニング及び管理機能が提供される。この機能はマルチクラウド環境で複数個のクラスターを中央(カクテルクラウド)で遠隔同時プロビゾニングしてコンテナアプリケーション運営環境を生成することであり、遠隔でクラスターのバージョンアップグレードを管理して運営効率性を向上させる(図１４参照)。
【０１２４】
図１５を参照すれば、クラスターのバージョンアップグレードの時Orchestration engine、add-onの最新機能が反映され、ＣＬＩ道具を利用して簡便にクラスターノードを追加して障害ノードを入れ替ることができる。そして、クラスターノードバックアップも可能であり、クラスター自動スケーリングも可能である。
【０１２５】
図１６は、クラスターが構成されたパブリッククラウドの計定情報を登録して遠隔でクラスターを制御してアプリケーションの配布、運営管理及びクラスターモニタリング機能を遂行することができる例示画面である。
【０１２６】
図１７は、本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理方法を示した流れ図である。
【０１２７】
マルチクラスタープロビゾニング及び管理のために使用者が入力することができるプロビゾニング及び管理ツール(tool)が提供される。
【０１２８】
プロビゾニング及び管理ツールによって使用者のクラスタープロビゾニングが要請されれば(Ｓ４００)、クラウドプラットフォームシステムは、クラスタータイプ情報(例えば、Bare-metal、public cloud、cloud platformなど)を入力するようにする(Ｓ４１０)。使用者によってクラスタータイプ情報が入力されれば、クラスター構成情報が生成される(Ｓ４２０)。具体的に、クラスター構成情報はインスタンス個数、インスタンス遠慮(ＧＰＵ、メモリータイプ)、ネットワーク構成情報、ストレージ構成情報のうちで少なくとも一つを含む。
【０１２９】
次に、パブリッククラウドまたはシステム接続情報(接続計定情報、認証情報)が登録されれば(Ｓ４３０)、クラウドプラットフォームシステムはクラスターを生成することか、または変更することかを確認する(Ｓ４４０、S４９０)。
【０１３０】
クラスターを生成することなら、クラウドプラットフォームシステムはインスタンス、ネットワーク、ストレージ生成を要請して構成する(Ｓ４５０)。以後、コンテナランタイムソフトウェアが設置される(Ｓ４６０)。そして、クラスター構成情報がセッティングされる(Ｓ４７０)。それではクラスタープロビゾニングが完了される(Ｓ４８０)。
【０１３１】
クラスターを変更することなら、クラウドプラットフォームシステムはクラスター構成ヒストリー情報を確認してクラスター構成をアップデートさせる(Ｓ５００、S５１０)。それではクラスター変更が完了される(Ｓ５２０)。
【０１３２】
一方、本発明の一実施例によるクラウドプラットフォームシステムは、管理者によってサービスまたは組織別に開発・テスト・運営され、クラスター別資源可用量によってクラスターインフラを割り当てるクラスターリソース割り当て管理機能を提供する。
【０１３３】
図１８は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース割り当て管理機能を説明するための図面である。
【０１３４】
図１８に示されたように、本クラウドプラットフォームシステムは、サービス/組織使用グループが登録され、サービス/組織所属使用者が割り当てされれば、割り当てされた使用者にクラスターを割り当てる。この時、クラウドプラットフォームシステムは使用可能なクラスター資源を問い合わせして割り当て、サービス/組織クラスター資源量が制限管理される。
【０１３５】
図１９は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース割り当て方法を示した流れ図である。
【０１３６】
図１９に示されたように、クラスターリソース割り当て要請が入力されれば(Ｓ４００)、サービスグループ情報が生成される(Ｓ４１０)。サービスグループの使用者は追加/削除されることができる(Ｓ４２０)。
【０１３７】
次のサービスグループに割り当てるクラスターが選択されて割り当て情報(例えば、ＣＰＵ、メモリー資源割り当て)が入力される(Ｓ４３０)。
【０１３８】
それではクラウドプラットフォームシステムがクラスター資源可用量を問い合わせする(Ｓ４４０)。
【０１３９】
資源が使用可能ならば、クラウドプラットフォームシステムがサービスグループに資源割り当て情報を登録して資源を割り当てる(Ｓ４５０、S４６０)。ここにクラスターリソース割り当てが完了される(Ｓ４７０)。
【０１４０】
資源が不足ならば、クラウドプラットフォームシステムがクラスター資源が加えられるかを確認する(Ｓ４８０)。クラスター資源が追加できれば、クラウドプラットフォームシステムがクラスター資源を追加登録する(Ｓ４９０)。その後、クラウドプラットフォームシステムがサービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する(Ｓ４５０、S４６０、S４７０)。
【０１４１】
仮に、クラスター資源が追加できなければ、可用クラスターを再選択するためにＳ４３０段階に復帰する。
【０１４２】
図２０は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース使用方法を示した流れ図である。
【０１４３】
先ず、クラスターリソース使用のためにアプリケーション資源使用量が登録される(Ｓ５００、S５１０)。
【０１４４】
クラウドプラットフォームシステムはクラスター資源可用量を問い合わせする(Ｓ５２０)。
【０１４５】
資源使用ができればアプリケーション資源を割り当てて機動する(Ｓ５３０)。この時、アプリケーション資源使用状態モニタリング及び制御がなされる。
【０１４６】
そして、残余リソース割り当て情報がアップデートされる(Ｓ５４０)。それではクラスターリソース使用が完了される(Ｓ５５０)。
【０１４７】
図２１は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース返納方法を示した流れ図である。
【０１４８】
クラスターリソース返納のためにアプリケーションが終わる(Ｓ５６０、S５７０)。
【０１４９】
クラウスプラットフォームシステムは、割り当てリソースを回収して(Ｓ５８０)、クラスター可用リソース情報をアップデートする(Ｓ５９０)。それではクラスターリソース返納が完了される(Ｓ６００)。
【０１５０】
一方、上述した本発明の実施例らはコンピューターで実行されることができるプログラムで作成可能であり、コンピューターで読める記録媒体を利用して前記プログラムを動作させる汎用デジタルコンピューターで具現されることができる。前記コンピューターで読める記録媒体は、マグネチック保存媒体(例えば、ロム・フロッピー・ハードディスクなど)、光学的判読媒体(例えば、CD-ROM・DVDなど)及びキャリアウエーブ(例えば、インターネットを通じた伝送)のような保存媒体を含む。
【０１５１】
このように本発明によるクラウドプラットフォームでアプリケーションをコンテナ化する方法によれば、隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、少ない大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能である。
【０１５２】
また、本発明によるクラウドプラットフォームでのマルチクラスタープロビゾニング及び管理方法によれば、多様なインフラにコンテナ基盤アプリケーションが動作することができるマルチクラスター環境を自動生成することができるし、遠隔でクラスターのバージョンアップグレードを管理して運営効率性を向上させることができる。
【０１５３】
今まで本発明に対してその望ましい実施例らを中心によく見た。本発明が属する技術分野で通常の知識を有した者は、本発明が本発明の本質的な特性から脱しない範囲で変形された形態で具現されることができることを理解することができる。それで、開示された実施例らは限定的な観点ではなく、説明的な観点で考慮されなければならない。本発明の範囲は前述した説明ではなく、特許請求範囲に現われているし、それと同等な範囲内にあるすべての差異は本発明に含まれる。
【産業上の利用可能性】
【０１５４】
本発明によるクラウドプラットフォームでのクラスターリソース割り当て及び管理方法は、クラスターリソースを効率的に割り当てて管理することができる効果を有する。
【図１】
2021530801.tif 000003
【図２】
2021530801.tif 000004
【図３】
2021530801.tif 000005
【図４】
2021530801.tif 000006
【図５】
2021530801.tif 000007
【図６】
2021530801.tif 000008
【図７】
2021530801.tif 000009
【図８】
2021530801.tif 000010
【図９】
2021530801.tif 000011
【図１０】
2021530801.tif 000012
【図１１】
2021530801.tif 000013
【図１２】
2021530801.tif 000014
【図１３】
2021530801.tif 000015
【図１４】
2021530801.tif 000016
【図１５】
2021530801.tif 000017
【図１６】
2021530801.tif 000018
【図１７】
2021530801.tif 000019
【図１８】
2021530801.tif 000020
【図１９】
2021530801.tif 000021
【図２０】
2021530801.tif 000022
【図２１】
2021530801.tif 000023
【国際調査報告】
2021530801.tif 000024
2021530801.tif 000025
2021530801.tif 000026
2021530801.tif 000027