ベストプラクティス: アプリケーションとクックブックの管理とデプロイ - AWS OpsWorks
整合性の維持オンラインインスタンスへのコードのデプロイ

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

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

重要

AWS OpsWorks Stacks は新規顧客を受け付けなくなりました。既存のお客様は、2024 年 5 月 26 日までは OpsWorks コンソール、 API、 CLI、 および CloudFormation リソースを通常どおり使用できますが、その時点でこれらのリソースは廃止されます。この移行に備えて、できるだけ早くスタックを AWS Systems Manager に移行することをおすすめします。詳細については、AWS OpsWorks Stacks サポート終了に関する FAQ および AWS Systems Manager アプリケーションマネージャへの AWS OpsWorks Stacks アプリケーションの移行 を参照してください。

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

  • すべての本稼働スタックインスタンスには、A/B テストに使用する場合など限られた例外を除いて、同じアプリケーションとカスタムクックブックのコードが必要です。

  • 更新のデプロイによって、何か問題が発生しても、サイトのサービスが中断されないことが必要です。

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

整合性の維持

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

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

  • インスタンスを起動すると、AWS OpsWorks スタックによって現在のアプリケーションとクックブックのコードがインスタンスに自動的にデプロイされます。

  • オンラインインスタンスの場合は、Deploy コマンド (アプリケーション用) または Update Custom Cookbooks コマンド (クックブック用) を実行して、現在のアプリケーションまたはクックブックのコードを手動でデプロイする必要があります。

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

レコメンデーション: Amazon S3 アーカイブ

すべてのインスタンスに承認済みのコードバージョンがあることを確認するには、 Amazon Simple Storage Service (Amazon S3) アーカイブからアプリケーションとクックブックをデプロイすることをお勧めします。これにより、コードが静的なアーティファクト (.zip またはその他のアーカイブファイル) であり、明示的に更新する必要があることが保証されます。さらに、 Amazon S3 は信頼性が高いため、アーカイブにアクセスできなくなることはほとんどありません。一貫性をさらに確実に維持するには、命名規則を使用するか、 [Amazon S3 versioning (Amazon S3 バージョニング)] を使用して、各アーカイブファイルのバージョンを明示的に管理します。これにより監査証跡が提供され、以前のバージョンに簡単に戻せるようになります。

例えば、[Jenkins] などのツールを使用してデプロイパイプラインを作成できます。デプロイするコードがコミットされてテストされた後、アーカイブファイルを作成し、 Amazon S3 にアップロードします。すべてのアプリケーションのデプロイやクックブックの更新では、そのアーカイブファイル内のコードがインストールされるため、すべてのインスタンスのコードは同じになります。

推奨事項: Git または Subversion リポジトリ

Git または Subversion リポジトリを使用する場合は、マスターブランチからデプロイしないでください。その代わりに、承認されたバージョンにタグを付け、アプリケーションまたはクックブックソースとしてそのバージョンを指定します。

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

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

  • デプロイプロセス中、サイトでのお客様のリクエストの処理を中断することなく、更新を効率的にデプロイする。

  • デプロイされるアプリケーションまたはクックブックに関する問題やデプロイプロセス自体に関する問題のため失敗したデプロイを処理する。

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

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

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

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

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

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

ローリングデプロイを実行するには

  1. [Deploy App] ページで、[Advanced] を選択し、1 つのアプリケーションサーバーインスタンスを選択して、そのインスタンスにアプリケーションをデプロイします。

    慎重を期す場合は、アプリケーションのデプロイ前に、ロードバランサーからインスタンスを削除できます。これにより、更新されたアプリケーションは正常に動作していることが確認されるまで、ユーザーからアクセスされなくなります。Elastic Load Balancing を使用する場合は、 [remove the instance (インスタンスを削除する)] Elastic Load Balancing コンソール、 CLI、または SDK を使用してロードバランサーから取得します。

  2. 更新されたアプリケーションが正常に動作していること、インスタンスのパフォーマンスメトリックスが許容可能であることを確認します。

    Elastic ロードバランサーからインスタンスを削除した場合は、 Elastic Load Balancing コンソール、 CLI、または API を使用してそのインスタンスを復元します。これで、更新されたアプリケーションのバージョンで、ユーザーのリクエストが処理されるようになりました。

  3. アベイラビリティーゾーン内の残りのインスタンスに更新をデプロイし、それらのインスタンスが正常に動作していること、メトリクスが許容可能であることを確認します。

  4. スタックの他のアベイラビリティーゾーンに対して、一度に 1 ゾーンずつ、手順 3 を繰り返します。特に注意が必要な場合は、手順 1 から 3 を繰り返します。

注記

