STAY KOBE

[SolutionArchitect Pro] AWS OpsWorks

AWS OpsWorks

OpsWorks スタック

スタック

レイヤー

レシピとライフサイクルイベント

インスタンス

Apps


AWS認定試験の練習問題

  1. お客様は、データセンターで Chef 構成管理を使用している顧客と作業しています。どのサービスが AWS で既存のシェフレシピを活用できるように設計されていますか?
    1. Amazon Simple Workflow Service
    2. AWS Elastic Beanstalk
    3. AWS CloudFormation
    4. AWS OpsWorks
  2. あなたのミッションは、ライトアウトデータセンター環境を作成し、これを達成するために AWS OpsWorks を使用する予定です。最初にスタックを作成し、その中で実行されているインスタンスでアプリケーションサーバー層を追加しました。次に、インスタンスにアプリケーションを追加し、これで MySQL RDS データベースインスタンスをデプロイする必要があります。バックエンドデータベースサーバーを OpsWorks スタックに追加する方法について、次の回答のうち正確な説明はどれか?3つの回答を選択
    1. 新しいデータベース層を追加し、データベースおよびアプリケーションサーバー層のデプロイアクションにレシピを追加します。(リンク参照)
    2. プライマリ AZ で障害が発生した場合に冗長性を確保するために、別のアベイラビリティーゾーンに2番目の RDS スタックを作成するには、OpsWorks の “クローンスタック” 機能を使用します。セカンダリ RDS インスタンスに切り替えるには、カスタム JSON を使用して実行できるサーバーに適した値に [:database] 属性を設定します。
    3. RDS データベース接続 (ホスト、ユーザーなど) を特徴付ける変数は、デプロイ JSON の [:deploy] [:app_name] [:database] 属性の対応する値を使用して設定されます。(リンク参照)
    4. クックブック属性はリポジトリに格納されるため、OpsWorks では、少なくとも256ビットキーを使用して RDS インスタンスの “password”: “your_password” 属性を暗号化する必要があります。
    5. カスタムレシピを使用して、アプリサーバーと RDS 層の間の接続を設定します。レシピでは、通常、構成ファイルを作成することによって、必要に応じてアプリサーバーを構成します。レシピは、ホストとデータベース名などの接続データを、すべてのインスタンスに AWS OpsWorks がインストールするスタック構成およびデプロイメント JSON 内の一連の属性から取得します。([リンク参照])
  3. あなたは、AWS への非常にトラフィックの多いノードの js アプリケーションの移行を任務としている。組織標準に準拠するためには、このアプリケーションをホストするアプリケーションサーバーを構成し、アプリケーションライフサイクルイベントをサポートするために、Chef レシピを使用する必要があります。管理上の負担を最小限に抑えながら、これらの要件を満たす展開オプションはどれですか。
    1. Opsworks 内に新しいスタックを作成する適切なレイヤをスタックに追加し、アプリケーションをデプロイします。
    2. Elastic Beanstalk の中に新しいアプリケーションを作成し、新しい環境にこのアプリケーションを展開する (シェフのレシピに準拠する必要があります)
    3. コミュニティ AMI からノード JS サーバーを起動し、起動した EC2 インスタンスにアプリケーションを手動でデプロイする
    4. EC2 インスタンスで Chef サーバーを起動して構成し、AWS CLI を活用してアプリケーションサーバーを起動し、Chef を使用してそれらのインスタンスを構成します。
  4. Web Startup は、Elastic Load Balancer、Java / Tomcatアプリケーションサーバーの Auto-Scaling グループ、およびデータストアとしての DynamoDB を使用して、Amazon EC2 上で非常に成功したソーシャルニュースアプリケーションを実行します。 メインの Web アプリケーションは、メモリに非常に拘束されているので、m2.xlarge インスタンス上で実行するのが最適です。 新しいデプロイメントでは、アプリケーションサーバー用の新しい AMI の半自動化された作成とテストが必要です。これにはかなりの時間がかかり、したがって1週間に1回しか実行されません。 最近、新しいチャット機能が node.js に実装され、アーキテクチャに統合されるのを待ちます。 最初のテストでは、新しいコンポーネントが CPU にバインドされていることがわかりました。Chef の使用経験があるため、導入プロセスを合理化し、AWS OpsWorks をアプリケーションのライフサイクルツールとして使用して、アプリケーションの管理を簡素化し、 新しいチャットモジュールを最も費用対効果の高い柔軟な方法で統合するには、AWS OpsWorks のどの設定が必要ですか?
    1. 1つの AWS OpsWorks スタックを作成し、1つの AWS OpsWorks レイヤーを作成し、1つのカスタムレシピを作成します。
    2. 1つの AWS OpsWorks スタックを作成し、2つの AWS OpsWorks レイヤを作成し、1つのカスタムレシピ (単一環境スタック、2層の java と node.js アプリケーションを使用して、他の構成としてのみ DynamoDB 接続のレシピとカスタムレシピを作成します。リンク参照)
    3. 2つの AWS OpsWorks スタックを作成し、2つの AWS OpsWorks レイヤーを作成し、1つのカスタムレシピを作成する。
    4. 2つの AWS OpsWorks スタックを作成し、2つの AWS OpsWorks レイヤーを作成し、2つのカスタムレシピを作成します。
  5. あなたは、同じ Amazon Relational Database(RDS) データベースを基にした約10種類のソフトウェアコンポーネントで構成される複雑な顧客関係管理システムを運用しています。 AWS OpsWorks を採用して、そのアプリケーションの管理とデプロイメントを簡素化し、個々のコンポーネントごとにレイヤーを備えた AWS OpsWorks スタックを作成しました。 内部セキュリティポリシーでは、すべてのインスタンスを最新の Amazon Linux AMI で実行する必要があり、最新の Amazon Linux AMI がリリースされてから1ヶ月以内にインスタンスを置き換える必要があります。 AMI の置き換えは、アプリケーションのダウンタイムや容量の問題を引き起こすことなく行う必要があります。 あなたは、新しいAmazon Linux AMI がリリースされるとすぐに実行されるようにスクリプトを書くことに決めました。 どのソリューションがセキュリティポリシーをサポートし、要件を満たしていますか? 2つの回答を選択
    1. 基礎となる AMI を置き換えるカスタムレシピを各レイヤに割り当てます。このカスタムレシピを段階的に実行し、新しい AMI でインスタンスを更新するには、AWS OpsWorks ライフサイクルイベントを使用します。
    2. 新しいスタックとレイヤーを同一の構成で作成し、カスタム AMI として指定された最新の Amazon Linux AMI を持つインスタンスを新しいレイヤーに追加し、DNS を新しいスタックに切り替え、古いスタックを破棄します。 (Blue-Green デプロイメント)
    3. AWS OpsWorks スタックのすべての Amazon Elastic Compute Cloud(EC2) インスタンスを識別し、各インスタンスを停止し、AMI ID プロパティを最新の Amazon Linux AMI ID の ID に置き換え、インスタンスを再起動します。 停止時間を避けるために、複数のインスタンスが同時に停止しないようにしてください。
    4. 最新の Amazon Linux AMI をスタックレベルでカスタム AMI として指定し、スタックのインスタンスを終了し、AWS OpsWorks が新しい AMI で新しいインスタンスを起動できるようにします。 (ダウンタイムにつながる)
    5. カスタム AMI として指定された最新の Amazon Linux AMI を持つ新しいインスタンスをスタックのすべての AWS OpsWorks レイヤに追加し、古い AMI を終了します。
  6. AWS OpsWorks について考える場合、スタックレイヤに割り当てることができるインスタンスタイプではないのは次のうちどれですか。
    1. 24/7 インスタンス (24/7 インスタンスがサポートされ、手動で起動し、停止するまで実行)
    2. スポットインスタンス (スポットインスタンスを直接サポートしていませんが、自動スケーリングで使用できます。リンク参照)
    3. 時間ベースのインスタンス (時間ベースのインスタンスは、指定された毎日および毎週のスケジュールで AWS OpsWorks によって実行されます)
    4. 負荷ベースのインスタンス (負荷ベースのインスタンスは、CPU 使用率などの指定された負荷メトリックに基づいて、AWS OpsWorks によって自動的に開始および停止されます)
  7. スタックを監視するために、AWS OpsWorks を直接サポートしていない次のツールはどれですか?
    1. AWS Config (リンク参照)
    2. Amazon CloudWatch メトリック(AWS OpsWorks は CloudWatch を使用して、13個のカスタムメトリックにスタック内の各インスタンスの詳細な監視を提供します)
    3. AWS CloudTrail(AWS OpsWorksはCloudTrail と統合して AWS OpsWorks API コールをすべて記録し、 S3 バケット)
    4. Amazon CloudWatch Logs(Amazon CloudWatch Logs を使用して、スタックのシステム、アプリケーション、およびカスタムログを監視できます)
  8. AWS OpsWorks について考えた場合、次のどちらが該当しますか。
    1. スタックには多くのレイヤーがあり、レイヤーには多くのインスタンスがあります。
    2. インスタンスには多くのスタックがあり、スタックには多くのレイヤーがあります。
    3. レイヤーには多くのスタックがあり、スタックには多くのインスタンスがあります。
    4. レイヤーには多くのインスタンスがあり、インスタンスには多数のスタックがあります。

リファレンス


Jayendra’s Blog

この記事は自己学習用に「AWS OpsWorks – Certification(Jayendra’s Blogより)」を日本語に訳した記事です。