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

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

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

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

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

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

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

整合性の維持

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

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

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

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

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

推奨事項: Amazon S3 アーカイブ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

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

個別のスタックの使用

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

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

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

開発スタック

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

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

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

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

  • AWS OpsWorks スタックのスタック管理機能へのアクセスを制御するには、スタックの[権限]

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

ステージングスタック

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

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

本稼働スタック

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

注記

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

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

  • 整合性 — 各スタックのテンプレートをソースリポジトリに保存することで、開発者が同じ目的に同じスタックを使用するようになります。

Blue-Green Deployment 戦略の使用

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

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

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

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

以下の例では、AWS OpsWorks スタックのスタックと AWS OpsWorks スタックのスタックとRoute 53のプールとElastic Load Balancing。切り替え前に以下の点を確認してください。

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

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

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

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

  • Elastic Load Balancing ロードバランサーのプールは、いずれかのスタックの Layer に動的にアタッチでき、加温済みを使用して、予想されるトラフィック量を処理します。

  • あなたはルート53を使用しました加重ルーティング機能を使用して、ロードバランサーのプールを含むホストゾーンにレコードセットを作成します。

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

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

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

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

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

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

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

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

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

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

Amazon RDS Layer

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

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

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

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

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

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

アプローチ 1: 両方のアプリケーションが同じデータベースに接続するようにする
利点
  • 移行中のダウンタイムはありません。

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

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

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

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

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

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

アプローチ 2: アプリケーションの各バージョンに専用のデータベースを提供する
利点
  • 各バージョンに専用のデータベースがあるため、スキーマ間の互換性は不要です。

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

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

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

推奨事項: 一般的に、Amazon RDS Layer は、移行シナリオを問わず、柔軟に適用できる Amazon RDS Layer を使用することをお勧めします。移行の処理方法の詳細については、『Amazon RDS ユーザーガイド