Elastic Load Balancing ロードバランサーを使用している場合は、そのヘルスチェックを使用して、デプロイメントが成功したことを確認できます。ただし、ping パス を設定するときは、依存関係をチェックしてすべてが正常に動作していることを確認するアプリケーションを指定してください。アプリケーションサーバーが動作していることを確認するだけの静的ファイルを指定しないでください。

個別のスタックの使用

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

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

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

開発スタック

開発スタックは、新しい機能の実装やバグの修正などのタスクに使用します。開発スタックは基本的に、本稼働スタックに含まれる同じレイヤー、アプリケーション、リソースなどが属するプロトタイプスタックです。開発スタックでは通常、本稼働スタックと同じ負荷を処理する必要がないため、インスタンスの数やサイズはより小さくなります。

開発スタックは公開されません。以下のようにアクセスを制御します。

  • 指定した IP アドレスまたはアドレス範囲からのみ受信リクエストを許可するように、アプリケーションサーバーまたはロードバランサーのセキュリティグループのインバウンドルールを設定することで、ネットワークアクセスを制限します。

    たとえば、HTTP、HTTPS、および SSH アクセスを自社のアドレス範囲内のアドレスに制限します。

  • スタックの [AWS OpsWorksPermissions] ページを使用して、スタックのスタック管理機能へのアクセスを制御します。

    たとえば、Manage アクセス権限レベルを開発チームに、Show アクセス権限を他のすべての従業員に付与します。

ステージングスタック

ステージングスタックは、更新された本稼働スタックの候補のテストと最終処理に使用します。開発が完了したら、開発スタックを複製することで、ステージングスタックを作成します。その後、ステージングスタックでテストスイートを実行し、そのスタックに更新をデプロイして、発生する問題を修正します。

ステージングスタックも公開されません。開発スタックに対する同じ方法でスタックおよびネットワークアクセスを制御します。開発スタックを複製してステージングスタックを作成するときは、AWS OpsWorks スタックのアクセス権限管理により付与されたアクセス権限を複製できることに注意してください。ただし複製は、ユーザーの IAM ポリシーによって付与されるアクセス権限には影響を与えません。これらのアクセス権限を変更するには、IAM コンソール、CLI、または SDK を使用する必要があります。詳細については、「ユーザー許可の管理」を参照してください。

本稼働スタック

本稼働スタックは、現在のアプリケーションをサポートする公開スタックです。ステージングスタックがテストに合格したら、本稼働スタックに昇格させ、古い本稼働スタックを削除します。これを行う方法の例については、「Blue-Green Deployment 戦略の使用」を参照してください。

注記

AWS OpsWorks スタックコンソールを使用してスタックを手動で作成する代わりに、スタックごとに AWS CloudFormation テンプレートを作成します。このアプローチには以下の利点があります。

  • スピードと利便性 – テンプレートを起動すると、 AWS CloudFormation によって必要なすべてのインスタンスを含むスタックが自動的に作成されます。

  • 一貫性 – 各スタックのテンプレートをソースリポジトリに保存することで、デベロッパーが同じ目的に同じスタックを使用するようになります。

Blue-Green Deployment 戦略の使用

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

  • Blue 環境は、現在のアプリケーションをホストする本稼働スタックです。

  • Green 環境は、更新されたアプリケーションをホストするステージングスタックです。

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

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

  • Green スタックにある更新されたアプリケーションはテストに合格し、本稼働用に準備ができている。

  • Green スタックは、更新されたアプリケーションが含まれていること、公開されないことを除いて、Blue スタックと同一である。

    両方のスタックでは、アクセス権限、各レイヤーのインスタンスの数とタイプ、時間ベースと負荷ベースの設定などは同一です。

  • Green スタックの 24/7 インスタンスおよびスケジュール済みの時間ベースのインスタンスのすべてがオンラインになっている。

  • いずれかのスタックのレイヤーに動的にアタッチでき、[pre-warmed (事前にウォーミングアップ)] することができるElastic Load Balancing ロードバランサーのプールがあり、予想されるトラフィックボリュームを処理します。

  • Route 53の [weighted routing feature (加重ルーティング機能) ] を使用して、プールされたロードバランサーを含むホストゾーンにレコードセットを作成しま。

  • Blue スタックのアプリケーションサーバーレイヤーにアタッチされているロードバランサーにゼロ以外の重みを割り当て、未使用のロードバランサーにゼロの重みに割り当てている。これにより、Blue スタックのロードバランサーによってすべての受信トラフィックが処理されるようになります。

