AWSのスポットインスタンス(Zabbix)を手動で止めてみた。
目的
・スポットインスタンスを手動で止められると聞いたので実践してみたい
・API検証用のZabbixサーバーを構築したい
環境
OS:Amazon Linux 2
インスタンスタイプ：t2.micro
Zabbix :4.0.16
MariaDB:5.5
実践
スポットインスタンス作成
まず、AWSのコンソール画面から画面上部のサービスをクリックします。
表示された画面からEC2をクリックします。
EC2画面からインスタンス画面に移動し、画面上部のインスタンス作成をクリックします。
AMIの選択でAmazon Linux 2を選択します。
インスタンスタイプの選択でt2.microのまま、インスタンスの詳細の設定に進みます。
★ここからの設定が今回のポイントになります！
購入のオプションのスポットインスタンスのリクエストにチェックを入れる。
チェック後に表示された最高価格に値を入力し、永続的リクエストにチェックを入れます。
チェック後に表示された中断操作を停止に設定します。
そのほかの設定をデフォルト設定のまま、ストレージの追加に進みます。
デフォルト設定のまま、タグの追加に進みます。
デフォルト設定のまま、セキュリティグループの設定に進みます。
Zabbixで使うのでHTTPも追加し、ソースをMyIPのみに絞ります。
確認と作成をクリックします。
起動をクリックします。
キーペア作成画面で新規のキーを作成します。
確認にチェックを入れ、スポットインスタンスのリクエストをクリックします。
スポットリクエストを表示をクリックします。
インスタンスに移動します。
インスタンスが作成されました！停止もできそうです！
Zabbixサーバの構築
※以下に記載されている # や $ から始まるものはコマンドです。
ホスト名変更
teratermでインスタンスのグローバルIPへsshでアクセスします。
「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し、インスタンスを作成した際に設定したキーを指定します。
※ユーザー名：ec2-user
ログイン出来たら、以下を参考にホスト名を変更し、再起動します。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/set-hostname.html
$ sudo hostnamectl set-hostname [ホスト名]
$ vim /etc/sysconfig/network
※/etc/sysconfig/networkに以下を追記
HOSTNAME=[ホスト名]
$ sudo reboot
起動してきたら再度ログインしホスト名が変更できていることを確認します。
$ hostname
パッケージのインストール
rootユーザーに変更します。
$ sudo su -
ZabbixのリポジトリのGPGキーをインポートします。
# rpm -import http://repo.zabbix.com/RPM-GPG-KEY-ZABBIX
Zabbixのリポジトリを追加します。
# rpm -i https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-2.el7.noarch.rpm
必要なZabbix関連のパッケージをインストールします。
※zabbix-senderとzabbix-getは必須ではありません。
# yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent zabbix-web-japanese zabbix-sender zabbix-get Loaded plugins: extras_suggestions, langpacks, priorities, update-motd (略) Complete!
Zabbixのパッケージがインストールされていることを確認します。
# rpm -qa | grep zabbix zabbix-server-mysql-4.0.16-1.el7.x86_64 zabbix-get-4.0.16-1.el7.x86_64 zabbix-web-mysql-4.0.16-1.el7.noarch zabbix-web-japanese-4.0.16-1.el7.noarch zabbix-sender-4.0.16-1.el7.x86_64 zabbix-release-4.0-2.el7.noarch zabbix-web-4.0.16-1.el7.noarch zabbix-agent-4.0.16-1.el7.x86_64
DBのインストールとセットアップ
MariaDB関連のパッケージをインストールします。
# yum install mariadb-server mariadb Loaded plugins: extras_suggestions, langpacks, priorities, update-motd (略) Complete!
MariaDBのパッケージがインストールされていることを確認します。
# rpm -qa | grep mariadb mariadb-5.5.64-1.amzn2.x86_64 mariadb-libs-5.5.64-1.amzn2.x86_64 mariadb-server-5.5.64-1.amzn2.x86_64
# systemctl enable mariadb Created symlink from /etc/systemd/system/multi-user.target.wants/mariadb.service to /usr/lib/systemd/system/mariadb.service. # systemctl is-enabled mariadb enabled
MariaDBを起動します。
# systemctl start mariadb # systemctl status mariadb ● mariadb.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2020-01-17 06:38:23 UTC; 4s ago (略)
MariaDBの初期セットアップをします。
# mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):※何も入力せずにEnter
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
Set root password? [Y/n] Y
New password:※rootユーザーのパスワードを設定する
Re-enter new password:※r再度rootユーザーのパスワードを入力する
Password updated successfully!
Reloading privilege tables..
... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n]※何も入力せずにEnter
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n]※何も入力せずにEnter
... Success!
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n]※何も入力せずにEnter
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n]※何も入力せずにEnter
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!
MariaDBの初期セットアップが完了したので、Zabbixのデータベースを作成します。
# mysql -uroot -p Enter password:※先ほど作成したrootユーザーのパスワードを入力する Welcome to the MariaDB monitor. Commands end with ; or \g. (略) MariaDB [(none)]>create database zabbix character set utf8 collate utf8_bin; Query OK, 1 row affected (0.00 sec) ※以下がzabbixユーザーの作成コマンドです。 'password'を変更することでZabbixユーザーのパスワードを任意で決めることができます。 MariaDB [(none)]>grant all privileges on zabbix.* to zabbix@localhost identified by 'password'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> quit; Bye
ZabbixのDBに必要なテーブルの定義を設定します。
zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix Enter password:※先ほど作成したzabbixユーザーのパスワードを入力します。
Zabbix関連の設定
/etc/zabbix/zabbix_server.confのバックアップを作成し、編集します。
※MariaDB上のzabbixユーザーのパスワードを設定します。
# cp -p /etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server.conf.org
# ls /etc/zabbix/zabbix_server.conf*
/etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server.conf.org
# vim /etc/zabbix/zabbix_server.conf
※124行目あたりの以下の部分を編集します。
変更前：# DBPassword=
変更後：DBPassword=MariaDBのzabbixユーザーのパスワード
バックアップファイルとの差分を確認をします。
# diff /etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server.conf.org 124c124 < DBPassword=password --- > # DBPassword=
編集した箇所のみ表示されれば、問題ありません。
/etc/httpd/conf.d/zabbix.confのバックアップを作成し、編集します。
※GUI上の時刻表示を変更します。
# cp -p /etc/httpd/conf.d/zabbix.conf /etc/httpd/conf.d/zabbix.conf.org
# ls /etc/httpd/conf.d/zabbix.conf*
/etc/httpd/conf.d/zabbix.conf /etc/httpd/conf.d/zabbix.conf.org
# vim /etc/httpd/conf.d/zabbix.conf
※20行目あたりの以下の部分を編集します。
変更前：# php_value date.timezone Europe/Riga
変更後：php_value date.timezone Asia/Tokyo
# diff /etc/httpd/conf.d/zabbix.conf /etc/httpd/conf.d/zabbix.conf.org
20c20
< php_value date.timezone Asia/Tokyo
---
> # php_value date.timezone Europe/Riga
設定が完了したら、関連サービスの自動起動を設定し再起動します。
# systemctl enable zabbix-server zabbix-agent httpd Created symlink from /etc/systemd/system/multi-user.target.wants/zabbix-server.service to /usr/lib/systemd/system/zabbix-server.service. Created symlink from /etc/systemd/system/multi-user.target.wants/zabbix-agent.service to /usr/lib/systemd/system/zabbix-agent.service. Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service. # systemctl restart zabbix-server zabbix-agent httpd
ZabbixのWebGUIにアクセス
webブラウザから「 http://ZabbxiサーバのグローバルIP/zabbix 」にアクセスします。
※Zabbixの画面が表示されない場合は、AWSのセキュリティグループを確認し80番ポートがあっているか確認してください。
以下の画面が表示されたら、画面右下の「Next step」をクリックします。
画面に表示されている項目が、全て「OK」になっていることを確認してください。
問題がなければ、「Next step」をクリックします。
Passwordの欄には、MariaDB上のzabbixユーザーのパスワードを入力し、「Next step」をクリックします。
Zabbxiサーバーの表示名を入力してください。(任意)
「Next step」をクリックします。
表示された確認内容に問題がなければ、「Next step」をクリックします。
「Finish」をクリックします。
Zabbixのログイン画面が表示されたら、以下を入力し「Sign in」をクリックします。
Username:Admin
Password:zabbix
ログイン出来たら、構築完了です！
スポットインスタンスを停止してみる
AWSのコンソール画面からEC2 → インスタンスへ移動します。
Zabbixサーバーにチェックを入れ、「アクション」→「インスタンスの状態」→「停止」をクリックします。
当たり前ですが、先ほど構築したZabbixも表示されません。
Zabbixサーバーを起動してみます。
グローバルIPが変更されているので、再びIPを確認し「 http://ZabbxiサーバのグローバルIP/zabbix 」にアクセスします。
Zabbixのログイン画面が表示されました！
感想
Azureでは、スポットインスタンス停止できるのに、AWSではできないのは不便だなーと考えていたので、今回スポットインスタンスが停止できてうれしいです。
これでより安価に色々試せますね！
Zabbixは、この状態でAMIを取っておけば、何時でも新規Zabbixサーバーを作成できるのでおすすめです!!
以上です。
Python3メモ 「a, b = b, a+b」はどのような順番で計算させれるのか
今回の内容
「a, b = b, a+b」はどのような順番で計算させれるのか。
環境情報
windows10
Python 3.8.1
何故疑問に思ったのか
pythonの勉強をしようと思い、問題集を解いていた際にフィボナッチ数列に関する問題がありました。 自分で作ったコードだと、結果は期待通りのものができましたが、気持ち悪いくらい強引な書き方をしていました。
a = 1
b = 1
while a < 2 ** 6:
print(a)
print(b)
a += b
b += a
そこで、すっきりとした書き方を知るために回答を確認したところ、以下のようなコードが記載されていました。
a=b=1
while a < 2 ** 6:
print(a)
a, b = b, a+b
すごいシンプルですね。。
恥ずかしながら、この時に初めて変数に同時に値を入れられることを知りました。
そして、いざ自分の書いたコードを修正しようと思った時に、動きがよくわからなったため調べてみようと思いました。
ちなみに、正解の実行結果は以下になります。
1 1 2 3 5 8 13 21 34 55
検証
最初は単純にばらして、以下のようにすればよいのではないかと考えていました。
a=b=1
while a < 2 ** 6:
print(a)
a = b
b = a+b
実行結果は以下のようになりました。。
1 1 2 4 8 16 32
改めて考えてみると、修正したコードは以下とほぼ同じなので、当たり前の動きなのですがますますよくわからなくなりました。
a=1
print(a)
while a < 2 ** 6:
print(a)
a += a
デバックのため以下のコードを実行しました。
a=b=1
while a < 2 ** 6:
print(a,b,a+b)
a = b
b = a+b
出力結果は以下になりました。
1 1 2 1 2 3 2 3 5 3 5 8 5 8 13 8 13 21 13 21 34 21 34 55 34 55 89 55 89 144
上記の出力結果(右端のa+b)をもとに考えると、どちらを先に計算するというよりかは、まったく同時に計算しているようですね。
結論
「a, b = b, a+b」は「a=b」、「b=a+b」のどちらも計算される前の値を使っているということがわかりました。 つまり、ばらしてコードを書く場合は、「a」を追加する前の「b」という値を維持する、ほかの変数を用意するのが手っ取り早いと思います。 修正したコードは、以下になります。
a=b=c=1
while a < 2 ** 6:
print (a)
b += a
a = c
c = b
出力結果
1 1 2 3 5 8 13 21 34 55
出来ました！！けど、かなり野暮ったいコードになりますね。。
動きは理解できたので、次回から使っていこうと思います！
AWS初心者学習⑪ ～CloudTrailについて～
今回は、CloudTrailについて書いて行きたいと思います。
前回書いたCloudWatchと似ているので、違いをちゃんと認識しておく必要があります。両方とも監視目的で使われることが多い機能ですが、この2つは監視対象が異なります。ざっくり比較すると、CloudWatchは、「利用者が作成したサービス、アプリ、インフラ」が対象です。一方、CloudTrailはAWSを利用するユーザーを対象にします。
では、今回もAWSの公式サイトを参考にまとめていきたいと思います。
CloudTrailについて
AWS CloudTrailは、AWSアカウントのガバナンス、コンプライアンス、および運用とリスクの監査を行えるように支援するAWSのサービスです。ユーザー、ロール、またはAWSのサービスによって実行されたアクションは、CloudTrailにイベントとして登録されます。
要するに、AWS上でどのユーザーが、何を行ったのかというログを取れるってことですね！
CloudTrailイベント
CloudTrailイベントは、AWSアカウントのアクティビティのレコードです。このアクティビティは、CloudTrailによってモニタリングされたユーザー、ロール、またはサービスによって実行されるアクションとすることができます。AWSには以下、2種類のイベントが存在します。
管理イベント
管理イベントでは、AWSアカウントのリソースで実行される管理オペレーションについての洞察が得られます。これらのイベントは、コントロールプレーンオペレーションとも呼ばれます。管理イベントには、以下のようなものが存在します。
・セキュリティグループの設定
・デバイスの登録
・データをルーティングするルールの設定
・ログ記録設定
他にも、ログインイベントの記録などもあります。
データイベント
データイベントでは、リソース内で実行されたリソールオペレーションについての洞察が得られます。これらのイベントは、データプレーンオペレーションとも呼ばれます。
・Amazon S3オブジェクトレベルのAPIアクティビティ
・AWS Lambda関数の実行アクティビティ
データイベントは、デフォルトでは無効になっています。
CloudTrailのリージョン設定の種類
全てのリージョンに適用される証跡
すべてのリージョンに適用される証跡を作成すると、CloudTrailは、各リジョーンでイベントを記録し、指定したS3パケットにCloudTrailイベントログファイルを配信します。証跡作成後、新たに追加されたリージョンに対しても自動的に適用されます。
1つのリージョンに適用される証跡
1つのリージョンに適用される証跡を作成する時に、CloudTrailはそのリージョンのみでのイベントを記録します。
※「CloudTrailで設定できる証跡の種類」、「1つのリージョンに適用される証跡」両方ともログは、S3バケットに配信されます。
CloudTrailの運用イメージ
CloudTrailは、前回記載したCloudWatchと連携させることで不正使用などをいち早く検知できます。
以下、イメージです。
- AWSユーザーAがEC2インスタンスに対して不正な操作(削除など)を実行
- CloudTrailが、AWSユーザーAの不正な操作を検知
- CloudTrailからCloudWatchへ、EC2インスタンスが不正な操作をされたことについて連携
- CloudTrailからCloudWatchへ連携されたことを、トリガーlambdaを実行
- AWS管理者に連絡するため、lambdaからAWS SNSを実行す
- AWS管理者に対して、SNSからメールが送られる。
以上です。 次回からは、AWSのストレージについて書く予定です。
AWS初心者学習⑩ ～CloudWatchについて～
今回は、CloudWatchについて書いていきたいと思います。
CloudWatchは、AWSが提供する監視機能です。
CloudWatchは、lambdaやSNSと連携させることで、運用が非常に楽になります。
私は、業務でZabbixを担当していたことがありますが、よく言えば柔軟な監視ができるのでなかな苦労しました。
なので、費用などで問題がなければ、サーバーレスであるCloudWatchの方が便利そうに感じます！
では、今回もAWSの公式サイトを参考にまとめていきたいと思います。
CloudWatch
CloudWatchでは、アプリケーションを監視し、システム全体におけるパフォーマンスの変化に対応して、リソース使用率の最適化を行い、運用上の健全性を統括的に把握するためのデータと実用的なインサイトが提供されます。CloudWatchは、ログ、メトリクス、およびイベントという形式でモニタリングデータと運用データを収集し、AWSとオンプレミスのサーバーで実行されるAWSのリソース、アプリケーション、およびサービスの統合されたビューをユーザーに提供します。CloudWatchを使用して、環境内における異常動作の検知、アラームの設定、ログとメトリクスを平行させた視覚化、自動化されたアクションの実行、問題のトラブルシューティング、およびインサイトの検出を行い、アプリケーションのスムーズな実行を維持することができます。
要するに、AWSもオンプレも、アプリもリソースもサービスも詳細に監視、分析できますよーってことです！
CloudWatchを利用するメリット
アプリケーションとインフラストラクチャ全体に対する単一プラットフォームでのオブザーバビリティ(可視性)
近代的なアプリケーションは、メトリクス、ログ、およびイベントといった形式で大量のデータを生成します。Amazon CloudWachでは、単一のプラットフォームでAWSとオンプレ両方のリソース、アプリケーション、サービスデータ情報を取得、収集可能です。データを分析するために役立ち、システム全体の可視性を確保して、問題をすばやく解決することが可能になります。
AWSおよびオンプレミスでメトリックスを収集するための最も簡単な方法
CloudWatchを使用することにより、AWSのリソースとアプリケーションのモニタリングが簡単にできます。AWSの70を超える機能を詳細に監視可能です。オンプレミスの環境でも、CloudWatchエージェントもしくはAPIを使用することで監視可能です。
運用パフォーマンスとリソース最適化の向上
CloudWatchには、事前定義された閾値、または移乗動作を識別する機械学習アルゴリズムのいずれかに基づいてアラームを設定し、アクションを自動化することが可能です。 CloudWatch Eventsを使用すれば、lambdaやSNS、CloudFormationなどのサービスでワークフローをトリガーにすることができます。
運用可視性とインサイトの取得
パフォーマンスとリソース使用率を、最適化するために必要な詳細なデータ(最大1秒に細分化されたデータ)を、長期間(最大15カ月間)保存可能です。 Metric Mathを実行すると、それら運用データを分析することができます。
ログからの実用的なインサイトの獲得
CloudWatchでは、運用上の問題を簡単にトラブルシュートできるように、ログを調査、分析、視覚化することが可能です。CloudWatch Logs Insightsでは、実行するクエリにのみ課金されます。
CloudWatchダッシュボードを使用し、ログベースのメトリクスを作成し、アラームを設定することでログと」メトリクスを相互に関連付けることが可能です。
実際のCloudWatch画面
以下の画像は、前回Lambdaの記事を書いた際に実施した、S3のCSVファイルをJSONファイルに変換するlambdaのログです。
「テキストがUTF-8じゃねえ！！」って怒られてますね。。（笑）
こんな感じにlambdaが想定通りの結果にならないような場合でも、CloudWatch Logsで確認すれば原因を特定できたりします。
lambdaに関しては、特に何も設定しなくてもモニタリングタブからログを確認することができます。
運用イメージ
また、実際の運用で使う際は、こんな感じのイメージだと思います。
その他にも、CloudWatch Eventsを使用することで「CPU使用率が90％を超えたらサーバを再起動させる」、「プロセスが落ちたことを検知したら、プロセスを再起動させる」など自動で障害対応させることも可能です。
※ログファイルの監視をする際は、対象のサーバーにCloudWatchのエージェントを入れる必要があります。
以上です。
次回はCloudTrailについて書きたいと思います。
AWS初心者学習⑨ ～lambdaについて～
今回は、lambdaについて書いていこうと思います。 hit
lambdaはうまく使えば、AWS料金を抑えることもできます。
AWSソリューションアーキテクトで、色々な問題にかかわってきたりするのできちんと「メリット(できること)」、「連携できるAWSの機能(主要な機能)」、「課金条件」 は押さえておきましょう！
では、AWSの公式ページを参考に詳細を書いていきます。
lambda
AWS Lambdaを利用することで、サーバーのプロビジョニングや管理をすることなく、コードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金は発生しません。
Lambdaを実行している時間に対してのみ、課金されるってことですね！
lambdaの利点
・サーバ管理が不要
AWS lambdaでは、コードを自動的に実行します。サーバーのプロビジョニングや管理は必要ありません。必要なのは、コードを書いてLambdaにアップロードすることのみです。
一言で説明するとlambdaは、サーバーレスでアプリを実行できる機能です。
・継続的スケーリング
AWS lambdaでは、毎回トリガーに対応してコードを実行することにより、自動的にアプリケーションをスケールします。コードを平行して実行され、トリガーごとに個別に処理され、ワークロードのサイズに合わせて性格にスケールします。
・ミリ秒単位の課金
AWS lambdaでは、コードが実行される100msごと、およびコードがトリガーされた回数に対して課金されます。コードが実行されていないときは、料金はまったく発生しません。
lambdaに登録されているプログラムの実行時間に対してのみ、課金されるってことですね！
lamdbaと連携できるAWSの機能
※ソリューションアソシエートでは以下の機能のうち、★の付いている機能と連携できることを覚えておけばよいと思います！
Lambda 関数を同期的に呼び出すサービス
・Elastic Load Balancing (Application Load Balancer)★
・Amazon Cognito
・Amazon Lex
・Amazon Alexa
・Amazon API Gateway★
・Amazon CloudFront (Lambda@Edge)★
・Amazon Kinesis Data Firehose
・AWS Step Functions
Lambda がイベントを読み取るサービス
・Amazon Kinesis
・Amazon DynamoDB★
・Amazon Simple Queue Service★
Lambda 関数を非同期的に呼び出すサービス
・Amazon Simple Storage Service★
・Amazon Simple Notification Service★
・Amazon Simple Email Service★
・AWS CloudFormation
・Amazon CloudWatch Logs★
・Amazon CloudWatch Events★
・AWS CodeCommit
・AWS Config
・AWS IoT Events
動きのイメージをつかむために、実際に使ってみました！
以下の手順を参考にさせていただきました。
実行イメージはいかになります。
curlコマンドの実行結果は以下のような感じでした！
StatusCode : 200
StatusDescription : OK
Content : {"message": "Hello from AWS Lambda"}
Connection: keep-alive
x-amzn-RequestId:ba39eb4a-eeed-4d36-97fa-e584d7688c09
x-amz-apigw-id: EpqKzHhctjMFsrw=
X-Amzn-Trace-Id:Root=1-5df3bd78-a1ab52c7f6753578671f3912;Sampled=0
...
Forms : {}
Headers : {[Connection, keep-alive], [x-amzn-RequestId, ba39eb4a-eeed-4d36-97fa-e584d7688c09], [x-amz-apigw-id, EpqKzHhctjMFsrw=], [X-Amzn-Trace-Id,
Root=1-5df3bd78-a1ab52c7f6753578671f3912;Sampled=0]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 36
★webブラウザからcurlコマンドを実行できるサイトもあります。
他にも、もう一つ実行してみました！ 参考にさせていただいたのは以下の手順になります。
イメージは以下になります。
ここにcsvファイルをアップロードすると、
こちらにjsonファイルに変換されて出力されました！
試すのは非常に簡単なので、ぜひ実践してみましょう！
ちなみに、lamdaの実行結果はcloudwatchの機能で確認できます。
次回は、そのCloudWatchについて書く予定です。
AWS初心者学習⑧ ～ELBについて～
今回はELBについて書いていきたいと思います。
可用性の高いシステムを構築するためには非常に重要な機能です。もちろん、試験でも多くかかわってきまので、きちんと理解しておいた方がよいです。
ELB(Elastic Load Balancing)について
ELBをターゲット(Amazon EC2インスタンス、コンテナ、IPアドレス、Lambda関数)の前段に配置することで、アプリケーションへのトラフィックを複数のターゲットに自動的に分散します。これにより、スケールアップを容易にすることが可能となり、単一障害点もなくすことが可能です。ELBは、変動するアプリケーショントラフィックの負荷を、1つのAZで処理できます。ELBでは、3種類のロードバランサーが用意されています。
Application Load Balancer(ALB)
Application Load Balancerは、HTTP/HTTPSトラフィックの負荷分散に最適です。ALBを使用すると、マイクロサービスやコンテナといった最新のアプリケーションアーキテクチャを対象とした高度なリクエストルーティングを実現できます。
ALBは、レイヤー7で動作し、リクエストの内容に基づいて、Amazon VPCにあるターゲットにトラフィックをルーティングします。
Network Load Balancer(NLB)
Network Load Balancerは、きわめて高いパフォーマンスが要求されるTCP、UDPおよびTLSにおけるトラフィックの負荷分散に最適です。
NLBは、レイヤー4で動作し、Amazon VPCにあるターゲットにトラフィックをルーティングします。また、きわめて低いレイテンシー(遅延)を維持しながら、1秒間に何百ものリクエストを処理できます。NLBは、突発的なトラフィックパターンや急変するトラフィックパターンを処理できるように最適化されてもいます。
Classic Load Balancer(CLB)
CLBは、複数のAmazon EC2インスタンスにおける基本的な負荷分散を提供し、レイヤー7とレイヤー4の両方で動作します。CLBは、EC2-Classicネットワーク内で構築されたアプリケーションを対象としている。
★ALBとCLBは同様に、レイヤー7での負荷分散を行いますが、後継であるALBの方が、機能を費用も優れています。ですので、特別な要件がなければALBを使用することをお勧めします。
ELBの利点
・高い可用性
ELBでは、受信トラフックが複数のAZにあるターゲットに分散され、健全なターゲットにのみトラフィックがルーティングされます。
また、ELBを使用すると、リージョン内での負荷分散が可能となり、異なるAZにある健全なターゲットにトラフィックがルーティングされます。
イメージはこんな感じです！
①まず、2つのWebサーバ用インスタンスの前段にELBを配置します。
②そうすることで、Webサーバ用インスタンスAで障害発生した際にトラフィックをWebサーバ用インスタンスBにのみルーティングします。
③その後、ELBがWebサーバ用インスタンスAの復旧をヘルスチェックで確認した際は、Webサーバ用インスタンスAにもトラフィックのルーティングを再開します。
・セキュア
ELBは、Amazon VPCとともに機能し、証明書管理、ユーザー認証およびSSL/TLS複合の統合といった堅牢なセキュリティ機能を提供します。
これらが組み合わされることで、TLS設定を柔軟に集中管理し、CPUを集中的に使用するアプリケーションの負荷を柔軟にオフロードできるようになります。
・弾力性
ELBは、ネットワークトラフィックパターンの急速な変化に対応できます。
また、Auto Scalingとの密接な統合により、手動での操作を必要とすることなく、様々なレベルのアプリケーション負荷に対応することが可能となり、アプリケーションの性能を十分に発揮させることができます。
簡単に言うと、負荷が増えた際にリソースを必要な分だけ追加し、必要がなくなれば不要なリソースを削除するようにできます。
・柔軟性
ELBでは、IPアドレスを使用してアプリケーションターゲットにリクエストをルーティングできます。これにより、アプリケーションターゲットを柔軟に仮想化することが可能となり、同じインスタンスでより多くのアプリケーションをホストできます。
また、同じネットワークポートを使用しながら各ターゲットアプリケーションに対して、個別にセキュリティグループを設定することが可能となり、マイクロサービスのアーキテクチャーにおけるアプリケーション間通信がさらに簡素化されます。
・堅牢なモニタリングと監査
ELBを使用すると、Amazon CloudWatchメトリクス、ロギング、リクエスト追跡を用いてアプリケーションとそのパフォーマンスをリアルタイムでモニタリングできるようになります。これにより、アプリケーションんぼ動作をより詳細に把握することが可能となり、問題の発見およびアプリケーションスタックにおけるパフォーマンスのボトルネックの特定、リクエスト単位で細かく行えるようになる。
・ハイブリット負荷分散
ELBによって、同じロードバランサーを使用してAWSおよびオンプレミスのリソースにかけての負荷分散が可能になります。これにより、オンプレミスアプリケーションのクラウドへの移行、バースト、フェイルオーバーが簡単になります。
Auto Scaling
システムの利用状況に応じて自動的にELBに紐づくインスタンスの台数を増やす、または減らす機能です。
要するに、システムの自動スケールアウトですね。
最小構成時の台数と最大構成時の台数、そして増減させる際の条件を設定することで利用できます。
例：最小2台
最大4台
増大条件：CPU使用率が80%を超えた場合 など
減少条件：CPU使用率が30%を下回った場合 など
動きのイメージは以下になります。
①まず、既存のシステムが存在します。
②上記の環境のWebサーバ用インスタンスA,BのCPU使用率が80％を超えた場合は、以下のようにインスタンスC,Dが追加されます。
③その後、CPU使用率が30％以下になった際にインスタンスが削除されます。
スケールイン時に削除されるインスタンスは条件はデフォルトでは、
・インスタンスの数が多いAZが対象
・次回の課金されるタイミングが最も短いもの
もう少し細かい条件がありますが、個人的には一先ずこの当たりを押さえておけばよいと思います。
ざっくりとした流れはこんな感じです！
ELBの関連用語説明
・スケールアップ
EC2のインスタンスのタイプを上げること。増える負荷に対して、サーバーのスペックをあげることで対応する方法のこと。
・スケールアウト
EC2のインスタンスの数を増やし、負荷(処理)を分散すること。
対象のシステムやレイヤーにもよりますが、Webサーバではこちらがベストプラクティスとされています。また、逆に台数を減らすことをスケールインといいます。
・単一障害点
特定の部分が止まってしまうと全体が止まってしまう箇所のこと。
可用性の高いシステムを構築するためには、できるだけ単一障害点をなくすことが重要です。
AWS初心者学習⑦ ～EC2について～
今回はEC2について書いていきます。
EC2は、AWS環境にシステムを構築する上で、一番基礎となる部分だと思います。
当然、ソリューションアソシエートの試験でも重要になってくるので、EC2とは何か、どんな種類、オプションが存在するのかは把握おいた方がよいです。
EC2とは
EC2を利用すると、Amazonが管理するハードウェア上に、仮想サーバーを立てることができる。それにより、利用者はハードウェアを意識する必要がなくなり、迅速にアプリケーションの開発、デプロイが可能になる。
Amazon EC2を使用して必要な数(またはそれ以下)の仮想サーバを起動して、セキュリティおよびネットワーキングの設定と、ストレージの管理を行う。
Amazon EC2では、要件定義や需要増に対応して迅速に拡張または縮小できるため、サーバートラフィック予測が不要になる。
個人的なメモとしては、EC2でインスタンスを作成するとインスタンス起動時にのみ課金されます。ただ、インスタンスに紐づいているEBSと呼ばれるボリュームには課金されるため注意。私は、気がつかずにしばらく課金されていました。。
AMI(Amazon Machine Image)とは
EC2インスタンスを作成する際に使用するイメージ(テンプレートみたいなもの)。Redhat用linuxやAmazon linux、Windows Serverなど色々なOSを提供している。
また、利用者が作成したインスタンスをバックアップとしてAMIにすることもできる。
AMIとスナップショットの違い
両方ともバックアップという観点で、使用されることがあり混同しがちなので調べました。違いは以下になります。
・スナップショット
EC2に紐づいているEBSのバックアップ。EC2の構成管理情報などは含まれない。
簡単に言えば、仮想サーバー上に乗っかっているデータをバックアップするイメージ。
・AMI
インスタンスの起動に必要な情報をEBSスナップショットと紐づけて取得する。
復元する際は取得したOSイメージを元に新規のサーバとして再構成が必要で、
OSクローン展開時などに利用される。簡単に言えば、スナップショットとインスタンスのOSなどを含め、複製保存しているイメージ。
Amazon EC2の種類と性能
インスタンスは作成する際のAMIによって性能が決まっている。(もちろん後からスケールアップも可能です。)AMIの名前の頭文字になっているアルファベットによってどんなインスタンスなのか判断できる。
例えば、aやtから始まるインスタンスは汎用型、cから始まるインスタンスはCPU最適化型、xやrから始まるインスタンスはメモリの最適化型を表す。
命名の基準は以下になります。
種別+バージョン+サイズ
t 2 .micro
t2.microの場合はこんな感じですね！
個人的には、やっぱり高スペックのものは高くなりますので、後からスケールアウトできる構成にして、そんなにバッファを持たせずに丁度いいサイズを選択するべきだと思います。
Amazon EC2のインスタンスオプション
EC2にはオプションとして以下のような購入オプションがある。オプションの種類を理解し使い分けることで、大幅にコストを削減できるのでかなり重要。
・オンデマンドインスタンス
秒単位で使用するインスタンスに対して支払いを行い、長期的な確約や前払いは不要。
一番スタンダードなタイプですね。
・Savings Plans
1～3年の期間、定期的な使用量を守ることによりAmazon EC2コストを削減できる。
・リザーブインスタンス
1～3年の期間、インスタンスタイプとリージョンを含む特定のインスタンス設定を守ることにより、Amazon EC2コストを削減できる。
長期的に使用することが決まっている際に、便利です。
・スポットインスタンス
未使用のEC2インスタンスをリクエストして、Amazon EC2コストを大幅に削減できる。
AWS側のリソースが枯渇してくると、使用中に突然消えてしまう可能性があるため注意が必要です。AutoScaling時などに増設分に対して利用すると効果的だと思います。
以上です。
次は、ELBについて書く予定です。
