翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ベストプラクティス: アプリケーションとクックブックの管理とデプロイ

AWS OpsWorks スタックは、リモートリポジトリから新しいインスタンスにアプリケーションとクックブックをデプロイします。インスタンスのライフタイム中、機能の追加やバグの修正などのために、スタックのオンラインインスタンスでアプリケーションとクックブックを頻繁に更新する必要があります。スタックのアプリケーションとクックブックの管理にはさまざまな方法がありますが、使用するアプローチは以下の一般的な要件を満たす必要があります。

このセクションでは、アプリケーションとカスタムクックブックを管理およびデプロイするためのベストプラクティスについて説明します。

整合性の維持

一般的に、本稼働スタックで実行されるアプリケーションとクックブックのコードは厳密に管理する必要があります。また、すべてのインスタンスでは、コードの現在承認されているバージョンを実行する必要があります。ただし例外があり、アプリケーションやクックブックを更新するときや、後述するように、A/B テストの実施など特殊な場合に対応するときは除きます。

アプリケーションとクックブックのコードは、以下の 2 つの方法で、指定したソースリポジトリからスタックのインスタンスにデプロイされます。

2 つのデプロイメカニズムがあるため、重要なのは、違ったコードを別のインスタンスで意図せず実行しないように、ソースコードを慎重に管理することです。例えば、Git マスターブランチからアプリケーションまたはクックブックをデプロイする場合、 AWS OpsWorks Stacks はその時点でそのブランチにあるものをデプロイします。マスターブランチにあるコードを更新し、新しいインスタンスを起動した場合、そのインスタンスには、以前のインスタンスにあるコードよりも新しいバージョンのコードがでデプロイされます。より新しいバージョンであっても本稼働用として承認されない場合があります。

オンラインインスタンスへのコードのデプロイ

AWS OpsWorks スタックは、更新されたコードをオンラインインスタンスに自動的にデプロイしません。手動でデプロイする必要がありますが、以下の課題があります。

最も簡単なアプローチは、デフォルトの Deploy コマンド (アプリケーション用) または Update Custom Cookbooks コマンド (クックブック用) を実行して、更新をすべてのインスタンスに同時にデプロイすることです。このアプローチは、シンプルで高速ですが、エラーに対する許容範囲がありません。デプロイが失敗した場合や、更新されたコードに問題がある場合、本稼働スタックのすべてのインスタンスが影響を受けることがあります。問題が解決されるか、以前のバージョンにロールバックされるまで、サイトのサービスが中断されるか無効になる可能性があります。

推奨事項: 堅牢なデプロイ戦略を使用することをお勧めします。デプロイが成功して、新しいバージョンのコードを実行しているインスタンスにすべての受信トラフィックが転送できるようになるまで、以前のバージョンのコードを実行しているインスタンスでリクエストの処理が継続されるようにします。

以下のセクションでは、堅牢なデプロイ戦略の 2 例を示してから、デプロイ中にバックエンドデータベースを管理する方法について説明します。わかりやすいように、更新されたアプリケーションについて説明していますが、クックブックについても方法は同じです。

ローリングデプロイの使用

ローリングデプロイでは、スタックのオンラインアプリケーションサーバーインスタンスでアプリケーションが複数のフェーズで更新されます。各フェーズでオンラインインスタンスのサブセットを更新し、次のフェーズの開始前に更新が成功していることを確認します。問題が発生した場合、その問題を解決するまで、以前のバージョンのアプリケーションを実行しているインスタンスで受信トラフィックの処理が継続されます。

以下の例では、複数のアベイラビリティーゾーンにまたがってスタックのアプリケーションサーバーインスタンスを配布するというベストプラクティスの使用を前提としています。

個別のスタックの使用

アプリケーションを管理するための別のアプローチは、アプリケーションのライフサイクルの各フェーズに別個のスタックを使用することです。この個別のスタックは環境と呼ばれることがあります。このアプローチでは、パブリックアクセス可能でないスタックで開発とテストを行うことができます。更新をデプロイする準備ができたら、現在のバージョンのアプリケーションのホストするスタックから、更新されたバージョンをホストするスタックに、ユーザートラフィックを切り替えます。

開発、ステージング、本稼働スタックの使用

最も一般的なアプローチでは、以下のスタックを使用します。

Blue-Green Deployment 戦略の使用

Blue-Green Deployment 戦略は、個別のスタックを効率的に使用して、更新されたアプリケーションを本稼働にデプロイする一般的な方法の 1 つです。

更新されたアプリケーションを本稼働にデプロイする準備ができたら、Blue スタックから新しい本稼働スタックとなる Green スタックにユーザートラフィックを切り替えます。その後、古い Blue スタックを削除します。

次の例では、 AWS OpsWorks Stacks スタックを使用して、 [Route 53 (ルート 53) ] および [Elastic Load Balancing load balancers (Elastic Load Balancing ロードバランサー)] のプールを併用して、ブルーグリーンのデプロイを実行する方法を説明します。切り替え前に以下の点を確認してください。

バックエンドデータベースの管理

アプリケーションがバックエンドデータベースに依存している場合は、古いアプリケーションから新しいアプリケーションに移行する必要があります。 AWS OpsWorks スタックでは、次のデータベースオプションがサポートされています。

AWS OpsWorks スタックは、アプリケーションサーバーに接続データを含むファイルを、アプリケーションで簡単に使用できる形式でインストールします。 AWS OpsWorks スタックは、データベース接続情報をスタック設定とデプロイ属性に追加し、レシピからアクセスできます。さらに、JSON を使用して、アプリケーションに接続データを渡すこともできます。詳細については、「データベースへの接続」を参照してください。

データベースに依存するアプリケーションを更新するには、2 つの基本的な課題があります。

このトピックで説明するデプロイの戦略を使用するときは、データベースを古いアプリケーションからデタッチし、新しいアプリケーションに再アタッチするだけでは済みません。アプリケーションの両方のバージョンが移行中に並行して実行され、同じデータにアクセスできる必要があります。以下に説明しているのは、移行を管理するための 2 つのアプローチです。いずれのアプローチにも利点と課題があります。

[Recommendation: (レコメンデーション:) 一般的に、アプリケーションのバックエンドデータベースとしては、移行シナリオを問わず、柔軟に適用できる Amazon RDS レイヤーを使用することをお勧めします。移行の処理方法の詳細については、「Amazon RDS User Guide (Amazon RDS ユーザーガイド) 」 を参照してください。