/写真ジュハン・ソニン CC
クラウドインフラストラクチャの要件は常に変化しているため、新しいビジネスモデルを開発し、アーキテクチャソリューションを作成する必要があります。 これにより、セキュリティとデータ管理のレベルを常に向上させることができます。
Habréのブログでは、データ管理とIaaSプロバイダーのクラウドへのバックアップの整理のためのソリューションとサービスについて既に書いています。
今日は、IaaSモデルでのサービスの配信と設計のトピックに触れたいと思います。 アプリケーション開発および配信プロセスのすべての参加者のコラボレーションを促進する展開モデルについて説明します。
サービス設計
テクノロジーとビジネスプロセスは毎年複雑になり、処理されるデータの量は増え続けています。 会社のリソースを最大限に活用してユーザーの満足度を高めるには、ITILライブラリを使用することをお勧めします。 ITILは、高品質のITサービスを提供するためのベストプラクティスを提供します。
このアプローチは、組織がその目標を達成することに焦点を合わせ、その達成に費やされるリソースにも焦点を合わせます。 戦略を立てるとき、サービスプロバイダーは、潜在的な顧客の目標に主に焦点を合わせる必要があります。 そのためには、提供されたITサービスがクライアントのビジネスで果たす役割を明確に理解する必要があります。 ここでITIL方法論が助けとなり、サービス設計の基本段階である戦略の構築を支援します。
ITILは、さまざまな分野の企業の間で広く人気を集めています。 Hewlett-Packard、Boeing、IBM、Sony、Honda、その他多くの企業がITILと協力しています。 Forresterは、itSMF（IT Service Management Forum）の491人の参加者にインタビューして調査を実施しました。 得られたデータによると、ITILが提案した方法により、回答者の85％でサービスの生産性が向上し、回答者の65％がビジネスの評判にプラスの影響を与えると指摘しました。 シスコがITIL支持者の仲間入りをしたと言っておく価値があります。 専門家が言うように、サービス設計はクラウドインフラストラクチャの重要なコンポーネントです。
サービス設計へのアプローチに大きな影響を与えたのは 、すべての活動分野でのクラウドテクノロジーの普及です。 サービス設計は、設計調整、サービスカタログ管理、サービスレベル管理、容量管理、可用性管理、サービス継続性管理、情報セキュリティ管理、サプライヤ管理の8つのポイントを含む深刻な段階です。 これらの各側面には、特定の変更が加えられています。
サービスをカタログに追加するタスクでは、クラウドサービスの適切な説明が必要になり始めたため、クライアントはその実装に関する質問をしませんでした。 サービスレベル管理にも同じことが当てはまります。サービスレベル契約（SLA）では、クラウドインフラストラクチャの問題をトラブルシューティングする時間、支払われる補償、提供される保証などの瞬間を詳しく説明する必要があります。
次の項目はアクセシビリティ管理です。 クラウドに移行する場合、ユーザーがアプリケーションを「インプレース」で展開したかのように、プロバイダーが高レベルのアクセシビリティを提供することが重要になります。 たとえば、IaaSの場合、リソースを監視するためのツールを提供するだけでなく、接続可能なメモリまたはプロセッサの可用性を確保する必要があります。
サービスの管理に関しては、マネージャーは会社のサイトだけでなく、クラウドプロバイダーのサイトの「転倒」の可能性を考慮する必要があります。 さらに、組織はサービスプロバイダーが提供するソリューションを研究し、市場を調査し、妥協を模索する必要があります。 これらすべてにより、セキュリティ条件、機密性、およびデータ整合性の評価を忘れてはなりません。
サービス設計の最後の要素は、サプライヤ管理プロセスです。 また、変更が加えられました。外部サービスを評価し、提供されるサービスの品質を監視する必要がありました。 重要なことは、追加のタスクがサプライヤーとの信頼関係を確立することでした。
展開モデル
現在の「クラウド」の世界では、ITチームがインフラストラクチャをエンドユーザーに提供する方法を決定するプロセスが変更されています。 Red Hatの従業員James Labockiは、通信、金融、輸送など、さまざまなビジネス分野の組織を数か月にわたって監視しました 。 この間、彼はチーム間の相互作用のメカニズムを評価し、サービスの設計を改善するための3つの主要なモデルを特定することに成功しました。
反復可能な展開モデル
このモデルでは、システム管理者のチームがインフラストラクチャ要素の開発と構成を担当します。インフラストラクチャ要素の責任は、仮想環境（仮想スイッチ、ストレージ、仮想マシン、OSのインストール）へのリソースの割り当て、コンテナーの展開、および保護の確保を含みます。
インフラストラクチャが構成された後、アプリケーションの配信を担当するチームが作業に入ります。 配信スペシャリストの責任には、アプリケーションを正しく実行および実行するために必要なサービスの展開、アプリケーションサーバークラスターの構成、データベース接続プールの設定が含まれます。 彼らの仕事の最後のステップは、アプリケーションをバイナリファイルからリポジトリにデプロイすることです。
このようなモデルでは、インフラストラクチャの展開はより頻繁に自動化され、アプリケーションサーバーの展開と構成のみが行われることもあります。 バイナリファイルからのアプリケーションのデプロイは、多くの場合自動化されていません。
このモデルは実装が最も簡単ですが、開発プロセスとアプリケーション自体の展開、構成、および操作との接続性が欠如しているため、高速配信を必要とする問題を解決できません。 さらに、このようなモデルは、アプリケーションの展開段階で人的要因の強い影響を受けるため、「防弾」ではありません。
カスタムの再現可能なビルドモデル
このモデルでは、システム管理者のチームが、インフラストラクチャ（ストレージ、ネットワーク、仮想マシン、コンテナ）の展開と構成を引き続き担当します。 ただし、このタイプのタスクは、専用のツールを使用して自動化されることがよくあります。 その後、完成したインフラストラクチャは分割不可能なユニットの形でアプリケーション配信チームに転送されます。
配信スペシャリストは、アプリケーションサーバーの構成と実行可能ファイルの送信を担当します。これはすべて、自動化および構成管理プラットフォームを使用して行われます。
カスタマイズされた繰り返しビルドのモデルは、開発プロセスに費やす時間を節約しますが、ソースをバンドルし、作業イメージを準備し、展開を自動化するための特別な知識が必要です。 さらに、このモデルには大きなマイナス点があります。1つのアプリケーションの試運転には数か月かかるため、数千のアプリケーションを実行する大企業にはこのようなモデルは受け入れられない場合があります。
規範的な反復可能なビルドモデル
規定の繰り返しビルドモデルの仮想インフラストラクチャには、システム管理チームが構成したストレージ、ネットワーク、仮想マシン、またはコンテナーが含まれます。 ただし、この場合、構成されたインフラストラクチャはアプリケーション配信チームではなく、クラウドインフラストラクチャのリソースを使用してPaaSサービスを提供するPaaSチームに転送されます。
PaaSモデルの開発環境には、セルフサービスポータルとして表示されるユーザーインターフェイスを使用してアクセスします。 開発者は、サービスを操作したり、アプリケーションソースにアクセスしたりするための便利なインターフェイスを利用できます。
このタイプのモデルの特徴は、最高レベルの標準化です。これにより、開発者はソースコードと動作中のアプリケーションをすばやく切り替えて、あらゆる種類の問題を解消できます。
おわりに
結論として、組織のパターンの選択は多くの要因に依存することに注意してください。
- 自身のスキルのレベル。
- アプリケーション開発プロセスの均一性。
- アプリケーションのライフサイクルに関連するビジネス要件（特に、時間）。
- アプリケーションアーキテクチャ。
- 管理プロセスの柔軟性。
また、 IaaSモデルでエンドユーザーにサービスを提供する速度と方法は、多くの変数に依存することも言う価値があります。 ただし、決定要因の1つは、展開パターンの選択と、隣接するチームの調整作業です。
PSHabréのブログのその他の資料：