Green スタックにユーザーを切り替えるには

  1. Green スタックのアプリケーションサーバーレイヤーにプールの未使用のロードバランサーのいずれかをアタッチします。フラッシュトラフィックを想定できる場合や、トラフィックを徐々に増加させるための負荷テストを設定できない場合など、シナリオによっては、想定したトラフィックを処理できるようにロードバランサーの事前ウォーミングを行います。

  2. Green スタックのすべてのインスタンスが Elastic Load Balancing ヘルスチェックに合格した後、 Route 53 レコードセットの重みを変更し、 Green スタックのロードバランサーの重みがゼロ以外になり、それに応じて Blue スタックのロードバランサーの重みを減らすようにします。まずは、Green スタックで受信リクエストのごく一部 (多くの場合 5%) が処理され、Blue スタックで残りが処理されるようにすることをお勧めします。これで、2 つの本稼働スタックが用意できました。Green スタックで受信リクエストの一部が処理され、Blue スタックで残りが処理されます。

  3. Green スタックのパフォーマンスメトリクスを監視します。それらのメトリクスが許容可能であれば、多くの場合、Green スタックの重みを増やして、受信トラフィックの 10% が処理されるようにします。

  4. Green スタックで受信トラフィックの約半分が処理されるようになるまで、手順 3 を繰り返します。すべての問題はこの時点までに確認できるため、Green スタックのパフォーマンスメトリクスが許容可能であれば、Blue スタックの重みをゼロまで減らすことで、プロセスを完了できます。これで、Green スタックは新しい Blue スタックになり、このスタックですべての受信トラフィックが処理されるようになります。

  5. 古い Blue スタックのアプリケーションサーバーレイヤーからロードバランサーをデタッチし、プールに戻します。

  6. 古い Blue スタックは、ユーザーのリクエストの処理に使用されなくなりますが、新しい Blue スタックに問題が発生した場合に備えて、しばらく保持することをお勧めします。その場合は、古い Blue スタックに受信トラフィックを割り振り直すことで、更新をロールバックできます。新しい Blue スタックのパフォーマンスメトリクスが許容可能になったことを確認できたら、古い Blue スタックをシャットダウンします。

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

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

Amazon RDS Layer

[Amazon Relational Database Service (Amazon RDS) layer Amazon Relational Database Service (Amazon RDS) レイヤー ] では、 RDS DB インスタンスを個別に作成し、スタックに登録します。RDS DB インスタンスを登録できるのは一度に 1 つのスタックのみですが、スタック間で RDS DB インスタンスを切り替えることができます。

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

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

  • 移行中にすべてのトランザクションを適切に記録すると同時に、アプリケーションの新旧バージョン間の競合状態を回避する。

  • サイトのパフォーマンスへの影響を制限し、かつダウンタイムを最小限に抑えるかなくす方法で、移行を行う。

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

アプローチ 1: 両方のアプリケーションが同じデータベースに接続するようにする
利点

  • 移行中のダウンタイムはありません。

    データベースへのアクセスを一方のアプリケーションが徐々に停止しながら、他方のアプリケーションが徐々に引き継ぎます。

  • 2 つのデータベース間でデータを同期する必要はありません。

チャレンジ

  • 両方のアプリケーションが同じデータベースにアクセスするため、アクセスを管理してデータの損失や破損を防ぐ必要があります。

  • 新しいデータベーススキーマに移行する必要がある場合、古いバージョンのアプリケーションで新しいスキーマを使用できる必要があります。

個別のスタックを使用している場合、インスタンスが特定のスタックに永続的に関連付けられず、異なるスタックで動作するアプリケーションからアクセスできるため、このアプローチはおそらく Amazon RDS に最適です。ただし、一度に複数のスタックに RDS DB インスタンスを登録できないため、JSON などを使用して両方のアプリケーションに接続データを渡す必要があります。詳細については、「カスタムレシピの使用」を参照してください。

ローリングアップグレードを使用する場合、新旧のアプリケーションバージョンは同じスタックでホストされるため、 Amazon RDS または MySQL のいずれかのレイヤーを使用できます。

アプローチ 2: アプリケーションの各バージョンに専用のデータベースを提供する
利点

  • 各バージョンに専用のデータベースがあるため、スキーマ間の互換性は不要です。

チャレンジ

  • 移行中に 2 つのデータベース間でデータを同期して、データの損失や破損がないようにする必要があります。

  • 同期手順によりサイトで重大なダウンタイムやパフォーマンスの大幅な低下が生じないようにする必要があります。

個別のスタックを使用する場合、各スタックに専用のデータベースを用意できます。ローリングデプロイを使用する場合、2 つのデータベースをスタックにアタッチし、各アプリケーションに 1 つのデータベースを用意できます。古いアプリケーションと更新されたアプリケーションとの間でデータベーススキーマの互換性がない場合、このアプローチの方が適しています。

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