クラウドにアプリケーションをデプロイする
クラウド アプリケーションの設計と開発が完了すると、クライアントにリリースするためにデプロイ フェーズに進むことができます。 デプロイは多段階のプロセスであり、各段階でアプリケーションの目標が達成されていることを確認する一連のチェックを伴います。
クラウド アプリケーションを運用環境にデプロイする前に、必須および推奨のベスト プラクティスの一覧に対するアプリケーションの評価に役立つチェックリストを用意しておくと役立ちます。 例として、AWS および Azure の導入チェックリストがあります。 多くのクラウド プロバイダーは、Azure のこちらのドキュメントなど、導入を支援するツールとサービスの包括的な一覧を提供しています。
デプロイ プロセス
クラウド アプリケーションのデプロイは反復的なプロセスであり、開発の終了から始まり、運用リソースへのアプリケーションのリリースに向かって続行されます。
図 1: コードのデプロイ プロセス
クラウド開発者は、アプリケーションの複数の同時実行バージョンを維持して、アプリケーションのデプロイをさまざまな段階にパイプライン処理することが一般的です。
- テスト
- ステージング
- 運用
3 つの各段階は、理想的にはリソースと構成が同じである必要があります。そうすれば、開発者がアプリケーションをテストしてデプロイし、環境や構成の変更によって矛盾が生じる可能性を最小限に抑えることができます。
アプリケーションの変更をパイプライン処理する
(前の図に示すように) 一般的なアジャイル アプリケーション開発シナリオでは、何らかの問題追跡メカニズムを使用して問題やバグを処理する一連のエンジニアと開発者によってアプリケーションは管理されます。 コードに対する変更は、コード リポジトリ システム (たとえば、svn、mercurial、git) を通じて維持され、コードのリリースに対して個別のブランチが維持されます。 コードの変更、レビュー、承認を経た後、コードをテスト、ステージング、および運用フェーズへとパイプライン処理できます。 この処理には複数の実行方法があります。
カスタム スクリプト: 開発者はカスタム スクリプトを使用してコードの最新バージョンをプルし、特定のコマンドを実行してアプリケーションをビルドし、それを運用状態にすることができます。
事前に準備した仮想マシン イメージ: 開発者は、アプリケーションをデプロイするために必要なすべての環境とソフトウェアを備えた仮想マシンをプロビジョニングして構成することもできます。 構成が完了すると、仮想マシンのスナップショットを作成して仮想マシン イメージにエクスポートできます。 このイメージをさまざまなクラウド オーケストレーション システムに提供して、自動的にデプロイし、運用デプロイ用に構成することができます。
継続的インテグレーション システム: デプロイに伴うさまざまなタスクを簡略化するために、継続的インテグレーション (CI) ツールを使用して、運用インフラストラクチャを構成するさまざまなマシンで完了する必要があるタスク (リポジトリからの最新バージョンの取得、アプリケーション バイナリの構築、テスト ケースの実行など) を自動化できます。 一般的な CI ツールの例としては、Jenkins、Bamboo、Travis などがあります。 Azure Pipelines は、Azure のデプロイと連携するように設計された Azure 固有の CI ツールです。
ダウンタイムを管理する
アプリケーションの変更によっては、アプリケーションのバックエンドに変更を組み込むために、アプリケーション サービスの一部またはすべてを終了する必要があります。 通常、開発者は、アプリケーションのユーザーの中断を最小限に抑えるような時間をスケジュールする必要があります。 継続的インテグレーションを目的として設計されたアプリケーションは、アプリケーションのクライアントの中断を最小限に抑えるか、まったく中断することなく、運用環境システムでこのような変更をライブで実行できる場合があります。
冗長性とフォールト トレランス
アプリケーション デプロイのベスト プラクティスは、通常、クラウド インフラストラクチャが一時的なものであり、いつでも使用不能になったり、変更されたりする可能性があることを前提としています。 たとえば、SLA の種類によっては、IaaS サービスにデプロイされた仮想マシンは、クラウド プロバイダーの判断で終了するようにスケジュールされる場合があります。
アプリケーションでは、データベースやストレージ エンドポイントなどのさまざまなコンポーネントの静的なエンドポイントをハードコーディングしたり想定したりしないでください。 適切に設計されたアプリケーションでは、サービス API を使用してリソースのクエリと発見を行い、動的な方法でそれらに接続することが理想的です。
リソースまたは接続の致命的な失敗がすぐに発生する可能性があります。 重要なアプリケーションは、このような失敗を想定して設計する必要があります。また、フェールオーバーの冗長性を考慮して設計する必要があります。
多くのクラウド プロバイダーは、リージョンとゾーンに分けてデータセンターを設計しています。 リージョンは完全なデータセンターを収容する特定の地理的サイトであり、ゾーンはフォールト トレランスのために分離されたデータセンター内の個々のセクションです。 たとえば、1 つのゾーンの障害が他のゾーンのインフラストラクチャに影響を与えることがないように、データセンター内の 2 つ以上のゾーンが個別の電源、冷却、および接続インフラストラクチャを持っている場合があります。 通常、クラウド サービス プロバイダーは、この分離の特性を利用するアプリケーションを設計および開発できるように、クライアントと開発者に対してリージョンとゾーンの情報を提供しています。
そのため、開発者は、アプリケーションの可用性を向上させ、ゾーンまたはリージョン全体で発生する可能性のある失敗を許容するために、複数のリージョンまたはゾーンのリソースを使用するようにアプリケーションを構成できます。 リージョンとゾーン全体でトラフィックをルーティングおよび分散できるシステムを構成する必要があります。 要求の発信元に応じて、各ゾーンの特定の IP アドレスへのドメイン参照要求に応答するように DNS サーバーを構成することもできます。 こうすることで、クライアントの地理的な距離に基づいて負荷を分散する方法を実現できます。
運用環境でのセキュリティとセキュリティ強化
パブリック クラウドでのインターネット アプリケーションの実行には注意が必要です。 クラウドの IP 範囲は高価値のターゲットとしてよく知られた場所であるため、エンドポイントとインターフェイスをセキュリティで保護し、セキュリティを強化する際には、クラウドにデプロイされたすべてのアプリケーションが確実にベスト プラクティスに従うことが重要です。 次のような基本的な原則があります。
- すべてのソフトウェアを運用モードに切り替えるようにします。 ほとんどのソフトウェアは、ローカル テスト用の "デバッグ モード" と実際のデプロイ用の "運用モード" をサポートしています。 通常、デバッグモードのアプリケーションからは、不正な入力を送信する攻撃者に対して大量の情報が漏えいされるため、ハッカーは簡単に偵察を行うことができます。 Django や Rails のような Web フレームワークや、Oracle のようなデータベースを使用している場合でも、運用アプリケーションをデプロイするための関連ガイドラインに従うことが重要です。
- 非パブリック サービスへのアクセスは、管理者アクセス用の特定の内部 IP アドレスに制限するようにします。 管理者が、内部スタート パッドにアクセスせずに、インターネットから重要なリソースに直接ログインできないようにします。 必要最小限のアクセス セット (特に SSH およびその他のリモート接続ツールを介するもの) を許可するように、IP アドレスとポートベースのルールを使用してファイアウォールを構成します。
- 最小限の特権の原則に従います。 必要なロールを実行できる最小限の特権を持つユーザーとして、すべてのサービスを実行します。 システム内の一部の重要な問題をデバッグまたは構成する必要があるシステム管理者による特定の手動ログインに対して、ルート資格情報の使用を制限します。 これは、データベースおよび管理パネルへのアクセスにも適用されます。 通常、アクセスは長いランダムな公開キーと秘密キーのペアを使用して保護するようにします。また、制限され、暗号化された場所にこのキー ペアを安全に保存するようにします。 すべてのパスワードには厳格な強度要件が必要です。
- 侵入検知と防止システム (IDS/IPS)、セキュリティ情報とイベント管理 (SIEM)、アプリケーション層ファイアウォール、およびマルウェア対策システムについては、よく知られている防御テクノロジとツールを使用します。
- 使用するシステムのベンダーによるパッチ リリースに合わせて修正スケジュールを設定します。 多くの場合、Microsoft などのベンダーには、パッチの固定のリリース サイクルがあります。