AWS ソリューションアーキテクトが初級ハンズオンで受けた疑問を解説

チャットに投稿した文字列を AI サービスである Amazon Comprehend で感情分析を行い、結果に対応した顔文字を表示するという機能もついています。

ハンズオンで行った内容は以下になります。

• AWS CloudFormation を使って仮想ネットワーク環境を構築
• Amazon EC2 で T 系(バースト可能) インスタンスを構築
• チャットアプリケーションのダウンロード、起動 (ハンズオン用の作成済みのアプリケーションを使用しています)
• チャットアプリケーションの動作確認
• Amazon Comprehend にアクセスするための IAM ポリシーの設定
• チャットアプリケーションの変更を行い、Amazon Comprehend による感情分析機能を追加

また、上記だけでは余力がある方に向けては追加の手順として、以下を行って頂きました。

• データベースを Amazon RDS (Relational Database Service) の DB インスタンスに外出しし、データベースの可用性の向上
• 複数のインスタンスを起動し、ELB (Elastic Load Balancing) を使ったロードバランシングでアプリケーションの可用性の向上

最終的な構成はこんな感じです。

※ ハンズオン用の構成のため、アプリケーションを構築する上でこの構成がベストということではありません。
※ 皆様が構築するアプリケーションにとってどのような構成がベストなのかは、AWS のソリューションアーキテクトに相談してみましょう !

この構成を作っていく上で、参加者の方から頂いた質問についてご紹介していきたいと思います！

ハンズオンのはじめに、AWS CloudFormation を使って仮想ネットワーク環境を構築して頂きました。アプリケーションやデータベースの可用性の向上のために、複数の Availability Zone (Multi-AZ) の構成を取っています。

なぜMulti-AZにしているのでしょうか？

まず、Availability Zone について簡単に振り返りたいと思います。

Availability Zone は 1 つ以上のデータセンターで冗長化されており、停電や災害などの問題から安全に隔離されています。Availability Zone 単体 (Single-AZ) でも十分な可用性を提供することができます。しかし、非常にまれですが、同じ場所にあるインスタンスすべての可用性に影響する障害が発生してしまうことがあります。

すべてのインスタンスを Availability Zone の 1 か所でホストしている場合、そのような障害が起きるとすべてのインスタンスが利用できなくなります。そのため、AWS では Multi-AZ を利用して可用性を高める形を推奨しております。

開発環境やお試しの場合などは Multi-AZ の必要はないかもしれません。動かすアプリケーションにどこまで可用性をもたせるのかによって、Single-AZ、Multi-AZ を選択していただくと良いと思います。

Amazon EC2 でインスタンスを建てる際に、バーストパフォーマンスインスタンスの「t2.micro」を選択しました。こちらは無料枠の対象ともなっており、ユースケースとして開発環境やテストやステージングの環境の他にも、様々なワークロードでご利用いただけます。

そもそもバーストパフォーマンスインスタンスとは何なのでしょうか ?

バーストパフォーマンスインスタンスは、ベースラインという予め定義された CPU 使用率を下回る場合に「CPU クレジット」というものを貯めておくことができます。そして突発的に負荷が高まった際に、貯めておいた CPU クレジットを消費してベースラインを超えた CPU 使用率を使用できるインスタンスタイプになります。

ちなみにバーストパフォーマンスインスタンスに割り当てられるマシンスペック (CPU 数やメモリ数など) 自体には変更はありません。CPU クレジットやバーストについての詳細はこちらのブログにまとまっておりますのでご参照ください。

スケールアップはインスタンスのマシンスペック (CPU 数やメモリ数など) を増加させる形になります。現状利用しているインスタンスタイプよりも大きなインスタンスタイプに変更し、マシンスペック全体を強化します。
インスタンスのスペックについてはこちらをご参照ください。

また、オートスケーリングについても触れておくと、オートスケーリングはインスタンス自体の性能を操作するものではなく、負荷を処理するために適切な数のインスタンスを起動、または終了 (スケールアウト / スケールイン) するものになります。
スケールアップとスケールアウトの違いについては、前回の超入門セミナーの記事にて紹介しております。

Amazon EC2 のインスタンス上にアプリケーションを動かすために、インスタンスにログインする必要があります。「サーバにログイン」というと Terraterm や iTerm などのターミナルソフトを利用した公開鍵認証やパスワード認証によるSSHログインが一般的かと思います。

今回のハンズオンではターミナルソフトを使わずに、AWS サービスの Systems Manager の機能であるセッションマネージャーを利用しました。

SSH 接続の場合、インスタンスに SSH ポートでアクセスするために、インスタンスのセキュリティグループに SSH ポート (22) を許可する必要があります。セッションマネージャーを使用する場合はセキュリティグループで SSH ポート (22) の許可設定は必要ありません。インスタンスにセッションマネージャーでアクセスするためのエージェントの設定や IAM ポリシーの設定が必要となります。またセッションマネージャーは NatGateway や PrivateLink を利用することで、プライベートなサブネットのインスタンスにもアクセス可能です。プライベートサブネットへの接続については以下ナレッジセンターの記事をご参照ください。

Systems Manager を使用してインターネットアクセスなしでプライベート EC2 インスタンスを管理できるように、VPC エンドポイントを作成するにはどうすればよいですか ? »

また、セッションマネージャーは AWS コンソール経由のアクセスとなるため、AWS コンソールへのアクセス権限が必要です。セキュリティグループの管理や AWS コンソールへのアクセス管理をどの様に行うかなど、要件に合わせて選択いただければと思います。

今回のハンズオンは、仮想ネットワーク環境を AWS CloudFormation で作成しました。AWS CloudFormation のテンプレートを作成すれば、同様の環境を手軽に構築することが可能です。では AWS CloudFormation を利用せずに構築した AWS 環境を複製するにはどうすればよいでしょうか ?

1 つの方法として、CloudFormation のテンプレートを新たに作成し、既存の AWS 環境のインポートを行う形です。インポートしたテンプレートを元に新たなAWS環境を構築します。インポートの方法についてはこちらのブログを参照ください。

またこの記事を連載している時点ではまだベータ版なのですが、CloudFormer (ベータ) を使用して既存の AWS リソースから AWS CloudFormation テンプレートを作成することが可能です。

注意: CloudFormer は現在ベータ版です。重要な環境や本番環境では使用しないことをお勧めします。

いかがでしたでしょうか。「ISV/SaaS 事業会社対象：今日から一緒にはじめよう！初級ハンズオン」にて頂いた質問について解説させて頂きました。
AWS を実際に触り始めた方々の疑問を解消する手助けになれば幸いです。

今後も ISV/SaaS 事業会社に向けたイベントを開催しますので、皆様から頂いた質問や疑問などを定期的に紹介していきたいと思います。ISV/SaaS 事業会社対象：AWS おすすめセミナー情報もチェックしてみてください !

「初歩的なことなので聞きづらい」「聞くのが恥ずかしい」などと考える必要はありません ! クラウドや AWS に関する疑問や課題などがありましたら、遠慮なく AWS のソリューションアーキテクトに相談頂ければと思います !

どんどん質問を投げて、疑問点を解消していきましょう！