この演習では、AWS (アマゾン ウェブ サービス) で LANSA イメージをサブスクライブして、LANSA スタックがイメージのいずれかを利用できるようにします。このイメージは、Amazon マシンイメージ、または (AMI)
注意：このステップは、LANSA 製品センターの AWS アカウントを使用している場合は、必要ありません。 |
上記の目的を達成するには、以下のステップを完了してください。
AWS Marketplace を利用するために AWS コンソールへのアクセスを取得します。
下に示されているパフォーマンスと価格例を確認してください。
また、次のガイドラインも確認してください。
Cloud Formation のテンプレートを利用して、LANSA スタックに複数の AWS リソースをインスタンス化できます。スタックの構成方法は無数にありますが、ここではいくつかの例を挙げて、スタックが1時間あたりにどのくらいのコストがかかるのか計算します。
経験からすると、m3.medium Webサーバーは、それぞれが約 10 人の同時ユーザーを処理できます。
CPU % 使用率が 50% 以下の場合、平均応答時間は RDS のインスタンス・タイプに依存します。
また、アプリケーションのパフォーマンスもそれぞれ異なります。根本的に異なると言ってもよいでしょう。ですから、アプリケーションの負荷テストが非常に重要となります。クラウドを使うことで、これを簡単に行うことができるので、やってみましょう。
マルチ AZ 配置は、単一障害点を最も少なくするために推奨されているアーキテクチャです。ただし、このアーキテクチャではトランザクションの半分がデータセンター (AZ） の外にある別の AZ に移動して RDS に接続する必要があるため、パフォーマンスが 20% 低下してしまいます。厳密にはこれは正しくはありませんが、同様のパフォーマンスを達成するために、より多くの EC2 インスタンスやより大きな RDS インスタンスを使用する可能性があり、その結果、時間単位の課金としてフォールト・トレランスのコストが増加します。
マルチ-AZ RDSを追加すると、スレーブを最新に保つために RDS が時間を費やす必要があるため、さらに遅くなる可能性があります。
EC2 インスタンス・タイプを小さく抑えておくと、スケール・アウトをより細かく調整できるので便利です。ただし、標準的なトランザクションの CPU 要件がベンチ・マークテストより高い場合、EC2 インスタンス・タイプのサイズを大きくしなければいけない場合もあります。そこで、負荷テストツールを使うと、予想されるトランザクションのワークロードを見れるので大変便利です。様々な負荷の下でアプリケーションがどのように動作するか、事前に観察することができます。また、インスタンス・サイズの調整も簡単で、アプリケーションのニーズに最適な組み合わせを測定することも可能です。
一度に多くのインスタンスを起動すると、MSI インストールを完了するのに非常に時間がかかります。これは、DB アクセス部分が一度に多くのインスタンスがウェブレットを発行して競合するためです。これは行わない方がよいでしょう。1 つか 2 つの Web サーバーを指定し、自動スケーリング・グループを使って、必要に応じさらに多くのインスタンスをスケールアップできます。
インスタンスを使用する前に、すべてのインスタンスが CPU % 0 の落ち着いた状態に達していることを確認することが非常に大切です。AWS コンソールを使って、作成時間順にリスト表示し、直近の 12 件ほどを選択して CPU 時間をグラフ表示します。小さな画像をクリックすると詳細が表示されます。
アプリケーションの負荷が安定していない場合、マイクロ・インスタンス (例： t3.micro) が解決策になります。